Integrare datelor folosind Oracle Data Integrator(ODI)

Sursă MySQL și destinație Oracle

Pentru exemplificarea rezolvarii scenariului, pentru schema destinatie se utilizeaza în seminar

numele datamart ,iar pentru staging area userul (schema) oditemp.
Fiecare student:
Va crea utilizatorii datamart și oditemp conectați fiind ca sys (conexiunea Oracle din SQL
Developer)
o create user datamart identified by datamart;
o grant connect,resource,create view,dba,unlimited tablespace to datamart;
o create user oditemp identified by oditemp;
o grant connect,resource,create view,dba,unlimited tablespace to oditemp;
 Obs: acordăm rolul de dba pentru a simplifica parcurgerea seminarului,
altfel, ar fi fost necesare provilegii individuale pe obiecte: grant
select,update,delete on clienti,... to...
va defini o conexiune în SQL Developer din MV pentru datamart (role default) unde va rula
scriptul din creare_tabele_datamart.txt;

numele tuturor obiectelor create in Repository-ul ODI pot fi personalizate prin adaugarea
numelui la sfarsitul denumirii utilizate în tutorial.

Scenariu:
Vom adăuga informații despre produse și inventar în data mart-ul nostru, dintr-o baza de date
MySQL cu informații despre produse. Vom realiza o consolidare a datelor despre produse, prin
combinarea informațiilor din două tabele sursă distincte într-o singură tabelă. De asemenea vom
prelucra datele referitoare la inventar prin transformarea unui număr de produs într-o denumire.
Pentru a realiza aceste cerințe vom folosi două metode distincte pentru joncțiunea informațiilor din
două sau mai multe surse.
Deoarece o interfață ODI este utilizată în mod obișnuit pentru a popula un singur datastore
destinație, vom crea două interfețe pentru realizarea scenariului, una pentru datele referitoare la
produse și cealaltă pentru datele de inventar.

Pentru integrarea datelor referitoare la produse:

Tabela destinatie in care dorim sa integram datele MySQL o reprezinta tabela Produse din schema
datamart. Aceasta tabela are urmatoarea structura:

Tabelele sursa sunt numite Produse si Categorie_produse și se găsesc în schema MYSQL:

sistemproductie. Cele doua tabele au structurile:
PRODUSE:

CATEGORIE_PRODUSE

Fluxul integrării:
Mapări necesare pentru integrare:

- Coloanele IDPRODUS, NUME_PRODUS, PRET_COST și PRET_LISTA vor fi populate pe baza

coloanelor denumite simiar din tabela SISTEMPRODUCTIE.PRODUSE
- Coloana TIP_PRODUS poate fi populată plecând de la coloana NUME_CATEGORIE din
SISTEMPRODUCTIE.CATEGORIE_PRODUSE legătura realizandu-se prin IDCATEGORIE
- Coloana TIP_PRODUS_PARINTE poate fi populată plecând de la aceeași coloană
NUME_CATEGORIE, prin intermediul unui self-join de la coloana ID_CATEGORIE_PARINTE
catre IDCATEGORE din aceeași tabelă
- Coloana ULTIMA_ACTUALIZARE se populează similar cu seminarul 1 (data curentă).

Sursa de date o reprezintă o bază de date MYSQL, iar staging are și destinația sunt localizate în
datamart-ul Oracle. Ca atare, vom folosi aceleași module de cunoștințe pentru încărcare și integrare
ca în seminarul anterior.

Etapa 1 - Construirea topologiei

1. Deschidem ODI Studio și ne conectăm la Repository

2. Selectăm tabul Topology, alegem secțiunea Physical Architecture și extindem nodul
Technologies
3. Facem click dreapta pe MySQL si alegem optiunea New Data Server
4. Se va deschide editorul Data server. Vom folosi ca nume pentru serverul nostru de date
SISTEMPRODUCTIE Vom folosi datele de conectare
 User:student
 Parola: stud
5. Pe tabul JDBC trebuie sa introducem manual URL-ul de conectare:
6. Testati conexiunea, salvati datele si continuati, apoi alegeti OK cand apare o fereastra de
dialog cu un reminder pentru crearea schemei fizice.

