Definiţia depozitului de date, accentuând contrastul între sistemul operaţional şi cel informaţional, ne-ar putea sugera niste imagini de genul următor: Sistemul operaţional seamănă cu ringul unei burse, cu o mulţime de brokeri agitându-se în jurul calculatoarelor, a panourilor de afisare, făcîndu-şi semne neinteligibile între ei, răcnind la telefoane, smulgând nerăbdători hârtiile din faxuri etc. Dimpotrivă, depozitul de date este un spaţiu liniştit, respirând atmosfera serenă a unei biblioteci.

De fapt, lucrurile nu stau chiar aşa. Depozitul de date are şi el dinamica lui, chiar dacă nu atât de agitată ca cea a sistemului operaţional. Pentru a exprima această dinamică se foloseşte adesea termenul "data warehousing", iar pentru a o descrie se recurge la cele cinci fluxuri informaţionale identificate de Richard Hackathorn.

Înţelegerea modului în care aceste fluxuri acţionează este cheia succesului construcţiei şi utilizării unui depozit de date.

In-flow

Acesta este fluxul de intrare a datelor în depozit. Datele provin din sistemul operaţional precum şi din surse externe. Actualizarea depozitului de date nu trebuie să afecteze datele existente. Nimic nu se şterge, nimic nu se suprascrie. Este vorba doar despre adăugarea unui nou "strat" de date. Actualizarea se face de regulă în loturi (batch), la intervale regulate, dar anumite cerinţe pot impune o actualizare în flux continuu, reflectând actualizări în sistemul operaţional. De exemplu, o bancă ar putea să dorească să păstreze un istoric al tuturor operaţiunilor efectuate asupra unui cont sau ar putea să se mulţumească cu balanţe periodice (de pildă la sfârşitul fiecărei zile).

Pentru datele provenind din aplicaţiile tranzactionale se pune în primul rând problema selectării şi extragerii. Instrumentele folosite în acest scop trebuie să fie capabile să exploateze la maximum middleware-ul disponibil pentru a accede la toate datele şi să poată să realizeze conversiile implicite la "transbordarea" între diverse platforme.

Dar acesta este abia începutul poveştii, deoarece datele trebuie să treacă printr-un proces complex de consolidare. Acest proces implică:

• eliminarea datelor nerelevante (a căror semnificaţie se leagă de procesul tranzacţional, cum ar fi de pildă numărul poziţiei din factură);

• conversia la codificări şi reprezentări unitare (conform unor convenţii clar stabilite de administraţia depozitului);

• curăţirea datelor (prin eliminarea inconsistenţelor, şi reconstituirea datelor parţial distruse, completarea informaţiilor lipsă cu valori implicite etc);

• reorganizarea datelor (adăugarea informaţiilor temporale unde este cazul, denormalizare şi rearanjare după subiecte etc).

În afară de datele provenite din sistemul operaţional, o cerinţă tot mai actuală o reprezintă consolidarea şi integrarea în depozitul de date a datelor provenind din alte surse. Printre acestea se remarcă datele non-relaţionale cum ar fi texte, e-mail, foi de calcul, imagini, obiecte multimedia, baze de date geografice, chiar şi reguli comerciale (business rules). De asemenea, alte surse de date externe pot fi sistemele operaţionale ale partenerilor de afaceri, bazele de date publice sau informaţiile furnizate pe bază de abonament (cotaţii bursiere, buletine meteorologice etc).

Up-flow

Prin procesul de intrare în depozitul informaţional, datele capătă un plus de claritate şi de semnificaţie. Dar odată ajunse în Data Warehouse ele nu rămân în acest stadiu, ci se îmbogăţesc în continuare printr-o serie de alte transformări. Aceste procese sunt numite în mod generic up-flow şi au rolul de a adăuga valoare informaţională datelor colectate.

Principalele procedee utilizate în acest scop sunt:

