Baze de Date Vs. Depozite de Date

Cuprins

Cap1 BAZE DE DATE

SGBD

Clasificarea bazelor de date

Structura si restrictiile unei baze de date relationale

Baze de date in Acces

Arhitectura bazei de date

Utilizarea bazelor de date in ACCES

Cap2 DEPOZITUL DE DATE

Extragerea de date

Organizarea datelor in DD

Arhitectura DD

Realizarea unui DD

Concepte de baza

Cap3 DEPOZITE DE DATE VS. BAZE DE DATE

Comparare sistem OLTP si OLAP

BIBLIOGRAFIE

1. Baze de date

Baza de date sau “banca de date” e o modalitate de stocare a unor date si informatii pe un dispozitiv de stocare(support extern) cu posibilitatea de a fi regasite usor.Aceasta baza de date este memorata in unul sau mai multa fisiere ce pot fi manipulate cu ajutorul sistemelor de gestiune(SGBD) care sunt reprezentate de totalitatea programelor utilizate pentru crearea,interogarea si intretinerea bazelor de date.

Baza de date este o colectie de fisiere interconectate care contin nucleul de date necesare sistemului informatic fiind constituite deorice mesaj primit.

Bazele de date fac parte din viata noastra zilnica si constituie cadrul sistemelor informationale si sunt intr-o modificare permanenta a modului de operare al organizatiilor.

Astfel incat in ultimii ani,mediul economic a suferit o serie de schimbari,cum ar fi comportamentul consumatorului;saturarea pietei;noile segmente de piata,noile;metode de marketing si canalele dedistributie;ciclul de viata mai scurt al anumitor produse;cresterea competitiei si a riscului in afaceri, acestea fiid datorate noilor baze de date.Baza de date este un deposit de date unic ,de mari dimensiuni,care este definit o singura data fiind utilizat de mai multe departamente si in acelasi timp de mai multi tilizatori,asaca in loc sa

fie mai multe fisiere separate,ele sunt grupate si integrate intr-o bazabaza de date.

O baza de date evolueaza in timp in functie de volumul si complexitatea proceselor,operatiunilor si fenomenelor pe care le reflecta.

Intr-o abordare mai analitica , o baza de date este un ansamblu de date:

Structurate,

Coerente,

Neredundante,

Independente de orice aplicatie,

Direct accesibile.

1.1 Sistemul de gestiune al bazelor de date

Sistemul de gestiune a bazelor de date (SGBD) este interfata intre utilizator si baza de date care are ca rol crearea , actualizarea si consultarea acesteia.Sistemul de gestiune a datelor este de fapt un instrument pentru asamblarea , codificarea, protectia si regasirea datelor di baza de date,SGBD are ca scop principal separarea datelor fata de programele de aplicatie care se realizeaza prin abstractizarea datelor memorate in baza de date O baza de date este reprezentata pe trei tipuri de niveluri. : extern : conceptual si intern,,acestora le corespunde o schema a bazei de date.

Schema externa presupune stabilirea efectiva a datelor ce nu constituie obiectul bazei de date,fiind o subschema a schemei conceptuale .

Schema interna implementeaza schema conceptuala prin utilizarea unui SGBD. O baza de date poate avea definite mai multe scheme externe , o singura schema conceptuala si o singura schema interna.

Principalele obiective ale unui SGBD sunt:

Independent fizica a datelor,ce consta in capacitatea de a schimba organizarea interna a datelorsi structurilor de inregistrare , fara a modifica programele de utilizator.

Independent logica a datelor consta in posibilitatea modificarii schemei externe fara a modifica schema conceptuala,rezultand din necesitatile utilizatorilor de a-si modifica in timp cerintele informationale.

Manipularea datelor .

Administrarea cat mai facila a datelor. Punanduse la dispozitie instrumente pentru descriera datelor din schema externa cat si din schema externa.

Performante sporite de acces la date

Functiile unui SGBD sunt:

Memorarea pe support extern.

Gestiunea datelor si a legaturilor dintre ele.

Introducerea si ectragera datelor in forma ceruta de utilizator.

1.2 Casificarea bazelor de date

Principalele tipuri de baze de date utilizate de către organizații și utilizatori sunt:

baze de date distribuite,

baze de date deductive,

baze de date multidimensionale,

baze de date orientate pe obiecte,

baze de date multimedia,

depozite de date (datawarehouse),

baze de date textuale.

Baze de date distribuite sunt utilizate de unitățile economice care sunt nevoite să gestioneze bazele de date distribuite. Lucrul în rețea de calculatoare permite distribuirea unei baze de date pe mai multe site-uri. Fiecare site are un gestionar local de tranzacții, deoarece o bază de date distribuită trebuie să dispună întotdeauna de un gestionar de tranzacții.

Avantajele repartizării bazelor de date distribuite sunt:

partajarea datelor și gestiunea distribuită a acestora,

fiabilitatea și disponibilitatea,

prelucrarea accelerată a cererilor.

Baze de date deductive se fundamentează pe legătura unei baze de date relaționale cu un procesor din clasa sistemelor expert.

Baze de date multidimensionale – au apărut ca urmare a necesităților crescânde de procesare multidimensională a datelor. Aplicațiile se bazează pe o analiză multidimensională a datelor denumite OLAP (adica On Line Analytical Processing). Conceptul de bază este cel de hipercub.

Baze de date orientate pe obiecte – dezvoltarea și aplicarea tehnologiei orientate pe obiecte în domeniul bazelor de date a dus la apariția bazelor de date orientate obiecte. O bază de date orientate pe obiecte trebuie să îndeplinească două condiții esențiale:

să îndeplinească cerințele unei baze de date,

să fie un sistem care să aibă la bază tehnologia orientată obiect.

Bazele de date orientate pe obiecte sunt gestionate folosind sisteme de gestiune orientate pe obiecte.

Baze de date multimedia – „se referă la abilitatea de a achiziționa, manipula, combina și reda informații de la o mare varietate de medii, ce includ text, grafică, animație, sunet, imagine fixă sau video.

De aici rezultă și numărul mare de aplicații, și anume:

În informare – multimedia este modul cel mai rapid, eficient și ieftin în comparație cu alte medii de informare a publicului, cuprinzând adevărate enciclopedi electronice.

În administrarea documentelor și a înregistrărilor – în întreprinderi și instituții comerciale, acestea având nevoie de diferite documente, în funcție de specificul lor.

În educație și instruire – în regăsirea materialelor pentru pregătirea tuturor persoanelor.

În reclame – în mod practic nu există nici o limită în folosirea informației multimedia în astfel de aplicații.

În controlul și monitorizarea proceselor în timp real – împreuna cu bazele de date active, prezentările multimedia de informații au un rol efectiv în operațiile de monitorizare și control în sistemele de transport, de supraveghere a pacienților, etc.

Pentru realizarea tuturor acestor aplicații în condiții optime, bazele de date multimedia trebuie ca pe lângă asigurarea unui timp minim de acces la date să garanteze și integritatea, securitatea și independența datelor. Există o serie de probleme ce apar în multimedia, deoarece aplicațiile multimedia conțin mii de imagini statice și dinamice, documente, texte, segmente audio și video, iar organizarea acestora depinde de modelarea structurilor și a conținutului de date.

1.3 Structura și restricțiile unei baze de date relaționale

In abordarea bazelor de date relaționale se au în vedere două aspecte ale acestora:

Schema (structura);

Conținutul (sau instanțierea).

O schemă relațională poate fi definită ca un ansamblu de relații asociate semantic prin domeniul lor de definiție și prin restricții de integritate.

Restricțiile de integritate sunt de trei feluri:

Restricțiile cheilor primare. Fiecare cheie primară este supusă restricțiilor de unicitate;

Restricții referențiale care decurg din existența cheilor străine;

Alte restricții care includ restricțiile de comportament.

În practică, în multe dintre SGBD-uri, integritatea datelor prezintă patru dimensiuni:

Integritatea entității

Integritatea domeniului

Integritatea referențială

Integritatea definită de utilizator

În multe situații, în cadrul unei organizații, este suficientă cunoașterea numai a schemei simplificate. Schema simplificată a unei baze de date relaționale care cuprinde numele tabelelor și enumerarea atributelor acestora, atributele-chei fiind subliniate.

CLIENȚI (Cod_Client, Nume, Adresa, Localitate)

Prezentarea schemei unei baze de date poate fi făcută și grafic. Iată câteva reguli pentru reprezentarea grafică a unei BDR:

O tabelă se reprezintă pe două linii, pe prima fiind scris numai numele relației iar pe cea de-a doua numele atributelor. În general, cheia primară este plasată la marginea stângă a tabelei.

Numele coloanelor ce alcătuiesc cheia primară se subliniază cu o linie continuă, iar cele care alcătuiesc identificatorii secundari se subliniază cu linie punctată;

Numele unei coloane facultative se scrie între paranteze;

Dacă o cheie străină, este alcătuită din mai multe coloane, se utilizează acolada pentru a le grupa;

O restricție referențială este reprezentată printr-o săgeată care pleacă de la numele coloanei de referință și are vârful în atributele tabelei la care se face referință.

1.4 PROIECTAREA CONCEPTUALĂ A BAZELOR DE DATE

Metodologia de proiectare conceptuală a bazelor de date are ca obiectiv construirea unui model de date conceptual local al unei organizații, pentru fiecare vedere a utilizatorilor specificată.Primul pas în proiectarea bazelor de date constă în realizarea unor modele de date conceptuale, pentru fiecare vedere a utilizatorilor asupra organizației.

O vedere a utilizatorului reprezintă datele cerute de către un anumit utilizator pentru a lua o decizie sau a efectua o anumită sarcină. De obicei, vederea unui utilizator constituie o zonă funcțională a organizației, cum ar fi producția, marketingul, vânzările, personalul, contabilitatea.

Modelul de date conceptual se referă la:

tipurile de entități;

tipurile de relații;

atributele;

domeniile atributelor;

cheile candidat;

cheile primare.

În cadrul unei documentații clar stabilite trebuie îndeplinite următoarele sarcini:

identificarea tipurilor de entități;

identificarea tipurilor de relații;

identificarea și asocierea atributelor cu tipurile de entități sau relații;

determinarea domeniilor atributelor;

determinarea atributelor chei candidat și primare;

specializarea / generalizarea tipurilor de entități;

desenarea diagramei Entitate – Relație;

revizuirea modelului de date conceptual local, împreună cu utilizatorul.

1.5 BAZE DE DATE ÎN ACCESS

1.6 ARHITECTURA MICROSOFT ACCESS

Microsoft Access face parte din pachetul de programe Microsoft Office. Este un sistem de gestiune a bazelor de date destinat rezolvării problemelor uzuale care apar într-o firmă medie, mică sau acasă, care oferă posibilitatea efectuării următoarelor operații:

crearea și întreținerea colecției de date, utilizatorul putând crea și manipula datele fără să cunoască modul în care sunt stocate pe mediul de memorare;

memorarea și actualizarea datelor din baza de date (adăugarea, ștergerea și modificarea lor);

căutarea și găsirea informațiilor necesare și asigurarea accesului rapid la datele din colecția de date prin folosirea interogărilor;

crearea formularelor pentru vizualizarea, introducerea și actualizarea datelor;

analizarea și tipărirea datelor folosind rapoartele;

importul și exportul datelor în diverse formate de baze de date (dBase, FoxPro, Paradox) sau în format de foaie de calcul Excel;

legarea datelor din tabelele create cu alte aplicații la tabelele bazei de date Accsess;

păstrarea unei copii de siguranță a datelor pentru a putea fi recuperate în cazul în care au loc întreruperi accidentale ale funcționării sistemului;

asigurarea securității datelor;

