El uso principal y secundaria con un número desconocido de filas

Djrc:

Tengo una tabla con información sobre la implicación de servicio para un grupo de personas como en el código siguiente, que estoy corriendo en Oracle.

CREATE TABLE SRVC_EPISODES
(
   CASE_INDEX        NUMBER (10),
   CLIENT_ID         NUMBER (10),
   SRVC_ID           NUMBER (10),
   SRVC_START_DT     DATE,
   SRVC_END_DT       DATE,
   SRVC_END_REASON   VARCHAR2 (70 BYTE)
);

INSERT INTO SRVC_EPISODES VALUES (1, 1, 3747, TO_DATE('03/28/2017', 'mm/dd/yyyy'), TO_DATE('06/27/2017', 'mm/dd/yyyy'), 'Full Completion');
INSERT INTO SRVC_EPISODES VALUES (2, 1, 5231, TO_DATE('02/16/2018', 'mm/dd/yyyy'), TO_DATE('06/30/2018', 'mm/dd/yyyy'), 'Service Transfer');
INSERT INTO SRVC_EPISODES VALUES (3, 1, 3929, TO_DATE('07/01/2018', 'mm/dd/yyyy'), TO_DATE('07/01/2018', 'mm/dd/yyyy'), 'Service Transfer');
INSERT INTO SRVC_EPISODES VALUES (4, 1, 6688, TO_DATE('07/13/2018', 'mm/dd/yyyy'), TO_DATE('10/19/2018', 'mm/dd/yyyy'), 'Full Completion');
INSERT INTO SRVC_EPISODES VALUES (5, 2, 73, TO_DATE('10/03/2017', 'mm/dd/yyyy'), TO_DATE('06/30/2018', 'mm/dd/yyyy'), 'Service Transfer');
INSERT INTO SRVC_EPISODES VALUES (6, 2, 201, TO_DATE('05/07/2018', 'mm/dd/yyyy'), TO_DATE('06/30/2018', 'mm/dd/yyyy'), 'Service Transfer');
INSERT INTO SRVC_EPISODES VALUES (7, 2, 8102, TO_DATE('06/02/2018', 'mm/dd/yyyy'), TO_DATE('06/30/2018', 'mm/dd/yyyy'), 'Service Transfer');
INSERT INTO SRVC_EPISODES VALUES (8, 2, 4164, TO_DATE('07/01/2018', 'mm/dd/yyyy'), TO_DATE('03/20/2019', 'mm/dd/yyyy'), 'Incomplete');
INSERT INTO SRVC_EPISODES VALUES (9, 2, 2066, TO_DATE('07/01/2018', 'mm/dd/yyyy'), TO_DATE('12/02/2019', 'mm/dd/yyyy'), 'Failed Classes');

Una cuestión que me encuentro con es que muchas veces, un individuo se transferirán los proveedores a mitad de camino a través de su servicio, como se indica por las diferentes SRVC_IDs y la SRVC_END_REASON anterior, al ordenar por CLIENT_ID -> SRVC_START_DT -> SRVC_END_DT.

En el siguiente ejemplo, CLIENT_ID # 1 tiene dos episodios de servicios distintos - uno que tuvo lugar del 03.28.2017 - 27.06.2017, que se completó con éxito. Su siguiente servicio sin embargo, se llevó a cabo con tres proveedores diferentes (tres IDs de servicios distintos), y se llevó a cabo a partir de 02/16/2018 a 10/19/2018, que también completaron con éxito.

CLIENT_ID # 4 también cuenta con dos episodios de servicios distintos. La primera tuvo lugar desde el 03/10/2017 y finalizó el 20/03/2019 con una incompleta. Su próximo episodio de servicios tuvo lugar del 07/01/2018 hasta 12/02/2019, que fracasaron. A pesar de que esto puede ser difícil de ver, CASE_INDEX # 9 es un servicio diferente que el servicio anterior no tenía 'transferencia' como una razón final del servicio (agrupados por CLIENT_ID, a continuación, ordenados por SRVC_START_DT, entonces SRVC_END_DT).

Yo diría que el mayor problema que estoy corriendo en es que el número de transferencias para cada cliente no es fijo, si tienen alguna transferencias en absoluto. Si tenemos que, supongamos que el número máximo de transferencias sería 5.

Sé que la solución a este implica el uso de avance / retardo, pero después de mucha lucha no puedo encontrar la manera. Mi objetivo final es tener SRVC_START_DT correcta, SRVC_END_DT y SRVC_END_REASON como en el ejemplo siguiente.

Tony Andrews:

Esto parece hacerlo (junto con un par de columnas adicionales se puede prescindir de):

select v2.*
,      min(srvc_start_dt) over (partition by grp order by srvc_start_dt) new_start_dt
,      max(srvc_end_dt)    over (partition by grp order by srvc_start_dt desc) new_end_dt
,      first_value(srvc_end_reason) over (partition by grp order by srvc_start_dt desc) new_end_reason
from (
  select v.*
  ,     sum(stat) over(order by client_id desc, srvc_start_dt desc, srvc_end_dt desc) grp 
  from (
    select s.*
    ,      case when srvc_end_reason not like '%Transfer%' then 1 end as stat
    from   SRVC_EPISODES s
  ) v
) v2
order by 1;