Modele de Date - Tipuri de Modele de Date

Modele de Date

Modelele de Dae sunt discutate in contextul apropierii Structurilor concepute in Spatiul de Informatii de instrumentul de prelucrare - Calculatorul. Vom regasi conceptele dezvoltate in sectiunile precedente, la care se vor adauga cele specifice reprezentarilor pe Suportul de Memorare. Avand in vedere Planurile de Descrise introduse in sectiunea 3.4.1.2 (al Numelor si al Valorilor) si in aceasta sectiune vom vedea procesul de implementare desfasurat pe nivele diferite de abstractizare (de la cele Conceptuale la cele Fizice).

Tipuri de Modele de Date

Interpretarea realitatii are nevoie de un instrument care sa asigure doua cerinte importante [TSIC82]:

Suficienta Abstractie - care sa stearga perturbatiile concretului

Suficienta Putere - pentru a surprinde esenta realitatii modelate

Sau altfel exprimat:

"Modelul trebuie sa reprezinte un instrument de abstractie, care sa permita:

Sa vezi Padurea - si anume informatiile continute in date,

in locul Copacilor - datele privite detasat de semnificatiile de aansamblu."

Langefors, in 1977, propune ca Element Atomic pentru modelarea Spatiului de Informatii si de Date tupla:

Nume Obiect , Proprietate Obiect, Valoare Obiect, Timp

Pentru reducerea volumului de date memorate si prelucrate, cel mai adesea se sacrifica ultimul component al tuplei si anume Timpul. Ramane atunci ca Element Atomic de descriere tupla :

Nume Obiect , Proprietate Obiect, Valoare Obiect)

retinandu-se pentru prelucrare doar ultimul eveniment semnificativ in timp.

Structurile de Informatii si de Date pot fi atunci construite in doua moduri :

