DEPOZITE DE DATE

BAZE DE DATE PENTRU

SUSŢINEREA PROCESULUI DECIZIONAL

• Sistemele care ajutǎ la analizarea informaţiior din domeniul afacerilor sunt sisteme de susţinere a deciziilor. Ele sunt destinate sǎ ajute conducerea sǎ determine tendinţele, sǎ identifice problemele şi, ca o consecinţǎ, sǎ ia decizii inteligente. Ceea ce leagǎ aceste sisteme de bazele de date este cerinţa de a aduce datele dintr-o bazǎ de date tranzacţionalǎ la o formǎ care poate analiza mersul unei afaceri şi poate modifica acest comportament prin decizii pertinente.

• Pe baza datelor furnizate de către activitatea unei firme se pot lua decizii de genul:

• Pe un anumit interval de ore este nevoie de mai mult personal pentru îndeplinirea sarcinilor administrative.

• În fiecare lună mai creşte vânzarea unui anumit produs, în consecinţă stocurile trebuiesc mărite.

• Anumiţi clienţi cumpără mai mult deci trebuie păstraţi prin oferirea de discount-uri sau bonusuri etc.

• Aceste decizii se pot lua din informaţiile oferite de slecţii sau de grafice.

• Începuturile acestor probleme se situeazǎ în anii 60, 70 când la Harvard şi MIT se promoveazǎ utilizarea calculatoarelor pentru asistenţǎ în procesul decizional. Utilizarea a fost atunci limitatǎ la generarea rapoartelor. În anii 70 se dezvoltǎ câteva limbaje de interogare şi, legat de acestea, sisteme de susţinere a procesului decizional implementate cu ajutorul unor generatoare de rapoarte ca RPG (Report Program Generator) şi programe de consultare a datelor ca Focus, Datatrieve sau NOMAD. Acestea au fost primele care au permis utilizarea datelor de cǎtre decidenţi fǎrǎ asistenţa informaticienilor (cu o pregǎtire prealabilǎ).

• O bazǎ de date pentru susţinerea procesului decizional diferǎ de o bazǎ de date OLTP (on line transaction processing) adicǎ tranzacţionalǎ, prin faptul cǎ datele de aici sunt ‘moarte’. Înţelegem prin aceasta cǎ ele nu se mai actualizeazǎ şi sunt folosite, în general, numai pentru interogǎri. Actualizǎrile constau eventual numai din reîmprospǎtǎri ale datelor. Deducem de aici importanţa corectitudinii datelor care se preiau într-o asemenea bazǎ de date.

• Iatǎ şi alte caracteristici speciale ale acestor baze de date:

• - Coloanele sunt utilizate mai des în combinaţii.• - Foarte des cheile au în componenţǎ un atribut

temporal.• - Datoritǎ acumulǎrii în timp a datelor, baza de

date are dimensiuni foarte mari.• - Baza de date este indexatǎ dupǎ multe câmpuri.• - Datele au o redundanţǎ mult mai mare decât

cea permisǎ într-o bazǎ de date tranzacţionalǎ.

• În interogǎrile cǎtre aceste baze de date apar complicaţii ca:• Expresii booleene complexe. • Complexitatea joncţiunilor. Aceastǎ problemǎ este cel mai des

rezolvatǎ prin denormalizǎri.• Necesitatea unui mare numǎr de funcţii statistice şi matematice.• Complexitatea analizelor ce trebuiesc efectuate, nu întotdeauna

cunoscutǎ complet de la început, duce la divizarea interogǎrilor cu pǎstrarea rezultatelor intermediare (care pot fi folosite şi la interogǎri ulterioare) şi, deci, la creşterea volumului bazei de date.

• Aceste particularitǎţi impun o proiectare fizicǎ orientatǎ spre performanţe.

PROIECTAREA LOGICĂ

• Din puct de vedere al proiectǎrii logice, J.C.Date (pǎrerea unei asemenea autoritǎţi trebuie luatǎ în considerare) scrie în [ ] cǎ deşi acest tip de baze de date este destinat numai citirii şi integritatea este verificatǎ la încǎrcare, totuşi nu trebuie trecutǎ cu vederea valoarea semanticǎ a dependenţelor funcţionale, care ajutǎ la formularea interogǎrilor. Deducem cǎ proiectarea logicǎ trebuie sǎ urmeze aceeaşi cale ca şi cea pentru baze obişnuite de date (adicǎ OLTP).