asigurarea integrității datelor (se pot introduce în baza de date numai date valide, iar operațiile de actualizare nu distrug legul Excel;

legarea datelor din tabelele create cu alte aplicații la tabelele bazei de date Accsess;

păstrarea unei copii de siguranță a datelor pentru a putea fi recuperate în cazul în care au loc întreruperi accidentale ale funcționării sistemului;

asigurarea securității datelor;

asigurarea integrității datelor (se pot introduce în baza de date numai date valide, iar operațiile de actualizare nu distrug legăturile dintre tabele);

crearea și folosirea macrocomenzilor pentru automatizarea unor operații folosite mai des în exploatarea bazei de date;

crearea și lansarea în execuție a modulelor (programelor) scrise în limbajul Visual Basic for Application (VBA) care pot fi folosite ca aplicații pentru manipularea datelor și extragerea informațiilor din baza de date.

Pentru expresiile folosite în rapoarte, formulare și interogări, Accsess pune la dispoziția utilizatorului peste 100 de funcții încorporate (built-in functions).

„O bază de date din Access poate fi definită ca o colecție de obiecte: tabele (table), cereri de interogare (query), formulare (form), rapoarte (report), pagini Web (pages), comenzi macro (macro) și module (module)

Tabela este un obiect definit de utilizator în care sunt stocate datele primare.

Formularul este un obiect care permite introducerea datelor, afișarea acestora sau controlul întregii aplicații.

Cererea de interogare este un obiect care permite vizualizarea informațiilor obținute prin prelucrarea datelor din una sau mai multe tabele și/sau alte cereri de interogare.

Raportul este un obiect care permite formatarea și tipărirea informțiilor obținute în urma consultării bazei de date sub formă de documente.

Pagina Web de accesare a datelor reprezintă un obiect care include un fișier HTML și alte fișiere suport în vederea furnizării accesului la date prin intermediul browser-elor Internet.

Comanda Macro reprezintă un obiect care conține o definiție structurată a uneia sau mai multor acțiuni pe care Access le realizează ca răspuns la un anumit eveniment.

Modulul reprezintă un obiect care conține proceduri definite de utilizator și scrise în limbajul de programare Visual Basic.

Tabelul

Bazele de date uzuale sunt concepute în scopul de a păstra structuri de date. Un element al structurii poartă numele de câmp (field). El se caracterizează prin nume, tip și lungime. Definiția structurii de date ca succesiune de câmpuri, poartă numele de șablon (template) de înregistrare (record). Datele propriu-zise grupate conform șablonului poartă numele de înregistrări. Acestea se pot reprezenta intuitiv sub forma unui tabel.

Baza de date relațională este formată din mai multe tabele, fiecare tabel fiind format din linii și coloane. Liniile tabelului se numesc înregistrări iar coloanele se numesc câmpuri.

Antetul tabelului definește structura tabelului (ansamblul de câmpuri și descrierea lor), care se mai numește și înregistrare de structură. Datele sunt înregistrate în baza de date prin intermediul structurii definite în înregistrarea de structură. La crearea unui tabel trebuie definită mai întâi structura tabelului , adică trebuie precizate campurile care îl compun și caracteristicile acestora. Intr-un tabel al unei baze de date relationale nu pot

exista inregistrări identice, adică două inregistrari care să aibă aceleasi valori pentru toate campurile.

Tabelul permite gruparea unor date înrudite și poate fi privit ca o colecție de câmpuri. Pentru fiecare câmp sunt descrise datele pe care le va memora. Descrierea se face prin tipul datelor, dimensiunea lor și alte proprietăți.

Tipul datei definește modul în care este reprezentată data în memorie, domeniul implicit de definiție al datei și mulțimea operatorilor care se pot aplica pe valorile datei.

Procesul de construire a unei baze de date se desfășoară în două etape:

1. Construirea tabelelor care compun baza de date. Aceasta înseamnă că pentru fiecare tabel din baza de date trebuie definită structura, adică ansambul de câmpuri împreună cu proprietățile lor. După definirea structurii începe încărcarea datelor în tabele. La nivelul tabelului, entitatea prelucrată este înregistrarea: se pot adăuga, șterge sau modifica înregistrări. Structura unui tabel se poate modifica chiar și după ce acesta a fost încărcat cu date.

2. Stabilirea relațiilor între tabele. Relațiile care se vor stabili între tabele sunt unidirecționale, adică între două tabele nu se stabilește o relație de egalitate, ci o relație de subordonare: unul dintre tabele este tabelul principal (tabelul de la care pornește legătura), iar celălalt este tabelul secundar (tabelul la care ajunge legătura). Tabelul secundar este subordonat tabelului principal, asta însemnând că dacă utilizatorul selectează o înregistrare în tabelul principal, sistemul va selecta automat înregistrarea de care este legată din tabelul secundar.

Modelul relațional cel mai des întâlnit este cel descris printr-un arbore cu o singură rădăcină, adică în baza de date există un singur tabel principal, celelalte tabele fiind legate de acesta direct sau indirect (prin intermediul altor tabele).

Puterea unei baze de date relaționale constă în posibilitatea de a găsi rapid informații memorate în tabele separate prin intermediul interogărilor, al formularelor și al rapoartelor. Pentru a putea realiza aceste performanțe, fiecare tabel trebuie să conțină un câmp sau un set de câmpuri care să identifice unic fiecare înregistrare din tabel. Această informație este numită cheie de indexare.

Cheie și index

Bazele de date își dovedesc utilitatea atunci când numărul înregistrărilor este mare. Pe lângă operația de introducere a unei înregistrări, mecanismele bazei de date trebuie să ofere posibilitatea regăsirii ei în vederea consultării, actualizării sau ștergerii. De asemenea, este foarte utilă selectarea unui grup de înregistrări, în funcție de anumite criterii și prezentarea lor într-o anumită ordine pe care să o precizăm noi. Un program poate citi secvențial înregistrare cu înregistrare, să selecteze într-un tabel înregistrările care satisfac criteriul de selecție, pentru ca în final să sorteze rezultatul (după criteriile dorite). Dacă tabelul conține multe înregistrări (sute de mii sau milioane), operația de selecție este de durată, iar eficiența aplicației este redusă. Pentru creșterea performanțelor, bazele de date folosesc mecanisme de indexare, prin care înlocuiesc căutarea secvențială prin căutarea arborescentă, mult mai rapidă.

Puterea sistemelor care gestionează baze de date relaționate constă în faptul că în astfel de sisteme este posibilă căutarea și prelucrarea simultană a informațiilor care sunt memorate în mai multe tabele distincte, prin intermediul diferitelor interogări, formulare și rapoarte. Pentru realizarea tratării simultane a informațiilor din mai multe tabele distincte, fiecare tabel trebuie să aibă cel puțin un câmp care să conțină o valoare unică pentru fiecare articol din tabel. Astfel, prin conținutul acestui câmp, fiecare articol memorat în tabel poate fi identificat în mod unic. Informația memorată în câmpul respectiv este denumită valoarea cheii primare, iar despre câmp se spune că are atributul de cheie primară a tabelului.

După selectarea câmpului care va avea atributul de cheie primară, programul Microsoft Access va supraveghea permanent informația care se introduce în câmpul respectiv. Astfel, în cazul în care utilizatorul introduce într-un câmp care are atributul de cheie primară o valoare care a fost deja utilizată sau nu introduce nici o informație în acest câmp, programul Access sesizează imediat această greșeală și emite un mesaj de eroare.

Stabilirea cheii primare se face prin poziționarea pe câmpul care dorim să fie cheie primară și apăsarea pe butonul . În stânga numelui câmpului va apare un simbol de forma unei chei.

Cheia secundară este formată dintr-unul sau mai multe câmpuri dintr-un tabel, care sunt folosite ca o cheie primară în alt tabel, valorile câmpurilor din cheie fiind identice în ambele tabele. Se mai numește și cheie externă.

Cheile primare și secundare se mai numesc și chei de indexare.

Relații tabelare

Relația este o legătură dintre un câmp sau o combinație de câmpuri dintr-un tabel (cheia primară) și câmpurile corespunzătoare dintr-un alt tabel (cheia secundară).

În cadrul unei baze de date pot fi tabele care au relații între ele, dar putem avea și tabele independente. Relațiile care se pot stabili între tabele sunt de trei tipuri:

una la una (one to one), în care o înregistrare din primul tabel este legată cu o singură înregistrare din al doilea tabel. Este posibil și cazul în care o înregistrare din primul tabel nu este legată cu nici o înregistrare din al doilea tabel. Această relație este similară cu un tabel care conține ambele tabele. Se folosesc însă două tabele din următoarele motive:

_ un tabel unic ar fi un tabel foarte mare, cu o structură care poate depăși numărul maxim de câmpuri acceptat de sistemul de gestiune a bazelor de date

_ numărul de câmpuri din înregistrările tabelului nu sunt fixe .

_ dacă se lucrează într-o rețea de calculatoare, se preferă ca anumite câmpuri din tabel să se păstreze pe calculatorul local și nu pe serverul de fișiere.

_ un grup de date dintr-un tabel sunt legate de un tabel, iar un alt grup de date din tabel sunt legate de un alt tabel sau nu sunt legate de nici un tabel.

_ asupra unui grup de date din tabel se execută un anumit gen de operații, iar asupra altui grup de date din tabel se execută alt gen de operații.

una la mai multe (one to many), în care o înregistrare din primul tabel poate fi legată cu mai multe înregistrări din al doilea tabel. Este cel mai răspândit tip de relație. Primul tabel trebuie să aibă un câmp cheie primară, iar al doilea tabel trebuie să conțină un câmp similar, prin care să se poată identifica înregistrarea din primul tabel de care este legată înregistrarea din al doilea tabel.

mai multe la mai multe (many to many) înseamnă că o înregistrare din primul tabel poate fi legată de mai multe înregistrări din al doilea tabel și invers, o înregistrare din al doilea tabel poate fi legată de una sau mai multe înregistrări din primul tabel.

Pentru definirea unei relații între tabelele unei baze de date se va proceda astfel:

se închide fiecare tabel creat, deoarece nu pot fi create sau modificate relații între tabele deschise.

Din meniul Tools se selectează opțiunea Relationships. În urma acestei acțiuni va apare o fereastră de dialog cu numele Relationships și alta numită Show Table.

În fereastra Show Table vor apare numele tabelelor create. Se selectează tabelul dorit după care se apasă butonul Add, apoi se închide fereastra.

În fereastra Relationships vor apare tabelele selectate. O relație între două tabele se realizează prin drag and drop de la cheia primară a tabelei principale la cheia externă a tabelei secundare.

Se va afișa automat o fereastră de dialog (fig.3.4). În această fereastră se verifică corectitudinea relației stabilite. În coloana din stânga (Table/Query) trebuie să fie afișat numele tabelului primar și numele cheii primare. În coloana din dreapta (Related Table/Query) trebuie să fie afișat numele tabelului asociat și numele cheii străine.

În continuare se configurează opțiunile de asociere utilizate între cele două tabele. În cazul în care a fost selectată proprietatea Enforce Referencial Integrity, aceasta înseamnă că atunci când se introduce o nouă înregistrare în tabelul asociat, se verifică dacă valoarea cheii străine se regăsește în tabelul principal în câmpul corespunzător cheii primare. Din acest motiv e necesară introducerea datelor în tabelul principal și apoi în tabelul asociat.În partea inferioară a ferestrei apare tipul relației stabilite. Pentru crearea efectivă a relației se va acționa butonul Create, apoi se salvează relația creată prin butonul Save din meniul File.

Relații

După crearea tabelelor și a relațiilor între acestea, se poate trece la introducerea datelor. În fereastra Database selectăm tabela în care dorim să introducem date și activăm butonul Open. Va apare pe ecran fereastra Datasheet . In cadrul căreia putem vizualiza și modifica datele deja existente sau putem introduce date noi.

Fereastra Datasheet

După introducerea de noi date tabela trebuie salvată din meniul File prin comanda Save.

Definirea elementelor bazelor de date din Access

Definiția tradițională a unei baze de date este aceea de colecție de date înregistrate înrudite într-un mod organizat. Access este un unicat în cadrul aplicațiilor pentru crearea de baze de date grație structurii sale cu fișiere complete în care sunt create bazele de date. Un singur fișier.mdb din Access poate conține obiecte de date (tabele, indexuri și interogări), precum și obiecte aplicație (formulare, rapoarte, macrocomenzi și module de cod VBA). Ca atare, putem să creăm o aplicație Access pentru baze de date completă într-un singur fișier.mdb. structura de fișiere.mdb completă folosită de Access simplifică operațiile de creare și de distribuire a aplicațiilor pentru baza de date.

Bazele de date Access pot conține următoarele elemente într-un singur fișier.mdb:

Tabelele – înregistrază datele într-un format pe linii și coloane ca acela folosit de aplicațiile pentru calculul tabelar. Putem să importăm tabele din alte aplicații pentru baze de date (de exemplu din FoxPro), din baze de date client/server (de exemplu Microsoft SQL Server) și din aplicații pentru calcul tabelar (cum ar fi Microsoft Excel). De asemenea, putem să legăm la bazele de date Access alte tipuri de tabele pentru baze de date, fișiere formate și alte baze de date Access.

Interogările – afișează datele selectate din cel mult 16 tabele. Cu ajutorul interogărilor putem să stabilim modul de prezentare a datelor, selectând tabelele care compun interogarea și până la 255 de câmpuri specifice (coloane) din tabelele selectate. Pentru a determina înregistrările (liniile) care trebuie afișate, specificăm criteriile pe care trebuie să le îndeplinească datele din interogare pentru a fi afișate,

Formularele – afișează datele incluse în tabele sau interogări și ne permit să adăugăm noi date și să actualizăm sau să ștergem datele existente. În formulare, putem să includem ilustrații și grafice, și chiar prezentări vocale sau muzică. Subformularele sunt formulare conținute într-un formular principal.

Rapoartele – tipăresc datele din tabele sau interogări în aproape orice format dorim. Access ne permite să adăugăm elemente grafice în rapoarte, astfel că putem tipării chiar un catalog complet, cu ilustrații ale produselor folosind o bază de date Access. Facilitățile programului Access pentru lucrul cu rapoarte sunt mult mai flexibile decât cele pe care le oferă majoritatea aplicațiilor pentru gestionarea bazelor de date relaționale, inclusiv a celor create pentru calculatoare de putere medie și mare.

Macrocomenzile – automatizează operațiile executate în Access. Macrocomenzile sunt acum depășite. Ele mai sunt folosite, uneori, pentru a asigura compatibilitatea cu aplicațiile pentru baze de date create cu versiuni anterioare ale programului Access. Microsoft recomandă folosirea codurilorde programare VBA.

Modulele – conțin coduri VBApe care le scriem noi pentru a crea funcții personalizate pe care să le folosim în formulare, rapoarte și interogări, precum și pentru a subproceduri care să poată fi folosite de toate modulele de clasă. Prin includerea codurilor VBA în baza de date putem crea aplicații complete pentru baze de date cu meniuri, bare de instrumente și alte facilități personalizate.

Relațiile – definesc legăturile existente între tabelele dintr-o bază de date.

Paginile – sunt pagini DAP (Data Access Pages) cu ajutorul cărora putem să afișăm și să edităm datele introduse în Access pentru publicarea ca pagini Web într-un server intranet.

O definiție mai bună pentru o bază de date Access este aceea de colecție de date înrudite și, opțional de metode necesare pentru selectarea, afișarea, actualizarea și includerea datelor în rapoarte. Această definiție subliniază doesebirea dintre Access și alte aplicații pentru gestionarea bazelor de date. Chiar și sistemele pentru baze de date client/server, cum ar fi Microsoft SQL Server, care includ toate tabelele înrudite într-o singură bază de date, nu includ echivalentul de formulare și rapoarte în aceeași bază de date. Trebuie să folosim o altă aplicație, denumită aplicație de interfață, ca să atașăm, să edităm și să includem în rapoarte datele din baza de date client/server. Putem să folosim programul Access și în scopul de a crea aplicații de interfață pentru bazele de date client/server legând tabelele din baza de date client/server la baza de date Access.

O bază de date Access are următoarele caracteristici:

Conține interogările, formularele, rapoartele și macrocomenzilenecesare pentru afișarea datelor într-un mod semnificativ și pentru actualizarea datelor atunci când este cazul;

Nu este necesar ca utilizatorii bazei de date să știe cum să creeze vreunul dintre elementele sale compomente. Toate elementele unei baze de date sunt predefinite în întregime în timpul etapei de proiectare a aplicației;

Este automatizată prin codurile VBA, astfel încât utilizatorii să-și poată exprima opțiunile folosind butoane de comandă sau meniuri personalizate în locul listelor din fereastra Database.

Toate aplicațiile pentru gestionarea bazelor date ne permit să introducem, să edităm, să afișăm și să tipărim informațiile conținute în unul sau în mai multe tabele împărțite în linii și coloane.

În acest moment, definiția aplicației pentru gestionarea bazelor de date nu diferă de cea a unei aplicații pentru calcul tabelar. Majoritatea aplicațiilor de calcul tabelar pot imita funcțiile simple ale unei baze de date.

Principalele caracteristici care deosebesc sistemele pentru gestionarea bazelor de date relaționale (RDBMS) de aplicațiile pentru calcul tabelar sunt:

Toate sistemele RDBMS sunt proiectate pentru a lucra eficient cu mari cantități de date, cu mult mai mari decât cele care pot fi procesate în mod eficient de programele de calcul tabelar;

Sistemele RDBMS permit legarea cu ușurință a două sau mai multor tabele în așa fel încât să le apară utilizatorilor ca și când ar forma un singur tabel. Acest proces este dificil și chiar imposibil de realizat în programele de calcul tabelar;

Sistemele RDBMS minimizează multiplicarea informațiilor prin folosirea repetărilor numai în cazul acelor date prin care se realizează legătura dintre mai multe tabele.

Access are o structură proprie a fișierelor cu baze de date, asemănătoare celei folosite de sistemele RDBMS client/server, care folosește extensia .mdb. Access se deosebește de bazele de date tradiționale prin faptul că un singur fișier cuprinde toate tabelele, indexurile, formularele și definițiile pentru rapoarte care sunt înrudite între ele. Fișierul .mdb conține chiar și codurile de programare pe care le scriem în VBA.

În afara structurii cu fișierele bazelor de date având extensia .mdb, Access conține și un fișier principal pentru bazele de date, care se numește fișier al grupului de lucru și are denumirea System.mdw. acest fișier conține următoarele informații:

Numele utilizatorilor și ale grupurilor de utilizatori care pot deschide programul Access;

Parolele utilizatorilor și un cod binar unic, numit System ID (SID), care identifică utilizatorul curent în sistemul Access;

Preferințele de operare pe care le stabilim folosind comanda Tools, Options din meniu;

Definiții ale barelor cu instrumente personalizate din Access, create de fiecare utilizator în parte.

1.7 utilizarea BAZElor DE DATE ÎN ACCESS

Tabelele împreună cu relațiile dintre ele formează baza de date. Legătura dintre tabelele bazei de date se realizează prin mecanismul de propagare a cheilor. În tabelul sursă, tabelul de la care începe propagarea cheii, se găsește cheia primară, iar în tabelul destinație, tabelul până la care se propagă cheia, se găsește cheia secundară. Acest mecanism permite stabilirea legăturii între o înregistrare din tabelul sursă și o înregistrare din tabelul destinație. Condiția care trebuie respectată pentru a putea fi asigurată această legătură se numește condiția de integritate referențială. Ea este specifică relațiilor dintre tabelele bazei de date și constituie o colecție de reguli și restricții impuse tabelelor între care s-au stabilit relații. Astfel, a asigura integritatea referențială înseamnă ca atunci când se fac modificări ale valorii unui câmp dintr-un tabel să nu fie afectată relația dintre tabele. Această problemă apare în cazul câmpurilor care fac parte dintr-o cheie primară sau secundară. Ele trebuie să respecte condiția de integritate referențială.

Condiția de integritate referențială impune ca mulțimea valorilor unei chei secundare să fie inclusă în mulțimea valorilor cheii primare din care s-a propagat.

Integritatea referențială trebuie să fie satisfăcută permanent în baza de date.

Operațiile de adăugare, ștergere și modificare pot afecta integritatea referențială astfel:

În tabelul condus:

Operația de adăugare a unei înregistrări trebuie să se facă numai dacă valorile din câmpurile secundare se găsesc în mulțimea valorilor cheilor primare din care s-au propagat.

Operația de ștergere a unei înregistrări se poate face fără să fie afectată integritatea referențială.

Operația de modificare a valorii unui câmp dintr-o înregistrare trebuie să aibă în vedere faptul că, dacă acel câmp este un câmp secundar, valoarea sa trebuie să se găsească în mulțimea valorilor cheii primare din care s-a propagat.

În tabelul conducător:

Operația de adăugare a unei înregistrări se poate face fără să fie afectată integritatea referențială.

Operația de ștergere a unei înregistrări poate să afecteze relațiile dintre tabele numai în cazul în care există chei secundare care au aceeași valoare cu a cheii

primare din înregistrarea ștearsă. În acest caz se pot folosi două metode: ștergerea restricționată (nu se acceptă ștergerea înregistrării dacă există cel puțin o cheie secundară într-unul din tabelele bazei de date, propagată din cheia primară care are aceeași valoare cu cheia primară din înregistrarea pe care vrem să o ștergem) sau ștergerea în cascadă (ștergerea înregistrării va avea ca efect ștergerea din toate tabelele a înregistrărilor care conțin chei secundare propagate din cheia primară și care au aceeași valoare cu cheia primară din înregistrarea ștearsă).

Operația de modificare a unei înregistrări poate să afecteze relațiile dintre tabele numai în cazul în care există chei secundare care au aceeași valoare cu a cheii primare care se modifică. Și în acest caz se pot folosi două metode: modificarea restricționată (nu se acceptă modificarea unui câmp dacă el este cheie primară și există cel puțin o cheie secundară într-unul din tabelele bazei de date propagată din cheia primară care are aceeași valoare cu cheia primară pe care vrem să o modificăm) sau modificarea în cascadă (modificarea cheii primare va avea ca efect modificarea tuturor cheilor secundare propagate din aceasta, din toate tabelele, care au aceeași valoare cu cheia primară care se modifică).

În fișierul bazei de date Access se găsesc două tipuri de date:

colecțiile de date organizate sub formă de tabele, care reprezintă informația utilă;

instrumente ajutătoare pentru manipularea și actualizarea datelor din colecție: informații despre descrierea datelor (structura tabelelor), informații despre proprietarul datelor și despre utilizatorii cărora le este permis accesul la consultarea sau actualizarea datelor și despre limitările în exploatare generate din necesitatea de a asigura securitatea și confidențialitatea datelor, relațiile dintre tabele, informațiile necesare regăsirii datelor în tabele (cum sunt cheile de indexare, care permit regăsirea datelor în baza de date în funcție de valoarea unui câmp cheie și care asigură accesul direct la date, și interogările) sau interpretării lor (cum sunt rapoartele) etc.

La pornirea calculatorului Microsoft Access se deschide din meniul Start astfel:

START PROGRAMS MICROSOFT ACCESS

Fereastra principală

Înainte de a crea o nouă bază de date trebuie luată o decizie importantă: vom crea o bază de date nouă pornind de la zero, pentru a crea apoi manual toate tabelele, rapoartele, interogările și formularele necesare, sau vom folosi utilitarul Database Wizard, care face singur toate aceste lucruri?

Database Wizard Access are mai multe aplicații Database Wizard. Aceste mini-programe formulează întrebări pentru a stabili ce ne trebuie, apoi creează structura bazei de date conform celor precizate. Pentru cei grăbiți, folosirea unui vrăjitor poate fi de mare folos.

Pe de altă parte, dacă vrem să creem o bază de date deosebită, sau dacă vrem să creem o bază de date doar pentru a exersa, este recomandabil este recomandabil să pornim de la o bază de date goală.

Pentru crearea unei baze de date noi, în fereastra principală se selectează Blank Access database și se activează butonul OK. Va apare o fereastră de dialog, unde se introduce numele bazei de date și se activează butonul Create,

Pentru a deschide o bază de date existentă în fereastra principală se selectează Open an existing file și se activează butonul OK, care va deschide o fereastră în care se selectează baza de date ce se dorește a fi deschisă.

Crearea structurii bazei de date

Crearea structurii tabelelor se poate face în trei moduri:

Utilizând fereastra de proiectare (Create table in design view);

Utilizând instrumentul Wizard (Create table by using wizard);

Prin introducerea datelor (Create table by entering data).

Prin activarea primului mod va apare pe ecran o fereastră (figura 3.9), în care se definește numele câmpului (Field Name), tipul de date (Data Type) și, opțional, o descriere a câmpului (Description).

Orice tabel trebuie să aibă cel puțin un câmp cu o valoare unică pentru toate înregistrările, numit câmp principal.

Pentru a-i comunica programului Access ce câmp vom folosi drept câmp principal, astfel încât să evităm introducerea accidentală a aceleiași valori în mai multe înregistrări din câmpul respectiv, vom efectua următorii pași:

În modul de afișare Table Design, vom selecta câmpul pe care vrem să-l folosim drept câmp primar.

Selectăm Edit, Primary Key, sau executăm clic pe butonul Primary Key de pe bara cu instrumente. La stânga denumirii câmpului va apărea simbolul unei chei, indicând că acesta a fost ales drept câmp primar.

Numele tabelelor și câmpurilor trebuie să fie sugestive și să nu fie lungi. Tipurile de date disponibile sunt foarte numeroase, inclusiv tipul memo pentru comentarii, tipul OLE object pentru obiecte OLE (imagini, sunete, documente). Unul sau mai multe câmpuri consecutive se pot declara cheie unică; în lipsa acestora, MSAccess adaugă un câmp de tip AutoNumber, pentru a fi folosit drept cheie unică. Tabelele și câmpurile au proprietăți deosebite, între care menționăm: reguli de validare, liste de valori posibile, mesaje de eroare. Aceste proprietăți bine gestionate se vor utiliza automat de către toate uneltele bazei de date, scutind programatorul de multe operații de rutină.

Tipurile de date care se pot defini în Access și care sunt folosite în aplicație, sunt: text, memo, number, autonumber, currency, date/time, lookup wizard.

Lookup wizard-ul crează câmpuri care permit utilizatorului să aleagă valori din cadrul altor tabele sau dintr-o listă de valori.

Câmpurile de tip text sunt cel mai des folosite, astfel că Access consideră acest tip ca fiind cel prestabilit. Un câmp text poate conține cel mult 255 de caractere. Access atribuie o lungime prestabilită de 50 de caractere.

Câmpurile de tip memo pot conține cel mult 64.000 de caractere și nu pot fi cheie.

Câmpul de tipul AutoNumber conține o valoare numerică, pe care Access o completează în mod automat pentru fiecare înregistrare. Numărul maxim de înregistrări dintr-o tabelă care pot folosi câmpul AutoNumber este mai mare de 2 miliarde.

Câmpurile de tip Number sunt disponibile în mai multe subtipuri de date. Alegem subtipul corespunzător selectând unul dintre parametri proprietății Field Size. Modul în care va fi afișat numărul se indică stabilindu-i proprietatea Format.

Tipul Currency este un tip special de date cu 4 zecimale în care vor fi introduse valori monetare.

În câmpurile de tipul Date/Time vor fi introduse date calendaristice și/sau ore. Controlăm modul în care Access afișează datele calendaristice selectând una dintre proprietățile Date/Time Format.

Pe lângă tipul câmpului, pentru orice câmp se pot selecta opțiuni de formatare. Ele apar în partea de jos a casetei de dialog din secțiunea Field Properties. Opțiunile de formatare sunt variabile, în funcție de tipul câmpului, cele mai importante fiind:

Field Size – reprezintă numărul maxim de caractere pe care un utilizator le poate introduce în câmpul respectiv ;

Format – este o listă derulantă a formatelor existente pentru câmpul respectiv. Se pot crea și formate personalizate ;

Default Value – Dacă un câmp conține de regulă o anumită valoare, putem să o introducem aici pentru a economisi timp. Ea va apărea întotdeauna ca o nouă înregistrare, peste care se poate introduce altă valoare, în cazul în care valoarea este diferită ;

Decimal Places – Pentru câmpurile numerice, se poate fixa un număr prestabilit de zecimale care va fi folosit pentru afișarea numerelor ;

Required – Se poate selecta Yes sau No pentru a-i comunica programului dacă utilizatorul poate lăsa câmpul gol atunci când introduce o nouă înregistrare.

După ce a fost proiectată structura unui tabel se poate trece la adăugarea articolelor în tabelul respectiv. Pentru fiecare articol din fiecare coloană se va introduce câte o valoare. Pentru aceasta se selectează Tables din fereastra Database și se execută clic pe numele tabelului.

Interogarea

De multe ori informațiile necesare se găsesc în mai multe tabele. Pentru a le găsi trebuie creată o interogare.

Interogarea sau cererea de înregistrări este un proces prin care se extrag din baza de date și sunt prezentate în vederea utilizării acele înregistrări care satisfac anumite criterii.

Avantajele oferite de modul de interogare a bazei de date prin cereri sunt:

selecția câmpurilor din tabele și a înregistrărilor acestora pe baza unor criterii impuse de necesitățile informaționale;

ordonarea rezultatelor după anumite criterii;

introducerea unor câmpuri calculate pe baza unor formule, care folosesc drept operanzi alte câmpuri existente în tabele, precum și posibilitatea determinării de totaluri pe anumite câmpuri;

utilizarea într-o cerere a mai multor tabele;

modularitatea cererilor în sensul că foaia de răspuns (rezultatul) a unei cereri poate fi folosită ca intrare pentru o nouă cerere;

crearea unor formulare și situații finale (rapoarte), care au la bază cereri de interogare (create anterior);

posibilitatea generării de reprezentări grafice pe baza unor cereri de tip analiză încrucișată.

Interogările se pot obține prin:

centralizarea anumitor date din mai multe tabele și sortarea lor după mai multe criterii;

efectuarea de calcule cu grupuri de înregistrări;

calcularea unor totaluri, numărarea sau gruparea rezultatelor după două tipuri de informații.

Drept urmare datorita interogarilor se pot adăuga, actualiza sau sterge inregistrari sau se pot executa calcule cu datele din câmpuri.

Formarea cererii de interogare se face prin:

proiectarea pas cu pas a cererii în modul Design view (fereastra de proiectare);

utilizând instrumentul wizard;

exprimarea cererii în limbajul SQL;

crearea unui filtru și salvarea acestuia ca cerere de interogare.

Cerere de interogare – filtru

Interogările pot fi folosite:

pentru vizualizarea, modificarea și analizarea datelor în diferite moduri;

ca sursă de date pentru formulare și rapoarte.

La baza creării interogărilor stă limbajul de interogare (Query language). Acesta este un limbaj accesibil, ușor de înțeles și de folosit de marea majoritate a utilizatorilor.

Din categoria limbajelor de interogare fac parte:

limbajul SQL, care exprimă interogările folosind operatori specifici relațiilor dintre tabele;

limbajul QBE, care se bazează pe calculul relațional (care exprimă interogările prin intermediul condițiilor pe care trebuie să le îndeplinească mulțimea înregistrărilor care corespund cererii).

SQL (Structured Query Language – limbaj structurat de interogare) este cel mai răspândit limbaj de interogare a bazelor de date relaționale. Este un limbaj standardizat care a fost creat special pentru a putea fi folosit la interogarea, actualizarea și gestionarea bazelor de date și este implementat în majoritatea sistemelor de gestiune a bazelor de date.

Instrucțiunile SQL sunt folosite pentru a:

defini datele folosite la descrierea structurii bazei de date;

manipula datele din baza de date (adăugarea, ștergerea și modificarea înregistrărilor);

selecta date din baza de date în vederea obținerii unor informații.

QBE (Query By Example – Interogarea prin exemple) pune de obicei la dispoziția utilizatorului o interfață prin intermediul căreia acesta își poate asambla interactiv interogarea, incluzând operatori pentru calculul:

sumei valorilor unui câmp din tabel – sum

mediei aritmetice a valorilor unui câmp din tabel – avg

celei mai mari valori a unui câmp din tabel – max

celei mai mici valori a unui câmp din tabel – min

numărului de înregistrări dintr-un tabel – count.

În Access se pot crea interogările atât cu limbajul SQL, cât și cu metoda interogativă a limbajului QBE. În culise, comenzile QBE sunt transformate în instrucțiuni SQL.

Formularul

Formularele reprezintă interfața principală între utilizator și o aplicație Microsoft Access, fiind obiecte ale bazei de date ce permit introducerea și afișarea datelor într-o manieră cât mai atractivă.

În cadrul unei aplicații formularele pot îndeplini mai multe funcții:

Afișarea și editarea datelor. Aceasta este cea mai des întâlnită formă de utilizare a formularului. Formularul permite afișarea datelor în forma dorită de proiectantul aplicației. De asemenea, datele afișate în cadrul formularelor pot fi modificate sau chiar șterse.

Controlul operațiilor realizate de aplicație. Se pot proiecta formulare care, împreună cu comenzi macro sau cu proceduri Visual Basic, să realizeze afișarea automată a anumitor date sau executarea automată a unui șir de operații cum ar fi deschiderea unui subformular dintr-un formular.

Introducerea de date

Afișarea de mesaje. Formularele pot furniza informații privind modul în care aplicația poate fi utilizată sau despre operațiile ce urmează a fi executate.

Tipărirea informațiilor. Chiar dacă mai rar, formularele pot fi folosite și pentru tipărirea de informații la imprimantă.

Într-un formular pot fi afișate două categorii de informații:

dinamice (se modifică în același formular) fiind preluate din sursa de date (din câmpurile înregistrărilor din tabele sau din interogări);

statice (nu se modifică în același formular) fiind memorate în formular elemente grafice folosite pentru separarea informațiilor (linii, dreptunghiuri etc.), texte care descriu informația afișată sau rezultatul unor calcule pe baza unei expresii memorate în formular.

Legătura dintre formular și sursa de date este asigurată prin intermediul controalelor. Cel mai des întâlnit tip de control pentru introducerea și afișarea datelor este caseta de text (text box).

Raportul

Vizualizarea datelor dintr-o bază de date se poate face pe ecran sau hârtie (la imprimantă) prin intermediul foilor de date, formularelor și situațiilor finale. Ultima posibilitate constituie modalitatea cea mai bună de prezentare a datelor pe hârtie.

O situație finală este o grupare de date prezentate într-un anumit format și o structură de pagină în funcție de necesitățile utilizatorilor și care servesc diverselor scopuri de informare sau de fundamentare a deciziilor. În plus aceasta poate include totaluri, subtotaluri (după anumite criterii), subformulare grafice și obiecte de tip OLE. Sursa datelor unei situații finale o constituie în principal cererile de interogare sau tabelele, restul făcând parte din structura acestora. În general dacă datele ce trebuie introduse în situația finală au ca sursă mai mult de o tabelă, se crează mai întâi o cerere de interogare (care reunește datele din tabele) și apoi situația finală bazată pe aceasta.

Raportul (report) este formatul pentru tipărire la imprimantă a datelor din tabelele bazei de date, folosit pentru a ușura analiza informațiilor.

Sursa de date a unui raport poate fi:

_ toate înregistrările dintr-un tabel;

_ anumite înregistrări dintr-un tabel;

_ câmpuri din mai multe tabele legate între ele;

_ câmpuri dintr-o interogare.

La fel ca și la formulare, într-un raport pot fi afișate două categorii de informații:

dinamice (se modifică în același raport) fiind preluate din sursa de date;

statice (nu se modifică în același raport) fiind memorate în raport: elemente grafice folosite pentru separarea informațiilor (linii, dreptunghiuri etc.), texte care descriu informația afișată sau rezultatul unor calcule pe baza unei expresii memorate în raport (câmpuri calculate).

Pe lângă toate facilitățile descrise mai sus, într-un raport mai avem posibilitatea de:

adăuga o imagine (o siglă);

grupa înregistrările după valoarea unui câmp cheie;

calcula totaluri și subtotaluri pentru grupurile de înregistrări;

afișa informațiile sub formă de diagramă;

crea etichete poștale.

Pentru aceasta se selectează opțiunea Create report by using wizard, după care apare o fereastră în care putem selecta tabela sau interogarea după care dorim să facem raportul, la fel și câmpurile pe care acesta să le conțină. Apăsând butonul Next apare o nouă fereastră în care putem adăuga nivele de grupare, apoi putem selecta câmpurile după care dorim să sortăm datele. În continuare putem alege forma de prezentare a raportului, care poate fi pe o singură coloană (Columnar), gen tabel (Tabular) și etichetă poștală (Justified). Apăsând Next mai putem alege stilul raportului iar în final denumirea acestuia.

2. DEPOZITUL de DATE

Un depozit de date este o bază de date folosit pentru a stoca date. Este un depozit central de date în care sunt stocate datele din diverse surse. Depozitul de date este apoi utilizat pentru raportare și analiză a datelor. Scopul unui depozit de date este de a oferi acces flexibil la datele utilizatorului. De stocare a datelor, în general, se referă la o combinație de mai multe baze de date diferite la nivelul întregii organizații. Depozite de date stoca datele istorice actuale, precum și, astfel încât toate datele relevante pot fi utilizate pentru analiza. O bază de date, pe de altă parte, este baza sau niciun fel de stocare a datelor. Este o colecție organizată de date. Date din diferite surse sunt colectate într-un singur loc, acest loc este baza de date. Datele sunt organizate într-o structură de un anumit fel, în special în conformitate cu un model de bază de date. În scopul de a prelua date de la o bază de date, trebuie să utilizeze un sistem de management al bazelor de date (DBMS). Sistemele de management de baze de date sunt aplicații concepute, care interacționează cu utilizatorul, alte aplicații, precum și baza de date în sine pentru a captura și analiza datelor. SGBD este conceput pentru a permite definirea, creație, interogare, actualizarea, și administrarea bazelor de date. În timp ce, o bază de date și un depozit de date poate părea la fel, ele sunt de fapt diferite este un aspect cheie. O bază de date este folosit pentru a stoca date în timp ce un depozit de date este folosit in principal pentru a facilita raportare și analiză. Practic, baza de date este doar în cazul în care sunt stocate datele, pentru a accesa aceste date sau analiza, este necesar un sistem de management al bazelor de date. Cu toate acestea, un depozit de date nu necesită neapărat un DBMS. Scopul unui depozit de date este pentru un acces facil la datele pentru un utilizator. Unele diferențe între o bază de date și un depozit de date:

O bază de date este folosit pentru Online Transactional Processing (OLTP), dar pot fi utilizate în alte scopuri, cum ar fi Data Warehousing.

Un depozit de date este utilizat pentru Online Analytical Processing (OLAP). Acest citește datele istorice pentru utilizatorii de decizii de afaceri.

Într-o bază de date tabele și se alătură sunt complexe, deoarece acestea sunt normalizate pentru RDMS. Acest lucru reduce datele redundante și economisește spațiu de stocare.

În depozit de date, tabelele și se alătură sunt simple, deoarece acestea sunt de-normalizat. Acest lucru se face pentru a reduce timpul de răspuns pentru interogări analitice.

Tehnici de modelare relaționale sunt folosite pentru proiectarea bazei de date RDMS, în timp ce tehnici de modelare sunt folosite pentru proiectarea Data Warehouse.

O bază de date este optimizat pentru operație de scriere, în timp ce un depozit de date este optimizat pentru operații de citire.

Într-o bază de date, de performanță este scăzut pentru interogări de analiză, în timp ce într-un depozit de date, este de înaltă performanță pentru interogări analitice.

Un depozit de date are un plus in fata bazei de date. Acesta incluzand o bază de date în formatul sau.

Depozitele de date rezolvă problemele legate de sursele de date disparate și de scopurile incompatibile dintre procesarea tranzacțiilor și aplicațiile de Inteligența Afacerii.

Scopul unui depozit de date este de a furniza un stoc central de date unde informațiile din unul sau mai multe sisteme tranzacționale pot fi consolidate într-o singură, integrată și consistentă sursă de date.

Depozitul de date este proiectat pentru a optimiza obținerea de rapoarte pe un număr mare de înregistrări ale bazei de date. El presupune multe regăsiri și foarte puține actualizări (sau deloc).

Caracteristicile principale ale Depozitului de Date sunt:

dimensiunea foarte mare, volumul de date fiind de la sute de GB la TB;

este organizat la nivelul unei organizații;

cererile de regăsire sunt ad-hoc și implică foarte multe înregistrări;

sursele de date sunt variate: istorice statistice, demografice etc.;

se pot folosi modele de date multidimensionale și tehnologia OLAP;

Colecția de date de tip Depozit de Date este:

orientată pe subiectele importante din organizație: clienți, produse etc.

integrată deoarece datele provin din surse diferite printr-un proces anterior de curățare / filtrare și prelucrare;

non-volatilă pentru că operațiile efectuate sunt în special de regăsire și periodic de încărcare, nu de actualizare;

dependentă de timp pentru că datele sunt stocate pentru o perioadă de 5-10 ani;

– necesitatea Depozitului de Date se referă la îmbunătățirea calității informațiilor din organizații.

De cele mai multe ori, Depozitele de Date sunt incluse ca facilități care aparțin unor SGBD-uri, de exemplu Oracle Warehouse Builder, Oracle Discoverer.

2.2 EXTRAGEREA DE DATE (data mining)

Extragerea de date constă în analiza complexă a datelor prin metode și mecanisme specifice, ca o dezvoltare a analizei statistice clasice.

Extragerea de date duce Inteligența Afacerii cu un pas mai departe decât OLAP. În OLAP utilizatorul este angajat în mod activ în explorarea datelor, pe când în data mining, informația spune ceva despre ea fără să fie adresată vreo întrebare.

Tehnologia de data mining utilizează metode de căutare complexe spre a identifica modele și grupări ale datelor. Extragerea de date poate identifica tendințe nesuspectate în comportamentul consumatorului, care potențial pot fi utilizate să prevadă comportamentul viitor

Extragerea de date se îmbunătățește cu cât crește cantitatea de date și necesită depozite de date de înaltă calitate pentru a putea da rezultate utile.

Data mining se folosește în cel puțin două domenii: statistică superioară – pentru analize complexe, inteligența artificială – pentru descoperire și cunoaștere.

Facilitățile de extragerea de date pot fi incluse în SGBD având stocul de date pregătit deja, prin interfețe specializate cum ar fi Oracle Data Mining și Oracle Miner.

Aspecte fundamentale

Depozitele de Date – Depozitul de Date (DW – data warehouse) reprezentă rezultatul interferenței mediului economic și al tehnologiilor informatice avansate.

Mediul economic este tot mai competitiv, tinde spre globalizare, devine tot mai complex și solicită informații elaborate pentru sprijinirea deciziilor strategice.

Un astfel de mediu economic a determinat evoluția activității de realizare a sistemelor informatice de la orientarea pe operațional spre orientarea pe procesul de afacere. Procesul de afacere (business process) este un ansamblu de activități interdepartamentale, la nivelul unei organizații, care presupune una sau mai multe intrări și care generează un rezultat important pentru client (intern sau extern).

Evoluția tehnologiilor informatice oferă soluții eficiente de gestionare a unor volume foarte mari de date integrate(de ordinul TB – terabytes), asigurând niveluri de sinteză și detaliere adecvate.

Costul realizării unui DD este foarte mare și recuperarea investiției se face în timp indelungat.

Din aceste costuri, 1/3 se cheltuiesc cu software necesar, 1/3 cu hardware și 1/3 cu servicii profesionale.

Depozitele de date furnizează arhitecturi și instrumente utile conducerii executive prin organizarea sistematică, înțelegerea și utilizarea datelor în luarea deciziilor strategice, într-un mediu economic competitiv și în rapidă evoluție.

William Inmon (vicepreședintele firmei Prism Solutions), este părintele necontestat al noțiunii de Data Warehouse, iar viziunea sa se concentrază asupra rolului DD ca bază informațională a deciziei manageriale, păstrând astfel un nivel înalt de generalitate si permițând unor multiple implementări să intre în sfera acestei noțiuni.

Earl Hadden este cel care a enunțat și a experimentat o metodologie riguroasă pentru implementarea depozitelor de date.

O serie de firme de Informatică și-au adus contribuția la clarificarea, dezvoltarea si popularizarea noii tehnologii: Software AG, Oracle Corp., Prism Solutions, MicroStrategy etc.

Depozitul de date (in general) este o bază de date de foarte mari dimensiuni care este întreținută separat de bazele de date operaționale ale unei organizații și care este construită din date provenite din sisteme sursă prin extragere, filtrare, transformare și stocare în depozite speciale, în scopul sprijinirii proceselor decizionale.

Depozitele de date sprijina prelucrarea informațiilor pentru analiză, furnizând o platformă solidă de consolidare a datelor istorice. Un depozit de date este un ansamblu de date consistente, din punct de vedere semantic, care servește la o implementare fizică a unui model de date pentru sprijinirea deciziei și stochează informații pe care o organizație le solicită în luarea deciziilor strategice.

Depozitul de date (dupa W.Inmon) este un ansamblu de colecții de date orientat pe subiecte, integrate, istorice și nevolatile destinată sprijinirii procesului de luare a deciziilor manageriale.

2.3 Organizarea datelor în Depozite de Date

Sursele de date pentru depozitul de date provin în principal din datele importate din sistemul informatic operational, dar mai pot proveni din datele de arhivă (în perioada de constituire a depozitului) precum și din surse externe (baze de date publice , date luate din sondaje, date demografice ,etc)

Colecțiile de date utilizate de sistemul informatic operațional au ca scop optimizarea și siguranța procesării datelor. Datele dintr-un depozit de date sunt organizate într-o manieră care să permită analizarea lor complexă, deci extragerea semnificației economice pe care o poartă.

Datele operaționale (Bazele de Date sau fișiere) sunt orientate pe aplicații, în sensul că organizarea lor este optimizată pentru a servi procesului tranzacțional, dinamicii sistemului.

Depozitul de date este orientat pe subiectele importante ale procesului economic: clientii, furnizorii, produsele, activitățile.

La depozitele de date, actualizarea se face foarte rar, adica dinamica lipseste. Actualizarea se realizează doar prin adăugarea periodică a unor date extrase din sistemele operative sau din alte surse de date.

Din punctul de vedere al aplicatiilor care folosesc depozitul de date, accesul la date este doar pentru citire.

Metadatele

Metadatele sunt informații despre datele existente în DD, care descriu structura (conținutul) depozitului și furnizează referințe directe la date.

Ca metadate se stochează și diverse viziuni (views) asociate unor categorii de utilizatori.

Metadatele sunt folosite pentru administrarea depozitului de date, deoarece conțin informații despre: sursa datelor, algoritmii de sumarizare, statisticile de utilizare etc. Metadatele sunt create pentru toate numele de date și definițiile din depozit. Metadate adiționale sunt create pentru a asocia intervale de timp la datele extrase și alte câmpuri care vor fi adăugate prin filtrarea datelor sau prin procesele de integrare.

Metadatele unui DD conțin următoarele categorii de informații:

o descriere a structurii de date din depozit, care include schema depozitului, dimensiunile, ierarhiile, definițiile datelor derivate;

metadatele operaționale, care includ: date privind evoluția în timp (istoricul datelor și secvența de transformare aplicată asupra lor), circulația datelor (active, arhivate, șterse) și informații de monitorizare (statistici privind utilizarea depozitului de date, rapoarte de erori etc.);

algoritmii utilizați pentru sumarizare, care includ: măsura și dimensiunea algoritmilor definiți, date despre granularitate, partiții, arii de subiecte, agregări, sumarizări, rapoarte și filtre predefinite;

mapările (transformările) de la mediul operațional la depozitul de date care includ: bazele de date sursă și conținutul lor, descrierile interfețelor (gateways), partiționarea datelor, extragerea datelor, filtrarea datelor, regulile de întreținere, securitate a datelor;

date referitoare la performanțele sistemului care include indici și profiluri care îmbunătățesc accesul la date și performanțele de căutare;

metadatele economice (business metadata), care includ termenii economici și definițiile aferente.

Rolul metadatelor pentru depozitul de date reiese din următoarele considerente:

stabilesc contextul depozitului de date. Sub orice sistem, inclusiv DD, utilizatorul intră sub o sesiune de lucru, adică se crează automat un context de lucru: parametri setați, conectări efectuate, drepturi existente etc.

ajută administratorii și utilizatorii depozitului să localizeze și să înțeleagă secvențele de date atât în sistemele sursă cât și în structura depozitului. În sistemele operaționale, dezvoltatorii și administratorii bazelor de date lucrează cu metadate în fiecare zi. Toată documentația tehnică a sistemelor reprezintă într-un fel sau altul metadate. Ele rămân totuși transparente pentru majoritatea utilizatorilor, ei percepând în general sistemul ca pe o cutie neagră ce oferă o interfață prin intermediul căreia trebuie manevrat. În cazul depozitelor de date, utilizatorii sistemelor de asistare a deciziei trebuie să înțeleagă înainte de toate conținutul depozitului, pentru ca apoi să beneficieze de informațiile necesare.

procesul de analiză cuprinde mai multe etape: identificarea datelor, obținerea datelor, interpretarea și analiza datelor pentru a obține informații, prezentarea informațiilor și recomandarea unei direcții de acțiune. Pentru ca depozitul de date să fie folositor analiștilor din întreprindere, metadatele trebuie să ofere utilizatorilor informații care să-i ajute în parcurgerea etapelor anterior enumerate. Astfel, metadatele trebuie să ajute utilizatorii să găsească rapid datele în depozit și să interpreteze corect datele obținute prin oferirea informațiilor referitoare la formatul și semnificația datelor;

metadatele sunt o formă de auditare a transformării datelor. Metadatele documentează transformarea datelor sursă în date ale depozitului, adică trebuie să fie capabile să explice modul în care o secvență de date din depozit este dedusă din sistemele operaționale. Toate regulile care guvernează transformarea datelor în noi valori sau noi formate sunt considerate a fi metadate. Această formă de audit este necesară atunci când utilizatorii trebuie să aibă încredere în veridicitatea și calitatea datelor din depozit. De asemenea, este important ca utilizatorii să-și poată da seama de unde provin datele existente în depozit. Este de dorit ca, pe baza acestor metadate, anumite produse să poată genera programe de extragere și transformare pentru cei care se ocupă de interfața de analiză a depozitului de date;

metadatele mențin și cresc calitatea datelor, fapt ce se realizează prin definirea valorilor valide pentru fiecare câmp din depozit. Înainte de a fi efectiv încărcate în depozit, datele pot fi revăzute și erorile pot fi corectate. De asemenea, regulile de corecție a erorilor pot fi documentate tot prin metadate;

permite gestiunea versiunilor. Un depozit de date conține date pentru diferite perioade de timp și de aceea este important să avem în vedere efectul pe care îl poate avea timpul asupra regulilor de trecere a câmpurilor sursă în câmpuri destinație, asupra agregărilor etc. Utilizatorii trebuie să aibă acces la metadatele corecte pentru perioada de timp pe care o studiază. Ceea ce la prima vedere ar părea să fie o eroare în transformarea datelor poate fi de fapt rezultatul schimbării regulilor de transformare a datelor. De aceea este important ca metadatele să fie corect gestionate din punct de vedere al versiunilor.

2.4 Arhitectura depozitelor de date

Sunt cel puțin două arhitecturi de DD care se pot transforma oricând una în cealaltă: pe componente, pe niveluri.

Arhitectura pe componente a depozitelor de date

Evidențiază componentele Depozitului de Date și legăturile dintre ele: depozitul de date, sursa de date, interfețele de analiză.

Esența unui depozit de date constă într-o bază de date de dimensiuni foarte mari conținând informațiile pe care le pot folosi utilizatorii (clienți, furnizori, companii de publicitate etc.).

Depozitul de date conține mai multe tipuri de date care corespund diferitelor cerințe informaționale ale utilizatorilor: date detaliate, date agregate, metadate (dicționarul de date).

Metadatele descriu datele conținute în depozitul de date și modul în care ele sunt obținute și stocate. Prin metadate se precizează structura datelor, proveniența lor, regulile de transformare, de agregate și de calcul. Ele sunt utilizate oro de câte ori se utilizează DD: la încărcarea datelor, la consultare, la actualizare, adică pe parcursul întregului ciclu de viață al depozitului.

Datele agregate, deși determină o creștere a redundanței datelor, sunt necesare în DD deoarece în acest fel se poate asigura un timp mediu de răspuns cât mai redus. Aceste date presupun un grad de prelucrare prealabilă, astfel încât să fie pregătite pentru nevoile managementului: consolidare, totalizare, însumare, împachetare (în formate accesibile interfețelor de analiză utilizate).

sursa de date depozit de date interfețe de analiză

Datele detaliate sunt cele relativ recente, livrate utilizatorilor, de regulă la nivel de execuție.

Tot aici se găsesc date având o anumită vechime (câțiva ani), în formă detaliată.

Sursele de date pentru Depozitele de Date sunt: datele operaționale curente (Baza de Date și/sau fișiere din sistemul informatic local), datele vechi arhivate, datele externe (Baza de Date și fișiere din sistemele informatice externe).

Construirea depozitului de date, pornind de la sursele de date, presupune parcurgerea unor etape în cadrul unui proces de extragere – transformare – încărcare (ETL – Extract Transformation Load):

extragerea datelor din datele operaționale sau din surse externe, urmat de copierea lor în depozitul de date. Acest proces trebuie, cel mai adesea, să transforme datele în structura și formatul intern al depozitului;

filtrarea datelor, pentru a exista certitudinea că datele sunt corecte și pot fi utilizate pentru luarea deciziilor;

încărcarea datelor corecte în depozitul de date;

agregarea datelor: totaluri precalculate, subtotaluri, valori medii, sume etc., .

Interfețele de analiză sunt produse software care implementează tehnologii informatice pentru extragerea și analiza datelor din DD: concentrări de date (Data Mart), extrageri și analize de date (Data Mining) analiza multidimensională a datelor (OLAP).

Arhitectura depozitelor de date pe trei straturi

Evidențiază modul de implementare a Depozitului de Date într-un mediu de rețea de calculatoare, pe trei straturi: stratul inferior, stratul mediu, stratul superior.

Stratul inferior (bottom tier) este format din serverul depozitului de date și este, în cele mai multe cazuri, un sistem de baze de date relaționale.

Datele care provin din bazele de date operaționale și din sursele externe(gateways), care colaborează cu sistemul de gestiune al bazelor de date initiale și permite programelor client să genereze cod (de obicei SQL) pentru a fi executat de server.

Ex de interfata: ODBC (Open DataBase Connection), OLE(Open Linking and Embedding), JDBC (Java DataBase Connection).

Astfel, datele sunt extrase, filtrate, transformate și încărcate în depozitul de date prin interfețe specializate de tip ETL – Extract Transformation Load (de exemplu produsul Oracle Data Integrator – ODI). Împrospătarea datelor din Depozitul de Date se face pe măsura trecerii timpului (lunar, trimestrial, anual).

Stratul mediu (middle tier) este bazat pe un server specializat, care poate fi: OLAP (bazat pe modelul relațional – ROLAP sau pe modelul multidimensional – MOLAP), Data Mining (analize statistice superioare), Data Mart (concentrări de date). De multe ori acest strat este inclus în sistemul de gestiune al bazelor de date(ex.Oracle, DB).

Stratul superior (top tier) este nivelul client care conține interfețe pentru generarea interogărilor, a rapoartelor, pentru superioară a datelor.

Strat superior

extragere

Strat mediu

transformare

Strat inferior

Tipuri de depozite de date

Construirea depozitului de date presupune parcurgerea următoarelor etape:

1. Un proces de extragere a datelor din bazele de date operaționale sau din

surse externe urmat de copierea lor în depozitul de date. Acest proces

trebuie, cel mai adesea, să transforme datele în structura și formatul

intern al depozitului;

2. Un proces de curățire a datelor, pentru a exista certitudinea că datele

sunt corecte și pot fi utilizate pentru luarea deciziilor;

3. Un proces de încărcare a datelor corecte în depozitul de date;

4. Un proces de creare a oricăror agregări ale datelor: totaluri

După aria de cuprindere se intalnesc trei tipuri de depozite de date: depozite de întreprindere (Enterprise Warehouse), concentrări de date (Data marts), depozite virtuale de date (Virtual Datawarehouse).

Depozitul de întreprindere colectează toate informațiile despre subiectele care privesc întreaga organizație. El furnizează un volum foarte mare de date. De regulă conține date detaliate, dar și date agregate, iar ca ordin de mărime, terabytes.

Un depozit de date de întreprindere poate fi implementat pe calculatoare mari (mainframes), pe superservere UNIX, pe platforme cu arhitecturi paralele. Acestea necesită cheltuieli mari și mult timp (ani) pentru modelare proiectare și realizare.

Concentrările de date conțin un subset al volumului de date din organizație, specific unui grup de utilizatori (unui compartiment). Domeniul este limitat la subiecte specifice. De exemplu, pentru activitatea de marketing se limitează subiectele la clienți, produse, vânzări.

Datele conținute sunt de obicei agregate. Concentrările de date sunt implementate pe servere departamentale (UNIX sau Windows). Ciclul de implementare al unei Concentrări de date este măsurat în săptămâni sau luni sau ani. Ca atare, un data mart poate fi considerat un subansamblu al unui depozit de date mai ușor de construit și întreținut și mai puțin scump.

Depozitul virtual este un set de viziuni (views) asupra bazelor de date operaționale. Pentru eficiența procesărilor interogărilor, numai unele din viziunile de agregare pot fi materializate. Un depozit virtual este ușor de construit, dar necesită capacități suplimentare pe serverele de baze de date.

După modelul de date implementat sunt următoarele tipuri de Depozite de Date: Depozite de Date relaționale, Depozite de Date multidimensionale.

2.5 Realizarea Depozitelor de Date

Realizarea unui depozit de date presupune aplicarea unei scheme de analiză economică pentru a determina măsura în care depozitul de date este necesar și eficient:

trebuie să furnizeze avantaje competitive prezentând informații relevante pe baza cărora putem măsura performanțele și putem face ajustări critice pentru a câștiga în fața competitorilor;

poate determina creșterea productivității deoarece permite obținerea rapidă și eficientă de informații care descriu cu acuratețe organizația;

facilitează gestiunea relațiilor cu clienții, deoarece acesta furnizează o viziune consistentă despre clienții și produsele comercializate de organizație, pe toate departamentele;

determină reducerea costurilor prin reliefarea tendințelor , direcțiilor și excepțiilor pe perioade lungi de timp.

Realizarea unui depozit de date poate lua în considerare viziuni diferite:

viziunea de sus în jos (top-down) permite selectarea informațiilor relevante necesare în depozitul de date, informații care reprezintă un sprijin decizional în activitatea curentă.

viziunea datelor sursă (data source view) exprimă informațiile culese, stocate și gestionate de sistemele operaționale.

viziunea depozitelor de date (data warehouse) are în vedere tabele de fapte și tabele dimensiune și reprezintă informațiile care sunt stocate în depozitele de date, incluzând contorizări și totaluri precalculate, precum și informații privitoare la sursă, dată calendaristică, origine, adăugate pentru a furniza contextul istoric.

viziunea de interogare (business query) oferă o perspectivă din punct de vedere al utilizatorului.

Un depozit de date poate fi proiectat și construit utilizând abordarea:

de sus în jos (top-down) care pornește cu proiectarea și planificarea completă. Se utilizează în cazul când tehnologia este matură și bine cunoscută și problemele economice care trebuie rezolvate sunt clare și bine înțelese. Dezvoltarea top-down a unui depozit de date constituie o soluție sistemică și minimalizează integrarea problemelor. Soluția este scumpă, solicită timp îndelungat pentru dezvoltare și îi lipsește flexibilitatea determinată de dificultățile în realizarea modelelor de date pentru întreaga organizație;

de jos în sus (bottom-up) pornește cu experimente și prototipuri. Aceasta este utilizată la începutul stadiului de modelare și de dezvoltare tehnologică. Ea permite unei organizații să meargă înainte cu cheltuieli considerabil mai mici și să evalueze beneficiile tehnologiei înainte de a face angajamente semnificative în această

direcție. Abordarea bottom-up în proiectarea, dezvoltarea și aplicarea concentrărilor de date (data marts) independente furnizează flexibilitate, costuri scăzute și recuperarea rapidă a investiției. Soluția poate determina probleme, când se încearcă integrarea într-un depozit de date consistent la nivel de întreprindere.

mixtă presupune că o organizație poate exploata caracterul planificat și strategic al abordării top-down atât timp cât reține avantajele implementării rapide și oportune a aplicațiilor după abordarea bottom-up.

Realizarea unui depozit de date presupune următorii pași: .- strategia de realizare;- . planificarea (modelarea) cerințelor; .- implementarea; . exploatarea.

Sistemele software mari pot fi dezvoltate utilizând două metodologii: metoda in cascadă,- metoda în spirală.

Metoda în cascadă execută o analiză structurată și sistematică la fiecare pas, înainte de a trece la următorul.

Metoda în spirală implică generarea rapidă de sisteme funcționale din în ce mai complete, la intervale scurte, între două versiuni succesive. Acest lucru constituie un atu important pentru dezvoltarea depozitelor de date, în special pentru data marts, pentru că intervalul de realizare este scurt, modificările pot fi făcute imediat și noile proiecte și tehnologii pot fi adaptate în mod rapid.

Strategia de realizare a depozitelor de date

Strategia de dezvoltare, la nivelul cel mai sintetic, trebuie să încludă elementele următoare:

planul preliminar al depozitului de date. In cadrul unui proiect DD nu pot fi satisfăcute toate cerințele utilizatorilor deoarece un astfel de proiect ar fi imens și periculos din punct de vedere al capacității de gestionare. Este mult mai realist să se facă o listă cu prioritățile cerințelor diferiților utilizatori, iar aceste cerințe să fie atașate diferitelor segmente care se vor dezvolta prin strategia iterativă. Natura iterativă a proiectului permite echipei de dezvoltare să extindă funcționalitățile depozitului de date într-o manieră ușor de controlat;

arhitectura preliminară a depozitului de date. Se definiște arhitectura generală a depozitului de date pentru proiectul pilot și versiunile care vor urma pentru a asigura scalabilitatea depozitului. Prin analizarea posibilelor arhitecturi de depozite de date, analiștii pot să determine o mulțime de alte componente tehnologice care sunt necesare pentru fiecare versiune;

lista preliminară a mediilor de dezvoltare a depozitului de date. Există un număr destul de mare de medii și instrumente pentru DD din care se pot face alegeri și, de aceea, se recomandă alcătuirea unei liste sintetice cu cele care pot fi de folos în cadrul organizației. Un set standard de instrumente va reduce problemele de integrare și va minimiza efortul de învățare atât pentru echipa de dezvoltare, cât și pentru utilizatori.

Etapele necesare pentru a duce la îndeplinire strategia Depozitului de Date sunt următoarele: determinarea contextului organizațional,- realizarea unei vederi preliminare de ansamblu asupra cerințelor,- realizarea auditului preliminar referitor la sistemele sursă-, -identificarea surselor de date externe, -definirea versiunilor depozitului de date, -definirea arhitecturii preliminare a depozitului de date,- evaluarea mediilor de dezvoltare a depozitului de date.

Determinarea contextului organizațional.

Ințelegerea profundă a organizației ajută la stabilirea contextului în care se desfășoară proiectul și poate evidenția aspectele culturii organizaționale, care pot ușura sau îngreuna proiectul depozitului de date. Răspunsurile la întrebările legate de organizație se obțin de obicei de la susținătorul proiectului, managerul IT sau managerul de proiect. Intrebările tipice sunt următoarele:

– cine este finanțatorul (susținătorul) proiectului în acest caz? Susținătorul proiectului stabilește domeniul proiectului DD. Acesta joacă un rol foarte important în stabilirea relațiilor de lucru între membrii echipei de dezvoltare, mai ales dacă sunt implicați și terți. Accesul facil la datele depozitului poate fi limitat de domeniul organizațional, care se află sub controlul susținătorului proiectului;

– care sunt grupurile IT din organizație care sunt implicate în proiectul DD? Deoarece un depozit de date este o dorință a organizației, grupurile IT din interior vor fi întotdeauna implicate în acest efort. Trebuie știut care sunt relațiile de lucru dintre ele și care este gradul de ocupare. Dacă, de exemplu, departamentul IT este foarte preocupat cu imbunătățirea sistemelor operaționale este foarte puțin probabil ca un depozit de date să fie pe lista de priorități;

– care sunt rolurile și responsabilitățile fiecaruia dintre cei care au legătură cu proiectul? Este important să definim rolul și responsabilitațile fiecărei persoane implicate. In acest fel se stabilesc limite și obiective, iar comunicarea și înțelegerea proiectului se îmbunătățesc.

Realizarea unei vederi preliminare de ansamblu asupra cerințelor.

In această etapă se obține un inventar al cerințelor utilizatorilor prin interviuri, individuale sau de grup, realizate în comunitatea utilizatorilor finali. Dacă este posibil, se recomandă obținerea de formate referitoare la rapoartele curente folosite de conducere. Inventarul cerințelor furnizează aria de întindere a informațiilor despre care se așteaptă să le ofere un viitor depozit de date.

Obiectivul principal este acela de a înțelege nevoile utilizatorilor, destul de mult, ca să poată fi ierarhizate. Aceasta este o informație critică ce determină aria fiecărui segment al Depozitului de Date.

La realizarea interviurilor pentru dezvoltarea depozitelor de date, este indicat să luăm în considerare următoarele recomandări:

Trebuie evitat să facem delimitări clare privind aria depozitului de date. Nu trebuie să fim surprinși dacă o să constatăm că o parte dintre interogările și rapoartele de care au nevoie utilizatorii nu pot fi realizate pe baza datelor existente în sistemele operaționale.

Trebuie păstrat clar obiectivul interviului și nu trebuie să ne abatem de la el. Obiectivul principal este acela de a realiza un inventar al cerințelor, nefiind nevoie o înțelegere foarte detaliată a acestora.

Echipa care realizează interviurile trebuie să fie mică; echipa ideală este formată din doi oameni – unul va pune intrebările și celălalt va nota răspunsurile. Intervievații pot fi intimidați dacă sunt abordați de un grup prea mare.

Se poate înregistra interviul, dacă persoana este de acord. Majoritatea persoanelor nu au nimic împotrivă, dacă le cereți acordul să înregistrați discuția pe suport magnetic, iar ascultarea ulterioară a discuției poate fi de mare ajutor.

Stilul de interviu va depinde de persoana intervievată. Managerii de nivel mediu sunt cei care lucrează cel mai mult cu rapoarte analitice, în timp ce managerii de nivel înalt au cerințe legate de informații cu caracter strategic. In funcție de intervievat se vor alege și întrebările la care se solicită răspuns.

Trebuie obținut copii ale rapoartelor, ori de câte ori este posibil. Rapoartele vor furniza echipei de dezvoltare informații importante, referitoare la sistemele sursă și la regulile și termenii afacerii.

Realizarea auditului preliminar referitor la sistemele sursă.

Este recomandabil ca echipa de dezvoltare să obțină un inventar al sistemelor sursă potențiale pentru depozitul de date. In timp ce managerul IT va furniza imaginea de ansamblu a sistemelor existente în organizație, cei mai în măsură să ofere detalii pentru auditarea sistemelor sursă sunt administratorii de baze de date și administratorii de sistem care întrețin sistemele operaționale.

Identificarea surselor de date externe.

Organizația poate folosi surse de date externe pentru completarea datelor din sistemele sursă interne. Astfel de surse de date externe pot fi: date de la bănci, date referitoare la codurile poștale, date statistice sau demografice, date de la alte organizații, date de la agenții de știri sau din publicații.

Deși datele externe reprezintă o oportunutate pentru îmbogățirea depozitului de date, ele prezintă dificultăți din cauza granularității diferite și, de aceea, decizia în legătură cu folosirea datelor externe trebuie să fie bine fundamentată.

Definirea versiunilor depozitului de date.

Specialiștii recomandă împărțirea dezvoltării depozitului de date în mai multe versiuni derulate în spirală. Disponibilitatea și calitatea datelor sursă vor juca un rol critic în finalizarea cu succes a acestei faze.

Abordarea iterativă permite gestionarea eficientă a cerințelor utilizatorilor și reduce efectele riscurilor care pot apărea. Fiecărei cerințe i se atribuie un nivel de prioritate. Se face o evaluare inițială a complexității în funcție de numărul sistemelor sursă. De asemenea, este identificat și sistemul țintă. Pot fi luați în calcul mai mulți factori pentru o mai bună înțelegere a cerințelor fiecărui modul. Definirea fiecărui modul este finalizată doar atunci când este aprobată de către susținătorul proiectului.

Definirea arhitecturii preliminare a depozitului de date.

Trebuie să se schițeze o arhitectură preliminară pentru fiecare modul în funcție de aria de întindere aprobată. Este recomandabil să se analizeze posibilitatea de a se folosi o intercorelare de baze de date relaționale și multidimensionale, precum și instrumente adecvate.

O arhitectură preliminară trebuie să prezinte cel puțin următoarele elemente:

Depozitul de date și concentrările de date. Se definesc aceste elemente pentru fiecare modul în parte. Este necesar să se indice modul în care sunt legate diferite baze de date. Arhitectura trebuie să asigure faptul că anumite concentrări de date nu sunt implementate izolat.

Numărul de utilizatori. Se specifică numărul de utilizatori pentru fiecare instrument de acces la fiecare versiune în parte.

Localizarea. Se precizează locul de dispunere a depozitului de date, a concentrărilor de date și a utilizatorilor pentru fiecare modul. Aceste aspecte au implicații asupra cerințelor arhitecturii tehnice a proiectului depozitului de date.

7. Evaluarea mediilor de dezvoltare a depozitului de date. Organizația poate alege între mai multe medii și interfețe pentru a dezvolta depozitul de date. Important este să se selecteze combinația de interfețe care satisfac cel mai bine cerințele organizației. In prezent nu există un producător care să ofere o suită integrată pentru depozite de date, însă există lideri pentru fiecare categorie în parte. Se vor elimina variantele neconvenabile și se va alcătui o listă din care fiecare versiune va avea parte de un set de interfețe (acces la date, SGBD etc.).

Concluzii generale

Dupa Ralph Kimball, un depozit de date reprezinta „o copie a datelor, special structurate in vederea interogarilor si analizelo.

Depozitele de date completeaza informatizarea organizatiilor, alaturi de sistemele informatice tranzactionale. Rolul depozitelor de date este de a stoca date preluate din restul sistemelor informatice, in vederea analizarii acestora prin diverse mijloace. Depozitele de date constituie „coloana vertebrala” a sistemelor de asistare a deciziei bazate pe sinteza si analiza datelor, sau altfel spus, depozitele de date contin „materia prima” pentru sistemele de asistare a deciziei bazate pe sinteza si analiza datelor.

William Inmon defineste astfel principalele caracteristici ale unui depozit de date

orientarea catre subiect: sistemele operationale sunt orientate (mapate) pe functiunile intreprinderii (contabilitate, salarii, vanzari etc.). Depozitele de date sunt orientate pe subiectele firmei (clienti/furnizori, surse de venituri, centre de cost);

integrarea: depozitele de date integreaza date din surse multiple care sunt, eventual, supuse unor transformari. In urma transformarilor, datele rezultate reprezinta un tot unitar. Astfel, pentru un anume subiect retinut in depozitul de date se foloseste o singura codificare, indiferent de sursele din care provin datele. De asemenea, un atribut din depozitul de date va avea un tip de date bine precizat, iar toate valorile sale vor respecta cerintele tipului de date respectiv.

non-volatilitatea: datele din depozitul de date nu sunt supuse, in mod obisnuit, operatiunilor de actualizare (modificare) ci numai unor operatiuni de adaugare. Datele noi care apar de-a lungul ciclului de viata al depozitului de date sunt adaugate datelor vechi.

orientarea in timp: datelor din depozitul de date li se asociaza o caracteristica de timp, un atribut sau un grup de atribute care indica momentul de timp cand datele au fost inregistrate in sistemul informational. Pentru datele care caracterizeaza o operatiune (tranzactie) economica, timpul este reprezentat de data sau momentul de timp (timestamp) asociate operatiunii respective.

Este bine-cunoscut astazi potentialul informational al datelor acumulate in timp de sistemele informatice operationale din firme. Pe baza acestor date se pot identifica si cuantifica in expresie monetara fenomenele ce au intervenit in activitatea firmei in diverse perioade, atat sub aspect static („imagini” la un moment dat), cat si dinamic (analiza comparativa in timp), de asemenea se pot cuantifica si cauzele acestor fenomene. Aceste informatii, puse la dispozitia managerilor, pot oferi un real suport in adoptarea deciziilor (unul dintre cele mai importante considerente in acest sens este faptul ca managerii stiu precis asupra caror aspecte din activitatea firmei trebuie sa intervina).

Exploatarea acestui potential nu se poate face totusi cu ajutorul sistemelor operationale, din mai multe considerente, cum ar fi[3]:

– nevoile informationale ale utilizatorilor depozitelor de date difera de cele ale utilizatorilor sistemelor tranzactionale: primii sunt interesati de analiza unui volum – de multe ori semnificativ – de date, care se refera la un interval de timp, ceilalti introduc/actualizeaza si solicita date/informatii in timp real;

– modul de organizare a datelor intr-un depozit de date difera de cel folosit intr-un sistem operational, in plus, pentru a raspunde unor anume cerinte exprimate de utilizatori, structura depozitului de date poate fi modificata, ceea ce intr-un sistem tranzactional este contra-indicat (sistemele operationale sunt proiectate de la bun inceput astfel incat sa raspunda cat mai bine unui anume set de cerinte, iar modificarile in structura datelor, daca sunt posibile, trebuie supuse unui proces de analiza atenta, pentru a nu se produce erori in modul de functionare a sistemului);

– folosirea in scop de analiza a sistemelor operationale greveaza asupra utilizarii lor normale, prin „consumul” de resurse de procesare hard/soft pe care l-ar presupune, situatie inacceptabila avand in vedere ca pentru un sistem operational performanta este exprimata prin prisma vitezei de prelucrare a datelor/raspuns la solicitarile utilizatorilor.

Aceste considerente impun ca depozitele de date si aplicatiile care le exploateaza sa fie separate (cel putin din punct de vedere software, separarea hardware poate fi, de la caz la caz, un avantaj pentru utilizatorii finali) de sistemele informatice tranzactionale.

2. Obiectivele depozitelor de date

Principalele obiective ale unui depozit de date sunt urmatoarele[4]:

a. Suportul in asistarea deciziei – depozitul de date trebuie sa contina date care sa asiste managementul de orice nivel in procesul decizional. Acest fapt se manifesta prin aceea ca decidentii pot consulta date din depozit pentru a-si forma/completa imaginea pe care o au asupra problemei care solicita adoptarea deciziei. Cu cat aceasta imagine este mai aproape de realitate, cu atat sunt mai mari sansele ca decizia sa fie corecta;

b. Depozitul de date trebuie sa ofere acces rapid si facil la informatii – aici intervin aplicatiile cu rol de client care ofera utilizatorilor interesati date extrase din depozit, acestia trebuie sa acceseze datele pe care le doresc fara dificultate, rolul lor este de a interpreta datele accesate;

c. Consistenta datelor – depozitul de date trebuie sa ofere certitudinea ca datele sunt corecte, in acest scop trebuie sa se acorde o mare atentie proceselor prin care datele sunt preluate din alte surse, prelucrate si apoi „livrate” catre depozitul de date. Respectarea consistentei datelor ridica valoarea calitativa a informatiilor care sunt obtinute pe baza acestor date;

d. Flexibilitate si adaptabilitate – depozitul de date trebuie sa fie construit astfel incat sa fie capabil sa raspunda prompt si corect nevoilor informationale in continua schimbare ale utilizatorilor sai;

e. Confidentialitatea – depozitele de date stocheaza informatii critice pentru activitatea firmei, informatii care trebuie sa fie disponibile numai celor in drept. Depozitele de date, prin functiile pe care le indeplinesc, stocheaza informatii intr-un volum mai mare fata de aplicatiile tranzactionale, astfel ca accesul neautorizat la continutul depozitului de date reprezinta un risc major pentru firma. Se poate spune ca daca informatiile din depozit ajuta utilizatorii in procesul decizional, odata ce caracterul secret al informatiilor a fost compromis, cei care au intrat in posesia informatiilor pot „simula” cu acuratete procesul decizional si pot prezice ce anume curs va urma activitatea firmei;

f. Acceptabilitatea – utilizatorii depozitului de date trebuie sa acorde incredere informatiilor primite in urma exploatarii depozitului de date.

Componentele unui depozit de date

Principalele componente ale unui depozit de date sunt:

a. Sursele de date

Sursele de date ale unui depozit de date pot fi toate celelalte componente ale sistemului informatic al firmei:

– baze de date (sisteme informatice tranzactionale);

– aplicatii de calcul tabelar;

– fisiere text etc.

Cel mai adesea, sursa de date o reprezinta bazele de date ce deservesc sistemele operationale din firma. Daca anterior am considerat ca depozitele de date trebuie separate de aceste sisteme, conlucrarea intre ele reprezinta o premisa a succesului implementarii unui sistem informatic de asistare a deciziei bazat pe sinteza si analiza datelor. Majoritatea instrumentelor de dezvoltare soft includ drivere native de comunicare intre cele doua niveluri – operational si decizional. Merita subliniat inca un considerent in sprijinul ideii de mai sus: transferand datele cu caracter istoric din sistemele tranzactionale in depozitele de date, capacitatea de stocare a celor dintai este degrevata de un volum de multe ori mare de date (aceasta procedura de arhivare poate inlocui sau completa back-up-ul traditional).

Sistemele informatice care furnizeaza date catre depozitele de date sunt separate din punct de vedere arhitectural de acestea, drept urmare, in multe situatii, utilizatorii depozitelor de date nu pot controla structura si natura datelor din sistemele sursa. Pot apare deci neconcordante intre sursele de date si depozitele de date, neconcordante ce trebuie tratate folosind fie instrumente proprii sistemelor informatice sursa, fie instrumente software asociate depozitelor de date. O solutie pentru tratarea unitara a acestui gen de situatii o reprezinta reproiectarea aplicatiilor-surse de date, astfel incat structura si natura datelor sa fie compatibile cu cerintele depozitelor de date[5].

Exista totusi situatii in care depozitele de date trebuie sa fie incarcate cu date care nu exista in alte sisteme informatice din firma. In acest caz, sistemele informatice tranzactionale pot fi modificate pentru a culege aceste date, sau se pot construi aplicatii noi pentru culegerea datelor, avand in vedere si considerentele exprimate in paragraful anterior: este necesar ca noile aplicatii sa comunice fara probleme cu depozitul de date.

b. Componenta de pregatire a datelor

Componenta de pregatire a datelor este acea parte a arhitecturii depozitului de date in care au loc procesele de extragere, transformare si incarcare a datelor[6], zona de granita intre sursele de date si depozitul de date.

Extragerea reprezinta procesul prin care datele sunt preluate din sursele de date si apoi incarcate in componenta de pregatire. Datele pot fi extrase folosind instrumentele de comunicare intre sursele de date (cel mai des intalnite sunt driverele OLE-DB si ODBC).

Transformarea reprezinta o intreaga colectie de operatii la care sunt supuse datele, cum ar fi:

– curatirea: sunt corectate erorile de tastare, se verifica apartenenta datelor la liste de valori acolo unde este cazul si se fac corectiile de rigoare, datele lipsa sunt incarcate automat acolo unde este posibil;

– combinarea datelor din mai multe surse: dupa cum am amintit anterior, sursele de date ale depozitului de date pot fi eterogene. De aceea este extrem de important sa se asigure compatibilitatea datelor, indiferent de sursa din care au provenit;

– eliminarea datelor duplicate: acest considerent este la fel de important pentru depozitele de date ca si pentru bazele de date si SGBD-uri. Datele duplicate viciaza grav calitatea informatiei extrase din depozitul de date, de aceea este necesar ca toate datele duplicate sa fie eliminate.

Pentru pregatirea datelor se poate utiliza ca suport software un sistem de gestiune a bazelor de date, cel putin din urmatoarele considerente:

– majoritatea SGBD existente poseda o colectie de drivere de comunicatie ce permit preluarea de date din diversele surse ale depozitului de date;

– curatirea si combinarea datelor se pot implementa facil folosind procedurile stocate sau interogarile de tip „actiune” din SGBD-uri, mai mult, operatiunile de transformare pot fi automatizate;

– bazele de date contin instrumente pentru eliminarea duplicatelor (cheile primare) si pentru asigurarea integritatii (cheile externe). Aceste mecanisme pot fi utilizate fara probleme pentru asigurarea unicitatii si integritatii datelor ce vor migra in depozitul de date.

Aceasta varianta presupune efectuarea urmatoarelor operatiuni:

– datele sunt incarcate in una sau mai multe baze de date, cu ajutorul driverelor de comunicatie;

– cu ajutorul instrumentelor specifice SGBD folosit, se executa operatiile de transformare a datelor;

– datele transformate pot fi incarcate in depozitele de date.

Se estimeaza ca 80% din fondul de timp alocat construirii unui depozit de date este alocat acestor activitati.

Incarcarea se refera la operatiunea de populare a depozitului de date, folosind datele extrase si transformate anterior.

c. Depozitul de date propriu-zis

Reprezinta acea parte a arhitecturii depozitului de date in care sunt stocate datele, disponibile pentru a fi accesate de catre utilizatori. Depozitul de date se prezinta sub forma unei colectii de baze de date multidimensionale, fiecare dintre acestea fiind dedicate unui anume segment din activitatea firmei: vanzari, contabilitate financiara, buget etc.

Daca anumite grupuri de utilizatori ai unui depozit de date manifesta cerinte informationale specifice, care necesita exploatarea unui anume segment al depozitului de date, acest segment poarta denumirea de magazie de date.

Procesul de proiectare a structurii unui depozit de date poarta denumirea de modelare dimensionala.

Modelarea dimensionala este similara pana la un punct celei relationale, datele sunt grupate in campuri si tabele. De asemenea, depozitul de date stocheaza, la fel ca o baza de date relationala, date atomice care pot fi supuse unor agregari si consolidari, combinand astfel nivele diferite de granularitate a datelor (daca depozitul de date contine datele la nivelul atomic, datele pot fi usor centralizate/agregate, astfel se creeaza premisele pentru viabilitatea in timp a structurii depozitului de date, capabila sa raspunda la diverse cerinte ale utilizatorilor, in timp ce reciproca nu este posibila – datele centralizate nu pot fi defalcate in date atomice fara ca acestea din urma sa fie stocate in depozit sau disponibile in sursele de date ale depozitului).

Modelarea dimensionala se bazeaza pe urmatoarele notiuni

– masuri: reprezinta datele (in mediul economic, acestea au cel mai adesea caracter cantitativ sau valoric) ce fac obiectul analizei, ca de exemplu: valoarea vanzarilor, cantitatea de produse fabricate/vandute etc. Masurile activitatii trebuie sa descrie situatii de genul: „cat s-a produs”, „cat s-a vandut”, „cat s-a consumat” (cantitativ sau valoric). Din punct de vedere al posibilitatilor de insumare a lor, masurile activitatii pot fi:

o masuri aditive: valorile masurii pot fi agregate fara restrictii in depozitul de date;

o masuri partial (sau semi-) aditive: valorile pot fi supuse insumarii doar pentru o parte a datelor din depozit;

o masuri non-aditive: valorile nu pot fi agregate pentru nici una dintre dimensiunile din depozitul de date.

– dimensiuni: reprezinta criteriile de formare a rezultatelor reprezentate de masuri (cantitatea de produse vandute se poate grupa in functie de gama de produse oferite spre desfacere, de subdiviziunile organizatorice ale firmei unde s-au inregistrat vanzarile etc. – toate aceste criterii pot fi privite ca dimensiuni). In functie de gradul de cuprindere al dimensiunilor, intre acestea se pot stabili relatii de tip parinte-copil, de exemplu dimensiunile Produs si Categorie Produse – dimensiunea a doua o include, putem spune, pe prima. O dimensiune particulara a oricarei activitati ce poate face obiectul modelarii dimensionale este timpul. O dimensiune este caracterizata de existenta mai multor atribute si de valorile acestora. De multe ori, o dimensiune este formata din una sau mai multe ierarhii (acestea se formeaza prin agregarea valorilor atomice ale unuia sau mai multor atribute ale dimensiunii, de exemplu, in cadrul dimensiunii Timp, se poate stabili o ierarhie in functie de luni, trimestre, ani). O ierarhie este formata din mai multe nivele intercorelate (in exemplul prezentat anterior, Luna, Trimestrul si Anul reprezinta nivele ale dimensiunii Timp). O dimensiune poate avea doua sau mai multe ierarhii alternative (pentru o dimensiune Clienti se poate defini o ierarhie in functie de localizarea geografica a clientilor – localitati, judete, si una in functie de specificul activitatii lor – subdomenii si domenii de activitate). Intre nivele se definesc legaturi, de la nivelul cel mai inalt (cu granularitatea cea mai mica) pana la nivelul cel mai detaliat. Intre doua nivele adiacente din cadrul unei ierarhii se stabileste o relatie de tip parinte-copil (nivelul superior joaca rolul de parinte iar nivelul inferior rolul de copil) ;

– tabelele de fapte: cuprind campurile ce reprezinta masurile activitatii, precum si campuri ce permit crearea de legaturi cu dimensiunile. Tabelul de fapte reprezinta elementul central al depozitului de date, deoarece stocheaza datele atomice (la nivel de tranzactie) ale activitatii analizate, precum si criteriile dupa care se va face analiza. Inregistrarile (randurile) din tabelul de fapte poarta denumirea de fapte. In cadrul unui tabel de fapte, raportul dintre masurile activitatii si dimensiuni este unitar (masurile din tabelul respectiv partajeaza aceleasi dimensiuni). Lista dimensiunilor prezente intr-un tabel de fapte indica granularitatea tabelului, care este identica deci pentru toate inregistrarile tabelului;

– tabelele dimensionale: contin campurile ce reprezinta dimensiunile (cum ar fi clientii, produsele). Pentru a asigura o analiza cat mai completa a datelor, este de dorit ca tabelele dimensionale sa includa cat mai multe atribute, care sa reflecte cat mai multe caracteristici ale criteriilor de analiza definite sub forma de dimensiuni. Spre deosebire de tabelele de fapte, in tabelele dimensionale sunt mai putine inregistrari, deoarece tabelele de fapte stocheaza toate tranzactiile firmei, in timp ce tabelele dimensionale stocheaza, o singura data, anumite elemente care intervin in tranzactii. Astfel, un tabel pentru dimensiunea Produse va contine lista produselor firmei, in timp ce tabelul de fapte pentru vanzari de produse va inregistra fiecare vanzare pentru fiecare produs. Este de asemenea de dorit ca tabelele dimensionale sa contina cat mai putine atribute codificate si cat mai multe atribute explicitate, pentru a asigura reprezentarea cat mai usoara in rapoarte a elementelor descrise de atributele respective.

Criteriul de unicitate a inregistrarilor mentionat anterior impune definirea unor chei in tabele, care sa asigure indeplinirea acestui obiectiv. Pentru tabelele dimensionale, definirea cheilor poate urma acelasi principiu ca si in cazul unui model relational (de fapt, tabelele dimensionale se aseamana foarte mult cu tabelele de nomenclatoare din modelele si bazele de date relationale). Pentru tabelele de fapte, se definesc chei externe, reprezentate de cheile primare ale tabelelor dimensionale care reflecta dimensiunile existente in tabelele de fapte. Prin combinarea cheilor externe se poate defini o cheie primara, compusa, pentru fiecare tabel de fapte. Legatura intre tabelele de fapte si tabelele dimensionale se realizeaza prin perechi de campuri de legatura cheie primara – cheie externa (similar cu legaturile dintre tabelele relationale). Definirea legaturilor intre tabelele dimensionale si de fapte in cadrul unui model dimensional permite pastrarea integritatii datelor.

Modelarea dimensionala este un proces iterativ, care cuprinde urmatoarele etape:

analiza activitatii ce va face obiectul modelarii. Cel mai adesea, beneficiarii depozitului de date isi vor exprima nevoile informationale, indicand ce anume informatii doresc sa primeasca din depozitul de date. Odata identificate informatiile, se poate trece la identificarea surselor de date pentru viitorul depozit de date si la stabilirea procedurilor de extragere a informatiilor dorite. Daca de exemplu se doreste construirea unui depozit de date pentru analiza dinamicii si structurii cifrei de afaceri, se vor identifica sursele de date pentru analiza (fie sisteme informatice pentru evidenta vanzarilor/prestarilor de servicii, fie, daca acestea nu exista, fluxul informational al activitatii in cauza);

definirea nivelului de granularitate al datelor din tabelul de fapte. In acest sens se poate tine cont si de sursele de date anterior determinate (sisteme informationale sau informatice din firma). Pentru exemplul considerat anterior, nivelul de granularitate va fi reprezentat de fiecare detaliu din factura de vanzare (fiecare produs care apare in factura va face obiectul unei fapte distincte);

identificarea faptelor si masurilor activitatii;

definirea dimensiunilor care caracterizeaza faptele. In cazul analizei dinamicii si structurii cifrei de afaceri, dimensiunile vor fi construite pe baza surselor de venituri ale firmei (bineinteles, sunt considerate doar veniturile ce se vor include in cifra de afaceri): produse vandute, organizarea activitatii de desfacere (agenti de vanzari sau magazine), clienti etc. De un real folos in definirea dimensiunilor sunt sursele de date de la care se porneste.

Modelarea dimensionala a depozitelor de date trebuie sa tina cont de urmatoarele considerente:

tabelele de fapte trebuie sa contina datele detaliate, la nivel de tranzactie si nu date agregate. Agregarea si insumarea datelor trebuie sa se realizeze doar cu ajutorul instrumentelor de interogare a datelor. Acest element este esential pentru a asigura o cat mai mare flexibilitate in interogarea datelor. Modificarea cerintelor informationale ale utilizatorilor depozitelor de date nu constituie o problema foarte dificila in acest caz;

modelele dimensionale trebuie sa functioneze la nivel de firma, pentru a se evita datele si elementele duplicate. Instrumentele de interogare permit definirea de magazii de date pe baza depozitelor de date. Chiar daca ulterior se vor utiliza magazii de date pentru a satisface cat mai bine necesitatile informationale ale unui anumit grup de utilizatori, magaziile trebuie extrase din depozitele de date;

in proiectarea unui depozit de date, principalul criteriu pe care trebuie avut in vedere il reprezinta nevoile informationale ale beneficiarilor depozitului de date, corelat cu necesitatea ca acestia sa acceseze cat mai usor datele ce le sunt necesare.

Exista trei variante de modele utilizate in proiectarea unui depozit de date:

– modelul stea (star): presupune existenta unui singur tabel de fapte, de care sunt legate toate tabelele dimensionale ale modelului;

– modelul fulg de nea (snowflake): presupune existenta unui singur tabel de fapte, dar nu toate tabelele dimensionale sunt legate direct de acesta, ci dimensiunile legate prin relatii de tip parinte-copil sunt reprezentate prin tabele dimensionale separate. Tabelele asociate dimensiunilor parinte sunt legate numai de tabelele asociate dimensiunilor copil, acestea din urma fiind legate de tabelul de fapte;

– modelul constelatie: se caracterizeaza prin existenta mai multor tabele de fapte, partajate de tabelele dimensionale corespunzatoare.

Componentele client

Putem aprecia ca aceste ultime componente sunt la fel de importante ca si depozitul de date propriu-zis, deoarece de folosirea corespunzatoare a acestora depinde calitatea informatiilor ce vor fi puse la dispozitia utilizatorilor finali. Componentele client se pot regasi sub forma unor simple instrumente utilitare de interogare a depozitelor de date, mergand pana la aplicatii complexe ce folosesc modele decizionale avansate pentru a prezenta informatiile.

Modelarea depozitelor de date

Depozitele de date (data warehouse) furnizează arhitecturi și instrumente utile

conducerii executive (business executives) prin organizarea sistematică, înțelegerea și

utilizarea datelor în luarea deciziilor strategice. Un mare număr de organizații

consideră că sistemele data warehouse dispun de instrumente valoroase în mediul

economic de astăzi, mediu competitiv și în rapidă evoluție. în ultimii ani multe firme

au cheltuit milioane de dolari cu realizarea de depozite de date. Multă lume își dă

seama că în condițiile competiției sporite din fiecare industrie, depozitele de date sunt

armele care trebuie marketingului, reprezentând calea de a păstra clienții. Primele

domenii care au adoptat tehnologia depozitelor de date au fost telecomunicațiile,

băncile și comerțul cu amănuntul. Ulterior depozitele de date au pătruns și în alte

domenii cum ar fi industria farmaceutică, sistemul sanitar, asigurări, transporturi etc.

Studiile statistice arată că telecomunicațiile și sistemul bancar se mențin în top

întrucât alocă cel puțin 15% din bugetul IT pentru proiecte referitoare la depozite de date.

2.6 CONCEPTE DE BAZĂ PRIVIND DEPOZITELOR DE DATE

DEPOZITE DE DATE – DELIMITĂRI CONCEPTUALE

Depozitele de date (data warehouse) au fost definite în foarte multe moduri

încât este destul de dificil de formulat o definiție riguroasă. în sens larg, un depozit de

date reprezintă o bază de date care este întreținută separat de bazele de date

operaționale ale organizației. Datele din sistemele sursă sunt extrase, curățite,

transformate și stocate în depozite specialeîn scopul sprijinirii proceselor decizionale.

Depozitele de date sprijină procesarea informațiilor furnizând o platformă solidă de

consolidare a datelor istorice pentru analiză. Un depozit de date este o sumă de date

consistentă din punct de vedere semantic care servește la o implementare fizică a unui

model de date pentru sprijinirea deciziei și stochează informații pe care o organizație

le solicită în luarea deciziilor strategice. În concordanță cu W. H. Inmon, liderul în

construirea sistemelor data warehouse, „un depozit de date este o colecție de date

orientate pe subiecte, integrate, istorice și nevolatile destinată sprijinirii procesului de

luare a deciziilor manageriale. În sinteză, definiția prezentată mai sus exprimă

caracteristicile majore ale depozitelor de date:

• orientare pe subiecte; _ caracter istoric

• integrare; _ persistenta datelor

.

Orientarea pe subiecte.

Sistemele operaționale tradiționale erau focalizate pe datele

cerute de compartimentele funcționale ale întreprinderii. Odată cu reingineria

proceselor (Business Process Reengineering – BPR) întreprinderile încep să axeze pecerințele decizionale ale echipelor de conducere. Sistemele operaționale moderne suntorientate pe cerințele întregului proces tranzacțional și sprijină execuția proceselor dela început până la sfârșit. Un depozit de date merge dincolo de informațiiletradiționale prin focalizarea pe subiecte ale activității întreprinderii cum ar fi: clienți,vânzări, profituri etc. Aceste subiecte necesită informații din diverse surse pentru afurniza o imagine completă a domeniului. în loc de a se concentra pe procesareaoperațiilor și tranzacțiilor zilnice dintr-o organizație, un depozit de date se focalizeazăpe modelarea și analiza datelor pentru luarea deciziilor. Din acest motiv, depozitele dedate oferă, în mod tipic, o viziune simplă și concisă relativă la un subiect specificexcluzând datele care nu sunt utile în procesul de sprijinire a deciziei.Integrarea. Un depozit de date este, în mod uzual, construit prin integrarea unormultiple surse heterogene: baze de date relaționale, fișiere, înregistrări privindtranzacții online. Tehnicile de curățire a datelor (data cleaning) și de integrare suntaplicate pentru a asigura concordanța în convențiile de atribuire a numelor, decodificare a structurilor, de atribuire a valorilor ș.a.m.d.

Caracterul istoric. Datele sunt stocate pentru a furniza informații în perspectivă

istorică (de exemplu, 5-10 ani în urmă). Astfel decidenții pot consulta valorile

succesive ale acelorași date pentru a determina evoluția în timp și a calcula anumițiindicatori.

Persistența datelor. Datele dintr-un depozit sunt permanente și nu pot fi modificate.O actualizare a depozitului de date, ca urmare a modificărilor efectuate în datele sursă,însemnă adăugare de date noi fără a modifica sau șterge datele existente. Un depozitde date este întotdeauna memorat separat din punct de vedere fizic de dateletransformate din alte aplicații. Datorită acestei separări, un depozit de date nu necesitămecanisme de procesare a concurenței. în mod uzual solicită numai două operațiuni înaccesarea datelor: încărcarea inițială a datelor și accesul la date. Alte definiții aledepozitelor de date surprind, cu unele nuanțări, aceleași elemente esențiale:

• Un depozit de date conține un volum foarte mare de date. Unele dintre acestedate provin din sursele operaționale ale organizației, altele pot proveni din

surse externe;

• Depozitul de date este organizat astfel încât să faciliteze folosirea datelor în scopuri decizionale;

• Depozitul de date furnizează instrumente prin intermediul cărora utilizatorii

finali pot accesa rapid datele.

MODELE DE DATE MULTIDIMENSIONALE

Cubul de date permite modelarea și vizualizarea datelor în dimensiNr. crt. Trăsături OLTP OLAP

Destinația Procese operaționale Procese informaționale

Orientarea sistemului Tranzacții Analize

Utilizatori Funcționari, Specialiști, manageri,

administratori BD,

profesioniști BD

executivi, analiști

Funcții Operații zilnice Cerințe informaționale pe termen

lung, asistarea deciziei

Instrumente folosite în

proiectare

Diagrame E-A Star/ snowflake

Nr. crt. Trăsături OLTP OLAP

Caracterul datelor Curente, noutate garantată Istorice, precizie menținută în timp

Nivelul de sinteză Primitive, detaliere ridicată Sintetizare, consolidare

Unitatea de lucru Scurtă, tranzacții simple Interogări complexe

Scheme de acces Read/write Aproape întotdeauna Read

Focalizare Culegere date Furnizare informații

Număr de înregistrări

accesate

Zeci Milioane

Număr de utilizatori Mii Sute

Mărimea bazelor de date 100 MB – GB 100 GB – TB

Priorități Performanțe ridicate,

disponibilitate ridicată

Flexibilitate ridicată, autonomie

utilizatori finali

Concepte

Înviziunea lui Barry Devlin, un depozit de date înseamnă „o stocare a datelor unitară,completă și consistentă obținută dintr-o varietate de surse, disponibilă utilizatorilorfinali într-un mod ușor perceptibil și utilizabil în contextul afacerii. Ralph

Kimball spune ca „depozitul de date oferă acces la datele organizaționale; datele conținute sunt consistente; datele pot fi separate și combinate în funcție de fiecare dimensiune sauaspect al afacerii. Depozitul de date include, de asemenea, un set de instrumentepentru interogare, analiză și prezentare a informațiilor; reprezintă locul în caresuntpublicate datele folosite; calitatea datelor conținute în depozit reprezintă o premisăpentru reingineria afacerii.” Sam Anahory subliniază finalitatea depozitelor de dateprecizînd că un depozit de date include „datele … și procesele manageriale … care facinformațiile disponibile, permițând managerilor să ia decizii corect fundamentate”.De asemenea, o serie de firme și-au adus contribuția în definirea, dezvoltarea șipopularizarea tehnologiilor data warehouseIBM, Software AG, Oracle, Microsoft,Prism Solutions etc. De ex, Software AG definește depozitul de date ca„punctul central pentru difuzarea informațiilor către utilizatorii finali pentru sprijinireadeciziilor și pentru acoperirea cerințelor informaționale ale conducerii”. IBM a propusun termen propriu pentru depozitele de date: Information Warehouse. După uniiautori, viziunea IBM se referă mai degrabă la conectivitatea globală a diverselor sursede date, fiind un fel de "middleware generalizat" bazat pe arhitectura proprie DRDA -Distributed Relational Database Architecture. De altfel, în literatura de specialitate sefolosesc și simultan cei doi termeni pentru depozite de date: Data Warehouse șiInformation Warehouse. După Efraim Turban, scopul unui "data (or information)warehouse este de a realiza un fond de date (data repository) care să facă accesibiledatele operaționale într-o formă acceptabilă pentru asistarea deciziilor și pentru alteaplicații”. DATA WAREHOUSING În legătură cu depozitele de date o noțiune frecvent utilizată este cea de "datawarehousing" care desemnează procesul de construire și utilizare a depozitelor de date(data warehouse). Construirea unui depozit de date necesită integrarea datelor,curățirea datelor (data cleaning) și consolidarea datelor. Utilizarea unui depozit dedate necesită adesea o colecție de tehnologii de asistare a deciziilor. Acestea permitmanagerilor și specialiștilor (de exemplu, analiști, consilieri etc.) să utilizeze depozitulpentru a obține rapid și convenabil datele necesare și să ia deciziile bazate peinformațiile din depozit. Alți autori utilizează termenul de „data warehousing" pentrua referi numai procesul de construire a depozitului de date, în timp de termenul de„warehouse DBMS" este utilizat pentru a referi conducerea și utilizarea depozitului dedate. În privința utilizării datelor din depozitele de date trebuie precizat că multeorganizații utilizează aceste informații pentru sprijinirea luării deciziilor în diferitedomenii de activitate cum ar fi:

• sporirea focalizării pe clienți care include analize ale vânzărilor (preferințe,

periodicitate, cicluri bugetare, apetit pentru cumpărare etc.);

• reorientarea producției și gestionarea portofoliului de produse, comparând

performanțele vânzărilor pe trimestre, ani, zone geografice, în ordinea celor

mai bune strategii de producție;

• analiza operațiilor și căutarea surselor de profit;

• gestionarea relațiilor cu clienții;

• gestionarea costului activelor corporale.

Data warehousing este, de asemenea, foarte util din punct de vedere al integrării

surselor de date heterogene. Multe organizații colectează, în mod obișnuit, diferite

tipuri de date și întrețin baze de date mari din surse de informații multiple, heterogene,autonome și distributive. Integrarea acestor date și obținerea unui acces eficient la eleeste lucrul cel mai dorit. Multe eforturi au fost depuse în industria bazelor de date și încomunitățile de cercetare pentru îndeplinirea acestui scop. În concepția bazelor dedate tradiționale integrarea bazelor de date heterogene este realizată de „wrappers" șiintegratori (integrators) sau mediatori (mediators) asupra bazelor de date multiple (ex.IBM Data Joiner, Informix Data Blade). Când o interogare este pusă unui site client,un dicționar de metadate este utilizat la transformarea interogării în interogăricorespunzătoare site-urilor heterogene implicate. Aceste interogări sunt atunci mapateși transmise proceselor locale de interogare. Rezultatele primite de la diferite site-urisunt integrate în răspunsul global. OBIECTIVELE DATA WAREHOUSE

În sinteză, scopurile unui depozit de date sunt următoarele:

• Să furnizeze utilizatorilor accesul sporit la date;

• Să furnizeze o singură versiune a adevărului;

• Să înregistreze cu acuratețe trecutul;

• Să „jongleze" cu nivelurile de acces sinteză/detaliu la date;

• Să separe prelucrările de nivel operațional și analitic;

Acces sporit la date pentru utilizatori. Depozitul de date furnizează accesul la

datele integrate ale întreprinderii, anterior blocat prin căi neprietenoase. Utilizatorii

pot acum să stabilească, cu un minim de efort, o conexiune garantată la depozitul de date prin intermediul unui microcalculator. Securitatea este întărită prin „the

warehouse front-end application", prin serverul bazei de date sau prin ambele.

O singură versiune a adevărului. Datele din depozitele de date sunt consistente și au

calitatea asigurată înainte de a fi puse la dispoziția utilizatorilor finali. în măsura în

care se se utilizează o sursă comună de date, depozitele de date pun capăt dezbaterilor privind veridicitatea datelor utilizate sau citate în ședințele de lucru. Depozitul de date începe să fie resursa comună de date pentru nivelurile decizionale din organizații..Menționăm că „o singură versiune a adevărului" este adesea posibilă numai după multe discuții și dezbateri asupra termenilor utilizați în organizație. De exemplu,termenul de „client rău platnic" poate avea mai multe înțelesuri: client care nu plăteștela timp, client care nu plătește decât parțial, client care nu plătește niciodată etc. Ar putea fi stabilită și o altă accepțiune: clienți care au datorii mai vechi de o lună. În mod sigur aceste accepțiuni au influență asupra proceselor decizionale și asupra pertinenței deciziilor. Înregistrarea cu acuratețe a trecutului. Multe date primite de manageri nu sunt semnificative dacă nu sunt comparate cu datele anterioare. De exemplu, rapoartele care compară performanțele actuale ale companiei cu cele din anul precedent sunt comune. Rapoartele care arată performanțele companiei pentru fiecare lună din ultimii trei ani pot fi foarte interesante pentru decidenți. Sistemele operaționale nu vor putea

permite acest gen de informații. Un depozit de date va fi utilizat pentru înregistrarea cu acuratețe a trecutului, părăsind sistemele OLPT libere pentru a realiza focalizarea pe corecta înregistrare curentă a tranzacțiilor. Datele istorice sunt încărcate și integrate cu alte date în depozit pentru un acces rapid.

Acces combinat sinteză/detaliu la date. Rapoartele dinamice și instrumentele de

interogare OLAP (de exemplu, releveele din programele de calcul tabelar, drill up,

drill down) permit utilizatorilor să vizualizeze informațiile din depozitul de date sub

diferite unghiuri și la diferite niveluri de detaliere. Aceste disponibilități oferite de

depozitele de date reduc timpul și efortul necesar pentru colectarea, formatarea și

filtrarea informațiilor plecând de la date. Separarea prelucrărilor de nivel operațional și analitic. Procesele decizionale și procesele operaționale sunt totalmente divergente arhitectural. încercarea de a să reuni în același sistem informațiile decizionale și operaționale determină ca întreținerea sistemului să devină o problemă. Pornind de la procesele operaționale depozitul de date furnizează o arhitectură separată pentru implementarea deciziilor.

DEPOZITE DE DATE VERSUS BAZE DE DATE

O comparație între bazele de date și depozitele de date este în măsură să ofereo imagime coerentă privind rolul depozitelor de date în organizații precum și

raporturile cu alte tipuri de sisteme informatice. Atât bazele de date cât și depozitelede date conțin mari cantități de date structurate care pot fi consultate rapid datorităstructurilor de acces optimizate și se bazează, în majoritatea cazurilor, pe tehnologiirelaționale. Totuși ele nu au fost proiectate pornind de la aceleași obiective și sediferențiază prin numeroase aspecte. Sistemele de gestiune a bazelor de date suntadecvate aplicațiilor curente de gestiune și servesc la crearea și întreținerea sistemelorde baze de date operaționale. Aceste sisteme cunoscute sub denumirea de sistemeOLTP (On-Line Transaction Processing) au ca obiectiv execuția on-line a tranzacțiilorși a proceselor de interogare. Ele încorporează toate operațiile zilnice dintr-oorganizație cum ar fi: aprovizionări, stocuri, producție, decontări, plăți, contabilitate.Sistemele depozite de date, pe de altă parte, servesc utilizatorii sau specialiștii îndomeniul analizei datelor și luării deciziilor. Aceste sisteme pot organiza și prezentadatele în formate variate în ordinea solicitărilor de la diferiți utilizatori. Aceste sistemesunt cunoscute sub numele de sisteme OLAP (On-Line Analytical Processing).Bazele de date din sistemele operaționale conțin date curente, detaliate care trebuieactualizate și interogate rapid, în condiții de deplină securitate, constituind suportul

sistemelor informaționale de prelucrare a tranzacțiilor (TPS). Depozitele de date sunt concepute special pentru sprijinirea luării deciziilor. Ele au ca obiectiv regruparea datelor, agregarea și sintetizarea lor, organizarea și coordonarea informațiilor provenind din surse diferite, integrarea și stocarea acestora pentru a da decidenților o imagine adecvată care să permită regăsirea și analiza eficace a informațiilor necesare. Interogările obișnuite într-un depozit de date sunt mai complexe și mai variate decât cele din sistemele de gestiune a bazelor de date. Ele se aplică asupra unor volume foarte mari de date și presupun calcule complexe (analiza tendinței, medii, dispersii etc.) care necesită adesea agregări (group by). Deosebirile majore între OLTP și OLAP sunt sintetizate în tabelul de mai jos și iau în considerare următoarele trăsături: utilizatorii și orientarea sistemului, caracterul datelor conținute, nivelul de sinteză, unitatea de lucru, schemele de acces, numărul de înregistrări accesate, mărimea bazelor de date, sistemul de evaluare etc.r. crt. Trăsături O

Atât bazele de date cât și depozitele de date conțin cantități mari de date structurate care pot fi consultate rapid, prin structuri de acces optimizate și se bazează, în majoritatea cazurilor, pe tehnologia relațională.

Sistemele de baze de date relaționale sunt adecvate aplicațiilor curente de gestiune și au ca obiectiv execuția on-line a tranzacțiilor și proceselor de interogare (sunt sisteme tip OLTP – On Line Transaction Processing). Aceste sisteme implementează toate operațiile zilnice dintr-o organizație.

Sistemele cu depozite de date servesc utilizatorilor sau specialiștilor în domeniul analizei datelor și luării deciziilor, pot organiza și prezenta datele în formate variate, în ordinea solicitărilor, de la diferiți utilizatori (sunt sisteme tip OLAP – On Line Analytical Processing).

Bazele de date din sistemele operaționale conțin date curente, detaliate, care trebuie actualizate și interogate rapid, în condiții de deplină securitate, constituind suportul sistemelor informaționale de prelucrare a tranzacțiilor.

Depozitele de date sunt construite special pentru sprijinirea luării deciziilor. Ele au ca obiectiv regruparea datelor, agregarea și sintetizarea lor, organizarea și coordonarea informațiilor provenind din surse diferite, integrarea și stocare acestora pentru a da decidenților o imagine adecvată care să permită regăsirea și analiza eficace a informațiilor necesare.

Interogările obișnuite într-un depozit de date sunt mai complexe și mai variate decât cele din bazele de date. Ele se aplică asupra unor volume foarte mari de date și presupun calcule complexe (analiza tendinței, medii, dispersii etc.), care necesită adesea agregări.

Bazele de date sunt orientate pe client (customer oriented) și sunt utilizate pentru procesarea tranzacțiilor și interogărilor. DD sunt orientate pe piață (market oriented) și utilizate de manageri și analiști de date.

Bazele de Date gestionează date curente care sunt destul de detaliate pentru a fi ușor utilizate înactivitatea operațională.

Depozitele de Date gestionează date istorice, furnizând facilități pentru sintetizare și agregare, precum și pentru stocarea și gestionarea informațiilor cu diferite niveluri de granularitate. Aceste aspecte fac ca datele să fie ușor utilizate de către decidenți, mai ales în tactica și strategia organizației.

La Bazele de Date sursele de date sunt tranzacțiile atomice, iar accesul este de tip citire și scriere.

La Depozitele de Date sursele de date sunt Baze de Date operaționale, iar accesul este cel mai adesea de tip citire pentru interogări complexe.

O bază de date este proiectată pornind de la sarcini și activități cunoscute: indexarea, utilizarea cheilor, căutarea unor înregistrări specifice, optimizarea interogărilor. Interogările unui depozit de date sunt adesea complexe, implicând calcule asupra unor grupuri mari de date cu totalizări pe diferite niveluri, ceea ce presupune activități speciale: de organizare a datelor, de acces.O bază de date presupune procesarea concurentă a tranzacțiilor multiple. Controlul concurenței pentru DD este mult mai simplu deoarece se aplică doar pentru citire.

Comparație între Baze de Date și Depozite de Date

3.1 Comparație între sistemele OLTP și OLAP

Un sistem OLTP este orientat pe client (customer oriented) și este utilizat pentru

procesarea tranzacțiilor și interogărilor. Un sistem OLAP este orientat spre piață

(market-oriented) și este utilizat de manageri, analiști și specialiști. Din punct de

vedere al datelor conținute un OLTP gestionează date curente care, în mod obișnuit,sunt destul de detaliate pentru a fi ușor utilizate în luarea deciziilor curente. Un sistemOLAP gestionează volume mari de date istorice furnizând facilități pentru sintetizareși agregare precum și pentru stocarea și gestionarea informațiilor cu diferite niveluride granularitate. Aceste aspecte fac ca datele să fie ușor utilizate de către decidenți,mai ales în domeniile tactic și strategic. De asemenea, un sistem OLTP este focalizatîn principal pe datele curente dintr-o întreprindere sau dintr-un departament fără areferi date istorice sau date din alte organizații. în contrast, un sistem OLAP cuprindedate istorice și date care provin de la diferite organizații, integrând informații dinsurse heterogene. în sistemele OLTP unitățile de acces sunt, în principal, tranzacțiileatomice. Aceste sisteme necesită mecanisme de control al concurenței și dereacoperire. Accesul la sistemele OLAP este cel mai adesea de tip read-only, cu toateacestea este posibilă realizarea de interogări complexe. De ce nu se execută procesărianalitice on-line (OLAP) direct pe bazele de date existente mai degrabă decât a cheltui

timp și resurse pentru a construi separat un depozit de date? Este o întrebare

pertinentă iar răspunsul poate explica și fundamenta investiția într-un depozit de date.Argumentul forte pentru această separare este promovarea performanței ridicate înambele sisteme. O bază de date operațională este proiectată și adaptată pornind de lasarcini și activități cunoscute cum ar fi indexarea, utilizarea cheile primare, căutareaunor înregistrări specifice, optimizarea interogărilor. Pe de altă parte, interogările unuidepozit de date sunt adesea complexe. Ele implică calcule asupra unor grupuri mari dedate cu totalizări pe diferite niveluri ce pot necesita utilizarea de metode speciale deorganizare a datelor, de acces și implementare bazate pe viziuni multidimensionaleProcesând interogările OLAP într-o bază de date operațională s-ar degrada substanțialperformanțele sarcinilor operaționale. De altfel, o bază de date operațională sprijinăprocesarea concurentă a tranzacțiilor multiple. Controlul concurenței și mecanismelede reacoperire sunt necesare pentru a asigura consistența și robustețea tranzacțiilor. Ointerogare OLAP are nevoie adesea de acces read-only la înregistrări pentrusumarizare și agregare. Controlul concurenței și mecanismele de reacoperire, dacăsunt aplicate pentru operațiunile OLAP pot primejdui execuția tranzacțiilorconcurente și astfel să reducă substanțial consistența unui sistem OLTP. În final,separarea dintre BD operaționale și depozitele de date se bazează pe structuri,conținut, utilizatori și date diferite. Luarea deciziilor necesită date istorice pe cândbazele de date operaționale nu conțin, în mod obișnuit, date istorice. în acest context,datele operaționale, deși abundente, sunt, în mod obișnuit, departe de a fi complete

pentru luarea deciziilor. Asistarea deciziei solicită consolidarea datelor (totalizări și

agregări) din diferite surse, rezultând date de înaltă calitate, curate și integrate. În

contrast, bazele de date operaționale conțin numai date neprelucrate (primare)

detaliate, cum sunt tranzacțiile care trebuie consolidate înaintea analizelor.

BIBLIOGRAFIE

Universitatea Spiru Haret-Arhitectura BAzelor de date de DOina Fusaru an 2002

www.wikipedia.ro

www.wikipedia.com

Manual utilizare MS acces 2003

Abordari-de-tip-Data-Warehousing-Implementare-in-MS-SQL-Server-2005

http://biblioteca.regielive.ro

http://biblioteca.regielive.ro -Depozite de Date – Oracle Warehouse

-Solutii de Organizare a Datelor in Depozite de Date

– Crearea de Baza de Date in Acces

http:/www.creeaza.com/referate/management/Depozite-de-date813.php

Universitatea Spiru Haret –sisteme informatice pentru asistarea deciziei economice

Zenovic Gherasim Doina Fusaru Maria Andronie

Programarea Bazelor de Date cu Visual C++6-editura Teora-Lyn Robison-2002

BIBLIOGRAFIE

Universitatea Spiru Haret-Arhitectura BAzelor de date de DOina Fusaru an 2002

www.wikipedia.ro

www.wikipedia.com

Manual utilizare MS acces 2003

Abordari-de-tip-Data-Warehousing-Implementare-in-MS-SQL-Server-2005

http://biblioteca.regielive.ro

http://biblioteca.regielive.ro -Depozite de Date – Oracle Warehouse

-Solutii de Organizare a Datelor in Depozite de Date

– Crearea de Baza de Date in Acces

http:/www.creeaza.com/referate/management/Depozite-de-date813.php

Universitatea Spiru Haret –sisteme informatice pentru asistarea deciziei economice

Zenovic Gherasim Doina Fusaru Maria Andronie

Programarea Bazelor de Date cu Visual C++6-editura Teora-Lyn Robison-2002