Gestiunea Depozitelor de Date. Aplicatii Si Tehnologii Folosite

BUCHAREST

February 2011

Table of Contents

1. Introducere

Statisticile ultimilor ani arată o imensă avalanșă de date existentă în lume, 90% dintre acestea fiind generate în ultimii doi ani. În fiecare zi este creat un volum de date foarte mare, volum care a ajuns la 2,5 exabytes, iar la fiecare 40 de luni, acest număr se dublează (fiecare secundă aduce cu ea mai multe date decât existau în tot Internetul acum 20 de ani). Marile companii, în speță, cele științifice, lucrează cu volume enorme de informații. În ultimii ani, companiile au fost „obligate” să asculte de nevoile curente ale oamenilor mereu pe fugă, oferindu-le acestora servicii diverse și mult mai personalizate. Estimările arată că fiecare organizație va crește volumul de date produse cu 53% în următoarele 18 luni (de la 194 terabytes la 296.7 terabytes). Mediile care contribuie la această creștere, în special, sunt bazele de clienți, documentele word precum și email-urile. De exemplu, compania Walmart colecționează în jur de 2.5 petabytes de date în fiecare oră, totul din tranzacțiile clienților săi. De asemenea, este probabil ca un magazin să știe ce vânzări va avea într-o anumită zi, înainte de a înregistra cumpărăturile. Acest lucru este posibil, deoarece toate datele generate de activitățile clienților sunt analizate foarte bine de către specialiștii în domeniu. Ele sunt generate cu o viteza uluitoare, iar volumul lor depășește orice posibilă predicție.

Fiind tot mai folosit, Internetul a devenit în ultimii ani o sursă indispensabilă. Majoritatea oamenilor îl folosesc în diverse scopuri, astfel că Internetul este cel mai mare dezvăluitor al tiparelor comportamentului uman. Anumite tehnici de corelare pot analiza datele stocate de o anume companie din care pot deduce sau preconiza comportamente, condiții și evenimente. În ziua de astăzi, o companie preocupată de creștere și eficiență poate să studieze comportamentul clienților săi în fiecare minut din fiecare zi. Concluziile formulate au un rol foarte important, deoarece stau la baza deciziilor de strategie care se vor lua în interiorul companiei. Livrarea de produse și servicii poate fi făcută la un grad înalt al profesionalismului, atent și rapid, cu o filtrare minuțioasă prin imensitatea de date.

În condițiile în care cea mai importantă cerință a oricărui sistem informatic este reprezentată de informarea într-o manieră eficientă a tuturor factorilor de decizie dintr-o companie, specialiștii consideră că în realizarea oricărui sistem informatic intervin două etape importante de calcul și anume: fundamentarea deciziilor și asistarea activităților curente din companie.

Sistemele vechi de gestiune a bazelor de date, care se ocupă de proiectarea tranzacțiilor curente, nu mai pot face față acestor noi cerințe, în primul rând din cauza faptului că nu au abilitatea de a reține date cu caracter istoric, date care sunt necesare în luarea de decizii manageriale, însă neimportante pentru derularea operațiunilor curente. În al doilea rând, aceste sisteme relativ vechi, sunt construite pentru înglobarea unor cantități mici de informație, în condițiile în care, pentru a putea face o analiză complexă și precisă a unei afaceri, este necesară o vedere globală asupra activităților desfășurate în întregime, iar acest lucru impune consultarea unei mase mari de informații.

Tehnologiile evoluate din ziua de astăzi au făcut ca acumularea unor volume imense de informații care sunt importante pentru ca activitatea să funcționeze si pentru a lua deciziile corecte, să nu mai reprezinte o problemă din punct de vedere tehnic. O problemă importantă care apare însă, este extragerea celor mai importante informații din multitudinea celor existente, relevante pentru o acțiune data, într-un mod eficient atât din punct de vedere temporal, cât și din punct de vedere al costului.

Astfel că, soluția care vine în sprijinul extragerii informației relevante dintr-o masă imensă de date, este aceea de a o structura în depozite de date – Data Warehouse – DW. Printre cerințele principale ale structurilor organizaționale moderne (întreprinderi, bănci, administrație etc.), se numără și aceea a depozitelor de date. Totodată, depozitele de date, reprezintă în companii o realitate tehnologică pusă în practică tot mai frecvent. META Group a efectuat în anul 1998 un sondaj conform căruia 90% dintre managerii participanți aveau în plan lansarea unor proiecte care să implementeze acest concept. Piața care folosește depozitele de date are o creștere anuală de aproximativ 35%.

Din punct de vedere istoric, părintele noțiunii de data warehouse este considerat William Inmon, el deținând chiar trademark-ul acestui termen. ” Viziunea sa despre depozitele de date se concentreaza asupra rolului acestora de baza informationala a deciziei manageriale, pastrând astfel un nivel înalt de generalitate. Un alt nume important este cel al lui Earl Hadden, cel care a enuntat, a fundamentat si a experimentat cu succes Revista Informatica Economica, nr. 2(26)/2003 47 metodologie riguroasa pentru implementarea rapida a depozitelor de date (90 day winners)”[1].

Din punct de vedere al aplicabilității, domeniul Data Warehousing-ului își găsește locul mai ales în sfera ariilor în care este foarte importantă relația cu publicul, ca de exemplu comerțul, idealul care se dorește atins fiind fidelizarea clienților.

Hipermarket-urile încearcă să păstreze o legătură strânsă cu clienții lor, astfel având o bază de date cu informații referitoare la aceștia. Strategia este ca preferințele clientului să fie știute, așa încât să se întoarcă cu plăcere în magazinul respectiv. În astfel de cazuri este foarte important să se realizeze un studiu de piață și o analiză a comportamentului clientului în raport cu ceea ce cumpără, deoarece întreg succesul afacerii depinde de aceste lucruri.

Și totuși există și domenii nerelaționate cu afacerile în care data warehousing-ul își găsește aplicabilitatea. În principiu, în orice proiect care are nevoie de o gestiune performantă, bazată pe criterii științifice, depozitele de date pot avea o anume contribuție. De exemplu, în Statele Unite ale Americii, instituțiile fiscale au construit un Data Warehouse, venind astfel în serviciul contribuabililor furnizându-le eficient informații despre statusul taxelor plătite sau pe care le mai au de plătit. Această idee a adus de la sine o serie întreagă de beneficii. Prin analiza modului în care contribuabilii își achită impozitele, profesioniștii în contabilitate pot identifica mult mai ușor fraudele. Determinarea eventualelor fraude este un domeniu de interes nu doar pentru fiscalitate. De pildă, marile corporații studiază informațiile angajaților care au comis acțiuni ilegale care au prejudiciat compania și astfel identifică șabloane de comportamente caracteristice pentru cei predispuși să acționeze fraudând.

Sub aspect economic, în unele cazuri s-a remarcat un profit de aproximativ 4 dolari pentru fiecare dolar investit într-un depozit de date. Este de la sine înțeles ca astfel de cazuri nu sunt neapărat majoritare, mai ales pentru faptul ca acest domeniu a cunoscut o expansiune mai mult în ultima vreme, însă pe măsură ce va câștiga popularitate, și fiecare organizație care lucrează cu volume foarte mari de date își va construi propriul depozit de date, atunci problema nu se mai pune din punct de vedere al câștigurilor, ci din prisma evitării/limitării pierderilor suferite. Odată ce tot mai multe companii vor începe să folosească această tehnologie, va fi destul de greu să facă față concurenței, pentru cele care nu adoptă această politică.

În altă ordine de idei, se poate spune că perspectiva tehnologică a ultimilor ani a atras cu sine puterea de calcul la prețuri accesibile. Există servere paralele care au micropocesoare ieftine și se compară la putere cu supercalculatoarele. Sistemele de gestiune a bazelor de date pot exploata la maxim arhitecturile hardware paralele, iar evoluția sistemelor deschise permite facil interoperabilitatea între platformele hardware/software. Unitățile magnetice și optice de stocare pot îngloba mase de ordinul giga sau chiar tera, iar interfețele grafice sunt prietenoase și ușor de înțeles, fiind accesibile utilizatorilor de rând, care nu au cunoștințe tehnice.

1.1 Motivație și structură

2. Data Warehouse – concept, analiză și integrarea datelor

Înainte de a explora procesul de proiectare a unui data warehouse, apare întrebarea ”Ce este de fapt un data warehouse în termeni largi?”. Din acest punct de vedere, un depozit de date poate fi considerat ca o modalitate centrală de stocare de informație din mai multe surse, pe care o gestionează și furnizează eficient și pe care o livrează mai multor audiențe, de obicei pentru a îndeplini cerințele de suport de decizie, precum și cele de business intelligence.

”De ce este nevoie de un depozit de date?, Care sunt pașii care trebuie îndepliniți pentru a proiecta un depozit de date?, Cum este folosit concret un depozit de date? Care este legatura dintre data warehousing, OLAP și data mining? ” sunt doar câteva dintre întrebările la care lucrarea prezentă încearcă să răspundă.

Conceptul de data warehousing este relativ simplu: informații extrase periodic din aplicații care suportă procesele business și copiate în computere special dedicate. Datele pot fi validate, reorganizate, restructurate și suplimentate cu informații din alte surse de date pentru a genera diferite rapoarte, analiza datelor etc. Datele pot proveni din informațiile din sistemul operațional, însă pot avea originea și în arhivă sau în alte surse externe ca de exemplu baze de date publice. De pildă, într-un depozit de date pot exista date statistice (provenind din institute specializate), date demografice (de exemplu în urma unui recensământ), date economice care se ocupă cu prognoza în diverse arii ale economiei, orientate pe studiul pieței, date obținute în urma unor sondaje de opinie etc. În principiu, aceste date pot fi de exemplu publice, gratuite, pot fi cumpărate sau pot fi preluate în funcție de politica celui care le furnizează (pe bază de abonament, de exemplu).

Definiția lui Inmon este una extreme de succintă: depozit de date este o colecție de date tematică, integrate, plasată într-un context temporal și permanent, destinată fundamentării deciziei manageriale. (”A data warehouse is a subject-oriented, integrated, time-variant and nonvolatile collection of data in support of management’s decision making process.” [1]).

Definiția lui Inmon este valabilă chiar și în ziua de astăzi la aproximativ 15 ani de la formularea ei, însă există uneori situații când aceasta nu este respectată întocmai. De exemplu, foarte multe dintre datele din depozitele de date din ziua de azi sunt volatile. În condițiile în care spațiul de stocare de care este nevoie, este imens, depozitul stochează doar un număr de perioade istorice. De exemplu, dacă managerul dorește să aibă acces la datele financiare și contabile din ultimii 2 ani, odată cu adăugarea datelor din ultima lună, datele corespunzătoare primei luni din serie (cea mai veche) sunt șterse automat.

Într-un sistem operațional colecțiile de date utilizate sunt focusate spre eficientizarea și siguranța în mod optim a procesării acestora, în schimb într-un depozit de date, organizarea acestora se face într-un mod care să asigure analizarea lor, în speță extragerea informației și a semnificației economice pe care o presupun.