• O atenţie deosebitǎ trebuie acordatǎ cheilor temporale. Bazele de date operaţionale conţin numai date curente, dar bazele de date pentru susţinerea procesului decisional conţin date istorice, deci majoritatea datelor vor avea adǎugatǎ o componentǎ temporalǎ (care sǎ indice data la care s-a întâmplat evenimentul respectiv) care, în general, va intra în componenţa cheii.

• Vom folosi, în continuare, pentru exemplificǎri urmǎtorul exemplu:

• Sǎ considerǎm , simplificând, baza de date a vânzǎrilor unui mare magazin, de exemplu METRO, care vinde numai pe facturǎ. Schema ar fi:

• clienţi=(cod_client,nume_client,adresa)• facturi=(nr_facturǎ,cod-

client,data_facturii,procent_tva,banca,nr_cont)• detaliu_facturǎ=(nr_facturǎ,cod_produs,cantitate)• produse=(cod_produs,denumire_produs,preţ_vânzare)

• , schema, şi mai simplificatǎ, ar putea arǎta astfel:• clienţi=(cod_cl,nume_cl)• fact=(nr_fac,cod_cl,data)• detaliu=(nr_fac,cod_pr,cant)• produs=(cod_pr,den_pr,pr_vanz) unde prescurtǎrile

sunt evidente.• Dacǎ facem o analizǎ a vânzǎrilor, ne va interesa , de

fapt, o schemǎ rezultatǎ prin joncţiune între fact şi detaliu în care nr_fact nu mai conteazǎ.

• vanzari=(cod_cl,data,cod pr,cant)

• O instanţǎ a acestui tabel, în care am simplificat şi data punând doar luna vânzǎrii, ar putea arǎta astfel:

Cod_cl data Cod_pr cant

Cl1 1 P1 10

Cl1 3 P2 20

Cl2 2 P2 30

Cl2 3 P3 20

Cl2 6 P3 10

Cl3 3 P1 15

Cl3 7 P1 30

Cl3 9 P2 50

Cl3 11 P4 25

• Cheia este subliniatǎ şi conţine, evident, data. Vom menţine şi tabelele client şi produs dar joncţiunile cu aceste tabele se vor face numai în rezultatele finale, pentru decodificare.

PROIECTAREA FIZICĂ

• Pin proiectarea fizicǎ vom urmǎri sǎ optimizǎm performanţele analizelor ce se vor efectua. Problemele sunt puse de cantitatea mare de date şi de timpii de cǎutare şi agregare a datelor.

• Pentru a rezolva problemele de spaţiu de stocare şi capacitate de calcul, dar şi pentru a se face adaptarea la condiţii de repartizare geograficǎ, se va apela la segmentarea bazei de date. Problema este aceeaşi ca la bazele de date distribuite.

• Pentru cǎ firmele producǎtoare de soft nu se preocupǎ de segmentarea verticalǎ, dar nu numai din aceastǎ cauzǎ, segmentarea se face pe orizontalǎ, adicǎ printr-o operaţie relaţionalǎ de selecţie. De exemplu baza de date a unei reţele de magazine METRO va fi repartizatǎ în punctele geografice în care existǎ magazine METRO.

• Din necesitatea accesǎrii dupǎ multe criterii, rezultǎ cǎ baza de date va fi puternic indexatǎ. Diversele criterii însǎ dau şi performanţe diferite ale indexǎrii aşa cǎ se folosesc diferite moduri de indexare.

• Iatǎ câteva:

• arbori balansaţi B+.

• indexǎri bitmap.

• tabele de repartizare.

• indexǎri pentru tabele multiple.

• indexǎri booleene.

• indexǎri funcţionale.

• Redundanţa controlatǎ este folositǎ într-o bazǎ de date pentru susţinerea deciziilor mai mult decât în alte tipuri de baze de date. Ea trebuie sǎ aibe o rezolvare fizicǎ deci nu trebuie sǎ afecteze proiectul logic.

• Se folosesc douǎ feluri de redundanţǎ:

• menţinerea unor copii exacte ale bazei de date sau ale unor pǎrţi ale bazei.

• Menţinerea datelor derivate.

• Sǎ vedem, pe rând ce implicaţii au acestea.

COPIILE

• Reproducerea poate fi sincronǎ sau asincronǎ:• Spunem cǎ reproducerea este sincronǎ dacǎ

actualizarea unei copii implicǎ actualizarea simultanǎ a tuturor copiilor. Rezultǎ cǎ vom avea mereu aceeaşi versiune pe toate ‘bucǎţile’ bazei de date. Dezavantajul este cǎ se supraîncarcǎ sistemul şi este posibil ca unele dintre copii sǎ nu poatǎ fi actualizate chiar în acel moment caz în care trebuie reluatǎ toatǎ aplicaţia.

