Realizarea unui depozit de date folosind

Oracle Warehouse Builder 11g

Introducere
In următorul studiu de caz ne propunem să construim un depozit de date pentru
activităţile comerciale ale unei societăţi, activităţi legate de aprovizionarea cu produse de la
furnizori şi desfacerea acestora către clienţi.
Datele rezultate din tranzacţii sunt stocate în tabele relaţionale. Pentru construirea
depozitului se creează tabele sau tabele virtuale noi care vor reprezenta sursele de date pentru
obiectele depozitului. În urma unor prelucrări şi transformări preliminare se obţin tabelele sursă
prezentate în schema următoare:

Tabelele utilizate la crearea depozitului sunt în schema sursa_owb/oracle pe serverul

Oracle (hostname: xpone2, service name: orclwm).
Pentru construirea depozitului de date vom utiliza instrumentul de dezvoltare Oracle
Warehouse Builder 11g release 1
(http://download.oracle.com/otn/nt/warehouse/OWB_11.1.0.6_Windows.zip).
Pentru conectare se vor specifica datele de identificare.
 Inainte de construirea efectivă a depozitului, vom verifica sursele de date utilizate, în
vederea stabilirii unor formate comune.

Partea 1. Curăţarea datelor

Pas 1: Realizăm un nou proiect: din meniul Design->New.

 Pas 2: Stabilim numele proiectului - denumiţi-vă proiectul folosind numele
Dumneavoastră!!!)

Observăm că există mai multe tipuri de obiecte incluse in proiect:

Colecţiile (Collections)=reprezintă un mecanism generic de grupare. Ele deţin o cale de

acces mai uşoară la definiţiile obiectelor pe care o folosim pentru a realiza activităţi la nivel de
grup, de exemplu validarea sau generarea de cod.

Bazele de date (Databases)=reprezintă aplicaţii generale cu baze de date. Acestea pot fi

baze de date Oracle sau non-Oracle.
 Se introduc noţiunile de modul şi locaţie.
Modulul reprezintă un mod logic de grupare a definiţiilor de obiecte. De exemplu, un
modul de bază de date Oracle reprezintă o grupare logică de obiecte care aparţin unei baze de
date (scheme) Oracle.
Bazele de date (Databases), fişierele (Files), aplicaţiile (Applications) cât şi fluxurile de
procese (Process Flows) sunt grupate din punct de vedere logic în module.
Locaţia (secţiunea B) defineşte informaţii referitoare la schema bazei de date sau la
instrumente destinaţie. Locaţiile sunt specifice tipurilor de module: bazei de date Oracle, bazei
de date non-Oracle, SAP sau fişiere. Atunci când se creează o locaţie,se memorează o definiţie
logică care conţine tipul de locaţie şi versiunea.

Fişiere (files) = reprezintă definiţii ale fişierelor (grupate ca un modul). Un modul de

fişiere defineşte o „legătură” la un director care conţine un număr de fişiere text. Putem folosi
asistentul de tip wizard pentru a importa aceste fişiere care pot conţine tipuri multiple de
înregistrări, înregistrări separate prin caractere etc.

Aplicaţii (applications) = conţin definiţii ale pachetelor de aplicaţii. Oracle Warehouse

Builder asigură un integrator pentru sistemele SAP.

Fluxuri de date (process flows) = reprezintă definiţii ale fluxurilor de procese. Acestea
sunt conţinute de module, iar în cadrul modulului sunt conţinute de pachete de fluxuri de date.
Codul pe care Warehouse Builder-ul îl generează pentru a reprezenta definiţiile fluxurilor de date
respectă standardul XML Process Definition Language(XPDL).

In zona C se introduce noţiunea de Transformări publice (Public Transformations) =

