You are on page 1of 26

Realizarea unui depozit de date folosind

Oracle Warehouse Builder 11g release 2

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 sunt în schema owb_sursa/oracle pe serverul Oracle:

Pentru construirea depozitului de date vom utiliza instrumentul de dezvoltare Oracle
Warehouse Builder 11g release 2
(http://download.oracle.com/otn/nt/warehouse/OWB_11.2.0.3_Windows_x86-64.zip).

Pentru conectare se vor specifica datele proprii de identificare.
Varianta 1 Varianta 2 Varianta 3
server intern server public mașina virtuală
Username BDSA_NUME_PRENUME BDSA_NUME_PRENUME master

Password stud stud oracle
Hostname 168.192.4.65 37.120.250.20 localhost
Service name oradb oracle orclwm

Inainte de construirea efectivă a depozitului, vom verifica sursele de date utilizate, în
vederea stabilirii unor formate comune.

SEMINAR 1.. Pas 2: Stabilim numele proiectului – PROFILE_NUME_PRENUME (denumiţi-vă proiectul folosind numele Dumneavoastră!!!) .. CURĂŢAREA DATELOR Crearea unui proiect nou Pas 1: Realizăm un nou proiect: din meniul File->New.

înregistrări separate prin caractere etc. De exemplu. . Oracle Warehouse Builder asigură un integrator pentru sistemele SAP. bazei de date non-Oracle. Bazele de date (Databases). SAP sau fişiere.  Aplicaţii (Applications) = conţin definiţii ale pachetelor de aplicaţii. Atunci când se creează o locaţie. Locaţia (secţiunea B) defineşte informaţii referitoare la schema bazei de date sau la instrumente destinaţie. de exemplu validarea sau generarea de cod. Acestea pot fi baze de date Oracle sau non-Oracle. aplicaţiile (Applications) cât şi fluxurile de procese (Process Flows) sunt grupate din punct de vedere logic în module. Modulul reprezintă un mod logic de grupare a definiţiilor de obiecte. Observăm că există mai multe tipuri de obiecte incluse in proiect:  Colecţiile (Collections)=reprezintă un mecanism generic de grupare. Locaţiile sunt specifice tipurilor de module: bazei de date Oracle. 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). 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. un modul de bază de date Oracle reprezintă o grupare logică de obiecte care aparţin unei baze de date (scheme) Oracle. fişierele (Files).  Bazele de date (Databases)=reprezintă aplicaţii generale cu baze de date. Se introduc noţiunile de modul şi locaţie. 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.

Acestea sunt divizate în transformări obişnuite şi transformări pre-definite. iar în cadrul modulului sunt conţinute de pachete de fluxuri de date.LTRIM etc.  „Conversion”=pentru realizarea conversiilor dintre tipurile de date. Cele obişnuite pot fi definite sau importate de către utilizator.  In zona C se introduce noţiunea de Transformări publice (Public Transformations) = reprezintă transformări care pot fi folosite în cadrul proiectului. ca de exemplu: activarea/anularea restricţiilor. analizare tabela/schemă etc.  „Character”. Toate acestea sunt disponibile în schema destinaţie. . Codul pe care Warehouse Builder-ul îl generează pentru a reprezenta definiţiile fluxurilor de date respectă standardul XML Process Definition Language(XPDL).  „Date”=asigură un număr de transformări specifice pentru datele de tip „date”. Transformările publice sunt divizate în următoarele categorii:  „Administration”. CONCAT. în timp ce transformările pre-definite sunt legate de instalarea Warehouse Builder. ca de exemplu CHR.  Fluxuri de date (Process flows) = reprezintă definiţii ale fluxurilor de procese. Acestea sunt conţinute de module. LDAP.

Stabilirea modulului sursă Pentru realizarea procesului de Data Profiling vom folosi un modul sursă (OWB_PROFILING).  „Numeric”. SIN. inclusiv transformări NVL.  „OLAP”=asigură accesul la procedurile de încărcare a cubului şi dimensiunilor. ca de exemplu ABS. 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 .FLOOR etc.  „Other”.  „XML”=pentru a expune transformările de încărcare XML. datele curăţate fiind plasate automat într-un modul destinaţie.

