You are on page 1of 48

ACADEMIA DE STUDII ECONOMICE DIN BUCUREŞTI

FACULTATEA DE CIBERNETICĂ, STATISTICĂ ŞI INFORMATICĂ ECONOMICĂ

Programul de masterat profesional
BAZE DE DATE – SUPORT PENTRU AFACERI

Modulul: GESTIUNEA VOLUMELOR MARI DE DATE

-- ASPECTE PRIVIND DEPOZITELE DE DATE --

Bucureşti
2016-2017

-1-

CUPRINS
DEPOZITE DE DATE.................................................................................................................... - 3 -
1. Modelul de date multidimensional ................................................................................................. - 3 -
1.1. Structura modelului multidimensional ....................................................................... - 3 -
1.2. Operaţii realizate asupra modelului multidimensional ............................................... - 7 -
1.3. Restricţii de integritate ............................................................................................... - 8 -
1.4. Modele de reprezentare a obiectelor depozitelor de date ........................................... - 9 -
2. Organizarea datelor în depozite de date ........................................................................................ - 11 -
2.1. Inteligenţa Afacerii – aspecte fundamentale ............................................................ - 11 -
2.2. Principalele tehnologii informatice utilizate în sistemele pentru Inteligenţa Afacerii- 12 -
2.3. Evoluţia şi definirea depozitelor de date .................................................................. - 13 -
2.4. Obiectivele şi caracteristicile organizării datelor în depozitele de date ................... - 15 -
2.5. Facilităţi oferite de depozitele de date sistemelor de Inteligenţa Afacerii ............... - 17 -
3. Arhitectura depozitelor de date ..................................................................................................... - 18 -
3.1. Arhitectura pe componente a depozitelor de date .................................................... - 18 -
3.2. Arhitectura pe niveluri a depozitelor de date ........................................................... - 19 -
3.3. Arhitectura depozitelor de date din punctul de vedere funcţional............................ - 20 -
4. Tipuri de depozite de date............................................................................................................. - 21 -
4.1. Tipuri de depozite de date în funcţie de aria de cuprindere ..................................... - 21 -
4.2. Tipuri de depozite de date în funcţie de procesele decizionale pentru care au fost
proiectate ............................................................................................................................... - 22 -
4.3. Tipuri de depozite de date în funcţie de modelul de date implementat .................... - 22 -
5. Aspecte comparative privind organizarea datelor în baze de date şi în depozite de date ............. - 23 -
REALIZAREA DEPOZITELOR DE DATE ............................................................................... - 25 -
1. Considerente privind realizarea depozitelor de date ..................................................................... - 25 -
1.1. Modalităţi de realizare a depozitelor de date............................................................ - 25 -
1.2. Metodologii utilizate la realizarea depozitelor de date ............................................ - 26 -
2. Etape de realizare a depozitelor de date ....................................................................................... - 28 -
2.1. Strategia de realizare a depozitelor de date .............................................................. - 28 -
2.2. Modelarea depozitelor de date ................................................................................. - 31 -
2.3. Implementarea depozitelor de date........................................................................... - 34 -
2.4. Exploatarea depozitelor de date ............................................................................... - 42 -
2.5. Criterii de evaluare a depozitelor de date ................................................................. - 44 -
2.6. Instrumente şi medii de dezvoltare utilizate pentru realizarea depozitelor de date.. - 45 -
BIBLIOGRAFIE ........................................................................................................................... - 47 -

* Varianta extinsă a materialului se regăseşte în monografia „Tratat de baze de date. Vol. I. Baze de date: organizare,
proiectare, implementare” – coord.Ion Lungu.

-2-

Gestiunea volumelor mari de date

DEPOZITE DE DATE
Un depozit de date furnizează o sursă integrată şi centralizată de date, separată de sistemul tranzacţional,
care conţine datele esenţiale despre activitatea companiei din multitudinea de surse de date existente.
Rapoartele obţinute pe baza acestor date sunt utilizate ca un instrument de analiză strategic şi competitiv,
analizele rapide şi corecte putând influenţa deciziile privind evoluţia organizaţiei pe termen mediu şi lung.

Cuvinte cheie: depozite de date, cub de date, schema de tip stea, model multidimensional, dimensiuni, fapte,
măsuri.

1. Modelul de date multidimensional

Depozitele de date sunt organizate diferit faţă de bazele de date, fiind destinate mai mult
extragerii de date decât actualizărilor repetate. Datele extrase sunt utilizate în analize dinamice care
presupun schimbări de perspectivă asupra datelor şi vizualizări ale acestora de la un nivel detaliat la
unul sintetic, agregat şi invers. Din acest motiv s-a impus o organizare specifică a datelor în care
obiectele sunt structurate pe diferite niveluri care permit această analiză dinamică.
Modelele de date utilizate pentru reprezentarea depozitelor de date au cunoscut o diversitate
destul de mare atât din punctul de vedere al teoretizării conceptelor cât mai ales din punctul de
vedere al aplicării diferitelor tipuri de modele în practică. Două direcţii importante au clasificat
totuşi această diversitate de modele şi anume dezvoltarea unor extensii ale modelului relaţional şi
dezvoltarea modelelor bazate pe cuburi n-dimensionale.
Tipul de model multidimensional utilizat de diverse tehnologii şi produse software care
implementează depozitele de date diferă atât din punctul de vedere al SGBD utilizat cât şi din cel al
operaţiilor realizate asupra datelor şi a arhitecturii implementate.

1.1. Structura modelului multidimensional

Structura modelului multidimensional conţine în principal obiectele referitoare la tabelele de
fapte cu atribute de tip măsuri sau metrici, tabelele de tip dimensiune în care regăsim niveluri
ierarhice, atribute de identificare şi atribute de descriere etc. Aceste obiecte vor fi prezentate în
continuare.
În cadrul modelului multidimensional se întâlnesc mai multe tipuri de obiecte care prezintă
o importanţă deosebită în analiză [KIRE98].
Dimensiunile – reprezintă structuri compuse formate din atribute structurate pe diverse
niveluri ierarhice în funcţie de care sunt grupate datele. Aceste atribute sunt de obicei descriptive şi
sunt folosite ca sursă pentru limitarea înregistrărilor afişate în cadrul rapoartelor analitice. Sunt
considerate tabele secundare datorită dimensiunilor reduse. Consiliul OLAP, un consorţiu al
firmelor dezvoltatoare de produse OLAP înfiinţat în 1995 cu rolul de a standardiza aceste tehnologii
prin stabilirea unor standarde deschise (OLAP API), defineşte conceptul de dimensiune ca fiind “un
atribut structural al unui cub care constă dintr-o listă de membri, pe care utilizatorii îi percep ca
fiind de acelaşi tip (de exemplu toate lunile, trimestrele, anii formează dimensiunea Timp).
Dimensiunile reprezintă un mod foarte concis, intuitiv de organizare şi selectare a datelor pentru

-3-

Gestiunea volumelor mari de date

explorare şi analiză.” [OLAP95].
Datele dintr-o dimensiune sunt structurate ierarhic, pe mai multe niveluri, fiecare dintre
acestea putând avea mai multe atribute.
Ierarhiile – sunt structuri logice utilizate pentru ordonarea nivelurilor de reprezentare a
datelor. Sunt utilizate şi pentru definirea căilor de navigare în interiorul dimensiunilor şi oferă
instrumentelor de analiză OLAP posibilitatea de detaliere graduală a datelor în rapoarte. Tot în
definiţiile date de Consiliul OLAP se menţionează că „membrii dimensiunilor pot fi organizaţi pe
baza relaţiilor de tip părinte-copil, unde un membru părinte reprezintă agregarea membrilor copil.
Rezultatul este o ierarhie şi relaţiile părinte-copil sunt relaţii ierarhice” [OLAP95].
Nivelurile – reprezintă poziţii în cadrul ierarhiilor, cu exemplificare pe dimensiunea Produs
(figura 1). De exemplu dimensiunea Timp poate avea trei niveluri de ierarhizare: an, trimestru şi
lună. Relaţiile între diferite niveluri sunt relaţii de tipul părinte-copil, însă se pot defini ierarhii în
care datele fiecărui nivel sunt agregate la un nivel imediat superior sau se poate sări peste anumite
niveluri care sunt independente.

Figura 1. Ierarhii şi niveluri ale dimensiunii Produs

Nivelurile unei ierarhii sunt esenţiale pentru determinarea tipurilor de navigări care se pot
realiza în dimensiuni. Tot consiliul OLAP precizează următoarele „doi membri ai unei ierarhii sunt
de aceeaşi generaţie dacă ei au acelaşi număr de strămoşi. Termenii de generaţie şi nivel sunt
necesari pentru a descrie subgrupuri de membri întrucât, de exemplu, deşi doi fraţi membri au
acelaşi părinte şi sunt de aceeaşi generaţie, ei ar putea să nu fie la acelaşi nivel, dacă unul din fraţi
are un copil şi celălalt nu.” [OLAP95]
Atributele – dimensiunile conţin atribute care reprezintă calificative specifice. Orice atribut
se asociază unei singure dimensiuni, iar o dimensiune se poate exprima prin mai multe atribute.
Există două tipuri de atribute: de identificare a dimensiunii şi a fiecărui nivel în parte şi atribute
descriptive care realizează o clasificare a datelor în cadrul ierarhiei.
Tabelele de fapte – sunt tabelele centrale care conţin atribute de tip măsuri (metrici) şi chei
externe către tabelele dimensiuni. Aceste obiecte conţin de obicei date numerice care pot fi
însumate şi analizate pe fiecare nivel din ierarhiile dimensiunilor.
Măsurile (metricile)- corespund atributelor (faptelor) din tabelele de fapte şi sunt de regulă
de natură numerică (de exemplu: volumul vânzărilor, costurile, stocurile disponibile). Aceste
variabile au sens numai în contextul unor anumite dimensiuni. Valoarea măsurii este calculată
pentru un punct dat prin agregarea datelor corespondente perechii aferente valoare-dimensiune,
diferite pentru punctul dat.
Sunt mai multe criterii după care se pot clasifica măsurile utilizate într-o tabelă de fapte, şi
anume: modalitatea de calcul, tipurile de funcţii agregate utilizate, modalităţile de însumare şi
agregare în funcţie de dimensiuni.
În funcţie de modalitatea de calcul atributele se pot clasifica în măsuri de bază, care se

