Qu’est-ce qu’Oracle Data Integrator (ODI) ? Présentation et concepts clés

Dans les grandes organisations, les données sont éparpillées : une base pour la comptabilité, une autre pour les ressources humaines, des fichiers, des applications métier… Les faire communiquer, les consolider dans un entrepôt de données ou les migrer d’un système à l’autre est un enjeu majeur. C’est précisément le rôle des outils d’intégration de données, et Oracle Data Integrator — ODI — est l’un des plus répandus dans l’écosystème Oracle.

Cet article présente ODI simplement : ce que c’est, à quoi il sert, sa particularité (l’approche « E-LT »), ses concepts clés, son architecture et ses versions. De quoi comprendre l’outil, que vous soyez développeur, chef de projet ou simplement curieux du sujet.

Les informations de cet article s’appuient sur la documentation publique d’Oracle. Les numéros de version évoluent : ils sont donnés à titre de repère historique.

Qu’est-ce qu’Oracle Data Integrator ?

Oracle Data Integrator est un outil d’intégration de données. Sa mission : extraire des données de sources variées (bases de données, fichiers, applications), les transformer (filtrer, agréger, joindre, nettoyer) et les charger dans une cible (souvent un entrepôt de données ou une autre base). En bref, il fait circuler et met en forme les données entre les systèmes d’une entreprise.

ODI n’est pas né chez Oracle : il est issu du rachat, fin 2006, d’une société française nommée Sunopsis, dont le produit se distinguait justement par une approche originale de l’intégration. Oracle en a fait l’un des piliers de sa gamme d’intégration de données, à côté de son ancien outil historique (Oracle Warehouse Builder).

À quoi ça sert concrètement ?

Les cas d’usage d’ODI sont nombreux, mais tournent tous autour de la circulation des données :

• Alimenter un entrepôt de données (data warehouse) : consolider des données issues de plusieurs systèmes pour l’analyse et le reporting.
• Migrer des données d’un système ancien vers un nouveau, lors d’un changement d’application.
• Synchroniser des données entre plusieurs bases ou applications.
• Traiter de gros volumes par lots (batch), typiquement la nuit, pour préparer les données du lendemain.

C’est un outil de l’ombre, rarement visible de l’utilisateur final, mais essentiel : sans intégration de données fiable, pas de tableaux de bord justes, pas de migration réussie, pas de données cohérentes entre les applications.

La particularité d’ODI : l’approche E-LT

C’est LE point qui distingue ODI de beaucoup d’outils concurrents. La plupart des outils d’intégration classiques sont des ETL : Extract, Transform, Load (extraire, transformer, charger). Dans cette approche, les données sont extraites de la source, envoyées vers un serveur intermédiaire dédié (le moteur ETL) qui effectue les transformations, puis chargées dans la cible. Les données transitent donc deux fois, et il faut installer et maintenir ce serveur intermédiaire.

ODI, lui, adopte une approche E-LT : Extract, Load, Transform (extraire, charger, transformer). L’ordre des lettres change, et ce n’est pas un détail. Au lieu de transformer les données dans un moteur intermédiaire, ODI pousse la transformation directement dans la base de données source ou cible. C’est le moteur SQL de la base elle-même qui exécute les transformations.

Les avantages de cette approche sont concrets :

• De meilleures performances : on exploite la puissance de calcul des bases de données, conçues pour exécuter du SQL efficacement, plutôt qu’un moteur intermédiaire.
• Pas de serveur intermédiaire à installer et maintenir, ce qui simplifie l’architecture.
• Les données transitent une seule fois, directement de la source vers la cible.
• Une grande flexibilité : le développeur peut choisir où s’exécute la transformation (côté source ou côté cible).

Les concepts clés d’ODI

Pour comprendre ODI, quelques notions reviennent systématiquement.

La topologie. C’est la description de l’infrastructure : les serveurs, les bases de données, les connexions physiques et logiques sur lesquels ODI va travailler. On la configure avant tout développement.

Les modèles. Ils décrivent la structure des données à manipuler : les tables, les colonnes, les contraintes. ODI peut les récupérer automatiquement par « reverse-engineering » (rétro-ingénierie) à partir des bases existantes.