2.1 Sisteme informaționale și sisteme operaționale

La baza conceptului de depozitare a datelor stă o idee foarte importantă și anume aceea că există două mari tipuri de sisteme de informație într-o organizație și anume sistemele informaționale și sistemele operaționale.

Așa cum spune și denumirea, sistemele operaționale au scopul de a ajuta angajații să opereze tranzacțiile curente din companie: înregistrare de comenzi, calculul și plata salariilor, înregistrări legate de contabilitate etc. Aceste sisteme constituie o foarte mare importanță pentru organizație, ele fiind primele care au dat sens obiectului informatizării. Încă de la începuturile tehnologiei informatizate, algoritmii și programele din spatele acestor sisteme de tip operațional au fost îmbunătățite continuu, iar astăzi ele sunt integrate complet în organizație. În ziua de astăzi, în condițiile în care avem de a face cu volume mari și foarte mari de date, majoritatea companiilor nu ar exista făra aceste sisteme operaționale și mai ales fără toate informațiile pe care aceste sisteme le înregistrează și operaționează.

Într-o structură organizațională, pe lângă sistemele operaționale, avem de a face cu o categorie de funcțiuni mult mai complexe care se ocupă cu planurile strategice, prognoza și managementul întreprinderii. De asemenea, aceste funcțiuni sunt foarte importante pentru ca organizația să supraviețuiască și ca ea să se dezvolte. Aspecte precum analiza financiară, planul de marketing sau studiul de piață au nevoie de asemenea de sisteme automatizate, computerizate. Aceste sisteme sunt diferite față de cele operaționale, în primul rând din prisma datelor de care au nevoie aceste sisteme pentru a funcționa.

În acest caz, avem de a face cu sisteme informaționale, care se ocupă cu gestiunea cunoștințelor în adevăratul sens al cuvântului.

Prin definiție, sistemele informaționale sunt sisteme al cărui scop este analiza datelor și luarea de decizii (de regulă importante referitoare la planul de viitor al companiei). Ele nu numai că au alt rol decât cele operaționale, ci și o cu totul altă dimensiune. În timp ce sistemele operaționale au de a face de obicei cu un singur domeniu (de pildă, gestiunea producției, a resurselor umane, departamentul financiar etc.), cele informaționale parcurg un număr mare de arii, lucrând cu mase foarte mari de date intercorelate. Conceptul de ”data warehousing” are în vedere mai ales sistemele informaționale, doar într-o măsură foarte mică lucrează și cu cele operaționale.

În literatura de specialitate anglo-saxonă, sistemele operaționale sunt denumite și ”business applications”, iar scopul lor este să asigure acțiunile zilnice și lunare ale operațiunilor întreprinderii. Atunci când aceste sisteme nu mai funcționează, nici activitatea organizației nu mai poate continua.

Sistemele informaționale mai sunt denumite în literatura de specialitate și ”about the business applications” și au scopul de a analiza toate activitățile unei companii în care acestea sunt utilizate. Evenimentele pe care le analizează și cu care lucrează sunt cele din istoric, cele din trecut, evenimente care ajută la luarea de decizii în viitor. Aceste evenimente din trecut au caracter predictiv, și pe baza acestor pot fi eliberate planuri strategice pentru întreprinderea activităților ulterioare în organizație. Dacă aceste sisteme încetează să mai funcționeze, activitatea companiei nu se oprește, însă, pe termen lung, competitivitatea sa va fi afectată, fiind diminuată.

Un sistem informațional optim are următoarele calități:

are abilitatea de a încărca informațiile din baza de date foarte rapid cu ajutorul sistemelor OLTP (Online Transaction Processing) sau a celor OSS (Operations Support Systems);

pot fi înglobate și înregistrate cantități foarte mari de date;

dacă se petrec defecțiuni, datele pot fi salvate și recuperate rapid;

utilizatorii au posiblitatea de a efectua un număr mare de interogări;

informația poate fi folosită la comun de către departamentele care lucrează cu ea;

importul și exportul datelor se realizează într-o manieră flexibilă;

analiza este de fapt un modul care permite realizarea unor grafice și diagrame corespunzătoare, de asemena tool-uri de editare de rapoarte, modelare statistică, procesare de text, instrumente de dezvoltare a aplicațiilor și multe altele.

2.2 Integritatea datelor

Un DW (Data Warehouse) are rolul de a asigura o imagine coerentă și clară cu privire la datele relative la activitatea unei companii și de a transpune aceste date în funcție de contextul în care acționează. Folosirea acestor date poate presupune extragerea unor rapoarte (la cerere, sau în funcție de o anumită periodicitate), extragerea unor informații care se doresc a fi utilizate de aplicații de genul programe de calcul tabelar, însă, cel mai mult sunt folosite de către aplicații specializate în analiză.

Instrumentele de analiză pot fi împărțite în două categorii:

– analiză on-line: OLAP – On Line Analytical Processing – reprezintă aplicații care se axează pe analiza multidimensională;

– instrumente pentru mineritul datelor: data mining – aplicații care se axează pe descoperirea unor modele semnificative în colecții de date.

Datele pe care le conține sistemul operațional al unei firme sunt relevante doar pentru momentul în care sunt accesate, ceea ce înseamnă ca putem afirma faptul că acest sistem reflectă de cele mai multe ori realitatea curentă, aflând-se într-o continuă expansiune. În general parcurge o perioadă cuprinsă între 60 și 100 de zile, după care, datele sunt arhivate, considerate fiind de domeniul trecutului. Ele nu mai prezintă interes din punct de vedere operațional.

La polul opus, atunci când se pune problema analizei economice, de fapt informațiile care sunt considerate de domeniul trecutului sunt cele mai importante, deoarece ele au caracter predictiv, reprezentând șablonul unei prognoze corecte.

Spre deosebire de sistemul operațional, un depozit de date poate parcurge o perioadă de până la aproximativ 5 ani, în unele cazuri chiar 10 ani, acest lucru depinzând de cerințele analizei precum și de relevanța informațiilor de analizat.

”Ce poate câștiga un analist business având un data warehouse?” este o întrebare pe care și-o pune orice firmă dorește să adopte o astfel de politică. În primul rând. Având un data warehouse poate furniza un avantaj competitiv prin prezentarea informației relevante de la care se poate măsura performanța și se pot face schimbări critice în spiritul câștigului în fața celorlalți competitori. În al doilea rând, un depozit de date poate spori productivitatea afacerii, deoarece are capabilitatea de a aduna foarte ușor și rapid informația care să descrie exact organizația. Pe de altă parte, un astfel de depozit de date ușurează relația dintre clienți și management deoarece furnizează o imagine consistentă asupra comportamentului clienților și articolelor de-a lungul întregilor linii ale business-ului, a tuturor departamentelor și locațiilor. În cele din urmă, un alt argument pentru care utilizarea unui data warehouse reprezintă un avantaj este faptul că se pot reduce costurile prin urmărirea trend-urilor, șabloanelor și excepțiilor de-a lungul diverselor perioade.

Pentru a construi un data warehouse este necesar să fie cunoscute nevoile afacerii și de asemenea să fie în prealabil proiectată analiza business-ului. Construirea unui sistem complex de informație poate fi văzută precum construcția unei clădiri complexe pentru care arhitectul și constructorul au viziuni diferite, deoarece și în acest caz realizarea poate fi văzută din perspective diferite de către proprietar și dezvoltator. Acest lucru ne conduce însă la faptul că proiectarea unui data warehouse chiar asta presupune și anume: atunci când este proiectat trebuie luate în considerare mai multe viziuni ca de exemplu viziunea top-down, viziunea sistemului informațional, a sursei de date etc.

Viziunea top – down permite selecția informației necesare și relevante pentru depozitul de date. Această informației se potrivește cu nevoile curente și/sau viitoare ale afacerii.

Viziunea sursei de date expune informația capturată, stocată și gestionată de către sistemul operațional. Această informație poate fi documentată la nivele variate de detalii și exactitate, de la tabele de surse de date individuale la tabele de surse de date integrate. Sursele de date sunt de obicei modelate de tehnicile tradiționale de modelare ca de exemplu modelul E-R sau instrumentele DASE.

Viziunea Data warehouse include de fapt tabele și tabelele de dimensiuni. Reprezintă informația care este stocată în interiorul depozitului, incluzând calculele totale precalculate, precum și informația privind sursele de date și timpul de origine adăugat în contextul istoric.

Per ansamblu, construcția unui depozit de date și totodata și utilizarea lui presupune un task dificil, deoarece sunt necesare cunoștințe de business, tehnice și de management. Sub aspectul cunoștințelor de business, proiectarea unui data warehouse implică înțelegerea felului în care sistemele stochează și gestionează datele, cum se pot construi procedee de extragere care să transfere datele de la sistemele operaționale la depozite și cum se poate realiza software-ul care sp mențină depozitul de date la curent cu informațiile sistemului operațional.

Orice tranzacție procesată în sistemul operațional presupune inserarea unei noi înregistrări, modificarea sau ștergerea altora etc. În cazul depozitelor de date lucrurile stau cu totul diferit, deoarece o astfel de dinamică nu există. Periodic are loc adăugarea unor informații extrase din sistemele operaționale, iar accesul la aceste date este doar pentru citire. La nivel de proiectare, această diferență este foarte importantă. O tranzacție încheiată cu succes trebuie obligatoriu să ducă baza de date dintr-o stare consistentă, într-o altă stare de asemenea consistentă, lucru care presupune ca menținerea integrității datelor să fie făcută de către mecanisme complexe, în special în cazul sistemelor concurențiale: mecanisme de salvare/restaurare/refacere, mecanisme de identificare a dead lock-urilor. Libertatea datelor poate fi făcută prin optimizarea accesului la acestea, denormalizare, sumarizare, statistici ale accesării, reorganizare dinamica etc.

Din punct de vedere operațional, datele sunt focusate pe aplicații, structura lor este orientată pentru a servi tranzacțiilor, spre deosebire de DW care este orientat pe subiectele cele mai importante ale procesului economic (clienți, produse, activități).

Un exemplu concret pentru a înțelege mai bine cele prezentate mai sus: atunci când un client realizează o comandă, în baza de date se vor înregistra date despre client, produsele sau serviciile pe care le-a comandat, informații despre livrare, transport, taxe de transport etc. Sistemul operațional se orientează către chei, așa încât să se păstreze principiul atomicității, adică baza de date să rămână consistentă. Din punct de vedere operativ, mai multe dintre datele înregistrate nu au nicio relevanță (numărul comenzii, de pildă). Astfel că, o consecință imediată a acestei focusări este reprezentată de redundanța datelor. Acest lucru reprezintă o altă diferență între sistemul operațional și depozitele de date, deoarece în sistemul operațional redundanța datelor este eliminată pentru a evita erorile de actualizare, pe când în DW redundanța este creată în mod indenționat, în ideea de a avea un acces în context mult mai ușor.