-4-

). Măsuri algebrice . Metadatele – reprezintă poate cea mai importantă componentă a depozitului de date. statistici privind utilizarea şi multe altele. dimensiunile. Măsura este algebrică dacă este obţinută prin aplicarea unei funcţii algebrice agregate. indicatori semiaditivi care se pot însuma numai după unele dimensiuni şi indicatori neaditivi care nu se pot însuma după nicio dimensiune. Dacă rezultatul obţinut prin aplicarea funcţiei asupra a n valori agregate este acelaşi cu cel obţinut prin aplicarea funcţiei asupra tuturor datelor fără partiţionare. circulaţia datelor (active. care includ: date privind evoluţia în timp (istoricul datelor şi secvenţa de transformare aplicată asupra lor). Exemple comune de funcţii holistice sunt: MEDIAN(). Măsurile distributive – sunt calculate cu ajutorul unor funcţii de agregare distributive. O funcţie agregată este holistică. Cele mai multe aplicaţii necesită calcularea eficientă a măsurilor distributive şi algebrice. fiecare din ele obţinută prin aplicarea unei funcţii agregate distributive. MODE(). definiţiile datelor derivate. printr-o primă partiţionare a acestuia într-un set de subcuburi. De exemplu. Calcularea funcţiei pe fiecare partiţie determină o valoare agregată. algoritmii de agregare şi însumare. pot fi mai dificil de calculat în mod eficient măsurile holistice. RANK(). funcţia poate fi calculată în manieră distributivă. Presupunem că datele sunt împărţite în n seturi. cu rezultate satisfăcătoare. ierarhiile. în loc de a aplica funcţia MEDIAN( ) cu exactitate. numărul de înregistrări participante poate fi calculat. Din acest motiv funcţia COUNT( ) este o funcţie agregată distributivă.  metadatele operaţionale.sunt calculate cu ajutorul unor funcţii holistice. -5- . nu există o funcţie algebrică având M argumente (unde M este o constantă) care caracterizează calculul. există tehnici care pot determina aproximativ valoarea mediană pentru un set foarte mare de date. De exemplu. descriu conţinutul depozitului şi permit accesul direct la date. Tot la nivelul metadatelor se definesc şi diverse tabele virtuale (views) asociate unor categorii specifice de utilizatori. În mod similar se poate demonstra că funcţiile MIN( ). holistice. care include schema depozitului. în contrast. În acest caz. Măsuri holistice . Există mai multe tehnici eficiente pentru aceasta dar. Metadatele sunt intens folosite pentru administrarea depozitului de date. Există totuşi anumite tehnici eficiente de aproximare a calculului măsurilor holistice. MAX( ) şi STDEV( ) (abaterea standard) sunt funcţii algebrice agregate. Nivelul metadatelor trebuie să conţină următoarele categorii de informaţii conform [JAJE98]:  o descriere a structurii de date din depozit. În funcţie de tipurile de funcţii agregate utilizate măsurile pot fi organizate în trei categorii: distributive. Metadatele. Gestiunea volumelor mari de date regăsesc sub forma atributelor din tabelele de fapte şi care provin din sursele de date şi măsuri derivate (virtuale) care se obţin prin combinarea măsurilor de bază şi care în tabelele de fapte au precizată formula de calcul prin care se obţin. şterse) şi informaţii de monitorizare (statistici privind utilizarea depozitului de date. denumite şi date despre date. rapoarte de erori etc. Ralph Kimball în lucrarea “The Data Warehouse Toolkit” [KIMB96] clasifică metricile în trei categorii: indicatori aditivi care se pot însuma după toate dimensiunile. media (funcţia AVG( )) poate fi calculată aplicând funcţiile SUM( )/COUNT( ) unde ambele funcţii SUM( ) şi COUNT( ) sunt funcţii agregate distributive.sunt calculate cu ajutorul unor funcţii algebrice cu M argumente (unde M este un întreg pozitiv). dacă aceasta nu este limitată constant pe spaţiul de stocare cerut de deschiderea subagregării. De exemplu. dar care pot fi combinaţi cu alte variabile pentru a deveni aditivi. Din punctul de vedere al modalităţii de însumare şi agregare în funcţie de dimensiuni. conţinând informaţii despre provenienţa datelor. pentru un cub de date. O măsură holistică este obţinută prin aplicarea unei funcţii agregate de tip holistic. algebrice. arhivate. aplicând funcţia COUNT( ) pentru fiecare subcub şi apoi însumând rezultatele obţinute.

care includ termenii economici şi definiţiile aferente. ale obiectelor depozitului de date şi ale regulilor folosite pentru a transforma datele din sistemul sursă în depozit. Importanţa metadatelor pentru depozitul de date reiese din faptul că acestea stabilesc contextul depozitului de date. Gestiunea volumelor mari de date  algoritmii utilizaţi pentru sumarizare. pentru ca apoi să beneficieze de informaţiile necesare. Se pot deosebi mai multe tipuri de metadate în funcţie de destinaţia lor: Metadate administrative. precum şi orice ierarhie care poate exista în cadrul dimensiunilor.  metadatele economice (business metadata). agregări. Metadate pentru utilizatorii finali. date despre granularitate. menţin şi cresc calitatea datelor. Rolul metadatelor pentru depozitul de date reiese din următoarele considerente:  stabilesc contextul depozitului de date. structura datelor şi conţinutul propriu-zis al depozitului de date. care includ: măsura şi dimensiunea algoritmilor definiţi. Toată documentaţia tehnică a sistemelor reprezintă într-un fel sau altul metadate. Exemple de astfel de metadate sunt următoarele: conţinutul depozitului de date. agregări. istoricul încărcării depozitului de date şi regulile de eliminare. definiţiile ierarhiilor.  mapările (transformările) de la mediul operaţional la depozitul de date care includ: bazele de date sursă şi conţinutul lor. atunci se elimină orice ambiguitate legată de semnificaţia datelor. Ele rămân totuşi transparente pentru majoritatea utilizatorilor. dar şi din faptul că sunt o formă de auditare a transformării datelor. utilizatorii sistemelor de asistare a deciziei trebuie să înţeleagă înainte de toate conţinutul depozitului. Aceste metadate au rolul de a le permite utilizatorilor să- şi creeze propriile interogări şi să interpreteze rezultatele în cadrul instrumentelor de analiză utilizate. transformarea câmpurilor sursă în câmpuri destinaţie. conectări efectuate. În sistemele operaţionale. datele pot fi revăzute şi erorile pot fi corectate.  date referitoare la performanţele sistemului care includ indici şi profiluri care îmbunătăţesc accesul la date şi performanţele de căutare. arii de subiecte. În cazul depozitelor de date. rapoartele şi interogările predefinite. dezvoltatorii şi administratorii bazelor de date lucrează cu metadate în fiecare zi. iar regulile de corecţie a erorilor pot fi documentate tot prin metadate. utilizatorul intră sub o sesiune de lucru. structura datelor folosite de programe şi instrumente de analiză. Metadatele menţin şi cresc calitatea datelor. drepturi existente etc. Înainte de a fi efectiv încărcate în depozit. Metadatele permit localizarea şi regăsirea datelor atât în sistemele sursă cât şi în structura depozitului. reguli şi formule de calcul.  ajută administratorii şi utilizatorii depozitului să localizeze şi să înţeleagă secvenţele de date atât în sistemele sursă. adică se creează automat un context de lucru: parametri setaţi. Metadatele se aplică pentru: sursele de date. filtrarea datelor. schema depozitului de date. fapt ce se realizează prin definirea valorilor valide pentru fiecare câmp din depozit. -6- . inclusiv în depozitele de date. securitate a datelor. aceştia percepând în general sistemul ca pe o cutie neagră care oferă o interfaţă prin intermediul căreia trebuie utilizat. descrierea lor. partiţii. uşurează procesul de analiză. Dintre exemplele de astfel de metadate menţionăm: descrierea tuturor surselor de date folosite. extragerea datelor. regulile de întreţinere. Această categorie de metadate are rolul de a creşte performanţele depozitului de date. rapoarte şi filtre predefinite. calitatea datelor. programele şi regulile de extragere şi transformare. Acestea conţin descrieri ale bazelor de date sursă şi ale conţinutului. Pentru aceasta au nevoie să cunoască definiţiile datelor din depozit. reguli de securitate şi de acces. Exemple de astfel de metadate sunt: definiţiile agregărilor şi colecţii de statistici. partiţionarea datelor. Dacă metadatele care descriu formatul datelor din depozite sunt disponibile. cât şi în structura depozitului.. În orice sistem. Metadate pentru optimizare. descrierile interfeţelor (gateways).

printr-un proces de abstractizare.2. pentru a economisi timp şi resurse se preferă uneori -7- . asupra agregărilor etc. Prin roll up se pot vizualiza datele la un nivel agregat. în funcţie de direcţie. de a naviga în cadrul ierarhiilor definite. datele pot fi revăzute şi erorile pot fi corectate. Este de dorit ca.  metadatele menţin şi cresc calitatea datelor. Operaţii realizate asupra modelului multidimensional Prin aplicarea unor operaţii specifice asupra modelului multidimensional utilizatorului i se oferă posibilitatea de a vedea şi de a analiza datele din perspective multiple. tipul de date pentru fiecare câmp (aşa cum este acceptat de SGBD). de a extrage un subset de date precum şi de a interschimba axele sau dimensiunile pentru a obţine o altă detaliere a datelor. este important ca utilizatorii să-şi poată da seama de unde provin datele existente în depozit. Ceea ce la prima vedere ar părea să fie o eroare în transformarea datelor poate fi de fapt rezultatul schimbării regulilor de transformare a datelor. Cu toate că instrumentele de analiză pot realiza dinamic toate operaţiile de navigare. Descrierea proprietăţilor datelor (obiectelor) din lumea reală se face prin intermediul metadatelor. De asemenea. prezentarea informaţiilor şi recomandarea unei direcţii de acţiune. metadatele trebuie să ajute utilizatorii să găsească rapid datele în depozit şi să interpreteze corect datele obţinute prin oferirea informaţiilor referitoare la formatul şi semnificaţia datelor. metadatele referitoare la câmpurile unui depozit de date se vor referi la: denumirea câmpului (aşa cum va fi folosită în tabela relaţională fizică).  metadatele sunt o formă de auditare a transformării datelor. Înainte de a fi efectiv încărcate în depozit. prin agregare pe nivelurile superioare sau detaliere pe nivelurile inferioare. Exemple de metadate. Metadatele documentează transformarea datelor sursă în date ale depozitului. cheia (dacă un câmp este cheie). anumite produse să poată genera programe de extragere şi transformare pentru cei care se ocupă de interfaţa de analiză a depozitului de date. pe baza acestor metadate. interpretarea şi analiza datelor pentru a obţine informaţii. Această formă de audit este necesară atunci când utilizatorii trebuie să aibă încredere în veridicitatea şi calitatea datelor din depozit. Toate regulile care guvernează transformarea datelor în noi valori sau noi formate sunt considerate a fi metadate. descrierea (o definiţie a câmpului). fapt ce se realizează prin definirea valorilor valide pentru fiecare câmp din depozit. De asemenea. utilizatorii pot vizualiza datele cu un grad de detaliu mai accentuat. Prin facilitatea de drill down. indexarea (dacă va fi folosită pentru câmp). Astfel. Orice depozit de date trebuie să permită navigarea pe diferite niveluri ale ierarhiilor. Pentru ca depozitul de date să fie folositor analiştilor din întreprindere. Toate aceste operaţii multidimensionale implementate în cadrul modelului multidimensional sunt prezentate în paragrafele următoare. Utilizatorii trebuie să aibă acces la metadatele corecte pentru perioada de timp pe care o studiază. formatul câmpului. Navigarea pe nivelurile ierarhice (drill down şi roll up) – reprezintă operaţii de navigare în cadrul ierarhiilor dimensiunilor. Această tehnică se numeşte roll up sau drill down. adică trebuie să fie capabile să explice modul în care o secvenţă de date din depozit este dedusă din sistemele operaţionale. obţinerea datelor. metadatele trebuie să ofere utilizatorilor informaţii care să-i ajute în parcurgerea etapelor anterior enumerate. Acestea sunt operaţii de schimbare a perspectivei de-a lungul nivelurilor unei ierarhii. Gestiunea volumelor mari de date  procesul de analiză cuprinde mai multe etape: identificarea datelor. Astfel. regulile de corecţie a erorilor pot fi documentate tot prin metadate. 1. Un depozit de date conţine date pentru diferite perioade de timp şi de aceea este important să avem în vedere efectul pe care îl poate avea timpul asupra regulilor de trecere a câmpurilor sursă în câmpuri destinaţie. spre vârful sau baza ierarhiei. De aceea este important ca metadatele să fie corect gestionate din punctul de vedere al versiunilor. sinonim pentru denumirea câmpului (aşa cum este folosit de utilizatori).  metadatele permit gestiunea versiunilor.

Pentru atributele organizate ierarhic. Procesul de agregare creează o redundanţă în cadrul depozitului. spre deosebire de cazul unor structuri relaţionale. însumare (din perspectiva procedurală). COUNT( ). iar în cazul tridimensional se pot utiliza 6 rotaţii pentru a vizualiza datele din diferite perspective.3.restricţia de asociere a nivelurilor prin care se defineşte realizarea legăturilor unui nivel inferior cu nivelul superior şi se specifică formula de agregare. o faţetă (slice) a datelor. Aceasta operaţie este numită consolidare (când se referă la aspectul conceptual). Rotaţiile – reprezintă operaţiile cele mai frecvente în structurile de date multidimensionale şi oferă utilizatorului posibilitatea de a alege perspectiva asupra datelor pe care le va utiliza. pentru care o nouă faţetă poate fi obţinută doar în urma unor interogări complexe. Gestiunea volumelor mari de date precalcularea unor valori globale. dar există şi excepţii în care se utilizează formule sau procedee statistice.reprezintă vederi sau imagini (views) specifice diverselor categorii de utilizatori. Secţiuni . STDEV( )). 1. consolidarea se face nivel cu nivel. iar pentru patru dimensiuni există 24 de perspective posibile. De exemplu în cazul bidimensional există două posibilităţi de vizualizare. -8- . Pentru relaţiile existente între nivelurile ierarhiilor unei dimensiuni se poate considera o restricţie specială . restricţiile de integritate nu sunt o componentă esenţială a acestuia. agregare (din perspectiva structurală). Tehnica aceasta constă în limitarea unor atribute la anumite valori şi obţinerea unui cub de date redus (procedeu numit data dicing). dar volumul acesteia nu este semnificativ deoarece scade exponenţial cu fiecare nivel de însumare. Nivelul la care se face însumarea în cazul în care sunt implicate ierarhii se numeşte granularitate. ci o schimbare a modalităţii de reprezentare. Extensii ale operatorilor relaţionali – permit realizarea în limbajul SQL a unor subtotaluri asupra obiectelor depozitului de date stocate sub formă de tabele relaţionale. aducând în prim-plan o structură bidimensională.  restricţiile de integritate de comportament: restricţii de domeniu şi restricţii temporale aplicate pentru valorile atributelor şi a metricilor. Aceste agregări se referă la o anumită măsură şi se realizează după dimensiunile corespunzătoare acesteia. Modelul multidimensional bazat pe reprezentarea sub formă de schemă tip stea utilizează totuşi o adaptare a restricţiilor de integritate ale modelului relaţional şi anume:  restricţiile de integritate structurale: restricţia de unicitate a cheii şi restricţia entităţii aplicate în cazul atributelor de identificare ale tabelelor de fapte şi ale dimensiunilor. Operatorul ROLLUP permite realizarea de subtotaluri în funcţie de coloanele specificate cu ajutorul funcţiilor de agregare implementate de SGBD relaţionale (SUM( ). prin operaţii de secţionare prin care se obţin „felii” bidimensionale (slices). Prin utilizarea funcţiei GROUPING se poate face o distincţie între valorile NULL din tabelă şi cele rezultate din agregare. Operatorul CUBE produce toate combinaţiile posibile de subtotaluri dintr-un cub. Din acest motiv rotaţia se mai numeşte şi data slicing. Restricţii de integritate Prin natura operaţiilor realizate asupra modelului multidimensional. restricţia referenţială aplicată pentru stabilirea legăturii dintre tabelele de fapte şi dimensiuni şi dependenţele între date pentru determinarea legăturii existente între anumite atribute sau metrici. AVG( ). Cercetătorul american Paul Gray a propus în anul 1998 [GRWA98] operatorii CUBE şi ROLLUP care realizează agregarea datelor pe baza unor coloane dintr-o tabelă relaţională ce reprezintă o dimensiune. Câştigul de performanţă obţinut la accesarea datelor este deosebit de important în analiză. Aceste operaţii nu implică o reorganizare a datelor stocate. Aceste operaţii implică de cele mai multe ori doar calcularea unor subtotaluri. Fiecare rotaţie pune în evidenţă o nouă perspectivă.

Optimizarea performanţei de răspuns la interogări este principalul avantaj al acestui model.Modelul propus de Kimball Acesta este modelul cel mai frecvent utilizat şi care a cunoscut în timp cele mai multe îmbunătăţiri şi variante: schema stea. Extensii ale modelului relaţional . Schema Stea – în cadrul acestui model propus de Ralph Kimball [KIMB96] obiectele sunt dispuse în formă de stea. Schema de tip stea are următoarele caracteristici:  între tabela de fapte şi dimensiuni există joncţiuni de egalitate. indecşi şi sinonime. Operaţia de consultare se realizează pe o singură tabelă de fapte şi nu necesită joncţiuni. care este o colecţie de obiecte. Figura 2. incluzând tabele de fapte. în centru aflându-se una sau mai multe tabele de fapte care sunt în relaţie cu dimensiunile (figura 2). Interogările de tip joncţiune multiplă apar după o serie de consultări şi implică restricţii plasate în cadrul dimensiunilor prin operaţia de joncţiune. În continuare vom prezenta câteva modele de reprezentare a obiectelor dintr-un depozit de date. fulg de zăpadă. Într-o schemă stea nu există decât o singură legătură între tabela de fapte şi dimensiuni. cu tabela de fapte. ele având date redundante care elimină necesitatea unor legături multiple între tabele. Schema stea Dimensiunile în acest caz sunt denormalizate. însă este destul de inflexibilă. Există mai multe tipuri de scheme utilizate în modelarea multidimensională. dimensiuni.4.  cheile primare ale dimensiunilor se regăsesc printre atributele cheii compuse a tabelei de fapte. Ambele modele reprezintă obiectele modelului multidimensional sub formă de schemă a depozitului de date. Schema de tip Fulg de Nea .  atributele tabelei de fapte care nu participă la joncţiune pot fi agregate. Gestiunea volumelor mari de date 1. galaxie.este o variantă a modelului stea în care o parte din tabelele -9- . O schemă de „joncţiune stea” suportă două tipuri de interogări: consultare şi joncţiuni multiple. Modele de reprezentare a obiectelor depozitelor de date Există două modalităţi (modele) principale de reprezentare a obiectelor depozitelor de date: modele care utilizează extensii ale modelului relaţional şi modele care structurează obiectele unui depozit sub forma elementelor unui cub de date. diferenţa fiind dată de modurile în care se pot aranja obiectele în cadrul acesteia.

10 - . structura fulg de nea poate reduce performanţa extragerii de date deoarece sunt necesare mai multe joncţiuni între tabele la o singură interogare. Rezultă o schemă reprezentată într-un grafic similar unui fulg de zăpadă. ceea ce determină o redundanţă controlată. Totuşi această economie de spaţiu este neglijabilă în comparaţie cu volumul foarte mare de date din tabela de fapte. Schema galaxie Legătura dintre stele se realizează prin intermediul dimensiunilor. Figura 4. numită stea centrală care conţine datele la nivel atomic. iar datele sunt distribuite în tabele suplimentare (figura 3). . iar celelalte stele conţin date agregate (figura 4). În cadrul galaxiei există o stea principală. Mai mult. astfel încât o dimensiune va face parte din una sau mai multe stele. Diferenţa între modelul stea şi modelul fulg de nea este că tabelele dimensiune din acesta pot fi păstrate în forma normalizată. Asemenea tabele sunt uşor de întreţinut şi astfel se economiseşte spaţiu de stocare. Schema fulg de nea Schema Galaxie reprezintă o asociere de scheme de tip stea şi care conţine tabele de fapte suplimentare care stochează date agregate. Figura 3. Gestiunea volumelor mari de date dimensiune sunt normalizate.

Cub de date cu patru dimensiuni 2. Secţiunile bidimensionale sunt numite tablouri. Acesta poate fi numit cub de date. fiind un spaţiu de date logic şi nu unul fizic. Modele bazate pe cuburi multidimensionale Cuburi de date . PRODUS LOCATIE TIMP Figura 5. Inteligenţa Afacerii se referă la capacitatea de a transforma date existente în informaţie utilă care să furnizeze perspective bogate. furnizor F1 furnizor F2 furnizor F3 locaţie produs T1 T2 T3 timp Figura 6.11 - . O matrice tridimensională poate fi vizualizată ca un cub în care fiecare dimensiune formează o faţă a cubului” [OLAP95]. care presupune că tranziţia pune în centrul atenţiei specialiştii care trebuie să asigure societăţii informaţionale o dezvoltare durabilă.Un mod mai simplu de vizualizare a datelor este reprezentarea într-un spaţiu cartezian definit pe toate dimensiunile depozitului de date (figura 5). asupra lumii afacerilor din prezent şi să ofere o . Gestiunea volumelor mari de date Avantajul principal al acestei scheme este dat de faptul că datele agregate sunt independente de cele atomice. Cercetările în acest domeniu se încadrează în tendinţa actuală de trecere de la societatea industrială la cea informaţională şi a cunoaşterii. Organizarea datelor în depozite de date 2. la intersecţia acestora fiind variabilele sau măsurile. Inteligenţa Afacerii – aspecte fundamentale Inteligenţa Afacerii – IA (Business Intelligence – BI) reprezintă o tehnologie informatică care priveşte organizarea şi funcţionarea întreprinderii şi a conducerii acesteia. În analiza multidimensională cubul de date cu mai mult de trei dimensiuni poartă denumirea de cub n-dimensional sau hipercub (hypercub). Axele cubului sunt reprezentate de dimensiuni. însă dezavantajul este că modificarea stelelor agregate trebuie să asigure consistenţa datelor cu steaua centrală. Cub de date cu trei dimensiuni Reprezentarea unui cub cu patru dimensiuni poate fi făcută ca în figura 6. Consiliul OLAP defineşte cubul n-dimensional ca fiind ”un grup de celule de date aranjate după dimensiunile datelor.1. iar obiectivul propus poate fi atins prin decizii fundamentate ştiinţific cu un suport informaţional pe măsură. şi mai ales noi.

unde informaţiile din unul sau mai multe sisteme tranzacţionale pot fi consolidate într-o singură sursă de date. concentrările de date. Depozitele de date (Data Warehouse) şi concentrările de date (Data Marts) . stocarea volumelor uriaşe de date. Un sistem informatic pentru Inteligenţa Afacerii oferă un ansamblu de tehnologii informatice. dinamic. Obiectivele unui sistem pentru Inteligenţa Afacerii rezultă din scopul unui astfel de sistem: suportul informaţional pentru fundamentarea deciziilor. raportare. analiză complexă a informaţiilor. Microsoft. Soluţiile de IA au rolul de a identifica şabloanele şi a înţelege tendinţele care pot influenţa afacerile şi permit analiza detaliată a activităţii organizaţiei. care livrează utilizatorilor informaţiile necesare pentru a răspunde la întrebările ce apar în rezolvarea problemelor de afaceri. deci.sunt două soluţii care rezolvă problemele legate de sursele de date disparate şi de scopurile incompatibile dintre procesarea tranzacţiilor şi aplicaţiile de IA. permiţând determinarea unor tendinţe viitoare în cadrul activităţilor urmărite. Analizele se realizează pe date istorice şi curente. Marii producători actuali de sisteme de gestiune a bazelor de date (SGBD) . conform căreia SGBD au devenit acum infrastructuri complexe şi complete pentru baze de date de diferite tipuri. multe organizaţii preferă să construiască un sistem separat pentru Inteligenţa Afacerii. gestionarea şi modelarea mediului de afaceri curent printr-o serie de mecanisme pentru interogare.sunt şi marii furnizori de soluţii informatice pentru Inteligenţa Afacerii. fie din motive de securitate. Acest lucru a fost realizat prin extinderea SGBD cu tehnologiile informatice care conduc spre soluţii de IA. Gestiunea volumelor mari de date idee referitoare la tendinţa acesteia în viitor. foarte puţine dintre soluţiile informatice pentru Inteligenţa Afacerii nu sunt realizate cu sisteme de baze de date. principala categorie de utilizatori fiind formată din manageri. IBM.sistemele OLAP. aşa cum este cel al conducerii. extragerea şi descoperirea datelor. integrată şi consistentă. eficiente pentru funcţionarea şi dezvoltarea organizaţiei.  să permită accesul rapid şi uşor la informaţiile organizaţiei pentru un număr cât mai mare de utilizatori de toate categoriile. de a înţelege comportamentul consumatorului şi de a îmbunătăţi procesul decizional. Principalele considerente care determină necesitatea unui sistem informatic pentru Inteligenţa Afacerii sunt legate de: reducerea timpului de obţinere a cererilor şi analizelor prin accesul şi livrarea rapidă a informaţiilor către utilizatori. extragerea şi descoperirea de cunoştinţe din date. că la nivelurile de conducere sunt urmărite în contextul unui sistem de IA următoarele obiective:  să permită soluţii informatice şi decizii ale conducerii având costuri cât mai scăzute. se ştie că sistemele dedicate dau performanţe ridicate pe domenii bine precizate.  să ofere suport pentru noi tehnologii informatice care să dea eficienţă sistemului. analiza complexă multidimensională a datelor . extragerea–transformarea-încărcarea datelor. deţinând mecanisme pentru optimizarea regăsirii datelor dintr-un volum mare de date. Principalele tehnologii informatice utilizate în sistemele pentru Inteligenţa Afacerii În momentul actual. 2. Extinderea se încadrează în tendinţa actuală. inclusiv produse software. deschis etc.Oracle. Pentru atingerea acestor obiective. reducerea costurilor informatice prin creşterea eficienţei sistemelor utilizate. Printre cele mai utilizate tehnologii informatice pentru sistemele de Inteligenţa Afacerii sunt: depozitele de date. Rezultă. flexibil.2. Depozitul de date este proiectat . Informix . De asemenea.  să ofere un mediu de lucru adaptat pentru nivelurile de conducere: interactiv. Scopul unui depozit de date este de a furniza un stoc central de date.12 - . fie din motive de performanţă a sistemului.

3. Rezultatele interogării intense a depozitelor de date sunt folosite pentru fundamentarea deciziilor. Dezvoltarea unei vederi singulare şi consistente a datelor care există în mai multe sisteme. Procesul de afacere . Aceste facilităţi. practicienii acestuia pot adopta o abordate alternativă: dezvoltarea unor depozite mai mici şi consolidate. putând identifica tendinţe neprevăzute în comportamentul consumatorului. informaţia spune ceva despre date fără să fie adresată vreo întrebare. Tehnologia OLAP (On Line Analytical Processing) . care potenţial pot fi utilizate să prevadă comportamentul viitor. Astfel. În procesul de analiză a datelor se ştie exact ce trebuie să se obţină.se referă la crearea unui depozit de date din mai multe surse de date. prin date stocate în volume mai mici.13 - . denumite dimensiuni. Acest cub constă din valori cantitative.). adăugând noi tehnici şi metode superioare. statistica. Deoarece procesul dezvoltării unui depozit de date la nivel de întreprindere este lung şi complex şi uneori nu se încheie cu succes. prin folosirea unor algoritmi de statistică superioară. Aşadar. Tehnologia de Extragere. răspund optim tuturor cerinţelor unei afaceri. prelucrarea datelor. cunoscute sub denumirea de concentrări de date. datele de la sursă s-ar putea să necesite uneori transformarea spre un format comun în depozitul de date. deoarece se bazează pe un ansamblu mare şi variat de date. Un astfel de mediu economic a determinat evoluţia activităţii de realizare a sistemelor informatice de la orientarea pe operaţional (activitatea curentă a firmei care pleacă de la funcţiile întreprinderii şi funcţiile conducerii) spre orientarea pe procesul de afacere.utilizează analiza multidimensională a datelor pentru a atinge flexibilitatea şi în acelaşi timp a menţine performanţa. În sistemele OLAP utilizatorul este angajat în mod activ în explorarea datelor. Extragerea şi descoperirea de date conduce tehnologia IA cu un pas mai departe decât OLAP. Extragerea de cunoştinţe din date se îmbunătăţeşte cu cât creşte cantitatea de date şi necesită depozite de date de înaltă calitate pentru a putea da rezultate utile. În această abordare. dacă sunt integrate în produse software care aparţin unui SGBD. Încărcare (ETI) . 2. acces la date. O interfaţă ETI permite definirea regulilor de afaceri utilizând produse software pentru: interfaţă grafică. Transformare. Gestiunea volumelor mari de date pentru a optimiza generarea de rapoarte dinamice pe un număr mare de înregistrări ale colecţiilor de date. Mediul economic este tot mai competitiv tinzând spre globalizare şi devine tot mai complex solicitând informaţii elaborate pentru sprijinirea deciziilor strategice. JDBC etc. matematica etc. la un preţ mai mic. adică integrarea datelor. Tehnologia data mining utilizează metode de căutare complexe spre a identifica modele şi grupări ale datelor. Această utilitate este dată de abilitatea la nivelul conducerii de a-şi analiza superior datele pe care le deţine în scopul de a furniza viziunea necesară luării deciziilor şi de căutare a datelor într-un spaţiu multidimensional prin valorificarea experienţei existente în analiza statistică clasică. interfeţe standard de comunicaţie cu date (ODBC. Extragerea de cunoştinţe din date (Data Mining . Utilitatea pentru organizaţii constă în abilitatea de a-şi analiza superior datele în scopul de a furniza viziunea necesară luării deciziilor. denumite măsuri şi categorii descriptive. De asemenea. stocarea datelor. Evoluţia şi definirea depozitelor de date Depozitele de Date (DD) reprezintă rezultatul interferenţei mediului economic şi al tehnologiilor informatice avansate. cu facilităţi de regăsire deosebite. concentrarea de date este de regulă un depozit de date de dimensiuni reduse realizat la nivelul unui departament sau al unei sector de activităţi din cadrul organizaţiei. El presupune multe regăsiri şi foarte puţine actualizări (sau deloc) pentru că datele stocate au un caracter istoric. datele sunt văzute la nivel conceptual ca un cub.DM). nevoia de o raportare mai exactă şi imediată poate fi suplinită într-un ciclu de dezvoltare mai scurt. Data mining realizează analiza datelor şi învăţarea folosind în acest sens un conglomerat de tehnologii informatice: inteligenţa artificială. necesită curăţarea acestora. pe când în data mining.

putem defini depozitul de date ca fiind un ansamblu de date de dimensiune foarte mare care este întreţinut separat de bazele de date operaţionale ale unei organizaţii şi care este construit din date provenite din sisteme sursă prin extragere. transformare şi stocare în depozite speciale. de asemenea un set de instrumente pentru interogare. Datele sunt istorice şi sunt actualizate la intervale regulate de timp. În concluzie. structurile de date dintr-un depozit de date sunt optimizate pentru o regăsire şi o analiză rapidă. provenite din sisteme tranzacţionale dar şi din fişiere externe. Spre deosebire de sistemele operaţionale. integrate. în scopul sprijinirii proceselor decizionale. transformare şi încărcare. Sunt două caracteristici fundamentale ale procesului de afaceri determinate de orientarea decidenţilor spre nivelul procesului de afaceri (interdepartamental) mai mult decât spre nivelul funcţiilor întreprinderii şi de integrarea activităţilor dintr-o organizaţie şi realizarea de sisteme informatice integrate. destinate prelucrărilor şi analizelor dinamice. Este evident că astfel de informaţii nu se pot obţine decât folosind anumite prelucrări cum ar fi analiza multidimensională. Consiliul OLAP formulează următoarea definiţie: „un depozit de date (data warehouse) reprezintă o stocare centralizată a datelor detaliate provenite din toate sursele relevante din cadrul unei organizaţii şi permite interogarea dinamică şi analiza detaliată a tuturor informaţiilor. Calitatea datelor conţinute în depozit reprezintă o premiză pentru re-ingineria afacerii. furnizând o platformă solidă de consolidare a datelor istorice. la nivelul unei organizaţii. Gestiunea volumelor mari de date (business process) este un ansamblu de activităţi interdepartamentale. păstrând astfel un nivel înalt de generalitate. Contribuţii la definirea. din punctul de vedere semantic. anumite metode statistice de prognoză şi alte metode matematice aplicate unui volum foarte mare de date din care se extrag numai datele relevante. stocate agregat pe niveluri ierarhice. analiză şi prezentare a informaţiilor şi reprezintă locul în care sunt publicate datele folosite. Prism Solution etc. Microsoft. destinată sprijinirii procesului de luare a deciziilor manageriale. Depozitele de date sprijină prelucrarea informaţiilor pentru analiză. în funcţie de cerinţele de raportare.” [OLAP95] În viziunea lui Ralph Kimball [KIMB96] depozitul de date oferă acces la datele organizaţionale. precum: în ce regiune a ţării se vinde mai bine un anumit produs.14 - . Software AG. integrate după anumite criterii. Un depozit de date este un ansamblu de date consistente. Un depozit de date reprezintă o modalitate de integrare şi organizare a datelor din surse omogene şi neomogene. care presupune una sau mai multe intrări şi care generează un rezultat important pentru client (intern sau extern). care serveşte la o implementare fizică a unui model de date pentru sprijinirea deciziei şi stochează informaţii pe care o organizaţie le solicită în luarea deciziilor strategice. care sunt preferinţele unui anumit segment de piaţă etc. profilul lor. filtrare. Se pot obţine astfel informaţii privind preferinţele clienţilor. fiind soluţia optimă de organizare a datelor pentru sistemele informatice suport de decizie şi executive. distribuţia etc. Depozitul de date include. precum şi perfecţionarea tehnologiilor de exploatare a acestora au condus la o nouă calitate a folosirii datelor prin analize care pot releva conducerii organizaţiei informaţii greu sau chiar imposibil de obţinut pe alte căi. istorice şi nevolatile. Evoluţia depozitelor de date este marcată de lucrările cercetătorului american William Harvey Inmon (născut în anul 1945) care este părintele de necontestat al conceptului de Data Warehouse. Oracle. datele obţinute sunt consistente şi pot fi separate şi combinate în funcţie de fiecare dimensiune sau aspect al afacerii.” [INMO96]. celelalte fiind . supuse unui proces de extragere. Astfel se pot furniza conducerii date. dezvoltarea şi popularizarea tehnologiilor de data warehouse au fost aduse de o serie de companii dezvoltatoare de produse software precum: IBM. Creşterea volumului de informaţii. iar viziunea sa se concentrează asupra rolului acestuia ca bază informaţională a deciziei manageriale. În viziunea sa „depozitul de date este o colecţie de date orientate pe subiecte.

Rolul unui depozit de date este de a oferi o imagine coerentă asupra datelor relative la activitatea unei organizaţii şi a contextului în care acesta acţionează. Din cele de mai sus rezultă importanţa deosebită a flexibilităţii impuse sistemelor care implementează asemenea depozite de date. De obicei. 2. programe de prezentare etc.  utilizarea datelor din depozite direct în analize. Este de asemenea deosebit de important să se aleagă o arhitectură care să se adapteze uşor la modificările de performanţe. la cerere şi să fie performant. costă mai puţin de 1 milion de dolari şi se implementează de obicei în aproximativ 90 de zile. structura informaţională existentă (o reţea LAN sau Intranet) cu mai puţin de 500 GB. Datele nu sunt doar centralizate. Obiectivele şi caracteristicile organizării datelor în depozitele de date Organizarea datelor în depozite de date prezintă o serie de obiective derivate din scopul principal al realizării acestora şi anume suportul pentru analize complexe şi dinamice asupra datelor istorice şi curente ale organizaţiei. datele trebuie bine organizate şi indexate pentru o uşoară regăsire şi utilizare. procesoare de text. astfel încât servere de baze de date diferite să se poată conecta simultan la depozitul deja existent. Un data mart tipic poate utiliza servere existente. Conectând împreună concentrările de date aferente diferitelor compartimente ale companiei se formează astfel o infrastructură specifică. depozitării şi analizării datelor. Această creştere exponenţială poate fi pe de o parte semnul sigur al succesului implementării depozitelor dar. Crearea unui astfel de depozit costă în medie 3-5 milioane dolari. iar ultima treime este destinată sistemelor hardware necesare şi stocării datelor. se poate alege o cale de mijloc şi se poate opta pentru realizarea unei concentrări de date (data mart) care să conţină numai datele relevante pentru analiza necesară. O altă treime se cheltuieşte pentru aplicaţiile necesare extragerii. Aici. departamentele putând folosi în comun datele şi se poate crea un depozit de date mai uşor de construit şi mai elastic. Accesul trebuie să se realizeze într-un timp cât mai scurt. precum tehnologia OLAP şi tehnologiile pentru extragerea cunoştinţelor din date (data mining). depozitele de date îşi dublează dimensiunile în primele 12 până la 18 luni. ci şi un set de utilitare pentru a interoga. Gestiunea volumelor mari de date ignorate. Pentru analiza economică.15 - . capacitate şi conectivitate.  stocarea de date istorice. analiza şi prezenta informaţiile. o treime o reprezintă serviciile profesionale. accesul presupune existenţa unor utilitare care să fie foarte uşor de folosit. Din acest cost. integrate şi stocate. Datele într-un depozit de date pot fi separate şi combinate pentru a oferi un acces cât mai rapid şi un timp de răspuns cât mai mic sistemului. fără alte prelucrări suplimentare. dar mai ales pentru a fi utilizate de către aplicaţii specializate de analiză. Pentru astfel de aplicaţii. extragerea unor date pentru a fi utilizate de aplicaţiile de birotică (programe de calcul tabelar. Există astfel şi depozite de date conţinând zeci de terabytes. Pentru a evita aceste probleme. aceste cifre neavând decât un caracter orientativ [VILA97]. Principalele obiective identificate sunt:  depozitul de date trebuie să asigure accesul la datele organizaţiei. poate deveni o problemă dacă sistemele nu sunt construite de la început suficient de elastice şi de deschise.).4. ci după ce sunt extrase dintr-o varietate de surse. pe de altă parte. flexibilitate înseamnă o conectivitate la nivelul întregii organizaţii. li se asigură calitatea necesară şi abia apoi devin utilizabile. sunt corectate de erori. transformate. Depozitele de date nu reprezintă doar datele. Volumul unui depozit de date se încadrează între 1 şi peste 10 TB. De asemenea. informaţiile care au caracter istoric sunt esenţiale. Utilizarea acestei colecţii poate consta din extragerea unor rapoarte (la cerere sau cu o anumită periodicitate). prelucrării. deoarece ele pun în evidentă tendinţe care reprezintă fundamentul unei .

Sistemul operaţional este de cele mai multe ori format din mai multe subsisteme relativ independente. de relevanţa datelor cu caracter istoric pentru nevoile analizei. ştergere). orice cheie de acces cuprinde şi o variabilă de timp. Consistenţa presupune faptul că atunci când două persoane solicită acelaşi set de informaţii să primească aceleaşi date. La depozitele de date. Depozitul de date este un istoric al sistemului operaţional.unităţile de măsură pentru diferite câmpuri trebuie exprimate într-un sistem unic (metric etc. Dacă datele nu au fost complet încărcate atunci utilizatorul va fi avertizat cu privire la acest lucru şi este sfătuit să aştepte până ce vor fi complet încărcate. adică . Integrarea datelor reprezintă o altă consecinţă importantă a realizării depozitului de date şi. furnizori. actualizarea este foarte rară. Calitatea datelor din depozitele de date este un factor determinant pentru procesul de analiză. Datorită obiectivelor impuse de utilizarea depozitelor de date în analiză se desprind câteva caracteristici mai importante pe care acestea le deţin. dar în depozitele de date ele trebuie să fie unice (lucrul în echipă).  convenţii clare privind modul de reprezentare a datelor – datele calendaristice. în maniere diferite. modificare. produse. date de prognoză economică.în sistemul operaţional acestea pot să difere de la o aplicaţie la alta. activităţi) faţă de datele operaţionale (BD sau fişiere) care sunt orientate pe aplicaţii. Integrarea datelor provenind din aceste sisteme dar şi din alte surse se referă la următoarele aspecte:  modalităţi unice de codificare – există nenumărate variante de a codifica un câmp dar o aplicaţie pentru analiza datelor va trebui să se bazeze pe o codificare unică.16 - . ceea ce face greoaie folosirea unui astfel de sistem pentru analiză. ajungând uneori la zece ani. trebuie să respecte convenţiile internaţionale. Din punctul de vedere al aspectelor tehnice. aceasta implică faptul că orice înregistrare din depozitul de date poate fi plasată în timp. O altă caracteristică importantă este redundanţa datelor.  sistem stabil de reprezentare fizică a datelor .). Se întâlneşte frecvent situaţia în care datele nu sunt de bună calitate sau nu sunt extrase în întregime sau au un caracter incert din punctul de vedere al conţinutului ceea ce face ca analiza ulterioară să conducă la rezultate eronate.). deci. dinamicii sistemului. date demografice. date obţinute în urma unor sondaje de opinie etc. Datele dintr-un depozit de date trebuie să fie consistente. asigurând faptul că rapoartele generate pentru diverse compartimente vor conţine aceleaşi rezultate.  sistem de unităţi de măsură unitar . chiar dacă ele au fost cerute la momente de timp diferite. Dacă în sistemul operaţional redundanţa este eliminată (prin procesul de normalizare) pentru a evita anomaliile de actualizare. Orizontul de timp pe care îl acoperă acesta de cel puţin cinci ani. dar mai pot proveni şi din datele de arhivă (în perioada de constituire a depozitului) precum şi din sursele externe (baze de date publice.în aplicaţiile tranzacţionale este posibil ca aceleaşi date să fie memorate în moduri de organizare diverse. create la momente diferite. în funcţie de dinamica evoluţiei pieţei şi. în cele din urmă. de echipe diferite. raţiunea pentru care acesta este creat. în sensul că organizarea lor este optimizată pentru a servi procesului tranzacţional. în depozitul de date redundanţa este creată în mod intenţionat prin denormalizare şi agregare pentru a permite un acces mai rapid la date. câmpurile care definesc timpul etc. Sursele de date pentru depozitul de date provin în principal din datele importate din sistemul informatic operaţional. Datele sunt încărcate pentru a răspunde nevoilor informaţionale ale întregii organizaţii. date statistice. Acestea trebuie stabilizate după anumite reguli precise.  convenţii unice privind denumirile câmpurilor de date .  orientarea depozitului pe subiectele importante ale procesului economic (clienţi. Gestiunea volumelor mari de date prognoze corecte.. Multe aplicaţii operaţionale (tranzacţii) presupun actualizarea continuă a colecţiilor de date (actualizare.

blocare). Sistemele care lucrează cu depozite de date dispun de o mare flexibilitate. organigrame) sau oferă posibilitatea analizei tendinţelor. generatoare de rapoarte). metode statistice superioare de prognoză. deosebit de important să se aleagă o arhitectură care să se adapteze uşor la modificările de performanţe. Depozitele de date sunt destinate managerilor şi analiştilor angrenaţi în luarea deciziilor strategice privind dezvoltarea şi viitorul organizaţiilor. Pentru aceasta. statistici ale accesării datelor. depozitele de date sunt supuse unor prelucrări complexe. Actualizarea se realizează aici doar prin adăugarea periodică a unor date extrase din sistemele operative sau din alte surse de date. corelaţiilor şi interpretarea acestora (OLAP. care au nevoie de acces rapid. de aceea uneori se consideră termenul data mining sinonim cu termenul Knowledge Discovery in Databases (KDD). Utilizatorul poate obţine rezultate imediate parcurgând dinamic dimensiunile cubului de date. În sistemul operaţional. cum ar fi: analiza multidimensională a datelor. precum şi păstrarea în tot acest timp a funcţionalităţii sistemului. astfel că gradul de libertate câştigat poate fi utilizat pentru optimizarea accesului la date prin denormalizare. bazat pe noi tehnologii informatice. Pentru a obţine informaţiile dorite. Aceste metode presupun folosirea unui software specializat deosebit de complex. regiunea unde se vinde mai bine un anumit produs. iar aceasta implică mecanisme complexe de menţinere a integrităţii datelor (jurnalizare. 2. de asemenea. capacitate şi conectivitate. Interfeţele OLAP se bazează pe reprezentarea multidimensională a datelor (cubul de date) şi permite analiza interactivă şi rapidă a datelor prin operaţiuni specifice. În cazul depozitelor de date mecanismele de integritate sunt inutile. care transformă datele în forma cerută de decidenţi (grafice. Procesele de configurare. inclusiv procedurile de salvare-restaurare. Din punctul de vedere al aplicaţiilor care folosesc depozitul de date. Gestiunea volumelor mari de date dinamica lipseşte. o tranzacţie trebuie să ducă colecţia de date dintr-o stare consistentă într-o altă stare consistentă. Interfeţele de tip Data Mining asigură extragerea şi transformarea datelor în cunoştinţe. concentrări de date (data mart). Se pot obţine astfel informaţii privind: preferinţele clienţilor. ceea ce înseamnă o conectivitate la nivelul întregii organizaţii. lucrând cu niveluri diferite de sinteză/detaliere (exemplu Oracle OLAP).5. de informaţii punctuale (limbaje de interogare gen SQL. diagrame. Facilităţi oferite de depozitele de date sistemelor de Inteligenţa Afacerii Creşterea volumului de date. OLAP (Online Analytical Processing). optimizare şi administrare a sistemului.  interfeţe specializate pentru asistarea deciziilor. adică produse software asociate depozitului de date:  interfeţe oferite de SGBD utilizatorilor. Este. distribuţia produselor. Se utilizează tehnici ale analizei statistice superioare şi de Inteligenţă Artificială . precum şi perfecţionarea produselor software pentru gestiunea acestuia au condus la o nouă calitate a utilizării datelor prin analize care pot releva conducerii organizaţiei informaţii greu sau chiar imposibil de obţinut pe alte căi. astfel încât servere provenind de la furnizori diferiţi să se poată conecta simultan la depozitul deja existent. metode matematice aplicate unui volum foarte mare de date. ei pot utiliza interfeţe performante de accesare şi analiză a datelor din depozite. inclusiv cu soluţii informatice clasice. pot deveni operaţii dificile dacă trebuie repetate la fiecare adăugare a unor noi servere în sistem. precum cele prezentate anterior: extrageri de cunoştinţe din date (data mining). profilul clienţilor. agregare. salvare/restaurare. care sunt preferinţele unui anumit segment de piaţă etc. cu ajutorul unor metode specifice.17 - . accesul la date este doar pentru citire. data mining). reorganizare dinamică a indexării etc.

totalizare.18 - . funcţionalitatea şi de viziunea utilizatorilor asupra acestora. Prin metadate se precizează structura datelor. Depozitul de date conţine mai multe tipuri de date care corespund diferitelor cerinţe informaţionale ale utilizatorilor: date detaliate. Metadatele descriu datele conţinute în depozitul de date şi modul în care ele sunt obţinute şi stocate. îşi schimbă destinaţia. cunoştinţe utile sprijinirii deciziilor (exemplu Oracle Miner). 3. reguli. îşi schimbă forma şi poziţia.). . Această structură a datelor în DD este dinamică. Tot aici se găsesc date având o anumită vechime (câţiva ani). Figura 7. interfeţele de analiză (figura 7). la actualizare. furnizori. Gestiunea volumelor mari de date care permit descoperirea de corelaţii. astfel încât să fie pregătite pentru suport decizional şi analize avansate: consolidare. companii de publicitate etc. 3. provenienţa lor. de agregare şi de calcul. pe niveluri şi arhitectura funcţională a DD. la consultare. metadate (dicţionarul de date). sursa de date. sunt necesare în depozitul de date deoarece în acest fel se poate asigura un timp mediu de răspuns cât mai redus. agregare. Arhitectura pe componente a depozitelor de date Notă. de regulă la nivel de execuţie. Datele detaliate sunt cele relativ recente. Arhitectura pe componente a depozitelor de date Esenţa unui depozit de date constă într-un ansamblu de date de dimensiuni foarte mari conţinând informaţiile pe care le pot folosi utilizatorii (clienţi. Astfel se pot distinge următoarele tipuri de arhitecturi: pe componente. date agregate. circulă pe diverse niveluri. datele intră în depozitul de date. Arhitectura pe componente evidenţiază componentele DD şi legăturile dintre ele: depozitul de date. livrate utilizatorilor.1. deşi determină o creştere a redundanţei datelor. regulile de transformare. în formă detaliată. Ele sunt utilizate ori de câte ori se utilizează depozitul de date: la încărcarea datelor. Aceste date presupun un grad de prelucrare prealabilă. împachetare (în formate accesibile interfeţelor de analiză utilizate). Datele agregate. adică pe parcursul întregului ciclu de viaţă al depozitului. Arhitectura depozitelor de date Elementele care alcătuiesc un depozit de date pot fi interconectate în mai multe tipuri de arhitecturi în funcţie de rolul.

sume etc.  filtrarea datelor. datele vechi arhivate. valori medii.  agregarea datelor: totaluri precalculate. Gestiunea volumelor mari de date Sursele de date pentru depozitul de date sunt: datele operaţionale curente (baze de date şi/sau fişiere din sistemul informatic operaţional al organizaţiei). presupune parcurgerea unor etape în cadrul unui proces de transformare:  extragerea datelor din datele operaţionale sau din surse externe. OLAP. interogări Strat superior extragere Strat mediu Servere specializate (OLAP. Arhitectura pe niveluri a depozitelor de date Stratul inferior (bottom tier) este format din serverul depozitului de date şi este. Rapoarte. DATA MINING) Depozite de date transformare Strat inferior Server de Date Surse de date operaţionale Figura 8.. Exemple de astfel de interfeţe: ODBC (Open DataBase . cel mai adesea. Interfeţele de analiză sunt produse software care implementează tehnologii informatice pentru extragerea şi analiza datelor din depozitul de date: data mining.  încărcarea datelor corecte în depozitul de date. în cele mai multe cazuri. superior (figura 8). Arhitectura pe niveluri a depozitelor de date Arhitectura pe niveluri evidenţiază modul de implementare a depozitelor de date într-un mediu de reţea de calculatoare.19 - . 3. Acest proces trebuie. pe trei straturi: inferior. rezultatele unor sondaje) sunt extrase utilizând programe de tip interfaţă (gateways). un sistem de baze de date relaţionale. urmat de copierea lor în depozitul de date. Datele care provin din bazele de date operaţionale şi din sursele externe (de exemplu. subtotaluri. care colaborează cu SGBD şi permite programelor client să genereze cod (de obicei SQL) pentru a fi executat de server. datele externe (baze de date şi fişiere din sistemele informatice ale altor organizaţii).2. date referitoare la profilul clientului. Aceste agregări sunt stocate în depozitul de date împreună cu datele importate din sursele interne şi externe. care se preconizează că vor fi cerute şi folosite de utilizatori. să transforme datele în structura şi formatul intern al depozitului. mediu. Construirea depozitului de date. date furnizate de consultanţi externi. analize. pentru a exista certitudinea că datele sunt corecte şi pot fi utilizate pentru luarea deciziilor. pornind de la sursele de date.

Acest proces de transformare a datelor reprezintă baza pe care se construieşte un depozit de date consistent. fişiere. De multe ori acest strat este inclus în SGBD relaţional (exemplu Oracle.MOLAP). a rapoartelor. datele trebuie să fie colectate şi aduse într-o formă consistentă pentru a putea fi folosite. de înaltă calitate. care poate fi: OLAP (bazat pe modelul relaţional – ROLAP sau pe modelul multidimensional . Aceste date pot proveni de la aplicaţii sau de la sisteme distribuite din cadrul companiilor cum ar fi sisteme de gestiune a comenzilor. Transformare şi Încărcare (ETI) Operaţional Date operaţionale: secvenţiale. curăţare. Modulul central al depozitului de date – reprezentat de SGBD. DB2). iar a doua posibilitate ar fi implementarea unei surse de date unice. Transformarea datelor presupune un proces de extragere. anual). Stratul mediu (middle tier) este bazat pe un server specializat. surse externe Sisteme operaţionale. Sisteme IA Modulul Extragerea şi procesarea datelor pentru analiză Strategic Utilitare pentru accesul la date Modulul Data Marts Central Replicare şi distribuire Depozitul de date central Modulul Extragere. sisteme informatice integrate Figura 9. fuziune. modulul central al depozitului de date şi modulul strategic de afaceri (figura 9). 3. trimestrial. de contabilitate financiară. salarizare etc. de serverul pe care acesta rulează şi de modul în care este implementat depozitul. filtrate. Arhitectura funcţională a depozitelor de date . descentralizat unde datele sunt păstrate în concentrări de date independente (Independent Data Marts) fiecare conţinând datele relevante pentru un anumit aspect al operaţiilor unei instituţii.reprezentat de datele companiei care sunt de obicei păstrate sub formă diferită la locaţii diferite. În acest fel. JDBC (Java DataBase Connection). Împrospătarea datelor din depozitul de date se face pe măsura trecerii timpului (lunar. pentru analiza superioară a datelor. OLE (Open Linking and Embedding). datele sunt extrase. Există în acest moment două tendinţe: una ar fi implementarea unui sistem distribuit. relaţionale. de eliberare a facturilor. Indiferent de originea lor. nerelaţionale. Stratul superior (top tier) este nivelul client care conţine interfeţe pentru generarea interogărilor. Gestiunea volumelor mari de date Connection).3. data mining (extrageri de cunoştinţe din date şi analize statistice superioare). condiţionare.20 - . de gestiune a stocurilor. transformate şi încărcate în depozitul de date. validare şi încărcare. centralizate la care au acces utilizatorii din toate departamentele respectivei instituţii. Arhitectura depozitelor de date din punctul de vedere funcţional Această arhitectură împarte depozitul de date în trei module (niveluri) distincte: modulul operaţional. Modulul operaţional .

dar şi date agregate.21 - . Concentrările de date sunt implementate pe servere departamentale sau pe serverele de baze de date existente în cadrul organizaţiei. ceea ce poate conduce la un timp de prelucrare mare. instrumente de vizualizare a datelor.1. 4. însă se elimină necesitatea stocării datelor într-un depozit real [HOLL00]. Datele conţinute sunt de obicei agregate. Domeniul este limitat la subiecte specifice. Tipuri de depozite de date Depozitele de date se pot clasifica în funcţie de: aria de cuprindere. Un depozit virtual este uşor de construit. numai unele din vederile de agregare pot fi materializate. timpul de extragere a datelor creşte semnificativ şi recomandabil ar fi să se combine soluţia de depozit virtual cu stocarea datelor agregate separat într-un data mart sau depozit de date real. . Arhitectura funcţională a depozitelor de date prezentată mai sus permite proiectarea şi implementarea unor diverse tipuri de depozite de date în funcţie de cerinţele de afaceri.valoarea finală a unui depozit de date este determinată de avantajele pe care le oferă utilizatorului în diferite procese de luare a deciziilor şi analiză. prezentări. De regulă conţine date detaliate. un data mart poate fi considerat un subansamblu al unui depozit de date mai uşor de construit şi întreţinut şi mai ieftin [INMO99]. Această variantă se recomandă a fi aplicată în cazul în care volumul de date necesar este mic. Tipuri de depozite de date în funcţie de aria de cuprindere În funcţie de aria de cuprindere se întâlnesc trei tipuri de depozite de date: depozite la nivelul organizaţiei (Enterprise Warehouse). depozite virtuale de date (Virtual Data warehouse). de procesele decizionale pentru care a fost proiectat şi de modelul de date implementat. pe platforme cu arhitecturi paralele sau pe maşini de baze de date. utilizatorii pot obţine informaţii care îi vor ajuta în procesele de stabilire a strategiei firmei. Ciclul de implementare al unei concentrări de date este măsurat în săptămâni sau luni sau ani. Depozitul virtual este un set de vederi (views) asupra bazelor de date operaţionale. rapoarte dinamice. de mii de înregistrări. concentrări de date (Data Marts). Prin folosirea diferitelor modalităţi de acces la informaţie şi a tehnologiilor de procesare disponibile. De exemplu. dar problema extragerii şi prelucrării datelor revine în mod exclusiv serverului de baze de date. vânzări. iar ordinul de mărime este de peste 5 TB. resursele disponibile şi posibilităţile de realizare. Depozitul la nivel de organizaţie colectează toate informaţiile despre subiectele care privesc întreaga activitate a unei companii şi furnizează un volum foarte mare de date. produse. 4. Ca atare. Pentru eficienţa procesărilor interogărilor. datele sunt pregătite pentru interpretare şi analiză cu ajutorul instrumentelor specifice cum ar fi: instrumente de realizare a graficelor. Un astfel de depozit de date poate fi implementat pe servere dedicate. Acestea necesită cheltuieli mari şi mult timp (ani) pentru modelare. pentru activitatea de marketing se limitează subiectele la clienţi. navigatoare (browser Web). specific unui grup de utilizatori (unui compartiment). proiectare şi realizare. La ultimul nivel al arhitecturii. Gestiunea volumelor mari de date Modulul strategic de afaceri . Însă dacă se depăşeşte acest interval. Concentrările de date conţin un subset al volumului de date din organizaţie.

În acest fel se pot analiza toate datele existente la nivelul organizaţiei. preprocesate şi pregătite pentru analiză.BPDM) reprezintă un tip de depozit specializat. multidimensionale şi hibride.GDW) reprezintă un tip de depozit centralizat. Gestiunea volumelor mari de date 4. Este varianta optimă datorită avantajelor oferite: capacitatea de procesare a unui volum mare de date. În acest caz.DDM) reprezintă un tip de depozit specializat. Sarcina realizării acestor operaţii cade în seama serverului multidimensional. Datele sunt extrase din surse diverse (baze de date relaţionale. fişiere). cu o arie de cuprindere limitată la un anumit departament.2. . 4. datele sunt stocate într-o structură denormalizată cum ar fi o schemă stea sau una din variantele sale. orientat pe satisfacerea cerinţelor de afaceri şi a proceselor de afaceri. Depozitul de date orientat pe procese de afacere (Business Process Data Warehouse - BPDW) reprezintă un tip de depozit specializat. Tipuri de depozite de date în funcţie de procesele decizionale pentru care au fost proiectate Această clasificare a depozitelor de date este propusă în lucrarea [POWE00] şi împarte tipologia depozitelor de date în funcţie de suportul decizional oferit.3. o bază de date normalizată nu este potrivită din punctul de vedere al performanţelor. Depozitele de date multidimensionale utilizează modelul multidimensional al datelor şi în acest caz datele sunt stocate pe un server dedicat. orientat pe satisfacerea unei anumite cerinţe de afaceri şi a unui singur proces de afaceri. având drept obiectiv integrarea şi prelucrarea datelor din fiecare departament în parte. denumit server multidimensional.22 - . Depozitele de date relaţionale utilizează modelul relaţional al datelor şi se recomandă a se utiliza în cazul în care datele provin dintr-un SGBD relaţional. Depozitele de date hibride utilizează modelul multidimensional pentru stocarea datelor istorice şi separat un model relaţional pentru datele curente care urmează a fi transformate şi încărcate în depozit. existenţa procesului ETI pentru transformarea şi încărcarea datelor. având drept obiectiv integrarea şi prelucrarea datelor specifice activităţilor acestuia. Tipuri de depozite de date în funcţie de modelul de date implementat În funcţie de modelul de date implementat sunt identificate următoarele tipuri de depozite: relaţionale. Depozitul de date de tip organizaţional sau „galactic” (Galactic Data Warehouse . cu o arie de cuprindere extinsă având drept obiectiv integrarea şi prelucrarea datelor la toate nivelurile organizaţiei. agregate pe diverse niveluri. Depozitul de date departamental (Departamental Data Warehouse . Concentrări de date de tip proces de afaceri (Business Process Data Mart . atât la nivelul departamentelor cât şi al întregii organizaţii. implementarea operaţiilor la nivel de server multidimensional optimizat pentru analiză.DDW) reprezintă un tip de depozit orientat pe departamente. În acest caz putem vorbi de un depozit de date format din obiecte multidimensionale asupra cărora pot fi aplicate direct operaţiile multidimensionale. transformate şi încărcate în cubul de date. iar depozitul de date este gestionat de către acesta sau este implementat ca un depozit de date virtual. Concentrări de date departamentale (Departamental Data Mart .

iar modelul datelor este optimizat pentru a realiza o mare varietate de interogări. Dintre aceste diferenţe se pot menţiona următoarele: Condiţii de utilizare diferite.). Operaţii tipice. pot organiza şi prezenta datele în formate variate. Aceste sisteme implementează toate operaţiile zilnice dintr-o organizaţie. ceea ce presupune activităţi speciale de organizare a datelor şi de acces la acesta. Modelul utilizat. Sistemele de baze de date relaţionale sunt adecvate aplicaţiilor curente de gestiune şi au ca obiectiv execuţia on-line a tranzacţiilor şi proceselor de interogare (sunt sisteme tip OLTP . în ordinea solicitărilor. mai ales în tactica şi strategia organizaţiei. utilizarea cheilor. Aceste aspecte fac ca datele să fie uşor utilizate de către decidenţi. O ultimă şi controversată diferenţă între cele două tipuri de modele este modul de abordare a datelor. Depozitele de date sunt construite special pentru sprijinirea luării deciziilor. dispersii etc. Depozitele de date gestionează date istorice. Date istorice.23 - . iar accesul este cel mai adesea de tip citire pentru interogări complexe. Acestea se aplică asupra unor volume foarte mari de date şi presupun calcule complexe (analiza tendinţei. căutarea unor înregistrări specifice. În schimb sistemele tranzacţionale suportă numai anumite operaţii pentru care au fost proiectate. În schimb. faţă de forma normalizată a datelor din modelul relaţional care optimizează operaţiile de adăugare/modificare/şterge şi garantează consistenţa datelor. Bazele de date din sistemele operaţionale conţin date curente. medii. Aspecte comparative privind organizarea datelor în baze de date şi în depozite de date Depozitele de date impun condiţii de realizare diferite faţă de bazele de date relaţionale. constituind suportul sistemelor informaţionale de prelucrare a tranzacţiilor. integrarea şi stocare acestora pentru a da decidenţilor o imagine adecvată care să permită regăsirea şi analiza eficace a informaţiilor necesare. furnizând facilităţi pentru sintetizare şi agregare. organizarea şi coordonarea informaţiilor provenind din surse diferite. O interogare a depozitelor de date poate parcurge mii sau chiar milioane de înregistrări (de exemplu pentru a analiza totalul vânzărilor din luna trecută pentru toţi clienţii existenţi). O bază de date presupune procesarea concurentă a tranzacţiilor multiple. care trebuie actualizate şi interogate rapid. transformare şi încărcare automată (ETI). agregarea şi sintetizarea lor. În depozitele de date se foloseşte forma denormalizată (cum este schema stea) pentru optimizarea operaţiilor. O bază de date este proiectată pornind de la sarcini şi activităţi cunoscute: indexarea. iar accesul este de tip citire şi scriere. Controlul concurenţei pentru depozitele de date este mult mai simplu de realizat deoarece se aplică doar pentru citire. care necesită adesea agregări. Din acest motiv interogările obişnuite într-un depozit de date sunt mai complexe şi mai variate decât cele din bazele de date. Datele din depozite sunt actualizate regulat (de regulă săptămânal sau lunar) cu ajutorul procesului de extragere. implicând calcule asupra unor grupuri mari de date cu totalizări pe diferite niveluri. optimizarea interogărilor. Actualizarea şi accesul la date. În cazul bazelor de date sursele de date sunt tranzacţiile atomice. Esenţa unui model multidimensional de calitate sporită este alegerea unui set de dimensiuni cât mai apropiate de cele naturale şi de perspectiva utilizatorului. Sistemele cu depozite de date servesc utilizatorilor sau specialiştilor în domeniul analizei datelor şi luării deciziilor. Este folositor să avem o analiză . detaliate. Gestiunea volumelor mari de date 5.OnLine Transaction Processing). o operaţie tranzacţională afectează o singură înregistrare sau un număr limitat de înregistrări. în condiţii de deplină securitate. În cazul depozitelor de date sursele de date sunt bazele de date operaţionale. Utilizatorii finali nu pot modifica (actualiza) direct datele. de la diferiţi utilizatori (sunt sisteme tip OLAP – OnLine Analytical Processing). precum şi pentru stocarea şi gestionarea informaţiilor cu diferite niveluri de granularitate. Surse de date diferite. Depozitele de date sunt proiectate pentru analize ad-hoc şi rezultatele nu sunt cunoscute dinainte. În sistemele tranzacţionale utilizatorii finali sunt cei care actualizează datele astfel încât să se reflecte starea fiecărei tranzacţii din organizaţie. Acestea au ca obiectiv regruparea datelor. Interogările unui depozit de date sunt adesea complexe.

analişti de date Operaţia tipică Actualizare Raportare şi analiză Frecvenţa operaţiilor Zilnice Asistarea deciziei Caracterul datelor Curente Istorice Nivelul de sinteză Primitive. cub de date Procesele Operaţionale Informaţionale Execuţie Tranzacţii Analize Utilizatori Toate categoriile Manageri. sintetic. de ordinul GB Mare. cu mai puţine tabele şi chei de administrat decât modelul entitate . pe tehnologia relaţională. detaliere Sintetizare. Gestiunea volumelor mari de date relaţională a datelor înainte de a începe analiza dimensională deoarece echipa de proiectanţi a depozitului de date va înţelege datele mai bine. . SGBD Ca o asemănare. Modelul multidimensional trebuie abordat mai mult din perspectiva utilizatorului decât din cea a datelor.24 - . consolidare Acces Citire. atât bazele de date cât şi depozitele de date conţin cantităţi mari de date structurate care pot fi consultate rapid. autonomie Software necesar SGBD Specializat. de ordinul TB Priorităţi Performanţe. tabele de fapte. disponibilitate Flexibilitate. Tabelul de mai jos descrie diferenţele principale între prelucrarea tranzacţională (modelul relaţional) şi prelucrarea analitică (modelul multidimensional): Tabel 1. prin structuri de acces optimizate şi se bazează. în majoritatea cazurilor.asociere. scriere Citire Focalizare Culegere date Furnizare informaţii Sursa de date este Validată Filtrată. transformată Volum de date Redus. Diferenţe între modelul relaţional şi modelul multidimensional al datelor Criteriu Modelul relaţional Modelul multidimensional Organizarea datelor Tabela Dimensiuni. Modelul multidimensional oferă o bază de date care este mult mai uşor de consultat şi de interogat la un nivel înalt. agregat.

procesul de extragere. Gestiunea volumelor mari de date REALIZAREA DEPOZITELOR DE DATE Realizarea depozitelor de date trebuie privită în contextul realizării sistemelor destinate Inteligenţei Afacerii. Cuvinte cheie: realizarea depozitelor de date. transformare şi încărcare a datelor. este iterativ. pe baza cărora se pot măsura performanţele şi se pot face ajustări critice pentru a câştiga în faţa concurenţei. Astfel.1. pe toate departamentele. abordări specifice ale ciclului de dezvoltare care să se concentreze pe cerinţele de afaceri ale organizaţiei. facilitează gestiunea relaţiilor cu clienţii prin furnizarea unei vederi consistente despre clienţii şi produsele comercializate de organizaţie. 1. direcţiilor şi excepţiilor pe perioade lungi de timp. Aceste sistemele sunt orientate mai mult spre oportunităţile de afaceri decât spre cerinţele sau nevoile curente şi trebuie să ofere suport decizional la nivel departamental sau chiar la nivelul întregii organizaţii în funcţie de scopul pentru care au fost proiectate. Considerente privind realizarea depozitelor de date La realizarea unui depozit de date trebuie avute în vedere o serie de aspecte preliminare care condiţionează atingerea obiectivelor pentru care acesta este destinat. Modalităţi de realizare a depozitelor de date Realizarea depozitelor de date este condiţionată de o serie de cerinţe specifice sistemelor de Inteligenţa Afacerii. Datorită acestor particularităţi la realizarea depozitelor de date se pot lua în considerare diferite vederi de lucru:  analiza cerinţelor decizionale începând cu nivelurile superioare şi continuând cu nivelurile departamentale (top-down view) care permite selectarea informaţiilor relevante . 1. Din această analiză economică se va vedea dacă depozitul de date satisface următoarele cerinţe: furnizează avantaje competitive oferind informaţii relevante. pentru a determina măsura în care depozitul de date este necesar şi eficient. determină reducerea costurilor prin evidenţierea tendinţelor. este necesar să se elaboreze mai întâi o analiză economică. orientat spre evaluarea şi îmbunătăţirea versiunilor succesive şi nu spre o livrare de proporţii a unei singure versiuni.25 - . metodologii de realizare a depozitelor de date. deoarece activitatea de realizare a unui depozit de date consumă importante resurse. iar ciclul de dezvoltare al acestor sisteme şi implicit al depozitelor de date. care necesită modele de analiză şi proiectare diferite. determină creşterea productivităţii prin obţinerea rapidă şi eficientă de informaţii care descriu cu acurateţe organizaţia.

În ceea ce priveşte abordarea activităţilor de realizare a depozitului de date se alege una dintre variantele:  realizarea de sus în jos (top-down) care porneşte cu proiectarea şi planificarea completă. implementarea şi dezvoltarea concentrărilor de date (data marts) independente furnizează flexibilitate. Metoda în spirală implică generarea rapidă de sisteme funcţionale din ce în ce mai complete. Din punctul de vedere al modului de abordare putem aplica atât metodologii structurate cât şi metodologii orientate-obiect. Metodologii cu abordare structurată (descrise pe larg în [LUNG05b]) presupun diviziunea în subsisteme pe baza funcţiilor identificate .  analiza datelor sursă (data source view) care exprimă informaţiile culese. Acest lucru constituie un atu important pentru realizarea depozitelor de date. date calendaristice. costuri scăzute şi recuperarea rapidă a investiţiei. între două versiuni succesive. Soluţia este scumpă. la intervale scurte.abordarea funcţională.  realizarea de jos în sus (bottom-up) porneşte cu experimente şi prototipuri.2. când se încearcă integrarea într-un depozit de date consistent la nivel de organizaţie. Abordarea bottom-up în proiectarea. Aceasta abordare este utilizată la începutul stadiului de modelare şi de dezvoltare tehnologică. Se reprezintă informaţiile care sunt stocate în depozitele de date. Din punctul de vedere al ciclului de viaţă putem aplica două tipuri de metode: metoda în cascadă şi metoda în spirală.  analiza şi proiectarea schemelor depozitului de date (data warehouse view) care are în vedere identificarea tabelelor de fapte şi a tabelelor dimensiune. care structurează . Gestiunea volumelor mari de date necesare în depozitul de date. 1. Soluţia poate determina probleme. origine.  realizarea mixtă presupune că o organizaţie poate exploata caracterul planificat şi strategic al abordării top-down atât timp cât reţine avantajele implementării rapide şi oportune a aplicaţiilor după abordarea bottom-up.  analiza şi proiectarea interogărilor (business query view) oferă o perspectivă din punctul de vedere al utilizatorului asupra informaţiilor oferite în urma analizei datelor din depozitul de date. putem utiliza la realizarea acestora metodologiile existente adaptate la cerinţele de utilizare a sistemelor de Inteligenţa Afacerii.26 - . adăugate pentru a furniza contextul istoric. informaţii care reprezintă un sprijin decizional pe toate nivelurile de management implicate. Această abordare se utilizează în cazul în care tehnologiile utilizate sunt bine cunoscute şi problemele economice care trebuie rezolvate sunt clare şi bine înţelese. pentru că intervalul de finalizare este scurt. Dezvoltarea top-down a unui depozit de date constituie o soluţie sistemică şi minimalizează integrarea problemelor. stocate şi gestionate de sistemele operaţionale. solicită timp îndelungat pentru dezvoltare şi îi lipseşte flexibilitatea determinată de dificultăţile care pot apărea la realizarea modelelor de date pentru întreaga organizaţie. Aceste informaţii pot fi documentate pe diferite niveluri de detaliere şi acurateţe. Metoda în cascadă presupune o analiză structurată şi sistematică pe fiecare etapă. Permite unei organizaţii să meargă înainte cu cheltuieli considerabil mai mici şi să evalueze beneficiile tehnologiei înainte de a face angajamente semnificative în această direcţie. precum şi informaţiile referitoare la surse. incluzând contorizări şi totaluri precalculate. de la colecţii individuale de date sursă până la colecţii de date integrate. schimbările pot fi făcute imediat şi noile tehnologii pot fi adaptate rapid şi uşor. Metodologii utilizate la realizarea depozitelor de date Privind depozitele de date ca orice sistem informatic integrat de mari dimensiuni.

În acest fel pot fi modelate şi cerinţele de afaceri în interacţiune cu obiectele. modelul funcţional – prin care se realizează transformarea valorii datelor cu ajutorul operaţiilor şi proceselor. AXIAL – elaborată de firma IBM.  modelul de date utilizat . Astfel eventualele schimbări identificate în utilizarea depozitelor se pot realiza cu uşurinţă prin modificarea structurilor deja implementate. Esenţa unui model dimensional de calitate sporită constă în alegerea unui set de dimensiuni cât mai apropiate de cele naturale şi de perspectiva utilizatorului. Metodologiile orientate-obiect (OO) bazate pe conceptele de obiect şi clasă permit utilizarea a trei tipuri diferite de modele pentru realizarea unui depozit de date: modelul static – prin care se modelează obiectele şi relaţiile lor în cadrul depozitului. de a surprinde asupra aceluiaşi obiect atât caracteristicile statice. Dezavantajele utilizării acestor metode în realizarea depozitelor de date pot fi cauzate de rigiditatea modelelor în sensul că divizarea şi realizarea modulară pot duce la pierderea privirii de ansamblu la un moment dat. Utilizatorii finali nu pot modifica (actualiza) direct datele. prin prisma interacţiunilor cu alte obiecte. Rapid Application Development (RAD). Un alt aspect este acela că metodologiile orientate-obiect acordă o mare importanţă reutilizării pachetelor şi a componentelor. prin elaborarea standardului UML s-au înlăturat o mare parte dintre diferenţele existente între diferitele tipuri de abordări şi se poate aplica acest standard de modelare pentru realizarea depozitelor de date. Printre metodologiile structurate care pot fi aplicate la realizarea depozitelor de date putem menţiona: Structured System Analysis and Design Methodology (SSADM – elaborată la propunerea Guvernului britanic).în depozitele de date se foloseşte forma denormalizată (schema stea) pentru optimizarea operaţiilor de interogare. Custom Development Method (CDM – elaborată de corporaţia Oracle). Această descompunere pe cele două niveluri poate fi un punct de plecare în abordarea unui depozit de date în ceea ce priveşte separarea şi delimitarea funcţiilor acestuia. Astfel se poate adapta setul standard de notaţii şi diagrame existente în UML ţinând cont de următoarele aspecte:  condiţiile de utilizare – depozitele de date sunt proiectate pentru analize multidimensionale şi extrageri de date. Din acest punct de vedere depozitul de date poate fi realizat pe două niveluri: logic – în care se modelează schemele depozitului de date şi fizic – în care este realizată structura tehnică şi operaţională a acestuia. funcţionale cât şi dinamice. putem spune că avantajele aduse de metodologiile orientate-obiect faţă de cele structurate recomandă abordarea obiectuală în cazul realizării depozitelor de date. În ceea ce priveşte metodologiile orientate-obiect. . Gestiunea volumelor mari de date sistemul pornind de la prelucrările pe care le suferă datele.abordarea bazată pe date. identificarea subsistemelor şi a componentelor sale. În concluzie. modelul dinamic – sunt descrise interacţiunile dintre obiecte. Din acest punct de vedere. sau în funcţie de date . fără a fi necesară reproiectarea DD. Avantajele aplicării metodologiilor orientate-obiect pentru realizarea depozitelor de date derivă tocmai din posibilitatea de a modela unitar atât funcţiile cât şi datele. avantajele utilizării modelelor structurate în realizarea depozitelor de date ar fi legate de realizarea modulară prin divizarea pe componente şi reducerea timpului de implementare prin posibilitatea realizării paralele a componentelor identificate. din acest motiv trebuie să fie optimizate pentru a realiza o mare varietate de interogări.  actualizarea datelor – datele din depozite sunt actualizate la intervale de timp regulate (săptămânal. care structurează sistemul pornind de la structura datelor utilizate şi de la relaţiile care există între acestea.27 - . lunar) cu ajutorul procesului ETI. Aceste metodologii propun modelarea datelor separat de modelarea procedurilor. iar cerinţele de afaceri pentru care acesta a fost conceput nu sunt modelate în interacţiune cu funcţiile şi datele. faţă de sistemele OLTP care folosesc forma normalizată a datelor pentru a optimiza operaţiile de adăugare/modificare/ştergere şi pentru a garanta consistenţa datelor.

obiecte. care vor fi dezvoltate iterativ. Întrebările tipice sunt următoarele: . Prin analizarea posibilelor arhitecturi de depozite de date.  lista preliminară a mediilor de dezvoltare a depozitului de date. precum şi versiunile care vor urma pentru a asigura scalabilitatea sistemului. managerul IT sau managerul de proiect. realizarea auditului preliminar referitor la sistemele sursă. Se defineşte arhitectura globală a depozitului de date pentru proiectul pilot.1. de aceea. 2. cât şi dinamic. De aceea. abstractizare) în realizarea modelului atât din punctul de vedere static (structural). Modelarea depozitelor de date cu ajutorul metodologiei orientate–obiect presupune utilizarea conceptelor fundamentale ale paradigmei OO (clase. analiştii de sistem vor putea să determine o mulţime de alte componente care vor fi necesare pentru fiecare versiune. cât şi pentru utilizatori. se recomandă alcătuirea unei liste sintetice cu cele care pot fi de folos în cadrul organizaţiei. deoarece ar rezulta un sistem uriaş. 4. realizarea unei vederi preliminare de ansamblu asupra cerinţelor. agregare. greu de gestionat. Strategia de realizare a depozitelor de date Strategia de realizare a depozitelor de date este primul pas care trebuie parcurs şi presupune elaborarea următoarelor elemente:  planul preliminar al depozitului de date. încapsulare. moştenire. 2. 2. Aceşti paşi vor fi prezentaţi în continuare.28 - . implementarea. strategia de realizare. iar aceste cerinţe vor fi ataşate diferitelor componente ale depozitului. care pot uşura sau îngreuna proiectul depozitului de date. Fiecare etapă poate fi îndeplinită într-un interval de timp de aproximativ trei până la cinci săptămâni. polimorfism. Există un număr destul de mare de medii de dezvoltare pentru depozitele de date şi. exploatarea. Înţelegerea profundă a organizaţiei ajută la stabilirea contextului în care se desfăşoară proiectul şi poate evidenţia aspectele culturii organizaţionale. rotaţii în cadrul acestora. deci trebuie modelat distinct accesul la date. selecţii de dimensiuni. Răspunsurile la întrebările legate de organizaţie se obţin de obicei de la susţinătorul proiectului. Determinarea contextului organizaţional.  arhitectura preliminară a depozitului de date. În cadrul unui proiect de DD nu pot fi satisfăcute chiar toate cerinţele utilizatorilor. care pot fi sintetizate în necesitatea parcurgerii următorilor paşi/etape: 1. 3. definirea versiunilor depozitului de date. Alegerea unor produse informatice standardizate va reduce problemele de integrare şi va minimiza efortul de învăţare atât pentru echipa de dezvoltare. Natura iterativă a proiectului permite echipei de dezvoltare să extindă funcţionalităţile depozitului de date într-o manieră uşor de controlat. definirea arhitecturii preliminare a depozitului de date şi evaluarea mediilor de dezvoltare a depozitului de date. Etape de realizare a depozitelor de date Din analiza diferitelor metodologii de realizare a depozitelor de date se pot deduce o serie de activităţi. Etapele necesare pentru a duce la îndeplinire strategia depozitelor de date sunt următoarele: determinarea contextului organizaţional. în funcţie de disponibilitatea resurselor şi mărimea organizaţiei. de regulă se face o listă cu priorităţile cerinţelor utilizatorilor. planificarea (modelarea) cerinţelor. 1. identificarea surselor de date externe. Gestiunea volumelor mari de date  operaţiile tipice realizate – utilizarea depozitelor implică schimbări de perspectivă.

La ce nivel măsuraţi profitabilitatea în grupul sau departamentul dvs. Ce produse vindeţi şi cum le clasificaţi? Aveţi o ierarhie a produselor? Analizaţi datele pentru toate produsele în acelaşi timp sau analizaţi datele despre fiecare produs în parte? Cum gestionaţi modificările care intervin în ierarhia produselor? Geografia. Obiectivul principal este acela de a înţelege nevoile utilizatorilor. Organizaţia operează în mai mult de o singură zonă? Vă împărţiţi piaţa în zone geografice? Păstraţi datele despre vânzări pe fiecare regiune în parte? La realizarea interviurilor pentru dezvoltarea depozitelor de date. Realizarea unei viziuni preliminare de ansamblu asupra cerinţelor. Care sunt rolurile şi responsabilităţile fiecăruia dintre cei care au legătură cu proiectul? Este important să definim rolul şi responsabilităţile fiecărei persoane implicate. care se află sub controlul susţinătorului proiectului. este foarte puţin probabil ca un depozit de date să fie pe lista de priorităţi. mai ales dacă sunt implicaţi şi terţi. Care este misiunea grupului sau a departamentului? Cum procedaţi ca să vă îndepliniţi misiunea? Cum ştiţi dacă aţi atins obiectivele fixate? Care sunt indicatorii de performanţă pe care îi folosiţi şi care sunt factorii critici de succes? Clienţii. astfel încât să poată fi ierarhizate. Dacă. destul de mult. rapoartele? Produsele. Ce rapoarte folosiţi acum? Ce informaţii folosiţi de fapt din fiecare raport pe care îl primiţi? Putem obţine machete ale acestor rapoarte? Cât de des se produc aceste rapoarte? Le primiţi destul de frecvent sau timpul de aşteptare este prea mare? Cine produce rapoartele pe care le primiţi? Cine sunt cei pentru care alcătuiţi dvs. Cum vă grupaţi sau vă clasificaţi clienţii? Se modifică această grupare de-a lungul timpului? Modul de grupare afectează modul în care vă trataţi clienţii? Ce fel de informaţii păstraţi despre fiecare tip de client? Ce informaţii demografice folosiţi? Aveţi nevoie să păstraţi date despre fiecare client în parte? Profitul. de exemplu. departamentul IT este foarte preocupat cu îmbunătăţirea sistemelor operaţionale. Inventarul cerinţelor furnizează aria de întindere a informaţiilor pe care se aşteaptă să le ofere un viitor depozit de date. Trebuie ştiut care sunt relaţiile de lucru dintre ele şi care este gradul de ocupare. Care sunt grupurile IT din organizaţie care sunt implicate în proiectul de realizare a depozitului de date? Deoarece un depozit de date este o dorinţă a organizaţiei. În acest fel se stabilesc limite şi obiective. Dacă este posibil. se recomandă obţinerea de formate referitoare la rapoartele curente folosite de conducere. realizate în comunitatea utilizatorilor finali. iar comunicarea şi înţelegerea proiectului se îmbunătăţesc.? Pe agent? Pe client? Pe produs? Pe regiune? La ce nivel de detaliere sunt înregistrate costurile şi veniturile? Ce fel de rapoarte privind profitabilitatea folosiţi actualmente? Sistemele. Aceasta este o informaţie critică care determină aria fiecărui segment din depozitul de date. Pentru câte luni sau ani aveţi nevoie să fie păstrate datele? Analizaţi performanţele pe durata unui an? La ce nivel de detaliere aveţi nevoie să fie prezentate graficele? Zilnic? Săptămânal? Lunar? Trimestrial? Anual? Cât de repede aveţi nevoie de date? Interogările şi rapoartele. individuale sau de grup. grupurile IT din interior vor fi întotdeauna implicate în acest efort. Funcţiile. Acesta joacă un rol foarte important în stabilirea relaţiilor de lucru între membrii echipei de dezvoltare.29 - .? Ce fel de transformări manuale de date trebuie să faceţi atunci când datele nu sunt disponibile? Timpul. Accesul facil la datele depozitului poate fi limitat de domeniul organizaţional. este indicat să se ia în considerare următoarele recomandări: . Gestiunea volumelor mari de date Cine este finanţatorul (susţinătorul) proiectului în acest caz? Susţinătorul proiectului stabileşte domeniul proiectului DD. Ce sisteme folosiţi ca parte a muncii dvs. În această etapă se obţine un inventar al cerinţelor utilizatorilor prin interviuri. 2. Exemple de întrebări care pot constitui repere într-o discuţie cu potenţialii utilizatori ai depozitului de date sunt prezentate în continuare.

Uneori se va constata că o parte dintre situaţiile de ieşire de care au nevoie utilizatorii nu pot fi realizate pe baza datelor existente în sistemele operaţionale. date de la alte organizaţii. Se recomandă dezvoltarea depozitului de date în mai multe versiuni. de aceea. echipamente. Definirea fiecărui modul este finalizată doar atunci când este aprobată de către susţinătorul proiectului.  trebuie păstrat clar obiectivul interviului şi nu trebuie să ne abatem de la el: realizarea unui inventar al cerinţelor şi nu o înţelegere foarte detaliată a lor. Există facilităţi de reţea care pot fi utilizate? Este posibil a se folosi doar un terminal sau un microcalculator pentru a accesa sisteme operaţionale diferite. instrumente utilizator. Care este arhitectura tehnologică curentă a organizaţiei? Ce fel de sisteme.30 - . Este recomandabil ca echipa de dezvoltare să obţină un inventar al sistemelor sursă potenţiale pentru depozitul de date. Disponibilitatea şi calitatea datelor sursă vor juca un rol critic în finalizarea cu succes a acestei faze. Gestiunea volumelor mari de date  trebuie evitat să se facă delimitări clare privind aria depozitelor de date. Abordarea iterativă permite gestionarea eficientă a cerinţelor utilizatorilor şi reduce efectele riscurilor care pot apărea. Există o legătură între diversele sisteme sursă? Un sistem furnizează informaţii altuia? Sistemele sunt integrate într-un mod anume? Facilităţi de reţea. date statistice sau demografice. dacă persoana este de acord. 3. din orice zonă? Calitatea datelor. Definirea versiunilor depozitului de date.  echipa care realizează interviurile trebuie să fie mică. Organizaţia poate folosi surse de date externe pentru completarea datelor din sistemele sursă interne. din sistemele actuale sunt cunoscute pentru slaba calitate a datelor? Documentaţia. structura bazelor de date. ele prezintă dificultăţi din cauza granularităţii diferite şi. Deşi datele externe reprezintă o oportunitate pentru îmbogăţirea depozitului de date. Identificarea surselor de date externe. În timp ce managerul IT va furniza imaginea de ansamblu a sistemelor existente în organizaţie. Echipa ideală este formată din doi oameni: unul pune întrebările şi celălalt notează răspunsurile. date de la agenţii de ştiri sau din publicaţii. tabele sau câmpuri. De asemenea. Pot fi luaţi în calcul mai mulţi factori pentru o mai bună înţelegere a cerinţelor fiecărui modul.  se poate înregistra interviul. Câtă documentaţie este disponibilă pentru sistemele sursă? Cât de corecte şi de actuale sunt aceste manuale şi referinţe? Este bine să se obţină următoarele informaţii ori de câte ori este posibil: copii ale manualelor şi instrucţiunilor de utilizare. Astfel de surse de date externe pot fi: date de la bănci. 5. derulate în spirală. scheme de generare a codului sursă. Ce mecanisme de extragere sunt posibile pentru sistemul curent? Ce mecanisme au fost folosite înainte şi care credeţi că vor fi mecanismele de extragere a datelor care nu vor funcţiona cu sistemul actual? 4. Fiecărei cerinţe i se atribuie un nivel de prioritate. decizia în legătură cu folosirea datelor externe trebuie să fie bine fundamentată.  stilul de interviu va depinde de persoana intervievată. sisteme de gestiune a bazelor de date. interfeţe de dezvoltare şi de accesare a datelor se folosesc în prezent? Relaţiile între sistemele sursă. Managerii de nivel mediu sunt cei care lucrează cel mai mult cu rapoartele analitice. Realizarea auditului preliminar referitor la sistemele sursă. Mecanisme de extragere posibile. reţele. coduri poştale. în timp ce managerii de nivel înalt au cerinţe legate de informaţii cu caracter strategic. părţi de programe sursă. Se face o evaluare iniţială a complexităţii în funcţie de numărul sistemelor sursă. detaliile pentru auditarea sistemelor sursă vor fi furnizate de administratorii de sistem care întreţin sistemele operaţionale. ascultarea ulterioară a discuţiei putând fi de mare ajutor. triere. Care este calitatea datelor? Cât de multe operaţii de filtrare. este identificat şi sistemul ţintă. Exemple de întrebări tipice pentru realizarea unui astfel de audit sunt prezentate în continuare Arhitectura curentă. . duplicare şi integrare estimaţi că vor fi necesare? Ce zone.

proiectarea schemelor depozitului. Arhitectura trebuie să asigure faptul că anumite concentrări de date nu sunt implementate izolat. Aria de cuprindere a modulului va fi determinată ţinând cont de interogări şi rapoarte. auditarea sistemelor sursă. 2. Numărul de utilizatori. transformarea câmpurilor sursă în cele destinaţie. Analiza cerinţelor informaţionale. stabilită de către specialiştii organizaţiei. aşa cum a fost ea definită în documentaţia strategiei. încărcarea datelor istorice în depozit. Planificarea depozitului de date detaliază domeniul preliminar al unei versiuni prin obţinerea detaliilor despre cerinţele utilizatorilor referitoare la interogări. În această etapă este revizuită aria de cuprindere a modulului depozitului de date. în funcţie de aria de întindere a modulului. crearea prototipului pentru versiunea curentă. Localizarea. modul în care sunt rezolvate problemele care apar. 2. Membrii echipei vor fi instruiţi cu privire la conceptele referitoare la tehnologia depozitelor de date. Se definesc aceste elemente pentru fiecare modul în parte. selectarea mediilor de dezvoltare. Este necesar să se indice modul în care sunt legate diferite baze de date. Alcătuirea echipei de lucru. Fiecare membru al echipei va fi instruit privind rolul pe care îl va avea în cadrul echipei (drepturi şi responsabilităţi). Se precizează locul de dispunere a depozitului de date. Trebuie să se schiţeze o arhitectură preliminară pentru fiecare modul. disponibilitatea şi calitatea documentaţiei sistemelor sursă. Analiza cerinţelor informaţionale se poate desfăşura în paralel.2. Evoluţia proiectului variază în funcţie de: modul de participare a personalului din întreprindere. Trebuie descrise activităţile proiectului. Se va stabili şi frecvenţa întâlnirilor cu toţi membrii echipei. Se va finisa acest aspect prin detalierea analizei preliminare a cerinţelor decizionale. Este recomandat să se analizeze posibilitatea de a se folosi o intercorelare de baze de date relaţionale şi multidimensionale.). Un proiect de planificare (modelare) durează între cinci şi opt săptămâni. Definirea arhitecturii preliminare a depozitului de date. pentru a analiza starea în care se află proiectul. care vor putea fi . Va fi necesar să se stabilească noi întâlniri cu reprezentanţii utilizatorilor. precum şi legăturile care există între diversele activităţi. astfel încât să poată fi stabilite termene şi obiective realiste pentru fiecare în parte. Modelarea depozitelor de date Modelarea (planificarea) unei versiuni a depozitului de date se realizează conform strategiei acestuia. Organizaţia poate alege dintre mai multe medii şi interfeţe pentru a dezvolta depozitul de date. Se vor elimina variantele neconvenabile şi se va alcătui o listă din care fiecare versiune va avea parte de un set de interfeţe (acces la date. a concentrărilor de date şi a utilizatorilor pentru fiecare modul. de regulă săptămânal. 7. Depozitul de date şi concentrările de date. Se începe cu organizarea internă a echipei în cazul în care este necesară o astfel de structură formală. Gestiunea volumelor mari de date 6. în timpul planificării depozitului de date. Se specifică numărul de utilizatori pentru fiecare interfaţă de acces la fiecare versiune în parte. în funcţie de aria de întindere aprobată. SGBD etc. Se identifică toate părţile care vor fi implicate în implementarea depozitului de date şi vor fi iniţiate în legătură cu proiectul. Important este să se selecteze combinaţia de interfeţe care satisfac cel mai bine cerinţele organizaţiei.31 - . cu activitatea de auditare a sistemelor sursă. Etapele necesare pentru realizarea planificării depozitului de date sunt următoarele: alcătuirea echipei. 1. la construirea unei scheme iniţiale a depozitului de date şi la stabilirea câmpurilor de interes din sistemele sursă. Obiectul analizei cerinţelor îl constituie înţelegerea cerinţelor informaţionale ale decidenţilor. analiza cerinţelor. Se vor distribui copii ale materialelor referitoare la strategia de realizare a depozitului. Evaluarea mediilor de dezvoltare a depozitului de date. precum şi instrumentele adecvate. O analiză preliminară a fost deja efectuată în etapa de formulare a strategiei DD.

fără ca în prealabil să formuleze strategia acestuia. iar aceste informaţii vor fi oferite auditorilor pentru a fi confirmate. mai ales dacă interogările şi rapoartele se focalizează pe măsurarea profitabilităţii.  bazele de date: pentru fiecare sistem sursă se va identifica tipul bazei de date folosite şi se vor face aprecieri asupra mărimii ei. Aceste persoane sunt. mai sunt folosite ca sursă de date şi rapoartele financiare ale întreprinderii. posibilitatea unificării lor. definirea arhitecturii acestuia. cu specialiştii IT din organizaţie şi se va urmări obţinerea următoarelor documente şi informaţii. Administratorii de baze de date şi ceilalţi specialiştii IT pot oferi informaţii valoroase cu privire la regulile după care se obţin rapoartele existente pe baza datelor operaţionale. Cele mai bune candidate pentru a fi sisteme sursă sunt sistemele operaţionale care automatizează tranzacţiile zilnice ale întreprinderii. Pentru auditarea sistemelor sursă trebuie realizate interviuri. Auditarea sistemelor sursă. Ca regulă generală. ei sunt cei mai în măsură să aprecieze oportunitatea folosirii fiecărui sistem ca sursă de date pentru depozit. atunci când un grup de utilizatori preiau iniţiativa realizării depozitului de date. familiarizate cu problemele legate de calitatea datelor din diverse sisteme sursă. arhitectura reţelei (diagrama care descrie configurarea reţelei).  sistemele de codificare: fiecare sistem sursă poate folosi un alt sistem de codificare şi de aceea administratorii bazei de date trebuie să ofere informaţii referitoare la: modul în care sunt generate codurile. Uneori. În cazul în care sunt disponibile şi surse de date externe. după ce în prealabil şi-a sintetizat cerinţele informaţionale. de o echipă de 6- 12 membri. vor fi documentate toate limitările impuse de sistemele sursă. aria trebuie limitată astfel încât versiunea să poată fi implementată într-o perioadă de la trei până la şase luni. este posibil ca o organizaţie să treacă direct la faza de planificare a depozitului de date. individuale sau de grup. Finanţatorul proiectului trebuie să revadă şi să aprobe documentaţia pentru a se asigura că aşteptările conducerii organizaţiei vor fi atinse. Având în vedere cunoştinţele pe care le au asupra sistemelor existente. anumite activităţi din etapa de formulare a strategiei vor fi etape din planificarea primei versiuni a depozitului de date: determinarea contextului organizaţional. . modelul datelor întreprinderii (un model al tuturor datelor care sunt stocate în prezent). Gestiunea volumelor mari de date realizate la finalizarea modulului depozitului de date. definirea modulelor depozitului de date. Auditarea preliminară a sistemelor sursă.32 - . va aduce eventual noi date disponibile sau vor fi pierdute o parte dintre cele existente.  planurile de perspectivă: ce proiecte de dezvoltare şi implementare au fost aprobate pentru următoarele 6-12 luni pentru fiecare sistem sursă în parte. administratorii de sistem şi alţi specialişti IT. Aria de cuprindere a versiunii determină direct timpul de implementare. Sistemele surse de date sunt în primul rând cele interne. De asemenea. În acest caz.  manualul tehnic şi manualul de utilizare pentru fiecare sistem sursă: modelele datelor şi schemele pentru toate subsistemele informatice care pot fi sisteme sursă. de asemenea. dacă nu au fost deja colectate în etapa de stabilire a strategiei de realizare a depozitului:  documentaţia arhitecturii IT a organizaţiei: diagramele arhitecturii sistemului (un model al tuturor sistemelor informaţionale existente în întreprindere şi al legăturilor dintre ele). ele vor putea fi integrate în depozitul de date. modul de reutilizare a codurilor. Persoanele cele mai potrivite în cazul auditării sistemelor sursă sunt administratorii de baze de date. dacă schimbarea structurii datelor va afecta preluarea datelor din sistemele sursă în depozit. care gestionează sisteme interne ce pot deveni surse pentru depozitul de date. Informaţiile oferite de aceştia vor fi documentate pentru a sprijinii procesul de extragere şi filtrare a datelor. realizată deja în cadrul formulării strategiei depozitului de date. 3. evaluarea instrumentelor şi a mediilor de dezvoltare. Auditarea sistemelor sursă trebuie să ofere o vedere de ansamblu asupra sistemelor care pot fi surse potenţiale de date pentru depozitul de date. Acest lucru se întâmplă. O arie prea mare va face ca proiectul să nu poată fi gestionat eficient. Pe lângă sistemele operaţionale. de obicei. trebuie să ofere o listă completă a surselor de date.

Realizarea şi prezentarea unui prototip de depozit de date este motivată de unul sau mai multe dintre aspectele următoare:  selectarea interfeţelor software. Oraş. De exemplu. Un câmp din depozitul cu date poate fi populat cu date din mai multe sisteme sursă. echipa trebuie să verifice dacă schema a suferit modificări în această perioadă. Este posibilă şi situaţia inversă. Dacă a fost efectuat un studiu amănunţit al acestui aspect în etapa de definire a strategiei. Judeţ. Aceste aspecte vor fi mult mai dificil de analizat. mai ales în cazul în care structura nu este documentată. există sisteme operaţionale care înregistrează adresele ca linii de text cu denumirea câmpului Adresa ce poate fi împărţit în mai multe câmpuri cum ar fi: Stradă. Transformarea câmpurilor sursă în câmpurile destinaţie. Prin folosirea listei finale a mediilor de dezvoltare se va crea prototipul depozitului de date. La încărcarea datelor istorice în depozitul de date trebuie avute în vedere următoarele aspecte:  schimbările în structura datelor. 5. un câmp din sistemele operaţionale poate fi divizat în mai multe câmpuri în depozitul de date. dacă fiecare sistem operaţional va avea propriile înregistrări referitoare la clienţi şi produse atunci un câmp din depozitul de date care va fi denumit Nume_client sau Denumire_produs va fi populat cu date din mai multe sisteme. Proiectarea schemelor depozitului de date. operaţiunile de extragere şi integrare a datelor devin mai complicate. Proiectarea schemelor depozitului de date trebuie să asigure acoperirea cerinţelor informaţionale ale utilizatorilor versiunii respective. Rezultatul evaluării va folosi în selectarea interfeţelor: produse OLAP. Sunt disponibile scheme rezultate din două tipuri de modele: relaţional (bazat pe normalizare) şi multidimensional (bazat pe denormalizare). Pentru a elimina orice confuzie. Este posibil să se ceară furnizorilor de tehnologii informatice să ofere un prototip al depozitului de date pentru a-l evalua.33 - . care sunt denormalizate şi conţin tabele de fapte şi tabele dimensiune. fulg de zăpadă. 6. Selectarea mediilor de dezvoltare. 7. În mod obligatoriu trebuie să se determine dacă datele istorice sunt disponibile pentru încărcarea lor în depozitul de date. generatoare etc. La trecerea câmpurilor sursă în câmpurile destinaţie trebuie să se stabilească modul în care câmpurile din sistemele sursă operaţionale sunt transformate în câmpuri ale depozitului de date. Aceasta este o consecinţă naturală a rolului de integrare pe care îl are depozitul de date. În modelarea multidimensională se lucrează cu schemele: stea. 8. activitatea de selectare devine opţională. Pachetele de aplicaţii existente şi SGBD pot avea probleme. Spre exemplu. care poate apărea referitor la modul în care datele sursă sunt transformate în depozitul de date. 4. constelaţie. În caz afirmativ. Încărcarea datelor istorice în depozitul de date. dacă documentaţia necesară lipseşte sau dacă niciun specialist IT din întreprindere nu este familiarizat cu vechile scheme de date. În modelarea bazată pe normalizare schema bazei de date este proiectată folosind tehnicile de normalizare utilizate în sistemele relaţionale (tranzacţionale – OLTP). Se va determina dacă schemele tuturor sistemelor sursă au suferit modificări în timp. De asemenea. trebuie să se precizeze toate regulile care guvernează integritatea sau divizarea datelor. Gestiunea volumelor mari de date  mecanismele de extragere: trebuie verificat dacă datele pot fi citite sau extrase direct din bazele de date operaţionale. Crearea prototipului pentru versiunea curentă. Dacă strategia de realizare a depozitului nu a fost formulată atunci trebuie să se facă evaluarea în acest moment. dacă perioada pentru care sunt păstrate datele în depozit este de doi ani şi datele din ultimii doi ani trebuie încărcate în depozit. se recomandă crearea unui tabel sursă-destinaţie care să evidenţieze cum se transformă fiecare câmp. fiecare sistem sursă putând necesita propriul tabel sursă-destinaţie. . Spre exemplu.  disponibilitatea datelor istorice. În această etapă se finalizează alegerea produselor software necesare pentru realizarea depozitului. Este obligatoriu să se facă selecţia mediilor de dezvoltare pentru ca livrarea lor să nu perturbe procesul de dezvoltare.

cele mai multe dintre programele de extragere şi prelucrare a datelor nu sunt suficient documentate şi sunt cunoscute doar de cei care le-au conceput.  validarea prototipului. care vor fi prezentaţi în continuare: 1. Implementarea depozitelor de date Unele dintre soluţiile pentru a obţine rapoartele decizionale solicitate de manageri necesită doar programe simple de extragere a datelor. încărcarea depozitului de date. 1. în aceeaşi organizaţie. În acest sens vor fi vizate următoarele aspecte:  datele actuale folosite pentru obţinerea rapoartelor. 6. 3. De regulă. Alte soluţii necesită executarea unei serii complexe de paşi. Aceste reacţii pot ghida echipa de dezvoltare privind corecţiile care trebuie efectuate. 2. următoarele aspecte trebuie să devină clare pentru utilizatori: obiectivele întâlnirilor. 4. formule de calcul.  programele actuale de extragere a datelor. 2. de asemenea. ca urmare. Echipa de dezvoltatori va invita reprezentanţii utilizatorilor să folosească prototipul pentru a-şi formula o părere iniţială. programele de extragere. adică persoane diferite aplică formule şi reguli diferite pentru aceleaşi date. Gestiunea volumelor mari de date  corectitudinea schemei de date. o astfel de experienţă declanşează o multitudine de reacţii pozitive şi negative din partea utilizatorilor. nu se aplică aceleaşi standarde pentru aceleaşi informaţii. care sunt executate periodic pentru a obţine datele necesare.34 - . Dacă cerinţele utilizatorilor pot fi îndeplinite folosind schema proiectată. El oferă utilizatorilor ceva tangibil. 7. Programele de extragere sunt un indiciu valoros pentru realizarea tabelelor sursă-destinaţie. testarea depozitului de date. Astfel. care este necesară pentru crearea rapoartelor solicitate de manageri. aria de cuprindere a prototipului. Prototipul este primul rezultat concret al efortului de dezvoltare. Astfel. 8. reguli. provine din unul sau mai multe sisteme sursă disponibile în întreprindere. instruirea utilizatorilor. Fiecare secvenţă de date. definirea ariei de cuprindere. natura şi sursa datelor folosite la validare. pot fi descoperite inconsistenţe referitoare la folosirea unor termeni. Este posibil ca echipa care planifică depozitul de date să descopere o serie de deficienţe legate de rapoartele care se produc în organizaţie. care combină manipularea datelor.3. ele oferă informaţii valoroase referitoare la regulile de transformare a datelor. în funcţie de persoana care creează sau citeşte raportul. se ajunge în situaţia în care. În cazul în care există astfel de situaţii. atunci echipa poate valida această schemă. În absenţa unui depozit de date multe dintre cerinţele decizionale sunt clasificate în categoria rapoartelor ad-hoc şi. Echipa va realiza un prototip bazat pe o anumită schemă şi apoi va lansa interogări sau rapoarte de probă pe baza datelor reale din sistemele sursă. crearea planului de implementare pentru versiunea curentă. Faza de implementare a depozitelor de date presupune parcurgerea următorilor paşi. ele trebuie analizate cu grijă pentru a se obţine informaţiile necesare şi pentru a se elimina o parte dintre transformările manuale. 9. însă există date . Definirea ariei de cuprindere a depozitului de date. formulele de conversie. Echipa de dezvoltare a depozitului de date trebuie să urmărească în primul rând introducerea standardelor locale sau internaţionale pentru manipularea datelor.  transformarea manuală a datelor. utilizatorilor să experimenteze pentru prima dată noua tehnologie. Avantajul este că echipa de dezvoltare va şti din start care câmpuri din aceste sisteme sunt mai importante. stabilirea schemei depozitului de date. La validarea prototipului. Aceste date trebuie să fie incluse în procesul de auditare a sistemelor sursă. Astfel. metadatele din depozitul de date. 5. El permite. pe care îl pot vedea şi folosi. modul de acces la date. implementarea propriu-zisă a depozitului de date.

dar nu sunt disponibile în sistemele sursă. Astfel. O secvenţă de date este considerată lipsă dacă nu există niciun sistem sursă care să fie prevăzut pentru a o colecta şi stoca.  estimarea resurselor şi a efortului. Combinaţia dintre abordările top-down şi bottom-up oferă procesului de planificare avantajul de a vedea problema din două perspective complementare: cerinţele utilizatorilor şi datele disponibile în sistem.  secvenţe de date care lipsesc. trebuie identificat modul cum poate fi îmbunătăţită calitatea datelor.35 - . Aşa se ajunge în situaţia că astfel de secvenţe de date sunt înregistrate doar pentru o parte dintre clienţi. planificarea depozitului de date are ca scop definirea clară a ariei de cuprindere a fiecărui modul din acesta. Se poate observa cum aria de cuprindere a unui depozit de date poate fi compromisă de limitările impuse de datele din sistemele sursă curente. dacă sistemele de acordare a împrumuturilor bancare nu înregistrează domeniul de activitate în care activează fiecare beneficiar de credite. Sunt oferite. Un raport de auditare a sistemelor sursă trebuie să conţină următoarele componente:  lista sintetică a sistemelor sursă. Trebuie să luăm în considerare şi varianta îmbunătăţirii sistemelor sursă în paralel cu desfăşurarea proiectului de realizare a depozitului de date. . sistemul de acordare a împrumuturilor poate avea un câmp denumit stare_client. se poate preciza un cost estimativ şi durata de timp necesară pentru a adăuga datele lipsă sau pentru a îmbunătăţi calitatea datelor. Echipa de dezvoltare trebuie să identifice toate limitările impuse de sistemele curente (auditarea). precum şi câmpurile esenţiale. Cele mai multe proiecte se limitează doar la ceea ce oferă sistemele sursă. însă pot avea o mare importanţă pentru deciziile tactice şi strategice. Crearea planului de implementare pentru versiunea curentă a depozitului. De exemplu.  secvenţe de date incomplete sau opţionale. Pentru fiecare sistem operaţional. De exemplu. Pot apărea date eronate când acestea sunt stocate în unul sau mai multe surse de date. acest lucru nu este posibil. dar dezvoltatorii aplicaţiei l-au prevăzut ca fiind un câmp opţional. Cele mai frecvente cazuri sunt cele ale datelor care nu sunt stocate. datele nu sunt disponibile. din una dintre următoarele cauze posibile: erori care au scăpat la introducerea datelor. atunci banca va avea probleme serioase când va dori să-şi analizeze gradul de expunere la risc în funcţie de sectorul economic finanţat. Limitările impuse de datele disponibile pot fi de următoarele tipuri:  secvenţe de date care lipsesc.  date eronate. descrieri generale ale funcţionalităţilor şi ale datelor. În această secţiune sunt evidenţiate datele care ar fi necesare în cadrul depozitului de date. din cauza faptului că datele nu sunt disponibile în totalitate. iar acest lucru va fi utilizat în procesul de rafinare.  rafinarea calităţii datelor. doar o parte a raportului anterior poate fi realizată şi anume doar pentru clienţii pentru care s-au înregistrat valorile pentru acel câmp. se merge pe varianta valorilor implicite care de fapt nu sunt corecte. pentru fiecare sistem operaţional. perioade de timp etc. însă nu există reguli care să precizeze clar că acea secvenţă trebuie să fie colectată şi stocată sau nu. Această secţiune trebuie să listeze toate sistemele operaţionale existente. produse. Pentru fiecare sistem operaţional. deoarece nu va putea genera un raport detaliat pe această temă. Atunci când se doreşte realizarea unei analize globale. De asemenea. Există cazuri când o secvenţă de date este clasificată cu termenul de reţinut. o listă cu entităţile cele mai importante. se pot menţiona şi utilizatorii actuali ai sistemelor analizate. În concluzie. 2. deoarece nu au nicio importanţă pentru derularea zilnică a tranzacţiilor. Gestiunea volumelor mari de date care nu se regăsesc în sistemele sursă. Trebuie evidenţiată importanţa datelor care lipsesc şi modul cum pot fi ele obţinute.

atunci planul implementării va estima o durată mai mică de realizare. doar 12 ore. reguli care trebuie respectate etc. a) Achiziţia şi configurarea mediului de dezvoltare Prima activitate din procesul de implementare o reprezintă achiziţia şi configurarea mediului de dezvoltare.  numărul de procese decizionale asistate. instalarea .. întreţinere zilnică şi optimizare. de exemplu.  dimensiunea estimată a volumului de date. Cu cât sunt asistate mai multe procese decizionale. Procesul de implementare a depozitului de date constă de fapt din activităţile legate de implementarea fiecărei versiuni. încep activităţile de gestionare. Astfel. 3. Un proiect de implementare a depozitului de date trebuie să dureze între trei şi şase luni. Implementarea propriu-zisă a depozitului de date. Progresul lucrărilor efectuate variază în funcţie de calitatea proiectării depozitului de date. f) construirea subsistemului pentru încărcarea depozitului de date. necesită o arhitectură specifică. cu atât va fi mai mare numărul utilizatorilor care vor avea observaţii privind depozitul. Alţi membri ai echipei sunt responsabili cu instalarea şi configurarea interfeţelor pentru a permite utilizatorilor accesul la depozitul de date. Unul dintre atuurile tehnologiei depozitelor de date este că este orientată pe subiecte. Odată instalat depozitul de date. de disponibilitatea şi interesul beneficiarului. Pentru un astfel de plan trebuie avuţi în vedere următorii factori:  numărul sistemelor sursă şi mecanismele specifice de extragere a datelor. timp de 5 zile pe săptămână. munca echipei de dezvoltare va fi mult uşurată. d) construirea sau configurarea subsistemelor de extragere şi transformare. Cu cât sunt mai multe sisteme sursă. Cu cât va fi mai mare numărul subiectelor avute în vedere. Volumul de date permite echipei de dezvoltare să aprecieze durata de încărcare a depozitului de date (numărul de înregistrări ponderat cu durata necesară pentru încărcarea unei înregistrări). Procesul de implementare propriu-zisă a depozitului de date presupune realizarea următoarelor activităţi: a) achiziţia şi configurarea mediului de dezvoltare.  disponibilitatea şi calitatea documentaţiei sistemelor sursă. cu atât va creşte complexitatea versiunii. Această mărime furnizează o estimare preliminară a efortului de încărcare şi prelucrare a depozitului de date. datorită numărului sporit de tabele de fapte care vor rezulta. c) finalizarea proiectării schemei fizice a depozitului de date. Această valoare este impusă de cerinţele utilizatorilor (cât de „proaspete” trebuie să fie datele) şi este determinantă pentru proiectarea şi implementarea depozitului. Instruirea utilizatorilor şi testarea depozitului de date sunt activităţi care au loc spre finalul proiectului de implementare. înainte de instalarea definitivă. Activităţile sunt organizate pe baza rezultatelor etapei de planificare a depozitului de date. care cuprinde următoarele aspecte: instalarea componentelor hardware. este posibil să se schiţeze un plan de implementare pentru versiunea curentă a depozitului de date.  rata de încărcare a depozitului de date. Dacă se poate conta pe sprijinul real al compartimentului IT şi al altor persoane implicate.  disponibilitatea solicitată de utilizatori. Gestiunea volumelor mari de date După definirea ariei de cuprindere şi specificarea modului de transformare a datelor sursă. referitoare la definiţii de termeni.36 - .  numărul de subiecte reţinute în depozitul de date. cu atât procesele de extragere şi integrare sunt mai multe şi mai complexe. În cazul în care aceste documentaţii există şi sunt actualizate. Echipa construieşte de asemenea subsistemele depozitului care asigură un flux constant de date valide din sistemele operaţionale în DD. diferită de a unuia care trebuie să fie disponibil. calitatea planului de implementare. b) obţinerea copiilor colecţiilor de date operaţionale. echipa de implementare construieşte sau extinde o schemă existentă a depozitului de date bazată pe proiectul schemei realizată în timpul planificării. e) construirea sau configurarea subsistemului pentru asigurarea calităţii datelor. Un depozit de date care să fie disponibil non- stop pentru utilizatori.  participarea şi sprijinul compartimentului IT.