• Sumarizare. Datele intră în depozit la nivel de detaliu. Cu toate că instrumentele de analiză pot aplica funcţii de agregare, pentru optimizarea accesului la astfel de informaţii de sinteză anumite astfel de operaţii sunt realizate chiar de administraţia depozitului de informaţii. Sumarizarea se realizează pe baza dimensiunilor cele mai utilizate şi poate implica nu doar însumarea unor valori, ci şi medii, valori minime/maxime, sau valori obţinute prin procedee statistice complexe. Un exemplu simplu este sumarizarea pe axa timpului. Dacă granularitatea este, de pildă, la nivelul zilei, se pot precalcula totaluri săptămînale, lunare, trimestriale şi anuale. De asemenea se pot calcula medii, se pot determina zilele de minim sau maxim (pe lună, pe trimestru, etc), se pot calcula dispersii, etc. (vezi caseta Agregare şi sumarizare)

• Împachetare. Utilizarea informaţiei din depozit nu se face doar on-line. Pentru cea mai mare parte dintre nevoile informaţionale ale organizaţiei se utilizează sistemul abonamentelor: un anumit beneficiar (un funcţionar, un birou, un departament etc.) are nevoie de anumite informaţii, la un anume nivel de sumarizare, la anumite intervale de timp. Aceste informaţii pot fi livrate ca simple rapoarte, dar cel mai adesea ele trebuie livrate în formate care să permită beneficiarului să le utilizeze în continuare pentru analize, prezentări, raportări, etc. Cel mai adesea datele se furnizează ca foi de calcul, documente text, baze de date personale, eventual grafice, animaţii etc., toate într-un format propriu utilizatorului. De pildă datele pot fi plasate în multiple file de calcul tabelar, în diverse nivele de detaliere, continând eventual şi prezentări grafice.

• Distribuire. De cele mai multe ori, diverse grupuri de utilizatori sunt interesate doar de anumite categorii de date, astfel încît pentru a creşte disponibilitatea informaţiilor se realizează nişte mici depozite departamentale, conţinând replici parţiale (cuprinzând doar datele de interes specific) ale depozitului central. Altă situaţie frecventă este când repartizarea teritorială a organizaţiei impune multiplicarea depozitului de date în mai multe locuri (de pildă replicarea integrală sau parţială la filialele din teritoriu). Pe măsură ce tehnologiile de stocare şi procesare distribuită se maturizează, arhitectura centralizată a depozitelor de informatii va fi înlocuită de o arhitectură distribuită.

Down-flow

Acest flux se referă la administrarea datelor şi este destinat să menţină "vitalitatea" depozitului de date. Datorită faptului că se lucrează cu volume imense de date (de regulă peste 500 GB), se impune o ierarhizare a priorităţii datelor în funcţie de gradul lor de utilizare. În general, datele vechi nu se mai consultă la nivel de detaliu: foarte rare sunt cazurile în care cineva este interesat de numărul de bucăţi dintr-un anumit produs vândute într-o anumită zi a anului 1991 la un anumit magazin. Aceste date vor fi transferate pe un suport mai lent (discuri optice, bandă magnetică, etc), păstrînd la nivelele de prioritate înaltă doar anumite nivele de sumarizare.

În esentă, acest flux trebuie să asigure că nici o informaţie importantă nu se pierde şi totodată că informaţiile mai puţin actuale sau mai puţin importante nu blochează în mod inutil canalele de comunicaţie şi mediile de stocare cu acces rapid.

Out-flow

Ieşirea datelor spre utilizatori reprezintă asa-numitul out-flow. Prin această deschidere, valoarea informaţională creată prin data warehousing devine disponibilă pentru întreaga organizaţie, oferind un substanţial suport pentru conducerea optimă a activităţii. Ca şi în cazul fluxul de intrare, fluxul de ieşire este posibil doar cu suportul unui middleware funcţional. Spre deosebire de in-flow, unde legătura se făcea mai ales către bazele de date ale sistemului tranzacţional, în acest caz middleware-ul trebuie să vizeze staţiile de lucru ale clienţilor. Out-flow reprezintă "tejgheaua" depozitului de date.