Într-un data warehouse datele sunt asigurate pentru a răspunde cerințelor întregii companii pentru diferite sectoare generând aceleași rezultate. Într-un sistem operațional datele sunt create la momente diferite de către echipe diferite, în moduri diverse, iar rezultatele obținute sunt de fapt un amalgam de date care nu poate fi folosit pentru analiză.

2.3 Data Warehouse la intersecția cu business intelligence (BI)

Conceptul de Inteligența Afacerii – IA (Business Intelligence – BI) este o tehnologie informatică ce privește organizarea și funcționarea întreprinderii, precum și a conducerii acesteia, având ca suport soluțiile informatice.

În practica sistemelor de baze de date, există astfel de sisteme în care se stochează volume foarte mari de date, care au din acest motiv caracteristici specifice de organizare și prelucrare. Aceste caracteristici sunt asigurate de următoarele tehnologii ale IA privind prelucrarea volumelor mari de date: depozitele de date (data warehouse), concentrările de date (data marts), extragerea de date (data mining).

Pentru a înțelege în detaliu conceptele de inteligență business și data warehouse, precum și legătura dintre ele, este necesar să aruncăm o privire asupra dezvoltării tehnologiei și business-ului.

În anii 1970 – 1980, componentele unui computer erau foarte scumpe ca preț, iar puterea de procesare a unui computer era limitată. O afacere de mărime medie, de obicei opera cu o mână de sisteme bazate pe mainframe, care erau proiectate pentru scopuri de date operaționale.

Nevoile informaționale erau adresate prin rapoarte pe hârtie, deoarece programele de rapoarte de la vremea aceea, erau foarte costisitoare pentru a scrie și în general foarte inflexibile. Pentru a putea scrie programele de raport, era nevoie de un programator. Din fericire, la vremea aceea, salariile programatorilor nu erau foarte mari ceea ce permitea pentru multe firme să aibă un astfel de angajat.

În anii 1980, bazele de date relaționale preluaseră controlul. Datele erau stocate în tabele, dispuse în rânduri și coloane, dar nu precum spreadsheet-urile din Excel de astăzi. Bazele de date relaționale erau mult mai intuitive pentru utilizatorii finali și totuși era nevoie de o logică destul de complexă de multe ori pentru a alătura tabele multiple în scopul de obține informația de care era nevoie. Cu toate acestea, era posibil pentru utilizatorii finali să scrie propriile lor rapoarte, interogările erau de obicei ineficiente și era nevoie ca acestea să fie rulate după orele normale de lucru, pentru a nu interacționa cu tranzacțiile online.

În aceeași perioada, mai multe business-uri au migrat de la computerele bazate pe mainframe la sistemele client – server. Oamenii de afaceri începuseră să aibă PC-uri (computere personale). Aplicațiile office precum Microsoft Word, Excel sau Access deveniseră foarte populare.

Calculatorul personal a împuternicit utilizatorii finali și le-a permis acestora să dezvolte propriile lor aplicații și să își prezinte datele într-o manieră corespunzătoare și care să prezinte înțeles pentru aceștia, ca de pildă, sub formă de grid sau grafică. Foile de calcul Excel puteau fi îmbunătățite și costumizate în funcție de schimbările nevoilor business, fără asistența departamentului IT. Din păcate, datele corporative au rămas centralizate și în general nu au fost accesibile pentru utilizatorii finali.

Nevoia de a îmbunătăți inteligența business și data warehousing-ul a fost accelerată în anii 1990. În decursul acestei perioade, s-au petrecut schimbări tehnologice substanțiale și ca o consecință a globalizării din acea perioadă a crescut concurența.

La începutul anilor 1990, Internet-ul a luat lumea cu asalt. Companiile s-au grăbit să își implementeze aplicațiile lor de timp eCommerce sau eBusiness cu speranța de a reduce nevoile personale și pentru a putea furniza suport service clienților 24 din 24 de ore.

A fost desfășurat un volum de sisteme de aplicare ca un set paralel de aplicații de Internet. „Punțile” de back-end au fost construite pentru a încerca să se integreze sistemele aplicațiilor de tip „self service” cu sistemele aplicațiilor de tip „full service”. Din păcate, integrarea a fost de multe ori greoaie și din această cauză datele corporative au rămas de multe ori fragmentate sau inconsistente.

Cum cererea pentru programatori a crescut, de asemenea și salariile acestora au urcat, iar mediile de business au căutat soluții alternative pentru a customiza sistemele integrate în aplicații. În ideea de a reduce costurile și pentru a rămâne competitve, mai multe companii au achiziționat pachete software de la părți terțe. Aceste pachete erau proiectate pentru cerințe business generice și de multe ori nu se integrau corespunzătpr cu politica existentă a sistemelor.

La finalul mileniului trecut, mediile business au descoperit faptul că numărul de sisteme de aplicații și baze de date s-a multiplicat și că sistemele lor erau sărac integrate, iar datele lor erau inconsistente de-a lungul sistemelor. De asemenea, au văzut faptul că au o mulțime de date fragmentate, acestea nefiind informațiile cerute pentru decizii critice.

Companiile au început construirea de Data Warehouse-uri pentru a consolida datele din baze de date disparate pentru a sprijini mai bine nevoile lor strategice și tactice de luare a deciziilor.

Există mai mulți conducători de business în joc astăzi care își motivează companiile să își structureze informația în depozite de date. Ei consideră că informația consistentă și clară este critică pentru luarea strategică și tactică de decizii.

Companiile au nevoie ca inteligența business să fie consolidată și prezentată într-o formă potrivită pentru luarea de decizii. Informația incosistentă nu este acceptată. Data warehouse-urile ajută companiile să vadă o singură versiune a adevărului prin conzolodiarea celor mai clare și actuale date din cele mai de bază sisteme.

Într-o piață competitivă, firmele au nevoie să identifice problemele și oportunitățile și să răspundă evenimentelor cu promptitudine și în mod corespunzător. Informația la zi a vânzărilor, profiturilor, inventarelor și a clienților poate ajuta la identificarea problemelor care altfel ar putea fi omise. Cele mai multe dintre sistemele aplicațiilor sunt prea restrânse și operează cu cicluri care nu suportă accesul în timp real sau aproape în timp real la informații. Un depozit de date este proiectat să ofere acces la informația actualizată celor care iau decizii.

Este o muncă dificilă pentru companii să anticipeze nevoile informaționale. Sistemele de aplicații de obicei par rigide și nedisponibile să se adapteze la un management evoluat al cerințelor informaționale. Firmele au nevoie de flexibilitate pentru a putea împărți informațiile în cât mai multe moduri în scopul de a identifica și analiza schimbările pieței sau în business însuși. Depozitele de date sun create pentru scopuri analitice, online și oferă o flexibilitate foarte bună.

Se spune adesea faptul că 10% dintre clienții unei afaceri, reprezintă 90% din profit. Identificând clienții buni și oferindu-le acestora servicii excelente de ajutor ajută la păstrarea clienților. Depozitele de date pot ajuta la identificarea de către companii a celor mai buni clienți folosindu-se de orice număr sau criteriu.

În ziua de astăzi nu mai este de ajuns să se furnizeze clienților service doar între orele 09:00 – 17:00. Clienții vor să își desfășoare activitatea 7 zile pe săptămână, 24 de ore pe zi folosind canalele alternative de service delivery precum via Internet sau la telefon. Examinând tranzacțiile utilizatorilor, cu privire la canalele folosite, companiile îi pot înțelege mai bine pe aceștia și pot veni mai bine și eficient în sprijinul acestora. Data Warehousing-ul este esențial în realizarea profilurilor utilizatorilor și a tranzacțiilor acestora, având în vedere canalul folosit de către ei.

Cele mai multe dintre firmele medii și mari operează cu zeci, dacă nu sute de sisteme neintegrate de aplicații. Departamentele individuale ale companiilor, des se focusează pe sistemul propriu, restrând, în funcție de cerințele informației și nu văd valoarea corporativă a sistemelor integrate. Atunci când există silozuri de date neintegrate, acestea nu sunt sincronizate și actualizate. Companiile au nevoie de baze de date care să reflecte „a single version of the truth” (o singură față a adevărului – adică o imagine de ansamblu bazată pe totalitatea datelor și nu mai multe imagini bazate pe porțiuni).

Aplicațiile achiziționate de la terți („out of the box”) uneori folosesc concepte și definiții care diferă de cele folosite de firmă în aplicațiile existente deja customizate. De exemplu, un client dintr-un sistem ar putea include toți clienții actuali și din trecut, plus potențialii clienți viitori. Într-un alt sistem, un client ar putea fi definit mai restrâns ca fiind cineva care a achiziționat un produs și un serviciu în cursul ultimelor 12 luni. Asemenea inconsistențe crează probleme din punct de vedere al analiticii perspectivei. Numărul clienților din prima bază de date diferă de numărul din cea de-a doua. Companiile au nevoie de alinierea conceptelor și terminologiilor. Astfel ca depozitele de date pot ajuta la această aliniere.

Structurile care stau la baza sistemelor de aplicații sunt de cele mai multe ori foarte complexe. Pentru a crea ceea ce intuitiv ar putea să apară ca o simplă interogare, de obicei necesită o logică de programare complexă care implică navigarea prin tabele multiple ale unei baze de date sau prin aplicațiile sistemului. Scrierea de rapoarte sau de interogări poate necesita într-o manieră consecventă bani și timp. Companiile au nevoie de un mediu de rapoarte care să permită ca interogările să fie generate rapid, necostisitor și cu cât mai puține cunoștințe tehnice de IT.

Companiile au o dinamică foarte accentuată, iar sistemele de aplicații au constant nevoie să fie îmbunătățite pentru a suporta noile cerințe de business. Atunci când sistemele sunt schimbate, interogările și rapoartele care au acces la oricare dintre tabelele schimbate, trebuie de asemenea actualizate. Această muncă de mentenență poate să coste foarte mult. Companiile au nevoia de a organiza costului suportului pentru fiecare aplicație în parte, astfel că depozitele de date vin în sprijinul acestei idei, prin protecția și actualizarea interogărilor și rapoartelor schimbate o dată cu sistemul.

Creșterea rapidă a rețelelor de calculatoare a permis companiilor să schimbe date cu furnizorii clienților, corpurile guvernamentale și alte grupuri. Business-urile de obicei au nevoie să integreze date din baze de date interne sau externe. Depozitele de date pot fi proiectate pentru a integra date corporative cu date externe în scopul raportării corespunzătoare.

Astfel că, Business Intelligence se referă la un set de metode și tehnici care sunt folosite de organizații pentru luarea de decizii tactice și strategice. Funcționează ca un mecanism de pârghii pentru tehnologiile care se concentrează pe cifre și stratistici și totodată pe obiectivele afacerii pentru a îmbunătăți performanța acesteia.

Un data warehouse este pur și simplu o consolidare a informației provenită din mai multe surse care este proiectată pentru a suporta luarea deciziilor. Scopul principal este de a furniza o imagine coerentă a afacerii la un anume moment de timp dorit. Folosind diverse seturi de instrumente de Data Warehouse, utilizatorii au posibilitatea de a rula online interogări și de mina datele lor.