• Dacǎ avem reproducere asincronǎ copiile se actualizeazǎ la momente ulterioare primei actualizǎri. Se câştigǎ în independeţa site-urilor, dar datele nu mai sunt tot timpul exact la fel pe toate copiile. Din cauza diferenţei de timp, se poate ajunge la inconsistenţa datelor. Din aceastǎ cauzǎ se preferǎ un alt mod care se numeşte administrarea copiilor. Aceasta înseamnǎ cǎ propagarea actualizǎrilor nu se mai face automat, ci of line într-un proces pe loturi (batch) care nu este simultan cu tranzacţiile.

DATELE DERIVATE

• Datele derivate pot fi coloane calculate sau tabele de sintezǎ. Acestea sunt noi pentru cǎ nu le permiem, în general într-o bazǎ de date tranzacţionalǎ. Din cauzǎ cǎ aceleaşi date se calculeazǎ de multe ori este preferabilsǎ le menţinem gata calculate în baza de date. Mai mult, pentru cǎ baza se actualizeazǎ foarte rar sau de loc datele calculate nu riscǎ sǎ deterioreze integritatea bazei de date.

• Coloana calculatǎ este un atribut care, pe un tuplu, se calculeazǎ din date aflate în acelaşi tuplu. De exemplu, dacǎ la tabela anterioarǎ am adǎuga şi preţul, o coloanǎ calculatǎ ar fi valoarea, care, într-o asemanea bazǎ de date nu ar mai suferi actualizǎri deci nu ar putea duce la pierdera consistenţei.

• O tabelǎ de sintezǎ este o tabelǎ care conţine rezultatul unor calcule fǎcute pe alte tabele (însumǎri, medii, contorizǎri etc…). Ele sunt prezente în cǎrţi sub diferite denumiri: tabele de sintezǎ automatǎ (AST – automatic summary table), tabel de interogǎri materializate (MQT – materialized query table), instantane, vederi materializate etc….

PREGĂTIREA DATELOR

• Aceasta este o etapǎ foarte importantǎ, de care depinde corectitudinea analizelor care se vor efectua pe baza de date pentruu susţinerea deciziilor. Ea cuprinde extragerea, curǎţarea, transformarea şi unificarea.

EXTRAGEREA DATELOR

• Este operaţia de preluare a datelor din baze de date tranzacţionale şi din alte surse. Important este ca operaţia sǎ nu interfereze cu operaţiile tranzacţionale obişnuite ale bazelor de date implicate pentru a nu se pierde integritatea . Tot cu acelaşi scop se adaugǎ, uneori, chei surogat de tip autonumber introducând chei strǎine şi evitând, astfel, folosirea pointerilor.

CURĂŢAREA

• Pentru cǎ sursele sunt foarte diverse, calitatea datelor ce urmeazǎ sǎ fie introduce trebuie controlatǎ în prealabil. Operaţiile de curǎţare sunt:

• completarea valorilor lipsǎ• corectarea erorilor tipografice• stabilirea unor prescurtǎri uniforme• înlocuirea uniformǎ a sinonimelor cu acelaşi

cuvânt• respingerea datelor ce nu pot fi curǎţate

TRANSFORMAREA ŞI UNIFICAREA

• Forma fizicǎ, în concordanţǎ cu schema logicǎ a bazei de date pentru susţinerea deciziilor, este diferitǎ de forma pe care o au datele sursǎ, de aceea ele trebuie sǎ fie aduse la o formǎ convenabilǎ pentru încǎrcare. În timpul procesului de transformare, se creazǎ relaţii noi care pot duce la identificarea altor erori în datele sursǎ. Datele incorecte sunt, de regulǎ, respinse. Sursele fiind diverse, este nevoie de o unificare a diverselor scheme, de corelare a datelor care poate presupune şi o sincronizare a timpului.

ÎNCĂRCAREA

• . Distingem şi aici mai mulţi paşi:• Mutarea datelor din fişiere intermediare obţinute la

operaţiile anterioare. Se poate întâmpla ca sǎ fie nevoie de o transformare în formatul fizic intern cerut de SGBD-ul ţintǎ.

• Verificarea integritǎţii se poate efectua, în general, înaintea încǎrcǎrii propriuzise, în tabele inermediare. Totuşi unele verificǎri (de exemplu verificarea unicitǎţii) nu pot fi efectuate decât în momentul încǎrcǎrii.