Există două activităţi principale care formează acest flux:

• Accesarea datelor. Această activitate se caracterizează prin faptul că iniţiativa aparţine clientului, care solicită informaţiile de care are nevoie. Cererile de acces la date pot fi de natură ocazională (interogări ad-hoc), de rutină (zilnice, săptămânale, etc) sau, în unele cazuri, chiar în timp-real (continue).

• Livrarea datelor. În acest caz, iniţiativa aparţine depozitului de date, care trimite din proprie iniţiativă anumite date către anumiţi clienţi. Data Warehouse face publice diverse obiecte (business objects) care sunt actualizate periodic iar clienţii pot să-şi aleagă seturile de obiecte care le sunt cele mai utile şi să le primească automat. Acestea sunt de regulă împachetate în formate uzuale şi pot fi reflectate automat în documente (prin legături dinamice de gen publish/subscribe sau DDE).

Deciziile luate pe baza analizei economice facilitate de informaţia din depozitul de date se vor concretiza în operaţii economice, consemnate prin tranzacţii în sistemul operativ, care la rândul lui va crea viitoarele date de intrare în depozitul de date. Uneori influenţa deciziilor poate fi estimată sau măsurată tot prin instrumente de analiză. La modul teoretic măcar, putem considera că acest flux este conectat la fluxul de intrare, procesul decizional formând un cerc închis.

Meta-flow

Metadatele, fiind date despre date, descriu structura şi conţinutul depozitului de date. Dar cum structura şi conţinutul au la rândul lor o dinamică, exprimată prin cele patru fluxuri descrise până acum, rezultă că există şi o dinamică a metadatelor. În principiu, acest meta-flow descrie şi conectează cele patru fluxuri, fiind un meta-model al dinamicii depozitului de date.

Depozitul de date nu este o aplicaţie care să poată fi cumpărată "de gata". Mai mult, ea nu este proiectată odată pentru totdeauna. Adaptabilitatea sistemului operaţional la conditiile mereu noi ale activităţii impune o adaptabilitate corespunzătoare a sistemului informaţional. Dacă apar schimbări în aplicaţiile organizaţiei, ele trebuie să se reflecte în definiţiile procedurilor de intrare asfel încît să nu afecteze ieşirile. De asemenea, schimbările în cerinţele utilizatorilor trebuie să poată fi rezolvate prin adaptarea corespunzătoare a fluxurilor interne.

Există două aspecte importante legate de meta-flow. Primul este faptul că, aşa cum uşor se poate deduce, este instrumentul principal de administrare a depozitului de date. Cum acest depozit este de fapt puntea dintre datele brute şi instrumentele de analiză, o bună proiectare a acestui flux trebuie să asigure imunitatea fiecărui subsistem în parte la schimbări intervenite în celelalte.

Al doilea aspect este faptul că meta-flow înseamnă de fapt modelare, atât a sistemului informatic, cât şi a activităţii de ansamblu. Ispita perfecţiunii ne-ar putea îndemna să începem proiectarea unui Information Warehouse cu modelarea activităţii întregii organizaţii şi a sistemului informatic. Probabil că dintre toate abordările posibile, aceasta este cea mai păguboasă: practic, nu există şanse de a termina vreodată (cu atât mai puţin în timp util...) o astfel de analiză. Adevărata provocare a proiectării şi administrării unui depozit de date este de a obţine rezultate imediate şi de a permite o evoluţie continuă a sistemului, prin îmbunătăţiri succesive. Iar cheia succesului în această direcţie o reprezintă dinamica metadatelor.

Găuri negre?

Concluzia ar putea fi că nu ajunge ca depozitul de date să existe, el trebuie să şi funcţioneze. Să funcţioneze corect, adică să poarte informaţia portivită către omul potrivit, în forma potrivită. Altfel el nu va reprezenta decât încă o gaură neagră în care datele dispar şi nimeni nu le va mai vedea niciodată.