Mai multe companii de succes au investit sume mari de bani în inteligența business a afacerii lor și a tool-urilor de data warehousing. Ele consideră ca informația actualizată și clară despre lanțul de aprovizionare, produsele și clienții lor sunt esențiale pentru supraviețuirea lor.

Gartner Group a introdus termenul de business intelligence la mijlocul anilor ’90, iar cea mai reprezentativă definiție care există pe piață este dată de U. S. Central Intelligence Agency (CIA) și anume: „redus la cei mai simpli termeni, inteligența este cunoștința și modul în care simțim lumea din jurul nostru – preludiul deciziior și acțiunilor politicienilor…”.

Inteligența înseamnă cunoașterea datelor despre concurență. Un avantaj esențial al acesteia, este cunoașterea datelor despre client sau eventualul client.

Depozitele de date reprezintă o componentă a inteligenței în afaceri.

2.4 Data Warehouse vs. Data Mining

Termenii de data mining și data warehousing sunt des confundați fiind ambii legați de business și tehnică. Întregul domeniu de data management a experimentat o creștere fenomenala odată cu implementarea colecțiilor de programe software de date și a scăzut costul memoriei calculatoarelor. Scopul principal în spatele acestor funcții este de a furniza instrumentele și metodologiile pentru a putea explora șabloane și sensuri într-un volum mare de date.

Diferențele principale dintre data mining și data warehousing sunt faptul design-ul sistemului, metodologia folosită precum și scopul dorit. Data mining reprezintă folosirea logicii recunoașterii șabloanelor pentru a identifica trenduri printr-un set de date simplu și de a extrapola această informație. Data warehousing este procesul de extragere și stocare a datelor pentru a permite raportarea mult mai ușoară.

Atât data mining cât și data warehousing sunt instrumente de business intelligence care sunt folosite pentru a transforma informația în cunoștințe acționabile. Cele mai importante diferențe dintre cele două instrumente sunt reprezentate de metodele și procesele pe care fiecare dintre cele două tehnologii le folosește pentru a atinge acest scop.

Data mining este un process de analiză statistică. Analiștii folosesc instrumente tehnice pentru a interoga și sorta terabytes de date, în scopul de a obține șabloane. De obicei, analistul dezvolta o ipoteză, ca de exemplu clienții care cumpără produsul X, de obicei cumpără și produsul Y timp de 6 luni. Rulând o interogare pe datele relevante pentru a confirma sau a infirma această teorie, reprezintă data mining. Organizațiile apoi folosesc această informație pentru a lua decizii de afaceri mai bune, bazate pe felul în care își înțeleg clienții precum și comportamentul acestora și ai furnizorilor lor.

Data warehousing descrie procesul prin care datele sunt stocate cu scopul de a îmbunătăți rapoartele precum și analizele. Experții consideră că prin data warehouse, mase variate de date sunt conectate și relaționate între ele atât din punct de vedere conceptual cât și fizic. Informațiile business sunt de obicei stocate de-a lungul unui număr de baze de date. Totuși, pentru a putea analiza în sens larg informațiile, fiecare dintre aceste baze de date trebuie să fie relaționate cu altele relevante într-un fel sau altul. Acest lucru înseamnă ca datele relevante sunt relaționate, iar bazele de date fizice înseși au o conexiune, așa că informațiile din ele pot fi găsite laolaltă pentru scopuri de rapoarte.

Astfel că relația dintre data mining și data warehousing este faptul ca informațiile, din depozitele de date sunt ușor de minat. Dacă o interogare data mining trebuie să ruleze prin terabytes de date, de-a lungul multiplelor baze de date, această interogare nu va fi eficientă, ceea ce înseamnă că va furniza rezultate pentru care se va aștepta o perioadă prea mare de timp.

Totuși, daca expertul de data warehouse proiectează un mediu de stocare care să conecteze datele relevante în diferite baze de date, data miner-ul poate rula mult mai efficient interogări care să îmbunătățească afacerea.

Un exemplu excelent de data mining este acela al procesului folosit de companiile de telefonie pentru produsele de pe piață pentru clienții existenți. Compania de telefonie folosește software data mining pentru a accesa baza de date cu informații despre clienți. Este scrisă o interogare care să identifice clienții care s-au abonat la pachetul basic de servicii de Internet și telefonie, într-o anumită perioadă de timp. Odată ce este selectat setul de date, o altă interogare este scrisă pentru a determina câți clienți au avut avantajul de opțiuni adiționale, gratis în decursul perioadei trial a promoției. Rezultatele acestui exercițiu de data mining relevă șabloanele comportamentului care pot conduce sau ajuta la redefinirea planului de marketing pentru a crește folosirea serviciilor adiționale de telefonie.

Este foarte important să se noteze faptul că scopul principal al data mining-ului este acela de reține modelele din informații. Specificațiile folosite pentru a defini setul de test au un impact major pentru relevanța datelor de ieșire și pentru acuratețea analizei. Întorcându-ne la exemplul de mai sus, dacă setul de date este limitat la clienții dintr-o anumită zonă geografică, rezultatele și șabloanele vor fi diferite de un set de date larg. Totuși, chiar dacă atât data mining cât și data warehouse lucrează cu volume foarte mari de informație, procesele folosite sunt destul de diferite.

Un exemplu relevant pentru data warehousing, pe care aproape toată lumea în ziua de astăzi îl folosește, este ceea ce face Facebook. Rețeaua de socializare Facebook, practic adună toate datele unei persoane – prietenii, numărul de like-uri, profilele vizualizate etc. după care stochează toate aceste date într-un repository central. Chiar dacă Facebook cel mai mult stochează prietenii, like-urile etc, în baze de date separate, ei vor să extragă cea mai relevantă informație și să o pună într-o singura bază de date centrală, agregată. De ce ar dori să facă acest lucru? Din mai multe motive: doresc să se asigure că un utilizator vede cele mai relevante reclame, în funcție de paginile pe care le apreciază, de asemenea prietenii care apar ca sugestii, să fie de asemenea relevanți pentru utilizatorul respectiv etc.

În altă ordine de idei, trebuie subliniat faptul că data warehousing este procesul care trebuie să se petreacă înainte de orice alt proces data mining. Cu alte cuvinte, data warehousing este procesul de compilare și organizare a datelor într-o singură bază de date comună, iar data mining este procesul de extragere a informației relevante din baza de date. Procesul de data mining reliefează datele compilate din faza de data warehousing cu scopul de a detecta șabloane relevante.

În exemplul cu Facebook, data mining va fi făcut în mod normal de utilizatorii business, care nu sunt ingineri, dar vor primi de ce mai multe ori asistență din partea inginerilor atunci când încearcă să manipuleze datele lor. Faza de data warehousing este strict dedicată inginerilor, acolo unde utilizatorii business nu sunt implicați. Acest lucru permite definirea celor doi termeni într-o altă modalitate: data mining este un proces realizat de utilizatorii business având ca ajutor asistența inginerilor, iar data warehousing este un proces realizat exclusiv de către ingineri specializați în domeniu.

Altfel spus, data mining este extragerea sau minarea cunoștințelor din volume mari de date, sau data warehouse. Pentru a face această extragere, data mining combina inteligența artificială, analiza statistică și managementul bazei de date pentru a obține cunoștințele din datele stocate. Data mining reprezintă totodată procesul de aplicare a metodelor inteligente pentru a extrage șabloane de date. Acest lucru este realizat folosind instrumente de front end. Foaia de calcul reprezintă cel mai compilat OLAP (Online Application for Analytical Processing). Provocările pentru susținerea unui mediu de interogări pentru OLAP pot fi sumarizate ca fiind o foaie de calcul pentru suportul operațiilor efective asupra bazelor de date foarte largi. Pentru a distinge informația extrasă prin data mining, de interogarea dintr-o bază de date tradițională, trebuie făcută următoarea observație: într-o aplicație de bază de date, problemele interogărilor sunt bine definite la nivelul aceea ce se dorește, iar datele de ieșire sunt precise, fiind un subset de date operaționale. Într-un data mining nu există un limbaj de interogări standard, iar interogările sunt slab definite. Astfel, output-ul nu este precis (fuzzy) și nu reprezintă un subset al bazei de date.

În timpul procesului de construire a unui data warehouse, datele operaționale sunt sumarizate în funcție de diferite caracteristici, ca de pildă împrumuturi pe o perioadă de 3 luni. Interogările pot fi de tipul „identificarea tuturor celor care au împrumutat și au același interes, sau un interes similar” sau „lucruri pe care un membru le-ar împrumuta frecvent alături de filme” care nu este la fel de precis precum lista de cărți împrumutate de un membru. În supermarket-uri, astfel de relații au fost deja identificate folosind data mining. Astfel de itemi relaționați precum „laptele și pâinea”, sau „berea și chips-urile” ar fi ținute împreună. Companiile de telefonie mobilă iau decizii cu privire la orele de vârf, ratele și pachete speciale bazate pe cercetări similare. Utilizatorii pot folosi tehnicile data mining pe un data warehouse pentru a extrage diferite tipuri de informație care eventual ar asista procesul de luare de decizii al unei organizații. Instrumentele de suport al deciziei asistă utilizatorii în descoperirea cunoștințelor.

Un sistem de suport al deciziei (DSS – Decision Support System) reprezintă orice tool folosit pentru a îmbunătăți procesul de luare de decizii în sistemele complexe. Un DSS poate migra de la un sistem care răspunde interogărilor simple, la un sistem care angajează inteligență artificială și furnizează data set-uri relaționate. De-a lungul celor mai importante zone ale unui DSS, cele mai complicate sistemele sunt cele care răspund direct întrebărilor, în particular, la un nivel înalt „what if” de modelare a scenariului.

3. Arhitectura data warehouse

Depozitele de date pot fi arhitecturate în mai multe moduri, în funcție de nevoile specifice ale afacerii. Modelul de mai jos, reprezintă arhitectura „hub-and-spokes”, care este populară în foarte multe organizații.

Fig. 1. Mediu data warehouse [2]

Pe scurt, datele sunt mutate din bazele de date folosite în sistemele operaționale, în zona de așteptare (staging), după care într-un data warehouse și în final într-un set conformat de data marts. Datele sunt copiate dintr-o bază de date în alta folosind po tehnologie denumită ETL (Extract, Transform, Load).

Motivul principal pentru care mediile de business au nevoie să creeze depozite de date este faptul că activele de date corporative sunt fragmentate de-a lungul multiplelor sisteme de aplicații disparate care rulează pe diferite platforme tehnice în diferite locații fizice. Această situație nu permite luarea bună de decizii.

Atunci când există redundanța datelor în mai multe baze de date, egalitatea datelor se deteriorează de obicei. Inteligența business săracă rezultă în luare săracă de decizii strategice și tactice.

Unitățile business dintr-o organizație sunt proiectate ca fiind „proprietari” ai aplicațiilor și bazelor de date operaționale.

Aceste „silozuri organizaționale”, uneori nu înțeleg importanța strategică a avea date bine integrate, ne-redundante. Consecvent, ele frecvent achiziționează sau construiesc sisteme operaționale care nu se integrează bine cu sistemele existente deja.