• Indexǎrile se pot efectua chiar pas cu pas la încǎrcare, sau dupǎ încǎrcare. Dupǎ caz poate fi mai rapidǎ o procedurǎ sau cealaltǎ.

REÎMPROSPĂTAREA

• Bazele de date pentru susţinerea deciziilor conţin date istorice ,dar dupǎ un timp trebuie adǎugate datele corespunzǎtoare timpului scurs. În general este vorba despre simple adǎugǎri de date, dar în unele cazuri poate fi vorba de reluarea de la zero a încǎrcǎrii. Operaţia are aceiaşi paşi ca şi încǎrcarea şi presupune, deseori, execuţia în paralel cu acţiunea tranzacţionalǎ, fapt care poate crea probleme în plus.

MAGAZIILE DE DATE OPERAŢIONALE

• Denumirea ODS vine de la Open Data Storage. O astfel de bazǎ de date este o colecţie de date orientate spre subiect, integrate, volatile, curente sau aproape curente.

• Sǎ observǎm , din aceastǎ definiţie, cǎ:• datele se referǎ la un anumit subiect, de obicei destul de

restrâns. De exemplu produse sau vânzǎri.• Sunt integrate adicǎ tabelele sunt legate între ele ca şi într-

o bazǎ de date tranzacţionalǎ.• Cǎ sunt volatile înseamnǎ cǎ se pot actualiza (chiar şi

şterge).• Curente sau aproape curente vrea sǎ spunǎ cǎ sut date

obţinute la zi sau pe o perioadǎ scurtǎ de timp înainte. Se îndeplineşte astfel scopul principal al acestui tip de bazǎ de date, care este de a servi pentru decizii operative.

• Magaziile de date operaţionale nu ajung foarte mari, pentru cǎ nu acumuleazǎ date pe o perioadǎ mare de timp.

DEPOZITELE DE DATE

• Pǎstrând acelaş stil de definiţii, depozitele de date sunt magazii de date orientate spre subiect, integrate, nevolatile, cu character pronunţat temporal, folosite pentru susţinerea deciziilor.

• pentru a oferi o singurǎ sursǎ de date, curatǎ şi consistentǎ pentru susţinerea deciziilor

• pentru a realiza acea susţinere a procesului decisional independent de procesul tranzacţional

• pentru a limita, pe cât posibil, memoria necesarǎ

PIEŢELE DE DATE

• Utilizând depozitele de date s-a constatat cǎ, pentru o anumitǎ problemǎ, se foloseşte doar o micǎ cantitate de date, mereu aceeaşi şi în acelaşi mod agregate. Aceste date pot fi extrase din depozitul de date , sau create direct din bazele de date tranzacţionale, agregate corespunzǎtor, şi folosite itens pentru interogǎri rapide. Se obţine astfel o piaţǎ de date. Deci piaţa de date este o bazǎ specialǎ de date, orientatǎ spre subiect, integratǎ, volatilǎ (pentru cǎ se pot adǎuga tabele noi, relaţii noi…) cu caracter pronunţat temporal, cu scopul susţinerii deciziilor.

• De observat cǎ este importantǎ granulaţia, înţeleasǎ aici ca nivel de combinare a datelor, fie prin selecţie (ex. date legate numai de un singur produs), fie prin operaţii asupra datelor (ex. date referiroare la valoarea vânzǎrilor pe luni, care se obţin prin înmulţiri şi însumǎri). Cel mai scǎzut nivel de agregare rǎmâne în sursǎ (de exemplu în depozitul de date) şi poate fi oricând recuperat dacǎ apar noi necesitǎţi.

PRELUCRAREA ANALITICĂ ONLINE

• Putem defini acest termen ca fiind procesul interactive de creare, administrare, analizǎ a datelor şi de editare de rapoarte din aceste date.

• Sǎ reluǎm exemplul nostru:

• Tabelul VANZ

• Sǎ presupunem cǎ vrem sǎ obţinem de aici:

• cantitatea totalǎ vândutǎ (ar fi fost mai normal valoarea totalǎ)

• cantitǎţi pe client

• cantitǎţi pe produs

• cantitǎţi totale pe client şi pe produs

• În SQL cele patru interogǎri ar fi:

• 1) SELECT SUM(CANT) AS CTOT

• FROM VANZ

• GROUP BY ()

• Rezultatul este tabela cu o singurǎ linie:

• SELECT CODCL, SUM(CANT ) AS CANPECL

• FROM VANZ