65 37.192.2 11.20 localhost Service name oradb oracle orclwm Versiune BD 10.4.120.Pas2: dacă nu există o legătură predefinită se va crea una nouă pentru a încărca metadatele în modul. Astfel. tipul şi versiunea bazei de date. Datele vor fi preluate din schema utilizatorului: owb_profiling / oracle. folosiți varianta aleasă inițial: Varianta 1 Varianta 2 Varianta 3 server intern server public mașina virtuală Hostname 168. apăsăm pe butonul Edit din dreptul câmpului Location pentru a stabili legătura cu baza de date sursă.250. Pentru completarea celorlalte date solicitate.2 10.2 .

.În fereastra Connection Information verificați ca opțiunea Import after finish să fie bifată! 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 owb_profiling. viziuni. secvenţe etc. Asistentul de tip wizard Import Metadata urmărește pașii prezentaţi mai jos: Pas 1: Stabilim tipurile de obiecte pe care vrem să le importăm:tabele. .

. Pas 3: După acest pas în modulul sursă sunt incluse obiectele selectate.Pas 2: Alegem din nodul TABLE tabela T_CLIENTI. Se apasă Finish.

. rezultatul fiind vizibil în nodul Tables al bazei de date din modulul sursă: Sursa de date o consultăm alegând opţiunea Data din meniul contextual deschis prin click dreapta pe tabela sursă T_CLIENTI.La final se vor importa tabelele.

telefonului: nu există o variantă unică de stocare a datelor .oraşului: nu există o variantă unică de stocare a datelor .ţării: nu există o variantă unică de stocare a datelor .clasei clientului: există valori eronate .Se observă neconcordanţe privind datele stocate la nivelul: .

Construirea unui proces de Data Profiling După import construim un proces Data Profile 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: Odată cu crearea profilului se va deschide fereastra Data Profile Editor: .

Este necesară specificarea datelor de autentificare pentru utilizatorul system / 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.Pentru a genera profilul datelor din tabelă. La prima generare a unui profil se va solicita crearea unei scheme noi pentru stocarea datelor generate de-a lungul procesului. sunt afişate detaliat statistici privitoare la date: . selectăm din meniul Profile opţiunea Profile. Realizarea profilului se urmăreşte în zona Monitor Panel După ce se execută procesul.

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: .

care trebuie să păstreze numai valorile corecte: Pentru a realiza corecţiile se alege din meniul Profile opţiunea Create Correction .Asemănător construim regula de validare pentru CLASA_CLIENT.

Se cere construirea unui modul destinaţie (Target Module) în care să fie plasate tabelele cu corecturile de rigoare. . Il vom denumi CLIENT_CORECTAT.

a utilizatorului cu care sunteţi conectat în OWB. .Stabiliţi locaţia ca fiind schema proprie.

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: .Se urmează paşii indicaţi.

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”. astfel: . vom selecta din opțiunile aferente coloanei Cleanse Strategy strategiile de aplicare a regulilor. La pasul 5 al asistentului de tip wizard.  coloanele noii tabele curăţate (atenţie.similarity Match – pentru regula de curăţare a clasei clientului . dimensiunile coloanelor nu se preiau automat din tabela sursă.  restricţiile de tip CHECK care implementează alegerile limitate pentru valorile acceptate în coloanele ţară_client şi clasă_client.

se verifică obiectele create în tab-ul Corrected Modules din Data Profile Editor: Dând dublu click pe mapare.custom – pentru regula de curăţare aferentă ţării (va fi implementată printr-o funcţie PL/SQL) După realizarea corecţiei. în scopul vizualizării fluxului de transformare parcurs: .. putem alege să o examinăm.

iar în tabul Implementation completăm codul PL/SQL necesar: .Pentru a implementa funcţia de transformare pentru coloana tara_client efectuăm dublu click pe funcţie.

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: 1) tabele. 2) funcţii. Pentru a rula corecţiile şi a încărca datele din sursă în destinaţie. 3) maparea:  selectaţi pentru Deploy Action – CREATE  alegeţi opţiunea Deploy (generează metadatele aferente obiectelor) .Implementăm funcţia CUS_TARA_CLIENT şi o testăm (opţiunea Test Deploy Function). din meniul Tools alegem Control Center Manager.

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

La final putem observa datele corectate în tabela t_clienti din schema proprie: EXERCITII: 1. .pentru liniile în care este introdus sectorul să apară Bucureşti .pentru liniile în care este introdusă prescurtarea Buc să apară Bucureşti . Realizaţi corecţia telefonului în modulul CLIENT_CORECTAT. astfel încât: .pentru liniile în care este introdus judeţul IF (sau Ilfov) să apară Popeşti-Leordeni 2. Realizaţi corecţia oraşului în modulul CLIENT_CORECTAT.