1.

Etape n crearea unui proiect ETL

Pentru a utiliza ODI este necesar crearea a dou baze de date de repository care sunt cunoscute
sub denumirea de Master Repository i Work Repository.
n Master Repository se memoreaz structura diferitelor tipuri de tehnologii, securitatea i
versiunile proiectelor i modelelor.
n Work Repository sunt stocate informaii legate de modelele de date, proiecte i modul cum
sunt ele utilizate.
Dup crearea Master Repository-ului se poate utiliza Topology Manager care permite
adminstrarea tehnologiile utilizate cum ar fi Essbase, Planning, flat files etc.
Prin intermediul Topology Manager se definesc topologiile din cadrul Oracle Data Integrator.
O topologie reprezint o informaie de sistem n ODI. ODI-ul utilizeaz topologia pentru a se
conecta la resurse pentru procesele de integrare.
Topologia n Oracle Data Integrator este o reprezentare complet a sistemului informatic. Prin
intermediul Topology Mananger se poate gestiona topologia sistemului informatic, tehnologiile
utilizate, serverele de date conectate la aceste tehnologii i schemele care sunt coninute,
contextele, limbajele i agenii. n plus, Topology i permite s gestionezi i repository-urile.
Modulul de Topology Manager stocheaz informaiile ntr-un master repository iar informaiile
memorate pot fi utilizate i de ctre alte module.
Prin intermediul Topology Manager, utilizatorul poate vizualiza arhitectura fizic i logic a
schemelor i componentele cu care lucreaz prin intermediul Oracle Data Integrator.
Pentru a crea o topologie se urmresc urmtorii pai:
-

Crearea contextului potrivit pentru configurrile fcute.

Crearea data server corespondent serverului utilizat n Oracle Data Integrator.

Pentru fiecare data server creat, definirea schemei fizice.

Crearea schemei logice i asocierea ei cu schema fizica din context.

Crearea agentului fizic pentru fiecare agent care ruleaz pe main.

Creare agentului logic i asocierea lui cu agentul fizic din context.

Contextele reunesc componete ale arhitecturii fizice (arhitectura real a sistemului informatic) cu
componentele scehemei logice (arhitectura pe care lucreaz utilizatorii) a Oracle Data Integrator.
Schema componentelor Topology Manager este prezentat n figura 2.1.

Fig. 2.1 Topology Manager

1.1 Crearea unui Data Server

Un data server este orice sistem capabil s stocheze date i s le fac accesibile sub form de
tabele. Data Server-ul nu este necesar s fie un DBMS (Database Management System). Data
server-ul este mereu ataat unei tehnologii cum ar fi Oracle, Sysbase, XML etc.
Exist dou modaliti ca ODI-ul s se conecte la Data Server. Cea mai utilizat este JDBC (Java
Database Conectivity). Drivere JDBC exist pentru o plaj larg de tehnologii. Celalalt
modalitate de conexiune a ODI-ului la Data Server este JNDI (Java Naming and Directory
Interface).
Fiecare instan a unui motor de baz de date tradiional cum ar fi Oracle sau Microsoft SQL
Server este un data server. Dei exist dou instane care ruleaz pe aceeai main, Oracle Data
Integrator le consider ca i cum ar fi dou data servere separate.
i baza de date Microsoft Access este un data server care accept doar o singur schem. Att
fiiere Microsoft Excel ct i fiiere servere funcioneaz ca i data server.
Sub data server se afl schemele fizice care sunt create.
Anumite tehnologii necesit instalarea anumitor componente nainte de a fi definite.

1.2 Crearea schemei fizice