Administratorul depozitului de date poate opta pentru divizarea unei dimensiuni logice (de exemplu. instalarea produselor software pentru DD. Această soluţie este viabilă în măsura în care sistemele sursă sunt într-un mediu omogen. unde conexiunea sistemelor operaţionale cu depozitul de date nu a fost încă realizată. însă performanţa interogărilor scade. Decizia de partiţionare trebuie să aibă în vedere că un depozit de date partiţionat este mai uşor de gestionat. client) în două sau mai multe dimensiuni separate (de exemplu.) care sunt comparate cu tabelele iniţiale. care pot fi cele originale sau doar copii încărcate pe serverul depozitului de date. Interfeţele software oferite de diverşii producători sunt capabile să documenteze procesul de extragere prin generarea metadatelor specifice. apoi să le pună la dispoziţia utilizatorilor. Echipa de dezvoltare trebuie să aibă la dispoziţie infrastructura necesară pentru a realiza efectiv implementarea depozitului. De aceea echipa trebuie să intre în posesia copiilor colecţiilor de date operaţionale pe care le va stoca pe serverul depozitului. De obicei. SGBDR nu trebuie neapărat să fie acelaşi cu cel existent în sistemele operaţionale. Acest lucru este posibil mai ales în cadrul proiectelor pilot. Extragerea se poate realiza printr-o varietate de mecanisme. crearea conexiunilor în reţea şi stabilirea drepturilor utilizatorilor. Aplicaţiile . o dimensiune client şi o dimensiune demografie) pentru a economisi spaţiul de memorare şi pentru a creşte performanţa interogărilor. instalarea şi configurarea motorului pentru baze de date relaţionale. O modalitate este aceea de a folosi numărarea cazurilor (numărul de clienţi.37 - . în funcţie de mărimea lor şi de posibilităţile de partiţionare care sunt suportate de motorul de baze de date. de la interfeţe software specializate până la programe realizate de personalul propriu. numărul de tranzacţii etc. deoarece diferă de la o organizaţie la alta în funcţie de sistemele sursă. În cazul în care depozitul de date este gestionat cu suport bază de date relaţională. c) Finalizarea proiectării schemei fizice a depozitului de date Detaliile proiectării logice şi fizice ale depozitului de date din faza de planificare se transpun într-o versiune finală a schemei fizice. Gestiunea volumelor mari de date sistemului de operare. avându-se în vedere următoarele aspectele specifice ale sistemului software. Aceste activităţi nu pot fi automatizate total. care a fost ales pentru depozitul de date:  proiectarea schemei depozitului de date. Subsistemul de extragere se referă la procesul de obţinere a datelor necesare din colecţiile de date ale sistemului operaţional. organizaţiile preferă deseori să-şi dezvolte propriile lor aplicaţii de extragere a datelor. Utilitarele pentru verificarea calităţii datelor pot sprijini echipa de dezvoltare în activitatea de implementare a depozitului de date. Echipa de implementare trebuie să dispună de un mecanism de verificare a corectitudinii şi completitudinii datelor care sunt încărcate pe serverul DD. De aceea. Crearea acestor copii poate fi automatizată prin folosirea tehnicii de replicare din tehnologia sistemelor de baze de date distribuite. Se finalizează proiectarea fizică a tabelelor de fapte şi a tabelelor dimensiune cu câmpurile lor specifice. d) Construirea sau configurarea subsistemelor de extragere şi transformare Subsistemele de transformare şi extragere trebuie să filtreze şi să încarce datele din sistemul operaţional în depozitul de date. în funcţie de dimensiunea estimată a volumului de date şi de natura anticipată a interogărilor ce se vor efectua asupra depozitului de date. b) Obţinerea copiilor colecţiilor de date operaţionale Uneori echipa de implementare nu are acces direct la sistemele sursă operaţionale. depozitul de date se află pe o maşină care este separată fizic de restul sistemelor operaţionale. mediul de dezvoltare şi de cerinţele utilizatorilor. Dezavantajul acestora este preţul prea mare.  parţionarea. Administratorul depozitului de date poate opta între partiţionarea tabelelor de fapte şi de dimensiuni. numărul de conturi. Se identifică cea mai potrivită metodă de indexare pentru tabelele şi câmpurile depozitului de date.  indexarea.