Bazele de date operaționale, sunt de obicei „relaționale” și nu „dimensionale”. Ele sunt proiectate pentru intrări de date operaționale și nu se potrivesc pentru analizări și interogări online.

Datorită globalizării, trendurilor de outsourcing a apărut nevoia de a integra date operaționale din organizații externe. Împărtășirea clienților și a vânzărilor de-a lungul partenerilor de business, poate, de exemplu, sa crească inteligența afacerilor pentru toți partenerii acesteia.

Provocarea pentru Data Warehouse este să consolideze rapid, să curețe și să integreze date din multiple baze de date care să ruleze pe platforme tehnice diferite, în locații geografice diverse.

Tehnologia ETL (arătată în figura 1 prin săgeți) este o componentă importantă din arhitectura Data Warehouse. Este folosită pentru a copia informațiile din aplicațiile operaționale în stagiul de așteptare al depozitelor de date, de la stagiul de așteptare la data warehouse, și, în final, de la data warehouse la un set conformat de data marts care sunt accesibile celor care iau decizii.

Software-ul ETL extrage datele, transformă valorile datelor inconsistente, curăță datele „rele”, filtrează datele și încarcă datele într-o bază de date target.

Programarea job-urilor ETL este critică. Dacă există o eroare într-un job ETL, celelalte job-uri ETL rămase trebuie să răspundă corespunzător.

Stagiul de așteptare al data warehouse-ului este o locație temporară unde sunt copiate datele din surse de sisteme. Un stagiu de așteptare este necesar într-o arhitectură data warehouse din motive de timing. Pe scurt, toate datele cerute trebuie să fie disponibile înainte ca acestea să fie integrate în depozitul de date.

Datorită ciclurilor variate de business, procesarea ciclurilor de date, limitările resurselor de hardware și de rețea, precum și a factorilor geografici, nu este fezabilă extragerea tuturor datelor din toate bazele de date operaționale în același timp.

De exemplu, s-ar putea să fie rezonabilă extragerea vânzărilor dintr-o zi, totuși, extragerile zilnice s-ar putea să nu fie potrivie pentru date financiare care au nevoie de un proces de terminare a lunii. Similar, s-ar putea să fie fezabilă extragerea informațiilor despre clienți dintr-o bază de date din Singapore la amiază, în funcție de ora de est, dar acest lucru nu va fi fezabil pentru clienții din baza de date specifică orașului Chicago.

Datele din depozitul de date pot fi de asemenea persistente (rămân în depozit pentru o perioadă lungă de timp) sau tranzitorii (rămân în depozit doar temporar).

Nu toate business-urile au nevoie de un stagiu de așteptare al data warehouse-ului. Pentru mai multe organizații este fezabil să se folosească ETL pentru a copia datele direct din bazele de date operaționale în Data Warehouse.

Scopul unui Data Warehouse în întreaga arhitectură data warehousing este acela de a integra date corporative. Conțin „singura față a adevărului” pentru organizație și au fost construite cu grijă din datele stocate în baze de date interne sau externe, operaționale.

Volumul de date din depozitul de date este masiv. Datele sunt stocate la un nivel granular de detalii. De exemplu, fiecare „vânzare” care s-a întâmplat vreodată într-o organizație este înregistrată și relaționată cu dimensiunea de interes. Acest lucru permite datelor să fie împărțite într-un număr inimaginabil de căi.

Contrar opiniilor populare, data warehouse-ul nu conține toate datele dintr-o organizație. Scopul acestuia este de a oferi cheile metrice ale afacerii care sunt necesare organizației pentru luare de decizii. Cei care se ocupă cu luarea de decizii, nu accesează depozitul de date direct. Acest lucru este posibil cu ajutorul diverselor instrumente front-end care citesc datele. Data Warehouse-ul poate fi totodată „relațional”, cât și „dimensional”. Acest lucru depinde de felul în care mediul business intenționează să folosească informația.

Joburile ETL (Extract Transform Load) extrag datele din depozitele de date și populează una sau mai multe data marts pentru a fi folosite de grupuri de persoane care se ocupă cu luare de decizii în organizație. Data Mart-urile pot fi dimensionale (scheme star) sau relaționale, acest lucru depinzând de felul în care este folosită informația și în care instrument front end va fi prezentată informația.

Fiecare Data Mart poate conține combinații diferite de tabele, coloane și rânduri din Enterprise Data Warehouse. De exemplu, o unitate business, sau un grup de utilizatori care nu are nevoie de prea multă informație istorică ar putea avea nevoie doar de tranzacțiile anului curent calendaristic. Departamentul de personal ar putea dori să vadă toate detaliile despre angajați, pe când datele de genul „salariu” sau „adresa personală” s-ar putea să nu fie potrivite pentru data mart-ul care se concentrează asupra vânzărilor.

3.1 OLAP, OLTP – concepte și diferențe

OLAP (Online Analytical Processing) reprezintă tehnologia din spatele mai multor aplicații de tip Business Intelligence. OLAP este o tehnologie puternică pentru descoperirea datelor, incluzând capabilități pentru vizualizarea limitată de raporturi, calcule complexe analitice și scenarii predictive „what if”.

Cum este folosită tehnologia OLAP?

OLAP lucrează cu analiza multidimensională a datelor business și furnizează capabilitatea pentru calcule complexe, analiza trendurilor și modelare sofisticată a datelor. Reprezintă fundația pentru mai multe tipuri de aplicații pentru performanța business a managementului, plan, modele de simulare, descoperirea cunoștințelor și raportarea data warehouse. OLAP permite utilizatorilor finali să efectueze analiză ad-hoc de date în multiple dimensiuni, furnizând înțelegerea a ceea ce au nevoie pentru o luare mai bună a deciziilor.

Știința este fundația tuturor deciziilor de succes. Afacerile de succes în continuu plănuiesc, analizează și efectuează rapoarte despre vânzări și activități operaționale, cu scopul de a maximiza eficiența, de a reduce cheltuielile și de a câștiga o piață de desfacere mai mare. Statisticienii vor spune că cu cât există mai multe date simple, cu atât mai mult rezultatele statistice vor fi adevărate. În mod natural, cu cât mai multe date o companie poate accesa cu privire la o activitate specifică, cu atât mai mult planul de a îmbunătăți acea activitate va fi mai eficient. Toate mediile de business colectează date folosind diferite sisteme, iar provocarea rămâne: cum să extragem toate datele împreună pentru a crea informații clare, de bază și rapide pentru companie. O firmă poate profita de avantaj și să îl transforme în cunoștințe împărtășite, clare și rapide, vor fi cu siguranță poziționate mai bine pentru a lua decizii business de succes și pentru a se ridica deasupra competiției.

Tehnologia OLAP a fost definită ca fiind abilitatea de a obține „acces rapid la informație multidimensională comună”. Fiind dată abilitatea de a crea agregări foarte rapide și calcule ale seturilor de date de bază, se poate înțelege indispensabilitatea sa în ajutorul liderilor afacerilor în a lua decizii mai bune și mai rapid „informate”.

Afacerea este o activitate multidimensionale, iar afacerile în general sunt bazate pe decizii din multiple dimensiuni. Business-urile își urmăresc activitățile luând în considerare mai multe variabile. Atunci când aceste variabile sunt urmărite pe o foaie de calcul, ele reprezintă un set de axe (x și y) unde fiecare axă reprezintă o grupare logică de variabile într-o categorie. De exemplu, vânzările în unități sau dolari ar putea fi urmărite pe o perioadă de un an, după luna, unde măsurile vânzărilor ar putea ocupa axa x ( de exemplu, măsurile vânzărilor sunt rânduri, iar lunile coloane). Pentru a analiza și a reporta în sufletul unei afaceri li pentru a plănui activități viitoare, mai multe grupuri de variabile sau parametri trebuie urmăriți într-o bază continuă – care este pe lângă scopul oricărui număr din foile de calcul relaționate. Aceste grupuri de variabile sau parametri sunt denumiți Dimensiuni în mediul OLAP.

În ziua de astăzi, mai mulți utilizatori ai foilor de calcul au auzit despre tehnologia OLAP, dar încă nu le este clar ce înseamnă de fapt. Spre deosebire de bazele de date relaționale, instrumentele OLAP nu stochează tranzacții individuale de înregistrări în două dimensiuni, rând – coloană format, în schimb stochează datele în structuri de baze de date, denumite și Cuburi. Datele și formulele sunt stocate într-o bază de date multidimensională, pe când view-urile datelor sunt create la cerere. Analiștii pot lua orice view, sau bucată a unui cub pentru a produce foi de lucru ca vederi ale punctelor de interes. Mai mult decât a munci simplu cu două dimensiuni (foi de calcul standard), sau trei dimensiuni, companiile au mai multe dimensiuni de urmărit, de exemplu, o firmp care distribuie bunuri pentru mai mult de o singură facilitate va avea cel puțin următoarele dimensiuni de luat în considerare: conturi, locații, perioade, vânzări și produse. Aceste dimensiuni comprimp o bază pentru planurile companiei, analiza și raporturile activităților. Această capabilitate de a efectua analize sofisticate (în special analiza multidimensională dată de tehnologia OLAP)este imperativă într-o organizație. Analiștii trebuie să vadă și să manipuleze datele de-a lungul multiplelor dimensiuni care definesc organizația și mai ales dimensiunile necesare creației unui model efectiv de business.

Implementările tehnologiei OLAP depind nu doar de tipul de software, ci și de sursele de date care sunt la bază și de obiectivele firmei. Fiecare industrie sau afacere este specifică și necesită un anumit grad de customizare pentru a crea cuburi multidimensionale pentru încărcarea informațiilor, crearea de rapoarte, cel puțin. O soluție de tip OLAP ar putea avea ca scop rapoartele dinamice pentru domeniul financiar, de exemplu, cu surse de date provenind din sisteme ERP. Sau o altă soluție s-ar putea adresa activităților unei instituții medicale cu privire la analiza pacienților. Per ansamblu trebuie ca clienții să aibă obiective clare pentru o anume soluție și să înceapă să considere selectarea de produse în funcție de acest lucru. Un alt factor care trebuie să fie luat în considerare într-o implementare OLAP este livrarea către utilizatorii finali: utilizatorul inițial dorește să adopte un nou front end, sau există preferința pentru a utiliza un dashboard? Sau poate utilizatorii sunt mai bine serviți de către un sistem de livrare dinamic, de exemplu un buget colaborativ.

Ca un exemplu de un sistem OLAP, HTAP – Hybrid Transaction/Analytical Processing. HTAP are la bază procesare nouă, puternică și distribuită: uneori implică o aplicare hardware nouă și aproape mereu are nevoie de o platformă nouă software. În afară de aceste lucru, ounctul cheie pare să fie faptul că toată această tehnologie este situată într-o bază de date relațională. Astfel, nu mai există replicarea datelor, iar tranzacțiile noi de informații devin parte din modelul analitic la fel de rapid din punct de vedere al timpului cât și al tehnologiei.