reprezintă transformări care pot fi folosite în cadrul proiectului. Acestea sunt divizate în
transformări obişnuite şi transformări pre-definite. Cele obişnuite pot fi definite sau importate de
către utilizator, în timp ce transformările pre-definite sunt legate de instalarea Warehouse Builder.
Toate acestea sunt disponibile în schema destinaţie.
 Transformările publice sunt divizate în următoarele categorii:
o „Administration”, ca de exemplu: activarea/anularea restricţiilor, analizare
tabela/schemă etc;
o „Character”, ca de exemplu CHR, CONCAT, LDAP,LTRIM etc;
o „Conversion”= pentru realizarea conversiilor dintre tipurile de date;
o „Date”= asigură un număr de transformări specifice pentru datele de tip
„date”; „Numeric”, ca de exemplu ABS, SIN,FLOOR etc;
o „OLAP”= asigură accesul la procedurile de încărcare a cubului şi
dimensiunilor; „Other”, inclusiv transformări NVL;
o „XML”= pentru a expune transformările de încărcare XML.

Stabilirea modulului sursă

Pentru realizarea procesului de Data Profiling vom folosi un modul sursă (PROFILING),
datele curăţate fiind plasate automat într-un modul destinaţie.

Pentru a crea modulul sursă procedăm astfel:

În arborele proiectului click dreapta pe nodul Oracle->New:
 Asistentul de tip wizard Create Module ne ghidează în parcurgerea următorilor paşi:
Pas1: stabilim numele modulului: CLIENTI_SURSA_NUME_STUDENT şi tipul acestuia -
modul sursă (Data Source)
 Pas2: dacă nu există o legătură predefinită se va crea una nouă pentru a încărca
metadatele în modul. Astfel, apăsăm pe butonul Edit din dreptul câmpului Location pentru a
stabili legătura cu baza de date sursă, tipul şi versiunea bazei de date.
Datele vor fi preluate din schema utilizatorului: profiling / oracle. Versiunea aleasă
pentru baza de date este 10.2. Verificaţi să fie aleasă corect.

La final va apărea un ecran care va centraliza toate configurările realizate.

Următoarea etapă este să importăm tabelele şi viziunile corespunzătoare schemei
profiling. Asistentul de tip wizard Import Metadata porneşte automat, iar paşii parcurşi sunt
prezentaţi mai jos:
Pas 1: Stabilim tipurile de obiecte pe care vrem să le importăm:tabele, viziuni, secvenţe
etc.
Pas 2: Alegem din nodul TABLE tabela T_CLIENTI.

Pas 3: După acest pas în modulul sursă sunt incluse obiectele selectate.
Se apasă Finish.
La final se vor importa tabelele:
Sursa de date o consultăm alegând opţiunea Data din meniul contextual deschis prin click
dreapta pe tabela sursă T_CLIENTI.

Se observă neconcordanţe privind datele stocate la nivelul:

- ţării: nu există o variantă unică de stocare a datelor
- oraşului: nu există o variantă unică de stocare a datelor
- clasei clientului: există valori eronate
- telefonului: nu există o variantă unică de stocare a datelor

Construirea unui proces de Data Profiling

După import construim un proces Data Profile revenind la fereastra Design Center şi
alegând opţiunea New din meniul de context deschis la click dreapta pe Data Profiles:
Denumim profilul şi selectăm tabelele pentru care urmează a fi aplicat:

Aşteptăm până apare fereastra următoare (poate dura puţin).

Odată cu crearea profilului se va deschide fereastra Data Profile Editor:

Pentru a genera profilul datelor din tabelă, selectăm din meniul Profile opţiunea Profile.
La prima generare a unui profil se va solicita crearea unei scheme noi pentru stocarea datelor
generate de-a lungul procesului. Este necesară specificarea datelor de autentificare pentru
utilizatorul sys / oracle. Selectaţi opţiunea Show Details pentru a stabili parola pentru noul user
ataşat schemei noi create şi pentru a verifica setările propuse (folosiţi ca parola: oracle).
Realizarea profilului se urmăreşte în zona Monitor Panel