o         Crearea, pe baza continutului in Informatii al Tuplei Elementare de descriere, a unor Categorii de Informatii sau Date (Abrial , reprezentate de Multimi de Informatii sau Date impreuna cu Relatiile dintre ele (vezi Modelul Formal tratat in sectiunea 4.1.1.3). Gruparea Multimilor in Categorii se face pe baza similaritatilor constatate, sub forma celor de mai jos:

aceleasi Proprietati

acelasi Nume Comun

aceleasi Relatii

o         Pornind de la o multime de asemenea Elemente Atomice, acestea sunt ad-hoc conectate intre ele pe baza Relatiilor de Legatura desprinse din spatiul ce urmeaza a fi descris

Cele doua moduri de utilizare a Tuplei Atomice conduc la doua variante de construire a Structurilor de Informatii si / sau de Date:

Informatii / Date Strict categorisite - Structuri zise de Tip Strict

Informatii / Date Vag categorisite - Structuri zise de Tip Vag

Cu aceste doua Tipuri de Date pot acum sa fie construite doua feluri de Modele:

o         Modele Stricte (Omogene) - care fac distinctie intre Entitati, Caracteristici si Valori, tratandu-le in mod diferentiat ca:

Elemente Autoidentificabile - Valorile

Elemente Nedecompozabile - Caracteristicile

Elemente Agregate - Entitatile

o         Modele Vagi (Heterogene) - care impun o tratare unitara a tuturor Elementelor, indiferent ca sunt Entitati, Caracteristici sau Valori

Fiecare Tip de Model prezinta avantaje si dezavantaje care favorizeaza anumite utilizari, defavorizandu-le pe altele. Se prezinta in continuare insusirile si utilizarile specifice pentru fiecare model:

o         Modelele Stricte - se preteaza pentru prelucrari de colectii de volum mare, care solicita un acces rapid, atat la nivel de entitate cat si la nivel de caracteristica (exemplu: Sisteme de Gestiune Baze de Date)

Pretind Structura Ferma a datelor

Impun Omogenizare fortata

Realizeaza Performante Ridcate la prelucrari de Volum Mare

Limiteaza utilizarea procedurilor de Adaptabilitate Inteligenta

o         Modelele Vagi - se preteaza pentru prelucrari care accepta structurare slaba a datelor la intrare si care genereaza structuri prin declarare de reguli de construire (exemplu: Sisteme de Programare Logica)

Accepta Structura Vaga a datelor

Realizeaza Formalizare Unica si Adaptabila a realitatii

Realizeaza Performante Acceptabile numai pentru Volume Mici de date

Asigura Adaptabilitate Inteligenta mare

Arhitectura Modelelor de Date Stricte

Modelele Stricte se bazeaza pe existenta unei puternice Structuri de Date a carei descriere amanuntita se concepe si se memoreaza inainte de precizarea oricarei proceduri de prelucrare si care urmareste in continuare urmatoarele obiective:

o         Sa realizeze Independenta Datelor fata de Proceduri si totodata a diferitelor Nivele de Descriere a Datelor

Legenda

M - Model

G - Reguli de Generare - LDD (Limbaj de Descriere Date)

G_s - Reguli de Specificare Structura

G_r - Reguli de Specificare Restrictii

S - Schema de Descriere (Baza de Date Logica - BDL

S_s - Lista de Categorii, Proprietati, Relatii

S_c - Lista de Restrictii

D - Realizare de BDL (Baza de Date Fizica)

O - Operatii de Acces Admise - LMD (Limbaj de Manipulare a Datelor)

O_l - Lista Operatiilor Utilizate

O_n - Operatii de Navigare

O_s - Operatii de Specificare

Fig. 4.2.1.1.1 Componentele Modelelor Stricte de descriere a datelor

o         Sa asigure Necesitatile de Informare pentru oricare utilizator pentru Cereri prezente si viitoare

o         Sa ofere tuturor procedurilor Facilitatile de Acces la Date conform criteriilor de performanta preconizate

o         Sa garanteze mentinerea in permanenta a unei Structuri de Date Deschise oricaror modificari, optimizari sau extensii cerute, fie datorita schimbarii conditiilor initiale de proiectare, fie datorita cerintelor de imbunatatire a performantelor (viteza de acces, consistenta, distribuire etc. )

Aceste cerinte solicita dezvoltarea unui nou Nivel de Proiectare Conceptuala, al carui aport sa fie marcat de urmatoarele avantaje:

Un Grad mai Abstract de Formalizare

o        Extinderea Validarii Datelor de la simple Limite sau Conditii, la Proceduri Restrictii) atasate Operatiilor de Actualizare Evenimente

o        Imbogatirea Semanticii atasate Structurilor de Informatii si Date prin incorporarea Operatiilor Compatibile cu Structurile Proiectate in corpul Modelului de Date

Posibilitati sporite de Control a Structurilor Complexe

o        Gruparea Obiectelor diverse (Structuri, Constrangeri, Reguli de Integritate, Restrictii, Operatii) in Modelul de Date

o        Corelarea Conditiilor de Definire a Obiectelor Multiple

Facilitati de Adaptabilitate la Modificari crescute

o        Instrumente Grafice performante pentru reprezentarea Formalismelor

o        Procese de Generare Directa Engineering) si Inversa Reengineering) a Structurilor de Implementare

Aceste conditii pot fi indeplnite daca se adauga un nou nivel de Definirea a Structurilor de Informatii si Date in forma unui produs specializat in constructia Modelelor de Date, care sa aiba in alcatuire trei componente principale (vezi Fig. 4.2.1.1.1:

o        Descrierea Structurii

o        Descrierea Restrictiilor

o        Descrierea Operatiilor

Pentru exemple vezi Baza de Date Medicala din sectiunea 4.2.4.

Descrierea Structurii

Descrierea Structurii contine declararea Proprietatile Principale (Statice), care se mentin Invariante in timp (Fig. 4.2.1.1.2.1). Declararea Structurii se efectueaza prin intermediul unui set de Reguli de Specificare (Fig. 4.2.1.1.1) - G (LDD)

Specificarea Elementelor de Structura (Proprietatile de Baza) - G _s

Specificarea Numelor de Categorii (Clase de Entitati)

Specificarea Proprietatilor pentru Categorii (Atribute Descriptoare, Dependente intre Atribute, Identificatori de Entitati)

Specificarea Relatiilor intre Categorii (Proprietatile de Referire)- G _s

Regulile de Specificare definite in cadrul Modelului de Date vor fi convertite in Liste de Categorii, Proprietati si Relatii S _s), care vor constitui Nivelul Logic de Descriere al Bazei de Date (S) (Fig. 4.2.1.1.1). Aceasta transformare se va face automat printr-un Process de Generare a Descrierii de Structura (Engineering).