Les mappings (ou interfaces). C’est le cœur du travail de développement : un mapping décrit comment les données passent des sources vers la cible, avec toutes les transformations (filtres, jointures, agrégations). On le construit graphiquement, en reliant les éléments — ce qui rend les flux lisibles et faciles à maintenir. (Dans les versions plus anciennes d’ODI, on parlait d’« interfaces » ; le terme « mapping » s’est imposé à partir de la version 12c.)

Les Knowledge Modules (KM). C’est sans doute la notion la plus caractéristique d’ODI, sa « recette secrète ». Un Knowledge Module est un modèle de code réutilisable pour une tâche d’intégration donnée. Plutôt que d’écrire à la main le code de chaque transformation, on applique un KM qui génère le code adapté. Il existe plusieurs types de KM selon la tâche : chargement (LKM), intégration dans la cible (IKM), contrôle de qualité des données (CKM), rétro-ingénierie des métadonnées (RKM), capture des changements (JKM). Le grand avantage : pour changer la façon dont un flux est physiquement exécuté, il suffit de changer le KM appliqué, sans réécrire le mapping.

L’architecture en bref

ODI repose sur quelques composants (illustrés dans le schéma plus haut) :

• Le référentiel (repository) : une base de données qui stocke toutes les métadonnées — configuration, projets, mappings, journaux d’exécution. On distingue généralement le référentiel « maître » (infrastructure, sécurité) et les référentiels « de travail » (les objets développés). Plusieurs référentiels peuvent coexister (développement, test, production…).
• Le Studio : l’interface graphique où travaillent développeurs et administrateurs. Il s’organise en modules — Designer (concevoir les mappings), Topology (décrire l’infrastructure), Operator (suivre les exécutions), Security (gérer les droits).
• L’agent : le composant qui orchestre l’exécution. C’est lui qui, au moment de lancer un traitement, récupère le code généré et l’envoie aux bases source et cible pour exécution.

Les versions d’ODI

Depuis son intégration chez Oracle, ODI a connu deux grandes générations. La version ODI 11g a été largement déployée pendant des années ; on y développait des « interfaces », et l’outil s’intégrait à l’écosystème Oracle Fusion Middleware. La version ODI 12c a marqué une évolution importante : introduction des « mappings » (plus souples que les anciennes interfaces, avec des composants réutilisables), refonte de la gestion des Knowledge Modules par composant, et améliorations de performance et d’ergonomie. Oracle a également décliné ODI en version cloud et l’a rapproché d’autres briques comme GoldenGate (pour la capture de données en temps réel).

Comme pour tout logiciel d’entreprise, chaque version majeure s’accompagne de versions correctives et de prérequis techniques (notamment une version de Java compatible). Avant toute installation, il est essentiel de vérifier la matrice de compatibilité officielle d’Oracle.

ODI face aux autres outils

ODI n’est évidemment pas seul sur le marché de l’intégration de données. Il coexiste avec d’autres outils ETL/ELT, propriétaires ou open source, chacun avec ses forces. Le choix dépend du contexte : un environnement fortement orienté Oracle tirera naturellement parti d’ODI et de son approche E-LT ; d’autres contextes privilégieront des outils différents selon leurs bases de données, leurs volumes ou leur budget. Comme souvent, il n’y a pas d’outil « meilleur » dans l’absolu, seulement des outils plus ou moins adaptés à une situation donnée.

En résumé

Oracle Data Integrator, en quelques idées clés :

• C’est un outil d’intégration de données : extraire, transformer et charger des données entre systèmes.
• Sa particularité est l’approche E-LT : la transformation est poussée dans les bases de données elles-mêmes, sans serveur intermédiaire — d’où de meilleures performances.
• Ses concepts clés : topologie, modèles, mappings et surtout les Knowledge Modules, ces modèles de code réutilisables.
• Son architecture repose sur un référentiel, le Studio et l’agent.
• Deux grandes générations : 11g (interfaces) et 12c (mappings), plus les déclinaisons cloud.

ODI est un outil puissant, taillé pour les gros volumes et les environnements Oracle, qui récompense la compréhension de ses concepts. Une fois la logique E-LT et les Knowledge Modules assimilés, on dispose d’un outil d’intégration à la fois performant et flexible.