Oracle Data Integrator

De Jose Castillo Aliaga
Ir a la navegación Ir a la búsqueda

Es tracta d'una aproximació declarativa a la transformació i integració de les dades. És a dir, un ETL o, com ells diuen, un E-LT (Extract - Load Transform). En una única ferramenta, incorpora tant la gestió dels fluxes de dades com la integració de les mateixes.

El que tracta de fer és separar les regles declaratives de els detalls d'implementació. L'arquitectura és E-LT en la que aprofita la potència de les bases de dades relacionals i en la que primer carrega les dades i després aplica les transformacions.

Arquitectura

Repositoris

Els components central de ODI són els repositoris. Ells guarden la configuració, les metadades, els projectes, els escenarios, els logs... Podem tindre més d'un repositori. Els repositoris permeten entorns separats que poden compartir metadades i escenarios. També actua com un control de versions. En ODI tenim el Master Repository i altres Work Repositories. El Master guarda els usuaris, la topologia i objectes guardats. En els de Work es guarden els objectes de desenvolupament com: Els models i metadades, projectes i escenaris d'execució.

Els repositoris són taules en una base de dades Oracle.

Interfície d'usuari

Hi ha una interfície gràfica d'escriptori per a ODI que permet administrar tota eixa arquitectura. Es separa en quatre navegadors que són:

  • Designer Navigator: Per a crear les transformacions i proves d'integritat de les dades.
  • Operator Navigator: Per gestionar la producció i monitoritzar.
  • Topology Navigator: Per a descriure l'arquitectura lògica i física. Les bases de dades, servidors...
  • Security Navigator: Per gestionar la seguretat dels usuaris, rols, perfils...

ETL amb ODI

En tots els projectes d'integració i transformació es tracta de:

  • Crear Mappings per moure i transformar les dades.
  • Automatizar l'execució dels mapes en els paquets
  • Executar els paquets i veure el resultat
  • Preparar els components desenvolupats per posar en producció
  • Implementar el control de qualitat de les dades

Projects

Navegació del Designer

Dins de la navegació del Designer trobem la part dels projectes. Ahí estan les regles de transformació de les dades com són els mappings, procedures, variables...

Models

En la navegació del Designer també trobem la part dels models, on estan les dades en les que treballarem. Els models són les dades i metadades i són una abstracció de les taules o fitxers o l'origen de dades que siga.

Mappings

El propòsit dels mappings és carregar les dades d'un origen en un destí. En ocasions les taules no tenen els mateixos camps. També pot passar que alguns camps es tinguen que modificar, calcular o buscar en altres orígens. També pot ser que les dades no siguen consistents amb les regles d'integritat implementades.

La definició dels mappings és visual, podem arrossegar els models d'origen o destí i connectar-los en fletxes. Al connectar-los, podem definir les regles del mapping. Aquesta connexió pot ser de tot el model o camp per camp. Si es fá de tot el model, podem dir si mapem per nom del field o altres criteris. Aquestes connexions fan que es guarde literalment el contingut d'un camp en un altre camp o aplicant una regla de transformació.

Exemple de Mapping on es veu que DEAR es modificat en una expression a partir del DEAR de la taula d'origen
Els diferents components que es poden afegir a un mapping

A banda de les connexions, es poden fer operacions SQL en les dades abans d'arribar al model de destí. En la captura anterior es veu un JOIN i un LOOKUP. Però tenim algunes altres. Cada component té les seues propietats i condicions.

Per crear un nou mapping anem a menú de Designer > Projects, obrim el projecte i en la secció de mappings en creem en el botó dret. A partir de ahí ja podem arrossegar els models i afegir els components. Dins de l'editor, podem arrossegar els components i models al nostre gust i fer click per veure les propietats. En el botó dret podem veure les dades guardades en eixos models.

En aquesta captura es veu cóm el LKM de SRC_SALES_PERSON está configurat en SQL to SQL

Data Loading Strategies (LKM)

Quan estem fent el mapping, les dades s'han de carregar d'alguna manera. Hi ha moltes maneres distintes contemplades dins d'ODI. En funció del tipus de dades, ODI tria la que considera més adequada. Baix de l'editor podem triar entre la visió lògica i la física. En la física podem configurar els LKM (Loading Knowledge Modules). No sempre el LKM triat és el millor ,per aixó cal veure en els LKM i configurar-los correctament. Els LKM són mòduls de programari que saben llegir les dades en el format correcte i passar-les a un format adequat per aplicar les transformacions. Són necessaris donada la gran diversitat de formats i fonts de dades que accepta ODI.

Data Integration Strategies (IKM)

També al guardar en el destí, cal utilitzar un IKM (Integration Knowledge Module). Aquest sap cóm guardar les dades de la transformació en el destí adequadament.

Data Control Strategy (CKM)

Permet definir la manera en la que es controlarà la integritat de les dades. Per defecte verificarà al menys les claus primàries.


Lògica i física

Dins d'ODI trobem que diferencien entre la part lògica i física. Es tracta d'una manera de referir-se als models tal com els interpreta ODI i el que realment està passant a nivell de bases de dades o fitxers.

Physical Architecture vs Logical Architecture

L'arquitectura física dins de Topology s'encarrega dels "drivers" per a connectar amb moltes fons de dades distintes. Pot connectar a fitxers, bases de dades de tot tipus, bases de dades Oracle, entre altres. Per a totes, proporciona un accés simplificat per a l'arquitectura lògica, que és utilitzada per els models.

Si tenim una nova font de dades, tenim que implementar, si no està, l'arquitectura física, després fer una nova lògica i un model.

Exemple amb un fitxer

Tenim un fitxer CSV a l'escriptori. (/home/oracle/Desktop). Per afegir-lo, creem un nou Physical Schema:

Esquema físic

Diu que no hi ha context al guardar, de moment no cal.

Després es crea l'esquema lògic:

Esquema lògic

A continuació ja podem crear un nou model basat en eixe esquema lògic:

Model

Després creem un nou Datastore on indiquem el nom del fitxer i el seu forma, en aquest cas sols cal dir que té una fila de capçalera, que el delimitar és el ; i els salts de lína de Unix. Després s'ha de definir el nom de les columnes, que ODI por deduir per ingenieria inversa:

Exemple d'ingenieria inversa