7. Apare încă o fereastră de dialog în care vom face testarea propriu zisă a conexiunii. Lăsați
nemodificată referința la Physical Agent, deoarece vrem să folosim agentul de execuție
implicit al ODI Studio. Selectați Test.

8. Dupa ce primiti mesajul ca a fost realizata cu succes conexiunea inchideti editorul.

9. Selectați MySQL→SISTEMPRODUCTIE → click-dreapta → New Physical Schema. În tabul

Definition selectăm din droplist sistemproductie atât pentru Database(Catalog) cât şi pentru
Database (Work Catalog)

10. Selectăm tabul Context. Adăugăm un nou context de mapare a unei scheme logice, folosind
ca nume pentru schema logica MySQL_SISTEMPRODUCTIE
 11. Salvăm (File→Save) şi închidem editorul.

12. Revenim la tabul Topology si cream un nou Data Server pentru tehnologia Oracle:
Nume DataServer: ODITEMP
User: oditemp
Parola: oditemp
JDBC URL: jdbc:oracle:thin:@localhost:1521:oracle

13. Selectați butonul Test Connection din bara de titlu a editorului. Alegeți să salvati datele și
continuați.

14. Selectați nodul nou creat click-dreapta → New Physical Schema. Alegem din droplist
DATAMART ca Schema(Schema) și ODITEMP ca Schema(Work Schema). De asemenea
asociem schema fizica unei scheme logice cu numele ORACLE_DATAMART folosind Contextul
Global. Salvăm și inchidem editorul.

Observați că termenul pentru zona de date în MySQL este Database (Catalog), în timp ce atunci se
definește schema fizică pentru sistemele Oracle termenul utilizat este Schema (Schema). Astfel de
diferențe între terminologiile furnizor/sistem sunt ascunse de ODI proiectantului fluxului de integrare prin
folosirea schemelor logice și a modelelor.

Etapa 2 - Reingineria modelului metadatelor

Vom crea un model nou bazat pe metadatele schemei MySQL.

1. Selectam tabul Design, extindem zona Models, selectam iconița din partea dreapta din bara
Models și apoi alegem opțiunea New Model.
2. În tabul Definition completăm/selectăm următoarele informații:

3. Selectăm tabul Reverse Engineering şi verificăm să fie ales contextul Global. Apoi selectăm
butonul Reverse Engineer din colțul din stânga sus, alegem Yes pentru a salva modelul şi apoi
închidem editorul.

4. Exindem nodul MySQL Sistem Productie, nou apărut în Model şi putem observa faptul că
tabelele categorie_produse, nivel_stocuri si produse au fost transformate in datasore-uri ODI
prin procesul de inginerie inversă dinspre baza de date MySQL.
 5. Vom repeta pașii pentru a crea un model pentru datamart. Cream modelul folosind
următoarele date:
o Nume: Oracle DataMart
o Tehnologie : Oracle
o Schema logica: ORACLE_DATAMART

6. Selectăm direct tab-ul Selective Reverse Engineering şi bifăm opțiunea Objects to Reverse
Engineer, ceea ce ar trebui să ducă la încărcarea tabelelor pentru care nu s-a făcut încă
ingineria inversă (le veti incarca pe toate 3).

7. Selectăm butonul Reverse Engineer apoi închidem editorul. În arborele nodului Oracle
DataMart se observă că au fost create data store-uri pentru toate tabelele.

În acet moment am creat în ODI, atât pentru tabelele sursă MySQL cât și pentru tabele destinație
Oracle, datastore-uri ce pot fi utilizate pentru crearea interfațelor de populare a tabelelor din data
mart.

Etapa 3 - Transferul datelor folosind o interfață ODI

I. Transferul datelor referitoare la produse
Pasul următor presupune construirea unei interfețe. Conform datelor scenariului, vom realiza o serie
de joncțiuni între tabelele sursă:

- O joncțiune între sistemproductie.produse și sistemproductie.categorie_produse pentru a