Descrierea Restrictiilor

Daca Structura unui Model de Date reuneste Proprietatile de Baza ce descriu Datele, Restrictiile suplimenteaza descrierea cu informatii referitoare la Conditiile Impuse fiecarui Obiect din Structura de Date (vezi Tab. 4.2.1.1.2.1). Specificarea Restrictiilor impuse Entitatilor si Atributelor definite in Structura se face prin intermediul unor Reguli de Specificare a Restrictiilor - G _r, care vor fi convertite in Baza de Date Logica, asemenea Elementelor de Structura, in Liste de Restrictii S_c Regulile de Specificare a Restrictiilor vin sa completeze semantica acordata datelor continute in structura, precizand conditiile pe care Valorile Datelor trebuie sa le respecte la incarcarea in Structura. Ca urmare Restrictiile retin Proprietati Auxiliare ale Datelor si anume Conditiile Logice impuse, ce descriu Cunostinte despre Structura. Se prezinta in continuare o clasificare a Categoriilor de Informatii pe care Restrictiile le adauga intr-un Model de Date:

Restrictii de Identificare - pentru evitarea Dublurilor

Restrictii de Referire - pentru evitarea "Copiilor Orfani"

Restrictii de Domeniu, ce vor fi apoi transferate asupra tuturor Atributelor provenite din Domeniu

Expresiile Dependentelor de Materializare a Datelor, implicand acele Date, Dependente Functional de Date Reale si care se memoreaza in Baza de Date din motive de performanta la regasire, avand insa nevoie de un Control Procedural a Consistentei

Restrictiile sunt de doua feluri Implicite si Explicite:

Restrictii Implicite - Denumite si Restrictii de Sistem (Inerente), ele sunt legate de Tipul de Model utilizat, verificarea lor cazand in seama SGBD - ului

Restrictii Explicite - Denumite si Restrictii de Utilizator, ele sunt specifice formelor particulare de implementare a Modelului de Date, fiind declarate de Utilizator

Modelele sunt cu atat mai Restrictive, cu cat Restrictiile Implicite sunt mai multe, iar Restrictiile Explicite sunt mai putine.

Analizand natura Informatiilor aduse de Restrictii se poate remarca, in calitate de Caracteristici de Baza ale acestor Obiecte, faptul ca ele reprezinta in Modelul de Date simultan Restrictii Logice si totodata Reguli Generice - G _r.

Exista doua moduri de declarare a Restrictiilor Intr-un Model de Date:

Statica - prin Specificare Predicativa

Dinamica - prin Specificare Operationala

Datorita functiei pe care Restrictiile o au in asigurarea Conditiilor de Validitate a continutului unei Baze de Date, Gradul lor de Indeplinire masoara calitatea Bazei de Date. Gradul de Indeplinire a Restrictiilor este masurat prin Propritatile lor la un moment dat:

o         Proprietati sintetice ale unei Restrictii

Consistenta

Realizabila (posibil de satisfacut)

Realista

o         Proprietati detaliate ale unei Restrictii C _i

Bine Formata - daca C _i satisface proprietatile sintetice

Realizata - daca C _i e adevarata pentru starea curenta a BD (DBS _k)

Realizabila - daca exista o stare DBS care satisface C _i

Invalida - daca nu exista nici-o stare DBS care satisface C _i

Consecventa Logica - C _i e o consecventa logica a unui set de alte restrictii C₁ , .. , C _n daca C _i e satisfacuta cand C ₁ , .. , C _n sunt satisfacute

Redondanta - daca C_i e o consecventa logica a restrictiilor C₁, .. , C_n

Echivalenta - C_i, C_j sunt echivalente daca C_i si C_j sunt consecvente logice reciproce

Proprietatile Restrictiilor se transfera asupra Bazei de Date pe care o supravegheaza. Ca urmare Proprietatile unei Baze de Date la un moment dat pot fi:

o         Consistenta a unei stari DBS _k a BD daca toate Restrictiile Schemei sunt satisfacute

o         Inconsistenta a unei stari DBS _k a BD - daca nu toate Restrictiile Schemei sunt satisfacute

o         Schema satisfacuta a unei stari DBS _k daca toate Restrictiile Schemei sunt satisfacute

o         Schema realizabila a unei BD - daca exista unele stari DBS _k care nu satisfac schema

o         Schema inconsistenta a unei BD - daca nici-o stare DBS _k nu satisface schema

o         O Schema Buna pentru o BD - o Schema care e:

Realizabila (poate fi satisfacuta)

Disponibila pentru Specificatii Precise

Disponibila pentru Validare

Tab. 4. Clasificarea Proprietatilor Obiectelor stocate intr-un Model de Date

Operatii

Transferul Operatiilor in Modelul de Date are o contributie deosebita pe linia asigurarii maximei Independente a elementelor constitutive ale Sistemelor cu Baze de Date.

Desi aparent paradoxal, apropierea Operatiilor de Date in cadrul Modelelor de Date creste Independenta Aplicatiilor fata de Structurile memorate prin aceea ca ele ofera Utilizatorului nu Colectii de Date, ci Metode de Regasire si Actualizare a acestora.

Migrarea Operatiilor in Modelele de Date se face pe cai multiple, prin Biblioteci de Functii, Proceduri Stocate, Trrigeri. O trecere in revista a acestor facilitati oferite de Sistemele de Gestiune a Bazelor de Date precum si de Programele de construire a Modelelor de Date va fi facuta in sectiunea 4.2.4.7.5, cu ocazia prezentarii Modelului Relational.

In aceasta prezentare generala a Modelelor Stricte de Date se ofera argumentele de baza care au facut ca Sistemele cu Baze de Date sa promoveze acest transfer al Operatiilor catre Structurile de Date:

o         Materializarea Datelor prin utilizarea Functiilor de Calcul pentru instantierea Datelor Virtuale doar in momentul apelului lor, a dat o rezolvare corecta a Dependentelor Functionale cauzatoare de inconsistenta in cazul memorarii redondante a datelor

o         Atasarea Operatiilor la Structurile de Date ofera pentru Utilizator o Interfata necesara care sa-l degreveze de cunoasterea detaliilor de structura a datelor, ferindu-l de posibile erori in operarea la acest nivel

o         Orientarea pe Evenimente a Operatiilor efectuatre asupra Datelor sunt stimulate de concentrarea lor in jurul Modificarilor operate in Structura

o         Prelucrarile Tranzactionale, indispensabile in contextul structurilor complexe prelucrate in regim de multiacces, cer o Viziune Globala asupra intregii colectii de Date

o         Colectiile Mari de Date pretind tot mai multa Logica de Prelucrare (Business Logic) in asigurarea coerentei datelor memorate, ceea ce determina dezvoltarea unui nivel de Proceduri orientate catre Structura de Date si nu catre Aplicatie, care asteapta in fiecare moment Date Validate

In consecinta ultima sectiune a unui Model de Date va fi consacrata descrierii Structurilor de Proceduri atasate Structurilor de Date. Descrierea Transformarilor (Operatiilor) - contine declararea proprietatilor Dinamice, care asigura Evolutia structurii in timp, prin intermediul unui set acordat de Operatii de Acces Admise - O (LMD). Din aceste Operatii de Acces Admise de Modelul de Date vor fi selectionate cele ce descriu Prelucrarile la care se cer a fi supuse Datele in cadrul Sistemelor de Aplicatii. Fiind grupate in Modelul Unic de Date sansa de a fi concepute Modular este foarte ridicata. Se spune ca Procedurile incorporate in Model vor fi mai degraba orientate catre Structurile de Date decat catre Aplicatii, cu un efect benefic asupra Controlabilitatii lor.

Operatii de Acces Admise - O vor da nastere in BD Logica, prin generare automata, la Listele de Operatii O_l (Fig. 4.2.1.1.1). Ultimul nivel din Figura va reprezenta Baza De Date Fizica (D), avand atasate Listele finale de Proceduri Individualizate O_n si O_s.