/* exemple **
with operations
as (  
select 1 idclient, sysdate dat, 4 val from dual union all
select 1 idclient, sysdate+1 dat, 8 val from dual union all
select 1 idclient, sysdate+2 dat, 7 val from dual union all
select 2 idclient, sysdate dat, 2 val from dual ) */
select idclient, max(dat) from operations group by idclient

Par contre si on veut récupérer d’autres informations de cet enregistrement, il faut passer par une sous-requête :

select idclient,  dat,  val
from operations a
where a.dat=(select max(b.dat) from operations b where b.idclient=a.idclient )

Le problème est ( entre autres ) qu’on passe 2 fois sur la table operations, ce qui dégrade les performances.

Oracle propose depuis la 9i les fonctions analytiques, ce qui est bien pratique pour gérer ce type de problème.
On utilisera par exemple la fonction row_number(), mais on aura toujours une sous-requête :

select idclient, dat, val from (
  select idclient, dat, val,
    row_number() over(partition by idclient order by dat desc) num
  from operations
)
where num=1

Cette solution n’est pas forcément simple à implémenter du fait de la sous-requête. Un ETL comme Sunopsis/ODI ne gère pas les sous-requêtes, il faut passer par des vues et du coup on perdra le lien dans l’analyse d’impact de l’outil.
Solution miracle, on a une requête en one-shot avec la clause keep :

select idclient,
  max(dat),
  max(val) keep (dense_rank last  order by dat) val
from operations
group by idclient

Cerise sur le gâteau, on peut aussi utiliser ce type de clause dans un univers Business Objects, cela évite de passer par une table dérivée ou du sql en dur.

Que du bonheur.

Les + :

• les performances ( mode ELT )
• les KM ( modules de connaissance ) qui définissent les process « standard » ETL comme la détection des doublons, des valeurs inconnues de tables de référence ( écartés dans une table d’erreur ),
  l’alimentation des tables ( en Insert pur, Insert en delta, en SCD … )
• pas besoin de connaitre un nouveau langage, le SQL du SGBD suffit généralement !
• debugage facile
• reprise d’un plantage à partir d’un certain point ( où ça s’est planté, ou depuis le début, ou 3 sql avant … )
• optimisation orientée SGBD donc facile ( un expert ETL n’est pas nécessaire, un DBA suffit )
• l’analyse d’impact très fine
• l’éditeur de requête sql qui permet de construire des requêtes assez complexes
• les contextes qui facilitent le déploiement d’un environnement à un autre
• la séparation modèle physique / modèle logique

Les – :

• traitements unitaires basiques ( plusieurs tables constituent une requête qui alimente une seule table ) : il faut généralement utiliser des tables temporaires, le flux de la donnée n’est pas visible en un seul job.
• nécessité de connaitre les SGBD … et des fonctions complexes dans certains cas
  comme pour les comparaisons relatives entre lignes,
  par ex pour comparer un statut par rapport au statut précédent
  –> fonctions analytiques oracle
• la perte des dépendances pour l’analyse d’impact sur certains traitements
• la prise en main – il faut bien décomposer ses traitements

L’éditeur de requête SQL permet d’élaborer des requêtes complexes tout en gardant les références aux objets. Ainsi il n’y a pas besoin de coder les clauses « where », « group by » ou « having » comme dans les autres ETL, et l’analyse d’impact se fait à la colonne …

Quelques astuces :

• simuler un MINUS – je vais faire un tuto dessus bientôt …

En conclusion :
Pour moi Sunopsis/ODI fait partie des meilleurs ETL du marché, il se démarque de ses concurrents principalement par ses performances et par l’intégration des process habituels d’alimentation dans l’outil.