De asemenea. oraş. Gestiunea volumelor mari de date pentru extragerea datelor dezvoltate în cadrul organizaţiei au dezavantajul că sunt greu de întreţinut. Prin calcularea şi încărcarea acestor valori în depozit.38 - . Ulterior. e) Construirea subsistemului pentru asigurarea calităţii datelor Probleme legate de calitatea datelor nu sunt întotdeauna vizibile încă de la începutul proiectului de implementare. Fiecare dintre câmpurile utilizate în sistemele operaţionale pot stoca date în diverse formate şi tipuri.  înlocuirea valorilor. care vor fi prezentate în continuare. Înregistrările din mai multe surse sunt comparate pentru a identifica înregistrările duplicat bazate pe valoarea câmpurilor cheie. codurile care au un înţeles specific în sistemul operaţional sunt lipsite de relevanţă pentru manageri.). Tot manual se vor rezolva şi înregistrările duplicat cu valori conflictuale. precalculate înainte de încărcarea lor în depozitul de date. De exemplu. Integrarea reprezintă operaţiunea inversă partiţionării: două sau mai multe câmpuri din sistemul operaţional vor fi integrate în depozitul de date. determinarea de indici şi alte valori derivate pot fi calculate folosind diverse formule. Duplicatele de tip excepţie pot fi rezolvate manual prin folosirea unui sistem de avertizare. administratorii bazei de date şi administratorii de sistem vor avea un rol deosebit de important în această etapă. În tehnologia DD au fost identificate câteva tipuri de transformări. un angajat sau o tranzacţie. Aceştia vor folosi depozitul de date doar în măsura în care au convingerea că datele pe care le gestionează sunt corecte. regiune.  integritatea referenţială slabă. Subsistemul de transformare înlocuieşte valorile originale cu valori noi care sunt utile pentru cei ce folosesc conţinutul depozitului de date. Câteva dintre cauzele care produc erori sunt prezentate în continuare.  derivarea valorilor. Uneori este necesar ca o secvenţă de date din sistemul sursă să fie partiţionată în unul sau mai multe câmpuri în depozitul de date. ţară etc. Agregările pot fi. în timp ce în depozit va fi memorată pe mai multe câmpuri (stradă. zonă.  schimbarea formatului. Uneori. Valorile lipsesc din sistemele sursă. Înţelegerea cauzelor care determină erori în cadrul datelor face mai uşoară munca de depistare şi corectare.  integrarea câmpurilor. posibilitatea ca utilizatorii să le calculeze greşit este eliminată. Una dintre cauzele care determină reticenţa utilizatorilor în privinţa depozitului de date o constituie tocmai slaba calitate a datelor. în cazul în care nu există mecanisme clare în acest sens.  partiţionarea câmpurilor. Deoarece majoritatea erorilor provin din sistemele sursă. integritatea referenţială nu poate fi realizată în sistemele sursă. din cauza valorilor inconsistente. Duplicatele sunt eliminate pentru a crea o singură înregistrare pentru un client. foarte importantă este şi percepţia pe care o au utilizatorii despre date. deoarece există tendinţa ca ele să nu fie documentate la momentul dezvoltării lor. Unul dintre cele mai des întâlnite cazuri de acest gen se referă la adresa clienţilor care în sistemul sursă este memorată într-un singur câmp. Aceste secvenţe individuale de date sunt modificate în timpul procesului de transformare pentru a respecta setul standard de formate din depozitul de date.  redundanţa datelor. Estimările. un produs. de asemenea. . Aceasta este o alternativă la încărcarea doar a valorilor atomice în depozitul de date. Subsistemul de transformare modifică datele în concordanţă cu regulile şi standardele care au fost stabilite pentru depozitul de date. din cauza înregistrărilor incomplete sau a câmpurilor opţionale care nu sunt completate. Unele valori care sunt folosite în sistemele operaţionale pot să nu fie pe înţelesul utilizatorilor depozitului de date.  agregarea valorilor.  valori lipsă. deoarece atenţia echipei este focalizată pe conversia unor volume mari de date şi mai puţin pe analizarea fiecărei secvenţe de date în parte. calitatea datelor va deveni o problemă din ce în ce mai stringentă.

Subsistemul de încărcare a datelor în depozitul de date trebuie să furnizeze facilităţile prezentate în continuare: . volumul mare de date necesită utilizarea unor proceduri automate de partiţionare a câmpurilor.  identificarea datelor importante.  ierarhii multiple. Toate erorile descoperite trebuie să fie corectate la sursă. O parte din datele din depozitul de date pot fi precalculate înainte de încărcarea lor. Dacă sistemele operaţionale care generează date eronate nu sunt revizuite. trebuie stabilită o tactică specifică de optimizare a calităţii. timp etc.săptămână şi zi – lună fiscală – trimestru fiscal – an fiscal. Pentru fiecare secvenţă de date cu importanţă mare pentru întreprindere. ele vor continua să fie o sursă sigură de erori pentru depozite. ca parte a procesului de transformare. aceeaşi secvenţă în două câmpuri diferite. De exemplu. datele care vor fi încărcate sunt stocate în colecţii de date care au aceeaşi schemă ca şi depozitul de date. Înlăturarea datelor multiplicate trebuie să aibă loc înainte de încărcarea lor în depozitul de date. Trebuie determinată mai întâi calitatea datelor pentru fiecare dintre sistemele sursă existente în întreprindere. Multe dintre dimensiunile depozitului de date vor avea ierarhii multiple determinate de necesităţile de analiză. volum. există riscul ca în depozit să apară valori duplicate. f) Construirea subsistemului pentru încărcarea depozitului de date Subsistemul pentru încărcarea depozitului de date preia schema generată de subsistemul de extragere şi transformare şi încarcă datele direct în depozit. dacă formulele sau calculele sunt greşite. ceea ce înseamnă că sistemele operaţionale trebuie să fie adaptate astfel încât să conţină valorile corecte. precum şi ierarhiile zi . atunci depozitul va conţine date eronate. Această practică asigură că atât utilizatorii sistemelor operaţionale. Neînţelegerea semnificaţiilor acestor ierarhii multiple din diferite dimensiuni poate cauza încărcări eronate în depozitul de date. Atunci când este posibil. Practica a dovedit însă că procesul de corectare a datelor la sursă poate fi uneori dificil de implementat atât din cauza responsabilităţilor operaţionale. Gestiunea volumelor mari de date  erori în datele precalculate. cât şi din cauza faptului că datele corecte nu sunt cunoscute.) poate duce la erori în depozitul de date dacă nu se efectuează în prealabil transformări la o măsură unitară. filtrarea datelor trebuie să se focalizeze în primul rând asupra sistemelor sursă. În cazul în care această operaţiune nu se desfăşoară corect. dimensiunea timp poate avea o ierarhie zi – lună – trimestru . Folosirea diferitelor unităţi de măsură pentru diverse atribute (valoare.an. ci trebuie să aibă în vedere prevenirea apariţiei erorilor. generatoare de inconsistenţe şi erori. iar efortul de optimizare poate fi direcţionat în mod eficient către zona de cel mai mare interes.  termeni şi reguli conflictuale. Regulile sau termenii conflictuali pot determina planificatorii depozitului de date să încarce două secvenţe diferite de date în acelaşi câmp al depozitului sau.  prevenirea erorilor. Echipa de implementare trebuie să determine care sunt datele cele mai importante pentru depozitului de date. Efortul întreprinderii nu trebuie să se limiteze doar la corecţii asupra datelor deja existente. cantitate. Calitatea datelor din cadrul organizaţiei poate fi îmbunătăţită prin mai multe modalităţi:  evaluarea calităţii datelor.  obţinerea duplicatelor. În felul acesta se pot stabili anumite priorităţi. care pot să nu funcţioneze corect în toate cazurile.  definirea modului de filtrare şi îmbunătăţire a datelor. astfel încât să se elimine posibilitatea propagării lor în depozitul de date.  partiţionarea câmpurilor.39 - . cât şi cei de la nivel decizional vor beneficia de date corecte. Există cazuri în care un singur câmp din sistemul operaţional trebuie partiţionat în mai multe câmpuri în depozitul de date. Uneori. invers.  unităţi de măsură diferite. După cum s-a menţionat anterior.

un produs sau o tranzacţie este identificată în mod unic printr-o cheie primară. Un astfel de sistem trebuie să furnizeze echipei de implementare informaţii referitoare la modul în care s-a desfăşurat operaţiunea de încărcare. Metadatele din depozitul de date. 5. După definirea schemei tabelelor şi precizarea indecşilor se trece la încărcarea datelor. Indecşii vor fi construiţi în tabele în concordanţă cu schema fizică a depozitului de date. Administratorul depozitului de date realizează schema acestuia în paralel cu construirea şi configurarea subsistemelor back-end (extragere şi transformare. subsistemul de încărcare trebuie să fie capabil să calculeze şi să stocheze şi valori agregate. În acest sens. Echipa care are ca responsabilitate implementarea componentei de acces trebuie să instaleze interfeţele selectate mai întâi pe o maşină de test. care are acces la depozitul de date. Unele echipe de dezvoltare preferă să încarce doar date corecte în depozitul de date. de genul celei prezentate în legătură cu restricţia referenţială.  încărcarea înregistrărilor în tabelele de fapte. Există controverse cu privire la datele inconsistente şi anume dacă acestea trebuie sau nu să fie încărcate în depozitul de date. Unii consideră necuprinderea datelor inconsistente ca pe un lucru absolut normal.  calcularea valorilor agregate pe baza înregistrărilor sursă.  popularea depozitului de date. Modul de acces la date Stabilirea modului de acces la date reprezintă aproximativ a zecea parte din întregul efort de dezvoltare a depozitului de date şi este partea vizibilă pentru utilizatori. Trebuie avute în vedere şi tabelele create pentru a gestiona excepţii. Gestiunea volumelor mari de date  încărcarea înregistrărilor în tabelele dimensiune. Înregistrările din tabelele dimensiune se încarcă înainte de cele din tabelele de fapte pentru a se putea realiza integritatea referenţială. Cheia primară în tabela de fapte este în realitate o concatenare a cheilor din tabelele dimensiune cu care sunt în legătură. Stabilirea schemei depozitului de date. adică prezentarea paşilor şi a erorilor care au apărut în timpul fiecărui pas.40 - . Achiziţia şi instalarea interfeţelor de acces. . asigurarea calităţii datelor şi încărcare).  construirea indecşilor. Similar. În acest fel. precum şi a tabelelor cu valori agregate. 4. În acest sens. Acest lucru înseamnă că metadatele descriu conţinutul depozitului de date. Cheile din sistemele sursă sunt uneori nepotrivite ca şi chei pentru depozitul de date. însă sunt cazuri în care ar fi de preferat ca ele să fie încărcate în depozitul de date.  reindexările. dezvoltatorii pot descoperi o serie de probleme legate de funcţionarea interfeţelor. Dacă mai mult de 20% din date sunt incorecte şi doar 80% sunt încărcate în depozitul de date. utilizatorii finali vor lua decizii bazate pe o imagine incompletă. el trebuie să efectueze următoarele activităţi:  crearea tabelelor depozitului de date. indicând de unde provin datele originale şi documentând regulile care guvernează transformarea datelor. indecşii din tabelele cele mai importante trebuie refăcuţi pentru a creşte performanţa interogărilor. fiecare înregistrare referitoare la un client. După ce toate datele s-au încărcat cu succes. În sistemele sursă. Interfeţele DD folosesc metadatele şi pentru automatizarea unor etape din ciclul de viaţă al dezvoltării depozitului de date. 6. argumentând că datele inconsistente sunt generatoare de erori.  prezentarea unui sistem de control. Alte echipe preferă să încarce ambele categorii de date. Metadatele se definesc ca fiind date despre date. După încărcarea valorilor atomice în depozitul de date. cu condiţia ca datele inconsistente să fie marcate distinct. astfel încât apare necesitatea generării lor în timpul procesului de încărcare. Schema fizică a depozitului de date se implementează prin crearea efectivă a tuturor tabelelor de fapte şi de dimensiuni. se efectuează activităţile care urmează. aceste entităţi trebuie identificate în depozitul de date tot printr-o cheie.

Gestiunea volumelor mari de date Construirea rapoartelor şi a interogărilor predefinite.utilizatorul obişnuit al depozitului de date are drepturi de vizualizare şi interogare asupra tabelelor din depozitul de date. care sunt responsabili de realizarea componentelor depozitului de date. iar schema depozitului şi metadatele au fost proiectate în întregime. Trebuie avut însă în vedere că utilizatorii diferiţi au cerinţe diferite. În sistemul de gestiune a depozitului de date. Construirea rapoartelor dinamice şi a interogărilor ad-hoc. Un avantaj important al soluţiei informatice cu depozite de date este acela că rezultatele de ieşire pot fi atât statice (predefinite). Instruirea trebuie efectuată pentru acei utilizatori care vor avea contact cu funcţionalităţile depozitului de date. De multe ori în procesul decizional este nevoie de situaţii de ieşire dinamice. astfel încât echipa de dezvoltare trebuie să selecteze varianta optimă. Aria de cuprindere a instruirii utilizatorilor. trebuie neapărat definite roluri şi profiluri de utilizatori pentru a stabili corect drepturile de acces. Utilizatorii vor fi informaţi cu privire la intervalul de încărcare a datelor şi la datele care vor fi încărcate. Instruirea trebuie să evidenţieze clar ce poate şi ce nu poate să facă depozitul de date.acest rol este atribuit pentru utilizatorii care trebuie să poată efectua orice fel de operaţii pe depozitul de date. Cel puţin două activităţi sunt necesare în acest sens: aria de cuprindere a instruirii utilizatorilor şi instruirea categoriilor de utilizatori. ci mai degrabă se poate apela la varianta bazelor de date. datele din depozit se împrospătează prin încărcare. Un utilizator care are acest rol poate crea noi obiecte în interiorul DD. 7. Dacă utilizatorii au nevoie pentru analize. de datele cele mai recente. Stabilirea profilurilor utilizator. de către utilizatori în orele de serviciu din timpul zilei şi de aceea el se încarcă de obicei noaptea sau la sfârşitul săptămânii.acest rol se atribuie membrilor din echipa de dezvoltare. Utilizatorii vor fi informaţi cum să obţină diverse informaţii despre folosirea depozitului de date. de regulă. Echipa de dezvoltare trebuie să includă în sistem această facilitate prin utilizarea unor interfeţe software adecvate. Dacă numărul lor este mare. Utilizatorii trebuie să înveţe cum să folosească fiecare opţiune în parte. Utilizatorii au aşteptări diferite în ceea ce priveşte depozitul de date şi de aceea instruirea trebuie să înceapă neapărat cu definirea DD. Încărcarea efectivă a depozitului de date se poate efectua doar după ce s-au populat tabelele care rezultă din procesul de extragere şi transformare a datelor.  administrator . 8. Se recomandă ca la început să se meargă pe varianta încărcărilor parţiale pentru a putea estima timpul total necesar pentru această operaţiune.  folosirea interfeţelor.  dezvoltator .  alte informaţii. Interfeţele au diverse opţiuni legate de rapoarte şi interogări. atunci ei pot fi împărţiţi în două grupuri – . Încărcarea depozitului de date La anumite intervale de timp. Instruirea categoriilor de utilizatori. Depozitul de date este folosit. atunci depozitul de date nu este soluţia ideală. cât şi dinamice (flexibile). instantanee. Instruirea trebuie să aibă în vedere toţi utilizatorii care vor intra în contact cu depozitul de date şi trebuie acoperite următoarele aspecte:  definirea depozitului de date. Nu sunt permise actualizări.  aria de cuprindere a depozitului de date.41 - . Instruirea utilizatorilor Instruirea privind depozitul de date care va fi implementat în întreprindere este absolut necesară pentru toţi utilizatorii. Se recomandă definirea cel puţin a următoarelor roluri:  utilizator .  intervalul de încărcare. Prototipul dezvoltat iniţial este rafinat în timpul dezvoltării depozitului de date prin încorporarea unor elemente furnizate de reacţia utilizatorilor (feed-back) şi prin construirea unor rapoarte şi interogări predefinite de care au nevoie decidenţii. Toţi utilizatorii trebuie să aibă cunoştinţe legate de conţinutul depozitului de date.

avându-se în vedere următoarele aspecte:  interogările. adică întreţinerea şi dezvoltarea acestuia. utilizarea agregărilor stocate. Valorile acestor indicatori statistici trebuie determinate şi analizate pentru a monitoriza performantă şi gradul de utilizare a depozitului de date. 2. În timpul fiecărei încărcări a depozitului trebuie parcurse toate etapele procesului final (back-end): extragerea.  răspuns pe durate specificate. Eventualele discrepanţe sunt reţinute şi se vor efectua corecţiile care se impun. după încheierea programului de muncă. însă acest lucru depinde de mai multe aspecte: mărimea depozitului de date. Depozitul de date trebuie să fie capabil să furnizeze rapoarte pe intervalul specificat de utilizatori (zi. Acest lucru implică o serie de activităţi specifice. noaptea sau la sfârşit de săptămână. de regulă. evaluarea mărimii depozitului de date şi refacerea datelor în caz de accidente. adică în timp util. din sistemele sursă în depozitul de date pentru ca utilizatorii să poată beneficia de date reale. calcularea indicatorilor statistici referitori la depozitul de date. validarea rapoartelor generate din depozitul de date se face construind manual sau prin mecanismele existente acelaşi raport şi comparând cele două rezultate. De regulă. în mod periodic. Pentru a ameliora acest indicator se pot folosi valorile agregate precalculate. Testarea depozitului de date Pentru testarea depozitului de date vor fi instruiţi reprezentanţii utilizatorilor. de asemenea. b) Calcularea indicatorilor statistici referitori la depozitul de date Evoluţia şi întreţinerea depozitului de date poate fi urmărită prin intermediul indicatorilor statistici.  numărul de interogări efectuate într-o zi exprimă numărul de interogări efectuate asupra datelor din depozit şi poate fi calculat pe diferite niveluri de complexitate şi detaliere. deoarece utilizatorii nu vor putea testa corect depozitul de date până când nu sunt instruiţi cu privire la conţinutul acestuia şi la regulile de utilizare.4. transformarea. săptămână. atunci când sistemele operaţionale nu sunt folosite. Utilizatorii vor testa corectitudinea rapoartelor şi interogărilor obţinute din depozitul de date. Echipa trebuie să aibă în vedere şi varianta ca eroarea să provină din sistemul manual de obţinere a raportului.42 - . Acest lucru este în legătură directă cu structura dimensiunii ierarhiei timp. Utilizatorul va dori ca interogarea lansată asupra depozitului de date să se execute instantaneu. lună. Numărul de interogări efectuate asupra tabelelor care conţin valori agregate indică. a) Încărcarea periodică a depozitului de date Date noi trebuie încărcate.  performanţa. Instruirea este de fapt pasul premergător testării. Pot fi stabilite anumite criterii de acceptare înainte de începerea implementării. asigurarea calităţii şi încărcarea efectivă a datelor. derulate în momente diferite de timp: încărcarea periodică a depozitului de date. Gestiunea volumelor mari de date începători şi avansaţi. iar acceptul va fi obţinut dacă sunt îndeplinite aceste criterii. numărul de utilizatori. Operaţia de încărcare a datelor se desfăşoară. . Câţiva dintre indicatorii statistici mai des folosiţi sunt prezentaţi în continuare. menţinerea calităţii datelor. Documentele privind acceptanţa depozitului de date sunt semnate doar după ce testele s-au terminat cu succes şi utilizatorii s-au declarat mulţumiţi de acesta. performanţele reţelei de calculatoare. Exploatarea depozitelor de date Activităţii de implementare a depozitului de date îi urmează cea de exploatare. Încărcarea depozitului cu date noi presupune şi necesitatea calculării şi populării tabelelor de agregări cu noi înregistrări. 9. trimestru. an).