HATP prezintă o nouă cale de a lega informațiile într-o manieră care nu a fost posibilă până acum: o unificare reală a datelor relaționale stocate în tabele cu modele de date care sunt folosite pentru a lua decizii de către liderii afacerilor.

MOLAP (Multidimensional OLAP) – CUBE based

Produsele acestui tip de tehnologie OLAP permit utilizatorilor finali să modeleze datele în medii multidimensionale, mai mult decât să furnizeze o vedere multidimensională a datelor relaționale.

Structura unui model multidimensional nu este o serie de tabele (cum există într-o bază de date relațională), dar în general se referă la cub. Cuburile modelate într-o bază de date multidimensională extind conceptul asociat foilor de calcul: așa cum o celulă dintr-o foaie de calcul reprezintă intersecția a două dimensiuni (vânzările unui produs în funcție de regiune), o celulă dintr-un cub reprezintă interesecția unui număr infinit de membrii dimensiune (de exemplu Produse, Clienți, Regiuni, Luni etc.). De asemenea într-un cub, valoarrea dintr-o celulă poate fi calculată prin formule care pot să implice și alte celule.

Pe scurt, bazele de date multidimensionale permit utilizatorilor să adauge dimensiuni extra, spre deosebire de tabele adiționale, precum în modelul relațional. Iar structura unui cub MOLAP permite calcule rapide, flexibile de modelare a datelor. Localizarea celulelor este foarte mult simplificată, o aplicație poate identifica locația unei celule după nume (la intersecția membrilor dimensiune), spre deosebire de bazele de date unde un index se caută în întregul model (prin SELECT-uri).

OLTP – Online Transaction Processing este o clasă de sisteme informaționale care facilitează și gestionează tranzacțiile orientate pe aplicații, de obicei pentru intrările de date și au ca date de ieșire procesarea tranzacțiilor. Termmenul poate fi puțin ambiguu, deoarece unii specialiști pot considera tranzacția în contextul unui computer sau a tranzacțiilor unei baze de date, pe când alții definesc termenul ca aparținând domeniului business sau comerțului. OLTP este de asemenea folosit pentru procesarea în care sistemele răspund imediat cerințelor utilizatorilor. Un ATM al unei bănci, de exemplu este un exemplu de tranzacție comercială. Acest gen de aplicații sunt folosite în mod simultan de către sute de utilizatori. Scopurile unui sistem OLTP sunt disponibilitatea, viteza, concurența și recuperarea rapidă.

Sistemul OLTP este un sistem de procesare a datelor popular în multe firme în ziua de astăzi. Câteva exemple ar putea include intrări ale unor comenzi, vânzări sau sisteme de tranzacții financiare. Sistemele OLTP au nevoie de suport pentru tranzacții care rulează într-o rețea și pot include mai mult de o companie. Pentru acest motiv, procesarea modernă a tranzacțiilor online folosesc procesarea client sau server pentru a permite tranzacțiilor să ruleze pe diferite computere din rețea.

În aplicațiile mari, sistemele OLTP eficiente pot depinde de tranzacții sofisticate sau optimizări ale bazei de date pentru a facilita procesarea numărului mare de actualizări concurente al unei baze de date OLTP.

Pentru și mai multă cerere decentralizată, sistemele de intermediere OLTP pot distribui procesarea tranzacțiilor de-a lungul multiplelor computere dintr-o rețea. OLTP este de obicei integrat în arhitectura orientată pe servicii (SOA) și pe servicii web.

OLTP implică adunarea de input, procesare și actualizarea informației existente pentru a reflecta informația adunată precum și procesarea ei. Cele mai multe organizații folosesc un sistem de management al bazei de date pentru a sprijini OLTP. OLTP este înglobat într-un sistem client – server.

Online Transaction Process se focusează pe concurență și atomicitate. Controlul concurenței garantează că doi utilizatori care acceasează aceleași date în același timp, nu vor putea să modifice acele date, sau un utilizator trebuie să aștepte până celălalt termină de procesat, înainte de a schimba acea porțiune de date. Controlul atomicității garantează că toți pașii dintr-o tranzacție sunt completați cu succes împreună, ca un grup. Dacă anumiți pași dintr-o tranzacție eșuează, și ceilalți pași constituenți eșuează.

Pentru a construi un sistem OLTP, un designer trebuie să știe faptul că numărul mare de utilizatori concurenți nu trebuie să interfereze cu performanța sistemului. Pentru a crește performanța unui sistem OLTP, designer-ul trebuie să evite folosirea excesivă a indecșilor și clusterelor.

Următoarele elemente sunt cruciale pentru performanța sistemelor OLTP:

segmentele rollback – porțiuni ale bazei de date care înregistrează acțiuni ale tranzacțiilor în evenimentul în care unei tranzacții i se aplică comanda roll back;

clustere – scheme care conțin unul sau mai multe tabele care una sau mai multe coloane în comun. Într-o bază de date, tabelele de clustering îmbunătățesc performanța operației de join;

tranzacții discrete – toate schimbările unor date sunt ascunse până în momentul în care se dă commit. Poate îmbunătăți performanța tranzacțiilor scurte, nedistribuite;

block size;

buffer cache size;

alocarea dinamică a spațiilor tabelelor și a segmentelor rollback;

procesarea tranzacțiilor – monitorizează coordonarea serviciilor;

partiționarea – crește performanța pentru site-uri care au tranzacții regulate în timp ce se menține disponibilitatea și securitatea.

Fig. 2 OLAP vs. OLTP [3]

Sistemele IT pot fi împărțite în sisteme tranzacționale (OLTP) și sisteme analitice. În general, putem spune că sistemele OLTP furnizează surse de date pentru depozitele de date, pe când sistemele OLAP ajută la analizarea acestor date. Astfel, OLTP și OLAP sunt tehnologii complementare.

Umătorul table surprinde în termini largi, câteva dintre cele mai mari diferențe dintre sistemele OLTP și cele OLAP.

Diferențe între OLAP și OLTP

Pe scurt, în practică este nevoie de două baze de date, una pentru OLAP și cealaltă pentru OLTP. Cea de-a doua este cea pe care o denumim data warehouse este obligatorie dacă se dorește aprofundarea inteligenței în afacere.

Dar dacă aceasta este cea mai bună soluție, de ce nu este adoptată de toate companiile? De ce există atâtea cazuri în care instrumentele de business intelligence sunt folosite pe baze de date tradiționale OLTP? Unul dintre cele mai comune motive ar putea fi: doctrina – timp de mai mulți ani, modelatorii de date au fost educați să normalizeze datele și tot atât timp aceștia au fost învățați asupra faptului că redundanța datelor reprezintă regresul într-o organizație.

3.2 Modelarea dimensională a datelor

Făcând o paralelă la viața reală, atunci când un constructor construiește o casă, va avea nevoie de foarte multe instrumente. Fiecare dintre acestea are scopul lui specific și contribuie la completarea lucrării finale. Probabil unul dintre instrumente va fi un pistol pentru cuie. De ce atâtea instrumente, când scopul principal este ca diferitele cuie să fie bătute în lemn?

Un pistol pentru cuie va face o treabă excelentă la construirea pereților, dar este un pic nedelicat pentru uși. Un ciocan de finisare se poate ocupa de asta, însă nu va fi suficient pentru construcția unui zid de susținere. Astfel, constructorul alege instrumentul care se potrivește cel mai bine pentru o acțiune anume individuală de construcție.

Un designer de baze de date alege din diversele tehnici de design pe aceea care se va potrivi cel mai bine unei anume activități. O tehnică ce câștigă popularitate în data warehousing este modelarea dimensională a datelor (dimensional data modeling). Pentru anumite situații de analiză a datelor poate întruni cerințele unei organizații prin origanizarea datelor dintr-un depozit.

În sistemele OLTP tranzacțiile tind să fie făcute pe baza a interogări mici, predefinite. Programatorul sau dezvoltatorii DBA testează și optimizează fiecare interogare. Utilizatorul final rareori trebuie să scrie interogări sau să interacționeze direct cu implementarea fizică a modelului de date.

În mediile Data Warehousing, interogările tind să folosească mai multe tabele, să returneze seturi de date foarte mari și să ruleze mai mult. Cum interogările nu sunt plănuite de obicei și nu pot fi refolosite, există o foarte mică posibilitate de optimizare a activităților.

Utilizatorii non-tehnici sunt des îndemnați să înțeleagă cum să lege șase, zece sau mai multe tabele pentru a răspunde unei întrebări. Performanța ulterioară are de suferit atunci când mai multe tabele mari au fost construite în așa fel încât interogările și indecșii nu au fost definiți sp optimizeze opțiunile de acces ale interogărilor.

Metafora de „cub” furnizează o nouă abordare pentru vizualizarea organizării datelor. Un astfel de cub dă impresia de dimensiuni multiple. Cuburile pot avea 2, 3, 4 sau mai multe dimensiuni. Utilizatorii pot „felia și împărți” dimensiunile, alegând ce dimensiune să folosească de la interogare la interogare.

Fiecare dimensiune reprezintă un atribut identificator:

mai multe dimensiuni pot fi folosite simultan pentru a categoriza faptele;

cu cât mai multe dimensiuni sunt folosite, cu atât mai mare este nivelul de date regăsite;

dimensiunile pot de asemenea fi folosite pentru a constrânge datele returnate într-o interogare, prin restricția rândurilor returnate la acelea care se potrivesc unei valori specifice a rangului de valori pentru dimensiunea de constrângere.

Pentru a înțelege mai bine modelarea dimensională a datelor, urmează o scurtă trecere în revistă a definițiilor termenilor specifici:

dimensiune – categorie de informație. De exemplu dimensiunea timp;

atribut – un nivel unic dintr-o dimensiune. De exemplu Luna este un atribut in dimensiunea Timp;

ierarhie – specificația nivelelor care reprezintă relația dintre diferite atribute într-o dimensiune. De exemplu o posibilă ierarhie pentru dimensiunea Timp este An -> Semestru -> Lună->Zi;

Fact Table (tabela de fapte) – reprezintă un tabel care conține măsuri (mărimi) de interes. De exemplu, totalul de vânzări ar fi o astfel de măsură. Această măsură este stocată în tabela de fapte cu granularitatea corespunzătoare. De exemplu, putem vorbi despre totalul de vânzări în funcție de magazine și zile. În acest caz, tabela de fapte ar conține trei coloane: o coloană pentru date, una pentru magazin și încă una pentru totalul de vânzări;

Lookup Table – tabelul Lookup este cel care furnizează informații detaliate cu privire la atribute. De exemplu, tabelul Lookup pentru atributul Semestru ar include o listă cu toate semestrele disponibile din data warehouse. Fiecare rând (fiecare semestru) ar avea diverse câmpuri, unul pentru ID-ul unic care identifică acel semestru și unul sa mai multe câmpuri adiționale care specifică cât reprezintă în particular acel semestru în raport (de exemplu, primul semestru din 2001 poate fi reprezentat ca „Q1 2001” sau „2001 Q1”).

Un model dimensional include tabele de fapte și lookup. Tabele de fapte conectează unul sau mai multe tabele lookup, dar tabelele de fapte nu au legături directe unele cu altele. Dimensiunile și ierarhiile sunt reprezentate de tabelele lookup. Atributele sunt coloanele non-cheie din tabelele lookup.