transforma codul TIP_PRODUS într-o valoare textuală;
- Un self-join pe sistemproductie.categorie_produse pentru a obține numele categoriei
produse pentru fiecare produs în parte.

Pentru a realiza aceste operații vom crea o interfață urmând următorii paşi.

1. Creem un proiect nou (din vizualizarea Projects) pe care îl vom numi MySQL-Oracle. Salvăm
(File→Save)

2. Pentru acest proiect alegem să importăm modulele de cunoştințe IKM Oracle Incremental
Update, CKM Oracle şi LKM SQL to Oracle din
C:\ORACLE\Middleware\Oracle_Home\odi\sdk\xml-reference
3. Extindem nodul First Folder şi apoi click-dreapta pe Mappings → New Mapping

4. Numim noua mapare Incarcare PRODUS. Debifăm Create Empty Dataset.

5. Selectăm datastore-ul PRODUS din modelul Oracle DataMart şi facem drag-and-drop în zona
principală

6. Selectăm datasore-ul produse din modelul MySQL SISTEM PRODUSE în zona principală

7. Repetăm procesul 6 pentru categorie_produse

8. Aducem o a doua copie a tabelei categorie_produse din modelul SistemProduse in editor,

chiar sub tabela deja existenta. Selectam tabul General din partea de jos si observam ca
pentru cea de-a doua copie a tabelei a fost alocat alias-ul CATEGORIE_PRODUSE1. Modificam
acest alias in PRODUS_PARINTE pentru a face mai usor distinctie intre cele doua tabele.
9. Pentru a crea un right join intre produs_parinte și categorie_produse adăugăm o
componentă tip join din zona din dreapta, conectam tabela categorie_produse la join apoi
conectam tabela produs_parinte la join (drag and drop conectorul de output al tabelei catre
conectorul de input al join-ului.

10. Intorucem conditia de jonctiune (CATEGORIE_PRODUSE.ID_CATEGORIE_PARINTE =

PRODUS_PARINTE.IDCATEGORIE), selectand optiunea din dreapta text_boxului Join
Condition si apoi atributele si conditia de jonctiune dintre acestea
Selectăm right join (sau left join in funcție de ordinea selectată între tabelele). Trebuie ca pe
lângă rândurile din join să fie aduse și rândurile din categorie_produse fără pereche în
produs_părinte:

11. Construim un inner join între Produse și Categorie_Produse (produse.IDCATEGORIE =

categorie_produse.IDCATEGORIE) și apoi facem drag and drop între conectorul de output al
Join și conectorul input al tabelei Produse (destinația). Selectăm OK pentru Attribute
Matching.
 12. Selectăm tabela Produs (destinație) pentru a face manual maparea pentru popularea
coloanelor TIP_PRODUS si TIP_PRODUS_PARINTE.

13. Introducem pentru coloana ULTIMA_ACTUALIZARE expresia SYSDATE.

Cu aceasta am finalizat maparile si trecem la pasul urmator> configurarea fluxului de date.

14. La Target, Integration Type selectăm Incremental Update

15. Selectam tabul Physical si observam ca cele doua jonctiuni vor fi realizate in sistemul sursa,
ceea ce va duce la diminuarea traficului de date intre sistemele sursa si destinatie.

16. Selectăm JOIN1_AP si verificam ca pentru încărcarea datelor de la sursă în zona de pregatire
a datelor (staging area) sa fie selectat modulul de cunostinte LKM SQL to Oracle, singurul
dintre cele importate potrivit pentru aceasta activitate. Daca nu este selectat il vom selecta
noi.

17. In mod similar selectam tabela țintă (Produse) ->Integration Knowledge Module -> alegem
modulul IKM Oracle Incremental Update. Dacă nu apare în droplist, e posibil să fi sărit peste
punctul 15. La Check Knowledge Module selectăm CKM Oracle.

18. Salvam. Nu e necesar să blocăm deoarece nu lucrăm în mediu multi-user.

Inainte de a rula procesul de integrare, vrem sa studiem codul pe care il va genera ODI pe baza
informatiilor pe care le-am specificat la construirea interfetei.
19. Selectam optiunea Run, iar cand apare fereastra de executie bifam optiunea Simulation apoi
selectam OK.

20. Ne apare o fereastra ce contine un Raport de simulare. Parcurgem raportul pana ajungem la
codul SQL folosit pentru a extrage informatiile din sistemul MySQL.

Putem observa implementarea jonctiunilor pe care le-am indicat grafic mai inainte.

21. Inchidem raportul si trecem la executia efectiva a interfetei, in vederea integrarii datelor.
Rulam din nou optiunea Execute, fara a bifa Simulation de aceasta data.

22. Deschidem tabul Operator (langa Designer), extindem nodul All Execution si deschidem
sesiunea Incarcare PRODUS. Observam ca au fost incarcate inregistrarile fara actualizari,
stergeri sau erori.
 23. Revenim la interfata, in tabul Mapping selectam din editor Produse→click-dreapta→ Data
pentru a vedea datele care au fost incarcate.

24. Inchidem editorul si interfata.

Pentru integrarea datelor referitoare la inventar:

Tabela destinatie este tabela Inventar, cu urmatoarea structura:

Tabela sursa MySQL se numeste Nivel_stocuri

Mapări necesare pentru integrare:
- Coloana IDPRODUS se populează din coloana cu nume similar din tabela Nivel_stocuri;
- Coloana NUME_PRODUS se preia din tabela Produse din datamart, care a fost încărcată
înainte. Procedăm așa, pentru ca informația exită deja în sistemul destinație și nu mai este
necesar să o transferăm printr-o rețea, ceea ce va duce la îmbunătățirea performanței;
- Coloana ULTIMA_ACTUALIZARE se populează în mod similar cu cele precedente.
Vom folosi încă odata aceleași module de cunoștințe, LKM și IKM.

II. Transferul datelor referitoare la inventar

1. Selectăm tabul Designer

2. Definim o a doua mapare în nodul First Folder al proiectului pe care o numim Incarcare
INVENTAR . Debifăm Create Empty Dataset.
3. Folosim ca destinație datastore-ul inventar din modelul Oracle DataMart și datastore-urile
nivel_stocuri și produse din modelul MySQL sistemproductie ca sursă.
4. Adăugăm o componentă de tip LOOKUP și una de tip AGGREGATE.
Componenta Lookup suporta si operatori de tipul <=,>= etc spre deosebire de o componenta
Join. De asemenea ea realizeaza in mod implicit o jonctiune externa stanga.
Componenta Aggregate este utilizata pentru realizarea agregarii datelor (sum, avg etc).
Lookup-ul îl legăm de nivel_stocuri și produse (nivel_stocuri.IDPRODUS=produse.IDPRODUS)
iar Aggregate de ieșirea acestuia.
5. Pentru Aggregate păstrăm doar coloanele idprodus, stoc și nume_produs iar pentru stoc
completăm expresia sum(nivel_stocuri.STOC):
6. Pentru tabela destinație, Inventar, selectăm astfel:

7. La Target→Integration Type selectăm Incremental Update

8. Selectăm tabul Physical unde ne asigurăm că pentru Inventar→Integratation Knowledge

module e selectat IKM Oracle Incremental Update iar la Check Knowledge Module e CKM
Oracle. De asemenea la Aggregate din Target Group trebuie să fie selectat LKM SQL:
 9. Validăm mapările (Butonul Validate the mapping)
10. Rulăm maparea. Putem verifica starea ei în tabul Operator
11. Putem testa că datele au ajuns în destinație folosind click dreapta pe Inventar în Logical
Model→Data. Putem, de-asemenea, să interogăm din SQL Developer tabela inventar din
utilizatorul datamart.

Bibliografie:

Hecksel, David, and Bernard Wheeler. Getting Started with Oracle Data Integrator 11g: A Hands-On
Tutorial. Packt Publishing Ltd, 2012.

Oracle® Fusion Middleware Getting Started with Oracle Data Integrator 12c