Gestiunea volumelor mari de date  timpul mediu de răspuns la interogări exprimă timpul necesar pentru a obţine rezultatul. Ori de câte ori este posibil. numărul de înregistrări din fiecare colecţie de date. iar gestiunea creşterii volumului de date va căpăta o importanţă deosebită.  frecvenţa utilizării evidenţiază numărul de accesări ale depozitului de date de către un utilizator într-o anumită perioadă de timp. dar pe măsura trecerii timpului acesta poate creşte cu fiecare nouă operaţie de încărcare. iar deciziile care se iau pe baza lor pot fi eronate. în special dacă datele sunt folosite doar la nivelurile de sinteză. săptămâna din lună etc. În prima abordare. în care numărul de interogări este mai mare. Astfel se scot în evidenţă momentele şi perioadele de timp în care depozitul de date este mai utilizat şi mai puţin utilizat.  numărul zilnic de utilizatori indică numărul de utilizatori care folosesc în fiecare zi. trebuie să se meargă pe varianta corectării datelor în sistemele operaţionale. precum şi subiectele care nu prezintă interes şi care pot fi eliminate. Deşi această abordare permite încărcarea DD cu toate datele din sistemele operaţionale. Folosirea agregărilor stocate reduce semnificativ spaţiul de memorare a datelor. ştergerea datelor nefolosite.  durata medie a sesiunii de lucru exprimă perioada medie de timp în care utilizatorul rămâne conectat la depozitul de date. ar trece prea mult timp până ce s-ar efectua o nouă încărcare a DD. De asemenea. Două alternative referitoare la calitatea datelor trebuie luate în considerare: încărcarea în depozitul de date numai a datelor corecte sau încărcarea tuturor datelor şi efectuarea ulterioară a corecţiilor. Deoarece erorile necesită mult timp pentru a fi identificate şi corectate.  intervalele de utilizare maximă a depozitului de date au în vedere perioada din zi. după fiecare încărcare a depozitului de date. din momentul în care a fost lansată interogarea în execuţie. d) Evaluarea mărimii depozitului de date Încărcarea iniţială a depozitului de date poate să nu ridice probleme referitoare la capacitatea de stocare. care sunt cele mai slab vândute produse?) nu vor fi relevante în cazul în care depozitul de date este incomplet. Datele analitice pot fi şterse sau arhivate după . pentru a obţine rata de creştere a depozitului de date. în cazul în care există încorporat un sistem pentru aşa ceva. calitatea datelor poate fi necorespunzătoare. pot lua decizii bine fundamentate. efectiv facilităţile oferite de depozitul de date. rezultatele multor interogări (de exemplu: care sunt primii 100 clienţi ?.43 - . c) Menţinerea calităţii datelor Indicatorii privind calitatea datelor trebuie să preocupe organizaţia şi după implementarea depozitului de date. A doua abordare presupune ca toate datele să fie încărcate în depozitul de date. Problema principală constă în modul în care sunt tratate erorile care apar în legătură cu funcţionarea depozitului de date. limitarea perioadei de timp. ziua din săptămână.  interogările arată care subiecte din depozitul de date sunt cele mai folosite de către utilizatori.  numărul de utilizatori indică numărul total de utilizatori care au acces la datele conţinute în depozitul de date.  numărul de excepţii pe zi caracterizează numărul de atenţionări şi de erori generate de depozitul de date. dar sunt definite şi implementate mecanisme pentru identificarea şi corectarea erorilor. astfel încât la următoarea încărcare a depozitului de date utilizatorii să beneficieze de avantajul datelor corecte. În felul acesta utilizatorii sunt siguri că depozitul de date conţine numai date corecte şi.  mărimea depozitului de date exprimă. ca atare. Există câteva modalităţi clasice de gestionare a creşterii volumului datelor: agregările stocate. putându-se lua măsuri pentru optimizarea acestor zone. doar datele care sunt corecte sunt încărcate în depozitul de date. indicând astfel gradul în care DD sprijină utilizatorul în activităţile zilnice.