În proiectarea modelelor de date pentru depozitele de date / data marts, cele mai utilizate tipuri de scheme sunt schema stea (star) și schema fulg de nea (snowflake).

Decizia de a utiliza schema stea sau cea a fulgului de nea, depinde foarte mult de preferințele personale și de nevoile afacerii.

Schema Stea – Star Schema

În designul acestei scheme, un singur obiect (tabelul de fapte) se situează în mijloc și este conectat radical cu obiectele care îl înconjoară (tabelele de lookup, dimensiuni) precum o stea. Fiecare dimensiune este reprezentată de un singur tabel. Cheia primară în fiecare tabel dimensiune este relaționată cu o cheie străină în tabelul de fapte.

Fig. 3. Exemplu de schemă simplă sub formă de stea [3].

Toate măsurile din tabelul de fapte sunt relaționate cu toate dimensiunile cu care tabelul de fapte este relaționat. Cu alte cuvinte, au același nivel de granularitate.

O schemă stea poate fi simplă sau complexă. O schemă simplă constă dintr-un tabel de fapte; o schemă complexă poate avea mai mult de un singur tabel de fapte.

Să luăm un exemplu: să presupunem un depozit de date care stochează datele vânzărilor și diferite dimensiuni sunt timpul, magazinul, produsul și clientul. În acest caz, figura de mai sus reprezintă schema star dorită. Liniile dintre două tabele indică faptul că există o relație de tip cheie primară – cheie secundară între două tabele. A se observa faptul că două dimensiuni diferite nu sunt relaționate.

Schema fulgului de nea (Snowflake schema) este o extensie a schemei stea, unde fiecare punct al stelei explodează în mai multe puncte. Într-o schemă stea, fiecare dimensiune este reprezentată de un singur tabel dimensiune, în timp ce într-o schemă de fip snowflake, acel tabel dimensional este normalizat în mai multe tabele lookup, fiecare reprezentând un nivel în ierarhia dimensională.

Fig. 4.Exemplu de schema simplă sub formă de fulg de nea [3].

De exemplu, dimensiunea Timp constă din două ierarhii diferite:

1. An – Lună – Zi;

2. Săptămână – Zi.

Vom avea astfel 4 tabele de tip lookup într-o schemp de tip snowflake: unul pentru an, unul pentru lună, unul pentru săptămână și încă unul pentru zi. Anul este conectat cu Luna, care mai apoi este conectată cu Ziua. Săptămâna este conectată doar cu Ziua. O schemă simplă care să ilustreze cele comentate, este reprezentată în figura 3. Cel mai mare avantaj al folosirii schemei snowflake este îmbunătățirea performanței interogărilor datorită cerințelor minimizate de stocare a discului și alăturarea cu tabele de lookup mici. Desavantajul major al folosirii acestui tip de schemă este reprezentat de eforturile adiționale de mentenanță de care este nevoie din cauza creșterii numărului de tabele lookup.

Primul pas în proiectarea unui tabel de fapte este determinarea granularității acestuia. Prin granularitate se înțelege ce mai jos nivel de informație care va fi stocat în tabelul de fapte. Acest lucru înseamnă doi pași:

determinarea căror dimensiuni vor fi incluse;

determinarea locației dimensiunii în ierarhie unde va fi stocată informația;

Determinarea căror dimensiuni vor fi incluse este un proces de obicei drept și obiectiv,

deoarece procesele de business vor dicta des care sunt dimensiunile relevante. De exemplu, într-un comerț de tip off-line, dimensiunile pentru tabelul de vânzări fact table sunt de obicei timpul, geografia și produsele. Un supermarket cu un program de carduri cu premii, unde clienții furnizează informații personale în schimbul cardurilor, iar supermarketul va oferi prețuri mai mici pentru anumite produse clienților care prezintă cardurile la finalizarea cumpărăturilor, va avea de asemenea abilitatea de a urmări dimensiunea clienților. Fie că sistemul de depozite de date include dimensiunea clienților, acest lucru va fi o decizie de luat în considerare.

Determinarea cărei parți a ierarhiei va stoca informația de-a lungul fiecărei dimensiuni nu este o știință exactă. Aici cerințele utilizatorului joacă un rol foarte important.

În exemplul dinainte, va vrea supermarketul să efectueze analize la nivel de ore? (de exemplu, câte produse de același tip sunt vândute la diferite ore ale zilei). Astfel, are sens să se folosească „ora” ca fiind cel mai mic nivel de granularitate în dimensiunea timp. Dacă analiza zilnică este suficientă, atunci „ziua” poate fi folosită ca cel mai mic nivel de granularitate. Cu cât scade nivelul de detalii, cu atât crește totalul de date din tabelul de fapte, granularitatea îl exercită în esență obținând punctul cheie dintre nivelul detaliat de analiză și stocarea de date.

Uneori utilizatorii nu specifică anumite cerințe, dar bazându-ne pe industria cunoștințelor, echipa de data warehousing poate prevedea faptul că va fi nevoie de anumite cerințe în viitor. În anumte cazuri este prudent pentru echipa de data warehousing să proiecteze tabelul de fapte la cel mai mic nivel de informație. Acest lucru va evita nevoia posibilă de a reproiecta tabelul în viitor. Pe de altă parte, încercând să se anticipeze toate aceste nevoi din viitor, este imposibil și prin urmare inutilă exercitarea și echipa de data warehousing are nevoie să se lupte cu nevoia de simptom „descărcarea celui mai scăzut nivel de detaliu în depozitul de date” și să includă doar ceea ce este necesar. Uneori acest aspect poate ține mai mult de artă, decât de știință, iar experiența anterioară devine neprețuită aici.

3.3 Tipuri de tabele de fapte

Există trei tipuri de tabele de fapte:

aditive: faptele aditive sunt fapte care pot fi sumarizate prin toate dimensiunile din tabela de fapte;

semi – aditive: faptele semi-aditive sunt faptele care pot fi sumarizate pentru anumite dimensiuni din tabela de fapte, dar doar pentru acelea;

ne-aditive: faptele neaditive sunt faptele care nu pot fi sumarizate pentru nicio dimensiune prezentă în tabela de fapte;

Să exemplificăm pentru a ilustra fiecare tip de tabele de fapte. Primul exemplu presupune un comerciant care are tabela de fapte cu următoarele coloane:

Data;

Magazin;

Produs;

Total_Vânzări.

Scopul acestui tabel este de a înregistra totalul de vânzări pentru fiecare produs în fiecare magazin zilnic.

Total_Vânzări este faptul. În acest caz, Total_Vânzări este un fapt aditiv, deoarece se pot sumariza oricare dintre cele trei dimensiuni prezente în tabel – data, magazinul sau produsul. De exemplu, suma pentru Total_Vânzări pentru cele șapte zile ale unei săptămâni reprezintă totalul de vânzări pentru o săptămână.

Să luăm un alt exemplu, pentru o bancă. Avem următoarele coloane în tabela de fapte:

Data;

Cont;

Balanța_Curentă;

Marja_de_Profit.

Scopul acestui tabel este de a înregistra balanța curentă pentru fiecare cont la finalul fiecărei zile, la fel ca și marja de profi pentru fiecare cont, în fiecare zi.

Marja_de_profit și Balanța_Curentă sunt faptele. Balanța_Curentă este un fapt semi-aditiv, deoarece trebuie adăugată la toate conturile (care este totalul balanței curente pentru toate conturile din bancă?), dar nu este necesară să fie adăugată la timp(adăugând toate balanțele curente pentru un cont dat în fiecare zi a lunii nu dă nicio informație folositoare).

Marja_de_Profit este un fapt ne-aditiv, deoarece nu are niciun sens să fie adăugată la nivelul de cont sau la nivelul zilei.

Bazându-ne pe observațiile anterioare, tabelele de fapte (fact tables) pot fi clasificate în alte două categorii:

Cumulative: acest tip de tabele de fapte descrie ce s-a întâmplat într-o perioadă de timp. De exemplu, un tabel de fapte descrie totalul de vânzări în funcție de produs, magazin și zi. Aceste fapte pentru acest tip de tabele de fapte sunt în mare parte fapte aditive. Primul exemplu prezintat este un tabel de fapte cumulativ;

Snapshot: acest tip de tabele de fapte descrie starea lucrurilor într-o instanță particulară dr timp, și de obicei include mai multe fapte semi-aditive și ne-aditive. Al doilea exemplu prezentat este un tabel de fapte snapshot.

Schimbarea lentă a dimensiunilor este o problemă comună și particulară depozitelor de date. Uneori se aplică în cazuri pentru care atributul pentru înregistrări variază în timp.

Să luăm următorul exemplu. Cosmin este un client al firmei Mobexpert. Prima dată a locuit în Ploiești, Prahova. Deci, intrarea originală a în tabelul lookup are următoarea schemă:

Cheia_Client Nume Județ

1001 Cosmin Prahova

Mai târziu în timp, în februarie 2004, el s-a mutat în Râmnicu Vâlcea, județul Vâlcea. Cum ar trebui Mobexpert să schimbe intrarea în tabel pentru a reflecta această schimbare? Acest lucru reprezintă problema schimbării lente a dimensiunilor.

În general există trei moduri de a rezolva acest tip de problemă și sunt clasificate după cum urmează:

noua înregistrare să o înlocuiască pe cea originală. În acest caz nu ar mai exista nicio urmă a vechii înregistrări;

o nouă înregistrare să fie adăugată în tabelul de dimensiuni al clientului. Atunci clientul respectiv va fi tratat ca fiind doi oameni diferiți;

înregistrarea inițială să fie modificată astfel încât schimbarea să fie reflectată.

Să luăm pe rând cele trei moduri.

Modul 1. Aici noua informație pur și simplu rescrie informația originală. Cu alte cuvinte, nu se menține niciun istoric.

În exemplul original, avem următoarea intrare în tabel:

Cheia_Client Nume Județ

1001 Cosmin Prahova

Care după mutarea lui Cosmin în Râmnicu Vâlcea va deveni:

Cheia_Client Nume Județ

1001 Cosmin Vâlcea

Avantaje: Aceasta este cea mai simplă cale de a gestiona problema schimbării lente a dimensiunilor, cum nu există nicio nevoie de a ține evidența informației vechi.

Dezavantaje: Tot istoricul este pierdut. Prin aplicarea acestei metodologii, nu este prosibilă o căutare în istoric. De exemplu, în acest caz, compania nu ar mai fi capabilă să știe faptul că clientul a locuit în Prahova înainte.

Acest mod ar trebui să fie folosit doar în cazurile în care nu este necesar pentru depozitul de date să țină și evidența schimbărilor istorice.

Modul 2. Aici avem de a face cu adăugarea unei noi înregistrări în tabel, ceea ce înseamnă informație nouă. Prin urmare, ambele înregistrări, atât cea originală, cât și cea nouă vor fi prezente. Noua înregistrare are propria cheie primară.

Astfel că exemplul de mai sus devine:

Cheia_Client Nume Județ

1001 Cosmin Prahova

1004 Cosmin Vâlcea

Avantaje: Acest mod permite acuratețea păstrării informației istorice.

Dezavantaje: Acest mod va cauza creșterea rapidă a mărimii tabelului. În cazuri unde numărul de rânduri pentru tabel este foarte mare de la început, stocarea și performanța pot deveni o problemă. Un alt dezavantaj ar fi faptul că acest mod complică procesul ETL.

Modul 2 ar trebui să fie folosit doar în cazurile în care este necesar ca depozitul de date să urmărească schimbările din istoric.

Modul 3. Aici vom avea două coloane pentru a indica atributul particular de interes – una pentru a indica valoarea curentă și una pentru a indica valoarea originală. Va exista de asemenea o coloană care să indice atunci când valoarea curentă devine activă.

În exemplul considerat mai sus, avem tabelul:

Cheia_Client Nume Județ

1001 Cosmin Prahova

Pentru a îndeplini modul 3, avem nevoie de următoarele coloane:

Cheia_Client;

Nume;

Județ_Original;

Județ_Curent;

Data_Efectivă.

După ce Cosmin s-a mutat din Prahova în Vâlcea, informația originală se actualizează și vom avea următorul tabel (presupunând că data efectivă a schimbării este februarie 4, 2004):

Cheia_Client Nume Județ_Original Județ_Curent Data_Efectivă

1001 Cosmi Prahova Vâlcea 04-FEB-2004

Avantaje: Acest mod nu crește mărimea tabelului, având în vedere faptul că informația este actualizată. Un alt avantaj este faptul că sunt reținute anumite aspecte din istoric.

Dezavantaje: Acest mod nu este capabil să rețină tot istoricul. De exemplu, dacă clientul Cosmin se va muta mai târziu în Cluj, în data de 15 August 2004, informația mutării în Vâlcea va fi pierdută.

Acest mod 3 este foarte rar folosit în practică. Ar trebui să fie folosit doar atunci când este necesar ca depozitul de date să urmărească schimbările istorice, iar acestea se vor întâmpla de un număr finit de ori.

Tabele de fapte care nu conțin fapte sunt tabele care nu au măsuri. Este esențial să existe o intersecție a dimensiunilor. La suprafață, un tabel de fapte care nu conține fapte nu are nicio utilitate, având în vedere faptul că un tabel de fapte se referă la fapte. Totuși, există situații în care având acest fel de relație, are sens în data warehouse.

De exemplu, să ne gândim la o înregistrare pentru prezența unui student la cursuri. În acest caz, tabela de fapte ar consta din trei dimensiuni: dimensiunea student, dimensiunea timp și dimensiunea curs. Acest tabel de fapte care nu conține fapte, ar arăta astfel:

PREZENȚA:

ID_Student

ID_Curs

ID_Timp

Singura măsură care poate fi atașată combinației este „1” pentru a arăta prezența unei combinații particulare. Totuși, adăugând un fapt care întotdeauna va afișa 1 este redundant, deoarece se poate pur și simplu folosi funcția COUNT din SQL pentru a rezolva aceeași prolemă.

Tabelele de de fapte care nu conțin fapte oferă cea mai mare flexibilitate pentru proiectarea depozitului de date. De exemplu, se pot răspunde ușor următoarelor întrebări cu acest tip de tabel:

Câți studenți au fost prezenți la un anume curs într-o anume zi?

La câte cursuri, în medie, este prezent un student, într-o anume zi dată?

Fără a folosi un astfel de tabel, ar trebui să avem două tabele separate de fapte pentru a răspunde la întrebările de mai sus. Având tabelul de mai sus, fara fapte, devine singurul tabel de fapte de care este nevoie.

3.4 Junk Dimension, conformed dimension

În design-ul unui data warehouse, se întâmplă frecvent situații unde există câmpuri de tip yes/no în sursa sistemului. Din analiza business, se știe că este necesar să se păstreze această informație în tabela de fapte. Totuși, dacă toată această informație va fi păstrată în tabela de fapte, nu numai că va trebui să construim mai multe tabele de dimensiune mică, dar și totalul informației stocată în tabela de fapte de asemenea va crește substanțial, având consecințe asupra performanței și a managementului.

Maniera în care se poate rezolva această problemă este printr-o dimensiune junk. Într-o astfel de dimensiune se combină câmpurile indicatoare într-o singură dimensiune. În acest fel, va trebui să construim un singur tabel dimnesiune, iar numărul de câmpuri din tabela de fapte, la fel ca și mărimea acesteia, pot descrește. Conținutul unui tabel de tip junk dimension este combinația tuturor valorilor posibile ale câmpurilor individuale indicatoare.

Să luăm în considerare următorul exemplu de tabel de fapte:

ID_Client

ID_Produs

ID_TXN

ID_Magazin

Cod_TXN

IND_Cupon

IND_Prepay

AMT_TXN

În acest exemplu, Cod_TXN, IND_Cupon și IND_Prepay reprezintă câmpurile indicatoare. În acest format, fiecare dintre ele este o dimensiune. Folosind principiul dimensiunii junk, pot fi combinate într-o singură dimensiune junk, rezultând următorul tabel de fapte:

ID_Client

ID_Produs

ID_TXN

ID_Magazin

ID_Junk

AMT_TXN

Acum numărul de dimensiuni din tabela de fapte a scăzut de la 7 la 5.

Conformed dimension (dimensiune conformată) reprezintă o dimensiune care are exact același înțeles și conținut atunci când este referită în diferite tabele de fapte. O dimensiune conformată poate să refere multiple tabele în multiple data marts în aceeași organizație. Pentru ca două tabele dimensiune să fi considerate conformate, ele trebuie fie să fie identice, sau unul dintre ele trebuie să fie un subset al celuilalt. De exemplu, două tabele dimensiune sunt exact la fel, exceptând cheia primară, care nu este considerată ca fiind dimensiune conformată.

De ce dimensiunea conformată este importantă?

Acest lucru este strâns legat de definiția unui data warehouse integrat. Integrat înseamnă că chiar dacă entitățile individuale au atribute diferite în sursa sistemelor, trebuie să fie o singură versiune a unei entități odată ce datele fluctuează în depozitul de date.

Dimensiunea timp este o dimensiune conformată comună într-o organizație. De obicei, singura regulă care trebuie să fie luată în considerare cu această dimensiune este dacă este un an fiscal în relație cu anul calendaristic și definiția unei săptămâni. Din fericire, ambele sunt relativ ușor de rezolvat. În cazul unui an fiscal vs. an calendaristic, una poate fi fie fiscală sau calendaristică, sau ca o alternativă eficientă este să existe una pentru anul fiscal și încă una pentru anul calendaristic. Definiția unei săptămâni este de asemenea ceva care poate fi diferit în organizațiile foarte mari: departamentele financiare pot folosi de Duminică până Vineri, pe când cele de marketing pot folosi de Duminică până Sâmbătă. În acest caz, ar trebui decisă care anume definiție trebuie luată în considerare pentru a putea continua. Un lucru avantajos în legătură cu dimensiunea timp este faptul că odată ce sunt stabilite regulile, valorile din tabelul dimensiune nu se vor schimba niciodată. De exemplu, data de 19 August nu va deveni niciodată data de 20 în August.

Nu toate dimensiunile conformate sunt ușor de folosit pentru a produce dimensiunea timp. Un exemplu este dimensiunea client. În orice organizație cu ceva istoric, există o mare probabilitate să existe mai multe baze de date cu clienți în diferite părți ale organizației. Pentru a îndeplini dimensiunea client conformată, înseamnă că toate acele date trebuie comparate unele cu altele, regulile trebuie stabilite și datele curățate. În plus, atunci când se fac incrementări de date într-un depozit de date, va trebui să aplicăm aceleași reguli și pentru noile valori pentru a fi siguri că adăugăm cu siguranță noi clienți adevărați pentru dimensiunea client.

Construirea dimensiunilor conformate este o parte a procesului de master data management, sau MDM. În MDM, nu trebuie doar să ne asigurăm de faptul că dimensiunile de master data sunt conformate, dar și de conformitatea care trebuie adusă înapoi sistemelor sursă.

Master Data Management se referă la procesul de creare și gestionare a datelor în organizație, proces care trebuie să aibă o singură copie master, master data.

De obicei, master data include clienții, vânzătorii, angajații și produsele dar poate diferi în funcție de fiecare industrie în parte și chiar diferite companii din cadrul aceleiași industrii. MDM este important deoarece oferă întreprinderii o singură versiune a adevărului. Fără o definire clară a conceptului de maste data, firma riscă să aibă multiple copii ale datelor care sunt inconsistente unele cu altele.

MDM este de regulă mai important în companii mari. De fapt, cu cât este mai mare organizația, cu atât este mai importantă disciplina MDM, deoarece o organizație mare, înseamnă că sunt mai multe sisteme disparate în cadrul ei, iar dificultatea de a avea o singură față a adevărului, precum și de a beneficia de master data, crește cu fiecare sursă de date adițională. O provocare particulară și foarte mare de a menține master data se întâmplă atunci când există o nouă achiziție. Fiecare organizație are propriul sistem de master data, și felul în care se concatenează două seturi de date poate reprezenta o provocare. Două companii au identificatori unici pentru fiecare client în parte. Adresele și numerele de telefon s-ar putea să nu se potrivească. Una dintre ele poate avea numele dinaintea căsătoriei, iar cealaltă numele curent. Una poate avea un nickname, pe când cealaltă poate avea numele întreg. Toate aceste lucruri contribuie la dificultatea în creare și menținere a unui singur set de date master.

Data Management și Data Warehousing au foarte multe lucruri în comun. De exemplu, efortul transformării datelor și curățarea este foarte similar cu procesul ETL în data warehousing și, de fapt pot folosi aceleași instrumente ETL. În lumea reală, nu este necomun să apară MDM și data warehousing în același proiect. Există, pe de altă parte și o serie de diferențe între cele două, dintre care cea mai importantă este scopul fiecărei tehnologii: data warehousing se referă la analiza datelor pe când MDM se referă la menținerea unei singure versiuni a adevărului datelor într-o companie, pentru o dimensiune particulară.

bibliography

The Bibliography title is written in B_Bibliography title, Calibri 12 pct, all caps, expanded spacing with 2 pt, centered.

References are numbered according to the order of their appearance in text. Text references are indicated by the number of the title between square brackets, such as [2].

Each bibliographic entry should mention: initial of the first name, family name, title, publishing house, place and year or periodical title, volume, number, year, initial and final pages. Authors names are written in italics (10 pct).

For Romanian books and articles a translation of the title will be inserted in parentheses.

[1] Conf.dr.ing. Mariana MOCANU Catedra de Calculatoare, Universitatea “Politehnica” Bucuresti, “Folosirea data warehouse în asistarea activitatii de retail partea I”

[2] http://data-warehouses.net/architecture/overview.html

[3] http://www.1keydata.com/datawarehousing/star-schema.html

[4] *** COSMOS/M – Finite Element System, User Guide, 1995.