• GROUP BY (CODCL)

• Cu rezultatul:

• Cantitǎţi pe produs:

SELECT CODPR, SUM(CANT) AS CANTPEPR

FROM VANZ

GROUP BY (CODPR)

Cu rezultatul:

Cantitǎţi totale pe client şi produs:

SELECT CODCL,CODPR,SUM(CANT) AS CATOT

FROM VANZ

GROUP BY(CODCL, CODPR)

Cu rezultatul:

• Având în vedere cǎ aceleaşi date sunt parcurse de mai multe ori cu însumǎri asemǎnǎtoare s-au introdus în SQL opţiuni noi legate de clauza GROUP BY.

• Acestea sunt GROUPING SETS, ROLLUP şi CUBE.

• SELECT CODCL,CODPR, SUM(CANT) AS CATO• FROM VANZ• GROUP BY GROUPING SETS((CODCL), (CODPR))• Are ca efect tabela:

• Care dǎ cu o singurǎ instrucţiune echivalentul exemplelor 1) şi 2). A se observa cǎ Null-urile nu au chiar aceeşi semnificaţie pe cele douǎ coloane.

• SELECT CODCL,CODPR, SUM(CANT) AS CATO• FROM VANZ• GROUP BY ROLLUP (CODCL,CODPR)• Care dǎ tabela:

• Unde se vede cǎ au fost considerate grupuri successive (CODCL,CODPR), (CODCL), ( ).

• Acestǎ instrucţiune dǎ rezultatul cumulat al exemplelor 1), 2), 4).

• SELECT CODCL,CODPR, SUM(CANT)• FROM VANZ• GROUP BY CUBE (CODCL, CODPR)• Care dǎ rezultatele cumulate ale celor 4

exemple cu atenţia necesarǎ la interpretarea valorilor de Null.

• Mai facem specificarea cǎ în clauza GROUB BY se pot introduce speecificaţiile anterioare în orice combinaţie.

TABELĂRI ÎNCRUCIŞATE

• O sǎ arǎtǎm pe un exemplu ce înseamnǎ o astfel de tabelǎ. Considerând vânzǎrile pe client şi produs obţinem:

• Sǎ observǎm cǎ am scǎpat de Null-uri şi valorile zero au o semnificaţie mult mai naturalǎ. Totuşi, deoarece numǎrul de coloane depinde de datele effective, nu putem asocial un format clar acestor tabele. Deasemenea, putem avea o mulţime de zero-uri ceea ce duce la rapoarte nejustificat de mari.

• Un astfel de tabel poate conţine chiar toate informaţiile care se obţin prin opţiunea CUBE.

• Acest mod de a vedea datele face o trecere de la ROLAP (Relational OLAP) la MOLAP(Multidimensional OLAP). Putem stoca tabele cu mai multe dimensiuni. De exemplu putem adǎuga, în exemplul nostru, dimensiunea data şi la intersecţia dimensiunilor client, produs data sǎ se afle cantitatea respectivǎ (ca într-un tablou multidimensional, dar la care indicii sunt luaţi din date). Se observǎ uşor cǎ nu vom avea valori la toate intersecţiile, deci tabelele au tendinţa de a fi rǎrite; de aici o capacitate scǎzutǎ de stocare, dar şi o vitezǎ sporitǎ de rǎspuns la interogǎri.

ANALIZA EXPLORATORIE

• Este vorba despre anliza datelor cu scopul de a stabili tipare care sǎ ajute dezvoltarea afacerii. De exemplu sǎ considerǎm un tabel cu vânzǎri care are schema:

• VANZ=(COS,DATA,PRODUS,CLIENT)

• COS aici înseamnǎ ceea ce s-a cumpǎrat la o singurǎ trecere prin magazin.

• Un exemplu ar fi

• Putem descoperi cǎ, de regulǎ, cel care cumpǎrǎ ROSIE cumpǎrǎ şi CEAPA. Cumpǎrǎ ROSIE este premiza , iar cumpǎrǎ CEAPA este consecinţa şi aceastǎ legǎturǎ are un coefficient de încredere. Mulţimea tranzacţiilor la care se aplicǎ regula (adicǎ unde se verificǎ premiza) este susţinere. În exmplul mostru susţinerea este de 4/11=36% iar încrederea este de ¾=75%. Putem avea multe idei de a stabili legǎturi. Unele legǎturi pot avea pronunţat character temporal. De exemplu cine a cumpǎrat azi CEAPA cumpǎrǎ mai târziu PASTA DE DINTI.