fără a avea posibilităţi de analiză a acestora. Pe măsura trecerii timpului. Gestiunea volumelor mari de date ce au fost create valorile agregate.5. pot fi identificate datele care nu sunt folosite de către utilizatori şi astfel se poate proceda la ştergerea lor. Anumite incidente pot necesita reinstalarea sistemelor de operare şi a sistemelor de gestiune a bazelor de date.  scalabilitate şi mentenanţă – depozitele trebuie să poată fi redimensionate în funcţie de structura şi de mediul de afaceri fără a pierde însă din performanţă.  integrarea datelor – sursele de date ale depozitului de date trebuie să fie multiple şi variate.riscurile acestei etape sunt legate de cele precizate anterior. adică o limitare a perioadei de stocare a datelor. Cel mai eficient mod de a realiza acest lucru este prin obţinerea unui mod de abordare structurat care să uşureze studiul acestor factori. se poate face un compromis referitor la perioada de timp pentru care un anumit set de date este păstrat în depozit. Alegerea tipului de depozit de date şi a modalităţii de realizare este deosebit de importantă. legislaţie. Astfel se pot identifica o serie de riscuri care pot apărea pe parcursul etapelor următoare:  analiza datelor . Prin folosirea rezultatelor indicatorilor statistici referitori la depozitul de date. referitoare la evoluţia pieţei. realizarea în grabă sau incorect a modelului metadatelor. dar trebuie avut în vedere faptul că odată şterse. concurenţă. 2.44 - . bazate atât pe date interne rezultate din procesul operaţional cât şi pe date externe organizaţiei. tot mai mulţi utilizatori din organizaţie vor deveni dependenţi de conţinutul depozitului de date şi astfel recuperarea datelor capătă o importanţă deosebită. fără analiza şi documentarea . nu se pot obţine detalieri ale agregărilor. nepracticabil pentru analize decizionale. organizate şi integrate haotic. Analiza multidimensională este de asemenea importantă.  analiza metadatelor .  suport pentru sistemele de Inteligenţa Afacerii – depozitul de date trebuie să permită extragerea datelor în vederea realizării analizelor multidimensionale de tip OLAP şi a extragerii de cunoştinţe din date (data mining). Procedurile de recuperare trebuie să prevadă toate situaţiile neplăcute care pot apărea în acest sens. relaţii cu alte organizaţii. acest fapt ducând automat la eşecul sistemelor de Inteligenţa Afacerii pentru care depozitul este proiectat. e) Refacerea datelor în caz de accidente La fel ca şi în cazul bazelor de date.principalul risc este acela de a realiza o colecţie de date. Pe parcursul etapelor de realizare este necesar să se ţină cont de varietatea factorilor ce pot afecta în vreun fel reuşita unui depozit de date pentru a asigura un risc minim de eşec. Din acest motiv s-au impus anumite criterii de evaluare a depozitelor de date:  performanţa – depinde de dimensiunile depozitului de date şi vizează realizarea de analize complexe într-un timp cât mai scurt. Deşi utilizatorii ar vrea ca depozitul să stocheze datele permanent. fiind necesară stabilirea corectă a dimensiunilor implicate. administratorii depozitului de date trebuie să acorde importantă sistemelor de recuperare a datelor în caz de accidente. Modelul logic al datelor la nivelul organizaţiei nu trebuie realizat prin adunarea sau „cârpirea” schemelor existente pentru că va rezulta un sistem rigid. Criterii de evaluare a depozitelor de date Activităţile complexe şi resursele costisitoare implicate în realizarea depozitelor de date şi a sistemelor de Inteligenţa Afacerii pentru care acestea sunt destinate impun satisfacerea unor criterii minime de performanţă şi asigurarea unui suport decizional corespunzător. precum şi reîncărcarea depozitului de date şi popularea tabelelor care conţin agregări.