Shema fizic este o subdiviziune a data server-ului dependent de tehnologia utilizat. Datastoreurile cum ar fi tabele, fiiere, topics de pe un data server sunt localizate n schema fizic.
Arhitectura fizic definete diferite elemente ale sistemului informatic ct i caracteristicile
considerate de Oracle Data Integrator.
O tehnologie manevreaz date formatate. Prin urmare, fiecare tehnologie este asociat cu una sau
mai multe tipuri de date care permit ODI-ului s genereze scripturi de manipulare a datelor.
Fiecare tip de baz de date (Oracle, DB2 etc), format de fiier (XML, file) sau software este
reprezentat n Oracle Data Integrator de o tehnologie.
Componentele fizice care stocheaz i returneaz date sunt definite ca Data Server. Un data
server care poate stoca informaii diferite conform logicii business, poate fi imprit n scheme
fizice. Un data server este mereu conectat la o singur tehnologie.
Fiecare server de baza de date, flat files etc care sunt utilizate n Oracle Data Integrator, trebuie
declarate ca data server. Fiecare schem, baze de date utilizate n ODI trebuie declarate ca o
schem fizic.
Arhitectura fizic mai conine i definiia unui agent fizic, componetele software Java care
permit ODI-ului s execute job-urile i pe un computer remote.
O schem fizic a ODI-ului corespunde la mai multe scheme:
- Data Schema n care Oracle Data Integrator va cuta structurile de date ale sursei i ale
destinaiei care sunt utilizate n interfee
- Work Schema n care Oracle Data Integrator poate crea i manipula structurile de date
temporare asociate sursei i destinaiei aflate n Data Schema.

1.3 Crearea schemei logice

Arhitectura logic permite utilizatorului s grupeze schemele fizice care conin datastore-uri
identice din punct de vedere structural dar care se afl n locuri diferite n Logical Schema,
structurate pe tehnologii.
Arhitectura logic definete agenii logici astfel nct fiecare agent care are aceeai funcie, dar
difer contextul, s aib acelai nume.

1.4 Crearea unui agent fizic

Agentul este o component run-time a ODI-ului care orchestreaz procesul de integrare prin
trimiterea de comenzi spre data server, spre sistemul de operare sau spre alte tehnologii. Acest
lucru nseamn c trimite comenzi SQL spre un data server, comenzi shell spre sistemul de
operare sau chiar comenzi SMTP spre serverul de e-mail.
Agentul este un serviciu Java care poate fi plasat ca un listener pe un port TCP/IP. Acest serviciu
permite:
-

Execuii ale sesiunilor la cererea modulelor din Oracle Data Integrator. Pentru acest lucru
trebuie lansat mai ntai un agent listener.
Execuia unor scenarii programate, n plus fa de execuia scenariilor la cerere. Agentul
fizic conine schedulator opional care permite scenariilor s se lanseze automat conform
programelor predefinite. Pentru acest lucru trebuie mai ntai lansat un agent schedulator.

Un agent fizic poate delega execuia unui alt agent fizic.

Ca i data server-urile, agenii fac parte din topologie. Agenii fizici din topologie corespunde cu
agenii care ruleaz la run-time. Oricum, trebuie definii i agenii logici care sunt asociai
ageniilor fizici prin intermediul contextului.