Asteptăm finalizarea procesului. După ce se acesta se execută, sunt afişate detaliat statistici
privitoare la date:

Pentru a realiza corectările la nivel de ţară şi clasă de client vom selecta tab-ul Domain
Pentru definirea unei reguli de corectare a ţării clientului selectăm valorile din
TARA_CLIENT şi alegem opţiunea Derive Data Rule.

Eliminăm din lista posibilă a ţărilor variantele prescurtate şi adăugăm manual variantele
complete acolo unde ele nu pot fi preluate, conform imaginii de mai jos:
Asemenător construim regula de validare pentru CLASA_CLIENT, care trebuie să
păstreze numai valorile corecte:

Pentru a realiza corecţiile se alege din meniul Profile opţiunea Create Correction
Se cere construirea unui modul destinaţie (Target Module) în care să fie plasate tabelele cu
corecturile de rigoare. Il vom denumi CLIENT_CORECTAT.
Stabiliţi locaţia ca fiind schema proprie, a utilizatorului cu care sunteţi conectat în OWB.
Se urmează paşii indicaţi, prin alegerea tabelei asupra căreia se vor realiza corecţiile şi a
regulilor de corecţie stabilite anterior:
La pasul 4 se observă faptul că apar în tab-uri distincte informaţii privind:

coloanele noii tabele curăţate (atenţie, dimensiunile coloanelor nu se preiau automat

precum în tabela sursă, ci sunt calculate în funcţie de dimensiunile valorilor regăsite în
tabelă la momentul generării profilului)
Important! Ne asigurăm că în tabela T_CLIENTI din CLIENT_CORECTAT coloana
TARA_CLIENT are dimensiunea 10 pentru a stoca şirul „NECUNOSCUT”.

restricţiile de tip CHECK care implementează alegerile limitate pentru valorile acceptate
în coloanele ţară_client şi clasă_client.
La pasul 5 al asistentului de tip wizard, vom selecta din lista derulantă ataşată coloanei Cleanse
Strategy strategiile de aplicare a regulilor, astfel:
- similarity Match – pentru regula de curăţare a clasei clientului
- custom – pentru regula de curăţare aferentă ţării (va fi implementată printr-o funcţie PL/SQL)

După realizarea corecţiei, se verifică obiectele create în tab-ul Corrected Modules din Data
Profile Editor:
Opţional: Dând dublu click pe mapare, putem alege să o examinăm, în scopul vizualizării
fluxului de transformare parcurs:

Pentru a implementa funcţia de transformare pentru coloana tara_client efectuăm dublu click pe
funcţie, iar în tabul Implementation alegem opţiunea Code Editor.
Codul PL/SQL necesar este:

Implementăm funcţia CUS_TARA_CLIENT şi o testăm testăm (opţiunea Test).

Pentru a rula corecţiile şi a încărca datele din sursă în destinaţie, revenim la Design Center
unde din meniul Tools alegem Control Center Manager.
Alegeţi obiectele corespunzătoare locaţiei destinaţie stabilite şi parcurgeţi pe rând
etapele următoare pentru fiecare dintre grupurile de obiecte, în această ordine: 1. tabele,
2. funcţii, 3. maparea:
selectaţi pentru Deploy Action – CREATE
alegeţi opţiunea Deploy (generează metadatele aferente obiectelor)

Dacă totul se finalizează cu succes, selectaţi maparea şi alegeţi execuţia acesteia:

La final putem observa datele corectate:

EXERCITII:

1. Realizaţi corecţia oraşului în modulul CLIENT_CORECTAT, astfel încât:

- pentru liniile în care este introdus sectorul să apară Bucureşti
- pentru liniile în care este introdusă prescurtarea Buc să apară Bucureşti
- pentru liniile în care este introdus judeţul IF (sau Ilfov) să apară Popeşti-Leordeni

2. Realizaţi corecţia telefonului în modulul CLIENT_CORECTAT.