Instrumente şi medii de dezvoltare utilizate pentru realizarea depozitelor de date Pentru asistarea activităţilor desfăşurate la realizarea depozitelor de date se pot utiliza o serie de instrumente şi medii de dezvoltare puse la dispoziţie de companiile producătoare de software. fişiere text etc. Microsoft SQL Server. Oracle. însă din punctul de vedere al surselor de date şi al complexităţii transformărilor realizate aceste componente sunt încă inferioare utilitarului corespondent din Oracle Warehouse Builder. prin achiziţia în anul 2007 a companiei franceze Business Objects care a realizat suita cu acelaşi nume destinată dezvoltării de soluţii de Inteligenţa Afacerii. pentru aplicarea funcţiilor de analiză şi pentru integrarea cu tehnologiile de Inteligenţa Afacerii.  implementarea procesului ETI . a depozitelor virtuale în Discoverer Administrator şi culminând cu Oracle Warehouse Builder. FoxPro.realizarea incorectă a modelelor utilizate (de exemplu modelarea multidimensională prin diagrame entitate-asociere). 2. instrument care susţine întreg ciclul de dezvoltare. .45 - .etapa finală a procesului de extragere. Nerealizarea acestora va face imposibilă administrarea ulterioară şi extinderea depozitului.  realizarea depozitului metadatelor . Compania IBM pune la dispoziţia utilizatorilor un mediu complet de realizare a depozitelor de date prin suita InfoSphere Warehouse care conţine instrumente pentru planificarea. transformare şi încărcare trebuie să încorporeze şi elemente de performanţă.  proiectarea procesului ETI . ce date se vor stoca agregat şi la ce nivel. obiectele să fie realizate uniform şi descrise corespunzător. DB2. fără a fi însă detaliate. iar managementul datelor şi al metadatelor se realizează cu Enterprise Manager şi Analysis Manager. Instrumentele Oracle pentru construirea depozitelor de date cât şi pentru managementul lor sunt variate începând cu un nivel general în Enterprise Manager Console. oferă mediul de dezvoltare Universe Designer care permite construirea universurilor. Compania SAP. exploatarea DD. Câteva dintre acestea sunt identificate în această secţiune. de securitate a datelor va afecta performanţele depozitului. implementarea.  proiectarea datelor .finalizarea construirii depozitului metadatelor şi instruirea corespunzătoare a personalului din punctul de vedere al administrării datelor sunt elementele principale în acest caz. Testarea procesului ETI trebuie să se realizeze riguros pentru a identifica la timp eventualele erori în transformarea datelor.proiectarea finală a metadatelor trebuie să ţină cont de flexibilitatea. Trebuie aleşi operatorii şi funcţiile aplicate pe fiecare modul în parte. transformare şi încărcare a datelor din surse variate: SAP.6. Gestiunea volumelor mari de date obiectelor din dicţionarul de date va face ca modificări şi extinderi ulterioare ale depozitului de date să fie extrem de greoaie. performanţa şi robusteţea depozitului. Un alt aspect este acela de a stabili corect structura datelor din depozit. neproiectarea unor algoritmi sau tehnici de optimizare. modelarea. transformare şi încărcare cu un grad mare de generalitate care doar să încarce datele în modulele destinaţie. Acestea reprezintă o viziune unitară asupra depozitelor de date şi permit modelarea multidimensională.un factor de risc principal este acela de a nu analiza calitatea datelor pe fiecare sursă/modul în parte şi de a proiecta un proces de extragere. Compania Microsoft oferă pentru construirea depozitelor de date instrumentul Microsoft SQL Server Analysis Services. trebuie stabilite intervalele de încărcare a datelor astfel încât să nu fie afectată funcţionarea sistemului sau a altor aplicaţii.  proiectarea metadatelor . ţinând cont în primul rând de scopul pentru care se vor încărca acele date. foi de calcul. Acesta reprezintă un instrument puternic de asistare a procesului de extragere. Componenta SQL Server Integration Services sau în variantele mai vechi componenta Data Transformation Services (DTS) susţin procesul ETI. în Analytic Workspace Manager.

