Sistem Informatic de Analiza a Bazelor de Date Multidimensionale
TEMA: SISTEM INFORMATIC DE ANALIZĂ A BAZELOR DE DATE MULTIDIMENSIONALE
CUPRINS
CAPITOLUL 1. Baze de date – elemente fundamentale
1.1. Prezentare generala a bazelor de date
1.2. S.G.B.D.R – prezentare generala
1.3. Elemente caracteristice BDM si BDO
1.4. Procesarea analitică a informațiilor
1.4.1. Arhitectura sistemelor de analiză multidimensională
1.4.2. Rolul motorului analitic
1.4.3. Elemente definitorii privind interfața client a aplicațiilor bazate pe motorul analitic și depozitele de date
CAPITOLUL 2. OLAP: modelare si analiza multidimensionala
2.1. Elemente introductive
2.2. Denormalizarea modelului bazei de date
2.3. Modelarea multidimensionala
2.3.1. Tipuri de modele multidimensionale
2.3.2. Avantaje și dezavantaje ale modelului multidimensional
2.4. Optimizarea la nivel fizic a bazelor de date multidimensionale
2.4.1.Partiționarea tabelelor
2.4.2. Analiza datelor prin intermediul tehnologiilor MOLAP și ROLAP
CAPITOLUL 3. Explorarea datelor din BDM (Data Mining)
3.1. Prezentare generala- definitii, elemente fundamentale
3.2. Gestiunea BDM folosind MS SQL Server
3.3. Business Inteligence – concept și fundament
3.3.1. Depozitele de date și componentele de business inteligence
3.3.2. Proiectarea soluțiilor de business inteligence
3.4. Limitele sistemelor tranzacționale în analiza informațiilor din bazele de date
3.5. Elemente fundamentale privind depozitele de date
3.6. Clasificarea depozitelor de date
CAPITOLUL 4. Studiu de caz
4.1. Descrierea generală a aplicației (Visual FoxPro)
4.2. Formulare și rapoarte ale aplicației
4.3. Structura tabelelor aplicației
BIBLIOGRAFIE
CAPITOLUL 1. Baze de date – elemente fundamentale
1.1. Prezentare generala a bazelor de date
Activitatea umană include o mulțime de activități desfășurate pentru a satisface diverse necesități, fie ele de natură materială sau spirituală. Pentru desfășurarea acestor activități s-au dezvoltat intreprinderi și organizații speciale care, in vederea indeplinirii scopului propus, necesită manevrarea unui volum ridicat de informații.
Au apărut și s-au dezvoltat sisteme informaționale care ocupă astăzi un loc important în funcționarea complexului mecanism reprezentat de societatea modernă.
Sistemele informatice sunt sisteme de organizare, manevrare și exploatare a informațiilor (respectiv a datelor), specifice unui anumit domeniu de activitate, cu ajutorul calculatorului. Pentru a rezolva problemele legate de manevrarea informațiilor
reprezentate prin intermediul datelor, apare ca o necesitate existența unor modele și mecanisme de organizare a datelor deoarece, de modul în care sunt organizate datele depinde eficiența sistemului informatic. Bazele de date, ca principale componente ale sistemelor informatice, oferă tocmai aceste modele și mecanisme de organizare a datelor.
Conceptul de bază de date a apărut în 1969 cu ocazia prezentării primului raport CODASYL în cadrul unei conferințe de probleme de limbaje de gestiune a datelor. Evoluția metodelor și tehnicilor de organizare a datelor a fost determinată de necesitatea de a avea un acces cât mai rapid și ușor la un volum din ce în ce mai mare de informații precum și de perfecționarea echipamentelor de culegere, memorare, transmitere și prelucrare a datelor.
Ideea principală a organizării datelor în baze de date se sprijină pe existența unui fișier de descriere globală a datelor prin care se realizează independența programelor față de date și a datelor față de programe.
Accesul oricărui utilizator la baza de date se realiza prin intermediul unui fișier de descriere globală a datelor. Fișierul de date conținea colecțiile de date și legăturile dintre ele.
În esență, conceptul de bază de date poate fi definit ca fiind una sau mai multe colecții de date aflate în interdependență, împreună cu descrierea datelor și a relațiilor dintre ele.
-1-
O bază de date astfel definită trebuie să îndeplinească următoarele condiții:
să asigure o independență sporită a datelor față de programe și invers;
structura bazei de date trebuie astfel concepută încât să asigure informațiile necesare și suficiente pentru a satisface cerințele informaționale și de decizie ale utilizatorului;
să asigure o redundanță minimă și controlată a datelor;
să permită accesul rapid la informațiile stocate.
Bazele de date sunt extrem de variate în funcție de criteriile de apreciere considerate. În continuare sunt prezentate câteva criterii de clasificare:
după orientare: generalizate, specializate;
după modelul de date folosit: ierarhice, în rețea, relaționale, orientate obiect;
după amploarea geografică: locale, distribuite;
după limbajele utilizate: autonome (cu limbaje proprii), cu limbaj gazdă, mixte.
Arhitectura generală a bazelor de date a fost standardizată internaținonal și cuprinde următoarele elemente componente:
baza de date propriu-zisă în care se memorează colecția de date;
sistemul de gestiune al bazei de date, care este un ansamblu de programe ce realizează gestiunea și prelucrarea complexă a datelor;
un set de proceduri manuale și automate, precum și reglementările administrative, destinate bunei funcționări a întregului sistem;
un dicționar al bazei de date (metabaza de date), ce conține informații despre date, structura acestora, elemente de descriere a semanticii, statistici, documentație etc.
echipamentele de calcul (hardware) utilizate (comune sau specializate);
personalul implicat (categorii de utilizatori: finali sau de specialitate, analiști-programatori, gestionari, operatori).
Componentele bazei de date pot fi strucurate pe trei nivele, în funcție de clasa utilizatorilor implicați:
nivelul logic. Este dat de viziunea programatorului de aplicații, care realizează programele de aplicații pentru manipularea datelor și structura logică (subschema) corespunzătoare descrierii datelor aplicației;
-2-
nivelul conceptual (global). Este dat de viziunea administratorului bazei de date, care realizează structura conceptuală (schema) corespunzătoare descrierii bazei dedate și administrează componentele bazei de date pentru manipularea datelor;
nivelul fizic. Este dat de viziunea inginerului de sistem care realizează structura fizică corespunzătoare descrierii datelor pe suportul fizic.
Bazele de date multidimensionale au apărut ca urmare a necesităților crescânde de procesare multidimensională a datelor.
Pentru a intelege mai bine ce inseamnă analiza multidimensională a datelor, se face trimitere la tabelele pivotate din EXCEL care sunt accesibile si in SGBD ACCESS. Ca si in cazul tabelelor din Excel, tabelele bazelor de date constau din linii si coloane. Fiecare coloană contine un atribut diferit, iar fiecărei linii îi corespunde o înregistrare.
Să ne imaginam, de exemplu, formarea unei baze de date, tabelară, ce contine nume de persoane si numerele lor de telefon. Vom construi coloane denumite “Nume”, “Prenume” si “Nr. Telefon”. Apoi, vom continua sa adaugam linii, una sub alta, care sa contina datele pe care dorim sa le inregistram. Astfel, daca vom introduce datele de contact a circa 50 de elevi, sa presupunem, vom obtine un tabel cu 50 de linii.
Modalitatea de identificare si extragere a inregistrarilor dintr-o baza de date se face prin intermediul “cheilor”. Fiecare baza de date are una sau mai multe coloane definite a fi “chei primare” sau “chei simple”, unică pentru fiecare tip de înregistrare a bazei de date.
De exemplu, sa presupunem ca tabelul “Elevii Clselor a IX”, contine datele de contact ale fiecarui elev al claselor a IX-a. Va trebui sa selectam o “cheie primara” care sa identifice fiecare elev. Aceasta cheie nu ar trebui sa fie numele elevului, deoarece exista posibilitatea ca doi elevi sa aiba acelasi nume. O alegere mai buna ar fi numarul matricol sau Codul Numeric Personal.
Odata alegerea facuta,. Baza de Date va trebui informata asupra unicitatii acesteia, iar fiecare incercare de a dubla “cheia primara”, nu va fi acceptata de sistem.
Exista Baze de Date capabile sa genereze propriile “chei primare” (ex. Microsoft Access). O altfel de cheie folosita de Baza de date este “cheia compusa”. Aceasta este destinata sa creeze o anume relatie intre tabele.
-3-
Spre exemplu, daca dorim sa adaugam la Baza de Date un tabel cu datele de contact ale tuturor elevilor Colegiului National Matei Basarab (si denumit “CNMB”), dar si cu alte date (numele cadrelor didactice, orar, programa scolara, etc), ar fi impropriu sa regasim aceeasi informatie (datele de contact elevi clasele aIX-a) in doua tabele.
In schimb, se poate crea o relatie intre cele doua tabele.
Sa presupunem ca tabelul “CNMB” foloseste in calitate de “cheie primara” o coloana cu denumirea “Profil clasa”. Pentru a crea o relatie intre cele doua tabele, vom aduaga o noua coloana in tabelul “Elevii Claselor a IX”, intitulata “Profil”, iar pe fiecare linie vom inregistra profilul de invatamant al fiecarui elev de clasa a IX-a.
Astfel, coloana “Profil” din tabelul “Elevii Claselor IX” va deveni cheie compusa in relatia cu tabelul “CNMB”, informatie ce o vom aduce la cunostinta Bazei de Date, care va asigura ca toate inregistrarile din coloana “Profil”, tabelul “Elevi Clasa IX” vor avea corespondenta in tabelul “CNMB”
Modalitatea de Interactionare cu Baza de Date
Cea mai raspandita modalitate de interactionare cu Baza de Date este un limbaj standard denumit Structured Query Language (SQL). Comenzile SQL pot fi impartite in doua sub-limbaje principale:
Data Definition Language (DDL) contine comenzi folosite pentru a crea sau distruge Baza de Date sau obiecte din Baza de Date
Dupa ce structura Bazei de Date este definita de DDL, utilizatorii pot folosi, in continuare, sub-limbajul
Data Manipulation Language pentru a inregistra, extrage sau modifica datele din continutul Bazei de Date.
In prezent, se folosesc, pe scara larga, interfete grafice (Graphical User Interface) care simplifica mult administrarea Bazei de date dar familiarizarea cu limbajul SQL este esentiala, aceasta reprezentand fundamentul Bazelor de Date.
In concluzie, Baza de date, prezinta, in principal, urmatoarele avantaje:
posibilitatea extragerii inregistrarilor ce corespund anumitor crierii
actualizarea simultana a inregistrarilor
interconectarea datelor din diferite tabele
realizarea de calcule complexe
-4-
Bazele de date multidimensionale sunt baze de date care folosesc pentru stocarea si prelucarea datelor, modele si tehnici multidimensionale (indeosebi OLAP si Data Mining).Aplicatiile care se bazeaza pe analiza multidimensionala a datelor sunt cunoscute sub numele de OLAP (ON LINE ANALYTICAL PROCESSING).
Se face astfel dintinctia intre :
OLTP (ON LINE TRANSACTIONAL PROCESSING), care privilegiaza: integritatea si securitatea datelor si tratarea cererilor informationale simple de catre servicii operationale (resurse umane, productie, comert etc.)
Si OLAP, care privilegiaza analiza si manipularea datelor (folosind cereri complexe) in vederea elaborarii strategiei si sunt destinate indeosebi conducerii si controlului de gestiune.
BDO – scop principal
Sistemele informationale operationale (tranzactionale) sunt organizate pe domenii de activitate (marketing, gestiunea resurselor umane, domeniul financiar-contabil, gestiunea vanzarilor etc.) si au ca nucleu baze de date orientate gestiune curenta, numite si baze de date operationale (BDO).
Scopul principal al acestor baze de date este stocarea datelor despre tranzactiile unui anumit domeniu de gestiune.
Baza de date garanteaza persistenta datelor si este conceputa pentru a pastra urma
tranzactiilor (evenimentelor) survenite intr-o organizatie.
OLTP (ON LINE TRANSACTION PROCESSING) reprezinta conceptul care descrie procesarea (prelucrarea) tranzactiilor legate de bazele de date operationale.
Intr-un context tranzactional, modelul de organizare a datelor este destinat sa minimizeze redundantele pentru a mentine fiabilitatea si r din diferite tabele
realizarea de calcule complexe
-4-
Bazele de date multidimensionale sunt baze de date care folosesc pentru stocarea si prelucarea datelor, modele si tehnici multidimensionale (indeosebi OLAP si Data Mining).Aplicatiile care se bazeaza pe analiza multidimensionala a datelor sunt cunoscute sub numele de OLAP (ON LINE ANALYTICAL PROCESSING).
Se face astfel dintinctia intre :
OLTP (ON LINE TRANSACTIONAL PROCESSING), care privilegiaza: integritatea si securitatea datelor si tratarea cererilor informationale simple de catre servicii operationale (resurse umane, productie, comert etc.)
Si OLAP, care privilegiaza analiza si manipularea datelor (folosind cereri complexe) in vederea elaborarii strategiei si sunt destinate indeosebi conducerii si controlului de gestiune.
BDO – scop principal
Sistemele informationale operationale (tranzactionale) sunt organizate pe domenii de activitate (marketing, gestiunea resurselor umane, domeniul financiar-contabil, gestiunea vanzarilor etc.) si au ca nucleu baze de date orientate gestiune curenta, numite si baze de date operationale (BDO).
Scopul principal al acestor baze de date este stocarea datelor despre tranzactiile unui anumit domeniu de gestiune.
Baza de date garanteaza persistenta datelor si este conceputa pentru a pastra urma
tranzactiilor (evenimentelor) survenite intr-o organizatie.
OLTP (ON LINE TRANSACTION PROCESSING) reprezinta conceptul care descrie procesarea (prelucrarea) tranzactiilor legate de bazele de date operationale.
Intr-un context tranzactional, modelul de organizare a datelor este destinat sa minimizeze redundantele pentru a mentine fiabilitatea si coerenta sistemului informational. Din punctul de vedere al utilizatorului, modelul de date este complet transparent.Astfel, utilizatorul nu poate accede la modelul de date decat in mod indirect, prin intermediul aplicatiilor integrate (‘packages’) puse la dispozitia sa.
Datorita acestui fapt, lizibilitatea modelului nu are o prea mare importanta cu exceptia momentului validarii modelului de catre utilizator.
Interogarile sunt in majoritatea cazurilor previzibile ; ele materializeaza cerintele informationale standard specificate de utilizatorii finali pe domenii de activitate.
-5-
Volumul datelor care trebuie accesat pentru a prelucra o tranzactie este in general limitat. Cel mai adesea, numarul de intrari/iesiri asociat fiecarei tranzactii este un numar finit, previzibil. Pentru a efectua prelucrarile necesare unei bune executii, o tranzactie face apel la un numar limitat si finit de structuri.
Este destul de rar cazul in care o interogare tranzactionala sa necesite asamblarea sau agregarea informatiilor ce provin de la un numar mare de tabele de date.
1.2. S.G.B.D.R. – prezentare generala
O baza de date poate fi privita ca o colectie de date stocate pe suporti de memorie externa, adresabile de catre mai multi utilizatori si care satisface cerintele de informare ale acestora.
Sistemul de gestiune al bazei de date (S.G.B.D) reprezinta ansamblul de programme (software) care permite indeplinirea scopului pentru care a fost creata baza de date. El trebuie sa asigure realizarea urmatoarelor activitati :
definirea structurii bazei de date ;
incarcarea bazei de date ;
accesul la date (interogare, actualizare) ;
intretinerea bazei de date (colectarea si refolosirea spatiilor goale, refacerea bazei de date in cazul unui incident) ;
reorganizarea bazei de date (restructurarea si modificarea strategiei de acces) ;
protejarea datelor.
Intr-un alt sens, sistemul de gestiune al bazei de date se constituie intr-o interfata intre utilizator si baza de date, reprezentand mecanismul prin intermediul caruia acesta are acces la date. Pentru a-si putea indeplini functiunile prevazute, unui sistem de gestiune al bazei de date modern îi revin o serie de obiective de îndeplinit, cum sunt :
Asigurarea independentei datelor. Aceasta presupune ca modificarea strategiei de memorare a datelor sau a strategiei de acces la date nu trebuie sa afecteze aplicatia care prelucreaza aceste date. Independenta datelor fata de aplicatie este necesara deoarece : diferite aplicatii au nevoie de viziuni diferite ale acelorasi date ;
-6-
administratorul bazei de date trebuie sa aiba libertatea de a schimba structura de memorare sau strategia de acces, ca raspuns la cerinte (schimbari de standarde, prioritatile aplicatiilor, schimbarea unitatilor fizice de memorare etc.), fara a modifica aplicatiile existente ; baza de date existenta, precum si programele de exploatare a ei reprezinta o investitie importanta la care nu trebuie sa se renunte prea usor. Independenta datelor trebuie privita din doua puncte de vedere : independenta fizica si independenta logica a datelor. Independenta fizica a datelor implica modificarea tehnicilor fizice de memorare a datelor fara a necesita rescrierea programelor de aplicatie. Independenta logica a datelor se refera la posibilitatea adaugarii de noi articole de date sau extinderea structurii conceptuale (globale), 10ar aca aceasta sa impuna rescrierea programelor existente.
Asigurarea unei redundante minime si controlate a datelor din baza de date. Redundanta se refera la numarul de aparitii a unei date in baza de date. In general, stocarea datelor in baze de date ar trebui sa se faca astfel incat fiecare data sa apara o singura data. Totusi, exista cazuri in care pentru a reduce timpul de cautare al unei date si implicit timpul de raspuns la solicitarile utilizatorilor, se accepta o anumita redundanta a datelor. Aceasta redundanta trebuie controlata automat, prin program, pentru a se asigura coerente datelor din baza.
Asigurarea unor facilitati sporite de utilizare a datelor. Aceasta presupune : – folosirea datelor de catre mai multi utilizatori in diferite aplicatii ; – accesul cat mai simplu al utilizatorilor la date, 10ar aca acestia sa fie nevoiti sa cunoasca structura intregii baze de date, acest lucru ramanand in sarcina administratorului_bazei_de_date ; – existenta unor limbaje performante de regasire a datelor, care permit exprimarea sub forma unei conversatii, a unor criterii de selectie a datelor si indicarea unor reguli cat mai generale pentru editarea informatiilor solicitate ; – utilizarea unui limbaj cat mai apropiat de limbajul natural, cu posibilitatea exploatarii bazei de date in regim conversational, lucru care ar oferi posibilitatea exploatarii bazei de date si de catre utilizatori neinformaticieni.
-7-
Asigurarea securitatii datelor impotriva accesului neautorizat la ele. In conditiile bazelor de date, administratorul bazei de date poate prevedea ca accesul la baza de date sa se faca numai prin canale corespunzatoare, si poate, totodata, defini verificari de autorizare realizate oricand se incearca accesul neautorizat la anumite date.
Asigurarea integritatii datelor impotriva unor stergeri intentionate sau neintentionate, prin intermediul unor proceduri de validare, a unor protocoale de control concurent si a unor proceduri de refacere a bazei de date dupa incidente.
Asigurarea partajabilitatii datelor. Partajabilitatea datelor trebuie inteleasa nu numai sub aspectul asigurarii accesului mai multor utilizatori la aceleasi date, ci si acela al posibilitatii dezvoltarii unor aplicatii fara a se modifica structura bazei de date.
Functiile unui sistem de gestiune a bazelor de date
Sistemele de gestiune a bazelor de date au o multitudine de sarcini de indeplinit. Grupand aceste sarcini se obtin activitatile si apoi functiile sistemului de gestiune al bazei de date. Tinand seama de complexitatea sistemului de gestiune, de facilitatile oferite, de limbajele utilizate si tipul bazei de date ce urmeaza a fi gestionata gruparea activitatilor pe functii poate avea un caracter relativ.
In continuare sunt prezentate cateva functii ale sistemelor de gestiune a bazelor de date, functii cu caracter de generalitate, valabil pentru toate tipurile de sisteme de gestiune a bazelor de date.
1. Functia de descriere a datelor, care permite definirea structurii bazei de date cu ajutorul unui limbaj de definire. Definirea datelor poate fi realizata la nivel logic, conceptual si fizic.
La nivelul acestei functii se descriu multitudinea atributelor (campurilor) din cadrul structurii bazei de date, legaturile dintre entitatile bazei de date sau dintre atributele aceleiasi entitatii, se definesc eventualele criterii de validare a datelor, metodele de acces la date, aspectele referitoare la asigurarea integritatii si confidentialitatii datelor.
-8-
2. Functia de manipulare a datelor este cea mai complexa functie si realizeaza urmatoarele activitati :
– crearea bazei de date ;
– încarcarea bazei de date ;
– adaugarea de noi înregistrari (tupluri) ;
– stergerea unor înregistrari ;
– modificarea valorilor corespunzatoare unor campuri ;
– cautarea, sortarea si editarea partiala sau totala a unei înregistrari virtuale etc.
3. Functia de utilizare asigura multimea interfetelor necesare pentru comunicarea tuturor utilizatorilor cu baza de date. In cadrul realizarii acestei functii apar mai multe categorii de utilizatori :
– utilizatori “liberi” sau conversationali. Acestia reprezinta categoria beneficiarilor de informatii (utilizatori finali) care utilizeaza limbajele de interogare a bazei de date intr-o forma simplista. Ei apar ca utilizatori neinformaticieni.
– utilizatori programatori, care utilizeaza limbaje de manipulare, realizand proceduri complexe de exploatare a bazei de date ;
– administratorul bazei de date, care este un utilizator special avand un rol hotarator în ceea ce priveste functionarea optima a intregului ansamblu.
4. Functia de administrare a bazei de date. Aceasta apare ca o functie complexa si este de competenta administratorului bazei de date.
S.G.B.D.R.-urile sunt în general slab adaptate procesului de analiza. Un S.G.B.D.R. poate furniza o lista de valori reiesite dintr-una sau mai multe tabele interogate. Astfel, de exemplu, o baza de date poate contine înregistrari care descriu intr-o forma bidimensionala vanzarile de produse pe regiuni (figura 1.1)
-9-
Figura 1.1. Interogare clasica intr-un SGBD Prin interogari clasice, aplicand o serie de restrictii bazei de date se pot obtine informatii rezultate din incrucisarea celor doua dimensiuni ale bazei de date (produsele vandute pe luna x pentru regiunea y sau repartizarea cheltuielilor asupra ansamblului regiunilor in care sunt distribuit produsele )
Bazele de date operationale, asa cum sunt ele organizate in prezent, nu dau raspuns la intrebari de genul :
-Cati clienti cu varsta cuprinsa intre 25 si 35 de ani din orasele Bucuresti si Constanta au cumparat o masina Dacia in cursul ultimilor 2 ani ?
– Care sunt componentele masinilor de productie ce au avut cel mai mare numar de incidente in perioada 2001-2002 ?
– Care este repartitia vanzarilor pe produse si pe localitati pe ultimele 12 luni ?
Pentru valorificarea superioara a datelor in procesele de management, intreprinderile sunt tot mai interesate :
sa permita un acces universal la baze de date eterogene si eventual distribuite ;
sa asambleze date in acelasi loc fara sa supraîncarce bazele de date operationale. Datele pot proveni din surse interne dar si surse externe ;
sa aiba functii de consolidare automata a datelor ;
sa permita o ameliorare globala a performantei întreprinderii ;
sa dispuna de proceduri care sa permita degajarea de cunostinte care sa fundamenteze mai bine procesul de management.
-10-
Bazele de date multidimensionale (BDM) sunt orientate pe management si au ca sursa principala BDO. Ele pot constitui suport pentru desfasurarea de activitati cum ar fi : analiza vanzari si marketing ; urmarirea si fidelizarea clientilor ; raportare financiara si consolidare ; prognozare planificare pe termen mediu si lung etc.
Sursele de date sunt : interne (in principal BDO sau fisiere de date) si/sau externe (cum ar fi : bazele de date sectoriale elaborate de organisme de sinteza sau de coordonare ca si : Directia de statistica, Camera de comert si industrie etc. ).
Prin analiza datelor din BDM se pot obtine informatii sau se pot deduce noi cunostinte (figura 1.2)
DATE
INFORMATII
Figura 1.2. Integrarea datelor, informatiilor, cunostintelor intr-o BDM
BDM poate fi definită astfel :
"Un ansamblu de date, constituite prin extractie sau transformare de date din bazele de date (fisiere) interne sau externe, variind in timp, organizate multidimensional si explorate folosind interogari conventionale sau tehnici specifice de analiza simpla (OLAP) sau de analiza avansata (Data Mining)."
-11-
In figura 1.3. se prezinta arhitectura generala de organizare si valorificare a unei BDM.
Date interne
Figura 1.3. Arhitectura generala de organizare si valorificare a unei BDM
-12-
I.3. Elemente caracteristice BDM si BDO
O sinteza cu caracteristicile celor doua tipuri de baze de date este prezentata astfel :
Elementele ce particularizeaza o BDM sunt :
Organizare pe teme ale conducerii. Datele sunt structurate avand la baza teme ale conducerii si nu procese functionale cum era în cazul bazelor de date operationale;
Memoria organizatiei. BDM este vazuta ca o memorie a întreprinderii. Volumul datelor este colosal si în armonie cu sistemele operationale.
Integrare date. Integrarea datelor constituie problema cel mai greu de rezolvat (acestea tin îndeosebi de codificarea datelor); ea vizeaza în egala masura datele interne si externe.
Date temporale (în literatura de specialitate mai sunt numite si istorice). Intr-o BDM datele temporale permit efectuarea de extrapolari bazate pe evenimente trecute.
Redundanta. Datele sunt stocate în BDM cu eventuale redundante (nu se poate înca vorbi de un formalism riguros pentru normalizarea datelor din BDM).
-13-
Date nevolatile. Datele din BDM nu se actualizeaza. O anume interogare efectuata la anumite intervale de timp determina obtinerea aceluiasi rezultat.
Date detaliate1. Sunt deduse (prin extragere si transformare) din bazele de date operationale. Într-o BDM se pot stoca date detaliate replică a datelor curente (operationale) sau a datelor pe mai multi ani.
Date agregate. Ele trebuie sa fie astfel stocate încat sa permita navigarea utilizatorilor de la sinteza la detaliu si invers.
Metadate. Una din componentele de baza ale unei baze de date o constituie metadatele. Acestea contin informatii despre BDM si procesele asociate si sunt destinate : utilizatorilor finali (semantica datelor utilizate), administratorului bazei de date (structura bazei de date), administratorului de date care este si garantul dictionarului de date, etc.
Data Marts. Intreprinderile mari pot descentraliza BDM si construi astfel ceea ce literatura de specialitate numeste DataMart.
OLAP. Termen introdus de catre E.F.Codd, OLAP (On-Line Analytical Processing) desemneaza o categorie de aplicatii si tehnologii ce permit colectarea, stocarea, tratarea si restituirea de date multidimensionale în scopuri de analiza2.
Data Mining. Termen folosit pentru a desemna procese de explorare a datelor utilizand tehnici izvorate din inteligenta artificiala si statistica in scopuri de analiza3 a datelor.
1 Nivelul de detaliu difera, în general, de cel din bazele de date operationale.
2 Numită si analiză simplă.
3 Numită si analiză avansată.
-14-
1.4. Procesarea analitică a informațiilor
Un server OLAP este un motor de tip multiutilizator, de mare capacitate pentru manipularea datelor, proiectat astfel încât sa poata lucra cu structuri de date multidimensionale. O structură multidimensională este alcătuită astfel încât orice dată poate fi localizată și accesată prin intersecția coordonatelor sale de-a lungul acelor dimensiuni care definesc amplasarea datei. Proiectarea serverului și a structurii de date sunt realizate astfel încât să se poată realiza atât optimizarea regăsirii ad-hoc a informației, cât și calcule flexibile folosind formule matematice.
OLAP și magazia de date sunt complementare, fiind însă important să se facă distincția între cele două tehnologii. Astfel, în timp ce magazia de date acumuleaza informatii cu caracter tactic într-o baza de date specializata, cu scopul de a furniza răspunsuri la întrebări de genul “Cine?” și “Ce?”, OLAP folosește de obicei o vedere cu mai multe dimensiuni a unor date agregate, pentru a putea răspunde la întrebări suplimentare de tipul “De ce…?” (“Why…?”) și “Ce se întâmplă dacă…?” (“What if…?”), tipice pentru sistemele de asistare a deciziilor.
1.4.1.Arhitectura sistemelor de analiză multidimensională
Fiind o tehnologie relativ nouă, modelul care s-a impus pentru sistemele orientate spre analiza multidimensională este unul de tip client/server în trei straturi:
Bazele de date formează nivelul cel mai de jos, responsabil cu stocarea și regăsirea datelor. De regulă, aplicațiile tranzacționale utilizează sisteme relaționale, dar pentru depozitele de date se folosesc și sisteme multidimensionale. Dat fiind volumul mare de date, este recomandabil ca SGBD-urile folosite să ofere suport pentru prelucrări paralele (interogări, încărcări și indexări paralele) și distribuite, să dispună de mecanisme performante de indexare și de optimizare, să ofere un nivel înalt de siguranță;
Logica aplicației este susținută de un “motor analitic” (OLAP Engine), acționând ca server pentru instrumentele desktop. Această componentă are o contribuție importantă la analiza datelor și furnizarea informațiilor solicitate de utilizatori;
-15-
Logica prezentării este constituită din instrumentele mânuite de utilizatorul final. Acestea au acces la datele din 19nalyti prin intermediul motorului 19nalytic. Dacă motorul 19nalytic este un instrument foarte specializat și care de regulă este cumpărat la un preț dat, aplicațiile front-end folosite de utilizatorii finali sunt 19nalyti de diverse. Există aplicații generale care răspund 19nalytic1919 de bine nevoilor unei categorii largi de utilizatori, există instrumente specializate pe domenii (cum ar fi, de pildă, analiza financiară) și în fine, există posibilitatea de a dezvolta instrumente foarte specifice unor anumite nevoi, utilizând medii de dezvoltare comerciale (de pildă Visual Basic) și interfețe de programare furnizate de serverul OLAP.
1.4.2. Rolul motorului 19nalytic
Principala sarcină a motorului OLAP este de a prelua cererile exprimate de clienți și, pe baza consultării metadatelor, generează cererile necesare pentru obținerea datelor ce vor fi redirectate către clienți. În plus, datelor obținute li se pot aplica la acest nivel o serie de prelucrări:
Generarea de interogări – se bazează pe criteriile furnizate de clienți sub forma unor formule exprimate prin operatori logici. Pentru a genera interogările (SQL sau specifice SGBD-urilor multidimensionale), motorul OLAP dispune de algoritmi care aplică criteriile asupra metadatelor, obținând căile de acces la datele referite și transformările necesare. Urmează apoi optimizarea cererii în vederea obținerii unei viteze optime;
Manipulările matematice – se aplică pentru a 19nalyt datele la forma dorită de clienți. Acestea constau de cele mai multe ori în calcularea unor metrici derivate pe baza unor formule date, analize statistice complexe etc.;
Sintetizarea rezultatelor – este o altă sarcină a motorului 19nalytic. Deși depozitul de date conține și date deja 19nalytic19, deseori utilizatorul dorește consolidarea unor sinteze pe baza unor combinații de 20nalytic20 care nu au fost prevăzute. În această situație, motorul 20nalytic solicită depozitului toate datele necesare la nivel de detaliu și realizează totalizările necesare.
-16-
1.4.3. Elemente definitorii privind interfața client a aplicațiilor bazate pe motorul 20tilize20 și depozitele de date
Din punct de vedere al utilizatorului final, aplicația front-end pe care o folosește trebuie să-I asigure două funcționalități importante: navigarea liberă prin depozitul de date în căutarea informațiilor relevante și posibilități diverse de prezentare a datelor. Aceste funcționalități sunt strâns legate între ele și este greu de spus care operațiune este de navigare și care de prezentare.
Stabilirea criteriilor de selecție este primul pas în orice analiză. Utilizatorul trebuie să poată exprima cu ușurință criterii simple, bazate pe valori ale atributelor și/sau pe valori ale metricilor. Aceste criterii simple trebuie să poată fi apoi combinate prin operatori logici și să poată fi salvate în biblioteci pentru eventuale reutilizări.
Rotațiile sunt operații care permit utilizatorului să găsească 20tilize20e20e care-l interesează specificând dimensiunile și direcțiile de rotație sau indicând un pivot.
Schimbarea nivelului de agregare permite găsirea nivelului de granularitate optim pentru analiză. Se poate adânci analiza spre nivele de detaliu (drill-down) pentru anumite dimensiuni, în timp ce pentru alte dimensiuni se crește nivelul de agregare (drill-up). De regulă, căile de navigare sunt date de ierarhiile de 20tilize20e.
Specificarea modului de prezentare trebuie să permită analistului să găsească modalitățile optime de valorificare vizuală a datelor extrase. În afară de posibilitățile grafice tipice pentru prezentare, este important ca utilizatorul să poată vizualiza tabelar date multidimensionale. În acest sens se pot 20tilize tabele complexe, care să grupeze coloane și linii exprimând dimensiuni diferite (de pildă, timpul și locația geografică), precum și nivele de agregare diferite.
-17-
Cap.2 OLAP: modelare si analiza multidimensionala
2.1. Elemente introductive
Cea mai mare parte a problemelor care se încearca a se rezolva cu tehnologia relationala sunt în realitate de natura multidimensionala.Modelul relational descrie tabelele în doua dimensiuni : linie, coloana, în timp ce modelul multidimensional nu are limite în ceea ce priveste stocarea dimensionala (spatiala) a datelor. Un SGBDR nu este adaptat unor astfel de cerinte în care intervin agregari de date, sintetizari, consolidari si proiectii multidimensionale.Aceasta explica si faptul ca în prezent editorii de SGBDR extind functionalitatile acestora prin adaugarea de componente care sa permita OLAP si Data Mining.
Tehnologiile OLAP se fondeaza pe modelarea si analiza multidimensionala a datelor. Conceptul de baza este cel de hipercub. Datele se regasesc la intersectia dimensiunilor hipercubului si au pentru coordonate atributele ce definesc dimensiunile hipercubului. Hipercubul din figura 2.1. poate fi utilizat pentru a reprezenta vanzarile pe trei dimensiuni :
dimensiune localitati ;
dimensiune produse ;
dimensiune timp (spre exemplu lunile anului).
Figura 2.1. Model multidimensional
-18-
Fundamentul teoretic al tehnologiei OLAP a fost pus de cercetătorul E.F.Codd („părintele” bazelor de date relaționale) încă din anul 1993. Codd a realizat manifestul OLAP care includea un set de reguli care trebuiesc avute în vedere, cu prioritate, la implementarea acestei noi tehnologii.
Punerea în practică a acestor elemente teoretice a avut loc în perioada 1998-1999. Cel mai important pas a fost făcut la începutul anului 1999, când IBM și Oracle au realizat standardizarea tehnologiei OLAP la institutul ANSI. Pe parcursul anului 1999 au fost create diverse versiuni ale sistemelor relaționale DBL și Oracle care permiteau exploatarea acestor noi facilități. Funcțiile OLAP au fost incluse treptat și în celelalte sisteme relaționale.
Cartea albă propusă în 1993 de Codd, intitulată Providing OLAP (On Line Analytical Processing) to User – Analyst: An IT Mandate, conținea 12 reguli, a căror îndeplinire putea califica un produs software ca fiind de tip OLAP.
Pentru ca un sistem informational sa fie cu adevarat performant este absolut necesar ca acesta sa fie proiectat pe componentele sale dimensionale.
OLAP ofera utilizatorilor instrumente ce permit navigarea de la o dimensiune la alta, precum si modalitati de relevare a informatiilor cele mai detaliate. Conceptul OLAP prezinta un mare interes în masura in care poate legitima si populariza abordarea dimensionala în general.
Principiile fundamentale elaborate de cercetătorul E.F.Codd :
viziune conceptuala multidimensionala asupra datelor ;
transparență prin arhitectura deschisa a sistemelor (ascundarea pentru utilizator a eterogenitatii eventuale a datelor) ;
accesibilitate prin ascunderea pentru utilizator a modalităților tehnice de furnizare a datelor (utilizatorul trebuie să preia datele dintr-un univers eterogen: SGBDR, fisiere, date externe organizatiei, WEB, etc.);
performante stabile si independente de complexitatea dimensionala a contextelor analizei;
arhitectura client-server, în care server-ul are un rol de omogenizare a datelor, putandu-se conecta la diferiti clienti ai produselor OLAP ;
prelucrarea generică a dimensiunilor, adică posibilitatea efectuării aceleiasi operatiuni asupra tuturor dimensiunilor ;
-19-
gestionarea dinamică si eficace a matricilor încrucisate, adică aptitudinea de a nu aglomera memoria calculatorului cu celulele care corespund combinărilor dimensionale nule ;
multi-user, adică posibilitatea de acces simultan la acelasi context de analiză pentru mai multi utilizatori ;
operatiuni nerestrictive, adică posibilitatea efectuarii, fara restrictii tehnice, de calcule asupra tuturor combinărilor de dimensiuni posibile si de niveluri ierarhice ;
posibilitatea manipulării intuitive a datelor ;
manipularea intuitivă a datelor ;
număr nelimitat de niveluri de agregare si de dimensiuni, adică absenta (apriori) limitelor numărului de dimensiuni posibile si a numărului de niveluri ierarhice pe fiecare dimensiune în parte.
Pentru a ilustra tehnicile de modelare a bazelor de date multidimensionale, se prezintă un exemplu ce pleacă de la un model normalizat căruia i se aplică o procedură de denormalizare pentru a fi transformat într-un model multidimensional. In figura 2.2. se prezintă un model normalizat de date, care ilustreaza produsele distribuite clienților de către o societate comercială, asigurand livrarea comenzilor către comercianti.
Din punct de vedere al analizei, este interesant de urmărit cum are loc ventilarea veniturilor obținute din vanzări de produse, pe clienti, pe judete, pe regiuni, pe tări importatoare etc.
-20-
Figura 2.2. Model normalizat de date4
Aceasta abordare este clasică si curenta în întreprinderi, în materie de modelare. Odată ce modelul bazei de date se dovedeste a fi normalizat, acesta poate fi implementat într-un sistem de gestiune a bazelor de date, permițand efectuarea multiplelor selecții si actualizări în linie. Intr-un context analitic în care actualizările în linie nu sunt de actualitate, pertinența modelului trebuie să fie reconsiderată.
O primă remarcă de făcut asupra modelului prezentat în figura 1.5 ar fi aceea că, din punct de vedere al analizei, semantica se dovedeste a fi slabă. Informațiile interesante pentru utilizator nu există apriori, acestea trebuind extrapolate pentru a fi cunoscute. Astfel, din model reiese că prețul unitar nu prezintă o valență informațională majoră, cu toate că acesta permite calcularea veniturilor (cifrei de afaceri) si a marjei comerciale.Acesti indicatori analitici vor trebui să fie calculați dinamic, la fiecare cerere de interogare.
4 Model adaptat după Jean Michel Franco, «Le Data Warehouse »
-21-
Din punct de vedere relațional, modelul este complet. Acesta lasă o marjă de autonomie utilizatorului. Dar, această autonomie poate provoca pierderea controlului asupra datelor, dacă, de exemplu fiecare utilizator îsi dezvoltă propria sa viziune despre ceea ce înseamnă o cifră de afaceri.Modelul normalizat prezentat în figura 2.2. este compus din șapte entități. Un model de distribuție implementat în întreprindere, ar putea conține teoretic zeci sau chiar sute de entități si, deci, tot atatea tabele la nivel fizic.
O cerere de interogare lansată pentru corelarea informațiilor (cum ar fi cheltuielile, vanzările sau stocurile) poate implica în funcție de complexitatea modelului conceptual zeci si zeci de tabele legate.Aceste tipuri de interogări vor fi foarte greu de formulat, atat pentru utilizatorul final, cat si pentru proiectantul si/sau administratorul bazei de date.
In sistemele decizionale simple, în care un număr redus de utilizatori lansează interogări asupra unui model de date de mică anvergură, demersul prezentat poate funcționa cu succes, dar în alte cazuri trebuie să se recurgă la alte tehnici si modele de reprezentare a datelor.
Avându-se în vedere complexitatea regulilor propuse de Codd, identificăm cinci elemente fundamentale care califică un produs ca fiind compatibil cu OLAP :
Analiza datelor cere ca sistemul de tip OLAP să permită efectuarea de către utilizator, într-un mod suficient de facil, și intuitiv, a oricărei analize logice sau statistice care este relevantă pentru aplicație. Aceasta include, pe lângă funcții preprogramate și posibilitatea de definire a unor calcule ad-hoc, și furnizarea de rapoarte în orice formă dorită, fără a face apel la limbaje de programare profesionale ;
Sistemul trebuie să furnizeze majorității utilizatorilor datele cerute într-un interval de timp de până la cinci secunde. Pentru analize simple, cerința de timp de răspuns este de o secundă și numai în foarte puține cazuri, excepționale chiar, se admite un timp de răspuns mai mare de 20 de secunde ;
Toate datele primare și informațiile stocate în depozitele dedate date pot sta la baza unor analize ;
Suportul pentru analiza multidimensională din aplicație trebuie să poată furniza vederi conceptuale ale datelor cu mai multe dimensiuni ;
Soluțiile OLAP implică cerințe privind asigurarea confidențialității și posibilitatea accesării de către mai mulți utilizatori a informației disponibile.
-22-
2.2 Denormalizarea modelului bazei de date
Pentru a răspunde exigențelor legate de utilizarea analitică a datelor din bazele de date, trebuie ca modelul normalizat al acestora să fie transformat printr-un proces de denormalizare a modelului datelor, dublat de precalcularea unor agregate care pot introduce redundanțe. Denormalizarea datelor din bazele de date reprezintă un demers pragmatic. Până în prezent nu a fost identificată încă (în literatura de specialitate) nici o tehnică formală de denormalizare.
5 Model adaptat după Jean Michel Franco, „Le Data Warehouse”
-23-
In exemplul prezentat, pentru a ajunge la o denormalizare a bazei de date (figura 1.6) s-a pornit de la o analiză precisă a necesităților informaționale ale utilizatorilor în ceea ce privește analiza veniturilor obținute din vânzări.
Această analiză referitoare la utilitatea informației a demonstrat că tabela Țară nu constituie un subiect de interes major pentru utilizatori. Din contră, este interesant de asociat <<numele țării>> subiectului unei linii de comandă.
Astfel tabela Țară poate fi anulată, iar un element identificator al acesteia (<<Cod Țară>>) poate migra în tabela Linie_Comandă. În mod identic, identificatorul de țară poate fi asimilat de tabela Clienți (pentru exporturi de produse) și de tabela Furnizori (pentru importuri de elemente necesare producției). Conform acestui raționament, pot fi suprimate și celelalte tabele „auxiliare” din baza de date, considerându-se a nu fi reprezentative într-un context analitic.
Elementele de identificare ale tabelelor anulate vor fi preluate după o analiză logică de către tabelele „principale”.
O primă observație a procesului de denormalizare este aceea că modelul bazei de date capătă aspecte redundante (de exemplu, atributul „preluat” <<Țara>> figurează în trei tabele : Furnizor, Client și Linie_Comandă). Se consideră că aceste redundanțe sunt ușor de gestionat în faza de culegere a datelor.
În mod global, modelul denormalizat conține un număr mai mic de tabele, fiecare tabelă fiind asociată unui pol de interes.
Printre altele, modelul prezintă un oarecare număr de informații agregate, cum ar fi <<Venituri n-1>> și <<Venituri n>> ce sunt asociate subiectului tabelei Produs. Aceste informații agregate trebuie să fie disponibile în orice moment, deoarece sunt cerute frecvent informații referitoare la venituri.
Procesul de denormalizare este centrat și orientat pe subiecte, ceea ce-l apropie de cerințele utilizatorilor, făcându-l mult mai transparent.
-24-
2.3. Modelarea multidimensională
Modelarea dimensională pleacă de la principiul că obiectivul major al unui sistem informatic pentru analizarea datelor din bazele de date este analiza performanței. Această performanță se poate materializa printr-un ansamblu de indicatori. Astfel, pentru un utilizator care lucrează în sfera comercială, performanța se poate traduce în termeni de volum al veniturilor obținute sau de mărime a marjei comerciale. Acești indicatori analitici nu au sens decât în relație cu dimensiunile analizei circumscrise fiecărui obiect de activitate. Factorul timp reprezintă o dimensiune ce este identificată sistematic în sistemul informațional al întreprinderii.
Dimensiunea temporală va permite urmărirea unui element analitic (venituri, de exemplu) pe o perioadă bine definită (zi,decadă, lună, trimestru,semestru, an(i)).
In același timp, analiza unui indicator cu incidență majoră în sistemul informațional- decizional va putea să-l ventileze pe alte subiecte emergente care sunt de fapt dimensiuni ale analizei indicatorului luat în considerație (de exemplu, ar fi interesant de relevat cum pot fi ventilate veniturile pe produs, pe regiuni, pe clienți).
Modelarea dimensională pleacă de la principiul general conform căruia obiectivul major al unui sistem informațional este reprezentat de analiza ventilării datelor cantitative (numite fapte) în interiorul datelor calitative (numite dimensiuni).
Tehnicile multidimensionale operează cu noțiunile de fapte, dimensiuni, ierarhie și agregat. Faptele reprezintă elementele analitice ale bazei de date, dimensiunile sunt categoriile descriptive după care se realizează gruparea, sintetizarea și consolidarea datelor, ierarhiile reprezintă nivelurile de detaliere pentru o dimensiune de date, iar agregatele sunt elemente descries29 ce conțin date aflate la stadii diferite de sintetizare.
Mai exact, noile concepte organizează datele după o structură matriceală care reflectă viziunea dimensională a utilizatorilor asupra bazelor de date.
Analizarea datelor de-a lungul mai multor dimensiuni este mult mai ușor de vizualizat decât de descries.
-25-
Este mult mai simplu pentru un utilizator să vizualizeze datele într-o structură multidimensională ce conservă informațiile și în care datele sunt legate între ele în mod natural6.
Figura 2.4. ilustrează modul în care datele referitoare la vânzări pot fi analizate de-a lungul dimensiunilor timp, produs și regiune (unde fiecare latură a cubului reprezintă un element dimensional).
TIMP
PRODUS
REGIUNE
Intersecția celulelor celor trei dimensiuni conține datele de analizat, măsurile acestora, iar fiecare dimensiune poate avea unul sau mai mulți membri.De exemplu, dimensiunea spațială Regiune poate avea ca membri zonele geografice (nord, sud, est, vest), dimensiunea Produs poate conține membri ce reprezintă produsele vândute de întreprindere, iar dimensiunea Timp poate avea membrii de tipul unităților de timp (zile, săptămâni, decade, luni, trimestre, semestre, ani, etc).
În general, din punct de vedere conceptual, analiza se axează pe trei dimensiuni principale: pe elementul supus analizei, pe componenta spațială și pe componenta temporală. În realitate, MOLAP (Multidimensional OLAP) poate organiza și analiza datele după “n” dimensiuni ale cubului.
6 Richard Finkelestein – Database Programming and Design, april, 1995
7 Figură preluată după Efraim Turban, Decision Support Systems, 1998
-26-
Termenul de cub este utilizat pentru a descrie spațiul n-dimensional ocupat de date. Datorită faptului că numărul de dimensiuni este variabil, utilizarea conceptului de cub nu este circumscrisă sensului său geometric.
Un cub ce stochează datele în mai multe dimensiuni, este cunoscut sub numele de hypercub. Într-un hypercub, datele sunt stocate pe zone multidimensionale, în care fiecare celulă dintr-o zonă reprezintă intersecția tuturor dimensiunilor. Utilizând această abordare poate fi analizat simultan orice număr de dimensiuni și pot fi prezentate multiple vizualizări multidimensionale ale datelor.
Există posibilitatea ca mai multe celule să nu conțină valori. De exemplu, dacă hypercubul analizează vânzările după axele produs, regiune, timp, volum vânzări și rata de creștere a vânzărilor este foarte posibil ca nu toate produsele să fie vândute în magazinele amplasate în diverse regiuni, de-a lungul perioadei analizate.
În general, cu cât numărul de dimensiuni ale hypercubului crește, cu atât numărul celulelor goale are probabilitatea de a fi mai mare. Acest fenomen poate influența capacitatea de stocare a datelor, deoarece MOLAP alocă din start un spațiu dimensional de înregistrare potrivit combinărilor maxim posibile dintre dimensiunile existente.
Datele dintr-un context multidimensional sunt percepute din punct de vedere conceptual sub formă de matrice cu mai multe straturi. Fiecare strat reprezintă o dimensiune ce descrie un fapt al bazei de date. Aceste matrici sunt de fapt hypercuburi multidimensionale.
Tehnologia matriceală prezintă trei avantaje majore:
Datele sunt din punct de vedere tehnic reprezentate sub o formă ce reflectă modelul conceptual și ca manipulările libere de date să fie mai intuitive. Astfel, un hypercub este un model de date auto-documentat;
Accesul la datele conținute de celulele hypercubului este mult mai direct decât în orice altă structură complexă de date. Noțiunea de “legătură” între date (join) nu există, deoarece acestea se regăsesc într-un singur tablou multidimensional. În egală măsură, timpii de răspuns pentru cererile de interogare formulate sunt foarte reduși, față de timpii de răspuns ai unei baze de date relaționale interogate;
-27-
Administrarea unei scheme matriceale este mult mai simplă decât exploatarea unei baze de date relaționale. Transcrierea modelului conceptual al datelor este o operațiune simplă și directă, cu condiția ca datele să se regăsească sub formă dimensională.
Singurul aspect nenormalizat ce poate deriva dintr-un mod dimensional de organizare a datelor este acela ce are ca obiect coabitarea mai multor contexte conceptuale în același hypercub.
Cererile de interogare a unei baze de date multidimensionale corespund formelor în care utilizatorii doresc să-și prezinte informația extrasă din bazele de date.
Rezultatele cererilor de interogare corespund în fapt unei matrici în care fiecare dimensiune este descrisă de o entitate, iar conținutul este dedus din asocierea entităților.
Combinarea condițiilor și restricțiilor reprezintă coordonatele ce determină valorile faptelor, după cum combinarea valorilor numerice pot determina reprezentarea unui punct într-un spațiu multidimensional.
Principalele operații într-o bază de date multidimensională sunt:
Navigarea verticală în datele bazei sau depozitului de date (drill down, drill up) reprezintă operația prin care se face trecerea de la un anumit nivel de prezentare al unui ansamblu de date, la un nivel mai detaliat (drill down) sau mai agregat (drill up);
Rotația bazei de date reprezintă schimbarea orientării dimensionale în prezentarea datelor, prin permutări între linii și coloane.
Bazele de date multidimensionale ce au ca sursă de constituire și agregare bazele de date relaționale sunt circumscrise unui demers 32unctua de transformare prin tehnicile ROLAP (Relational OLAP) – figura 2.5.
Această abordare pleacă de la modelele normalizate ale bazelor de date relaționale, trece printr-o etapă de denormalizare și ajunge la un model dimensional care poate fi normalizat din 32unctual de vedere al dimensiunilor analizei.
-28-
-29-
2.3.1. Tipuri de modele multidimensionale
Modelul in stea
In modelul dimensional, indicatorii de baza sunt grupati intr-o tabela principala, numita tabela de fapte. O astfel de tabela regrupeaza toti indicatorii ce partajeaza acelasi ansamblu de dimensiuni si toti indicatorii ce nu pot fi dedusi din alti indicatori. Tabela de fapte contine elemente numerice masurabile ce exista la intersectia dimensiunilor. Faptele din tabela de fapte reprezinta elementele de date ce pot fi agregate. La nivelul tabelei de fapte nu este necesara descrierea datelor in mai mult de doua dimensiuni.
Acest tip de model este cunoscut sub numele de „model in stea”. In centrul reprezentarii in stea se regaseste tabela de fapte. Identificatorul acestei tabele de fapte este o cheie multipla compusa din concatenarea cheilor fiecarei dimensiuni de analiza.
Astfel, atributul <<venituri>> stocat in tabela de fapte, va putea fi identificat prin dimensiunea timp, produs, client, furnizor. Modelul dimensional al tabelei de fapte este prezentat in figura 2.6.
-30-
În corelație cu tabela de fapte, figureaza toate elementele ce caracterizează dimensiunele analizei. Aceste caracteristici sunt regrupate în tabele de dimensiuni. În acest fel, tabela ce corespunde dimensiunii „Produse” va conține toate informațiile de analizat care descriu un produs (culoare, gamă, preț, ambalaj, accesorii etc.).
În exemplul prezentat, figurează patru tabele de dimensiuni ce sunt corelate cu tabela de fapte. În realitate, pot exista mai multe tabele de fapte, deoarece nu toți indicatorii partajeaza aceeasi dimensiune.
Modelul în stea și în general, toate modelele multidimensionale care pot deriva din acesta, pleacă de la principiul potrivit căruia interesul utilizatorilor este centrat pe analiza indicatorilor. O cerere de interogare bazată pe modelul multidimensional va începe prin selectarea criteriilor de analiză asupra dimensiunilor și se va interesa de valoarea indicatorilor pentru datele selectate anterior. În acest mod, un utilizator va căuta să afle de exemplu volumul veniturilor realizate din vânzarea produselor din gama „Z” pentru anul în curs și pe regiuni.Din cele expuse se desprind două avantaje majore pentru modelul multidimensional și anume, lizibilitatea și performanța modelului. Lizibilitatea sau transparența modelului evidențiază faptul că acesta este foarte sugestiv pentru utilizator, iar finalitatea sa este evidentă. Modelul este, în mod natural, orientat pe subiecte și își definește explicit indicatorii de analiză.
Performanța derivă din ușurința cu care sunt previzibile căile de acces la baza de date. În modelul multidimensional, tabela de fapte poate conține mai multe milioane de înregistrari, în timp ce tabelele de dimensiuni sunt mult mai reduse ca volum. Numărul mare de înregistrări prezente în tabela de fapte este contrabalansat de dimensiunea redusă a fiecărei înregistrări. Tabela de fapte conține numai informație numerică și identificatori. Este mult mai ușor de gestionat și de optimizat accesul la tabela de fapte, deoarece aceasta este activată după ce au fost făcute selecțiile necesare asupra tabelelor de dimensiuni. Aceste operațiuni de selecție vor returna ca rezultate identificatori, iar prin intermediul acestora se va permite accesul în tabela de fapte. Parcurgerea totală a tabelelor va putea fi evitată printr-o operație de indexare, obținându-se timpi de răspuns proporționali cu rezultatul așteptat.
-31-
Modelul tip fulg de zăpadă
-32-
Modelarea intitulată sugestiv „fulg de zăpadă” (snowflake) derivă din modelul în stea. „Fulgul de zăpadă” este de fapt o stea ale cărei raze sunt ele însele descompuse într-o structură ierarhică. A modela potrivit acestei tehnici presupune a conserva nucleul modelului în stea (tabela de fapte) și a descompune tabelele de dimensiuni în sub-tabele. În fapt, modelul „fulg de zăpadă” normalizează tabelele dimensionale ale modelului stea. Pentru tratarea dimensiunii temporale se pot defini sub-entități de tip an, lună, semestru. Normalizând dimensiunile, modelul poate elimina redundanțele apărute odată cu denormalizarea bazei de date (figura 2.7.).
2.3.2. Avantajele și dezavantajele modelului multidimensional
Unul dintre punctele slabe ale modelului multidimensional este dat de faptul că acesta nu este complet. Astfel, în exemplul prezentat, noțiunea de comandă a dispărut, deoarece în momentul analizei nu s-a judecat ca fiind utilă procesului decizional.
Să presupunem că la un moment dat al analizei, utilizatorii ar dori să cunoască corelațiile dintre vânzări la nivelul unei comenzi.
Modelul furnizat nu poate prezenta o astfel de informație, deoarece s-a făcut abstracție de această entitate informațională. Pentru ca modelul să poată face analiza pe comenzi, ar trebui adăugată o nouă dimensiune <<comandă>>.
Pentru a realiza acest lucru, se pleacă de la modelul normalizat, unde se observă faptul că tabela comandă este legată în principal de client, de produs și de dată. În modelul dimensional, se va adăuga în tabela de fapte un nou atribut „ID_Comandă” pentru fiecare triadă „Produs-Client-Dată”.
A adăuga o nouă dimensiune poate aveaca efect creșterea sensibilă a volumului tabelei de fapte.
Ultima caracteristică a acestui tip de modelare este aceea că din punctul de vedere al utilizatorului este puternic orientată pe subiecte.
-33-
Gestiunea dimensiunii temporale
În bazele de date, gestiunea timpului va genera multiple operațiuni de sintetizare a informației pe mai multe niveluri de agregare. Interogările bazei de date axate pe o componentă temporală vor fi ușor de evaluat și de interpretat de către utilizator, axa timpului putând fi declinată din mai multe puncte de vedere.
De exemplu, analiza vânzărilor la un mare distribuitor va putea să se efectueze după mai multe criterii (ora dintr-o zi, ziua unei săptămâni, luna, perioadă fiscală, perioadă legată de promovarea unor produse sau evenimente externe) și va permite cel mai adesea efectuarea de comparații asupra unor perioade numite „variabile” (creșterea vânzărilor lunii curente față de luna precedentă, vânzări realizate în primele cinci zile ale anului școlar – față de aceeași perioadă a anului precedent, etc.).
Noțiunea temporală apare prezentată la două niveluri în modelele dimensionale. Timpul este întotdeauna o dimensiune cu parte întreagă. Dar, în mod independent de acest fapt, noțiunea temporală poate apare la nivelul mai multor dimensiuni, atunci când caracteristicile elementelor descrise prin timp evoluează (se vorbește astfel de dimensiune ușor (lent) schimbătoare „slowly changing dimensions”). Prin acest termen se descriu anumite dimensiuni ce sunt asociate unor caracteristici ce pot evolua în timp și ale căror evoluții trebuiesc cunoscute.
Dacă se are în vedere, de exemplu, dimensiunea Client: atunci când un client își schimbă domiciliul, această evoluție este independentă de relația sa cu întreprinderea și de evenimentele pe care le implică ea. Dacă respectivul client își schimbă zona geografică de domiciliu (orașul, județul, țara), vânzările pe care el le generează trebuie agregate în zone geografice diferite înainte ca acesta să-și schimbe domiciliul. În cazul dat, trebuie ca elementul timp să figureze nu numai la nivelul tabelei de fapte, ci acesta trebuie asociat de asemenea fiecărui element de dimensiune ce se poate schimba (tabela dimensională Client va conține în egală măsură data calendaristică, la care se asociază eventual un număr de versiune pentru data respectivă).
-34-
Figura 2.8. ilustrează modul cum pot fi gestionate dimensiunile prin administrarea versiunilor.
Figura 2.8. Gestiunea prin atribuirea de versiuni dimensiunilor ușor variabile
Conceptul de versiune rezolvă problemele de modelare dimensională în care intervine factorul timp, dar îngreunează procesele de culegere a datelor și/sau de redare a acestora. Astfel, în primul rând gestiunea versiunilor presupune compararea datelor ce descriu dimensiunile la intrarea în sistem cu cele existente deja în bazele de date, pentru a se decide dacă înregistrarea există sau trebuie adăugată o nouă versiune. Aceste comparări ale datelor din tabele îngreunează operațiile în termeni de performanță.
În al doilea rând, este nevoie de anumite operații de analiză care să compare faptele cu proprietățile corespunzătoare dimnesiunilor. Această tehnică este operațională prin compararea datelor dintre tabela de fapte și tabelele de dimensiuni. Pentru fiecare element din tabela de fapte se alocă un număr propriu de versiune pentru fiecare dimensiune modificată. Soluția practică este aceea de a introduce un identificator pentru fiecare element de dimensiune modificabilă.
-35-
2.4. Optimizarea la nivel fizic a bazelor de date multidimensionale
Optimizarea unui model relațional „clasic” normalizat sau nu, sau a unui model derivat din acesta (stea sau fulg de zăpadă) implică două abordări la nivel fizic pentru bazele de date multidimensionale:
Stocarea fizică a agregatelor
Partiționarea sau fragmentarea fizică a tabelelor potrivit unui criteriu de căutare.
Stocarea fizică a agregatelor
Prima etapă a unei politici de optimizare a performanțelor este aceea de definire a agregatelor. Interogările ce fac apel la date agregate constituie 80% din cererile efectuate de un sistem decizional. Construirea tabelelor agregate permite furnizarea de către baza de date dimensională de timpi de răspuns cu valoare foarte mică.
În modelul ce a fost prezentat anterior, este creată o tabelă de agregare pentru fiecare dintre intersecțiile posibile între două dimensiuni. Acest tip de mecanism este operațional cu ajutorul SGBD OLAP. În momentul în care bazele de date au un volum mare de date, se pot întâlni două probleme:
Pentru un volum de date excesiv, câteva baze de date OLAP necesită un volum de stocaj de 40 de ori mai mare decât în cazul stocării datelor detaliate;
La un volum mare de date, există probleme restrictive în termeni de performanță în momentul încărcării bazei de date, deoarece fiecare dată introdusă antrenează după sine calculul unei multitudini de informații derivate.
O soluție pentru rezolvarea acestor probleme constă în a nu agrega fizic decât un subansamblu din toate combinațiile potențiale posibile. Potrivit exemplului precedent, se va alege agregarea asupra unui atribut dată calendaristică la nivel de lună și de an, dar nu la nivel de trimestru (figura 2.9.). O astfel de agregare la nivel de trimestru poate fi dedusă din agregarea la nivel de lună și deci va beneficia de agregarea pe care administratorul bazei de date a definit-o la nivel fizic. Acest fapt va reduce semnificativ timpul de încărcare a datelor.
-36-
Această metodă de agregare prin “diseminare” (sparse agregates) se dovedește a fi adaptată pentru SGBD-urile relaționale, un agregat aparținând unei noi tabele a bazei de date. În plus, dacă baza de date este modelată după abordarea în stea sau fulg de zăpadă, gestiunea agregărilor este simplificată, deoarece elementele susceptibile de a fi agregate sunt regrupate din punct de vedere fizic în tabela de fapte.
Inconvenientul acestei metode rezidă în complexitatea administrării bazei de date. Procesul de alimentare a bazei de date este deosebit de complex și de aceea trebuie să existe mijloace și instrumente specifice pentru a menține o coerență totală intre conținutul tabelelor de detaliu și conținutul tabelelor agregate.
Majoritatea SGBD-urilor ce exploatează datele în mai multe dimensiuni (Informix, SQL, Server, Oracle, CA/Platinum, SAP) propun instrumente adecvate pentru administrarea datelor agregate, permițând conservarea într-un jurnal a tuturor cererilor emise către baza sau depozitul de date. Informațiile astfel colectate, pot fi analizate printr-un mediu de asistare a deciziei adecvat, pentru a se determina politica de agregare în funcție de timpul de răspuns, de frecvența unor anumite cereri de interogare, de sursa emiterii cererilor, de dimensiunea și timpul de calcul necesar unui eventual stocaj fizic al noilor agregate.
-37-
2.4.1. Partiționarea tabelelor
O a doua tehnică de optimizare fizică a bazelor de date dimensionale în scopul implementării acestora este operațiunea de partiționare. Această tehnică presupune decuparea unei tabele voluminoase în funcție de valoarea unui ansamblu de coloane.
Dacă se urmărește un exemplu din analiza vânzărilor se observă că acestea se repartizează echitabil (cu excepția aspectului sezonier sau al sărbătorilor) de-a lungul unui an. Potrivit acestei premise este posibil a se împărți tabela ce conține vânzările anuale după criteriul “lună”.
Ventilarea înregistrărilor dintr-o astfel de tabelă (anuală) va permite obținerea câte unei tabele pentru fiecare lună în parte (total 12 tabele).
Operațiunea de partiționare evită crearea unui index într-o tabelă voluminoasă. Dacă un utilizator va cere informații despre vânzările lunii ianuarie, va fi solicitată pentru răspuns o singură tabelă redusă ca dimensiuni (figura 2.10). Pe un calculator dotat cu o arhitectură multiprocesor ce conține un multicontroller de disc, implementarea unei astfel de soluții de partiționare este benefică deoarece un SGBD poate afecta “task-uri” de căutare asupra fiecărei tabele pentru fiecare procesor.
-38-
În cazul “ideal” prezentat în exemplul precedent, pe un calculator dotat cu 12 procesoare și 12 controllere de disc, parcurgerea unei tabele va dura de 12 ori mai puțin decât în cazul unei tabele nepartiționate.
Un alt avantaj al partiționării fizice este reprezentat de facilitatea administrării sistemelor, “task-urile” de salvare și restaurare a datelor făcându-se partiție cu partiție.
Un alt beneficiu al partiționării care nu trebuie neglijat este acela de a trata diferit fiecare partiție în funcție de dimensiune, de frecvența de acces la date, etc.
Dacă baza de date ierarhic inferioară o permite, va fi posibilă asocierea pentru fiecare partiție a unor tehnici de acces diferit. Se dovedește astfel a fi posibilă rezervarea unor structuri costisitoare în 44resent de stocaj sau de timpi de încărcare (indexul sau agregările fizice) pentru partițiile accesate cel mai frecvent.
Ca și în cazul agregărilor, problema partiționării trebuie să fie transparentă pentru utilizator și acest lucru este posibil prin intermediul instrumentelor informatice utilizate.
După cum s-a arătat mai înainte, cuvântul cheie care definește 44resent44al de OLAP (produs sau aplicație) este în mod constant multidimensionalitatea vederilor folosite în analiză. În 44resent, coexistă două soluții de implementare a multidimensionalității: soluția MOLAP (Multidimensional OLAP), care folosește baze de date multidimensionale (MDB- Multidimensional Data Base) sau baze de date de tip “hipercub” (de fapt hiperpoliedru); soluția bazelor de date relaționale care asigură multidimensionalitatea pentru analiză, numite pe scurt ROLAP (Relational-OLAP sau OLAP-on-Relational).
-39-
2.4.2. Analiza datelor prin intermediul tehnologiilor MOLAP și ROLAP
O bază de date relațională are două dimensiuni sau axe (coloane și rânduri) și presupune existența unui limbaj de interogare de tip SQL (Structured Query Language). Asigurarea posibilității de a efectua analize multidimensionale folosind o bază de date relațională se obține, în implementările actuale, prin folosirea unei scheme de proiectare intitulată “schema stea” sau “floarea-soarelui” (vezi fig.2.6). Aceasta creează două tipuri de tabele: “o tabelă de fapte” (care poate avea milioane de rânduri) și conține informațiile care sunt subiectul interogărilor; mai multe tabele care conțin datele descriptive privind fiecare dimensiune. Există mai multe criterii pentru calificarea unui produs ca incluzând 45bligat pentru ROLAP, dintre care amintim:
Existența unui generator SQL, care poate 45bligat operațiile de selectare a datelor;
Posibilitatea de a 45bligat clasificări, comparații și calculul procentelor pentru înregistrările din bazele de date;
Prezența unui 45bligator care descrie modelul datelor prin intermediul metadatelor și care poate folosi metadatele în timp real pentru a 45bligat interogări;
Aptitudinea de a partiționa aplicația între clienți, prestatori și un element mediator care gestionează șirurile de apeluri la baza date.
Primul produs de tip ROLAP, denumit Metaphor, a fost lansat în 1984 pentru aplicațiile de marketing la companiile producătoare de bunuri de consum. Succesul 45bligatory al lui Metaphor (deținut din anul 1991 de către firma IBM) a fost destul de limitat. De atunci o serie de alte produse au fost lansate, ca de exemplu: AXSYS al firmei Advantage, Beacon al firmei Prodea sau MetaCube al lui Stanford Technology Group.
Operațiunile primare și tipice pentru aplicatiile OLAP sunt “felierea” și “forarea”, ce presupun o organizare logică a datelor sub forma unui hipercub (n-dimensional) format din 45bligat în care timpul este o dimensiune 45bligatory în cadrul tabelelor bidimensionale ale bazelor de date relațuionale.
-40-
Sunt identificate trei etape de proiectare a hipercubului:
Alegerea subiectelor de interes pentru întreprindere (de exemplu: vânzările, reclamațiile sau capacitățile de producție);
Stabilirea valorilor care trebuie culese (de exemplu: volumul lucrărilor, elementele de cost sau gradul de încărcare și timpii de staționare ai mașinilor și instalațiilor);
Determinarea granularității datelor sau a nivelului de detaliu. Spre deosebire de bazele de date relaționale, bazele de date multidimensionale (MDB) nu au încă un model acceptat de toată lumea și nici o metodă de acces standard, cum era SQL în cazul relațional.
Primul instrument informatic pentru MOLAP a fost Express, care a fost gândit la începutul anilor ’70 pentru aplicații cu timp partajat în mediul academic.
În prezent, Express este deținut, din anul 1995, de către firma Oracle (un mare producător de instrumente pentru baze de date relaționale) și își păstrează conceptele inițiale, deși prezintă soluții de implementare noi.
Tendința actuală este de a include în cadrul sistemelor de gestiune a bazelor de date componente care permit realizarea analizei eficiente a datelor.
Astfel, sisteme importante ca Oracle 9i, Microsoft SQL Server 2000 sau IBM DB/2 au incluse instrumente eficiente pentru analiza și procesarea analitică a datelor.
-41-
Cap.3 Explorarea datelor din BDM (Data Mining)
3.1. Prezentare generală
Explorarea datelor din BDM se realizează folosind tehnici de analiză avansată rezultate din intersecția inteligenței artificiale cu tehnici de analiză a datelor (analiză statistică, modele funcționale, rețele neuronale, căutarea de reguli asociative, clasificare, segmentare, etc.) fondată pe modele statistico-matematice. Aceste mijloace de explorare sunt desemnate cu apelativul Data Mining.
Un Data Mining are două obiective: un obiectiv de descriere8 ce constă în determinarea variabilelor semnificative și determinarea influențelor (interacțiunilor între variabile asupra altor variabile, etc.) și un obiectiv de modelare/predicție9 (pentru a prevedea, datele trebuie incluse într-un model10).
Principalele concepte utilizate în procesul de explorare a datelor sunt:
Clasă: datele stocate sunt folosite pentru a localiza date în grupuri predefinite. De exemplu: un lanț de restaurante poate explora datele pentru a determina care sunt intervalele orare cu un aflux mai mare de clienți, precum și ce comandă ei în mod obișnuit.
Cluster: datele sunt grupate conform relațiilor logice sau preferințelor existente. De exemplu: pot fi explorate date pentru a identifica segmentul de piață sau preferințele consumatorilor.
Asocieri: datele pot fi explorate pentru a identifica asocieri sau legături existente între ele.
Model secvențial: datele sunt explorate pentru anticiparea comportamentului și a modelelor.
8 Tehnici: analiza factorială, descriptivă, analiza în componente principale, analiza corespondențelor, analiza vectorială discriminantă descriptivă, clasificarea, etc
9 Exemplu: tehnici de regresie, tehnici factoriale, tehnica arborelui de decizie, rețele neuronale, etc.
10 A modela constă în a explica o variabilă prin alte variabile
-42-
Principalele funcții ale unui model de descoperire a datelor sunt următoarele:
Clasificare – descoperirea unei funcții care să indice apartenența unei date la o anumită clasă dintr-un grup de clase predefinite.
Regresie – identificarea unei funcții care să estimeze valorile viitoare ale unei date pe baza valorilor precedente.
Clustering – determinarea unui set finit de categorii sau clustere necesar pentru descrierea datelor.
Modelarea dependențelor – determinarea unui model care să descrie dependențele semnificative dintre variabile.
Analiza legăturilor – descoperirea celor mai semnificative, importante modificări ale datelor față de valorile anterioare, identificarea variabilelor dependente, precum și a intensității dependenței.
Printre cele mai utilizate metode în procesul de explorare a datelor se numără:
Rețele neuronale artificiale: sunt modele neliniare care „învață” din situațiile anterioare, acestea simulând structura rețelelor neuronale biologice.
Algoritmi genetici: reprezintă tehnici de optimizare care utilizează procese cum ar fi combinațiile genetice, mutațiile și selecția naturală în proiectarea bazată pe conceptele evoluției naturale.
Arbori decizionali: sunt structuri de tip arbore care reprezintă un set de decizii.
Metoda „celui mai apropiat vecin”: este o tehnică de clasificare a fiecărei înregistrări într-un set de date, bazat pe o combinație de clase ale celor mai similare k înregistrări. Această metodă este cunoscută și sub numele „cei mai apropiați k vecini”.
Reguli de inducție: presupune extragerea regulilor „if-then” folositoare din baza de date, extragere bazată pe semnificația statistică.
Vizualizarea datelor: se referă la interpretarea vizuală a relațiilor complexe între date multidimensionale, instrumentele grafice fiind utilizate pentru reflectarea relațiilor relațiilor dintre date .
-43-
Pentru obținerea unor rezultate cât mai performante în urma procesului de explorare a datelor este necesară o integrare deplină a BDM și a instrumentelor de analiză a datelor.
Multe dintre instrumentele de explorare a datelor lucrează în afara BDM, acest lucru implicând o serie de pași suplimentari ce trebuiesc efectuați pentru extragerea, importul și analizarea datelor. Aceste depozite de date pot fi implementate într-o varietate de sisteme de gestiune a bazelor de date (de exemplu: Oracle, Sybase, etc.).
Aplicații ale explorării datelor se regăsesc într-o multitudine de domenii, ca de exemplu: marketing (identificarea asociațiilor între caracteristicile demografice ale cumpărătorilor, previzionarea efectelor unei campanii promoționale), domeniul financiar-bancar (determinarea corelațiilor ascunse între diferiți indicatori financiari, identificarea clienților loiali, previzionarea preferințelor clienților în ceea ce privește anumite servicii bancare, previzionarea evoluției prețului acțiunilor etc.), asigurări (previzionarea clienților care vor cumpăra noi polițe de asigurare, identificarea unui posibil comportament fraudulos), transporturi, medicină (identificarea celor mai potrivite proceduri medicale pentru o anumită boală, determinarea procedurilor medicale care pot fi executate împreună).
Instrumente pentru Data Mining:
Cele mai multe din SGBDR-urile puternice (Oracle, Informix, etc.) încorporează instrumente de Data Mining.
În cazul în care SGBDR-ul folosit pentru gestiunea BDM nu dispune de instrumente Data Mining se poate utiliza un program specializat. Este cazul programelor SPSS și SAS. Și programul dispune de facilități Data Mining (de exemplu: facilități de analiză a datelor furnizate de un Spreadsheet (Excel)).
-44-
3.2. Gestiunea BDM folosind MS SQL Server
Sistemul de gestiune a bazelor de date MS SQL Server 2000 facilitează realizarea de aplicații DSS (Decision Suport Systems – sistem suport pentru decizii) prin intermediul setului de facilități denumite Analysis Services care include instrumente pentru OLAP și Data Mining (explorarea datelor). Instrumentele OLAP permit bazelor de date multidimensionale să fie utilizate efectiv pentru analiză facilitând obținerea unor răspunsuri rapide la o serie de interogări complexe.
Avantajul de a agrega un volum mare de date rapid, permite instrumentelor OLAP din SQL Server să ofere utilizatorilor posibilitatea de a efectua analize în timp real. Pe ansamblu depozitele de date pot fi accesate în următorul mod de către utilizatori:
DTS (Data Transformation Services) – reprezintă un set de instrumente grafice care permit extragerea și transformarea datelor din surse multiple (de exemplu: baze de date relaționale) în una sau mai multe destinații (de exemplu: depozite de date). Baza de date multidimensională poate fi implementată folosind SQL Server, Oracle, Access, etc.
-45-
Analysis Server – permite transpunerea datelor stocate într-o bază de date multidimensională în „cuburi” de date permițând utilizatorilor să le interogheze.
Pivot Table Service (PTS) – permite utilizatorilor să acceseze cuburile gestionate de server (Analysis Server) prin intermediul tehnologiilor OLE DB și/sau ADO MD (ADO Multidimensional). De asemenea, PTS permite crearea și interogarea cuburilor locale fără a fi necesară o conexiune la Analysis Server.
3.3. Business Inteligence – concept și fundament
3.3.1.Depozitele de date si componentele de business inteligence
Sistemele informatice de asistare a deciziilor si instrumentele de business inteligence tind sa devina elemente omniprezente in cadrul companiilor . Dinamica vietii economice si explozia informationala contemporana fac din utilizarea diverselor tipuri de sisteme de asistare a procesului decizional o necesitate .
In ciuda limitarilor impuse de imposibilitatea reproducerii perfecte de catre calculator a rationamentelor umane, sistemele informatice pentru manageament reprezinta astazi instrumentele indispensabile managerul modern, marea majoritate a activitatilor decizionale de rutina, informatiile necesare procesului decizional impreuna cu tehnicile de cautare si regasire a informatiei fiind preluate complet de catre aceste sisteme.
In plus, perfectionarea lor continua, dublata de imbunatatirea performantelor computerelor, ofera posibilitati sporite de preluare a unor segmente din ce in ce mai cuprinzatoare ale activitatii de rationare desfasurata de catre decidentul uman.
Business inteligence
Categoria de sisteme informatice care ofera suport in procesul decizional poate fi definita de termenul business inteligence. Acesta priveste ansamblul instrumentelor de natura informatica ce aduc un plus de ,,inteligenta’’procesului de afaceri . Integrarea aplicatiilor traditionale, operationale cu o gama de programme de analiza a datelor sau din categoria sistemelor expert asigura o baza eficienta pentru asistarea procesului decizional.
-46-
Etapele decizionale in cazul utilizarii solutiilor Business intelligence:
In ceea ce priveste procesul de luare a deciziilor, bazat pe solutiile de business intelligence, identificam urmatoarele etape fundamentale:
Analiza –Filtrarea din multitudinea de date a informatiilor utile in concordanta cu modelul afacerii si indentificarea indicatorilor de performanta.Analiza informatiilor in diverse contexte pentru a identifica tendintele Business inteligence inseamna punerea informatiilor la dispozitia tuturor departamentelor companiei astfel incat fiecare manager sa isi poata realiza propriile analize si sa fie capabil sa urmareasca evolutia indicatorilor de performanta pe segmentul care il intereseaza;
Descoperirea de cauze -Explicarea cauzelor anumitor fenomene care nu corespund cu modelul afacerii;
Actiunea – Luarea deciziilor bazate pe informatiile analizate .
Aceste decizii se bazeaza pe protectia in viitor a efectelor pe care le va avea o actiune (de exemplu, cresterea vanzarilor la un anumit produs ca urmare a unei promotii). Din nou conponenta umana are un rol important: ea apreciaza care dintre variantele de actiune va duce la rezultatul scontat. Business Intelligence asista la procesul decizional prin posibilitatea de a simula efecte (analiza What if);
Masurarea rezultatelor –In aceasta ultima etapa putem vedea daca deciziile luate au fost corecte sau daca rezultatele nu sunt exact cele asteptate, ne indica directia in care trebuie sa actionam pentru imbunatatirea lor.
3.3.2. Proiectarea solutiilor de Business Intelligence
Atunci cand dorim sa implementam o solutie pentru Business Inteligence trebuie sa pornim de la cerintele utilizatorilor care o vor folosi. Nu trebuie sa luam aici in considerare doar echipa manageriala, ci orice tip de utilizator care va avea nevoie-sub o forma sau alta- de informatii din acest sistem pentru a-si desfasura activitatea. Putem imparti utilizatorii unui sistem de Business Intelligence in :
Utilizatori de informatie – Acestia au nevoie doar de rapoarte sau de anumiti indicatori de performanta. Ei folosesc rapoarte standard si nu au capacitati de analiza a informatiei ;
-47-
Consumatori de informatie – Au nevoie de posibilitati de analiza, de informatii in diverse contexte si solicita functii pentru interogari dinamice ale datelor ;
Analiza si experti -Sunt cei carora le este necesara analiza multidimesionala pentru a identifica tendinte si pentru a lua decizii majore.Ei au nevoie de analiza ad-hoc si de acces liber la orice tip de informatii din sistem.
Pentru a avea o imagine cat mai corecta asupra categoriilor de utilizatori ai sistemului si de a raspunde cerintelor acestora, proiectarea solutiei trebuie sa aiba in vedere urmatoarele doua elemente fundamentale :
a) Localizarea informatiilor pe baza carora se realizeaza analiza.
Aceste date se vor afla , de obicei, in diverse sisteme operationale existente: aplicatii Line of Business (LOB), sisteme Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), managementul resurselor umane (HR), managementul retelelor de distributie (supply chain).
Toate aceste sisteme au cateva caracteristici comune, printre care cea mai importanta este ca sunt sisteme tranzactionale. Un alt aspect, care impiedica de obicei utilizarea datelor pentru analize, este faptul ca sistemele sunt izolate si comunica prea putin cu alte sisteme, iar datele nu sunt corelate. In momentul in care dorim sa realizam o solutie de analiza a informatiei trebuie sa gasim o cale pentru a integra datele din toate aceste sisteme.
b) Utilizatorii sistemului si tipurile de informatii necesare
Vor fi create profilurile utilizatorilor pentru ca, mai tarziu, sa fie realizat design-ul sistemului si planificarea capacitatii acestuia pe baza acestor cerinte.
Depozitele de date
Depozitul de date reprezinta un concept nou care vizeaza asistarea proceselor decizionale in contextul cerintelor actuale de administrare a organizatiilor, folosind analiza a cat mai multe informatii care provin din surse diferite.
Asistarea deciziei centrate pe date, are un caracter normativ relativ scazut.Caracteristica sa esentiala consta in furnizarea la timp a informatiilor cerute de decident pentru activitatile sale.
-48-
Instrumentele informatice orientate catre date indeplinesc functii de regasire si analiza a datelor. Principalele clase identificate sunt prezentate in continuare :
Sisteme standard de informare, care au ca scop automatizarea unui mod de lucru manual si servesc la accesul on-line la anumite date. Ele sunt destinate persoanelor care au sarcini operationale (functionari, sefi de ateliere), care au nevoie de acces imediat la valoarea curenta a anumitor variabile ;
Sisteme rentru analiza datelor, care ajuta personalul cu sarcini de asistare a conducerii in analiza fisierelor cu date curente si istorice, cu scopul de a produce rapoarte pentru manager. Produsele generalizate permit analize cu caracter general, folosind datele existente intr-o baza de date si chiar formularea si programarea unor modele matematice simple. Ca exemple, se pot aminti rapoartele privind stadiul de realizare a unor comenzi de fabricatie sau analiza eficientei unor investitii ;
Sisteme pentru analiza informatiilor, care asigura accesul la o serie de baze de date destinate asigurarii informationale a deciziilor si la modele de dimensiuni reduse, in scopul furnizarii informatiilor specifice pentru rezolvarea unor situatii decizionale particulare.
Sistemele din aceasta clasa sunt proiectate sa extraga datele relevante din aplicatiile de prelucrare electronica a datelor (Electronic Data Processing – EDP) proprii ale intreprinderii si sa le completeze cu date externe.
3.4. Limitele sistemelor tranzactionale in analiza informatiilor din bazele de date
Aparitia conceptului de magazie de date este justificata prin limitile sistemelor de prelucrare on-line a tranzactiilor (On Line Transaction Processing – OLTP). Acestea nu pot furniza, catre manager cu promtitudinea ceruta si in formatul dorit, acele informatii care sunt necesare. De cele mai multe ori este vorba de informatii care servesc la verificarea unor ipoteze inlantuite, considerate in rezolvarea problemelor decizionale.Aceste informatii se pot obtine (in majoritatea cazurilor) din analiza unor serii de timp diferite, care se gasesc in baze de date distincte.
In contrast cu ‘datele operationale’, pe care le manipuleaza sistemele de tip OLTP, cerintele decidentelor se numesc in terminologia IBM ‘date informationale’
-49-
Sistemele de tip OLTP sunt specializate pe tipuri de probleme, ca de exemplu, conducerea productiei, efectuarea de tranzactii comerciale etc. Ele au ca misiune principala manipularea rapida si sigura a datelor si sunt denumite uneori sisteme cu misiune critica (‘mission critical systems’) Pentru a asigura performantele cerute si uneori, din motive istorice sau de securitate, ele nu sunt proiectate pentru a lucra in cooperare cu alte sisteme.In consecinta ,cu toate progresele tehnologice relative privind integrarea aplicatiilor, exista o serie de dezavantaje in utilizarea OLTP pentru asistarea deciziilor si analizei :
-limitarea datelor manipulate de aceste sisteme in valorile curente necesare indeplinirii menirii lor ;
-aspectele de securitate in cazul, din ce in ce mai raspandit,al productiei globalizate in care diferitele baze de date sunt distribuite din punct de vedere geografic ;
Daca se analizeaza problema din punctul de vedere al instrumentului, informatic care administraza baza de date, se pot observa alte complicatii.
Intr-o organizatie exista ,,sisteme mostenite ’’(,,legacy system’’) care sunt realizate prin folosirea unei diversitati de sisteme de gestiune a bazelor de date (S.G.B.D.)
Acestea sunt fie mai vechi (indexat secventiale, de tip retea, ierarhice ), fie mai noi (relationale, orientate obiect) sau specializate (de exemplu,pentru lucru in tip real,pentru stocarea de date multimediale etc.).
La ora actuala predomina S.G.B.D. de tip relational, care permit efectuarea de zeci de mii de tranzactii pe minut.S.G.B.D. relationale au o serie de avantaje :
–Ele permit acumularea unor volume impresionante de date intrun mod neredundant sub forma unor tabele, care pot fi combinate prin anumite operatii bine fundamentate matematic pentru a obtine informatiile dorite.
-interogarea poate fi realizata intr-un mod flexibil folosind limbajul S.Q.L.(Structured Querry Language). Cu toate aceste avantaje , folosirea directa S.Q.L. de catre un manager de pe nivelurile superioare ale ierarhiei de conducere necesita din partea lui cunostinte si timp, pe care acesta, in unele cazuri, nu le are.
Pentru a ocoli aceste neajunsuri, o solutie intermediara au constituit-o sistemele de informare a managementului (Executive Information Systems-EIS).
-50-
Acestea sunt niste sisteme de tip ,,front-ond ’’pentru sistemele de tip OLTP si au ca menire realizarea de operatiuni de agregare a datelor primite de la sistmele de tip OLTP in vederea stocarii in mod intermediar in dispozitivele de memorare ale EIS.
In loc sa formuleze comenzi de interogare in limbajul SQL managerul, are posibilitatea sa aleaga informatia necesara dintr-un mediu prestabilit.
Desi solutiile de tip EIS au reprezentat un pas important inainte de asistarea deciziilor centrate pe date, ele sufera de anumite neajunsuri izvorate din insasi conceptia de realizare.In primul rand, culegerea de date de la sisteme de tip OLTP ramane o problema care, uneori,nu este simpla din punct de vedere tehnic. In al doilea rand, solutia EIS sufera de inflexibilitate.Aceasta se manifesta atat in utilizarea sistemului informatic, cat si in intretinere si dezvoltare.
Avand in vedere considerentele prezentate anterior, precum si limitele atinse de instrumentele de tip sisteme de gestiune a bazelor de date a aparut necesitatea unui concept nou (magazia de date) si respectiv a unor instrumente informatice noi (OLAP) .
Magazia de date este o baza de date specializata, care raspunde nevoilor si cerintelor specifice ale decidentilor aflati pe nivelurile superioare ale ierarhiei de conducere a intreprinderii. Ea cuprinde mai multe tipuri de date, provenind de la mai multe ,,surse de aprovizionare’’,care pot fi sisteme de tip OLTP, calculatoare de proces, retelei industriale, biblioteci, fotografii sau CD-ROM, Internet etc.
Etapele fundamentale in gestionarea unui depozit de date sunt urmatoarele :
1-Colectarea datelor prin extragerea lor din diferite surse, care consta in urmatoarele : a) detectarea datelor noi de interes aflate in bazele de date sursa si : b) determinarea modului de incarcare.Incarcarea se efectueaza la momente programate, in regim ,,pe loturi’’ (,,batch’’), pentru a nu perturba fuctionarea sistemelor furnizoare de tip OLTP;
2- Transpunerea datelor din formatul originarin cel adoptat in magazia de date;
3- Eliminarea erorilor, care cuprinde functii de identificare si corectare a ererilor de conversie si completarea omisiunilor ;
4- Sintetizarea datelor prn operatii de agregare si rezumare.
-51-
3.5. Elemente fundamentale privind depozitele de date.
Magazia de date trebuie sa serveasca necesitatilor managerilor prin oferirea de raspnsuri rapide si in conformitate cu cerintele de interogare si de prezentare ale acestora. Pentru aceasta, o magazie de date trebuie sa posede o serie de caracteristici generale care se prezinta mai jos :
Separarea fizica de bazele de date operationale.Aceasta cerinta are ca scop, pe de o parte, furnizarea operativa a informatiilor necesare procesului decizional si pe de alta parte, evitarea perturbari aplicatiilor operative, care trebuie sa satisfaca standardele legate de timpul de raspuns si de siguranta operatiunilor.
Orientarea catre o tema de cercetare. Spre deosebire de bazele de date operationale care sunt centrate pe aplicatii sau functii, magaziile de date sunt organizate astfel incat sa vizeze anumite subiecte de interes pentru manager precum : clienti, produse, activitati ;
Integrarea fara exceptii a datelor.Aceasta se traduce prin uniformitatea convetiilor folosite in definirea datelor si a unitatilor de masura utilizate ;
Analiza cronologica a datelor.Spre deosebire de datele operationale, care sunt valabile numai in momentul acesului, cele continute in magazia de date sunt valabile oricand Aceasta se traduce prin urmatoarele trasaturi derivate :orizontul de timp 5-10 ani (fata de maximum cateva zeci de zile in cazul operational) ; structura cheii de acces care contine elementul ,,timp’’ ( zi,luna,an,) ; interzicerea modificarii datelor stocate corect la un anumit moment discret de timp ;
Caracterul datelor din depozitul de date este istoric. In cazul depozitelor de date aceasta se traduce prin reducerea numarului de tipuri de operatii permise la doua : incarcarea initiala si acesul la date, spre deosebire de cazul operational, in care se efectueaza o multitudine de inserari, stergeri si actualizari la nivelul unei singure inregistrari.
Consecintele acestei caracteristice sunt diverse. In primul rand dispare pericolul potential al actualizarilor eronate.In al doilea rand se paote realiza proiectarea la nivel fizic pentru a optimiza acesul fara a mai tine cont de cerintele de redundanta si normalizare .
-52-
In al treilea rand, dispare necesitatea folosirii unor tehnici complicate pentru asigurarea integritatii datelor ;
Arhitectura generala a unui 58as cop de date cuprinde urmatoarele componente:
Componenta bazelor de date operationale existente ;
Componenta de acces la informatii a utilizatorilor care sunt, de obicei managerii de varf sau analisti din echipele de sprijin ale managerilor ;
Componenta de acces la date, care permite schimbul de date între primele două paliere în scopul realizării unui „acces universal la date” indiferent unde se află localizate acestea;
Componenta directorului de date, care conține metadatele privind informațiile din bazele de date operaționale și diferitele « vederi » ale utilizatorilor;
Componenta de transport a datelor, care utilizează suportul unei rețele de comunicații.
3.6. Clasificarea depozitelor de date
Termenul de magazie de date este destul de general. Unii autori sau furnizori de produse informatice folosesc diferiți termeni pentru a numi unele cazuri particulare sau componente ale magaziei de date.
Toate tipurile au în comun faptul că sunt colecții integrate, nevolatile, de date de tip serie de timp, care au 58as cop asistarea proceselor decizionale manageriale.
Ceea ce diferentiaza tipurile de depozite de date este aria de cuprindere a proceselor decizionale, dupa cum urmeaza :
1 – Magazia de date orientată pe un proces de business («Business Process Data Warehouse » – BPDW) asistă procesele decizionale care privesc toate procesele de business și legaturile lor reciproce, precum si cu mediul lor înconjurator.
2 – Magazia de date departamentală (« Department Data Warehouse » – DDW) asistă procesele decizionale care privesc compartimentele și interactiunile lor reciproce, precum si cu mediul inconjurator.
3 – Un depozit de date (data mart) de tip proces de business (« Business Process Data Mart – BPDM) asistă procesele decizionale centrate pe un singur proces de business.
-53-
CAP 4. Studiu de caz
4.1. Descrierea generală a aplicației (Visual Fox Pro)
Ne propunem să realizăm o aplicație de contabilitate financiară în Visual Fox Pro. Produsul informatic trebuie să permită următoarele:
Gestionarea conturilor;
Gestionarea notelor contabile;
Elaborarea automată a principalelor documente contabile: Registrul Jurnal, Fișa Contului, Balanța de Verificare și Bilanțul contabil.
Elaborarea tabelelor:
-54-
-55-
În scopul facilitării operațiilor de introducere a datelor, s-a optat pentru următoarele formulare:
Formularul Cont – permite actualizarea tabelului cu aceeași denumire fiind creat într-un format Tabular. Prin intermediul formularului se pot realiza:
Adăugarea unui cont
Modificarea unui cont utilizând caseta combinată
Ștergerea unui cont din planul de conturi
Formularul Operație – permite:
Actualizarea tabelelor Document, Operație și Rulaje astfel:
Adăugarea unor înregistrări noi ;
Stergerea unei înregistrări
Navigare între înregistrări
Tabelul Rulaje este actualizat prin intermediul subformularului RULAJE Subform
Căutarea operațiilor după număr prin intermediul listei cmbCautăOperație
-56-
Formularul dlgFișaCont – permite deschiderea raportului FisaCont.
-57-
Rapoarte ale aplicației :
-58-
4.2. FORMULARE ale APLICATIEI
1. BALANTA – Vizualizare balanta pentru perioada de analiza
2. BILANT – Culegere date formular bilant
3. BILANTVIZ – Vizualizare bilant
4. CONT – Culegere date tabela CONT
5. DATAB – Declararea perioadei de listare balanta
6. DATABALANTA – Crearea balantei pentru perioada de analiza
7. DATABIL – Crearea bilantului pentru perioada de analiza
8. DATAFISACONT – Crearea fisei cont pentru perioada de analiza
9. DATAJ – Declararea perioadei de listare registru jurnal
10. DATAJURNAL – Crearea registrului jurnal pentru perioada de analiza
11. FISACONT – Vizualizare fisa cont
12. JURNAL – Vizualizarea registrului jurnal
13. OPERATIE – Culegere date pentru tabelele DOCUMENT, OPERATIE,
RULAJE
14. PRELDATA – Declararea perioadei de initializare solduri
15. RAP – Optiuni pentru listari
16. VIZ – Optiuni pentru vizualizare
-59-
Formularul – FINANCONT
FINANCONT – formularul de interfata al aplicatiei
Procedura – INIT (dimensiunile formularului)
thisform.height=326
thisform.left=50
thisform.width=636
thisform.top=50
Clauza CONT – creearea si actualizarea tabelei CONT
use "d:\aplicont\dbfs\cont"
index on simbolcont tag simbolcont
use "d:\aplicont\dbfs\cont" order simbolcont
do form CONT
Clauza OPERATIE – creearea si actualizarea tabelelor DOCUMENT, OPERATIE,
RULAJE
select A
use "d:\APLICONT\DBFS\document"
index on str(numardoc,4) tag numardoc
use
use "d:\APLICONT\DBFS\document" order numardoc
select B
use "d:\APLICONT\DBFS\operatie"
index on str(numarop,4) tag numarop
use
use "d:\APLICONT\DBFS\operatie" order numarop
select C
use "d:\APLICONT\DBFS\rulaje"
index on simbolcont tag simbolcont
use
use "d:\APLICONT\DBFS\rulaje" order simbolcont
do form OPERATIE
Clauza REGISTRUJURNAL – executa creearea Registrului Jurnal pentru perioada
declarata
do form DATAJURNAL
Clauza FISACONT – creeaza Fisa Cont a produsului pentru perioada de studiu
do form DATAFISACONT
-60-
Clauza BALANTA – efectueaza Balanta sintetica pentru perioada de analiza
do form DATABALANTA
Clauza BILANT – efectueaza crearea si actualizarea tabelei BILANT
do form BILANT
Clauza – EXECUTIE BILANT – prelucreaza datele pentru perioada de analiza obtinindu-se
bilantul contabil
do form DATABIL
Clauza – INITIALIZARE SOLDURI LUNARE – modul executa initializarea soldurilor
initiale pentru luna in curs cu soldurile finale ale lunei precedente
do form PRELDATA
Clauza – VIZUALIZARI – ofera vizualizare pentru REGISTRUL JURNAL, FISA CONT,
BALANTA SI BILANT aferenta perioadei de analiza
do form VIZ
Clauza – RAPORTARI – confera listari pentru REGISTRUL JURNAL, FISA CONT,
BALANTA SI BILANT aferente perioadei de analiza
do form RAP
Clauza – IESIRE
close data
THISFORM.RELEASE
Formular – CONT
Procedura – INIT – se initializeaza cimpurile aferente culegerii de date
simbol1=space(10)
simbol2=space(10)
den1=space(50)
tipcont1=space(3)
sid1=0
sic1=0
-61-
Clauza – CAUTARE(combo)
Procedura – INIT
simbol2=space(10)
Procedura – LOST FOCUS – intructiuni ce se executa la iesirea din CAUTARE
In cadrul procedurii se citeste tabela CONT in functie de variabila simbol2 si se executa modificarea sau stergerea inregistrarii.
select cont
do case
case sw=2
seek simbol2
if found()=.T.
store cont.simbolcont to simbol1
store cont.denumire to den1
store cont.tipcont to tipcont1
store cont.sid to sid1
store cont.sic to sic1
thisform.refresh
thisform.text2.enabled=.T.
thisform.text2.setfocus
endif
case sw=3
store cont.simbolcont to simbol1
store cont.denumire to den1
store cont.tipcont to tipcont1
store cont.sid to sid1
store cont.sic to sic1
thisform.refresh
thisform.command4.enabled=.T.
thisform.command4.setfocus
endcase
-62-
Clauza – TEXT1-Simbol1
Procedura – INIT
simbol1=space(10)
Procedura – LOST FOCUS
La parasirea cimpului Simbol1 se valideaza existenta in tabela CONT a valorii noului cont.
select cont
seek simbol1
if found()=.T.
messagebox("Numar simbol existent")
thisform.command1.enabled=.T.
thisform.command1.setfocus
endif
Procedura – VALID EVENT – continutul variabilei nu trebuie sa fie spatiu
select cont
if empty(simbol1)=.T.
messagebox(" Eroare – simbolul are valoarea spatiu ")
return.F.
endif
Clauza – TEXT2 – den1
Procedura – INIT
den1=space(50)
Procedura – VALID EVENT – denumirea trebui sa fie diferita de spatiu
if empty(den1)=.T.
messagebox("Eroare – denumirea nu este completata")
return.F.
endif
Clauza – TEXT3 – tipcont 1
Procedura – INIT
tipcont1=space(3)
-63-
Procedura – VALID EVENT – valideaza valoarea tipului cont (A, P, B)
if upper(tipcont1)#'A'.and.upper(tipcont1)#'P'.and.upper(tipcont1)#'B'
messagebox("Eroare – Sunt admise numai valorile A,P,B ")
tipcont1=space(3)
return.F.
endif
Clauza – TEXT 4 –sid 1
Procedura – INIT
sid1=0
Procedura – LOST FOCUS
sic1=0
Clauza – TEXT 5 – sic 1
Procedura – LOST FOCUS – (sid1>0 si sic1=0) sau (sid1=0 si sic1>0)
if (sid1<>0.and.sic1<>0)
messagebox ("Eroare – Contul are doua solduri initiale")
sid1=0
sic1=0
thisform.text4.setfocus
endif
Clauza – ADAUGARE(command)
Procedura – CLICK EVENT
sw=1
thisform.text1.setfocus
Procedura – VALID EVENT
simbol1=space(10)
Clauza – MODIFICARE(command)
Procedura – CLICK
sw=2
thisform.combo1.enabled=.T.
thisform.combo1.setfocus
-64-
Clauza – STERGERE(command)
Procedura – CLICK
sw=3
thisform.combo1.enabled=.T.
thisform.combo1.setfocus
Clauza – SCRIERE(command)
Procedura – VALID – In functie de valoarea variabilei sw se face adaugarea unei noi
inregistrari, modificarea sau stergerea inregistrarii existente
do case
case sw=1
select cont
seek simbol1
appe blank
repl simbolcont with simbol1
repl denumire with den1,tipcont with proper(tipcont1)
repl sid with sid1,sic with sic1
case sw=2
select cont
seek simbol1
if found()=.T.
repl denumire with den1, tipcont with proper(tipcont1)
repl sid with sid1,sic with sic1
endif
case sw=3
seek simbol2
if found()=.T.
dele
endif
endcase
simbol1=space(10)
simbol2=space(10)
den1=space(50)
tipcont1=space(3)
sid1=0
sic1=0
thisform.refresh
thisform.combo1.requery
thisform.command1.enabled=.T.
thisform.command1.setfocus
-65-
Clauza – EXIT
Procedura – CLICK
select cont
pack
use
thisform.release
Formularul – OPERATIE
Procedura – INIT
nrdoc1=0
tipdoc1=space(10)
datadoc1=ctod(space(8))
nrop1=0
dataop1=ctod(space(8))
expl1=space(50)
simbolcont1=space(10)
sumadb1=0
sumacr1=0
contcoresp1=space(10)
select rulajman
zap
Procedura – CAUTARE (combo)
Procedura – INIT
nrop2=1
Procedura – LOSTFOCUS
select document
seek nrdoc2
if found()=.T.
store document.numardoc to nrdoc1
store document.tipdoc to tipdoc1
store document.datadoc to datadoc1
endif
select operatie
seek nrdoc2
if found()=.T.
-66-
store operatie.numarop to nrop1
store operatie.dataop to dataop1
store operatie.explicatie to expl1
endif
select rulajman
zap
appe from "d:\aplicont\dbfs\rulaje" for numarop=nrop1
select rulajman
sum rulajman.sumadebit to totalsid
sum rulajman.sumacredit to totalsic
thisform.refresh
if sw=21.or.sw=22
thisform.text2.enabled=.T.
thisform.text2.setfocus
else
thisform.command7.enabled=.T.
thisform.command7.setfocus
endif
Procedura – REQUERY
thisform.combo1.requery
Clauza – nrdoc1(text)
Procedura – GOT FOCUS
nrdoc1=0
tipdoc1=space(10)
datadoc1=ctod(space(8))
nrop1=0
dataop1=ctod(space(8))
expl1=space(50)
simbol1=space(10)
contcoresp1=space(10)
thisform.refresh
Procedura – INIT
nrdoc1=0
-67-
Procedura – LOST FOCUS
select A
seek str(nrdoc1,4)
if found()=.T.
messagebox("Numar document existent")
thisform.command1.enabled=.T.
thisform.command1.setfocus
endif
Clauza – tipdoc1(text)
Procedura – VALID
if empty(tipdoc1)=.T.
messagebox("Cimp necompletat")
return.F.
endif
Clauza – datadoc1(text)
Procedura – INIT
datadoc1=ctod(space(8))
Procedura -VALID
if empty(strtran(dtoc(datadoc1),'/',' '))=.T.
messagebox("Data documentului necompletata")
return.F.
endif
Clauza – nrop1(text)
Procedura – LOST FOCUS
if sw=1
select operatie
seek str(nrop1,4)
if found()=.T.
messagebox("Numar operatie existent")
thisform.command1.enabled=.T.
thisform.command1.setfocus
endif
endif
-68-
Procedura – VALID
if nrop1=0
messagebox(" Eroare – Numar operatie 0")
return.F.
endif
Clauza – dataop1 (text)
Procedura – VALID
if empty(strtran(dtoc(dataop1),'/',' '))=.T.
messagebox("Data documentului necompletata")
dataop1=ctod(space(8))
return.F.
endif
Clauza – EXPL1(text)
Procedura – LOST FOCUS
if sw=22
thisform.command7.enabled=.T.
thisform.command7.setfocus
else
thisform.text7.enabled=.T.
thisform.text7.setfocus
endif
Procedura – VALID
if empty(expl1)=.T.
messagebox("Eroare – Explicatia nu este completata")
expl1=space(50)
return.F.
endif
Clauza – simbol1(text)
Procedura – INIT
simbol1=space(10)
Procedura – LOST FOCUS
if sw=21
select rulajman
locate for rulajman.simbolcont=simbol1
if found()=.T.
store sumadebit to sumadb1,sumadb
store sumacredit to sumacr1,sumacr
endif
endif
-69-
thisform.refresh
thisform.text9.setfocus
Procedura -VALID
if empty(simbol1)=.T.
messagebox(" Eroare – simbolul are valoarea spatiu ")
return.F.
endif
Clauza – nrop1(text)
Clauza – sumadb1(text)
Clauza – sumacr1(text)
Procedura – LOST FOCUS
if sw=1.and.((sumadb1<>0.and.sumacr1<>0).or.(sumadb1=0.and.sumacr1=0))
sumadb1=0
sumacr1=0
thisform.refresh
thisform.text9.setfocus
endif
Clauza – contcoresp1(text)
Procedura – LOSTFOCUS
select rulajman
do case
case sw=1
locate for rulajman.simbolcont=simbol1
if found()=.F.
appe blank
repl simbolcont with simbol1, numarop with nrop1
repl contcoresp with contcoresp1
repl sumadebit with sumadb1
repl sumacredit with sumacr1
if sumadb1>0
repl contdb with simbol1
else
repl contcr with simbol1
endif
else
messagebox("Eroare – Contul exista")
endif
-70-
case sw=21.and.(sumadb1<>0.or.sumacr1<>0)
locate for rulajman.simbolcont=simbol1
if found()=.T.
repl sumacredit with 0
repl sumadebit with 0
repl contdb with space(10)
repl contcr with space(10)
repl simbolcont with simbol1, numarop with nrop1
repl contcoresp with contcoresp1
repl sumadebit with sumadb1
repl sumacredit with sumacr1
if sumadb1>0
repl contdb with simbol1
else
repl contcr with simbol1
endif
else
appe blank
repl simbolcont with simbol1, numarop with nrop1
repl contcoresp with contcoresp1
repl sumadebit with sumadb1
repl sumacredit with sumacr1
if sumadb1>0
repl contdb with simbol1
else
repl contcr with simbol1
endif
endif
case sw=21.and.(sumadb1=0.and.sumacr1=0)
dele for rulajman.simbolcont=simbol1
select rulaje
dele for rulaje.numarop=nrop1.and.rulaje.simbolcont=simbol1
endcase
thisform.refresh
thisform.command5.enabled=.T.
thisform.command5.setfocus
-71-
Procedura – VALID
if empty(contcoresp1)=.T.
messagebox(" Eroare – simbolul are valoarea spatiu ")
return.F.
endif
Cluza – Totalsid
Clauza – Totalsic
Clauza – ADAUGARE(command)
Procedura – CLICK
sw=1
totalsic=0
totalsid=0
thisform.text1.setfocus
Procedura – VALID
store 0 to sumadb,sumacr
thisform.refresh
simbol1=space(10)
thisform.refresh
Clauza DA (command)
Procedura – CLICK
sw=21
store 0 to sumadb,sumacr
thisform.combo1.enabled=.T.
thisform.combo1.setfocus
Clauza NU (command)
Procedura – CLICK
sw=22
store 0 to sumadb,sumacr
thisform.combo1.enabled=.T.
thisform.combo1.setfocus
Clauza – STERGERE(command)
Procedura – CLICK
sw=3
store 0 to sumadb,sumacr
thisform.combo1.enabled=.T.
thisform.combo1.setfocus
-72-
Clauza – DA (command)
Procedura – REFRESH
totalsid=totalsid+sumadb1-sumadb
totalsic=totalsic+sumacr1-sumacr
Procedura – VALID
simbol1=space(10)
sumadb1=0
sumacr1=0
contcoresp1=space(10)
thisform.refresh
thisform.text7.enabled=.T.
thisform.text7.setfocus
Clauza – IESIRE(command)
Procedura – VALID
simbol1=space(10)
sumadb1=0
sumacr1=0
contcoresp1=space(10)
thisform.refresh
thisform.command7.enabled=.T.
thisform.command7.setfocus
Clauza – SCRIU(command)
Procedura – VALID
do case
case sw=1
select A
appe blank
repl numardoc with nrdoc1,datadoc with datadoc1
repl tipdoc with proper(tipdoc1)
select B
appe blank
repl numarop with nrop1
repl dataop with dataop1
repl explicatie with proper(expl1)
repl numardoc with nrdoc1,tipdoc with proper(tipdoc1)
select C
appe from "d:\aplicont\dbfs\rulajman"
case sw=3
-73-
select A
dele all for document.numardoc=nrdoc1
pack
select B
dele all for operatie.numardoc=nrdoc1
pack
select rulaje
dele all for rulaje.numarop=nrop1
pack
endcase
select rulajman
zap
nrdoc1=0
tipdoc1=space(10)
datadoc1=ctod(space(8))
nrop1=0
dataop1=ctod(space(8))
expl1=space(50)
simbol1=space(10)
sumadb1=0
sumacr1=0
contcoresp1=space(10)
totalsid=0
totalsic=0
thisform.refresh
sw=1
thisform.command1.enabled=.T.
thisform.command1.setfocus
Clauza – EXIT
Procedure – VALID
close database
thisform.release
-74-
FORMULAR BILANT – modulul creeaza si actualizeaza tabela formular bilant
Procedura – INIT
codform1="10"
explrind1=space(60)
formula1=space(100)
nrrind1=0
tipop1="cont"
select formbilant
index on codform+str(nrrind,3) tag formrind
Clauza – FORMULAR(Combo)
Procedura – LOST FOCUS
if sw=1
calculate max(nrrind) to nrrind1 for codform=codform1
nrrind1=nrrind1+1
thisform.refresh
thisform.combo2.enabled=.T.
thisform.combo2.setfocus
else
nrrind1=0
endif
Clauza – NUMAR RAND(text)
Procedura – LOSTFOCUS
loca for codform=codform1.and.nrrind=nrrind1
if tipop='ct'
store 'cont' to tipop1
else
store 'rind' to tipop1
endif
store explrind to explrind1
store formula to formula1
thisform.refresh
if sw=2
thisform.combo2.enabled=.T.
thisform.combo2.setfocus
else
thisform.command4.enabled=.T.
thisform.command4.setfocus
endif
-75-
Clauza – TIP OPERATIE
Procedura – LOST FOCUS
thisform.text1.setfocus
Clauza – EXPLICATIE(text)
Procedura – VALID
if empty(explrind1)=.T.
messagebox("EROARE – cimp incomplet")
return.F.
endif
Clauza – FORMULA(text)
Procedura – VALID
if empty(formula1)=.T.
messagebox("EROARE – cimp incomplet")
return.F.
endif
Clauza – ADAUG(command)
Procedura – CLICK
sw=1
thisform.combo1.enabled=.T.
thisform.combo1.setfocus
Procedura – GOT FOCUS
codform1="10"
explrind1=space(60)
ormula1=space(100)
tipop1="cont"
thisform.refresh
Clauza – MODIFICARE(command)
Procedura – CLICK
sw=2
thisform.combo1.enabled=.T.
thisform.combo1.setfocus
Clauza – STERGERE(command)
Procedura – CLICK
sw=3
thisform.combo1.enabled=.T.
thisform.combo1.setfocus
-76-
Clauza – SCRIERE – DA (command)
Procedura – VALID
select formbilant
seek codform1+str(nrrind1,3)
do case
case sw=1
if found()=.T.
messagebox("EROARE – Formular si rind existent")
else
appe blank
replace codform with codform1, explrind with upper(explrind1)
replace nrrind with nrrind1, formula with formula1
if tipop1='rind'
replace tipop with "r"
else
replace tipop with "ct"
endif
endif
case sw=2
if found()=.F.
messagebox("EROARE – Formular si rind inexistent")
else
replace explrind with upper(explrind1)
replace formula with formula1
if tipop1='rind'
replace tipop with "r"
else
replace tipop with "ct"
endif
endif
case sw=3
if found()=.F.
messagebox("EROARE – Formular si rind inexistent")
else
dele
endif
endcase
thisform.refresh
thisform.command1.enabled=.T.
thisform.command1.setfocus
-77-
Clauza – SCRIU – NU (command)
Procedura – CLICK
thisform.command1.enabled=.T.
thisform.command1.setfocus
Procedura – EXIT (command)
select formbilant
pack
thisform.release
FORMULAR DATABALANTA
Procedura – INIT
wdata1=ctod(space(8))
wdata2=ctod(space(8))
thisform.refresh
Clauza – PERIOADA
Procedura – VALID (text1)
if empty(strtran(dtoc(wdata1),'/',' ' ))=.T.
messagebox("Data de inceput a analizei necompletata")
return.F.
endif
Procedura – VALID (text2)
if empty(strtran(dtoc(wdata2),'/',' ' ))=.T.
messagebox("Data de sfarsit a analizei necompletata")
return.F.
endif
Clauza – IESIRE – OK (command)
Procedura – CLICK
ll=month(wdata2)
store ' ' to a
a=strtran(str(ll-1,2),' ','0')
use "d:\aplicont\dbfs\soldlunar" order simbolcont exclusiv in B
if reccount()>0
use "d:\aplicont\dbfs\cont" order simbolcont exclusiv in C
set rela to simbolcont into B
repl all cont.sid with soldlunar.db_&a
repl all cont.sic with soldlunar.cr_&a
endif
-78-
close data
use "d:\aplicont\dbfs\balanta" exclusiv in A
zap
index on simbolcont tag simbolcont
use "d:\aplicont\dbfs\cont" order simbolcont exclusiv in C
select A
appe from cont
close data
use "d:\aplicont\dbfs\balanta" order simbolcont exclusiv in A
use "d:\aplicont\dbfs\jurnal" exclusiv in B
wcont=space(10)
scan
if empty(b.contdb)=.F.
wcont=b.contdb
select balanta
seek wcont
if found()=.T.
repl a.ruldb with a.ruldb+b.sumedebit
endif
else
if empty(b.contcr)=.F.
wcont=b.contcr
select balanta
seek wcont
if found()=.T.
repl a.rulcr with a.rulcr+b.sumecredit
endif
endif
endif
wcont=space(10)
select balanta
endscan
close data
use "d:\aplicont\dbfs\balanta" order simbolcont exclusiv in A
select balanta
scan
repl a.totalsd with a.sid+a.ruldb
repl a.totalsc with a.sic+a.rulcr
if totalsd>=totalsc
repl a.sfdb with a.totalsd-a.totalsc
repl a.sfcr with 0
endif
-79-
if a.totalsc>a.totalsd
repl a.sfcr with a.totalsc-a.totalsd
repl a.sfdb with 0
endif
endscan
select balanta
use
thisform.release
Clauza – IESIRE – CANCEL(command)
Procedura – CLICK
messagebox("EROARE – Formularul BALANTA nu a fost creat")
thisform.release
FORMULAR – DATABIL
Procedure – INIT
wdata1=ctod(space(8))
wdata2=ctod(space(8))
thisform.refresh
Clauza PERIOADA (text1)
Procedura – VALID
if empty(strtran(dtoc(wdata1),'/',' ' ))=.T.
messagebox("Data de inceput a analizei necompletata")
return.F.
endif
Clauza PERIOADA (text2)
Procedura – VALID
if empty(strtran(dtoc(wdata2),'/',' ' ))=.T.
messagebox("Data de sfarsit a analizei necompletata")
return.F.
endif
Clauza – IESIRE – DA(command)
Procedure – CLICK
li=strtran(str(month(wdata1),2),' ' ,'0')
ls=strtran(str(month(wdata2),2),' ' ,'0')
sele a
use d:\aplicont\dbfs\soldlunar
index on simbolcont tag simbolcont
use
-80-
use d:\aplicont\dbfs\soldlunar order simbolcont
sele b
use d:\aplicont\dbfs\formbilant
index on codform+tipop+str(nrrind,3) tag codform
use
use d:\aplicont\dbfs\formbilant order codform
repl all sold_i_an with 0
repl all sold_sf_an with 0
store 0 to wnr
store ' ' to wtipop,wcodform
scan
sele b
wcodform=codform
wsimbcont=space(10)
wnrrind=nrrind
wtipop=tipop
store 0 to n,l,ip,im
store 0 to ts_i_an,ts_sf_an
ip=occurs('+',formula)
im=occurs('-',formula)
n=ip+im
do case
case n=0
if wtipop='ct'
wsimbcont=substr(formula,1,10)
sele a
seek wsimbcont
if found()=.T.
store a.db_&li+a.cr_&li to ts_i_an
store a.db_&ls+a.cr_&ls to ts_sf_an
endif
else
wsimbcont=substr(formula,1,3)
loca for codform=wcodform.and.;
alltrim(str(nrrind,3))=alltrim(wsimbcont)
if found()=.T.
store sold_i_an to ts_i_an
store sold_sf_an to ts_sf_an
endif
endif
-81-
sele b
seek wcodform+wtipop+str(wnrrind,3)
repl sold_i_an with ts_i_an
repl sold_sf_an with ts_sf_an
case n>0
ff='+'+formula
sp=occurs('+',ff)
sm=occurs('-',ff)
n=sp+sm
decl matr_s[n,n]
for i=1 to n
matr_s[i,1]=0
matr_s[i,2]=' '
endfor
l=len(alltrim(ff))
i=1
wsemn=' '
for j=1 to l
if substr(ff,j,1)='+'.or.substr(ff,j,1)='-'
matr_s[i,1]=j
matr_s[i,2]=substr(ff,j,1)
i=i+1
endif
endfor
for i=1 to n
ki=matr_s[i,1]+1
wsemn=matr_s[i,2]
if i#n
ks=matr_s[i+1,1]
wsimbcont=substr(ff,ki,ks-ki)
else
ks=l
wsimbcont=substr(ff,ki,l-ki+1)
endif
do case
case wtipop='ct'
sele a
seek wsimbcont
if found()=.T.
if wsemn='+'
ts_i_an=ts_i_an+a.db_&li+a.cr_&li
ts_sf_an=ts_sf_an+a.db_&ls+a.cr_&ls
-82-
else
ts_i_an=ts_i_an-(a.db_&li+a.cr_&li)
ts_sf_an=ts_sf_an-(a.db_&ls+a.cr_&ls)
endif
endif
case wtipop='r '
loca for codform=wcodform.and.alltrim(str(nrrind,3))=alltrim(wsimbcont)
if found()=.T.
if wsemn='+'
ts_i_an=ts_i_an+sold_i_an
ts_sf_an=ts_sf_an+sold_sf_an
else
ts_i_an=ts_i_an-sold_i_an
ts_sf_an=ts_sf_an-sold_i_an
endif
endif
endcase
endfor
sele b
seek wcodform+wtipop+str(wnrrind,3)
repl sold_i_an with ts_i_an
repl sold_sf_an with ts_sf_an
endcase
endscan
thisform.release
Clauza – IESIRE – CANCEL
Procedura – CLICK
messagebox("EROARE – BILANTUL nu a fost creat")
thisform.release
FOREMULAR – DATAFISACONT
Procedura – INIT
wdata1=ctod(space(8))
wdata2=ctod(space(8))
thisform.refresh
-83-
Clauza – PERIOADA (text1)
Procedura – VALID
if empty(strtran(dtoc(wdata1),'/',' ' ))=.T.
messagebox("Data de inceput a analizei necompletata")
return.F.
endif
Clauza – PERIOADA (text2)
Procedura – VALID
if empty(strtran(dtoc(wdata2),'/',' ' ))=.T.
messagebox("Data de sfarsit a analizei necompletata")
return.F.
endif
Clauza – IESIRE – DA(command)
Procedure – CLICK
select b
use operatie
index on str(numarop,4) tag numarop
use
use operatie order numarop
select c
use rulaje
index on str(numarop,4) tag numarop
use
use rulaje order numarop
set rela to str(numarop,4) into b
select d
select c.simbolcont,c.numarop,;
b.dataop,b.numardoc,b.tipdoc,;
c.contcoresp,c.sumadebit,c.sumacredit from ;
operatie b,rulaje c into DBF ;
d:\aplicont\dbfs\fisacont where ;
betw(b.dataop,wdata1,wdata2);
.and.str(b.numarop,4)=str(c.numarop,4)
close data
thisform.release
-84-
Procedure – IESIRE – CANCEL
Proceduran – CLICK
messagebox("EROARE – Formularul FISA CONT nu a fost creat")
thisform.release
FORMULAR FISADATA
Procedura – INIT
wdata1=ctod(space(8))
wdata2=ctod(space(8))
wcont=space(10)
select A
use d:\aplicont\dbfs\cont
index on simbolcont tag simbolcont
use
use d:\aplicont\dbfs\cont order simbolcont
Clauza -PERIOADA (text1)
Procedura -VALID
if empty(strtran(dtoc(wdata1),'/',' ' ))=.T.
messagebox("Data de inceput a analizei necompletata")
return.F.
endif
Clauza – PERIOADA (text2)
Procedura – LOST FOCUS
thisform.list1.enabled=.T.
thisform.list1.setfocus
Procedura – VALID
if empty(strtran(dtoc(wdata2),'/',' ' ))=.T.
messagebox("Data de sfarsit a analizei necompletata")
return.F.
endif
Procedura – DBLCLICK
thisform.command1.enabled=.T.
thisform.command1.setfocus
Procedura – LOSTFOCUS
wcont=substr(wcont,1,10)
-85-
Clauza – IESIRE – OK
Procedura – CLICK
select B
use d:\aplicont\dbfs\fisaman
zap
appe from d:\aplicont\dbfs\fisacont for fisaman.simbolcont=wcont
thisform.release
do form FISACONT
Clauza IESIRE – CANCEL
messagebox("EROARE – S-a renuntat la VIZUALIZARE")
close data
thisform.release
-86-
PRINCIPAL.PRG – Programul principal al aplicatiei
clea
close data
on error do CANCEL
set talk off
set safety off
set defa to d:\aplicont
set path to SCRS,DBFS,PRLIST
set date french
set delete on
public nrdoc1,tipdoc1,datadoc1,sw
public simbol1,den1,tipcont1,sid1,sic1
public nrop1,dataop1,expl1,nrdoc1,tipdoc1
public sumadb1,sumacr1,totalsid,totalsic
public wdata1,wdata2,nrrind1,explrind1,formula1
public sumadb,sumacr
sumadb=0
sumacr=0
totalsid=0
totalsic=0
do form financont
rele all
cancel
read events
clear events
****************
procedure CANCEL
****************
close database
clear events
return
-87-
4.3.STRUCTURA TABELELOR APLICATIEI
Structure for table: BALANTA.DBF
Field Field Name Type Width Dec Index Collate Nulls
1 SIMBOLCONT Character 10 Asc Machine No
2 DENUMIRE Character 50 No
3 SID Currency 8 4 No
4 SIC Currency 8 4 No
5 RULDB Currency 8 4 No
6 RULCR Currency 8 4 No
7 TOTALSD Currency 8 4 No
8 TOTALSC Currency 8 4 No
9 SFDB Currency 8 4 No
10 SFCR Currency 8 4 No
** Total ** 125
Structure for table: CONT.DBF
Field Field Name Type Width Dec Index Collate Nulls
1 SIMBOLCONT Character 10 Asc Machine No
2 DENUMIRE Character 50 No
3 TIPCONT Character 3 No
4 SID Currency 8 4 No
5 SIC Currency 8 4 No
** Total ** 80
-88-
Structure for table: DOCUMENT.DBF
Field Field Name Type Width Dec Index Collate Nulls
1 NUMARDOC Numeric 4 No
2 TIPDOC Character 10 No
3 DATADOC Date 8 No
** Total ** 23
Structure for table: FISACONT.DBF
Field Field Name Type Width Dec Index Collate Nulls
1 SIMBOLCONT Character 10 No
2 NUMAROP Numeric 4 No
3 DATAOP Date 8 No
4 NUMARDOC Numeric 4 No
5 TIPDOC Character 10 No
6 CONTCORESP Character 10 No
7 SUMADEBIT Currency 8 4 No
8 SUMACREDIT Currency 8 4 No
** Total ** 63
Structure for table: FISAMAN.DBF
Field Field Name Type Width Dec Index Collate Nulls
1 SIMBOLCONT Character 10 No
2 NUMAROP Numeric 4 No
3 DATAOP Date 8 No
4 NUMARDOC Numeric 4 No
5 TIPDOC Character 10
-89-
No
6 CONTCORESP Character 10 No
7 SUMADEBIT Currency 8 4 No
8 SUMACREDIT Currency 8 4 No
** Total ** 63
Structure for table: FORMBILANT.DBF
Field Field Name Type Width Dec Index Collate Nulls
1 CODFORM Character 2 No
2 EXPLRIND Character 60 No
3 NRRIND Numeric 3 No
4 FORMULA Character 100 No
5 TIPOP Character 2 No
6 SOLD_I_AN Currency 8 4 No
7 SOLD_SF_AN Currency 8 4 No
** Total ** 184
Structure for table: JURNAL.DBF
Field Field Name Type Width Dec Index Collate Nulls
1 NUMARDOC Numeric 4 No
2 TIPDOC Character 10 No
3 DATADOC Date 8 No
4 NUMAROP Numeric 4 No
5 DATAOP Date 8 No
6 EXPLICATIE Character 50 No
7 CONTDB Character 10 No
8 CONTCR Character 10
-90-
No
9 SUMACREDIT Currency 8 4 No
10 SUMADEBIT Currency 8 4 No
** Total ** 121
Structure for table: OPERATIE.DBF
Field Field Name Type Width Dec Index Collate Nulls
1 NUMAROP Numeric 4 No
2 DATAOP Date 8 No
3 EXPLICATIE Character 50 No
4 NUMARDOC Numeric 4 No
5 TIPDOC Character 10 No
** Total ** 77
Structure for table: RULAJCUM.DBF
Field Field Name Type Width Dec Index Collate Nulls
1 SIMBOLCONT Character 10 No
2 NUMAROP Numeric 4 No
3 SUMADEBIT Currency 8 4 No
4 SUMACREDIT Currency 8 4 No
5 CONTCORESP Character 10 No
** Total ** 41
Structure for table: RULAJE.DBF
Field Field Name Type Width Dec Index Collate Nulls
1 SIMBOLCONT Character 10 Asc Machine No
2 NUMAROP Numeric 4 No
3 SUMADEBIT Currency 8 4
-91-
No
4 SUMACREDIT Currency 8 4 No
5 CONTCORESP Character 10 No
6 CONTDB Character 10 No
7 CONTCR Character 10 No
** Total ** 61
Structure for table: RULAJMAN.DBF
Field Field Name Type Width Dec Index Collate Nulls
1 SIMBOLCONT Character 10 Asc Machine No
2 NUMAROP Numeric 4 No
3 SUMADEBIT Currency 8 4 No
4 SUMACREDIT Currency 8 4 No
5 CONTCORESP Character 10 No
6 CONTDB Character 10 No
7 CONTCR Character 10 No
** Total ** 61
Structure for table: SOLDLUNAR.DBF
Field Field Name Type Width Dec Index Collate Nulls
1 SIMBOLCONT Character 10 Asc Machine No
2 DB_01 Currency 8 4 No
3 CR_01 Currency 8 4 No
4 DB_02 Currency 8 4 No
5 CR_02 Currency 8 4 No
6 DB_03 Currency 8 4 No
7 CR_03 Currency 8 4
-92-
No
8 DB_04 Currency 8 4 No
9 CR_04 Currency 8 4 No
10 DB_05 Currency 8 4 No
11 CR_05 Currency 8 4 No
12 DB_06 Currency 8 4 No
13 CR_06 Currency 8 4 No
14 DB_07 Currency 8 4 No
15 CR_07 Currency 8 4 No
16 DB_08 Currency 8 4 No
17 CR_08 Currency 8 4 No
18 DB_09 Currency 8 4 No
19 CR_09 Currency 8 4 No
20 DB_10 Currency 8 4 No
21 CR_10 Currency 8 4 No
22 DB_11 Currency 8 4 No
23 CR_11 Currency 8 4 No
24 DB_12 Currency 8 4 No
25 CR_12 Currency 8 4 No
** Total ** n 203
-93-
BIBLIOGRAFIE:
Grupul BDASEIG – „Baze de date. Fundamente teoretice și practice” – Editura Infomega 2002;
Tamaș Ilie, Popa Gheorghe, Berbec Florentina, Vrîncianu Marinela, Glăvan Nicolae – „Sisteme de gestiune a bazelor de date – Visual FoxPro” – Editura CISON 2001.
Kaufman F. – „Data Systems Cross Company – Haward Business” 2001
META Group Application Development Strategies – „Data Mining For Data Warehouse: Uncovering for Hidden Patterns”
Ovidiu Nicolescu și colectivul – „Sistemul decizional al organizației” – Editura Economică 1998.
Al.Ștefănescu, Gh.Popa, M.Iliescu, F. Albescu – „Programarea calculatoarelor” – lito ASE București 1993
I.Radu – „Informatica Managerială” – Editura Economică, București, 1996.
M.Stănescu ș.a. – „Bazele informaticii” – Editura CISON, 1995
E. Oxborrow – „Databases and Database Systems” – Chartwell, 1989
J.G.Ullman – „Principles of Database Systems” – Computer science, 1982
I.Lungu s.a. – „Baze de date – Organizare, proiectare și implementare” – Editura All educational, București, 1995
D. Fife, T.Hardgrave – „Database concepts” – South-Western, 1986
Gabriel Dima – „FoxPro” – Editura Teora,București, 1993
Al.Ștefănescu, Gh..Popa, V. Florescu, M.Iliescu, V. Sasu, B.Ionescu, V.Tinta – „Lucrari practice – Aplicații ale limbajului COBOL pe minicalculatoare și microcalculatoare PC” – lito ASE, București, 1991.
Ghe.Popa, Al.Ștefănescu – „Sisteme de gestiune a bazelor de date dBase IV, Oracle” – Editura All, București, 1991
-94-
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Sistem Informatic de Analiza a Bazelor de Date Multidimensionale (ID: 148816)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.