2. Knowledge Module
Knowledge Module-urile (

2.1 Tipuri de Knowledge Module

Check Knowledge Modules (CKM)

Are rolul de a verifica dac datele care se ncarc respect restriciile de integritate. CKM-ul este
folosit pentru a menine integritatea datelor i , n principiu, particip la asigurarea calitii
datelor. CKM poate fi folosit n 2 moduri: pentru a verifica consistena datelor existente sau
pentru a asigura consistena datelor nainte de a fi ncrcate n datastore-ul destinaie.
CKM accepta un set de restricii de integritate i numele tabelului care se dorete a fi verificat.
Dac exist nregistrri care au fost respinse se nregistreaz n tabelul de erori E$.
Loading Knowledge Modules (LKM)
Se utilizeaz pentru a ncrca datele surs dintr-un server remote ntr-un staging area. Este folosit
n interfee n momentul n care unele datastore-uri surs nu sunt pe acelai server de date ca
staging area. LKM implementeaz reguli declarative ce trebuie executate pe serverul surs i
extrage un singur set de rezultate care sunt ncrcate ntr-un tabel C$ n staging area.
O interfa poate avea nevoie de mai multe LKM cnd utilizeaz datastore-uri din diferite surse.
Cnd toate datastore-urile surs se afl pe acelai server ca i staging area nu este nevoie s fie
utilizat niciun LKM.
Integration Knowledge Modules (IKM)
IKM are rolul de a scrie datele finale, transformate, n destinaie. Fiecare interfa utilizeaz un
singur IKM. IKM i ncepe activitatea dup ce toate fazele ncrcrii datelor pentru serverul
remote au fost ndeplinite cu succes. Asta nseamn c toate nregistrrile sursei remote au fost
ncrcate de LKM n tabela temporar C$ a staging are-ului sau c datastore-urile surs sunt
pe acelai server de date ca staging area. Prin urmare, IKM, trebuie doar s execute
transformrile, join-urile i filtri pe tabela C$. nregistrrile rezultate sunt procesate de ctre IKM
i scrise n tabela temporar I$ nainte de a fi ncrcate n destinaie. Transformrile finale ale
nregistrrilor pot fi scrise n moduri diferite n funcie de IKM ales n interfa. Ele pot fi

adugate la surs sau verificate pentru a fi ncrcate incremental. Exista 2 tipuri de IKM-uri: cele
care presupun c staging area se afl pe acelai server ca datastore-ul destinaie i cele care nu
presupun c staging area se afl pe acelai server.
Cnd staging area se afl pe acelai server ca destinaia atunci IKM execut urmtorii pai: se
execut clauza SELECT pentru muta staging area i regurile declarative ale destinaiei n tabelele
C$ i n tabelele locale. Aceast aciune genereaz un set de rezultate. Opiunea de append
scrie direct setul de rezultate n tabelul destinaie. IKM-urile care au opiuni mai complexe
creaz un tabel I$ pentru a memoriza rezultatele. Dac fluxul de date trebuie verificat pentru a
vedea dac respect restriciile de integritate, IKM-ul cheam CKM pentru a scrie erorile n
tabelul I$. Apoi, IKM, scrie rezultatele din I$ n destinaie folosind opiunile alese (update
incremental, schimbarea dimensiunilor etc). IKM terge tabela temporar I$. Opional, IKM
poate rechema CKM pentru a verifica consistena datastore-ului destinaie.
Aceste KM nu pot gestiona datele care se afl n afara serverului de destinaie. Procesarea datelor
este orientat pentru a reui s execute task-uri pe volume mari de date.
Cnd staging area este diferit de serverul destinaie, IKM, de obicei, execut urmtorii pai:
execut clauza SELECT pentru muta regurile declarative ale destinaiei n tabelele C$ i n
tabelele locale. Aceast aciune genereaz un set de rezultate. IKM ncarc rezultatul n
datastore-ul destinaie utiliznd opiunea de append sau incremental update. Aceast arhitectur
este limitat deoarece un CKM nu poate fi utilizat pentru datele care pot fi procesate. Datele
trebuie extrase din staging area nainte de a fi ncrcate n surs ceea ce poate duce la probleme
de performan.
Journalizing Knowledge Modules (JKM)
JKM creaz infrastructura pentru Change Data Capture(CDC) pe un model, sub-model sau
datastore. JKM nu sunt utilizate n interfee ci n modele pentru a determina cum sunt iniializate
infrastructurile CDC-urilor.
Service Knowledge Modules (SKM)
SKM sunt responsabile de crearea i deploy-ingul manipulrii datelor pe Web Service pe
infrastructura Service Oriented Architecture (SOA). SKM-urile sunt setate pe un model. Ele
definesc operaii diferite de generat pentru fiecare datastore a web service-ului. Spre deosebire de
celelalte KM-uri, SKM nu genereaz un cod executabil. Ele genereaz cod Java utiliznd
framework-ul Oracle Data Integrator-ului pentru Web Service. Codul este apoi compilat i apoi
instalat pe containerele Application Server.

3. Gestionarea unui proiect ce permite integrarea surselor de date

Un proiect este un grup de obiecte dezvoltate utiliznd Oracle Data Integrator. Componentele
unui proiect sunt:
Folder: anumite obiecte din proiect sunt grupate n foldere i sub foldere.
Pachetul: este cea mai mare unitate de execuie din Oracle Data Integrator. Un pachet este
construit dintr-o secven de pai organizai ntr-o diagram de execuie.
Interfa: const ntr-un set de reguli care definesc ncrcarea unui Datastore sau o structur de
date destinaie temporar dintr-una sau mai multe surse de Datastore.
Proceduri: o procedur specific este component reutilizabil care grupeaz operaii care nu se
potrivesc n framework-ul interfeei, ncrcnd un datastore destinaie din una sau mai multe
surse.
Exemple de proceduri: ateapt i unzip un fiier, trimite un batch file via FTP, primete
email-uri. O procedur poate lansa comenzi pe schemele logice definite n topologie, dar de
asemenea poate utiliza comenzi OS sau intrumente Oracle Data Integrator.
Variabil: este o valoare memorat n Oracle Data Integrator. Aceast valoare se poate schimba
pe parcursul execuiei. Valoarea:
o Are definit o valoarea de default la momentul crerii.
o Poate fi transmis ca parametru cnd ruleaz un scenariu care utilizeaz variabila.
o Se poate schimba cu paii variabilei de refresh, set i increment.
o Poate fi evaluat pentru a crea condiii n scenariu
o Poate fi utilizat n interfee, proceduri etc.
O variabil poate fi definit n afara proiectului, adic poate fi definit global, pentru a putea fi
utilizat n toate proiectele.
Secvena: este o variabil incrementat automat atunci cnd se utilizeaz. ntre dou utilizri,
valoarea este persistent. Secvenele se pot utiliza ca variabilele n interfee, proceduri etc. O
secven poate fi definit n afara proiectului pentru a putea fi folosit n toate proiectele.
User functions: permite utilizatorului s defineasc funcii customizate sau funcii alias pentru
care trebuie specificate tehnologiile necesare implementrii. Se pot utiliza n interfee i n
proceduri.
Knowledge Modules: Oracle Data Integrator utilizeaz Knowledge Modules pentru a defini
metode legate de o anumite tehnologie.
Marker: elementele unui proiect pot fi marcate pentru a reflecta metodologia de organizare a
dezvoltrilor. Steguleele sunt definite utiliznd markere. Aceste markere sunt organizate n
grupuri i pot fi aplicate la majoritatea obiectelor dintr-un proiect.

Scenariu: cnd un pachet, o interfa, o procedur sau o variabil este finalizat, este compilat
ntr-un scenariu. Scenariul este unitatea de execuie pentru producie. Acesta poate fi i
programat.
Etape n construirea unui proiect:
-

crearea unui model de reverse-engineering

crearea unui proiect

utilizarea de markere(opional)

crearea i organizarea folder-elor

importul KM-urilor

crearea i modificarea obiectelor reutilizabile: variabile, secvene, interfee, proceduri,

user function

testarea interfetelor i procedurilor

constuirea pacheteleor pentru elementele create

testarea integrarii pachetelor

generearea scenariului

programarea scenariului

gestionarea scenariilor n producie

mentenan, repararea bug-urilor i alte modificri necesare

3.1 Crearea de pachete

Pachetul este cea mai mare unitate de execuie din Oracle Data Integrator. Un pachet este
construit dintr-o secven de pai organizai ntr-o diagram de execuie.
Paii sunt de mai multe feluri. Ei pot fi grupai n familii de pai:
-

flux(interfa) execut o interfa

procedura execut o procedur

variabila declar, seteaz, refresh-uiete sau evalueaz valoarea variabilei

instrumente Oracle Data Integrator aceste instrumente, disponibile n Toolbox permit

accesul la toate comenziile Oracle Data Integrator API

modele, sub-modele i datastore-uri execut jurnalizri, control static, operaii de

reverse-engineering pe aceste obiecte.

Crearea de pachete poate fi realizat datorit urmtoarelor procese: crearea unui nou pachet,
manevrarea pailor(insert, duplicate, delete), definirea secvenelor de pai, rularea pachetului.

3.2 Crearea de scenarii

Cnd o component este terminat i testat, ea funcioneaz prin generarea unui scenariu
corespunztor strii sale actuale. Aceast operaie are loc n modulul de Designer. Este posibil s
se genereze scenarii pentru pachete, proceduri, interfee sau variabile. Ultimele 3 obiecte
genereaz scenarii cu un singur pas.
Variabilele de scenariu sunt variabile n scenariu care ar trebui setate cnd se lanseaz scenariul
n scopul parametrizrii lui.
Generarea unui grup de scenarii: cnd un set de pachete, interfee, proceduri i variabile grupate
sub un proiect sau folder au fost create i testate, ele pot fi pregatite n scopul generrii
scenariilor. Aceast operaie are loc n modulul de Designer.
Exist mai multe opiuni ce se pot efectua asupra scenariilor: export/import, criptare.
Procedura de export i de import permite transferul obiectelor Oracle Data Integrator de pe un
repository pe un alt repository. Este posibil exportul de un singur scenariu sau de mai multe
scenarii. Dup procesul de export, se creaz fiiere XML n locaia specificat.
Criptarea unui scenariu permite protecia codului din spatele lui. Dac un scenariu este criptat,
comenziile care apar n log cnd este executat scenariul, nu pot fi citite de ctre utilizator.
Oracle Data Integrator utilizeaz algoritmul de criptare DES bazat pe o cheie de criptare
personal. Aceast cheie poate fi salvat ntr-un fiier i reutilizat pentru a executa criptri i
decriptri de operaii.

3.3 Crearea de interfee

O interfa const ntr-un set de reguli care definesc ncrcarea unui Datastore sau o structur de
date destinaie temporar dintr-una sau mai multe surse de Datastore.
Compontele unei interfee sunt:
- Datastore-ul destinaie: este elementul care va fi ncrcat de interfa. Acest datastore poate fi
permanent (definit ntr-un model) sau temporar (creat de interfa n staging area).

- Datastore-ul surs: conine date menite s ncarce datastore-ul destinaie. Dou tipuri de
datastore pot fi utilizate ca surs a unei interfee: datastore-urile din modele i datastore-urile
temporare.
Datastore-ul surs al interfeei poate fi filtrat n timpul procesului de ncrcare i poate fi pus n
relaii de join. Filtrii i join-urile pot fi recuperate din definiia modelelor i de asemenea pot fi
definite pentru interfa.
- Mapri: definesc regulile de transformare pe surs capabile s genereze date pentru ncrcarea
destinaiei.
- Fluxul: este un set de strategii de ncrcare i integrare pentru datele mapate bazate pe
knowledge module-uri.
- Control Strategy: permite definirea metodei de verificare a fluxului nainte de ncrcarea n
destinaie. Control Strategy este definit de un Check Kwnoledge Module.
Interfeele utilizeaz urmtoarele componente: datastore-ul definit n modele ca surs i
destinaie pentru procesul de ncrcare; Kwnoledge Module-ulul pentru a genera procesul
necesar ncrcrii; variabilele i secvenele pentru a memora valori n expresii; user function-uri
pentru a uura coding-ul regulilor de transformare.

3.4 Crearea de proceduri

O procedur este o secven de comenzi lansate pe schemele logice. Are un grup de opiuni
asociate. Aceste opiuni parametrizeaz att dac o comand ar trebui sau nu executat ct i
codul comenzii.
Crearea unui proceduri este compus din urmtorii pai: crearea unei noi proceduri, definirea
opiunilor procedurii, crearea i gestionarea comenzilor procedurii, executarea procedurii.
Encriptarea unui KM sau a unei proceduri i permite protejarea codului. Un KM sau o procedur
criptat nu poate fi citit sau modificat dac nu este decriptat. Comenziile generate n log de un
KM criptat sau de o procedur criptat, de asemenea, nu pot fi citite.
Oracle Data Integrator utilizeaz algoritmul de criptare DES bazat pe o cheie personala de
criptare. Aceast cheie poate fi salvat ntr-un fiier i reutilizat pentru criptarea sau decriptarea
operaiilor.
Nu se poate decripta sau cripta un KM sau o procedur fr cheie de criptare, prin urmare este
foarte recomandat pstrarea cheii ntr-o locaie sigur. Este, de asemenea, recomandat utilizarea
unei singure chei de criptare pentru toate dezvoltarile.