.46 - . Eventualul succes al realizării depozitelor de date poate fi afectat de factori variaţi care trebuie identificaţi pe durata întregului proces de dezvoltare recomandându-se să fie orientat spre cerinţele de afaceri ale managementului şi spre satisfacerea suportului decizional. Gestiunea volumelor mari de date În concluzie. deşi metodologiile şi etapele de realizare ale depozitelor de date sunt cele clasice. scopul şi caracteristicile specifice ale depozitelor de date prezintă un set de probleme unice şi dificile care trebuie analizate şi depăşite.

Botha I.. 5.Modeling multidimensional databases. . Watson H. Lungu I.. Hawaii. Inc. Reading. March.H.. Botha I. 5. 1998 [KIMB96] Kimball R. Reeves L. . Velicanu M. editura ASE.... Bâra A – Sisteme informatice executive. 1997 [DIBO08] Diaconiţa V.. [LUBA07] Lungu I. Vassiliadis P.A.Data mart does not equal data warehouse.The Data Warehouse Toolkit. Quix C. Italy. [DEVL97] Devlin.The data Warehouse Lifecycle Toolkit.. Maio D. cross-tabs and sub-totals. – Decision Support in the Data Warehouse.. Diaconiţa V. 2000 [INMO96] Inmon. ISSN: 1709-0832. Jeusfeld M.. . 1998. 1996 [KIRE98] Kimball R... . Oracle Magazine. Mass. . .Conceptual design of data warehouses from E/R schemes. WSEAS Transactions on Information Science and Applications. Pisa... .. B. 13th International Conference on Data Engineering. vol. Sarawagi S. Gestiunea volumelor mari de date BIBLIOGRAFIE [AGGU97] Agrawal R.Architecture and quality in data warehouses. [GOMA98] Golfarelli M. XXII. Mai 2008 [ERIC08] Erickson J.. of the 12th International Conference of Data Engineering. – Improving query performance in virtual data warehouses. ISSN: 1709- 0832. Proceedings CaiSE 98. Velicanu M. Thornthwaite W. Bosworth A. numărul 5. Proceeding of HICSS-31. 1998. W. Gupta A. Revista WSEAS Transactions on Information Science and Applications. Reading. 1996 [GRWA98] Gray P. [HOLL00] Holland. Bâra A. New York. Addison Wesley Longman. M. pp. ISSUE 6.Data Cube: A relational aggregation operator generalizing group by. . vol. John Wiley & Sons.. .. Layan A. P. November/December 2008. 806-815.47 - .. Mai 2008.Data Warehousing gets extreme. . B.. Pirahesh H. New York.Data Warehouse – from Architecture to Implementation. 2007 . DM Direct Newsletter. 1997 [ANDE97] Anahory S. 1999 [JAJE98] Jarke M. Ross M. John Wiley&Sons.. New York. Lungu I. John Wiley & Sons. November. Rizzi S. nr.Building the Data Warehouse.. Dennis.. 1998 [GRBO96] Gray J. .Data Warehousing in the Real World. – Two integration flavors in public institutions. Prentice Hall. White Paper. Mass. 1997 [BALU08] Bâra A.Traditional data warehouses vs virtual data warehouses. volumul 5. 1996 [INMO99] Inmon.. Addison Wesley Longman.Proc.

– Tehnologia Inteligenţa Afacerii. 2007 [VEMA10] Velicanu M.olapcouncil. http://dssresources. – Building a data warehouse step by step. LNCS 1873. 2007 [VEMA07b] Velicanu M. ISSN 1453-1305. ed. . 2009. Lungu I. [VEMA07] Velicanu M.Decision Support Systems: Concepts and Resources. nr. Londra.. 3/2008. Revista Informatica Economica nr.a. Matei Gh. 18 (88)..org. pag. Editura ASE Bucureşti.. IA: DSSresources. Gestiunea volumelor mari de date [OLAP95] The OLAP Council Definitions. ISBN 978-606-505-217-8. Revista Informatica Economică nr 3/2007 (43). www. Matei Gh. Matei Gh. 2000 [VELU09] Velicanu M.J. . Cedar Falls. Revista Informatica Economică nr 2/2007. ISSN 1453-1305. ş. – A few implementation solutions for Business Intelligence. ianuarie 1995 [POWE00] Power D. 83-89. ISSN 1453-1305. ISBN 978-606-505-311-3. – Sisteme de baze de date evoluate.– Database vs Data Warehouse. 2000 [TEST00] Teste O. ASE. Matei Gh. [VEMA07a] Velicanu M.com/dssbook. Dexa 2000. pag. Revista Computerworld România.48 - . 21 Octombrie 1997 . data marts şi data mining. – Data warehouses.Towards Conceptual Multidimensional Design in DecisionSupport Systems..com.. 2010 [VILA97] Vilan A. 91-95.