Perenitatea Conceptelor Promovate

de BAZELE DE DATE

Editia I-a

Alexandru Lelutiu

Cluj -Napoca 2002

Copiilor nostri, Smaranduca, Cristi si Raducu Sa învete sa fie curajosi.

Tuturor celor apropiati prin preocupari, care,

datorita interesului acordat disciplinei de Baze de Date,

m-au încurajat sa-mi exprim parerea pe un tarâm ce depaseste Tehnica si Ingineria,

patrunzând în misterul Informatiei,

fara de care pentru noi n-ar exista nimic din ceea ce ar putea exista si fara noi,

si nici chiar noi.

DIALOG

SOCRATE – Suntem de acord, nu-i asa, ca pentru a ne aminti un lucru, trebuie sa-l fi cunoscut înainte.

SIMMIAS – Intru totul de acord.

SOCRATE – Putem oare a conveni în aceasta privinta ca daca cunostinta ne vine într-o anume maniera, aceasta e o reminiscenta. Iata ce înteleg prin aceasta anume „maniera”:

Daca un om care a vazut, a auzit a perceput un lucru într-o maniera diferita decât a lua cunostinta de el, ci gândindu-se la altul, care nu apartine aceluiasi domeniu de cunostinte, nu-i asa ca nu avem drept de a spune ca si-a reamintit lucrul la care s-a gândit?

SIMMIAS – Cum asta?

SOCRATE – Sa luam un exemplu: Una e cunoasterea unui om si alta e cunoasterea unei lire.

SIMMIAS – Fara îndoiala.

SOCRATE – Ei bine, n-ai spus tu ce trezeste într-un prieten vederea unui mantou sau a oricarui alt lucru de care amicul sau are obiceiul sa se serveasca? In acelasi moment în care el recunoaste lira el receptioneaza în gândirea sa imaginea prietenului caruia îi apartine acea lira. Si aceasta e o reminiscenta ca si atunci când vazându-l pe Simias îti amintesti de Kebes. Si aici pot sa citez mii de exemple de acest fel.

SIMMIAS – Intr-adevar mii, pe Zeus!

SOCRATE – Nu este în acest caz un soi de reminiscenta, mai ales când e vorba de lucruri pe care timpul sau neatentia ne-a facut sa le uitam?

SIMMIAS – Sigur ca da.

SOCRATE – Dar, vazând un cal sau o lira, nu pot oare sa-mi amintesc de un om, si vazând portretul lui Simias sa-mi amintesc de Kebes?

SIMMIAS – Desigur.

SOCRATE – Si vazând portretul lui Simias sa-mi amintesc de însusi Simias?

SIMMIAS – Desigur, se poate Socrate!

Platon

Dialoguri / Fedon

„Doctrina aducerii aminte”

(extras)

Rostirea evocata poarta o patina de aproape doua milenii si jumatate.

Ea a fost transcrisa de catre Profesorul francez Jean Raymond Abrial, de la Universitatea din Grenoble, în deschiderea prezentarii conceptului de Baza de Date (denumita simbolic SOCRATE), pornind de la Modelul de Informatii: Entitate – Caracteristica – Valoare, elaborat în colectivul de cercetare pe care îl conducea la începutul anilor 1970.

Ce legatura poate avea cugetarea amintita cu Bazele de Date?

In aceasta descoperire a puterii de Evocare în reconstituirea unei Realitati trecute se regasesc o multime de raporturi de dualism între conceptele de baza cu care se opereaza în construirea Modelelor de Informatii si Date. Dintre acestea amintim urmatoarele:

o Informatie - Data în conceperea, proiectarea si prelucrarea Structurilor

o Semantic – Sintactic în reprezentarea continutului si formei Informatiei

o Nume – Valoare în reprezentarea Structurile de Date si Informatii

o Plan Logic – Fizic în descrierea Structurilor de Date si Informatii

o Model de Date – Baza de Date Logica în proiectarea generala si particulara a acelorasi structuri

Raporturile de mai sus stau la baza definirii Nivelelor de Abstractizare în operarea cu Structurile de Informatii si Date, deschizând calea spre nivelele înalte de concepere si proiectare a structurilor ce stau la baza oricarui sistem de aplicatii.

Ca urmare, putem folosi în locul Valorii concrete a Datei, Numele general al Datei, în locul Nivelului Fizic de reprezentare, Nivelul Logic de descriere, în locul Bazei de Date Logice particulare, Modelul de Date ce permite generarea mai multor instante de Baze de Date adaptate resurselor disponibile, apelând chiar la Sisteme de Gestiune diferite.

Legaturile care se creeaza izvorasc toate din puterea asociativa pe care o ofera planurile paralele de reprezentare a realitatii, Concreta si Simbolica, sustinute de competenta factorului uman, uneori înnascuta, cel mai adesea învatata, de a extrage din simple asocieri, lucruri aparent ascunse si recuperate prin amintire.

In exemplele enumerate, ce apartin în întregime Sistemelor cu Baze de Date, în sensul de a fi initiate si apoi promovate cu perseverenta în timp, de mai bine de o jumatate de veac, gasim motivatia frumoasei evocari folosite de profesorul francez.

Ideile cresc în stralucire atunci când vin de la o distanta de patru secole înainte de era noastra , de unde o fiinta reala, recunoscuta ca filosof, nu numai Iubitor de Întelepciune, ci si fondator al filozofiei morale, deci deopotriva Iubitor de Oameni, transmitea semenilor de atunci si de mai apoi mesajul, purtat din gura-n gura, ca Viata nu e un pret prea mare când poti da nastere unui Simbol care sa-i lumineze pe cei ce vin, înlesnindu-le cunoasterea, sporindu-le puterea de aflare a caii spre Adevar, Dreptate si Iubire.

Prefata 5

“Trecutul este usa Viitorului“ B.P. Hasdeu

PPRREEFFAATTAA

Timpul este Judecatorul neînduplecat al Conceptelor. El da adevarata lor masura, reala lor profunzime, dar mai ales confirmarea fertilitatii lor.

Aceasta veche constatare poate fi foarte bine verificata în cazul Sistemelor cu Baze de Date (SBD), atunci când se analizeaza aportul lor în domeniul prelucrarii automate a informatiilor si datelor, dar mai ales când se încearca aprecierea importantei lor trecute, prezente, dar mai ales viitoare.

Aceste sisteme au asistat de-a-lungul deceniilor la aparitii spectaculoase de noi metode, tehnici si limbaje de prelucrare, care au cazut apoi în uitare sau au fost mistuite de noi încercari si descoperiri. In tot acest timp SBD si-au continuat nestingherit drumul, pastrându-si personalitatea prin domeniul de preocupari, devenind tot mai prietenoase cu utilizatorii prin accesibilitatea conceptelor implementate. Tinta acestor sisteme a ramas permanent construirea unei viziuni cât mai unitare si cât mai controlabile asupra Spatiilor de Informatii reprezentate si prelucrate cu tehnici din ce în ce mai performante. Fidele acestui deziderat ele au asimilat toate noutatile pe care le-au filtrat dupa capacitatea lor de a servi ideilor initiale de gestiune a colectiilor mari de informatii si date. Intre aceste noutati tinem sa mentionam pe cele legate de conceptele structuraliste de organizare a datelor si procedurilor, cele ce promovau viziunea functionala în prelucrare, cele ce dezvoltau conceptul de independenta, deschizând orientarea spre organizarea obiectuala etc.

Multe din facilitatile dezvoltate au usurat într-atât utilizarea produselor comerciale care abunda piata informatica, încât a creat falsa impresie ca oricine se pricepe la Baze de Date, ca odata însusite câteva cunostinte de operare, proiectarea SBD e la îndemâna oricui. De aici s-a nascut si mentalitatea multor beneficiari ca achizitia unor asemenea aplicatii trebuie sa fie gratuita, neglijând urmarile pe care diletantismul în proiectare le aduce mai devreme sau mai târziu, când de fapt totul trebuie reproiectat si de obicei abia acum se realizeaza faptul ca aceasta costa.

Un alt pericol consta în faptul ca pâna si unii proiectanti considera ca, de vreme ce exista utilizatori multumiti cu sisteme improvizate, precis ca domeniul de interes al Bazelor de Date s-a deplasat spre construirea interfetelor de acces spectaculoase, acolo unde tehnologiile în inflatie lanseaza mereu o noua moda, chiar si atunci când nu sunt înca suficient definite, mai ales în ceea ce priveste raportul lor cu sistemele traditionale, pe care refuza sa le înteleaga considerându-le apuse. Atitudinea: „Sursa de Date trebuie lasata la latitudinea utilizatorului, fie el si neinstruit” determina înmultirea rapida a produselor de ocazie, efemere si inconsistente ca structura. Pornind

6 Prefata

de la observatiile facute, consideram utila o prezentare a conceptelor de baza, care în lumina timpului trecut de la prima lor lansare, au fost permanent confirmate, dezvoltate si corelate, asa încât sa permita în prezent o corecta definire a SBD si sa ofere totodata fundamentul pentru dezvoltarea acestora spre o proiectare de nivel mai înalt. Acest nivel va implica definirea si construirea structurilor de date si proceduri, reunite în domeniul mai larg al Modelelor de Date, ce încorporeaza atât Structurile de Date cât si Restrictiile si Operatiile aferente, declarate la un nivel superior de abstractizare, cu capacitate generativa sporita. Aceasta intentie justifica absenta unor capitole de interes recent, legate de tehnologiile de acces de la distanta la sursele de date organizate ca Baze de Date, în favoarea concentrarii atentiei asupra întelegerii acelor particularitati care mentin si azi interesul în jurul SBD. Cititorul va fi ajutat sa caute raspuns la unele întrebari importante, legate de procesarea datelor, cum ar fi:

o De ce Sistemele cu Baze de Date sunt înca în voga?

o Este conceptul de Independenta asociat cu SBD?

o Este Modelul Relational perisat?

o Model Relational sau Obiectual?

o Simplitatea Tabelei mai poate ascunde secrete?

o Explorarea Dependentele între Informatii e straina Bazelor de Date?

Cu acest cadru propus lucrarea nu va oferi prilejul de învatare a unui Limbaj, a unui Produs sau a unei Tehnici, ci posibilitatea însusirii unei viziuni generale asupra drumului parcurs de SBD si mai ales asupra zestrei de cunostinte pe care acest domeniu îl pune la dispozitia Cercetatorului, Proiectantului si Utilizatorului. Ca urmare ea se adreseaza tuturor acestor categorii de specialisti, la care se adauga bineînteles cei ce se initiaza prin studiu sau practica în acest domeniu promitator (studenti sau elevi).

Numerosi colaboratori (cadre didactice, cercetatori, proiectanti, implementatori, studenti), însirati pe un drum de 30 de ani de activitate în domeniu, gasesc aici cuvântul meu de multumire pentru spijinul acordat cu generozitate s i pasiune. Daca acest sprijin a fost cu adevarat folosit va putea hotarî desigur numai cititorul. Exista între cei apropiati o categorie aparte pentru care cuvântul meu de multumire e de prisos, caci au alergat prea aproape de mine, ducându-ma spre tinta si ferindu-se la vederea liniei de sosire si care doresc acum doar sa afle daca am trecut-o cu bine. Dar sii aceasta informatie o pot afla doar de la cititor. Mai este loc pe prezenta pagina pentru o lacrima de iubire închinata celor care mi-au împartas it singuratatea, asteptându-ma.

Autorul

Prefata 7

Cluj – Napoca, septembrie 2002

8 Prefata

C U P R I N S

PPRREEFFAATTAA .................................................................................................................................................. 5 1 Introducere......................................................................................................................................17

1.1 Importanta Sistemelor cu Baze de Date .........................................................................17 1.2 Aportul Sistemelor cu Baze de Date ...............................................................................19 1.3 Continutul Lucrarii .............................................................................................................21

2 Sisteme cu Baze de Date...............................................................................................................28

2.1 Aparitia Conceptului de Baza de Date ...........................................................................28 2.1.1 Nivele de Abstractizare într-un SBD..........................................................................28 2.1.2 Functiile unui SGBD .....................................................................................................33 2.1.3 Raportul Date - Proceduri .............................................................................................34

2.2 Definitia Bazelor de Date ...................................................................................................36 2.3 Avantajele utilizarii Bazelor de Date ..............................................................................37 2.4 Exemple de Baze de Date ...................................................................................................38

3 Concepte de Baza...........................................................................................................................42 3.1 Multimi si Relatii..................................................................................................................42

3.1.1 Multimi ............................................................................................................................42 3.1.1.1 Caracteristicile de baza ale Multimii ......................................................................43 3.1.1.2 Incluziunea Multimilor .............................................................................................43 3.1.1.3 Identitatea Multimilor ...............................................................................................44 3.1.1.4 Multimea Totala .........................................................................................................44 3.1.1.5 Numararea Partilor unei Multimi Totale ................................................................45 3.1.1.6 Operatii Booleene pe Multimea Partilor unei Multimi Totale ...........................46 3.1.1.7 Acoperire si Partitie ...................................................................................................46 3.1.1.8 Latice............................................................................................................................47

3.1.2 Relatii între Multimi ......................................................................................................48 3.1.2.1 Produs Cartezian de multimi....................................................................................49 3.1.2.2 Reuniunea Disjuncta a Multimilor..........................................................................49 3.1.2.3 Relatia n-ara ................................................................................................................49 3.1.2.4 Implicarea relatiilor (Extensii si Restrictii) ...........................................................50 3.1.2.5 Proiectia relatiilor ......................................................................................................51 3.1.2.6 Proprietatile Relatiilor Binare ..................................................................................52

3.1.2.6.1 Relatii Binare pe Doua Multimi Distincte .....................................................52 3.1.2.6.2 Relatii Binare pe Aceeasi Multime .................................................................53

3.1.2.6.2.1 Tipuri de Relatii Binare pe Aceeasi Multime ........................................55 3.1.2.6.2.1.1 Relatia de Echivalenta .......................................................................55 3.1.2.6.2.1.2 Relatii de Ordine.................................................................................56

3.1.2.6.2.1.2.1 Relatia de Ordine Partiala ..........................................................57 3.1.2.6.2.1.2.2 Relatia de Ordine Totala ............................................................58

Cuprins 9

3.1.2.6.2.1.2.3 Relatia de Bine Ordonare ..........................................................59 3.1.2.6.2.1.3 Relatia de Similitudine (Asemanare) ..............................................59

3.1.3 Relatii, Aplicatii, Functii .............................................................................................60 3.1.4 Grafuri ..............................................................................................................................60

3.1.4.1 Graful ca Relatie ........................................................................................................60 3.1.4.2 Graful ca Aplicatie .....................................................................................................61 3.1.4.3 Arbori...........................................................................................................................62

3.2 Informatie si Data ................................................................................................................65 3.2.1 Modelul Matematic ........................................................................................................66 3.2.2 Modelul Semiotic ...........................................................................................................67 3.2.3 Modelul Propozitional...................................................................................................68

3.3 Date si Proceduri..................................................................................................................71 3.4 Structuri de Informatii si Date .........................................................................................73

3.4.1 Structura, Organizare si Acces.....................................................................................73 3.4.1.1 Structura Logica si Fizica.........................................................................................77 3.4.1.2 Spatiul de Informatii si de Date...............................................................................80

3.4.2 Structuri Fundamentale de Informatii si Date ...........................................................83 3.4.2.1 Definirea Structurilor Fundamentale ......................................................................83 3.4.2.2 Transformarea Structurilor Fundamentale .............................................................91

3.4.2.2.1 Tipuri de transformari .......................................................................................91 3.4.2.2.1.1 Eliminarea Redondantei............................................................................92 3.4.2.2.1.2 Inversarea Partiala (Indexarea).................................................................93 3.4.2.2.1.3 Eliminarea Redondantei + Inversarea Partiala ......................................94 3.4.2.2.1.4 Inversarea Totala ........................................................................................96 3.4.2.2.1.5 Reorganizarea Structurii............................................................................98

3.4.2.2.2 Generalizarea Conceptului de Inversare.........................................................99 3.4.3 Reprezentarea Structurilor de Informatii si de Date...............................................101

3.4.3.1 Reprezentarea Fizica (Reprezentarea Clasica)....................................................101 3.4.3.2 Reprezentarea Logica (Reprezentarea Simbolica).............................................103 3.4.3.3 Arborele de Structura ..............................................................................................107 3.4.3.4 Diagrama Entitati – Relatii.....................................................................................111 3.4.3.5 Schema de Descriere ..............................................................................................115

3.4.4 Structuri de Informatii la Utilizator...........................................................................116 3.4.4.1 Structura de Ansamblu............................................................................................116 3.4.4.2 Structuri Partiale ......................................................................................................119 3.4.4.3 Reprezentarea Structurii de Ansamblu .................................................................124

3.4.5 Diversificarea Tipurilor de Legaturi între Entitati..................................................127 3.4.5.1 Viziunea în Produsul ORACLE ............................................................................127 3.4.5.2 Viziunea în Produsul ERWIN ...............................................................................135

3.5 Structuri de Proceduri......................................................................................................138 3.5.1 Operatie si Procedura ..................................................................................................138 3.5.2 Operatii de control .......................................................................................................139

3.5.2.1 Compozitia ................................................................................................................139 3.5.2.2 Selectia .......................................................................................................................139 3.5.2.3 Repetitia .....................................................................................................................141

10 Cuprins

3.5.2.4 Substitutia..................................................................................................................142 3.5.3 Elementele Structurilor de Proceduri........................................................................142 3.5.4 Descrierea Formala a Procedurilor............................................................................144 3.5.5 Descrierea în Pseudo - Cod ........................................................................................145 3.5.6 Arborele de Programare ..............................................................................................146

4 Modele de Informatii si Date.....................................................................................................152 4.1 Modele de Informatii ........................................................................................................152

4.1.1 Modelul Entitate – Caracteristica – Valoare (Modelul ECV) ..............................152 4.1.1.1 Descrierea Spatiului de Informatii ........................................................................152 4.1.1.2 Descrierea Spatiului de Date..................................................................................155 4.1.1.3 Entitate – Caracteristica – Valoare .......................................................................157

4.1.1.3.1 Entitate ...............................................................................................................158 4.1.1.3.2 Clasa de Entitati................................................................................................159 4.1.1.3.3 Metaclasa de Entitati .......................................................................................161 4.1.1.3.4 Caracteristica.....................................................................................................162 4.1.1.3.5 Valoare ...............................................................................................................163 4.1.1.3.6 Relatii de Asociere ...........................................................................................165 4.1.1.3.7 Ansamblu de Entitati .......................................................................................166 4.1.1.3.8 Clasa de Ansambluri de Entitati ....................................................................168

4.1.1.4 Modelul formal ECV în termeni de Multimi si Relatii ....................................171 4.1.1.4.1 Definire matematica.........................................................................................171 4.1.1.4.2 Descriere g rafica...............................................................................................171

4.1.2 Modelul Obiectelor Abstracte (OA) .........................................................................174 4.1.2.1 Procesul de Abstractizare .......................................................................................174 4.1.2.2 Obiecte Abstracte.....................................................................................................175

4.1.2.2.1 Obiecte Generice ..............................................................................................175 4.1.2.2.2 Obiecte Agregate..............................................................................................178

4.1.2.3 Ierarhii de Obiecte Abstracte .................................................................................179 4.1.2.4 Realizari de Obiecte Abstracte..............................................................................182 4.1.2.5 Ierarhii de Obiecte Abstracte în Planul Realizarilor..........................................183 4.1.2.6 Relativitatea Viziunii asupra Obiectelor Abstracte............................................186 4.1.2.7 Sintaxa Abstracta.....................................................................................................189 4.1.2.8 Operatii Abstracte....................................................................................................191 4.1.2.9 Principiul Conservarii Semantice..........................................................................191 4.1.2.10 Metodologia de Proiectare în Modelul OA.....................................................192

4.1.2.10.1 Continutul Metodologiei de Proiectare ......................................................192 4.1.2.10.2 Erori de Utilizare a Metodologiei ...............................................................193

4.1.2.10.2.1 Stabilirea Categoriilor Directe .............................................................193 4.1.2.10.2.2 Stabilirea Componentelor Directe.......................................................194 4.1.2.10.2.3 Identificarea Incompleta .......................................................................195 4.1.2.10.2.4 Tratarea Obiectelor Abstracte de tip Rol............................................195

4.1.3 Modelul Conceptual.....................................................................................................200 4.2 Modele de Date ...................................................................................................................206

4.2.1 Tipuri de Modele de Date ...........................................................................................206 4.2.1.1 Arhitectura Modelelor de Date Stricte .................................................................207

4.2.1.1.1 Descrierea Structurii ........................................................................................209

Cuprins 11

4.2.1.1.2 Descrierea Restrictiilor....................................................................................210 4.2.1.1.3 Descrierea Operatiilor .....................................................................................213

4.2.2 Modelul Ierarhic ...........................................................................................................214 4.2.2.1 Segmentul de Articol ca si Constructor de Structura.........................................214 4.2.2.2 Avantajele si Dezavantajele Modelului Ierarhic ................................................216

4.2.3 Modelul Retea...............................................................................................................217 4.2.3.1 Setul de Articole ca si Constructor de Structura.................................................217 4.2.3.2 Avantajele si Dezavantajele Modelului Retea ....................................................222

4.2.4 Modelul Relational.......................................................................................................224 4.2.4.1 Relatia ca si Constructor de Structura ..................................................................224 4.2.4.2 Proprietatile Relatiei................................................................................................228 4.2.4.3 Intensiunea si Extensiunea Relatiilor ...................................................................230 4.2.4.4 Cheile Relatiilor.......................................................................................................231

4.2.4.4.1 Reguli de Integritate a Relatiilor ...................................................................232 4.2.4.4.2 Identificare, Acces si Ordonare în Structuri Relationale ...........................232

4.2.4.4.2.1 Chei de Identificare ..................................................................................233 4.2.4.4.2.2 Chei de Acces............................................................................................236 4.2.4.4.2.3 Chei de Ordonare......................................................................................242

4.2.4.5 Manipularea Structurilor Relationale ...................................................................244 4.2.4.5.1 Metoda bazata pe Algebra Relationala .........................................................245

4.2.4.5.1.1 Operatori Relationali................................................................................245 4.2.4.5.1.2 Operatori Relationali Traditionali..........................................................247 4.2.4.5.1.3 Operatori Specific Relationali................................................................251 4.2.4.5.1.4 Set Complet de Operatori Relationali ...................................................257 4.2.4.5.1.5 Sintaxa unui LMD bazat pe Algebra Relationala ...............................257 4.2.4.5.1.6 Limbajul de Navigare si Operatorii Algebrei Relationale .................259 4.2.4.5.1.7 Tipuri de SGBD-uri Relationale ............................................................260

4.2.4.5.2 Metoda bazata pe Calculul Relational..........................................................261 4.2.4.5.2.1 Limbajul Logic ..........................................................................................261 4.2.4.5.2.2 Calculul Relational al Tuplelor..............................................................264

4.2.4.5.2.2.1 Elementele Expresiilor în CRT ......................................................264 4.2.4.5.2.2.2 Variabile Libere si Legate...............................................................265 4.2.4.5.2.2.3 Expresii de Calcul Relational al Tuplelor ....................................267 4.2.4.5.2.2.4 Implementare Calcului Relational al Tuplelor ............................268

4.2.4.5.2.2.4.1 Exemple de ECT .......................................................................268 4.2.4.5.2.2.4.2 Limbajul SQL............................................................................270

4.2.4.5.2.3 Calculul Relational al Domeniilor.........................................................277 4.2.4.5.2.3.1 Elementele Expresiilor în CRD......................................................277 4.2.4.5.2.3.2 Variabile Libere si Legate...............................................................279 4.2.4.5.2.3.3 Expresii de Calcul Relational al Domeniilor ...............................279 4.2.4.5.2.3.4 Implementare Calcului Relational al Domeniilor.......................280

4.2.4.5.2.3.4.1 Exemple de ECD.......................................................................280 4.2.4.5.2.3.4.2 Limbajul QBE ...........................................................................281

4.2.4.6 Nivelul Extern în Modelul Relational ..................................................................285 4.2.4.6.1 Vederea ca si Constructor al Nivelului Extern ............................................285 4.2.4.6.2 Operatii în LMD asupra Vederilor................................................................287 4.2.4.6.3 Vederile si Independenta Datelor..................................................................290

12 Cuprins

4.2.4.7 Modelul Relational ca Model Strict de Date.......................................................292 4.2.4.7.1 Structura datelor ..............................................................................................292 4.2.4.7.2 Tipuri de Structuri Relationale .......................................................................297

4.2.4.7.2.1 Tipuri de Legaturi Relationale ...............................................................298 4.2.4.7.2.2 Tipuri de Relatii ........................................................................................300

4.2.4.7.2.2.1 Relatii de tip Entitate .......................................................................301 4.2.4.7.2.2.1.1 Entitate Completa .....................................................................301 4.2.4.7.2.2.1.2 Entitate Incompleta...................................................................302

4.2.4.7.2.2.2 Relatii de tip Legatura .....................................................................304 4.2.4.7.2.2.2.1 Legatura Simpla ........................................................................304 4.2.4.7.2.2.2.2 Legatura Completa ...................................................................307

4.2.4.7.2.2.3 Relatii de tip Mixt .............................................................................308 4.2.4.7.3 Implementarea Relationala a Operatiilor de Abstractizare .......................311

4.2.4.7.3.1 Implementarea Agregarii .........................................................................312 4.2.4.7.3.2 Implementarea Generalizarii ..................................................................312 4.2.4.7.3.3 Tip General de Structura Relationala ....................................................314

4.2.4.7.4 Restrictii impuse Datelor..............................................................................315 4.2.4.7.4.1 Restrictii Implicite....................................................................................315 4.2.4.7.4.2 Restrictii Explicite....................................................................................316

4.2.4.7.5 Operatii asupra datelor....................................................................................318 4.2.4.7.5.1 Operatii Procedurale – Navigarea în Tabele .......................................319 4.2.4.7.5.2 Operatii Neprocedurale ...........................................................................322 4.2.4.7.5.3 Nivele de Definire a Operatiilor.............................................................323

4.2.4.8 Construirea Structurilor Relationale .....................................................................324 4.2.4.8.1 Generalizarea Entitatilor .................................................................................324 4.2.4.8.2 Agregarea Entitatilor .......................................................................................328

4.2.4.8.2.1 Structuri 1 - n.............................................................................................328 4.2.4.8.2.2 Structuri m - n ...........................................................................................329

4.2.4.8.3 Reprezentarea Structurilor Ierarhice .............................................................345 4.2.4.8.3.1 Reprezentarea Entitatii ............................................................................347 4.2.4.8.3.2 Reprezentarea Subentitatii ......................................................................349

4.2.4.8.4 Reprezentarea Structurilor Matriciale ...........................................................357 4.2.4.8.5 Reprezentarea Datelor de Tip Multime ........................................................359

4.2.4.9 Conditiile ca o BD sa fie Relationala ...................................................................362 4.2.4.9.1 Reguli de Fundamentare – Regula 0 si 12 ...................................................362 4.2.4.9.2 Reguli Structurale – Regula 1 si 6.................................................................363 4.2.4.9.3 Reguli de Integritate – Regula 10 si 3 ..........................................................364 4.2.4.9.4 Reguli de Manipulare a Datelor – Regula 5, 2, 7 si 4................................365 4.2.4.9.5 Reguli de Independenta a Datelor – Regula 8, 9 si 11...............................366

5 Optimizarea Modelelor de Date................................................................................................369 5.1 Optimizarea Structurilor de Date .................................................................................369

5.1.1 Introducere.....................................................................................................................370 5.1.2 Abordarea Formalizata a Normalizarii Relatiilor...................................................371

5.1.2.1 Definitii si Notatii ....................................................................................................371 5.1.2.2 Dependente Functionale .........................................................................................373

5.1.2.2.1 Definitii si Notatii ............................................................................................373

Cuprins 13

5.1.2.2.1.1 Proprietatile Formale ale Dependentelor Functionale.......................374 5.1.2.2.2 Relatii Normalizate BCNF .............................................................................378

5.1.2.3 Dependente Multivalorice ......................................................................................379 5.1.2.3.1 Proprietatile Formale ale Dependentelor Multivalorice:...........................381

5.1.3 Abordarea Istorica a Normalizarii Relatiilor...........................................................383 5.1.3.1 Studiu de Caz............................................................................................................384

5.1.3.1.1 Spatiul Informatiilor ........................................................................................384 5.1.3.1.1.1 Descrierea Spatiului de Informatii.........................................................384 5.1.3.1.1.2 Diagrama Simbolica.................................................................................385 5.1.3.1.1.3 Diagramele Dependentelor Functionale ...............................................386

5.1.3.1.2 Spatiul Datelor..................................................................................................387 5.1.3.1.2.1 Descriere Intensionala .............................................................................387 5.1.3.1.2.2 Arborele de Structura ...............................................................................389 5.1.3.1.2.3 Descriere Extensionala – Valori Memorate .........................................389

5.1.3.2 Etapele Normalizarii................................................................................................390 5.1.3.2.1 Relatii Normale de Grad 1..............................................................................391 5.1.3.2.2 Relatii Normale de Grad 2..............................................................................391 5.1.3.2.3 Relatii Normale de Grad 3..............................................................................394 5.1.3.2.4 Descompunerea Relatiilor ..............................................................................395 5.1.3.2.5 Relatii Normale BCNF....................................................................................399

5.1.3.2.5.1 Relatii cu Chei Candidate Multiple Disjuncte.....................................399 5.1.3.2.5.2 Relatii cu Chei Candidate Multip le Nedisjuncte.................................400

5.1.3.2.6 Relatii Normale de Grad 4..............................................................................403 5.1.3.2.7 Relatii Normale de Grad 5 (PJNF) ................................................................405 5.1.3.2.8 Concluzii............................................................................................................410

5.1.4 Abordarea Semantica a Normalizarii Relatiilor......................................................411 5.1.4.1 Abordarea Sistemica a Proiectarii.........................................................................413 5.1.4.2 Utilizarea Modelului Obiectelor Abstracte .........................................................427

5.1.4.2.1 Implementarea Relationala a Modelului Obiectelor Abstracte................428 5.1.4.2.2 Definirea Restrictiilor......................................................................................428 5.1.4.2.3 Definirea Procedurilor Stocate.......................................................................428

5.1.4.3 Concluzii finale ........................................................................................................429 5.2 Optimizarea Cererilor ......................................................................................................430

5.2.1 Evaluarea Costurilor de Prelucrare a Cererilor.......................................................430 5.2.2 Reorganizarea Cererilor..............................................................................................431

5.2.2.1 Tratarea Produselor Carteziene .............................................................................431 5.2.2.2 Tratarea Reunirilor..................................................................................................433

5.2.3 Strategii Generale de Optimizare ..............................................................................433 6 Securitatea Bazelor de Date.......................................................................................................436

6.1 Controlul Accesului la Date.............................................................................................436 6.1.1 Categorii de Informatii gestionate în Controlul Accesului la Date .....................436 6.1.2 Controlul Drepturilor de Acces la Date cu ajutorul LMD....................................438 6.1.3 Controlul Confidentialitatii de Acces la Date .........................................................439

6.2 Prelucrari Tranzactionale ...............................................................................................443 6.2.1 Erori în Tranzactii Necontrolate ................................................................................444

14 Cuprins

6.2.2 Tipurile de Întreruperi ale unei Tranzactii ...............................................................446 6.2.3 Starile unei Tranzactii .................................................................................................447 6.2.4 Jurnalizarea Tranzactiilor ...........................................................................................450 6.2.5 Proprietatile unei Tranzactii Atomice.......................................................................451 6.2.6 Planul de Operatii Tranzactionale .............................................................................452 6.2.7 Proprietatile Tranzactiilor în Refacerea Bazei de Date .........................................453 6.2.8 Serializarea Tranzactiilor............................................................................................455 6.2.9 Controlul Concurentei.................................................................................................461 6.2.10 Granularitatea Datelor.................................................................................................466

6.3 Refacerea B azelor de Date ...............................................................................................467 6.3.1 Termeni si Concepte....................................................................................................467 6.3.2 Tehnici de Refacere .....................................................................................................471

6.3.2.1 Tehnica bazata pe Actualizarea Amânata............................................................472 6.3.2.2 Tehnica bazata pe Actualizarea Imediata ............................................................473

7 Baze de Date Evoluate ................................................................................................................475 7.1 Baze de Date Deductive ....................................................................................................476

7.1.1 Inferenta bazata pe Calculul Propozitional..............................................................477 7.1.2 Inferenta bazata pe Calculul Predicativ ....................................................................482 7.1.3 Descrierea Formala a unui Limbaj Predicativ .........................................................483

7.1.3.1 Predicate ....................................................................................................................483 7.1.3.2 Formule Bine Construite ........................................................................................483

7.1.4 Interpretare si Model ...................................................................................................485 7.1.4.1 Interpretarea Formulelor.........................................................................................485 7.1.4.2 Evaluarea Formulelor Bine Construite.................................................................488 7.1.4.3 Model.........................................................................................................................489

7.1.5 Forme Clauzale .............................................................................................................491 7.1.6 Deducere în Baze de Date...........................................................................................493 7.1.7 Viziunea Inferentiala a unei BDD.............................................................................500 7.1.8 Metode de Deducere în SBD......................................................................................505

7.1.8.1 SBD Pur Deductive .................................................................................................505 7.1.8.2 SBD Deductive Mixte .............................................................................................507 7.1.8.3 SBD Deductiv-Generative......................................................................................510

7.2 Baze de Date Distribuite ...................................................................................................513 7.2.1 Generalitati ....................................................................................................................513 7.2.2 Solutii Generale de Proiectare....................................................................................515 7.2.3 Proiectarea Structurilor de Date Distribuite ............................................................520

7.2.3.1 Generalitati................................................................................................................520 7.2.3.1.1 Baze de Date Distribuite ( BDS) ...................................................................521 7.2.3.1.2 Arhitecturi Client - Server ..............................................................................522

7.2.3.2 Tehnici de proiectare a BDS..................................................................................523 7.2.3.2.1 Tehnica de Fragmentare ..................................................................................524

7.2.3.2.1.1 Fragmentarea Orizontala ........................................................................526 7.2.3.2.1.2 Fragmentarea Verticala ..........................................................................527 7.2.3.2.1.3 Fragmentarea Mixta ................................................................................527

7.2.3.2.2 Tehnica de Replicare .......................................................................................528

Cuprins 15

7.2.3.2.3 Tehnica de Alocare ..........................................................................................528 7.2.3.2.4 Studiu de Caz....................................................................................................529

7.2.3.3 Tipuri de Baze de Date Distribuite .......................................................................534 7.2.3.3.1 Criteriul de Omogenitate.................................................................................534 7.2.3.3.2 Criteriul de Autonomie....................................................................................534 7.2.3.3.3 Criteriul de Transparenta................................................................................535

7.2.3.4 Procesarea Cererilor în Baze de Date Distribuite ........................................535 7.2.3.4.1 Costurile în Procesarea Distribuita................................................................535 7.2.3.4.2 Procesarea Cererilor Distribuite prin Operatia de SEMIJOIN.................538 7.2.3.4.3 Descompunerea Cererilor si Actualizarilor .................................................540

7.2.3.5 Controlul Concurentei si al Securitatii .................................................................543 7.2.3.5.1 Generalitati ........................................................................................................543 7.2.3.5.2 Controlul Concurentei Distribuite cu Copie Distincta a Datelor .............544

7.2.3.5.2.1 Tehnica Statiei Primare ...........................................................................544 7.2.3.5.2.2 Tehnica Statiei Primare cu Statie de Salvare .......................................545 7.2.3.5.2.3 Tehnica Copiei Primare ...........................................................................545 7.2.3.5.2.4 Tehnica Alegerii Dinamice a Coordonatorului...................................545

7.2.3.5.3 Controlul Concurentei Distribuite prin Tehnica Votarii............................545 7.2.3.5.4 Securitatea Distribuita .....................................................................................546

7.3 Baze de Date Obiectuale...................................................................................................547 7.3.1 Generalitati ....................................................................................................................547 7.3.2 Independenta Obiectelor.............................................................................................550

7.3.2.1 Clase de Obiecte.......................................................................................................553 7.3.2.2 Metode si Mesaje .....................................................................................................557 7.3.2.3 Restrictii impuse Obiectelor...................................................................................558

7.3.3 Mostenirea între Obiecte.............................................................................................558 7.3.3.1 Mostenire Structurala ..............................................................................................560 7.3.3.2 Mostenirea Comportamentala ................................................................................563

7.3.3.2.1 Mostenire Simpla .............................................................................................565 7.3.3.2.2 Mostenire Multipla ...........................................................................................566

7.3.3.3 Meclase, Clase si Obiecte.......................................................................................568 7.3.4 Identitatea Obiectelor ..................................................................................................569 7.3.5 Comunicarea între Obiecte .........................................................................................575 7.3.6 Solutii de Implementare pentru BDO.......................................................................576

7.4 Consideratii Critice ...........................................................................................................577 ANEXE....................................................................................................................................................582 8 Scurt Istoric al Evolutiei SBD...................................................................................................582 9 Principalele Surse de Informare...............................................................................................583

PPOOSSTTFFAATTAA...........................................................................................................................................584 Lista Figurilor si Tabelelor.................................................................................................................585 Bibliografie.............................................................................................................................................592 Index de Termeni ..................................................................................................................................598

16 Importanta Sistemelor cu Baze de Date

PPAARRTTEEAA 11--aa

IINNTTRROODDUUCCEERREE

Sectiunile de Introducere subliniaza interesul, consolidat în timp, referitor la Sistemele cu Baze de Date si indirect atractia mentinuta vreme de mai bine de o jumatate de veac în jurul dezbaterilor având în centrul lor subiecte din domeniul SBD.

Sectiunile continute în Introducere puncteaza notele caracteristice ale acestei atractii îndelungate.

1.1 – Importanta Sistemelor cu Baze de Date – se face o

trecere în revista a domeniilor din Stiinta Calculatoarelor si din Informatica Aplicata care vizeaza SBD. Un accent special este pus pe domenii noi, de mare atractie în prezent (Warehousing, Data Mining), care au în fundal aceleasi Arhitecturi promovate de BD.

1.2 – Aportul Sistemelor cu Baze de Date – sunt

enumerate principalele avantaje care mentin SBD în centrul preocuparilor legate de Prelucrarea Automata a Datelor. Rezulta cu usurinta faptul ca avantajele amintite îsi vor mentine perenitatea în contextul cresterii interesului pentru Industrializarea Procesului de Elaborare de Programe si Aplicatii.

1.3 – Continutul Lucrarii – face oficiul consacrat de

Ghid al Cititorului în lucrarea gândita ca o Monografie de Concepte, promovate într-un domeniu deosebit de peren.

Importanta Sistemelor cu Baze de Date 17

1 Introducere 1.1 Importanta Sistemelor cu Baze de Date

Sistemele cu Baze de Date (SBD) apar ca produse de software individualizate în deceniul al saptelea al secolului al XX-lea. Un traseu al drumului parcurs de SBD este prezentat în Tab. 9.1 din Anexe. Viziunea noua pe care ele o aduc asupra prelucrarii automate a datelor polarizeaza atentia specialistilor, cercetatorilor si comerciantilor de-a lungul a mai bine de patru decenii. Afirmatia nu este exagerata întrucât, oricât de mare a fost în timp dorinta de înnoire prin introducerea de noi termeni (unii ramasi pentru multi la nivelul unor atragatoare “cuvinte claxon”) – Sisteme cu Reguli Inteligente, Baze de Cunostinte, Baze de Date Obiectuale, Explorarea Datelor (Data Mining), Gestiunea Specializata a Depozitelor (Warehousing) etc., acesti noi termeni nu au putut regasi taria principiilor fundamentate si confirmate prin nenumarate implementari de catre Sistemele cu Baze de Date si înca mai mult, s-au sprijinit puternic pe acestea, în masura în care nu au vrut sa ramâna doar captivante exercitii de testare a abilitatii discipolilor în prelucrarea informatiei.

Argumentatia poate fi completata cu o serie de întrebari retorice:

- Ce implementare reala de Reguli Inteligente e mai fecunda decât sistemele de Restrictii ale Bazelor de Date?

- Ce Sistem de Constrângeri nu devine mai puternic când e implementat în centrul nucleului de informatii ca si Constrângeri Intrinseci?

- Ce Dependente între informatii ramân straine Sistemelor Normalizate ale Bazelor de Date?

- Ce Explorare de Date (Data Mining) poate fi efectuata cu succes în afara unei Surse de Date construita pe o Baza de Date?

- Ce Warehousing nu e construit pe structura unei Baze de Date Specializate?

- Ce Cunostinte nu pot fi înmagazinate în Procedurile Stocate ale unei Baze de Date?

- Ce rafinament semantic de Agregare, Generalizare, Specificare, Taxonomie nu poate fi exprimat de Modelele de Date ce stau în spatele structurii logice ale unei Baze de Date?

Si exemplele pot continua sub semnul transformarii conceptelor teoretice bine fundamentate în instrumente practice puse la dispozitia unor categorii foarte diverse de utilizatori finali. Înseamna ca interesul Bazelor de Date mentinut si în prezent este motivat. Motivata apare si cresterea acestui interes prin încorporarea în sistemele ce Baze de Date a tuturor noilor cuceriri în domeniul tehnologiilor avansate de prelucrare a informatiei. Se poate afirma ca în timp ce multe limbaje, metode si tehnici, de mare senzatie în momentul aparitiei lor, au intrat în muzeu (evitam aici enumerari pentru a nu stârni gratuite adversitati), Sistemele cu Baze de Date au gasit mereu noi cai de dezvoltare odata cu dezvoltarea tehnologiei de calcul. In prezent orice sistem complex nu poate fi privit în afara unei puternice surse de date, structurata, consistenta, persistenta, care implica un sistem adecvat de gestiune. De data aceasta enumerarile nu ne mai pot aduce prejudicii:

18 Importanta Sistemelor cu Baze de Date

o Sistemele Informatice pentru Conducere – privite ca Sisteme cu Baze de Date

o Bazele de Date din Sistemele de Programare Logica

o Bazele de Date pentru Prelucrarea Textelor si Metatextelor

o Bazele de Date Grafice pentru Proiectarea Asisteta de Calculator (CAD)

o Bazele de Date din Sistemele Informatice Geografice (GIS)

o Bazele de Date Orientate Obiectual

o Bazele de Date Inteligente

Si în cazul acestei enumerari exemplele pot continua.

In privinta interesului pe care piata informatica l-a aratat Sistemelor cu Baze de Date este foarte semnificativ numarul deosebit de mare de Sisteme de Gestiune a Bazelor de Date (SGBD-uri) oferite de producatori în acest rastimp pe toate platformele Hardware si Software, precum si în toate tehnologiile de prelucrare, de la SGBD-uri pentru calculatoare individuale la tehnologii Client – Server si apoi la arhitecturi pe trei nivele (three tired architectures). SGBD-urile pot fi întâlnite între primele trei produse Software cerute, vândute si utilizate pe piata informatica. Rasfoiti la întâmplare orice ziar de oferte de servicii informatice si veti putea vedea ce convingator este si în prezent procentul de solicitari de specialisti în domeniul Bazelor de Date.

Ca o consecinta fireasca a acestui interes nu exista programa de învatamânt de specialitate, universitar sau preuniversitar, care sa nu contina disciplina de Baze de Date sub forma de curs, seminarii, lucrari practice si proiecte. Dar si pentru nespecialisti (chimisti, fizicieni, dar si biologi, filologi, juristi etc.) necesitatea crearii unor Colectii de Informatii bine structurate reprezinta o cerinta primordiala.

Potentialul înca neatins al SBD consta pe de o parte în deschiderea pe care ele o au de a construi cu ajutorul Modelelor de Date noi nivele de abstractizare în abordarea problemelor reale, carora însa le ofera si promisiunea, sustinuta de garantia necesara, ca vor putea fi implementate. In al doilea rând SBD sunt pregatite pentru a folosi performantele în continua crestere ale platformelor Hardware, ceea ce va spori interesul pentru Solutiile Normalizate de Structura , pentru Independenta reala a Nivelului Extern de definire a datelor, pentru implementarea Obiectelor Active direct în Nivelul Extern etc.

Nu putem încheia aceasta scurta pledoarie în favoarea SBD fara a sublinia contributia deosebita pe care Bazele de Date au adus-o în domeniul dezvoltarii si implementarii unor concepte deosebit de fructuoase cum ar fi Viziunea Structuralista, Independenta Structurala, Formele de Dependenta Structurala, Unificarea Date-Proceduri prin Materializarea Datelor, Orientarea pe Eveniment a Procedurilor, Conceptia Integratoare de Sistem.

Neglijarea concluziilor acumulate timp de aproape o jumatate de secol, poate duce la experimente foarte costisitoare, nu numai în sfera producatorilor, mai mici dar foarte numerosi, de Sisteme de Aplicatii, dar si în categoria marilor producatori de Produse Specializate, cum ar fi SGBD-urile. In acelasi sens, întelegerea aportului real pe care aceste sisteme de prelucrare l-au adus în domeniul procesarii volumelor mari de date, complex structurate, pot orienta cercetari si dezvoltari care sa combine cresterea Performantelor în Functionarea Echipamentelor cu ridicarea Nivelului Conceptual de Proiectare.

Aportul Sitemelor cu Baze de Date 19

1.2 Aportul Sistemelor cu Baze de Date

Dorim sa raspundem în aceasta sectiune, în mod succint, la întrebarea: “Care e motivul perenitatii Sistemelor cu Baze de Date?”, perenitate care a facut obiectul pledoariei anterioare.

Ne simtim obligati sa facem pentru început o precizare utila legata de acceptia termenului de Sistem cu Baza de Date (SBD) si a-l separa de cel de Sistem de Gestiune a Bazelor de Date (SGBD):

- SBD – Sistem de Aplicatii având în centru o Colectie Structurata de Date de volum mare a carui continut e gestionat în mod direct de un SGBD, dar care pe lânga acesta implica prezenta si a altor componente specializate cum ar fi Interfetele Utilizator, Retelele de Comunicatie, Instrumente de Ingineria Programarii Asistata de Calculator (Computer-Aided Software Engineering - CASE) etc., dar si Personalul (Utilizatori Finali sau Intermediari) însarcinat cu conceperea, proiectarea, întretinerea si dezvoltarea sistemului

- SGBD – Sistem specializat în Gestiunea nemijlocita a Colectiei de Date, activitate ce implica doua Functii Principale, cea de Definire si cea de Manipulare a Datelor (vezi functiile unui SGBD descrise în sectiunea 2.1.3)

In mod ciudat, într-o sectiune consacrata acestui subiect, vom evita enumerarea acelor avantaje practice aduse de Sistemele cu Baze de Date, ca instrumente de organizare si control a volumelor mari de informatii ce se cer prelucrate în orice domeniu, avantaje care vor fi prezentate în sectiunea 2.3, pentru a ne putea concentra asupra aportului la nivel conceptual, sustinut si consacrat în plan teoretic si confirmat în cenusiul de zi de zi al utilizarii acestor sisteme. Este vorba de concepte si principii lansate de SBD, a caror paternitate le este unanim recunoscuta si pe care se bazeaza longevitatea lor, dar care nu pot fi exprimate usor într-un „singur cuvânt”.

Observatie

Organizarea datelor într-o Baza de Date a adus, cu scurgerea timpului, în afara rezultatelor directe, si un câstig indirect, la început aproape neperceput. Aceasta activitate migaloasa de organizare a unui material imens de Fapte a format utilizatorului, indiferent de rolul jucat în Sistemul Informatic, o noua viziune asupra Informatiilor prelucrate. Întregul arsenal de tehnici si metode dezvoltat sub semnul Structuralismului si al Independentei maxime a fiecarei componente a sistemului a declansat resurse sinergetice în descoperirea de noi raporturi si conexiuni între obiectele extrase din realitatea privita ca sursa inepuizabila de informatii, din ce în ce mai complexe si mai rafinate. In acest continuu izvor de noi înfatisari ale aceleiasi prezente trebuie cautata si perenitatea preocuparilor, a interesului si a rezultatelor mereu înnoite obtinute în aproape o jumatate de veac de existenta a domeniului.

Ne-a aparut ca foarte sugestiv pentru ideea pe care o avansam, experimentul facut de o echipa de ingineri, biologi si logicieni, condusi de cercetatorul M. McKay.

S-a constatat ca inteligenta efectueaza permanent o filtrare a informatiei brute receptionate. Efectul e evident atât în zona constienta, cât si în cea subconstienta a activitatii cerebrale.

20 Aportul Sitemelor cu Baze de Date

Echipa de cercetatori a suprapus peste o miscare browniana doua retele reticulare de forme diferite obtinând imagini deosebite ale aceleiasi existente, imagini rezultate din filtrarea, stimulata de retea, dar operata de factorul uman (Fig. 1.2.1).

Filtrarile operate au fost induse de structurile particulare prin care a fost privita aceeasi realitate din care au fost separate detalii initial pierdute în multimea de evenimente dezordonate.

Fig. 1.2.1 Experimentul lui M. McKay

Organizarea informatiilor si datelor în modele si structuri permite, asemenea Retelelor de Filtrare, evidentierea unor Relatii esentiale existente în Colectiile cu care opereaza utilizatorul, dar care ramân pentru el pierdute în multitudinea de evenimente particulare, supuse hazardului, daca nu i se ofera Instrumente adecvate de introspectie, de scrutare a Planurilor Secunde, generatoare de Legi de Organizare.

Înarmate cu metode impuse de necesitatea rezolvarii cazurilor concrete, SBD nu s-au sfiit sa caute un raspuns la întrebari mari:

“Poate Independenta sa fie o cale spre Unitate?”

Intentionam sa aducem, pe tot parcursul acestei lucrari argumente în sprijinul Ideilor avansate. Personalizarea fiecarei componente a Sistemelor cu Baze de Date prin extinderea conceptului de Independenta va reprezenta punctul central din care vor lua nastere argumentele promise.

+

+

⇒

⇒

Miscare Browniana

Miscare Browniana

Retea Circulara

Miscare Circulara

Retea Reticulara

Miscare Centrifuga

Continutul Lucrarii 21

1.3 Continutul Lucrarii

Lucrarea contine prezentarea conceptelor principale dezvoltate în activitatea de promovare a Sistemelor cu Baze de Date. Sunt referite totodata conceptele matematice care au stat la baza notiunilor cu care opereaza Bazele de Date, în special cele referitoare la Modelul Relational. Aceasta cuprindere face expunerea mult mai accesibila si pentru specialistul care a întrerupt contactul cu studiul teoretic. Este recomandata si specialistului în domenii conexe, care poate gasi interesante solutii ce-i prilejuiesc comparatii cu cele din domeniul propriu de interes si totodata îl îndeamna sa vada unde anume conceptele prezentate, suficient de cuprinzatoare, l-ar putea ajuta.

Parcurgerea lucrarii este utila atât pentru studentul preocupat de studiul disciplinelor de programare a calculatoarelor, dar si pentru specialistii care activeaza în domeniul Sistemelor Informatice si care pot gasi în lucrare suficiente solutii pentru probleme practice.

Lucrarea abunda în ilustratii grafice bazate pe simboluri si formalisme care concentreaza expunerea prin evitarea descrierilor extinse, greu de urmarit si totodata ofera un suport bogat de exemple lamuritoare.

Se insista de asemenea pe frecvente clasificari, însotite de definitii de termeni si notiuni, strict necesare pentru a putea discuta despre un domeniu dinamic de probleme în care elaboratorii de produse comerciale, ba chiar si Colectivele de Lucru în domeniul Terminologiei, fac cu greu fata necesitatilor de unificare.

Lucrarea e structurata pe 7 Sectiuni principale, detaliate poate prea amanuntit pe Subsectiuni. S-a preferat aceasta detaliere pentru a oferi cititorului, înca de la lectura Cuprinsului, o orientare în continutul lucrarii si de asemenea posibilitatea regasirii rapide a unui anume subiect. Situatia e ceruta si de faptul ca acelasi subiect este reluat în sectiuni diferite, apelându-se la forme diferite de prezentare si unghiuri diferite de vedere. Prezentarile intuitive alterneaza cu reluari riguros definite, care vin sa fixeze materialul initial, oferind o baza si pentru specialistul interesat în cercetarea domeniului.

Aceste sectiuni de prezentare au ca axa de organizare Definitia Bazelor de Date la care s-a oprit autorul si care e prezentata înca în sectiunea 2.2.

Sunt urmarite asadar elementele de Descriere a Structurilor de Date privite în independenta lor fata de proceduri, alaturi de cele ale Limbajelor de Manipulare a Datelor în cele doua forme de realizare, prin Navigare si prin Specificare.

Pentru a completa cerinta impusa de prelucrarea Volumelor mari de Date sunt tratate în sectiunea 6 problemele ridicate de Prelucrarile Tranzactionale, Refacerea Bazelor de Date în caz de incident si Controlul Accesului la Date.

Acestor subiecte li se adauga o prezentare finala concentrata asupra viitorului de dezvoltarea a Sistemelor cu Baze de Date.

Materialul e completat cu prezentari de informare documentara reunite în câteva sectiuni de Anexa. O Lista de Figuri si Tabele, precum si un Index de Termeni asigura, alaturi de cuprinsul detaliat, instrumente de consultare punctuala rapida a întregului material continut în lucrare.

22 Continutul Lucrarii

In cele ce urmeaza se prezinta continutul celor sapte sectiuni principale ale lucrarii.

- Sectiunea 1 – Introducere

Se scoate în evidenta interesul unuia din cele mai raspândite domenii de preocupare în prelucrarea automata a datelor, cel al Sistemelor cu Baze de Date. Este subliniata importanta cunoasterii rezultatelor obtinute în aceasta sfera de preocupari, cât si a instrumentelor puse la dispozitia utilizatorilor.

- Sectiunea 2 – Sisteme cu Baze de Date

Sectiunea îsi propune sa prezinte personalitatea Sistemelor cu Baze de Date, ca mijloace specifice de abordare a problemelor de conceptie, proiectare si implementare a sistemelor cuprinzatoare de prelucrare a informatiilor si datelor.

Un istoric al aparitiei si consolidarii conceptelor, atât de specifice domeniului, e considerata necesara în aceasta parte a lucrarii. Se initiaza prezentarea conceptului considerat fundamental pentru Sistemele cu Baze de Date si anume Independenta Structurala. Multiplele forme de aparitie ale acestei proprietati definitorii a structurilor de tip Baza de Date, vor contribui în sectiunile ce urmeaza la nuantarea conceptului.

Pornind de la Independenta Structurala se sintetizeaza o definitie a Bazelor de Date, supuse de-a-lungul evolutiei lor la multe interpretari si chiar denaturari. Aceasta definitie este apoi urmarita pe tot parcursul lucrarii, prin acumularea de caracteristici si directii de preocupari, toate venind sa încarce cu continut formularea initiala foarte concentrata.

Enumerarea avantajelor principale pe care le aduce viziunea de Sistem cu Baza de Date, întaresc conturul domeniului. Ca exemplu, se prezinta succint Baza de Date care a deschis preocuparile legate de separarea datelor de proceduri si anume Prelucrarea Structurilor de tip Nomenclator.

- Sectiunea 3 – Concepte de Baza

Prezentarea Conceptelor de Baza este grupata în jurul notiunilor de Multimi si Relatii. Acestea vor contribui mai târziu la construirea Modelului Formal al Structurilor de Informatii si Date, ce va fi utilizat ca model de referinta pentru toti termenii introdusi ulterior. Am considerat foarte utila aceasta formalizare întrucât ea evita confuziile într-un domeniu ce sufera de o inflatie terminologica.

Aceeasi idee ne-a condus si în cazul prezentarii raporturilor Informatie – Data, a caror circumscriere într-o acceptiune adecvata demersului lucrarii, am considerat-o foarte utila pentru operarea cu termenii Structurilor de Informatii si Date. Antinomia Date – Proceduri vine sa adânceasca cutele de expresie ale produselor cu pretentii de Baze de Date. Este reluata ideea structuralista a Programarii Structurate, prezentata în paralel cu Structura atasata, dar separata a Datelor, la care însa se adauga viziunea Functionala introdusa de Virtualizarea Datelor, atât de proprie Bazelor de Date si care reapropie Procedurile de Date.

Toate conceptele prezentate sunt în continuare utilizate si particularizate în prezentarea Structurilor de Informatii si Date. Se începe cu prezentarea conceptelor de Organizare, Structura si Acces, cu insistenta asupra acceptiunilor în definirea nivelelor Logic – Fizic în reprezentarea datelor.

Continutul Lucrarii 23

Se consacra un capitol al acestei sectiuni pentru motivarea importantei recunoasterii Structurilor Fundamentale pentru analiza si sinteza structurilor complexe, dar si pentru compararea diferitelor Modele de Date ale SGBD-urilor, pentru evaluarea performantelor si a perspectivelor lor de evolutie. Problema Structurilor Fundamentale e reluata în lucrare ori de câte ori se face o trecere în revista a constructorilor de structuri, punându-se accentul cuvenit asupra faptului ca orice Model de Date este atunci stapânit când se cunosc formele de implementare a cestor tipuri de structuri de date.

Metodele de reprezentare, în special cele ce apeleaza la conciziunea grafica, gasesc un spatiu suficient în capitolul care urmeaza si creeaza o baza pentru întelegerea usoara a exemplelor redate în lucrare. Fara o parcurgere atenta a conventiilor propuse, conventii în marea majoritate întâlnite în literatura de specialitate (cu exceptia Arborelui de Structura a Datelor) interpretarea exemplelor foarte numeroase din lucrare va întâmpina dificultati.

Aplicarea conceptelor cu care s-a început sectiunea continua cu transpunerea lor în slujba disciplinarii gândirii celor care opereaza cu structurile în spatiul problemelor reale. Rafinarile necesare care se cer aduse prezentarilor Structurilor Fundamentale încheie aceasta sectiune. Viziuni ale unor producatori de notorietate în domeniul construirii Modelelor de Date sunt aduse la cunostinta prin intermediul produselor ORACLE si ERWIN.

- Sectiunea 4 – Modele de Informatii si Date

Sectiune vasta, întrucât îsi propune sa sustina ideea ca viitorul construirii Sistemelor Informatice îl reprezinta metodele conceptuale, reprezentative, care dau prioritate abordarii de tip Top - Down (realizare de Sus în Jos), pe care nu uita sa o combine cu dezvoltarile analitice, cumulative, de tip Bottom - Up (realizare de Jos în Sus). Procesele de Engineering (Generare automata Proiect din Model) si Reengineering (Completare Model cu detalii din Proiect), atât de familiare deja Bazelor de Date, stau chezasie pentru aplicarea acestei metode de lucru în mod industrial.

In aceasta tratare Procedurile urmeaza sa migreze în Modelul de Informatii sau Date, care va deveni instrumentul esential pentru aducerea viziunii asupra problemei reale într-un singur punct, cel de reprezentare globala a realitatii de modelat. Când s-a reusit aceasta concentrare, reprezentarea câstiga o deosebita putere generativa pentru întreg proiectul ce urmeaza sa prinda viata. Vor germina în mod natural Structuri de Date, Restrictii impuse, Proceduri asociate, Reguli de Comportament, Interfete de colaborare cu Utilizatorul, pe scurt tot ce urmeaza a se naste în sistem chiar fara a fi prevazute anume în Specificatiile Initiale.

Acest deziderat a determinat regruparea în aceasta sectiune atât a problemelor conceptuale, desfasurate în Spatiul Informatiilor, cât si a celor de proiectare, dezvoltate în Spatiul Datelor. Sunt reunite de asemenea descrierile Structurilor de Date (proprii Limbajelor de Descriere a Datelor – LDD) împreuna cu descrierile de Proceduri asociate (proprii Limbajelor de Manipulare a Datelor – LMD).

Sectiunea e împartita în doua parti consacrate Modelelor de Informatii si Modelelor de Date. Se regasesc aici exemplificate cele doua acceptiuni date anterior Informatiei ca purtatoare a încarcaturii semantice conferite de utilizator Spatiului Modelat (Spatiul

24 Continutul Lucrarii

Informatiilor) si Datei ca forma de reprezentare a Modelului în consonanta cu instrumentul de prelucrare folosit (Sistemul de Calcul).

Modelele de Informatii îsi încep prezentarea cu primul model de nivel înalt (fundamenat de colectivul profesorului Abrial), Modelul ECV (Entitate, Caracteristica, Valoare), continua cu Modelul Obiectelor Abstracte (fundamentat de lucrarile de cercetare ale sotilor Smith) si se încheie cu un model propus de autor, Modelul Conceptual.

Primul model contine definirea notiunilor de baza cu care continua sa opereze toate celelalte modele dezvoltate: Entitate, Caracteristica, Valoare, Ansamblu de Entitati, Baza de Date Logica, Baza de Date Fizica. Este prezentat aici si un model formal de descriere a unui Spatiu de Informatii prin stabilirea corespondentelor între termenii modelului ECV si notiunile din Teoria Multimilor.

Al doilea model introduce notiunile generale de Abstractizare, Generalizare, Agregare, Obiecte Abstracte, Operatii Abstracte, Integritate a Obiectelor Individuale etc. Proiectia lor într-o reprezentare relationala asigura legatura cu nota generala de aplicabilitate a tuturor conceptelor prezentate.

In ultimul model se încerca o generalizare a conceptelor anterioare într-o solutie noua, care alege ca si constructor unic Conceptul în forma lui de prezentare în Logica. Sunt discutate problemele de Identificare si de Derivare a Conceptelor.

Modelele de Date sunt tratate într-o sectiune care reuneste teme foarte diverse, de la Tipurile de SGBD-uri, la Componentele diverselor Nivele de Abstractizare, de la Tipurile de Structuri de Date la modurile de Procesare a Datelor. Aceasta sectiune formeaza de altfel si centrul lucrarii prin problemele pe care le dezbate si prin solutiile pe care le ofera.

Aici este cuprinsa si descrierea Modelului Relational, pe care prezenta lucrare îl vede ca o solutie de neînlocuit în reprezentarea structurilor de date si în viitor, cel putin la un nivel intern, apropiat de calculator si netransparent pentru utilizator. Utilizatorul va pastra astfel posibilitatea alegerii unor viziuni agreate de reprezentare, a caror consistenta conceptuala va fi garantata de posibilitatea proiectiei lor în Modelul Intern Relational.

Sectiunea debuteaza cu încadrarea Modelelor de Date utilizate de SGBD-uri în contextul general de modelare a structurilor. Modelele Stricte de Date sunt apoi prezentate în formele lor istorice de evolutie: Ierarhic, Retea si Relational, încercându-se o marcare a acumularilor realizate pe linia descrierii structurale.

Întrucât atentia ramâne concentrata pe Modelul Relational, dezvoltarea facilitatilor oferite de el au ramas grupate în subsectiunile adiacente, ceea ce a încarcat indentarea capitolelor. S-a urmarit ca prezentarea sa fie organizata pe cele trei componente ale unui Model Strict de Date: Structura, Restrictii, Operatii.

Problemei Identificarii, Accesului si Ordonarii îi sunt consacrate dezbateri interesante în partea de descriere a structurii.

Alaturi de acestea o dezvoltare proprie a Tipurilor de Relatii în Structurile Relationale vin sa pregateasca terenul unor ample exemplificari de implementare a Proceselor de Abstractizare în Structuri Relationale precum si de aplicare a lor în practica de proiectare a Structurilor Relationale. O legatura fertila este astfel stabilita între

Continutul Lucrarii 25

conceptele proiectarii în Modelul Obiectelor Abstracte si formele de implementare a acestor concepte în proiectarea Structurilor Relationale.

Relatiile de tip Entitate, Legatura si Mixte sunt definite si utilizate apoi în construirea Structurilor Elementare a caror însusire va crea competenta viitorului proiectant de Structuri Relationale. Se creeaza acum baza pentru metodele de proiectare dezvoltate în sectiunea 5.1.4, care vor asigura un înalt grad de Normalizare, fara apelul la algoritmii consacrati acestor activitati de Optimizare a Structurilor.

Partea de descriere a Restrictiilor aduce detalii de realizare pentru clasificarile operate în sectiunea 3.4.5. Sunt trecute în revista diferitele forme de încorporare a Conditiilor de Validare a Structurilor în Modelul de Date prin intermediul Constrângerilor, Triggerilor si Procedurilor Stocate.

Incursiunea în Limbajele de Manipulare a Datelor (Algebra Relationala - AR, Structure Query Language - SQL si Query By Example - QBE, preced încadrarea acestor forme de procesare în tipurile de limbaje, de Navigare, Specificare Operatoriala si Specificare Predicativa.

Nivelul extern este analizat prin prisma Independentei pe care acesta o prezinta fata de operatiile care se efectueaza asupra structurii unei Baze de Date.

Un set bogat de exemple de implementare a Structurilor Relationale de Baza încheie sectiunea, cu incursiuni în aplicarea Generalizarii si Agregarii, a construirii Structurilor de tip 1 – n si m – n, a descrierii Structurilor Ierarhice, a implementarii Datelor de tip Multime etc.

- Sectiunea 5 – Optimizarea Modelelor de Date

O sectiune aparte este rezervata problemei optimizarii Modelelor de Date. Divizata în doua parti, sectiunea dezbate în prima parte conceptul de Normalizare a structurilor de Date, rezervând problema Optimizarii Cererilor pentru cea de a doua. Se observa si aici tratarea alternativa a Datelor si Procedurilor în ceea ce aduce particular fiecare element în problema optimizarii.

O prezentare formalizata a Modelului Relational creeaza cadrul necesar dezbaterilor centrate pe problema Dependentelor Functionale în structurile relationale. Noutatea dezbaterii o constituie doua aspecte aparte asupra carora este concentrata atentia.

Primul aspect este legat de încadrarea normalizarii structurilor în problematica mai larga a asigurarii Independentei Structurale, de data aceasta transferata la nivelul Atributelor Desciptoare ale Relatiilor.

Al doilea aspect aduce în discutie alternativele conceptuale oferite pentru proiectarea structurilor consistente, vizavi de metodele pur analitice de optimizare „post festum” a unor structuri vicioase. Este aici interesant de urmarit demersul provocat de întrebarea retorica: ”De ce sa tratezi când poti simplu sa previi?”. Numeroase exemple ofera solutii practice utile.

- Sectiunea 6 – Securitatea Bazelor de Date

Aceasta sectiune vine sa raspunda ultimei parti a definitiei Bazei de Date avansata înca în sectiunea 2. Prelucrarea Volumelor Mari aduc în atentie problema Securizarii Datelor prelucrate.

26 Continutul Lucrarii

In capitole dedicate sunt prezentate cele trei probleme importante legate de acest aspect. Prima tratare se refera la asigurarea Controlului Accesului la Date prin metodele clasice de interzicere a accesului neautorizat.

Al doilea subiect concentreaza atentia asupra Prelucrarilor Tranzactionale în forma lor de implementare a restrictiilor ACID (Atomicitate, Consistenta, Izolare, Durabilitate). Si în acest caz nu se pierde ocazia de a încadra solutiile de rezolvare a Starilor Conflictuale prin urmarirea asigurarii maximei Independente Procedurale a Tranzactiilor.

Problema Restaurarii Bazelor de Date în caz de incident este în final tratata în strânsa legatura cu prelucrarea tranzactionala.

- Sectiunea 7 – Baze de Date Evoluate

In cadrul facilitatilor ce urmeaza a fi transferate catre Bazele de Date, cum ar fi cele de Deducere de Fapte, Distribuire de Resurse, Creare de Viziune Obiectuala sunt gasite noi prilejuri de a privi sub alte aspecte problema Independentei Structurale.

In cazul Bazelor de date Deductive problema Independentei reiese ca forma de Materializare a Datelor prin functii de Calcul Logic, ceea ce readuce în discutie opozitia Redondanta – Inconsistenta. Se reitereaza importanta procesului deductiv nu atât sub aspectul evitarii redondantei, cât sub aspectul asigurarii consistentei, prin evitarea memorarii datelor dependente ca date ce pot fi aduse în contradictie prin actualizare independenta.

In cazul Bazelor de Date Distribuite atentia e îndreptata catre problema Independentei Surselor de Date. Încalcarea unicitatii datelor din motive de performanta, prin acceptarea replicarii, determina construirea unor proceduri de sistem care sa transfere controlul consistentei Bazelor de Date Distribuite din Structural în Procedural.

In cazul Bazelor de Date Obiectuale problema Independentei e tratata mai amplu. In primul rând prin sublinirea structurii obiectuale ca forma de asigurare maxima a Independentei elementelor sale, fie ele Date sau Proceduri.

In al doilea rând se atrage atentia asupra pericolului pe care îl reprezinta implementarea la nivel intern a structurilor obiectuale nenormalizate, prin eliminarea Modelului Relational.

Acestui subiect îi este consacrat si capitolul de consideratii critice. Se acrediteaza din nou ideea ca Viziunea Obiectuala, adaptata în general pozitiei Utilizatorului, nu trebuie sa constituie o solutie pentru construirea Nivelului Conceptual, ci o alternativa a Nivelului Extern al unei Baze de Date, capabil în aceasta forma sa implementeze viziuni multiple asupra aceleiasi Structuri de Date. Si în acest caz sursa pentru Structura de Date a Obiectelor se recomanda a fi alcatuita din Vederile consacrate Structurilor de Baza de Date, împreuna cu tot arsenalul de Proceduri Stocate aferent.

Consideram ca, în sprijinul ideilor avansate, vine întreaga evolutie prezenta a interfetelor create pentru a avea acces la Sursele de Date din orice mediu (Client Specializat – Thick Client, Client Banal – Thin Client, Interfete Vocale, Interfete Mass Media etc.) utilizând Tehnologia Obiectelor Active.

Continutul Lucrarii 27

PPAARRTTEEAA aa 22--aa

SSIISSTTEEMMEE ccuu BBAAZZEE ddee DDAATTEE

Legate într-un fel de Partea Introductiva, sectiunile prezentei Parti initiaza cititorul neavizat în problematica Sistemelor cu Baze de Date (SBD).

Sectiunile incluse pornesc de la o fundamentare istorica a preocuparilor în domeniu, definesc Conceptul de Baza de Date, consolidându-l cu exemple.

2.1 – Aparitia Conceptului de Baza de Date – o

incursiune istorica în Prelucrarea Automata a Datelor subliniaza modul natural de aparitie a preocuparilor legate de cresterea performantelor calitative si cantitative în Prelucrarea Informatiilor si Datelor.

2.2 – Avantajele Utilizarii Bazelor de Date – sunt

concretizate o suma de avantaje, în prezent indispensabile în conceperea si utilizarea Sistemelor Complexe, pe care le ofera abordarea acestora ca Sisteme cu Baze de Date.

2.3 – Exemple de Baze de Date – se prezinta Structura

primului Sis tem cu Baze de Date, a carui actualitate se mentine si în prezent prin modul de Proiectare si prin Avantajele finale oferite..

28 Nivele de Abstractizare într-un SBD

2 Sisteme cu Baze de Date

Ca orice concept care si-a câstigat o anume popularitate, si cel al Bazelor de Date nu este unul de trecut cu vederea din aceasta privinta, cel cu care ne vom ocupa în continuare nu a scapat de alterare pâna la chiar golirea de continut. Desi credem ca orice sechestrare a conceptului de BD de catre o singura categorie de utilizatori, fie ea chiar reprezentata de cercetatori în domeniul dependentelor operatoriale abstracte, este neavenita, dorim sa limitam acceptiunea termenului prin circumscrierea domeniului care a putut sa reziste atâta timp în lumea diversa a teoreticienilor, comerciantilor si utilizatorilor. 2.1 Aparitia Conceptului de Baza de Date

In paginile care urmeaza vom încerca sa parcurgem pe scurt un istoric de aparitie a necesitatii de abordare a prelucrarii datelor de volum din ce în ce mai mare, care a determinat fundamentarea acelor concepte care au stat la radacina Sistemelor cu Baze de Date. Exista desigur destule voci care sustin ca nu e nevoie sa acordam o asa atentie trecutului si sa ne concentram mai mult asupra cerintelor prezentului. Raspunsul nostru consta în faptul ca prezenta lucrare îsi propune sa se ocupe mai mult de viitor si de aceea rememorarea drumului parcurs de SBD, deloc neglijabil în timp, este o chezasie a presupunerilor corecte de evolutie în viitor a acestor sisteme. Nu putem însa omite nici aportul pe care întelegerea corecta a noutatii conceptelor promovate de SBD o are la utilizarea lor în prezent. Ne referim în special la recuperarea importantei pe care Sursele de Date, construite solid, o au în prezent si o vor avea în viitor pe tarâmul prelucrarii de informatii. 2.1.1 Nivele de Abstractizare într-un SBD

Aparitia Bazelor de Date a fost o urmare fireasca a dezvoltarii tehnologiilor în procesul de prelucrare a datelor. Aceste transformari pot fi urmarite sub doua aspecte:

o sub aspect cantitativ – ca o crestere a numarului datelor ce urmau a fi prelucrate automat; colectii de date incluzând milioane de date care se cereau memorate, actualizate, regasite, calculate si transmise cu ajutorul dispozitivelor automate de calcul (calculatoare si retele de interconectare)

o sub aspect calitativ – ca o crestere a complexitatii structurii datelor prelucrate atât în ceea ce privea relatiile descrise între date, cât si a distribuirii datelor, puternic legate prin intercorelare, pe diferitele medii de stocare

Trei etape pot fi semnalate în procesul de evolutie prezentat anterior:

o Prima etapa – Separarea Numelor de Valorile datelor

o A doua etapa – Cresterea Complexitatii datelor prelucrate

o A treia etapa - Separarea Datelor de Proceduri

Separarea Numelor de Valorile datelor determina aparitia a doua nivele de descriere a acestora:

o Un nivel Concret de descriere – descriere cu ajutorul Valorilor numit nivel Fizic de descriere (descriere de Instanta)

Nivele de Abstractizare într-un SBD 29

o Un nivel Abstract de descriere – descriere cu ajutorul Numelor numit nivel Logic de descriere (descriere de Notiune)

Prezenta nivelului abstract de descriere a datelor va facilita:

o Gruparea (separarea) descrierii datelor într-o sectiune specializata numita Dictionarul datelor

o Definirea sistematica a Tipurilor de Date (prin generalizarea Datelor de acelasi Tip)

o Asocierea Restrictiilor impuse la Datele de acelasi Tip

o Asocierea Operatiilor adecvate diverselor Tipuri de Date

Toate aceste noutati aduse descrierii structurilor de date reprezinta primul pas important în definirea Bazelor de Date, ca metode de prelucrare care centreaza atentia asupra obiectului prelucrarii - Datele.

In ceea ce priveste cresterea complexitatii structurii datelor ea poate fi analizata în directa legatura cu raportul între cele doua componente ale procesului de prelucrare automata a datelor:

§ Date ce descriu Starile (Structura)

§ Calcule asupra datelor, ce descriu Operatiile (Transformarile)

Trei perioade distincte pot fi sesizate în evolutia conceptiei de prelucrare a datelor cu ajutorul sistemelor de calcul:

o Prima perioada – descrisa prin Date Simple si Calcule Complexe

Datele simple sunt considerate date de volum mic, nestructurate, prezentate sub forma de scalari sau multimi simple si statice de scalari (vectori, matrici) utilizate pentru calcule stiintifice reprezentate de proceduri si functii care implementeaza instrumente matematice de calcul complex (calcule numerice, statistice, vectoriale, matriciale etc.). Acestea sunt reunite în biblioteci specializate de proceduri si functii ce pot fi cu usurinta apelate din diverse programe orientate spre rezolvarea unor probleme cu caracter particular. Cel mai reprezentativ limbaj de prelucrare utilizat în aceasta perioada este limbajul FORTRAN.

o A doua perioada - descrisa prin Date Complexe si Calcule Simple

Datele complexe sunt constituite din date de volum mare, structurate prin gruparea lor în înregistrari de lungimi fixe sau variabile si multimi de înregistrari corelate între ele. Aceste date sunt utilizate în aceasta etapa preponderent pentru calcule economice simple (adunari si scaderi). Este descoperita acum importanta regasirii datelor, prin localizarea lor în ansamblul structurat. Cel mai reprezentativ limbaj de prelucrare utilizat în aceasta perioada este limbajul COBOL.

o A treia perioada - descrisa prin Date Complexe si Calcule Complexe

In aceasta perioada datelor complexe li se adauga functii complexe grupate în biblioteci extinse. Functiile sunt specializate pentru prelucrarea diferitelor tipuri si

30 Nivele de Abstractizare într-un SBD

structuri de date, de la datele de tip numeric, caracter sau sir de caractere, pâna la date de tip înregistrare, tablouri de înregistrari, liste, arbori, stive, cozi, indecsi etc.

Atunci când volumul de date de prelucrate este redus, structurile prelucrate pot fi încarcate în memoria interna si transferul din si în memoria externa se efectueaza printr-o citire initiala, respectiv o scriere finala. Cel mai reprezentativ limbaj de prelucrare utilizat în acest caz este limbajul PASCAL.

Prin cresterea volumului de date, structurile de date trebuiesc retinute în memoria externa si comunicarea cu memoria interna se efectueaza exclusiv prin operatii de regasire a fragmentelor de structura care se cer consultate sau actualizate. Cele mai reprezentative limbaje de prelucrare care îndeplinesc aceste cerinte sunt Limbajele de Descriere (LDD) si de Manipulare (LMD) a Datelor din Sistemele de Gestiune a Bazelor de Date (SGBD).

Asa dupa cum s-a mentionat anterior, a treia etapa în evolutia procesului de prelucrare automata aduce ca noutate necesitatea Separarii Datelor de Proceduri. Acest deziderat reprezinta pasul cel mai important pentru conturarea specificului viitoarelor Sisteme cu Baze de Date.

Complexitatea sporita a datelor prelucrate ridica pretentii noi în actualizarea permanenta a structurilor de date, atât în definirea initiala a acestora prin actualizarea nivelului logic de descriere a datelor, cât si în extinderea, modificarea sau eliminarea instantelor concrete reprezentate prin valorile memorate în nivelul fizic de descriere a datelor. Toate aceste modificari frecvente solicitau actualizarea simultana a procedurilor asociate structurilor de date, în cazul în care aceste proceduri includeau descrierea datelor. Pentru solutionarea acestei dificultati a fost necesara în prima etapa introducerea unei fragmentari în tratarea ansamblului complex de colectii de date, prin introducerea conceptului de Nivele de Abstractizare în reprezentarea structurii datelor într-o Baza de Date. J. D. Ullman descrie în [ULMA80] trei Nivele de Abstractizare într-un Sistem cu Baza de Date (SBD). Acestea sunt sugestiv reprezentate în Fig. 2.1.1.

La nivelul interior de abstractizare, denumit si Nivel Intern, este reprezentata Baza de Date Fizica, care e stocata întotdeauna pe suportul extern de memorare, datorita volumului de date ce necesita un spatiu mare de depozitare. Ea consta din:

o Setul de Valori de Date care sunt memorate pe suportul extern conform conventiilor de reprezentare adoptate de Sistemul de Gestiune al Bazei de Date, în acord cu sistemul de operare pe care acesta e implementat. Aceste conventii includ metodele de organizare si acces la date, conventiile de codificare si compresie a datelor etc.

o Setul Informatiilor de Control asociate informatiilor utile stocate în Baza de Date. Aceste informatii suplimentare sunt determinate de tehnicile adoptate pentru gestiunea suportului fizic

In centrul reprezentarii se regaseste Nivelul Conceptual în forma Bazei de Date Logice, care grupeaza elementele ce descriu Datele cu ajutorul Numelor si anume:

o Modelul de Descriere a Datelor care poate fi:

§ Ierarhic

Nivele de Abstractizare într-un SBD 31

§ Retea

§ Relational

o Setul de Caracteristici de descriere:

§ Nume

§ Tipuri

§ Limite de Valori

o Limbajul de Descriere a Datelor ( LDD)

Baza de Date Logica contine Schema de Descriere a Datelor.

Cel de al treilea nivel de abstractizare este reprezentat de Nivelul Extern. Acest nivel este construit cu ajutorul a doua concepte: Vederea si Data Virtuala. Acest nivel va contine:

o O multime de Vederi incluzând parti din datele descrise în Baza de Date Logica si memorate în Baza de Date Fizica

o O multime de Date Virtuale care extind informatiile ce pot fi regasite în Baza de Date ca date memorate. Datele efectiv memorate în Baza de Date (cea Logica si cea Fizica) sunt denumite Date Reale. Datele Virtuale sunt date ce pot fi obtinute pe baza Datelor Reale prin aplicarea unei Functii de Calcul de forma:

VD = f ( RD )

Procesul prin care, pornind de la un set de Date Reale tratate ca Argumente, se determina o Valoare de Data Virtuala (se instantiaza o Data Virtuala) poarta numele de Materializarea Datelor Se remarca faptul ca asupra naturii Functiei de Calcul nu este impusa nici-o restrictie. Ea poate implica un Calcul Aritmetic, Logic, pe Siruri de Caractere etc.

Exemplu:

Intr-o Baza de Date PERSOANE:

o Data Nasterii e memorata într-o Data Reala cu numele DN

o Daca Vârsta, VR, e tratata ca o Data Virtuala, ea nu va fi memorata în Baza de Date ca valoare reala, ci va apare doar într-o Vedere la nivelul extern, fiind definita printr-o Expresie de Calcul redactata ca o functie:

VR = f (DN) = DC – DN

unde:

§ DC este Data Curenta furnizata de sistem

§ DN este Data Nasterii memorata în Baza de Date. Se observa usor ca ori de câte ori o Data poate fi exprimata ca fiind dependenta de alte date memorate în sistem, consistenta ansamblului de date nu poate fi mentinuta decât prin recalcularea automata a valorii dependente în functie de valorile momentane ale valorilor independente (argumentele functiei de calcul). În exemplul nostru Vârsta (variabila dependenta) va putea fi exprimata în orice moment cu precizia dorita, prin referirea la valoarea Datei curente (argument) care se modifica permanent.

32 Nivele de Abstractizare într-un SBD

Fig. 2.1.1 Nivele de Abstractizare într-o Baza de Date

La nivel Extern, prin intermediul conceptului de Vedere, poate fi schimbat si Modelul de reprezentare a Structurii de Date. Spre exemplu, la nivel Conceptual se poate utiliza o descriere în termenii unui model Relational de date, în timp ce la nivel Extern poate fi utilizat un model Ierarhic, Retea sau Obiectual (si viceversa).

Viziunea Sistemelor cu Baze de Date ca o succesiune de Nivele de Abstractizare conduce la recunoasterea a doua Interfete de legatura între nivele:

o Interfata Fizica – care asigura Imunitatea Fizica a Datelor definita de stabilitatea Nivelului Conceptual la modificari operate în Nivelul Fizic

BAZA de DATE

LOGICA

BAZA de DATE

FIZICA

vedere 1

vedere 2

vedere 3

vedere n

U1

U2

U3

U6

U4

U7

U5

Un

nivel EXTERN

nivel CONCEPTUAL

(LOGIC)

nivel INTERN (FIZIC)

INTERFATA LOGICA

INTERFATA FIZICA

Nivele de Abstractizare într-un SBD 33

o Interfata Logica - care asigura Imunitatea Logica a Datelor definita de stabilitatea Nivelului Extern la modificari operate în Nivelul Logic

Ambele Interfete permit, prin intermediul protectiilor pe care le asigura, construirea diferitelor nivele de Independenta în structurarea datelor.

In final, deoarece Vederile definite în nivelul Extern vor fi încorporate în Procedurile diverselor aplicatii, nivelele de abstractizare prezentate vor asigura Imunitatea Procedurilor, definita de stabilitatea Procedurilor la modificarile operate în cele doua nivele de descriere a Structurii Datelor (cel Logic si cel Fizic). Aceasta forma finala de imunitate poarta numele de Independenta a Datelor fata de Proceduri.

Când trebuie sa se verifice fara întârziere daca un produs software îndeplineste conditiile unui Sistem de Gestiune a Bazelor de Date (SGBD), e suficient sa se verifice gradul în care acel produs asigura Independenta între Date si Proceduri. 2.1.2 Functiile unui SGBD

Toate Sistemele de Gestiune a Bazelor de Date (SGBD) asigura trei functii principale:

o Functia de Definire a Datelor – care asigura declararea elementelor care compun Structura de Date precum si a Relatiilor existente între ele

o Functia de Manipulare a Datelor – care regrupeaza Operatiile de Intrare / Iesire, care asigura Adaugarea, Stergerea si Modificarea Valorilor Datelor memorate în Baza de Date

o Functia de Utilizare a Datelor – care permite construirea Sistemului de Aplicatii ce prelucreaza datele continute în Baza de Date; aceasta functie e asigurata de Mediul de Programare asociat Nivelului de Acces la Baza de Date

Exista si alte functii pe care un SGBD trebuie sa le asigure pentru gestionarea Colectiilor Mari de Date:

o Functia de Control a Accesului la Date – care include metodele de acordare si revocare Drepturilor de Acces la Date (câmpuri, tabele, fisiere, domenii, operatii de actualizare)

o Functia de asigurare a Integritatii Datelor – care ofera posibilitatea de declarare a Restrictiilor impuse structurii de date (Unicitate, Referire, Compatibilitate etc.)

o Functia de asigurare a Accesului Concurent la Date – care grupeaza operatiile de Blocare / Deblocare a accesului simultan la date

o Functia de Salvare / Restaurare a Datelor – ce asigura crearea si folosirea Copiilor de Securitate în caz de incidente

o Functia de Acces Tranzactional la Date – ce ofera facilitatea de grupare a operatiilor de actualizare în Unitati Atomice de Executie (Tranzactii), care se pot efectua doar integral sau refuza integral

Mediile de Programare care implementeaza Accesul la Baza de Date aduc si ele noi Functii specializate, care sunt incluse tot în Functia de Utilizare a Datelor.

34 Raportul Date - Proceduri

2.1.3 Raportul Date - Proceduri

Datele si Procedurile reprezinta Elementele de Baza ale oricarei prelucrari de date. Aspectele ridicate de aceasta constatare sunt pe larg explicate în lucrarea de referinta [WIRT76].

Datele reprezinta în procesul de prelucrare elementul static, descriind la un moment dat Starea în care se afla sistemul de prelucrare, în timp ce Procedurile reprezinta elementul dinamic, ce defineste Transformarea între doua stari succesive. In timp ce datele descriu Structura Sistemului , procedurile descriu Secventele de Operatii care modifica în timp starea sistemului.

Cu cât aceste elemente sunt mai precis delimitate, cu atât sistemul este mai:

o Adaptabil - întelegând prin aceasta capacitatea sa de a suporta modificari intervenite în definirea initiala a cerintelor si totodata deschiderea la dezvoltari ulterioare

o Controlabil - prin posibilitatile oferite pentru verificarea modului sau de functionare în vederea corectarii sale, precum si a îmbunatatirii performantelor

Evolutia procesarii datelor în prelucrarea automata este strâns legata de evolutia raporturilor existente între aceste doua elemente fundamentale.

Trei etape pot fi delimitate în evolutia raportului între Date si Proceduri în cadrul prelucrarii automate a datelor:

o Prima etapa - este caracterizata de importanta predominanta acordata Procedurilor, prin descoperirea aportului calculului automat la urgentarea procesarii. Procedurile înghit datele în corpul lor îmbracând forma unei Cutii Negre, ce are precizate spre exterior doar Datele de Intrare si Datele de Iesire ca rezultate ale prelucrarii

o A doua etapa - este caracterizata de revolutia provocata de Eliberarea Datelor de sub dominanta Procedurilor. Prin câstigarea Independentei lor fata de proceduri, datele încep sa fie personalizate din ce în ce mai mult prin descoperirea importantei de definire a Tipurilor de Data, precum si a Conditiilor pe care trebuie sa le respecte fiecare Tip si Instantiere de Tip (Limite de Valori, Restrictii de Identitate si de Referire, Restrictii de Dependenta Functionala, Restrictii de Consistenta, Restrictii de Validare a Corectitudinii si Compatibilitatii).

Datele sunt deja capabile sa se organizeze în Structuri din ce în ce mai complexe, care contin înca înainte de procesare o încarcatura semantica din ce în ce mai mare. Ele nu mai deservesc trecator un singur proces de prelucrare, ci constituie Rezervorul de Informatii al întregului sistem, pe toata durata lui de viata. Fiind independente, datele pot fi preocupate în mod sporit de dezvoltarea si rafinarea modului de a-si Descrie Structura .

Independenta dobândita fata de proceduri se manifesta prin Separarea Numelor de Valorile Datelor punându-se astfel bazele aparitiei Nivelelor de descriere Logica (prin Nume) si Fizica (prin Valori). Datele se vor refugia în Nivelele

Raportul Date – Proceduri 35

proprii de definire (Conceptual si Intern). De asemenea starea de autonomie ofera datelor posibilitatea de a fi modificate cu tot mai multa usurinta, chiar si în timpul functionarii sistemului, prin compensatia pe care o ofera procedurilor de a deveni imune la modificarile operate în cercul datelor.

Consolidate într-un mediu cu reguli proprii de organizare, constiente de aportul lor foarte precis definit în prelucrarea informatiilor, datele pornesc sa exercite o atractie irezistibila asupra procedurilor în privinta preluarii conceptelor de structuralism. Sunt stimulate organizarile pe Module, care transpun în cadrul fragmentelor de proceduri principiile de independenta reciproca, si odata cu acestea cresc adaptabilitatea si controlabilitatea procedurilor complexe. Acum Procedurile încep sa înteleaga ca separându-se tot mai mult fata de datele pe care le prelucreaza îsi pot multiplica utilitatea prin autonomia care le-o confera Reentranta.

In acest sens însa descoperirea cea mai mare care se produce este cea de a putea asimila cu o Data Potentiala orice Procedura, care este privita functional, ca o expresie de dependenta între datele de intrare si de iesire. Acest concept este repede asimilat de Date, care adopta noii constructori de structuri, le boteaza Date Virtuale, si le acorda îndata misiuni precise de a reduce Redondanta si a spori Consistenta informatiilor memorate cu ajutorul Datelor Reale (datele efectiv înregistrate pe suportul fizic).

Se pun astfel bazele proceselor de Materializare a Datelor, prin definirea în cadrul structurilor a unor noi tipuri de date (Datele Virtuale), care se instantiaza doar în momentul apelului, prin executia procedurilor de calcul atasate. Cu aceasta noua achizitie se construieste un nou nivel de interfata între Utilizator si Structurile de Date, si anume Nivelul Extern , care adaugat la nivelele anterioare, cel Conceptual si cel Intern , definitiveaza independenta initiata în cadrul modelelor structurate de date ( vezi Fig. 2.1.1).

o A treia etapa - este caracterizata de reîntâlnirea datelor cu procedurile în corpul Obiectelor, care respecta drepturile la definirea independenta si transanta a Structurilor si Operatiilor, dar le reuneste prin comunitatea sarcinilor pe care sunt chemate sa le îndeplineasca împreuna, aceea de a da nastere la o noua entitate, nu numai cu Structura Specifica, ci si cu un Comportament Individualizat (capacitati de mostenire si de transmitere a însusirilor, de receptie si interpretare a mesajelor, de executie a comenzilor primite prin mesaje etc.).

Reîntâlnirea se produce deci sub semnul definitiei facuta în lucrarea [WIRT76] mai sus amintita :

“ Un Tip de Data este o Structura + Operatorii acceptati. “

Noutatea adusa de Bazele de Date consta în Virtualizarea Datelor, care determina unificarea Datelor cu Procedurile prin înglobarea modificarilor potentiale de stari în structura sistemului. Procedurile Stocate orientate pe Eveniment asigura acest lucru.

Se realizeaza astfel o concentrare a cunostintelor asupra Sistemului ce urmeaza a fi proiectat în asa numitul Model de Date, cu o mare putere de generare a diverselor componente ce vor alcatui sistemul.

36 Definitia Bazelor de Date

2.2 Definitia Bazelor de Date

In literatura de specialitate se gaseste o diversitate de definitii ale Bazelor de Date. Vom prezenta în continuare o definitie bazata pe caracteristicile desprinse din prezentarile facute în sectiunile anterioare. Am ales aceasta definire datorita preciziei si conciziunii sale.

O Baza de Date este o Colectie Memorata de Date, variabila în timp, având urmatoarele caracteristici:

o Asigura Independenta Datelor prin:

§ Prezenta Schemei de Date (cel mai adesea si a Subschemelor de Date) precum si a Limbajului de Definire a Datelor (LDD), asociat Schemelor de Date

o Asigura Accesul (cel mai adesea Multiaccesul) la Colectii Mari de Date prin:

§ Prezenta Nivelul Fizic de Acces la Date precum si a Limbajului de Manipulare a Datelor (LMD)

§ Asigurarea functiilor de Securitate a Datelor prin:

• Controlul Accesului la Date

• Restaurarea Colectiilor de Date în caz de incident

Am încercat sa sintetizam în definitia prezentata acele caracteristici pe care le consideram strict necesare pentru recunoasterea calitatilor de Baza de Date pentru o Colectie de Date, ca si pentru un Produs Comercial care gestioneaza aceste colectii. Gasim aici grupate urmatoarele caracteristici:

- Precizarea Independentei Datelor ca si însusire principala a oricarui produs din categoria SGBD. Asa dupa cum se va vedea pe parcursul lucrarii, proprietatea de Independenta va fi promovata de conceptele Bazelor de Date si în alte raporturi decât cele de Date – Proceduri. O vom regasi între Structura – Ordine, Valoare – Suport, Atribute Descriptoare, Tranzactii, etc. Sectiuni numeroase din lucrare vor sustine interesul pe care SBD îl acorda definirii, întretinerii si perfectionarii Structurilor de Date privite sub aspectul Independentei lor

- Precizarea importantei Gestiunii Datelor prin Limbaje Specializate. Sunt prezentate, categoriile de Limbaje de Navigare, de Specificare Operatoriala si de Specificare Predicativa. O sectiune speciala este destinata problemelor ridicate de Prelucrarile Tranzactionale

- Legata de Gestiunea Datelor de Volum Mare, este cuprinsa în lucrare si o sectiune care trateaza problema Securitatii Datelor. Doua subiecte sunt dezvoltate aici: unul ce dezvolta problema ampla a Subsistemelor de Salvare / Restaurare si celalalt consacrat Controlului Accesului la Bazele de Date

Se observa ca, exceptând sectiunea finala care este orientata spre caile de dezvoltare în viitor a Sistemelor cu Baze de Date, restul sectiunilor sunt axate pe componentele Definitiei adoptate pentru Baza de Date. Ca urmare, toate informatiile prezentate vin sa argumenteze acele caracteristici ce au fost alese ca definitorii pentru asemenea produse atât de variate ca structura si ca utilizare.

Avantajele Utilizarii Bazelor de Date 37

2.3 Avantajele utilizarii Bazelor de Date

Din numeroasele avantaje ale Sistemelor cu Baze de Date, avantaje care au asigurat perenitatea acestor sisteme, le enumeram pe cele considerate cele mai importante:

- Facilitatile oferite pentru Gestiunea Colectiilor Mari de Date

§ posibilitatile de definire a Structurilor Complexe de Date cu ajutorul unui Limbaj Unificat de Definire a Datelor ( LDD)

§ posibilitati multiple de regasire si actualizare a datelor din si în memoria externa prin intermediul unui Limbaj unificat de Manipulare a Datelor (LMD)

- Scurtarea duratelor de proiectare si implementare a proiectelor complexe

§ asigurarea unei structuri deschise prin caracteristica de Independenta a datelor

§ oferirea unei mari flexibilitati de manevrare a structurilor de date prin mediile de programare disponibile în diferite tehnologii de prelucrare

- Adaptabilitate la modificarea specificatiilor initiale

§ Independenta Datelor fata de Proceduri asigura Imunitatea Procedurilor

§ legaturile strânse cu produsele de Construire a Modelelor de Date permit Generare Automata a Structurilor Logice de Date

- Facilitati de definire a Proiectelor Integrate

§ existenta unei Descrieri Unice de Structura cu functie de Dictionar de Date

§ existenta posibilitatilor de cuprindere în Baza de Date a sectiunii de definire a Restrictiilor Asociate Datelor

§ materializarea datelor prin Proceduri Orientate pe Eveniment si memorate tot în Baza de Date sub forma de Proceduri Declansate (Triggeri)

- Controlul validitatii datelor

§ utilizarea conceptului de Integritate a Bazei de Date, asigurat prin Restrictiile de Integritate puse la dispozitia utilizatorului

§ posibilitati multiple de declarare a regulilor suplimentare de validare (Unicitate de Chei, Constrângeri,Triggeri, Proceduri Stocate)

- Raspuns la Întrebari Neprevazute initial

§ posibilitatea adresarii de Cereri Instantanee Bazei de Date prin Limbaje Neprocedurale (SQL - Structure Query Language sau QBE - Query By Example)

- Flexibilitate de adaptare la noile Tehnologii de Proiectare

§ construirea Surselor de Date accesibile de pe diferite platforme Hardware si Software

§ Îmbunatatirea dialogului Utilizator - Calculator

§ dezvoltarea Interfetelor Utilizator cu mare grad de interactivitate

38 Exemple de Baze de Date

2.4 Exemple de Baze de Date

Dam ca exemplu de Baza de Date prima structura de date care, pornind de la cerintele practice ridicate de industrie, a stimulat dezvoltarea conceptelor care au stat la baza domeniului de prelucrare a colectiilor mari de date. Este vorba de Prelucrarea Nomenclatoarelor (List of Part Processing). Provenind din domeniul constructiilor de masini, prelucrarea consta în determinarea necesarului de Repere componente într-un Ansamblu privit ca un Produs Compus.

Exemplu simbolic:

Structura de Informatii descrie cantitatea q necesara dintr-un COMPONENT pentru a produce 1 bucata de COMPUS. In forma concentrata structura e reprezentata în Fig. 2.4.1.

Fig. 2.4.1 Structura de informatii ce descrie componenta unui produs

Exemplu general:

Un exemplu detaliat al structuri anterioare e redata în Fig. 2.4.2. unde: - A, B, .... sunt COMPUSI sau COMPONENTE - q este Cantitatea Necesara

Doua colectii de date sunt folosite pentru a descrie structura de mai sus: - Colectia Principala continând Elementele A, B, .. - Colectia de Legatura ce descrie Legaturile AB q1, BD q2, ..

Procedurile consacrate pentru prelucrarea structurile de genul celor prezentate sunt:

- Explozie Detaliata – lista structurii COMPUS - COMPONENTE desfasurata pe nivele, sub forma:

Compusul A are Componenta B în cantitatea q 1 Componenta C în cantitatea q 2

Compusul B are Componenta D în cantitatea q 3 Componenta E în cantitatea q 4

Compusul C are Componenta F în cantitatea q 5 Componenta E în cantitatea q 6

- Explozie Cumulata – lista necesarului cumulat de COMPONENTE pentru un nivel dat de COMPONENT sub forma:

COMPUS

COMPONENT

q

Exemple de Baze de Date 39

Compusul A are Componenta B în cantitatea q 1 Componenta C în cantitatea q 2 Componenta D în cantitatea q 1 x q 3 Componenta E în cantitatea q 1 x q 4 + q 2 x q 6 Componenta F în cantitatea q 2 x q 5

Fig. 2.4.2. Structura generala de informatii pentru componenta unui produs

- Implozie – lista COMPUSILOR în care apare un COMPONENT dat sub forma: Componenta B apare în

Compusul A în cantitatea q 1 Componenta C apare în

Compusul A în cantitatea q 2 Componenta D apare în

Compusul B în cantitatea q 3 Compusul A în cantitatea q 1 x q 3

Componenta E apare în Compusul B în cantitatea q 4 Compusul C în cantitatea q 6 Compusul A în cantitatea q 1 x q 4 + q 2 x q 6

Componenta F apare în Compusul C în cantitatea q 5 Compusul A în cantitatea q 2 x q 5

Date de Intrare:

o Informatii Tehnice si Tehnologice legate de structura produselor si de necesarul de materiale pentru fabricarea acestor produse

o Informatii Comerciale asupra Comenzilor de Produse si Componente de Produse

Date de Iesire:

o Lista Componentelor care se cer achizitionate sau fabricate pentru onorarea Comenzii

o Lista Necesarului de Materiale necesare fabricarii produselor solicitate

o Lista Modificarilor în listele anterioare, modificari generate de schimbarea continutului Comenzilor

C B

A q 1 q 2

q 3 q 5 q 4 q 6

D E F E

40 Exemple de Baze de Date

o Lista Produselor afectate de un dis ponibil insuficient de Componente

Exemplu concret:

Sa consideram structura de date care descrie componenta unei Retele de Calculatoare si care e reprezentata în detaliu în tabelul 2.4.3.

RETEA de CALCULATOARE

Componenta SERVER (1) STATII de LUCRU (8) Memorie

Principala 128 Mb Memorie

Principala 32 Mb

Memorie Cache

1024 Kb Memorie Cache

1024 Kb

Memorie Interna

Porturi 4 Porturi 2 Hard Disc 2 GB Hard Disc 1 GB

Drive 2 GB Drive 1 GB Controler de

Disc SCASI Controler de

Disc IDE

CD drive CD drive 3.5

inches Floppy Disc 3.5 inches

Memorie Externa

Floppy Disc

5.25 inches

5.25 inches

Monitor Monitor Display Placa Video Placa Video

Tastatura Carcassa Mouse

Tab. 2.4.3 Componenta unei Retele de Calculatoare

Cerintele de informatii care se ridica în legatura cu structura descrisa si memorata în calculator sub forma celor doua colectii de date prezentate anterior (Colectia Principala si Colectia de Legaturi) sunt:

o Fiind data o Comanda de achizitie a unor Ansambluri (Retele integrale) si a unor Componente separate (Piese), sa se determine Necesarul Total pentru fiecare Componenta

o Cunoscând Disponibilul (Stocul) de Componente sa se determine Necesarul de Aprovizionat pentru fiecare tip de Componenta în vederea onorarii Comenzii

o Cunoscând Disponibilul (Stocul) de Componente sa se determine Comenzile care se pot onora imediat sau care se cer amânate

Se pot remarca doua aspecte legate de genul de prelucrari de date prezentat anterior:

o Amploarea Colectiilor de Date care formeaza Sursa de Date pentru asemenea prelucrari:

§ Calitativ - structuri de tip Padure de Arbori

§ Cantitativ - mii de Noduri si sute de mii de Legaturi

o Utilitatea informatiilor care se ofera cu implicatii directe asupra procesului de conducere a activitatilor principale ale unei întreprinderi

Exemple de Baze de Date 41

PPAARRTTEEAA aa 33--aa

CCOONNCCEEPPTTEE ddee BBAAZZAA

Conceptele de Baza sunt grupate în jurul a trei Antinomii, cu care Sistemele cu Baze de Date opereaza curent si al caror continut ca notiuni nu întruneste unanimitate în rândul specialistilor:

Multimi – Relatii Informatie – Data Date – Proceduri

Pentru a consolida claritatea expunerii din lucrare se sacrifica aceste prime sectiuni pentru a rememora anumite concepte fundamentale si a cladi pe ele acceptiuni ale altor concepte supuse interpretarilor. Sectiunile subordonate au fost organizate astfel:

3.1 – Multimi si Relatii – conceptele rememorate sunt de

un real folos pentru întelegerea aportului Modelului Relational la viziunea structuralista a SBD si mai ales la aprecierea rolului acestui model în perspectiva timpului.

3.2 – Informatie si Data – notiuni de baza pentru SBD,

ele sunt supuse numeroaselor interpretari, asa încât definirea clara a acceptiunilor din lucrare se impune.

3.3 – Date si Proceduri – opozitia Date-Proceduri nu

poate fi ocolita în cadrul unui subiect care readuce frecvent în discutie problema Independentei celor doua elemente.

3.4 – Structuri de Informatii si Date – orienteaza conceptele deja prezentate spre sarcina lor principala: Construirea si Controlul Structurilor.

3.5 – Structuri de Proceduri – reia problema Structurii în cadrul Procedurilor pentru a da unitate Viziunii Structuraliste

42 Concepte de de Baza / Multimi

3 Concepte de Baza

Prezentarea Conceptelor de Baza este organizata în jurul a trei opozitii de termeni cu care opereaza frecvent Bazele de Date:

o Multimi si Relatii – ca elemente fundamentale de descriere a existentei

o Informatie si Data – ca forme de reprezentare a Semnificatului si Semnificandului în SBD

o Data si Procedura – ca mijloace de descriere a Starilor si Transformarilor unui Sistem

Termenii introdusi sunt apoi folositi pentru descrierea Structurilor de Informatii, Date si Proceduri, notiuni pe care se bazeaza construirea si utilizarea Sistemelor cu Baze de Date. 3.1 Multimi si Relatii

Începerea prezentarii Conceptelor de Baza cu care opereaza disciplina de Baze de Date prin reamintirea unor notiuni fundamentale legate de Multimi si Relatii aduce urmatoarele beneficii:

- Permite raportarea conceptelor proprii disciplinei, precum si a terminologiei de specialitate la notiuni consistente

- Înlesneste întelegerea evolutiei modelelor utilizate în diferite etape de dezvoltare a disciplinei

- Permite orientarea în perspectivele de dezvoltare ale modelelor promovate si utilizate în SBD

- Faciliteaza compararea si evaluarea conceptelor din domeniu, prin raportarea lor la cele din domeniile înrudite (Programare Clasica, Programare Obiectuala, Ingineria Programarii, Instrumente CASE etc.)

3.1.1 Multimi

Multimea – poate fi privita ca o colectie de Elemente distincte (concrete sau abstracte), ce au o proprietate comuna.

Definitia lui Cantor: “O multime este rezultatul cuprinderii într-un singur tot a unor obiecte determinate ale perceperii sau gândirii noastre; aceste obiecte se numesc elemente ale multimii.”

Multimea si Elementul sunt notiuni primare si nu pot ca urmare sa fie definite în plan abstract (ex.: într-un sistem formalizat).

Având în vedere utilitatea proprietatilor generale ale multimilor pentru tratarea Colectiilor de Informatii si Date cu care opereaza SBD, se retranscriu în continuare Caracteristicile de Baza ale Multimii. Se va observa în cele ce urmeaza ca ele vor fi preluate ca Restrictii implicite ale Modelului Relational de Date.

Concepte de Baza / Multimi 43

3.1.1.1 Caracteristicile de baza ale Multimii

o Individualitatea Elementului – Fiecare Element al Multimii trebuie sa se deosebeasca de celelalte.

Orice Colectie de Date privita ca o Multime trebuie sa contina aceasta prima proprietate si sa asigure posibilitatea ca fiecare element din colectie (articol, înregistrare, tupla etc.) sa fie referit unic. De aici deriva necesitatea existentei unui Identificator pentru toate colectiile de date care, intrând în relatii reciproce, constituie un tot unitar si consistent.

o Individualitatea Multimii – Fiecare Multime se individualizeaza prin existenta unei Proprietati Comune, definitorie pentru multime (multimea sa fie Bine Definita)

Proprietatea de Multime Bine Definita poate interveni doar în cazul Colectiilor de Date ce sunt definite intensional în cadrul Bazelor de Cunostinte sau a Bazelor de Date Deductive.

o Asemanarea Elementelor (Echivalenta Elementelor) – Din punctul de vedere al Proprietatii Comune nu exista Element Privilegiat si ca urmare nu exista nici Ordine a Elementelor (aceasta fiind o proprietate nespecificata în Proprietatea Comuna).

Evidentiata în special de modelul Relational de date, caracteristica de Asemanare e prezenta prin modul de definire a Relatiei (Tabelei) ca si colectie de tuple sau rânduri care initial apar în Ordine Naturala (ordinea cronologica de înregistrare în colectie), ceea ce corespunde inexistentei unui element privilegiat, nici macar în ceea ce priveste Ordinea în Colectie, care survine doar ulterior în prelucrare, prin atasarea explicita a unui Criteriu de Ordonare si a unei Ordini introduse de o Tabela de Index.

o Unitatea Elementelor – Proprietatea Comuna permite ca Multimea sa fie privita si tratata ca un nou Element (o noua entitate), care în aceasta calitate poate participa în alta Multime.

Esenta prelucrarilor în sistemele cu Baze de Date este capacitatea de generare a unor noi Colectii de Date prin Regrupare sau Combinare de multimi. Fiecare noua colectie trebuie sa fie Identificabila (printr-un Nume, printr-o Proprietate sau printr-un Proprietar) si prin aceasta sa fie recunoscuta ca un Element într-o noua Colectie de Colectii de Date.

Legatura între Element si Multime este realizata prin proprietatea de Apartenenta, care va sta la baza Relatiei de Echivalenta. 3.1.1.2 Incluziunea Multimilor

Fie M 1 si M 2 doua multimi.

44 Concepte de de Baza / Multimi

Se zice:

M 2 ⊆ M 1 (M 2 e Inclus în M 1 sau M 2 e Parte Proprie a lui M 1)

daca:

∀ x ∈ M 2 ⇒ x ∈ M 1

Se zice:

M 2 ⊂ M 1 (M 2 e Strict Inclus în M 1)

daca:

∀ x ∈ M 2 ⇒ x ∈ M 1

si

∃ x ∈ M 2 ⇒ x ∉ M 1

Prima forma de legatura între Multimi este realizata prin proprietatea de Incluziune si e bazata pe generarea de noi multimi prin Regrupare de Elemente. (Cea de a doua forma de legare a multimilor va fi introdusa odata cu prezentarea Relatiei.). 3.1.1.3 Identitatea Multimilor

Fie M 1 si M 2 doua multimi.

Se zice:

M 1 = M 2 (M 1 , M 2 identice sau egale)

daca:

∀ x ∈ M 1 ⇔ x ∈ M 2

sau:

∀ x ∈ M 1 ⇒ x ∈ M 2

∀ x ∈ M 2 ⇒ x ∈ M 1

O multime de multimi se numeste Clasa sau Familie. Notiunile de Clasa de Entitati si Clasa de Obiecte îsi au originea în notiunea de Clasa , atât Entitatea Notiune cât si Entitatea Obiect fiind privite ca Mutimi de Caracteristici, respectiv Multimi de Tuple de Valori. 3.1.1.4 Multimea Totala

Multimea Totala este multimea constituita pe baza unei Proprietati Fundamentale (Primare) a unor Elemente.

Concepte de Baza / Multimi 45

Toate celelalte proprietati care pot fi recunoscute pentru elementele unei Multimi Totale se adauga Proprietatii Primare purtând numele de Proprietati Secundare. Proprietatile secundare definesc în multimea totala Parti ale acestei multimi.

Referitor la o Multime Totala exista trei categorii de Proprietati:

§ Echivalente - definesc Multimea Totala (Multimea Plina), fiind echivalente din acest punct de vedere cu proprietatea fundamentala

§ Straine - definesc Multimea Vida a Multimii Totale

§ Restrictive - definesc Submultimi Parti ale Multimii Totale

Proprietatile Restrictive sunt cele care asigura generarea de noi multimi prin Regruparea Elementelor unei Multimi date.

Fiind data o Multime Totala M, se definesc:

P(M) – Multimea Partilor lui M , care contine:

• Submultimile lui M • Multimea Vida • Multimea Plina

P*(M) – Multimea Partilor Nevide ale lui M , care contine:

• Submultimile lui M • Multimea Plina

Exista expresia de legatura:

P*(M) = P(M) \ ∅

Fiind data o Multime M, Familia tuturor Submultimilor lui M e o Familie Bine Definita de multimi numita Familia Partilor Multimii M. 3.1.1.5 Numararea Partilor unei Multimi Totale

Pentru o Multime M având n Elemente P(M) va avea 2 n Elemente (reprezentate de Multimile Parti).

Pentru o Multime M având definite n Submultimi (Multimi Parti) oarecare (nedisjuncte) acestea genereaza în multimea data:

C n0 + C n

1 + C n2 + … + C n

n = 2 n

Parti Disjuncte (obtinute prin Intersectia Submultimilor Oarecare pentru fiecare Combinatie de Submultimi)

(C02) n + (C1

2) n + (C32) n + … + (Cn

2) n = (2 n ) n

Parti Disjuncte si Nedisjuncte (obtinute prin Reuniunea Submultimilor Disjuncte pentru fiecare Combinatie de Submultimi)

Pentru n=9 Submultimi rezulta un Numar de Parti mai mare decât numarul estimat al electronilor si protonilor din univers, de unde si puterea de generare de noi multimi prin

46 Concepte de de Baza / Multimi

Regrupare de Elemente (Partitii sau Acoperiri), procedeu mult utilizat în generarea de noi colectii de date.

Notiunea de Multime Totala corespunde notiunii de Univers de Discurs din Calculul Predicatelor si notiunii de Univers din unele Sisteme Formale Axiomatizate. In domeniul Bazelor de Date ea poate fi atasata fie unei Baze de Date (Logice sau Fizice) sau chiar unei Relatii (Tabele) care, fiind Bine Definite pot conduce la generarea unor numeroase Medii de Lucru (Colectii de Date) prin simpla adaugare de Filtre de Selectie (Proprietati Secundare). 3.1.1.6 Operatii Booleene pe Multimea Partilor unei Multimi Totale

Fie M Multimea Totala si M i ∈ P (M), pentru ∀ i ∈ 1,2, .. ,n. Complementara unei multimi

M 1C = m ∈ M | m ∉ M 1

Reuniunea multimilor

M 1 ∪ M 2 = m ∈ M | m ∈ M 1 sau m ∈ M 2

“sau” e inclusiv

Intersectia multimilor

M 1 ∩ M 2 = m ∈ M | m ∈ M 1 si m ∈ M 2

Diferenta multimilor

M 1 \ M 2 = m ∈ M | m ∈ M 1 si m ∉ M 2

Diferenta simetrica a multimilor

M 1 ∆ M 2 = m ∈ M | m ∈ M 1 sau exclusiv m ∈ M 2 si m ∉ ( M 1 ∩ M 2 )

Multimi Disjuncte

M 1 \ M 2 sunt disjuncte pentru M 1 ∩ M 2 = ∅

3.1.1.7 Acoperire si Partitie

Fig. 3.1.1.7.1. Submultimi în Relatie de Acoperire

Multimile Parti M 1, M 2, M 3, .. , M n formeaza o Acoperire pe M pentru:

M 1

M 3

M 2

Concepte de Baza / Multimi 47

M 1 ∪ M 2 ∪ M 3 ∪ .. ∪ M n = M

Fig. 3.1.1.7.2. Submultimi în Relatie de Partitie

Multimile Parti M 1, M 2, M 3, .. , M n formeaza o Partitie Neordonata pe M pentru:

M 1 ∩ M 2 = ∅ pentru ∀ i , j ∈ 1,2, .. ,n si i # j

3.1.1.8 Latice

Conceptul de Latice s-a format cu scopul generalizarii si unificarii raporturilor care exista între submultimile anumitor structuri.

LATICEA – O Multime L împreuna cu doua Operatii de Compozitie: Intersectie (∩) si Reuniune (∪), care respecta urmatoarele Axiome:

o Comutativitate

a ∩ b = b ∩ a

a ∪ b = b ∪ a

o Asociativitate

(a ∩ b) ∩ c = a ∩ (b ∩ c)

(a ∪ b) ∪ c = a ∪ (b ∪ c)

o Absorbtie

a ∪ (a ∩ b) = a

a ∩ (a ∪ b) = a

pentru:

∀ a, b, c ∈ L

M 1

M 3

M 2

M 6

M 4

M 5

48 Concepte de Baza / Relatii între Multimi

3.1.2 Relatii între Multimi

Exista doua metode de a genera noi multimi pornind de la multimi date prin:

- Regrupare de Elemente – operatie întâlnita la stabilirea Multimilor Parti (de tip Partitie sau Acoperire) prin definirea de Proprietati Secundare

- Combinare de Elemente - operatie întâlnita la efectuarea Produsului Cartezian a multimilor

Combinarea de elemente se realizeaza cu ajutorul notiunii de Cuplu.

Fiind date multimile M 1 si M 2 , perechea ordonata (m 1 , m 2) cu m 1 ∈ M 1 si m 2 ∈ M 2 poarta numele de Cuplu. Se observa ca notiunea de Cuplu introduce pentru prima data în discutie problema Ordinii în multimile de elemente, prin aceea ca termenul “perechea ordonata (m 1 , m 2)” este folosit, într-un sens intuitiv, ca o alaturare a elementelor m 1 si m 2 astfel încât m 1 poate fi perceput ca un Element Aparte (Primul Element) al perechii ordonate (m 1 , m 2) si m 2 ca Celalalt Element (al Doilea Element).

Faptul ca definirea formalizata a relatiilor de Ordine pe multimi apeleaza la conceptul de Cuplu, ne face sa consideram Ordinea, alaturi de Multime si Element , ca o notiune primara.

Pentru aceeasi idee pledeaza si definirea în cadrul Teoriei Multimii a notiunii de Pereche Ordonata, nu pur si simplu ca m 1, m 2 , ci prin postularea urmatoarei egalitati prin definitie:

(m 1 , m 2) = def m 1 , m 1 , m 2

înteleasa în modul ca, daca m 1 # m 2 , membrul stâng al perechii ordonate (m 1 , m 2) este elementul multimii formate dintr-un singur element, pe când membrul drept este constituit cu elementul ce nu se gaseste în aceasta multime. Definitia folosita extrage elementul m 1 din multime eliberându-l de proprietatea de echivalenta si acordându-i o proprietate noua, pe cea de Pozitie în multime pe care se bazeaza de fapt conceptul de Ordine. Se mai poate remarca si faptul ca daca, prin reducere la absurd, consideram:

(m 1 , m 2) = m 1 , m 1 , m 2 = m 2 , m 1 , m 2

rezulta:

m 1 = m 2

Din aceasta definitie se poate deriva si urmatoarea proprietate fundamentala a perechilor ordonate, cunoscuta si sub numele de Axioma Cuplului si care se enunta astfel:

(x , y ) = (x’ , y’) ⇒ x = x’ si y = y’ ,

Aceasta definitie subliniaza o data în plus faptul ca modul de enumerare (pozitia în multime), care pâna acum era indiferenta începe deja sa conteze.

Notiunea de Cuplu se generalizeaza pentru n multimi, M 1, M 2, M 3, .., M n, primind denumirea de n-TUPLU (sau n-UPLU) si având forma:

(m 1, m 2, m 3, .. , m n).

Concepte de Baza / Relatii între Multimi 49

3.1.2.1 Produs Cartezian de multimi

Produsul Cartezian a n multimi M 1 , M 2 , M 3 , .. , M n se defineste ca fiind multimea:

M 1 x M 2 x M 3 x .. x M n = Π M i = (m 1 , m 2 , m 3 , .. , m n) | m i ∈ M i pentru ∀ i ∈ 1,2, .. ,n

Pentru M 1 = M 2 = M 3 = .. = M n = M , Produsul Cartezian a n multimi se transforma în Puterea Carteziana a unei multimi, notata M n. 3.1.2.2 Reuniunea Disjuncta a Multimilor

Cu ajutorul notiunii de Produs Cartezian poate fi definita operatia de Reuniune Disjuncta a doua multimi:

M 1 ∪ d M 2 = ( M 1 x 1 ) ∪ ( M 2 x 2 )

operatie care realizeaza dedublarea elementelor comune multimilor M 1 si M 2 . Aceasta operatie da justificarea prelucrarilor în sistemele ce nu respecta unicitatea de identificare a elementelor de date si cu toate acestea implementeaza proceduri consistente de tratare a dublurilor, prin Reguli Specializate de tratare a Elementelor Dublate potrivit Provenientei lor din Colectii de Date diferite, în cazul Interclasarii. Reguli Specializate similare pot trata si Pozitia în Colectie a Elementelor Dublate. 3.1.2.3 Relatia n-ara

O Relatie n-ara R pe multimile nevide M 1 , M 2 , M 3 , .. , M n se defineste ca o Submultime a Produsului Cartezian M 1 x M 2 x M 3 x .. x M n . Deci:

R ⊆ M 1 x M 2 x M 3 x .. x M n

Cu alte cuvinte, orice Multime Parte a unui Produs Cartezian e o Relatie.

Numarul Multimilor pe care e definit Produsul Cartezian confera Gradul Relatiei, în speta n, cu conditia impusa n ≥ 2. (Orice Relatie implica minimum doua Domenii, nu neaparat Distincte.)

Relatia e deci o multime si are ca urmare o Proprietate Definitorie, care e valabila pentru toate n-Tuplele Relatiei. Întrucât fiecare n-tupla contine mai multe elemente primare mi, provenind din multimile de definitie M i , Proprietatea Definitorie a relatiei poate fi privita ca un Predicat Polinar;

P (m 1 , m 2 , m 3 , .. , m n).

In definirea unei Relatii se pot recunoaste cele doua forme de definitie ale unei multimi:

- Intensionala – prin:

P (m 1 , m 2 , m 3 , .. , m n) = ‘adevarat’

50 Concepte de Baza / Relatii între Multimi

pe multimea Produsului Cartezian M 1 x M 2 x M 3 x .. x M n , privit ca Multime Totala

- Extensionala – prin:

(m 1 , m 2 , m 3 , .. , m n) | m i ∈ M i pt. ∀i ∈ 1,2, .. ,n si (m 1 , m 2 , m 3 , .. , m n) ∈ R

Conditia ca Multimile de Definitie M i sa nu fie vide se motiveaza prin necesitatea ca fiecare n-tuplu sa contina în mod constant n elemente, absenta unuia din elementele n-tuplului distrugând ideea de Ordine pe care n-tuplul trebuie sa o instituie între elementele sale. Relatia poate însa sa fie Vida , fiind în acest caz reprezentata de Submultimea Vida a Produsului Cartezian M 1 x M 2 x M 3 x .. x M n, care semnifica faptul ca Proprietatea Definitorie, în acest caz, este o Proprietate Straina (neîndeplinita de nici o combinatie de elemente din Multimile de Definitie).

Pentru n = 2 se obtin Relatiile Binare , relatii foarte utile pentru descrierea naturii legaturilor între Multimi, dar si între Elementele Multimilor (în speta Atributele unei Relatii din Modelul Relational de Date).

Pentru relatiile binare se folosesc doua conventii de notatie echivalente:

x R y ⇔ (x , y) ∈ R

Fiind data o relatie binara R definita pe o singura multime M se pot defini notiunile:

- Domeniul de Definitie al Relatiei (numit si Suport), reprezentat de Proiectia de Rang 1 a Puterii Carteziene M x M:

DD R = P R , 1

- Domeniul de Valori al Relatiei (numit si Codomeniu), reprezentat de Proiectia de Rang 2 a Puterii Carteziene M x M:

DV R = P R , 2

- Domeniul Relatiei , reprezentat de Reuniunea Domeniului de Definitie cu Domeniul de Valori:

DR R = DD R ∪ DV R

De unde rezulta:

DD R ⊆ DR R

si

DVR ⊆ DR R

3.1.2.4 Implicarea relatiilor (Extensii si Restrictii)

Fie doua relatii R 1 si R 2 definite pe acelasi Produs Cartezian de Multimi.

Se zice ca:

Relatia R 1 implica relatia R 2

Concepte de Baza / Relatii între Multimi 51

si se noteaza cu:

R 1 ≤ R 2

Daca:

R 2 e adevarata ori de câte ori R 1 e adevarata

Aceasta proprietate determina existenta unei Legaturi de Dependenta (Incluziune) si între Domeniile de Valori ale celor doua Relatii.

R 1 ≤ R 2 ⇔ R 1 ⊆ R 2

(în Intensiune) (în Extensiune)

R 1 - se zice Restrictie a lui R 2

R 2 - se zice Extensie a lui R 1

3.1.2.5 Proiectia relatiilor

Proiectia relatiilor reprezinta o forma de Generare de noi Multimi care se înscrie în forma de Regrupare, dar de data aceasta a Multimilor de tip Relatie. Ca urmare Relatia reprezentând o multime:

R= (m 1 , m 2 , m 3 , .. , m n) | m i ∈ M i pentru ∀i ∈ 1,2, .. ,n si P (m 1 , m 2 , m 3 , .. , m n) = ‘adevarat’

de multimi ordonate:

(m 1 , m 2 , m 3 , .. , m n)

Regruparea se va extinde în doua planuri:

- Planul Multimii de Elemente ce formeaza n-Tupla – prin definirea Rangului Proiectiei

- Planul Multimii de n-Tuple ce formeaza Relatia – prin definirea Conditiei de Proiectie

Proiectia de rang j a Relatiei n-are:

R ⊆ M 1 x M 2 x M 3 x .. x M j x .. x M k x .. x M n

e data de Multimea:

- pentru Proiectia Neconditionata

π R , j = m j | m k ∈ M k pentru ∀ k ∈ 1,2, .. ,n \ j si (m 1 , m 2 , m 3 , .. , m j , .. , m k.. , m n) ∈ R

unde j reprezinta Rangul pe care se face Proiectia Relatiei R

- pentru Proiectia Conditionata

52 Concepte de Baza / Relatii între Multimi

π R , j, Mk’ = m j | m k ∈ M k‘ pentru ∀ k ∈ 1,2, .. ,n \ j , M k‘ ⊂ M k si (m 1 , m 2 , m 3 , .. , m j , .. , m k.. , m n) ∈ R

unde M k‘ ⊂ M k reprezinta Conditia dupa care se face proiectia relatiei R (de fapt o multime de conditii suplimentare impuse tuplelor din care se extrag elementele de rang j)

In aceasta forma completa, Proiectia Relatiilor sta la baza Operatorilor Relationali de Selectie si Proiectie din Algebra Relationala. 3.1.2.6 Proprietatile Relatiilor Binare

Asa dupa cum rezulta din conditia impusa Gradului Relatiilor n ≥ 2 , Relatiile Binare reprezinta categoria de relatii de Rang Minim. Analiza proprietatilor Relatiilor Binare este foarte importanta pentru clasificarea raporturilor în care pot sta doua multimi legate prin relatii. Proprietatile relatiilor binare definesc tot atâtea Tipuri de Relatii Binare. 3.1.2.6.1 Relatii Binare pe Doua Multimi Distincte

In acest caz:

R ⊆ M 1 x M 2 .

unde:

R = (m 1 , m 2) | m i ∈ M i pentru ∀i ∈ 1,2si P (m 1 , m 2) = ‘adevarat’

Relatia Inversa

R –1 ⊆ M 1 x M 2

- proprietate:

(m 1 , m 2) ∈ R –1 ⇒ (m 2 , m 1) ∈ R

Relatia Complementara

R c ⊆ M 1 x M 2

- proprietate:

(m 1 , m 2) ∈ R c ⇒ (m 1 , m 2) ∉ R

Relatia Unica la Stânga

R us ⊆ M 1 x M 2

- proprietate:

(m 1 , m 3) ∈ R us si (m 2 , m 3) ∈ R us ⇒ m 1 = m 2

Concepte de Baza / Relatii între Multimi 53

Relatia Unica la Dreapta

R ud ⊆ M 1 x M 2

- proprietate:

(m 1 , m 2) ∈ R ud si (m 1 , m 3) ∈ R ud ⇒ m 2 = m 3

Relatia Biunica

Relatia Biunica este o Relatie Unica la Stânga si Unica la Dreapta.

Relatia Binara Functionala

Relatia Binara Functionala este o Relatie Unica la Stânga sau Unica la Dreapta

Întrucât proprietatea de Unicitate nu e simetrica au loc urmatoarele determinari:

- pentru Relatia Unica la Stânga

P R , M 2 → P R , M 1

P R , M 2 determina functional pe P R , M 1

P R , M 1 depinde functional de P R , M 2

- pentru Relatia Unica la Dreapta

P R , M 1 → P R , M 2

P R , M 1 determina functional pe P R , M 2

P R , M 2 depinde functional de P R , M 1

Dependenta Functionala între doua Multimi:

M 1 si M 2

în cadrul unei Relatii n-are:

R ⊆ M 1 x M 2 x M 3 x .. x M n

poate fi determinata din analiza proprietatii proiectiei:

P R , M 1 x M 2 .

Daca Proiectia este o Relatie Binar Functionala, atunci:

Multimile M 1 si M 2 sunt Functional Dependente

în cadrul Relatiei n-are R

3.1.2.6.2 Relatii Binare pe Aceeasi Multime

In acest caz:

54 Concepte de Baza / Relatii între Multimi

R ⊆ M x M .

unde:

R = (m 1 , m 2) | m i ∈ M pentru ∀i ∈ 1,2 si P (m 1 , m 2) = ‘adevarat’

Relatia Identica (Nula)

R i ⊆ M x M

- proprietate:

∀ m ∈ M ⇒ (m , m) ∈ R si (m 1 , m 2) ∈ R ⇒ (m 1 = m 2)

Relatia Totala – relatie identica cu Produsul Cartezian

R t = M x M

Relatia Reflexiva – orice relatie ce contine o Relatie Identica

R r ⊆ M x M

- proprietate:

∀ m ∈ M ⇒ (m , m) ∈ R r

sau altfel exprimat:

R r ≥ R i

Relatia Nereflexiva – orice relatie ce nu contine nici un element al Relatiei Identice

R n ⊆ M x M

- proprietate:

∀ m ∈ M ⇒ (m , m) ∉ R n

Relatia Simetrica – contine toate perechile de cupluri simetrice

R s ⊆ M x M

- proprietate:

(m 1 , m 2) ∈ R ⇒ (m 2 , m 1) ∈ R s

sau altfel exprimat:

R s-1 = R s

Relatia Asimetrica– contine si cupluri fara perechea simetrica

R as ⊆ M x M

Concepte de Baza / Relatii între Multimi 55

- proprietate:

∃ (m 1 , m 2) | (m 1 , m 2) ∈ R as ⇒ (m 2 , m 1) ∉ R as

Relatia Antisimetrica– nu contine nici-o pereche de cupluri simetrice

R a ⊆ M x M

- proprietate:

(m 1 , m 2) ∈ R a ⇒ (m 2 , m 1) ∉ R a

sau altfel exprimat:

R a ∩ R a-1 ≤ R i

Relatia Tranzitiva

R t ⊆ M x M

- proprietate:

(m 1 , m 2) ∈ R t si (m 2 , m 3) ∈ R t ⇒ (m 1 , m 3) ∈ R t

sau altfel exprimat:

R t * R t ≤ R t

Relatia Conexa

R x ⊆ M x M

- proprietate:

(m 1 , m 2) ∈ R x sau inclusiv (m 2 , m 1) ∈ R x

3.1.2.6.2.1 Tipuri de Relatii Binare pe Aceeasi Multime

3.1.2.6.2.1.1 Relatia de Echivalenta

Relatia de Echivalenta este o Relatie Binara cu urmatoarele proprietati:

§ Reflexivitate

§ Simetrie

§ Tranzitivitate

Multimea tuturor Echivalentelor pe o multime data M se noteaza cu E ( M ) si se bucura de proprietatea:

E ( M ) ⊆ P ( M x M ) .

Clasa de Echivalenta a Elementului m ∈ M fata de Echivalenta E e data de Multimea:

56 Concepte de Baza / Relatii între Multimi

[ m ] E = m 1 | m E m 1 .

Reprezentant al Clasei de Echivalenta se considera a fi:

∀ m ∈ [ m ] E

Multimea Cât , se noteaza M | E si reprezinta Multimea Claselor de Echivalenta ale tuturor Elementelor unei Multimi M fata de o Echivalenta E:

M | E = [ m ] E | ∀ m ∈ M

Cardinalul Multimii Cât este o masura a Gradului de Omogenitate al unei Multimi M fata de o Echivalenta E.

Pe baza definitiei Claselor de Echivalenta, [ m ] E , pot fi demonstrate urmatoarele proprietati ale acestora:

- Clasele de Echivalenta formeaza o Acoperire pe Multimea de Definitie M:

∪ [m] E = M

Rezulta din proprietatea de Reflexivitate a Echivalentei:

∀ m | m E m

- Clasele de Echivalenta formeaza o Partitie pe Multimea de Definitie M:

[m 1] E ∩ [m 2] E = ∅ , pentru (m 1 , m 2) ∉ E

Rezulta din proprietatea de Tranzitivitate a Echivalentei :

Daca:

∃ m | m ∈ [ m 1] E si m ∈ [ m 2] E

Atunci:

(m 1 , m 2) ∈ E.

Reciproc : Orice Partitie pe o Multime data M determina o Relatie de Echivalenta E pe aceasta multime.

3.1.2.6.2.1.2 Relatii de Ordine

Relatia de Ordine este o Relatie Binara cu urmatoarele proprietati:

§ Reflexivitate

§ Antisimetrie

§ Tranzitivitate

Importanta relatiilor de Ordine consta în faptul ca ele permit introducerea conceptului de Multime Ordonata, definita ca o pereche ordonata:

Concepte de Baza / Relatii între Multimi 57

- O Multime - M - O Relatie de Ordine - O

M o ≡ ( M , O )

Acest concept este preluat de Modelul Relational de organizare a datelor prin urmatoarele restrictii implicite:

o Orice Colectie de Date este privita ca o Multime (de tuple, sau înregistrari), deci neordonata

o Cu ajutorul acestor Colectii de Date, care constituie Structura de Baza a Modelului de Date, se poate construi, utilizând conceptul de Relatie, orice structura de date oricât de complexa

o Toti Operatorii implementati pe aceasta Structura de Baza nu pretind existenta prealabila a unei Ordini

o Ordonarea Colectiilor de Date se face prin adaugarea unor Structuri Auxiliare de date (Indecsi), care folosesc exclusiv pentru ridicarea performantelor de prelucrare (la Identificare, Acces sau Ordonare) si nu la construirea structurilor de date

o Unei Colectii de Date i se pot adauga oricâti Indecsi transformând-o în tot atâtea Colectii Ordonate, care dispar odata cu eliminarea structurilor auxiliare atasate, ceea ce confera un caracter dinamic procesului de ordonare

o Procesul de Navigare în aceste Colectii de Date ramâne si el dinamic prin posibilitatea modificarii Ordinii de Inspectie prin simpla înlocuire a Indexului Activ pe parcursul navigarii

In functie de proprietatile suplimentare care se adauga proprietatilor de baza ale Relatiei de Ordine se pot defini mai multe Tipuri de Relatii de Ordine:

§ Relatii de Ordine Partiala

§ Relatii de Ordine Totala

§ Relatii de Bine Ordonare 3.1.2.6.2.1.2.1 Relatia de Ordine Partiala

O Relatie de Ordine fara alte restrictii suplimentare se zice Relatie de Ordine Partiala – O P . Denumirea provine din faptul ca proprietatile exprimate fac ca relatia sa nu se extinda asupra tuturor Elementelor Multimii.

Ca exemplu tipic de relatie de Ordine Partiala este:

“ Multimea partilor unei multimi P ( M ) , care e partial ordonata prin relatia de Incluziune a Partilor. “

In cadrul structurii generate de apartenenta Partilor la o Multime data, alaturi de raporturile de Incluziune, care sunt ordonate de legatura Ascendent – Descendent, extinsa pe toate nivele de imbricare ale submultimilor, este prezenta si legatura de Echivalenta între

58 Concepte de Baza / Relatii între Multimi

submultimile sau elementele aflate pe acelasi nivel si între care, neexistând prioritate, nu exista nici relatie de ordine.

O Multime Partial Ordonata este o pereche ordonata ( M , O P ) , unde:

§ M – Multime

§ O P – Relatie de Ordine Partiala

In exemplul dat, multimea Partilor unei Multimi, privita ca Multime Ordonata, se defineste prin cuplul (P ( M ) , I ) , unde:

§ P ( M ) - Multimea Partilor lui M

§ I - Relatia de Incluziune definita de:

( p 1 , p 2 ) ∈ I ⇒ “ Multimea Parte p 1 include Multimea Parte p 2 “

3.1.2.6.2.1.2.2 Relatia de Ordine Totala

O Relatie de Ordine Partiala care se extinde asupra tuturor elementelor Multimii M, se zice Relatie de Ordine Totala – O T . O relatie de Ordine Totala îndeplineste, fata de relatia de Ordine Partiala, urmatoarea conditie suplimentara:

∀ m 1 , m 2 ∈ M ⇒ m 1 O T m 2 sau exclusiv m 2 O T m 1

(sau e Exclusiv întrucât relatia ramâne Antisimetrica)

Conditia suplimentara putea fi exprimata si în forma:

O T ∪ O T -1 = R T

unde:

R T e Relatia Totala (Puterea Carteziana a Multimii M)

Ca exemplu reprezentativ de Relatie de Ordine Totala este:

“ Multimea Numerelor Reale - R , care e Total Ordonata prin relatia Naturala de Ordine - O N . “

o Relatia Naturala de Ordine se poate exprima între oricare doua Numere Reale.

O Multime Total Ordonata este o pereche ordonata (M , O T ) , unde:

§ M – Multime

§ O T – Relatie de Ordine Totala

In exemplul dat, Multimea Numerelor Reale, privita ca Multime Ordonata, se defineste prin cuplul (R , O N ) , unde:

§ R - Multimea Numerelor Reale

§ O N - Relatia Naturala de Ordine definita de:

Concepte de Baza / Relatii între Multimi 59

( r 1 , r 2 ) ∈ O N ⇒ “ numarul r 1 ≤ numarul r 2 “

Se verifica:

∀ r 1 , r 2 ∈ R ⇒ r 1 ≤ r 2 sau exclusiv r 2 ≤ r 1

3.1.2.6.2.1.2.3 Relatia de Bine Ordonare

O Relatie de Ordine Totala care are un Element Cel Mai Mic, se zice Relatie de Bine Ordonare – O B . O Relatie de Bine Ordonare îndeplineste, fata de Relatia de Ordine Totala, urmatoarea conditie suplimentara:

∀ M 1 ⊂ M , M 1 # ∅ ⇒ ∃ m 1 ∈ M 1 | ∀ m ∈ M 1 , m 1 O T m

Altfel exprimat:

“ Pentru orice Submultime Nevida din M, exista un Element Cel Mai Mic. “

Ca exemplu reprezentativ de Relatie de Bine Ordonare este:

“ Multimea Numerelor Naturale - N , care e total ordonata prin relatia Naturala de Ordine - O N . “

Fata de Multimea Numerelor Reale, în Multimea Numerelor Naturale se poate întotdeauna gasi un Numar Cel Mai Mic.

O Multime Bine Ordonata este o pereche ordonata ( M , O B ) , unde:

- M – Multime

- O B – Relatie de Bine Ordonare

In exemplul dat, Multimea Numerelor Naturale, privita ca Multime Ordonata, se defineste prin cuplul (N , O B ) , unde:

- N - Multimea Numerelor Naturale

- O B - Relatia Naturala de Ordine definita de:

( n 1 , n 2 ) ∈ O B ⇒ “ numarul n 1 ≤ numarul n 2 “

se verifica:

∀ r 1 , r 2 ∈ R ⇒ r 1 ≤ r 2 sau exclusiv r 2 ≤ r 1

si

“ în orice submultime de numere exista un numar cel mai mic “

3.1.2.6.2.1.3 Relatia de Similitudine (”Asemanare”)

Relatia de Similitudine este o Relatie Binara cu urmatoarele proprietati:

o Reflexivitate

60 Concepte de Baza / Grafuri si Arbori

o Simetrie

O relatie de Similitudine Tranzitiva devine Relatie de Echivalenta.

3.1.3 Relatii, Aplicatii, Functii

Relatia generalizeaza notiunile de Aplicatie si Functie, concepte de baza în matematica.

O Functie pe o multime DD cu valori în DV este o Relatie Unica la Dreapta cu Suportul DD si Domeniul Valorilor DV:

F = (x,y) ∈DD x DV | (x,y) ∈ R ud .

Daca nu impunem conditia de Relatie Unica la Dreapta, ajungem la definirea mai generala a Aplicatiilor cu particularitatile lor:

- Aplicatii Injective – aplicatii din DD în DV – când Suportul relatiei atasate e întregul DD

- Aplicatii Surjective – aplicatii din DD pe DV – când Domeniul Valorilor relatiei atasate e întregul DV

- Aplicatii Bijective – aplicatii ce sunt Relatii Biunice

Particularizând aceste proprietati în cazul Functiilor obtinem:

- Functiile Injective – sunt Relatii Unice la Stânga si ca urmare, pe baza definitiei Functiilor ca Relatii Unice la Dreapta, sunt totodata si Functii Injective si, în final, sunt Functii Bijective (Biunivoce sau Inversabile)

- Functiile Inverse notate F –1 sunt definite pe o multime DV cu valori în DD

F –1 = ( y,x ) ∈DV x DD | ( x,y ) ∈F

astfel încât orice Element din DD are o Imagine Inversa Unica în DD si Inversa unei Functii Bijective este tot Bijectiva.

3.1.4 Grafuri

Prezentarea notiunii de Graf si a celor atasate acestuia se face întrucât reprezentarea Structurilor de Informatii si de Date cu ajutorul Grafurilor este foarte frecvent întâlnita în disciplina de Baze de Date. 3.1.4.1 Graful ca Relatie

In forma cea mai generala Graful poate fi definit ca o Relatie pe un Produs de Multimi:

G ⊆ ∏ M i

Concepte de Baza / Grafuri si Arbori 61

In aceasta viziune Graful e privit nu doar ca o Multime de Arce ce leaga Perechi de Vârfuri, ci si ca un set de alte caracteristici atasate Arcelor si Vârfurilor ce intra în legatura (Intensitati, Debite, Fluxuri, Rezistente etc.).

In Teoria Grafelor notiunea de Graf se obtine prin particularizarea definitiei de mai sus:

§ Graful e definit de o Relatie Binara

§ Relatie Binara e definita pe o Singura Multime

§ Multimea de Definitie a Relatiei e Numarabila

3.1.4.2 Graful ca Aplicatie

Definitia I - a:

Graful e reprezentat de expresia:

G = (X , T)

si contine:

o O Multime Nevida de Elemente X

o O Aplicatie T a lui X în Multimea Partilor lui X

T : X → P ( M )

Definitia a II - a:

Graful e reprezentat de expresia:

G = (X , U)

si contine:

o O Multime Nevida de Elemente X numite Vârfuri sau Noduri:

X = x 1 , x 2 , .. , x n

o O Multime de Perechi de Elemente U:

Neordonate x i , x j – numite Muchii (neorientate)

cu x i , x j - Extremitati

sau

Ordonate ( x i , x j ) - numite Arce (orientate)

cu x i - Origine si x j - Extremitate

62 Concepte de Baza / Grafuri si Arbori

Intr-un Graf Orientat, G = ( X , U ) pot fi definite urmatoarele elemente:

- Succesor al unui Vârf x i – toate Vârfurile x j pentru care exista Arcele (x i, x j)

- Predecesor al unui Vârf x i – toate Vârfurile x j pentru care exista un Arc de forma (x j, x i )

- Vârfuri Adiacente – doua Vârfuri legate printr-un Arc

- Drum Orientat – o Succesiune de Vârfuri Adiacente (x 1 , x 2 , .. , x d-1 , x d )

astfel încât:

(x 1 , x 2) , (x 1 , x 2) , .. , (x d-1 , x d) ∈ U

- Circuit– un Drum Orientat în care Extremitatea ultimului Arc coincide cu Originea primului Arc

- Graf Tare Conex – un Graf Orientat în care fiecare Cuplu de Vârfuri defineste un Drum Orientat

- Lungime de Drum – Numarul Arcelor unui Drum

- Bucla – un Drum de Lungime 1

- Descendent al unui Vârf x i – toate Vârfurile x j din G astfel încât sa existe un Drum Orientat de la i la j

- Ascendent al unui Vârf x i – toate Vârfurile x j din G astfel încât sa existe un Drum Orientat de la j la i

In cazul unui Graf Neorientat definitiile anterioare ramân valabile facând urmatoarele substitutii:

• Arc cu Muchie

• Circuit cu Ciclu

• Graf Tare Conex cu Graf Conex

3.1.4.3 Arbori

Arborii reprezinta cazuri particulare de Grafuri, adica Grafuri având proprietati

suplimentare, pe care le prezentam în continuare:

- Arbore – un Graf Conex care are un singur Vârf, numit Radacina, fara nici-un Ascendent

- Vârf Terminal – toate Vârfurile unui Arbore care nu au nici-un Descendent

- Nivelul unui Vârf – Lungimea Drumului între Radacina si Vârf

- Subarbore al unui Arbore – un Arbore a carui Radacina are un Ascendent într-unul din Vârfurile Arborelui în care e continut

- Padure de Arbori – o Multime Ordonata de Arbori (exemplu: multimea Subarborilor unui Arbore )

Concepte de Baza / Grafuri si Arbori 63

Structurile de Date ale Bazelor de Date Fizice se aliniaza la caracteristicile Padurii de Arbori, datorita prezentei obligatorii a Relatiilor de Incluziune, care genereaza Partitiile necesare în Multimea de Instante ale Claselor de Entitati (Ex. Produsele contractate de Beneficiari, Unitatile unei Structuri Organizatorice pentru care sunt definite alte Resurse etc.)

Fig. 3.1.4.1 Reprezentarea Recursiva a structurii unui Arbore

Definitiile de mai jos introduc termeni specifici structurilor de date din Sistemele cu Baze de Date, cum sunt Arborele Simplu si Arborele Invers si care forteaza în anumite limite rigoarea definirii matematice, ramânând însa suficient de clare pentru a putea fi utilizate în practica fiind de asemenea prezente si în literatura de specialitate.

- Arbore Simplu – un Arbore în care toate nodurile, cu exceptia Radacinii, au un singur Ascendent

Proprietatile Arborilor Simpli:

§ într-un Arbore Simplu între oricare doua Vârfuri exista un singur Drum

§ într-un Arbore Simplu daca se exclude Radacina, celelalte Vârfuri pot fi împartite într-un numar de multimi disjuncte de Vârfuri, fiecare multime alcatuind la rândul ei un Arbore, numit Subarbore al Arborelui initial

S3 S2 S1

R

A

Subarbore → Arbore (Apel Recursiv)

A - Arbore R – Radacina S – Subarbore

64 Concepte de Baza / Grafuri si Arbori

- Arbore Invers – un Arbore care are cel putin un Vârf cu mai mult de un Ascendent

Arborele Invers preia denumirea de la aparitia unei Ierarhii de Ascendenta (mai multi Asscendenti pentru un Descendent), alaturi de Ierarhia de Descendenta (mai multi Descendenti pentru un Ascendent)

Cea mai importanta Proprietate a Arborelui este Structura sa Recursiva. Ea este pusa în evidenta atât de definirea structurii de Arbore utilizând Reguli de Descriere, cât si din reprezentarea grafica din Fig. 3.1.4.1.

Arbore → Radacina Subarbore 1 , Subarbore 2 ,.., , Subarbore i

Subarbore → Arbore

Avantajele utilizarii Proprietatii de Recursivitate a structurilor de tip Arbore sunt multiple. Enumeram câteva:

- Concentrarea Definirii Logice a structurilor de date - Reducerea numarului de Structuri Fizice Memorate - Simplificarea Interfetelor Utilizator pentru actualizarea datelor - Utilizarea Procedurilor Recursive de Traversare a Arborilor

Problema tratarii Recursivitatii este deosebit de importanta si pentru Limbajele de Manipulare a Datelor. Limbajele Neprocedurale utilizate în Bazele de Date nu dispun de facilitatea de recursivitate, ceea ce a determinat Extensiile Limbajelor de Manipulare a Datelor (ex. PL SQL), care sa permita apelul la Limbajele de Navigare pentru Traversarea Arborilor. Exista trei forme de Inspectie a Arborilor (Parcurgere a Arborilor), numita si Traversare a Arborilor:

- Parcurgere în Preordine – Utilizata pentru Listarea Structurii prin transformare Structurii Arborescente în structura Secvential - Ierarhizata

Radacina, Subarbore Stâng, Subarbore Drept

- Parcurgere în Endordine – Utilizata pentru Acumularea Informatiei din Descendenti în Ascendent (ex. Proceduri de Centralizare)

Subarbore Stâng, Subarbore Drept, Radacina

- Parcurgere în Postordine – Utilizata pentru Transferul Informatiei între Descendenti cu consultarea Ascendentului

Subarbore Stâng, Radacina, Subarbore Drept

Traversarea Arborilor reprezinta proceduri laborioase, care devin adesea neadecvate consultarii interactive a Bazelor de Date. Aceste proceduri pot fi cu succes înlocuite de alte metode de calcul:

o Ridicarea recursivitatii prin Liniarizarea Structurii

o Materializarea datelor prin Functii de Calcul încorporate în Proceduri Stocate.

Structurile de tip Arbore sunt utilizate în Bazele de Date si pentru Generarea Automata a Codurilor Structurate, eliminând operatiile laborioase de întocmire a Cataloagelor de Obiecte, carora sa li se ataseze manual coduri ce trebuie si gestionate în continuare.

Concepte de Baza / Informatie si Data 65

3.2 Informatie si Data

Clarificarea notiunilor de Informatie si Data, precum si a raportului dintre ele constituie un demers necesar înaintea oricarei dezbateri care îsi propune tratarea problemelor legate de Construire a Structurilor de Informatii si de Date, de Prelucrare Automata sau Manuala a acestora, de Optimizare a Structurilor, de legatura a lor cu Procedurile de Prelucrare, si în final de stabilire a utilizarii lor cât mai profitabile în practica.

Investigatia este cu atât mai necesara cu cât , având de a face cu Notiuni Primare, se poate vorbi mai degraba despre acceptiuni ale acestor concepte, despre Modele preferate în definirea lor, decât despre adoptarea unor Definitii unanim recunoscute de catre specialisti.

Întrucât se poate considera ca Teoria Informatiei se constituie în primul rând ca o suma de Concepte si Modele - întelegând prin Model, o aproximare a unei realitatii prin postularea unor prezumtii - problema care se pune este alegerea unui model adecvat studiului întreprins. In cazul nostru vom cauta sa alegem acele Modele care slujesc cel mai bine Descrierii cu ajutorul Structurilor de Informatii si Date a domeniilor specifice Sistemelor cu Baze de Date, deci cele care vizeaza memorarea, regasirea, transmiterea si prelucrarea avantajoasa a Volumelor de Informatii si de Date, folosind tehnica sistemelor de calcul.

Utilizata în stiinta si tehnica, informatia e greu de definit în toata complexitatea sa. In legatura cu definirea riguroasa a notiunii de Informatie, cercetatorul W. R. Ashby [ASBY56] afirma:

" Evolutiile în aceste regiuni sunt ca deplasarile într-o jungla plina de gropi-capcana. Cei care stiu cel mai mult despre aceste subiecte sunt si cei mai precauti când vorbesc despre ele. "

Fig. 3.2.1. Reflectarea realitatii prin informatii

Pornind de la schema ilustrata de Fig. 3.2.1, în care se reprezinta relatia existenta între Realitatea înconjuratoare si Imaginea reflectata în constiinta unui Observator, Informatia poate fi privita ca o Notiune Primara ce sta la baza procesului de cunoastere, bazat pe

I M A G I N E reflectata

preluare de informatii

prelucrare de informatii

particula de materie particula de reflectare

R E A L I T A T E înconjuratoare

66 Concepte de Baza / Informatie si Data

activitatea de Reflectare a Realitatii prin Contemplare si Meditatie. Informatiile reprezinta metaforic Caramizile cu ajutorul carora constiinta Observatorului recladeste Realitatea din Fapte culese, îmbogatind-o cu Adevaruri Nepercepute si completând-o apoi cu Lumi Imaginate, Deduse sau Închipuite, ce pot în final sa fie comparate cu Realitatea Înconjuratoare.

Pentru a defini acceptiunea notiunii de Informatie, ce va fi folosita în continuare, vom apela la trei schite de Modele de Definire, pe care le vom prezenta succint în cele ce urmeaza:

• Modelul Matematic

• Modelul Semiotic

• Modelul Propozitional

Modelul Matematic reprezinta punctul de plecare în definirea oricarui Model Specific adoptat pentru descrierea Informatiei. Aceasta datorita formularilor cantitative precise, care ofera exactitate conceptelor introduse. Modelul Semiotic la care se va apela apoi va permite precizarea proprietatilor de natura calitativa ale notiunii de Informatie. Ultimul model conturat, Modelul Propozitional, este cel mai adecvat activitatii de Prelucrare a Informatiilor si Datelor, fiind utilizat în special pentru stabilirea diferentelor si asemanarilor dintre conceptele de Informatie si Data. 3.2.1 Modelul Matematic

Modelul Matematic, elaborat de Hartley si generalizat de Shannon urmareste determinarea în exprimare cantitativa a Masurii Gradului de Nedeterminare pe care îl contin Sistemele Complete de Evenimente. Pornind de la exprimarile calitative:

" Informatia este ceea ce elimina o Nedeterminare

sau,

" Informatia este o Nedeterminare Înlaturata" ,

se încearca obtinerea expresiei cantitative a Masurii Gradului de Nedeterminare a unui Sistem Complet de Evenimente.

Prin Sistem Complet de Evenimente se întelege:

Orice Proces X cu n Stari distincte,

sau:

Orice Experiment X cu n Rezultate distincte,

în care sunt cunoscute: n - întreg si pozitiv p(x i) - Probabilitatile de realizare ale starilor

astfel încât :

∑ =≤≤n

1

1)( si 1)(0 ii xpxp

Concepte de Baza / Informatie si Data 67

Daca se noteaza cu:

Ex - Masura Gradului de Nedeterminare,

altfel exprimat:

Cantitatea Medie de Informatie obtinuta prin cunoasterea starii x i

sau:

Entropie Informationala

atunci expresia:

Cantitatii Medii de Informatie obtinuta prin cunoasterea Starii x i

este data de formula lui Shannon :

∑n

1=i

i in 21 p log p - = ) p , ... , p , p ( E 2

Pentru Evenimente Echiprobabile si n = 2 , Hartley, pornind de la expresia:

BI = n

unde : n - Numarul Starilor

B - Baza Procesului de Cautare prin Divizare I - Cantitatea de Informatie

si de la alegerea unui sistem cu n = 2 Stari, obtine expresia:

Cantitatii Elementare de Informatie:

I0 = - log2 1 / 2 = 1 .

3.2.2 Modelul Semiotic

In cadrul Modelul Semiotic se releva aspecte calitative semnificative ale notiunii de Informatie si anume cele legate de cele trei elemente care intervin în Procesul de Reflectare:

- Observatorul ca Interpretor de Mesaj

- Sensul în calitate de Continut ce urmeaza a fi transmis, prelucrat sau memorat

- Semnul ca Forma Purtatoare a Sensului

Ca urmare Informatia va putea sa fie privita din urmatoarele puncte de vedere :

- Unul Pragmatic - legat de modul în care Observatorul interpreteaza continutul informational al mesajului

68 Concepte de Baza / Informatie si Data

- Unul Semantic - legat de Continutul Informatiei, deci de Sensul acordat mesajului

- Unul Sintactic - legat de Forma mesajului care transmite Informatia prin Semne

Referitor la aspectele calitative ale Informatiei, mentionam rezultatele publicate în lucrarea [IRIM82] de profesorul clujean Ion Irimie, în care autorul recurge la o Definire prin Caracteristici a Informatiei. Dupa ce preia definirea cantitativa din Modelul Matematic, autorul considera ca definitorii pentru Informatie urmatoarele însusiri:

§ Opus al Nedeterminarii

§ Nota Calitativa a Comunicarii Neredondante

§ Factor Antientropic

§ Neenergie

In ciuda formularii negative a ultimei caracteristicii, care se cere de altfel completata cu definitia Informatiei din Modelul Matematic si care intervine în prima însusire selectata, retinem modelul propus pentru urmatoarea observatie concluziva facuta de autor:

“ Ultimul continut (nenenrgie) devine prioritar prin aceea ca el caracterizeaza cel mai bine specificul informatiei ca entitate de sine statatoare. Informatia ramâne informatie si când este redondanta 100%, caz în care eliminarea nedeterminarii ramâne potentiala sau când, prin abatere de la regula, ea genereaza efecte entropice (prin utilizarea ei eronata în orientarea prin decizie a conduitei ). “

Redam si definitia finala la care se opreste autorul:

“ Informatia este entitatea existentiala, care, pe fondul reflectarii, se naste în contextele situatiei semiotice, se instituie în câmpul semnelor si / sau al semnalelor si devine continut si esenta a oricarei comunicari. “

3.2.3 Modelul Propozitional

Modelul Propozitional este dezvoltat ca o particularizare a celorlalte modele prezentate, fiind considerat ca fiind cel mai adecvat pentru studiul Structurilor de Informatii si Date si pentru prelucrarea acestora, în special cu mijloace automate. Asemenea modelului anterior, el preia definirea cantitativa a informatiei din modelul matematic, urmarind sa realizeze particularizarea ei sub aspect calitativ.

In acest model Informatia este definita ca:

O eliminare de Nedeterminare prin formularea unei Propozitii.

Informatia este un cuplu Subiect - Stare (sau Însusire ) rezultat prin selectarea unei Stari (Însusiri) constatate, din multimea Starilor (Însusirilor) posibile si atasarea ei Subiectului aflat în discutie.

Întocmai ca si Propozitiile, Informatiile pot fi simple sau compuse, Informatia Simpla fiind acea care nu se mai poate descompune în alte informatii, indiferent de cantitatea de informatie pe care o poarta.

Concepte de Baza / Informatie si Data 69

Data este Forma de Reprezentare a Informatiei în vederea transmiterii, înmagazinarii si prelucrarii ei.

Datele constituie Suportul Informatiilor. Fiecare Data semnifica o Informatie prin cuplul care se stabileste între Numele Datei, alcatuind Subiectul si Valoarea Datei, reprezentând Însusirea.

Aceleiasi Informatii îi pot corespunde diferite forme de reprezentare prin Date, care pot diferi fie prin Formatul de Reprezentare al Valorilor, fie prin Numele Datelor, fie prin ambele. Tab. 3.2.3.1 reda un exemplu sugestiv de reprezentare cu ajutorul Datelor diferite a aceleiasi Informatii: ”Cantitatea-Livrata este 100”.

Data Informatie

Nume Valoare

Observatii

Cantitate 100 Tipul Datei: Întreg

CantLiv 100 Tipul Datei: Întreg Zecimal

Cantitate 1100100 Tipul Datei: Binar

CL 64 Tipul Datei: Hexazecimal

Cantitatea-Livrata este 100

Cantitate ’Suta’ Tipul Datei: Sir de Caractere

Tab. 3.2.3.1 Reprezentarea Informatiei prin Data

Valorile Datelor vor reprezenta o Informatie numai în momentul în care sunt atasate unor Nume de Date.

Informatia se constituie în plan Semantic, reprezentând Sens, în timp ce Data se constituie în plan Sintactic, reprezentând Semn.

Relatiile între Informatii reprezinta ele însele noi Informatii. Din punct de vedere al naturii acestor Relatii ele pot fi de doua feluri:

- Relatii de Dependenta (Relatii de Echivalenta sau Incluziune) - aceste relatii, specifice proceselor de clasificare, apar ca însusiri reciproce a doua sau mai multe Subiecte (Informatii corespunzatoare Predicatelor Poliadice), fiind apoi transferate, în Sfera Datelor, asupra Numelor de Date, caracterizând raporturile existente între acestea. Exemplu: Structura Ierarhica definita pin Nume (de Entitati si de Atribute):

BEEFICIAR (Cod, Nume, ADRESA (Oras, Strada, Numar))

Conduce la Structura Ierarhica de Instantiere, definita pin Valori:

Beneficiar 1 - c1, n1, o1, s1, n1

Beneficiar 2 - c2, n2, o2, s2, n2

Beneficiar 3 - c3, n3, o1, s3, n3

..

70 Concepte de Baza / Informatie si Data

Beneficiar n - cn, nn, o1, sn, n3 Unde regasim urmatoarele elemente:

§ Nume de Entitati – BEEFICIAR, ADRESA

§ Nume de Atribute – Cod, Nume, Oras, Strada, Numar

§ Nume de Instante – Beneficiar 1 , Beneficiar 2, ..

§ Valori de de Atribute – c1, n1,o1, s1, n1, c2, n2,o2, s2, n2, ..

§ Valori (Instante) de Entitati – c1, n1,o1, s1, n1, c2, n2,o2, s2, n2 ..

- Relatii de Identitate si de Relatii de Ordine Naturala - aceste relatii apar între Însusiri, respectiv Valori ale Datelor, putându-se apoi transfera si asupra Subiectelor, respectiv a Numelor de Date Exemplul 1 – Relatie de Ordine transferata Sa ordonam Beneficiarii din structura anterioara dupa Oras:

Beneficiar i| Oras i = ’ o1’ ≡ Beneficiar 1, Beneficiar 3, .. , Beneficiar n

Beneficiar j| Oras j = ’ o2’ ≡ Beneficiar 2

Exemplul 2 – Relatie de Identitate transferata Sa consideram o structura de Societati – Partenere (vezi Fig. 4.2.4.8.2.2.5). Fiecare SOCIETATE poate fi privita ca Producator, Beneficiar si / sau Furnizor. Dorim sa identificam SOCIETATILE care au ca Furnizori si Beneficiari acelasi PARTENER. Este suficient sa testam Egalitatea Valorilor Atributului Societate din PARTENER care refera asociativ o SOCIETATE pentru Tipuri diferite de PARTENER (Furnizor si Beneficiar) si sa transferam Egalitatea acestor Valori asupra Identitatii Entitatilor SOCIETATI (Nume de Instante de Societati).

PARTENER i . Societate = PARTENER j . Societate si PARTENER i . Partener (Conditie de Furnizor) = PARTENER j . Partener (Conditie de Beneficiar) ⇒

SOCIETATE m (Conditie de Partener pentru PARTENER i) ≡ SOCIETATE n (Conditie de Partener pentru PARTENER j)

In problema diferentei existente între Informatie si Data consideram ca foarte expresiva si concisa formularea data de cercetatorul Bo Sundgren în [SUND75], pe care o retranscriem:

“ Daca o persoana aranjeaza intentionat un obiect al realitatii ca sa-l reprezinte pe celalalt, acest aranjament se denumeste Data. Cel mai adesea Data reprezinta:

- în primul rând o Cunostinta umana (Informatie)

- doar secundar, Obiectul Propriuzis din realitate care este el .“

In proiectarea Structurilor de Informatii si Date se convine sa se numeasca descrierea unei realitati cu ajutorul informatiilor ca facând parte din Spatiul Informatiilor, iar modelarea cu ajutorul datelor a unei descrieri prin informatii deja definite, se considera ca apartine Spatiului Datelor. Totodata, atât în Spatiul Informatiilor cât si în Spatiul Datelor, descrierea cu ajutorul Numelor se considera ca apartine Nivelului Logic sau Conceptual de reprezentare, în timp ce descrierea cu ajutorul Valorilor se considera ca apartine Nivelului Fizic de reprezentare.

Concepte de Baza / Date si Proceduri 71

3.3 Date si Proceduri

Prezentarea Antinomiei Date-Proceduri apare motivata daca avem în vedere faptul ca diferentierea Sistemelor cu Baze de Date de Sistemele Clasice a fost conturata odata cu Separarea Datelor de Proceduri (vezi sectiunea 2.1), caracteristica mentinuta ca dominanta. Sa analizam pentru început principala opozitie dintre aceste doua elemente ale prelucrarii automate a datelor:

§ Datele reprezinta Partea Statica a cestui proces – descriu Starile sistemului la un moment date, jalonând totodata evolutia acestuia prin descrierea stadiului în care el a ajuns

§ Procedurile reprezinta Partea Dinamica a aceluiasi proces – descriu Transformarile care intervin în cadrul sistemului prin intermediul Secventelor de Operatii

Exista doua viziuni diferite ale procesului de prelucrare a datelor:

o Viziunea Sistemelor Clasice – descrierea Datelor precum si a Procedurilor sunt elementele constitutive ale unitatilor de prelucrare, denumite cel mai general Programe

o Viziunea Sistemelor cu Baze de Date – descrierea Datelor este separata de descrierea Procedurilor, prin Zone Specializate de depozitare a descrierierilor, Limbaje Dedicate fiecarui scop, Caracteristici individualizate pentru fiecare sectiune

Câstigurile unei asemenea viziuni devin remarcabile, fiind grupate sub numele de – Independenta Datelor fata de Proceduri:

§ Specializarea Instrumentelor de Lucru

§ Specializarea Personalului însarcinat cu functiile de Conceptie, Proiectare, Dezvoltare si Întretinere :

• Colective de Administrare a Structurilor de Date

• Colective de Proiectare a Procedurilor si Aplicatiilor

• Colective de Implementare a Sistemelor de Aplicatii

§ Specializarea Unitatilor de Executie (Statii Server, Statii Client)

Nu trebuie neglijat faptul ca aparitia ideii de separare a fost sustinuta si de unele Limbaje Clasice de Programare (Limbajele de Programare folosite în Gestiunea Economica). Actiunea este însa partiala deoarece separarea se efectueaza doar în cadrul sectiunilor de program, fara existenta unui Dictionar al Datelor. De aici deriva si amestecarea Datelor Interne (Variabilele de Program) cu Datele din Baza de Date (Atribute – Câmpuri de Date). Ceea ce constituie o caracteristica specifica procedurilor în Sistemele cu Baze de Date este renuntarea la Variabilele de Program (utilizate de obicei ca Variabile de Conditie - Switch-uri sau Variabile de Marcare - Flag-uri). Necesitatea utilizarii lor denota în cele mai multe cazuri o insuficienta populare cu Atribute a Structurii de Date din Baza de Date, fapt ce va fi resimtit, mai devreme sau mai târziu în utilizarea BD.

72 Concepte de Baza / Date si Proceduri

Asemanarea elementelor Date – Proceduri este tot atât de importanta în Sistemele cu Baze de Date. Ea se manifesta în urmatoarele privinte:

o Datele pot fi privite ca Stari Curente – sunt definite declarativ (prin precizarea unei Valori Memorate). In aceasta forma Datele sunt întotdeauna tratate ca Date Reale, date existente în Baza de Date.

o Procedurile pot fi privite ca Stari Viitoare – sunt definite functional (prin precizarea unei Functii de Calcul). Valoarea rezultata din calcul poate fi Memorata, luând forma de Data Reala (Redondanta) sau numai Afisata, înfatisându-se ca Data Virtuala (Data care se Instantiaza la Cerere). In aceasta definire Procedurile reprezinta, prin ele însele, Date Virtuale. Functiile de Calcul vor fi în fiecare caz Memorate în Baza de Date si sub aceasta forma ele constituie Date Potentiale. Doar din motive de performanta (economie de timp de calcul) Rezultatele pot fi Memorate, caz în care implica prezenta Redondantei în Baza de Date, cu posibile inconsistente (daca Procedurile de Calcul nu sunt Declansate si Controlate Automat). Se mai poate remarca faptul ca facilitatea de definire functionala a datelor este implementata foarte natural, Functia de Calcul putând fi reprezentata de orice tip de Procedura (Program sau Fragment de Program si chiar Secvente de Operatii sau simple Expresii de Calcul).

Pentru ca demersul de acceptare a Procedurilor în familia de Stari Descriptoare ale unui sistem sa fie consemnat mai lipseste un element si acesta este Momentul de Declansare a Procedurilor. Acest moment va fi ales din multimea Evenimentelor pe care sistemul de procesare (Mediul de Programare le recunoaste). Se impune concluzia conform careia Procedurile pot fi privite ca Date în Devenire doar în Mediile de Programare Orientate pe Evenimente. Majoritatea mediilor Client actuale se bucura de asemenea facilitati. Începând cu atasarea Fragmentelor de Proceduri (Snippets) la diferite momente de prelucrare a datelor de intrare (memorate în Componenta Client) si continuând cu Trrigerii si Procedurile Stocate (vezi sectiunea 4.2.4.7.5) memorate direct în Baza de Date, toate acestea reprezinta implementari de Proceduri Declansate pe Eveniment si prin aceasta creeaza mediul prielnic de transpunere în realitate a conceptelor prezentate anterior, ce pot parea la prima vedere Pedanterii Academice.

Apropierea Procedurilor de Date face un salt important în construirea unei Viziuni Structuraliste asupra procesului de prelucrare a datelor. Datele si Procedurile sunt privite ca Stari (Caramizi) din care se construieste sistemul. Completarea ideilor structuraliste este facuta în sectiunea Structuri de Proceduri. Unghiul de abordare va fi însa diferit. El va încerca sa sublinieze, în acel context, necesitatea coborârii conceptului de Structura si în interiorul Procedurilor, pentru ca apoi sa se arate aportul Sistemelor cu Baze de Date în sprijinirea procesului de Structurare a Procedurilor, pornind de la Structura Datelor supuse prelucrarii. Paralela între cele doua structuri este cu atât mai necesara cu cât în Sistemele cu Baze de Date Procedurile vor migra în Modelul de Date, fiind tot mai frecvent atasate, sub forma Fragmentelor de Proceduri, anumitor Structuri de Date, si ramânând definite ca Entitati de sine statatoare (Obiecte) în Baza de Date. Dar si atunci când ele vor fi destinate prelucrarii Cursorilor generati prin Denormalizarea Relatiilor, Structura de Provenienta a acestora va trebui sa ghideze Structura Procedurilor atasate, pentru a usura construirea si depanarea lor.

Structuri de Informatii si Date / Structura, Organizre si Acces 73

3.4 Structuri de Informatii si Date 3.4.1 Structura, Organizare si Acces

Spunem ca un ansamblu e Structurat atunci când Multimea sa de Elemente poate fi privita ca o Multime de Multimi. Altfel exprimat: Orice recunoastere într-o Multime a unei legaturi de Echivalenta sau Incluziune, alta decât cea primara de apartenenta a elementelor la multimea data, indica prezenta unei Structuri interne. Întrucât Legaturile de Echivalenta si Incluziune sunt toate Relatii definite pe aceeasi Multime , si cum Legaturile între Multimi sunt descrise tot de Relatii, putem afirma ca orice prezenta a unei Relatii într-un Sistem de Multimi confirma existenta unei Structuri interne a acelui sistem.

Gradul de structurare al unei Multimi de Elemente sau de Multimi depinde de numarul de Submultimi distincte care pot fi definite la un moment dat, precum si de raporturile existente între ele: Legaturi de Echivalenta, Nivele de Incluziune, Domenii de Intersectie etc. Organizarea Elementelor în Submultimi usureaza Controlul Ansamblului (manevrabilitatea sa), dar poate creste, în anumite conditii, Timpul de Acces la elemente. Din acest motiv modul de organizare a elementelor în multimi si submultimi este, în abordarile traditionale, subordonat scopurilor de prelucrare. Este de mult încetatenita afirmatia ca:

“Organizarea aleasa depinde de Accesul dorit.”

Dupa cum se va vedea din analiza instrumentelor dezvoltate în proiectarea Bazelor de Date, o desprindere totala de aceasta afirmatie nu este pâna în prezent posibila datorita restrictiilor impuse de performantele sistemelor de calcul. Cu toate acestea desprinderea amintita a reprezentat, reprezinta si va reprezenta un deziderat important al sistemelor cu Baze de Date, pasi remarcabili fiind deja realizati pe aceasta cale. Specificul colectiilor de Informatii si Date în cadrul sistemelor cu Baze de Date consta în aceea ca ele sunt aprioric destinate sa deserveasca fie:

§ Scopuri Multiple

§ Scopuri Neprecizate initial

Aceasta constatare justifica aspiratia specialistilor spre structuri care ofera înainte de calitatea de a fi Bine Organizate, pe cea de a fi Capabile De Reorganizare rapida. Se prefera asadar însusirii de Optimalitate, care e legata de un Criteriu sau de o Lista de Criterii, cunoscuta si ordonata dupa Prioritati, pe cea de Adaptabilitate la Liste de Criterii definite Adhoc. Pe baza conceptele de Cupluri sau Tupluri, privite ca Multimi Intrinsec Ordonate, Structura implica instituirea unei Ordini într-o Multime de Elemente, prin succesiunea Legaturilor de Echivalenta si Incluziune, precum si a Legaturilor între Multimi , prin cuplarea acestora. In acest demers orice Structura gata construita poate reprezenta o Înghetare a Sistemului de Elemente într-o anumita Ordine Momentana care se poate adeveri ca Temporara, întrucât este generata de o Viziune Partiala asupra Multimii de Elemente. Construirea unei Noi Structuri pornind de la Vechea Structura implica doua operatii principale:

- Demontarea Vechii Structuri pentru obtinerea Elementelor constitutive necesare în pasul urmator

- Remontarea unei Noi Structuri cu Elementele obtinute în primul pas

74 Structuri de Informatii si Date / Structura, Organizre si Acces

Ambele operatii sunt mari consumatoare de timp în cazul Colectiilor Mari de Date (în SBD). Acest inconvenient conduce la dezvoltarea a doua tipuri de abordari în construirea Structurilor de Informatii si Date cu care opereaza Sistemele cu Baze de Date:

§ Structuri Dedicate – obtinute prin Specializarea domeniului de interes (Spatiul de Informatii) cu limitarea tipurilor de Elemente si Legaturi care urmeaza a fi tratate (ex. Baze de Date Documentare, Baze de Date Finaciare, Baze de Date pentru Tranzactii Comerciale, Baze de Date pentru CAD etc.)

§ Structuri Generale – destinate Sistemelor cu Utilizare Multipla, privite mai mult ca Surse de Date si mai putin ca si Colectii de Aplicatii predefinite (ex. Baze de Date pentru Sisteme Integrate, Banci de Date etc.)

Întrucât conceptele dezvoltate de disciplina de Baze de Date trebuie sa faca fata ambelor cerinte ele vor trebui sa ofere într-un înalt grad capacitatea de Adaptabilitate la Cerinte Noi, initial neprecizate. Solutia propusa este urmatoarea:

“Salvarea vine nu din Perfectiunea Structurii, ci din Capacitatea ei de a se Adapta” Altfel exprimat:

“ Daca nu exista o Ordine General Valabila pentru Elementele Constitutive, acestea sa fie pastrate în cea mai mare Neordine posibila, pentru a se putea Reorganiza Instantaneu în Ordinea ceruta.”

Aceasta valenta este oferita de maxima Independenta a Elementelor Constitutive, concentrata în Elementaritatea descrierii Spatiului de Informatii si Date.

Referitor la solutia propusa pentru Construirea si Reconstruirea Structurilor din Atomi Structurali, facem o mica digresiune, pentru a comenta unul din reprosurile facute Modelului Relational si care convine problemei aflata în discutie:

Eliminarea Relationala a Redondantei Descriptorilor

nu se aplica si Identificatorilor, pentru care se promoveaza o acuta Redondanta

In Fig. 3.4.1.1 se prezinta comparativ descrierile Ierarhice si Relationale ale structurii Bneficiari – Produse – Contracte. Pot fi facute urmatoarele observatii:

o Modelul Ierarhic

§ Structura este gata Construita (Înghetata) în varianta Ierarhica (BPC)

§ Structura este Contextuala ceea ce o face Compacta (fara Redondanta de Identificatori)

§ Orice Reorganizare (de exemplu PBC) necesita demontarea primei structuri

§ Structura implica Redondanta mare de Descriptori (Descriptorii lui P)

§ Adaugarea de Restrictii Suplimentare (ex. un singur Produs pentru un Beneficiar) necesita o tratare Procedurala

o Modelul Relational

§ Structura este Elementara (Atomica), în varianta Relationala (B, P, C)

§ Structura este Necontextuala ceea ce o face Reorganizabila prin schimbarea dinamica a Viziunilor

Structuri de Informatii si Date / Structura, Organizre si Acces 75

§ Orice Reorganizare (de exemplu P, B, C) este doar o alta Viziune asupra aceleiasi structuri (se modifica doar Ordinea de Inspectie a Relatiei C prin Indecsi adecvati)

§ Structura implica Redondanta Aparenta de Identificatori, deoarece Componentele Atomice de Structura bi, pj, ck au ca Identificator unic Identificatorul Compus din cele trei componente enumerate (acesta este si motivul pentru care Structura ramâne Necontextuala, Componentele pastrându-si Identitatea si în urma unei reamplasari, prin schimbarea Ordinii lor)

§ Structura nu implica nici-o Redondanta de Descriptori

§ Adaugarea de Restrictii Suplimentare (ex. un singur Produs pentru un Beneficiar) poate fi rezolvata Structural, prin adaugarea unei Constrângeri de Cheie Candidata (Index unic) pentru combinatia B+P

Fig. 3.4.1.1 Compararea Redondantei în Modelele de Date

Modelul Relational de descriere a Structurilor de Date asigura, în cel mai înalt grad, realizarea Independentei Elementelor cu ajutorul carora se descriu si se prelucreaza Structurile de Date, prin implementarea urmatoarelor Concepte de Independenta:

- Interfetele între Nivelele de Abstractizare în descrierea datelor

§ Interfata între Nivelul Intern si cel Conceptual – asigura Independenta Nivelului Conceptual fata de modificarile din Nivelul Intern

§ Interfata între Nivelul Conceptual si cel Extern – asigura Independenta Nivelului Extern fata de modificarile din Nivelul Conceptual

Intensiune

Extensiune

BENEFICIAR Cod Nume PRODUS Cod Nume

CONTRACT Numar

Cantitate END END

BENEFICIAR Cod Nume END PRODUS Cod Nume END CONTRACT Beneficiar Produs Cantitate END

BPC b1, p1, c1, c2, .. , p2, c1, c2, .. , .. , b2, p2, c1, c2, .. , p3, c1, c2, .. , .. , ..

B b1, b2, .. P p1, p2, .. C b1, p1, c1 b1, p1, c2 .. b1, p2, c1 b1, p1, c2 .. b2, p2, c1 b2, p2, c2 .. b2, p3, c1 b2, p3, c1 ..

Model Ierarhic Model Relational

Intensiune Extensiune

76 Structuri de Informatii si Date / Structura, Organizre si Acces

§ Interfata între Nivelul Extern si Proceduri – asigura Independenta Procedurilor fata de modificarile din Date

- Normalizarea Structurilor de Date – asigura Independenta între Atributele descriptoare ale Entitatilor

- Propagarea Atributelor de Legatura – asigura Independenta Legaturilor fata de Atributele ce nu sunt de Legatura (nu sunt definite pe Domenii Comune)

- Constructor Elementar Unic (Relatia) – asigura Independenta Structurii fata de Constructorul de Structura

§ Implementare Unica a Claselor de Entitati si a Legaturilor între Clasele de Entitati – asigura Independenta descrierii Legaturilor fata de descrierea Claselor de Entitati

§ Implementarea oricarui Tip de Structura – asigura Independenta Componentelor de Structura prin implementarea identica a Structurilor de Tip Echivalenta (n – n), a Structurilor de Tip Incluziune – Arborescenta (1 – n) si a Structurile de Tip Incluziune - Retea (m – n)

§ Modificarea Dinamica a Tipului de Structura – asigura Independenta relativa a Definirii de Structura fata de Specificatiile de Definitie

§ Implementarea Proceselor de Abstractizare – asigura Independenta Componentelor de Structura prin implementarea identica a Structurilor de Tip Generalizare, precum si a Structurilor de Tip Agregare

- Utilizarea Descrierilor Deschise – asigura Independenta Descrierilor Noi fata de Descrierile Vechi

- Referirea Asociativa – asigura Independenta Descrierii Fizice (prin Valori) de Suportul de Memorare

- Distribuirea Bazelor de Date– asigura Independenta Surselor de Date fata de Localizarea lor pe Statii

- Tranzactiile Consistente – asigura Independenta Operatiilor Tranzactionale asupra Bazei de Date

Enumerarile facute dau o imagine sugestiva asupra perseverentei cu care Sistemele cu Baze de Date au urmarit fructificarea Ideii de Independenta în construirea structurilor. Este de netagaduit faptul ca multe încadrari în acest principiu sunt facute în urma unor analize retrospective ale diverselor directii de activitate, urmate doar apoi de sintezele necesare. Acest lucru nu micsoreaza valabilitatea constatarii facute, înca la începutul prezentarii materialului, si anume ca promovarea Principiului de Independenta în Structura este indisolubil legat de Sistemele cu Baze de Date, ca aplicarea lui a fost fortata de necesitatea mentinerii controlului asupra unor Sisteme Complexe, ce reuneau Structuri de Date si de Proceduri, care se cereau aplicate în domenii foarte diverse. Aceste caracteristici ale Modelului Relational, concentrate în Elementaritatea sa de descriere, reprezinta nu numai motivele extinderii sale prezente în sistemele cu Baze de Date, ci si perspectiva mentinerii lui în viitor, ca instrumentul cel mai eficient de reprezentare a Colectiilor de Date ce urmeaza a satisface Cerinte initial Incomplete si ulterior Dinamice.

Structuri de Informatii si Date / Structura, Organizre si Acces 77

3.4.1.1 Structura Logica si Fizica

Asa dupa cum au fost descrise Nivelele de Abstractizare în Bazele de Date se pot remarca doua Nivele de Descriere:

- Conceptuala (Logica) – descrierea Datelor prin Nume

- Interna (Fizica) – descrierea Datelor prin Valori; aici însa sunt adaugate la datele care prezinta interes direct pentru Utilizator si cele care sunt utile doar pentru Gestionarea Suportului si care contin Informatiile de Control a Suportului

Întrucât, referitor la utilizarea termenilor de nivel Logic si Fizic, exista atât în literatura de specialitate, cât si în produsele comerciale, unele utilizari ce pot conduce la ambiguitati, facem urmatoarele precizari legate de Planurile de Descriere a Datelor. Termenii de descriere Logica si Fizica au aparut în legatura directa cu procesarea datelor, adica în Spatiul Datelor unde erau prezente doua categorii de Utilizatori:

§ Programatorul de Aplicatii – interesat în special de Valorile Datelor înregistrate pe Suport si grupate în asa numite Articole Logice

§ Programatorul de Sistem – interesat în ansamblul tuturor informatiilor existente pe Suport (Valori si Date de Control), utile gestiunii eficiente a proceselor de Memorare – Regasire a informatiilor, prin intermediul prelucrarii Blocurilor de Realizari de Articole Logice, numite Articole Fizice

Au luat ca urmare nastere termenii prezentati în mod sugestiv în Fig. 3.4.1.1.1, care redau sugestiv implementarea planurilor de descriere Logica si Fizica a Datelor. In schita întocmita se face o comparatie de termeni între viziunea de Prelucrare Clasica a Fisierelor si cea preluata si dezvoltata de Bazele de Date:

o In Prelucrarea Clasica Programele de Aplicatii opereaza, cu:

§ Articolele Logice descrise în Programe

§ Articolele Fizice, atunci când se cere o gestiune a Informatiilor de Control a Suportului

o In Bazele de Date:

§ Nivelul Fizic se rezuma la descrierea prin Valori a Datelor

§ Prelucrarea Articolelor Fizice este lasata exclusiv în seama Nivelului Intern, deci a Modulelor SGBD-ului, însarcinate cu Gestiunea Structurii Fizice

§ Nivelul Logic se dezvolta catre o descriere detaliata regrupata în Dictionarul de Date

Termenii au reaparut apoi în legatura cu descrierea cerintelor din ce în ce mai complexe ale utilizatorului determinate de preluarea maxima de informatie din domeniul lui de interes, deci din Spatiului Informatiilor (din Descrierea Problemei) si ulterior de transpunere a lor în Spatiul Datelor (pentru construirea Modelului de Date celui mai adecvat pentru prelucrare).

Concepte de Baza / Structuri de Informatii si Date 78

Fig. 3.4.1.1.1. Implementarea planurilor de descriere Logica si Fizica a Datelor

REPREZENTARE COMPLETA ARTICOLE LOGICE pe SUPORT (VALORI + DATE de CONTROL = BLOC de INREGISTRARE)

( INREGISTRARE FIZICA )

N 1 N 2 . . .

. . .

N n

V 11 V 12 . . .

. . .

V 1n V 21 V 22 . . .

. . .

V 2nICA1 ICA 2 11

ICB1 V m1 Vm2 . . .

.

. V mn SB

1 ICA m

11

. . .

DESCRIERE ARTICOL prin NUME

( ARTICOL LOGIC )

REPREZENTARE VALORI ARTICOL LOGIC pe SUPORT

( INREGISTRARE LOGICA )

Plan NUME

Plan VALORI

DICTIONARE de DATE

(SABLOANE de DESCRIERE)

FISIERE de DATE pe SUPORT

BLOCURI de INREGISTRARI

Legenda N – NUME de DATA V – VALOARE de DATA ICA – informatii de CONTROL ARTICOL ICB – informatii de CONTROL BLOC SB – separator SFARSIT de BLOC

Concepte de Baza / Structuri de Informatii si Date 79

Ambele categorii de Utilizatori chemati sa colaboreze în acest moment: Utilizatorul Final si Proiectantul de Aplicatie au agreat existenta a doua planuri de descriere:

- Descriere Logica – cea care descrie Nivelul Abstract (Descriere Notiuni prin Nume)

- Descriere Fizica - cea care descrie Nivelul Concret (Descriere Instante prin Valori)

Au luat nastere astfel termenii prezentati cu ocazia prezentarii Nivelelor de Abstractizare în Bazele de Date. Unificarea celor doua acceptiuni de termeni este prezentata în tabelul sintetic. 3.4.1.1.2.

Nivelul diferentiat de descriere Elementul Descris

Nivelul general de descriere

Mijlocul de descriere Interpretare Viziune

ENTITATE NOTIUNE

LOGIC

NUME

ENTITATI

+ RELATII

Gestiune Informatii

+ DATE

ENTITATE OBIECT

LOGIC / FIZIC

VALORI

ARTICOL LOGIC

/ ARTICOL FIZIC

Gestiune DATE

+ Proceduri

SUPORT FIZIC Reprezentare VALORI +

Date de CONTROL

ARTICOL FIZIC

Gestiune DATE

+ SUPORT

Tab. 3.4.1.1.2 Raportul Structura Logica de Date - Structura Fizica de Date

Mentionam ca, desi termenii de Articol Fizic si Articol Logic sunt folositi în prezent doar în Programarea Clasica, am tinut sa prezentam relatia lor cu termenii din Sistemele cu Baze de Date din doua motive:

- Pentru a ilustra cronologia aparitiei si consolidarii anumitor concepte

- Pentru a sublinia mai mult apropierea dintre diferite concepte, decât diferentele lor, legate firesc de momentelor de dezvoltare în care au aparut

Se poate nota existenta Nivelului hibrid Fizic / Logic (Fizic pentru noua acceptiune, Logic în acceptiunea clasica) în descrierea datelor si care împaca cele doua viziuni, subliniind totodata faptul ca aceleasi planuri de reprezentare sunt diferit vazute de categorii diferite de utilizatori, în speta Proiectantul de Aplicatie si Programatorul de Sistem. In sectiunea ce urmeaza va fi accentuata importanta ca Utilizatorii, Specialisti sau Utilizatori Finali, sa gândeasca în cele doua planuri:

- Logic – pentru a le asigura Generalitatea necesara cuprinderii într-un Tot Unitar a unui volum adesea imens de informatii

- Fizic – pentru a nu pierde nici o clipa contactul cu Lumea Faptelor, acea Realitate unde se naste si se utilizeaza Informatia si de unde trebuie extrase cerintele reale legate de Modelarea Informatiilor si Datelor

80 Spatiul de Informatii si de Date

3.4.1.2 Spatiul de Informatii si de Date

Conform definirii conceptelor de Informatie si Data se pot face urmatoarele delimitari:

o Spatiul Informatiilor – este alcatuit din ansamblul Informatiilor definite si descrise pe baza Analizei Realitatii (Stari, Fapte, Evenimente, Transformari, Cunostinte), Realitate în care activeaza Utilizatorul si care se cere cunoscuta, modelata si în final adaptata necesitatilor de control al Informatiilor care o descriu; se mai numeste si Spatiul Problemei

o Spatiul Datelor – este alcatuit din ansamblul Datelor pe care Proiectantul le alege pentru a transpune Informatiile descrise într-un Model de Date adecvat prelucrarii automate; se mai numeste si Spatiul Calculatorului

Neglijând reprezentarea pe suport a datelor se poate ajunge la schema din Fig. 3.4.1.2.1. Dupa cum descrierea este facuta cu ajutorul Numelor sau Valorilor, în fiecare Spatiu se poate distinge un Nivel Logic sau un Nivel Fizic, grupate în doua Planuri de Descriere distincte. Se remarca faptul ca unui Spatiu de Informatii îi pot corespunde mai multe Spatii de Date (utilizând acelasi Tip de Model de Descriere, sau unul diferit: Ierarhic, Retea sau Relational). Fiecare Plan de Descriere prin Nume poate fi concretizat (instantiat) prin Seturi de Valori diferite. Aceasta este semnificatia Legaturilor 1 – n, între Structura Logica de Informatii (SLI) si Structura Logica de Date (SLD), respectiv între Structurile Logice de Informatii si de Date (SL) si Structurile Fizice de Informatii si de Date (SF). Reprezentarea punctata a legaturii între Structurile Fizice de Informatii si de Date trebuie înteleasa ca o Legatura Derivata din cele trei Legaturi Primare: SLI → SFI, SLI → SLD, SLD → SFD.

Gruparile efectuate si Raporturile stabilite între acestea permit trecerea la reprezentarea din Fig. 3.4.1.2.2. Prin aceasta ne apropiem de modul în care SBD utilizeaza Spatiile si Planurile de organizare a Informatiilor si Datelor. Pornind de la prezenta unei multiplicari generativa la trecerea între diferitele Planuri si Spatii de realizare a descrierilor, se naste ideea utilizarii unor Produse Specializate pentru Descrierea Nivelelor si pentru Conversia acestor Descrieri. Se ofera astfel un Control riguros al Variantelor de Descriere de pe Nivelele Inferioare generate de Descrierile de pe Nivele Superioare. Exista urmatoarele Produse Specializate pentru gestiunea Nivelelor:

- Nivelul SI - Produse CASE care descriu Modele de Date (Modelere)

- Nivelul SLD – Componente ale SGBD care descriu Structura Logica

- Nivelul SFD – Componente ale SGBD care gestioneaza Structura Fizica

Procese deja consacrate asigura si Conversiile necesare între Nivelele de mai sus:

- Conversie SI - SLD – Procesul de Engineering al unui Model de Date

- Conversie SLD - SI – Procesul de Reengineering al unui Model de Date

- Conversie SLD - SFD – Operatiile de Actualizare ale unui SGBD

Lucrul cel mai important de retinut din prezentarea anterioara este faptul ca Sistemele cu Baze de Date nu se opresc la simpla Separare a Nivelelor Logic si Fizic de Descriere, ci prin diferentierile operate între Spatiile Informatiilor si Datelor deschid perspective pentru o Proiectare la un Nivel mai Înalt de Abstractizare.

Spatiul de Informatii si de Date 81

Fig. 3.4.1.2.2 Spatii si Planuri de descriere a Informatiilor si Datelor

Demersurile facute pâna în prezent, începând cu delimitarea diferentelor de acceptiune între Informatie si Data si terminând cu valorificarea raporturilor între diferitele Planuri si Spatii de reprezentare, apare ca foarte utila în procesul de proiectare a sistemelor complexe cu Baze de Date. Precizarea zonelor în care se poarta discutia în timpul realizarii unui Proiect este foarte importanta din mai multe puncte de vedere, dintre care enumeram:

- Utilizarea corecta a Notiunilor Specifice domeniului în discutie

- Recurgerea la Instrumentele Consacrate de reprezentare

- Redactarea concisa si precisa a Specificatiilor de Definitie

- Deducerea cu usurinta a implicatiilor pe care le au modificarile inerente ale Specificatiilor de Definitie

Aceste Notiuni vor fi regasite, indiferent de denumire, în produsele care se ocupa cu Proiectarea de Nivel Înalt, întelegând prin aceasta formele de proiectare care apeleaza la Modele de Date pentru descrierea tot mai directa a Spatiului de Informatii si continuând apoi

SPATIUL DATELOR

SPATIUL INFORMATIILOR

1 n

STRUCTURA LOGICA de

INFORMATII

STRUCTURA LOGICA

de DATE

1

n

1 n

STRUCTURA FIZICA

de INFORMATII

STRUCTURA FIZICA

de DATE

1

n

Planul NUMELOR

Planul VALORILOR

82 Spatiul de Informatii si de Date

cu Proceduri Automate de Generare a Nivelelor de Descriere corespondente, prin proceduri de Engineering / Reengineering (conform prezentarilor anterioare).

Fig. 3.4.1.2.1 Spatiul de Informatii – Structura Logica de Date – Structura Fizica de Date

Este demn de remarcat drumul parcurs de Conceptul de descriere prin Nume si prin Valoare, de la prima initiativa de Separare a Nivelelor de Descriere a Datelor, pâna la fundamentarea Proiectarii de Nivel Înalt în cadrul Modelelor de Date, Modele ce încorporeaza atât Structura , cât si Restrictiile si Operatiile aferente. Este înca o dovada ca perenitatea Sistemelor cu Baze de Date s-a bazat pe selectarea cu atentie a Valorii Conceptelor adoptate, completata cu perseverenta în urmarirea extragerii tuturor Consecintelor Derivate din valoarea acestor concepte.

Vorbind despre Proiectarea la Nivel Înalt, folosind Modele de Date gasim un prilej de a prezenta diferitele acceptii de termeni, care trebuiesc interpretate de fiecare data cu atentie. Desi în cadrul unui Model de Date nu gasim reprezentat Planul Valorilor, proiectarea rezumându-se la Planul Numelor, întâlnim notiunea de Model Logic de Date si Model Fizic de Date. Termenul se refera la raportul 1 – n între SI si SLD. Modelul Logic de Date va descrie în acest caz Structura de Informatii, în timp ce Modelele Fizice de Date vor descrie Instantele Structurii Logice de Date, generate pentru diferite Platforme de Implementare a Bazei de Date. Aceasta particularizare nu anuleaza notiunile prezentate, care doar îi usureaza întelegerea.

STRUCTURA de INFORMATII

STRUCTURA LOGICA de DATE

( STRUCTURA TEORETICA)

STRUCTURA FIZICA de DATE

( STRUCTURA de STOCARE)

Caracteristici de descriere a INFORMATIILOR

Caracteristici de descriere a DATELOR

Caracteristici de descriere a SUPORTULUI

1

n

1

n

Structuri Fundamentale de Informatii si Date 83

3.4.2 Structuri Fundamentale de Informatii si Date

Sectiunea este consacrata prezentarii acelor concepte care ne permit sa abordam problema construirii de structuri într-un mod sistematic. In primul rând se raspunde la întrebarea:

Care sunt Raporturile între Elementele unei Structuri care se cer implementate?

Raspunsul obtinut la aceasta întrebare va fi apoi utilizat pe tot parcursul lucrarii în scopuri foarte diverse:

o Pentru determinarea Structurilor Elementare care permit implementarea Raporturilor strict necesare în cadrul unei Structuri de Informatii si de Date. Vor putea fi elaborate astfel Module de Structura a caror combinare sa permita industrializarea construirii de Structuri Complexe.

o Pentru obtinerea unui Instrument de Comparatie si de Evaluare a diferitelor Modele de Date utilizate în SGBD-urile existente, modul de implementare a Raporturilor Fundamentale fiind un Criteriu esential.

o Pentru determinarea Calitatii Structurilor Proiectate un asemenea Instrument este deosebit de util. El va putea folosi nu numai pentru Evaluarea unui Proiect de Structura, ci mai ales pentru formarea unei Discipline de Proiectare a Structurilor.

o Pentru a putea gândi la formele de Construire a Structurilor în viitor, prin apelul la acelasi Instrument de Comparatie si de Evaluare

3.4.2.1 Definirea Structurilor Fundamentale

Pentru construirea unei Structuri de Informatii sau Date este important sa se cunoasca care sunt Tipurile de Structuri Fundamentale, care se regasesc în orice Multime Particulara de Informatii dintr-o Realitate ce se cere modelata. Cunoscând aceste Tipuri de Structuri, împreuna cu modul lor specific de implementare într-un Model de Date aflat la dispozitie, reprezentarea unei realitati prin informatii si date poate deveni un proces de rutina .

Tipurile fundamentale de structuri se definesc pornind de la evidentierea Relatiilor de Dependenta între Multimile de Elemente ce descriu realitatea. Aceste Relatii de Dependenta pot fi de Echivalenta sau de Incluziune.

Trei tipuri de Structuri Fundamentale pot fi regasite într-o structura data (vezi Fig. 3.4.2.1, Fig. 3.4.2.2 si Fig. 3.4.2.3), daca la dependentele anterioare se adauga si raporturile în care pot sta Multimile Parti (Mi) ale unei multimi date (M) si anume:

o Relatia de Echivalenta

o Relatia de Incluziune

§ De tip Partitie

§ De tip Acoperire

84 Structuri Fundamentale de Informatii si Date

j si i pt. = M M si M = M - Partitie de -

M = M - Acoperire de -

ji

i

i

i

i

∀∅IU

U

Diagrama VENN

Structura GRAF

Fig. 3.4.2.1 Structura de tip Echivalenta - Nivel

Relatia de Echivalenta decurge din proprietatea de Apartenenta a Elementelor la aceeasi Clasa de Echivalenta.

E

nE 5 nE 4

nE 3

nE 2 nE 1

nE 1

E

nE 3 nE 2

nE 5 nE 4

n

Structuri Fundamentale de Informatii si Date 85

Relatia de Echivalenta implica existenta unei relatii de Incluziune si reciproc relatia de Incluziune implica existenta unei relatii de Echivalenta. In primul caz Incluziunea rezulta din însasi existenta unei proprietati comune ce sta la baza definirii Clasei de Echivalenta în cadrul unei Multimi Totale care include aceasta clasa. In mod reciproc recunoasterea unei proprietati comune de Incluziune implica existenta unei Echivalente între membrii incluziunii aflati la acelasi nivel (între care nu exista nici macar o relatie de Ordine). Aceasta observatie conduce la ideea reprezentarii relatiei de Incluziune printr-o legatura între relatii succesive de Echivalenta. Relatia de Echivalenta implica o legatura în plan Orizontal sau pe Nivel (Fig. 3.4.2.1). Aceasta întrucât ea descrie relatia în care se afla elementele aflate pe acelasi nivel formând o Clasa de Echivalenta generata de aceasta proprietate (multimea E). Dependenta elementelor fata de aceasta multime e luata în considerare doar în masura în care transfera asupra Elementelor proprietatea de Echivalenta. De aici provine si utilizarea liniei punctate pentru reprezentarea dependentei Elemente – Multime si totodata denumirea aleasa pentru acest gen de structura - Nivel. S-a considerat mai sugestiva aceasta denumire fata de cea îndeobste folosita de Secventa, care ar implica existenta Ordinii în aceasta structura. Pentru faptul ca aceasta precizare nu reprezinta o speculatie teoretica, ci un concept ancorat în practica proiectarii Structurilor de Informatii si de Date, pledeaza urmatoarele doua argumente:

- Modelul Relational de Date se bazeaza pe proprietatea de Multime a Tuplelor apartinând oricarei relatii, fapt ce implica mentiunea ca Ordinea lor este indiferenta, iar atunci când se cere implementata, aceasta se face prin atasarea la Multimea de Tuple a unei Relatii de Ordine sub forma structurilor auxiliare de tip Index

- Daca între Elementele aflate pe acelasi Nivel de ascendenta într-o Structura Ierarhica se doreste utilizarea unei Relatii de Ordine, aceasta trebuie implementata cu un Atribut destinat acestei proprietati si anume Ordinea pe Nivel

Relatia de Incluziune (Fig. 3.4.2.2 si Fig. 3.4.2.3) implica o legatura în plan Vertical sau în Adâncime (pe mai multe Nivele). Aceasta relatie implementeaza întotdeauna în plan Vertical o Relatie de Ordine. Aceasta relatie de Ordine este într-adevar Partiala pentru ca, asa cum s-a precizat deja, relatia de Incluziune defineste totodata la fiecare Nivel de descendenta Clase de Echivalenta descrise de proprietatea :

Toate Elementele ce au acelasi Ascendent

Relatiile de Incluziune se descompun în doua categorii, în functie de Numarul Ascendentilor:

o Incluziune de tip Arborescenta – structura cu Ascendent Unic, de Tip Partitie

o Incluziune de tip Retea– structura cu Ascendent Multiplu, de Tip Acoperire

In timp ce Relatia de Echivalenta corespunde unei legaturi de Coordonare între Elemente, Relatia de Incluziune corespunde legaturilor de Subordonare.

De asemenea, în timp ce Relatia de Incluziune implementeaza legatura de Posesiune:

Un Posesor – O multime de Obiecte Posedate

Relatia de Echivalenta implementeaza doar legatura de Alaturare de Elemente:

Elemente de acelasi Fel

86 Structuri Fundamentale de Informatii si Date

Diagrama VENN Structura GRAF

Fig. 3.4.2.2 Structura de tip Incluziune - Partitie

E

nE 5 nE 4

nE 3

nE 2 nE 1

E ‘ "

E ‘’

nE 1

E

nE 3 nE 2 nE 5

nE 4

E‘ E’’ n n

n

Structuri Fundamentale de Informatii si Date 87

Aceste doua tipuri de legaturi (Echivalenta si Incluziunea) vor reapare în toate Structurile de Informatii si de Date la care se va face referire în continuare. Atât Legatura de Posesiune cât si cea de Alaturare pot primi concretizari semantice dintre cele mai diferite. Din prima categorie mentionam una foarte des întâlnita si anume cea de: Compus – Componente. Relatia de Echivalenta se defineste ca legatura care exista între Elementele apartinând aceleiasi Multimi, iar relatia de Incluziune ca legatura între Elementele Multimii si Multimea propriuzisa privita ca Element la alt Nivel. Prezinta interes o alta Antinomie între cele doua tipuri de legaturi. Este vorba despre implementarea relatiilor: are (has) si este (is a). Echivalenta implementeaza operatia de Clasificare prin stabilirea unor Clase de Echivalenta. Se mai spune ca implementeaza prin legatura Clasa de Echivalenta – Elemente, relatia Gen Proxim – Diferenta Specifica. Relatia de Incluziune implementeaza operatia de generare noi obiecte prin Agregare de Componente. Sa analizam însusirile tipurilor de structuri la care am ajuns si pe care le consideram unice si prin aceasta fundamentale în construirea structurilor.

o Nivelul

§ Se descrie ca un Arbore Simplu cu un singur Nivel (Fig. 3.4.2.1), deoarece se considera ca aceasta reprezentare este cea mai semnificativa pentru descrierea relatiei de Echivalenta

§ Legaturile Clasa de Echivalenta – Elemente nu intereseaza decât în masura în care defineste Proprietatea Comuna, întrucât relatia se manifesta între Elemente (de aceea ea mai e definita ca o legatura n – n)

§ Legatura n – n este diferita de cea m – n (many to many). Prima este o structura de tip Echivalenta, cea de a doua de tip Incluziune

§ Legatura n – n înlocuieste structura de tip Secventa folosita în literatura de specialitate. Recunoasterea ei este stric necesara în cadrul unei abordari exhaustive a Structurilor Fundamentale

§ Tipul de structura Nivel subliniaza Omogenitatea elementelor în relatie de Echivalenta

§ Legatura se considera desfasurata pe Orizontala (pe Nivel).

§ Tipul de structura este considerat Structura Primara (prin opozitie, celelalte tipuri de structuri vor fi denumite Structuri Evoluate). La prima vedere acest tip de structura indica mai degraba absenta structurii, decât prezenta ei. A fost însa tratat ca prima forma de structurare întrucât relatia pe care o defineste determina recunoasterea în cadrul unui ansamblu de elemente a unei Proprietati Comune (a unei Multimi), proprietate considerata importanta din punct de vedere a prelucrarii elementelor (aceasta proprietate difera de cea de banala apartenenta la ansamblul initial de elemente, care reprezinta Multimea Totala, prin aceea ca ea determina recunoasterea Elementelor ca fiind de Acelasi Fel pentru prelucrarea lor ulterioara)

§ Implementeaza operatia de Coordonare sau Alaturare de elemente

§ Este utilizata ca Structura de Baza în multe Modele de Date (ex. Modelul Relational, Modelul Obiectelor Abstracte etc.)

88 Structuri Fundamentale de Informatii si Date

o Arborescenta

§ Se descrie ca un Arbore Simplu cu mai multe Nivele (Fig. 3.4.2.2), structura Ierarhica care implementeaza legatura 1 – n (datorita Unicitatii Ascendentului).

§ Reprezinta o structura Verticala indicând o descompunere pe Nivele, în care toate Elementele de pe un Nivel sunt legate de un singur Element de pe un Nivel superior (Structura de Tip Partitie)

§ Implementeaza o semantica de tip Posesor – Membri Posedati:

Un Ascendent ca Posesor are n Descendenti ca Membri

§ Structura în Profunzime pe care o implementeaza se pastreaza si pentru cazul n = 1, când legatura ia caracterul particular 1 – 1.

§ Tipul de structura subliniaza Heterogenitatea elementelor în Relatie de Incluziune (diferenta între Elementul Posesor si Elementele Posedate)

§ Implementeaza operatia de Subordonare Simpl a între elementele de pe nivele diferite.

o Reteaua

§ Se descrie ca un Arbore Invers cu mai multe Nivele (Fig. 3.4.2.3), structura Ierarhica care implementeaza legatura m – n (datorita Neunicitatii Ascendentului).

§ Reprezinta o structura Verticala indicând o descompunere pe Nivele, în care toate Elementele de pe un Nivel sunt legate de unul sau mai multe Elemente de pe un Nivel superior (Structura de Tip Acoperire)

§ Implementeaza o dubla semantica de tip Posesor – Membri Posedati:

Un Ascendent ca Posesor are n Descendenti ca Membri

Un Descendent ca Posesor are n Ascendenti ca Membri

§ Tipul de structura subliniaza Heterogenitatea elementelor în relatie de Incluziune (diferenta între Elementul Posesor si Elementele Posedate)

§ Implementeaza operatia de Subordonare Multipla între elementele de pe nivele diferite.

In Fig. 3.4.2.4 este data în recapitulare o sinteza a Tipurilor de Structuri Fundamentale. Apreciem ca deosebit de utila cunoasterea Constructorilor (Modulele care implementeaza Structurile Fundamentale) cu care trebuie sa opereze proiectantul de structuri în vederea garantarii unui punct de pornire sanatos al oricarui Sistem cu Baza de Date. Indiferent care este tipul de Model de Date utilizat pentru construirea Structurii de Date, stabilirea modului de implementare a Constructorilor de Structuri Fundamentale ramâne esential pentru calitatea finala a oricarui proiect. O prezentare detaliata a Construirii Structurilor de Date este rezervata pentru sectiunea 4.2.4.8, cu referire la Modelul de Date Relational.

Structuri Fundamentale de Informatii si Date 89

Diagrama VENN Structura GRAF

Fig. 3.4.2.3 Structura de tip Incluziune - Acoperire

E

nE 5 nE 4

nE 3

nE 2 nE 1

E ‘ "

E ‘’

nE 1

E

nE 3 nE 2

nE 5 nE 4

E‘ E’’

Structuri Fundamentale de Informatii si Date 90

Fig. 3.4.2.4. Structuri Fundamentale

STRUCTURI

de tip ECHIVALENTA structura orizontala

de tip INCLUZIUNE structura verticala

structura PRIMARA

structura EVOLUATA

relatie n - n

pe orizontala

relatie 1 - n

pe verticala de tip

PARTITIE

relatie m - n

pe verticala de tip

ACOPERIRE

ARBORESCENTA

RETEA

NIVEL raport de COORDONARE

raport de SUBORDONARE

SIMPLA ascendent unic

raport de SUBORDONARE

MULTIPLA ascendent neunic

Transformarea Structurilor Fundamentale 91

3.4.2.2 Transformarea Structurilor Fundamentale

Transformarea Structurilor Fundamentale reprezinta o operatie de baza în exploatarea Modelelor de Informatii si de Date. Ea vizeaza legatura directa între operatiile de Organizare si Acces referitoare la Colectiile de Informatii si de Date si ofera o metoda riguroasa de asigurare a performantelor de Acces, fara a compromite calitatea pretinsa Organizarii Colectiilor aflate în discutie. Poate fi de asemenea recunoscuta sorgintea ideii de separare a Structurilor în:

- Structuri Principale – care contin informatiile propriuzise, cele care intereseaza Utilizatorul Final

- Structuri Secundare – care asigura doar alegerea strategiei dorite de Acces la Date

Termeni ca si cel de Cheie de Inversare (Inversion Key), prezenti nu numai în literatura de specialitate, dar si în produse de notorietate, dovedesc ca subiectul legat de Transformarea Structurilor Fundamantale nu este o preferinta teoretica, ci o motivare a conceptelor a caror paternitate apartine Bazelor de Date, dintre care amintim:

o Perfectionarea Modelelor de Date pe care sunt construite succesiv Sistemele de Gestiune ale Bazelor de Date

o Dezvoltarea Indecsilor ca Structuri Anexe performante de Acces si nu de Organizare a Colectiilor de Date

3.4.2.2.1 Tipuri de transformari

Vom analiza Tipurile de Transformari aplicate Colectiilor de Date în sensul de crestere a calitatii Organizarii precum si a performantelor de Acces. Aceasta evolutie se petrece prin aplicarea succesiva a aceluiasi proces de Inversare a structurilor.

Sa consideram urmatoarea Colectie de Informatii care descrie Clasa de Entitati STUDENTI:

STUDENTI

Marca Nume Vârsta Localitate M1 N1 V3 L2 M2 N2 V2 L1 M3 N3 V1 L2 M4 N4 V3 L3 M5 N5 V1 L1

Fig. 3.4.2.2.1.1 Colectie de Informatii STUDENTI

Sa mai observam ca Marca poate reprezenta cu succes Identificatorul Colectiei de Date, întrucât Numele, desi în extensia reprezentata în Fig. 3.4.2.2.1.1 este unica, în cazul general aceasta supozitie nu se verifica. Celelalte caracteristici (Nume, Vârsta si Localitate) se constituie ca si Descriptori ai Clasei de Entitati.

92 Transformarea Structurilor Fundamentale

Identificatorul unei Colectii de Date este candidat pentru organizarea unei Chei Primare, denumita si Criteriu Primar sau Index Primar. Datorita aplicatiei bijective ce exista între multimea Valorilor Identificatorului si multimea Instantelor din Colectie, Cheia Primara e cea mai performanta cale pentru:

§ Accesarea datelor

§ Validarea unicitatii instantelor Pentru a efectua aceste functie Identificatorul trebuie construit ca o Colectie Secundara de tip Index (vezi Fig. 3.4.2.2.1.2.1).

Este de remarcat faptul ca o Colectie de Date poate avea mai multi Identificatori (Identificatori Candidati). Dintre acestia unul este ales ca Primar, ceilalti ramânând Secundari Iau nastere ca urmare o Cheie Primara si eventual mai multe Chei Secundare (Chei Candidate). Clasificarea Cheilor în Primare si Secundare iau în considerare doar criterii de uzualitate în ceea ce priveste regasirea informatiilor pornind de la valorile Cheii de Cautare:

§ Disponibilitate

§ Lungime

§ Usurinta de Memorare

§ Obisnuinta Utilizatorului 3.4.2.2.1.1 Eliminarea Redondantei

La cresterea volumului colectiei STUDENTI, numarul Localitatilor de Resedinta diferite nu va creste în aceeasi masura ceea ce va determina aparitia si cresterea redondantei în Colectia de Date. Eliminarea redondantei se poate face prin separarea colectiei initiale în doua colectii: STUDENTI si LOCALITATI, conform Fig. 3.4.2.2.1.1.1.

STUDENTI

Marca Nume Vârsta Localitate

Referinta M1 N1 V3 R-L2 M2 N2 V2 R-L1 M3 N3 V1 R-L2 M4 N4 V3 R-L3 M5 N5 V1 R-L1

LOCALITATI

Localitate

L1 L2 L3

Fig. 3.4.2.2.1.1.1 Eliminarea Redondantei

Transformarea Structurilor Fundamentale 93

In Colectia STUDENTI atributul Localitate va fi înlocuit cu o Referinta la noua colectie creata. Desigur ca în noua Colectie atributele descriptoare ale LOCALITATILOR pot sa sporeasca (Tip, Cod Postal, Judet etc.). Apare implicit posibilitatea unei economii de spatiu, In general lungimea referintei fiind inferioara celei a denumirii (fara a lua în considerare si ceilalti descriptori adaugati Intre timp), dar câstigul principal consta în mentinerea Consistentei Datelor, prin memorarea într-un singur loc a informatiei: Denumirea Localitatii. Rezulta totodata o crestere a timpului de acces la caracteristica eliminata din colectie, prin necesitatea unui dublu acces la ambele Colectii, dar câstigul realizat prin garantarea Consistentei Datelor justifica aceasta pierdere. Noua colectie de date regrupeaza Valorile Izotipe (vezi sectiunea 4.1.1.3.4) din structura definind, pe multimea STUDENTILOR, Ansambluri de Entitati: vezi sectiunea 4.1.1.3.5) - STUDENTII având aceeasi LOCALITATE de resedinta.

3.4.2.2.1.2 Inversarea Partiala (Indexarea)

Aparitia noii colectii creeaza însa si un alt avantaj în afara Eliminarii Inconsistentei si anume sugerarea posibilitatii de a modifica Strategia de Acces la Date:

o Strategia 1 – Acces de la Entitate la Caracteristica (Fig. 3.4.2.2.1.1.1 – acces de la STUDENT la Localitate)

o Strategia 2 – Acces de la Caracteristica la Entitate (Fig. 3.4.2.2.1.2.1 - acces de la LOCALITATE la STUDENTI)

LOCALITATI

Localitate Student

Referinta R-S2 L1 R-S5 R-S1 L2 R-S3

L3 R-S4

STUDENTI

Marca Nume Vârsta M1 N1 V3 M2 N2 V2 M3 N3 V1 M4 N4 V3 M5 N5 V1

Fig. 3.4.2.2.1.2.1 Inversarea Partiala (Indexarea)

Pentru a realiza aceasta inversare de strategie de acces referinta între colectii se muta din STUDENTI în LOCALITATI . Se asigura totodata si un acces nu doar la o Instanta (Entitate Obiect), ci la o Multime de Instante (toti Studentii cu aceeasi Localitate de

94 Transformarea Structurilor Fundamentale

Resedinta). Aceasta se realizeaza prin inspectia tuturor Referintelor atasate unei Valori din Colectia Secundara de tip Index. Solutia acestei grupari a referintelor aduce însa si doua inconveniente importante, ce provin din numarul variabil al Valorilor Izotipe din STUDENTI (Studenti din aceeasi Localitate):

o Prezenta Instantelor de Lungime Variabila în Colectia Secundara LOCALITATI

o Actualizarea dificila a Colectiei Index (LOCALITATI)

Termenul de Inversare îsi are originea în procedura initiala prin care se asigura aceasta modificare de strategie prin Inversarea Ordinii de Sortare a Colectie Principale (Ordinea de Sortare dupa Identificatorul de Student e înlocuita cu Localitatea de Referinta).

Clasa de Entitati LOCALITATI poarta denumirea de Index Secundar sau Cheie de Inversare (Inversion Key), pentru Clasa de Entitati STUDENTI, spre deosebire de Indexul Primar definit anterior (Marca).

Colectiile de Date de tip Index pot fi:

o Dense – când Realizarile (Instantele) Colectiei Secundare refera fiecare Entitate Obiect (Realizare sau Instanta) din Colectia Principala.

Altfel zis – pentru a ajunge la oricare Instanta din Colectia Principala se inspecteaza doar Colectia Index care ofera o Referinta pentru fiecare înregistrare (Instanta) din Colectia Principala.

In acest caz se zice ca Indexul are o Intrare pentru fiecare Instanta din Colectia Principala.

o Nedense – când Realizarile (Instantele) Colectiei Secundare refera un Ansamblu de Entitati Obiect (Realizari sau Instante) din Colectia Principala.

Altfel zis – pentru a ajunge la oricare Instanta din Colectia Principala se inspecteaza întâi Colectia Index apoi Grupul de Instante din Colectia Principala.

In acest caz se zice ca Indexul are o Intrare pentru fiecare Grup de Instante din Colectia Principala.

Se numesc Puncte de Intrare în Colectia de Date Principala Instantele Colectiei de Date Index (fiecare Pereche de Date: (Vi, Rj) Valoare de Caracteristica – Referinta la o Instanta din Colectia Principala).

Denumirea de Dens, Nedens se foloseste si atasata direct Indecsilor.

Exemple Indecsi Densi – Indecsii din Fig. 3.4.2.2.1.2.1si Fig. 3.4.2.2.1.4.1. Indecsi Nedensi – Indexul din Fig. 3.4.2.2.1.3.1 si Fig. 3.4.2.2.1.3.2

3.4.2.2.1.3 Eliminarea Redondantei + Inversarea Partiala

Ideea combinarii celor doua metode survine imediat, întrucât prin aceasta se ofera ambele strategii de acces, pornind de la Entitate sau de la Caracteristica (Fig. 3.4.2.2.1.3.1 si Fig. 3.4.2.2.1.3.2).

Transformarea Structurilor Fundamentale 95

In prima varianta transformarea nu face decât sa puna laolalta cele doua metode precedente, asigurând posibilitatea accesului si de la STUDENTI la Localitatea de Resedinta, dar si de la o LOCALITATE la toti STUDENTII având Resedinta în aceasta Localitate. Numarul Variabil de Referinte se pastreaza în colectia LOCALITATI, complicând gestiunea ei.

STUDENTI

Marca Nume Vârsta Localitate Referinta

M1 N1 V3 R-L2 M2 N2 V2 R-L1 M3 N3 V1 R-L2 M4 N4 V3 R-L3 M5 N5 V1 R-L1

LOCALITATI

Localitate Student

Referinta R-S2 L1 R-S5 R-S1 L2 R-S3

L3 R-S4

Fig. 3.4.2.2.1.3.1 Eliminarea Redondantei + Inversarea Partiala (Varianta 1)

Pentru a înlatura inconvenientul mentionat mai sus se înlocuiesc referintele din LOCALITATI cu referinte între Instantele din STUDENTI. In acest fel, Înregistrarile în ambele Colectii ramân de Lungime Fixa. Modificarea transforma Colectia de Date LOCALITATI din Index Dens (LOCALITATI în varianta 1) în Nedens (LOCALITATI în varianta 2). Un anume STUDENT dintr-o LOCALITATE data va fi localizat prin doua inspectii:

- Inspectia Colectiei Secundare LOCALITATI pentru o anume Localitate

- Inspectia Colectiei Principale STUDENTI pornind de la Referinta din LOCALITATI (Referintele cu linie întrerupta) si continuând cu Referintele la Entitatile Obiect (Instantele) STUDENTI (Referintele punctate)

Prin aceasta modificare de structura se obtin urmatoarele efecte:

Avantaje:

- Structura de Date care descrie Referintele devine din Statica (Vectori de Valori) Dinamica (Liste de Articole)

- Actualizarea Referintelor devine mai comoda, prin Alocarea Dinamica de Spatiu de Memorare, odata cu înregistrarea noilor instante în Colectia Principala

96 Transformarea Structurilor Fundamentale

Dezavantaje:

- Creste Numarul Acceselor la regasire (se inspecteaza ambele Colectii de Date)

- Durata parcurgerii Listelor de Referinte poate deveni critica

- Necesitatea dublarii Referintelor în Lista de Referinte (înlantuire directa si inversa) în cazul actualizarilor frecvente (în special Stergeri)

LOCALITATI

Localitate Student Referinta

L1 R-S2 L2 R-S1 L3 R-S4

STUDENTI

Marca Nume Vârsta Localitate

Referinta Localitate Referinta Izotipa

M1 N1 V3 R-L2 R-S3

M2 N2 V2 R-L1 R-S5

M3 N3 V1 R-L2 -

M4 N4 V3 R-L3 -

M5 N5 V1 R-L1 -

Fig. 3.4.2.2.1.3.2 Eliminarea Redondantei + Inversarea Partiala (Varianta 2)

Aceasta structura a fost introdusa de Modelul Retea, reprezentând primii pasi pe calea obtinerii Structurilor de Date Integrate de tip m - n. 3.4.2.2.1.4 Inversarea Totala

Inversarea Totala duce la o structura care a câstigat interes pe masura cresterii performantelor de procesare a datelor, în special în ceea ce priveste gestionarea simultana a mai multor Colectii de Date. Se reia ideea de Indexare simpla, care se repeta pentru toate caracteristicile care descriu Colectia Principala. Se spune în acest caz ca s-a realizat Inversarea Totala a Colectiei de Informatii întrucât s-a asigurat câte un Punct de Intrare pentru fiecare Valoare a fiecarei Caracteristici. Pentru a nu pierde avantajul mentinerii ambelor Strategii de Acces, în Colectia Principala se cere mentinerea tuturor caracteristicilor descriptoare, chiar daca aparent aceasta sugereaza o mare redondanta. (Faptul ca nu este vorba despre redondanta în acest caz îl justifica observatia ca Structura de Informatii este descrisa doar de Colectia

Transformarea Structurilor Fundamentale 97

Principala, Colectiei Secundare revenindu-i întotdeauna doar rolul de a descrie Strategiile de Acces.

STUDENTI

Marca Nume Vârsta Localitate M1 N1 V3 L2 M2 N2 V2 L1 M3 N3 V1 L2 M4 N4 V3 L3 M5 N5 V1 L1

MARCI

Marca Student Referinta

M1 R-S1 M2 R-S2 M3 R-S3 M4 R-S4 M5 R-S5

NUME Nume Student

Referinta N1 R-S1 N2 R-S2 N3 R-S3 N4 R-S4 N5 R-S5

VARSTE Vârsta Student

Referinta R-S3 V1 R-S5

V2 R-S2 R-S1 V3 R-42

LOCALITATI Localitate Student

Referinta R-S2 L1 R-S5 R-S1 L2 R-S3

L3 R-S4

Fig. 3.4.2.2.1.4.1 Inversarea Totala

98 Transformarea Structurilor Fundamentale

Din motive de claritate s-a evitat reprezentarea grafica a referintelor.

In aceasta noua structura preocuparile de performanta sunt legate doar de perfectionarea Structurilor Secundare în care ideile de tratare a Valorilor Izotipe prin Liste de Referinte gaseste un câmp fertil.

Prin aceasta structura s-au obtinut urmatoarele efecte:

Avantaje:

- Structura de Date dispune de maximum de Puncte de Intrare în Colectia Principala

- Se întrevede si posibilitatea modificarii dinamice a Caracteristicilor de Inversare chiar în timpul procesarii datelor din Colectia Principala

Dezavantaje:

- Spatiul necesar Colectiilor Secundare depaseste în general pe cel al Colectiei Principale

In practica se foloseste, din motive de performanta, o Inversare Partiala în care Utilizatorul îsi alege singur Caracteristicile de Inversare generând si eliminând Colectiile Secundare atasate, chiar si în timpul proceselor de prelucrare.

Aceasta structura a fost cu succes promovata de Modelului Relational, fiind proprie Structurilor de Date Integrate. 3.4.2.2.1.5 Reorganizarea Structurii

Aceasta metoda de transformare se concentreaza asupra Colectiei Principale în care opereaza modificari de structura prin segmentarea Entitatilor. Se ajunge la descrierea Secvential Ierarhizata a unei Structuri Ierarhice. Operatia consta în parcurgerea în Preordine a unui Arbore de Structura si alocarea pentru fiecare Nod a unei Entitati de descriere adecvata. Pentru detalii a se vedea Viziunile Partiale descrise în Spatiul de Informatii la Utilizator (sectiunea 3.4.4).

Localitate Marca Nume Vârsta

L1 M2 N2 V2 M5 N5 V1

L2 M1 N1 V3 M3 N3 V1

L3 M5 N5 V1

Fig. 3.4.2.2.1.5.1 Reorganizarea Structurii

Aceasta Structura de Date sta la baza Modelului Ierarhic, stimulând conceperea Procedurilor de Prelucrare organizate pe Aplicatii Independente.

Transformarea Structurilor Fundamentale 99

Remarcile care se pot face aici sunt urmatoarele:

Avantaje:

- Deschide drumul spre întelegerea necesitatea de a crea Viziuni Partiale asupra unui Ansamblu de Informatii, prin Transformarea Structurilor

- Este capabila sa foloseasca Medii de Memorare cu Performante Reduse

Dezavantaje:

- Modificarea Ordinii de Acces la Date implica Reorganizari de Structura, adaptate fiecarei Viziuni Particulare, ceea ce implica timpi mari de prelucrare, care devin prohibitivi când se opereaza cu volume mari de date

- Absenta posibilitatilor de combinare a Strategiilor de Acces descrise anterior 3.4.2.2.2 Generalizarea Conceptului de Inversare

Este deosebit de instructiva urmarirea procesului de Transformare a Structurilor în domeniul Structurilor Fundamentale. Am vazut ca la baza procesului de Transformare a Structurilor sta operatia de Inversare care poate fi redefinita prin generalizare în trei moduri:

- In cazul Structurilor Fundamentale:

§ Inversarea – este un proces de Structurare (crestere a Calitatii unei Structuri) prin stabilirea în cadrul unei Mutimi date a unor Clase de Echivalenta

- In domeniul Structurilor de Informatii descrise în Spatiul Entitate-Caracteristica-Valoare definitia poate fi refrazata astfel:

§ Inversarea – este un proces de determinare a Valorilor Izotipe Identice pentru Caracteristicile unei Structuri de Informatii

In general Inversarea poate fi privita ca o simplificare a descrierii unui ansamblu prin identificarea unor Parti Comune si scoaterea lor în Factor. Aceste Parti Comune trebuie privite ca niste Invarianti ai ansamblului, care odata evidentiati cristalizeaza Structura Ansamblului. Fixându-ne în domeniul structurilor Fundamentale putem face urmatoarele constatari:

§ Structura de tip Arborescenta poate rezulta dintr-o structura de tip Nivel prin aplicarea unei operatii de Inversare

§ Structura de tip Retea poate rezulta dintr-o structura de tip Arborescenta prin aplicarea aceleiasi operatii de Inversare

Aceasta necesita descoperirea unor elemente comune în Entitatile structurii de tip inferior. In caz de esec Structura de Tip Inferior (Nivel respectiv Arborescenta) nu poate fi transformata în Structura de Tip Superior (Arborescenta respectiv Retea).

Se regasesc astfel cele trei tipuri de Structuri Fundamentale definite anterior:

§ Nivel – Structura Primara

§ Arborescenta – Structura Evoluata de grad I

100 Transformarea Structurilor Fundamentale

§ Retea – Structura Evoluata de grad II

In Spatiul Datelor procesul de Inversare sta la baza Indexarii Colectiilor de Date, a carei implementare da Nota de Performanta a oricarui Sistem de Gestiune a Bazelor de Date.

Observatii:

Poate fi facuta urmatoarea comparatie între Modelele de Date utilizate în SGBD:

o Modelul Ierarhic

§ Arborescenta pentru Colectiile Principale

• Confera rigiditate Structurii de Date datorita necesitatii de refacere a Contextului prin inspectia secventiala a Segmentelor

§ Retea pentru Colectiile Secundare

• Limiteaza accesul la nivelul Segmentelor din Colectia Principala

o Modelul Retea

§ Retea pentru Colectiile Principale

• Mentine rigiditate în Structura de Date prin inspectia secventiala a Listelor de Articole (Setului)

§ Retea pentru Colectiile Secundare

• Limiteaza accesul la nivelul Articolelor Principale

o Modelul Relational

§ Nivel pentru Colectiile Principale

• Asigura simplitatea Colectiilor Principale

• Ofera flexibilitate în inspectia si extinderea Colectiilor Principale

§ Retea pentru Colectiile Secundare

• Asigura accesul la nivelul Tuplelor Simple sau de Legatura

• Maxim dinamism în crearea, modificarea si refacerea Colectiilor Secundare

Toti Operatorii Relationali sunt definiti doar pe Structura Simpla a Colectiei Principale (Multime de Tuple Neordonate, de Valori Elementare).

Structura de tip Retea prezenta în Colectiile Secundare nu afecteaza cu nimic simplitatea structurii Modelului Relational întrucât Colectiile Secundare nu intervin niciodata în construirea structurilor relationale, care se bazeaza exclusiv pe Referirea Asociativa. Prin aceasta se mentine totodata independenta fata de Suportul de Memorare al Structurii de Date, Colectiile Secundare putând sa fie refacute în orice moment prin operatia de Reindexare a Structurii Principale. Consecintele acestei caracteristici se regaseste în faptul ca orice portare de Structura Relationala pe alt suport de memorare este asigurata prin copierea doar a Structurii Principale (eventual a Expresiilor de Indexare atasate acestor colectii), Colectiile Secundare, de tip Index fiind apoi refacute pe noul suport.

Reprezentarea Structurilor de Informatii si de Date 101

3.4.3 Reprezentarea Structurilor de Informatii si de Date

Reprezentarea Structurilor de Informatii si Date se refera la utilizarea unor instrumente care formalizeaza descrierea concentrata, dar totodata fidela a continutului în Informatii si Date al unor Spatii de Reprezentare destinate a preciza:

- Specificatiile de Definitie ale unor Cerinte ce se cer îndeplinite de un Proiect, cerinte ce se nasc în Spatiul Utilizatorului (Spatiul Informatiilor)

- Modelul de Reprezentare a Datelor în vederea prelucrarii lor cu ajutorul unor instrumente adecvate de calcul

Ca metode generale de reprezentare se folosesc cel mai adesea metodele grafice, datorita caracteristicilor lor de:

§ Expresivitate

§ Precizie

§ Conciziune

§ Simplitate

Dintre metodele cele mai des folosite în descrierea Sistemelor cu Baze de Date prezentam urmatoarele:

o Reprezentarea Fizica

o Reprezentarea Logica (Simbolica)

o Arborele de Structura

o Diagrama Entitati– Relatii

o Schema de Descriere

Pentru întelegerea termenilor utilizati în descrierea simbolurilor grafice se vor face adesea referiri la notiunile prezentate în detaliu in sectiunea 4.1.1. De aceea o reluare a prezentei sectiuni, dupa parcurgerea sectiunii mai sus amintita, este binevenita.

3.4.3.1 Reprezentarea Fizica (Reprezentarea Clasica)

In reprezentarea Fizica se utilizeaza descrierea Structurilor cu ajutorul Valorilor, care desemneaza Entitatile Obiect, denumite si Instantele (Realizarile) de Entitati Notiune, precum si Legaturile de Structura existente între Elementele Concrete cu care se opereaza pentru rezolvarea unei probleme date. De aici provin si principalele caracteristici ale acestei forme de reprezentare, constituite atât ca avantaje cât si ca dezavantaje:

- Precizia de reprezentare, chiar a situatiilor complicate sau delicate

- Expresivitatea care permite întelegerea usoara a specificului fiecarui element în parte, precum si a legaturilor dintre ele

- Comunicarea simpla, directa si rapida între utilizatori diversi ca pregatire

- Grad mare de detaliu, cu extinderea pronuntata a reprezentarilor integrale

102 Reprezentarea Structurilor de Informatii si de Date

Aceste reprezentari pot fi extinse de la simpla prezenta a relatiilor de Incluziune si Echivalenta, la rafinarea Echivalentelor în Disjunctive si Conjunctive, Incluziunile în Partitii si Acoperiri s.a.m.d.

Reprezentarea se bazeaza pe prezenta Entitatilor Obiect vazute succesiv ca:

- Elemente individuale (Ascendenti)

- Multimi de Elemente (Descendenti)

Fig. 3.4.3.1.1. Reprezentarea Fizica

Reprezentarea se poate continua pâna când se ajunge la Elemente Nedecompozabile.

Utilitatea reprezentarilor este limitata la lamurirea detaliilor de structura, în special în cazurile neclare sau controversate, cum ar fi: Partajarea Elementelor, Nivelele Variabile de Descendenta pe ramuri diferite, Semantica Legaturilor de Descendenta, Modul de Identificare (Contextuala sau Necontextuala) etc. Metoda se foloseste pentru reprezentarea Structurilor Fizice de Informatii si Date.

Exemplu

Fig. 3.4.3.1.2 ofera un exemplu de utilizare a metodei Fizice de descriere a unei structuri de Informatii în cazul Structurii Organizatorice a unei unitati de învatamânt superior. Particularitatile de structura pe care le releva detaliile reprezentarii Fizice în exemplul analizat sunt:

- Se poate distinge o Structura Organizatorica Administrativa a Anilor si Grupelor de Studenti

- Structura Organizatorica Administrativa nu poate satisface toate cerintele didactice de constituire a Formatiilor de Studiu

- Formatiile de Studiu asigura necesitatile de regrupare a studentilor pentru:

o Instruirea în cadrul Trunchiurilor Comune de Studiu

Entitate Obiect ≡ Clasa de Entitati Obiecte

- ascendent -

Entitate Obiect ≡ Clasa de Entitati Obiecte

- descendent / ascendent -

Entitate Obiect ≡ Clasa de Entitati Obiecte

- descendent / ascendent -

Entitate Obiect ≡ Clasa de Entitati Obiecte

- descendent / ascendent -

Entitate Obiect- descendent -

Entitate Obiect - descendent -

Reprezentarea Structurilor de Informatii si de Date 103

o Redistribuirea pe Formatii pentru Optiuni de Studiu (Limbi Straine, Educatie Fizica, Specialitati etc.)

Se evidentiaza faptul ca structura poate fi privita ca o Padure de Arbori, fiecare Arbore putând sa fie extras prin filtrare cu ajutorul unei conditii prestabilite (Structura Organizatorica sau / si Structura Didactica).

Legenda U – Universitate A- An de Studenti FS – Formatie de Studiu F – Facultate G – Grupa de Studenti P – Profil S - Student

Fig. 3.4.3.1.2. Structura unei Universitati în Reprezentare Fizica

3.4.3.2 Reprezentarea Logica (Reprezentarea Simbolica)

In reprezentarea Logica se utilizeaza descrierea cu ajutorul Numelor, pentru precizarea Entitatilor Notiune, care desemneaza totodata, în forma potentiala, Clase de Entitati Obiecte, precum si Legaturi de Structura între Entitatile Notiune definite anterior. Forma potentiala de reprezentare a Clasei de Entitati Obiecte, sugereaza faptul ca popularea Clasei de Entitati cu Instante (Entitati Obiecte) se va face doar la încarcarea cu Valori a Bazei de Date. La acestea se adauga si constatarea ca Multimea Valorilor de Instanta este în continua schimbare prin operatiile de actualizare a Bazei de Date, fara ca Entitatea Notiune atasata sa sufere vreo modificare. Neglijarea Planului de Valori în reprezentarea Simbolica introduce un Nivel mai Abstract de descriere a Caracteristicilor Esentiale ale Structurii, prin accentuarea Generalului, odata cu omiterea Particularului.

U

F1 F2 F3 FS 1 FS 2

P1 P2 P3

A1 A2 A3

G1 G2 G3

S1 S2 S3 Sn

P1 P2 P3 P1 P2 P3

A1 A2 A3 A1 A2 A3

G1 G2 G3 G1 G2 G3

S1 S2 S3 Sn

104 Reprezentarea Structurilor de Informatii si de Date

Conventiile de reprezentare se reduc la cele continute în Fig. 3.4.3.2.1.

Fig. 3.4.3.2.1 Conventiile grafice de reprezentare a Schemei Simbolice

Caracteristici acestei forme de reprezentare sunt:

- Conciziunea de Reprezentare, chiar pentru spatii mari de cuprindere

- Putine Conventii de Reprezentare a specificului Caracteristicilor si Legaturilor

- Comunicarea Rapida între utilizatori cu o pregatire relativ redusa

Reprezentarea se bazeaza pe prezenta Entitatilor Notiune vazute simultan ca:

- Elemente Abstracte (Entitati Notiune)

- Multimi Potentiale de Elemente Concrete (Clase de Entitati Obiect)

Conventiile folosite conduc la reprezentari de forma celei din Fig. 3.4.3.2.2. Utilitatea reprezentarilor este foarte generala, datorita conciziei si expresivitatii sale. Se

foloseste pentru reprezentarea Structurilor Logice de Informatii si Date. Pornind de la numele cercetatorului care a introdus aceasta metoda de reprezentare pe scara larga în activitatea de

nEntitate Notiune ≡

Clasa potentiala de Entitati Obiecte

i

1 n

1 n

i

m n

i

i

m n

- Entitate Notiune – numele Entitatii Notiune, care reprezinta si Clasa potentiala de Entitati Obiecte

- n – Numarul estimat de elemente în Clasa de

Entitati Obiecte - Sageata Continua – Legatura Fundamentala

între Entitati Notiuni - n – Numarul de elemente în Clasa de

Ansambluri de Entitati Obiecte Membri (unul sau mai multi Membri)

- m - Numarul de elemente în Multimea

Proprietarilor unei Clase de Ansambluri de Entitati Obiecte Membri (unul sau mai multi Proprietari)

- i – Descrierea Intensionala (prin Nume) a

relatiei între Entitatile Notiuni (poate fi în general subînteleasa)

- Sageata Punctata – Legatura Derivata între

Entitati Notiuni

Reprezentarea Structurilor de Informatii si de Date 105

proiectare, în cadrul laboratoarelor firmei IBM, formalismul mai poarta si numele de Diagrama Bachman.

Fig. 3.4.3.2.2 Reprezentarea Simbolica

In legatura cu specificarea semnificatiei Descrierii Intensionale (i) s-a facut observatia ca ea poate în general sa fie subînteleasa în acele scheme de reprezentare în care ne rezumam exclusiv la descrierea Naturii Legaturilor, în termenii Legaturilor Fundamentale între Informatii si Date. Atunci când între doua Entitati Notiune apar Legaturi Multiple acestea se cer diferentiate semantic prin Legaturi Concretizate, fapt ce determina si necesitatea implementarii lor separate. Diferentierea se realizeaza cu ajutorul Descrierii Intensionale, care poate fi ca urmare:

o Generala – descrie doar natura Legaturii între Posesor si Membri ca de exemplu:

§ Legaturi 1 – 1

§ Legaturi 1 – n

§ Legaturi m – n

o Concreta – precizeaza un raport expres între Posesor si Membri ca de exemplu:

§ m Ascendenti au n Descendenti

§ 1 Document are n Rânduri

§ 1 Producator are 1 Adresa

§ 1 Grupa are n Studenti

§ 1 Unitate este de n Tipuri

Legaturile de tip Are si Este pot descrie Semantica Legaturii în termenii Modelului Obiectelor Abstracte, care utilizeaza facilitati de Abstractizare de genul urmator:

- Agregare - descrisa de o legatura de tip Are

- Generalizare sau Categorisire - descrisa de o legatura Este

Entitate Notiune 1 ≡ Clasa potentiala de Entitati

Obiecte 1

Entitate Notiune 3 ≡ Clasa potentiala de Entitati

Obiecte 3

Entitate Notiune 4 ≡ Clasa potentiala de Entitati

Obiecte 4

Entitate Notiune 2 ≡ Clasa potentiala de Entitati

Obiecte 2

1

1 n

i

1

1 1

n n

m

n

n

n

i

i

i

i

i

106 Reprezentarea Structurilor de Informatii si de Date

Exista si alte categorii de Legaturi Generale a caror semnificatie poate fi cuprinsa în Descrierea Intensionala rafinând-o semantic, cum ar fi implementarea Rolurilor Abstracte a Subtipurilor de Clasificare (Disjuncte sau Nedisjuncte) etc. Când declararea unor asemenea Legaturi, mai profund descrise, dispune de Conventii Precise de Implementare, continutul crescut în informatii al reprezentarii poate fi în mod automat transpus în Structurile de Date generate. Produsele Evoluate de Modelare permit si Descrierea Orientata a Intensiunii Legaturilor:

- Legatura Directa – de la Entitatea 1 la Entitatea 2 (1 Grupa are n Studenti)

- Legatura Inversa – de la Entitatea 2 la Entitatea 1 (1 Student apartine la 1 Grupa)

Legenda

U – Universitate A - An de Studenti FS – Formatie de Studiu F – Facultate G – Grupa de Studenti d – Legatura de Descendenta

P – Profil S - Student

Fig. 3.4.3.2.3 Structura unei Universitati în Reprezentare Simbolica

Exemplu

Ca exemplificare se apeleaza la aceeasi structura organizatorica a unei unitati de învatamânt superior, ilustrata în Reprezentare Logica în Fig. 3.4.3.2.3. Utilizarea aceluiasi exemplu permite evidentierea diferentelor între celor doua tipuri de reprezentari. In reprezentarea din exemplu, întrucât apar doar Legaturi de Descendenta, mentionarea expresa a semnificatiei lor poate fi omisa ceea ce descarca schema de repetari de descrieri.

n

n

1

n

1

d

1

d

n d

n 1

1U

3F

2FS

5A

3G

1000S

1 n

n

1

1

1

n

d

d

d

d

d

Reprezentarea Structurilor de Informatii si de Date 107

3.4.3.3 Arborele de Structura

Arborele de Structura utilizeaza tot reprezentarea cu ajutorul Numelor, deci cea specifica Nivelului Logic. Particularitatea acestei metode de reprezentare consta în orientarea ei spre implementarea descrierilor din Spatiul de Informatii în Modelele specifice Spatiului Datelor. Urmarind aceste deziderate formalismul va desemna caracteristicile ce descriu Nivelul Conceptual al Modelului de Date ales pentru implementarea Structurilor de Informatii. Conventiile de reprezentare sunt cele din Fig. 3.4.3.3.1.

Fig. 3.4.3.3.1 Conventiile grafice pentru Arborelui de Structura în varianta Relationala

Reprezentarile prin Arbore de Structura sunt destinate Structurilor Logice de Date, indiferent de Modelul de Date utilizat (Ierarhic, Retea, Relational etc.). Conventiile grafice, care contin reprezentari nu numai pentru Entitati, ci si pentru Caracteristicile lor componente, vor fi însa diferit interpretate în Modele diferite, în special în ceea ce priveste Legaturile Specifice între Caracteristici, legaturi care construiesc structura si anume:

- Legatura Ierarhica între Segmente (Fig. 4.2.2.1.3)

- Legatura de tip Lista între Articolele din Set (Fig. 4.2.3.1.2)

- Legatura Relationala între Relatii (Fig. 3.4.3.3.4)

R

n

a

* i

- Cerc – Relatie - R - Numele Relatiei - n – Numarul estimat de tuple în relatie - Punct – Atribut al Relatiei - a – Numele Atributului - Asterisc – Constituent de Identificator al

Relatiei, Cheie Primara sau Candidata (toti Constituentii aceleiasi Chei vor porni din acelasi punct, marcând astfel Identificatorii Relatiei)

- i – Nume Constituent de Identificator - Linie Continua – Legatura de Agregare

Relatie- Atribut - Sageata Punctata – Legatura Relationala

între Cheie Straina si Cheie Primara - Linie Punctata – Legatura Relationala între

Atribute Comune

108 Reprezentarea Structurilor de Informatii si de Date

Exemplu: Ca exemplificare se apeleaza la aceeasi Structura de Date, ilustrata în Reprezentarile Fizice si Logice anterioare. Se va urmari în continuare modul de transformare într-o reprezentare în Model Relational de Date a acestor structuri definite în Spatiul de Informatii (pentru lamuriri vezi si sectiunea 3.4.4.3). Sa consideram în reprezentare concentrata Entitatile Notiune si Legaturile dintre ele (Fig. 3.4.3.1.8).

U – Entitate UNITATE

o – Legatura Organizatorica d – Legatura Didactica f – Legatura Functionala s – Legatura Derivata de Structura

Fig. 3.4.3.3.2 Structura unei Universitati în reprezentare Simbolica Concentrata Este de notat faptul ca în aceasta noua forma de reprezentare a aceluiasi Spatiu de Informatii (Fig. 3.4.3.2.3) apar urmatoarele particularitati:

- Se mentine dezinteresul fata de Forma de Implementare a Legaturilor între Entitati, aceste detalii fiind transferate în Modelul de Date

- Apare ca strict necesara Descrierea Intensionala Nuantata a Legaturilor între Entitati, prin aceasta recuperându-se o parte importanta a continutului de informatii ce se cere cunoscut

Înainte de a ajunge în Spatiul Datelor trecem printr-o forma intermediara de Reprezentare Simbolica a Structurii Logice de Date prin figurarea si a altor Entitati:

o Relatia de Legatura STRUCTURA (S) care va permite Implementarea Relationala a Legaturilor de Structura (Ascendenta si Descendenta)

o Relatiile TIP UNITATE (TU) si TIP STRUCTURA (TS) care vor permite Clasificarea Claselor de Entitati descrise de Relatiile UNITATE si STRUCTURA

Se obtine Diagrama din Fig. 3.4.3.3.3, unde se observa:

o Transformarea Legaturilor de Descendenta (Organizatorice, Didactice si Functionale) pe U în Legaturi de Ascendenta si Descendenta între U si S

o Mentinerea Legaturii Induse (Derivate) pe U (Legatura m – n)

o Aparitia Legaturilor de Clasificare (c) între TU si U, respectiv între TS si S

f

d s

300U

m

1

1

o

n

n

n

Reprezentarea Structurilor de Informatii si de Date 109

U – Entitate UNITATE TU – Entitate TIP UNITATE S – Entitate STRUCTURA TS – Entitate TIP STRUCTURA d – Legatura de Descendenta

• - Organizatorica • - Didactica • - Functionala

a – Legatura de Ascendenta • - Organizatorica • - Didactica • - Functionala

s – Legatura Derivata de Structura c – Legatura de Categorisire

Fig. 3.4.3.3.3 Structura unei Universitati în reprezentare Simbolica Extinsa

Modelul de Date la care se ajunge în final este reprezentat în Fig. 3.4.3.3.4. Legaturile din Diagramele Simbolice se transforma aici in Legaturi Relationale implementate prin Referirea Asociativa între Atribute Comune:

o U. t → TU. i – Semantica: Unitatile de un Tip & Tipul unei Unitati

o S. t → TS. i – Semantica: Structurile de un Tip & Tipul unei Structuri

o S. uc → U. i – Semantica: Descendentii unei Unitati & Ascendentul unei Unitati

o S. ua → U. i – Semantica: Ascendentii unei Unitati & Descendentul unei Unitati

Arborele de Structura ca metoda de reprezentare face parte, dupa cum s-a mentionat înca de la începutul sectiunii, din categoria Reprezentarilor Logice, întrucât cuprinde caracteristicile specifice Modelului de Date, descrise prin Nume. El va fi ca atare utilizat pentru descrierea Spatiului Datelor în Plan Logic. Deoarece vor exista caracteristici specifice fiecarui Model de Date vor exista ca urmare si simboluri particulare de reprezentare a acestor caracteristici. Ceea ce trebuie retinut în finalul exemplificarilor legate de ultima metoda de reprezentare descrisa sunt urmatoarele observatii:

- Arborele de Structura se refera la Modelul de Date utilizat pentru prelucrarea datelor cu ajutor SGBD-ului (în speta un Model de Date Relational)

- In spatele acestui Model de Date sta o viziune corespunzatoare a Spatiului de Informatii, adica un Model de Informatii, modificat fata de prima Reprezentare Simbolica ; el este redat în Fig. 3.4.3.3.2 si Fig. 3.4.3.3.3

n

d

300U

a 1 1

s

e n

1500S

50

TU

5TS

m n

1

n 1

c

c

110 Reprezentarea Structurilor de Informatii si de Date

- Exista nu numai mai multe Modele de Date corespunzatoare unui Model de Informatii, ci si mai multe Modele de Informatii corespunzatoare unor Viziuni diferite ale aceleiasi Realitati supuse analizei

- Procesul de transformare a unei Viziuni în Spatiul Informatiilor într-o Viziune în Spatiul Datelor poarta numele de Transformare Directa (Proces de Engineering), vezi secventa de reprezentari continute în Fig. 3.4.3.3.2, Fig. 3.4.3.3.3 si Fig. 3.4.3.3.4.

- Procesul de modelare poate parcurge si un drum Invers, din Spatiul Datelor spre Spatiul de Informatii, în acest caz având de a face cu o Transformare Inversa (Proces de Reengineering), vezi secventa precedenta în ordine inversa

Relatii Atribute

U – UNITATE i – Identificator S – STRUCTURA UNITATII t – Tip TU – TIP UNITATE n – Nume (Universitate, Facultate, Profil, Specializare, An, Grupa) a - Adresa TS – TIP STRUCTURA uc – Unitate Curenta

(Organizatorica, Didactica, Functionala) ua – Unitate Ascendenta

Fig. 3.4.3.3.4 Structura unei Universitati reprezentata prin Arbore de Structura

Procesele de Transformare a Structurilor între Nivelele diferite de Reprezentare, vizeaza ansamblul componentelor care descriu un Model de Informatii si de Date (Structura, Restrictii, Operatii). Pentru detalii vezi sectiunea 4.2, precum si explicatiile referitoare la Fig. 4.2.4.8.3.2.6.

U

S

TU

TS

*

* *

*

*

i

uc

i

i

t

ua n

n

n

t

a

Reprezentarea Structurilor de Informatii si de Date 111

3.4.3.4 Diagrama Entitati – Relatii

In reprezentarea Entitati - Relatii sunt continute aceleasi elemente ca si în Reprezentarea Simbolica, dar se folosesc simboluri diferite, care încearca sa atraga mai mult atentia asupra prezentei Legaturilor ca elemente de aceeasi importanta ca si Entitatile.

Fig. 3.4.3.4.1 Conventiile grafice de reprezentare a Diagramei Entitati - Relatii

Aceasta varianta de reprezentare obliga pe utilizator sa înscrie în simbolul grafic atasat Relatiei de Legatura Numele acestei Legaturi, informatie care va putea fi direct transportata într-un produs care se ocupa în mod special cu Modelarea Datelor (ex. ERWIN, RATIONAL

1 n

m n

1 1

n Entitate Notiune ≡

Clasa potentiala de Entitati Obiecte

I 4

I 3

- Entitate Notiune – numele Entitatii Notiune, care reprezinta si Clasa potentiala de Entitati Obiecte

- n – Numarul estimat de elemente în Clasa de Entitati Obiect

- Romb cu linie continua – Legatura între doua

Entitati Notiune - n – Numarul de elemente în Clasa de

Ansambluri de Entitati Obiect Membri (unul sau mai multi Membri)

- m - Numarul de elemente în Multimea Proprietarilor unei Clase de Ansambluri de Entitati Obiect Membri (unul sau mai multi Proprietari)

- i – Descrierea Intensionala (prin Nume) a Legaturii între Entitatile Notiune

- Ii – Intrare în Legatura (Entitate Notiune) - Romb cu intrari multiple – Legatura între mai

mult de doua Entitati Notiune (maxim patru) - 1, n , m – Cardinalitatea Legaturilor Adiacente - i – Decrierea Intensionala (prin Nume) a

Relatiei Polinare între Entitatile Notiune - Ii – Intrare în Legatura (Entitate Notiune) - Romb cu linie punctata – Legatura Derivata

între Entitati Notiune - Aceleasi Conventii ca în cazul Legaturilor

Principale

m n I 1 I 2 i

m n I 1 I 2 i

m n I 1 I 2 i

m n I 1 I 2 i

m n I 1 I 2 i

112 Reprezentarea Structurilor de Informatii si de Date

ROSE, CAEN, VISIO etc.) si care va utiliza în descriere inclusiv Intensiunile Legaturilor. Conventiile de reprezentare utilizate în cadrul acestei metode sunt cele din Fig. 3.4.3.4.1.

Exemplul 1:

Ca exemplificare se aplica noua metoda pentru reprezentarea structurilor din Fig. 3.4.3.3.2 si Fig. 3.4.3.3.3. Consideratiile legate de continutul informatiilor reprezentate ramân valabile si în acest caz. Au rezultat schemele din Fig. 3.4.3.4.2, Fig. 3.4.3.4.3.

U – Entitate UNITATE

o – Legatura Organizatorica d – Legatura Didactica f – Legatura Functionala s – Legatura derivata de Structura

Fig. 3.4.3.4.2 Structura unei universitati în reprezentare Entitati – Relatii (Varianta 1)

Reprezentarea cu ajutorul Legaturilor Binare aduce cea mai mare precizie în metoda Entitati – Relatii, întrucât permite evidentierea pentru fiecare Legatura între Entitati a:

§ Descrierii Intensionale

§ A Cardinalitatii (Tipului 1 –1, 1 – n, m – n)

Utilizarea Legaturilor Polinare efectueaza o concentrare a reprezentarii, din care se pot deduce, prin descompunere Relatiile Binare implicate. Din reprezentare lipseste marcarea Entitatii de Legatura , care reprezinta Produsul Cartezian al celorlalte Entitati. O Solutie în acest caz ar putea fi cea d orientare a liniilor care intra si care ies din Romburile de Legatura. Necesitatea acestei precizari rezulta din exemplul ilustrat în Fig. 3.4.3.4.3.

Exemplul 2:

Se urmareste reprezentarea unei structuri care descrie Rezultatele la Examene ale Studentilor. Structura se realizeaza cu urmatoarele Entitati si Legaturi:

- Se pleaca de la trei Relatii de tip Entitate, ce pot fi privite ca Domenii de Definire a relatiei finale

n

m300

U

1 n o

s

1 n f

1

n

d

Reprezentarea Structurilor de Informatii si de Date 113

• DISCIPLINA

• PROFESOR

• STUDENT

- Se genereaza o Relatie de Legatura continând Rezultatele la Examene

• NOTA - N ⊆ P x D x S

U – Entitate UNITATE TU – Entitate TIP UNITATE S – Entitate STRUCTURA TS – Entitate TIP STRUCTURA d – Legatura de Descendenta

- Organizatorica, Didactica, Functionala a – Legatura de Ascendenta

- Organizatorica, Didactica, Functionala s – Legatura derivata de STRUCTURA c – Legatura fundamentala de CATEGORISIRE

Fig. 3.4.3.4.3 Structura unei Universitati în reprezentare Entitati – Relatii (Varianta 2)

Pot fi facute urmatoarele observatii legate de reprezentarea din Fig. 3.4.3.4.4:

- S-au impus urmatoarele Restrictii:

§ Se considera o singura Nota la o Disciplina, neglijându-se Forma de Examinare (Scris, Oral, Proiect, Lucrari Practice etc.)

§ Se accepta ca un Profesor poate preda mai multe Discipline si o Disciplina poate fi predata de mai multi Profesori

n n

1 1

n m

300

U

1500

S

50

TU

n 1 c

s

d a

5

TS

n 1 c

114 Reprezentarea Structurilor de Informatii si de Date

§ Se accepta ca un Profesor examineaza mai multi Studenti si un Student e examinat de mai multi Profesori

- Se remarca prezenta urmatoarei Restrictii Derivate:

§ O Nota e data de un singur Profesor, la o singura Disciplina, unui singur Student

- Pentru Legatura Polinara (r) si pentru Legaturile Binare Derivate (dp, ps, nd, ns, np) rezulta Cardinalitatile specificate în Diagrama din Fig. 3.4.3.4.4

- Daca Relatiile Binare au si descriptori proprii, ele vor trebui materializate prin Relatii de Legatura corespunzatoare

P – Entitate PROFESOR r – Legatura polinara REZULTATE D – Entitate DISCIPLINA dp – Legatura binara derivata DISCIPLINE / PROFESOR S – Entitate STUDENT ps – Legatura binara derivata STUDENTI / PROFESOR N –Entitate NOTA nd – Legatura binara derivata NOTE / DISCIPLINA N ⊆ P x D x S ns – Legatura binara derivata NOTE / STUDENT np – Legatura binara derivata NOTE / PROFESOR

Fig. 3.4.3.4.4 Rezultatele la Examene în reprezentare Entitati – Relatii

10000

S

n

n

30000

N

400

D

800

P

n

1

1 1

n

mn

m m

n

1

n

n

1

r

nd

dp ps

ns

np

1

1

Reprezentarea Structurilor de Informatii si de Date 115

3.4.3.5 Schema de Descriere

Reprezentarea unei Structuri de Date cu ajutorul Schemei de Descriere se bazeaza pe definirea unui limbaj specializat, denumit Limbaj de Descriere Date (LDD), care sa permita precizarea tuturor Elementelor (Obiectelor) care descriu o Baza de Date. Grupate pe Categorii acestea sunt urmatoarele:

o Elemente ce descriu Structura (Tabele de Baza, Atribute, Vederi)

o Elemente ce descriu Restrictii

§ Restrictii de Identitate (Chei Primare, Chei Candidate)

§ Restrictii de Referire (Chei Straine)

§ Constrângeri (Limite de Valori, Valori Compatibile, Restrictii semantice)

o Elemente ce descriu Operatii (Definire Proceduri Stocate, Triggeri)

Exemplu Se exemplifica metoda de reprezentare pentru structura din Fig. 3.4.3.4.4: RELATION

PROFESOR (Marca, Nume, Prenume, Functie, Titlu); PRIMARY KEY (Marca);

RELATION STUDENT (Marca, Nume, Prenume, Grupa); PRIMARY KEY (Marca)

RELATION DISCIPLINA (Cod, Denumire, Fel); PRIMARY KEY (Cod);

CANDIDATE KEY (Denumire) RELATION

EXAMEN (Profesor, Disciplina, Student, Nota); PRIMARY KEY (Profesor, Disciplina, Student); FOREIGN KEY (Profesor REFERENCES Profesor.Marca) ; FOREIGN KEY (Disciplina REFERENCES Disciplina.Cod); FOREIGN KEY (Student REFERENCES Student.Marca); CHECK (Nota >= 1 and Nota <=10)

Fig. 3.4.3.5.1 Rezultatele la Examene – Schema de Descriere

Initial un instrument de declarare a continutului unei Baze de Date, Limbajul de Descriere a Datelor a fost pe parcurs înlocuit cu Interfete Interactive de introducere, stergere si modificare dinamica a continutului Bazei de Date Logice. Ridicat Intre timp la un nivel avansat de standardizare, LDD îsi mentine în prezent un important rol în descrierea continutului unei BDL în vederea asigurarii urmatoarelor activitati de administrare a Bazei de Date:

- Salvarea / Restaurarea continutului unei BDL

- Conversia (Transferul) continutului unei BDL între diferite SGBD-uri

116 Structuri de Informatii la Utilizator

3.4.4 Structuri de Informatii la Utilizator

In aceasta sectiune se încearca sa se prezinte într-un mod sugestiv noutatea pe care o aduc Sistemele cu Baza de Date în ceea ce priveste organizarea Structurilor de Informatii. Se va putea vedea de ce o multime de Colectii de Date poate sa nu satisfaca gradul de integrare cerut de o Baza de Date. De asemenea va apare deslusit faptul ca Informatiile sunt continute nu doar în Entitati si Atribute, ci si în Legaturile între Entitati. Se insista în final asupra noii Viziuni asupra Spatiului propriu de Informatii pe care Utilizatorul trebuie sa o dobândeasca. 3.4.4.1 Structura de Ansamblu

Sa consideram nucleul informatiilor dintr-un compartiment de Vânzari, alcatuit din trei Categorii de Informatii: Beneficiari, Produse si Contracte. Atributele care descriu aceste Colectii de Date sunt redate mai jos:

o BENEFICIARI – Categorie de Informatii ce descrie Partenerii Comerciali interesati în cump ararea unor Produse. Atributele care caracterizeaza aceasta Clasa de Entitati sunt:

- Cod - Telefon

- Nume - Banca

- Tip Societate - Cont

- Adresa - Etc.

o PRODUSE - Categorie de Informatii ce descrie Produsele în care Beneficiarii sunt interesati. Atributele care caracterizeaza aceasta Clasa de Entitati sunt:

- Cod - Greutate

- Denumire - Stoc

- Pret - Calitate

- Culoare - Etc.

o CONTRACTE - Categorie de Informatii ce descrie Documentele Comerciale (Contractele) care stau la baza relatiilor de Vânzare – Cumparare. Atributele care caracterizeaza aceasta Clasa de Entitati sunt:

Antet Document Rânduri Document

- Beneficiar (Codul Beneficiarului) - Produs (Codul Produsului)

- Numar Contract - Cantitate Contractata

- Data Contract - Pret de Livrare

- Clauze Contractuale - Termen de Livrare

- Etc. - Etc. In cele ce urmeaza CONTRACTELE vor fi reprezentate de Antet, în timp ce Informatiile din Rânduri vor descrie Pozitiile Contractuale (vezi Fig. 3.4.4.1.1).

Structuri de Informatii la Utilizator 117

Categoriile de Informatii sugerate în enumerarea precedenta vor putea fi completate, de la caz la caz cu alte detalii. O structura reala însa implica un numar mult mai mare de Informatii care sa rafineze descrierea. Pentru a putea urmari demersul legat de desprinderea noutatii pe care o aduce viziunea Structurilor de tip Baza de Date ne vom rezuma doar la informatiile de baza (Fig. 3.4.4.1.1), prezentate în contextul consemnarii urmatoarelor Fapte:

o Beneficiarul B1 a stabilit Relatiile Comerciale din Contractele C1, C3

§ Contractul C1 contine Pozitiile Contractuale referitoare la Produsele P1

§ Contractul C3 contine Pozitiile Contractuale referitoare la Produsele (P1, P2

o Beneficiarul B2 a stabilit Relatiile Comerciale din Contractele C2

§ Contractul C2 contine Pozitiile Contractuale referitoare la Produsele P1, P2, P3

Fig. 3.4.4.1.1 Structura de Informatii în compartimentul Vânzari

Din aceste Informatii Primare iau nastere urmatoarele Informatii Derivate:

o Pentru Beneficiarul B1 rezulta Obligatiile Comerciale referitoare la Produsele P1, P2

n

n

n

Relatii Contractuale

BENEFICIARI

B 1

n

n

n

n

n

n

B 2

PRODUSE

CONTRACTE

nObligatii

Contractuale

Pozitii Contractuale

C 1

P 1

C 2

P 2 P 3

C 3

118 Structuri de Informatii la Utilizator

o Pentru Beneficiarul B2 rezulta Obligatiile Comerciale referitoare la Produsele (P1, P2, P3

Din Fig. 3.4.4.1.1 rezulta prezenta în Spatiul Informatiilor a doua tipuri de informatii:

- Informatii descriptive ale Categoriilor (Grupurilor) definite:

• BENEFICIARI

• PRODUSE

• CONTRACTE

- Informatii de Legatura între Categoriile de Informatii definite:

§ Relatii Contractuale – consemnarea în cadrul unui CONTRACT a conditiilor generale de livrare catre un anume BENEFICIAR

B i are Legaturile Contractuale din C j

§ Pozitii Contractuale – specificarea în cadrul CONTRACTELOR a conditiilor detaliate de livrare pentru fiecare PRODUS

C i are Pozitiile Contractuale pentru P k

§ Obligatii Contractuale – centralizarea pe PRODUSE a sarcinilor de livrare catre fiecare BENEFICIAR

Fata de B i sunt consemnate Obligatiile Contractuale pentru P k

Luând în considerare si modul în care iau nastere informatiile în Spatiul de Informatii se poate realiza o categorisire a acestora.

o In domeniul Categoriilor de Informatii:

§ Categorii de Informatii Independente

• BENEFICIARI

• PRODUSE

§ Categorii de Informatii Dependente

• CONTRACTE

o In domeniul Legaturilor între Categorii de Informatii:

§ Legaturi Primare (reprezentate în figura prin linii continue)

• Relatii Contractuale

• Pozitii Contractuale

§ Legaturi Derivate (reprezentate în figura prin linii punctate)

• Obligatii Contractuale

Legaturile Derivate pot fi deduse din proprietatea de Tranzitivitate a relatiei descrise de Categoria de Informatii CONTRACTE si conferita de semantica atasata Legaturilor între Categoriile de Informatii. Se zice ca Legaturile Derivate sunt induse de Legaturile Primare.

Structuri de Informatii la Utilizator 119

Din cele prezentate se remarca urmatoarele:

- In lumea reala Spatiile de Informatii sunt încarcate de informatii care se cer transpuse în Modelele de Date care doresc sa ofere o fidelitate cât mai mare

- Utilizatorii Structurilor de Ansamblu lipsesc în general, fiind înlocuiti de Grupuri de Utilizatori interesati doar în Viziuni Partiale ale ansamblului

- Definirea continutului general al Structurii de Ansamblu trebuie sa fie rezultatul unei activitati de sinteza , ce cade în sarcina Informaticianului , neputând fi rodul unei simple actiuni de colationare a cerintelor partiale deduse prin analiza

3.4.4.2 Structuri Partiale

Pornind de la remarcile anterioare sa urmarim cu ce viziuni particulare se confrunta proiectantul de structuri.

Structura Partiala I

Structura este specifica utilizatorului interesat de imaginea CONTRACTELOR cu Beneficiarii. Structura e reprezentata de o viziune ierarhica pe trei nivele care descrie:

Relatiile Contractuale cu Beneficiarii B i

defalcate pe Contractele Cj

si Produsele Pk din Pozitiile Contractuale

Fig. 3.4.4.2.1 Structura Partiala I (BENEFICIARI / CONTRACTE / PRODUSE)

Legaturile de dependenta Ierarhica sunt ilustrate în Diagrama Simbolica din Fig. 3.4.4.2.2.

n nB 1

n n

n nn

B 2

n

C 1

P 1

C 2

P 2 P 3

C 3

BENEFICIARI

PRODUSE

CONTRACTE

Relatii Contractuale

Pozitii Contractuale

120 Structuri de Informatii la Utilizator

Fig. 3.4.4.2.2 Structura Partiala I (Diagrama Simbolica)

Structura Partiala II

Structura este specifica utilizatorului interesat de imaginea regrupata pe BENEFICIARI si PRODUSE a CONTRACTELOR cu BENEFICIARII. Structura e reprezentata de o viziune ierarhica pe trei nivele care descrie:

Obligatiile Contractuale fata de Beneficiarii B i

centralizate pe Produsele Pk

si defalcate pe Pozitiile Contractuale din Contractele Cj

Fig. 3.4.4.2.3 Structura Partiala II (BENEFICIARI / PRODUSE / CONTRACTE)

Relatii Contractuale

BENEFICIARI

PRODUSE

CONTRACTE

Pozitii Contractuale

1

n

m

n

C 3

Obligatii Contractuale

n nB 1

n n

n nn

B 2

nC 1

P 1

C 2

P 2 P 3

BENEFICIARI

PRODUSE

CONTRACTE

Pozitii Contractuale

Structuri de Informatii la Utilizator 121

Fig. 3.4.4.2.4 Structura Partiala II (Diagrama Simbolica)

Structura Partiala III

Structura este specifica utilizatorului interesat de imaginea regrupata pe PRODUSE si CONTRACTE a CONTRACTELOR cu BENEFICIARII. Gruparea e utila pentru Programele de Productie orientate pe clauzele contractuale (Termene). Structura e reprezentata de o viziune ierarhica pe trei nivele care descrie:

Pozitiile Contractuale centralizate pe Produsele Pk

din Contractele Cj

si regrupate pe Relatiile Contractuale cu Beneficiarii B i

Fig. 3.4.4.2.5 Structura Partiala III (PRODUSE / CONTRACTE / BENEFICIARI)

BENEFICIARI

PRODUSE

CONTRACTE

Pozitii Contractuale

m

n

Obligatii Contractuale

m

n

n

Relatii Contractuale

n n

B 1 n

n

nn

B 2

nC 1

P 1

C 2

P 2 P 3

C 3

BENEFICIARI

PRODUSE

CONTRACTE

Pozitii Contractuale

122 Structuri de Informatii la Utilizator

Fig. 3.4.4.2.6 Structura Partiala III (Diagrama Simbolica)

Structura Partiala IV

Structura este specifica utilizatorului interesat de imaginea regrupata pe PRODUSE si BENEFICIARI a CONTRACTELOR cu BENEFICIARII. Gruparea e utila pentru Programele de Livrare orientate pe destinatiile expeditiilor (Adrese de Beneficiari). Structura e reprezentata de o viziune ierarhica pe trei nivele care descrie:

Obligatiile Contractuale pentru Produsele Pk

regrupate pe Beneficiarii B i

si defalcate pe Pozitiile Contractuale din Contractele Cj

Fig. 3.4.4.2.7 Structura Partiala II (PRODUSE / BENEFICIARI / CONTRACTE)

Relatii Contractuale

n

1

BENEFICIARI

PRODUSE

CONTRACTE

Pozitii Contractuale

m

n

n

Obligatii Contractuale

n n

B 1

n

n

n

n

B 2

nC 1

P 1

C 2

P 2 P 3

C 3

BENEFICIARI

PRODUSE

CONTRACTE

Pozitii Contractuale

Structuri de Informatii la Utilizator 123

Fig. 3.4.4.2.8 Structura Partiala II (Diagrama Simbolica)

Structura Partiala V

Structura este specifica utilizatorului interesat de imaginea regrupata pe PRODUSE a CONTRACTELOR cu BENEFICIARII. Gruparea e utila pentru Situatiile Statistice utilizate pentru evaluarea indicatorilor de performanta ai Produselor (Valoare Contractata, Ritmicitate de Livrare etc.). Structura e reprezentata de o viziune ierarhica pe doua nivele care descrie:

Sinteza pe Produsele Pk

a valorilor Obligatiilor Contractuale fata de Beneficiarii B i

si a valorilor din Pozitiile Contractuale din Contractele Cj

Fig. 3.4.4.2.9 Structura Partiala II (PRODUSE / BENEFICIARI si CONTRACTE)

1

n

Obligatii Contractuale

Relatii Contractuale

BENEFICIARI

PRODUSE

CONTRACTE

m

n

nP 3

n

Obligatii Contractuale

n

B 1

n

n

n

n

B 2

nC 1

P 1

C 2

P 2

C 3

BENEFICIARI

PRODUSE

CONTRACTE

Pozitii Contractuale

124 Structuri de Informatii la Utilizator

Fig. 3.4.4.2.10 Structura Partiala V (Diagrama Simbolica) 3.4.4.3 Reprezentarea Structurii de Ansamblu

Din analiza sectiunilor anterioare se pot trage urmatoarele concluzii:

- Structurile reale de informatii, prin continutul lor semantic, devin rapid suprapopulate

- Utilizarea metodelor de Reprezentare Fizica a Structurilor de Ansamblu sunt inoperante datorita încarcarii cu detalii a schemelor de reprezentare

- Reprezentarile Fizice ramân instrumente utile pentru relevarea cerintelor rafinate de structura în vederea încorporarii acestor detalii în Structura de Ansamblu

- Descompunerea în Structuri Partiale este o metoda specifica proiectarii clasice de aplicatii, orientate spre prelucrarea fisierelor de date

- In general, fiecare Structura Partiala corespunde în Programarea Clasica unei Aplicatii, întrunind cerintele doar a unui grup de utilizatori (vezi semnificatiile viziunilor ierarhice prezentate mai sus)

- Încercarea de tratare prin descompunere esueaza rapid prin numarul mare de variante combinatoriale (pentru trei Categorii de Informatii desfasurate pe trei nivele de ierarhizare rezulta 3! = 6 variante de descompunere, fara a lua în calcul si descompunerile pe doar doua nivele)

- Fiecare Structura Partiala anterior prezentata pierde aspecte de reprezentare a detaliilor structurale ale informatiilor, aspecte care ulterior pot fi cu greu recuperate

Solutia de Integrare a Viziunilor Partiale ale unei Structuri de Informatii este construirea unei Reprezentari Globale asupra întregului Spatiu de Informatii, care sa cuprinda toate tipurile de informatii prezente: Entitati, Atribute, precum si a Relatiilor între Entitati.

O asemenea reprezentare trebuie sa apeleze la conventii care sa elimine Particularul , încarcat de detalii, în favoarea Generalului sintetizator si reprezentativ. Din acest motiv reprezentarile simbolice sunt cele care ofera solutia cautata (Fig. 3.4.4.3.1).

m

n

Obligatii Contractuale

Relatii Contractuale

BENEFICIARI

PRODUSE

CONTRACTE

m

n

Structuri de Informatii la Utilizator 125

Fig. 3.4.4.3.1 Structura de ANSAMBLU (Diagrama Simbolica - Varianta Extinsa)

Varianta Extinsa contine toate trei Categoriile de Informatii si pe cele Independente (BENEFICIARI si PRODUSE) si pe cele Dependente (CONTRACTE). Se poate observa însa faptul ca a doua Categorie de Informatii este purtatoarea Informatiilor de Legatura între primele doua, putând ca urmare sa fie dedusa din Legatura existenta între acestea. Se ajunge la structura din Fig. 3.4.4.3.2, denumita si Varianta Concentrata de reprezentare (vezi sectiunea 3.4.3.2). Ca urmare, s-a ajuns la un mod de reprezentare care elimina o întreaga Categorie de Informatii (Informatiile de Legatura), care pot fi implicate de marcarea corecta a Relatiilor de Legatura între Entitatile Notiune din Structura.

Fig. 3.4.4.3.2 Structura de ANSAMBLU (Diagrama Simbolica - Varianta Concentrata)

Se întelege acum de ce Proiectarea la Nivel Înalt solicita Modele de Date care dispun de facilitatea, îndeobste neglijata de proiectantii începatori, de a descrie Relatii Fundamentale m – n, ce nu pot fi de fapt implementate direct în Structurile Bazelor de Date Relationale.

m

n

Obligatii Contractuale

Relatii Contractuale

BENEFICIARI

PRODUSE

CONTRACTE

1

n

m

n

Obligatii Contractuale

m

n

BENEFICIARI

PRODUSE

Obligatii Contractuale

126 Structuri de Informatii la Utilizator

Produsele care accepta introducerea unor asemenea structuri dispun si de posibilitatea de a genera automat Relatiile de Legatura sub forma unor Tabele de Baza distincte (ex. pornind de la descrierea din Fig. 3.4.4.3.2 produsul de modelare va genera automat structura din Fig. 3.4.4.3.1 prin adaugarea Tabelei de Baza CONTRACTE cu Legaturile Relationale aferente).

In concluzie se fac urmatoarele constatari:

- Varianta Concentrata se preteaza pentru reprezentari de Structuri Complexe, fiind si singura care poate fi controlabila în practica proiectarii

- Aceasta forma de reprezentare poate fi cu succes folosita pentru generarea automata a Categoriilor de Informatii Dependente, în cadrul produselor de Proiectare Asistata de Calculator a Modelelor de Date (ex. produsul ERWIN, [ERWM01] )

- Din ultima varianta de reprezentare se pierd detaliile legate de descrierea Atributelor Proprii Relatiilor de Legatura, în speta atributele proprii relatiei CONTRACTE (Numar Contract, Data Contract, Cantitate Contractata, Pret de Livrare, Termen de Livrare, Clauze Contractuale)

- In cazul generarii automate a Informatiilor Dependente (Tabelele de Legatura), ramâne în sarcina Proiectantului sa adauge Atributele Proprii acestor Tabele, atribute care descriu Intensitatea Relatiilor între Entitati

- O problema importanta legata de crearea Viziunilor de Ansamblu care sa ofere structurile adecvate construirii Bazelor de Date este legata de formarea Utilizatorului General, singurul interesat în crearea acestei baze de integrare a sistemului; de obicei acest Utilizator General trebuie selectat din esaloanele de Conducere a Unitatii care doreste implementarea unui Sistem Integrat

Înainte de a încheia aceasta sectiune, pe care o consideram foarte utila în definirea conturului Sistemelor cu Baze de Date, gasim aici locul de a face o referire la una din observatiile facute la începutul lucrarii si care a putut sa fie apreciata atunci doar ca o „Figura de Stil” în caracterizarea SBD. Este vorba de Comparatia folosita în sectiunea 1.2 cu Experimentul lui M. McKay. Instrumentele de Investigare a Structurilor de Informatii si de Date prezentate în aceasta sectiune pot juca rolul Retelelor de Filtrare utilizate în experimentul mentionat, pentru a descoperii Ordini Interne acolo unde se pare ca domina Hazardul, Întâmplarea Neprevazuta. Necesita multa Educatie pregatirea Utilizatorilor în a întelege ca Sistemul asteptat nu se poate construi acumulând Cerinte de Moment, Urgente Cotidiene, ci ca acestea trebuie subordonate unor Comandamente Superioare. Descoperirea Relatiilor Fundamentale în Structurile de Informatii si de Date, capacitatile acestora de a fi îmbunatatite prin Transformare, stabilirea prioritatilor între Informatiile Independente si cele Dependente, toate ridicate la forme de sinteza prin adecvate Mijloace de Reprezentare, ofera toate suportul de concepte necesar pentru mentinerea controlului asupra unor volume imense de Informatii.

Acesta este unul din drumurile deschise de preocuparile SBD spre un domeniu mai general de analiza si sinteza a Structurilor de Informatii, preocupare care prin îmbogatirea continutul în detalii al structurilor pune bazele Ingineriei Informatiilor. Atunci se va întelege îndemnul SBD de a renunta în conceperea Structurilor la simpla juxtapunere de Cerinte Particulare si Momentane, conferind procesului o Competenta Superioara în întelegerea rolului pe care îl joaca în Ansamblu fiecare Element de Structura .

Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati 127

3.4.5 Diversificarea Tipurilor de Legaturi între Entitati

Daca la Tipurile Fundamentale de Legaturi între entitati se adauga criterii suplimentare, se obtin deferite subclasificari ale acestor legaturi. Adaugarea de noi criterii înseamna sporirea semanticii atasata Relatiilor de Legatura si prin aceasta se creste posibilitatea introducerii de noi Restrictii Generale în descrierea intensionala a datelor. Aceste Restrictii vor fi încorporate în Nivelul Conceptual al Bazelor de Date sau, daca se proiecteaza la un nivel înalt, în Modelul de Date (vezi sectiunea 4.2.1.1).

Deoarece predilectia pentru continutul semantic adaugat legaturilor între relatii difera de la un producator la altul, am ales sa prezentam aceasta rafinare prin prizma a doua viziuni particulare promovate de doi cunoscuti producatori comerciali: ORACLE (SGBD-ul ORACLE) si LOGITECH (Produsul pentru construirea de Modele de Date ERWIN). 3.4.5.1 Viziunea în Produsul ORACLE

ORACLE [BARK01] foloseste în clasificarea legaturilor urmatoarele Criterii:

o Gradul Legaturii (Cardinalitatea)

§ Legaturi m - 1 Mai multe instante ale unei Entitati refera o instanta a altei Entitati

§ Legaturi 1 - 1 O instanta a unei Entitati refera o instanta a altei Entitati

§ Legaturi m – n Mai multe instante ale unei Entitati refera mai multe instante ale altei Entitati

o Optionalitatea Legaturii

§ Optionala Fiecare instanta a unei Entitati poate exista independent, cu sau fara asocierea cu alta instanta din Entitatea referita

§ Mandatata O instanta a unei Entitati poate exista numai daca exista o instanta asociata din Entitatea referita

Se remarca faptul ca tipul legaturii trebuie interpretata la cele doua extremitati, ceea ce determina descrierea tipului unei legaturi printr-o pereche de alternative: Optionala sau Mandatata. Se va remarca în conventiile grafice ce vor fi utilizate în continuare, aceasta dubla descriere a legaturii prin prezenta segmentului continuu pentru extremitatea Mandatata si a segmentului punctat pentru extremitatea Optionala.

o Repetitivitatea Legaturii

§ Nerecursiva Legatura porneste si se termina în Entitati diferite

§ Recursiva Legatura porneste si se termina în aceeasi Entitate

Aceeasi legatura poate fi clasificata dupa Criterii diferite. Rezulta urmatoarele cazuri de combinare:

128 Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati

o Legatura Nerecursiva

§ Legatura m - 1

• Mandatata la Optionala

Fig. 3.4.5.1.1 Copiii Angajatilor

Un Copil nu poate apare în Baza de Date decât asociat cu un Angajat. Presupunerea poate conduce la solutii care impun aceasta restrictie si anume: Un Copil nu poate fi identificat decât în asociere cu un Angajat.

• Optionala la Mandatata

Fig. 3.4.5.1.2 Produsele unui Pachet

Un Pachet nu poate apare în Baza de Date decât daca ambaleaza niste Produse. In acest caz restrictia semantica nu se reflecta si în modul de identificare a instantei de pachet întrucât un pachet poate contine în general mai multe produse. Ca atare restrictia semantica trebuie adaugata restrictiilor de identificare.

• Mandatata la Mandatata

Fig. 3.4.5.1.3 Rândurile unei Comenzi

Structura descrisa ia în considerare faptul ca o Comanda comerciala se descrie prin doua Clase de Entitati: COMENZI si RANDURI de COMANDA între care se descrie explicit Legatura Relationala Rândurile Comenzii. Doar aceasta viziune explica necesitatea restrictiei duble:

§ Nici-un Rând fara Comanda

§ Nici-o Comanda fara cel putin un Rând

Restrictia apare ca foarte utila în momentul în care Aplicatia o presupune, caci altfel Structura de Date poate face invizibile pentru prelucrari datele eronate: Rândurile necuprinse în Comenzi sau Comenzile fara Rânduri. Baza de Date având aceasta restrictie va împiedica introducerea datelor eronate.

COPII ANGAJATI Copiii Angajatilor

PRODUS PACHET

Produsele unui Pachet

RANDURI COMANDA

Rândurile unei Comenzi

Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati 129

Se impune o observatie importanta referitoare la legaturile Mandatata la Mandatata si anume faptul ca restrictiile impuse sunt întotdeauna verificate la sfârsitul unei tranzactii, care în acest caz trebuie sa implice actualizarea ambelor referiri aflate la extremitatile legaturii. (Ex. în aceeasi tranzactie trebuie prevazute adaugarile si stergerile necesare în sau din ambele colectii de date COMENZI si RANDURI, în caz contrar actualizarea Bazei de Date ar ramâne blocata).

• Optionala la Optionala

Fig. 3.4.5.1.4 Copii adoptatii

Fie o Baza de Date continând doua Clase de Entitati: COPII ABANDONATI si PERSOANE. Se urmareste consemnarea printr-o Relatie de Legatura a adoptiilor legalizate. In acest caz ambele extremitati ale legaturi ramân OPTIONALE putând exista COPII ABANDONATI ce nu au fost înca adoptati sau PERSOANE ce doresc sa adopteze, dar nu au gasit înca prilejul favorabil.

§ Legatura 1 - 1

• Mandatata la Optionala

Cazul propus în Fig. 3.4.5.1.5 este semantic similar cu cel prezentat în Fig. 3.4.5.1.1 (inclusiv restrictia de identificare), cu noutatea pe care o aduce particularitatea n=1, în societatile cu monogamie recunoscuta.

Fig. 3.4.5.1.5 Sotia Angajatului

• Optionala la Mandatata

Întrucât, datorita particularitatii n=1, relatia matematica implicata de legatura este simetrica, pentru acest caz poate fi utilizat exemplul din Fig. 3.4.5.1.5 inversat. Se remarca diferenta între cele doua cazuri:

• Fig. 3.4.5.1.5 - pornind de la ANGAJAT se afla SOTIA sa

• Fig. 3.4.5.1.6 - pornind de la SOTIE se afla sotul ca ANGAJAT

SOTIA ANGAJATULUI

ANGAJAT

Sotia Angajatului

COPII ABANDONATI

PERSOANE

Copii adoptatii

130 Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati

Fig. 3.4.5.1.6 Angajatul Sotiei

Exemplul a fost preferat pentru a se ilustra dubla functionalitate a oricarei legaturi relationale (directa si inversa) si prin aceasta relativitatea în alegerea Proprietarului si a Membrilor definitii printr-o relatie între doua multimi.

• Mandatata la Mandatata

Fig. 3.4.5.1.7 Certificatul unei Persoane

Orice PERSOANA trebuie sa aiba un CERTIFICAT de NASTERE si orice CERTIFICAT de NASTERE trebuie sa se refere la o PERSOANA. Aceasta realitate poate fi considerata ca o restrictie necesara într-o Baza de Date orientata spre utilizarea acestor informatii. Si aici se manifesta proprietatea de simetrie a relatie de legatura.

• Optionala la Optionala

- Fi

Fig. 3.4.5.1.8 Casatoriti

Intr-o Baza de Date care contine persoane cu Stare Civila diferita, grupate în doua Colectii de Date, organizate dupa atributul Sex, actualizarea oricareia dintre colectii ramâne Optionala. Restrictia semantica în acest caz ar putea sa fie în continuare rafinata în sensul transformarii tipului de legatura în functie de valoarea atributului Stare Civila (casatorit sau necasatorit), dar acest caz iese din sfera declararii pur Structurale a restrictiilor semantice si patrunde în sfera declararii Procedurale (corelarea amintita va trebui în acest caz rezolvata cu ajutorul unei Proceduri Stocate de tip Trigger, care sa evite actualizarile inadvertente). Discutia poate continua în sensul unei completari a declaratiei de Optionalitatea a Legaturii prin adaugarea unei Conditii

BARBAT

FEMEIE

Casatoriti

PERSOANA CERTIFICAT

De NASTERE

Certificatul unei Persoane

ANGAJAT SOTIA

ANGAJATULUI

Angajatul Sotiei

Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati 131

Suplimentare (ex. Starea Civila=’casatorit’ pentru Mandatat si Starea Civila=’necasatorit’ pentru Optional). In acest caz ramânem în sfera declaratiilor Structurale.

§ Legatura m - n

• Mandatata la Optionala

Fig. 3.4.5.1.9 Membrii Echipei

Prima Clasa de Entitati a fost aleasa ca MEMBRI si nu ca PERSOANE pentru a se consemna acceptia semantica ca persoanele sunt înregistrate în Baza de Date doar în calitatea lor de Membri ai unei Echipe. ECHIPA poate fi însa înregistrata înainte ca sa-i fie definiti MEMBRII. Un Membru însa poate face parte din mai multe Echipe (sa zicem activând în ramuri diferite de activitate).

• Optionala la Mandatata

Fig. 3.4.5.1.10 Echipele unei Persoane

Sa modificam acum acceptia semantica din Fig. 3.4.5.1.9, pe care o dorim implementata în Baza de Date dupa cum urmeaza. ECIPELE sunt urmarite numai ca un atribut al PERSOANELOR existente în Baza de Date. Persoanele vor intra si iesi în sau din Baza de Date optional, în timp ce echipele doar în masura în care sunt referite, parasind Baza de Date la stergerea ultimei persoane care le refera. Se remarca înca o data dependenta stricta a tipului de legatura de semnificatia care se doreste implementata în structura de date. Modificarea semnificatiei atasata unei legaturi determina necesitatea modificarii tipului de legatura memorat în descrierea Bazei de Date. Este evidenta problema adaptarii Valorii Datelor deja existente în Baza de Date la noile restrictii impuse. Produsele de proiectare avansata ofera doua posibilitati:

• Restrictie valabila retroactiv (se aplica si valorilor existente)

• Restrictie valabila ulterior (se aplica numai valorilor noi)

MEMBRI

ECHIPE Membrii Echipei

PERSOANE

ECHIPE

Echipele unei Persoane

132 Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati

• Mandatata la Mandatata

Fig. 3.4.5.1.11 Jucatorii unui Joc

Nu se accepta existenta în Baza de Date a unui JUCATOR fara JOC si nici a unui JOC fara JUCATORI, acceptându-se participarea unui JUCATOR la mai multe JOCURI simultan si evident si reciproc.

• Optionala la Optionala

Fig. 3.4.5.1.12 Parteneri

Urmarirea cuplurilor care se creeaza poate fi cu succes realizata într-o structura care accepta introducerea optionala a potentialilor parteneri (BARBATI si FEMEI) si declararea explicita a relatiei de Parteneri. (Se poate observa si faptul secundar ca structura oferita nu satisface toate gusturile de Parteneriat.)

o Legatura Recursiva

§ Legatura m – 1

• Mandatata la Optionala - Infinita Legaturile recursive sunt acceptate doar pe aceeasi Clasa de Entitati. Acest tip de legatura conduce la un apel continuu în structura daca cel putin una din extremitati este Mandatata. Aceasta situatie este structural inacceptabila, datorita neprecizarii Punctului de Taiere a Recursivitatii. Ca urmare, legatura e considerata Infinita fiind inacceptabila.

• Optionala la Mandatata - Infinita

• Mandatata la Mandatata - Infinita

• Optionala la Optionala

Acest tip de structura descrie Ascendenta într-o Structura Ierarhica (n Descendenti – 1 Ascendent).

JUCATORI JOCURI Jucatorii unui Joc

Barbati

Femei

Parteneri

Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati 133

In exemplul din Fig. 3.4.5.1.13. Structura Ierarhica e reprezentata de Structura Organizatorica a unei Companii care contine mai multe Departamente. Pentru a putea folosi proprietatea de Recursivitate (vezi sectiunea 3.1.3.) în structura de date se cere unificarea într-o singura descriere a tuturor Unitatilor care apar în structura de informatii (Companie, Departament, Birou, Grupa etc.). Aceasta este semnificatia Clasei de Entitati unice UNITATE din Figura.

Fig. 3.4.5.1.13 Ascendenta

Legatura fundamentala implementata este de tip Ierarhie (vezi sectiunea 3.4.3.). Restrictia adaugata structurii este cea de ascendent unic pentru fiecare UNITATE, mai putin Radacina, ceea ce implica acceptarea conditiei Nedefinit pentru referinta ascendenta, implementata ca un atribut al UNITATII. Relatia de Legatura e implementata de relatia:

Ascendenta = (Uc ,Ua) Uc are ca ascendent pe Ua

unde Uc reprezinta instanta curenta a UNITATII si Uc reprezinta instanta ascendenta a UNITATII.

§ Legatura 1 - 1

• Mandatata la Optionala – Infinita

• Optionala la Mandatata - Infinita

• Mandatata la Mandatata – Infinita

• Optionala la Optionala

Structura descrie perechi de instante de ANGAJATI ce apartin relatiei:

Înlocuire = (Ac , Ai) Ac e înlocuit de AI

unde Ac reprezinta instanta curenta a ANGAJATULUI si Ai reprezinta instanta ANGAJATULUI înlocuitor. Datorita implementarii Angajatului Înlocuit si a celui Înlocuitor prin aceeasi Clasa de Entitatii (ANGAJAT), implementarea legaturii recursive 1 – 1 trebuie sa implice existenta unei Chei

Ascendenta

UNITATE

134 Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati

Candidate pe atributul Înlocuitor din ANGAJAT, care sa asigure unicitatea Înlocuitorului pe multimea Înlocuitilor. Deci declararea acestui tip de legatura va determina generarea automata a Cheii Candidate Înlocuitor.

Fig. 3.4.5.1.14 Înlocuire

§ Legatura m - n

• Mandatata la Optionala – Infinita

• Optionala la Mandatata – Infinita

• Mandatata la Mandatata - Infinita

• Optionala la Optionala

Fig. 3.4.5.1.15 Componenta

Pentru acest tip de relatie s-a ales ca exemplu structura de date utilizata în Prelucrarea Nomenclatoarelor (vezi sectiunea 2.4). Aceasta structura implementeaza relatia fundamentala de tip Retea (vezi sectiunea 3.4.3.) Legatura e descrisa de relatia:

Componenta = (Pc , Pm) Pc are ca si component pe Pm

unde Pc reprezinta instanta de PRODUS Compus si Pm reprezinta instanta de PRODUS Component.

ANGAJAT

Inlocuire

PRODUS

Componenta

Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati 135

3.4.5.2 Viziunea în Produsul ERWIN

Produsul ERWIN [ERWM01] promoveaza o Metoda proprie pentru Modelarea Datelor descrisa în urmatoarele documente:

o IDEFX1 (Information Definition – Definirea Informatiilor) [IDEF1X] – o metoda dezvoltata de Fortele Aeriene ale Statelor Unite. Ea e în prezent folosita pentru:

§ Agentii guvernamentale

§ Industria aerospatiala

§ Piata bancara

§ Corporatii majore

o IE (Information Engineering – Ingineria Informatiilor) – o metoda dezvoltata de James Martin & Clive Finkelstein.

Ambele metode sunt cuprinse în produsul ERWIN. Aceste metode sunt orientate catre descrierea Modelelor de Date complexe, caracterizate prin:

• Volume mari de date

• Conceptie riguroasa de structurare

• Spatii de Informatii ale Intreprinderilor mari

Modelele de Date create cu ajutorul acestor tehnici formeaza nucleul procesului de generare a Structurii Logice (Nivelul Conceptual) al Bazelor de Date, prin procesul de Inginerie a Datelor specific produselor de Ingineria Programarii Asistate de Calculator (Computer-Aided Software Engineering – CASE). Criteriile de Clasificare a Structurilor de Date în produsul ERWIN sunt prezentate mai jos. Pot fi urmarite cu usurinta asemanarile cu metoda ORACLE, precum si particularitatile produsului ERWIN.

o Gradul si Cardinalitatea Legaturii

§ Gradul Legaturii - (1 sau n) înseamna ca 0, 1 sau mai multe (n) Instante ale unei Entitati refera o Instanta a altei Entitati

§ Cardinalitatea Legaturii – proprietate de legatura care indica precis numarul Instantelor Copil legate de o Instanta Parinte (0, 1, n)

o Independenta Entitatilor

§ Entitate Independenta - Entitatea care nu depinde în procesul de identificare de alta Entitate (nu are Constituenti de Identificator care migreaza din exterior, adica sunt Chei Straine)

Exemplu: TIPUL-UNITATII sau TIPUL-STRUCTURII-UNITATII (Fig. 3.4.3.4.3 )

§ Entitate Dependenta - o Entitate Copil a carei identificare (unicitate) depinde de o Cheie Straina

136 Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati

• Dependenta ca Existenta – Entitatea nu poate exista daca nu exista Entitatea Parinte

Exemplu: Rândurile unei Comenzi (Document) nu pot exista fara Antetul Comenzii (Documentului)

• Dependenta ca Identificare – Entitatea nu poate fi completa fara prezenta Identificatorului Parintelui

Exemplu: Entitatea UNITATE daca identificarea ei se face cu Codul-Unitatii + Codul-Tipului-de-Unitate (Atribut preluat din Entitatea Parinte TIP-UNITATE)

o Optionalitatea Legaturii

§ Legatura Optionala - Entitatea Copil nu e Dependenta ca Existenta, nici Dependenta ca Identificare de Entitatea Parinte

Exemplu: Entitatea UNITATE daca identificarea ei se face numai cu Codul-Unitatii, Codul-Tipului-de-Unitate fiind doar un atribut descriptor, preluat din Entitatea Parinte TIP-UNITATE, care ramâne evident Cheie Straina

§ Legatura Mandatata - Entitatea Copil e Dependenta ca Existenta de Entitatea Parinte

Exemplu: vezi exemplul de mai sus, referitor la Dependenta ca Existenta

o Repetitivitatea Legaturii

§ Nerecursiva – Legatura porneste si ajunge în Entitati diferite

§ Recursiva – Legatura porneste si ajunge în aceeasi Entitate

o Tipuri Suplimentare de Legaturi

§ Legaturi m-n (Many to Many) - vezi exemplele de la ORACLE (Legatura poate fi definita doar în Spatiul de Informatii (si nu în cel al Datelor Relationale); Modelerul de Date ERWIN permite descrierea unor asemenea legaturi si generarea automata a Entitatii de Legatura si a Legaturilor Relationale care o implementeaza în Spatiul Datelor (în Baza de Date)

§ N-aritatea Legaturii – precizarea numarului maxim admis de Instante ale Entitatii Copil ( > 2 )

§ Legaturi de Clasificare (Subtipuri si Supertipuri) – Legarea unei Entitati Comune, cu Atribute Generale (Supertip) de mai multe Entitati Specifice, cu Atribute Particulare (Subtip)

Exemplu: Clasificarea Rolurilor unei Entitati Persoana

• PERSOANA - Entitate Generica (Gen Proxim)

o PROFESOR – Entitate Specifica

o STUDENT – Entitate Specifica (Diferenta Specifica)

o CANDIDAT – Entitate Specifica

Concepte de Baza / Diversificarea Tipurilor de Legaturi între Entitati 137

Se prezinta în continuare conventiile grafice utilizate pentru reprezentarea Structurilor de Informatii si Date descrise mai sus.

Simboluri de Legaturi

IDEF1X IE

Descrierea

Cardinalitatii Identificatoare Neidentificatoare Identificatoare Neidentificatoare

1 – 0,1,n

1 – 1,n

1 – 0,n

0,1 – 0,1,n neidentifi-

catoare

0,1 – 0,1 neidentifi-

catoare

Fig 3.4.5.2.1. Conventiile de reprezentare grafica IE si IDEF1X

In Fig. 3.4.5.2.1 sunt continute doua variante de Conventii Grafice (IDEF1X si IE) pentru reprezentarea Structurii de Date în Modelele construite cu ajutorul produsului de modelare ERWIN. Ambele conventii fac parte din Standardul American [IDEF-0], utilizat în construirea Modelelor de Date.

Caracteristica aparte în aceasta conventie de reprezentare o constituie Legaturile Identificatoare, respectiv Neidentificatoare, determinate de Migrarea Cheii Primare în Identificatorul, respectiv într-un Descriptor al Relatiei Dependente.

138 Concepte de Baza / Structuri de Proceduri

3.5 Structuri de Proceduri

Ideile si Conceptele care vor fi prezentate succint în aceasta sectiune par sa depaseasca cadrul unei dezbateri a problematicii Bazelor de Date. Ele apartin altor domenii de interes, cum ar fi Programarea Clasica sau Programarea Structurata. Argumentul principal care a determinat cuprinderea lor în aceasta lucrare sunt urmatoarele:

o Bazele de Date nu au pregetat sa asimileze orice descoperire aparuta în alte domenii de cercetare

o Orice preluare a fost însotita de introducerea ei în contextul propriu de preocupari, subordonata scopului principal urmarit: Integritate prin Independenta

o Însusirea unor idei si concepte a fost întotdeauna marcata de transpunere lor în practica, de valorificarea potentialului lor teoretic în confruntare directa cu solutionarea unor probleme de interes cotidian, dar nu dintre cele mai simple, datorita complexitatii conferite de situatiile reale ce asteptau rezolvare

Noutatea pe care o aduce discutia despre Structura Procedurilor este legata de paralela facuta cu Structura Datelor, al carei beneficiu consta în promovarea Simplificarii Procedurilor si a cresterii simultane a Gradului de Control al acestora. Aceste idei vin sa defineasca în plus ceea ce am desemnat adesea pe parcursul acestei lucrari prin sintagma: Viziune Structuralista. 3.5.1 Operatie si Procedura Definitii:

Operatie – o interventie asupra unui ansamblu de date, în scopul transformarii sau evaluarii lui, dupa cum urmeaza:

o Transformare pentru obtinerea de noi date:

§ Ca Forma – conversie

§ Ca Pozitie – reamplasare

§ Ca Ordine – reordonare

§ Ca si Continut – calcul aritmetic sau logic

o Evaluare prin marcarea ca Adevarat sau Fals a rezultatului unei comparatii Ca urmare Operatiile pot fi:

§ De Atribuire – Fortare de Egalitate – Actiune

§ De Evaluare – Testare de Egalitate – Conditie Procedura – o Succesiune de Operatii având drept scop trecerea unui ansamblu de date dintr-o Stare Initiala într-una Finala. Instructiune – forma de comunicare a unei Operatii.

Concepte de Baza / Structuri de Proceduri 139

Elementele cu care vor opera Procedurile apartin la doua categorii distincte:

o Date

§ Principale – reprezentate de Atribute din Baza de Date

§ Auxiliare – reprezentate de Variabilele de Program

o Operatii

§ Specifice – descriu Actiuni si Evaluari proprii Mediilor de Programare (în speta Bazelor de Date)

§ De Control – descriu Logica Procedurii (relatiile de Echivalenta si de Incluziune între Operatii, alaturi de Repetitivitatea lor)

3.5.2 Operatii de control

In cele ce urmeaza se face o trecere în revista, într-o reprezentare grafica, a Operatiilor de Control utilizate în limbajele procedurale. In reprezentarile grafice care urmeaza s-au folosit urmatoarele simboluri:

- Cercul – Grup de Operatii

- Punctul – Operatie Elementara sau Grup Elementar de Operatii

- n - Numarul de aparitii (Instante) ale unui Grup de Operatii

- oi – Operatie Elementara sau Grup Elementar de Operatii

- c – Operatie de tip Conditie

- B – Bloc Nerepetitiv

- R – Bloc Repetitiv 3.5.2.1 Compozitia

Compozitia, denumita si Bloc sau Secventa este reprezentata de un Grup de Operatii (Elementare sau Grupuri de Operatii Elementare, marcat printr-un Început si un Sfârsit (Fig. 3.5.2.1.1). Numarul de Aparitii (Instante) ale Blocului este 1.

Fig 3.5.2.1.1 Structura de Control de tip Compozitie 3.5.2.2 Selectia

Selectia, denumita si Structura Alternativa, are doua forme de realizare: Selectia Simpla si Multipla.

BEGIN ..

Operatiei ..

END • on •

o2

• o1

B

1

140 Concepte de Baza / Structuri de Proceduri

Selectia Simpla este reprezentata de un Bloc care are în componenta o Conditie alaturi de alte doua Blocuri subordonate primului. Cele doua Blocuri subordonate vor fi executate în functie de rezultatul conditiei (cel din stânga pentru conditia Adevarata, cel din dreapta pentru conditia Falsa (Fig. 3.5.2.2.1). Si Selectia are o singura Instanta.

Fig 3.5.2.2.1 Structura de Control de tip Selectie Simpla

Selectia Multipla este reprezentata de un Bloc care are în componenta o multime de Blocuri Conditionale care au fiecare în alcatuire o Conditie alaturi de un singur Bloc. Blocul se va executa pentru Conditia Adevarata. Un Bloc special si optional (OTHER - ALTE) încheie structura. El se va executa în cazul în care nici-o alta Conditie nu a fost îndeplinita. Blocurile Conditionale sunt disjunctive, în sensul ca unul singur va fi executat în ordinea de prioritate data de pozitia lor în structura (vezi Fig. 3.5.2.2.2).

Fig 3.5.2.2.2 Structura de Control de tip Selectie Multipla

IF Conditie THEN .. Operatiei .. ELSE .. Operatiej .. END

* c

C

• on

• o2

• o1

B1

• on

• o2

• o1

B2

1

1 1

• o2

• o2

• o2

1

1 1

* co

DO CASE CASE Conditie1

.. Operatiei

.. CASE Conditie2

.. Operatiej

.. CASE ..

.. OTHER .. Operatiek .. END

• on

• o1

B2

• on

• o1

B0

* c1

C1

* c2

C2

1

1

1

B

• on

• o1

B1

C0

1..

Concepte de Baza / Structuri de Proceduri 141

3.5.2.3 Repetitia

Repetitia, denumita si Bucla, are în alcatuire un Bloc Principal caruia îi este atasata o Conditie care determina Numarul de Repetari (de Instante) ale Blocului Repetitiv. In functie de locul de amplasare a Conditiei, Repetitia are doua variante de realizare:

o Repetitia Posibil Nula (Fig. 3.5.2.3.1) – Conditia e amplasata la Intrarea în Bucla (în stânga în reprezentarea grafica), putându-sa parasi Bucla daca la prima intrare Conditia de Iesire e satisfacuta

Fig 3.5.2.3.1 Structura de Control de tip Repetitie (Repetitie Posibil Nula)

o Repetitia Nenula (Fig. 3.5.2.3.2) – Conditia e amplasata la Iesirea din Bucla (în dreapta în reprezentarea grafica), Bucla executându-se cel putin o data

Fig 3.5.2.3.2 Structura de Control de tip Repetitie (Repetitie Nenula)

Repetitia apeleaza la Operatia de Fortare a Iesirii din Bucla (EXIT) care poate fi folosita si în afara Conditiei de Repetare a Structurii. Desigur ca orice regrupare a conditiilor de parasire a structurii aduce un plus de control în comportarea în functiune a secventei de Operatii.

BEGIN .. Actiunej .. IF Conditie THEN EXIT END REDO END

r > 0

* c

R

• on •

o2

• o1

B1 1

r ≥ 0 BEGIN IF Conditie THEN EXIT END .. Operatiei .. REDO END

* c

R

• on

• o2

• o1

B1

1

142 Concepte de Baza / Structuri de Proceduri

3.5.2.4 Substitutia

Substitutia, este reprezentata de o Operatie de Apel, care determina executia tuturor Operatiilor continute în Procedura invocata, cu revenirea la Operatia de dupa Apel (Fig. 3.5.2.4.1.

Fig 3.5.2.4.1 Structura de Control de tip Substitutie 3.5.3 Elementele Structurilor de Proceduri

Elementele cu care se vor construi Structurile Procedurilor sunt grupate în Tab. 3.5.3.1. Din clasificarea prezentata rezulta si modul recursiv de construire a Procedurilor. Grupurile Compuse se formeaza din Grupuri Elementare în care pe pozitia Operatiilor apar Grupuri Elementare. Acest proces se poate repeta indefinit, conducând la Proceduri Complexe. Respectând o structura bine definita procesul de construire, dar mai ales de depanare a functionarii ei, pot fi tinute sub control. Câteva remarci legate de Tipurile de Structuri definite sunt utile.

- Selectia Multipla include Selectia Simpla oferind totodata posibilitatea transformarii ei în selectie multipla

- Selectia Simpla ofera posibilitatea, exploatata de unele Medii de Programare, de a fi transformata în Functie, putând fi utilizata ca Data. O asemenea implementare este oferita de structura Selectie Imediata ( IMMEDIATE IF):

IIF (Conditie, Atribuire1, Atribuire2)

- Repetitia în cele doua variante, diferentiate prin amplasarea conditiei în structura se refera la numarul de inspectii efectuate:

§ Varianta Posibil Nula (Cât Timp) – considera pornirea de la o Conditie îndeplinita si se opreste la prima neîndeplinire

§ Varianta Nenula (Pentru) – inspecteaza toata multimea de elemente selectându-le pe cele care verifica Conditia

- Substitutia reprezinta „Cuiul lui Pepelea” pentru Programare – Cu sau fara instructiunea GO TO? Am denumit cele doua variante de încorporare într-un punct a unei alte secvente de proceduri în mod sugestiv:

.. DO Nume-Procedura .. PROCEDURE Nume-Procedura BEGIN .. Operatiei .. END

* a

P

• on

• o2

• o1

B

1

1

Concepte de Baza / Structuri de Proceduri 143

Atribuire ACTIUNE Operatie Evaluare CONDITIE

Neconditional COMPOZITIA Simpla

Nerepetitiv

BLOC

Conditional

SELECTIA

Multipla

Posibil Nula

REPETITIA

Nenula

Fixa (CALL)

Grup Elementar (Grup de Operati)

Repetitiv

BUCLA

SUBSTITUTIA

Variabila (GO TO)

Element

Grup

Grup Compus (Grup de Grupuri)

Tab. 3.5.3.1 Elementele Structurilor de Procedurii

Concepte de Baza / Structuri de Proceduri 144

§ Repetitie Fixa – cu referire la faptul ca înlocuirea prin invocare (CALL) conduce la definirea precisa a structurii ce urmeaza a fi încorporata, prin necesitatea revenirii în punctul de plecare dupa încheierea executiei

§ Repetitie Variabila – care reprezinta tot o forma de „Substitutie”, structura ce urmeaza a fi încorporata este necunoscuta depinzând de Conditiile întâlnite pe parcurs; de asemenea revenirea în punctul de pornire nu e impusa

Este evident ca sistemele complexe, cum sunt Sistemele cu Baze de Date, prefera prima varianta, cea care ofera maxim control în proiectare si depanare, ramânând astfel fidele concluziilor Programarii Structurate.

3.5.4 Descrierea Formala a Procedurilor

In Fig. 3.5.4.1 este definita formal Procedura cu ajutorul expresiilor de rescriere în format BNF (Backus Normal Form). Se regasesc constructiile prezentate anterior în clasificarea din Fig. 3.5.3.1. Traducerea atasata face ca sintaxa descrisa sa poata fi usor folosita pentru definirea unui Pseudo-Cod de descriere generala a Procedurilor.

- procedura → [PROCEDURE nume-procedura (parametri)]

corp-procedura [END]

- parametri → nume-data [parametri]

actiune [END]

- corp-procedura → [corp-procedura]

structura-elementara

- structura-elementara → compozitie

→ selectie

→ repetitie

→ substitutie

- compozitie → BEGIN corp-procedura END

- selectie → IF conditie THEN corp-procedura1 ELSE corp-procedura2 END

WHILE

- repetitie → DO conditie [END] corp-procedura END

FOR

- substitutie → DO nume-procedura END

- operatie → operatie-specifica

→ operatie –de-control

- operatie-specifica → actiune

→ conditie

Concepte de Baza / Structuri de Proceduri 145

- operatie –de-control → structura-elementara

Traducerea Mnemonicelor

PROCEDURE - PROCEDURA IF - DACA BEGIN - INCEPUT THEN - ATUNCI END - SFARSIT ELSE - ALTFEL DO - EXECUTA WHILE - CAT TIMP

FOR - PENTRU

Fig. 3.5.4.1 Definirea în Sintaxa BNF a Procedurii 3.5.5 Descrierea în Pseudo - Cod

Un Pseudo – Cod este denumit un limbaj conventional, foarte apropriat de Limbajul Natural, folosit pentru descrierea precisa, rapida si foarte comoda a Procedurilor de catre orice Utilizator.

Aceste cerinte pot fi traduse în practica prin:

- Precizie – adoptarea unor Reguli de Descriere (a unei Sintaxe de Limbaj)

- Rapiditate – evitarea regulilor amanuntite, impuse de limbajele compilabile

- Comoditate – exprimarea elementelor de baza cu usurinta în limbajul natural:

§ Actiunea – se exprima printr-un Enunt Imperativ ce trebuie executat

§ Conditia – se exprima printr-un Enunt Afirmativ ce trebuie verificat

Acest instrument este utilizat pentru transpunerea în Proceduri de Prelucrare a Specificatiilor de Descriere a Proceselor identificate în cadrul unui Sistem. Reprezinta un pas intermediar între faza de Specificare si cea de Programare prin aceea ca permite:

- Descrierea facila a Procedurilor

- Transpunerea directa a descrierii în Programe

Specificul Limbajelor Formale de Descriere a Procedurilor este strâns legat de specificul Structurilor de Date ce urmeaza a fi prelucrate. Pentru acest motiv Sistemele cu Baze de Date se preteaza pentru asemenea descrieri, întrucât nivelul de descriere Logica a Datelor ofera Entitati, Atribute si Relatii extrase direct din Spatiul de Informatii, deci foarte familiare utilizatorului si totodata unice pe parcursul evolutiei sistemelor de aplicatii, prin prezenta Modelului de Date. Pentru a construi un asemenea instrument de lucru trebuiesc respectate urmatoarele conditii:

o Preluarea Structurilor de Control din Limbajele Procedurale (vezi Fig. 3.5.3.1)

o Definirea unui Limbaj Formal general (vezi Fig. 3.5.4.1)

o Exprimarea Operatiilor Specifice din sistemele ce urmeaza a fi descrise (în speta SBD) în Limbaj Natural

Concepte de Baza / Structuri de Proceduri 146

3.5.6 Arborele de Programare

Arborele de Programare reprezinta un formalism grafic utilizat în Programarea Structurata. El se construieste prin stabilirea relatiilor de Echivalenta sau de Incluziune între Elementele de Structura precizate cu ajutorul Regulilor Formale ce descriu Procedura (vezi Fig. 3.5.4.1). Prezentarea Arborelui de Programare se va face pe baza unor exemple.

Exemplul 1

Sa consideram ca, din motive de performanta dorim sa sortam nu prin Indexare, ci în memorie, dupa Nume, lexicografic, descrescator, structura de date descrisa mai jos, care prezinta forma unei structuri statice de tip Matrice:

BENEFICIAR B Cod c Nume n

Arborele de Programare va arata ca în Fig. 3.5.6.1.

Exemplul 2

Fie Structura de Date simbolica a unui Model de Date de tip Retea, descrisa în Fig. 3.5.6.2. Se recunosc urmatoarele caracteristici:

- A – Entitate

- B, C, D, E – Subentitati

- a, b, c, c, d, e – Descriptori

- ri – Referinta la Lista de Membri (Lista de Articole din Entitatea de tip E)

- r – Referinta la Posesor (Entitate de tip D) Sa mai consideram urmatoarele Specificatii de Definitie a unei Proceduri de interogare a Structurii de Date prezentate:

- Obtinerea Rezultatelor trebuie confirmata de Utilizator la începutul procedurii

- Rezultatele constau din:

• Numararea Instantelor (Realizarilor) Entitatii A care verifica o Conditie data (a > v)

• Numararea tuturor Instantelor (Realizarilor) Subentitatii E din prima instanta a Entitatii A

• Afisarea Rezultatelor

In Fig. 3.5.6.3 este redata o descriere în Pseudo – Cod a Procedurii descrisa anterior, iar în Fig. 3.5.6.4 este redata aceeasi Procedura cu ajutorul Arborelui de Programare.

In urma analizei exemplelor prezentate se cuvin câteva concluzii:

o Ultimul exemplu prezentat lasa sa se observe faptul ca Arbore de Programare nu reprezinta un instrument practic de lucru pentru descrierea Procedurilor. Utilitatea

Concepte de Baza / Structuri de Proceduri 147

lui consta însa în educarea modului de a ”gândi” procedura. In cest scop se fac urmatoarele remarci:

§ Procedura e privita ca o Constructie din Module precis definite separate în cele doua categorii:

• Operatii de Control

• Operatii Specifice Mediului de Programare (vezi Operatia o10 din Fig. 3.5.6.1 si Fig. 3.5.6.2, care evita o structura de control de tip Repetitie)

Legenda

M – Sortare Matrice T – Transpunere Elemente e - Element I – Initializare Index E – Extragere Element i, j – Indecsi A – Actualizare Index D – Deplasare Elemente n - Nume S – Scanare Matrice R – Reamplasare Element m – Variabila Interna C – Test Conditie

Fig. 3.5.6.1 Arborele de Programare pentru procedura de Sortare prin Transpunere

≥ 0

≥ 0

1

1

1 1

1

1

1

M

S

A C

T

I

D E R

•

*

• • • • •

•

*

*

i=1

i<n

i=i+1n

j=i+1 m=n(j)

n(i) ≥ n(i+1)

j >1 si n(j-1)>m

n(j) =m n(j)=n(j-1) j=j-1

Concepte de Baza / Structuri de Proceduri 148

§ Operatia de Substitutie, care nu poate fi în viziunea structurala decât Fixa, invita la Modularizarea Procedurii, cu rezultate directe atât în faza de constructie cât si în cea de depanare

§ Viziunea Structuralista consta în construirea ansamblului din Structuri Elementare si prin aceasta se apropie de procedeele de construire a Structurilor de Date

o Se remarca asemanarea Arborelui de Programare cu Arborele de Structura a Datelor:

§ Ambele au o Organizare Structurala Ierarhica pe Nivele

§ Nivelele de Procedura pe care apar Repetitii trebuie sa corespunda unor Nivele de Structura a Datelor care descriu date de tip Multime (Clase de Entitati, Ansambluri de Entitati etc.)

§ Nu întâmplator s-a ales în Exemplul 2 un Model de Date de tip Retea în care sa fie mai vizibile Nivelele de Subordonare Ierarhica. In Modelele Relationale cel mai adesea Procedurile de Prelucrare opereaza pe Cursori, care sunt Vederi rezultate din operatii de Cuplare de Relatii si care vor contine în reprezentare Secvential Ierarhizata diferite Nivele de Ierarhizare în functie de Vederea Partiala utilizata (vezi sectiunea 3.4.4), dar aceasta transformare de structura ar fi complicat prezentarea

Fig. 3.5.6.2 Structura Simbolica de tip Retea (Arbore de Structura)

o Utilizarea Procedurilor Structurate este foarte adecvata Sistemelor cu Baze de Date. Când se opereaza cu Baze de Date, se manifesta anumite particularitati:

§ In descrierea Structurilor de Control de tip Repetitie vor apare Operatii Specifice orientate pe Inspectia si Filtrarea Multimilor de Instante ale Colectiilor de Date

•a

A

E

D C

B

• d

• c2

• c1

• e

* r

* ri

•b

Concepte de Baza / Structuri de Proceduri 149

PROCEDURA Interogare Cerere-Raspuns (r) …………………………….. operatia o1

DACA R=nedefinit ………………………. conditia c1 ATUNCI IESIRE …………………………….. operatia o2

SFARSIT Initializare Contor …………………………….. operatia o3 TEST CAZ

CAZ R=’A’ EXECUTA Scanare1 …………………………….. operatia o4

CAZ R=’E’ EXECUTA Scanare2 …………………………….. operatia o5

ALTFEL EXECUTA Eroare (1) …………………………….. operatia o6

SFARSIT EXECUTA Listare(R, Contor) …………………….. operatia o7

SFARSIT PROCEDURA Scanare1

Cerere-Raspuns (v) …………………………….. operatia o8 PENTRU TOATE Instantele A având a > v ……... conditia c2

Incrementare Contor …………………………….. operatia o9 SFARSIT

SFARSIT PROCEDURA Scanare2

Contor = Cardinal Multime de Instante E ………………….….. operatia o10 SFARSIT PROCEDURA Listare PARAMETRII Nume-Entitate, Contor

Listare Nume-Entitate, Contor …………………………….. operatia o11 SFARSIT PROCEDURA Eroare PARAMETRII Numar-Eroare

TEST CAZ CAZ Numar-Eroare =1 ………………………. conditia c3

Listare ‘Valoare Raspuns Eronata’ ………………….. operatia o12 CAZ ..

.. ALTFEL

.. SFARSIT

SFARSIT

Fig. 3.5.6.3 Procedura de Interogare (Descriere în Pseudo – Cod)

Concepte de Baza / Structuri de Proceduri 150

Legenda I – Interogare L – Listare S1 – Scanare 1 E – Eroare S2 – Scanare 2 T – Test Raspuns S – Scanare Multime de Instante E Tc – Test Caz Te – Test eroare

Fig. 3.5.6.4 Procedura de Interogare (Arborele de Programare)

§ In Conditii este recomandat sa apara doar Atribute din Structura de Date si nu Variabile de Memorie, care denota o descriere insuficienta a Structurii de Date (în exemplul prezentat în conditii nu apar decât Variabile specifice unei Proceduri de Interogare si anume: Raspunsuri de Continuare sau Constante de Filtrare)

1

•o3

1

1

c2

1 1

Tc

C2 C1 A

•

*

o4

..

1 L

•

o11

1 E

•

1

c3

1 1 1

Te

E2 E1 A

•

*

o12

..

S2

•

o10

1

≥ 0

S1

•

•

*c2 o9

o8

o5

1 1

1

o2

1 I

*

o1

c1

T

•

C1 C2

•

o6

* * *

* o7

S

Concepte de Baza / Structuri de Proceduri 151

PPAARRTTEEAA aa 44--aa

MMOODDEELLEE ddee IINNFFOORRMMAATT IIII ssii DDAATTEE

Sectiunile reunite în aceasta parte formeaza Centrul de Greutate al lucrarii, prin volumul de informatii pus la dispozitie si de asemenea prin viziunea pe care o consolideaza, referitoare la Sistemele cu Baze de Date. Conceptele de Baza prezentate anterior sunt aici pe îndelete folosite pentru a construi în doua planuri distincte: Spatiul Informatiilor – Viziunea Utilizatorului Spatiul Datelor – Viziunea Sistemului de Calcul structurile care formeaza fundamentul unei Surse de Date Bine Definite. Sectiunile alaturate, deosebit de numeroase, poate prea numeroase din intentia de a mentine cursivitatea în înlantuirea Structurilor & Restrictiilor & Operatiilor, ca elemente inseparabile în cadrul Modelelor de Date, sunt grupate în doua parti: 4.1 – Modele de Informatii – creeaza baza Abordarii

Semantice a Modelelor de Structuri si deschide calea Proiectarii Asistate de Calculator a SBD. Punctul central îl formeaza Modelul Obiectelor Abstracte, ale carui concepte, bazate pe Procesele de Abstractizare, vor fi urmarite, în formele de transpunere si implementare în Spatiul Sistemului de Calcul, de-a-lungul întregii lucrari. Se pun astfel bazele unei Proiectari de Nivel Înalt, care începe din Spatiul Utilizatorului si continua cu Instrumente de definire conceptuala a Modelelor de Date.

1.4 – Modele de Date – se alege Modelul Strict de Date,

cu întreaga sa Arhitectura , ca forma cea mai fidela de transpunere a conceptelor Modelelor de Informatii în Spatiul Sistemelor de Calcul. Prezentarea comparativa a Tipurilor de Modele de Date (Ierarhic, Retea, Relational) satisface cerintele de cronologie ale unei Monografii de Concepte. Accentul prezentarii va cadea asupra Modelului Relational (Structuri, Limbaje, Particularitati, Exemple).

152 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare

4 Modele de Informatii si Date 4.1 Modele de Informatii

Modele de Informatii sunt dezvoltate în Spatiul de Informatii care descrie Problema Utilizatorului, fiind ca atare încarcate cu maximum de semantica, ce urmeaza a fi transpusa în Modelul de Date, care ia în discutie si instrumentele ce vor fi folosite în prelucrare.

4.1.1 Modelul Entitate – Caracteristica – Valoare (Modelul ECV)

Modelul ECV introduce elementele fundamentale de descriere a Structurilor de Informatii (vezi si Modelul lui Langefors, aparut ulterior si referit în sectiunea 4.2.1). 4.1.1.1 Descrierea Spatiului de Informatii

Cu ajutorul Informatiilor, care poarta semnificatia (Sensul) cunostintelor noastre asupra unui domeniu de interes al realitatii, descriem elementele si legaturile între ele ce permit construirea acelor structuri a caror evolutie în timp dorim sa o urmarim. Aceste structuri descriptive le vom denumi, în termenii sistemelor cu Baze de Date, Spatiul de Informatii. Ele vor reprezenta întotdeauna legatura directa cu Utilizatorul în vederea supravegherii domeniului lui de interes. Fie urmatoarele informatii care descriu un asemenea Spatiu de Informatii, reprezentând – Studentii unui An de Studiu reuniti în Grupe de Activitate (Fig. 4.1.1.1.1). Informatiile cuprinse în domeniul specificat mai sus, au putut fi structurate prin grupare în Multimi de Informatii:

- Entitati Obiect • Student 1 • Student 2 • .. • Student i

- Clasa de Entitati Obiect

STUDENTI ≡ [Student 1, Student 2, .., Student i

Prin abstractizare se poate obtine o noua Multime foarte importanta în descrierea informatiilor si anume:

- Entitatea Notiune • STUDENT

care descrie pe oricare din Studenti dar pe nici unul anume. Structurarea poate continua si în interiorul Categoriilor definite pâna acum,

obtinându-se noi Multimi de Informatii: - Caracteristici descriptive pentru entitatea STUDENT

• Marca • Nume • Prenume • Vârsta • Sex

Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 153

• Sectie • Responsabilitate • Membru-în-Grupa

- Valori ale Caracteristicii Marca • 101 • 102 • 103 • etc.

- Valori ale Caracteristicii Nume • Ionescu • Varga • Pop • etc.

- Valori ale Caracteristicii Prenume • Andrei • Stefan • Maria • etc.

- Valori ale Caracteristicii Vârsta • 22 • 21 • etc.

- Valori ale Caracteristicii Sex • Barbatesc • Femeiesc

- Valori ale Caracteristicii Specialitate • Informatica • Electronica • etc.

- Valori ale Caracteristicii Responsabil-de-Grupa • Da • Nu

- Valori ale Caracteristicii Membru-în-Grupa cu Responsabil-de-Grupa = Studentul-2

• Sstudentul-1, Studentul-2, etc. • etc.

- Valori ale Caracteristicii Membru-în-Grupa • Studentul-1, Studentul-2, etc. • Studentul-3, Studentul-4, etc. • etc.

- Valori de Caracteristica (în general) • 101 • Ionescu • Stefan • Barbatesc • Informatica • Studentul-1, Studentul-2, etc. • etc.

154 Modele de Informatii si Date

Fig. 4.1.1.1.1. Descrierea Clasei de Entitati STUDENTI

un Student are Marca este 101 un Student are Nume este Ionescu un Student are Prenume este Andrei un Student are Varsta este 22 un Student are Sex este Barbatesc un Student este Informatician un Student nu este Responsabil-de-Grupa un Student are un Responsabil-de-Grupa este Student-2

Student-1

Student-2

Student-3

Studenti

un Student are Marca este 102 un Student are Nume este Varga un Student are Prenume este Stefan un Student are Varsta este 22 un Student are Sex este Barbatesc un Student este Informatician un Student este Responsabil-de-Grupa un Student are un Responsabil-de-Grupa este Student-2 un Student are Marca este 103 un Student are Nume este Pop un Student are Prenume este Maria un Student are Varsta este 21 un Student are Sex este Femeiesc un Student este Electronist un Student nu este Responsabil-de-Grupa un Student are un Responsabil-de-Grupa este Student-4

Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 155

4.1.1.2 Descrierea Spatiului de Date

In vederea transformarii Informatiilor în Obiectul prelucrarii lor cu ajutorul unor instrumente consacrate (automate sau manuale), vom utiliza Datele în calitate de Semne Purtatoare ale Semnificatiei Informatiilor. Vom putea reface constructiile de structuri descifrate în Spatiul Informatiilor utilizând conventii simplificatoare, care sa usureze culegerea, memorarea, prelucrarea, transmiterea si extragerea Datelor purtatoare de Informatii. Noile structuri vor descrie Spatiul Datelor, ce va fi personalizat conform cerintelor impuse de instrumentele de prelucrare utilizate. Se prezinta în continuare într-un pseudo-limbaj formalizat trei Modele de reprezentare în trei Spatii de Date distincte ale aceluiasi Spatiu de Informatii descris mai sus.

ENTITY STUDENT-RESPONSABIL (10)

BEGIN Marca numeric 3

Nume character 25 Prenume character 25 Varsta numeric 2 Sex value-set (M, F) Sectie value-set (I, E, M)

ENTITY GRUPA (1) BEGIN ENTITY STUDENT -MEMBRU (15) BEGIN

Marca numeric 3 Nume character 25 Prenume character 25 Varsta numeric 2 Sex value-set (M, F)

END END

END

Fig.4.1.1.2.1 Spatiul de Date cu model Ierarhic

ENTITY STUDENT (150) BEGIN

Marca numeric 3 Nume character 25 Prenume character 25 Varsta numeric 2 Sex value-set (M , F) Sectie value-set (I , E , M) Responsabil logical Grupa entity-set STUDENTI

END

Fig. 4.1.1.2.2 Spatiul de Date cu model Retea

156 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare

ENTITY STUDENT (150) BEGIN

Marca numeric 3 Nume character 25 Prenume character 25 Varsta numeric 2 Sex value-set (M , F) Grupa numeric 3

END

ENTITY GRUPA (10) BEGIN

Cod numeric 3 Responsabil numeric 3 Sectie value-set (I , E , M)

END Fig. 4.1.1.2.3 Spatiul de Date cu model Relational

Din analiza descrierilor celor doua Spatii de Descriere se desprind urmatoarele observatii:

- Continutul Spatiului de Informatii trebuie sa fie:

§ cuprinzator - pentru satisfacerea cerintelor de complexitate

§ clar - în fata unor categorii diverse de utilizatori

§ concis - pregatit pentru transpunere formalizata

- Continutul Spatiului de Date trebuie sa fie:

§ fidel - sensurilor multiple din domeniul de interes al utilizatorilor

§ adecvat - la instrumentele de prelucrare

§ extensibil - în fata modificarilor sau adaugarilor de noi informatii

- Ideile de organizare, sistematizare si clasificare a unor volume mari de cunostinte trebuie sa apara înca în descrierea Spatiului de Informatii si aceasta e posibil prin utilizarea unor Modele de Date performante pentru culegerea cerintelor de informare ale utilizatorilor

- Unui Spatiu de Informatii unic îi pot corespunde mai multe Spatii de Date. Alegerea celui mai adecvat este o conditie pentru valorificarea unui volum bine cules de informatii si depinde de instrumentele de prelucrare aflate la dispozitie

- Semnificatiile din Spatiul de Informatii pot fi în mod diferit transpuse în diferite Spatii de Date, cu posibile nuantari în gradul de fidelitate

Exemplu:

Informatia: “un STUDENT este Responsabil-de-Grupa” poate fi transpusa în descrierea LOGICA prin urmatoarele elemente:

o Implicit (printr-o Entitate) în modelul Ierarhic

§ Se prevad în Structura de Date doua Entitati STUDENT cu roluri diferite (Responsabil si Membru al Grupei)

Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 157

§ Se economiseste astfel o Caracteristica de descriere (Responsabil) în cadrul Entitatilor

§ Se iroseste o dubla descriere prin Caracteristici a Entitatii STUDENT în cele doua roluri

§ Informatia e pastrata în Modelul Ierarhic si în cazul particular al neactualizarii Subentitatii Student-Membru prin existenta Entitatii Student-Responsabil

o Explicit (prin Caracteristica Responsabil din Entitatea STUDENT) în Modelele Retea si Relational

§ Informatia ar putea fi reprezentata si în absenta Caracteristicii Responsabil, prin simpla prezenta a unei multimi nevide de Membri ai Grupei

§ In cazul particular al neactualizarii Caracteristicii de tip Multime (Grupa), informatia e pierduta daca ar lipsi Caracteristica Explicita (Responsabil)

Observatiile facute nu au avut drept scop sa orienteze cititorul catre o solutie în cazul discutat, ci sa evidentieze multitudinea de probleme pe care le ridica construirea structurilor în spatiul Entitate-Caracteristica-Valoare. In acest punct merita relevat faptul ca singura fidelitate fata de Cerintele Utilizatorului nu sunt suficiente, daca nu se adauga unui proces competent si rabdator de surprindere a aspectelor mai profunde legate de construirea Structurilor de Informatii si Date, a caror calitate îsi va pune amprenta pe întregul proiect. Aceasta preocupare va oferi Sistemelor cu Baze de Date capacitatea de a raspunde nu numai Cerintelor Curente ale Utilizatorului, ci si celor pe care el nu le prevede înca. Acest lucru ne-a determinat sa vorbim despre culegerea de Cunostinte asupra informatiilor ce urmeaza a fi descrise si nu o simpla fotografiere a unui volum momentan vehiculat de informatii, care cel mai adesea descrie în primul rând Obisnuinte si nu Realitati. Fara a insista asupra ideii se accentueaza faptul ca orice Sistem Informatic implica si Resursele Umane care trebuiesc aduse la un grad de Cultura Informatica în consonanta cu stadiul Tehnologiei Avansate de prelucrare a Informatiilor si a Datelor.

Prezentarea facuta are drept tinta construirea unui formalism de reprezentare a Structurilor de Informatii si Date prin reducerea legaturilor interne la conceptele introduse în sectiunea 3. 4.1.1.3 Entitate – Caracteristica – Valoare

In aceasta sectiune se pun bazele definirii formalismului general amintit. Îl numim general întrucât îl dorim desprins de Modelul de Date ales pentru construirea Spatiului de Date (Ierarhic, Retea, Relational, Obiectual etc.). Promisiunea de realizare a acestui deziderat consta în faptul ca, pentru construirea lui, se va apela la concepte mai abstracte, din domeniul matematic ce defineste notiunile de Multimi si Relatii, cu tot arsenalul aferent reamintit în sectiunile consacrate acestui subiect. Modelul Relational de descriere a datelor, care va fi utilizat cu predilectie pe tot parcursul lucrarii, va gasi bineînteles o buna fundamentare, fiind cel mai apropiat de implementarea directa a acestui formalism.

Pentru început se cere o Definire de Termeni. Toate definitiile enuntate pot fi regasite ca exemplificare în studiul de caz prezentat la începutul sectiunii. Continutul lor se va regasi totodata în Modelul Formal descris în Tab. 4.1.1.4.1 si în Fig. 4.1.1.4.2.1.

158 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare

4.1.1.3.1 Entitate

Definitia 1 (Generala)

Entitate – o Unitate Identificabila într-un univers de obiecte, concrete sau abstracte.

Definitia 2 (Particularizata pentru Spatiul Informatiilor)

Entitate – orice Existenta, Concreta sau Abstracta, caracterizata printr-un anumit numar de informatii, care o individualizeaza .

Multimea de informatii care descriu Entitatea poarta denumirea de Însusiri sau Caracteristici. Ca urmare Entitatea se defineste deja ca o Multime de Însusiri si totodata ca o Multime de Elemente ce pot fi descrise cu ajutorul acestor Însusiri.

Entitatea poate fi privita în doua moduri, unul Abstract (General) si unul Concret (Particular):

o Entitate Notiune – un Element Abstract reprezentativ pentru elementele multimii (oricare din multime, dar nici unul anume). Ea va contine descrierea generala prin Nume de Caracteristici (Însusiri) a fiecarui element din multime. Exemplu:

STUDENT

Entitatea Notiune descrie Tipul de Entitate spre a o deosebi de altele (Entitatea STUDENT de Entitatea GRUPA).

In expresie analitica Entitatea Notiune se descrie ca o Multime Ordonata de Caracteristici:

Ei ≡ ( c i1 , c i2 , .. , c in )

Multimea Ordonata care descrie Entitatea Notiune mai poarta numele si de Tupla Logica.

o Entitate Obiect – un Element Concret din multimea de elemente (Realizare sau Instanta de Entitate Notiune). Particularizarea va fi facuta prin acordarea de Valori particulare fiecarei Caracteristici (Însusiri) generale. Exemplu:

Studentul 1

sau

Studentul cu Nume ‘Ionescu’ si Prenume ‘Andrei’

In expresie analitica Entitatea Obiect se descrie ca o Multime Ordonata de Valori de Caracteristici:

E ir ≡ ( v 1, v 2, .., vr .. , ve )

Multimea Ordonata care descrie Entitatea Obiect mai poarta numele si de Tupla Fizica.

Multimea tuturor Entitatilor Obiect formeaza extensiunea Clasei de Entitati omonime:

Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 159

E i‘ ⊆ C1 x C2 x .. x Cr .. x Ce

E i‘ = ( v 1, v 2, .., vr .. , v e ) | v r ∈ Cr pt. ∀r ∈ 1,2, .. ,e

Asemenea demersului legat de Mutimi, o problema esentiala care se ridica legat de Entitati este cea de definire a posibilitatilor de Identificare. Identificarea Entitatii poate fi facuta în mai multe moduri:

- Prin Caracteristici – declararea Valorilor de Caracteristici (Însusiri) atasate Entitatii, care permit selectare unei Submultimi de Entitati din întreaga Multime existenta de Entitati:

§ Identificare Discriminanta – când multimea selectata contine un singur element; Exemplu:

Studentul cu Marca ‘101’

§ Identificare Nediscriminanta - când multimea selectata poate contine mai multe elemente; Exemplu:

Studentul cu Vârsta ‘22’

- Prin Nume – Numele este o caracteristica aparte de identificare, ce are în componenta doua elemente:

§ Însusirea Comuna tuturor Entitatilor Obiect (Numele Entitatii Notiune). Exemplu:

Studentul

§ Însusirea Specifica unei Entitatii Obiect. Exemplu:

1

Identificarea prin Nume este întotdeauna Discriminanta.

In Modelul ECV Entitatea Notiune apare în sectiunea de Descriere a Informatiilor, urmând sa stea la baza crearii Dictionarului Datelor. In acest sens ea va apare în Modelul Formal descris în termenii de Multimi si Relatii ca element în Multimea Entitatilor E, care descrie semantica Spatiului de Informatii (Fig. 4.1.1.4.1.3):

E = e 1 , e 2 , .. , e n

si se va regasi apoi în Descrierea unei Bazei de Date (BDL - Baza de Date Logica):

BDL = E 1 , E 2 , .. , E mb

4.1.1.3.2 Clasa de Entitati

Fiind declarata Clasa aceasta structura trebuie sa fie definita ca o Multime de Multimi. Clasa de Entitati asigura aceasta conditie întrucât vom regasi în continutul ei:

o O Multime Ordonata (Multimea de Caracteristici)

o O Multime de Multimi Ordonate (Multimea de Entitati Obiect)

160 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare

Definitie:

Clasa de Entitati – o Multime de Entitati Obiect, de acelasi fel, având aceleasi Caracteristici de descriere, dintre care una definitorie pentru întreaga Clasa. Caracteristica Definitorie da Numele Clasei, care se transfera apoi si asupra Entitatilor Obiect din Clasa .

Orice Clasa de Entitati este definita prin Entitatile asociate:

§ O Entitate Notiune – contine descrierea Clasei si reprezinta Intensiunea ei. Constituie partea constanta în timp de definire a Clasei. Exemplu:

Entitatea Notiune STUDENT descrisa de Caracteristicile:

- Marca - Sex - Nume - Sectie - Prenume - Responsabil

- Vârsta - Grupa

§ O Multime de Entitati Obiect – reprezinta Extensiunea Clasei. Constituie partea variabila în timp pentru definirea Clasei prin Valori (Instante). Exemplu:

Multimea de Entitati Obiect STUDENTI:

Student 1, Student 2, ..

Pentru a deosebi Entitatea Notiune de Clasa de Entitati Obiect este binevenita utilizarea pentru denumirea lor a formelor de singular (pentru prima) si de plural (pentru a doua). Exemplu:

Entitatea Notiune STUDENT

Entitatea Obiect Student 1

Clasa de Entitati Obiect STUDENTI

Proprietatile Clasei de Entitati:

§ Entitatile din Clasa au o Caracteristica Definitorie comuna

§ Caracteristica Definitorie da Numele Clasei

§ Entitatile din Clasa au aceleasi Însusiri care caracterizeaza toate Entitatile Obiect din Clasa, individualizându-le prin Instantiere

§ Entitatile din Clasa se supun acelorasi Relatii cu alte Clase de Entitati

Continutul notiunii de Clasa de Entitati este dat de descrierea formala de mai jos: CE i ≡ (E i , E i

‘) Ei ≡ ( c i1 , c i2 , .. c ij , .. , c in )

E i are c ij E i

‘≡ E i1, E i2, .., E ir .. , E im E ir

≡ ( v 1, v 2, .., vr .. , ve )

E ir este E i

Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 161

Se regasesc elementele definitiei anterioare:

Clasa de Entitati este alcatuita din:

o O Entitate Notiune (E i ) – definirea în intensiune printr-o Lista de Caracteristici (Tupla de Nume)

o O Multime de Entitati Obiect (E i‘ ) - definirea în extensiune printr-o

Multime de Tuple de Valori

Din aceasta definire decurge si continutul semantic atasat legaturilor intrinseci ale acestui concept:

o E i are c ij - O Entitate Notiune are Caracteristica c j ca si componenta de descriere

o E ir este E i - O Entitate Notiune generalizeaza o Entitate Obiect si reciproc, o Entitate Obiect specifica o Entitate Notiune

Este anticipata prezenta planurilor de Agregare si Generalizare ca operatii abstracte de generare de Obiecte (vezi Modelul Obiectelor Abstracte în sectiunea 4.1.2).

4.1.1.3.3 Metaclasa de Entitati

O situatie particulara apare atunci când Elementele Multimii de Entitati Obiecte sunt Entitati Notiuni . Sa analizam Multimea de Entitati Notiune E (vezi si Fig. 4.1.1.4.2.1. Si în acest caz putem sa recunoastem o Clasa de Entitati asa cum am definit-o anterior, prin simpla echivalare de termeni ce descriu continutul acestei noi Clase. Putem regasi cu usurinta acesti termeni de definitie în:

o O Entitate Notiune – ce defineste în intensiune Multimea de Elemente printr-o singura Caracteristica si anume Numele Comun atasat Clasei (cel de Entitate Notiune pentru toate elementele Clasei)

E ≡ (Nume)

o O Multime de Entitati Obiect - ce defineste în extensiune Multimea prin enumerarea Entitatilor Notiune, care formeaza Instantele Clasei, definite doar prin Nume:

E ‘≡ E 1, E 2, .. , E i, .. , E n

unde:

e i reprezinta un Nume de Entitate Notiune

Întrucât aceasta noua Clasa de Entitati Obiect joaca rolul unei Clase Generice pentru toate Entitatile definite în Structura de Informatii, ea mai este definita si Metaclasa. Am considerat însa mai utila asimilarea acestui nou termen cu Clasa de Entitati, având în vedere ca definirea prezentata pentru Metaclasa ca o Clasa de Entitati este lipsita de echivoc si conduce la o unificare de termeni care va simplifica în continuare tratarea Metaclasei.

Procesul de unificare de termeni prin asimilare va fi reîntâlnit si în continuare când vor fi analizate notiunile de Caracteristica si Valoare.

162 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare

4.1.1.3.4 Caracteristica

Definitia 1:

Caracteristica – orice Însusire a unei Entitati. Caracteristica mai poarta si numele de Atribut.

Definitia 2:

Caracteristica – o Clasa de Entitati care nu mai admite descrierea cu alte însusiri (Caracteristici) si ale carei Entitati Obiect sunt reprezentate de Elemente Nedecompozabile (Valori de Însusiri).

Ca urmare aceasta Clasa de Entitati elementara va fi definita prin:

§ Numele Caracteristicii reprezentând intensiunea ei data de sensul acordat Caracteristicii. Exemple:

Vârsta

Sex

§ O Multime de Entitati Obiect reprezentate de Valorile pe care le poate lua însusirea descris a. Exemple:

19, 20, .., 35

Masculin, Feminin

Orice Caracteristica este la rândul ei o Clasa de Entitati subordonata altei Clase de Entitati, pe lânga care joaca rolul de descriptor. Descriind o Clasa de Entitati cu ajutorul unor Caracteristici se realizeaza o asociere între Clase de Entitati: Clasei de Entitati descrise i se asociaza Clasele de Entitati descriptoare (Caracteristicile). In general o Clasa de Entitati poate fi descrisa prin asociere cu orice alta Clasa de Entitati (Elementara ca si Caracteristica sau Neelementara ca si Entitatea). Orice Relatie de Asociere genereaza doua Informatii:

- Informatia de Asociere Directa: STUDENTUL are GRUPA

- Informatia de Asociere Inversa : GRUPA are STUDENTI

Definirea completa a Caracteristicii rezulta numai prin luarea în considerare a afirmatiei prin care o Caracteristica este o Clasa de Entitati si anume una Elementara , prin aceea ca e descrisa numai de Valori si nu de alte Caracteristici. Ca urmare continutul oricarei Caracteristici este definit de:

o O Entitate Notiune – definirea în intensiune printr-un Nume de Caracteristica (Însusire sau Proprietate)

o O multime de Entitati Obiect - definirea în extensiune printr-o Multime de Valori (Valorile Proprii Caracteristicii)

C j = P 2 R ; R = cj x V (proiectie de rang 2 a lui R)

Se poate si în acest caz evidentia acelasi continutul semantic atasat legaturilor intrinseci ale conceptului de Caracteristica:

Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 163

o C j are v jk - O Caracteristica are Valoarea vjk ca si componenta de descriere

o v jk este C j - O Caracteristica generalizeaza o Multime de Valori privite ca Entitati Obiect (Intensitati ale Caracteristicii) si reciproc, o Valoare specifica în planul instantelor o Caracteristica privita ca Entitate Notiune

4.1.1.3.5 Valoare

Necesitatea utilizarii Planului Valorilor în descrierea Structurilor de Informatii rezulta din urmatoarele constatari legate de aportul Valorii în tripletul Entitate - Caracteristica - Valoare:

o Caracteristica este definita ca o Clasa de Entitati Elementara, având ca Elemente Valorile

o Valorile sunt Entitati Nedecompozabile

o Proprietatile Caracteristicii sunt Valorile

o Rolul Valorii este de a descrie o Intensitate de Însusire (Însusire)

o Entitatea este descris a Intensional de Caracteristici si Extensional de Valori de Caracteristici

Rezulta urmatoarele definitii:

Definitia 1:

Valoare – Intensitatea unei Însusiri (Caracteristici).

Definitia 2:

Valoare – Entitatile Obiect ale unei Clase de Entitati Caracteristica.

Informatiile definite prin propozitii (cuplu Subiect – Însusire) având termenul Însusire o Valoare sunt Informatii Elementare (Nedecompozabile). De aici rezulta ca Valorile trebuie sa fie Elemente Autoidentificabile.

Daca luam în considerare legatura indirecta care se stabileste între multimile de Entitati, Caracteristici si Valori, se pot defini urmatoarele Ansambluri de Valori:

Fig. 4.1.1.3.5.1 Valori Izonime •

•C2

Cj

C1 V1 •

V2

Vj

E1

164 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare

o Valori Izonime - reprezentând Valorile pe care le iau Caracteristicile ce descriu o Entitate Obiect (vezi exemplul simbolic din Fig. 4.1.1.3.5.1)

In Modelul Relational Valorile Izonime descriu Tabelele de Baza.

Fig. 4.1.1.3.5.2 Valori Izotipe

o Valori Izotipe - reprezentând Valorile pe care le ia o Caracteristica în toate Entitatile Obiect din Colectia de Date (vezi exemplul simbolic din Fig. 4.1.1.3.5.2)

In Modelul Relational Valorile Izotipe descriu Indecsii asociatii Tabelelor de Baza.

Valorile sunt descrise printr-o serie de proprietati:

§ Tipul Datei

§ Limitele de Valori admise

§ Conditii de Validare (Constrângerile) impuse

In expresie analitica (Fig. 4.1.1.4.1.2) Multimea Valorilor V cuprinde toate valorile care pot fi întâlnite în Colectiile de Date:

V = v 1 , v 2 , .. , v p Multimea de Valori pe care le poate lua o Caracteristica data formeaza Domeniul de

Valori al acelei Caracteristici definit analitic:

C j = P 2 R ; R = cj x V (proiectie de rang 2 a lui R)

Definirea Domeniului Valorilor este de o importanta deosebita în proiectarea Structurilor de Informatii datorita urmatoarelor motive:

o Permite stabilirea legaturilor initiale care exista între Informatiile multiple care populeaza un Spatiu de Informatii

o Prin adaugarea de noi cunostinte se ajunge la stabilirea unor Clase de Echivalenta pe baza Criteriului de asemanare, nu numai Formala, ci si Informala

o Derivarea ulterioara a Atributelor ce descriu Clasele de Entitati va putea fi consolidata prin utilizarea unor Surse Comune care sa asigure Mostenirea de Proprietati

o Legaturile bazate pe Referinta Asociativa vor gasi terenul gata pregatit

C1

C1

C1

V1 •

V2 •

Vi •

E1

En

E2

Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 165

4.1.1.3.6 Relatii de Asociere

Relatiile de Asociere sunt Relatii între Clase de Entitati. Cele mai frecvente Relatii de Asociere sunt Relatii Binare de forma:

A ⊆ E i‘ x E j

‘

unde:

A – este Relatia de Asociere

E i‘ - Extensiunea Clasei de Entitati E i

E j‘ – Extensiunea Clasei de Entitati E j

In cazul Structurilor de Informatii Clasele de Entitati pe care se defineste Relatia de Asociere poarta semnificatii specializate si anume:

E i – se denumeste Clasa de Entitati Posesori (P)

E j – se denumeste Clasa de Entitati Membri (M)

Tabelul 4.1.1.3.6.1, prin exemplificarile de Relatii de Asociere ofera o paralela între descrierile Formale si Informale, Generale si Particulare, ca si cea între Legaturile Are si Este, care sunt transpuse prin inversare doar în cazul anumitor semantici continute în Relatia de Asociere. Se poate urmari cum Cuplul (e i, e j), încarcat cu o Semantica Generica, se instantiaza apoi în diferite Intensiuni Concrete atasate Relatiei de Asociere.

Descrierea Asocierilor Informala

Generala Particulara Formala

Directa Inversa

Directa Inversa

e i are Component pe e j e j este Compus pentru e i

e j este Categorie pentru e i e i are ca Specie pe e j

e i Poseda pe e j e j e Posedat de e i

e i are Descendent pe e j e j are Ascendent pe e i

e i ∈ P e j ∈ M

(e i , e j) ∈ A

e i are Membru pe e j e j are Posesor pe e i

e i are Copil pe e j e j are Parinte pe e i

Tab. 4.1.1.3.6.1. Legatura Relatii de Asociere – Tipuri de Structura

Fiind data o Clasa de Entitati (Membri) careia i se ataseaza o Însusire de Asociere cu o alta Clasa de Entitati (Posesori), Relatia de Asociere defineste, în general, pe Multimea Membrilor o Acoperire si doar cu o Restrictie suplimentara (unicitatea Posesorului) o Partitie.

166 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare

Se remarca descrierea oricarei Asocieri prin doua Relatii:

- Relatia Directa – care descrie legatura Posesor - Membri

- Relatia Inversa – care descrie legatura Membru - Posesor

Raportul Relatiilor de Asociere cu Relatiile Fundamentale este redata în tabelul 4.1.1.3.6.2.

Relatie de Asociere

Directa Inversa Semantica Tip Structura Semantica Tip Structura

Posesor - Membri 1 - n Membru-Posesor 1 - 1 Posesori - Membri m - n Membru-Posesori 1 - m

Tab. 4.1.1.3.6.2. Legatura Relatii de Asociere – Tipuri de Structura

In cazul Relatiilor de Asociere care descriu Relatii Fundamentale de tip m – n, Relatia Inversa defineste si ea pe Multimea Posesorilor o Acoperire.

Relatia de Asociere poate fi privita ca orice Relatie în dublul ei continut:

o Intensional – descris a de Proprietatea de Asociere (RA), care extrage Relatia de Asociere (A i) din Produsul Cartezian

A i ⊆ E i‘ x E j

‘ ⇔ RA

unde RA are semnificatia:

e i are Membru pe e j si e j are Posesor pe e i

cu

e i ∈ P si e j ∈ M

o Extensional – descris a de Multimea de Cupluri de Asociere care descriu fizic Relatia de Asociere

A e ≡ (e i , e j ) | e i RA e j

4.1.1.3.7 Ansamblu de Entitati

Ansamblul de Entitati are la baza conceptul de Relatie între Clasele de Entitati. Aceasta Relatie ia forma Asocierii între Entitatile Obiect continute în Clasele de Entitati, Posesori si Membri.

Ansamblul de Entitati urmareste sa prezinte din alt unghi de vedere Relatia de Asociere si anume ca o Multime de Cupluri:

A e ≡ (p i , m pj) | p i RA m pj pentru ∀ i si j

Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 167

Exemplu: Studentii Grupelor≡ (Grupa 1 , Student 1, Student 3, ..),

(Grupa 2 , Student 2, Student 5, ..), ..

Definitie

Ansamblul de Entitati – o Submultime de Entitati Obiect ale unei Clase de Entitati (Membri), care au o însusire comuna, ce poate fi exprimata ca o Relatie de Asociere între o Entitate Obiect Posesor (al Ansamblului), extras dintr-o Clasa de Entitati Posesori si mai multe Entitati Obiect Membri (ai Ansamblului), extrase din Clasa de Entitati Membri. Posesorul Ansamblului nu face parte din Ansamblu.

Exemplu: Student 1, Student 3, ..

Ansamblul de Entitati, la fel ca Entitatea poate fi si el privit în cele doua moduri, unul Abstract (General) si unul Concret (Particular):

o Ansamblul de Entitati Notiune – un Element Abstract reprezentativ pentru elementele multimii (oricare din multime, dar nici unul anume). Ea va contine descrierea generala a Relatia de Asociere prin:

§ Numele Clasei de Entitati Membri (E i)

§ Numele Clasei de Entitati Posesori (E j)

§ Relatia de Asociere (RA)

Exemplu:

Studentii unei Grupe

Ansamblul de Entitati Notiune descrie Tipul de Ansamblu de Entitati spre a le deosebi de altele (Studentii unei Grupe de Grupa unui Responsabil etc.). Se observa ca Ansamblul de Entitati Notiune încorporeaza, în Numele atasat, semantica acordata acestui element de structura. Ea e data de Intensiunea Relatiei de Asociere RA.

Formal Ansamblul de Entitati Notiune AE n va putea fi definit prin Intensiunea Relatiei de Asociere A i, care implica si desemnarea Claselor de Entitati Posesori E i si Membri E j pe care ea e definita:

AE n ≡ A i

o Ansamblul de Entitati Obiect – un Element Concret din multimea de elemente (Realizare sau Instanta de Ansamblu de Entitati Notiune). Particularizarea va fi facuta prin acordarea de Valori concrete fiecarui Ansamblu de Entitati.

Exemplu:

Pentru Grupa 1 - Studentul 1, Studentul 3 ..

Ansamblul de Entitati Obiect se descrie prin proiectia de rang 2 a extensiuni Relatiei de Asociere (Ae) pentru un element Posesor (t). Sau în expresie analitica:

168 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare

§ Relatia de Asociere (A i) pentru un element Posesor (t) se defineste ca o Proiectie Conditionata a Relatiei de Asociere (vezi sectiunea 3.1.2.5):

A t ≡ (e i , e j ) | i = t si e t ∈ E i‘ si e j ∈ E j

‘ si (e i , e j ) ∈ Ae

§ Ansamblul de Entitati Obiect va putea fi definit formal prin Proiectia de rang 2 a lui A t:

AE o t ≡ P 2 A t

E evident extensiunea acestei multimi este o Restrictie a Multimii Entitatilor Obiect din Clasa de Entitati Membri E i

‘:

AE o t ⊆ E i

‘

Ansamblul de Entitati va putea lua forme diferite de utilizare în Modele de Date diferite:

o Caracteristica – în cazul în care el apare ca descriptor al altei Clase de Entitati

§ Caracteristica ce descrie Posesorul – Data de implementare poate fi elementara (pentru legaturi 1 – n), sau trebuie sa fie de Tip Multime (pentru legaturi m – n)

§ Caracteristica ce descrie Membrii – Data de implementare trebuie sa fie întotdeauna de Tip Multime

o Clasa de Entitati – în cazul în care este definit independent

§ Clasa de Entitati va descrie integral Relatia de Asociere (A) în forma:

A e ≡ (p i , m j ) | p i RA m j

unde:

p i ∈ P – Multimea Posesorilor m j ∈ M – Multimea Membrilor

4.1.1.3.8 Clasa de Ansambluri de Entitati

Întocmai ca si în cazul Clasei de Entitati si acum termenul de Clasa este justificat de continutul acestei noi notiuni. Ea urmareste sa regrupeze notiunile definite în legatura cu Ansamblul de Entitati.

Definitie

Clasa de Ansambluri de Entitati – multimea Ansamblurilor de Entitati Obiect considerate ca Membri, asociate tuturor Entitatilor Obiect din Clasa de Entitati Obiect, considerate ca Posesori. Caracteristica definitorie (Relatia Posesor – Membri) da Numele Clasei, care se transfera apoi si asupra Entitatilor Obiect din Clasa.

Orice Clasa de Ansambluri de Entitati este definita prin Entitatile asociate:

Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 169

§ Un Ansamblu de Entitati Notiune – ce contine descrierea Clasei si reprezinta Intensiunea ei . Constituie partea constanta în timp de definire a Clasei.

AE n ≡ A i

Exemplu:

Studentii unei Grupe

§ O Multime de Ansambluri de Entitati Obiect – care reprezinta extensiunea Clasei. Constituie partea variabila în timp de definire a Clasei.

Exemplu:

Multimea de Ansambluri de Entitati Obiect Studentii Grupelor:

Student 1, Student 3, .. , Student 3, Student 5, .. , ..

Formal Multimea de Ansambluri de Entitati Obiect va fi definita prin toate Multimile de Membri E o t

asociate tuturor Posesorilor P:

AE o ≡ E o t pentru ∀ t ∈ P

unde:

P – Multimea Posesorilor

Ca urmare Clasa de Ansambluri de Entitati se construieste cu ajutorul urmatoarelor concepte:

o Ansamblul de Entitati Notiune - Studentii unei Grupe

o Ansamblul de Entitati Obiect - Studentii Grupei 1

o Multimea de Ansambluri de Entitati Obiect - Studentii Grupelor

Continutul notiunii de Clasa de Ansambluri de Entitati este redat de descrierea formala completa de mai jos:

CAE ≡ (AE n, AE o) AE n ≡ A i

A i ⊆ E i‘ x E j

‘ ⇔ RA e i are Membru pe e j si e j are Posesor pe e i

e i ∈ P si e j ∈ M AE o ≡ E o t

pentru ∀ t ∈ P A t ≡ (e i , e j ) | i = t si e t ∈ E i

‘ si e j ∈ E j‘ si (e i , e j ) ∈ Ae

AE o t ≡ P 2 A t

Desi definitia formala a Clasei de Ansambluri de Entitati apare mai complicata, ea se reduce în final la continutul cunoscut al notiunii de Clasa de Entitati (vezi sectiunea 4.1.1.3.2). Este suficienta simpla echivalare de termeni prin corespondentele:

Entitatea Notiune (E i) ≡ Ansamblul de Entitati Notiune (AE n)

Multimea de Entitati Obiect (E i‘) ≡ Multimea de Ansambluri de Entitati Obiect (AE o)

170 Modele de Informatii / Modelul Entitate – Caracteristica - Valoare

Element de Structura Definitie

Nume Nivel Nume Nivel

Exemple

Notiune O existenta descrisa printr-un Nume General

+ O Multime Ordonata de Caracteristici

STUDENT GRUPA

Obiect O existenta descrisa printr-un Nume Particular

+ O Multime Ordonata de Valori

Student 1 Grupa 1

Entitate

Clasa

O Existenta Identificabila descrisa informational

O Entitate Notiune +

O Multime de Entitati Obiect

STUDENTI =Student 1, Student 2,..

Notiune Proprietate descrisa prin Nume Obiect O Instanta (Valoare) de Caracteristica

Caracteristica

Clasa

Însusire a unei Entitati

Proprietate descrisa printr-un Nume

+ O Multime de Valori Compatibile

Marca Nume Prenume

Valoare - Intensitate a unei Însusiri O Entitate Autoidentificabila 101 Ionescu Andrei

Notiune O Relatia de Asociere descrisa printr-un Nume General de Clasa de Entitati Posesori

+ Nume General de Clasa de Entitati Membri

STUDENTII unei GRUPE

Obiect O Relatia de Asociere descrisa printr-un Nume Particular de Clasa de Entitati Posesori

+ Nume Particular de Clasa de Entitati Membri

Studentii Grupei 1= Student 1, Student 3,..

Ansamblu de Entitati

Clasa

O Relatie de Asociere între

O Clasa de Entitati Posesori

si

O Clasa de Entitati Membri

Un Ansamblu de Entitati Notiune +

O Multime de Ansambluri de Entitati Obiect

Studentii Grupelor=Studentii Grupei 1, Studentii Grupei 2, ..

Tab. 4.1.1.4.1 Notiunile definite în Modelul ECV - Recapitulare

Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 171

Proprietatile Clasei de Ansambluri de Entitati:

§ Ansamblurile de Entitati din Clasa au o Caracteristica Definitorie comuna data de semantica Relatiei de Asociere (Posesor – Membri)

§ Caracteristica Definitorie da Numele Clasei de Ansambluri

§ Ansamblurile de Entitati din Clasa au aceleasi Însusiri care le caracterizeaza, individualizându-le prin instantiere

§ Ansamblurile de Entitati din Clasa se supun acelorasi Relatii cu alte Clase de Entitati

Înainte de a trece la construirea Formalismului de descriere a Modelului Entitate - Caracteristica - Valoare facem o recapitulare a notiunilor definite în sectiunile anterioare, sinteza cuprinsa în Tabelul 4.1.1.4.1. Recapitularea facuta are drept scop extragerea, din multimea de detalii folosite în definirea notiunilor, a esentelor care se vor regasi mai departe fixate prin expresiile matematice si simbolurile grafice utilizate in sectiunile urmatoare.

4.1.1.4 Modelul formal ECV în termeni de Multimi si Relatii 4.1.1.4.1 Definire matematica

Elementele Structurilor de Informatii definite în contextul Modelului Entitate - Caracteristica – Valoare, elemente care vor fi regasite într-o forma sau alta în toate modelele prezentate în lucrare sunt descrise prin corespondenta cu expresiile matematice introduse în sectiunea Multimi si Relatii (Fig. 4.1.1.4.1.2). Punerea în corespondenta a acestor expresii cu continutul notiunilor definite si comentate pe larg a fost facuta deja în sectiunile anterioare. 4.1.1.4.2 Descriere grafica

Fig. 4.1.1.4.1.3 reda, cu ajutorul simbolurilor grafice, elementele de baza ale Modelului Entitate - Caracteristica –Valoare. Asa dupa cum s-a mai mentionat simbolurile descrise în termenii acelorasi raporturi stabilite în sectiunea referitoare la Multimi si Relatii pot fi considerate de referinta pentru fixarea notiunilor si a conversiei sau asimilarii de termeni în alte Modele de Informatii si de Date. Ca urmare, desi structurile reprezentate sunt orientate spre arhitectura Sistemelor cu Baze de Date, ele pot fi utilizate cu succes pentru întelegerea terminologiei specifice domeniului mai general al Modelelor de Date cu a caror manevrare cititorul se va simti poate mai familiar.

In legatura cu aportul acestei noi forme de reprezentare facem urmatoarele sublinieri:

o Marcarea diferentei între Multimile Neordonate si Ordonate ( )

o Ilustrarea formelor de Generare a Multimilor, prin Regrupare si prin Combinare

o Conturarea prin suprafete texturate a continutului Claselor de Entitati, în diferitele lor contexte de aparitie, Entitate, Caracteristica, Ansamblu de Entitati

o Punctarea formei particulare de aparitiei a Relatiilor de Asociere ca legatura Posesor - Membri

Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 172

Notiune Nume Simbol Expresie Observatii

Multimea Valorilor V V = v 1 , v 2 , .. , v p Multimea Caracteristicilor C C = c 1 , c 2 , .. , c n

Multimea Entitatilor Notiune E E = e 1 , e 2 , .. , e n Caracteristica C j C j = P 2 R proiectie de rang 2 a lui R

R = cj x V Entitate Notiune E i E i = (c 1 , c 2 , .. , c m ) ∈ C x C x .. x C Entitate Obiect E ir

E ir ≡ (v 1, v 2, .., vr .. , v e)

Multimea Entitatilor Obiect E i‘ E i

‘ ⊆ C1 x C2 x .. x Cr .. x Ce E i

‘ E i‘ = ( v 1, v 2, .., vr .. , v e ) | v r ∈ Cr pt. ∀r ∈ 1,2,..,e

Clasa de Entitati CE i CE i ≡ (E i , E i‘) E i are c j

E ir este E i

Ansamblu de Entitati Notiune A A ⊆ E i‘ x E j

‘ Ansamblu de Entitati Obiect E i s t

E i s t ⊆ A restrictie a lui A

E i s t E i s t

= P 1 A proiectie de rang 1 a lui A Clasa de Ansambluri de Entitati

Obiect E i s

E i s ⊆ E i s 1 , E i s 2 , .. , E i s q ⊆ P ( E i

‘ )

Baza de Date Logica BDL BDL = E 1 , E 2 , .. , E mb Baza de Date Fizica BDF BDF = E 1

’ , E 2’ , .. , E mb

’

Fig. 4.1.1.4.1.2. Modelul ECV în expresii de Multimi si Relatii - Definire matematica

Modele de Informatii / Modelul Entitate – Caracteristica - Valoare 173

Fig. 4.1.1.4.2.1 Modelul ECV reprezentat prin Multimi si Relatii

ENTITATI Notiuni

E

C 1

(c 1 , c 2 , …. , c i s , … , c m)

C 2

ENTITATE Obiect

E i r

VALORI V

CARACTERISTICI C

ENTITATE Notiune

E i BAZA de DATE

LOGICA BDL

ANSAMBLU de ENTITATI Obiecte

E i s t

CLASA de ANSAMBLURI de

ENTITATI C i s ≡ E i s

BAZA de DATE FIZICA

BDF

CARACTERISTICAC j

Multimi de ENTITATI OBIECT

E i‘

C j

v k , j

v k

( v 1 , v 2 , …. , v e )

C m

E i

C 1

CLASA de ENTITATI E i

174 Modele de Informatii / Modelul Obiectelor Abstracte

4.1.2 Modelul Obiectelor Abstracte (OA)

Modelul Obiectelor Abstracte descris în referinta bibliografica [SMIT82], a fost dezvoltat de autorii J.M. Smith si D.C.P. Smith, în jurul anilor ‘80, ca un instrument promitator de proiectare a structurilor în Spatiul Informatiilor, deci înainte de a fi precizat un Model de Date care sa implementeze, pe un sistem automat de calcul, structurile proiectate. Ca urmare metodele propuse vor fi întâlnite în domeniul Proiectarii Conceptuale a Structurilor de Informatii. 4.1.2.1 Procesul de Abstractizare

Conceptele de Abstractizare fundamentate prin aceste cercetari vor sta la baza Proiectarii Obiectuale dezvoltate în deceniul care a urmat. Cu toate acestea consideram ca Modelul de Structura de Informatii prezentat ca rezultat al acestor cercetari este mult mai general, putându-si gasi aplicatii mai largi decât Programarea Orientata pe Obiecte (OOP – Object Oriented Programming). In domeniul Structurilor de Informatii se gaseste o asemenea aplicare, care fara sa apeleze la Viziunea Obiectuala din Programarea Clasica, utilizeaza conceptele initiale pentru activitati foarte fertile, cum ar fi implementarea Generalizarii pentru operatiile de Clasificare, a Agregarii pentru Relatiile de Asociere, descrierea Tipurilor de Relatii, operatii care pot transforma în proceduri automate activitatea de transpunere a proceselor de Agregare si Generalizare în Structuri de Date si de Proceduri, în cadrul Sistemelor cu Baze de Date (vezi sectiunile 4.2.4.7.2 si 4.2.4.7.3).

In deslusirea si definirea Entitatilor Notiune dintr-un Spatiu de Informatii se apeleaza în permanenta la un proces fundamental de Abstractizare, întelegând prin operatia de abstractizare initiata într-un sistem:

“ o culegere de detalii ce pot fi denumite într-un mod convenabil ca un întreg “ .

Aceasta operatie care utilizeaza una din caracteristicile de baza ale notiunii de Multime si anume cea a unitatii elementelor, conferita de proprietatea comuna si care permite ca Multimea sa fie privita si tratata ca un nou Element (o noua Entitate).

Abstractizarea poate fi operata în doua planuri :

o cel al Starilor unui Sistem si atunci conduce la definirea Obiectelor Abstracte

o cel al Transformarilor unui Sistem si atunci conduce la definirea Operatiilor Abstracte

Obiectele si operatiile definite prin acest proces primar de generalizare poarta numele de Obiecte Primitive sau Operatii Primitive. Primordiala în conceperea structurilor este definirea Obiectelor Abstracte, deoarece o definire corecta a acestora usureaza simtitor etapa de definire a Operatiilor Abstracte.

Se pot retine urmatoarele echivalente de termeni:

Obiect Abstract ≡ Concept ≡ Entitate Notiune

Cu aceste notiuni precizate, se poate afirma ca obiectivul Proiectarii Conceptuale a Structurilor este reprezentat de definirea Structurii Relative a Obiectelor Abstracte.

Modele de Informatii / Modelul Obiectelor Abstracte 175

4.1.2.2 Obiecte Abstracte

Generarea unor Obiecte Abstracte (OA) din alte obiecte abstracte (Primitive sau Neprimitive ) se face în doua moduri (vezi Generarea de Multimi din sectiunea 3.1.2):

o Prin Generalizare - generarea unui Obiect Generic dintr-o Multime de Obiecte Categorie, corespunde operatiei de formare de multimi prin Regrupare de Multimi Parti

o Prin Agregare - generarea unui Obiect Agregat dintr-o Relatie existenta între Multimi de Obiecte, corespunde operatiei de formare de multimi prin Combinare de Multimi

4.1.2.2.1 Obiecte Generice

Procesul de Generalizare permite realizarea operatiei de Clasificare a Entitatilor prin observarea caracteristicilor Comune si a celor Specifice dupa modelul prezentat în Fig. 4.1.2.2.1.1.

Fig. 4.1.2.2.1.1 Exemplificarea procesului de Abstractizare prin Generalizare

Operatia de Clasificare include doua operatii inverse:

o Generalizarea – pornind de la o multime de Obiecte Categorie se genereaza un Obiect Generic

Procesul de Generalizare permite construirea unei noi Colectii de Informatii (ex. Persoana), pornind de la existenta altor Colectii de Informatii (ex. Student, Profesor, Copil, Angajat), prin recunoasterea unor Caracteristici Comune, ce vor fi transferate noii Colectii de Informatii. Caracteristicile Specifice Colectiilor Initiale vor continua sa le defineasca în parte, individualizându-le. In cadrul Noii Colectii, care va descrie în ansamblu Obiectul Generic, diferentierea Obiectelor Categorie va fi realizata cu ajutorul unui Criteriu de Clasificare atasat unui Domeniu de valori, prezent în colectie sub forma unui Atribut (ex. Tip-Persoana).

Multimi de Obiecte

Câine, Pisica, Elefant, Cal Student, Profesor, Copil, Angajat

Examen, Colocviu, Proiect Vehicol-Terestru, Vehicol-Aerian, Vehicol-Naval

Camion, Turism, Avion Producator, Beneficiar, Furnizor

O1 , O2 , O3 , .. , On

Og – Obiect Generic Oc - Obiect Categorie

Oc este O g Generalizarea suprima diferentele între Categorii

Obiect Generic

Animal Persoana Verificare Vehicol

Autovehicol Partener

Og

176 Modele de Informatii / Modelul Obiectelor Abstracte

o Specializarea – pornind de la un Obiect Generic se genereaza mai multe Obiecte Categorie

Procesul de Specializare permite construirea unor noi Colectii de Informatii (ex. Student, Profesor, Copil, Angajat), pornind de la definirea unui Criteriu de Clasificare atasat unui Domeniu de valori ce va fi implementat în Colectia initiala sub forma unui Atribut (ex. Tip-Persoana). Domeniile de Valori, care descriu Criteruil de Clasificare, pot reprezenta fie Obiecte Primitive (vezi Fig. 4.1.2.2.1.2), fie Multimi de Valori de Identificatori ai unor Obiecte rezultate dintr-un proces de abstractizare anterior (vezi Fig. 4.1.2.2.1.3)

Operatiile de Clasificare sunt reunite sub numele de Proces de Abstractizare prin Generalizare. Conceptele ce stau la baza acestui proces sunt reprezentate în Fig. 4.1.2.2.1.2 si în Fig. 4.1.2.2.1.3, ca doua variante de implementare a Criteriului de Clasificare.

• Obiectul Abstract Generic PERSOANA ce urmeaza a fi Clasificat prin Generalizare

• Obiectul Abstract Categorie Profesor ce rezulta din Obiectul Abstract Generic PERSOANA care are, ca Valoare a Atributului Tip-Persoana, Valoarea de Categorie Profesor

• Realizare a Obiectului Abstract Categorie Profesor, reprezentat de o aparitie concreta a acestui Obiect Abstract

• Atributul Categorie Tip-Persoana, care va fi ales ca si Criteriu de Clasificare

• Valoare de Categorie (Profesor), reprezentata de o Valoare a Atributului Categorie în Obiectul Abstract Generic PERSOANA

Fig. 4.1.2.2.1.2. Generalizarea cu Atribut de tip Categorie

In legatura cu cele doua variante de implementare a Generalizarii se fac urmatoarele observatii:

- In exemplul din Fig. 4.1.2.2.1.2 Clasificarea se realizeaza prin simpla alegere a Atributului Tip-Persoana (corespunzator unui Domeniu de Valori anterior definit) si descrierea Colectiilor de Realizari: Studenti, Profesori, Copii, Angajati, prin considerarea Valorilor concrete ale acestui Atribut în cadrul PERSOANEI.

Obiect Abstract Generic

PERSOANA Marca Nume Prenume Vârsta Tip-Persoana

M1 N1 P1 V1 Student M2 N2 P2 V2 Profesor M3 N3 P1 V3 Student M4 N4 P3 V2 Profesor M5 N5 P4 V4 Angajat

Student

Profesor

Angajat

Obiecte Abstracte Categorie

Modele de Informatii / Modelul Obiectelor Abstracte 177

• Obiectul Abstract Generic PERSOANA ce urmeaza a fi Clasificat prin Generalizare

• Obiectul Abstract Categorie Profesor, ce rezulta din Obiectul Abstract Generic PERSOANA care are, ca Valoare a Atributului Tip-Persoana, Valoarea de Categorie Identificator de Profesor,

• Realizare a Obiectului Abstract Categorie Profesor, reprezentat de o aparitie concreta a acestui Obiect Abstract

• Atributul Categorie Tip-Persoana, care va fi ales si în acest caz ca si Criteriu de Clasificare

• Valoare de Categorie (C2) reprezentata de o Valoare a Atributului Categorie în Obiectul Abstract Generic PERSOANA, reprezentata de data aceasta nu de Nume de Categorie, ci de Identificatorul de Realizare al Obiectului Abstract Categorie (TIP-PERSOANA)

• Obiectul Abstract TIP-PERSOANA, care descrie un Criteriu de Clasificare ce urmeaza sa realizeze Generalizarea si care contine Valorile de Categorii ca si Valori ale Atributului Nume din TIP-PERSOANA

• Realizare a Obiectul Abstract TIP-PERSOANA, care va reprezenta o aparitie concreta de Valoare de Categorie (Profesor ca Valoare de Nume TIP-PERSOANA)

Fig. 4.1.2.2.1.3. Generalizarea cu Obiect Abstract de tip Criteriu de Clasificare

TIP-PERSOANA Cod Nume C1 Student C2 Profesor C3 Copil C4 Angajat

PERSOANA Marca Nume Prenume Vârsta Tip-Persoana

M1 N1 P1 V1 C1 M2 N2 P2 V2 C2 M3 N3 P1 V3 C1 M4 N4 P3 V2 C2 M5 N5 P4 V4 C4

Obiect Abstract Generic

Obiect Abstract Criteriu de Clasificare

Student

Profesor

Angajat

Obiecte Abstracte Categorie

178 Modele de Informatii / Modelul Obiectelor Abstracte

- Pentru cresterea Gradului de Consistenta a Colectiei de Date initiale se poate construi o noua Colectie de Date care descrie chiar Criteriul de Clasificare (TIP-PERSOANA), prin doua Atribute proprii:

TIP-PERSOANA (Cod*, Nume)

In Colectia Initiala este acum suficient sa înlocuim Valorile Atributului Tip-Persoana cu Identificatorul corespunzator din Colectia nou creata. Realizarea consistentei se manifesta, ca în cazul general, prin urmatoarele avantaje:

• In structura anterioara sistemul nu poate sa verifice corectitudinea Numelor de Categorii (Student, Profesor, Copil, Angajat), putându-se strecura cu usurinta erori de actualizare, nu numai prin introducerea unor Categorii Neadmise, ci si prin simpla tastare incorecta a Numelor de Categorii

• Modificarea unor Nume de Categorii, deja introduse în structura, necesita inspectia tuturor realizarilor Obiectului Generic pentru a modifica toate aparitiile Valorii Modificate

4.1.2.2.2 Obiecte Agregate

Procesul de Agregare permite construirea unei Colectii de Informatii pornind de la definirea unei Relatii între mai multe Domenii de Valori. Domeniile de Valori pot reprezenta fie Obiecte Primitive (vezi definitia de mai jos), fie multimi de valori de Identificatori ai unor Obiecte rezultate dintr-un proces de abstractizare anterior. Exemplificarea modului de Construire prin Agregare a obiectelor este redata în Fig. 4.1.2.2.2.1 .

Fig. 4.1.2.2.2.1 Exemplificarea procesului de Abstractizare prin Agregare

Relatii între Obiecte

Un tip de Persoana are un Cod si un Nume O Persoana are o Marca, un Nume, un Prenume, o Vârsta

si un Tip de Persoana Un Autovehicol are un Numar, un Producator, o Valoare

si o Categorie Un Vehicol transporta o Incarcatura, la o Data

catre o Destinatie Un Producator contracteaza cu un Furnizor un Serviciu de o

Valoare

(O1 , O2 , O3 , .. , On )

Oa – Obiect Agregat Oc - Obiect Componenta

Oa are Oc Agregarea suprima numele Componentelor

Obiect Agregat

Tip Persoana Persoana

Tip Element

Transport

Contract

Og

Modele de Informatii / Modelul Obiectelor Abstracte 179

Agregarea se naste dintr-o Relatie între alte Obiecte. Asa dupa cum Obiectul Generic se construieste din Obiecte de tip Categorie, Obiectul Agregat se construieste din Obiecte de tip Componente. Agregarea preia în general numele Verbului din Relatia care îl defineste.

Definitie: Obiect Primitiv – Obiectul Abstract Nedecompozabil, care nu are ca urmare în structura sa alte Obiecte Abstracte (nici Categorii, nici Componente).

4.1.2.3 Ierarhii de Obiecte Abstracte

Acelasi obiect poate fi privit simultan ca Obiect Generic, si ca Obiect Agregat, cele doua Procese de Abstractizare desfasurându-se simultan, pe mai multe nivele si conducând la generarea, în doua planuri distincte, a Ierarhiilor de Abstractizare:

• Ierarhia de Generalizare

• Ierarhia de Agregare

Ierarhia de Generalizare va fi alcatuita din Categoriile Obiectelor Abstracte Generice, desfasurate pe nivele succesive de subordonare.

Ierarhia de Agregare va fi alcatuita din Componentele Obiectelor Abstracte Agregate, desfasurate pe nivele succesive de subordonare.

Pentru exemplificare se prezinta o Structura de Informatii care descrie Gestiunea Vehicolelor de Transport, ce cuprinde urmatoarele Obiecte:

AUTOVEHICOL (Numar*, Producator*, Valoare, Categorie)

PRODUCATOR (Companie*, Sediu)

INTRETINERE (Autovehicol*, Data*, Mecanic)

MECANIC (Nume*, Atelier)

TRANSPORT (Autovehicol*, Data*, Destinatie, Incarcatura)

Sa mai consideram urmatoarele clasificari semantice ale Obiectului VEHICOL. Aceasta se realizeaza prin precizarea Criteriilor de Clasificare împreuna cu Categoriile pentru fiecare Criteriu:

o Mediu de Deplasare – Blocul B1

VEHICOL (Terestru, Aerian, Naval)

o Mijloc de Propulsie – Blocul B2

VEHICOL (Auto, Manual, Naval)

o Încarcatura – Blocul B3

VEHICOL (Persoane, Marfa)

Modele de Informatii / Modelul Obiectelor Abstracte 180

Fig. 4.1.2.3.1 Structura pe Blocuri a Categoriilor

Fig. 4.1.2.3.2 Ierarhii de Generalizare

B1

VEHICOL

B2 B3

TerestruC1

Aerian C2

Naval C3

Auto C4

Manual C5

Hipo C6

Persoane C7

Marfa C8

BicicletaC11

VEHICOL

Terestru Aerian

Camion C41

Auto

Marca M2

Marca M1

Avion C43

Planor C21

Turism C42

Marca M3

Marca M4

Modele de Informatii / Modelul Obiectelor Abstracte 181

Fig. 4.1.2.3.3 Ierarhia de Agregare

AUTOVEHICOL

PRODUCATOR

TRANSPORT INTRETINERE

Numar Valoare

Sediu Companie

Data

Destinatie

Incarcatura MECANIC

Nume

Atelier

Categorie

Data

182 Modele de Informatii / Modelul Obiectelor Abstracte

Rezulta în mod direct gruparea pe Blocuri a Categoriilor, daca se respecta conditia ca Multimile de Categorii pe Blocuri sa fie Disjuncte (Fig. 4.1.2.3.1). Conditia ca Blocurile sa fie disjuncte este fireasca daca se tine seama de urmatoarele restrictii impuse de Modelul Obiectelor Abstracte:

- Fiecare Criteriu de Clasificare, deci fiecare Bloc va fi atasat unui Atribut de tip Categorie din Obiectul Generic

- Fiecare Atribut reprezinta un Obiect Primitiv, deci Nedecompozabil

In Fig. 4.1.2.3.2 este reprezentata o Ierarhie de Generalizare bazata pe clasificarile anterior prezentate. In Ierarhia de Generalizare se observa prezenta unor Categorii distribuite pe mai multe nivele si care sunt partajate de mai multe Categorii aflate pe nivele superioare. Nu se încalca însa restrictia de disjunctivitate întrucât atunci când se va dori cuprinderea întregului Arbore de Clasificare, în Lista de Atribute vor trebui sa se regaseasca toate Criteriile de Clasificare, a caror combinare de Valori va asigura acoperirea Ierarhiei de Generalizare prezentata. In exemplul care va fi folosit la prezentarea Ierarhiei de Agregare se recurge la o simplificare a Ierarhiei de Generalizare datorita interesului acordat doar Obiectului Abstract AUTOVEHICOL.

In Ierarhia de Agregare (Fig. 4.1.2.3.3) se regasesc cele cinci Obiecte Abstracte: AUTOVEHICOL, PRODUCATOR, INTRETINERE, MECANIC, TRANSPORT, împreuna cu Obiectele de tip Componente. Se poate remarca:

- Prima categorisire a tipurilor de Atribute este legata de posibilitatea de Identificare a Obiectelor:

§ Identificatori reprezentati de Atributele marcate cu asterisc

§ Descriptori reprezentati de celelalte Atribute

- Orice Descriptor apare doar într-un Obiect Abstract

- Existenta a doua tipuri de Atribute în Ierarhia de Agregare si anume:

§ Categorii - Valori de Categorii ale Obiectului Abstract AUTOVEHICOL

§ Componente - restul Atributelor care descriu continutul Obiectului Abstract 4.1.2.4 Realizari de Obiecte Abstracte

Reprezentarea Ierarhiilor de Generalizare si de Agregare se continua prin desfasurarea lor în planul Realizarilor, în momentul implementarii. Desfasurarea se realizeaza prin Instantierea cu Valori a Obiectelor Abstracte. Imaginile astfel obtinute sunt cele ale Tabelelor care corespund Relatiilor, deci corespund de la bun început modului de constructie prin Agregare, specific Relational.

Fiecarui Obiect Abstract îi corespund mai multe Realizari (Instante) în Spatiul de Informatii si implicit ulterior în Spatiul Datelor. Preluând conceptele dezvoltate cu ocazia introducerii nivelelor Logic si Fizic de descriere a Informatiilor si Datelor putem sa operam urmatoarea adaptare:

§ La nivel Logic – se defineste Tipul de Obiect Abstract (Definire Intensionala)

Modele de Informatii / Modelul Obiectelor Abstracte 183

§ La nivel Fizic – se Instantiaza prin Valori Tipul de Obiect Abstract (Definire Extensionala); Instanta mai poarta si numele de Token

In construirea Planului Realizarilor de Obiecte Abstracte (OA) se au în vedere urmatoarele Reguli de Reprezentare:

o Orice Realizare de OA e reprezentata de Identificatorii Realizarilor Componentelor sale

o Realizarile Obiectelor Primitive sunt Autoidentificabile

o Realizarile Obiectelor Neprimitive sunt Identificabile Asociativ, prin declararea unui numar suficient de Identificatori de Componente (Atribute), care vor defini o Cheie

o Atributele Tipului de Obiect Abstract sunt Componentele si Categoriile (sub forma de Nume)

o Atributele Realizarii de Obiect Abstract sunt Realizarile de Componente si Categorii (sub forma de Valori)

o Identificarea OA este Asociativa, întrucât se face cu ajutorul Identificatorilor de Componente, deci a Valorilor de Componente

Un exemplu de reprezentare a unui OA în Planul Realizarilor e data în Fig. 4.1.2.4.1.

Fig. 4.1.2.4.1 Realizarile OA AUTOVEHICOL

4.1.2.5 Ierarhii de Obiecte Abstracte în Planul Realizarilor

Pentru construirea de Ierarhii de Agregare în Planul Realizarilor se face apel la urmatoarele Reguli de Reprezetare:

o Fiecare OA are un Identificator (Cheie)

o Fiecare Realizare de Componenta este reprezentata de Identificatorul de Realizare (prin Referire Asociativa) si nu de Realizarea propriuzisa; Aceasta determina:

• Simplificarea reprezentarii prin eliminarea Redondanta si asigurarea Consistentei

AUTOVEHICOL Numar* Producator* Valoare Categorie

N1 P1 V1 C42 N2 P2 V2 C41 N3 P1 V3 C41 N4 P3 V4 C43 N5 P4 V5 NULL

Identificatori de Realizari de Componente

Identificatori de Realizari de Categorii

184 Modele de Informatii / Modelul Obiectelor Abstracte

• Realizarea referita trebuie sa fie deja definita

• Se asigura Ierarhizarea Realizarilor în Planul de Agregare

• Se asigura partajarea Realizarilor prin Referire Multipla

o Exista Realizari de OA care nu apar în nici-o Relatie (nu sunt referite de nici-o alta Realizare a altui OA)

Regulile prezentate sunt ilustrate de exemplul continut în Fig. 4.1.2.5.1.

Din aceasta prezentare se remarca faptul ca Modelul Obiectelor Abstracte se aseamana, în punctele esentiale este chiar identic, cu Modelul Relational. In continuare se vor semnala si deosebiri, în special în forma de implementare a Generalizarii. Asemanarile însa ramân preponderente si ele atrag atentia, întrucât punctele de pornire si caile parcurse de cele doua Modele difera:

- Modelul Relational porneste de la definirea matematica, formala si riguroasa a Multimilor si Relatiilor

- Modelul Obiectelor Abstracte porneste de la Principii Logice de formare a Conceptelor, punând accent pe procesul mental de Reflectare a Realitatii

Fig. 4.1.2.5.1 Ierarhie de Agregare în Planul Realizarilor

In cazul transpunerii OA în Planul Realizarilor (vezi Figurile 4.1.2.5.1 si 4.1.2.5.2) trebuie respectate urmatoarele Reguli de Reprezentare:

AUTOVEHICOL Numar* Producator* Valoare Categorie

N1 P1 V1 C42 N2 P2 V2 C41 N3 P1 V3 C41 N4 P3 V4 C43

INTRETINERE Autovehicol* Data* Mecanic

N1 D1 M1 N2 D2 M1

TRANSPORT Autovehicol* Data* Destinatie Incarcatura

N1 D1 T1 I1 N2 D2 T2 I2 N3 D1 T1 I3

MECANIC Nume* Atelier

M1 A1 M2 A2

PRODUCATOR Companie * Sediu

N1 S1 N2 S2

Modele de Informatii / Modelul Obiectelor Abstracte 185

o Obiectul Abstract Generic desfasurat în Planul Realizarilor va avea doua tipuri de Componente:

• Componente Comune, care pot fi: Transferabile (Mostenite) sau Netransferabile asupra OA Categorie

• Componente Specifice, care caracterizeaza si individualizeaza OA de tip Categorie

o Realizarile Obiectului Generic si ale Obiectelor Categorie, care descriu aceeasi realitate se numesc Imagini Reciproce (ale aceluiasi Obiect)

o In Imaginile Reciproce de OA, Componentele Comune trebuie sa fie identice

o Fiecare Realizare de OA din Planul de Generalizare nu apare în mai mult de o Categorie de OA (pentru a respecta restrictia dupa care Valoarea Categoriei în orice OA e Unica si nu Multipla)

Aceasta conditie impusa asigura tratarea unitara a Realizarilor de Componente si de Categorii.

o O multime de Categorii Disjuncte ale unui OA formeaza un Bloc (vezi Fig. 4.1.2.3.1), care corespunde unui Criteriu de Clasificare Unic

Fig. 4.1.2.5.2 Ierarhie de Generalizare în Planul Realizarilor

AUTOVEHICOL Numar* Producator* Valoare Categorie

N1 P1 V1 C42 N2 P2 V2 C41 N3 P1 V3 C41 N4 P3 V4 C43 N5 P4 V5 NULL

Avion (C43) Numar* Producator* Valoare Nr-Aripi

N4 P4 V4 A1

Camion (C41) Numar* Producator* Valoare Tonaj

N2 P2 V2 T1 N3 P1 V3 T2

Turism (C42) Numar* Producator* Valoare Nr-Usi

N1 P1 V1 U1

Imagini Reciproce ale OA

Autovehicol N1

186 Modele de Informatii / Modelul Obiectelor Abstracte

4.1.2.6 Relativitatea Viziunii asupra Obiectelor Abstracte

Pentru a putea discuta acest subiect vom face referire la Figurile 4.1.2.2.1.2 si 4.1.2.2.1.3. Totodata vom schita în Fig. 4.1.2.6.1 o Ierarhie de Generalizare cu considerarea Blocurilor din Fig. 4.1.2.3.1, la care adaugam si elemente din Ierarhia de Agregare (vezi OA AUTOVEHICOL si INTRETINERE). Ierarhiile vor fi reprezentate în Planul Realizarilor.

Relativitatea Viziunii asupra Obiectelor Abstracte nu sterge nimic din precizia de definire a acestora. Ea provine din unghiul de vedere al Utilizatorului asupra Structurii de OA si totodata din raporturile multiple în care OA este angajat. Aceste raporturi multiple sunt datorate generalitatii de definire a OA ca Unic Constructor al Structurilor de Informatii. OA poate îndeplini simultan mai multe functii în cadrul Structurii de Informatii. Dintre aceste functii multiple enumeram:

o OA Agregat cu Realizari Multiple – este functia de baza cu care OA este definit si introdus în sistem, prin precizarea continutului sau principal de informatii, adus de OA de tip Componente si / sau Categorie

o OA Categorie cu Realizari Multiple – OA de tip Criteriu de Clasificare care provine în general dintr-un OA de tip Categorie, referit în definirea unui OA Generic

o Realizare de OA – Instanta de OA este considerata tot OA, dar în Planul Realizarilor

o OA Primitiv – OA Nedecompozabil, care apare pe post de Atribut al unui alt OA, cu functia de :

§ OA de tip Componenta când apare ca:

• Atribut Autoidentificabil pe post de Componenta

• Identificator de OA care refera de pe post de Componenta un alt OA

§ OA de tip Categorie care contribuie la:

• Descrierea unui nou OA si includerea lui în sistem

• Generalizarea unui OA deja existent în sistem

Privit dintr-un punct de vedere exterior Modelului OA un Obiect Abstract poate îndeplini functii diverse de reprezentare:

- Functie de Entitate – OA descrie o Existenta printr-o Multime de Atribute

- Functie de Relatie – OA descrie o Legatura între alte OA

- Functie de Atribut – OA descrie o Însusire Elementara

Acest punct de vedere este sistematic reprezentat în Tab. 4.1.2.6.2, care ilustreaza diversele ipostaze ale OA, rezultate în etapele succesive de Abstractizare. Se regasesc regrupate conceptele cu care opereaza Modelul Obiectelor Abstracte. Este oferita totodata echivalarea acestor concepte cu notiunile care au fost introduse în cadrul Modelului Entitate – Caracteristica – Valoare.

Modele de Informatii 187

Fig. 4.1.2.6.1 Viziunile Multiple ale Obiectului Abstract AUTOVEHICOL

Autovehicol (C4) Auto N1 P1 V1 C41

Vehicol-Manual (C5)

Vehicol-Hipo (C6)

VEHICOL Numar* Producator* Valoare Mediu de

Deplasare Mijloc de Propulsie

Incarcatura

N1 P1 V1 C4 N2 P2 V2 C4 N3 P1 V3 C4 N4 P3 V4 C4 N5 P4 V5 C4

MIJLOC-PROPULSIE Cod* Nume Grad

Poluare Putere Tipica

C4 Auto G1 P3 C5 Manual G2 P2 C6 Hipo G3 P5

Vehicol-Terestru (C1)

Vehicol-Aerian (C2)

Vehicol-Naval (C3)

Vehicol-Persoane (C7)

Vehicol-Marfa (C8)

INTRETINERE Autovehicol* Data* Mecanic

N1 D1 M1 N2 D2 M1

Viziuni ale Obiectului Abstract AUTOVEHICOL - Obiect Abstract Agregat cu mai multe realizari - Realizare de Obiect Abstract - Obiect Abstract Categorie cu mai multe realizari - Valoare de Categorie - Obiect Abstract Primitiv Componenta - Realizare de Obiect Abstract Categorie - Obiect Abstract Primitiv Categorie

Modele de Informatii 188

COMPONENTA VALOARE de

COMPONENTA

PRIMITIV

CATEGORIE VALOARE de

CATEGORIE

ATRIBUT

OBIECT ABSTRACT AGREGAT

RELATIE AGREGARE

OBIECT ABSTRACT COMPONENTA

NOTIUNE

OBIECT ABSTRACT GENERIC

OBIECT ABSTRACT

NEPRIMITIV

GENERALIZARE

OBIECT ABSTRACT CATEGORIE

ENTITATE

OBIECT

Tab. 4.1.2.6.2 Relativitatea viziunii utilizatorului asupra Obiectelor Abstracte

Modele de Informatii / Modelul Obiectelor Abstracte 189

4.1.2.7 Sintaxa Abstracta

Definirea structurilor în Modelul Obiectelor Abstracte se face prin intermediul unui Limbaj de Descriere, a carui Sintaxa este descrisa cu ajutorul Metalimbajului prezentat în Fig. 4.1.2.7.1. Limbajul, concis si simplu, permite declararea Obiectelor Abstracte prin:

o Numirea OA cu ajutorul Simbolurilor Unice

o Precizarea Identificatorilor de Instanta pentru OA, prin intermediul Cheilor

o Indicarea Continutului OA:

§ Componentele OA – cu precizarea Componentelor Comune si Specifice, prin intermediul Conditiei de Aparitie

§ Categoriile OA – cu precizarea Ierarhiei de Categorii prin intermediul Conditiei de Aparitie si totodata cu enumerarea Valorilor Admise de Categorii (pentru detalii legate de construirea prin Generalizare a Obiectelor Abstracte vezi Figurile 4.1.2.3.1 si 4.1.2.3.2)

def < obiect> obiect [cheie] < componenta > [conditie] ; < componenta > [conditie] ; . . . < componenta > [conditie] ; < componenta > = (categorie , categorie , ... , categorie) [conditie] ; < componenta > = (categorie , categorie , ... , categorie) [conditie] ; . . .

< componenta > = (categorie , categorie , ... , categorie) [conditie] ; end

unde : cheie → componenta, componenta, .. , componenta conditie → componenta categorie = valoare categorie

Fig. 4.1.2.7.1 Sintaxa Abstracta pentru Limbajul de Definire a Obiectelor Abstracte

Fata de modelul de descriere oferit de autori s-au luat în considerare urmatoarele completari:

o descrierea Componentelor Condi tionale prin adaugarea în limbaj a Conditiei de Prezenta a Componentelor în corpul obiectului, cu urmatoarele consecinte:

§ In cazul Componentelor Simple - prezenta Conditiei permite delimitarea Componentelor Comune si a celor Specifice, pentru Imaginile Reciproce ale Obiectelor Individuale

190 Modele de Informatii / Modelul Obiectelor Abstracte

§ In cazul Componentelor de tip Categorie - prezenta Conditiei usureaza descrierea Arborilor de Clasificare desfasurati pe nivele multiple, prin concentrarea descompunerii în Blocuri a Categoriilor

§ In ambele cazuri - prezenta Conditiei micsoreaza simtitor numarul de Obiecte Abstracte care se cer descrise explicit în Modelul Conceptual, fara însa a reduce finetea de rafinare în definirea Obiectelor de tip Categorie, a caror identificare poate fi facuta automat de sistem , prin preluarea Valorii de Categorie, în calitate de Nume de Obiect de tip Categorie

Exemplu:

Ca exemplificare a Sintaxei Abstracte se da în continuare, în Fig. 4.1.2.7.2, descrierea Structurii Organizatorice a unei Unitati de Învatamânt Superior. Structura prezentata este de tip Recursiv, m – n.

def UNITATE obiect Cod Cod; Nume;

Tip (Universitate, Facultate, Specializare, Profil, An, Grupa, Subgrupa, Secretariat, .. ,)

end def UNITATE_CRONOLOGICA obiect Cod, Data_Inceput Cod; Data_Inceput; Data_Sfarsit; Nume; Forma_Invatamant (Facultate, Colegiu, Masterat, .. ,); Profil (Tehnic, Economic, Matematic, .. ,) Acreditare (Da, Nu) end def STRUCTURA obiect Unitate_Curenta,Unitate_Asscendenta Unitate_Curenta; Unitate_Asscendenta; Tip (Organizatorica, Functionala, Admitere, .. ,) end

Fig. 4.1.2.7.2 Structura Organizatorica Universitara (descriere ca structura de OA

Se remarca regruparea în cadrul unui singur OA a tuturor OA de tip Categorie (Universitate, Facultate, Specializare, Profil, An, Grupa, Subgrupa, Secretariat). Pentru simplificare este prezentata doar varianta de implementare cu Atribute de tip Categorie (Fig. 4.1.2.2.1.2)

Modele de Informatii / Modelul Obiectelor Abstracte 191

4.1.2.8 Operatii Abstracte

A doua directie de abstractizare în Modelul OA se efectueaza în Planul Transformarilor la care sunt supuse Obiectele Abstracte si are ca rezultat definirea Operatiilor Abstracte. Întrucât în orice Structura definita, problema care se pune este cea de Pastrare a Integritatii ei în urma Transformarilor pe care le sufera, în definirea Operatiilor Abstracte intereseaza Setul Minim de Operatii care asigura mentinerea Semanticii Agregarii si a Generalizarii continute în Structura de Informatii. Operatiile care actioneaza în cadrul Modelului Obiectelor Abstracte se împart în doua categorii:

o Operatii Primitive - operatii ce actioneaza direct asupra Realizarilor de Obiecte

o Operatii de Utilizator - operatii ce actioneaza asupra Obiectelor Individuale Definitie:

Prin Obiecte Individuale se întelege Ansamblul tuturor Realizarilor de OA care descriu în Modelul Obiectelor Abstracte aceeasi Existenta din Spatiul Informatiilor. 4.1.2.9 Principiul Conservarii Semantice

Autorii formuleaza Principiul Conservarii Semantice a Obiectelor Individuale astfel:

Fiecare Operatie de Utilizator trebuie sa pastreze Integritatea Obiectelor Individuale.

Un set de cinci restrictii sunt definite pentru precizarea Conditiilor de Pastrare a Integritatii Obiectelor Individuale. Acestea sunt:

1. Fiecare Realizare (Instanta) de Categorie trebuie sa aiba o Imagine în

Realizarile (Instantele) Obiectelor Abstracte (întrucât o Valoare de Categorie defineste un OA Categorie, ca o submultime de Realizari ale OA Generic – Fig. 4.1.2.6.1)

2. Daca exista o Valoare de Componenta Categorie c1 într-o Realizare

de Obiect Abstract Categorie OAC1, care este Imaginea Realizarii de Obiect Abstract în Planul de Generalizare, atunci va exista si o Valoare (Realizare) de Categorie c1 în Obiectul Abstract Categorie, care descrie Structura pe Categorii a Obiectului Generic OA (Fig. 4.1.2.2.1.3)

3. Imaginile de Realizari trebuie sa fie Consistente (toate Valorile

Componentelor Comune sa fie Identice si Valoarea Atributului Categorie în Imagine sa fie egala cu Valoarea unei Realizari de Categorie – vezi Figurile citate anterior)

4. Valorile Componentelor Cheie în Realizarile de Obiecte Abstracte

trebuie sa fie Unice (fiecare Imagine trebuie sa fie identificabila în Planul de Agregare)

5. Atributele oricarei Imagini trebuie sa fie Identificatori de Realizari de

Obiecte Abstracte deja existente

192 Modele de Informatii / Modelul Obiectelor Abstracte

4.1.2.10 Metodologia de Proiectare în Modelul OA

In finalul prezentarii Modelului Obiectelor Abstracte autorii stabilesc urmatoarea Metodologie de Proiectare a Structurilor de Informatii. Etapele si pasii propusi pentru fiecare etapa se vad în Fig. 4.1.2.10.1.1.

4.1.2.10.1 Continutul Metodologiei de Proiectare

Metodologia consta dintr-o suita de cinci pasi subdivizati în faze:

o Definirea Dictionarului Obiectelor Abstracte

§ Stabilirea, în urma Analizei Cernitelor, a Obiectelor ce urmeaza a fi tratate si care constituie o Categorie Primara , Categoria Obiectelor Abstracte

o Construirea Planului de Generalizare

§ Determinarea corespondentei Obiect - Categorie

§ Împartirea Categoriilor fiecarui obiect în Blocuri

o Construirea Planului de Agregare

§ Determinarea corespondentei Obiect – Componenta

o Construirea Planului de Realizari de Obiecte

§ Determinarea Valorilor de Chei pentru fiecare Obiect

§ Determinarea Valorilor Categoriilor fiecarui Obiect

§ Determinarea Valorilor Categoriilor pe Bloc pentru fiecare Categorie

o Descrierea structurii cu ajutorul Sintaxei Abstracte

§ Specificarea pentru fiecare Obiect a Componentelor, Categoriilor si Cheilor

Fig. 4.1.2.10.1.1 Modelul Obiectelor Abstracte (Metodologia de Proiectare)

Este de notat simplitatea metodei propuse si totodata utilitatea informatiilor culese pentru construirea ulterioara a unui Model de Date. In special atunci când Modelul de Date prevazut este Relational majoritatea informatiilor îsi gasesc corespondenta directa cu elementele de structura cu care urmeaza sa se faca implementarea.

In sensul de evidentiere a acestor corespondente între Modelul Obiectelor Abstracte si Modelele de Date va fi purtata si discutia referitoare la Implementarea Relationala a Proceselor de Abstractizare (vezi sectiunea 4.2.4.7.3).

Modele de Informatii / Modelul Obiectelor Abstracte 193

4.1.2.10.2 Erori de Utilizare a Metodologiei

Pentru a asigura Principiul Integritatii Obiectelor Individuale se cere a se analiza cu atentie anumite capcane care pot abate Metodologia de la acest deziderat, afirmat înca în preambulul prezentarii Modelului Obiectelor Abstracte. Câteva cazuri sugestive sunt oferite în cele ce urmeaza, sub forma unor erori de concepere a Structurilor OA, pentru care se ofera si solutii de remediere. 4.1.2.10.2.1 Stabilirea Categoriilor Directe

Sa consideram OA de tip Categorii din Fig. 4.1.2.10.2.1.1. Ierarhia de Generalizare este eronata datorita nivelului pe care apare Categoria Amfibiu. Motivele sunt urmatoarele:

- Categoriile descrise nu sunt Disjuncte

- Amfibiu nu este o Categorie Imediata (Directa) a OA VEHICOL, întrucât ea este simultan o Categorie a altor doua OA:

• VEHICOL Terestru

• VEHICOL Acvatic

- Categoria Amfibiu nu poate fi adaugata în Ierarhia de Generalizare înaintea celor doua Categorii de care depinde

Fig. 4.1.2.10.2.1.1 Categorii Indirecte

Pentru aceste consideratii se impune modificarea Ierarhiei de Generalizare dupa cum este ilustrat în Fig. 4.1.2.10.2.1.2.

Fig. 4.1.2.10.2.1.2 Categorii Directe

VEHICOL

Terestru Amfibiu Acvatic

VEHICOL

Terestru

Amfibiu

Acvatic

194 Modele de Informatii / Modelul Obiectelor Abstracte

4.1.2.10.2.2 Stabilirea Componentelor Directe

Daca în primul caz semantica este bazata pe cunostinte obisnuite de limbaj, în acest al doilea caz trebuie pornit de la o precizare expresa pe care Utilizatorul o face în legatura cu semantica continuta în Spatiul de Informatii pe care doreste sa-l modeleze.

Aceasta cunostinta suna în cazul exemplificat astfel:

Înscrierea Studentilor se face numai dupa ce s-a format o Clasa

Fig. 4.1.2.10.2.2.1 Componente Indirecte

In aceste conditii Ierarhia de Agregare a Obiectelor Abstracte din Fig. 4.1.2.10.2.2.1 este eronata deoarece:

- Permite construirea OA INSCRIERE înainte ca OA CLASA sa existe

- Nu se respecta Integritatea Obiectelor Individuale (este vorba de referirea unui OA care nu exista în structura)

- Componentele Curs si An nu sunt Componente Directe ale OA INSCRIERE

Fig. 4.1.2.10.2.2.2 Componente Directe

INSCRIERE

Instructor

CLASA

Curs*

An*

STUDENT

Nume

Prenume

Marca*

Vârsta

INSCRIERE

Instructor

CLASA

Curs*

An*

STUDENT

Nume

Prenume

Marca*

Vârsta

Modele de Informatii / Modelul Obiectelor Abstracte 195

Pentru a corecta Structura OA Curs si An vor trebui legate la OA INSCRIERE doar prin OA CLASA, dupa cum se vede în Fig. 4.1.2.10.2.2.2. Acum pentru a introduce un OA INSCRIERE trebuie în prealabil definite OA CLASA si STUDENT. 4.1.2.10.2.3 Identificarea Incompleta

Având la baza Referirea Asociativa, Modelul OA trebuie sa impuna restrictia de Completa Identificare a fiecarei Instante (Realizari) de OA. Pentru toate cazurile în care aceasta conditie nu este respectata se adauga Componente la Identificator. Acest motiv face ca în Ierarhia de Realizari de OA Cheia sa fie precizata pentru fiecare OA. 4.1.2.10.2.4 Tratarea Obiectelor Abstracte de tip Rol

Exista Obiecte Abstracte ce se definesc printr-o Relatie, legata de un anume moment în timp, si care dispar odata cu disparitia Relatiei care le-a definit. Aceste Obiecte Abstracte se numesc Roluri. Întrucât prezenta lor este determinata de alte OA de care ele depind, se discuta statutul lor în cadrul Structurii de OA. De data aceasta dificultatea este creata de lipsa de Independenta a unui OA, care urmeaza sa fie încorporat în structura. Exemplu:

Sa consideram evenimentul CASATORIE. El va defini Obiecte legate de acest eveniment, cum ar fi: (MIRE, MIREASA, NAS, NASA)

Ele provin din Obiectul Abstract PERSOANA, dar ramân legate de Relatia de Definitie CASATORIE. Fig. 4.1.2.10.2.4.1 reda Ierarhia de Agregare pentru aceste Obiecte.

In exemplul prezentat se remarca urmatoarele particularitati:

- Desi Atributele: Mire, Mireasa, Nas, Nasa, Ofiter al Starii Civile, Componente ale OA CASATORIE, reprezinta toate Functii în evenimentul CASATORIE, statutul lor de independenta este diferit

- Atributele: Mire, Mireasa, Nas, Nasa nu pot fi tratate ca si Componente Obisnuite ale Obiectului Abstract CASATORIE, întrucât nu exista independent , ca OA de sine statatoare, care sa poata fi referite prin Identificatori de Instanta

- Atributul Ofiter al Starii Civile poate fi privit ca OA, caci exista independent de Relatia CASATORIE, cu toate ca si el reprezinta o Functie în OA CASATORIE, dar nu este dependent de el, fiind definit anterior evenimentului

- MIRE, MIREASA, NAS, NASA sunt Roluri si nu Obiecte Abstracte Obisnuite, caci depind de Obiectul Abstract CASATORIE, care le defineste

- Definirea Rolurilor MIRE, MIREASA, NAS, NASA ca Obiecte Abstracte de tip Categorie ale OA Generic PERSOANA întâmpina dificultati datorita aparitiei si disparitiei lor, independenta de Valoarea Categoriei atasate (Rol în Casatorie)

Modele de Informatii / Modelul Obiectelor Abstracte 196

Fig. 4.1.2.10.2.4.1 Definire Roluri în Casatorie (Ierarhie de Agregare)

Fig. 4.1.2.10.2.4.2 Definire Roluri în Casatorie (Ierarhie de Generalizare)

PERSOANA

Nume

Prenume

CNP*

Vârsta

CASATORIE

Ofiter al Starii Civile

Numar*

Data*

Mire

Mireasa

Nas

Nasa

Loc

CNP – Cod Numeric Personal

PERSOANA

B1 B2

Doctor C12

Profesor C13

BalerinaC14

Nas C23

Mire C21

Mireasa C22

Nasa C24

Ofiter al Starii Civile

C11

Bloc B1 – Meserie Bloc B2 – Rol în Casatorie

Modele de Informatii / Modelul Obiectelor Abstracte 197

Fig. 4.1.2.10.2.4.3 Definire Roluri în Casatorie (Ierarhie de Agregare – Varianta 1)

CASATORIE Numar* Data* Loc Ofiter

Stare Civila Mire Mireasa Nas Nasa

N1 D1 L1 N1 N4 N5 N2 N3 N2 D1 L1 N1 N6 N7 N2 N3 N3 D2 L1 N1 N9 N8 N4 N5

Balerina (C14)

Profesor (13)

Doctor (C12)

Nasa (C24)

Nas (C23)

PERSOANA CNP* Nume Prenume Vârsta

Meserie Rol în

Casatorie N1 P1 P1 V1 C11 NULL N2 P2 P2 V2 C12 C23 N3 P1 P3 V3 C13 C24 N4 P3 P4 V4 C13 C21 N5 P4 P5 V5 C14 C22

Ofiter Stare Civila (C11)

Mireasa (C22)

Mire (C21)

Modele de Informatii / Modelul Obiectelor Abstracte 198

Fig. 4.1.2.10.2.4.4 Definire Roluri în Casatorie (Ierarhie de Agregare – Varianta 2)

CASATORIE Mire Mireasa Nas Nasa Numar* Data* Loc Ofiter Stare Civila

Pesoana Pesoana Pesoana Pesoana N1 D1 L1 N1 N4 N5 N2 N3 N2 D1 L1 N1 N6 N7 N2 N3 N3 D2 L1 N1 N9 N8 N4 N5

Balerina (C14)

Profesor (13)

Doctor (C12)

PERSOANA CNP* Nume Prenume Vârsta

Meserie

N1 P1 P1 V1 C11 N2 P2 P2 V2 C12 N3 P1 P3 V3 C13 N4 P3 P4 V4 C13 N5 P4 P5 V5 C14

Ofiter Stare Civila (C11)

Modele de Informatii / Modelul Conceptual 199

In continuare se prezinta doua solutii de tratare a Obiectelor de tip ROL. Solutia 1:

In aceasta varianta de tratare:

- Se evita recunoasterea Rolurilor la Nivel Conceptual (Nivelul de Definire a OA)

- Rolurile apar numai la Implementare (Nivelul de Definire a Realizarilor de OA)

- Rolurile, privite ca Obiecte Abstracte Categorie vor fi actualizate în functie de actualizarile operate în Relatia de care depind

- Rolurile se considera Obiecte Abstracte Virtuale, care se recreeaza în Planul Realizarilor de OA din alte OA (în speta din PERSOANA si CASATORIE). Modul de recreare a Obiectelor Abstracte Virtuale este redat de schemele din Figurile mentionate mai jos:

§ Ierarhia de Generalizare cuprinzând Criteriul de Clasificare Rol în Casatorie (Blocul B2) – vezi Fig. 4.1.2.10.2.4.2

§ Ierarhia OA în Planul Realizarilor reprezentata în Fig. 4.1.2.10.2.4.3 Solutia 2:

In aceasta varianta de tratare:

- Obiectul va fi tratat ca Rol în cadrul Relatiei de Definitie

- Rolul va apare si va dispare odata cu Relatia de Definitie, implicând dependenta Obiectelor Abstracte de Relatii

- Apar Structuri Ierarhice în definirea Obiectelor Abstracte Ierarhia OA în Planul Realizarilor pentru aceasta varianta de structura este reprezentata în Fig. 4.1.2.10.2.4.3. Mentionam ca si în acest caz este folosita Ierarhia de Generalizare din Fig. 4.1.2.10.2.4.2.

Se poate observa faptul ca problema definirii corecte a Rolurilor în Structurile cu care opereaza Bazele de Date este foarte utila. Modelul Relational vine sa ofere o multime de solutii de implementare pentru conceptele promovate de Modelul Obiectelor Abstracte, în special cele legate de implementarea Generalizarii Obiectelor Abstracte si a Rolurilor Abstracte. In încheiere gasim utila prezentarea unor solutii de implementare a OA într-un Model de Date Relational, solutii care dau o rezolvare practica multor probleme ridicate:

- Implementarea Operatiilor de Abstractizare prin Structuri Relationale consacrate, care sa ofere baza pentru o transpunere automatizata a Modelului Obiectelor Abstracte în Structura Logica Relationala (vezi sectiunea 4.2.4.7.3)

- Evitarea Mosteniri Datelor Comune în cazul implementarii Obiectelor Abstracte de tip Categorie, prin utilizarea Referirii Asociative la Obiectul Generic

- Implementarea Obiectelor Abstracte de tip Rol utilizând Relatii adecvate de Generalizare, combinate cu Relatii d tip Legatura (vezi sectiunea 4.2.4.7.3)

- Implementarea Obiectelor Individuale prin utilizarea Nivelului Extern al Bazelor de Date Relationale

- Implementarea Operatiilor Abstracte asupra Obiectelor Individuale prin utilizarea Procedurilor Stocate

200 Modele de Date

4.1.3 Modelul Conceptual

Modelul Conceptual ce urmeaza a fi schitat poate fi privit ca solutie de viitor pentru reprezentarea Informatiilor. El încearca sa sintetizeze acumularile facute pâna în prezent în descrierea Spatiului de Informatii. Modelul propus se arata a fi realizabil si stimulativ, în sensul posibilitatii sale de implementare si totodata de adâncire a sensurilor si semnificatiilor informatiilor implicate.

Analizând rezultatele obtinute în directia perfectionarii Structurii Elementare care sa reprezinte un posibil Constructor Unic de Structura în domeniul reprezentarii Informatiilor, am constatat ca toate încercarile converg, în mod firesc, spre forma naturala de Reflectare a Realitatii, care este Notiunea din Logica. Redam mai jos o definire prin caracteristici a Notiunii [BOTE97]:

o Este Forma Logica Elementara care reprezinta în planul cunoasterii rationale Reflectarea Claselor de Obiecte

o Reprezinta Sinteza Cunostintelor referitoare la un Obiect determinat

o Descrie Fiinta Obiectului , Unica si Constanta

o Exprima Esenta Obiectelor, prin precizarea Notelor lor Comune si Stabile

o Defineste o Clasa de Obiecte ca o Unitate

o Un Element al Ansamblului Termen: Notiune (Forma Logica) – Nume (Forma Lingvistica)

Întrucât în limbajul uzual Notiunea este recunoscuta ca sinonim al Conceptului, în Modelul Conceptual s-a optat pentru aceasta a doua forma.

Desi consideram deschisa calea catre rafinari de genul celor continute în definirea raporturilor Functie – Concept si Concept – Obiect [FREG77], am fost obligati sa le evitam în aceasta prima forma de prezentare a Modelului.

Pentru simplificarea operata a pledat si dorinta de a unifica Constructorul de Structura . Desigur în acest scop a fost necesara introducerea termenilor de Concept Primar (Autoidentificator si Identificator) si Concept Derivat, care sa asigure viziunea pragmatica necesara unor implementari.

Asa dupa cum se va vedea în continuare, Modelul propus preia o multime de notiuni deja implementate în Tehnica Modelarii Informatiilor (vezi Modelele Clasice, Modelul Relational, Modelul Obiectelor Abstracte). Modelul de Baza, dezvoltat în aceste constructii anterioare, care precede Conceptului este Clasa de Entitati. Aportul Modelului Conceptual se manifesta prin urmatoarele particularitati:

- Realizeaza o Sinteza a notiunilor anterioare

- Accentueaza Viziunea Structuralista prin încorporarea Procedurii în Concept, ca aptitudine potentiala de generare a unui nou Concept

- Asigura Unicitate prin reducerea tuturor Elementelor de Structura la notiunea de Concept

Modele de Informatii / Modelul Conceptual 201

Conceptul, ca forma Unica de Reprezentare a Structurilor de Informatii, preia Elementele de Definire a Notiunii utilizata în Logica:

o Definirea Conceptului

o Definirea Continutului Conceptului (Nivel Logic de Definire) prin:

§ Numele Conceptului (forma lexicala de Singular) care va asigura referirea Conceptului în Operatiile de Transformare

§ Proprietatile Conceptului – Operatiile care asigura Definirea Functionala a Conceptului prin formele:

o Agrega conceptele ...

o Se generalizeaza prin ...

o Este echivalent cu ...

o Deriva din ... prin transformarea ...

Conceptul poate fi:

• Primar

o Se Autodefineste Structural prin Instanta Unica (Numele se confunda cu Valoarea)

o Nu contine în Definitia Structurala alte Concepte

o Se Autoidentifica prin Valoarea Instantei

o Se Defineste Operational prin Metode Implicite de Sistem

o Apare la Nivelul Instantelor de Concepte având atributii de:

§ Identificator – Identifica unic o Instanta de Concept Derivat

§ Descriptor – Descrie o Instanta de Concept Derivat prin alte Instante de Concepte Primare

§ Înlocuitor – Refera (Substituie) o Instanta de Concept Derivat

o Exemple: Întreg, Real, Caracter, Sir de Caractere, Figura, Imagine etc.

• Derivat

o Se Defineste Structural cu ajutorul altor Concepte

o Poate avea i Instante (unde i reprezinta Cardinalitatea Conceptului)

o Se identifica prin conceptul de Identificator de Instanta

o Se Defineste Operational prin Metode Explicite de Utilizator

202 Modele de Date

o Exemple: Vezi Formele de Derivare

o Definirea Sferei Conceptului prin:

§ Numele Clasei de Instante atasata Conceptului (forma lexicala de Plural) care va asigura referirea Clasei de Instante în Operatiile de Prelucrare

§ Clasa de Instante atasata Conceptului (Nivel Fizic de Definire) prin:

• Instanta de Concept - care descrie o Aparitie Concreta (Instantiere) a Conceptului realizata cu ajutorul Conceptelor Primare

• Identificatorul de Instanta - care reprezinta un Concept Primar Autoidentificator utilizat în continuare în cadrul altei Instante ca si Concept Primar Identificator al primei Instante

• Multimea de Instante – ansamblul tuturor Instantelor care descriu Extensional Clasa de Instante, variabila în timp

Nume Concept (plural) ≡ Concept i

Multimea de Instante reprezinta un Concept Primar în calitate de Valoare de tip Multime ce va contine Identificatori de Instante sub forma de Concepte Primare de tip Înlocuitor (Referinte Asociative la Instantele continute în Multime)

o Conceptul acopera definitia urmatoarelor notiuni:

Clasa de Entitati ≡ Relatie ≡ Clasa de Obiecte

o Conceptul acopera si notiunile de:

Domeniu

Caracteristica ≡ Atribut

vazute ca si Clase de Entitati (vezi sectiunea 4.1.1.3.4)

o Conceptul acopera si notiunea de:

Valoare

vazuta ca si Concept Primar

o Conceptul acopera si notiunile de:

Superclasa de Obiecte

Subclasa de Obiecte

Metaclasa de Obiecte

vazute ca si Clase de Entitati (vezi sectiunea 4.1.1.3.3)

Modele de Informatii / Modelul Conceptual 203

o Conceptul se defineste sub doua aspecte: Structural ( .. are Proprietatile) sau Operational ( .. este rezultatul Transformarii), ambele pastrând forma Predicativa Nesaturata [FREG77]

§ Definire Structurala - prin precizarea Starilor Conceptului sub forma Proprietatilor care îl descriu în doua planuri:

• Planul Logic – se descrie prin alte Concepte invocate prin Nume

Conceptele care descriu alte Concepte vor juca rolul de Caracteristici

• Planul Fizic – descriere prin Concepte Primare

Conceptele Primare vor fi reprezentate de Instante de Concepte, care sunt descrise cu ajutorul Valorilor

§ Definire Operationala - prin precizarea operatiilor care determina Transformarile admise asupra Conceptelor

Transformarile de Concepte preiau forma de transformare a Obiectelor prin Metode invocate de Mesaje. Noutatea consta în faptul ca orice Transformare de Concept returneaza un nou Concept, sau cu alte cuvinte, orice transformare genereaza un nou Concept potrivit relatiei de echivalenta:

Concept 1 ≡ Concept 2 (Transformare)

Transformarea poate fi privita ca un Concept Virtual (Concept în devenire)

o Derivarea Conceptelor se poate face printr-una din urmatoarele forme:

§ Derivare prin Definire

• Definire prin Agregare

Conceptul 1 ≡ (Conceptul 2 , Conceptul 3 , ... Conceptul n )

Orice invocare a unui Concept pentru Definirea prin Agregare:

o La nivel Logic – se face prin invocarea de Concepte prin Nume, care însa nu implica Mostenire de Stari

o La nivel Fizic - se face prin invocare a unui Concept Primar Identificator (Valoare de Identificator de Instantiere)

Se zice :

Conceptul 1 agrega Conceptul 2 , Conceptul 3 , ... Conceptul n

Exemplu:

PERSOANA ≡ (Marca , Nume , Prenume, Sex, Grupa)

unde: Marca, Nume, Prenume, Sex, Grupa sunt Concepte de tip Domeniu anterior definite:

MARCA ≡ (Intreg)

204 Modele de Date

NUME ≡ (Sir de Caractere)

..

• Definire prin Generalizare

Conceptul 1 ≡ (Conceptul 2 , Conceptul 3 , ... Conceptul n )

Conceptul 2 ≡ Categorie Unde:

Categorie este un Concept Definit prin Agregare

Se zice :

Conceptul 1 se generalizeaza prin Conceptul 2

Definitia de Categorie poate genera automat structura:

Concept 2 ≡ (Cod ≡ Intreg, Nume ≡ Sir)

Unde:

Domeniul de Valori al atributului Nume contine Valorile de Categorie ale Conceptului 2

Orice definire prin Generalizare:

o Genereaza noi concepte cu numele construite din:

Nume Concept 1 + Valoare-Categorie din Concept 2

o Adaugarea de concepte specifice de definire pentru fiecare Concept-Categorie se va face prin completarea definirii prin agregare (adaugarea de noi Componente alaturi de cele generate automat – Cod si Nume)

Exemplu:

PERSOANA ≡ (Marca , Nume , Prenume, Sex, Adresa, Rol)

unde:

ROL ≡ (Cod, Nume)

ROLURI ≡ (1,’Profesor), (2,’Student)’,(3,’Angajat’)

• Definire prin Echivalenta Conceptul 1 ≡ Conceptul 2

Se zice : Conceptul 1 este echivalent cu Conceptul 2

Definirea prin Echivalenta permite declararea Sinonimiei în cadrul Conceptelor

§ Derivare prin Transformare

Conceptul 1 ≡ Conceptul 2 (Transformare)

Se zice :

Modele de Informatii / Modelul Conceptual 205

Conceptul 1 deriva din Conceptul 2 prin transformarea invocata de Mesaj

Se remarca ca Derivarea prin Transformare este cea mai generala forma , ea putând suplini, cu metode adecvate de transformare, Derivarea prin Definire

Exemplu 1:

PERSOANA-Profesor ≡ PERSOANA (Rol=’Profesor’)

PERSOANA-Student ≡ PERSOANA (Rol=’Student’ si Sex=’Barbat’)

Exemplu 1:

GRUPA ≡ (Cod , Nume , Limba-Predare)

PERSOANA-Student-Grupa1 ≡ PERSOANA-Student (Grupa=’1’)

Având în vedere faptul ca Transformarea se implementeaza în Concept ca si Proceduri de Utilizator, posibilitatea de generare a noi Concepte ramâne deosebit de mare.

o Conceptul exclude Mostenirea de Structura de Concept. Mostenirea de Nume de Concepte nu duce decât la Redondanta si Inconsistenta posibila. Ea e înlocuita cu invocarea unui Concept în definirea altui Concept prin Nume sau a unei Instante prin Valoare

o Mostenirea de Metode se face între Conceptele legate prin Derivarea prin Generalizare, care e o legatura de tip Este (IS-A) si care poate fi Multipla

o Legatura de Clasa - Subclasa e considerata o Structura Ierarhica de natura Statica, fiind înlocuita cu trei forme proprii de mo stenire care corespund celor trei forme de definire a Conceptelor:

§ Mostenire prin legatura de Abstractizare prin Agregare

§ Mostenire prin legatura de Abstractizare prin Generalizare

§ Mostenire prin legatura de Echivalenta

o Modelul foloseste doar Regasirea Asociativa a Instantelor

o Modelul apeleaza la doua nivele de reprezentare a datelor:

§ Reprezentare Conceptuala la Nivel Extern

§ Reprezentare Relationala la Nivel Intern

o Modelul foloseste notiunea de Concepte Persistente bazata pe memorarea Conceptelor definite utilizând Proiectia Relationala de la Nivelul Intern, precum si a Descrierii Conceptelor la Nivelul Extern

In dorinta de a prezenta si o tendinta întrevazuta pentru dezvoltarea noilor tehnologii de prelucrare a informatiilor si datelor am tinut sa prezentam si Schita unui Model Conceptual. Desigur numeroase încercari de implementare vor fi necesare pentru a valida, definitiva sau înlocui ideile anticipate în aceasta încercare. Ramânem însa cu convingerea ca multe din ideile avansate aici, vor fi regasite sub o forma sau alta în instrumentele din viitor.

206 Modele de Date

4.2 Modele de Date

Modelele de Date sunt discutate în contextul apropierii Structurilor concepute în Spatiul de Informatii de instrumentul de prelucrare – Calculatorul. Vom regasi conceptele dezvoltate în sectiunile precedente, la care se vor adauga cele specifice reprezentarilor pe Suportul de Memorare. Având în vedere Planurile de Descrise introduse în sectiunea 3.4.1.2 (al Numelor si al Valorilor) si în aceasta sectiune vom vedea procesul de implementare desfasurat pe nivele diferite de abstractizare (de la cele Conceptuale la cele Fizice). 4.2.1 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 în date,

în locul Copacilor – datele privite detasat de semnificatiile de ansamblu.”

Langefors, în 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. Ramâne atunci ca Element Atomic de descriere tupla :

( Nume Obiect , Proprietate Obiect, Valoare Obiect)

retinându-se pentru prelucrare doar ultimul eveniment semnificativ în timp .

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

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

§ aceleasi Proprietati

§ acelasi Nume Comun

§ aceleasi Relatii

Modele de Date 207

o Pornind de la o multime de asemenea Elemente Atomice, acestea sunt ad-hoc conectate între 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 între Entitati, Caracteristici si Valori, tratându-le în 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, defavorizându-le pe altele. Se prezinta în continuare însusirile si utilizarile specifice pentru fiecare model:

o Modelele Stricte - se preteaza pentru prelucrari de colectii de volum mare, care solicita un acces rapid, atât la nivel de entitate cât 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 4.2.1.1 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 înainte de precizarea oricarei proceduri de prelucrare si care urmareste în continuare urmatoarele obiective:

208 Modele de Date

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) Gs - Reguli de Specificare Structura Gr - Reguli de Specificare Restrictii

S - Schema de Descriere (Baza de Date Logica - BDL) Ss - Lista de Categorii, Proprietati, Relatii Sc - Lista de Restrictii

D - Realizare de BDL (Baza de Date Fizica) O - Operatii de Acces Admise – LMD (Limbaj de Manipulare a Datelor)

Ol - Lista Operatiilor Utilizate On - Operatii de Navigare Os - 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

M

O

Gr Gs

Sc Ol Ss

S

D

G

Os On

Model de Date

Baza de Date Logica

Baza de Date Fizica

Modele de Date 209

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

o Sa garanteze mentinerea în permanenta a unei Structuri de Date Deschise oricaror modificari, optimizari sau extensii cerute, fie datorita schimb arii conditiilor initiale de proiectare, fie datorita cerintelor de îmbunatatire 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 Îmbogatirea Semanticii atasate Structurilor de Informatii si Date prin încorporarea Operatiilor Compatibile cu Structurile Proiectate în corpul Modelului de Date

- Posibilitati sporite de Control a Structurilor Complexe

o Gruparea Obiectelor diverse (Structuri, Constrângeri, Reguli de Integritate, Restrictii, Operatii) în 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 îndeplinite daca se adauga un nou nivel de Definirea a Structurilor de Informatii si Date în forma unui produs specializat în constructia Modelelor de Date, care sa aiba în 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. 4.2.1.1.1 Descrierea Structurii

Descrierea Structurii contine declararea Proprietatile Principale (Statice), care se mentin Invariante în 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)

210 Modele de Date

• Specificarea Proprietatilor pentru Categorii (Atribute Descriptoare, Dependente între Atribute, Identificatori de Entitati)

§ Specificarea Relatiilor între Categorii (Proprietatile de Referire)– G s

Regulile de Specificare definite în cadrul Modelului de Date vor fi convertite în 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 Proces de Generare a Descrierii de Structura (Engineering).

4.2.1.1.2 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 în Structura se face prin intermediul unor Reguli de Specificare a Restrictiilor – G r, care vor fi convertite în Baza de Date Logica, asemenea Elementelor de Structura, în Liste de Restrictii Sc. Regulile de Specificare a Restrictiilor vin sa completeze semantica acordata datelor continute în structura, precizând conditiile pe care Valorile Datelor trebuie sa le respecte la încarcarea în Structura. Ca urmare Restrictiile retin Proprietati Auxiliare ale Datelor si anume Conditiile Logice impuse, ce descriu Cunostinte despre Structura . Se prezinta în continuare o clasificare a Categoriilor de Informatii pe care Restrictiile le adauga într-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, implicând acele Date, Dependente Functional de Date Reale si care se memoreaza în Baza de Date din motive de performanta la regasire, având însa nevoie de un Control Procedural al 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 cazând în 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 atât mai Restrictive , cu cât Restrictiile Implicite sunt mai multe, iar Restrictiile Explicite sunt mai putine.

Analizând natura Informatiilor aduse de Restrictii se poate remarca, în calitate de Caracteristici de Baza ale acestor Obiecte, faptul ca ele reprezinta în Modelul de Date simultan Restrictii Logice si totodata Reguli Generice – G r.

Modele de Date 211

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 în asigurarea Conditiilor de Validitate a continutului unei Baze de Date, Gradul lor de Îndeplinire masoara calitatea Bazei de Date. Gradul de Îndeplinire 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 C1 , .. , C n daca C i e satisfacuta când C 1 , .. , C n sunt satisfacute

• Redondanta - daca Ci e o consecventa logica a restrictiilor C1, .. , Cn

• Echivalenta - Ci, Cj sunt echivalente daca Ci si Cj 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

212 Modele de Informatii si Date

Entitati

Proprietati

Primare

Structura

Obiectelor

Relatii

Integritatea

Structurala

Integritatea Actualizarii

Obiectelor Primitive

Integritatea Actualizarii

Obiectelor Individuale

Proprietatile

Obiectelor

Proprietati

Secundare

Integritatea

Operationala

Generarea

Datelor Derivate

Tab. 4.2.1.1.2.1 Clasificarea Proprietatilor Obiectelor stocate într-un Model de Date

Modele de Date / Modelul Ierarhic 213

4.2.1.1.3 Descrierea Operatiilor

Transferul Operatiilor în 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 în 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 în Modelele de Date se face pe cai multiple, prin Biblioteci de Functii, Proceduri Stocate, Triggeri. O trecere în 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 în 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 în momentul apelului lor, a dat o rezolvare corecta a Dependentelor Functionale cauzatoare de inconsistenta în 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 în operarea la acest nivel

o Orientarea pe Evenimente a Operatiilor efectuate asupra Datelor sunt stimulate de concentrarea lor în jurul Modificarilor operate în Structura

o Prelucrarile Tranzactionale, indispensabile în contextul structurilor complexe prelucrate în regim de multiacces, cer o Viziune Globala asupra întregii colectii de Date

o Colectiile Mari de Date pretind tot mai multa Logica de Prelucrare (Business Logic) în asigurarea coerentei datelor memorate, ceea ce determina dezvoltarea unui nivel de Proceduri orientate catre Structura de Date si nu catre Aplicatie, care asteapta în 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 în 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 în cadrul Sistemelor de Aplicatii. Fiind grupate în Modelul Unic de Date sansa de a fi concepute Modular este foarte ridicata. Se spune ca Procedurile încorporate în Model vor fi mai degraba orientate catre Structurile de Date decât catre Aplicatii, cu un efect benefic asupra Controlabilitatii lor.

Operatii de Acces Admise – O vor da nastere în BD Logica, prin generare automata, la Listele de Operatii Ol (Fig. 4.2.1.1.1). Ultimul nivel din Figura va reprezenta Baza De Date Fizica (D), având atasate Listele finale de Proceduri Individualizate On si Os.

214 Modele de Date

4.2.2 Modelul Ierarhic

Modelul Ierarhic de organizare a datelor este primul model utilizat în construirea Structurilor de Date ce au stat la baza Sistemelor de Gestiune a Bazelor de Date (SGBD). Cu toate ca în prezent, din motive legate de resursele necesare pentru conversie (timp si bani), continua sa existe Sisteme cu Baze de Date ce utilizeaza structura de baza promovata de acest model, din punct de vedere teoretic modelul pastreaza doar o importanta istorica. La aceasta recunoastere istorica trebuie însa adaugata si utilitatea de evidentiere a traseului parcurs în perfectionarea metodelor de structurare a colectiilor de date, în vederea întelegerii sensului de dezvoltare a conceptelor din domeniu. Este sugestiv în special de urmarit începutul de drum spre câstigarea independentei componentelor de structura. Cunoasterea neajunsurilor acestui model este o buna cale de a învata cum se proiecteaza o structura sanatoasa.

4.2.2.1 Segmentul de Articol ca si Constructor de Structura

Modelul accepta mai multe Tipuri de Articole Fizice (ansambluri de câmpuri care se memoreaza în Baza de Date), denumite Segmente de Articole, care prin reasamblare pot construi Articolele Logice (ansambluri de câmpuri care se retin în memoria interna în scopul prelucrarii). Ca atare constructorul oricarei structuri de date în acest model este Segmentul, iar operatia de asamblare a structurilor este cea de concatenare secventiala, prin alaturarea în urma citirii secventiale a diferitelor tipuri de segmente pe baza unei Ierarhii prestabilite de Tipuri de Segmente. Intre caracteristicile acestei forme de reprezentare pe suport a structurilor de date mentionam:

- Implementarea unei prime forme de eliminare a redondantei prin extragerea câmpurilor de date comune altor segmente si gruparea lor într-un Segment Ascendent

- Construirea unei structuri de date de forma unui Arbore de Segmente, putându-se vorbi despre Segmente Ascendente si Segmente Descendente

- Exploatarea Structurii Secventiale a primilor suporti de memorare a datelor (benzi magnetice)

- Deducerea formei de reprezentare a Structurii Logice din organizarea pe suport a Structurii Fizice a datelor pe suport

- Asigurarea posibilitatilor de reprezentare doar a Structuri Fundamentale de tip 1-n (Structuri de tip Partitie)

- Reprezentarea fizica se efectueaza prin Traversarea structurii de tip Ierarhie (Arborescenta) în Preordine (Radacina – Subarbore Stâng – Subarbore Drept)

- Realizarea unei Structuri de Date Contextuale cu Context Unic reprezentat de drumul de la Radacina Arborelui pâna la nodul reprezentat de Segmentul Curent

Exemplu:

Ca exemplu se ofera transpunerea în Model de Date Ierarhic a reprezentarii structurii de informatii descrisa în sectiunea 3.4.4.

Modele de Date / Modelul Ierarhic 215

Fig. 4.2.2.1.1 Componentele Modelului Ierarhic

Vor fi utilizate doua Tipuri de Segmente (Fig. 4.2.2.1.1), care regrupeaza o multime de Câmpuri de Date (Fig. 4.2.2.1.2):

Fig. 4.2.2.1.2 Descrierea Segmentelor BENEFICIAR (B) si PRODUS (P)

Întrucât Segmentele reprezinta Elementele de Memorare pe suportul extern ele poarta numele si de Articole Fizice. Articolele Fizice, ce reprezinta Fragmente de Entitati, au în general nevoie de alte Articole Fizice (Segmentele Ascendente) pentru a descrie în întregime Entitatile implicate. Articolele Fizice Ascendente descriu contextual Articolelor Descendente.

PRODUS - P

Cod - Ci

Nume (Denumire) - Ni

Culoare - Ci

Pret - Vi

Stoc - Si

Cantitate - Qi

BENEFICIAR - B

Cod – Bi

Nume (Denumire) - Ni

Culoare - Ci

Oras -Oi

B1 N1 C1 O1

P1 N1 C1 V1 S1 Q1

P2 N2 C2 V2 S2 Q2

B2 N2 C2 O2

P1 N1 C1 V1 S1 Q3

P2 N2 C2 V2 S2 Q4

P3 N3 C3 V3 S3 Q5

. . . .

. . . . . .

Beneficiarul 1

Produsul 1 contractat de Beneficiarul 1

Produsul 2 contractat de Beneficiarul 1

Produsul 3 contractat de Beneficiarul 2

Beneficiarul 2

Produsul 1 contractat de Beneficiarul 2

Produsul 2 contractat de Beneficiarul 2

Memorie externa

B1 N1 C1 O1 P1 N1 C1 V1 S1 Q1

Segment tip 1

Segment tip 1

Segment tip 2

Segment tip 2

Segment tip 2

Segment tip 1

Segment tip 2

Segment tip 2

Segment tip 2

Articol Logic Produsul 1 contractat de Beneficiarul 1 Memorie interna

216 Modele de Date

Limbajul de manipulare a datelor îsi manifesta caracteristica specifica în special prin modul de inspectie a Structurii de Segmente pentru reconstituirea Structurii Articolului Logic, elementul de prelucrare a datelor. Operatiile de citire segmente sunt:

- GET UNIQUE – Regasire Articol Fizic (Segment) cautat, împreuna cu Contextul atasat (Multimea de Segmente Ascendente)

- GET NEXT – Citire Articol Fizic urmator punctului în care se afla prelucrarea Operatiile de actualizare, Adaugare si Stergere sunt însotite în general de rescrierea Secventei de Segmente pe suport. Formalismul grafic de reprezentare, prezentat în sectiunea 3.4.3.3 pentru Modelul Relational, sub numele de Arbore de Structura , poate fi usor adaptat la Modelul Ierarhic. In Fig. 4.2.2.1.3 se foloseste o asemenea reprezentare.

Fig. 4.2.2.1.3 Arborele de Structura pentru Modelului Ierarhic 4.2.2.2 Avantajele si Dezavantajele Modelului Ierarhic In concluzie se prezinta urmatoarele avantaje si dezavantaje ale Modelului Ierarhic: Avantaje:

- Model simplu si natural de reprezentare a Relatiei Fundamentale Ierarhie (1–n)

- Posibilitatea de utilizare si a suportilor secventiali de memorare a datelor (benzi magnetice), in calitate de suporti neadresabili

Dezavantaje:

- Modelarea Structurilor m-n doar prin Structuri 1-n, cu repetarea descendentilor partajati de mai multi ascendenti, implica redondanta si prin aceasta inconsistenta, greu de controlat procedural (Exemplu: Modificarea Culorii unui Produs implica actualizarea acestuia în contextul tuturor Beneficiarilor care au contractat acest Produs – vezi Fig. 4.2.2.1.1)

- Accesul la date trebuie efectuat întotdeauna pe linia Contextului Unic implicat de structura de tip Arbore

- Încercarea de modificare a Strategiei de Acces la Segmente, prin atasarea Structurilor de tip Index, face ca Indecsii sa participe la construirea Structurii Principale de Date

B

P

* c

• n •

t

• o

* c

• n

• l

• v

• q

Modele de Date / Modelul Retea 217

4.2.3 Modelul Retea

Acest Model de Baza de Date a fost propus si fundamentat de grupul de lucru pentru standardizare Data Base Task Group (DBTG). Ca si Modelul Ierarhic, Modelul Retea urmareste sa gaseasca un Constructor de Structura care sa permita reprezentarea unei Structuri de Baza (în speta Structura Fundamentala m – n), cu ajutorul careia sa poata fi apoi construite cât mai multe Structuri reale, complexe de date. Structurile care le realizeaza ambele Modele ramân însa statice în timp, reconfigurarea lor implicând consumuri mari de resurse. 4.2.3.1 Setul de Articole ca si Constructor de Structura

Modelul Retea a aparut ca o solutie de rezolvare a impasurilor ridicate de reprezentarea Structurilor Fundamentale de tip m-n. Rezolvarea Contextelor Multiple de aparitie a aceluiasi Articol de Date a fost gasita în utilizarea Listelor de Articole denumite Seturi de Articole. Ca urmare, constructorul Modelului Retea este Setul de Articole. El este definit prin:

- Posesorul Listei (Capul Listei sau Header) implementat ca o Referinta de Adresa la Primul Articol din Lista (vezi Referintele de Adresa rc din Articolele BENEFICIARI si PRODUSE - Fig. 4.2.3.1.1); Posesorul Listei nu face parte din Lista de Articole, ci doar o refera.

- Membrii Listei reprezentati de Articolele de Date înlantuite prin Referintele de Adresa care construiesc Lista (vezi Referintele de Adresa rc din Articolele POZITII CONTRACTUALE - Fig. 4.2.3.1.1)

In Fig. 4.2.3.1.1 este redata Structura Fizica de Date utilizata de modelul Retea. Se remarca elementele de baza ale structurii si anume Articolele Principale si de Legatura :

- Articolele Principale contin datele care identifica si descriu Articolele Principale împreuna cu referintele de adresa la Seturile de Articole pe care le refera

§ BENEFICIAR

• Identificator – Codul Beneficiarului (Bi)

• Descriptori – Nume, Cont, Oras (Ni, Ci, Oi)

• Referinta de Adresa la Setul de Produse Contractate (rci)

§ PRODUS

• Identificator – Codul Produsului (Pj)

• Descriptori – Denumire, Culoare, Pret, Stoc (Nj, Cj, Vj, Sj)

• Referinta de Adresa la Setul de Beneficiari Contractanti (rcj)

- Articolele de Legatura contin datele care identifica si descriu Articolele de Legatura împreuna cu referintele de adresa la Capetele de Lista precum si la celelalte Articole de Legatura din acelasi Set de Articole

§ POZITIE CONTRACTUALA

• Identificator – Codul Beneficiarului+Codul Produsului accesate prin Referinte de Adresa (rbk si rpk)

218 Modele de Date / Modelul Retea

Fig. 4.2.3.1.1 Componentele Modelului Retea

Pozitii Contractualeale unui Produs

B1 N1 C1 O1

B2 N2 C2 O2

P1 N1 C1 V1 S1

P2 N2 C2 V2 S2

P3 N3 C3 V3 S3

. . . .

. . . . .

Beneficiar

Produs

rc i – referinta de adresa la o Pozitie Contractuala i

rb j – referinta de adresa la un Beneficiar j

rp k – referinta de adresa la un Produs k

Memorie externa

PRODUSE

rc 2 rb 1 Q1 rp 1

- rb 1 Q2 rp 2

rc 4 rb 2 Q3 rp 1

rc 5 rb 2 Q4 rp 2

- rb 2 Q5 rp 3

. . . .

rc 1

rc 3

.

rc 1

rc 2

rc 5

.

rc 3

rc 4

-

-

-

.

BENEFICIARI

POZITII CONTRACTUALE

Pozitie Contractuala

B1 N1 C1 O1 rc 1

rc 2 rb 1 Q1 rp 1 rc 3

P1 N1 C1 V1 S1 rc 1

Beneficiarul unei Pozitii Contractuale

Pozitii Contractuale ale unui Beneficiar

Produsul unei Pozitii Contractuale

Memorie interna

Modele de Date / Modelul Retea 219

• Descriptori – Cantitate Contractata (Qk)

• Referinte de Adresa la:

• Posesorul 1 al Articolului Membru Beneficiarul Contractant (rbk)

• Posesorul 2 al Articolului Membru Produsul Contractat (rpk)

• Articolul Membru urmator în Lista de Pozitii Contractate (rck)

Constructorul Set de Articole este o notiune echivalenta cu Ansamblul de Realizari din Spatiul de Informatii. Setul de Articole se defineste:

- In plan Logic – prin Numele Setului construit din Numele Posesorului alaturat printr-o Relatie cu Numele Membrilor (Exemplu: Produsele contractate de un Beneficiar)

- In plan Fizic – prin instanta (realizarea) Articolul Posesor si instantele (realizarile) Articolelor Membri

Setul este descris asadar:

- Prin Tipul Setului – defineste Setul Logic

- Prin Instanta Setului (Multimea Membrilor) – defineste Setul Fizic In structura fizica din Fig. 4.2.3.1.1 sunt înregistrate doua categorii de informatii:

o Valorile Caracteristicilor Simple – ansamblul Insusirilor Descriptoare ale Claselor de Entitati

o Referintele de Adresa (Pointeri) – descriu legaturile între Clasele de entitati si sunt ca urmare denumite Caracteristici de Structura

Pentru a întelege cum se utilizeaza structura fizica prezentata în Fig. 4.2.3.1.1 se prezinta în continuare Strategia de Acces la date prin Navigarea în structura cu exploatarea Referintelor de Adresa.

o Reconstituirea Ierarhiei Simple (Produsele contractate de un Beneficiar)

§ Se localizeaza un Beneficiar

§ Se inspecteaza Setul de Articole Produsele contractate de un Beneficiar pornind din referinta de adresa (rci din Beneficiar), memorata în Posesorul Setului (Beneficiarul localizat)

§ Pentru fiecare Articol de Legatura din Lista de Articole începând cu rci din Beneficiar se citeste Produsul punctat de Referinta de Adresa rpk din Pozitia Contractuala în curs de prelucrare

o Reconstituirea Ierarhiei Inverse (Beneficiarii care au contractat un Produs)

§ Se localizeaza un Produs

§ Se inspecteaza Setul de Articole Beneficiari care au contractat un Produs pornind din referinta de adresa (rci din Produs), memorata în Posesorul Setului (Produsul localizat)

220 Modele de Date / Modelul Retea

§ Pentru fiecare Articol de Legatura din Lista de Articole începând cu rci din Produs se citeste Beneficiarul punctat de Referinta de Adresa rbj din Pozitia Contractuala în curs de prelucrare

Fig. 4.2.3.1.2 Relatia Fundamentala între BENEFICIAR si PRODUS

Se poate remarca cu usurinta modul în care se reprezinta în structura fizica de date Relatia Fundamentala m-n descrisa în Spatiul Informatiilor (Fig. 4.2.3.1.2), precum si dubla relatie 1-n care implementeaza relatia m-n în Spatiul Datelor (Fig. 4.2.3.1.3).

Se prezinta si pentru Modelul Retea o reprezentare grafica folosind Arborele de Structura (vezi Fig. 4.2.3.1.4). Fata de Modelul Relational în noua reprezentare cu linie punctata este reprezentata legatura Posesor – Membri, descrisa de Listele de Articole care apar în Modelul Retea. Conventia pe care am adoptat-o este ca sageata sa fie orientata de la Posesor catre Membri. In aceasta reprezentare se vede clar cum Articolul de Legatura POZITIE-CONTRACT se afla înregistrat în doua Liste de Articole:

- POZITIILE–CONTRACTUALE ale unui BENEFICIAR (Legatura B.c → C.b)

- POZITIILE–CONTRACTUALE ale unui PRODUS (Legatura P.c → C.p)

Fig. 4.2.3.1.3 Diagrama Simbolica B-P-C

BENEFICIAR

POZITIE CONTRACTUALA

1

n

PRODUS

1

n

Produsele contractate de un Beneficiar

Beneficiarii care au contractat un Produs

BENEFICIAR

PRODUS

m

n

Produsele contractate de un Beneficiar

Beneficiarii care au contractat un Produs

Modele de Date / Modelul Retea 221

Ca si în cazul precedentului model, Limbajul de manipulare a datelor îsi manifesta si în acest caz caracteristica specifica în special prin modul de exploatare a Referintelor de Adresa memorate în structura:

- FIND – localizare Articol Fizic si actualizarea Indicatorului de Articol Curent

- GET – încarcare Articol Fizic Curent

Operatiile de actualizare, Adaugare si Stergere sunt însotite în general de executia procedurilor de actualizare a Listelor de Articole.

Fig. 4.2.3.1.2 Relatia Fundamentala între BENEFICIAR si PRODUS

Pentru fixarea particularitatilor la care apeleaza Modelul Retea pentru construirea Structurilor de Date de tip m – n, dam în continuare reprezentarea în acest model a unui Arbore Invers în forma cea mai generala de Graf (structura tipica de Retea în varianta Recursiva),. In Fig. 4.2.3.1.3 este redata Reprezentarea Fizica, pentru ca apoi sa poata fi urmarita transformarea ei în Reprezentare Simbolica (Fig. 4.2.3.1.4).

Fig. 4.2.3.1.3 Arbore Invers în Reprezentare Fizica

Descrierea concentrata a Structurii de Date într-un LDD conventional este continuta în Fig. 4.2.3.1.4. Se marcheaza doar prezenta Articolului Principal (Nod), a Articolului de Legatura (Arc), precum si a caracteristicilor de tip Set de Articole (Arce în Intrare si Arce în Iesire).

P

* c

• n

• l

• v

B

* c •

n • t

• o

C

* b

• q *

p

1

2 3

4 5 6

8 7

222 Modele de Date / Modelul Retea

Fig. 4.2.3.1.4 Arbore Invers în Reprezentare Simbolica

Figurile 4.2.3.1.5 si 4.2.3.1.5 redau implementarea structurii în Plan Fizic (al Valorilor). Nod BEGIN Identificator Descriptor 1 Descriptor 2 .. Arce-în-Intrare Set de Articole Arce-în-Iesire Set de Articole END Arc BEGIN Nod Ascendent Nod Descendent Descriptor 1 .. END

Fig. 4.2.3.1.4 Arbore Invers în Reprezentare Simbolica

4.2.3.2 Avantajele si Dezavantajele Modelului Retea

In concluzie se prezinta urmatoarele avantaje si dezavantaje ale Modelului Retea: Avantaje:

- Eliminarea dificultatilor de actualizare specifice secventei de Segmente, prin posibilitatea de actualizare independenta a Articolelor Principale (Clasele de Entitati) si a Articolelor de Legatura (Relatiile între Clasele de Entitati)

- Eliminarea redondantei în cazul reprezentarii structurilor m-n Dezavantaje:

- Legatura prea strânsa a descrierii Logice de reprezentarea Fizica pe suport prin prezenta structurii de Lista de Articole în Schema de Descriere

- Dependenta reprezentarii fizice de suportul de memorare prin intermediul Referintelor de Adresa

- Actualizare dificila a Listelor de Articole dependente de Referintele de Adresa

1 n

1 n

NOD

ARC

Arce în Iesire

Arce în Intrare

Modele de Date 223

Fig. 4.2.3.1.4 Descrierea Nodurilor ca Articole Principale

Fig. 4.2.3.1.4 Descrierea Arcelor ca Articole de Legatura

NOD Caracteristici

Nume Identificator Descriptor1 Descriptor2 Primul Arc în Intrare

Primul Arc în Iesire

Nod 1 1 D11 D21 .. NULL Arc 12 Nod 2 2 D12 D22 .. Arc 12 Arc 24 Nod 3 3 D13 D23 .. Arc 13 Arc 35 Nod 4 4 D14 D24 .. Arc 24 NULL Nod 5 5 D15 D25 .. Arc 25 Arc 57 Nod 6 6 D16 D26 .. Arc 36 NULL Nod 7 7 D17 D27 .. Arc 57 NULL Nod 8 8 D18 D28 .. Arc 58 NULL

Nodk

Nodi

Nodj

ARC Caracteristici

Identificator

Nume Nod

Ascendent Nod

Descendent

Descriptor1 (Intensitate de Legatura)

Arc Succesor în Intrare

Arc Succesor în Iesire

Arc 12 1 2 D12 .. NULL Arc 13 Arc 13 1 3 D22 .. NULL NULL Arc 24 2 4 D23 .. NULL Arc 25 Arc 25 2 5 D24 .. Arc 35 Arc 35 Arc 35 3 5 D25 .. NULL Arc 36 Arc 36 3 6 D26 .. NULL NULL Arc 57 5 7 D27 .. NULL Arc 58 Arc 58 5 8 D28 .. NULL NULL

224 Modele de Date / Modelul Relational / Relatia ca si Constructor de Structura

4.2.4 Modelul Relational

Promovat de cercetatorul Codd, prin articolele aparute la începutul anilor 1970 [CODD70], [CODD71], Modelul Relational se bazeaza pe Teoria Matematica a Relatiilor (vezi sectiunea 3.1.2), ceea ce îi confera consistenta, prin fundamentarea teoretica a tuturor conceptelor. Ceea ce trebuie mai ales retinut pentru viitorul descrierii Structurilor de Date este Elementaritatea acestui model, înteles prin aceea ca nu exista metode mai simple si mai complete de descriere a oricaror structuri.

Modelele de SGBD-uri anterioare erau preocupate de reprezentarea unor Structuri Fundamentale (Modelul Ierarhic – Structura 1 - n, Modelul Retea – Structura m -n). Se considera atunci ca modelul care poate reprezenta Structura Fundamentala cea mai generala va fi si cel preferat în descrierea oricarei structuri. Se neglija caracteristica dinamica a structurii, data de evolutia ei inevitabila în timp.

Modelul Relational schimba obiectivul constructiv al modelelor precedente, orientându-l spre construirea Structurilor Elementare, care vor permite apoi configurarea oricarui tip de Structura de Date, diferita de la un moment la altul. Elementele de Baza pentru construirea structurilor sunt: Clasele de Entitati si Legatura între Clasele de Entitati. Pentru ambele elemente poate fi folosit acelasi Constructor si anume Relatia. Aceasta unicitate de reprezentare a Elementelor de Baza reprezinta descoperirea esentiala a Modelului Relational, care ofera pentru prima data robustete si dinamism Structurilor de Date prin aceea ca, având la dispozitie Modulele de Baza (Caramizile) constructia dorita poate fi în orice moment construita si reconstruita dupa preferinta utilizatorului, fara a necesita dezasamblare si reasamblare (vezi facilitatile oferite de conceptul de Vedere din Nivelul Extern al Modelului Relational). De aceea orice dezvoltare a acestui model trebuie conceputa ca un alt nivel de descriere care poate oferi alte viziuni cerute de utilizatori asupra datelor, dar care trebuie sa pastreze la baza forma elementara de descriere (Modelul Relational).

Pentru evidentierea avantajelor enuntate mai sus se vor folosi în continuare mai multe forme de prezentare ale acestui Model de Date, de la cele intuitive spre cele formalizate. Se începe cu o prezentare simplificata, care sa ofere la acest nivel posibilitatea unei comparatii directe cu celelalte modele descrise în sectiunile precedente si care are totodata scopul de a trasa directia de evolutie în perfectionarea metodelor de reprezentare a structurilor.

4.2.4.1 Relatia ca si Constructor de Structura

Constructorul de Structura în Modelul Relational este Relatia, conform definitiei preluate din matematica (vezi sectiunea 3.1). Notiuni ca Domeniu, Tupla, Relatie se vor regasi implementate direct în mediul Structurilor de Informatii si Date. Vorbind despre Structurile de Date specifice Modelului Relational putem face urmatoarele asocieri:

o Domeniul– este reprezentat de Multimea Valorilor pe care le poate lua o anumita Însusire (Caracteristica) a unei Entitati în Colectia de Date

• D i ≡ Codul Beneficiarului ≡ 101, 102, 103, 104, ..

• D i+1 ≡ Culoarea Produsului ≡ alb, rosu, negru, ..

• D i+2 ≡ Cantitatea Contractata ≡ 10, 20, 100, ..

Modele de Date / Modelul Relational / Relatia ca si Constructor de Structura 225

o Tupla

§ Logica – o Multime Ordonata de Atribute (Însusiri) extrase din Multimea Insusirilor definite în Colectia de Date si care descrie o anumita Entitate

• T j ≡ BENEFICIAR (Cod, Nume, Companie, Cont) – Beneficiarul are un Cod, un Nume, o Companie si un Cont

§ Fizica – o Multime Ordonata de Valori extrase din Domenii care descriu o Legatura (Relatie) confirmata de realitate ca un fapt

• T jk ≡ Beneficiarul k ≡ 101, Compania X, 11123, Oras Y – exista un Beneficiar cu urmatoarele Valori de Caracteristici: Codul ≡ 101; Numele ≡ Compania X; Contul ≡ 11123

- Relatia – este o Submultime a Produsului Cartezian a mai multor Domenii, reprezentate ca o Multime de Tuple

o BENEFICIAR ⊆ Cod Beneficiar x Nume Beneficiar x Cont Beneficiar x Oras Resedinta Beneficiar

Sau:

BENEFICIAR ≡ T j pentru ∀ j ∈ 1 .. b, unde b e Numarul de Beneficiari memorati în Baza de Date

Se regaseste asadar definitia cunoscuta:

“Fiind data o multime i de Domenii Di, nevide, dar nu neaparat distincte, o Relatie R este o Multime de Tuple privite fiecare ca multimi ordonate de Valori (v1 , v2 .. vi), astfel încât vj ∈ D j pentru ∀ j∈ 1 .. i. Elementele multimii R se numesc Tuple (sau n-Tuple), iar Gradul Relatiei e dat de i.”

Domeniile pe care e definita o Relatie reapar ca si Atribute descriptoare ale Relatiei. Distinctia între Domeniu si Atribut provine din faptul ca Domeniile pe care este definita o Relatie nu trebuie sa fie neaparat distincte (vezi relatia ANSAMBLU din Fig. 4.2.4.3), în timp ce Atributele Relatiei trebuie sa respecte conditia de unicitate ca Nume.

Spatiul Informatiilor Modelul Relational Spatiul Datelor

Notiune Definita

(Tabela de Baza)

Definit Clasa de

Entitati

Obiecte

Relatie

Instantiata

(Vedere)

Fisier

Omogen

Memorat

Notiune Logica Logic Entitate

Obiect

Tupla

Fizica

Articol

Fizic

Domeniu Tip Nume

Atribut Nume

Caracteristica

Valoare Valoare

Data

Valoare

Tab. 4.2.4.1 Comparatie de termeni – SI / MR / SD

226 Modele de Date / Modelul Relational / Relatia ca si Constructor de Structura

O Relatie poate fi reprezentata foarte sugestiv printr-un Tabel datorita corespondentei ce poate fi facuta între Coloanele Tabelei si Atributele Relatiei pe de o parte si Rândurile Tabelei si Tuplele Relatiei pe de alta parte. Exemplu:

Sa reluam exemplul din Fig. 2.4.2, COMPUS – COMPONENT dându-i o reprezentare relationala. Pentru început se definesc Domeniile (Fig. 4.2.4.2), pe care se vor construi Relatiile PRODUS (Fig. 4.2.4.3), ca o Clasa de Entitati si ANSAMBLU (Fig. 4.2.4.4) ca o Legatura între Clasa de Entitati PRODUS, vazuta ca si COMPUS si ca si COMPONENT.

DOMENIU ATRIBUT Nume Valori Relatie Nume

PRODUS Cod ANSAMBLU Cod-Compus

Cod

A, B, C, D, E, F

ANSAMBLU Cod-Component Nume N1, N2, N3, N4, N5, N6 PRODUS Nume

Culoare C1, C2, C3 PRODUS Culoare Greutate G1, G2, G3, G4 PRODUS Greutate

Tab. 4.2.4.2 Domeniile Structurii Relationale COMPUS – COMPONENT

PRODUS

COD* NUME CULOARE GREUTATE A N1 C1 G1 B N2 C2 G2 C N3 C3 G2 D N4 C1 G3 E N5 C3 G4 F N6 C1 G1

Tab. 4.2.4.3 Relatia PRODUS

ANSAMBLU

COD-COMPUS* COD-COMPONENT* CANTITATE A B Q1 B C Q2 B D Q3 B E Q4 C F Q5 C E Q6

Tab. 4.2.4.4 Relatia ANSAMBLU

Datele reprezentate extensional în figurile mentionate sunt apoi descrise intensional cu ajutorul unui Limbaj de Descriere a Datelor (LDD). Redam mai jos Schema de Descriere a Modelului de Date Relational PRODUS – ANSAMBLU (Fig. 4.2.4.3). Arborele de Structura din Fig. 4.2.4.6 concentreaza caracteristicile Modelului Relational.

Modele de Date / Modelul Relational / Relatia ca si Constructor de Structura 227

DOMAIN Cod CHARACTER 8 DOMAIN Nume CHARACTER 20 DOMAIN Culoare CHARACTER 6 DOMAIN Greutate NUMERIC 4 DOMAIN Cantitate NUMERIC 10 RELATION Produs (Cod, Nume, Culoare, Greutate) KEY (Cod) RELATION Ansamblu (Cod-Compus DOMAIN Cod, Cod-Component DOMAIN Cod, Cantitate) KEY (Cod-Compus, Cod-Component )

Fig. 4.2.4.5 Schema de Descriere a structurii PRODUS - ANSAMBLU

Legat de Elementele unei Structuri Relationale de Date se pot face urmatoarele observatii:

- Domeniul descrie natura unei Multimi de Valori (Nume, Tip, Restrictii impuse)

- Relatia se descrie ca o Multime de Atribute provenite din Domenii anterior definite

Fig. 4.2.4.6 Arbore de Structura PRODUS – ANSAMBLU

- Relatiile pot fi categorisite în:

o Relatii ce stabilesc doar legatura între Domenii (ex. PRODUS)

o Relatii ce stabilesc, prin intermediul Domeniilor, o legatura între alte Relatii (ex. ANSAMBLU)

- Definirea Domeniilor poate fi si este adesea evitata, prin transferarea Descrierii Domeniilor în Descrierea Atributelor din Relatii

- Rolul definirii Domeniilor este însa mai larg decât simpla economie de declarare a Tipurilor si Restrictiilor atasate Atributelor; el se extinde asupra definirii, înca din aceasta faza incipienta, a Legaturilor Structurale între Date prin recunoasterea Domeniilor Comune ale Atributelor, care vor realiza Cuplarea Tabelelor prin operatia de Reunire (JOIN), operatie ce în viitor va putea sa fie automat invocata pe baza cunoasterii Domeniilor Comune

q

* • • •

P

* c

n cl

g

AN

* cs

cp •

P-PRODUS AN-ANSAMBLU c-cod n-nume cl-culoare g-greutate cs-cod-compus cp-cod-component q-cantitate

228 Modele de Date / Modelul Relational / Proprietatile Relatiei

Definitie:

Baza de Date Relationala – O colectie de Relatii Normalizate, de diverse grade, variabile în timp ca si continut [DATE95].

4.2.4.2 Proprietatile Relatiei

Cercetatorul Codd [CODD70] este cel care defineste si acele proprietati fundamentale pe care Constructorul Modelului Relational trebuie sa le îndeplineasca pentru a respecta definirea teoretica a Relatiei ca Multime . Aceste Proprietati referitoare la o Relatie sunt:

o Nici o Tupla nu e identica cu alta Tupla Fiecare Tupla a unei Relatii, în calitate de Element al unei Multimi , trebuie sa fie Unica (vezi sectiunea 5.2.4.4). Aceasta proprietate va permite în continuare, la Manipularea Structurilor Relationale, sa se preia cu usurinta operatorii din Teoria Multimilor (Reuniune, Intersectie, Diferenta, Produs Cartezian – vezi sectiunea 4.2.4.5.1.2).

o Ordinea Tuplelor e indiferenta Relatia respecta conditia de Multime prin care proprietatea de Echivalenta între Elemente (Tuple) implica absenta oricarui privilegiu (inclusiv cel al Ordinii). Ca urmare Ordinea Tuplelor va fi introdusa, la fel ca în modelul matematic, cu ajutorul unei Relatii de Ordine auxiliara (reprezentata de Tabela de Index curenta), care se ataseaza Multimii Tuplelor pentru a o transforma într-o Multime Ordonata.

o Ordinea Domeniilor e indiferenta Definirea Relatiei ramâne aceeasi indiferent de Ordinea Domeniilor. Trebuie însa remarcat ca, odata Relatia definita, Ordinea Domeniilor trebuie mentinuta pe toata durata de viata a Relatiei, pentru a se putea reface în orice moment corespondenta Atribut – Domeniu. Sistemele de Gestiune, care permit la un moment dat schimbarea Ordinii Domeniilor, efectueaza o operatie automata de recopiere a vechii Relatii (Tabele de Baza) într-una noua, cu stergerea (sau arhivarea) în final a celei vechi.

o Toate Atributele sunt Date Elementare (Nedecompozabile) Prin aceasta restrictie, care cere ca, în Tabelele de Baza , Câmpurile de Date sa fie de tip Scalar si nu de tip Multime, impune mentinerea Relatiei ca Unic Constructor de Structura . O Relatie care îndeplineste aceasta restrictie se zice Relatie Minim Normalizata (cu grad minim de normalizare – vezi sectiunea 5.3.1). Exemplu: Structura de mai jos, în ciuda reprezentarii ei tabelare nu este o structura acceptata de Modelul Relational, întrucât contine Date Decompozabile (vezi atributul Obligatie, care are ca descendenti atributele Produs si Cantitate. Structura se considera Nenormalizata.

Modele de Date / Modelul Relational / Proprietatile Relatiei 229

CONTRACT

Obligatie Beneficiar Produs Cantitate

B1 P1 Q1 B1 P2 Q2 B1 P3 Q3 B1 P4 Q2 B1 P5 Q4 B2 P1 Q5 B2 P2 Q1 B3 P2 Q3 B4 P5 Q6

Tab. 4.2.4.2.1 Structura Nenormalizata

Eliminarea Nenormalizarii se face simplu prin eliminarea Structurii Ierarhice din cadrul Tabelei prin eliminarea atributului compus Obligatie (vezi structura din Fig.4.2.4.2.2).

CONTRACT

Beneficiar Produs Cantitate B1 P1 Q1 B1 P2 Q2 B1 P3 Q3 B1 P4 Q2 B1 P5 Q4 B2 P1 Q5 B2 P2 Q1 B3 P2 Q3 B4 P5 Q6

Tab. 4.2.4.2.2 Structura Normalizata

Se cere aici mentionat faptul ca o diversitate de implementari ale Modelului Relational au profitat cu succes de licente bazate pe abateri de la restrictiile prezentate anterior. Toate aceste succese momentane nu trebuiesc însa privite decât ca adaptari ingenioase la stadiul momentan de evolutie a puterii de calcul. Evolutiile ulterioare au dovedit însa valabilitatea acestor restrictii în mediile de procesare adaptate unor abordari avansate în ceea ce priveste încorporarea sporita de semantica în Modelele de Date.

Ne exprimam totodata rezervele legate de orice implementare la nivel intern a Modelelor Relationale Extinse, care încalca restrictiile precedente si prin aceasta se abat de la Elementaritatea Modelului. Revenirea la Modelul Relational de Baza se va face oricând puterea de calcul creste suficient pentru a putea oferi performante adecvate de implementare a Motorului Relational. Extinderea ceruta de utilizari specifice va putea fi însa realizata la un nivel superior de implementare a structurilor dorite, care sa se sprijine însa în interior pe un Model Consistent de Date (vezi si sectiunea 6.3).

230 Modele de Date / Modelul Relational / Proprietatile Relatiei

4.2.4.3 Intensiunea si Extensiunea Relatiilor

Relatiile, fiind Multimi definite pe Produsul Cartezian al Domeniilor, preiau de la Multimi descrierea Intensionala si Extensionala. Notiunile sunt deosebit de utile în definirea Planurilor Logice si Fizice de descriere a Structurilor Relationale. In primul plan vom întâlni Schemele de Relatii descrise prin precizarea Tuplelor Logice (vezi Fig. 4.2.4.2). In cel de al doilea plan vom regasi ansamblul Tuplelor Fizice, care descriu partea variabila în timp a relatiilor (vezi tabelele 4.2.4.3 si 4.2.4.4).

Intensiunea Relatiei – este reprezentata de Ansamblul Caracteristicilor care descriu Relatia ca Multime , definita prin Enuntarea de Proprietati. Intensiunea Relatiei reprezinta partea constanta în timp a relatiei. Ea contine Descrierea Logica, prin Nume, Tipuri si Conditii a Proprietatilor Generale ale Structurii de Date, proprietati care vor controla si vor valida actualizarea Structurii Fizice cu Instante.

Intensiunea Relatiei contine urmatoarele elemente:

o Denumirea Structurii

§ Numele Domeniilor

§ Numele Relatiei

§ Numele Atributele (cu Domeniile asociate)

o Restrictiile de Integritate

§ Restrictii de Identificare

• Declarare Chei Candidate

o Cheia Primara

o Chei Candidate (Alternative)

• Declarare Proceduri de Verificare a Unicitatii

§ Restrictii de Referire

• Declarare Chei Straine

• Declarare Conditii de Validare a Referirii (vezi sectiunea 3.4.5)

§ Alte Restrictii

• Declarare Conditii de Validare a Valorilor

o De Corectitudine (tipuri, limite, liste de valori etc.)

o De Compaibilitate (conditii de corelare a valorilor diferitelor Atribute, din aceeasi Tupla sau din Tuple diferite)

Extensiunea Relatiei – este reprezentata de Ansamblul Valorilor care descriu Relatia ca Multime definita prin Enumerarea de Elemente (tuple). Extensiunea Relatiei reprezinta partea variabila în timp a relatiei. Ea contine Descrierea Fizica, prin Instante (Valori) a Structurii de Date, fiind foarte utila pentru extragerea acelor Proprietati Particulare ce vor putea fi sintetizate în Proprietati Generale pentru a fi încorporate în Descrierea Logica.

Modele de Date / Modelul Relational / Reguli de Integritate a Relatiilor 231

4.2.4.4 Cheile Relatiilor

Cheile Relatiilor sunt Atribute Speciale ale Relatiilor, care joaca un rol aparte în Identificarea, Accesul si Ordonarea Tuplelor componente ale Relatiilor. Functia lor principala este cea de Identificare, subdivizata în:

- Identificare Propriuzisa – Chei Primare, Chei Candidate (Alternative)

- Referire – Chei Straine

In Tab. 4.2.4.4.1 se da o clasificare a Cheilor care pot apare în Relatii.

Tip Cheie

Redondanta - Compusa m Atribute Componente

Simpla 1 Atribut Component 1 Cheie Candidata

Compusa m Atribute Componente

Simple 1 Atribut Component

Proprie

Neredondanta n Chei Candidate

- 1 Cheie Primara

- n-1 Chei Candidate Compuse m Atribute Componente

Simpla 1 Atribut Component Straina -

Compusa m Atribute Componente

Tab. 4.2.4.4.1 Tipuri de Chei

Definitii:

Domeniu Primar – Domeniul pe care este definit cel putin un Atribut Constituent al unei Chei Primare.

Cheie Proprie – Multime de Atribute ce constituie Identificatorul unei Relatii (nu exista doua Tuple cu aceeasi combinatie de Valori pentru aceste Atribute).

Constituent de Cheie – Atribut participant într-o Cheie si care mai poarta numele de Atribut Primar.

Cheie Straina – Multime de Atribute din cadrul unei Relatii, care constituie Identificatorul (Cheia Primara) a altei Relatii.

Cheie Redondanta - Multime de Atribute care ramâne Cheie prin excluderea unei submultimi de Atribute Constituenti de Cheie.

Cheie Neredondanta - Multime de Atribute din care nu poate fi exclus nici-un Atribut astfel ca ea sa ramâna Cheie.

Cheie Candidata (Alternativa) – fiecare Cheie Neredondanta a unei Relatii.

Cheie Primara – orice Cheie Candidata aleasa de utilizator (din motive subiective – simplitate, obisnuinta, preferinta etc.) ca Identificator Privilegiat.

Cheie Surogata (Interna) – o Cheie Primara generata automat de Sistem.

232 Modele de Date / Modelul Relational / Cheile Relatiilor

4.2.4.4.1 Reguli de Integritate a Relatiilor

Având în vedere Elementaritatea Structurilor memorate într-o Baza de Date Relationala, apare în mod firesc necesitatea verificarii consistentei lor pentru a putea garanta ca structurile care vor fi construite pe baza elementelor atomice stocate vor fi corecte. Asigurarea acestei proprietati se face prin adaugarea la Elementele de Structura a Conditiilor de Validitate, impuse de semantica atasata structurii. Aceste conditii iau forma Regulilor de Integritate care sunt memorate în Baza de Date.

Exista doua categorii principale de Reguli de Integritate:

o Integritatea de Identificare (Entitatii) – Fiecare Entitate trebuie sa aiba o Cheie Primara în care nici-un Constituent nu poate fi nedefinit, pentru pastrarea posibilitatilor ca fiecare Identificator sa corespunda unei Entitati (de aici si cealalta denumire a Restrictiei – Integritatea Entitatii).

o Integritatea de Referire – Cheia Straina poate fi nedefinita, dar atunci când ea e definita, Valoarea ei trebuie sa faca parte din Ansamblul Valorilor memorate în Cheia Primara pe care Cheia Straina o refera.

4.2.4.4.2 Identificare, Acces si Ordonare în Structuri Relationale

Identificarea, Accesul si Ordonarea în Structurile Relationale se realizeaza cu ajutorul Cheilor. Asa dupa cum s-a aratat deja, prin Cheie se întelege orice Combinatie de Atribute ale unei Relatii care îndeplineste o functie specializata de tratare a Tuplelor (de exemplu, identificare, acces, ordonare).

In prelucrarea datelor Cheile sunt în mod eronat asimilate cu Tabelele de Index, prescurtat, cu Indecsii, care reprezinta Structuri Secundare atasate Relatiilor si care ridica doar performanta în îndeplinirea anumitor functii. Cu alte cuvinte Cheile trebuie privite ca si Proprietati ale Relatiilor, conferite acestora de functiile pe care le joaca anumite Atribute ale Relatiilor. Pentru asigurarea acestor proprietati SGBD-ul poate utiliza diferite mijloace, între care se numara si Tabelele de Index, obiecte ce pot fi definite si eliminate direct de Sistemul de Gestiune sau de catre Utilizator.

Dupa cum se va vedea în continuare, Tabelele de Index pot asigura realizarea, în anumite conditii, a functiilor atasate Atributelor de tip Cheie. Functiile specifice Tabelelor de Index sunt enumerate mi jos:

- Asigurarea Functiei de Acces Rapid, cu toate ca functiile de Localizare, ca de altfel si cea de Identificare (verificare a Unicitatii) pot fi asigurate teoretic si prin Acces Lent (inspectie secventiala a Tuplelor în absenta Tabelelor de Index) (ex. comenzile LOCATE, SET FILTER din produsele Xbase)

- Asigurarea dinamica (în timpul actualizarii) a Functiei de Ordonare, ce poate fi altfel realizata doar prin Sortare Fizica (dupa actualizare) a Fisierelor Memorate atasate Tabelelor de Baza (comanda SORT din produsele Xbase)

- Asigurarea Functiei de Identificare doar în acele SGBD-uri care au atasate Tabelelor de Index proprietati declarative de tipul: Index Primar, Index Candidat

Modele de Date / Modelul Relational / Identificare, Acces si Ordonare 233

4.2.4.4.2.1 Chei de Identificare

Cheile de Identificare sunt proprietati atasate Relatiilor pe baza semanticii care este acordata Colectiilor de Date sursa. Ca urmare recunoasterea si declararea acestor proprietati face parte din analiza Spatiului de Informatii al utilizatorului în vederea precizarii Cerintelor Sistemului de Aplicatii (Business Logic Definition). Cheile de Identificare sunt reprezentate de Cheile Candidate si de Cheile Straine care se declara într-o Structura Relationala de Date prin urmatoarele Chei:

o Chei Primare - desemnate sa asigure Integritatea Entitatii (posibilitatea de localizare unica a fiecarei Entitati Obiect (Tuple)

o Chei Straine - desemnate sa asigure Integritatea de Referire

o Chei Candidate - desemnate sa ofere forme diversificate de Identificare a Entitatilor Obiect si în plus posibilitatea de analiza a Gradului de Normalizare a Relatiilor (vezi sectiunea 5.1.3); Cheile Candidate sunt denumite si Chei Secundare sau Alternative

SGBD-urile care nu beneficiaza de facilitatea de definire a Cheilor de Identificare, nu pot asigura Conditiile de Integritate în mod Structural (prin simpla declarare în Structura Datelor a Functiei de Identificare pe care o îndeplineste un Atribut) si ca urmare ele nu pot evita, fara interventia programatorului (în mod Procedural), inserarea de Omonime (Tuple cu acelasi Identificator), în alta exprimare, inserarea de Coduri Duble.

O amagire o poate constitui facilitatea oferita de optiunea de declarare a unui Index Unic. Aceasta facilitate permite însa numai filtrarea Dublurilor, prin crearea unui Index special, în care Dublurile nu sunt inserate, cu toate ca adaugarea în Relatie (în Fisierul Memorat) este efectuata. Un asemenea Index va oferi posibilitatea eliminarii dublurilor dintr-un rezultat de Selectie (echivalenta cu comanda SELECT UNIQUE din SQL), dar nu va proteja datele memorate în Tabelele de Baza contra ambiguitatii de identificare.

BENEFICIAR LOCALITATE c - Cod c - Cod n - Nume n - Nume l - Localitate t - Tip

Fig. 4.2.4.4.2.1.1 Arbore de Structura BENEFICIAR – LOCALITATE

Exemplul 1: Se considera Relatia BENEFICIAR cu atributele Cod, Nume, Localitate. Sa se selecteze Orasele în care exista Beneficiari (vezi relatia BENEFICIAR din Fig. 4.2.4.4.2.1.1).

* *

B

c t l n

L

c n

234 Modele de Date / Modelul Relational / Identificare, Acces si Ordonare

Este suficient sa se Indexeze Unic relatia BENEFICIAR dupa Localitate si sa se afiseze continutul (spre exemplu prin comanda BROWSE). Se vor citi toate valorile definite de Localitati, care vor aparea o singura data, chiar daca în aceea Localitate se afla mai mult de un BENEFICIAR.

Alternativa oferita de produsele Xbase pentru a asigura Integritate de Identificare este cea Procedurala. Pentru a prezenta modul de asigurare a Conditiilor de Integritate de Identificare si de Referire pe cale procedurala se dau urmatoarele exemple:

Exemplul 2: Sa se actualizeze relatia LOCALITATE din Fig. 4.2.4.4.2.1.1, cu ajutorul comenzii în mod ecran BROWSE astfel încât sa se asigure pentru orice adaugare de tupla Integritatea de Identificare pentru Cheia Primara COD.

Pentru a asigura, în regim de afisare a datelor (mod ecran BROWSE) posibilitatea de verificare a unicitatii valorii unui atribut, trebuie sa se asocieze atributului respectiv o Procedura de Validare, a carei structura este urmatoare:

- Se verifica prezenta unei tuple cu Valoarea de Atribut egala cu cea din Tupla care se adauga

- Se returneaza Fals daca exista o Tupla cu aceasta Valoare; în aceasta situatie actualizarea în regim de afisare este refuzata, sistemul mentinând Vechea Valoare a atributului

Exemplul 3: Sa se scrie procedura care realizeaza actualizarea celor doua relatii cu asigurarea urmatoarelor restrictii:

- Actualizarea simultana a relatiilor pornind de la datele pe BENEFICIARI

- Garantarea Integritatii de Identificare pentru ambele relatii

- Garantarea Integritatii de Referire între cele doua relatii

Structura Procedurilor de Actualizare descrisa în Pseudo-Cod este urmatoare:

o Procedura de Actualizare BENEFICIAR

§ Se citeste Valoarea Identificatorului pentru tupla care se adauga (valoarea atributului Cod Beneficiar)

§ Se verifica prezenta unei Tuple cu Valoarea de Atribut Cod Beneficiar egala cu cea citita

• daca exista o Tupla cu aceasta Valoare

§ se refuza actualizarea

§ se solicita o noua Valoare de Identificator

• daca nu exista o Tupla cu aceasta Valoare

Modele de Date / Modelul Relational / Identificare, Acces si Ordonare 235

§ se genereaza o noua tupla cu valoarea citita de Identificator

§ Se citesc si se actualizeaza restul valorilor de atribute din relatia BENEFICIAR

§ La citirea Valorii de Cheie Straina (atributul Localitate Beneficiar) se efectueaza Procedura de Verificare LOCALITATE

• daca Procedura a raspuns ADEVARAT se actualizeaza Cheia Straina cu Valoarea citita

• daca Procedura a raspuns Fals se solicita o noua Valoare de Cheie Straina

o Procedura de Verificare LOCALITATE

§ Se verifica prezenta unei tuple cu valoarea Cod LOCALITATE = Localitate BENEFICIAR

• daca exista o Tupla cu aceasta Valoare se returneaza ADEVARAT

• daca nu exista o Tupla cu aceasta Valoare se solicita adaugarea unei noi LOCALITATI

§ la confirmare

• se genereaza o noua Tupla cu valoarea de Identificator data de Localitate BENEFICIAR

• se citesc si se actualizeaza restul Valorilor de Atribute din relatia LOCALITATE

• se returneaza ADEVARAT

§ la infirmare se returneaza Fals

Proceduri ca cele de sus pot fi cu usurinta parametrizate si introduse ca Module de Actualizare în Bibliotecile de Proceduri atasate Bazei de Date. Este primul pas spre construirea Procedurilor Stocate, ca Obiecte ale Bazei de Date.

In SGBD-urile evoluate (ORACLE, INFORMIX, SYBASE, dar chiar si VISUAL FOX) Procedurile de Verificare a Integritatilor de Identificare si de Referire sunt încorporate în facilitatile oferite de sistem, ceea ce determina aparitia în Limbajul de Definitie a clauzelor declarative de tip: Cheie Primara, Cheie Candidata, Cheie Straina. Întrucât aceste Proceduri de Control necesita, din motive de performanta acces rapid, clauzele mai sus enumerate apar atasate Tabelelor de Index. Aceasta determina declansarea automata a procedurilor de verificare a Integritatii Structurii de Date în momentul reperarii anumitor Evenimente, în general legate de Actualizarea Structurilor Relationale (Adaugari, Stergeri, Modificari), la nivel de Tuple sau Atribute. Controlul de creare si mentinere a Integritatii Structurilor ia forme foarte diverse, ceea ce implica completarea simplelor Declaratii de Chei cu atasarea la Regulile de Integritate a unor Conditii Specifice solicitate de Utilizator în procesul permanent de actualizare a extensiunii Relatiilor (vezi sectiunile 3.4.5. si 4.2.1.1.2.).

236 Modele de Date / Modelul Relational / Identificare, Acces si Ordonare

4.2.4.4.2.2 Chei de Acces

Cheile de Acces reprezinta facilitati atasate Structurilor de Date în vederea cresterii Performantei în Prelucrarea lor. Aceste facilitati sunt orientate catre diversificarea Strategiilor de Acces la Date, prin ext inderea Accesului Direct (ex. Acces dupa Valori de Expresii, Indecsi Multipli etc.) precum si a celui Secvential (ex. Ordinii de Inspectie Multiple, Filtrate etc.). Accesul la Date este strâns legat de Operatiile asupra Structurilor, în cazul de fata Structurile Relationale (pentru detalii vezi sectiunea 4.2.5.3). Dintre cele doua moduri de prelucrare a Structurilor Relationale (vezi sectiunea 4.2.4.7.5):

- Procedurala - prin Navigarea în Tabele

- Neprocedurala - prin Specificarea Cererilor de Regasire primul mod este cel mai adecvat pentru clasificarea Strategiilor de Acces, datorita faptului ca în al doilea caz selectarea modului de acces este preluat de SGBD, în cadrul operatiilor implementate în Motorul Relational. In cele ce urmeaza clasificarea va fi facuta pe baza facilitatilor oferite de Mediile de Programare care utilizeaza preponderent Procedurile de Navigare în Tabele (produsele din gama Xbase). Procedurile de Navigare introduse în Extensiile de Limbaje Neprocedurale Standardizate (PL/SQL) opereaza exclusiv asupra Cursorilor, care reprezinta Structuri Secventiale Denormalizate.

Fiecare Tabela de Baza (fisier DBF) reprezinta o Multime de Tuple, care poate fi privita, în absenta oricarei Tabele de Index atasata, ca o Multime Logic Neordonata (Ordinea Logica presupune prezenta unui Criteriu de Ordonare important pentru prelucrarea datelor). Datorita secventialitatii suportului de memorare, Tabela de Baza apare întotdeauna ca o Multime de Tuple Fizic Ordonata. Ordinea tuplelor corespunde în acest caz Ordinii Cronologice de Inserare si Eliminare de Tuple din Tabela de Baza . Întrucât operatia de Eliminare de Tuple modifica Numarul de Ordine al Tuplelor, s-au adoptat doua operatii de Stergere Tuple în Structurile de Date Relationale din produsele comerciale din clasa Xbase:

o Stergere Logica - Marcare Tupla pentru a putea deveni Invizibila pentru Utilizator (comanda DELETE), mentinându-se posibilitatea de demarcare ulterioara (comanda RECALL) cu reintegrarea Tuplei în Tabela de Baza

o Stergere Fizica – Eliminare Tupla din Tabela de Baza , cu refacerea Numerelor de Ordine ale Tuplelor (comenzi DELETE urmate de comanda PACK); Operatia este Ireversibila

Numarului de Ordine al Tuplelor îi corespunde un Identificator Intern de Tupla (Numar de Înregistrare), care este gestionat de sistem. In produsele Xbase, care au la baza un sistem de comenzi orientat pe Prelucrarea Procedurala (Navigarea în Tabele), sistem ce a fost doar ulterior extins cu comenzi Neprocedurale (SQL), o mare importanta o au notiunile descrise mai jos (vezi Fig. 4.2.4.7.5.1.1, cu mentiunea ca în produsele Xbase, Zona de Lucru (Cursorul) corespunde unei singure Tabele de Baza):

o Tabela de Baza Curenta - Tabela de Baza, atasata unei Zone de Lucru Curente (prin comanda OPEN); Tabela de Baza ramâne unica în Baza de Date, ea este însa vazuta prin intermediul unei anumite Zone de Lucru

o Zona de Lucru Curenta - Zona de Memorie Interna atasata la un moment dat unei Tabele de Baza (prin comanda SELECT); aceeasi Tabela de Baza poate fi

Modele de Date / Modelul Relational / Identificare, Acces si Ordonare 237

deschis a în mai multe Zone de Lucru Curente fiecare având atribuite Proprietati Specifice dintre care cele mai importante sunt:

• Un Nume (de tip Alias –„alt Nume”)

• O Ordine de Inspectie data de Indexul de Ordonare atasat

• O Pozitie de Tupla în Multime, pozitie memorata într-o Variabila de Sistem numita Cursor; (de la acest termen provine si cealalta denumire a Zonei de Lucru si anume Cursor)

o Tupla Curenta - Tupla pe care s-a facut pozitionarea la un moment dat a Variabilei de Sistem Indicator de Pozitie (Cursor), care memoreaza Identificatorul Intern al Tuplei Curente, denumit si Numarul de Înregistrare Curenta

o Ordine Curenta – Ordinea de Inspectie la un moment dat a Tabelei de Baza, specificata de Indexul Selectat pentru a defini Ordinea Logica a Tuplelor la acel moment

Referitor la o Tabela de Baza se pot utiliza doua Functii de Sistem deosebit de utile pentru navigare:

- Cardinalul Multimii de Tuple din Tabela de Baza la un moment dat, indicând Numarul Total de Înregistrari din Tabela de Baza (functia RECOUNT() din produsele Xbase)

- Ordinalul Multimii de Tuple din Tabela de Baza la un moment dat, precizat de Tupla Curenta memorata în Indicatorul de Pozitie (functia RECNO() din produsele Xbase)

Valorile Functiilor de Sistem descrise anterior sunt Protejate la Scriere, permitând Utilizatorului doar Acces în Citire. Chiar si utilizarea lor pentru Referirea Structurala este contraindicata, datorita posibilei lor modificari de catre sistem în procesul de actualizare sau întretinere a Tabelelor de Baza (inserari, eliminari sau reordonari fizice de tuple) Cu aceste notiuni se poate trece la analiza Strategiilor de Acces la Tuplele Tabelelor de Baza:

o Strategii de Acces dupa Numarul Tuplelor Accesate

§ Accesul la o Tupla - în acest caz regasirea se efectueaza prin comanda de Cautare Tupla. (comenzile FIND si SEEK ce utilizeaza Indecsi Densi)

§ Accesul la o Submultime de Tuple care au o Proprietate Comuna - în acest caz regasirea se efectueaza în doi pasi :

• se cauta Submultimea de Tuple care satisface Conditia de Cautare si se pozitioneaza Cursorul pe prima Tupla din Submultime (comenzile FIND si SEEK ce utilizeaza Indecsi Nedensi)

• se inspecteaza Tuplele din Multimea gasita (comanda CONTINUE)

Definirea unei Submultimi de Tuple se realizeaza prin doua procedee:

• Cuantificare - definirea Ariei de Cautare data de Multimea de Tuple pe care se face cautarea pe baza Ordinii Tuplelor în Tabela de

238 Modele de Date / Modelul Relational / Identificare, Acces si Ordonare

Baza. Definirea Ariei de Cautare se face cu ajutorul clauzei SCOPE din Comenzile de Acces, comanda ce are ca optiuni:

o ALL - Toate Tuplele din Tabela de Baza

o REST - Restul Tuplelor, începând cu Pozitia Curenta

o NEXT n - Urmatoarele n Tuple

o RECORD n - Tupla cu Numarul Intern de Identificare n

• Filtrare - cautarea si selectarea Tuplelor din Aria definita anterior si care satisfac o Conditie Data. Definirea Filtrului se face cu clauzele:

o FOR expresie (Pentru Expresia Adevarata) - Toate Tuplele din Aria de Cautare, ce satisfac Conditia Logica continuta în Expresie

o WHILE expresie (Cât Timp Expresia e Adevarata) - Toate Tuplele consecutive din Aria de Cautare, ce satisfac Conditia Logica continuta în Expresie, începând cu Tupla Curenta si terminând la prima Tupla care nu mai îndeplineste Conditia

o Strategii de Acces dupa Modul de Realizare a Accesului

§ Acces prin Inspectie - accesul se realizeaza prin trecere de la o Tupla la alta în Ordinea Logica sau Fizica atasata Tabelei de Baza; inspectia poate fi realizata:

• Pas-Cu-Pas - Salt peste un Numar de Tuple înainte (+) sau înapoi (-) (comanda SKIP ± n)

• Cursiva - parcurgerea Repetitiva a Tuplelor unei Tabele de Baza (comenzile SCAN – ENDSCAN)

§ Acces prin Selectie - accesul se realizeaza prin cautarea unei Submultimi de Tuple care verifica o Conditie de Selectie

• Secventiala - cautarea se realizeaza prin verificarea Tuturor Tuplelor din Tabela de Baza

o Asociativa - Selectia Secventiala se realizeaza prin verificarea Valorii Conditiei de Selectie pentru Toate Tuplele din Tabela de Baza (comenzile LOCATE si SET FILTER)

• Directa - cautarea se realizeaza prin Adresare Rapida

o Interna - pe baza Numarului de Înregistrare (comanda GO)

o Asociativa - prin Valoare de Conditie de Selectie, cu ajutorul Tabelelor de Index (comenzile FIND si SEEK) Cheile de Acces sunt reprezentate, în cazul Accesului Direct Asociativ (regasire pe baza de Valoare de Conditie

Modele de Date / Modelul Relational / Identificare, Acces si Ordonare 239

de Selectie), de catre Atributele din Tabelele de Baza , ce intra în Expresia Conditiei de Selectie atasata Tabelului de Index utilizat pentru acces.

Localizarea unei Tuple sau a unei Multimi de Tuple se poate face, în absenta Tabelelor de Index, prin inspectia exhaustiva a Tuplelor dintr-o Tabela de Baza (comenzile LOCATE si SET FILTER), ceea ce subliniaza înca o data faptul ca Structurile Relationale se construiesc exclusiv cu ajutorul Tabelelor de Baza , Tabelele de Index fiind doar Structuri Auxiliare de crestere a performantelor de prelucrare a datelor.

Tabelele de Index reprezinta totodata Structuri Dinamice ce pot fi atasate sau eliminate în orice moment de evolutie a Tabelelor de Baza , fara ca datele continute în acestea sa fie afectate. Se asigura astfel o noua forma de Independenta în cadrul Sistemelor cu Baze de Date si anume Independenta Structurii fata de Metodele de Acces (Independenta Tabelelor de Baza fata de Tabelele de Index definite).

O a doua forma de independenta se manifesta între Proceduri si Tabelele de Index atasate Structurii de Date. Independenta Procedurilor fata de Metodele de Acces masurata prin Imunitatea Procedurilor la modificarile efectuate în Structurile Auxiliare este realizata în cadrul Limbajelor de Specificare (vezi sectiunea 4.2.4.5.2). Exista însa SGBD-uri care realizeaza aceasta independenta si în cadrul Limbajelor de Navigare, prin încorporarea dinamica a Modulelor Specifice de Acces în functie de Operatiile de Acces cuprinse în Proceduri (Sistemul R). Se poate afirma cu toate acestea ca pâna în prezent problema Independentei Procedurilor fata de Strategiile de Acces nu este în totalitate rezolvata, întrucât Viteza de Raspuns la Cereri continua sa fie dependenta de modul de definire a Tabelelor de Index.

Fiecare Tabela de Index are atasata o Expresie de Indexare, care e evaluata pentru fiecare Tupla din Tabela de Baza indexata, expresie dupa care se face Inversarea Colectiei de Date continuta în Tabela de Baza (vezi sectiunea 3.4.2.2). Unei Tabele de Baza i se pot atasa oricâte Tabele de Index. Exista o mare varietate de Tipuri de Tabele de Index si de moduri de utilizare a acestora. Se indica în continuare mai multe clasificari ale Tabelelor de Index, cu mentionarea Criteriului de Clasificare:

o Tabele de Index dupa Rolul Indecsilor la un moment dat

§ Indecsi Pasivi - nu se actualizeaza cu datele actualizate în Tabelele de Baza (actualizarea lor va fi facuta ulterior, prin Reindexare, în cadrul unei Proceduri Seriale – Off Line)

§ Indecsi Activi - se actualizeaza la fiecare actualizare de date în Tabelele de Baza (prin Proceduri Paralele – On Line)

• Index Principal – Indexul Curent selectat pentru a defini Ordinea Logica a Tuplelor la un moment dat (poate exista un singur astfel de Index, cu toate ca el poate fi modificat în mod dinamic)

• Indecsi Secundari – ceilalti Indecsi Activi

Asupra Tabelelor de Index (Indecsilor) se pot efectua mai multe operatii:

- Creare Index - se genereaza o structura de Arbore Binar pornind de la o Tabela de Baza si o Expresie de Indexare (vezi sectiunea 3.4.2.2.1.2)

- Dezactivare Index - se detaseaza Tabela de Index de Tabela de Baza

240 Modele de Date / Modelul Relational / Identificare, Acces si Ordonare

- Atasare Index - se ataseaza Tabela de Index de Tabela de Baza

- Selectare Index - un Index Secundar e selectat ca Index Principal

- Reactualizare Index - se refac Structurile de Arbori Binari ale Indecsilor Activi

- Eliminare Index - se detaseaza Tabela de Index de Tabela de Baza si se sterge Indexul de pe suport

o Tabele de Index dupa Multimea de Tuple Localizate (vezi si sectiunea 3.4.2.2.1.2)

§ Indecsi Densi - localizeaza o Tupla

§ Indecsi Nedensi - localizeaza o Multime de Tuple

o Tabele de Index dupa Numarul Indecsilor Memorati într-un Fisier de Indecsi

§ Indecsi Individuali – Fisierul de Indecsi atasat Tabelei de Baza contine un singur Index

§ Indecsi Multipli - – Fisierul de Indecsi atasat Tabelei de Baza contine o Multime de Indecsi, identificati prin Nume (Etichete)

o Tabele de Index dupa Complexitatea Expresiei de Indexare

§ Indecsi Simpli - Expresia de Indexare se rezuma la valoarea unui singur Atribut din Tabela de Baza

§ Indecsi Compusi - Expresia de Indexare se construieste pe baza mai multor Atribute din Tabela de Baza, putând include si apeluri de Functii de Sistem sau de Utilizator .

o Tabele de Index dupa Numarul Tuplelor care participa la indexare

§ Indecsi Neconditionati - sunt indexate toate Tuplele din Tabela de Baza

§ Indecsi Conditionati - sunt indexate numai Tuplele din Tabela de Baza care verifica Conditia de Indexare atasata Indexului

o Tabele de Index dupa Modul de Tratare al Omonimelor (Tuple având aceeasi Valoare a Expresiei de Indexare)

§ Indecsi Neunici - participa toate Omonimele

§ Indecsi Unici - participa doar Prima Tupla întâlnita dintr-o Multime de Omonime

o Tabele de Index dupa Modul de Organizare a Tabelei de Baza

§ Indecsi Neblocati (Neclusterati) – Daca Tabela de Baza nu are atasat nici-un Index Blocat ea va fi organizata pe Înregistrari si Ordinea Fizica a Tuplelor din Tabela de Baza este cea Cronologica, acestea fiind apoi accesate din Tabela de Index prin Referire de Adresa (Varianta obisnuita)

§ Indecsi Blocati (Clusterati) - Daca Tabela de Baza are atasat un Index Blocat (un singur Index Blocat este admis pentru o Tabela de Baza) Ordinea Fizica a Tuplelor din Tabela de Baza este aceeasi cu Ordinea Logica data de

Modele de Date / Modelul Relational / Identificare, Acces si Ordonare 241

expresia de Indexare atasata Tabelei de Index; Tuplelor din Tabela de Baza sunt accesate din Tabela de Index prin Referirea Blocului apoi prin inspectie secventiala în cadrul Blocului (Optiune speciala continuta în standardul SQL) Varianta este deosebit de avantajoasa pentru consultarea integrala a Tabelei de Baza dupa o Ordine Preferentiala, dar complica Operatiile de Actualizare prin Gestiunea Blocurilor de Înregistrari

La aparitia si impunerea Limbajelor Neprocedurale în domeniul interogarii Bazelor de Date lumea specialistilor s-a grabit sa decreteze apusul Prelucrarii Procedurale. Datorita unei multimi de factori situatia asteptata nu s-a confirmat. Enumeram dintre acesti factori:

- Controlul crescut în gestionarea volumelor mari de date a crescut complexitatea structurilor ce puteau fi prelucrate (Structuri Recursive, Imp lementari de Procese de Abstractizare definite la nivelul Modelelor de Date, Structuri Active, Viziuni Obiectuale etc.)

- Limbajele Neprocedurale de Interogare au trebuit supuse unui proces de Standardizare în vederea Unificarii si a Generalizarii lui, ceea ce a limitat posibilele dezvoltari ale versiunilor standardizate succesive, general acceptate

- Necesitatea mentinerii unui anumit grad de siguranta si ca urmare de simplitate în formularea si validarea Cererilor

In aceste conditii Navigarea în structurile de date a trebuit sa fie mentinuta. Este vorba însa de o forma redusa de navigare, care în primul rând a eliminat gestionarea manuala a strategiilor de acces prin controlul Tabelelor de Index. Alegerea Strategiei de Acces, Generarea Tabelelor de Index si utilizarea acestora în procesul de descompunere a Cererilor si de executie a Operatiilor Relationale care este lasata pe seama Optimizatorului de Cereri si a Motorului Relational, ambele componente ale SGBD-ului Relational.

Dupa cum se cunoaste din descrierea Nivelului Extern al Modelului de Date Relational, orice Cerere reprezinta în Limbajul Neprocedural o descriere de Rezultat sub forma unei Relatii. Acest Rezultat poate însa sa fie o Valoare Individuala (un Atribut Unic sau o Tupla Unica) sau o Valoare de tip Multime (o Multime de Tuple). Atunci când rezultatul este livrat unui Instrument (Tool) care stie sa-l prelucreze indiferent de tipul sau (Individual sau Multime) descrierea, care este privita întotdeauna ca un tot, este suficienta. Exemple sunt oferite de Limbajele Interactive de Interogare, care stiu sa afiseze rezultatul în formatul ales de reprezentare, indiferent de numarul tuplelor continute în rezultat, precum si Instrumentele de Construire a Rapoartelor. Când însa rezultatele Cererilor sunt furnizate unui Limbaj Gazda (un limbaj care încorporeaza Cererile pe post de Comenzi de Acces la Baza de Date), Rezultatul de tip Multime trebuie inspectat prin Navigare, pentru a se oferi o prelucrare specifica fiecarui element (Tupla) din multime. Aceasta forma aditionala de prelucrare a Rezultatului de tip Multime se poate face în Limbajul Gazda sau în Limbajul Extins de Cereri (exemplu PL/SQL). Limbajul Extins de Cereri contine, pe post de Comanda de Navigare comanda:

FETCH [[ <directia de navigare> ] FROM] <nume cursor> INTO <lista de variabile>

unde:

- Directia de navigare – este reprezentata de clauzele:

o NEXT – urmatoarea tupla

242 Modele de Date / Modelul Relational / Identificare, Acces si Ordonare

o PRIOR – precedenta tupla

o FIRST – prima tupla

o LAST – ultima tupla

o ABSOLUTE i – tupla cu Numarul Intern de Identificare i

o RELATIVE i – urmatoarea a i – a tupla pornind de la tupla curenta

- Nume Cursor – Numele atasat Variabilei Interne care memoreaza Pozitia Tuplei Curente (tupla aflata în curs de prelucrare) si a carui valoare este gestionata automat de sistem în urma interpretarii comenzilor FETCH

- Lista de Variabile – Variabilele interne în care vor fi transferate atributele din rezultat

Rezultatul de tip Multime destinat unei operatii ulterioare de prelucrare prin Navigare poarta si denumirea improprie de Cursor, aceasta denumire fiind indusa de Cursorul atasat Rezultatului si care gestioneaza Pozitia Tuplei Curente din Rezultat. 4.2.4.4.2.3 Chei de Ordonare

Cheile de Acces îndeplinesc simultan si functia de Ordonare, datorita procedeului de indexare utilizat (Indexare prin Arbori Binari).

O Tabela de Baza poate avea atasate mai multe Criterii de Ordonare si ca urmare mai multe Ordini de Inspectie. Dam o clasificare în cele ce urmeaza:

o Ordinea Naturala data de:

§ Ordinea Cronologica de introducere a Tuplelor în Tabela de Baza, atunci când:

• Tabela de Baza este construita ca un Fisier Secvential de Înregistrari

• Adaugarea de Tuple se efectueaza printr-o scriere de Înregistrari la sfârsitul Fisierului

• Stergerea Fizica se realizeaza prin rescrierea Fisierului

§ Sortarea Fizica prin Reordonarea Tabelei de Baza cu rescrierea Fisierului

§ Ordonarea Fizica dupa un Criteriu Logic (vezi Indecsii Blocati), caz în care:

• Tabela de Baza este construita ca un Fisier Secvential de Blocuri (Secvente Fizice, înlantuite prin Referinte de Adresa)

• Adaugarea de Tuple se efectueaza ca o scriere de Înregistrari la sfârsitul Blocurilor Ordonate printr-un Criteriu de Ordonare

• Stergerea Fizica se realizeaza prin reorganizarea (rescrierea) Blocurilor

O Tabela de Baza admite a singura Ordine Naturala (Ordine Fizica). Acesta este si motivul pentru care o Tabela de Baza admite un singur Index Blocat. Alegerea Indexului care sa fie Blocat (Clusterat) este o problema delicata întrucât efectul

Modele de Date / Modelul Relational / Identificare, Acces si Ordonare 243

poate fi uneori invers (de crestere a duratei totale de prelucrare). Pentru aceasta alegere se fac urmatoarele recomandari:

o Cheia Primara a Tabelelor de Baza reprezinta în majoritatea cazurilor o buna alegere, întrucât este solicitata foarte frecvent în procesul de actualizare pe post de Cheie de Acces (inclusiv pentru Cautarea în Vecinatate)

o Atributul Nume , prezent în majoritatea Tabelelor, daca îndeplineste si conditia de a fi discriminat (Cheie Candidata) poate reprezenta o alternativa, atunci când principalele Rapoarte Finale folosesc aceasta Ordine de Inspectie

o Numele Categoriilor din Tabelele ce descriu Criterii de Clasificare sunt întotdeauna candidate pentru Indecsi Blocati datorita utilizarii lor în cadrul Listelor de Selectie din Interfetele Utilizator

o Ordinea Logica data de:

§ Ordinea Valorilor unui Criteriu de Ordonare în Tabela de Index (asigurata de Structura de Arbore Binar a Tabelei de Index) si care adreseaza în final Înregistrarile din Tabela de Baza prin Referinte de Adresa (vezi sectiunea 3.4.2.2.1.2)

Întrucât Ordinea Logica se implementeaza prin Structurile Auxiliare de tip Index, o Tabela de Baza poate admite oricâte Ordini Logice atasate. In acest caz Indecsii sunt grupati într-o Lista de Indecsi, diferentiati prin Numele Indexului (Eticheta Indexului). La un moment dat însa Ordinea Logica a Tabelei de Baza este si ea unica, fiind data de Indexului Principal din Lista de Indecsi, selectat ca Index Curent. Modificarea Indexului Curent are un caracter dinamic, putând fi utilizata chiar între doua Operatii de Prelucrare a Tabelei de Baza. Trebuie retinut faptul ca Indexul, fiind o structura atasata Tabelei de Baza, fiecare actualizare a acesteia determina o actualizare corespunzatoarele a Tabelei de Index. Numarul Indecsilor din Lista de Indecsi determina durata de actualizare a unei Tuple în Tabela de Baza, fiind recomandabila evitarea supraîncarcarii cu Indecsi Activi a Listelor de Indecsi. Întrucât o buna parte din Indecsi sunt utilizati doar în faza finala a prelucrarii, cu ocazia extragerii Rapoartelor Finale (a Suporturilor de Decizie) se recomanda utilizarea urmatoarelor procedee de lucru:

• Utilizarea de Indecsi Temporari, Tabele de Index ce se creeaza dupa încheierea fazei de actualizare a Bazei de Date, prin Reindexarea Tabelelor de Baza dupa Criterii de Ordonare ce corespund Ordinii de Inspectie utilizate pentru mai multe Iesiri (Familii de Rapoarte); Tabelele de Index Temporare vor fi apoi abandonate

• Resortarea Fizica a Tabelelor de Baza dupa încheierea fazei de actualizare, potrivit unui Criteriu de Ordonare Preferential (daca acesta exista), pentru extragerea datelor în Rapoartele Principale

244 Modele de Date / Modelul Relational / Identificare, Acces si Ordonare

4.2.4.5 Manipularea Structurilor Relationale

Manipularea Structurilor Relationale se bazeaza pe Expresii (ansambluri de Operatori Relationali) având atât ca Operanzi, cât si ca Rezultat, chiar Constructorul de Structura – Relatia, ceea ce va permite în orice moment concatenarea Expresiilor Relationale întrucât orice Rezultat Intermediar poate constitui un nou Operand într-o noua Expresie. Exemple:

Sa consideram Structura Relationala BENEFICIARI, PRODUSE, CONTRACTE, descrisa extensional în Fig. 5.1.3.1.2.3.1. Fie urmatoarele întrebari adresate Colectiei de Date:

Întrebarea 1 – Codul PRODUSELOR contractate de BENEFICIAUL având codul B2?

Raspuns 1:

Cod*

P2

P3

P4

Tab. 4.2.4.5.1. Produsele Contractate de Beneficiarul cu Codul ’B2’

Întrebarea 2 – Numele si Contul BENEFICIARILOR din Orasul O1?

Nume Cont

N1 C1

N2 C2

Tab. 4.2.4.5.2 Numele si Contul Beneficiarului din Orasul ’O1’

Întrebarea 3 – Codul PRODUSULUI si Orasul în care trebuie livrate conform CONTRACTULUI?

Codp* Oras

P1 O1

P3 O1

P3 O1

P2 O2

P3 O2

P4 O2

Tab. 4.2.5.1. Codul Produsului si Orasul în care trebuie livrate

Modele de Date / Modelul Relational / Manipularea Datelor 245

Se remarca situatia anticipata si anume faptul ca toate raspunsurile la întrebarile formulate ca si Cereri sunt reprezentate de Tabele (de fapt de Clase de Entitati), de Relatii. Modelul Relational ofera doua cai de a descrie noi Relatii care sa reprezinte raspunsurile solicitate.

o Precizarea detaliata a Secventei de Operatii din Algebra Relationala, care trebuie executate pentru a obtine Rezultatul

o Specificarea Rezultatului prin Formularea unei Definitii a Rezultatului cerut în termenii Calculului Relational, lasând sistemul (SGBD) sa stabileasca secventa de operatii ce trebuiesc executate pentru obtinerea Rezultatului

Întrucât definirea Modelului Relational are la baza Teoria Matematica a Multimilor în care definirea Relatiilor este un capitol continut (vezi sectiunea 4.1), este firesc sa se regaseasca o asemanare directa între caile de descriere a Relatiilor Rezultat si modurile de definire a Multimilor în general:

o Prin precizarea Operatiilor pe Multimi (Reuniune, Intersectie, Negare, Diferenta etc.)

o Prin definirea unui Predicat care sa constituie Însusirea Definitorie a Rezultatului, privit ca o noua Multime

Diferenta dintre cele doua cai prezentate anterior este cea între:

o Proceduralitate – bazata pe enumerarea succesiva a operatorilor de Algebra Relationala

o Neproceduralitate – bazata pe specificarea cu ajutorul Calculului Relational a Rezultatului (întotdeauna o Relatie)

4.2.4.5.1 Metoda bazata pe Algebra Relationala

Algebra Relationala reprezinta o baza pentru un Limbaj de Manipulare a Datelor Relationale, care se constituie ca un Limbaj de Nivel Înalt. Ea contine o colectie de Operatori având drept Operanzi Relatii, si care produc de fiecare data ca Rezultat o noua Relatie. Având în vedere ca orice raspuns la o întrebare poate fi reprezentat de o Clasa de Entitati (deci de o Relatie) sarcina Limbajului de Manipulare a Datelor este de a permite, pentru orice întrebare formulata, gasirea unei secvente de Operatori care sa conduca la Rezultatul cautat. 4.2.4.5.1.1 Operatori Relationali

Doua categorii de Operatori Relationali (vezi Tab. 4.2.4.5.1.1.1) pot fi recunoscuti în Algebra Relationala, domeniu matematic ce se ocupa cu definirea Expresiilor Relationale:

- Operatori Traditionali, provenind din operarea cu Multimi , aici privite ca si Clase de Entitati

- Operatori Specific Relationali, provenind din operarea cu Relatii

Ambele categorii de Operatori Relationali sunt utilizati în Limbajele Relationale Procedurale. Operatorii Traditionali de felul Reuniunii (UNION) si Intersectie (INTERSECT) vor fi regasiti însa si în Limbajele Neprocedurale pentru a le extinde puterea de calcul.

246 Modele de Date

REUNIUNE UNION R1 ∪ R2 INTERSECTIE INTERSECT R1 ∩ R2 DIFERENTA MINUS R1 \ R2

Traditionali pe

Multimi PRODUS CARTEZIAN TIMES R1 x R2

SELECTIE SELECT σ ls (R1) PROIECTIE PROJECT π lp (R1)

= (R1) ρ (e1 = e2) (R2) < (R1) ρ (e1 < e2) (R2) > (R1) ρ (e1 > e2) (R2)

NATURALA (R1) ρ (e) (R2) POSIBILA (R1) ρ p (e) (R2)

REUNIRE (CUPLARE)

JOIN

EXTERIOARA (R1) ρ x (e) (R2)

Operatori Relationali

Specific Relationali

IMPARTIRE DIVIDEBY R1 / R2

Tab. 4.2.4.5.1.1.1 Clasificarea Operatorilor din Algebra Relationala

Modele de Date / Modelul Relational / Manipularea Datelor 247

4.2.4.5.1.2 Operatori Relationali Traditionali

o Operatiile Relationale Tradi tionale – sunt operatii din teoria multimilor aplicate Relatiilor privite ca Multimi de Tuple. Pentru ca doua Relatii sa poata juca rolul de Operanzi în Operatiile Relationale Traditionale, ele trebuie sa îndeplineasca proprietatea de Compatibilitate la Reuniune, definita prin urmatoarele conditii:

• Relatiile sa fie definite pe aceleasi domenii

• Ordinea Atributelor provenind din Domenii Corespondente sa fie aceeasi

• Numele Atributelor provenind din Domenii Corespondente pot sa difere

• Relatiile sa respecte restrictia de Integritate de Identificare Spre deosebire de Relatiile de Baza definite de utilizator cu ajutorul Limbajului de Definire a Datelor (LDD) , Relatiile care apar ca Rezultate ale aplicarii Operatorilor Relationali din Limbajul de Manipulare a Datelor (LMD) , poarta numele de Relatii Derivate. Pentru denumirea Atributelor din Relatiile Derivate se folosesc urmatoarele conventii:

• Pentru operatiile Reuniune, Intersectie si Diferenta Numele Atributelor din Rezultat se preiau din primul operand

• Pentru operatia Produs Cartezian - Numele Atributelor din Rezultat se preiau din ambii operanzi astfel:

o Pentru R1 x R2 numele atributelor în rezultat vor fi calificate astfel:

R1. a1, R1. a1, .. , R1. am, R2. am+1, R2. am+2, .. , R2. am+ n

o Pentru R1 x R1, a doua aparitie a relatiei R1 trebuie înlocuita prin redenumire (R1

’ ALIASES R1) si se aplica conventia anterioara pentru numele atributelor

§ REUNIUNE

• Mnemonica în Limbajele Relationale – UNION

• Simbol în Expresii Relationale ∪

• Forma generala a operatiei este:

( <nume relatie 1>) ∪ ( <nume relatie 2>)

unde ∪ - desemneaza operatorul Reuniune

• Defineste o relatie care contine reuniunea multimilor de tuple din doua alte relatii

• Proprietatile operatorului sunt:

248 Modele de Date / Modelul Relational / Manipularea Datelor

o este un operator binar

o este un operator comutativ

o rezultatul contine toate Atributele ce refera Domenii Comune

o gradul relatiei Rezultat este acelasi cu gradul relatiilor initiale

o relatia Rezultat va contine tuple care exista în prima sau a doua Relatie Initiala

o tuplele Duplicate vor fi eliminate din Rezultat, folosind Integritatea de Identificare (vezi sectiunea 5.2.4.4.1)

o numarul de tuple în Rezultat este mai mic sau egal cu (n + m), unde n este numarul tuplelor în relatia 1 si m este numarul tuplelor în relatia 2

Exemplul 1: Fie o relatiile GRUPA si STUDENT definite intensional ca în Fig. 4.2.4.5.1.1 si extensional ca în Tab. 4.2.4.5.1.1.

GRUPA (Cod, Nume, Limba-predare) KEY (Cod)

STUDENT (Marca, Nume, Prenume, Sex, Grupa) KEY (Marca)

Fig. 4.2.4.5.1.1 Intensiunea relatiilor GRUPA si STUDENT

GRUPA COD* NUME Limba-predare

C1 N1 L1 C2 N2 L2 C3 N3 L1 C4 N4 L1 C5 N5 L2 C6 N6 L1

STUDENT Marca* Nume Prenume Sex Grupa

M1 N1 P1 S1 G1 M2 N2 P2 S2 G2 M3 N3 P3 S2 G2 M4 N4 P1 S1 G3 M5 N5 P3 S2 G4 M6 N6 P1 S1 G1

Tab. 4.2.4.5.1.1 Extensiunea relatiilor GRUPA si STUDENT

Sa descriem în expresie de Algebra Relationala raspunsul la întrebarea: Studentii care fac parter din Grupa G1 sau G2?

(σ ( Grupa=’G1’ ) (STUDENT)) ∪ (σ (Grupa=’G2’) (STUDENT))

Modele de Date / Modelul Relational / Manipularea Datelor 249

Acelasi rezultat poate fi obtinut mai simplu:

(σ (Grupa=’G1’ or Grupa=’G2’) (STUDENT))

Exemplul 2: Sa adaugam la structura relationala anterioara si relatia PROFESOR:

PROFESOR (Marca, Nume, Prenume, Sex, Titlu) KEY (Marca)

Fig. 4.2.4.5.1.2 Intensiunea relatiei PROFESOR

PROFESOR Marca* Nume Prenume Sex Titlu

M1 N1 P1 S1 T1 M12 N12 P12 S2 T2 M13 N13 P13 S1 T3

Tab. 4.2.4.5.1.1 Extensiunea relatiei PROFESOR

Fie întrebarea: Marca, Numele si Prenumele Persoanelor(Studenti sau Profesori)?

(π ( Marca,Nume, Prenume) (STUDENT)) ∪ (π (Marca,Nume, Prenume) (PROFESOR))

In acest caz expresia nu poate fi rescrisa.

§ INTERSECTIE

• Mnemonica în Limbajele Relationale – INTERSECT

• Simbol în Expresii Relationale ∩

• Forma generala a operatiei este:

( <nume relatie 1>) ∩ ( <nume relatie 2>)

unde ∩ - desemneaza operatorul INTERSECTIE

• Defineste o relatie care contine intersectia multimilor de tuple din doua alte relatii

• Proprietatile operatorului sunt:

o este un operator binar

o este un operator comutativ

o rezultatul contine toate Atributele ce refera Domenii Comune

o gradul relatiei Rezultat este acelasi cu gradul relatiilor initiale

o relatia Rezultat va contine numai tuplele care exista în ambele Relatii Initiale

o tuplele Duplicate vor fi eliminate din Rezultat, folosind Integritatea de Identificare (vezi sectiunea 5.2.4.4.1)

250 Modele de Date / Modelul Relational / Manipularea Datelor

o numarul de tuple în Rezultat este mai mic sau egal cu (n + m), unde n este numarul tuplelor în relatia 1 si m este numarul tuplelor în relatia 2

Exemplul 3: Considerând aceleasi structuri relationale sa raspundem la întrebarea: Studentii care fac parter din Grupa G1 si au Sexul S2?

(σ ( Grupa=’G1’ ) (STUDENT)) ∩ (σ (Sex=’S2’) (STUDENT))

Acelasi rezultat poate fi obtinut mai simplu:

(σ (Grupa=’G1’ and Sex=’S2’) (STUDENT))

Exemplul 4: Fie întrebarea: Marca, Numele si Prenumele Persoanelor care sunt si Studenti si Profesori)?

(π (Marca,Nume, Prenume) (STUDENT)) ∩ (π (Marca,Nume, Prenume) (PROFESOR))

In acest caz expresia nu poate fi rescrisa.

§ DIFERENTA

• Mnemonica în Limbajele Relationale – MINUS

• Simbol în Expresii Relationale \

• Forma generala a operatiei este:

( <nume relatie 1>) \ ( <nume relatie 2>)

unde \ - desemneaza operatorul DIFERENTA

• Defineste o relatie care contine diferenta multimilor de tuple din alte doua relatii

• Proprietatile operatorului sunt:

o este un operator binar

o este un operator necomutativ

o rezultatul contine toate Atributele ce refera Domenii Comune

o gradul relatiei Rezultat este acelasi cu gradul relatiilor initiale

o relatia Rezultat va contine numai tuplele care exista în prima Relatie si nu exista în a doua

o numarul de tuple în Rezultat este mai mic sau egal cu (n + m), unde n este numarul tuplelor în relatia 1 si m este numarul tuplelor în relatia 2

Exemplul 5: Considerând aceleasi structuri relationale sa raspundem la întrebarea: Studentii care fac parter din Grupa G1 si nu au Sexul S2?

(σ ( Grupa=’G1’ ) (STUDENT)) \ (σ (Sex=’S2’) (STUDENT))

Modele de Date / Modelul Relational / Manipularea Datelor 251

Acelasi rezultat poate fi obtinut mai simplu:

(σ (Grupa=’G1’ a nd Sex ≠ ’S2’) (STUDENT))

Exemplul 6: Fie întrebarea: Marca, Numele si Prenumele Persoanelor care sunt Studenti si nu sunt Profesori)?

(π (Marca,Nume, Prenume) (STUDENT)) \ (π (Marca,Nume, Prenume) (PROFESOR))

In acest caz expresia nu poate fi rescrisa.

§ PRODUS CARTEZIAN

• Mnemonica în Limbajele Relationale – TIMES

• Simbol în Expresii Relationale x

• Forma generala a operatiei este:

( <nume relatie 1>) x ( <nume relatie 2>)

unde x - desemneaza operatorul PRODUS CARTEZIAN

• Defineste o relatie care contine produsul cartezian al multimilor de tuple din doua alte relatii

• Proprietatile operatorului sunt:

o este un operator binar

o este un operator comutativ

o rezultatul contine toate combinatiile de tuple din cele doua relatii (poate fi asimilata cu o operatie de Reunire cu Conditia de Reunire valabila pentru toate combinatiile de tuple)

Întrucât operatia de Produs Cartezian este utilizata doar în cadrul operatiilor de Reunire (Cuplare), exemple vor fi date la prezentarea acelor operatori, specific relationali.

4.2.4.5.1.3 Operatori Specific Relationali

o Operatiile Specific Relationale – sunt operatii ce transforma Relatiile Initiale în noi Relatii prin doua procedee fundamentale (vezi si sectiunea 4.1.2):

• Regrupare – prin Selectie Orizontala (PROJECT) si Verticala (SELECT)

• Combinare – prin Cuplare (Reunire) de Tabele (JOIN)

§ SELECTIE

• Mnemonica în Limbajele Relationale – SELECT

• Simbol în Expresii Relationale σ

252 Modele de Date / Modelul Relational / Manipularea Datelor

• Forma generala a operatiei este:

σ < conditie de selectie > ( <nume de relatie>)

unde σ - desemneaza operatorul SELECTIE < conditie de selectie > - este o expresie Booleana

• Defineste o submultime de tuple ale unei relatii care satisfac o Conditie de Selectie

• Proprietatile operatorului sunt:

o este un operator unar

o Conditia de Selectie e construita numai cu Valori de Atribute apartinând unei singure Tuple

o gradul relatiei Rezultat este acelasi cu gradul relatiei initiale

o numarul de tuple în Rezultat este mai mic sau egal cu numarul tuplelor din relatia initiala

Exemplul 7: Considerând aceleasi structuri relationale sa raspundem la întrebarea: Studentii care au Sexul S2?

σ ( Sex=’S2’ ) (STUDENT)

§ PROIECTIE

• Mnemonica în Limbajele Relationale – PROJECT

• Simbol în Expresii Relationale π

• Forma generala a operatiei este:

π < lista de attribute de proiectie > ( < nume de relatie >)

unde π - desemneaza operatorul PROIECTIE < lista de attribute de proiectie > - este Lista Atributelor de Definitie pentru relatia Rezultat

• Defineste o noua relatie având ca Lista de Atribute de Definitie o submultime de atribute (Lista de Atribute de Proiectie) din Lista de Atribute de Definitie ale relatiei initiale

• Proprietatile operatorului sunt:

o este un operator unar

o tuplele Duplicate vor fi eliminate din Rezultat, pastrând Integritatea de Identificare (vezi sectiunea 4.2.4.4.1) în Relatia Rezultat

o Lista de Atribute de Proiectie e continuta în Lista Atributelor de Definitie ale relatiei initiale

o gradul relatiei Rezultat este egala cu numarul atributelor cuprinse în Lista de Atribute de Proiectie

Modele de Date / Modelul Relational / Manipularea Datelor 253

o numarul de tuple în Rezultat este mai mic sau egal cu numarul tuplelor din relatia initiala

Exemplul 8: Considerând aceleasi structuri relationale sa raspundem la întrebarea: Marca Numele si Prenumele Studentilor?

π (Marca,Nume, Prenume) (STUDENT)

§ REUNIRE (CUPLARE)

• Mnemonica în Limbajele Relationale – JOIN

• Simbol în Expresii Relationale ρ

• Forma generala a operatiei este:

(<nume relatie 1>) ρ < conditie de reunire > (<nume relatie 2>)

unde ρ - desemneaza operatorul REUNIRE < conditie de reunire > - este o conditie cu atribute din cele doua relatii initiale

• Defineste o combinatie de tuple corespondente din doua Relatii care vor fi reunite într-o singura tupla în Relatia Rezultat, pe baza unei Conditii de Reunire (Cuplare)

• Proprietatile operatorului sunt:

o este un operator unar

o este un operator comutativ

o Rezultatul contine numai Valori de Atribute din Tuplele care satisfac Conditia de Reunire

o tuplele Duplicate vor fi eliminate din Rezultat, pastrând Integritatea de Identificare (vezi sectiunea 5.2.4.4.1) în Rezultat

o tuplele cu Valori Nule pentru Atributele din Conditia de Reunire vor lipsi din Rezultat

o gradul relatiei Rezultat este egala cu (n + m), unde n este numarul tuplelor în relatia 1 si m este numarul tuplelor în relatia 2

o numarul de tuple în Rezultat este mai mic sau egal cu numarul tuplelor din Produsul Cartezian al relatiilor initiale

Exemplul 9: Considerând aceleasi structuri relationale sa raspundem la întrebarea: Atributele Studentilor împreuna cu Atributele Grupei din care fac parte?

(STUDENT) σ ( STUDENT. grupa = GRUPA . cod) (GRUPA)

Exista o mare varietate de operatori de Reunire. Lista acestora împreuna cu o scurta descriere e redata în Tab. 4.2.4.5.1.3.

254 Modele de Date

Varianta de Operator de

Reunire

Subvarianta de

Operator de Reunire

Mnemonica

Descriere

Reunire EGALA

EQUIJOIN Operatorul de Comparatie din Conditia de Reunire este =

Reunire MAI MICA

LESSJOIN Operatorul de Comparatie din Conditia de Reunire este <

Reunire MAI MARE

GREATHERJOIN Operatorul de Comparatie din Conditia de Reunire este >

Reunire NATURALA

NATURAL JOIN Conditia de Reunire contine doar Atribute Omonime din relatiile initiale (membrul drept al conditiei poate fi omis)

STANGA LEFT OUTER JOIN

Rezultatul contine toate tuplele din relatia din Stânga (cu valori NULE în locul atributelor din tuplele corespondente care lipsesc la Dreapta)

DREAPTA RIGHT OUTER JOIN

Rezultatul contine toate tuplele din relatia din Dreapta (cu valori NULE în locul atributelor din tuplele corespondente care lipsesc la Stânga)

Reunire EXTERNA

COMPLETA FULL OUTER JOIN

Rezultatul contine toate tuplele din ambele relatii (cu valori NULE în locul atributelor din tuplele corespondente care lipsesc – la Stânga sau la

Dreapta) Reunire

POSIBILA POSSIBLE JOIN Conditia de Reunire e adevarata doar pentru Valori Nedefinite de

Atribute

Tab. 4.2.4.5.1.3 Variantele de Operatori de Reunire

Modele de Date / Modelul Relational / Manipularea Datelor 255

§ IMPARTIRE

• Mnemonica în Limbajele Relationale – DIVIDEBY

• Simbol în Expresii Relationale /

• Forma generala a operatiei este:

R = (R1 / R2)

unde:

o R – Rezultat

o R1 – Deîmpartit

o R2 – Impartitor

• Definitie 1:

Daca: R1 (am+n) si R2 (an) sunt Relatii Initiale definite pe Listele de Atribute am+n si an, cu an ⊂ am+n, astfel încât am+n \ an = am ≠ ∅ ,

atunci: operatorul IMPARTIRE construieste o relatie R (am), definita pe Lista de Atribute am si având extensia reprezentata de o multime de tuple vmi, care verifica proprietatea:

vni ∈ R ⇔ vmj ∈ R2 si v(n+m)i, vmj ∈ R1, pentru ∀ j ∈ (m+1) .. (m+n)

Definitie 2: Definirea operatiei se face de asta data cu ajutorul operatorilor deja cunoscuti:

Fie doua relatii initiale: R1 (la1) si R2 (la2), unde la1 si la2 sunt Liste de Atribute, cu la = la1 \ la2.

Atunci: R 1 / R 2 = RI1 \ RI 2

unde: RI1 = π <la> (R1)

T2 = π <la> (R2 x RI1) \ R1) Definitie 3: Pentru fiecare tupla din Rezultat, Valorile Atributelor trebuie sa apara în prima Relatie Initiala cu toate Valorile Atributelor din cea de a doua Relatie Initiala.

256 Modele de Date / Modelul Relational / Manipularea Datelor

Exemplul 10: Fie Structura Relationala descrisa extensional în Fig. 4.2.4.5.1.4.1:

CERERE Beneficiar* Produs*

B1 P1 B1 P2 B1 P3 B1 P4 B1 P5 B2 P1 B2 P2 B3 P2 B4 P5

STOC

Produs* P1 P2

Fig. 4.2.4.5.1.4.1 Structura CERERE - STOC

Sa consideram Întrebarea: Care sunt Beneficiarii cu cerere maxima de Produse care pot fi satisfacuti? Raspuns:

o In expresie de Algebra Relationala:

REZULTAT = CERERE / STOC

o In exprimare extensionala Rezultatul e reprezentat în Fig. 4.2.4.5.1.4.2:

REZULTAT Beneficiar*

B1 B2

Fig. 4.2.4.5.1.4.2 Rezultatul Beneficiarii care au cerut toate Produsele din STOC

• Proprietatile operatorului sunt:

o este un operator binar

o este un operator necomutativ

o Lista de Atribute reprezinta DIFERENTA dintre Listele de Atribute ale Relatiilor Initiale

o gradul relatiei Rezultat este egal cu diferenta gradelor Relatiilor Initiale

o numarul de tuple în Rezultat este mai mic sau egal cu numarul tuplelor din proiectia primei Relatii Initiale pe Atributele Necomune

Modele de Date / Modelul Relational / Manipularea Datelor 257

4.2.4.5.1.4 Set Complet de Operatori Relationali

Un Set Complet de Operatori Relationali este reprezentat de orice Submultime de Operatori Relationali care au proprietatea ca oricare Operator Relational necuprins în Set poate fi exprimat ca o Secventa de Operatori cuprinsi în Set. Exista mai multe asemenea Seturi. Un exemplu reprezentativ de Set Complet de Operatori Relationali este submultimea de Operatori Relationali din Fig. 4.2.4.5.1.4.1:.

- SELECTIE σ - PROIECTIE π - REUNIRE ρ - DIFERENTA - - PRODUS CARTEZIAN x

Fig. 4.2.4.5.1.4.1 Set Complet de Operatori Relationali

Cu ajutorul operatorilor din Setul anterior pot fi exprimati toti ceilalti operatori. Se dau mai jos doua asemenea exemple:

Exemplul 1: Operatorul de INTERSECTIE poate fi exprimat astfel:

R1 ∩ R2 = (R1 ∪ R2 ) - (R1 - R2 ) ∪ (R2 - R1 )

Exemplul 2: Operatorul de Reuniune poate fi exprimat astfel:

R1 ρ (Condition) R2 = σ ( Condition) (R1 x R2 ) 4.2.4.5.1.5 Sintaxa unui LMD bazat pe Algebra Relationala

Prezentam în continuare un Limbaj de Manipulare a Datelor bazat pe Algebra Relationala, care evita folosirea Simbolurilor din Expresiile Relationale pe pozitia de Operatori Relationali, în intentia de a construi un limbaj mai prietenos cu utilizatorii. Pentru aceasta s-au operat înlocuirile de simboluri din tabelul 4.2.4.5.1.5. Asa dupa cum se va vedea, restul simbolurilor sunt înlocuite cu mnemonicele deja prezentate. Se face mentiunea ca în limbajul prezentat parantezele drepte nu indica elemente optionale, ci reprezinta elemente de limbaj. Asa dupa cum se va vedea, restul simbolurilor sunt înlocuite cu mnemonicele deja prezentate.

Nume Operator Simbol în Expresii Clauza de Limbaj

SELECTIE σ WHERE expresie booleana

PROIECTIE π [lista-atribute]

Tab. 4.2.4.5.1.5.1 Corespondente Simboluri de Expresii – Clauze de Limbaj

258 Modele de Date / Modelul Relational / Manipularea Datelor

Sintaxa prezentata în Fig. 4.2.4.5.1.5 foloseste expresiile de rescriere în format BNF (Backus Normal Form).

- comanda-algebrica → definire-sinonim

→ atribuire

- definire-sinonim → nume-sinonim ALIASES nume-relatie

- atribuire → nume-relatie [lista-atribute] := expresie-algebrica

- lista-atribute → identificator-atribut

→ identificator-atribut, lista-atribute

- identificator-atribut → nume-atribut

→ nume-relatie.nume-atribut

→ nume-sinonim.nume-atribut

- expresie-algebrica → selectie

→ proiectie

→ operatie-infixata

- selectie → primitiva WHERE expresie-booleana

- primitiva → nume-relatie

→ nume-sinonim

→ (expresie-algebrica)

- proiectie → primitiva

→ primitiva [lista-atribute]

- operatie-infixata → proiectie operator-infixat proiectie

- operator-infixat → UNION

→ INTERSECT

→ MINUS

→ TIMES

→ JOIN

→ DIVIDEBY

- expresie-booleana → (combinatie-booleana-de-comparatii)

- comparatie → identificator-atribut operatie-de-comparare identificator-valoare

Fig. 4.2.4.5.1.5.1 Definirea în Sintaxa BNF a unui LMDR bazat pe Algebra Relationala

Modele de Date / Modelul Relational / Manipularea Datelor 259

4.2.4.5.1.6 Limbajul de Navigare si Operatorii Algebrei Relationale

In cele ce urmeaza se prezinta o transcriere în Limbaje Procedurale a Operatorilor Specific Relationali. Aceasta prezentare va fi reluata în detaliu atunci când se va trata problema extensiei Modelelor de Date, prin adaugarea la functia traditionala de descriere a Structurii si pe cea de descriere a Restrictiilor, precum si a Operatiilor (vezi sectiunea 4.2.4.10.2). La aceasta prima prezentare se urmareste doar motivarea interesului practic pe care cunoasterea Operatorilor Algebrei Relationale o prezinta pentru toti proiectantii si utilizatorii de Structuri Relationale, si în cazul în care SGBD-ul preferat e orientat spre Prelucrari Procedurale. Chiar si atunci când nu se foloseste descrierea Cererilor prin Expresii de Algebra Relationala, corespondentele prezentate introduc o disciplina necesara în Prelucrarea Procedurala a Structurilor Relationale, prin educarea gândirii structurale si în construirea procedurilor. Avantajele unei asemenea abordari sunt:

- Scurtarea duratei de proiectare

- Cresterea gradului de control al procedurilor

Transcrierea Procedurala a Operatorilor de Selectie, Proiectie si Reunire e data mai jos:

Operator – de - Selectie SCANEAZA relatia PENTRU < conditie de selectie > comenzi SFARSIT SCANARE

Operator – de - Proiectie

SCANEAZA relatia comenzi < lista de atribute > SFARSIT SCANARE

Operator – de - Reunire

SCANEAZA relatia1 SCANEAZA relatia2 PENTRU < conditie de reunire > comenzi SFARSIT SCANARE

comenzi SFARSIT SCANARE

Fig. 4.2.4.5.1.6.1 Implementarea procedurala a operatorilor Specific Relationali

Se remarca prezenta celor trei elemente esentiale pentru implementarea operatorilor relationali cu ajutorul carora se construiesc relatiile Rezultat:

o Conditiile de Selectie

o Listele de Atribute

o Conditiile de Reunire (Cuplare)

Exemple: Fie urmatoarele Întrebari adresate Structurii Relationale din Fig. 5.1.3.1.2.3.1:

260 Modele de Date / Modelul Relational / Manipularea Datelor

Exemplul 1: Numele BENEFICIARILOR care au contractat PRODUSUL ‘P2’?

- Solutie în pasi utilizând rezultatele Intermediare R1 si R2:

R1 = π (BENEFICIAR.Nume,CONTRACT.Produs) (BENEFICIAR ρ < BENEFICIAR.Cod=CONTRACT.Beneficiar > CONTRACT)

R2 = σ < R1. Produs =’P2’ >(R1)

R = π < R2. Nume >(R2)

- Solutie directa, într-un singur pas:

R = π < BENEFICIAR. Nume >(σ < CONTRACT.Produs =’P2’ (BENEFICIAR ρ < BENEFICIAR.Cod=CONTRACT.Beneficiar > CONTRACT))

Exemplul 2: Codul BENEFICIARILOR care au contractat cel putin un PRODUS de Culoare ‘rosie’?

R = π < CONTRACT. Beneficiar >(σ < PRODUS.Culoare =’rosu’ (PRODUS ρ < PRODUS.Cod=CONTRACT.Produs > CONTRACT))

Exemplul 3: Numele BENEFICIARILOR care au contractat toate PRODUSELE?

R = ((π < CONTRACT. Beneficiar,CONTRACT.Produs >CONTRACT) \ (π < PRODUS.Cod> PRODUS))

ρ < BENEFICIAR.Cod=CONTRACT.Beneficiar > (CONTRACT)

Exemplul 4: Numele perechilor de BENEFICIARI care locuiesc în acelas Oras?

B1 ALIASES BENEFICIAR

B2 ALIASES BENEFICIAR

R = (π < B1. Nume, B2. Nume >(B1 ρ < B1.Oras=B2.Oras and B1.Cod ≠ B2.Cod > B2)

4.2.4.5.1.7 Tipuri de SGBD-uri Relationale

Redam mai jos câteva concluzii legate de Limbajului de Manipulare bazat pe Algebra Relationala:

o Este putin familiar Utilizatorului Final confruntat adesea cu dificultatea de decizie în ceea ce priveste Corectitudinea Expresiilor pe care le utilizeaza

o Se impune ca un mijloc de evaluare a Completitudinii Relationale a altor limbaje

o Ramâne un punct de sprijin pentru cercetari în multe domenii legate de Proiectarea si Utilizarea Structurilor Relationale:

• Optimizarea Structurilor Relationale

• Alegerea Vederilor în Bazele de Date Relationale

• Adaptarea Structurilor Relationale la cerinte modificate

• Optimizarea Cererilor adresate Bazelor de Date Relationale

Modele de Date / Modelul Relational / Manipularea Datelor 261

Având în vedere rigurozitatea de definire a Limbajului de Manipulare bazat pe Algebra Relationala, el ramâne un punct de referinta în evaluarea performantelor de implementare a Sistemelor de Gestiune a Bazelor de Date Relationale. Se definesc ca urmare doua tipuri reprezentative de SGBD-uri Relationale (SGBDR):

o Complet Relationale – SGBDR-uri care ofera:

§ Limbaj de Definire a Structurilor Relationala de Date

• Descriere Domenii

• Descriere Chei

• Declarare Reguli de Integritate

§ Limbaj de Manipulare a Datelor Relationale cel putin atât de puternic ca si cel bazat pe Algebra Relationala (care permite redactarea unei singure Expresie de Calcul pentru aflarea Rezultatului oricarei Cereri).

o Semirelationale – SGBD-uri care ofera:

§ Limbaj de Definire a Structurilor Relationala de Date (cu elementele definite mai sus)

§ Limbaj de Manipulare a Datelor Relationale mai putin puternic ca si cel bazat pe Algebra Relationala

4.2.4.5.2 Metoda bazata pe Calculul Relational

Calculul Relational este o metoda de definire a unei Relatii Rezultat pornind de la o Colectie de Relatii Initiale si a unui Limbaj Logic de Specificare. Din aceasta definitie rezulta faptul ca metoda bazata pe Calculul Relational conduce la Limbaje de Specificare, deci la Limbaje Neprocedurale, denumite datorita acestor caracteristici si Limbaje de Nivel Înalt (indica CE trebuie obtinut nu si CUM trebuie procedat).

Stimulat de puterea de prelucrare a Limbajelor Neprocedurale, interesul cercurilor de specialisti a determinat în scurt timp adoptarea lor ca instrument principal de Manipulare a Structurilor Relationale. Dupa anul 1974, odata cu recunoasterea Sistemului R ca primul Prototip de SGBD Relational au fost emise o serie de standarde succesive, menite sa unifice accesul la Bazele de Date Relationale în produsele comerciale. 4.2.4.5.2.1 Limbajul Logic

Înainte de a defini elementele si constructiile utilizate în cele doua forme de implementare ale Calculului Relational: Calculul Tuplelor (CRT) si Calculul Domeniilor (CRD), vom face o scurta prezentare intuitiva a Limbajului Logic, care sta la baza celor doua forme de generare prin specificare a unor noi relatii, privite ca Multimi definite de Predicate asociate.

Limbajului Logic se preocupa de constructia si clasificarea Enunturilor. Elementele utilizate în acest scop sunt continute în Tab. 4.2.4.5.2.1. Utilizând Operatiile Logico-Lingvistice Enunturile pot fi transformate dintr-un tip în altul (vezi Fig. 4.2.4.5.2.1.2).

Modele de Date / Modelul Relational / Manipularea Datelor 262

Determinat

CONSTANTA

LIBERA (fara

cuantificatori)

SUBIECT (univers de discurs)

- 1 Subiect ∈ MULTIME - n Subiecte ∈ RELATIE

Nedeterminat

VARIABILA

LEGATA (cu

cuantificatori) cu

Subiect Determinat

PROPOZITIE

ENUNT

PREDICAT (proprietate) cu

Subiect Nedeterminat

PREDICAT

Tab. 4.2.4.5.2.1.1 Structura Enuntului în Limbajul Logic

Modele de Date / Modelul Relational / Manipularea Datelor 263

Fig. 4.2.4.5.2.1.2 Structura Enuntului în Limbajul Logic

NEGATIA ¬

CONJUNCTIA ∩

DISJUNCTIA ∪

IMPLICATIA ⇒

Operatori LOGICI

ECHIVALENTA ⇔

EXISTENTIALI

∃

Operatori Logico-Lingvistici

CUANTIFICATORI UNIVERSALI

∀

Tab. 4.2.4.5.2.1.3 Clasificarea Operatorilor Logico- Lingvistici

Enunturi Initiale

Operatii Logico-Linvistice

PROPOZITII

Limbajul LOGICII

PROPOZITIILOR

PREDICATE Limbajul LOGICII

PREDICATELOR

Enunturi Finale

264 Modele de Date / Modelul Relational / Manipularea Datelor

Operatorii Logico-Lingvistici care pot fi utilizati sunt prezentati în Tab. 4.2.4.5.2.1.3. Folosind termenii introdusi anterior se trece la descrierea formala generala a Relatiei (vezi Fig. 4.2.4.5.2.1.4). Se apeleaza la acelasi formalism bazat pe expresii de rescriere în format BNF. Sunt utilizate de asemenea urmatoarele simboluri:

– simbol pentru Multime (Multime de Tuple)

: - simbol de legatura ”astfel încât”

- relatie → tupla-logica : predicat

- tupla-logica → (lista-atribute)

- lista-atribute → nume-relatie, lista-atribute

→ nume-relatie. nume-atribut, lista-atribute

- predicat → proprietate

→ cuantificator (expresie-de-calcul-predicate)

→ cuantificator (predicat)

- expresie-de-calcul-predicate → expresie-de-calcul-a-tuplelor

→ expresie-de-calcul-al-domeniilor

Fig. 4.2.4.5.2.1.4 Descrierea formala a Relatiei

Pentru definirea termenilor: Expresie-de-Calcul-al-Tuplelor (ECT) si Expresie-de-Calcul-al-Domeniilor (ECD), se face trimitere la sectiunile ce urmeaza. 4.2.4.5.2.2 Calculul Relational al Tuplelor

Calculul Relational al Tuplelor (CRT) alege ca Univers de Discurs Multimile de Tuple din Relatiile Initiale, de unde vor fi extrase elementele Expresiilor de Calcul Relational (ECR). Se prezinta în continuare succint constructiile unui asemenea limbaj (pentru detalii vezi sectiunea 5.1.1). 4.2.4.5.2.2.1 Elementele Expresiilor în CRT

o Variabilele de Tuple– Variabile ce inspecteaza multimea Tuplelor unei Relatii Exemple:

• X – Tupla X

• X.A – Valoarea Atributului A în Tupla X

o Conditii – Expresii Booleene având ca elemente: Constante, Variabile si Operatori Logici

§ x1 OC x2 – unde:

• x – este:

Modele de Date / Modelul Relational / Manipularea Datelor 265

o Constanta

o Atribut din Relatie (X.A)

• OC – este Operator de Comparatie (=, <, >, .. )

o Formule Bine Construite (FBC) – Expresii cu urmatoarele proprietati:

§ Contin ca elemente:

• Conditii

• Operatori Logici

• Cuantificatori

§ Respecta urmatoarele Reguli:

• Orice Conditie e FBC

• Daca f e FBC, atunci:

o ( f ) – e FBC

o NOT ( f ) e FBC

• Daca f si g sunt FBC, atunci:

o (f AND g) – e FBC

o (f OR g) – e FBC

• Daca f e FBC si X e Variabila Libera, atunci:

o ∃ X ( f ) – e FBC

o ∀ X ( f ) – e FBC

• Nimic altceva nu e FBC 4.2.4.5.2.2.2 Variabile Libere si Legate

Variabilele Libere sunt Variabile Necuatificate pe când cele Legate sunt Cuantificate. Prezenta Cuantificatorilor determina modul de inspectie al Universului de Discurs. Pentru o mai buna întelegere a semnificatiei Tipului de Variabila de Tupla redam mai, jos în descriere procedurala, modul de inspectie a Multimii de Tuple pentru cele trei cazuri privind raportul dintre Variabile si Cuantificatori:

o Variabila Libera – Necuantificata (Fig. 4.2.4.5.2.2.2.1) Se remarca faptul în acest caz Multimea de Tuple este parcursa integral, indiferent de rezultatul de test al Conditiei. Procedura care se executa va determina Submultimea de Tuple care verifica Conditia.

o Variabila Legata – Cuantificata In acest al doilea caz Procedurile atasate determina doar validilitatea Cuantificatorului, care va fi ulterior interpretata la evaluarea Expresiei de Calcul Relational. Modul de inspectie al Multimii de Tuple difera însa si acum în functie de natura Cuantificatorului testat, si anume:

266 Modele de Date / Modelul Relational / Manipularea Datelor

§ Variabila Cuantificata Existential (Fig. 4.2.4.5.2.2.2.2) In cazul Cuantificatorului Existential se testeaza prezenta unei singure Tuple care verifica Conditia, caz în care se paraseste inspectia raspunzându-se Adevarat (exista o Tupla care verifica Conditia). Numai daca inspectia nu gaseste nici-o Tupla care sa verifice Conditia, procedura se paraseste cu raspunsul Fals.

§ Variabila Cuantificata Universal (Fig. 4.2.4.5.2.2.2.3) In cazul Cuantificatorului Universal tratamentul se inverseaza, în sensul ca, se testeaza prezenta unei singure Tuple care nu verifica Conditia, caz în care se paraseste inspectia raspunzându-se Fals. Numai daca inspectia nu gaseste nici-o Tupla care sa nu verifice Conditia, procedura se încheie cu raspunsul Adevarat (toate Tuplele verifica Conditia). Asemanarea procedurilor pentru Variabilele Legate permit verificarea expresiei de transformare a Cuantificatorilor Universali în Existentiali si vice-versa:

∃ X (P) ≡ ∀X (¬ P)

PROCEDURA variabila-libera REPETA pentru toate Tuplele-din-Multime

DACA conditie EXECUTA Introducere-Tupla-în-Rezultat

SFARSIT-CONDITIE SFARSIT-REPETITIE

SFARSIT-PROCEDURA

Fig. 4.2.4.5.2.2.2.1 Procedura de inspectie pentru Variabile Libere

PROCEDURA variabila-cuantificata-existential REPETA pentru toate Tuplele-din-Multime

DACA conditie EXECUTA Raspuns-Adevarat IESIRE

SFARSIT-CONDITIE SFARSIT-REPETITIE

EXECUTA Raspuns-Fals SFARSIT-PROCEDURA

Fig. 4.2.4.5.2.2.2.2 Procedura de inspectie pentru Variabile Cuantificate Existential

PROCEDURA variabila-cuantificata-universal

REPETA pentru toate Tuplele-din-Multime DACA NON conditie

EXECUTA Raspuns-Fals IESIRE

SFARSIT-CONDITIE SFARSIT-REPETITIE

EXECUTA Raspuns-Adevarat SFARSIT-PROCEDURA

Fig. 4.2.4.5.2.2.2.3 Procedura de inspectie pentru Variabile Cuantificate Universal

Modele de Date / Modelul Relational / Manipularea Datelor 267

In continuare se prezinta regulile de propagare a Naturii Variabilelor în Expresiile Calculului Relational:

o Intr-o Conditie toate Variabilele de Tuple (VT) sunt Variabile Legate

o Variabilele de Tuple (VT) în constructiile FBC de tipul:

• ( f )

• NOT ( f )

sunt Libere sau Legate dupa cum sunt în f.

o Variabilele de Tuple (VT) în constructiile FBC de tipul:

• ( f AND g )

• ( f OR g )

sunt Libere sau Legate dupa cum sunt în f sau în g.

o Variabilele de Tuple (VT) în constructiile FBC de tipul:

• ∃ X ( f )

• ∀ X ( f )

sunt Legate indiferent cum sunt în f. 4.2.4.5.2.2.3 Expresii de Calcul Relational al Tuplelor

O Expresie de Calcul Relational (ECR) în CRT are forma:

X.A, Y.B, .. , Z,C [ WHERE f ]

unde:

- X, Y, .. , Z – sunt Variabile de Tuple

- A, B, .. , C – sunt Atribute

- f – este FBC

Cu alte cuvinte: ECR în CRT este o Proiectie pe A, B, .. , C a Selectiei care verifica conditia f, din Produsul Cartezian X x Y x .. x Z.

Nota Bene !

o Produsul Cartezian se face cu Tuplele identificate de Variabilele de Tuple X x Y x .. x Z

o Formula f joaca simultan rolurile de:

§ Conditie de Selectie pentru determinarea valorilor Variabilelor de Tuple

§ Conditie de Reunire pentru definirea unei submultimi a Produsului Cartezian

o Proiectia se face pe Lista de Atribute A, B, .. , C

268 Modele de Date / Modelul Relational / Manipularea Datelor

4.2.4.5.2.2.4 Implementare Calcului Relational al Tuplelor 4.2.4.5.2.2.4.1 Exemple de ECT

Ca exemplu de implementare a CRT se prezinta Limbajul Experimental ALPHA ca fiind cel mai aproape de utilizarea directa a ECR în CRT. Limbajul ALPHA e Complet Relational.

Conventii de limbaj:

- Comanda GET – transfera date din Baza de Date în Memoria Interna

- Comanda PUT – transfera date din Memoria Interna în Baza de Date

- Se considera urmatoarele ALIAS-uri pentru Relatiile din Baza de Date:

§ B – pentru BENEFICIAR

§ P – pentru PRODUS

§ C – pentru CONTRACT

- M, M1, M2 – Zone de Lucru în Memoria Interna (Tampoane)

- RANGE nume-relatie nume-variabila-de-tupla – atasarea unei Variabile de Tupla unei Relatii

Se prezinta în continuare un set de exemple de operatii în Limbajul ALPHA, utilizând Structura Relationala BENEFICIAR, PRODUS, CONTRACT (vezi Fig. 5.1.3.1.2.3.1).

o Operatii de Regasire

§ Regasire Relatie Atributele pentru toti BENEFCIARII:

GET M (B)

§ Regasire Lista de Atribute Codurile pentru toti BENEFCIARII:

GET M (B.Cod)

§ Regasire Filtrata (cu Predicat) Codurile pentru toti BENEFCIARII din Orasul ‘O1’ având Tipul ‘T3’ :

GET M (B.Cod) : B.Oras = ‘O1’ AND B.Tip = ‘T3’

§ Regasire Filtrata si Ordonata Numele pentru toti BENEFCIARII din Orasul ‘O1’ crescator dupa Nume’ :

GET M (B.Nume) : B.Oras = ‘O1’ UP B.Nume

§ Regasire Ordinala Codul primului BENEFCIAR (memorat) din Orasul ‘O1’:

GET M (1) (B.Cod) : B.Oras = ‘O1’

Modele de Date / Modelul Relational / Manipularea Datelor 269

§ Regasire Ordinala si Ordonata Codul primului BENEFCIAR (memorat) din Orasul ‘O1’, având Tipul cel mai mare ( în ordine lexicografica descrescatoare):

GET M (1) (B.Cod) : B.Oras = ‘O1’ DOWN B.Tip

§ Regasire cu Variabila de Adresa Codul BENEFCIARILOR care au contractat PRODUSUL cu Codul ‘P1’: Solutia 1:

GET M (C.Beneficiar) : C.Produs = ‘P1’

Solutia 2:

RANGE C X

GET M (X.Beneficiar) : X.Produs = ‘P1’

§ Regasire cu Predicat cuantificat Existential Numele BENEFCIARILOR care au contractat PRODUSUL cu Codul ‘P1’:

RANGE C X

GET M (B.Beneficiar) : ∃ X (X. Beneficiar = B.Cod AND X.Produs = ‘P1’

§ Regasire cu Predicat cuantificat Existential multiplu Numele BENEFCIARILOR care au contractat cel putin un PRODUS de Culoare rosie: Solutie 1:

RANGE P X

RANGE C Y

GET M (B.Beneficiar) : ∃ Y (Y. Beneficiar = B.Cod AND

∃ X (Y. Produs = X.Cod AND X.Culoare = ‘rosu’)

Solutie 2: In a doua varianta, utilizând aceleasi Variabile de Tuple, se normalizeaza forma de exprimare a Predicatului prin gruparea cuantificatorilor (forma normala prefixata – PRE NEX)

GET M (B.Beneficiar) : ∃ X ∃ Y (Y. Beneficiar = B.Cod AND

Y. Produs = X.Cod AND X.Culoare = ‘rosu’)

§ Regasire cu combinare de atribute din mai multe relatii Exemplul 1: Numele BENEFCIARILOR si Numele PRODUSELOR contractate de acestia:

GET M (B.Nume, P.Nume) : B.Cod=C. Beneficiar AND P.Cod=C.Produs)

270 Modele de Date / Modelul Relational / Manipularea Datelor

Exemplul 2: Numele BENEFCIARILOR si Codul PRODUSELOR care se afla în acelasi Oras:

GET M (B.Nume, P.Cod) : B.Oras=P.Oras

§ Regasire cu Predicat cuantificat Universal Numele BENEFCIARILOR care nu au contractat PRODUSUL cu Codul ‘P1’:

RANGE C X

GET M (B.Nume) : ∀ X (X. Beneficiar ≠ B.Cod OR X. Produs ≠ ‘P1’)

§ Regasire cu Predicat cuantificat Existential si Universal Numele BENEFCIARILOR care au contractat toate PRODUSELE:

RANGE P X

RANGE C Y

GET M (B.Nume) : ∀ X ∃ Y (Y. Beneficiar = B.Cod AND X. Produs = X.Cod)

Observatie: Ordinea cuantificatorilor e în acest caz critica.

o Operatii de Memorare Operatiile de Memorare nu prezinta interes pentru fizionomia ECR în CRT. De aceea se fac doar câteva observatii:

§ Actualizarea Zonei de Lucru din Memoria Interna se face cu ajutorul comenzilor din Limbajul Gazda

§ Pentru transferul efectiv MI → BD se foloseste comanda Put

§ Comenzile de Stergere (DELETE) si Modificare (UPDATE) se bazeaza pe o comanda prealabila de Regasire

§ Pentru a asigura multiaccesul în regim de Actualizare se utilizeaza comenzi de Blocare / Deblocare (HOLD / Release)

4.2.4.5.2.2.4.2 Limbajul SQL

Lansat în cadrul primului SGBD Relational, Sistemul R (1974 – 1979), Limbajul SQL, cu acronimul construit din Structure Quey Language, a devenit cel mai raspândit Limbaj Neprocedural de Manipulare a Structurilor Relationale. Supus unor actiuni succesive de standardizare el s-a constituit într-o componenta de referinta a tuturor produselor comerciale lansate pe piata SGBD-urilor. Din motive de informare, prezentarea este si de data aceasta grupata în doua sectiuni:

- Operatii de Regasire

- Operatii de Actualizare

Modele de Date / Modelul Relational / Manipularea Datelor 271

cu toate ca elementele de definire a Limbajului Predicativ de tip CRT este continut integral în Operatiile de Regasire.

o Operatii de Regasire

Constructia Operatiilor de Regasire au la baza structura Blocului SELECT având principalele Clauze cele prezentate în Fig. 4.2.4.5.2.2.4.2.1.

SELECT [UNIQUE] lista-attribute 1 FROM lista-relatii WHERE conditie ORDER BY lista-atribute 2

Semnificatia Elementelor Variabile ale Blocului

lista-attribute 1 – Lista Atributelor de Proiectie lista-relatii – Lista Relatiilor Initiale conditie – Conditiile de:

o Selectie – Termenii din Conditie care contin numai Atribute dintr-o singura Tupla

o Reunire - Termenii din Conditie care contin Atribute din mai multe Tuple

lista-attribute 2 – Lista Atributelor de Ordonare a Rezultatului

Fig. 4.2.4.5.2.2.4.2.1 Structura Blocului SELECT Nota Bene !

Comanda SELECT din Calculul Relational difera de Comanda SELECT din Algebra Relationala prin faptul ca:

- In Algebra Relationala - Termenii din Conditia de Selectie contin numai Atribute dintr-o singura Tupla

- In Calculul Relational - Termenii din Conditia de Selectie pot contine Atribute din mai multe Tuple, jucând în acest caz rol dublu:

o Conditie de Selectie

o Conditie de Reunire

Exemple:

§ Regasire Relatie Atributele pentru toti BENEFCIARII:

SELECT *

FROM B

Simbolul * invoca întreaga Lista de Atribute de Definitie.

§ Regasire Lista de Atribute Codurile pentru toti BENEFCIARII:

272 Modele de Date / Modelul Relational / Manipularea Datelor

SELECT Cod

FROM B

§ Regasire Filtrata (cu Predicat) Codurile pentru toti BENEFCIARII din Orasul ‘O1’ având Tipul ‘T3’ :

SELECT Cod

FROM B

WHERE Oras = ‘O1’ AND Tip = ‘T3’

§ Regasire Filtrata si Ordonata Numele pentru toti BENEFCIARII din Orasul ‘O1’ crescator dupa Nume’:

SELECT Nume

FROM B

WHERE Oras = ‘O1’

ORDER BY Oras

§ Regasire Ordinala Codul primului BENEFCIAR (memorat) din Orasul ‘O1’:

SELECT FIRST Cod

FROM B

WHERE Oras = ‘O1’

§ Regasire Ordinala si Ordonata Codul primului BENEFCIAR (memorat) din Orasul ‘O1’, având Tipul cel mai mare ( în ordine lexicografica descrescatoare):

SELECT Cod

FROM B

WHERE Oras = ‘O1’

ORDER BY DESCENDING Tip

§ Regasire din mai multe Tabele Codul BENEFCIARILOR care au contractat PRODUSUL cu Codul ‘P1’:

SELECT Cod

FROM B, C

WHERE C.Codp = ‘P1’ Codul PRODUSELOR contractate si Orasele din care se livreaza:

SELECT UNIQUE Cod, Oras

FROM P, C

Modele de Date / Modelul Relational / Manipularea Datelor 273

WHERE C.Codp = P.Cod

Clauza UNIQUE determina retinerea în Rezultat a unei singure Tuple pentru fiecare Valoare diferita de Oras.

§ Regasire cu Predicat cuantificat Existential (Operatorul ANY) Numele BENEFCIARILOR care au contractat PRODUSUL cu Codul ‘P1’: Solutie 1:

SELECT UNIQUE Nume

FROM B, C

WHERE B.Cod = C.Codb AND C.Codp = ‘P1’ Solutie 2:

SELECT Nume

FROM B

WHERE B.Cod = ANY ( SELECT Codb

FROM C

WHERE C.Codb AND C.Codp = ‘P1’)

Operatorul ANY desemneaza oricare din Multimea de Tuple care satisface Conditia impusa în al doilea SELECT. La prima verificare a conditiei din primul SELECT cautarea se încheie.

§ Regasire cu Predicat cuantificat Existential (Operatorul IN) Numele BENEFCIARILOR care au contractat PRODUSUL cu Codul ‘P1’:

SELECT Nume

FROM B

WHERE B.Cod = IN ( SELECT Codb

FROM C

WHERE C.Codb AND C.Codp = ‘P1’)

Operatorul IN este echivalent cu ANY si desemneaza o Tupla (prima) care satisface Conditia impusa în al doilea bloc SELECT.

§ Regasire cu Predicat cuantificat Existential (Operatorul EXISTS) Numele BENEFCIARILOR care au contractat PRODUSUL cu Codul ‘P1’:

SELECT Nume

FROM B

WHERE EXISTS ( SELECT Codb

FROM C

WHERE Codb = B.Cod AND C.Codp = ‘P1’)

Operatorul EXISTS returneaza Valoarea Logica:

274 Modele de Date / Modelul Relational / Manipularea Datelor

o Adevarat daca Multimea de Tuple returnata de blocul SELECT urmator este NEVIDA

o Fals daca Multimea de Tuple returnata de blocul SELECT urmator este VIDA

§ Regasire cu Cereri multiplu continute Numele BENEFCIARILOR care au contractat cel putin un PRODUS de Culoare rosie:

SELECT Nume

FROM B

WHERE B.Cod = IN ( SELECT Codb

FROM C

WHERE Codp IN (SELECT Cod

FROM P

WHERE P.Cod = ‘rosu’)

§ Regasire cu referinta interblocuri Numele BENEFCIARILOR care au contractat PRODUSUL cu Codul ‘P1’:

SELECT Nume

FROM B

WHERE ‘P1’ = IN ( SELECT Codp

FROM C

WHERE Codb = B.Cod)

In Clauza WHERE din al doilea SELECT Atributul Codb e calificat implicit de C, dar Atributul Cod trebuie calificat cu Numele Relatiei din primul bloc SELECT, B.

Codul unui BENEFCIAR care a contractat cel putin un PPRODUS contractat de BENEFICIARUL cu Codul ‘B2’:

SELECT Codb

FROM C

WHERE Codp = IN ( SELECT Codp

FROM C

WHERE Codb = ‘B2’)

De aceasta data transmiterea contextului nu e necesara întrucât Contextele Locale din cele doua comenzi SELECT imbricate, desi diferite, actioneaza doar local (în interiorul comenzii SELECT în care au fost introduse prin Clauza FROM.

Modele de Date / Modelul Relational / Manipularea Datelor 275

Codurile PRODUSELOR contractate de mai mult de un BENEFCIAR:

SELECT UNIQUE Codp

FROM C

WHERE Codp = IN ( SELECT Codp

FROM CX

WHERE C.Codb ¬ = CX.Codb)

De aceasta data transmiterea contextului este necesara datorita referintei inter-blocuri. Contextul Local CX din Clauza WHERE al celui de al doilea bloc SELECT trebuie înlocuit cu Contextul anterior C.

Se pot remarca aici doua tipuri de Contexte (ca în general în Structurile de Date):

o Context Logic - dat de Tabela (Relatia) referita (C si CX au acelasi Context Logic, caci refera ambele Tabela CONTRACT)

o Context Fizic - dat de Tupla referita; C si CX au Contexte Fizice diferite, referind Tuple diferite, deoarece aceeasi Tabela, CONTRACT, e deschis a si inspectata diferit, de doua ori, odata ca si C, apoi ca si CX, pentru a se realiza Produsul Cartezian de Tuple)

§ Regasire cu Predicat cuantificat Universal Numele BENEFCIARILOR care nu au contractat PRODUSUL cu Codul ‘P1’:

SELECT Nume

FROM B

WHERE ‘B2’ ¬ = ALL ( SELECT Codp

FROM CX

WHERE Codb = B.Codb)

Operatorul (¬ = ALL) este echivalent cu ( NOT IN ) si desemneaza absenta unei Valori din Multimea selectata de Conditia impusa în al doilea bloc SELECT.

§ Regasire cu Operatorul UNION (Reuniune de Tuple)

Codurile PRODUSELOR care au Greutatea mai mare decat ‘G1’ sau sunt contractate de BENEFCIARUL cu Codul ‘P2’:

SELECT Cod

FROM P

WHERE Grutate > ‘G1’

UNION

276 Modele de Date / Modelul Relational / Manipularea Datelor

SELECT Codp

FROM C

WHERE C.Codp = ‘P2’

o Operatii de Actualizare Operatiile de Actualizare nu prezinta interes pentru fizionomia ECR în CRT. De aceea se fac doar câteva prezentari de asemenea operatii:

§ Adaugare (Inserare) Tupla

INSERT INTO P

< ‘P6’, ‘D6’, ‘G1’, ‘C3’, ‘O2’ >

§ Modificare Tupla

UPDATE P

SET Culoare = ‘C4’

SET Culoare = NULL

WHERE Cod = ‘P1’

NULL – reprezinta valoarea nula.

§ Modificare multime de Tuple

UPDATE B

SET Tip = ‘T1’

WHERE Oras = ‘O1’

§ Stergere Tabela

DROP C

§ Stergere Tupla

DELETE C

WHERE Codb = ‘B1’AND Codp = ‘P1’

§ Stergere multime de Tuple

DELETE C

WHERE Codb = ‘B1’ Concluzii:

- Limbajul SQL e Complet Relational (orice Cerere adresata Bazei de Date poate fi exprimata printr-o singura Comanda SQL)

- Limbajul SQL a facut obiectul a numeroase Standardizari, cu efecte pozitive dar si negative:

o Se constituie în Limbaj Universal de Manipulare Relationala a Datelor

Modele de Date / Modelul Relational / Manipularea Datelor 277

o Este riguros definit în detaliu si facut public

o Inovatiile eventuale trebuie sa astepte validarea Comisiilor de Standardizare

- Limbajul SQL se preteaza la numeroase variante de utilizare si extensii posibile:

o Variante de utilizare

§ Limbaj Independent pentru Utilizatorii Finali

§ Limbaj încorporat în Limbaje Gazda

§ Limbaj pentru Administrarea Bazelor de Date

• Gestiunea Tabelelor Sistem

• Controlul Accesului la Date

• Transferul de Date

§ Componente de Software apartinând Sistemelor de Operare pentru accesarea Surselor de Date

§ Limbaj pentru încorporarea Restrictiilor si Operatiilor în Bazele de Date (alaturi de STRCTURA) – vezi sectiunea 4.2.4.7.

o Extensii posibile

§ Incorporarea Bibliotecilor de Functii

§ Clauze speciale pentru Editare Date

§ Facilitati de pregatire a Rapoartelor Finale

§ Introducerea facilitatilor de Prelucrare Procedurala (Extensia PL SQL)

4.2.4.5.2.3 Calculul Relational al Domeniilor

Calculul Relational al Domeniilor (CRD) alege ca Univers de Discurs Multimile de Valori din Domeniile pe care sunt definite Relatiile Initiale, si de unde vor fi extrase elementele Expresiilor de Calcul Relational (ECR). Constructiile primare în CRD sunt Expresiile de Calcul a Domeniilor (ECD). 4.2.4.5.2.3.1 Elementele Expresiilor în CRD

o Variabilele de Domeniu – Variabile ce inspecteaza multimea Valorilor unui Domeniu (denumirea mai adecvata, prin transcrierea Variabilelor de Tuple din CRT, ar fi Variabile de Elemente de Domeniu, deci Variabile de Valori). Denumirea Variabilelor de Domeniu se face prin alipirea Numelor de Variabile de Domenii la Numele de Domenii (punctul care în general este utilizat pentru calificarea numelor este omis)

278 Modele de Date / Modelul Relational / Manipularea Datelor

Exemplu:

• D X – Valoarea X din Domeniul D

o Conditii – Expresii Booleene având ca elemente: Constante, Variabile si Operatori Logici

§ Comparatii Simple

• x1 OC x2 – unde:

o x – este:

§ Constanta

§ Valoare de Domeniu (DX)

o OC – este Operator de Comparatie (=, <, >, .. )

§ Conditii cu Membri

• Forma

R (termen, termen, .. )

unde:

§ R – este Relatie

§ termen – este o pereche A : V cu:

• A – Atribut din Relatie

• V – Valoare

o Constanta

o Variabila de Domeniu

• Interpretare – Tuplele din Relatia R care satisfac toti Termenii (membrii) Conditiei

o Formule Bine Construite (FBC) – Expresii cu urmatoarele proprietati (identice cu cele din CRT):

§ Contin ca elemente:

• Conditii

• Operatori Logici

• Cuantificatori

§ Respecta urmatoarele Reguli:

• Orice Conditie e FBC

• Daca f e FBC, atunci:

o ( f ) – e FBC

o NOT ( f ) e FBC

Modele de Date / Modelul Relational / Manipularea Datelor 279

• Daca f si g sunt FBC, atunci:

o (f AND g) – e FBC

o (f OR g) – e FBC

• Daca f e FBC si X e Variabila Libera, atunci:

o ∃ X ( f ) – e FBC

o ∀ X ( f ) – e FBC

• Nimic altceva nu e FBC 4.2.4.5.2.3.2 Variabile Libere si Legate

Definirea Variabilele Libere si Legate este aceeasi ca în cazul CRT. Specifica ramâne doar atasarea lor la alte Multimi de Elemente din Domenii (Multimi de Valori) si nu la Multimi de Elemente din Relatii (Multimi de Tuple).

4.2.4.5.2.3.3 Expresii de Calcul Relational al Domeniilor

O Expresie de Calcul Relational (ECR) în CRD are forma:

D, E, .. ,F [ WHERE f ]

unde:

- D, E, .. , F – sunt Variabile de Domenii

- f – este FBC cu D, E, .. , F, Variabile Libere

Cu alte cuvinte: ECR în CRT este o Relatie Rezultat descrisa de f, în care sincronizarea Tuplelor din Relatiile de Intrare e data de Variabilele deDomeniu D, E, .. ,F.

Nota Bene !

o Produsul Cartezian se face cu Tuplele identificate de Variabilele de Domeniu D, E, .. ,F prin intermediul Conditiilor cu Termeni din f

o Formula f joaca simultan rolurile de:

§ Conditie de Selectie pentru determinarea valorilor Variabilelor de Tuple

§ Conditie de Reunire pentru definirea unei submultimi a Produsului Cartezian

§ Lista de Atribute de Proiectie data de Lista de Termeni din Conditiile continute în f

280 Modele de Date / Modelul Relational / Manipularea Datelor

4.2.4.5.2.3.4 Implementare Calcului Relational al Domeniilor 4.2.4.5.2.3.4.1 Exemple de ECD

Ca exemplu de implementare a Expresiilor de Calcul al Domeniilor (ECD) se prezinta câteva expresii într-un limbaj experimental, care îndeplineste conditiile de completitudine.

Vor fi prezentate exclusiv expresii de regasire. Se face de asemenea precizarea necesara ca în expresiile FBC din CRD se vor folosi Numele de Domenii declarate în Fig. 5.1.3.1.2.3.1.

§ Regasire Relatie Atributele pentru toti BENEFCIARII:

CodbX, NumebY, OrasZ, TipbV WHERE

B (Cod : CodbX, Nume : NumebY, Oras : OrasZ, Tip : TipbV)

§ Regasire Lista de Atribute Codurile BENEFCIARILOR si Codurile PRODUSELOR contractate de ei:

CodbX, CodpY WHERE C (Codb : CodbX, Codp : CodpY)

§ Regasire Filtrata Codurile pentru toti BENEFCIARII din Orasul ‘O1’ având Tipul ‘T3’ :

OrasX, TipbY WHERE B (Oras : OrasX, Oras : ‘O1’, Tip : TipbY, Tip : ‘T3’)

Numele si Orasele de resedinta ale BENEFCIARILOR care au contractat PRODUSUL cu Numele ‘N2’ :

NumebX, OrasY, NumepZ, CodbU, CodpV WHERE

B (Cod :CodbU, Nume : NumebX, Oras : OrasY) AND

P (Cod :CodpV, Nume : NumepZ, Nume : ‘N2’) AND

C (Codb : CodbU, Codp : CodpV)

§ Regasire cu Predicat cuantificat Existential Codurile si Orasele de resedinta ale BENEFCIARILOR care au contractat cel putin un PRODUS de Culoare rosie:

CodbX, OrasX WHERE (B(Cod : CodbX) AND P(Oras : OrasX))

∃ OrasX WHERE (B(Oras : OrasX) AND P(Oras : OrasX))

§ Regasire cu Predicat cuantificat Universal Numele BENEFCIARILOR care au sedii în toate Orasele :

∀ OrasX, NumebY WHERE B (Oras : OrasX, Nume : NumebY)

Modele de Date / Modelul Relational / Manipularea Datelor 281

4.2.4.5.2.3.4.2 Limbajul QBE Limbajul QBE, acronim pentru Query By Example – Interogare pe baza de Exemple,

a fost initiat de cercetatorul ZLOOF si dezvoltat In laboratoarele firmei IBM. Este cel mai reprezentativ exemplu de produs comercial pentru implementarea Limbajelor bazate pe Calculul Domeniilor.

Originalitatea lui consta în implementarea Calculului Domeniilor într-un Limbaj Bidimensional, considerând Limbajele Clasice ca Limbaje Unidimensionale.

Este foarte intuitiv, si prin aceasta prietenos cu utilizatorii (User Friendly), prin aceea ca permite utilizatorului sa-si descrie Cerintele direct în forma Rezultatului pe care-l asteapta. De asemenea nu impune utilizatorului decât cunostinte reduse în ceea ce priveste structura de detaliu a Sursei de Date pe care doreste sa o consulte.

Orientat pe prelucrarea interactiva, produsul permite construirea Rezultatului dorit prin modificari succesive ale cerintelor adresate initial.

Asa dupa cum arata si numele, produsul este orientat spre declararea Cererilor prin introducerea Valorilor din:

§ Listele de Atribute

§ Conditiile de Filtrare

§ Conditiile de Reunire direct în Tabelele Initiale, pe care sistemul de afiseaza cu tot continutul intensional, îndata dupa invocare.

Modul de operare este urmatorul:

- Se utilizeaza Taste Functionale atasate diferitelor Operatii de Baza

- Se utilizeaza Formate Automate afisate de sistem (Tabele)

- Se introduc Valori în aceste Tabele (în Linii si în Coloane), care sunt interpretate de sistem, ca si Conditii de Selectie sau Reunire

- Sistemul raspunde încarcând Tabela cu Valori din Sursa de Date, care corespund Valorilor introduse de Utilizator

Exemplu:

§ Utilizatorul introduce Numele Relatiei – Sistemul raspunde afisând Lista de Atribute de Definitie

§ Utilizatorul introduce Valorile din Conditiile de Filtrare – Sistemul raspunde afisând Tuplele care satisfac Conditia de Filtrare

§ Utilizatorul introduce Valorile din Conditiile de Reunire – Sistemul raspunde afisând Tabela Rezultat cu Lista de Atribute de Definitie împreuna cu Tuplele care satisfac Conditia de Reunire

Conventii de Limbaj:

- P.nume-Valoare-de-Exemplu – Afiseaza Valoare pe Coloana

- P. ALL – Afiseaza toate Valorile pe Coloane

- Vs–Introducere Valoare de Exemplu (s–Simbol de Identificare Valoare Variabila)

- V – Introducere Valoare Constanta

282 Modele de Date / Modelul Relational / Manipularea Datelor

§ Regasire Simpla Codul tuturor PRODUSELOR Contractate:

C Codb Codp Cantitate P. PX

Se remarca:

• Comanda de afisare P.

• Valoarea de Exemplu: PX (o Valoare Simbolica)

Toate Atributele BENEFICIARILOR:

B Cod Nume Tip Oras P. BX P. NY P. TZ P. OV

Sau mai simplu:

B Cod Nume Tip Oras P BX NY TZ OV

§ Regasire Filtrata Codul BENEFICIARILOR din Orasul ‘O1’ si având Tipul ‘T1’:

B Cod Nume Tip Oras P BX T1 O1

Codul BENEFICIARILOR din Orasul ‘O1’ sau având Tipul ‘T1’:

B Cod Nume Tip Oras

BX O1 P BY T1

Valorile de Exemplu diferite (BX , BY) pe aceeasi coloana, indica selectarea valorilor returnate din Tuple diferite. Codul BENEFICIARILOR din Orasul ‘O1’ si având Tipul >‘ T1’ si <‘T2’:

B Cod Nume Tip Oras

BX > T1 O1 P BX < T2

Valorile de Exemplu identice (BX) pe aceeasi coloana, indica selectarea valorilor returnate din aceeasi Tupla, permitându-e astfel combinarea Conditiilor simple.

Modele de Date / Modelul Relational / Manipularea Datelor 283

§ Regasire Filtrata si Ordonata Codurile si Numele BENEFICIARILOR ordonate descrecator dupa Nume:

B Cod Nume Tip Oras P BX DO NY

Conventii:

§ DO(n) – Descrescator

§ UP(n) – Crescator

§ n – Ordinea atributului în Cheia de Ordonare

§ Regasire din mai multe Tabele cuplate Codurile si Numele BENEFICIARILOR care au contractat PRODUSUL ‘P2’:

B Cod Nume Tip Oras P BX NY

C Codb Codp Cantitate BX P2

Cuplarea se face prin Valori de Exemplu egale pe coloanele definite pe Domenii Comune.

Numele BENEFICIARILOR care au contractat cel putin un PRODUS rosu:

B Cod Nume Tip Oras BX P . NY

P Cod Nume Greutate Culoare P PX rosu

C Codb Codp Cantitate BX PX

§ Regasire cu Negatie Numele BENEFICIARILOR care nu au contractat PRODUSUL ‘P2’:

284 Modele de Date / Modelul Relational / Manipularea Datelor

B Cod Nume Tip Oras BX P. NY

C Codb Codp Cantitate ¬ BX P2

§ Regasire cu cuplarea aceleasi Tabele Codul PRODUSELOR contractate de mai mult de un BENEFICIAR:

C Codb Codp Cantitate

BX P. PY ¬ BX PY

Conditia (¬ BX) evita perechile de Coduri ale aceluiasi BENEFICIAR.

§ Regasire cu Tabela de Conditii Perechile deCoduri ale BENEFICIARILOR având resedinta în acelasi Oras:

B Cod Nume Tip Oras

BX OX BY OX

CONDITII BX < BY

REZULTAT Primul Al-Doilea

P BX BY

Conditia (BX < BY ) din Tabela de Conditii evita perechile de Coduri ale aceluiasi BENEFICIAR în conditiile în care solutia anterioara (BX , ¬ BX) nu poate fi folosita întrucât în REZULTAT vor trebui sa apara distinct Valorile de Exemplu (BX , BY).

Concluzii:

- Conceptul QBE este familiar utilizatorului terminal, fapt pentru care s-a bucurat de popularitate în cazurile simple de interogare a Bazelor de Date

- Pentru cazuri mai complicate conventiile îngreuneaza manipularea datelor

- E încorsetat de viziunea Tabelara , nepretându-se pentru încorporare în alte Medii de Programare

- Implementarile evita unele facilitati ale Modelului Teoretic, mai greu de tratat

- Modelul Teoretic al CRD este Complet Relational, dar implementarile nu

Modele de Date / Modelul Relational / Nivelul Extern 285

4.2.4.6 Nivelul Extern în Modelul Relational 4.2.4.6.1 Vederea ca si Constructor al Nivelului Extern

Prezentarea Nivelului Extern al Modelului Relational va fi facuta sub semnul dezideratului principal al acestui mo del si anume asigurarea maximei Independente a Structurii de Date, atât în interior, între Elementele Structurii, cât si în exterior, între Structura Datelor si cea a Procedurilor.

Constructorul Nivelului Extern este Vederea, privita ca o Tabela Virtuala (Relatie Virtuala). In aceasta calitate Vederea se instituie ca principalul exponent al Virtualizarii Datelor si prin aceasta un factor important de asigurare a Consistentei diferitelor Viziuni ale Utilizatorilor asupra Datelor Reale, efectiv memorate în Baza de Date.

Relatia Vederii cu Constructorii celorlalte Nivele de Abstractizare ale Bazelor de Date este prezentata în Tab. 4.2.4.6.1.1.

Nivelul de Abstractizare

Constructor Legatura

CONCEPTUAL TABELA de BAZA

TB

-

INTERN FISIER MEMORAT

FM

TB ↔ FM

EXTERN VEDERE

VD

VD ↔ TB ↔ FM

Tab. 4.2.4.6.1.1 Legaturi între Constructorii Nivelelor de Abstractizare

Legaturile între elementele de baza ale Nivelelor de Reprezentare ale Structurilor de Date vorbesc foarte mult despre Dependentele ce trebuie respectate si care masoara Gradul de Independenta la care se poate ajunge. In acest sens se remarca faptul ca Vederea are urmatoarele proprietati de baza:

- Nu exista independent de Tabelele de Baza , care prin intermediul Fisierelor Memorate se mentin ca singura Sursa de Date Reala (Fizica)

- Nu va putea sa transmita direct actualizari spre Fisierele Memorate, ci doar prin intermediul Tabelelor de Baza

Vederea este un element al Nivelului de Descriere a Structurilor de Date, întelegând prin aceasta faptul ca definirea Vederii va trebui memorata în Dictionarul Datelor, fiind invocata în Limbajele de Manipulare ca orice alt Obiect de Descriere – Relatii (Tabele), Atribute (Coloane) etc. Vederile vor putea fi deci:

o Create cu Comenzi Specifice

§ Forma

286 Modele de Date / Modelul Relational / Nivelul Extern

DEFINE VIEW Nume –Vedere [ (Lista-de-Atribute) ]

AS comanda-select comanda-select – poate contine la rândul sau Vederi anterior definite (Vederile pot fi definite în termenii altor Vederi)

§ Exemplu

DEFINE VIEW B -O1 AS

SELECT Cod, Nume, Tip, Oras

FROM B

WHERE Oras = ‘O1’

o Invocate în Comenzi de Regasire

§ Forma

Vederea va putea apare în blocul SELECT în locul Tabelei de Baza (Clauza FROM, Calificarea Atributelor etc.)

§ Exemplu

SELECT Cod, Nume

FROM B -O1

WHERE Tip = ‘T1’

ORDER BY Nume

Comanda SELECT este echivalenta cu cea de mai jos, care apeleaza doar la Tabele de Baza si nu la Vederi:

SELECT Cod, Nume

FROM B

WHERE Oras = ‘O1’ AND Tip = ‘T1’

ORDER BY Nume

o Sterse cu Comenzi Specifice

§ Forma

DROP VIEW Nume –Vedere Se vor sterge toate Vederile Derivate (Vederi definite pe baza acelei Vederi), fara afectarea Tabelelor de Baza

§ Exemplu

DROP VIEW B -O1

Din cele prezentate pâna acum rezulta urmatoarele Caracteristici ale Vederilor:

- Vederea e definita si memorata doar Intensional prin intermediul unei comenzi specifice de creare

Modele de Date / Modelul Relational / Nivelul Extern 287

- Definirea Vederilor nu necesita definirea de noi Domenii, acestea fiind preluate din Domeniile pe care sunt definite Tabelele de Baza , utilizate pentru definirea Vederilor

- Comanda SELECT din definirea Vederilor nu poate contine Clauze care se refera la generarea Extensiunii Vederii (Valorilor de Atribute si Tuple) în momentul invocarii:

o Clauza ORDERBY

o Date Virtuale (Date calculate)

o Variabile de Program (în cazul Limbajului SQL încorporat)

- Comanda SELECT din definirea Vederilor nu se executa în momentul memorarii, ci în momentul invocarii Vederii în cadrul altui Bloc SELECT

- Vederea poate fi utilizata în Limbajul SQL ca orice alta Relatie (Tabela de Baza)

- Stergerea unei Tabele de Baza determina stergerea tuturor Vederilor Derivate din aceasta Tabela de Baza

4.2.4.6.2 Operatii în LMD asupra Vederilor

Asa dupa cum s-a aratat în sectiunea precedenta, Vederile nu reprezinta o copie a Datelor Reale, ci o Fereastra spre Datele Memorate, populata de Date Virtuale care se instantiaza doar în momentul invocarii prin folosirea ultimelor Valori actualizate în Sursa de Date (Valorile din Înregistrarile Fisierelor Memorate). Ca urmare:

- Modificarile Datelor Reale, pâna în momentul invocarii, sunt vizibile din orice Vedere asupra Datelor Reale

- Operatiile de Actualizare a Datelor continute în Vederi se convertesc în operatii asupra Datelor Reale (Tabelelor de Baza)

Operatiile asupra Vederilor se clasifica în:

o Operatii de Regasire care sunt considerate Operatii Simple – orice Vedere poate fi privita ca o Relatie Derivata (Tabela Derivata)

o Operatii de Actualizare care sunt considerate Operatii Dificile - cuprind ansamblul operatiilor de transfer a Valorilor de Date catre Baza de Date (INSERT, DELETE, UPDATE)

Din punctul de vedere al raportului cu operatiile de actualizare Limbajele de Manipulare a Datelor (LMD) continute în SGBD-urile se împart în:

o LMD-uri Restrictive – nu permit actualizari asupra Vederilor (nu accepta Vederi Actualizabile)

o LMD-uri Permisive – permit actualizari asupra Vederilor (accepta Vederi Actualizabile)

Înca în Sistemul R au fost definite conditiile ce trebuiesc impuse Vederilor pentru a putea fi Actualizabile si anume:

288 Modele de Date / Modelul Relational / Nivelul Extern

o Vederea sa fie derivata dintr-o singura Tabela de Baza

o Fiecare Tupla Virtuala a Vederilor instantiate sa corespunda unei singure Tuple Reale din Tabela de Baza

o Fiecare Coloana a Vederii sa corespunda unei singure Coloane a Tabelei de Baza

Ca urmare Vederea Actualizabila nu poate sa fie Rezultatul urmatoarelor Operatii Relationale:

- Proiectie cu eliminarea Tuplelor Duplicate

- Reunire cu cuplarea mai multor Tabele de Baza

- Reuniune cu posibile eliminari de Tuple Duplicate

- Selectie cu Clauza GROUPBY

- Selectie continând Functii de Calcul (Date Virtuale ce sintetizeaza mai multe Date Reale, fara a pastra originea lor)

Exemplul 1:

Fie Vederea definita intensional ca în Fig. 4.2.4.6.3.1 si cu extensia, generata la invocare, din Tab. 4.2.4.6.3.2.

DEFINE VIEW PCO AS SELECT UNIQUE Culoare, Oras FROM P

Fig. 4.2.4.6.3.1 Intensiunea Vederii PCO PCO

Culoare Oras C1 O1 C2 O2 C3 O3 C3 O2

Tab. 4.2.4.6.3.2 Extensiunea Vederii PCO

Impasul actualizarii consta în: La o Inserare în PCO a unei noi Tuple, ce Valoare de Cheie Primara (Atributul Cod) se adauga în Tabela de Baza P?

Cod correspondent în P P1, P4, P6

P2 P3 P5

Modele de Date / Modelul Relational / Nivelul Extern 289

Exemplul 2:

Fie Vederea definita intensional ca în Fig. 4.2.4.6.3.3 si cu extensia, generata la invocare, din Tab. 4.2.4.6.3.4.

DEFINE VIEW PC1 AS SELECT Cod, Nume, Greutate, Culoare FROM P WHERE Culoare = ‘C1’

Fig. 4.2.4.6.3.3 Intensiunea Vederii PC1

PC1 Cod Nume Culoare Greutate P1 N1 C1 G1 P2 N2 C2 G2 P3 N3 C3 G3 P4 N4 C3 G3

Tab. 4.2.4.6.3.4 Extensiunea Vederii PC1

Dificultatile de actualizare sunt redate în Tab. 4.2.4.6.3.5.

Se cere sa fie facuta precizarea ca exista reguli mai precise de actualizare decât cele din sistemul R. De asemenea se poate remarca si aparitia unor LMD – uri mai permisive cu Operatiile de Actualizare, dar care nu au putut înca penetra în sfera de recunoastere a Standardelor.

Operatie Dificultate Solutie în Sistemul R

Atributul Oras nu apare în Vederea PC1 si ar putea fi definit ca NONULL în P

Se evita actualizarea

INSERT INTO PC1 < ‘P3’, ‘N3’, ‘G3’, ‘C3’, ‘O3’ >

P3 nu exista în Vederea PC1, dar exista în P si provoaca încalcarea Restrictiei de Integritate de Identificare

Se evita actualizarea

UPDATE PC1 SET Culoare = ’C5’

WHERE Cod = ’P1’

Tupla modificata iese din Conditia de Definire a Vederii PC1 (Culoare = ‘C1’)

Se exclude Tupla

Tab. 4.2.4.6.3.5 Dificultati de actualizare a Vederii PC1

290 Modele de Date / Modelul Relational / Nivelul Extern

4.2.4.6.3 Vederile si Independenta Datelor

Pentru a putea analiza rolul, deosebit de important, pe care vederile îl au în controlul Structurilor de Date începem prin a reaminti cele doua Nivele de Independenta a Datelor promovate în Sistemele de Gestiune a Bazelor de Date (vezi sectiunea 2.1.1):

o Independenta Fizica a Datelor – imunitatea Nivelului Conceptual la modificarile survenite în Nivelul Fizic

o Independenta Logica a Datelor – imunitatea Nivelului Extern la modificarile survenite în Nivelul Conceptual

Întrucât Vederea este angajata în cea de a doua forma de Independenta a Datelor, sa urmarim care sunt Modificarile susceptibile sa apara în Nivelul Conceptual si la care conceptul de Vedere trebuie sa faca fata, din punctul de vedere a mentinerii imunitatii:

o Modificari prin Extensie, care la rândul lor se subdivid în:

§ Modificari prin Expansiune – adaugari de Atribute noi în Relatii existente

§ Modificari prin Incluziune – adaugari de Relatii noi în Baza de Date

o Modificari prin Restructurare – divizare Relatii prin Proiectie pentru Optimizarea Structurii

Sa analizam acum comportarea Vederii în cazurile mai sus mentionate:

§ Modificari prin Extensie Vederile asigura Imunitatea Utilizatorului la Extensiile Bazei de Date, prin aceea ca Atributele sau Relatiile noi nu apar în Vederile deja definite si prin aceasta nu trebuie sa fie afectate.

§ Modificari prin Restructurare Motivul Restructurarilor este în general unul de proiectare a Structurilor de Date. El vizeaza:

• Separarea Datelor în vederea simplificarii Controlului Accesului la Date (interzicerea Accesului Neautorizat)

• Optimizarea Structurilor prin Normalizarea Relatiilor ceruta de:

o Proiectari Defectuoase ce se cer corectate

o Modificari ale Cerintelor Initiale specificate în Spatiul de Informatii si care sunt datorate fie unei Analize incomplete sau defectuoase ori a evolutiei Conditiilor în care Sistemul de Aplicatii trebuie sa functioneze

Exemplu:

Sa consideram ca din motive de proiectare Relatia B a trebuit sa fie descompusa în alte doua Relatii BX si BY având definirile:

BX (Cod, Nume, Oras) KEY Cod

BY (Oras, Tip) KEY Oras

Modele de Date / Modelul Relational / Nivelul Extern 291

Deoarece cazul Restructurarilor ridica cele mai dificile probleme, se va urmari comportarea Vederilor în doua situatii distincte de utilizare:

• Utilizarea Vederilor pentru Regasire Vederile asigura Imunitatea Utilizatorului la Restructurarile Bazei de Date, în cazul Operatiilor de Regasire, daca modificarile operate în Structura de Date ramân mascate prin pastrarea Numelui unei Vederi vechi, a carei redefinire regrupeaza datele noi, furnizând utilizatorului vechea structura de date în extensiune. Exemplu:

Pentru a mentine neschimbate Cererile care invocau Tabela de Baza (Relatia) B, care acum nu mai exista în structura, se introduce o Vedere cu acelasi Nume si care regrupeaza datele din noile Tabele de Baza , BX si BY:

DEFINE VIEW B AS SELECT Cod, Nume, Oras, Tip FROM BX, BY WHERE BX .Oras = BY .Oras

Toate Cererile care-l apelau pe B ramân în acest caz imune. Singurele implicatii ce apar sunt legate de cresterea duratelor de precompilare si eventual de executie a Cererilor, care solicita instantierea noii Vederi definite, care de cele mai multe ori ramân totusi neglijabile.

• Utilizarea Vederilor pentru Actualizare In general Vederile nu asigura Imunitatea Utilizatorului la Restructurarile Bazei de Date, în cazul Operatiilor de Actualizare. Criteriul de decizie în stabilirea gradului în care imunitatea poate totusi sa fie mentinuta este cel de respectare a Conditiilor impuse Vederilor Actualizabile.

Concluzii:

Utilizarea corecta a functiilor Nivelului Extern al unei Baze de Date este deosebit de importanta în construirea Surselor de Date bine structurate si usor controlabile. Mentionam în finalul discutiei urmatoarele avantaje pe care Vederile îl pot aduce în proiectarea si exploatarea Bazelor de Date:

o Utilizatorii ramân imuni la Extensia Bazei de Date

o Utilizatorii pot ramâne imuni la Restructurarea Bazei de Date, daca se respecta restrictiile impuse Vederilor Actualizabile

o Perceptia Utilizatorului asupra Bazei de Date este simplificata prin încorporarea unui numar semnificativ de operatii din LMD în definirea Vederilor care vor putea fi direct apelate în Cereri.

Se remarca un proces de transfer a elementelor din LMD direct în Baza de Date.

o Aceeasi data poate fi diferit vazuta de Utilizatori diferiti

o Se asigura o protectie a Accesului la Date prin mascarea anumitor date din Nivelul Conceptual, date care nu reapar în Nivelul Extern

292 Modele de Date / Modelul Relational / Nivelul Extern

4.2.4.7 Modelul Relational ca Model Strict de Date

Descrierea Modelului Relational ca model fundamental de organizare a datelor va fi facuta în termenii elementelor componente ale unui Model Strict de Date (conform schemei de structura din Fig. 4.2.4.7.1).

Fig. 4.2.4.7.1 Componentele Modelului Relational 4.2.4.7.1 Structura datelor

Structura datelor va fi prezentata folosind un exemplu de Baza de Date Relationala în domeniul Medical. Pornind de la Clasele de Entitati care descriu Spatiul de Informatii precum si a Relatiilor dintre acestea (Fig. 4.2.4.7.1.3 si 4.2.4.7.1.4) se întocmeste Lista Caracteristicilor din Tab. 4.2.4.7.1.1. Se ajunge la Schema de Relatii de mai jos:

SPITAL (Cod Spital *, Nume, Adresa, Telefon, Total Paturi)

SECTIE (Cod Spital *, Cod Sectie*, Nume, Total Paturi)

PERSONAL (Cod Spital *, Cod Sectie, Marca*, Nume, Profesie, Schimb, Salariu)

DOCTOR (Cod Spital *, Marca*, Nume, Specializare)

PACIENT (Numar Înregistrare *, Nume, Adresa, Data Nasterii, Sex, Numar Asigurare)

DIAGNOSTIC (Numar Înregistrare *, Cod Diagnostic, Tip Diagnostic , Complicatii, Precautii)

LABORATOR (Numar Laborator*, Nume, Adresa, Telefon)

TEST (Numar Înregistrare*, Numar Laborator*, Numar Test*, Tip Test, Data Programarii, Ora Programarii, Numar Fisa, Rezultat)

LABORATOR /SPITAL (Cod Spital *, Numar Laborator*)

DOCTOR/ PACIENT (Marca*, Numar Înregistrare*)

PACIENT/ PAT (Cod Spital*, Cod Sectie*, Numar Înregistrare*, Numar Pat*, Data Ocuparii)

MODEL RESTRICTII

OPERATII

STRUCTURA

GENERALIZARE

LOGICA

FIZICA

de SISTEM

de UTILIZATOR

NAVIGARE

IMPLICITE

AGREGARE

IERARHII de

INSTANTE

GENERALIZARE

AGREGARE

IERARHII de

OBIECTE

EXPLICITE

SPECIFICARE

Modele de Date / Modelul Relational ca Model Strict de Date 293

Tab. 4.2.4.7.1.1 Baza de Date MEDICALA (Atributele Descriptoare)

Simbol RELATIE

Nume RELATIE

Lista ATRIBUTE

Identificatori Chei de Legatura

Chei Straine

Tip RELATIE

SP SPITAL cs,n,a,t,tp cs - - Ec

SC SECTIE cs,ct,n,tp cs,ct cs cs M PE PERSONAL cs,ct,m,n,p,s,sl cs,m cs cs, ct M

DO DOCTOR cs,m,n,sp m - m Ei

PA PACIENT ni,n,a,dn,sx,na ni - - Ec

DI DIAGNOSTIC ni,cd,td,cm,pr ni,cd,td ni ni M LA LABORATOR nl,n,a,t nl - - Ec

TE TEST ni,nl,nt,tt,dp,op,nf,r ni,nl,nt ni, nl ni, nl M LS LABORATOR /

SPITAL cs,nl cs,nl cs, nl cs, nl Ls

DP DOCTOR / PACIENT

m,ni m,ni m,ni m,ni Ls

OC PACIENT / PAT

cs,ct,ni,np,dc cs,ct,ni,np cs,ct cs,ct Lc

Tab. 4.2.4.7.1.2 Baza de Date MEDICALA (Gruparea Atributelor în Clase de Entitati)

cs – Cod Spital p – Profesie cm - Complicatii nf – Numar Fisa m – Marca

na – Numar Asigurare s – Schimb pr – Precautii ni – Numar Inregistrare

n – Nume sl – Salariu nl – Numar Laborator dn – Data Nasterii

a – Adresa sp – Specializare nt – Numar Test sx – Sex

t – Telefon na – Numar Asigurare tt – Tip Test r - Rezultat

tp – Total Paturi cd – Cod Diagnostic dp – Data Programarii np – Numar Pat

ct – Cod Sectie td – Tip Diagnostic op – Ora Programarii dc – Data Ocuparii

Modele de Date / Modelul Relational ca Model Strict de Date 294

Fig. 4.2.4.7.1.3 Baza de Date MEDICALA (Arborele de Structura)

•

ni nl

*

• •

sp

tt

dn ni

s

cd

ct cs

•

•

•

*

OC

•

SP

*

cs

* •

SC

*

cs ct

•

PE

* m •

DO

* cs m

•

PA

*

ni

*

LS

*

cs

cd

* •

DI

* td

* •

LA

nl

*

DP

*

m

ct *

• *

cs

np * * ni

nl

* •

TE

*

ni nt

•

n

n

* a

t

t

a

n

• tp

n

• •

•

• sp • •

•

• • • pr

cm

na

sx

sl

p

n

r nf

sp •

Modele de Date / Modelul Relational ca Model Strict de Date 295

Fig. 4.2.4.7.1.4 Baza de Date MEDICALA (Diagrama Simbolica)

SP

OC

SC

DO

PA

LA

PE

DP

DI

LS

TE

296 Modele de Informatii si Date

Fig. 4.2.4.7.1.8 Baza de Date MEDICALA (Diagrama Entitati-Relatii)

ST/ SP DO/

SP

LA/ SP

PE/ ST

PA/ ST

DO/PA

TE/ LA

PA/DI

PA/ TE

ST

DO

LA

SP

TE

PA

PE

DI

Modele de Date / Modelul Relational ca Model Strict de Date 297

4.2.4.7.2 Tipuri de Structuri Relationale

In construirea Structurilor Relationale, Categorisirea Relatiilor, cu evidentierea particularitatilor fiecarei Clase de Relatii, este de o deosebita importanta pentru transformarea procesului de conceptie, dintr-o activitate inspirata de moment, într-un proces metodic, si fundamentat de elaborare controlata a ansamblurilor de informatii si de date care descriu o realitate complexa. Problema este cu atât mai acuta, cu cât structurile relationale, prin simplitatea si elementaritatea lor, par a nu suporta cu usurinta un proces de diferentiere prin clasificare.

Înainte de a trece la Categorisirea Relatiilor se extind termenii introdusi în sectiunea 4.2.4.4 cu urmatoarele notiuni:

o Cheie Candidata - orice Grup de Atribute care se constituie într-un Identificator al unei Relatii (numarul minim de Atribute ale unei Relatii, fata de care celelalte Atribute sunt Functional Dependente), sau formal exprimat:

O Cheie Candidata în R (Ω ) este ∀ ∇ ⊆ Ω ,

daca:

∆ DF→ Ω

si

∀ ∆‘ ⊂ ∆ ⇒ ∆‘ ¬ DF→ Ω

unde:

Ω si ∆ sunt Multimi de Atribute din R

DF→ este o Relatie de Dependenta Functionala, care se citeste:

• ∆ determina functional pe Ω

sau

• Ω depinde functional de ∆

o Cheie Primara - orice Cheie Candidata aleasa la un moment dat, pe criterii de preferinta, ca Prim Identificator al Relatiei

o Atribut de Legatura - orice Atribut al unei Relatii, care e definit pe un Domeniu Comun (Atribut din care porneste sau în care soseste o Legatura Relationala)

o Cheie Straina - orice Atribut de Legatura al unei relatii, care este Cheie Primara în alta relatie

o Cheie de Legatura - orice Cheie Straina, care este totodata constituent de Cheie Primara în relatia în care este definit

o Legatura Relationala - orice legatura între doua Atribute de Legatura din Relatii diferite

298 Modele de Date / Modelul Relational ca Model Strict de Date

4.2.4.7.2.1 Tipuri de Legaturi Relationale

Folosind notatiile urmatoare: R – Relatie, i – Identificator, d – Descriptor, am reprezentat în figurile de mai jos diferitele ipostaze ale simplei Legaturi Relationale, dupa cum urmeaza:

- Legatura Cheie Straina → Cheie Primara face sa migreze Cheia Primara în Cheia Straina, care fiind un Descriptor determina o Legatura Neidentificatoare (vezi sectiunea 3.4.5.2), mai putin determinanta pentru Relatia R2; este cea mai frecventa Legatura Relationala 1 – n, care încorporeaza Atributele unei alte Relatii (R1) în corpul Relatiei care o Refera Relational (Asociativ) (Fig. 4.2.4.7.2.1.1)

R1 . i - Cheie Primara R2 . i - Cheie Primara R2 . d - Cheie Straina

Fig. 4.2.4.7.2.1.1 Legatura Neidendificatoare 1 – n (Cheie Straina → Cheie Primara)

- Legatura Cheie de Legatura → Cheie Primara determina migrarea Cheii Primare într-un Constituent de Cheie, deci într-un Identificator al Relatiei R2, care devine mai puternic dependenta de R1 (Fig. 4.2.4.7.2.1.2); se implementeaza astfel o Legatura Relationala 1 – n

R1 . i - Cheie Primara R2 . i1 + R2 . i2 - Cheie Primara R2 . i1 - Cheie de Legatura

Fig. 4.2.4.7.2.1.2 Legatura Idendificatoare 1 - n (Cheie de Legatura → Cheie Primara)

- Legatura Cheie de Legatura → Cheie Primara într-o varianta particulara este cea în care Cheia de Legatura este totodata si Cheie Primara în Relatia R2; se

* * i d d i

R1 R2

* * i1 d d i

R1 R2

* i2

Modele de Date / Modelul Relational ca Model Strict de Date 299

implementeaza astfel o Legatura Relationala 1 – 1, specifica fragmentarii Relatiilor, care de altfel descriu aceeasi Entitate (Fig. 4.2.4.7.2.1.3).

Fragmentarea este utilizata în doua cazuri:

§ Pentru Relatii cu multe Atribute, care prin separare urgenteaza operatiile de Reunire

§ Pentru Extinderea Relatiilor cu noi Atribute fara a modifica vechea structura declarata

R1 . i - Cheie Primara R2 . i - Cheie Primara R2 . i1 - Cheie de Legatura

Fig. 4.2.4.7.2.1.3 Legatura Idendificatoare 1 - 1 (Cheie de Legatura → Cheie Primara)

- Legatura Atribut de Legatura → Atribut de Legatura este o Legatura Relationala Incompleta; se observa ca, lipsind cel putin un Identificator în aceasta Legatura, nu se poate vorbi despre o Migrare de Chei si mai mult are loc o vizibila Redondanta cauzatoare de Inconsistenta, prin repetarea acelorasi Descriptori (Fig. 4.2.4.7.2.1.4); se implementeaza o Legatura Relationala m – n cu doar doua Relatii, dar asa cum s-a mentionat Structura nu e „sanatoasa”

R1 . i - Cheie Primara R2 . i - Cheie Primara R1 . d - Atribut de Legatura R2 . d - Atribut de Legatura

Fig. 4.2.4.7.2.1.4 Legatura Neidendificatoare m – n ( între Atribute de Legatura)

- Legatura Atribute de Legatura → Cheie Primara ofera solutia corecta pentru Legatura Relationala Incompleta anterioara; Descriptorii se unifica prin deplasarea lor într-o Entitate de sine statatoare (R), cu un Identificator Propriu

* * i d d i

R1 R2

* * i d d i

R1 R2

300 Modele de Date / Modelul Relational ca Model Strict de Date

(R . i), care va migra în ambele Relatii, evitându-se astfel Redondanta si mai ales posibilitatea de Inconsistenta (Fig. 4.2.4.7.2.1.5)

R . i - Cheie Primara R1 . i - Cheie Primara R2 . i - Cheie Primara R1 . d - Cheie Straina R2 . d - Cheie Straina

Fig. 4.2.4.7.2.1.5 Legaturi Neidendificatoare 1- n (Atribute de Legatura→Cheie Primara)

4.2.4.7.2.2 Tipuri de Relatii

Pentru ca o Structura Relationala sa fie sanatos construita se impune o corecta organizare a structurii pe Nivele de Relatii, în functie de Gradul de Dependenta al Relatiilor. Gradul de Dependenta al Relatiilor este strâns legat de Gradul Relatiilor definit în sectiunea 3.1.2.3:

“Numarul Multimilor pe care e definit Produsul Cartezian confera Gradul Relatiei”

La aceasta se adauga însa si Numarul de Domenii Comune care participa la definirea Produsului Cartezian, întrucât acestea indica Numarul de Relatii cu care are Legaturi o Relatie data. Vom vedea în continuare ca aceasta abordare va întâlni Procesele de Abstractizare prin care se genereaza Noi Obiecte, în speta Generalizarea si Agregarea (vezi sectiunea 4.2.4.7.3).

Este suficient aici sa recunoastem existenta a doua Tipuri Fundamentale de Relatii:

- Relatii Primare – Relatii care nu sunt definite pe nici un Domeniu Comun

- Relatii Derivate – Relatii care au cel putin un Domeniu Comun în definire

Întrucât prezenta unui Domeniu Comun implica o Dependenta între Relatii putem alege aceasta Dependenta ca si Criteriu de Clasificare a Relatiilor pe Tipuri. Prin rafinarea Criteriului mai sus mentionat pot fi recunoscute trei Categorii Principale de Relatii, cu functiuni bine precizate în proiectarea Structurilor Relationale de Date:

o Relatii de tip Entitate - existenta lor nu depinde în esenta de prezenta altor Relatii

o Relatii de tip Legatura - existenta lor depinde de prezenta altor Relatii, fara de care ele îsi pierd semnificatia

* * i d d i

R1 R2

* d i

R1

Modele de Date / Modelul Relational ca Model Strict de Date 301

o Relatii de tip Mixt – Relatii care datorita semanticii încorporate au comportament dublu, de Relatii de tip Entitate si de Relatii de tip Legatura

Rafinarea anticipata poate fi continuata dupa cum arata Categoriile de Relatii care se prezinta în continuare. 4.2.4.7.2.2.1 Relatii de tip Entitate

Relatiile de tip Entitate stau la baza generarii Structurilor Relationale. Pornind de la ele vor fi generate celelalte Relatii si în mod progresiv construita Structura Relationala. Relatiile de tip Entitate vor avea cea mai mare Independenta fata de alte Relatii. Relatiile de tip Entitate pot fi subclasificate în:

§ Relatii de tip Entitate Completa

§ Relatii de tip Entitate Incompleta 4.2.4.7.2.2.1.1 Entitate Completa

Relatiile de tip Entitate Completa sunt Relatii ce nu emit nici-o Legatura Relationala, dar pot receptiona asemenea legaturi. Ca urmare ele îsi pastreaza o Independenta Totala fata de celelalte Relatii.

Fig. 4.2.4.7.2.2.1.1.1 Relatie de tip Entitate Completa

Caracteristicile enumerate sunt vizibile în Structura generala a Relatiei de tip Entitate Completa (Ec) din Fig. 4.2.4.7.2.2.1.1.1. Toti Descriptorii (di) se afla în corpul Entitatii Complete (Ec), Identificatorul (i) oferind acces din exterior la acesti Descriptori.

Exemplu:

Sa analizam acum Relatia SPITAL extrasa din Baza de Date MEDICALA (vezi sectiunea 4.2.4.7.1). Se remarca Independenta Totala a Relatiei, fata de celelalte Relatii prezente în structura. Relatia SP poate fi referita (în general prin Identificatorul sp) pentru recuperarea informatiilor n, a, t sau tp, dar ea nu emite nici-o Referinta Relationala. Relatia SP se va afla la baza Structurii Relationale prezentate, grupând cele mai multe Referinte Relationale din partea altor Relatii din structura (vezi si Fig. 4.2.4.7.2.2.1.1.2).

• • •

Ec

*

i

d1 d2 ..

302 Modele de Date / Modelul Relational ca Model Strict de Date

Fig. 4.2.4.7.2.2.1.1.2 Relatie de tip Entitate Completa – Relatia SPITAL

Relatiile de tip Entitate Completa sunt destinate descrierii Colectiilor de Date relativ constante în timp de genul Cataloagelor, Dictionarelor, dar si a Listelor de Clasificare grupate în Criterii de Clasificare (vezi Relatia PROFIL din sectiunea urmatoare). Începerea proiectarii unui Model de Date cu aceste Clase de Entitati este o garantie pentru:

§ Asigurarea Consistentei necesare pentru Structura de Date

§ Oferirea fundamentului pentru Operatii de Abstractizare corecte de Generalizare si Specializare

§ Garantarea unui Nivel Ridicat de Normalizare a Structurii de Date

O Relatie îsi poate modifica Tipul în cursul existentei sale. Acest lucru este cauzat de modificarile, de cele mai multe ori inerente, care survin prin dezvoltarea Structurii de Date. Modificarea Tipului Entitatii Complete se datoreste adaugarii de noi Informatii în Baza de Date, cu respectarea Restrictiilor de Consistenta. Spre exemplu, daca dorim sa adaugam informatii noi legate de Profilul Spitalului, solutia de mentinere a consistentei Structurii de Date este cea de adaugare a unei noi Entitati de forma:

PROFIL (Cod*, Nume, Grupa-Salarizare)

în care Atributul Nume ar defini urmatoarele Valori de Domeniu: Interne, Chirurgie, ORL, Oftalmologie, Ginecologie, ... Pentru a referi aceste noi date stocate în Baza de Date, Relatia SPITAL (SP) trebuie completata cu Atributul Profil (p). Prin aceasta ea devine de tip Entitate Incompleta (vezi Fig. 4.2.4.7.2.2.1.2.2). 4.2.4.7.2.2.1.2 Entitate Incompleta

Relatiile de tip Entitate Incompleta sunt Relatii care au cel putin o Cheie Straina care refera o alta Relatie, a carei disparitie nu le desfiinteaza , ci doar le descompleteaza prin pierderea accesului la descriptorii Relatiei disparute.

Schema generala a unei Relatii de tip Entitate Incompleta este ilustrata în Fig. 4.2.4.7.2.2.1.2.1. Se remarca modul în care Entitatea Incompleta îsi completeaza descrierea prin intermediul Referintei Relationale (r), implementata ca un Descriptor, pe post de Cheie Straina .

• • •

SP

*

cs •

n a

t

tp

Modele de Date / Modelul Relational ca Model Strict de Date 303

Fig. 4.2.4.7.2.2.1.2.1 Relatie de tip Entitate Incompleta Exemplul 1:

Sa analizam Relatia SPITAL dupa o extensie a Bazei de Date MEDICALA, ca cea sugerata în sectiunea anterioara (adaugarea atributului Profil).

Fig. 4.2.4.7.2.2.1.2.2 Relatie de tip Entitate Incompleta – Relatia SPITAL extinsa

Relatia PROFIL, adaugata în structura, va fi de tip Entitate Completa (nu emite nici-o Referinta Relationala). Relatia SPITAL devine Relatie de tip Entitate Incompleta. Pentru ca structura sa ramâna consistenta atributul Profil va fi reprezentat de o Cheie Straina, migrata din Relatia PROFIL. Daca Relatia PROFIL va fi eliminata din structura, (dupa eliminarea în prealabil a eventualei Restrictii de Referire) entitatea SPITAL nu îsi pierde semnificatia. Inclusiv Codurile din Atributul Profil vor putea fi tratate procedural. Accesul structural la descriptorii n si g din PROFIL este pierduta.

Exemplul 2:

Revenind la structura initiala a Bazei de Date MEDICALE observam prezenta si a altor Legaturi Relationale de forma Entitate Completa – Entitate Completa (vezi Fig. 4.2.4.7.2.2.1.2.2). Relatia DOCTOR, prin Cheia Straina Cod Spital (cs) are acces la toti descriptorii SPITALULUI. Entitatea DOCTOR îsi va mentine semnificatia prin disparitia Entitatii SPITAL, dar va fi saracita în descriere.

• • •

Ec

*

i

d1 d2 ..

• • •

Ei

*

i

d1 d2 ..

• r

• • •

SP

*

cs •

n a

t

tp

• p

PR

* c • n

• g

304 Modele de Date / Modelul Relational ca Model Strict de Date

Fig. 4.2.4.7.2.2.1.2.3 Relatie de tip Entitate Incompleta – DOCTOR / SPITAL

O caracteristica importanta a Entitatii Incomplete provine din natura Neidentificatoare a Legaturii Relationale, care face ca disparitia chiar a Atributului din care se emite Legatura Relationala sa nu compromita Entitatea Incompleta. Aceasta însusire nu va mai fi prezenta la Entitatile de tip Mixt. 4.2.4.7.2.2.2 Relatii de tip Legatura

Relatiile de Legatura sunt Relatii care contin întotdeauna între Atribute cel putin doua Chei de Legatura . Prin aceasta ele constituie Relatii de Grad > 0 , care realizeaza legatura între alte relatii, permitând construirea Nivelelor de Agregare a Relatiilor de diferite Grade, întelegând prin aceasta ca Relatiile Agregate pot participa în continuare în alte Nivele de Agregare. Intre Domeniile pe care sunt definite Relatiile de Legatura figureaza întotdeauna Domeniile Cheilor de Legatura. Pe lânga acestea pot participa însa si alte Domenii care descriu Atribute proprii Relatiilor de Legatura . Subtipurile Relatiilor de tip Legatura sunt:

§ Relatii de tip Legatura Simpla

§ Relatii de tip Legatura Completa 4.2.4.7.2.2.2.1 Legatura Simpla

Relatiile de tip Legatura Simpla sunt Relatii fara descriptori proprii, care realizeaza agregarea exclusiva a Cheilor de Legatura . Relatiile de Legatura Simpla pot implementa atât Structuri Fundamentale de tip 1 - n, cât si m - n între Entitatile reprezentate de Relatiile legate. Structura manifesta toate caracteristicile Relatiei Matematice:

o Independenta Legaturii, definita ca o existenta de sine statatoare

o Flexibiltatea Legaturii în timp, prin posibilitatile oferite de:

§ Actualizare Extensionala care îsi pastreaza în permanenta caracterul dinamic

§ Reordonare dinamica asigurata de posibilitatea adaugarii dinamice a Structurilor Secundare de tip Index si de selectare a Indexului Curent

• • •

SP

*

cs •

n a

t

tp

•

DO

*

cs

m

• •

n

sp

Modele de Date / Modelul Relational ca Model Strict de Date 305

In cadrul Cheii Primare a Relatiei de Legatura Simpla se manifesta urmatoarele Dependente Functionale:

- Pentru Legaturi 1 – n:

Ls. i1 DF→ Ls. i2

si

Ls. i2 ¬ DF→ Ls. i1

- Pentru Legaturi m – n:

Ls. i1 ¬ DF→ Ls. i2

si

Ls. i2 ¬ DF→ Ls. i1

Structura schematica a Legaturii Simple este redata în Fig. 4.2.4.7.2.2.2.1.1.

Fig. 4.2.4.7.2.2.2.1.1 Relatie de tip Legatura Simpla

Relatia de Legatura Ls este definita pe Produsul Cartezian E1 x E2, având ca Intensiune Predicatul:

“E1. ip este Posesorul Membrului E2. im pentru ∀ p,m (E1. ip =Ls. i1p si E2. im =Ls. i2p)”

la care se poate adauga si cunostinta:

“p este Posesorul Membrului m” ⇔ “m este Membrul Posesorului p”

Rezulta definirea urmatoarelor Multimi:

- Multimea Membrilor Posesorului E1. ip

• • •

E1

*

i

d1 d2 .. • • •

E2

*

i

d1 d2 ..

Ls

* i1 * i2

306 Modele de Date / Modelul Relational ca Model Strict de Date

E2. im (E1. ip =Ls. i1p si E2. im =Ls. i2p) pentru ∀ m

- Multimea Posesorilor Membrului E2. im

E1. ip (E1. ip =Ls. i1p si E2. im =Ls. i2p) pentru ∀ p

Întrucât aici relatia de Posesor – Membri este indusa doar de existenta raportului 1 –n, rolul Posesorului poate fi, din acest punct de vedere strict formal, inversat cu rolul Membrului . Doar atasarea unor marci semantice Entitatilor E1 si E2 poate fixa un sens suplimentar Predicatului încorporat în Relatia de Legatura descrisa de Ls.

Singurele Atribute ale Relatiei Ls ramân Identificatorii Entitatilor aflate în Legatura. Lipseste orice Atribut suplimentar care ar putea masura Intensitatea Relatiei de Legatura . Cei doi Identificatori vor constitui Cheia Primara a Relatiei de Legatura.

Fig. 4.2.4.7.2.2.2.1.2 Relatii de tip Legatura Simpla cascadate

Asupra Entitatilor care intra în Legatura nu s-a facut nici-o precizare, ceea ce conduce la ideea ca o Relatie de Legatura poate sa serveasca ca Entitate pentru alta Legatura cu o noua Entitate (vezi structura din Fig. 4.2.4.7.2.2.2.1.2. Aceasta structura aduce ca noutate introducerea unui nou Identificator, numit în general Cheie Surogata, sub forma unei Chei Candidate (Ls1. i), care reprezinta în general un Atribut de tip Identificator, generat de sistem în scopul evitarii migrarii în Relatii a unor Componente Multiple de Chei Primare. Prezenta Cheii Surogate nu este obligatorie, dar aduce în practica proiectarii vizibile avantaje prin reducerea dimensiunii Cheilor Primare si implicit a Testelor de Identitate a Entitatilor.

• • •

E1

*

i

d1 d2 ..

• • •

E3

*

i

d1 d2 ..

Ls1

* i1 * i2

• • •

E2

*

i

d1 d2 ..

Ls2

* i1 * i2

* i

Modele de Date / Modelul Relational ca Model Strict de Date 307

Exemple: Ca exemple facem apel la Relatiile LABORATOR / SPITAL si DOCTOR / PACIENT din Fig. 4.2.4.1.2. Structurile invocate sunt suficient de explicite pentru a nu avea nevoie de explicatii suplimentare.

4.2.4.7.2.2.2.2 Legatura Completa

Relatiile de tip Legatura Completa sunt Relatii care, pe lânga Cheile de Legatura , contin si Descriptori Proprii, care masoara Intensitatea Legaturii create între Componentele de Chei si, indirect, între Entitatile reprezentate de acesti Identificatori.

Structura schematica a Legaturii Complete este redata în Fig. 4.2.4.7.2.2.2.2.1.

Au loc urmatoarele Dependente Functionale ce definesc Atributele de Intensitate ca Descriptori ai Legaturii:

Lc. i1, Lc. i2 DF→ Lc. di

Lc. i1 ¬ DF→ Lc. di

Lc. i2 ¬ DF→ Lc. di

Fig. 4.2.4.7.2.2.2.2.1 Relatie de tip Legatura Completa

Pentru ca Descriptorii Proprii sa caracterizeze cu adevarat Relatiile de Legatura Complete, trebuie ca acestia sa fie Complet Dependenti Functional de Cheia Primara a Relatiei formata întotdeauna din Ansamblul Cheilor de Legatura , (vezi Dependentele Functionale de mai sus).

..

• • •

E1

*

i

d1 d2 .. • • •

E2

*

i

d1 d2 ..

•

Lc

* i1 *

•

d1 i2

308 Modele de Date / Modelul Relational ca Model Strict de Date

Exemple: Relatiile de Legatura Simple LABORATOR / SPITAL (LS) si DOCTOR / PACIENT (DP) pot deveni Relatii de Legatura Completa daca adaugam, prin extensie urmatoarele Atribute:

- In LS – Atributul Numar Teste indicând Numarul de Teste efectuate de un Laborator pentru un anume Spital

- In DP – Atributul Numar Consultatii indicând Numarul de Consultatii efectuate de un Doctor unui anumit Pacient

Relatia PACIENT / PAT (OC) este de la bun început o Relatie de tip Legatura Completa prin atributul propriu Data Ocuparii.

4.2.4.7.2.2.3 Relatii de tip Mixt Relatiile de tip Mixt sunt Relatii la care Legatura Relationala se realizeaza prin Chei de Legatura , rezultate prin migrarea unei Chei Primare într-un Identificator al Relatiei de tip Mixt (Fig. 4.2.4.7.2.2.3.1). Din aceasta particularitate decurge si imposibilitatea eliminarii Chei de Legatura fara alterarea Relatiei. Apartinând Identificatorului, Cheia migrata determina o dependenta mai puternica a Relatiei Mixte de Relatiile cu care intra în Legatura . Dependenta mai strânsa se aseamana cu cea creata de Relatiile de Legatura , de care însa o diferentiaza prezenta unor Componente de Identificator Proprii, de unde si denumirea de Relatie de tip Mixt.

Fig. 4.2.4.7.2.2.3.1 Relatie de tip Mixt

Legaturile descrise de Relatiile Mixte sunt întotdeauna Complete, prin aceea ca Descriptorii Relatiei Mixte sunt totodata Descriptori de Intensitate ai Legaturii între cele doua Entitati, deoarece orice Atribut din Relatia Mixta ramâne Functional Dependent de Cheia Primara a Legaturii E. i, E m. i2:

E m. i1, E m. i2 DF→ E m. di

dar:

E m. i1 ≡ E. i

deci:

E. i, E m. i2 DF→ E m. di

• • •

E

*

i

d1 d2 ..

• • •

Em

* i2 d1 d2

..

i1

*

Modele de Date / Modelul Relational ca Model Strict de Date 309

In general Legatura de tip Mixt este încarcata si de o conotatie semantica descrisa de categoria de Legatura Mandatata si Independenta Entitatilor (vezi sectiunile 3.4.5.1 si 3.4.5.2). Exemplul ce urmeaza vine sa lamureasca aceste notiuni. Exemplu:

Sa consideram o structura ce descrie un DOCUMENT, alcatuit din doua parti:

§ Un ANTET – continând Date Comune pentru întregul Document

§ O Multime de RANDURI – continând Date Specifice

Restrictiile care trebuie avute în vedere sunt urmatoarele:

- Un ANTET nu poate exista fara cel putin un RAND

- Nici-un RAND nu poate exista fara un ANTET asociat Reprezentarea relationala a structurii descrise este prezentata în Fig. 4.2.4.7.2.2.3.2, cu luarea în considerare a urmatoarei particularizari:

o DOCUMENTUL poate reprezenta ,o Comanda, un Contract, o Factura etc.

§ ANTETUL care contine:

• Identificatorii de Document

o Cheie Primara (Surogata)

§ Identificatorul Intern de Document

o Cheie Candidata

§ Emitent (Societate / Persoana)

§ Numarul Documentului

§ Data Documentului

• Descriptori

§ Termenul Scadent

§ Conditii de Livrare / Plata

§ Etc.

§ RANDURILE contin:

• Identificatorul de Rând

§ Identificatorul Intern de Document

§ Numarul Rândului

• Descriptori

§ Codul Obiectului (Produs / Serviciu)

§ Unitatea de Masura

§ Cantitatea (Tranzactia Fizica)

§ Valoarea Unitara (baza Tranzactiei Valorice)

§ Etc.

310 Modele de Date / Modelul Relational ca Model Strict de Date

Fig. 4.2.4.7.2.2.3.2 Structura DOCUMENT / RANDURI

Actualizarea acestei structuri trebuie facuta Tranzactional (cu Validarea Restrictiei la sfârsitul Tranzactiei la nivel de Adaugare ANTET si Stergere RAND), pentru a asigura Natura Mandatata la Mandatata a Legaturii Relationale R. d → D. Id, de Tip 1 – n.

Asa dupa cum se va vedea mai jos, în procesul de Analiza a Proprietatilor Relatiilor am preferat caracteristica de Legatura Identificatoare / Neidentificatoare (vezi sectiunea 3.4.5.2) în locul caracteristicii de Legatura Mandatata / Optionala (vezi sectiunea 3.4.5.1), deoarece o consideram pe prima mai aproape de Viziunea Structuralista pe care încercam sa o promovam. Aceasta întrucât nu necesita o specificare expresa a Proprietatii Suplimentare ce asigura preluarea de semantica, ci doar o observare a formei Structurii Relationale în expresie mai abstracta, dar mai generala.

In finalul prezentarii Tipurilor de Relatii se remarca faptul ca gruparea acestora apeleaza la doua Criterii de Clasificare:

§ Natura Legaturilor implementate

§ Gradul de Independenta al structurilor implementate

Comparând cele doua Criterii de Clasificare se poate afirma ca, din punctul de vedere al Naturii Legaturilor implementate si fara a lua în considerare Gradul de Independenta al structurilor construite, Relatiile de Tip Mixt pot fi privite ca Relatii de Tip Entitate Incompleta. Diferentierea rezulta tocmai în modul în care Entitatea analizata îsi pastreaza Independenta Informationala fata de Legatura :

- Entitatea Incompleta – îsi pastreaza Independenta fata de Legatura, datorita migrarii Cheii Primare într-un Descriptor ( Migrare Neidentificatoare)

- Relatia de tip Mixt – ramâne Dependenta de Legatura, datorita migrarii Cheii Primare într-un Identificator ( Migrare Identificatoare)

Sa examinam acum utilitatea rezultatelor obtinute în privinta clasificarii Tipurilor de Relatii. Se mentin aceste rezultate doar în sfera demersului pur teoretic, a rigorii academice în sine, sau are repercursiune directa asupra cerintelor practice ridicate de activitatea de proiectare? In favoarea celui de al doilea raspuns aducem argumentele ce urmeaza.

Cunoasterea proprietatilor ce descriu în plan Intensional Structurile Relationale, care prin Elementaritatea lor îsi vor dovedi perenitatea în construirea Structurilor Complexe de Informatii si Date, va asigura întotdeauna în practica proiectarii un important beneficiu. Aceste

* id

* *

• ..

•

•

A

* nd dt em

cd • • •

R

* nr co um

ct d

*•

ts

•

..

vu

Modele de Date / Modelul Relational ca Model Strict de Date 311

cunostinte vor putea fi cu folos transmise Modelelor construite prin intermediul instrumentelor de Proiectare Asistata de Calculator a Sistemelor cu Baze de Date. Se va spori astfel continutul semantic al Modelelor de Date si totodata capacitatea lor generatoare. Enumeram în continuare domeniile în care avantajele mentionate sunt asteptate:

- Generarea automata a Restrictiilor de Integritate pentru Structurile Relationale – fiecare Tip de Structura implica anumite Restrictii Proprii, ce pot fi deduse din însasi aparteneta structurii concrete la un Tip definit

- Construirea Interfetelor Standard de manipulare (regasire si actualizare) a Tipurilor de Structuri Relationale – fiecarui Tip de Structura i se poate atasa o Clasa de Obiecte specifice, care sa asigure interactiunea cea mai potrivita dintre Utilizator si Structura ; profitul se împarte între doua activitati:

§ Activitatea Programatorului – construirea Interfetelor Tipizate prin combinarea si particularizarea unor Module de Structura construite pe baza de Tipuri de Structuri de Date, care atrag Structuri adecvate de Proceduri cu proprietati Functionale si de Orientare pe Eveniment; definirea Procedurilor este favorizata de cunoasterea Restrictiilor impuse de Tipurile de Structuri, care vor determina Tipizarea Procedurilor atasate:

• Unificarea Operatiilor de Actualizare (Bare de Comanda Tipizate)

• Prototipuri de Generare a Regulilor de Integritate

• Prototipuri de Actualizari Tranzactionale a Structurilor de Date

• Functii Predefinite pentru Propagarea Câmpurilor Active

• etc.

§ Activitatea Utilizatorului Final – reducerea efortului de asimilare a cunostintelor si obisnuintelor de lucru prin Tipizarea Interfetelor

4.2.4.7.3 Implementarea Relationala a Operatiilor de Abstractizare

Viziunea creata de Modelul Obiectelor Abstracte este deosebit de fertila în activitatea de construire a unui Model Relational. Ea conduce la utilizarea practica a Proceselor de Abstractizare în crearea Claselor de Entitati si a Relatiilor între ele. Dupa cum se va putea urmari în detaliu în sectiunea 5.1.4.2 o asemenea abordare reprezinta o cale sigura pentru evitarea unor structuri defectuoase din punct de vedere a Independentei Elementelor în cadrul Structurii si implicit a Gradului de Normalizare al Relatiilor. Crearea unor deprinderi de gândire în activitatea de conceptie scuteste echipa de proiectare de analiza finala a Gradului de Normalizare al Structurii proiectate. Un al doilea beneficiu consta în posibilitatea de automatizare a procesului de transpunere a conceptelor din Modelul Obiectelor Abstracte în Modelul Relational de Date. Cu alte cuvinte, utilizând Metodologia de Proiectare prezentata în sectiunea 4.1.2.10, construirea unui Model Relational se rezuma la implementarea celor doua Procese de Generare a noi Obiecte (Clase de Entitati):

o Prin Generalizare

o Prin Abstractizare

312 Modele de Date / Modelul Relational ca Model Strict de Date

4.2.4.7.3.1 Implementarea Agregarii

Agregarea îmbraca doua forme de aparitie:

o Agregarea de Domenii (forma primara de generare a Claselor de Entitati)

o Agregarea de Relatii (forma evoluata de combinare a Descriptorilor mai multor Clase de Entitati)

Agregarea de Domenii este poate cea mai vulnerabila atunci când se neglijeaza continutul semantic al Informatiilor din Spatiul Utilizatorului. Pericolul consta în introducerea în structura Relatiilor a Dependentelor Functionale nedorite (vezi sectiunea 5.1). Câteva recomandari sunt deosebit de utile:

- Adaugarea unui Atribut la o Clasa de Entitati numai daca el descrie nemijlocit acea Clasa (pentru exemplificari vezi sectiunea 5.1.3)

- Relativitatea aspectului de Caracteristica sau Entitate (vezi sectiunea 4.1.1.3) se transeaza prin constatarea posibilitatii de descompunere în elemente subordonate (la nivelul nedecompozabil se afla Caracteristica)

Automatizarea acestui proces este din ce în ce mai solicitat. La baza lui va sta conceptul de Element Atomic pentru modelarea Spatiului de Informatii (vezi sectiunea 4.2.1) si va consta din Agregarea Atomilor ce descriu aceeasi Entitate, atomi generati cu ajutorul unor Reguli Deductive din structuri complexe de tip descriptiv (texte, imagini, benzi sonore etc.). Implementarea Agregarii de Relatii se poate face în doua moduri, folosind urmatoarele Tipuri de Relatii:

o Doua Relatii Oarecare + o Relatie de tip Legatura (Simpla sau Completa), care descrie Obiectul Agregat.

In Fig. 4.2.4.7.1.3 Relatiile LABORATOR / SPITAL (LS), DOCTOR / PACIENT (DP) si PACIENT / PAT (OC), împreuna cu Entitatile LABORATOR, SPITAL, DOCTOR, PACIENT si PAT, sunt exemple de implementare a Agregarii cu ajutorul Relatiilor de Legatura .

o O Relatie Oarecare + o Relatie de tip Mixt, care descrie Obiectul Agregat. In Fig. 4.2.4.7.2.2.3.2 Relatia Mixta RANDURI (R) împreuna cu Relatia Entitate ANTET (A), este un exemplu de implementare a Agregarii cu ajutorul Relatiei Mixte.

4.2.4.7.3.2 Implementarea Generalizarii

Generalizarea pretinde existenta în Structura de Date a Colectiilor de tip Nomenclatoare, Cataloage sau Dictionare, care memoreaza Criteriile de Clasificare (Relatii ce contin Categoriile, care vor genera Obiectele de tip Categorie). Implementarea Generalizarii se va face în urmatoarele moduri:

o O Relatie Oarecare, care urmeaza sa fie Generalizata + o Relatie de tip Entitate (Completa sau Incompleta), care descrie Categoriile unui Criteriu de Clasificare.

In Fig. 4.2.4.7.2.2.1.2.2 Relatia Extinsa SPITAL (SP), este Generalizata de Relatia PROFIL (PR) ale carei Tuple contin Categoriile care vor specializa

Modele de Date / Modelul Relational ca Model Strict de Date 313

Obiectului Generic SPITAL prin generarea Obiectelor Categorie de forma SPITAL de INTERNE , SPITAL de CHIRURGIE etc. Obiectele Categorie reunesc Tuplele din Relatia SP cu aceeasi Valoare de Categorie Profil.

Faptul ca Relatia de tip Entitate poate fi si Incompleta asigura posibilitatea de cascadare a Procesului de Abstractizare prin Generalizare (definirea de Criterii, Subcriterii etc. pentru generarea de Categorii).

o O Relatie Oarecare, care urmeaza sa fie Generalizata + o Relatie de tip Entitate (Completa sau Incompleta), care descrie Categoriile unui Criteriu de Clasificare + o Relatie de tip Legatura (Simpla sau Completa), care descrie legatura Obiect Categorie - Categorie. In Fig. 4.2.4.7.3.2.1 este reprezentata Structura de Generalizare din Fig. 4.1.2.3.1. Sunt definite urmatoarele Relatii:

VEHICOL (Identificator**, Numar*, Producator*, Valoare)

CRITERIU (Cod*, Nume)

CATEGORIE (Cod*, Nume, Criteriu)

VEHICOL-CATEGORIE (Identificator**, Vehicol*, Categorie*)

§ Relatia VEHICOL (V) descrie Obiectul Generic, care urmeaza a fi separate în Categorii.

§ Relatia CRITERIU (CC) descrie Criteriile de Clasificare grupate în Blocuri si care realizeaza Generalizarea Relatiei CATEGORIE (gruparea Instantelor de Categorii pe Blocuri)

§ Relatia CATEGORIE (CT) memoreaza toate Instantele de Categorie, gruparea lor pe Blocuri fiind asigurata de Atributul Criteriu (CT. b)

Fig. 4.2.4.7.3.2.1 Structura DOCUMENT / RANDURI

v

•

V

*

i

n p v

•

CC

* c

n

VC

* * c

• •

CT

*

c

n b

* *

* i V – VEHICOL i - Identificator CT – CATEGORIE n - Nume CC – CRITERIU p - Producator VC – VEHICOL v - Valoare CATEGORIE c - Cod

314 Modele de Date / Modelul Relational ca Model Strict de Date

§ Relatia VEHICOL-CATEGORIE (VC) specializeaza Instantele de VEHICOL, prin atasarea Categoriilor pentru fiecare Criteriu

Se remarca Cheile Surogate (marcate **) si Cheile Candidate (marcate *). Ceea ce s-a urmarit în ultimul exemplu este rolul de Clasificare pe care îl poate îndeplini Relatia de tip Legatura, precum si Generalizarea Criteriilor de Clasificare.

4.2.4.7.3.3 Tip General de Structura Relationala

Încercam sa facem o sinteza privind Tipurile de Relatii. Am mentionat avantajele pe care le putem astepta atunci când procesul de conceptie si de proiectare a Structurilor Relationale respecta anumite reguli de construire si utilizare a Elementelor Modulare cu ajutorul carora asamblam structurile ample. Este de asemenea evident ca operarea este cu atât mai mult înlesnita cu cât manevram mai putine Structuri Elementare.

Întrebarea care se ridica acum este: ”Putem sa definim un Modul Unic de Structura care sa fie acoperitor în privinta implementarii Proceselor de Abstractizare?”

Putem începe aceasta cautare cu o întrebare mai generala: ”Pot fi reduse cele doua Procese de Abstractizare la unul singur?”

Raspunsul credem ca este afirmativ. Procesul de Abstractizare cel mai cuprinzator este Generalizarea. Agregarea, în ambele ei forme, poate fi redusa la Generalizare:

o Agregarea de Domenii - Daca se porneste de la Elementul Atomic atemporal ce descrie Spatiile de Informatii (vezi sectiunea 4.2.1):

( Nume Obiect , Proprietate Obiect, Valoare Obiect )

Entitatile vor rezulta ca si Categorii reprezentate de Atomii ce au acelasi Nume de Obiect.

o Agregarea de Relatii - Daca se porneste de la definirea notiunii de Clasa de Ansambluri de Entitati (vezi sectiunea 4.1.1.3.8):

CAE ≡ (AE n, AE o)

Multimile de Ansambluri de Entitati Obiect AE o vor defini direct Categoriile Clasei, determinate de Relatia de Asociere A i atasata Ansamblului de Entitati Notiune AE n.

Cu aceste consideratii rezulta ca Modul Unic de Structura propus este cel reprezentat în Fig. 4.2.4.7.2.2.2.2.1. Explicatiile care urmeaza vor lamuri în ce consta unificarea:

- Când una din Entitatile E1 sau E2 (fie ea E1) descrie Categoriile unui Criteriu de Clasificare, atunci Relatia de Legatura Lc va atasa fiecarei Instante din Clasa de Entitati E2 câte o Categorie asa încât E2 va Generaliza aceste Entitati-Categorie.

- Când între Entitatile E1 sau E2 se poate defini semantic o Relatie de Asociere de tip Posesor – Membri, Relatia de Legatura Lc va implementa aceasta Relatie de Asociere, care împarte cele doua Clase de Entitati în Clase de Echivalenta:

Membrii Posesorului e1i Posesorii Membrului e2j

Modele de Date / Modelul Relational ca Model Strict de Date 315

Aceste Clase de Echivalenta reprezinta Categoriile Generalizate de fiecare Clasa de Entitati.

Trecând peste problemele de eficienta a implementarilor, care în conditiile cresterii vertiginoase a performantelor Hardware nu ar trebui sa limiteze solutiile conceptuale, redam în continuare în ce constau avantajele unei asemenea perspective:

- Implementarea Proceselor de Abstractizare se simplifica prin Unificarea Structurii de Date utilizata în acest scop

- Modulul Structurii de Date odata fixat el va permite atasarea Procedurilor Adecvate (Metodelor) de creare si întretinere

- Constructia folosita ridica valoarea Procedurilor de Alocare candidate pentru implementarea foarte diverselor Operatii de Utilizator din sfera Sistemelor de Aplicatii (Business Logic)

- Arhitectura Interfetelor Utilizator pentru Accesul la Baza de Date gasesc un sprijin semnificativ în sensul unificarii si simplificarii

- Un suport important este oferit pentru generarea automata a Structurilor de Date si Proceduri pornind de la o Metodologie de Proiectare simplificata si consistenta, de genul celei prezentate în Modelul Obiectelor Abstracte

- Se creeaza o baza pentru industrializarea procesului de construire a Sistemelor de Aplicatii Complexe, reducându-se activitatile artizanale

4.2.4.7.4 Restrictii impuse Datelor

Prezentarea Restrictiilor ca si componente ale oricarei Model de Date este facuta prin grupare pe cele doua categorii: Implicite (de Sistem) si Explicite (de Utilizator). In afara ordinii impuse, aceasta clasificare ofera si o masura pentru flexibilitatea SGBD-ului utilizat. 4.2.4.7.4.1 Restrictii Implicite

Modelul relational impune un numar minim de Restrictii Implicite (inerente) ceea ce implica un mare Grad de Libertate în utilizarea lui. Restrictiile Implicite rezulta din Proprietatile Relatiilor privite ca Multimi (Codd 1972). Ele sunt:

o Identitatea Tuplelor care implica existenta Cheii Primare

Restrictii:

§ Cheia Primara nu poate fi modificata (operatia de Modificare se înlocuieste cu o operatie de Stergere si una de Adaugare referitoare la întreaga Tupla)

§ Cheia Primara nu poate avea constituenti nedefiniti

o Ordinea Tuplelor e indiferenta

Fara a impune vreo restrictie ordinea tuplelor ramâne însa un criteriu de performanta de care proiectantul trebuie sa tina cont.. Ordinea tuplelor este în majoritatea sistemelor relationale cea Cronologica. Sistemele evoluate introduc însa si posibilitatea de a controla aceasta ordine prin atasarea de Structuri

316 Modele de Date / Modelul Relational ca Model Strict de Date

Auxiliare de tip Index Blocat, care determina ordinea de memorare a Tuplelor în Tabele de Baza (vezi sectiunea 4.2.4.4.2.2).

o Ordinea Domeniilor e indiferenta

Întrucât odata definita aceasta ordine trebuie pastrata pe toata durata operarii cu Tabela de Baza, majoritatea sistemelor încorporeaza facilitati de recopiere integrala automata a Tabelelor la orice modificare a ordinii de definire a Atributelor Descriptoare.

o Atributele unei Relatii sunt Date Elementare (Câmpuri Nedecompozabile) 4.2.4.7.4.2 Restrictii Explicite

Libertatea în utilizarea Structurilor Relationale se bazeaza pe posibilitatea oferita utilizatorului de a adauga la Restrictiile Minime impuse de sistem noi Restrictii Explicite acordate cu Spatiul de Informatii care urmeaza a fi descris. Prin aceasta Restrictiile Explicite contribuie la preluarea maxima de semantica în Modelul de Date, ceea ce degreveaza procedurile continute în aplicatiile sistemului. Restrictiile Explicite pot fi categorisite astfel:

o Declarare de Domenii Interpretate

§ Declarare de Limite de Valori prin:

• Tip (Întreg, Real, Caracter etc.)

• Interval ( >, <, între etc)

• Enumerare (v1, v2 , v3 , .. )

§ Declarare de Domenii Comparabile – Domenii care impun pentru Identitate acelasi Tip acelasi Domeniu de Valori si aceeasi Semantica

Exemplu: Compararea Codului de Sectie cu Codul de Spital nu are nici-o semnificatie (Domeniile nu sunt Comparabile chiar la acelasi Tip si Valori).

§ Declarare de Unitati de Masura

o Facilitati de Asertare (declarare de Predicate)

§ Declarare de Stari Permise pentru:

• Valori de Atribut

Exemplu: 8< Ora-Programarii <20

ASSERT Conditie1 ON Test:

Ora-Programarii >8 and Ora-Programarii <20

• Expresii de Calcul

Exemplu: Suma paturilor din Sectii=Suma paturilor din Spital

ASSERT Conditie2:

(SELECT Numar-Paturi FROM SPITAL )=

(SELECT SUM(Numar-Paturi) FROM SECTIE

Modele de Date / Modelul Relational ca Model Strict de Date 317

WHERE Sectie.Cod-Spital=Spital.Cod-Spital)

• Liste de Valori

Exemplu: Sex∈ ‘M’, ‘F’

ASSERT Conditie3 ON Pacient:

Sex IS IN ‘M’, ‘F’

• Specificare de Chei

Exemplu: Numar-Inregistrare unic (sau Numar tuple în Pacient=Valori unice de Cheie)

ASSERT Conditie4 ON Pacient:

COUNT(*)=COUNT(UNIQUE Numar-Inregistrare)

§ Declarare de Tranzitii Permise pentru:

• Restrictii de Unicitate

Exemplu: Alocare unica de Pat

ASSERT Conditie5 ON INSERTION OF Ocupare(Numar-Pat),

UPDATE OF Ocupare(Numar-Pat):

NOT NEW Numar-Pat IS IN

(SELECT Numar-Pat FROM Ocupare

WHERE Cod-Sectie=NEW Cod-Sectie)

Clauzele:

* NEW si OLD refera Valorile de Atribute DUPA si INAINTE de actualizare

* ON INSERTION si ON UPDATE declara Momentul de Validare (de invocare a asertiunii)

• Expresii de Calcul

Exemplu: Salariu-Nou > Salariu-Vechi

ASSERT Conditie6 ON UPDATE OF Personal(Salariu):

NEW Salariu>OLD Salariu

o Facilitati de Declansare Proceduri (Trrigeri)

Facilitatile de Declansare Proceduri se bazeaza pe invocarea la un moment dat (la producerea unui Eveniment) a unei Proceduri sau Asertiuni declarate anterior si memorate în Baza de Date. Invocarea poate fi:

§ Imediata – se declanseaza la sesizarea producerii Evenimentului

§ Amânata – se declanseaza la sfârsitul Tranzactiei în curs de desfasurare (Tranzactie - un Set de Comenzi ce se executa toate sau nici una, pentru a mentine în permanenta Baza de Date într-o stare consistenta – vezi sectiunea 6.2)

318 Modele de Date / Modelul Relational ca Model Strict de Date

Acest tip de proceduri poarta numele de Triggeri. Structura unui Trigger este urmatoarea:

• un Set de Comenzi grupate într-un bloc de comenzi (BEGIN-END) ce contin obligatoriu comanda de Executie (COMMIT) sau Abandonare (ROLLBACK)

• o Conditie de Declansare a procedurii

Exemplu: Stergere tupla DIAGNOSTIC la stergere tupla PACIENT (pentru asigurarea integritatii referentiale)

DEFINE TRRIGER DELETE Diagnostic ON DELETION OF Pacient:

(DELETE Diagnostic

WHERE Numar-Inregistrare=OLD Pacient.Numar-Inregistrare)

Exemplu: Verificare integritate referentiala dupa un eventual incident

ASSERT Pacient Diagnostic DEPENDENCY:

(SELECT Numar-înregistrare FROM Diagnostic)

IS IN

(SELECT Numar-Inregistrare FROM Pacient)

Facilitatile de Asertare si de Declansare sunt elemente ale Limbajului de Manipulare a Datelor (LMD) introduse în Modelul de Date si transferate apoi în descrierea Bazei de Date. Ele poarta denumirea de Facilitati Orientate catre Descrierea Schemei Bazei de Date (Schema Oriented Facilities). Aceste facilitati au rolul de:

- Crestere a controlului asupra Sistemelor cu Baze de Date – prin administrarea centralizata a restrictiilor provenind din Spatiul Informatiilor (Business Logic)

- Cresterea flexibilitatii Modelului de Date prin adaptarea rapida la noi conditii impuse

- Degrevarea Aplicatiilor de proceduri de verificare a Restrictiilor prevazute în sistem

4.2.4.7.5 Operatii asupra datelor

Modelul Relational permite doua categorii de Operatii asupra datelor:

o Operatii Procedurale – bazate pe precizarea Succesiunii de Operatii care sa conduca la rezultat în urma parcurgerii Structurii de Date (Navigare)

o Operatii Neprocedurale – bazate pe descrierea prin Specificare a rezultatului ce se cere obtinut

Modele de Date / Modelul Relational ca Model Strict de Date 319

4.2.4.7.5.1 Operatii Procedurale – Navigarea în Tabele

Operatiile Procedurale sunt destinate manipularii Tabelelor. Ele se bazeaza pe doua concepte:

o Pozitia Curenta în Tabele – reprezentata de Indicatorul Curent (CURRENCY)

Indicatorul Curent este implementat ca o Variabila de Sistem în care este memorata Valoarea Identificatorului Intern ca Numar de Înregistrare Curenta

o Ordinea de Inspectie a Tabelelor – reprezentata de Succesiunea Tuplelor în Tabele, care poate fi Fizica sau Logica

Ordinea fizica e data fie de Ordinea Cronologica de memorare a Tuplelor în Tabela de Baza, fie de un Index Special, care asigura memorarea succesiva a Tuplelor potrivit Valorii Expresiei de Indexare – ex. Indexul Blocat (Clusterat)

Comenzi generale de navigare:

o Initiere Operatie de Navigare

CREATE SCAN nume-scan ON nume-relatie

Pot fi initiate mai multe Operatii de Navigare (Scanare) pentru aceeasi Relatie

o Initializare Indicator Curent

SET SCAN nume-scan

o Stergere Operatie de Navigare

DROP SCAN nume-scan

o Deplasare Indicator Curent

GET NEXT nume-scan [WHERE conditie]

o Testare Indicator Curent (test de Sfârsit Navigare)

IF STATUS-CHECK

Este similar cu functia EOF( ) din produsele Xbase

o Regasire Date din Tupla Curenta

SELECT FROM nume-scan, .. [: nume-atribut, ..]

In Fig. 4.2.4.7.5.1.1 sunt reprezentate Structurile de Date utilizate pentru Operatiile de Navigare în Tabele. Sunt de notat urmatoarele aspecte:

- Unicitatea Tabelei ca Sursa de Date ce asigura consistenta Structurii de Date

- Structurile Atasate Tabelei (Indecsii atasati), care permit construirea Multimilor Ordonate de Tuple

- Multitudinea Cursorilor ce pot fi atasati unei Tabele oferind Viziuni Multiple ale aceleiasi Multimi de Tuple ce poate apare în mod repetat în Produsele Carteziene

Modele de Date 320

Fig. 4.2.4.7.5.1.1 Structuri de Date pentru operatia de Navigare în Tabele

MEMORIE INTERNA

CURSOR 1 - NUME - ORDINE – Index Curent - POZITIE – Variabila Sistem

BAZA de DATE

CURSOR 2 - NUME - ORDINE – Index Curent - POZITIE – Variabila Sistem

CURSOR n - NUME - ORDINE – Index Curent - POZITIE – Variabila Sistem

TABELA de BAZA 1 - Nume

- Indecsi atasati

TABELA de BAZA 2 - Nume

- Indecsi atasati

TABELA de BAZA m - Nume

- Indecsi atasati

Modele de Date / Modelul Relational ca Model Strict de Date 321

Cursorul ca Structura este descris de urmatoarele elemente:

o Nume Cursor – construit din Numele Tabelei de Baza sub forma unui Alias

o Index Curent – purtatorul Ordinii de Inspectie

o Numar Înregistrare Curenta – Valoare reprezentând Pozitia în Tabela de Baza

Implementarea operatiilor din Algebra Relationala cu ajutorul secventelor de comenzi de navigare e data mai jos:

o Selectie + Proiectie

Exemplul 1: Aflarea din BD medicala a medicilor interni ce lucreaza în schimbul de noapte:

CREATE SCAN schimb-noapte ON personal SET SCAN schimb-noapte LOOP UNTIL END OF SCAN

GET NEXT schimb-noapte WHERE profesie=’intern’ AND schimb=’noapte’ EXIT LOOP IF STATUS-CHECK OUTPUT SELECT FROM schimb-noapte : nume, salar

END LOOP

Eventualele operatii speciale (ex.- Eliminarea Dublurilor se face în Limbajul Gazda – Limbaj Procedural ce încorporeaza prin Apel Operatiile Relationale de acces la Baza de Date.

o Reunire (CUPLARE)

Exemplul 2: Aflarea din BD medicala a pacientilor din sectia 2 (numar-înregistrare, numar-pat):

CREATE SCAN p ON pacient CREATE SCAN o ON ocupare SET SCAN p LOOP1 UNTIL END OF SCAN p

GET NEXT p EXIT LOOP IF STATUS-CHECK numar-înregistrare=SELECT FROM p : numar-înregistrare SET SCAN o LOOP2 UNTIL END OF SCAN o

GET NEXT o WHERE o. numar-înregistrare=p.numar-înregistrare AND cod-sectie=’2’ EXIT LOOP2 IF STATUS-CHECK OUTPUT SELECT FROM p:nume, o:numar-înregistrare, numar-pat

END LOOP2 END LOOP1

322 Modele de Date / Modelul Relational ca Model Strict de Date

4.2.4.7.5.2 Operatii Neprocedurale

Operatiile Neprocedurale sunt denumite si Operatii de Specificare. Ele ofera posibilitatea de descriere a Rezultatului privit ca o noua relatie. Rezultatul poate fi:

o Final – se transmite Utilizatorului

o Intermediar – se memoreaza în Baza de Date sub forma de:

§ Vedere – în Baza de Date se memoreaza Intensiunea (definirea) Vederii

§ Instantaneu - (în Baza de Date se memoreaza Intensiunea Instantaneului precum si Extensiunea sub forma unei Tabele Temporare)

Specificarea Rezultatului poate fi facuta în mai multe moduri:

o Prin redactarea de Comenzi – ex. comenzile limbajului SQL (Structure Query Language)

o Prin intermediul Ecranelor de Descriere

§ cu Selectie de Optiuni

§ cu Completare de Optiuni (Fill în Blanks) – variante ale limbajului QBE (Query By Example)

Comenzile Limbajului SQL (Limbaj Standardizat de acces la BD) se împart în:

• Comenzi de Regasire

• Comenzi de Actualizare

• Comenzi Speciale

Structura generala a Comenzilor de Regasire e reprezentata de Blocul SELECT:

SELECT [UNIQUE] lista-attribute 1 FROM lista-relatii WHERE conditie 1 GROUP BY nume-atribut HAVING conditie 2 ORDER BY lista-atribute 2

Exemplele anterioare, continând referirea la Operatorii Algebrei Relationale, sunt reluate în formulari specifice Limbajului Neprocedural SQL, sunt redate mai jos:

Exemplul 1:

SELECT nume, salar

FROM personal

WHERE profesie=’intern’ AND schimb =’N’

Exemplul 2:

SELECT pacient.nume, pacient.numar-înregistrare, ocupare.numar-pat

FROM pacient, ocupare

Modele de Date / Modelul Relational ca Model Strict de Date 323

WHERE pacient.numar-înregistrare=ocupare.numar-înregistrare AND ocupare.cod-sectie=’2’

4.2.4.7.5.3 Nivele de Definire a Operatiilor

Pentru a completa imaginea Limbajelor de Manipulare a Datelor în Bazele de Date Relationale transcriem ultima Cerere formulata în Limbajul SQL, în termenii Expresiilor de Algebra Relationala:

R = Π p.nume, p.numar-înregistrare, o.numar-pat (P ρnumar-înregistrare (∑cod-sectie =’2’ O))

Comparând cele trei forme de redactare a cererilor remarcam existenta mai multor Nivele de Definire a Operatiilor în Structurile Relationale, nivele reprezentate în schema de mai jos.

Fig. 4.2.4.7.5.3.1 Nivele de Definire a Operatiilor

Nivelul intermediar, cel de Specificare Operatoriala, este Nivelul de Referinta în aprecierea Gradului de Completitudine Relationala a unui Limbaj de Manipulare a Datelor (vezi sectiunea 4.2.4.5). Totodata el ramâne de referinta si în ceea ce priveste formarea Modului de Gândire al Proiectantului de Structuri Relationale înca din faza de Conceptie. Combinat cu Nivelul Semantic de Interpretare a Informatiilor acest Nivel Formal de Manipulare a Datelor permite evaluarea si stabilirea modului în sunt grupate informatiile în structura. Totodata permite prevederea costurilor de prelucrare înca din aceste faze incipiente de construire a structurilor.

Nivelul de Specificare Predicativa ramâne cel mai raspândit în zona de acces la datele continute în Baza de Date. Forme diverse l-au impus prin usurinta cu care poate fi utilizat, de la Comenzi de Limbaj (SQL) , pâna la Ecrane de Interfata cu Selectie sau cu Completare de Optiuni.

Nivelul Procedural se mentine pentru Extensii ale Limbajelor Predicative (PL/SQL), destinate prelucrarilor speciale (prelucrari Recursive, Tranzactionale, tratare Cursori etc.).

Nivele de Definire a Operatiilor

Neprocedurale

Procedurale

Specificare Operatoriala

Impunere Secvente de Operatii

(Navigare)

Specificare Predicativa

Nivele de Specificare

Nivel Imperativ

324 Modele de Date / Modelul Relational / Construirea Structurilor de Date

4.2.4.8 Construirea Structurilor Relationale

Scopul sectiunii de fata este de a înfatisa modul de utilizare a Caracteristicilor de Structura ale Modelului Relational, la construirea Structurilor de Date chemate sa modeleze Spatiul de Informatii al utilizatorului. Reunite într-un set de exemple concentrate, dar acoperitoare, vor fi regasite conceptele prezentate în sectiunile precedente, cu scopul de a fixa notiunile, a le îmbogati cu nuante si a le prezenta fertilitatea în confruntarea cu realitatea.

Se vor regasi trecute în revista Tipurile de Relatii ca Structuri Relationale Elementare, ce vor reprezenta Caramizile cu care se vor efectua constructiile de structuri. Vor apare solutii de implementare a Structurilor Fundamentale, 1-n si m-n, în calitate de masura a puterii constructive a Modelului de Date Relational. Se vor face comparatii cu elemente de structura din Modelele Ierarhic si Retea, pentru a înlesni transpuneri, dar si formarea unui nou mod de a gândi Relational (în Multimi si Relatii). Conceptele Modelului Obiectelor Abstracte, transpuse în implementari Relationale vor oferi sugestii de aplicare a Metodologiei de Proiectare Obiectuala prezentata deja în sectiunile anterioare. Observatii asupra modului de definire Intesionala si Extensionala a Structurilor cu preluarea proprietatilor Relatiilor Matematice, sunt de asemenea cuprinse în exemple.

In cadrul solutiilor selectate sunt prezentate atât exemple simbolice, caz în care intereseaza doar raporturilor de structura ale diferitelor elemente, cât si exemple concrete, prin care se încarca cu semantica domeniului ales, elementele care participa la construirea structurilor. 4.2.4.8.1 Generalizarea Entitatilor Exemplul 1

Descrierea sumara a unei Colectii de Date STUDENTI se face cu Relatia urmatoare:

STUDENT (Marca*, Nume, Data-nastere)

Neexistând nici-un Atribut de tip Categorie aceasta descriere conduce la o Structura de tip Entitate Completa (Fig. 4.2.4.8.1.1). In practica însa asemenea Colectii de Date vor apela întotdeauna la Structuri de tip Clasificare (încadrare în Categorii). Pentru a o apropia de realitate am enumerat în Fig. 4.2.4.8.1.2 câteva Criterii de Clasificare strict necesare pentru prelucrari curente. Construirea unei Ierarhii de Generalizare, conform celor mentionate în Procesele de Generalizare din Modelul Obiectelor Abstracte (vezi si sectiunea 4.2.4.7.3.2), apare o metoda deosebit de utila pentru implementarea corecta a Structurilor Relationale.

Fig. 4.2.4.8.1.1 Structura STUDENT- varianta 1

• •

Ec

*

m

n d

Modele de Date / Modelul Relational / Construirea Structurilor de Date 325

Fig. 4.2.4.8.1.2 Structura de Generalizare pentru STUDENT

Tocmai datorita frecventei cu care apar Procesele de Clasificare a Colectiilor de Date ele nu trebuie pierdute din Structura si lasate în seama Procedurilor, în ciuda faptului ca, transpuse în Structuri Relationale Criteriile de Clasificare si Categoriile (Fig. 4.2.4.8.1.2) vor determina explozia numarului de Relatii în Baza de Date (Fig. 4.2.4.8.1.3).

STUDENT (Marca*, Nume, Data-nastere, Sex, Finantare, Situatie-scolara, Stare)

SEX (Cod*, Nume)

FINANTARE (Cod*, Nume)

SITUATIE-SCOLARA (Cod*, Nume)

STARE (Cod*, Nume)

Fig. 4.2.4.8.1.3 Structura STUDENT- varianta 2

Caracterul dinamic al Extensiei Ierarhiilor de Generalizare poate provoaca dificultati.

Sex - Feminin - Masculin

Finantare - Buget - Plata

Situatie Scolara - Promovat

- Nepromovat

STUDENT

..

Stare - Continuare

- Retras - Exmatriculat

- Transferat

• •

st

•

X

* c n

ss

m

• • •

S

* f n

d s

•

F

* c n

•

SS

* c n

•

ST

* c n

•

326 Modele de Date / Modelul Relational / Construirea Structurilor de Date

Adaugarea de noi Criterii determina adaugarea de noi Relatii în Baza de Date. O posibila solutie pentru rezolvarea extensiilor frecvente, poate fi gasita în transferul actualizarilor necesare din sfera Intensionala în cea Extensionala. Identitatea Atributelor de Definire a Relatiilor SEX. FINANTARE, SITUATIE-SCOLARA si STARE favorizeaza o actiune de unificare a lor. Dupa cum se va vedea aceasta actiune trebuie metodic condusa pentru a nu crea complicatii si a oferi în final solutia cea mai bine adaptata cazului concret:

o In primul pas (Fig. 4.2.4.8.1.4) se comaseaza Relatiile care descriu Criteriile de Clasificare, cu mentinerea însa a Atributelor atasate acestor Criterii în descrierea relatiei STUDENT (care se generalizeaza).

STUDENT (Marca*, Nume, Data-nastere, Sex, Finantare, Situatie-scolara, Stare)

CATEGORIE (Cod*, Nume)

Ca urmare:

§ Orice adaugare de noi Criterii determina adaugarea unor noi Atribute în STUDENT (nu însa si de Relatii noi în Baza de Date, ca în cazul precedent)

§ Desi între Entitatile CATEGORIE si STUDENT se instituie o relatie fundamentala 1 – n, un Student va apartine la o singura Categorie din fiecare Bloc de Categorii (Criteriu)

§ Identificatorul de Categorii va trebui sa fie discriminator pentru toate Categoriile (indiferent de Bloc), ceea ce va aduce dificultati la selectarea acestora de catre Utilizatorul Final

Fig. 4.2.4.8.1.4 Structura STUDENT- varianta 3

o In al doilea pas (Fig. 4.2.4.8.1.5) se comaseaza si Atributele de tip Categorie.

STUDENT (Marca*, Nume, Data-nastere)

CATEGORIE (Cod*, Nume, Tip, Ascendent)

CATEGORIE-STUDENT (Categorie*, Student*)

Pentru aceasta:

§ In Relatia Unificata CATEGORIE vor apare doua Atribute noi:

• •

st

•

C

* c n

ss

m

• • •

S

* f n

d s

•

Modele de Date / Modelul Relational / Construirea Structurilor de Date 327

• Tipul Entitatii de Generalizare Criteriu, Categorie care va permite:

o Înregistrarea în Baza de Date si a Criteriilor alaturi de Categorii

o Diferentierea Categoriilor de Criterii

• Ascendentul Entitatii de Generalizare (Cod) care va permite:

o Deducerea Criteriilor la care apartin Categoriile

o Deducerea Categoriilor unui Criteriu

§ Legaturile dintre Criterii, Categorii si Studenti va fi implementata printr-o Relatie de tip Legatura Simpla (CS), care asigura:

• Materializarea unei legaturi Entitate – Categorie printr-o Tupla Fizica din Relatia de Legatura

• Unicitatea unei Instante de Categorie prin Identificatorul (c, s) atasat Relatiei de Legatura

§ Orice adaugare de noi Criterii determina doar actualizarea extensiei Relatiei CATEGORIE, cu o noua instanta de Categorie, sau de Criteriu (Bloc)

Fig. 4.2.4.8.1.5 Structura STUDENT- varianta 4

Exemplul tratat tine sa evidentieze, înca de la începutul prezentarii tehnicii de concepere si construire a Structurilor de Date, faptul ca aceasta activitate poate fi condusa de reguli precise si nu lasata la inspiratia proiectantului. Absenta cunostintelor legate de Procesele de Abstractizare determina în general cautari laborioase acolo unde utilizarea unor componente structurale predefinite transforma actul artizanal în proces industrial. Ne referim bineînteles la Sisteme Complexe si Dinamice în care adaugarea înca a unui Atribut sau a înca a unei Legaturi Relationale (asa numita ”potcovire”) devine în timp paguboasa si determina în final refacerea integrala a structurii, prin regândirea ei. Ar mai fi de subliniat faptul ca teama orgolioasa legata de pierderea personalitatii de ”specialist în programare” este complet nejustificata atunci când vorbim de probleme reale. Problema încorporarii maxime de semantica începe de la punctul în care dispunem de instrumente puternice, care sa elimine rutina ori de câte ori aceasta e posibil.

CS

* * s

a

• •

C

* c

n

m

•

S

* d

n

•

c

• t

328 Modele de Date / Modelul Relational / Construirea Structurilor de Date

4.2.4.8.2 Agregarea Entitatilor

Aparent mai simpla, problema implementarii Legaturilor între Entitati cuprinde Procesele Abstracte de Generare prin Agregare (vezi si sectiunea 4.2.4.7.3.1). In general problema Agregarii este raportata la modurile de implementare a Structurilor Fundamentale. 4.2.4.8.2.1 Structuri 1 - n

Structurile 1 – n pornesc cu recunoasterea în Clasele de Entitati a unei Entitati Obiect Posesor si a unei Multimi de Entitati Obiect Membri.

Exemplul 1

Sa adaugam la structura comentata în sectiunea precedenta GRUPA de Studenti.

STUDENT (Marca*, Nume, Data-nastere, Grupa)

GRUPA (Cod*, Nume, Tip, Ascendent)

Prima forma de implementare este cea minimala, reprezentata de o singura Legatura Relationala (S.g → G.c), suficienta datorita naturii 1 – n a Legaturii (Fig. 4.2.4.8.2.1.1)

Fig. 4.2.4.8.2.1.1 Structura GRUPA / STUDENT- varianta 1

Se remarca urmatoarele:

o Asemanarea cu structurile de Generalizare prin aceea ca, asa dupa cum am mai aratat, proprietatea de apartenenta la un Posesor (Grupa) determina o divizare de tip Partitie în Multimea Studentilor.

o Pentru a ne apropia de cazul real am mentinut proprietatile de Clasificare ale Entitatii GRUPA, în care Atributul Nume (n) e definit pe Multimea de Valori An, Grupa, Subgrupa, cu evidentierea Legaturii de Ascendenta (G.a → G.c)

In varianta a doua încercam sa utilizam Structura Unificata propusa în sectiunea 4.2.4.7.3.3. Se ajunge la structura din Fig. 4.2.4.8.2.1.2. Cu aceasta constructie s-a facut trecerea la structuri m – n, cu care putem modela si structuri 1 – n, daca adaugam o Restrictie de Unicitate a Descendentului în Relatia de Legatura între Entitati, care implementeaza Unicitatea Ascendentului în Structura Ierarhica (un Student apartine la o singura Grupa) .

a

• •

G

* c

n

m

•

S

* d

n

• • t

• g

Modele de Date / Modelul Relational / Construirea Structurilor de Date 329

STUDENT (Marca*, Nume, Data-nastere)

GRUPA (Cod*, Nume, Tip, Ascendent)

GRUPA-STUDENT (Grupa*, Student*)

Fig. 4.2.4.8.2.1.2 Structura GRUPA / STUDENT- varianta 2

Implementarea acestei Restrictii se face foarte usor prin atasarea unei conditii de Cheie Candidata pe Componenta Student a Cheii Primare din Relatia GS. Solutia este mai avantajoasa decât Eliminarea Grupei din Cheia Primara , întrucât asigura posibilitatea Extensiei Structurii de la 1 – n, la m – n, odata cu modificarea Specificatiilor de Definitie (”un Student poate apartine la mai multe Grupe de Studiu pentru diferite activitati”). Solutia de modificare a Cheii Primare poate conduce la alte modificari legate de Restrictiile implicate de aceasta cheie. 4.2.4.8.2.2 Structuri m - n

Structurile m – n se implementeaza în mod direct utilizând Tipul General de Structura Relationala (vezi sectiunea 4.2.4.7.3.3). Construirea acestor structuri se realizeaza întotdeauna prin intermediul unor Relatii de tip Legatura , care leaga între ele Relatii de tip Entitate sau alte Relatii de tip Legatura . Gradul Relatiilor de Legatura este dat de Numarul Relatiilor pe care le cupleaza prin agregare. Fiecare Legatura Relationala cu Relatia de tip Legatura defineste o Clasa de Ansambluri de Realizari ale unei Entitati (vezi sectiunea 4.1.1.4), adica o descriere de Submultimi de Tuple Copii (Membri) asociate unor Tuple Parinte (Posesori). Modul de exploatare a acestor structuri este redat în continuare. Exemplul l:

Fie o Legatura Fundamentala m-n între Entitatile E1 si E2 dintr-un Spatiu de Informatii. O asemenea Legatura poarta întotdeauna o semantica generala de forma:

o O Instanta Posesor e1i din E1 are e2j Instante Membri din E2, pentru j ∈1 .. n

o O Instanta Membru e2j din E2 are e1i Instante Posesori din E1, pentru i ∈1 .. m

GS

* * s

a

• •

C

* c

n

m

•

S

* d

n

•

g

• t

GS Grupa Student

G1 S1 G1 S2 G2 S3 G2 S4

330 Modele de Date / Modelul Relational / Construirea Structurilor de Date

Fig. 4.2.4.8.2.2.1 Legatura m – n (Diagrama Simbolica )

Structura m - n din Spatiul Informatiilor (Fig. 4.2.4.8.2.2.1) este modelata într-un Spatiu Relational de Date prin Arborele de Structura reprezentat în Fig. 4.2.4.8.2.2.2.

E – Relatie de tip Entitate i - Identificator L – Relatie de tip Legatura d - Descriptor

Fig. 4.2.4.8.2.2.2 Legatura m – n (Arborele de Structura )

Pornind de la notatiile:

eij - Realizarea (Instantierea) j a Entitatii Ei

lk - Realizarea k a Entitatii L

sa consideram ca în Planul Valorilor din Spatiul Informatiilor are loc urmatoarea Relatia m-n : e11 e21 e11 e22

e12 e21 e12 e23

unde se remarca:

- Partajarea Realizarii Posesor e11 de catre Realizarile Membri e21 si e22

- Partajarea Realizarii Membru e21 de catre Realizarile Posesori e11 si e12 Structura Relationala din Planul Valorilor de Date va arata ca cea din Fig. 4.2.4.8.2.2.3. Extragerea Informatiilor din aceasta Structura se realizeaza cu urmatoarele Proceduri:

o Extragerea Membrilor unui Posesor

n

m Membrii unui Posesor Posesorii unui Membru

E 2

E 1

E 1

d

E 2

d

L

d

* i

legatura 1 - n *

i

* i1

* i 2

legatura 1 - m

Modele de Date / Modelul Relational / Construirea Structurilor de Date 331

§ Procedura Extragere Membri

Pentru toate Tuplele e1i ale lui E1

Pentru toate Tuplele lk din L cu L. i1 = E1. i

Adauga Tupla e2 j din E2 cu E2 . i = L. i2 în Rezultat

Sfârsit

Afisaza Rezultat pentru e1i

Sfârsit

§ Rezultate

e11 → e21, e22

e12 → e21, e23

Fig. 4.2.4.8.2.2.3 Legatura m – n (Arborele de Structura)

o Extragerea Posesorilor unui Membru

§ Procedura ExtragerePosesori

Pentru toate Tuplele e2 j ale lui E2

Pentru toate Tuplele lk din L cu L. i2 = E2 . i

Adauga Tupla e1i din E1 cu E1. i = L. i1 în Rezultat

Sfârsit

Afisaza Rezultat pentru e2 j

Sfârsit

§ Rezultate

e21 → e11, e12

e22 → e11

e23 → e12

ENTITATE1

Tupla Idntificator Descriptor e11 i11 d11 e12 i12 d12

ENTITATE2

Tupla Idntificator Descriptor e21 i21 d21 e22 i22 d22 e23 i23 d23

LEGATURA

Tupla Idntificator1 Idntificator2 Descriptor l1 i11 i21 d1 l2 i11 i22 d2 l3 i12 i21 d3 l4 i12 i23 d4

332 Modele de Date / Modelul Relational / Construirea Structurilor de Date

O problema importanta pe care o ridica structurile cu Relatie de Legatura este stabilirea Identificatorilor acestei Relatii. Identificatorii sunt reprezentati de Cheia Primara si de Cheile Candidate. Acestia sunt cel mai adesea compusi din combinatia Cheilor Primare migrate în Relatia de Legatura din Relatiile de Baza pe care le reuneste. Pentru a nu migra Chei Compuse foarte frecvent se implementeaza în Relatia de Legatura Chei Surogate (vezi sectiunea 4.2.4.4). Exista însa si cazuri în care Relatia de Legatura dispune de o Cheie Primara Simpla (Necompusa), dar naturala. Vezi exemplul urmator. Exemplul 2:

Sa consideram informatiile care descriu Cursele Aviatice între Localitati. Schema de Relatii este cea de mai jos:

PILOT (Marca*, Nume, Prenume, Grad)

AVION (Cod*, Capacitate, Tip)

LOCALITATE ( Cod*, Nume )

DECOLARE (Numar*, Zi, Ora)

CURSA (Numar*, Comandant, Însotitor, Avion, Pornire, Destinatie, Decolare)

Identificatorii Relatiei CURSA sunt multiplii. Ei formeaza Cheile Candidate ale Relatiei, pe care le enumeram în continuare:

- Numar – CURSA are un Atribut Propriu care constituie Cheia Primara

- Comandant + Decolare – Identificator rezultat din unicitatea Persoanei în timp

- Însotitor + Decolare – – Identificator rezultat din unicitatea Persoanei în timp

- Avion + Decolare – – Identificator rezultat din unicitatea Avionului în timp

- Pornire+Destinatie+Decolare – Identificator rezultat din unicitatea Cursei în timp

Declararea Cheile Candidate foloseste pentru încorporarea Regulilor de Validare Semantica în structura. De aceea alegerea corecta a Cheilor Candidate este o premiza pentru simplificarea Regulilor de Validare a Relatiilor. In locul unor proceduri elaborate de verificare, este suficienta, ca în cazul de fata, atasarea Indecsilor adecvati Cheilor Candidate. Structura este grafic descrisa în Fig. 4.2.4.8.2.2.4. Exemplul3:

Sa descriem acum o noua Structura de Date care sa contina informatii referitoare la Societati Comerciale Partenere. Arborele de Structura este cel din Fig. 4.2.4.8.2.2.5, iar Schema de Relatii este cea de mai jos:

SOCIETATE (Cod*, Denumire )

TIP - PARTENER (Cod*, Nume )

PARTENER (Societate*, Partener*, Tip*)

Modele de Date 333

P –PILOT m – Marca q – Capacitate cd - Comandant l - Decolare A – AVION n – Nume t – Tip i - Însotitor L – LOCALITATE p – Prenume nr – Numar a - Avion D – DECOLARE g – Grad z – Zi P – Localitate Pornire C – CURSA c – Cod o – Ora d - Localitate Destinatie

Fig. 4.2.4.8.2.2.4 Structura de Date Curse Aviatice

cd

* * **

A

t

L

c n q n

z

D

nr o

P

p

m c

a

C

i

d p

l *

g

nr

334 Modele de Date

In Cheia Primara a Relatiei de Legatura P (definita pe S x S x T) se remarca faptul ca atributul Tip reprezinta o însusire de tip Rol si nu de tip Caracteristica, aceasta întrucât:

o In calitate de Caracteristica

§ Ar descrie Entitatea SOCIETATE, indiferent de Legatura ei cu alte Entitati

§ S-ar regasi între Atributele Entitatii SOCIETATE

o In calitate de Rol

§ Descrie Legatura care se creeaza la un moment dat între o Instanta a SOCIETATII (Societatea 1) cu alta Instanta a SOCIETATII (Societatea 2), care joaca Rolul dat de Tip (Producator, Beneficiar, Furnizor) pentru prima

§ Se regaseste între Atributele Relatiei de Legatura (PARTENER)

§ Daca participa în Cheia Primara alaturi de Identificatorul Entitatii atunci aceeasi Entitate (SOCIETATE) poate juca Roluri diferite (Parteneri diferiti) în Tuple diferite (Societate-Producatoare, Societate-Beneficiara, Societate-Furnizoare)

Fig. 4.2.4.8.2.2.5 Structura de Date Societati Partenere

Sa adaugam la structura precedenta descrierea Contractelor între Partenerii definiti anterior. Rezulta Structura din Fig. 4.2.4.8.2.2.6, derivata din Schema de Relatii de mai jos:

SOCIETATE (Cod*, Denumire)

TIP- PARTENER (Cod*, Nume)

PARTENER (Societate*, Partener*, Tip-Partener*)

CONTRACT (Cod**, Parteneri*, Numar-Contract*, Valoare-Contract, Termen-Contract)

*

* *

* P

s

p

t

S

c d

T

c n

* S –SOCIETATE T – TIP-PARTENER (Producator, Beneficiar, Furnizor) P – PARTENER c – Cod d – Denumire s – Societate p – Partener n – Nume t – Tip

Modele de Date 335

S –SOCIETATE c – Cod p – Partener v – Valoare pt - Pret T – TIP-PARTENER d – Denumire t – Tip tc – Termen Contractual ct - Cantitate P – PARTENER n – Nume pi – Parteneri pr - Produs C – CONTRACT s – Societate nr – Numar Contract rd – Numar Rând

PC – POZITIE CONTRACT Fig. 4.2.4.8.2.2.6 Structura de Date Contracte / Parteneri

C

pi

v

nr

tc

*

* *

* P

s

p

t

S

c d

T

c n

*

*

* *

c

*c

*

PR

c d

*

PC

c

rd p

*

pt

ct

336 Modele de Date / Modelul Relational / Construirea Structurilor de Date

Pentru a putea lega doi Parteneri printr-un Contract se introduce o Cheie Surogata P. c în Relatia de Legatura PARTENER, care sa evite migrarea celor trei Componente de Cheie Primara (P.s, P.p, P.t) în Relatia Mixta CONTRACT. Relatia CONTRACT joaca aici un dublu rol de:

o Relatie de tip Entitate (din punct de vedere Semantic în Spatiul Informatiilor) în calitate de Document Comercial, care se Identifica prin Numarul de Document si prin Atributele Descriptoare C.v si C.tr

o Relatie de tip Legatura (din punct de vedere Structural în Spatiul Datelor) în calitate de Relatie care leaga doua Entitati bine individualizate:

§ Un Cuplu de Parteneri – Relatia P, identificata prin C. pi

§ Un Document Oficial ce consemneaza colaborarea între Societati - Relatia C, identificata prin (C. pi + C. Nr)

In Fig. 4.2.4.8.2.2.6 se poate remarca modul de construire a unei Relatii de Legatura de Grad 2 (relatia C), pornind de la o Relatie de Legatura de Grad 1 (relatia P). Relatiile initiale, de tip Entitate, pot fi considerate de Grad 0 . Semantica încorporata în Entitatea Contract sugereaza nu numai posibilitatea, ci necesitatea ca, la o extensie a structurii, acest Document sa intre în Legatura cu alte Entitati (ex. Obligatii Contractuale, Istoric de Evolutie a Starii Contractului etc.). Pentru acest motiv a fost deja prevazuta, pe post de Cheie Primara un nou Identificator (C. c), sub forma unei noi Chei Surogate. Ea este folosita în continuare pentru introducerea în Structura de Date a Obligatiilor Contractuale specificate în Rândurile Documentului de Contractare (Tabela POZITIE CONTRACT). Pentru aceasta sa consideram extensia Schemei de Relatii cu urmatoarele Relatii:

PRODUS (Cod*, Denumire, Pret)

RANDURI DOCUMENT (Contract*, Numar Rând*, Produs, Cantitate)

Este evidentiata cascadarea Relatiilor de Legatura prin introducerea unei Relatii de Legatura de Grad 3 (POZITIE CONTRACT), care nu poate fi evitata întrucât are Atribute Proprii (pr, ct). Aceasta noua Relatie asigura totodata o constructie detaliata a structurii BENEFICIAR–PRODUS–CONTRACT cu mentinerea Independentei necesare între Entitati (POZITIE CONTRACT, pe post de Rând Document, fiind repetitiv trebuie implementat ca o Entitate de sine statatoare, care preia Informatiile atasate Pozitiilor Contractuale (vezi Fig. 3.4.4.1.1). Prin aceasta completare de structura Relatia Mixta CONTRACT, pe post de Antet Document, devine Relatie de Legatura între PARTENERI si POZITII CONTRACTUALE

Vom urmari în continuare Legarea Entitatilor într-un caz particular în care cele doua Entitati care se leaga se suprapun. Exemplul 4:

Sa implementam o Relatie între Studenti care sunt Parteneri. Adaugam la Relatia de tip Entitate STUDENT o noua Relatie de tip Legatura PARTENER (Fig. 4.2.4.8.2.2.7).

STUDENT (Marca*, Nume, Data-nastere)

PARTENER (Student 1, Student 2)

Modele de Date / Modelul Relational / Construirea Structurilor de Date 337

Relatia PARTENER depinde strict de definirea relatiei STUDENT. Daca dispare Relatia S, dispare complet si semnificatia Relatiei P.

De asemenea, la fel ca în cazul general al Relatiilor de Legatura , Relatia Mixta PARTENER, reprezinta mai degraba legaturi între alte Relatii (în cazul de fata Relatia STUDENT luata de doua ori în calcul, ca Student 1 si ca Student 2). Altfel exprimat, Relatia Mixta PARTENER stabileste legatura între Atributele Descriptoare ale Entitatii STUDENT (Student 1 si Student 2) si nu între Atributele Relatiei PARTENER (s1 si s2). Relatia PARTENER implementeaza fidel Relatia Matematica între doua Multimi , asa încât va purta, definite în Intensiune (prin Restrictii) si reflectate în Extensiune (prin Valori) toate proprietatile Relatiei Matematice. Pentru a le putea urmari mai îndeaproape sa încarcam cu semantica Relatia Partener, transformând-o în relatie de Prietenie (Fig. 4.2.4.8.2.2.8).

Fig. 4.2.4.8.2.2.7 Structura STUDENT - PARTENER

Sa consideram ca Relatiei de Prietenie îi putem asocia afirmatia:

„Prietenul Prietenului meu îmi este Prieten”

Atunci Relatia de Prietenie este o Echivalenta pe multimea Studentilor, cu proprietati bine definite (Reflexivitate, Simetrie, Tranzitivitate). In Structura Relationala de Date Legatura de Prietenie poate fi implementata în doua moduri:

o Cu o Legatura Relationala Recursiva de tip 1 – n, în cadrul Relatiei STUDENT (Fig. 4.2.4.8.2.2.9)

STUDENT (Marca*, Nume, Data-nastere, Prieten)

Fig. 4.2.4.8.2.2.8 Structura STUDENT - PRIETEN (varianta 1)

* *

S

m n v

P

s2 s1 *

*

S

m n p d

STUDENT m n d p M1 N1 D1 M2 M2 N2 D2 M4 M3 N3 D1 M5 M4 N4 D3 NULL M5 N5 D4 NULL M6 N6 D1 M3 M7 N7 D1 NULL

338 Modele de Date / Modelul Relational / Construirea Structurilor de Date

Caracteristicile acestei structuri sunt:

• Structura cu o singura Tabela de Baza (Relatie)

• Putin expresiva structural deoarece:

o Reprezentantul Clasei de Echivalenta (primul Element introdus în Echivalenta ), apare în coloana m si nu apare în coloana p

o Membrii Clasei de Echivalenta (restul Elementelor introduse în Echivalenta) apar în coloana p si în coloana m

o Reprezentantul lipseste din multimea Membrilor (nu apare în coloana p)

• Dificultati de actualizare datorate necesitatii de gestiune a proprietatilor de Simetrie si Tranzitivitate a relatiei de Echivalenta

Fig. 4.2.4.8.2.2.9 Structura STUDENT - PRIETEN (varianta 2)

o Cu o Legatura Relationala Recursiva de tip m – n, în cadrul Relatiei STUDENT (Fig. 4.2.4.8.2.2.9)

STUDENT (Marca*, Nume, Data-nastere, Prieten)

PRIETEN (Student*, Prieten*)

Caracteristicile acestei structuri sunt:

• Structura cu doua Tabele de Baza (Relatii)

• Foarte expresiva structural (e fidela Relatiei Matematice) deoarece:

o La fiecare introducere de Tupla (Mx) în S se poate genera automat si o Tupla (Mx, Mx) în P (pentru respectarea proprietatii de Simetrie)

o La fiecare introducere de Tupla (Mx, My) în P se poate genera automat în P câte o Tupla (My, Mz) pentru:

∀ x (Mx, Mz) ∈ P

(pentru respectarea proprietatii de Simetrie si Reflexivitate)

PRIETEN S1 S2 M1 M2 M1 M4 M3 M5 M5 NULL M6 M3 M7 NULL

* *

S

m

n v

P

s2 s1

*

Modele de Date / Modelul Relational / Construirea Structurilor de Date 339

o Membrii Clasei de Echivalenta ai lui Sx ∈ S fata de Echivalenta P e data de Proiectia pe coloana S2 a tuplelor cu S1=Sx:

π S2 ρ S1=Sx P • Dificultatile de actualizare constau în cresterea numarului de Tuple

în P, impunându-se ca solutie virtualizarea tuplelor aditionale, cu materializarea lor în momentul interogarii printr-o Functie de Calcul adecvata

• Structura se preteaza si la extensii care apropie exemplul de lumea reala în care afirmatia Prietenia nu e o relatie de Echivalenta, ci mai degraba una de Similitudine. Relaxând Relatia de Prietenie prin eliminarea conditiei de Tranzitivitate se trece la o structura m – n care nu poate fi implementa decât în Varianta 2. Nici conditia de Simetrie nu poate fi luata în calcul când se vorbeste de Prietenie. Grupele de Prieteni formeaza pe Multimea Studentilor (si nu numai a lor) mai degraba o Acoperire decât o Partitie. Cu toate aceste relaxari, Structura din Varianta 2 rezista, dovedindu-si flexibilitatea

Relatiile de Legatura pot reprezenta legaturi între doua sau mai multe Relatii, indiferent de Tipul lor. Numarul Relatiilor legate indicând si Gradul Relatiei de Legatura . Legatura poate fi facuta pe un nivel (Fig. 4.2.4.8.2.2.11) sau pe mai multe Nivele de Legatura. Legatura pe mai multe nivele se impune atunci când Relatiile de Legatura Intermediare sunt Relatii Complete, întrucât au Atribute Proprii ce trebuiesc implementate la acel nivel de descriere (Fig. 4.2.4.8.2.2.13, ca de altfel si anterior Fig. 4.2.4.8.2.2.6). Exemplul 5:

Sa consideram o Structura de Informatii referitoare la Gestiunea Comunicarilor Stiintifice. Schema de Relatii ce descrie Structura de Date este urmatoarea:

PROFESOR (Marca*, Nume, Specialitate)

STUDENT (Marca*, Nume, An)

TEMA (Cod*, Nume, Tip, Ascendent)

CONFERINTA (Cod*, Loc, Data, Tematica)

COMUNICARE (Student*, Profesor*, Conferinta*, Tema*, Apreciere)

In prima acceptiune se considera ca o Comunicare este întocmita de un Colectiv format dintr-un Profesor si un Student. Comunicarile sunt încadrate într-o Tema, iar Conferintele într-o Tematica (Domeniu de Teme). Poate fi definita ca urmare o Ierarhie de Generalizare (Fig. 4.2.4.8.2.2.10), care va fi apoi implementata în cadrul Structurii de Date cu ajutorul Atributului ce descrie Referinta Relationala, Ascendent din Entitatea de tip Categorie TEMA (Fig. 4.2.4.8.2.2.11).

340 Modele de Date / Modelul Relational / Construirea Structurilor de Date

Fig. 4.2.4.8.2.2.10 Ierarhia de Generalizare pentru Entitatea TEMA

Fig. 4.2.4.8.2.2.11 Structura COMUNICARE ca Entitate Agregata P x S x C x T

* ***

* * * *

S

a

C

c

t

T

c

n

n n

c

l

CM

p a s

t

P

s m m

d a

t

TEMA

Tema 1

Domeniu 1

Tema 1 .. Tema 1

Domeniu 2

Tema 1 ..

..

Modele de Date / Modelul Relational / Construirea Structurilor de Date 341

Legatura care asigura construirea Ierarhiei de Generalizare în Spatiul Datelor este de tip Recursiv, întrucât atât Criteriile (Blocurile de Categorii), cât si Categoriile sunt instante ale aceleiasi Entitati (TEMA), care reuneste Obiecte de tip Criteriu si Obiecte de tip Categorie. Ca urmare el va receptiona trei Legaturi Relationale:

o Generalizarea Conferintelor prin Tematici (Domenii) – (C.t → T.c)

o Generalizarea Comunicarilor prin Teme (CM.t → T.c)

o Generalizarea Temelor prin Domenii (T.a → T.c)

Legaturile principale în cadrul Structurii de Date din Fig. 4.2.3.8.2.2.11 sunt de Agregare, prin definirea unei Relatii (COMUNICARE) pe Produsul Cartezian P x S x C x T. Diagrama Simbolica din Fig. 4.2.4.8.2.2.12 reda Legaturile Directe (cu linie continua) si Induse (cu linie punctate), de tip m – n si 1 – n, ce leaga Entitatile pe care se defineste Produsul Cartezian din care se extrage Relatia Finala (COMUNICARE).

Fig. 4.2.4.8.2.2.12 Gestiunea Comunicarilor – Legaturi Fundamentale

Sa încercam sa adaugam o noua Cerinta la structura discutata:

„In Colectivul de redactare a unei Comunicari poate participa mai mult de un Student”

Aparent minora, completarea corecta a structurii cu aceasta informatie determina modificari însemnate. Sa analizam pentru început câteva solutii posibile:

o Extinderea simpla prin dublarea Atributului Student din COMUNICARE

§ Structura Relatiei COMUNICARE devine „Volens nolens” Ierarhica

• Relatia va contine Grupul STUDENTI, cu instante descrise de Valori de Atribute si nu de Tuple

• Adaugarea unor Descriptori ai STUDENTILOR / COMUNICARE se face prin dublarea lor în Lista de Atribute (ex. Prioritate, Rol, Aport etc., care vor alatura fiecarui Atribut Student)

S se preocupa de T

T e prezenta în CM C gazduieste CM

S prezinta CM P prezinta CM

P se preocupa de T

PROFESOR

CONFERINTA TEMA

STUDENT P colaboreaza cu S

C e în domeniul D

COMUNICARE P participa laC

T e în domeniul D S participa la C

342 Modele de Date / Modelul Relational / Construirea Structurilor de Date

• Extinderea numarului de Studenti participanti va determina de fiecare data modificarea Structurii Logice

§ Relatia COMUNICARE va contine Atribute care nu o descriu direct, fiind ca urmare Improprii (ex. Prioritate, Rol, Aport STUDENT în COMUNICARE)

o Extinderea Structurii de Date cu Entitatea ECHIPA (Fig. 4.2.4.8.2.2.13), singura capabila sa regrupeze noile informatii care se cer în structura si anume:

§ O COMUNICARE e pregatita de o ECHIPA de Autori (un Profesor si o Multime de Studenti) si nu o Pereche de Autori (un Profesor + un Student)

§ La CONFERINTA participa o COMUNICARE pregatita de o ECHIPA

§ ECHIPA va avea Atribute Proprii, care nu pot fi implementate în alta Relatie

In aceste conditii, structura initiala trebuie modificata dupa cum urmeaza:

PROFESOR (Marca*, Nume, Specialitate)

STUDENT (Marca*, Nume, An)

ECHIPA (Cod*, Nume, Profesor)

ECHIPA-STUDENTI (Cod*, Prioritate, Rol, Aport)

TEMA (Cod*, Nume, Tip, Ascendent)

CONFERINTA (Cod*, Loc, Data, Tematica)

COMUNICARE (Student*, Profesor*, Conferinta*, Tema*, Apreciere)

Noua structura este reprezentata în Fig. 4.2.4.8.2.2.13. De ce modificarea este importanta? Daca ea este realizata pe un Model de Date în Dezvoltare, adaugarea a înca doua Relatii si modificarea câtorva Liste de Atribute si Referiri Asociative pare neînsemnata. Când însa este vorba de acordarea la aceste modificari a unei Baze de Date în Functiune, lucrurile se complica. Este suficient sa privim doar modificarea Cheilor Primare, care atrage dupa sine modificarea Restrictiilor de Integritate, pentru a întelege Întristarea Proiectantului în fata unei asemenea Cerinte Inopinate. Gasim un bun prilej pentru a atrage atentia asupra Identificatorului Relatiei ECHIPA-STUDENTI. Migrarea unei Chei Primare (E.c) în Identificatorul (e+s) defineste Relatia ES ca o Relatie de tip Mixt. Disparitia Relatiei ECHIPA compromite Relatia ECHIPA-STUDENTI, ceea ce rezulta si din caracterul Legaturii Mandatat – Optional, daca nu chiar Mandatat – Mandatat, între cele doua Entitati.

Exemplul6:

Structura care urmeaza implementeaza tot o Legatura Fundamentala m – n. Implementarea se face însa în acest caz printr-o referire reciproca a doua Atribute de Legatura jucând rolul de Descriptori.

PROFESOR (Marca*, Nume, Prenume, Sex, Data-Nasterii, Domeniu-de-Interes)

STUDENT (Marca*, Nume, Prenume, Sex, Data-Nasterii, Domeniu-de-Interes)

Modele de Date 343

Fig. 4.2.4.8.2.2.13 Structura COMUNICARE ca Entitate Agregata E x C x T

***

* *

c

t

T

c

n

c

l

CM

e a t

d a

t

* *

S

a n n

e

P

s m m

*

E

c

n

p

*

ES

s p r a

* C

344 Modele de Date / Modelul Relational / Construirea Structurilor de Date

Schema de Relatii e descrisa grafic în Fig. 4.2.4.8.2.2.14. Aparent nimic nu pare a deranja raporturile între elementele Structurii Relationale. Ba mai mult s-a reusit implementarea unei structuri m – n fara Relatie de Legatura . Si totusi, asa dupa cum s-a aratat în sectiunea 4.2.4.7.2.1 (Fig. 4.2.4.7.2.1.4 ), Structura e Incompleta, purtând în ea toate „Relele” implicate de Dependentele Nedorite.

Fig. 4.2.4.8.2.2.14 Structura Profesor – Student – Domeniu-de-Interes (Varianta 1)

Sa analizam fisurile din structura:

o Prezenta aceluiasi Descriptor, Domeniu-de-Interes, repetat în doua Atribute ale structurii cauzând Redondanta si implicit Inconsistenta

o Absenta unei Chei Primare dintr-o Legatura Relationala, care, asa cum s-a vazut în repetate rânduri, nu poate implementa decât Legaturi Fundamentale 1 – n

o Numele Domeniu-de-Interes nu descrie nici pe Profesor nici pe Student, priviti ca Entitati, ci Entitatea Domeniu-de-Interes, momentan absenta din structura

Ca urmare se impune înlocuirea ei cu structura din Fig. 4.2.4.7.2.1.15.

Fig. 4.2.4.8.2.2.15 Structura Profesor – Student – Domeniu-de-Interes (Varianta 2)

P

m n

p d s

*

dn

S

m n

p d s

*

dn

P

m n

p d s

*

dn

S

m n

p d s

*

dn

*

T

c

n

a

t

Modele de Date / Modelul Relational / Construirea Structurilor de Date 345

Completarea structurii se face prin adaugarea unei noi Entitati, care sa permita transformarea Descriptorului care joaca rolul Atributului de Legatura în Identificator, singurul care poate realiza selectarea corecta a Tuplelor ce intra în Legatura Relationala si elimina totodata Redondanta, asigurând Consistenta structurii prin unicitatea Valorilor de Descriptori (Numele T.n din Fig. 4.2.4.8.2.2.15, în loc de P.d = S.d din Fig. 4.2.4.8.2.2.14 ).

PROFESOR (Marca*, Nume, Prenume, Sex, Data-Nasterii, Domeniu-de-Interes)

STUDENT (Marca*, Nume, Prenume, Sex, Data-Nasterii, Domeniu-de-Interes)

TEMA (Cod*, Nume, Prenume, Sex, Data-Nasterii, Domeniu-de-Interes)

4.2.4.8.3 Reprezentarea Structurilor Ierarhice

Prezentarea modului de realizare relationala a Structurilor Ierarhice a fost considerata utila pentru construirea Modelelor de Date, datorita frecventei cu care Arborescenta, ca Tip de Structura, apare în Reprezentarea Informatii ce urmeaza a fi transpuse în Date. O seama de probleme legate de Identificarea Contextuala si Necontextuala apar interesante în special pentru ”Proiectantii Relationisti”. In Structurile de Date se considera Structura de Baza ca fiind alcatuita din multimile sau submultimile de Caracteristici (Atribute) grupate prin simpla lor Alaturare sau Subordonare, fara prezenta nici unei Referiri Exterioare. Aceste ultime elemente le vom considera ca formând suportul Structurii Suprapuse. Termenii sunt preluati din modelele clasice de Baze de Date, Ierarhic si Retea, prezentate în sectiunile 4.2.2 si 4.2.3. Raporturile de Alaturare sau Subordonare între date se realizeaza prin declararea Grupurilor (Blocurilor) de Caracteristici (Câmpuri Elementare de Date), care pot fi în raporturi reciproce de Echivalenta sau de Incluziune. Aceste raporturi sunt bine reprezentate în structurile de tip Arborescenta. Un exemplu în acest sens este reprezentat grafic în Fig. 4.2.4.8.3.1. Sunt evidentierea urmatoarelor Nivele de Ierarhizare:

- Baza de Date - BD

- Entitati - E 1 , E 3

- Subentitati - E 2

Structura esentiala pentru orice colectie ampla de date, Arborescenta, a prezentat atractie înca de la aparitia primelor preocupari legate de Bazele de Date. Nu întâmplator Modelul Ierarhic construieste prima Structura de Date ca o Arborescenta de Segmente. Pe baza celor prezentate anterior se poate observa ca Arborescenta poate fi construita exclusiv cu elemente ale Structurii de Baza . Totodata însa o Structura de Baza nu poate defini decât structuri de tip Partitie, Ierarhii cu Ascendent Unic, adica Arborescente (vezi sectiunea 3.4.2). Trecând la definirea Arborescentei cu ajutorul unui Limbaj de Descriere care evita referirile între Blocurile de Date, se ajunge la reprezentarea din Fig. 4.2.4.8.3.2. Utilizând o descriere în Pseudo-Cod a Structurii de Baza de tip Arborescenta se evidentiaza, prin indentare, Gradul de Incuibarire a Grupurilor de Date. Din simpla analiza a acestei descrieri se poate remarca Gradul de Rigiditate pe care îl impune structurii, datorata urmatoarelor motive:

- Necesitatea reprezentarii unei Structuri Deschise de Informatii (în general, cu numar variabil de Nivele Ierarhice) printr-o Structura Inchisa de Date (numar fix de Nivele Ierarhice)

346 Modele de Date

BD – Baza de Date E – Entitate i – Identificator d - Descriptor

Observatii - Blocul exterior descrie Baza de Date - Entitatile E1 si E2 sunt în raport de Incluziune - Entitatea E2 joaca rol de Subentitate - Entitatile E1 si E3 sunt în raport de Echivalenta

Fig. 4.2.4.8.3.1 Reprezentarea structurii de tip Arborescenta

* i21

E 2

* i31

BD

E 1 E 3

d21

d31 d11

* i11

Modele de Date / Modelul Relational / Construirea Structurilor de Date 347

- Dificultati de Inserare a unor noi elemente în structura (Noduri sau Arce)

- Imposibilitate de Reorganizare a Ordinii Nivelelor Ierarhice fara refacerea integrala a Structurii de Date

INCEPUT BLOC ENTITATE nume1 INCEPUT BLOC caracteristica1 - identificator caracteristica2 - descriptor . . . ENTITATE nume2 INCEPUT BLOC caracteristica1 - identificator caracteristica2 - descriptor . . . SFIRSIT BLOC SFIRSIT BLOC ENTITATE nume3 INCEPUT BLOC caracteristica1 - identificator caracteristica2 - descriptor . . . SFIRSIT BLOC SFIRSIT BLOC

Fig. 4.2.4.8.3.2 Exemplul de Structura de Baza de tip Arborescenta

Daca Modelul Ierarhic, construieste Arborescentele ca Ierarhii de Segmente, Modelul de tip Retea extinde constructia la doua metode diferite: una Directa (prin Juxtapunere), cealalta Indirecta (prin Referire). Cele doua metode sunt prezentate mai jos::

- Metoda Directa –cu ajutorul Articolelor Principale de lungime Variabila (Blocuri de Date continute în alte Blocuri de Date)

- Metoda Indirecta – prin implementarea Relatiilor de Echivalenta pe Nivele Ierarhice prin Liste de Articole (Constructorul Set de Articole)

Spre deosebire, Modelul Relational va încerca construirea Structurilor de Baza utilizând doar Relatia (Structura Fundamentala de tip Nivel), ca unic constructor. In acest caz Legaturile Ierarhice vor fi reprezentate ca Legaturi Relationale obisnuite (Legaturi Cheie Straina – Cheie Primara), dupa cum se arata în Fig. 4.2.4.8.3.3. 4.2.4.8.3.1 Reprezentarea Entitatii

Intr-un Model Relational Entitatea va corespunde Relatiei, Identificatorul Entitatii fiind precizat de Cheia Primara a Relatiei, declarata prin LDD.

Exemplul 1:

PRODUS (Cod*, Denumire, Unitate-Masura, Pret) KEY Cod

348 Modele de Date

R – RELATIE

i - Identificator (Atribut) d - Descriptor (Atribut)

Identificatori Contextuali R 1 R 2 R 3 i11 i11 + i21 i11 + i21 + i31

Fig. 4.2.4.8.3.3 Construirea Structurilor Ierarhice prin Legaturi Relationale

* i21

* i11

* i11

* i11

R 3

d11 d12

R 2

d21 d22 d31 d32 * i21

* i31

R 1

Modele de Date 349

Reprezentarea grafica, utilizând Arborele de Structura este data în Fig. 4.2.4.8.3.1.1. Nota Bene !

Declararea de Chei Primare nu este acceptata în toate produsele care implementeaza SGBD-uri, caz în care Restrictiile de Identitate vor trebui rezolvate procedural. P - PRODUS

c – Cod d – Denumire u – Unitate de Masura

p – Pret

Fig. 4.2.4.8.3.1.1 Reprezentarea relationala a Entitatii PRODUS

4.2.4.8.3.2 Reprezentarea Subentitatii

Reprezentarea Subentitatii se face tot printr-o Relatie, legatura Entitate-Subentitate descriindu-se apoi separat prin Referire Relationala, într-unul din modurile prezentate mai jos:

o Prin repetarea Identificatorului Entitatii în Relatia ce descrie Subentitatea; Identificatorul Subentitatii va fi constituit din unul sau doua Atribute dupa cum urmeaza:

§ Identificare Contextuala - Cheia Primara a Subentitatii contine doua Atribute (Fig. 4.2.4.8.3.2.2)

• Identificatorul Entitatii

• Identificatorul Subentitatii în Entitate

§ Identificare Necontextuala - Cheia Primara a Subentitatii contine un Atribut (Fig. 4.2.4.8.3.2.3)

• Identificatorul Subentitatii în Entitate

Identificatorul Entitatii ramâne Cheie Straina, dar nu si Constituent de Cheie Primara în Subentitate; Structura se impune pentru cazul în care Subentitatea trebuie sa fie identificata si în afara Contextului Entitatii

o Prin construirea unei Relatii de Legatura între Relatia Entitate si Relatia Subentitate, având ca si Chei Straine chiar Cheile Primare ale Relatiilor Entitate si Subentitate; aceste doua Chei Straine vor reprezenta si Constituentii Cheii Primare pentru Relatia de Legatura (Fig. 4.2.4.8.3.2.5)

Exemplul 1:

Ca prim exemplu de Ierarhie se prezinta Structura Organizatorica a unei Universitati. Este redata în Fig. 4.2.4.8.3.2.1 Viziunea Ierarhica a acestei structuri, cu reprezentarea a trei Nivele de Subordonare Ierarhica (Universitate, Facultate, An de Studiu)

* c

P

d u p

350 Modele de Date

In Fig. 4.2.4.8.3.2.2 si Fig. 4.2.4.8.3.2.3 se regaseste viziunea Relationala a aceleiasi Structuri de Informatii. Structura Relationala este prezentata în doua versiuni, în functie de modul de Identificare (Contextuala sau Necontextuala) încorporat în structura. Remarca ce se cere facuta este faptul ca deoarece aceste Structuri de Baza au fost implementate cu ajutorul Referintelor Relationale, fata de Modelul de Date Retea (chiar în varianta de implementare prin Lista de Articole), Gradul de Independenta al elementelor din structura este sporit, prin adaugarea Independentei de Suport, asigurata de utilizarea Referirilor Asociative.

Fig. 4.2.4.8.3.2.1 Structura organizatorica a unei UNIVERSITATI (Viziune Ierarhica) Structura Organizatorica a unei Unitati face parte din acele structuri din Spatiul Informatiilor despre care Utilizatorul Final îsi creeaza si îsi pastreaza o Viziune Ierarhica, Viziunea Relationala aparându-i nefamiliara. Este sarcina Nivelelor de Interfata cu Baza de Date sa adapteze Reprezentarea Relationala la Viziune Ierarhica a Utilizatorului. In general la structurile de genul celei prezentate se poate usor ajunge la constatarea ca Descriptorii Entitatii ramân aceiasi indiferent de Nivelul Ierarhic pe care Entitatea apare. Aceasta observatie conduce la ideea unificarii descrierii Entitati (vezi si sectiunea 3.4.3.3). Ia nastere Structura de Date Recursiva din Fig. 4.2.4.8.3.2.4, cu dezvoltarile ulterioare. Pentru a putea face deosebirea între semnificatia diferitelor Entitati descrise de relatia UNITATE (U), s-a atasat la structura relatia TIP (T). Atributul Nume din aceasta ultima relatie va avea valorile: Universitate, Facultate, An. Referintele Relationale din celelalte variante de structuri sunt înlocuite aici cu o singura legatura de tip 1 – n (Ascendent Unic):

Cod Ascendent → Cod Curent (c)

i

*

i

*

i

* F

A

U

d

d

d

Modele de Date / Modelul Relational / Construirea Structurilor de Date 351

U - UNIVERSITATE F - FACULTATE A – AN

U . c1 = F. c1 = A. c2 - Cod Universitate si Identificator Universitate F. c2 = A. c2 - Cod Facultate în cadrul Universitatii F . c1 + F . c2 - Identificator Facultate A . c3 - Cod An în cadrul Facultatii A . c1 + A . c2 + A . c3 - Identificator An

Fig. 4.2.4.8.3.2.2 Structura Relationala cu Identificare Contextuala

c2

* c1

* c2

* c1

* c1

*

U

d

A

d

F

d c3

*

Modele de Date / Modelul Relational / Construirea Structurilor de Date 352

U - UNIVERSITATE F - FACULTATE A – AN

U . c1 - Cod Universitate si Identificator Universitate F . c2 - Cod Facultate si Identificator Facultate A . c3 - Cod An si Identificator An

Fig. 4.2.4.8.3.2.3 Structura Relationala cu Identificare Necontextuala

c3

* c2

*

c1

*

U

d

A

d

F

c1 d

c2

Modele de Date / Modelul Relational / Construirea Structurilor de Date 353

Structura Recursiva care este aleasa prezinta caracteristici speciale, care apar fie ca avantaje, fie ca dezavantaje. Dintre acestea enumeram:

§ Face economie în Descrierea Logica a Structurii de Date

§ Introduce posibilitatea Clasificarii Unitatilor cu ajutorul Tipurilor asociate

§ Asigura o Clasificare Deschisa prin adaugarea simpla de noi tuple în TIP

§ Permite descrierea unui numar variabil si necunoscut de Nivele Ierarhice

§ Ofera posibilitatea inserarii de noi Noduri si Legaturi în Structura Ierarhica

§ Necesita proceduri speciale de prelucrare cu facilitati recursive

T – TIP UNITATE i - Identificator t – Tip U – UNITATE d - Descriptor a - Ascendent

Fig. 4.2.4.8.3.2.4 Structura unei Universitati (Varianta 1)

Daca relaxam conditia de Unicitate a Ascendentului se poate trece la Structura de tip Arbore Invers (vezi sectiunea 3.1.4), structura care implementeaza o Padure de Arbori ce pot partaja aceleasi Unitati de Structura .

T – TIP UNITATE c - Cod t – Tip

U – UNITATE d - Descriptor L – STRUCTURA a - Ascendent

Fig. 4.2.4.8.3.2.5 Structura unei Universitati (Varianta 2)

a

* c

*

c

* c

*

T

d

U

t d

S

* c

c

*

T

d

a

U

t d

354 Modele de Date / Modelul Relational / Construirea Structurilor de Date

Relaxarea amintita e ceruta de necesitatea de Reprezentare Unificata a mai multor Tipuri de Structuri (Organizatorica, Didactica, Functionala), în asa fel încât o Unitate de Structura (ex. un Departament) sa participe în mai mult decât un Tip de Structura (o Arborescenta). Solutia de implementare a structurii de tip Arbore Invers se gaseste în reprezentarea din Fig. 4.2.4.8.3.2.5. Se observa ca s-a iesit din sfera Structurilor de tip Partitie (1 – n), trecându-se la Structuri de tip Acoperire (m – n). Aceasta transformare, atrasa de o simpla modificare de Restrictie, justifica introducerea în Baze de Date a conceptului de Arbore Invers (denumire de altfel improprie), ca o extensie a structurii initiale de Arbore Simplu.

Daca dorim sa reprezentam structural si Generalizarea Arborilor din Fig. 4.2.4.8.3.2.5, prin încorporarea Informatiei legate de Tipurile de Structuri, construim imaginea unei Paduri de Arbori (în particular ea este totodata o Padure de Arbori Clasificati), definiti în sectiunea 3.1.4 si concretizati în Fig. 4.2.4.8.3.2.6. Padurea de Arbori, structura predilecta a Bazelor de Date, apare între cele mai complexe structuri prezente în SBD. De data aceasta, Clasificarea operata de Generalizarea Structurilor prin Tipuri ofera, în afara Generalizarii obisnuite, si posibilitatea declararii Regulilor de Validare Diferentiate:

o Structura de tip Partitie pe fiecare Tip de Structura (pe Entitate Categorie) – Restrictie implementata prin simpla includere în Cheia Primara a Atributului S.ts

o Structura de tip Acoperire pe ansamblul tuturor Tipurilor de Structura (pe Entitate Generica) – Relaxare implementata de neunicitatea Constituentilor de Cheie S.c + S.a, carora li se poate atasa doar o Cheie de Inversare (vezi sectiunea 3.4.2.2.1.2)

In aceasta observatie, legata de raportul Structura – Restrictii, consta si diferenta între exemplele utilizate în Fig. 4.2.4.8.3.2.6 si Fig. 3.4.3.3.4. Observatia este apoi concretrizata printr-o solutie structurala concentrata.

TU – TIP UNITATE c - Cod tu – Tip Unitate U – UNITATE d - Descriptor ts – Tip Structura

L – LEGATURA a - Ascendent TS – TIP STRUCTURA

Fig. 4.2.4.8.3.2.6 Structura unei Universitati (Varianta 3)

ts

* a

* c

* c

*

c

* c

*

TU

d

d

U

tu d

TS S

Modele de Date / Modelul Relational / Construirea Structurilor de Date 355

Exemplu 2: Al doilea exemplu oferit difera de cele precedente prin evidentierea Viziunii Multiple, pe care utilizatorul o poate avea asupra Structurii de Informatii. Daca în exemplul precedent, datorita stabilitatii relative a Structurii Organizatorice, utilizatorul îsi pastreaza pe toata durata existentei structurii, o Viziune Ierarhica, în exemplul de fata viziunea utilizatorului se modifica în timp.

P – PRODUS c - cod S – SUBANSAMBLU d - descriptor M - MATERIAL q - consum

Fig. 4.2.4.8.3.2.7 Structura P x S x M (Viziune Ierarhica)

In Fig. 4.2.4.8.3.2.7 este reprezentata viziunea Ierarhica a Consumurilor de Semifabricate si Materiale în Produse. Pentru Produse deja executate, pentru care Listele de Consumuri Tehnologice sunt deja stabilite, Structura Ierarhica apare utilizatorului fireasca.

Atunci când Colectiile de Date sunt folosite pentru a întocmi o noua Lista de Consumuri, într-o noua tehnologie de fabricatie, viziunea Ierarhica nu mai corespunde. Acum Utilizatorul doreste sa lucreze cu un Set de Cataloage de Produse, Semifabricate si Materiale, din care sa poata selecta corespondentele de consumuri impuse de o anumita tehnologie de fabricatie. In acest caz viziunea lui se apropie de cea Relationala (vezi Fig. 4.2.4.8.3.2.8).

Am facut aceasta remarca pentru a evidentia înca o data gradul mare de acoperire a diferitelor viziuni ale utilizatorului, de catre o Structura Relationala de Date. Pe primul nivel al reprezentarii si al structurii de date se regasesc Cataloagele cu Produse, din care, prin combinarea de informatii rezulta Listele de Consumuri de pe nivelul doi (Consumuri de Semifabricate si de Materiale). Dezvoltarea structurii în sensul unificarii Cataloagelor într-unul singur, este si aici posibila, cu eforturi mai mari însa în transformarea Atributelor în Caracteristici Comune. Se obtine si aici o Generalizare a Entitatii PRODUS, prin Categoriile Ansamblu, Subansamblu, Material, cu posibilitatea cuprinderii si a Consumurilor de PRODUS în PRODUS (Fig. 4.2.4.8.3.2.9).

c

*

c

*

c

* S

M

P

d

d

d

q

q

Modele de Date 356

P – PRODUS S – SUBANSAMBLU M - MATERIAL SP - consum SUBANSAMBLU / PRODUS MP - consum MATERIAL / PRODUS

c - cod d - descriptor

q – consum

Fig. 4.2.4.8.3.2.8 Structura P x S x M (Viziune Relationala – Varianta 1)

c2

* c3

* c2

*

c1

* c1

*

c

* c

* c

*

P

d

S

d

SP

q

MP

q

M

d

Modele de Date / Modelul Relational / Construirea Structurilor de Date 357

P – PRODUS T – TIP PRODUS (Ansamblu, Subansamblu, Material) C - CONSUM c - cod d - descriptor t - tip q - consum

Fig. 4.2.4.8.3.2.9 Structura P x S x M (Viziune Relationala – Varianta 2) 4.2.4.8.4 Reprezentarea Structurilor Matriciale Structurile Matriciale prezinta caracteristici aparte, cu toata înrudirea cu Structurile Ierarhice. Particularitatile lor sunt redate astfel:

- Adâncimi mici de Ierarhizare (doua sau trei Nivele)

- Implementeaza Structuri de tip m-n, ce pot fi reduse la Structuri 1-n în Reprezentari Partiale

La prima vedere transpunerea unei Matrici Bidemensionale într-o Relatie pare o corespondenta banala întrucât ambele reprezentari corespund unui Tabel, cu Linii si Coloane. Diferentele constau în urmatoarele functii diferite:

- Tabelul – Matrice Bidimensionala confera Liniilor si Coloanelor acelasi Rol, de convertire a unor Dimensiuni (exprimabile si Calitativ) în Indecsi (exprimati ca Intregi) de Rapidizare a Accesului la Elemente

- Tabelul – Relatie acorda Liniilor si Coloanelor Roluri diferite:

§ Coloanele – descriu Atribute

§ Liniile – descriu Tuple:

• Prima Linie – Tupla Logica (prin Nume)

• Restul Liniilor – Tuple Fizice (prin Valori)

Este evident ca datorita reprezentarii sale compacte, destinate Memoriei Interne, Tipul de Data Matrice îsi va pastra functia. Exista însa si cazuri, în special cele legate de creare a Arhivelor de Date cu Structura Matriciala, care vor putea beneficia de existenta unei Baze de Date în acest scop. Reprezentarea câstiga în interes acolo unde este vorba de Multimi (Seturi) de Matrici, având o Structura Rara (multe Elemente Absente, Nedefinite sau Nule).

c2

* c1

*

c

* c

*

P

d

C

q

T

d

t

358 Modele de Date / Modelul Relational / Construirea Structurilor de Date

Principalul câstig al acestei exemplificari consta în sublinierea cerintelor elementare ale oricarei Structuri Relationale de Date de a reprezenta Clase de Entitati si Relatii între acestea.

Exemplu: Sa se construiasca o Structura Relationala pentru descrierea unei Multimi de Matrici Bidimensionale Rare cu evidentierea urmatoarelor Clase de Entitati: MATRICE, COLOANA, LINIE, ELEMENT.

Fig. 4.2.4.8.4.1 Matrice Bidimensionala – Diagrama simbolica Diagrama Simbolica din Fig. 4.2.4.8.4.1 reda sugestiv Clasele de Entitati precum si Relatiile care intervin între ele, permitând transcrierea Structurii într-o Schema de Relatii:

SET (Numar*, Denumire)

MATRICE (Numar*, Denumire, Set)

COLOANA (Numar*, Denumire, Matrice)

LINIE (Numar*, Denumire, Matrice)

ELEMENT (Linie*, Coloana*, Valoare)

Arborele de Structura din Fig. 4.2.4.8.4.2 completeaza întelegerea Structurii de Date. Se vede cum Identificatorii Claselor de Entitati, ce exceptia ELEMENTULUI sunt considerati toti Discriminanti, sub forma Cheilor Primare declarate de Utilizator ca si Numere (de Seturi, Matrici, Linii sau Coloane) sau Chei Surogate (Identificatori Interni). ELEMENTUL are o Cheie Primara Compusa , formata din Numarul de Linie si Numarul de Coloana. Se remarca impreciziaa expresiei: ”LINIILE unei COLOANE” corect fiind ”ELEMENTELE unei COLOANE” si reciproc pentru o LINIE.

SET

MATRICE

COLOANA LINIE

ELEMENT

Modele de Date / Modelul Relational / Construirea Structurilor de Date 359

Fig. 4.2.4.8.4.1 Matrice Bidimensionala – Arbore de Structura 4.2.4.8.5 Reprezentarea Datelor de Tip Multime

Consacram o analiza succinta si reprezentarii Datelor de Tip Multime, tocmai pentru ca aceste date, dupa unele pareri, pot fi trecute cu vederea în Structurile SBD. Proiectantii crescuti la scoala Programarii Clasice, le privesc ca simple Date Elementare, având un Tip Consacrat, cu Operatori Asociati, ce asigura oricând tratarea lor procedurala adecvata. Tocmai aceasta viziune Proceduralista asupra unor Date purtatoare de Structura dorim sa o combatem dintr-un punct de vedere Structuralist.

O Data de Tip Multime are forma:

Nume Data ÷ v1, v2, .. vn

Reprezentarea Datelor de Tip Multime ca Date Elementare aduce prejudicii viziunii Structuraliste prin aceea ca performanta obtinuta prin prelucrarea lor în memoria interna nu compenseaza pierderea determinata de diminuarea Controlului asupra Structurii de Ansamblu a Datelor. Argumentele principale pentru aceste afirmatii sunt enumerate în continuare:

§ Risipirea în Proceduri, Module si Aplicatii a Modurilor de Interpretare a acestui Tip de Data (a Semanticii Datei)

§ Prelucrarea lor Functionala nu elimina Dependenta Datelor de Proceduri

• Conditii de Selectie dificile

• Imposibilitatea aplicarii metodelor de Ordonare a Multimilor (cu ajutorul Indecsilor)

• Reducerea uniformitatii de Tratare Relationala a Datelor, indiferent de Tip

*

l

*

n

* n

* M

E

S d

d

* *

L

n n

v

C

s

c

d

m

m

360 Modele de Date / Modelul Relational / Construirea Structurilor de Date

§ Reducerea Caracterul Dinamic al extensiei Tipului de Data

• Cu noi Atribute Desciptoare

• Cu noi Valori de Instanta

§ Submineaza tratarea unitara a Procesului de Clasificare prin Generalizare

§ Poate ascunde în interiorul Datei Elementare Caracteristici de Structura care vor fi tratate altfel decât Relational (memorarea Listelor ca Siruri de Caractere)

§ Distrugerea caracterului Elementar al reprezentarii Relationale prin încalcarea conditiei de minima Normalizare a Structurii, cu toate dificultatile de actualizare aferente

Solutia propusa pentru Implementarea Relationala a Datelor de tip Multime este urmatoarea:

o Informatia trebuie privita ca si Clasa de Entitate si nu ca Atribut de Entitate (Data Elementara)

Entitatea atasata va descrie un Criteriu de Clasificare atasat unui Proces de Generalizare (descrie Colectii de tip: Dictionar, Nomenclator, Catalog etc.)

o Structura Entitatii este urmatoarea:

§ Identificator de Categorie, recomandabil a fi gestionat de sistem în calitate de Cheie Surogata

§ Nume de Categorie ce va avea ca Instante Elementele (Valorile) din Lista de Valori, cu conditia ca Atributul sa fie o Cheie Candidata si sa admita Valoarea Speciala – „Neprecizat”

§ Alti Descriptori, ce folosesc alaturi de Atributul Nume pentru interpretarea Valorilor din Lista

§ Atribute de Centralizare a Categoriilor, utile pentru memorarea Valorilor Statistice pe Multimile de Instante ale unei Categorii

§ Conditii de încadrare în Categorii Vagi, reprezentate de Atribute ce memoreaza Expresii Logice pentru încadrarea Instantelor unor Categorii anterior definite în Categorii noi, de tip Vag, prin Conversie de Valori

Exemplul 1:

Sa consideram o Multime de Studenti care trebuie Clasificata dupa Rezultate. Relatiile propuse pentru descrierea Structurii Relationale sunt:

STUDENT (Marca*, Nume, Prenume, Sex, Data-Nasterii, Medie, Categorie)

CATEGORIE (Cod*, Nume, Conditie -de--Medie)

Structura din Fig. 4.2.4.8.5.1 necesita unele detalii pentru a putea fi înteleasa:

o Entitatea CATEGORIE descrie Grupurile de Studenti în care se doreste împartita multimea de Studenti dupa Medie

Modele de Date / Modelul Relational / Construirea Structurilor de Date 361

o Numele Categoriilor corespund Valorilor Atributului Nume din Entitatea Categorie si va avea Valorile:

‘foarte bun’,’ bun’, ‘mediocru, ‘slab’, ‘foarte slab’

o Categoriile definite ca mai sus corespund unor Multimi Vagi de Studenti definite de Conditiile:

• ‘foarte bun’ ⇔ Medie ≥ 9

• ‘bun’ ⇔ 9 > Medie ≥ 8

• ‘mediocru’ ⇔ 8 > Medie ≥ 6

• ‘slab’ ⇔ 6 > Medie > 4

• ‘foarte slab’ ⇔ 4 > Medie ≥ 0

Aceste Conditii sunt memorate în Atributul Conditie-de-Medie

o Atributul Categorie din Student e o Data Calculata si ca atare Functional Dependenta de Media Studentului si de Conditia-de-Medie din Categorie:

S.ct = f (S.md, C.cm)

o Functia de Dependenta pote fi implementeaza ca o Procedura Stocata Declansata pe Evenimentul de Actualizare Medie

o Indata dupa acualizarea atributului Categorie din Student, Instanta respectiva de Student va putea sa fie repartizata prin Legatura Relationala S.ct → C.c, la o Instanta de Categorie, memorata în Entitatea CATEGORIE

S - STUDENT c - Cod dn – Data Nasterii C - CATEGORIE n – Nume md - Medie p – Prenume ct - Categorie s – Sex cm – Conditie–de-Medie

Fig. 4.2.4.8.5.1 Reprezentarea Listelor de Valori

In exemplul de fata au fost abordate mai multe aspecte legate de Categoriile definite ca Liste de Valori (Atribute Suplimentare Descriptoare, Date Statistice Atasate, Multimi Vagi de Entitati Categorie). Ceea ce trebuie însa retinut este faptul ca orice implementare de Liste de Valori în afara unei Entitati de tip Criteriu, ale carui Categorii sa fie Valorile din Lista de Valori, nu respecta Conditiile Minimale ale Modelului Relational de Date.

m

* c

* C

n cm

S

n p md s dn

ct

362 Modele de Date / Modelul Relational / Conditiile ca o BD sa fie Relationala

4.2.4.9 Conditiile ca o BD sa fie Relationala

În încheierea prezentarii Modelului Relational tinem sa mentionam, ca o imagine a disputelor de afirmare si consacrare a acestui model, Regulile de Încadrare a unei Baze de Date Intr-o Baza de Date Relationala. Aceste Reguli, în numar de 13, au fost enuntate de cercetatorul Codd în anul 1985, sub imperiul necesitatii de a mentine SBD în domeniul definit de el ca Relational (1970) si care era amenintat a fi depersonalizat de o invazie de produse, care, toate, aveau pretentia de a promova ”Concepte Relationale”. Subiectul de discutie a nascut multe controverse, multi producatori de SGBD considerând Regulile lui Codd ca un simplu ”Exercitiu Academic”, care nu pot fi interpretate ca Restrictii pentru Produsele Comerciale. Sinteza facuta de Codd îsi are ca punct de pornire analizele detaliate la care a fost supus un numar impresionant de produse comerciale din acea perioada. O asemenea descriere analitica se gaseste în [SCHM83].

Prezentarea celor 13 Reguli de Evaluare a unei BDR se prezinta grupata pe sectiuni, organizate dupa obiectivul urmarit [PARS89].

- Reguli de Fundamentare

- Reguli Structurale

- Reguli de Integritate

- Reguli de Manipulare a Datelor

- Reguli de Independenta a Datelor 4.2.4.9.1 Reguli de Fundamentare – Regula 0 si 12

Acest Grup de Reguli reprezinta un Test Elementar pentru Încadrarea uni BD în BDR. (Mai e denumit si Testul Hârtiei de Turnesol).

o Regula 0

§ Un SBDR trebuie sa fie capabil de a folosi integral toate Facilitatile Relationale pentru Gestiunea BD.

Aceasta Regula solicita ca BDR sa nu utilizeze nici-o metoda nerelationala pentru Gestiunea Datelor, incluzând: Definirea Datelor, Manipularea Datelor, Prelucrarea Cererilor, precum si extensiile de Asigurare a Integritatii, a Securitatii si a Conditiilor de Performanta. Aceasta pretinde mentinerea în orice conditii a unei Interfete Relationale, întelegând prin aceasta asigurarea permanenta si a unei Prelucrari pe Multimi de Înregistrari (Prelucrare prin Spcificare) si nu numai Înregistrare cu Înregistrare (Prelucrare prin Navigare).

o Regula 12

§ Daca un SGBDR dispune de o forma de Manipulare a Datelor Înregistrare cu Înregistrare, aceasta nu poate încalca Restrictiile de Integritate declarate la Nivelul Limbajului Relational.

Modele de Date / Modelul Relational / Conditiile ca o BD sa fie Relationala 363

Acele SGBD-uri care nu asigura aceasta conditie în permanenta sunt considerate ca Insuficient Relationale de catre Codd.

4.2.4.9.2 Reguli Structurale – Regula 1 si 6

Acest Grup de Reguli se preocupa de Conceptul Structural Fundamental al Modelului Relational – Tabela (Constructorul de Structura). Tabelele, asa cum au fost definite în sectiunea 4.2.4.1, sunt grupate în urmatoarele categorii:

§ Tabele de Baza – reprezinta singura forma persistenta de memorare a datelor în BDR, atât sub forma de definire Intensionala (prin Nume), cât si Extensionala (prin Valori)

§ Tabele Rezultat – reprezinta forme momentane de oferire a Rezultatelor de prelucrare a Cererilor, care pot fi salvate doar temporar în BDR (vezi Instantaneul)

§ Tabele de tip Vedere – reprezinta forme partiale de descriere (doar Intensional) a structurilor de date, în vederea definirii Datelor Dependente (Datele Virtuale) în functie de cele Independente (Datele Reale). În forma Intensionala, Vederile sunt memorate si ele persistent în BDR.

§ Tabele de tip Instantaneu – reprezinta forme Temporare de memorare a Rezultatului de executie (Materializare) a Vederilor în scopul utilizarii lor ulterioare neactualizate. Din datele lor de creare, Instantaneele pot fi apreciate ca Perisate sau înca Actuale, în functie de actualizarile operate între timp în BDR.

Acelasi Grup de Reguli se preocupa de Conceptul Structural de Domeniu privit ca principala Sursa de Valori a Atributelor. Este relevat rolul semantic al Domeniului în Prelucrarea Cererilor prin proprietatea de Interpretare si Comparabilitate a Domeniilor.

Conceptul de Referire Asociativa este de asemenea continut în corpul acestui Grup de Reguli prin sublinierea necesitatii mentinerii Independentei între Definirea Cheilor Primare si Procedurile de Acces asociate prin Indecsi (vezi si sectiunile 4.2.4.4.2). Asocierea Cheie Primara – Cheie Straina defineste forma concreta de implementare a Referirii Asociate în BDR.

o Regula 1

§ Toate Informatiile într-o BDR sunt reprezentate explicit, la Nivel Logic prin Nume de Atribute si la Nivel Fizic prin Valori în Tabelele de Baza.

Aceasta regula, denumita si Regula Informatiilor, enunta faptul ca singura forma de descriere a Informatiilor într-o BDR este Tabela, indiferent ca e vorba de Datele Utilizatorului sau de Datele de Sistem (Definirea Tabelelor, a Coloanelor a Domeniilor, a Restrictiilor de Integritate, a Drepturilor de Acces, a Conditiilor de Salvare / Restaurare etc.). Cu Datele de Sistem se alcatuieste o Colectie Speciala de Informatii denumita Catalogul Sistemului (Dictionarul Sistemului).

364 Modele de Date / Modelul Relational / Conditiile ca o BD sa fie Relationala

o Regula 6

§ Toate Vederile Actualizabile vor fi Actualizabile si de catre SGBD.

Aceasta regula pretinde ca SGBD-ul sa poata determina proprietatea de Vedere Actualizabila si apoi sa efectueze actualizarea cu evitarea oricarei Inconsistente în actualizarea Tabelelor de Baza pe care e definita Vederea.

Pâna în prezent nu exista un SGBD (si nici un Standard SQL), care sa trateze complet aceasta problema.

4.2.4.9.3 Reguli de Integritate – Regula 10 si 3

Regulile din aceasta sectiune subliniaza importanta Conceptului de Integritate al Modelului Relational, prin accentul pe care îl pune pe Calitatea Datelor, conferita tocmai de Integritatea lor. Indicatorul de Performanta dat de Integritatea Datelor este tratat prioritar fata de alte însusiri, preferate de multi utilizatori si producatori, cum ar fi: Facilitatile Modulelor de Editare de Rapoarte, Interfetele Prietenoase de Utilizator sau Modulele Performante pentru Utilitati (Editare Texte, Gestiune Fisiere, Controlul Securitatii, Salvari / Restaurari etc.). Trei categorii de Integritate sunt mentionate:

§ Integritatea Entitatii – pretinde ca fiecare Colectie de Date sa fie privita ca o Multime (vezi sectiunea 3.1.1) si prin aceasta sa aiba definit cel putin un Identificator, sub forma unei Chei Primare.

§ Integritatea de Referire – asigura posibilitatea de rezolvare a oricarei Referiri Asociative prin perechea Cheie Straina → Cheie Primara (vezi sectiunea 4.2.4.4.1)

§ Integritatea de Utilizator – defineste Constrângeri definite de Utilizator pentru implementarea Regulilor Proprii extrase din Spatiul Informatiilor (asa numita Business Logic). Constrângerile pot fi definite ca Reguli de Corectitudine sau de Compatibilitate, la nivel de Coloana, Rând, Tabela sau Baza de Date.

o Regula 10

§ Restrictiile de Integritate trebuiesc definite prin Limbajul de Definire a Datelor (LDD) si memorate în Catalogul BDR si nu în Sistemul de Aplicatii

Aceasta regula, ofera metoda de a obtine un Control Centralizat al Integritatii BDR. Aparitia Restrictiilor în Sistemul de Aplicatie poate cauza Redondanta si prin aceasta Inconsistenta în gestionarea modificarilor frecvente care apar în aceasta zona. Memorarea Independenta a Restrictiilor de Integritate în Catalogul Sistemului este o a doua conditie care asigura dinamismul la modificari, prin aceea ca ele nu vor solicita Redefinirea Integrala a Bazei de Date.

o Regula 3

§ BDR vor admite reprezentarea Informatiei Absente prin Coduri Speciale , adecvate Tipurilor de Date. Valoarea Absenta e diferita de 0 sau Sirul Vid de Caractere.

Modele de Date / Modelul Relational / Conditiile ca o BD sa fie Relationala 365

Aceasta regula aduce o multime de beneficii prin posibilitatea de tratare a urmatoarelor cazuri:

• Evitarea Componentelor Nule de Cheie Primara

• Rezolvarea Referirilor Absente (Valoare Nula de Cheie Straina)

• Introducerea Logicii cu Trei Valori pentru cazuri de Calcule Statistice ce presupun prezenta Valorilor Nedeclarate (vezi Functia de Sistem ISNUL ( ) din SQL).

4.2.4.9.4 Reguli de Manipulare a Datelor – Regula 5, 2, 7 si 4

Codd distinge 18 Moduri de Manipulare a Datelor într-un SGBDR. Aceasta viziune extinde Cererile la Comenzi de Regasire si Comenzi de Actualizare. Ele reunesc Operatori Relationali si Comenzi pe Multimi de Înregistrari. Regulile ce urmeaza reprezinta un Ghid de Aplicare al celor 18 Moduri de Manipulare.

o Regula 5

§ Un SBDR trebuie sa dispuna de cel putin un Limbaj de Manipulare a Datelor (LMD) construit pe baza unui Limbaj Formal de Nivel înalt (Limbaj de Specificare) definit ca un set de Formule Bine Construite si redactat textual.

Nivelul Înalt va asigura posibilitatea utilizarii Comenzilor pe Multimi de Înregistrari (nu numai Înregistrare cu Înregistrare), iar redactarea textuala va permite transcrierea Comenzilor în Fisiere Sursa Portabile (Scripturi). LMD va contine ca sectiuni principale:

• Definirea Datelor

• Definirea Vederilor

• Manipularea Datelor (Interactiva si Programata)

• Definirea Restrictiilor

• Autorizarea Accesului

• Prelucrari Tranzactionale

o Regula 2

§ Fiecare Data Elementara dintr-o BDR, reprezentând o Valoare Elementara Ve , va avea asociata o Functie de Acces de forma:

Fa (T, C, VCP)

unde:

Fa – Functia de Acces

T – Tabela (Relatia)

C – Coloana (Atributul)

366 Modele de Date / Modelul Relational / Conditiile ca o BD sa fie Relationala

VCP – Valoarea Cheii Primare (Identificatorului)

Regula poarta si numele de Regula de Completitudine si afirma ca nu poate exista nici-o portiune a BDR care sa nu fie accesibila prin intermediul LMD.

o Regula 7

§ Tratarea în LMD a întregului continut al unei Tabele ca un singur Operand trebuie sa fie posibil atât pentru Operatii de Regasire cât si pentru Operatii de Actualizare..

Operatiile de Actualizare trebuiesc garantate ca si Comenzilor la Nivel de Seturi de Înregistrari (nu numai Înregistrare cu Înregistrare).

o Regula 4

§ Descrierea BDR la Nivel Logic va dispune de acelasi LMD ca si BDR la Nivel Fizic.

Potrivit acestei Reguli, Datele si Metadatele din BDR vor fi tratate unitar din punctul de vedere al LMD.

4.2.4.9.5 Reguli de Independenta a Datelor – Regula 8, 9 si 11

Un numar de 3 Reguli e rezervat pentru enuntarea Nivelelor impuse pentru asigurarea Independentei între Date si Proceduri (vezi si sectiunea 2.1.1).

o Regula 8

§ Procedurile de Aplicatii îsi mentin Imunitatea Logica la modificari operate în Structura Fizica de organizare a Memoriei Interne sau în Structura Procedurilor de Acces.

Regula poate fi interpretata ca si Imunitatea Nivelului Logic al Datelor la modificari în Nivelul Fizic, întrucât aceasta imunitate o garanteaza pe cea enuntata direct.

o Regula 9

§ Procedurile de Aplicatii îsi mentin Imunitatea la modificari operate în Structura Logica de definire a BDR daca Nivelul Extern descris de Ansamblul Vederilor definite acopera aceste modificari( vezi si sectiunile 2.1.1 si 4.2.4.6.3).

Regula invoca facilitatea asigurata de Vederi de a ascunde de Utilizatori modificarile operate în structura Tabelelor de Baza . Asupra limitelor admisibile pentru asemenea modificari vezi sectiunea mai sus amintita, referitoare la Vederi Actualizabile.

o Regula 11

§ O BDR are Independenta la Distribuirea pe platformele HARDWARE si SOFTWARE.

Utilizatorul trebuie sa lucreze în Regim Distribuit cu impresia ca Resursele se mentin Centralizate (vezi sectiunea 7.2).

Modele de Date / Modelul Relational / Conditiile ca o BD sa fie Relationala 367

PPAARRTTEEAA aa 55--aa

OOPPTTIIMMIIZZAARREEAA MMOODDEELLEELLOORR ddee DDAATTEE

Încercând sa dam o constructie unitara Monografiei de Concepte am reunit problemele legate de Analiza Dependentelor Functionale în BD si cele referitoare la Îmbunatatirea Performantelor de Acces la Date într-un grup de sectiuni intitulat expresiv Optimizarea Structurilor, cu trimitere directa la cele doua forme de structuri evidentiate în lucrare si întâlnite în fiecare Model de Date:

Structuri de Date Structuri de Proceduri

Desi agreem termenul mai practic de Ameliorare de Structuri, l-am mentinut în titlu pe cel de Optimizare, având în vedere, pe de o parte eforturile deosebite întreprinse de cercetare în aceste directii si pe de alta parte rezultatele deosebite obtinute pe linia definirii limitelor la care procesele de ameliorare mai prezinta interes. Structura Partii a 5-a urmeaza consideratiile de mai sus:

5.1 – Optimizarea Structurilor de Date – dezvoltarea

acestui subiect este facuta minutios, pornind de la prezentarea Formala, Istorica si Informala a problematicii Dependentelor în Structuri. O comparatie amanuntita a metodelor Formale si Informale mentine în atentie una din problemele a carei neglijare sau abordare gresita atrage întotdeauna urmari tardive deosebit de costisitoare. Solutii originale sunt oferite în sectiunile care se ocupa de Abordarea Semantica a Ameliorarii Structurilor de Date.

5.2 – Optimizarea Cererilor – o tratare clasica este folosita în tratarea performantelor de acces la date, desi în acest punct s-ar fi cuvenit poate o insistenta prelungita asupra Rolului Nivelului Extern al unei BD

368 Modele de Date / Modelul Relational / Optimizarea Modelelor de Date

în asigurarea indicatorilor de calitate asteptati în privinta vitezei de acces la date.

Optimizarea Structurilor de Date 369

5 Optimizarea Modelelor de Date

Problema Optimizarii trebuie privita în legatura directa cu cele doua resurse principale care intervin în procesul de prelucrare a informatiilor: Datele si Procedurile. Asa cum se va vedea în continuare obiectivele care determina criteriile de evaluare a Structurii Datelor sau a Procedurilor nu se suprapun în totalitate. Aceste criterii sunt prezentate mai jos:

o Criterii de evaluare a Structurii Datelor

§ Gradul de asigurare a Fidelitatii Semantice a Datelor – criteriu calitativ ce urmareste adaptarea Structurii de Date la Structura de Informatii

§ Gradul de asigurare a Consistentei Datelor – criteriu calitativ ce urmareste cresterea Independentei Datelor

§ Viteza de Acces la Date – criteriu cantitativ ce urmareste reducerea timpului de regasire a datelor

o Criterii de evaluare a Structurii Procedurilor

§ Viteza de Prelucrare a Cererilor – criteriu cantitativ ce urmareste reducerea timpului de compilare si executie a Cererilor adresate Structurilor de Date

Daca Viteza de Acces la Date si Viteza de Prelucrare a Cererilor sunt criterii convergente, Gradul de asigurare a Fidelitatii Semantice si a Consistentei Datelor, pe de o parte, si Viteza de Acces la Date, pe de alta parte, pot fi divergente. Aceasta întrucât primul va insista asupra Normalizarii accentuate a Structurilor, pe când cel de al doilea ar cere Compromisuri de Denormalizare si de Redondanta.

Ni se pare firesc sa începem discutia problemei optimizarii cu principala resursa si anume Datele. Aceasta cu atât mai mult cu cât criteriile de evaluare a structurii acestora sunt mai complexe, implicând si aspectele calitative ale Sursei de Date. 5.1 Optimizarea Structurilor de Date

Optimizarea structurii datelor poarta numele de Normalizare a Structurilor, dupa numele dat Structurilor Optimizate Calitativ – Forme Normalizate. Procesul se bazeaza pe determinarea si îmbunatatirea Dependentelor Functionale în cadrul Structurilor de Date.

Dependentele Functionale stabilite în Structurile de Date pot fi folosite si în alte scopuri decât cel de îmbunatatire a structurilor. Ele formeaza o sursa importanta pentru Deducerea Cunostintelor provenind din Analiza Faptelor consemnate în Arhivele de Date ale sistemelor de Explorare a Datelor (Datamining).

Termenul de Optimizare a Structurii Datelor suporta comentarii, deoarece Criteriile de Optimizare, atât sub aspect calitativ (preluare maxima de semantica în structura), cât si cantitativ (viteza de prelucrare a Cererilor) nu îsi gasesc o formulare analitica simpla si univoca, care sa ofere în general Solutii Unice. Daca îl folosim totusi este pentru a marca necesitatea de perfectionare permanenta a ambelor procese. Pe primul îl vom privi ca o Tendinta Permanenta, în timp ce pe cel de al doilea îl vedem ca o Constrângere Momentana, legata de Gradul de Evolutie al Tehnicii de Calcul. Ambele însa se înscriu în preocuparea continua a SBD de crestere a Gradului de Independenta a Datelor.

370 Optimizarea Structurilor de Date

5.1.1 Introducere

Problema Normalizarii Relatiilor apare ca o necesitate de Îmbunatatire a Structurii Datelor într-un Model Relational. Formularea matematica precisa a acestui Model permit aparitia preocuparilor legate de analiza Calitatii Structurii Interne a Datelor. Obiectivele principale ale acestei activitati sunt reprezentate de:

o Asigurarea Fidelitatii Semantice maxime la conversia Structurilor de Informatii în Structuri de Date

Prin Fidelitate Semantica se întelege preluarea sensurilor din Spatiul de Informatii si transpunerea lor în Structurile din Spatiul Datelor. Acest deziderat poate fi realizat prin respectarea urmatoarelor conditii:

§ Suprapunerea sferelor Entitatilor si Claselor de Entitati din Spatiul Datelor peste cele din Spatiul Informatiilor

§ Alocarea Atributelor acelor Entitati pe care le descriu cu adevarat în Spatiul Informatiilor (”Atributul potrivit la Locul potrivit”)

§ Asigurarea Independentei Atributelor Descriptoare

§ Preluarea corecta a Legaturilor existente între Entitati în Planul Semantic

In concluzie activitatea consta în împartirea corecta a Rolurilor între Informatii si Grupuri de Informatii, încheiata cu stabilirea Entitatilor, a Claselor de Entitati, a Atributelor si a Legaturilor între Entitati

o Asigurarea Consistentei Informationale maxime

Prin Consistenta se întelege eliminarea dintr-o Structura de Date a cazurilor de Ambiguitate provocate de aparitia multipla a aceleiasi Informatii. Eliminarea acestei ambiguitati se poate face la doua nivele:

§ La nivel Structural – prin evitarea aparitiei Informatiei Multiple (Datelor Dependente)

§ La nivel Procedural – prin prevederea Sincronizarii Operationale a Informatiei Multiple, utilizând proceduri speciale de actualizare a Datelor Dependente (Proceduri Tranzactionale sau de Replicare)

Se remarca faptul ca problema Consistentei este strâns legata de cea a Redondantei în Structurile de Date. Prioritara ramâne însa asigurarea Consistentei, care se mentine si atunci când exista suficient spatiu de memorare si Redondanta ar putea fi acceptata. Eliminarea Redondantei se mentine doar ca o forma de crestere a performantelor de utilizare a resurselor de spatiu si timp. Dupa cum arata practica, eliminarea completa a Redondantei nu este, în caz general, posibila la performantele actuale ale sistemelor de calcul. Este vorba de necesitatea memorarii Starilor Sistemelor la un moment dat (Solduri, Stocuri, Conturi etc.), care altfel pot fi deduse din ansamblul Transformarilor Sistemelor (Tranzactiilor), daca se presupun Stari Initiale Nule, prezumtie greu, daca nu imposibil, de respectat. Chiar în conditiile acestei ipoteze confirmate, ramâne deschisa problema Timpului de Calcul al Starilor pornind de la inspectia tuturor Transformarilor (Tranzactiilor) aferente.

Optimizarea Structurilor de Date 371

In cele ce urmeaza ne vom concentra atentia exclusiv asupra nivelului Structural de mentinere a Consistentei Datelor. Tratarea nivelului Procedural formeaza obiectul Sistemelor Tranzactionale (vezi sectiunea 6.2).

La nivel Structural, Optimizarea Structurilor de Date se poate formula si în termenii asigurarii în Plan Conceptual a Capacitatii Complete de Legatura (Complete Relatability), reprezentata de capabilitatea Schemei de Definitie de a oglindi Exact si Neambigu toate legaturile existente în Spatiul Informatiilor, adica toate legaturile ce prezinta interes pentru Utilizatorul Final. Aceste legaturi reunesc raporturile existente între:

§ Entitate – Atribute - Raporturi între Atribute si Entitate

§ Atribute – Atribute - Raporturi între Atributele aceleiasi Entitati

§ Entitati – Entitati - Raporturi între Entitati diferite 5.1.2 Abordarea Formalizata a Normalizarii Relatiilor

Înainte de tratarea Formalizata a Normalizarii sa exprimam formalizat conceptele BDR. 5.1.2.1 Definitii si Notatii

o Baza de Date Relationala – o multime de relatii, variabile în timp si având diferite grade n, (n ≥ 1), fiecare având forma:

R (A 1 , A 2 , .. , A n )

o Atribute ale relatiei R – lista A 1 , A 2 , .. , A n , reprezentând aparitia în cadrul relatiei a Domeniilor pe care e definita relatia R; numelor atributelor poate prelua numele domeniilor, caz în care la provenienta unor atribute distincte din acelasi domeniu se cere o diversificare a numelor lor (adaugarea unui ALIAS) pentru evitarea ambiguitatii;

o Tupla Logica a unei relatii R ( Ω ) – ansamblul Atributelor care descriu o relatie privite ca o multime si ca atare având ordinea de aparitie indiferenta, dar odata definita ea trebuind sa fie mentinuta pe toata durata de existenta a relatiei:

Ω = A 1 , A 2 , .. , A n

o Intensiunea unei relatii R ( Ω ) – semnificatia acordata legaturii între Atributele relatiei privita ca o Proprietate Definitorie adaugata multimii Produsului Cartezian al Domeniilor în care e inclusa Relatia; Intensiunea unei relatii e definita de Tupla Logica asociata acelei relatii:

R ( Ω ) , cu:

Ω = A 1 , A 2 , .. , A n

o Cardinalitatea Tuplei Logice a unei relatii – numarul elementelor din multimea de Atribute, care defineste Gradul relatiei:

372 Optimizarea Structurilor de Date

| Ω | = n

(Cardinalitatea Tuplei Logice ≡ Cardinalitatea Intensiunii Relatiei)

o Subtupla Logica a unei relatii R ( Ω ) – o submultime de Atribute ale unei relatii:

Ω = A 1 , A 2 , .. , A m , cu:

∆ ⊆ Ω

o Atribut al unei relatii – orice Proprietate ce caracterizeaza o relatie:

R [ A ] unde A ∈ Ω

o Valoare de Atribut al unei relatii – o valoare particulara a unui Atribut ce caracterizeaza o relatie (Instanta sau Realizare de Atribut):

r [ A ] unde A ∈ Ω

o Tupla Fizica a unei relatii R – o combinatie particulara de valori ale tuturor Atributelor unei relatii (Instanta sau Realizare de Tupla):

r [ Ω ]

o Subtupla Fizica a unei relatii R ( Ω ) – un ansamblu de valori ale unui subset de Atribute ale unei relatii:

r [ ∆ ] cu:

∆ ⊆ Ω

o Extensiunea unei relatii R ( Ω ) – multimea legaturilor existente între Valorile din Domeniile pe care e definita Relatia; Extensiunea unei relatii e definita de multimea Tuplelor Fizice ale relatiei:

R [ Ω ] = R r 1 , r 2 , .. , r m

o Cardinalitatea unei relatii R ( Ω ) – numarul Tuplelor Fizice ale relatiei:

m r = | R |

o Cardinalitatea Subtuplei Logice a unei relatii – numarul de Atribute din Subtupla:

n s = | ∆ |

o Proiectia unei relatii – multimea tuturor Subtuplelor Fizice ale unei relatii, corespunzatoare unei Subtuple Logice ale relatiei date:

Π R ∆ = r 1 | r 1 = r [ ∆ ] si r ∈ Ω

care se poate scrie si:

Optimizarea Structurilor de Date 373

Π R ( ∆ ) = Π R ( Ω ) ∆

întrucât:

Π R ∆ e ea însasi o relatie pe submultimea de atribute ∆ .

o Tuple Logice disjuncte – tuple a caror intersectii de multimi de Atribute sunt vide ( ∅ )

o Reunirea (Cuplarea) Naturala a doua relatii R ( Ω ) si S ( ∆ ) – o noua relatie J, pe multimea de atribute Ω ∪ S , definita ca:

R ( Ω ) * S ( ∆ ) = r | r [ Ω ] ∈ R [ Ω ] si r [ ∆ ] ∈ S [ ∆ ] = J ( Ω ∪ ∆ )

Reunirea Naturala e comutativa si asociativa.

o Produsul Cartezian a doua relatii R ( Ω ) si S ( ∆ ) – o Reunire a relatiilor pentru cazul în care se verifica conditia:

∩ ∆ = ∅

5.1.2.2 Dependente Functionale

Dupa cum se va putea remarca, Dependentele Functionale reprezinta un instrument precis si consistent pentru a masura Gradul de Independenta existent între Elementele constitutive ale Relatiilor , anume Atributele, grupate în Identificatori si Descriptori. 5.1.2.2.1 Definitii si Notatii

o Dependenta Functionala DF – o combinatie de Atribute Γ se zice Functional Dependenta (FD) în R de o combinatie de Atribute ∆ , în notatie:

∆ → Γ

care exprima proprietatea:

∆ determina functional pe Γ

sau:

Γ e functional dependenta de ∆

daca:

∀ ( r 1 , r 2 ) ∈ R | ( r 1 [ ∆ ] = r 2 [ ∆ ] ) ⇒ ( r 1 [ Γ ] = r 2 [ Γ ] )

altfel spus:

“ egalitatea Valorilor atributelor ∆ implica egalitatea Valorilor atributelor Γ “

374 Optimizarea Structurilor de Date

o Independenta Functionala IF – o combinatie de Atribute Γ se zice Independenta Functional în R de o combinatie de Atribute ∆ , în notatie:

∆ ⁄ → Γ

Γ e Functional Independenta de ∆ daca:

∃ ( r 1 , r 2 ) ∈ R | ( r 1 [ ∆ ] = r 2 [ ∆ ] ) ⇒ ( r 1 [ Γ ] ≠ r 2 [ Γ ] )

altfel spus:

“ egalitatea Valorilor atributelor ∆ nu implica egalitatea Valorilor atributelor Γ “

o Dependenta Functionala Triviala – orice DF :

∆ → Γ

pentru care :

∆ ⊇ Γ

o Determinant DT – membrul stâng al unei Dependente Functionale care nu include o Dependenta Triviala:

DT → Γ

o Orice Determinant implica o Dependenta Functionala Minimala (Ireductibila) – vezi definitiile ulterioare

5.1.2.2.1.1 Proprietatile Formale ale Dependentelor Functionale

Proprietatile formale ale Dependentelor Functionale sunt importante pentru optimizarea structurilor relationale, fiind ca atare folosite în proiectarea Schemelor de Descriere a Bazelor de Date Relationale.

Fie:

- Relatia R ( Ω )

- Combinatiile nevide de atribute: ∆ , Γ , Λ , Ψ ⊆ Ω

Cu elementele precizate mai sus se definesc urmatoarele Proprietatile formale ale Dependentelor Functionale:

§ Reflexivitate - sta la baza Dependentelor Functionale Triviale

∆ ⊆ Γ ⇒ ∆ → Γ

§ Augmentare

∆ ⊆ Γ si Λ ⊆ Ψ ⇒ ( ∆ ∪ Λ ) → ( Γ ∪ Ψ )

caci prin Reflexivitate:

∆ ⊆ Γ ⇒ ∆ → Γ

Optimizarea Structurilor de Date 375

Λ ⊆ Ψ ⇒ Λ → Ψ

§ Tranzitivitate

∆ → Γ si Γ → Ψ ⇒ ∆ → Ψ

§ Pseudo-Tranzitivitate

∆ → Γ si ( Γ ∪ Λ ) → Ψ ⇒ ( ∆ ∪ Λ ) → Ψ

§ Aditivitate

∆ → Γ si ∆ → Ψ ⇒ ∆ → ( Γ ∪ Ψ )

§ Distributivitate - fata de Reuniune

∆ → Γ si ∆ → Ψ ⇒ ∆ → ( Γ ∪ Ψ )

§ Proiectabilitate

∆ → ( Γ ∪ Λ ) ⇒ ∆ → Γ si ∆ → Λ

§ Proiectabilitate Inversa – transferul Dependentelor Functionale între o Proiectie P (R) si Relatia R

∆ → Γ în P ( R ) ⇒ ∆ → Γ în R

Cu aceste proprietati se pot defini urmatoarele Tipuri de Dependente Functionale:

o Dependenta Functionala Tranzitiva – orice DF, Γ z :

∆ → Γ z

pentru care:

∆ → ∆ ‘ → Γ z .

o Dependenta Functionala Compusa – orice DF, Γ c :

∆ → Γ c

pentru care:

∆ = A 1 , A 2 , .. , A k , cu k >1

o Dependenta Functionala Completa (Ireductibila) – orice DF compusa, Γ t :

∆ → Γ t

pentru care:

∆ = A 1 , A 2 , .. , A k , cu k >1

si:

∆ ‘ ⁄ → Γ t

376 Optimizarea Structurilor de Date

unde:

∆ ′ ⊂ ∆ .

Se pot acum introduce urmatoarele notiuni necesare în tratarea Dependentelor Functionale:

o Cheie Candidata a unei relatii R ( Ω ) - o combinatie de Atribute ∆ , ∆ ⊇ Ω se zice Cheie Candidata pentru R ( Ω ) daca:

∆ → Ω

si:

∀ ∆′ ⊂ ∆ ⇒ ∆′ ⁄ → Ω

Proprietatea definitorie a Cheii Candidate face ca existenta în cadrul unei relatii a mai multor tuple cu aceeasi valoare de Cheie Candidata sa nu fie admis a, întrucât încalca proprietatea de Identificare Unica a fiecarui element din Relatia privita ca multime. Rezulta de aici, pentru fiecare Relatie, necesitatea:

• Unicitatii valorilor Cheii Candidate

• Existentei, cel putin a unei Chei Candidate, numita Cheie Primara

Existenta în R doar a Dependentelor Triviale, Ω → P ( Ω ) , face ca Ω sa reprezinte singura Cheie Candidata

o Cheie Primara a unei relatii R ( Ω ) - o Cheie Candidata selectata arbitrar de Utilizator pentru a identifica în mod curent Tuplele Relatiei; criteriile de selectie a Cheii Primare sunt:

• Simplitatea

• Uzualitatea

• Obisnuinta

• etc.

o SuperCheie a unei relatii R ( Ω ) - o combinatie de Atribute ∆ S , ∆ S ⊇ Ω , care include o Cheie Candidata ∆ ca o Submultime (nu neaparat Proprie). Ca urmare:

∆ S ⊇ ∆ ⇒ ∆ S → Ω

întrucât:

∆ → Ω

altfel spus:

“ O SuperCheie e o Cheie Candidata fara conditia de minimalitate impusa “

Pe baza acestei ultime definitii se poate observa utilitatea notiunii de SuperCheie la determinarea Cheilor Candidate ale unei relatii:

Optimizarea Structurilor de Date 377

§ Se determina SuperCheile relatiei

§ Se încearca minimalizarea acestora pentru obtinerea Cheilor Candidate

Se mai subliniaza proprietatea unei SuperChei de a Determina Functional toate Atributele unei Relatii.

o Închiderea D + a unui set dat de Dependente Functionale D – multimea tuturor Dependentelor Functionale implicate de Dependentele Functionale Initiale D:

D ⇒ D +

Determinarea Închiderii D + a unui set dat de Dependente Functionale D se poate face conform urmatoarei proceduri: • Se porneste de la o multime de DF determinate de semantica atasata

structurii de date • Se genereaza noi DF pe baza unui set de Reguli de Inferenta

Un asemenea set de Reguli de Inferenta a fost propus de Armstrong (Axiomele lui Armstrong):

• Reguli Primare

o 1.– Reflexivitate B ⊆ A ⇒ A → B

o 2.– Augmentare A → B ⇒ AC → BC

o 3.– Tranzitivitate A → B si B → C ⇒ A → C

• Reguli Derivate

o 4.– Autodeterminare A → A

o 5.– Descompunere A → BC ⇒ A → B si A → C

o 6.– Reuniune A → B si A → C ⇒ A → BC

o 7.– Compunere A → B si C → D ⇒ AC → BD

o Închiderea ∆ S+ a unei SuperChei ∆ S implicata de Dependentele Functionale D – multimea tuturor Atributelor unei relatii ce Depind Functional de acea SuperCheie pornind de la D:

∆ S → ∆ S+

Algoritm de determinare a lui ∆S+ folosind Regulile de Inferenta ale lui Armstrong:

∆ S+vechi =

∆ S+ = ∆ S

REPETA cât timp ∆ S+vechi ≠ ∆ S+

∆ S+vechi = ∆ S+

REPETA pentru toate DF ( X → Y) DACA X ⊆ ∆ S

∆ S+ = ∆ S+ ∪ Y

378 Optimizarea Structurilor de Date

SFARSIT-CONDITIE SFARSIT-REPETITIE

SFARSIT-REPETITIE

o Acoperirea Da a unui set dat de Dependente Functionale D – un set de Dependente Functionale continut în D si care implica toate Dependentele Functionale din D:

Da ⊂ D

si daca:

D ⇒ D+

atunci:

Da ⇒ D+

altfel spus:

“ Daca un SGBD asigura Restrictiile impuse de D a atunci el va asigura implicit si Restrictiile impuse de D “

o Dependente Functionale Minimale Dm – un set de Dependente Functionale ce sunt Ireductibile deoarece satisfac urmatoarele conditii:

§ Membrul drept al tuturor DF e singular (contine un singur Atribut)

§ Membrul stâng al fiecarei DF e Ireductibil (eliminarea oricarui Atribut modifica Închiderea D+ a multimii DF)

§ DF sunt Ireductibile (eliminarea oricarei DF modifica Închiderea D+ a multimii DF)

Pentru orice multime DF exista cel putin o multime de

Dependente Functionale Minimale Dm.

o Acoperire Minimala Dam a unui set dat de Dependente Functionale D – o Acoperire care satisface conditiile de minimalitate.

In general Acoperirea Minimala D am nu e unica.

5.1.2.2.2 Relatii Normalizate BCNF

o Relatii Normalizate BCNF – sunt relatii în care orice Determinant e Cheie Candidata.

o Conservarea Semantica la descompunerea unei Relatii R într-o multime de Proiectii Ri – mentinerea Dependentelor existente în relatia initiala prin respectarea conditiei:

D am (D ( R ) ) = D am ( ∪ D (R i ) )

Optimizarea Structurilor de Date 379

altfel spus:

“ Acoperirea Minimala a Dependentelor din relatia initiala sa fie aceeasi cu Acoperirea Minimala a reuniunii Dependentelor din proiectiile relatiei “

5.1.2.3 Dependente Multivalorice

o Multime de Valori Asociate M ∆ ( r [ θ ] ) – Multimea de Valori r ′ [ ∆ ] asociata unei Valori r [ θ ] din R si definita astfel (vezi si Fig. 5.1.2.3.1):

M ∆ ( r [ θ ] ) = r ′ [ ∆ ] | r ′ ∈ R si r ′ [ θ ] = r [ θ ]

M ∆ (r [ θ ]) se zice si Imaginea lui r [ θ ] în R, pentru θ si ∆ disjuncte în Ω

o Multimea Imaginilor lui Π R (θ) în Π R (∆) M ∆ – Domeniul de Valori al Aplicatiei Multimii Valorilor Proiectiei Π R (θ) în Multimea Partilor lui Π R (∆) din R ( Ω ). Aplicatia e definita ca mai jos (vezi si Fig. 5.1.2.3.1):

( r [ θ ], r [ ∆ ]) ∈ Π R (θ) x Π R (∆) | ( r [ θ ], r [ ∆ ]) ∈ R

Fig. 5.1.2.3.1 Exemplificarea grafica a Dependentelor Multivalorice

o Dependenta Multivalorica DM – Fiind data relatia R (Ω ) si Listele de Atribute Γ , ∆ si Λ , astfel încât:

Γ , ∆ , Λ ⊂ Ω

si:

Λ = Ω - (Γ ∪ ∆)

Multimea Π R (θ ) Domeniul de definitie

n n

n n n

n n n

n

n

M ∆

Multimea Partilor Π R (∆)

Domeniul de valori

M ∆ ( r [ θ ] ) r [ θ ]

r ′ [ ∆ ] )

380 Optimizarea Structurilor de Date

iar:

Λ = Ω - (Γ ∪ ∆)

M ∆ reprezinta Multimea Imaginilor lui Π R (Γ ∪ Λ) în Π R (∆)

Atunci, o Combinatie de Atribute ∆ se zice Multivaloric Dependenta (MD) în R de o Combinatie de Atribute Γ , în notatie:

Γ →→ ∆

si în expresie:

Γ determina multivaloric pe ∆

sau:

∆ e multivaloric dependenta de Γ

daca:

∀ ( r 1 , r 2 ) ∈ Π R (Γ ∪ Λ) | ( r 1 [ Γ ] = r 2 [ Γ ] ) ⇒ (M ∆ ( r 1 ) = M ∆ ( r 2 ) )

altfel spus:

“ Egalitatea Valorilor atributelor Γ implica egalitatea Multimii de Valori ale atributelor ∆ Asociate Valorilor atributelor Γ “ .

Exemplu:

Sa consideram activitatea de Aprovizionare cu Produse a unor Depozite, care se desfasoara cu urmatoarele restrictii:

• Fiecare Produs se caracterizeaza printr-o Marca de Produs

• Fiecare Depozit este specialializat pentru achizitia acelorasi Marci de Produse

• Aprovizionarea se efectueaza prin emiterea de Comenzi

• Fiecare Comanda contine urmatoarele informatii: Numarul de Comanda, Depozitul, Produsul, Marca Produsului

• La fiecare Comanda, fiecare Depozit emite cereri pentru toate Marcile de Produse în care este interesat

Activitatea de Aprovizionare va putea fi descris a de urmatoarea Schema de Relatii:

COMANDA (Numar-Comanda, Depozit, Produs, Marca)

PRIMARY KEY (Numar-Comanda, Depozit, Produs, Marca)

In Tab. 5.1.2.3.2 se da o extensie posibila a Tabelei de Baza atasata Relatiei anterior descris a:

Optimizarea Structurilor de Date 381

Ω Λ Γ ∆

Numar-Comanda

Depozit Produs Marca-Produs

NC1 D1 P1 MP1 NC1 D1 P1 MP2 NC2 D2 P1 MP3 NC2 D2 P1 MP4 NC3 D1 P1 MP1 NC3 D1 P1 MP2 NC4 D1 P2 MP5 NC5 D2 P2 MP6 NC6 D2 P1 MP3 NC6 D2 P1 MP4

Tab. 5.1.2.3.2 Extensiunea Tabelei de Baza COMANDA

o Dependenta Multivalorica Triviala – orice DM pentru care:

Γ ∪ ∆ = Ω deci: Λ = ∅

sau

Γ ⊇ ∆

o Dependenta Functionala – orice DM pentru care:

| M Γ ( r [ ∆ ] )| = 1 pentru orice valoare a combinatiei ( Γ ∪ ∆ )

o Relatie Normala RN4 – o relatie care contine DM Netriviale de o combinatie data de atribute si în care toate celelalte atribute sunt Functional Dependente de aceeasi combinatie de atribute.

5.1.2.3.1 Proprietatile Formale ale Dependentelor Multivalorice:

Proprietatile Formale ale Dependentelor Multivalorice alaturi de cele ale Dependentelor Functionale stau la baza tratarii formale a proceselor de optimizare a structurilor relationale. Fie:

- Relatia R ( Ω )

- Combinatiile nevide de atribute: ∆ , Γ , Λ , Ψ ⊆ Ω

Cu elementele precizate mai sus se definesc urmatoarele Proprietatile formale ale Dependentelor Multivalorice:

§ Reflexivitate - sta la baza Dependentelor Multivalorice Triviale

∆ ⊆ Γ ⇒ ∆ →→ Γ

r [ Γ ] = (D1, P1)

r [ Γ ] = (D2, P1)

M ∆ ( r [ θ ] ) = MP1, MP2)

M ∆ ( r [ θ ] ) = MP3, MP4)

382 Optimizarea Structurilor de Date

§ Complementaritate

∆ →→ Γ daca si numai daca Λ →→ Γ

unde:

Λ = Ω - ( ∆ ∪ Γ )

§ Augmentare

Λ ⊆ Ψ si ∆ →→ Γ ⇒ ( ∆ ∪ Λ ) →→ ( Γ ∪ Ψ )

§ Tranzitivitate

∆ →→ Γ si Γ →→ Ψ ⇒ ∆ →→ ( Ψ - Γ )

§ Tranzitivitate Restrânsa

∆ →→ Γ si Γ →→ Ψ ⇒ ∆ →→ Ψ

daca:

Γ ∩ Ψ = θ

§ Pseudo-Tranzitivitate

∆ →→ Γ si ( Γ ∪ Λ ) →→ Ψ ⇒ ( ∆ ∪ Λ ) →→ ( Ψ - Γ )

§ Compozitie Generala

∆ →→ Γ si Λ →→ Ψ ⇒ ∆ →→ ( Ψ - Γ )

unde:

Λ ⊆ ( ∆ ∪ Γ )

§ Partitionabilitate

∆ →→ Γ si ∆ →→ Λ ⇒ ∆ →→ ( Γ - Λ )

∆ →→ Γ si ∆ →→ Λ ⇒ ∆ →→ ( Λ - Γ )

∆ →→ Γ si ∆ →→ Λ ⇒ ∆ →→ ( Γ ∩ Λ )

§ Aditivitate

∆ →→ Γ si ∆ →→ Ψ ⇒ ∆ →→ ( Γ ∪ Ψ )

§ Proiectibilitate

∆ →→ Γ în R ( Ω ) ⇒ ∆ →→ Γ ∩ Ψ în Π R ( Ψ )

unde:

∆ ⊆ Ψ ⊆ Ω

Optimizarea Structurilor de Date 383

5.1.3 Abordarea Istorica a Normalizarii Relatiilor

Abordarea istorica a Normalizarii Relatiilor este mult mai mult decât o consemnare a aparitiei preocuparilor legate de optimizarea Structurilor de Date si aceasta cel putin din doua motive:

o Pentru întelegerea importantei Normalizarii Structurilor în orice domeniu si prin aceasta a Rolului actual de neînlocuit, pe care îl joaca acest proces în construirea Structurilor de Date

o Pentru întelegerea limitelor la care analiza Strict Formala a dependentelor este concurata de alte abordari, de obicei Semantice, si astfel îsi pierde prioritatea ca instrument practic, transformându-se într-un obiect de studiu cu posibile aplicari viitoare

Legenda RNN - Relatii Nenormalizate RN - Relatii Normalizate RN1 - Relatii Normalizate de gradul I

RN2 - Relatii Normalizate de gradul II RN3 - Relatii Normalizate de gradul III RN4 - Relatii Normalizate de gradul IV RBCNF - Relatii Normalizate de tip Boyce – Codd Normal Form RPJNF - Relatii Normalizate de tip Project Normal Form

Fig. 5.1.3.1 Gradele de normalizare ale relatiilor

RN + RNN

RN1

RN2

RN3 RBCNF

RN4 RN5 -PJNF

384 Optimizarea Structurilor de Date

Prezentarea evolutiei modului de îmbunatatire progresiva a structurilor de baza pe care se construiesc sistemele complexe permite de la început o clasificare a Calitatii diferitelor Structuri de Date. Referirea este directa la Structurile Relationale si aceasta apare firesc pentru cei ce au înteles fundamentalitatea abordarii relationale. Clasificarea Structurilor Relationale respecta pasii facuti pe calea perfectionarii Structurilor Relationale. Se cunosc 6 etape de normalizare a relatiilor care corespund Gradelor de Normalizare reprezentate în Fig. 5.1.3.1.

Se remarca proprietatea de incluziune a multimilor de relatii având Grade de Normalizare crescatoare, ceea ce conduce la afirmatia evidenta:

“ O relatie de grad N (i+1) este totodata o relatie de grad N (i). “

sau în expresie:

RN (i+1) ⇒ RN (i)

Exista în procesul de descoperire a Gradelor de Normalizare o determinare legata de stadiul evolutiei tehnologiei de prelucrare a datelor la momentul aparitiei preocuparilor de îmbunatatire a Structurilor de Date. Sistemele complexe erau presate de dificultatile tot mai frecvente, implicate de administrarea integrata a colectiilor mari si foarte mari de date acumulate de sistemele traditionale de gestiune a fisierelor. Rezolvarea acestor dificultati în pasi succesivi au determinat si definirea gradelor crescatoare de normalizare a relatiilor.

Pentru prezentarea Etapelor de Normalizare a Relatiilor se foloseste în literatura de specialitate exemplul de gestiune a CONTRACTELOR de PRODUSE încheiate de un BENEFICIAR. Se prezinta în continuare acest exemplu prin descriere Intensionala si Extensionala, în Spatiul Informatiilor si al Datelor. Sunt adaugate de asemenea câteva reprezentari grafice utile: Diagrama Simbolica si Arborele de Structura .

Se mentioneaza ca întregul studiu al Dependentelor Functionale se bazeaza pe semantica acordata datelor ce se cer modelate, asa încât cunoasterea Spatiului de Informatii în detaliu, cu toate nuantele de interpretare atasate elementelor componente este strict necesara. 5.1.3.1 Studiu de Caz

Întrucât problematica Normalizarii Structurilor nu poate fi prezentata în afara Semanticii acordata de Utilizator Structurilor de Date se prezinta, în deschiderea analizei Etapelor de Normalizare, o Structura de Informatii si Date frecvent prezenta în Sistemele Informatice – BENEFICIARI / PRODUSE / CONTRACTE. Fata de structura discutata în sectiunea 3.4.4 s-a preferat o versiune simplificata, în care Entitatea CONTRACTE este prezentata fara structura interna ANTET DOCUMENT – RANDURI DOCUMENT. 5.1.3.1.1 Spatiul Informatiilor 5.1.3.1.1.1 Descrierea Spatiului de Informatii

o Clase de Entitati

§ BENEFICIAR - societati comerciale interesate în achizitionarea unor produse

Optimizarea Structurilor de Date 385

§ PRODUSE - portofoliul de produse oferit de un producator

§ CONTRACTE - specificarea cantitatilor contractate de fiecare beneficiar din fiecare produs

o Atribute

§ Clasa de Entitati BENEFICIAR

• Cod - simbol de identificare al societatii comerciale

• Nume - denumirea societatii comerciale

• Oras - orasul de resedinta al societatii comerciale (unic)

• Tip - forma de organizare a societatii comerciale (SRL, SA, RA)

§ Clasa de Entitati PRODUS

• Cod - simbol de identificare al produsului oferit

• Nume - denumirea produsului oferit

• Culoare - culoarea produsului oferit

• Greutate - greutatea produsului oferit

• Oras - orasul de resedinta al producatorului (unic)

§ Clasa de Entitati CONTRACT

• Beneficiar - beneficiarul pozitiei contractate

• Produs - produsul contractat

• Cantitate - cantitatea contractata

o Identificatori

§ BENEFICIAR - Cod Beneficiar

§ PRODUS - Cod Produs

§ CONTRACT - Cod Beneficiar + Cod Produs

Pentru transpunerea Specificatiilor de Definitie Semantica a Spatiului de Informatii se vor folosi doua formalisme grafice Diagrama Simbolica si Diagramele Dependentelor Functionale. 5.1.3.1.1.2 Diagrama Simbolica

In Fig. 5.1.3.1.1.2.1 sunt reprezentate Clasele de Entitati si Legaturile între acestea provenite din semnificatiile atribuite în Spatiul de Informatii. Aceasta reprezentare consemneaza legaturile fundamentale care exista între entitatile din spatiul de informatii, grupate în:

o Legaturi de Baza :

§ Un BENEFICIAR poate contracta diferite cantitati specificate în CONTRACTE (sageata continua BENEFICIAR – CONTRACT)

386 Optimizarea Structurilor de Date

§ Un PRODUS poate fi contractat în diferite cantitati specificate în CONTRACTE (sageata continua PRODUS – CONTRACT)

o Legaturi derivate:

§ Un BENEFICIAR poate contracta diferite PRODUSE (sageata punctata BENEFICIAR – PRODUS)

§ Un PRODUS poate fi contractat de diferiti BENEFICIARI (sageata punctata PRODUS - BENEFICIAR)

Fig. 5.1.3.1.1.2.1 Diagrama Simbolica BENEFICIARI - PRODUSE - CONTRACTE 5.1.3.1.1.3 Diagramele Dependentelor Functionale

Aceasta noua reprezentare completeaza tabloul descrierii semantice cu Legaturile de Dependenta precizate între atributele fiecarei entitati. In aceste relatii sunt cuprinse numai Dependentele Functionale Ireductibile (vezi sectiunea 5.1.2.2.1.1).

o Entitatea BENEFICIAR

§ Un BENEFICIAR se identifica printr-un Cod unic

§ Un BENEFICIAR are un Nume unic

§ Un BENEFICIAR are sediul într-un singur Oras

§ Un BENEFICIAR are un Tip de Societate Comerciala unic

Fig. 5.1.3.1.3.1 Dependentele Functionale în relatia BENEFICIAR

BENEFICIAR PRODUS

CONTRACT

1 1

n n

nm

Cod

Nume

Oras

Tip

Optimizarea Structurilor de Date 387

o Entitatea PRODUS

§ Un PRODUS se identifica printr-un Cod unic

§ Un PRODUS are un Nume unic

§ Un PRODUS are o Culoare unica

§ Un PRODUS are o Greutate unica

§ Producatorul unui PRODUS are sediul într-un singur Oras

Fig. 5.1.3.1.3.2 Dependentele Functionale în relatia PRODUS

o Entitatea CONTRACT

§ Fiecare Pozitie Contractata dintr-un CONTRACT se identifica printr-o pereche unica Beneficiar - Produs

§ Fiecare Pozitie Contractata dintr-un CONTRACT are o Cantitate unica

Fig. 5.1.3.1.3.3 Dependentele Functionale în relatia CONTRACT

5.1.3.1.2 Spatiul Datelor 5.1.3.1.2.1 Descriere Intensionala

Pentru descrierea Intensionala a Structurii de Date se foloseste Schema de Relatii reprezentata în Fig. 5.1.3.1.2.1.1.

Cod

Nume

Culoare

Greutate

Oras

Produs

Cantitate

Beneficiar

388 Optimizarea Structurilor de Date

Schema de Relatii contine urmatoarele Informatii:

- Descrierea Domeniilor

- Descrierea Relatiilor + Atributelor Descriptoare

- Descrierea Identificatorilor (Chei Primare, Chei Candidate)

- Descrierea Referirilor Relationale (Chei Straine) Schema de Relatii

DOMAIN codb CHAR (5) DOMAIN numeb CHAR (20) DOMAIN oras CHAR (15) DOMAIN tipb CHAR (2) DOMAIN codp CHAR (5) DOMAIN numep CHAR (30) DOMAIN culoare CHAR (15) DOMAIN greutate NUMERIC (8)

DOMAIN cantitate NUMERIC (10)

RELATION BENEFICIAR Cod DOMAIN codb Nume DOMAIN numeb Oras DOMAIN oras Tip DOMAIN tipb

PRIMARY KEY Cod

RELATION PRODUS Cod DOMAIN codp Nume DOMAIN numep Culoare DOMAIN culoare Greutate DOMAIN greutate Oras DOMAIN oras

PRIMARY KEY Cod RELATION CONTRACT

Beneficiar DOMAIN codb Produs DOMAIN codp Cantitate DOMAIN cantitate

PRIMARY KEY Beneficiar, Produs FOREIGN KEY Beneficiar REFERENCES BENEFICIAR.Cod FOREIGN KEY Produs REFERENCES PRODUS.Cod

Fig. 5.1.3.1.2.1.1 Schema de Relatii BENEFICIAR-PRODUS-CONTRACT

Optimizarea Structurilor de Date 389

5.1.3.1.2.2 Arborele de Structura

Arborele de Structura din Fig. 5.1.3.1.2.2.1 releva caracteristicile relationale de implementare în Spatiul Datelor a structurii BENEFICIARI – PRODUSE – CONTRACTE.

Sunt evidentiate: Entitatile, Atributele, Identificatorii (Cheile Primare cu Constituentii de Chei), Referirile Relationate Asociative (Cheile Straine)

B - BENEFICIARI P – PRODUSE C - CONTRACTE

c - Cod l - Culoare b - Cod Beneficiar n - Nume g - Greutate p - Cod Produs o - Oras q - Cantitate t - Tip societate

Fig. 5.1.3.1.2.2.1 Schema de Relatii BENEFICIAR-PRODUS-CONTRACT

5.1.3.1.2.3 Descriere Extensionala – Valori Memorate

Asa dupa cum se va vedea în continuare, Faptele consemnate în structura de date sub forma Valorilor de Atribute si Tuple, releva numeroase aspecte legate de semantica acordata Spatiului de Informatii care a stat la baza Structurii de Date. De aceea reprezentam în tabelele din Fig. 5.1.3.1.2.3.1 descrierea extensionala a structurii relationale prezentata anterior.

BENEFICIAR Cod* Nume Oras Tip

B1 N1 O1 T1 B2 N2 O2 T2 B3 N3 O2 T2 B4 N4 O1 T1 B5 N5 O3 T3

l n

o n

n n

q n

g n

o n*

*

* C

b p

B

c n

P

c

*

t n

390 Optimizarea Structurilor de Date

PRODUS Cod* Nume Culoare Greutate Oras

P1 N1 C1 G1 O1 P2 N2 C2 G2 O2 P3 N3 C3 G2 O3 P4 N4 C1 G3 O1 P5 N5 C3 G1 O2 P6 N6 C1 G4 O1

CONTRACT Beneficiar* Produs* Cantitate

B1 P1 Q1 B1 P2 Q2 B1 P3 Q3 B1 P4 Q2 B1 P5 Q4 B2 P1 Q5 B2 P2 Q1 B3 P2 Q3 B4 P5 Q6

Fig. 5.1.3.1.2.3.1 Schema de Relatii BENEFICIAR-PRODUS-CONTRACT

5.1.3.2 Etapele Normalizarii

Problema Normalizarii Structurilor de Date a aparut odata cu sporirea atentiei acordata construirii Structurilor de Date ca punct de pornire în Prelucrarea Datelor. Tinta propusa era de Optimizare a Structurilor de Date pornind de la urmatoarea formulare generala:

o Maximum de Control în Gestiunea Datelor, garantat de Maxima Independenta a Elementelor Componente

o Respectarea Fidelitatii Semantice a Datelor fata de Informatiile din Spatiul Utilizatorului

Cu alte cuvinte se urmarea realizarea dezideratului:

“ Informatia potrivita în Structura de Date potrivita “

Proiectantii Structurilor de Date s-au confruntat însa destul de repede cu cele doua forme ale Dilemei Proiectarii:

o ”Nici asa nu-i bine, nici asa nu-i bine” – forma aparent mai grava, dar de preferat pentru ca te mentine în Starea de Cautare

o ”Si asa pare bine, si asa pare bine” – forma mult mai pernicioasa în absenta unui Instrument de Masura

Istoria evolutiei formelor de normalizare a structurilor de date ofera un bun exemplu pentru rezolvarea acestei dileme.

Optimizarea Structurilor de Date 391

Preocuparilor legate de Normalizarea Structurilor Relationale sunt initiate de cercetarile fondatorului Modelului Relational, Codd. Lui i se datoreaza definirea primelor trei forme de normalizare si participarea directa la sinteza efectuata prin forma a patra de normalizare, fundamentata în colaborare cu cercetatorul Boyce de unde si denumirea formei a patra de normalizare Boyce / Codd Normal Form (BCNF).

Redam în continuare evolutia analizei Formelor de Normalizare a Relatiilor. Aceasta prezentare permite, în afara informarii istorice legate de perfectionarea formelor de normalizare si o buna întelegere a modului în care Bazele de Date au devenit din ce în ce mai preocupate de încorporarea de Semantica în descrierea Structurilor de Date.

5.1.3.2.1 Relatii Normale de Grad 1

Prima treapta de normalizare face deosebirea dintre Relatiile Normalizate si Nenormalizate, luând în considerare una din conditiile impuse de Codd Modelului Relational si anume:

“Fiecare atribut al unei relatii provenit dintr-un domeniu definit anterior sa fie reprezentat de valori nedecompozabile, deci de valori de tip Scalar si nu de tip Multime “

Aceasta conditie mentine Elementaritatea de Descriere a Datelor de Baza , impunând totodata restrictia ca orice data de tip Multime sa faca obiectul unei definiri exprese prin declararea separata a Multimii, a Elementului , precum si a Relatiei dintre acestea.

Ca urmare s-a ajuns la prima treapta de normalizare conform definitiei de mai jos.

Definitie:

Relatie Normala de Grad 1 – o relatie e în forma RN1 daca toate atributele refera domenii nedecompozabile

Observatii:

o Modelul Relational pretinde aceasta minima forma de normalizare pentru toate Relatiile din Structura

o Relatiile B, P, C respecta fiecare aceasta Conditie Minima 5.1.3.2.2 Relatii Normale de Grad 2

Sa luam acum în considerare o Structura de Date frecventa în prelucrarile clasice, aparuta înca în fazele incipiente ale SBD si având urmatoarele caracteristici principale:

o Orientarea prelucrarii catre Obiective Partiale

o Urmarirea unor Criterii Locale de Performanta

o Complexitate redusa a Structurii de Date

o Rezolvarea procedurarala (în Programele de Aplicatii) a tuturor problemelor de Consistenta a Datelor

Fie structura descrisa de Relatia de mai jos:

392 Optimizarea Structurilor de Date

RELATION BC (Beneficiar, Oras, Tip, Produs, Cantitate) KEY (Beneficiar, Produs)

Sa mai consideram modificarea semanticii atributului descriptor Tip Societate:

o Din: SRL, SA, RA etc.

o In: Urbana si Rurala

Diagrama Dependentelor Functionale prezentata în exemplul initial se va modifica în consecinta, prin aparitia unei determinari între atributele Oras si Tip, asa dupa cum se evidentiaza în diagrama din Fig. 5.1.3.2.2.1.

Fig. 5.1.3.2.2.1 Dependentele Functionale între atributele Oras si Tip

Diagrama Dependentelor Functionale pentru relatia BC va arata astfel (Fig. 5.1.3.2.2.2):

Fig. 5.1.3.2.2.2 Dependentele Functionale în cadrul relatiei BC

Observatii:

o Atributele Oras si Tip nu sunt Complet Dependente de Cheia Primara (Beneficiar, Produs)

o Atributele descriptoare Oras si Tip nu sunt Reciproc Independente

Oras → Tip

Dificultati de Actualizare în relatia BC la:

o Adaugare – datele pentru o instanta B1 a unui BENEFICIAR nu pot fi adaugate decât la aparitia unui CONTRACT pentru un PRODUS Px, deoarece lipseste Cheia Primara compusa (Beneficiar, Produs) care sa permita adaugarea unei tuple în relatia BC

o Stergere – stergerea din relatia BC a datelor care descriu toate pozitiile contractate de un BENEFICIAR B1 provoaca disparitia si a datelor care descriu instanta B1 a entitatii BENEFICIAR

Cantitate

Produs

Beneficiar

Tip

Oras

Oras Tip

Optimizarea Structurilor de Date 393

o Modificare – redondanta datelor în relatia BC poate cauza inconsistenta datelor la o modificare incompleta a instantelor repetate aceiasi Valori de Atribut (ex. modificarea incompleta a valorilor atributului Oras din O1 în O2 , pentru toate instantele B1 ale atributului Beneficiar din relatia BC determina o incertitudine legata de sediul real al societatii B1 - Orasul O1 sau O2)

Solutie de Remediere: Descompunerea relatiei BC prin proiectie, în doua relatii BO si C.

RELATION BO (Cod, Oras, Tip) KEY (Cod)

RELATION C (Beneficiar, Produs, Cantitate) KEY (Beneficiar, Produs)

Diagrama Dependentelor Functionale pentru relatiile BC si C va arata ca în Fig. 5.1.3.2.2.3 .

Fig. 5.1.3.2.2.3 Dependentele Functionale în cadrul relatiilor BO si C

Observatii:

o Eliminarea Dependentei Incomplete a atributelor Oras si Tip de Cheia Primara (Beneficiar, Produs)

o In plan semantic în relatia BC descriptorii Oras si Tip nu descriau relatia contractuala (deci CONTRACTUL), ci BENEFICIARUL

o O relatie RN1 care nu e RN2 trebuie sa aiba o cheie primara compusa

o Transformarea relatiei RN1 într-o relatie RN2 se face prin descompunerea relatiei initiale folosind operatia de Proiectie

o Transformarea e reversibila prin aplicarea operatiei de Reunire (JOIN)

o Transformarea relatiei RN1 într-o relatie RN2 se face fara pierdere de informatie

o Relatia CONTRACT e deja în forma RN4

Definitie: Relatie Normala de Grad 2 – o relatie e în forma RN2 daca e în forma RN1 si toate atributele descriptoare (care nu participa în Cheia Primara) sunt complet dependente de unicul identificator (Cheia Primara)

Cod

Tip

Oras

Cantitate

Produs

Beneficiar

394 Optimizarea Structurilor de Date

5.1.3.2.3 Relatii Normale de Grad 3

Observatii:

o In relatia BO se mentine însa Neindependenta Atributelor Descriptoare Oras si Tip

o Ca urmare, Dificultatile de Actualizare continua sa existe în relatia BO

Dificultati de Actualizare în relatia BO la:

o Adaugare – nu se poate adauga informatia de legatura (Dependenta Functionala) între atributele Oras si Tip decât la aparitia în relatia BO a unei instante Bx a entitatii BENEFICIAR si aceasta întrucât lipseste reprezentarea separata a informatiei elementare:

“ Oras 1 are Tip 1 “

fiind prezenta doar informatia compusa:

“ Beneficiar 1 are Oras 1 are Tip 1 “

o Stergere – stergerea din relatia BO a datelor care descriu toate instantele BENEFICIARILOR având sediul în orasul O1 provoaca disparitia si a informatiei elementare:

“ Oras 1 are Tip 1 “

o Modificare – redondanta datelor în relatia BO, cauzata de aparitia repetata a informatiei elementare:

“ Oras x are Tip y “

poate cauza inconsistenta datelor la o modificare incompleta a instantelor repetate ale acestei informatii (ex. modificarea incompleta a cuplului (Oras 1, Tip 1) în (Oras 1, Tip 2) determina o incertitudine legata de Tipul real al societatii (T1 sau T2) implicat de un anume Oras - O1 de resedinta al acesteia)

Solutie de remediere: Descompunerea relatiei BO prin proiectie în doua relatii O si B.

RELATION O (Oras, Tip) KEY (Oras)

RELATION B (Cod, Oras) KEY (Cod)

Diagrama dependentelor functionale pentru relatiile BC si C va arata ca în Fig. . 5.1.3.2.2.4.

Fig. 5.1.3.2.2.4 Dependentele Functionale în cadrul relatiilor B si O

Cod Oras Tip Oras

Optimizarea Structurilor de Date 395

Observatii:

o Eliminarea Dependentei între atributele descriptoare Oras si Tip

o Ca urmare, eliminarea Dependentei Tranzitive:

Cod → Oras → Tip

o In plan semantic simplificarea consta în:

§ Descrierea initiala explicita a informatiilor elementare:

“ Beneficiar Bx are Oras Oy “

“ Oras Oy are Tip Tz “

§ Deducerea informatiei compuse:

“ Beneficiar Bx are Oras Oy are Tip Tz “

din informatiile elementare anterioare, care pot fi actualizate independent

o Transformarea relatiei RN2 într-o relatie RN3 se face prin descompunerea relatiei initiale folosind operatia de Proiectie

o Transformarea e reversibila prin aplicarea operatiei de Reunire (JOIN)

o Transformarea relatiei RN2 într-o relatie RN3 se face fara pierdere de informatie

o Relatiile B si O ajung si ele în forma RN4

o Eliminarea Dificultatilor de Actualizare ale relatiei BO

Definitie:

Relatie Normala de Grad 3 – o relatie e în forma RN3 daca e în forma RN2 si toate atributele descriptoare (care nu participa în Cheia Primara) sunt netranzitiv dependente de unicul identificator (Cheia Primara)

5.1.3.2.4 Descompunerea Relatiilor

Parcurgând primele trei etape de îmbunatatire a structurilor relationale al retinut faptul ca principalul proces de simplificare a acestora consta în Descompunerea Relatiilor . Ce se întâmpla însa atunci când aceasta descompunere nu este unica ? Care varianta o alegem ? Suntem direct în fata Dilemei Proiectantului. Fie structura din relatia BO, ale carei Dependente Functionale sunt cele din Fig. 5.1.3.2.2.5.

Observatii:

o Dependente Directe apar reprezentate prin sageti continue si reprezinta:

§ Dependenta:

Cod → Oras

care contine informatia:

396 Optimizarea Structurilor de Date

“ Beneficiar Bx are Oras Oy “

§ Dependenta :

Oras → Tip

care contine informatia:

“ Oras Oy are Tip Tz “

o Dependenta Indirecta (Tranzitiva) apare reprezentata prin sageata punctata

§ Dependenta:

Cod → Tip

care contine informatia:

“ Beneficiar Bx are Tip Tz “

RELATION BO (Cod, Oras, Tip) KEY (Cod)

Fig . 5.1.3.2.2.5 Dependentele Functionale în cadrul relatiei BO

Solutia aleasa în pasul trei de normalizare nu este unica. Exista în total trei variante de descompunere. Cum pot acestea sa fie evaluate?

Exista doua criterii de evaluare a descompunerilor:

o Fidelitatea

§ Se masoara prin Gradul de Conservare a Continutului de Informatii al relatiei initiale

§ Parametrii de Evaluare sunt:

• Dependentele Conservate – se verifica Dependentele continute în relatiile derivate

§ Recomandare – descompunerea sa urmareasca doar Dependentele Directe care contin informatia primara

o Independenta Relatiilor

§ Se masoara prin posibilitatea de Actualizare Independenta a relatiilor derivate prin descompunere

Cod

Tip

Oras

Optimizarea Structurilor de Date 397

§ Parametrii de Evaluare sunt:

• Restrictiile între Relatii la actualizare – se verifica daca actualizarea unei relatii implica consultarea continutului altor relatii cu care intra în legatura)

• Atomicitatea Relatiilor – se verifica daca o relatie mai poate sa fie descompusa prin proiectie

§ Recomandari:

• Asigurarea Identitatii fiecarei relatii derivate prin nerepetarea aceluiasi Identificator (Cheie Candidata)

• Asigurarea Referentialitatii între relatiile derivate prin prezenta Cheilor Straine asociate cu noii Identificatori (Chei Candidate) prezenti în aceste relatii

Varianta I-a:

RELATION BT (Cod, Tip) KEY (Cod)

RELATION O (Oras, Tip) KEY (Oras)

Observatii:

o Descompunere Eronata

§ Se pierde informatie prin disparitia dependentei:

Cod → Oras

si implicit a informatiei:

“ Beneficiar Bx are Oras Oy “

§ Erori de Descompunere:

• Lipseste referirea relatiei O, având cheia primara Oras, de catre relatia BT

Varianta a II-a:

RELATION B (Cod, Oras) KEY (Cod)

RELATION BT (Cod, Tip) KEY (Cod)

Observatii:

o Descompunere Partial Corecta

§ Se mentine dependenta relatiilor B si BT în procesul de actualizare, datorata înlocuirii informatiei primare:

“ Oras Oy are Tip Tz “

cu informatia primara:

398 Optimizarea Structurilor de Date

“ Beneficiar Bx are Oras Oy “

plus informatia derivata:

“ Beneficiar Bx are Tip Tz “

(actualizarea Orasului unui Beneficiar în relatia B trebuie sa urmareasca prezenta Tipului de Oras în relatia BT)

§ Erori de Descompunere

• Lipseste identificarea unica a relatiilor (exista doua relatii, B si BT, cu aceeasi Cheie Primara, Cod)

Varianta a III-a:

RELATION B (Cod, Oras) KEY (Cod)

RELATION O (Oras, Tip) KEY (Oras)

Observatii:

o Descompunere Corecta

§ Se Conserva Semantica relatiei initiale prin retinerea informatiilor primare continute în dependentele directe:

Cod → Oras

cu informatia:

“ Beneficiar Bx are Oras Oy “

si

Oras → Tip

cu informatia:

“ Oras Oy are Tip Tz “

§ Se mentine Independenta Relatiilor B si BT în procesul de actualizare (actualizarea Orasului unui Beneficiar în relatia B verifica prezenta Orasului si implicit a Tipului de Oras în relatia O, prin referirea directa Cheie Straina – Cheie Primara , respectiv:

B.Oras → O.Oras

o Recomandari Respectate

§ S-au preluat doar Dependentele Directe

§ Fiecare relatie are o Cheie Primara proprie

§ Exista prezenta Legatura prin Referire între relatii

Optimizarea Structurilor de Date 399

5.1.3.2.5 Relatii Normale BCNF

Observatii:

o Formele de normalizare RN1 si RN2 ramân forme primare de normalizare care pastreaza doar o valoare istorica pentru prezentarea:

§ Obiectivelor normalizarii legate de eliminarea Dificultatilor de Actualizare

§ Procesului de îmbunatatire a structurilor prin cresterea Independentei Relatiilor în urma descompunerii lor cu asigurarea Pastrarii Continutului în Informatii

o Sinteza normalizarii structurilor relationale are la baza cercetarile efectuate de numerosi specialisti între care Codd, Heath, Boyce, Kent etc.

o Aceasta sinteza a survenit prin elaborarea unei definitii concentrate a primelor trei forme de normalizare pornind numai de la notiunea de Determinant

o In aceasta sinteza a fost inclusa si o îmbunatatire a definitiei normalizarii pentru a cuprinde si cazurile implicate de:

§ Relatii cu Chei Candidate Multiple Disjuncte (Nesuprapuse)

§ Relatii cu Chei Candidate Multiple Nedisjuncte (Suprapuse)

Definitie:

Determinant – multime de atribute fata de care alte atribute sunt functional dependente (complet sau incomplet)

Definitie:

Relatie normala BCNF – o relatie e în forma BCNF daca orice Determinant este Cheie Candidata

Observatii:

o Definitiile relatiilor RN2, RN3 sunt continute în definitia BCNF

o Definitia relatiilor RN3 apare mai putin cuprinzatoare în comparatie cu definitia BCNF (vezi Tab. 5.1.3.2.5.2.2)

5.1.3.2.5.1 Relatii cu Chei Candidate Multiple Disjuncte

Sa modificam descrierea relatiei anterioare BO prin:

o Adaugarea atributului Nume cu semantica de Denumire a Societatii Comerciale

o Considerarea denumirii ca fiind unica pentru fiecare societate (acest atribut va putea juca deci functia de Identificator fiind considerat în structura de date ca si Cheie Candidata)

400 Optimizarea Structurilor de Date

o Revenirea la semnificatia initiala a Tipului de Societate (SRL, SA, RA, etc.), atributul devenind astfel Independent de Descriptorul Oras

Ajungem la schema de relatii:

RELATION BN (Cod, Nume, Oras, Tip) KEY (Cod) Candidate (Nume)

Diagrama Dependentelor Functionale se va modifica în consecinta prin aparitia unor noi Dependente Functionale fata de noul atribut identificator (Cheia Candidata) Nume (Fig. 5.1.3.2.5.1.1).

Fig. 5.1.3.2.5.1.1 Dependentele Functionale în cadrul relatiei BN

5.1.3.2.5.2 Relatii cu Chei Candidate Multiple Nedisjuncte

Sa modificam descrierea relatiei anterioare BC prin:

o Adaugarea atributului Nume cu semantica descrisa anterior

o Evitarea utilizarii atributelor Oras si Tip din motive de simplificare a descrierii

Ajungem la schema de relatii:

RELATION BNC (Beneficiar, Nume, Produs, Cantitate) KEY (Beneficiar, Produs)

CANDIDATE (Beneficiar, Nume)

Diagrama Dependentelor Functionale se va modifica în consecinta prin aparitia unor noi Dependente Functionale fata de noul Atribut Identificator Compus, care joaca rolul de Cheie Candidata (Beneficiar, Nume) si care în acest caz partajeaza cu Cheia Primara unul din Constituenti si anume atributul Produs.

In Tab. 5.1.3.2.5.2.1 se face o comparatie a modului de evaluare a Gradului de Normalizare a relatiilor analizate pâna în prezent, utilizând definitiile Formelor Normale RN3 si BCNF.

Observatii:

o definitia BCNF e mai completa decât definitia NF3 întrucât:

§ Relatia BNC e normalizata conform NF3 si nenormalizata conform BCNF

Cod Oras

Nume Tip

Optimizarea Structurilor de Date 401

§ Definitia NF3 neglijeaza dependentele între atributele participante la Identificare

§ Definitia BCNF ia în considerare toti Determinantii dintr-o relatie

§ Relatia BNC implica toate Dificultatile de Actualizare

Fig. 5.1.3.2.5.2.1 Dependentele Functionale în cadrul relatiei BNC

o Definitia BCNF e conceptual mai simpla decât definitia NF3 întrucât:

§ Definitia BCNF apeleaza doar la conceptul de:

• Determinant

§ Definitia NF3 apeleaza la conceptele de:

• Cheie Primara

• Dependenta Completa

• Dependenta Tranzitiva

o Declararea Cheilor Candidate într-o relatie permite usor separarea Determinantilor Viciosi (Determinantii care nu sunt Chei Candidate), informând pe proiectant asupra nerealizarii Gradului necesar de Independenta în structurarea datelor (în general asupra prezentei Subentitatilor în cadrul unei Relatii)

Relatia Normala de tip BCNF sintetizeaza Gradul de Independenta la care aspira Dependentele Functionale în cadrul Structurilor Relationale. Câstigul cel mai important este cel de definire a conceptului de Determinant, concept care este cuprins si în abordarea Formala a Normalizarii Relatiilor (vezi sectiunea 5.1.2).

Restul Formelor de Normalizare ramân doar de importanta istorica în încercarea de a Optimiza Structurile de Date de tip Relational. Noi gasim însa o utilitate în plus în acest demers, întrucât aflam aici foarte bine subliniate obiectivele urmarite pe calea ridicarii Calitatii Structurilor de Date si anume cele de Asigurare a Maximei Independente Elementelor de Structura.

Beneficiar

Cantitate

Nume

Produs

Optimizarea Structurilor de Date 402

Forma de normalizare Relatia Chei candidate Determinanti Dependente functionale RN3 BCNF

Beneficiar → Oras Beneficiar Beneficiar → Tip

Oras Oras → Tip

BC

(Beneficiar, Produs)

(Beneficiar, Produs) (Beneficiar, Produs) → Cantitate

nu

nu

Cod Cod → Oras BO Cod Oras Oras → Tip

nu nu

C (Beneficiar, Produs) (Beneficiar, Produs) (Beneficiar, Produs) → Cantitate da da B Cod Cod Cod → Oras da da O Oras Oras Oras → Tip da da

Cod → Oras Cod → Tip

Cod Cod

Cod → Nume Nume → Oras Nume → Tip

BN

Nume Nume

Nume → Cod

da

da

(Beneficiar, Produs) → Cantitate (Beneficiar, Produs) (Beneficiar, Produs) → Nume

(Beneficiar, Produs)

Beneficiar Beneficiar → Nume (Nume, Produs) → Cantitate (Nume, Produs)

(Nume, Produs) → Beneficiar

BNC

(Beneficiar, Nume)

Nume Nume → Beneficiar

da

nu

Tab. 5.1.3.2.5.2.2 Compararea definitiilor RN3 si BCNF

Optimizarea Structurilor de Date 403

5.1.3.2.6 Relatii Normale de Grad 4

Sa consideram relatia:

RELATION CPM (Curs, Profesor, Manual) KEY (Curs, Profesor, Manual)

care descrie setul de Cursuri tinute de un Profesor folosind un anume set de Manuale.

Fie extensiunea relatiei la un moment dat cea din Tab. 5.1.3.2.6.1.

Curs Profesor Manual C1 P1 M1 C1 P1 M2 C1 P2 M1 C1 P2 M2 C2 P3 M3 C2 P3 M4

Tab. 5.1.3.2.6.1 Dependente Multivalorice

Observatii:

- Intre atributele relatiei nu exista nici-un fel de Dependenta Functionala

- Se remarca însa prezenta unei noi forme de dependenta numita Dependenta Multivalorica si care e sugestiv reprezentata în Tab. 5.1.3.2.6.2, prin gruparea valorilor Scalare în Multimi ; reprezentarea tabelara nu corespunde de data aceasta unei Relatii întrucât încalca Gradul de Normalizare RN1, tabela fiind aici utilizata doar pentru evidentierea Dependentelor Multivalorice ca forma generalizata de reprezentare a Dependentelor Functionale

Curs Profesor Manual C1 P1,P2 M1,M2 C2 P3 M3,M4

Tab. 5.1.3.2.6.2 Reprezentarea conventionala sugestiva a Dependentelor Multivalorice

- Semantica Dependentelor Multivalorice este urmatoarea:

§ Un Curs e predat de o multime de Profesori (mereu aceiasi)

§ Un Curs e predat dupa un set de Manuale (mereu aceleasi)

- care în exprimare conditionala ia forma:

∃ (Cx, P1, M1), (Cx, P2, M2) ⇒ ∃ (Cx, P2, M1) , (Cx, P1, M2)

- Dependentele Multivalorice se reprezinta astfel:

Curs →→ Profesor

Curs →→ Manual

404 Optimizarea Structurilor de Date

- Deoarece potrivit proprietatii de complementaritate a Dependentelor Multivalorice (vezi sectiunea 5.1.2.3.1):

Curs →→ Manual ⇒ Curs →→ Profesor

reprezentarea anterioara poate fi simplificata astfel:

Curs →→ Profesor Manual

Diagrama Dependentelor Functionale pentru relatia CPM va arata ca în Fig. 5.1.3.2.6.3.

Fig . 5.1.3.2.6.3 Dependentele Functionale în cadrul relatiei CPM

Dificultati de actualizare în relatia CPM la:

- Adaugare – la adaugarea unei tuple pentru un nou Profesor care preda un anume Curs trebuie adaugate toate tuplele pentru Manualele dupa care se preda acel Curs

- Stergere – la stergerea unei tuple pentru un Profesor care a predat un anume Curs trebuie sterse toate tuplele pentru Manualele dupa care se preda acel Curs

- Modificare – la modificarea unei tuple pentru un Profesor care preda un anume Curs trebuie modificate toate tuplele pentru Manualele dupa care se preda acel Curs

Solutie de remediere: Descompunerea relatiei CPM prin proiectie în doua relatii poate fi facuta în doua moduri:

o în CP si CM

o în CP si PM – mai avantajoasa datorita Gradului Marit de Independenta

RELATION CP (Curs, Profesor) KEY (Curs, Profesor)

RELATION PM (Profesor, Manual) KEY (Profesor, Manual)

Diagrama Dependentelor Functionale pentru relatiile CP si PM va arata astfel:

Fig . 5.1.3.2.6..4 Dependentele Functionale în cadrul relatiilor CP si PM

Curs

Manual

Profesor

Curs Manual Profesor Profesor

Optimizarea Structurilor de Date 405

Definitie:

Relatie Normala de Grad 4 – o relatie e în forma RN4 când include o dependenta multivalorica fata de un Determinant si toate celelalte atribute sunt functional dependente de acel Determinant, care e Cheie Candidata

Observatii:

o Dependenta Multivalorica generalizeaza Dependenta Functionala , aceasta putând fi privita ca un caz particulara în care multimile atasate unui Determinant au cardinalitate unitara

o Prezenta unei Dependente Multivalorice Netriviale este un motiv necesar si suficient pentru a descompune relatia în componente

o O relatie continând doar Dependente Multivalorice Triviale este considerata Atomica

5.1.3.2.7 Relatii Normale de Grad 5 (PJNF)

Exista relatii ce nu pot fi descompuse prin proiectie fara pierdere de informatii în doua alte relatii derivate, dar pot fi astfel descompuse în trei relatii.

Fie relatia SPT cu descrierea intensionala:

RELATION SPT (Student, Profesor, Proiect) KEY (Student, Profesor, Proiect)

si care are descrierea extensionala la un moment dat, cea din tabelul de mai jos:

Student Profesor Proiect S1 P1 T2 S1 P2 T1 S2 P1 T1 S1 P1 T1

Fig . 5.1.3.2.7.1 Extensiunea relatiei SPT

Sa urmarim extensional rezultatul urmatoarelor operatii relationale de descompunere si recompunere efectuate pornind de la relatia initiala SPT:

Prima descompunere:

o Descompunerea relatiei initiale se face în aceasta varianta prin proiectie în doua relatii derivate si încercarea de recompunere a primei relatii prin reunire (cuplare) a relatiilor rezultat. Folosind operatorii din algebra relationala secventa de operatii este redata în mod concentrat de expresia de mai jos:

SPT ′ = πSP ( SPT) ρP πPT ( SPT)

Pentru extensia propusa transformarile efectuate sunt redate în Fig. 5.1.3.2.7.2 .

406 Optimizarea Structurilor de Date

Fig. 5.1.3.2.7.2 Descompunerea si recompunerea relatiei SPT în varianta I-a

Concluzie:

o Operatia se face cu alterarea continutului în informatii al relatiei initiale, provocat de aparitia tuplei intruse (s2,p1,t1) inexistenta în extensiunea relatiei de pornire. Ca urmare:

SPT ′ ≠ SPT

A doua descompunere:

o Descompunerea relatiei initiale se face în aceasta varianta prin proiectie în trei relatii derivate si încercarea de recompunere a primei relatii prin doua reuniri succesive ale relatiilor rezultat. Folosind operatorii din algebra relationala secventa de operatii este redata în mod concentrat de expresia de mai jos:

SPT ′ ′ = πSP ( SPT) ρP πPT ( SPT) ρT S πPT ( SPT)

Pentru extensia propusa transformarile efectuate sunt redate în Fig. 5.1.3.2.7.3.

SPT Student Profesor Proiect

S1 P1 T 2 S1 P2 T 1 S2 P1 T 1 S1 P1 T 1

SP Student Profesor

S1 P1 S1 P2 S2 P1

PT Profesor Proiect

P1 T2 P2 T1 P1 T1

SPT ′ Student Profesor Proiect

S1 P1 T2 S1 P1 T1 S1 P2 T1 S2 P1 T2 S2 P1 T1

SP = π SP ( SPT) PT=π PT ( SPT)

SPT ′ = SP ρP PT

Tupla intrusa

Optimizarea Structurilor de Date 407

Fig. 5.1.3.2.7.3 Descompunerea si recompunerea relatiei SPT în varianta a II-a

Concluzie:

o Operatia se face de aceasta data fara alterarea continutului în informatii al relatiei initiale, prin eliminarea în cadrul ultimei operatii de reunire a tuplei intruse (s2,p1,t1). Eliminarea a fost posibila datorita participarii si a celei de a treia relatii derivate în care era continuta informatia pierduta în prima varianta de descompunere. Ca urmare:

SPT ′ ′ = SPT

SPT ′′ = SPT ′ ρ TS TS

SPT ′ = SP ρ P PT

TS=π TS ( SPT) SP = π SP ( SPT)

PT=π PT ( SPT)

SPT Student Profesor Proiect

S1 P1 T 2 S1 P2 T 1 S2 P1 T 1 S1 P1 T 1

SP Student Profesor

S1 P1 S1 P2 S2 P1

PT Profesor Proiect

P1 T 2 P2 T 1 P1 T 1

SPT ′ Student Profesor Proiect

S1 P1 T 2 S1 P1 T 1 S1 P2 T 1 S2 P1 T2 S1 P1 T 1

TS Proiect Student

T 2 S1 T 1 S1 T 1 S2

SPT ′′ = SPT Student Profesor Proiect

S1 P1 T 2 S1 P2 T 1 S2 P1 T 1 S1 P1 T 1

Tupla intrusa

408 Optimizarea Structurilor de Date

Pentru a lega prezentarea precedenta de o situatie reala sa aprofundam semantica continuta în informatiile din Tabela de Baza SPT. Tabela de Baza descrie o Relatie de Legatura (SPT) între trei clase de entitati (S, P, T), legatura care reprezinta activitatile de colaborare între PROFESORI si STUDENTI în realizarea unor Proiecte. Descrierea intensionala a Relatii de Legatura în Spatiul de Informatii este atunci:

“ Studentul S realizeaza sub îndrumarea Profesorului P Proiectul T “

la care se adauga un set de Restrictii:

- Daca 1 Student Sx lucreaza la 2 Proiecte Ty si Tz

atunci ele sunt conduse de acelasi Profesor Pu

- Daca 1 Student Sx lucreaza cu 2 Profesori Py si Pz

atunci ei conduc acelasi Proiect Tu

- Daca 1 Profesor Px conduce 2 Studenti Sy si Sz

atunci el lucreaza cu amândoi la acelasi Proiect Tu

Aceste restrictii pot fi rescrise formal astfel:

- Prin referire la relatia SPT:

(S1,P1,Tz), (Sx, P1,T1), (S1,Py,T1) ∈ R (S,P,T) ⇒ S(S1, P1,T1) ∈ R (S,P,T)

- Prin referire la relatiile SP, PT, TS si SPT:

(S1,P1) ∈ R (S,P) and (P1,T1) ∈ R (P,T) and (T1,S1) ∈ R (T,S) ⇒

(S1, P1,T1) ∈ R (S,P,T)

Aceasta formulare ilustreaza particularitatea Structurii Relationale care se cere analizata sub aspectul Gradului ei de Normalizare.

Dificultati de actualizare în relatia SPT la:

o Adaugare – daca la extensia care verifica restrictiile semantice impuse:

Student Profesor Proiect S1 P1 T2 S1 P2 T1

§ Se adauga tupla (S2,P1,T1), atunci trebuie adaugata si tupla (S1,P1,T1), pentru a respecta restrictiile semantice impuse (reciproca nu se mentine adevarata)

o Stergere – daca din extensia care verifica restrictiile semantice impuse:

Student Profesor Proiect S1 P1 T2 S1 P2 T1 S2 P1 T1 S1 P1 T1

Optimizarea Structurilor de Date 409

§ Se sterge tupla (S1,P1,T1), atunci trebuie stearsa si una din tuplele (S1,P1,T2), (S1,P2,T1), (S2,P1,T1), pentru a respecta restrictiile semantice impuse

§ Se sterge tupla (S2,P1,T1), actualizarea nu trebuie completata cu alte operatii

o Modificare – modificarea, privita ca o succesiune de operatii de Adaugare si de Stergere, aduce aceleasi probleme impuse de restrictiile de prezenta a datelor în relatia SPT

Exemplul precedent a aratat ca exista structuri care pierd informatie prin descompunere partiala (în 2 relatii), neputând reface astfel relatia initiala. O asemenea proprietate interna a relatiilor a fost definita ca Dependenta Operationala sau mai concret Dependenta de Reunire.

Se zice ca R (Ω ) satisface Dependenta de Reunire, în notatie:

DR* (X, Y, …, V)

daca poate fi refacuta prin reunire din proiectiile ei pe X, Y, …, V, care sunt submultimi ale multimii atributelor de definitie a relatiei R. Sau în expresie formala:

∃ DR*R (X, Y, …, V)

daca:

(π X R) ρ (π Y R) ρ … ρ (π Y R) = R (Ω )

cu:

X, Y, …, V ⊂ Ω

Conditia formala de evaluare a Gradului de Normalizare PJNF este dat în definitia de mai jos.

Definitie:

Relatie Normala PJNF – o relatie e în forma PJNF daca toate Dependentele de Reunire sunt implicate de Chei Candidate, caz în care descompunerea nu aduce nici-un avantaj, fiecare proiectie continând o Cheie Candidata

Exemple:

Fie relatia SPT:

RELATION SPT (Student, Profesor, Proiect) KEY (Student, Profesor, Proiect)

DR*SPT ((Profesor*,Student*), (Student*,Proiect*),(Proiect*,Student*))

o Proiectiile posibile sunt implicate de submultimi ale singurei chei candidate SPT si anume SP, PT, TS si nu de Cheia Candidata însasi. Ca urmare SPT nu e în Forma Normala PJNF (NF5).

o Posibilitatile de descompunere în continuare ale relatiilor derivate SP, PT, TS sunt excluse, datorita semanticii atasate relatiilor si care se refera la restrictii impuse cuplurilor de atribute care formeaza Cheile Candidate ale relatiilor

410 Optimizarea Structurilor de Date

derivate. Se spune ca orice descompunere ar fi implicata de Chei Candidate. Relatiile SP, PT, TS sunt în forma PJNF (NF5).

Fie relatia B:

RELATION B (Cod, Nume, Tip, Oras) KEY (Cod) CANDIDATE (Nume)

Varianta I-a de descompunere:

DR*B ((Cod*,Nume,Tip), (Cod*,Oras))

Varianta a II-a de descompunere:

DR*B ((Cod*,Nume) (Cod*,Tip), (Nume*,Oras))

o Proiectiile posibile sunt implicate în ambele variante de descompunere de Chei Candidate si anume Cod sau Nume. Ca urmare B e în forma PJNF (NF5) potrivit variantelor de descompunere propuse.

o Afirmatia din definitie însa se refera la toate Dependentele de Reunire DR. Determinarea acestora necesita o procedura complicata a carei fundamentare teoretica este înca în discutie. Cercetatorul Fagin propune un algoritm pentru a determina daca o Dependenta de Reunire DR e implicata de Cheile Candidate ale unei relatii R.

Observatii:

o Dependentele Operationale (de Reunire) DR generalizeaza Dependentele Multivalorice DM, care introduc si ele Restrictii de Actualizare a relatiilor si acestea generalizeaza la rândul lor Dependentele Functionale DF, singurele care se trateaza doar Structural folosind conceptele de Determinant si Cheie Candidata

o Pentru acest motiv Dependentele Operationale (de Reunire) DR sunt considerate ca forma cea mai înalta de Dependenta între Atributele unei Relatii

Pentru alti operatori exista si alte Forme de Dependenta. 5.1.3.2.8 Concluzii

o Normalizarea urmareste Optimizarea Structurilor de Date din punct de vedere al Calitatii Structurii

o Scopul Normalizarii este asigurarea Fidelitatii maxime a Modelului de Date fata de realitatea din Spatiul de Informatii

o Limbajele formale de Manipulare Relationala a Datelor (LMD) nu pretind decât minima Conditie de Calitate a Structurilor Relationale de Date si anume Forma Normala FN1

o Forma Normala RN4 reprezinta în procesul de proiectare o Disciplina de Modelare care asigura Preluarea Maxima de Semantica

Optimizarea Structurilor de Date 411

5.1.4 Abordarea Semantica a Normalizarii Relatiilor

Abordarea Informala a Optimizarii Structurilor Relationale ofera raspunsuri la câteva probleme importante de Proiectare a Structurilor de Informatii si de Date. Noutatea pe care o aduce aceasta abordare consta în instrumentele pe care le pune la dispozitie Teoria Informatiei în comparatie si în completarea celor oferite de Formalismul Dependentelor în cadrul Multimilor si al Relatiilor.

Demersul care urmeaza porneste de la afirmatia prezentata în cadrul concluziilor finale ale sectiunii de abordare istorica:

“ Normalizarea trebuie privita ca o Disciplina de Modelare care asigura Preluarea Maxima de Semantica. “

Întrebari:

1 Care sunt, pentru activitatea de proiectare, rezultatele finale ale analizei Dependentelor existente în structuri?

2 De ce Instrumentele de Optimizare Formala a Structurilor nu sunt prezente în produsele de Inginerie a Programarii Asistata de Calculator (Computer-Aided Software Engineering – CASE)?

3 Care este rolul pe care Analiza si Sinteza Formala a Dependentelor îl joaca în Proiectarea Structurilor?

4 Exista o metoda riguroasa de Proiectare Informala a Structurilor Optime?

Raspunsuri:

1 Problema Optimizarii Structurilor de Informatii si Date a venit sa aprofundeze conceptul initial promovat înca de la aparitia Sistemelor cu Baze de Date si anume Independenta Elementelor în cadrul Structurilor ca principal Indicator de Calitate al sistemelor complexe.

Exista numeroase forme de realizare a Independentei Structurale, majoritatea promovate de viziunea Sistemelor cu Baze de Date. Dintre acestea enumeram:

§ Independenta între Nivelele de Reprezentare a Datelor (Intern, Conceptual, Extern)

§ Independenta între Date si Proceduri

• Accesul la date prin Vederi

• Transferul Restrictiilor în Baza de Date

• Transferul Procedurilor Stocate în Baza de Date

§ Independenta între Datele Reale prin Virtualizarea Datelor Dependente cu ajutorul Expresiilor Functionale

§ Independenta Reprezentarii Datelor fata de Suportul de Memorare prin utilizarea Referirii Asociative în locul Referirii prin Adresa

412 Optimizarea Structurilor de Date

§ Independenta între Relatii ca si Constructori de Baza în Modelul Relational prin:

• Implementarea cu ajutorul Tabelei de Baza atât a Claselor de Entitati, cât si a Relatiilor de Legatura între Clasele de Entitati

• Referirea Relatiilor prin Migrarea Cheilor

§ Independenta Relatiilor între Domenii (Tabelele de Baza) fata de Relatiile de Ordine (Indecsii)

§ Independenta între Tuple ca Elemente de Multimi Neordonate Identificabile

§ Independenta între Atribute continute în Tabele de Baza asigurata de Normalizarea Relatiilor

Coborârea discutiei legata de Independenta Structurilor la nivelul Atributelor apartine preocuparilor determinate de Normalizarea Relatiilor prin Optimizarea Dependentelor existente în interiorul unei Relatii.

Studiul Formal al Dependentelor în Structurile de Date a condus la fundamentarea teoretica a necesitatii de a asigura si la acest nivel Independenta Maxima între elementele care compun structura. Au fost elaborati numerosi algoritmi de analiza si sinteza, care au evoluat însa rapid spre dificultati din ce în ce mai mari, sfârsind prin a oferi solutii prea complicate pentru probleme ce ar fi aflat solutii mai simple si mai robuste prin schimbarea doar a punctului de vedere.

Aceasta noua viziune îsi are originea tocmai în ceea ce consideram a fi câstigul principal al preocuparilor de Normalizare si anume necesitatea coborârii Independentei la nivelul Atributelor.

2 Raspunsul la a doua întrebare vine în continuarea precedentului raspuns si are la baza urmatoarele observatii:

§ Problema Normalizarii apare cronologic în momentul în care se cereau îmbunatatite Structurile Clasice Nenormalizate de Date, destinate unor prelucrari partiale de informatii; de aici si preferinta pentru procesul de Descompunere prin Proiectie a unor Colectii Existente de Date pe care se bazeaza Normalizarea Structurilor.

§ Construirea unei Baze de Date porneste însa în conditiile actuale cu definirea unui Model de Date, activitate care implica:

• Construirea Structurilor Elementare

• Agregarea Structurilor Elementare în Structuri Complexe

• Definirea Restrictiilor Atasate

• Adaugarea Procedurilor Stocate pentru actualizari si prelucrari

Aceste observatii marcheaza o modificare esentiala intervenita în realizarea Structurilor Corecte de Date, nu prin perfectionarea unor Structuri Initiale Defectuoase, ci prin conceperea unor Constructii Bine Fundamentate. Ramâne în acest caz numai de stabilit daca exista o metoda de proiectare suficient de riguroasa pentru a realiza asemenea Proiecte de Structuri de Date.

Optimizarea Structurilor de Date 413

3 Câstigul cel mai mare al Tratarii Analitice a Dependentelor în cadrul Structurilor de Date consta în oferirea unui Instrument Fundamentat Teoretic pentru formarea “Gândirii Semantice” corecte a Proiectantului de Structuri si pentru confirmarea stadiului atins prin Evaluare Cantitativa a Structurilor. Aptitudinea de Proiectare nu trebuie sa implice bunul simt, talentul si arta, ci cunostinte legate de Construirea Structurilor de Informatii si Date. Transformate în abilitati si deprinderi, consemnate apoi în proceduri ce pot fi automatizate, ele vor sta la baza Proceselor Industriale de Proiectare a Structurilor. Aceste cunostinte se refera la:

§ Determinarea Claselor de Entitati prin aprecierea functiilor pe care ele le joaca în Spatiul Informatiilor

§ Alegerea corecta a rolului de Entitate sau Caracteristica pentru fiecare element

§ Apartenenta corecta a Atributelor la Entitati

§ Aprecierea corecta a Legaturilor dintre Entitati, cu evidentierea Nivelelor Ierarhice de Agregare a Structurii

§ Mentinerea unui Grad Maxim de Independenta a Elementelor de Structura

4 Îndraznim sa afirmam, ca raspuns la cea de a patra întrebare, ca exista o Cale Riguroasa de Concepere Informala a structurilor, sub forma unei Metode de Proiectare si nu a unei succesiuni de Algoritmi de Optimizare. Metoda propusa contine referiri la conceptele prezentate anterior si care se cer doar aplicate cazurilor concrete ivite în practica.

5.1.4.1 Abordarea Sistemica a Proiectarii

In Abordarea Sistemica a unui proiect sunt recunoscute trei metode de construire a proiectului vazut de la bun început ca un întreg (un Sistem):

§ Metoda Top-Down (de Sus în Jos)

§ Metoda Bottom-Up (de Jos în Sus)

§ Metoda Mixta (alternarea celor doua metode de baza)

Ce înseamna aceste metode când e vorba despre Proiectarea Structurilor de Informatii si de Date?

In primul rând Întregul trebuie sa fie reprezentat de o succesiune de Nivele subordonate între ele si care permit gruparea informatiilor sau datelor de la formele elementare la cele compuse, care conduc la forma finala dorita de utilizator. Ca urmare Ierarhia de Structuri va fi constituita din urmatoarele categorii de nivele:

o Nivelele superioare - Structurile Finale (Nenormalizate) – Nivele de Utilizator (deservesc necesitatile de informare ale Utilizatorului.)

o Nivelele intermediare – Structurile Intermediare (Nenormalizate) – Nivele Mixte (de Utilizator si / sau de Sistem)

414 Optimizarea Structurilor de Date

o Nivelele inferioare - Structurile de Baza (Normalizate) – nivele Conceptuale (descriu Rezerva de Informatii a Sistemului)

In orice Proiectare de Structuri de Informatii sau Date se porneste de la construirea unei Rezerve Minime de Concepte, cele care descriu Domeniul Problemei (Spatiul de Informatii).

Pe baza conceptelor definite anterior se încearca în faza a doua construirea prin Agregare a Vederilor diverse care corespund:

- Cerintelor particulare ale unui Utilizator

- Necesitatii definirii unor Nivele Intermediare (de sistem) pe care se vor construi alte Vederi (de sistem sau de utilizator)

Trebuie retinut caracterul de agregare al Structurilor de tip Vedere care conduce la structuri nenormalizate, ce satisfac cerinte particulare care însa nu altereaza structura mereu normalizata a nivelelor inferioare (frunzele Ierarhiei de Structuri).

In final se verifica daca pe ultimul Nivel al Ierarhiei se regasesc toate informatiile cerute de toti utilizatorii. daca nu sunt respectate toate cerintele se coboara pe structura si se încearca la fiecare nivel îmbogatirea continutului de informatii, putându-se ajunge pâna la Nivele Inferioare unde se adauga noi Concepte. Acest proces este repetat si pentru cazul interventiei unor completari sau modificari de Cerinte sau de Acceptii Semantice legate de informatiile în discutie.

Se poate afirma ca Metoda de Proiectare Sistemica a Structurilor de Informatii si de Date care se propune este cea Mixta, în care se începe cu parcurgerea BOTTOM-UP a structurii. Vom da în continuare un set sugestiv de exemple.

Exemplul 1: Sa analizam Spatiul de Informatii în care se desfasoara discutia de Normalizare a Structurilor în primele trei forme RN2, RN3 si BCNF. Se remarca usor prezenta Claselor de Entitati si Relatiilor de Legatura prezentate în exemplul descris în sectiunea precedenta. Noutatea apare atunci când modificam semantica atributului Tip din:

Tipul Societatii Comerciale – (SA, SRL, RA)

în:

Tipul Localitatii de Sediu – (urban, rural)

care se transfera apoi asupra Tipului de Societate Comerciala. In aceste noi conditii se impunea recunoasterea unei noi Clase de Entitati ORASUL (mai bine zis LOCALITATEA):

- Cu Atribute Proprii – Numele, Tipul si Codul (ca identificator concentrat)

- Cu Legaturi Proprii – (1-n) sau (m-n) cu Entitatea BENEFICIAR, dar si eventual cu entitatea PRODUS (descriind sediul Stocurilor de Produse)

Procesul de constructie a Structurii de Date în Viziune Sistemica este reprezentat în Fig. 5.1.4.1.1.

Optimizarea Structurilor de Date 415

Legenda B – BENEFICIAR BO – vedere BENEFICIAR-ORAS P – PRODUS BN – vedere BENEFICIAR-NUME C – CONTRACT BT – vedere BENEFICIAR-TIP L – LOCALITATE BNC – vedere BENEFICIAR-NUME- FB – FILIALA BENEFICIAR -CONTRACT SD – STOC-DEPOZIT BC – vedere BENEFICIAR-CONTRCT

c - cod r - culoare t - tip tb – tip societate lb – oras beneficiar n - nume g - greutate q - cantitate tl – tip localitate lp – oras produs a – adresa b - cod beneficiar p - cod produs l – localitate

Fig. 5.1.4.1.1 Arborele de Structura proiectat BOTTOM-UP pentru structura BNC

tl n

l

*b

*

p*

b

*

p* a n

p*

b

*

l

*

b

*

* p

* b

b *

* c

n n

l

*

* c

tb n

n

*

SD FB

C

BO

t n

B

c *

q n

g n

r n

P

n n

t n

L

b

*

BN

BC

BNC

q n

q n

a n

q n

Nivel 1

Nivel 2

Nivel 5

Nivel 4

Nivel 3

Nivel 6

Nivel 7

BT

tb n

tb n

tl n

*n

l*

lb*

lp*

*n

416 Optimizarea Structurilor de Date

Observatii:

o Se remarca construirea pe Nivele a Structurii de Date

§ Nivelele Inferioare (1, 2) reprezinta Structura Elementara (de Baza)

• Constructiile sunt simple întrucât descriu Structuri Elementare, Localitate L, Beneficiar B, Produs P

• Componentele Structurilor Elementare sunt Unic Identificabile (prin Chei Candidate)

• Atributele sunt Unic Definite, fiind atasate Entitatilor de Profunzime (Conceptelor Primare) de care apartin semantic

• Dependenta Unica a Atributelor de Cheile Candidate e usor de respectat prin interpretarea informatiei pe care o poarta:

“ Beneficiar are Tip Societate”

“ Localitate are Tip Localitate”

§ Nivelele Inferioare (3, 4) sunt construite prin agregarea informatiei de pe primele doua nivele folosind Relatiile de Legatura FB si SD

• Constructiile Agrega Informatiile din Structurile Elementare

• Agregarea se efectueaza doar prin Referire Relationala

• Fiecarui Nivel de Agregare i se ataseaza Atributele Specifice Aportului Informational care le este atasat semantic, cu respectarea Prioritatilor de intrare a Informatiilor în Structura (întâi definirea conceptului de Sediu pentru Beneficiar si Produs, apoi doar definirea Contractului diferentiat pe Sedii de Beneficiari si Produse):

o Pentru Nivelul 3 Aportul Informational este:

“ Beneficiarul are Filiala are Sediu în Localitate”

“ Produsul are Stoc are Sediu în Localitate”

o Pentru Nivelul 4 Aportul Informational este:

“ Contractul are Beneficiar este Filiala are Sediu în Localitate”

“ Contractul are Produs este în Stoc are Sediu în Localitate”

“ Contractul are Cantitate”

§ Restul Nivelelor (5, 6, 7) sunt Nivele Derivate construite cu ajutorul Vederilor (Date Virtuale), pe baza Rezervei de Informatii de pe Nivele Inferioare stocata în Tabelele de Baza

• Nivelul Intermediar (5) contine Rezultate de Prelucrare

Optimizarea Structurilor de Date 417

o Reprezinta Date de Centralizare (prin însumarea Cantitatilor pe Beneficiari si Produse, indiferent de Localitatile de Sediu)

o Deserveste exclusiv necesitati de consultare si nu de actualizare

o Întâmplator Structura e Normalizata (dar contine Date Calculate)

o Consistenta e asigurata prin Materializarea Datelor Virtuale

§ Nivelele Superioare (6,7) sunt destinate Viziunilor particulare ale diversilor Utilizatori

• Reprezinta Date Finale extrase din Baza de Date

• Poate deservi necesitati de consultare si de actualizare restrictionata

• Structurile apar Denormalizate, dar aceasta calitate nu intereseaza pe proiectant pe acest Nivel

• Consistenta e asigurata, în ciuda denormalizarii, prin aceeasi Materializare a Datelor Virtuale

o Se remarca usurinta cu care Semantica Structurii de Date a putut fi îmbogatita prin:

§ Adaugarea ambelor acceptii pentru atributul Tip (Tipul Societatii si Tipul Localitatii)

§ Adaugarea Sediului atât pentru BENEFICIAR cât si pentru PRODUS

§ Acceptarea Sediilor multiple pentru acelasi BENEFICIAR si pentru acelasi PRODUS

o Rezolvarea fireasca a Dependentelor Artificiale din Structuri

§ Dependenta Tranzitiva prin Referirea Relationala a Entitatilor, evident distincte, BENEFICIAR si LOCALITATE

§ Dependentele Incomplete prin transferul lor în Structurile Finale Nenormalizate (vederile BN si BNC)

Exemplul 2: Sa analizam Spatiul de Informatii în care se desfasoara discutia de normalizare a structurilor care includ Dependente Multivalorice, în speta structura CPM. Se poate retine recomandarea ca Informatiile ce descriu o Dependenta Multivalorica sa faca obiectul unei descrieri separate, prin Entitati Dedicate acestui scop. Actiunea asigura un Control riguros al tuturor Restrictiilor pe care le implica aceste Dependente, indiferent de Gradul de Normalizare al Structurii în care ele apar. Se realizeaza astfel o Maxima Independenta între Restrictiile atasate Dependentelor Multivalorice si Structurile de Date în care ele sunt angajate si prin aceasta o gestiune continua a Multimii Valorilor din cadrul Dependentelor, care are o Extensiune variabila în timp .

418 Optimizarea Structurilor de Date

O asemenea viziune aduce totodata posibilitatea unei rafinari semantice în domeniul Definirii Intensionale a Multimii care descrie Dependente Multivalorice. Spre exemplu, Dependentele între Curs, Profesor si Manual pot fi Independent descrise ca Restrictii Structurale ce pot evolua între diferite forme:

Forma 1 – Cursurile se predau doar dupa Manuale desemnate: In intensiune:

CM (Curs*, Manual*)

Relatia contine Dependenta Multivalorica Triviala (vezi sectiunea 5.1.2.3.1):

Curs →→ Manual

Un Curs se preda dupa Manuale desemnate

In extensiune: CM

Curs Manual C1 M1 C1 M2 C2 M3 C2 M4

Tab. 5.1.4.1.2 Extensiunea Structurii CM – Forma 1

Se remarca prezenta Dependentelor Multivalorice initiale:

C1 →→ M1, M2

C2 →→ M3, M4

Forma 2 - Cursurile se predau doar dupa Manuale proprii: In intensiune:

CPM (Curs*, Profesor*, Manual*)

Relatia contine Dependenta Multivalorica Triviala:

Curs, Profesor →→ Manual

Un Curs se preda de un Profesor dupa Manualele proprii

In extensiune: CPM

Curs Profesor Manual C1 P1 M5 C1 P1 M6 C1 P2 M7 C1 P2 M8

Tab. 5.1.4.1.3 Extensiunea Structurii CPM – Forma 2

Optimizarea Structurilor de Date 419

Se remarca aparitia Dependentelor Multivalorice de un Determinant Compus:

C1, P1 →→ M5, M6

C1, P2 →→ M7, M8

Forma 3 - Cursurile se predau dupa Manuale impuse si dupa Manuale proprii: In intensiune:

CPM (Curs*, Profesor*, Manual*)

Relatia contine Dependentele Multivalorice Triviale:

Curs →→ Manual

si

Curs, Profesor →→ Manual

Un Curs se preda de un Profesor dupa Manualele desemnate,

la care se adauga Manualele proprii

In extensiune:

Curs Profesor Manual C1 P1 M1 C1 P1 M2 C1 P1 M5 C1 P1 M6 C1 P2 M1 C1 P2 M2 C1 P2 M7 C1 P2 M8 C2 P3 M3 C2 P3 M4

Tab. 5.1.4.1.2 Extensiunea Structurii CPM – Forma 3

Se remarca mentinerea Dependentelor Multivalorice initiale restrânse:

C1 →→ M1, M2

C2 →→ M3, M4

la care se adauga:

C1, P1 →→ M5, M6

C1, P2 →→ M7, M8

In acest caz Restrictiile vor fi compuse din doua categorii de Conditii: Generale si Particulare, fiecare putându-se modifica prin simple adaugari de Tuple în Relatiile de Legatura CM si / sau CPM1.

420 Optimizarea Structurilor de Date

Legenda C – CURSURI CP – PROFESORI / CURSURI P – PROFESORI PM – MANUALE / PROFESORI M – MANUALE CM – MANUALE / CURSURI

c – Cod n – Nume

t – Titlu f – Fel

r – Cuprins

CPM ′ = (c,p,m) (c,p) ∈ CP and (c,m) ∈ CM CPM ′ ′ = (c,p,m) (c,p) ∈ CP and (c,p,m) ∈ CPM 1

CPM = CPM ′ ∪ CPM ′ ′

Fig. 5.1.4.1.2 Arborele de structura proiectat BOTTOM-UP pentru structura CPM

c*

c

* p* p*

c

*

m

*

m

*

p*

c

*

m

*

p

* m* m* c* c*

p

*

n n

n n c*

c* c*

CPM ′

CP

t n

P

r n

M

n n

f n

C Nivel 1

Nivel 2

Nivel 4

CPM 1

CM

CPM ′ ′

CPM Nivel 5

Nivel 3

Optimizarea Structurilor de Date 421

Combinarea extensiunilor din forma 1 si 3 apar de asemenea posibile. In mod evident aceste Restrictii vor trebui completate cu Proceduri Stocate de Actualizare adecvate, care însa nu vor complica nejustificat descrierea Structurala, lasând-o în forma ei fireasca, de simpla descriere a Restrictiilor. Abordarea sistemica ilustreaza Adaptabilitatea Semantica a unei structuri initial Bine Construita. Procesul de constructie a structurii CPM în viziune sistemica este reprezentat în Fig. 5.1.4.1.2.

Observatii:

o Reapare construirea pe Nivele a Structurii de Date

§ Nivelul Inferior (1) reprezinta Structura Elementara (de Baza)

• Nivelul descrie Tabelele atasate Claselor de Entitati Curs C, Profesor P si Manual M

• Constructiile sunt necesare pentru crearea cadrului dezvoltarii unor Structuri Reale, care sa deserveasca scopuri practice diverse

• Nivelul asigura Relatiile de tip Entitate pe care se vor cladi Relatiile de Legatura de pe celelalte Nivele

§ Nivelul Inferior (2) este construit prin agregarea informatiilor de pe primul Nivel

• Nivelul descrie Tabelele atasate Relatiilor de Legatura

• Constructiile sunt necesare întrucât pe aceste Nivele se definesc Dependentele Multivalorice ca si Clase de Entitati distincte (Relatiile de Legatura CP si CM reprezinta si ele la rândul lor Clase de Entitati)

• Necesitatea definirii acestor structuri este sugerata si de formularea Restrictiilor impuse de Dependentele Multivalorice

Curs →→ Profesor

Curs →→ Manual

Semantica atasata acestor Relatii ce descriu Restrictiile de Actualizare a fost comentata anterior. Ceea ce însa trebuie retinut este conlucrarea dintre Date si Proceduri (ambele elemente ale Modelului de Date) în implementarea acestor Restrictii

§ Nivelul Inferior (3) este construit tot prin agregarea informatiei de pe primul nivel

• Nivelul descrie Tabela de Baza CPM 1, atasata Relatiei de Legatura permite rafinarea semanticii Dependentei Multivalorice initiale; pentru a-si mentine Complet Independenta ea se va lega tot de Primul Nivel. Va fi astfel adaugata Informatia suplimentara continuta în categoria de Restrictii:

Curs, Profesor →→ Manual

422 Optimizarea Structurilor de Date

Un Curs se preda de un Profesor dupa Manualele proprii

§ Nivelul Intermediar (4) este construit prin materializarea informatiei de pe primele trei Nivele

• Nivelul descrie doua vederi care pregatesc continuarea rafinarii semantice a Dependentei Multivalorice:

o Vederea CPM ′ definita:

CPM ′ = (c,p,m) (c,p) ∈ CP and (c,m) ∈ CM

descrie Semantica:

Curs →→ Profesor

Curs →→ Manual

Un Curs se preda de un Profesor desemnat dupa Manualele desemnate

o Vederea CPM ′ ′ definita: CPM ′ ′ = (c,p,m) (c,p) ∈ CP and (c,p,m) ∈ CPM 1

descrie Semantica:

Curs →→ Profesor

Curs, Profesor →→ Manual

Un Curs se preda de un Profesor desemnat dupa Manualele proprii,

§ Nivelul Superior (5) permite regasirea structurii ce se cerea optimizata

• Nivelul descrie Semantica mixta prin expresia cu care se genereaza prin materializare:

CPM = CPM ′ ∪ CPM ′ ′

Un Curs se preda de un Profesor desemnat dupa Manualele desemnate,

la care se adauga Manualele

o Important de retinut este din nou modul firesc în care apare rezolvata în abordarea informala, problema eliminarii Dependentelor Artificiale din Structura (fara apel la conceptele din definitia RN4):

§ In structura CPM 1

• Structura

o Atribute – c, p, m

o Cheie primara c,p,m

• Dependente Functionale

Optimizarea Structurilor de Date 423

Curs →→ Profesor

Curs →→ Manual

• Structura Normalizata

§ In structura CPM

• Structura

o Atribute – c, p, m

o Cheie Primara c, p, m

• Dependente Functionale, datorate reunirii a 2 structuri intermediare

Curs →→ Profesor

Curs →→ Manual

Curs, Profesor →→ Manual

• Structura Denormalizata (Consistenta rezolvata prin Materializarea Datelor)

Exemplul 3 Solutia informala pentru cazul Dependentelor Operationale (în speta pentru structura SPT) se prezinta în doua variante de rezolvare. Se poate retine ca orice Dependenta Operationala implica, ca si în cazul Dependentelor Multivalorice, existenta unor Restrictii de Actualizare, care se cuvin a fi rezolvate în sectiunea destinata încorporarii firesti a acestor Conditii în Baza de Date, prin atasarea lor la structurile pe care le controleaza. Încercarea de a forta rezolvarea dificultatilor doar prin modificari de Structura , în loc de a recurge la simpla atasare a Restrictiilor aferente unor structuri, reprezinta o complicatie nerealista a problemei Optimizarii Structurilor. Asa dupa cum s-a mai aratat, este cunoscuta în Teoria Programarii definirea conceptului de Tip de Data ca un ansamblu de:

§ Structuri - ca descriind partea Statica (de Stare)

§ Operatori atasati – ca descriind partea Dinamica (de Transformare) Ramâne ca urmare a preciza acele Entitati care sunt implicate în declararea unor Restrictii, pentru a le putea descrie explicit în Structura de Baza a Modelului de Date. Este de la sine înteles orizontul care se deschide nelimitat pentru modul foarte particular de a descrie Restrictiile foarte diverse ce rezulta din nuantarea semantica a Datelor ca Structuri Abstracte si a Restrictiilor sau a Procedurilor Stocate ca forme de Transformari Abstracte [SMIT82]. Abordarea sistemica a structurii SPT ilustreaza varietatea de solutii care stau la dispozitie proiectantului daca Structurile Initiale sunt Bine Construite. Procesul de construire a structurii SPT în Viziune Sistemica este reprezentat, în cele doua variante, în Fig. 5.1.4.1.3 si Fig. 5.1.4.1.4.

424 Optimizarea Structurilor de Date

Observatii pentru varianta I-a:

o Reapare si în acest exemplu construirea pe Nivele a Structurii de Date

§ Nivelul Inferior (1) reprezinta Structura Elementara

• Aceleasi observatii ca în exemplul precedent pentru Structurile de Baza: STUDENT, PROFESOR, PROIECT

Legenda

S – STUDENTI SP – STUDENTI / PROFESORI P – PROFESORI PT – PROFESORI / PROIECTE T – PROIECTE TS – PROIECTE / STUDENTI

c - cod n - nume t - titlu a – an studiu f – fel

SPT = (s,p,t) (s,p) ∈ SP and (p,t) ∈ PT and (t,s) ∈ TS

Fig. 5.1.4.1.3 Structura SPT - Varianta I-a

Nivel 2

t*

p*

s*

t* t* p* p* s*

c* c*

Nivel 1

SP

t n

P

f n

T

n n

a n

S

Nivel 3

PT TS

c* n n

n n

s*

SPT

Optimizarea Structurilor de Date 425

• Descrierea Nivelelor Inferioare este completata cu Nivelul 2, reprezentat de acele Tabele de Baza (SP, PT, TS), care implementeaza Restrictiile încorporate în Modelul de Date, sub forma Conditiei Logice ce trebuie verificata la fiecare actualizare a Bazei de Date (vezi sectiunea 5.1.3.2.7):

((s,p) ∈ SP and (p,t) ∈ PT and (t,s) ∈ TS) ⇒ (s,p,t) ∈ SPT

In sectiunea mai sus amintita este redat si procesul de analiza a Spatiului de Informatii din care a provenit Conditia Logica sintetizata în expresia precedenta si care este descompusa în trei Conditii Interrelationale referitoare la Tabelele de Baza SP, PT, TS. Aceste Relatii sunt si cele care trebuiesc protejate la actualizare prin verificarea Conditiilor Interrelationale.

§ Restrictiile particulare sunt Restrictii de Utilizator si se adauga Restrictiilor de Integritate ale Modelului Relational (Restrictiilor de Identitate si de Referire)

§ Nivelele Intermediare lipsesc din aceasta Structura

§ Nivelele Superioare sunt reprezentate în acest caz de Nivelul 3, pe care regasim Structura Initiala Nenormalizata SPT, sub forma de Vedere, ceea ce asigura si în acest caz Consistenta Datelor, prin urmatoarele tratamente:

• Actualizarile se executa asupra Nivelelor de Baza

• Actualizarile sunt gardate si de Restrictiile de Utilizator

• Actualizarile împreuna cu Restrictiile de Utilizator se transmit Nivelului Superior prin împrospatarea Vederii (REFRESH VIEW)

o Analiza exemplului prezentat releva înca o data faptul ca solutia ce se propune porneste de la o abordare naturala a problemei conceperii unei structuri, începând cu Cerintele impuse de Realitate, cerinte ce se cer materializate într-o Structura construita de la Baza si nu cu o Structura Data ce se cere îmbunatatita.

Observatii pentru varianta a II-a:

o Reprezinta o alternativa simplificata a structurii precedente

§ Nivelul Inferior (1) se mentine acelasi ca în varianta anterioara

§ Pe Nivelul 2 apare deja Relatia Finala SPT, careia îi sunt atasate Restrictiile de Utilizator în exprimare modificata (cu referire la o singura relatie – SPT):

SPT= (s,p,t)(s1,p1,z) ∈ SPT and (x, p1, t1) ∈ SPT and (s,y, t1) ∈ SPT ⇒ (s1,p1,t1) ∈ SPT

§ Varianta a II-a însa nu reprezinta numai o alternativa, ci constituie solutia generala de construire a unei Relatii Ternare cu Restrictii si aceasta întrucât în mod obisnuit Relatiile Polinare nu pot fi descompuse în Relatii Binare Independente fara implicarea Restrictiilor Interrelationale

426 Optimizarea Structurilor de Date

§ Nivelele Superioare sunt reprezentate în acest caz de Nivelul 3, care acum joaca doar rolul de Nivel Extern pentru construirea Interfetei Utilizator – Nivel Conceptual

Legenda

S – STUDENTI SP – STUDENTI / PROFESORI P – PROFESORI PT – PROFESORI / PROIECTE T – PROIECTE TS – PROIECTE / STUDENTI

c - cod n - nume t - titlu a – an studiu f – fel

SPT = (s,p,t) (s1,p1,z) ∈ SPT and (x, p1, t1) ∈ SPT and (s,y, t1) ∈ SPT ⇒ (s1,p1,t1) ∈ SPT

Fig. 5.1.4.1.4 Structura SPT - Varianta a II-a

t* p*

t*

s*

c* n n

c* c*

n n

t n

P

f n

T

a n

S Nivel 1

Nivel 2

Nivel 3

SPT

SPT

n n

s*

p*

Optimizarea Structurilor de Date 427

5.1.4.2 Utilizarea Modelului Obiectelor Abstracte

Modelul Obiectelor Abstracte ofera o buna solutie de abordare în proiectarea Structurilor de Date „sanatoase”. Simpla respectare a Metodologiei de Proiectare propusa în sectiunea 4.1.2.10 este o garantie de evitare a alegerii unor Structuri Vicioase, care sa trebuiasca ulterior îmbunatatite. Aplicarea corecta a Proceselor de Abstractizare, împreuna cu însusirea conceptelor dezvoltate si implementate în cadrul acestui model, determina formarea aptitudinilor necesare în proiectarea si implementarea Structurile de Informatii si Date. In cele ce urmeaza vom face o scurta trecere în revista a conceptelor promovate de Modelul Obiectelor Abstracte (pentru detalii vezi sectiunea 4.1.2), instrumente de lucru care usureaza conceperea Structurilor de Date prin care se modeleaza o anume realitate:

o Toate Entitatile sunt Obiecte Abstracte

o Toate Caracteristicile (Atributele) Entitatilor sunt si ele Obiecte Abstracte

o Toate Atributele unei Entitati reprezinta Identificatori si se clasifica în:

§ Atribute Autoidentificabile (Atribute care se Autorefera) – toate Caracteristici Elementare

§ Atribute Identificatoare (Atribute care refera Entitati) – Caracteristici ce Identifica prin Referire Asociativa alte Entitati

o Orice Structura de Obiecte Abstracte contine:

§ Obiecte Abstracte Primitive – Caracteristici Elementare

§ Obiecte Abstracte Derivate (Generate) – Entitati

o Generarea de Obiecte Abstracte se poate face prin doua Procese Fundamentale de Abstractizare:

§ Agregarea – grupeaza Obiecte Abstracte într-un nou Obiect Abstract:

• Obiecte Abstracte Initiale – Obiecte în Intrare

• Obiecte Abstracte Derivate – Obiecte în Iesire

§ Generalizarea – regrupeaza prin Clasificare (procese inverse de Generalizare / Specializare) Realizarile unui Obiect Abstract pe baza valorilor unui Criteriu de Clasificare ce defineste submultimi de Obiecte Categorii în corpul unui Obiect Generic; orice clasificare implica existenta a doua Entitati:

• Entitatea Clasificata (Obiectul Generic+Obiectele Categorii)

• Entitatea care Clasifica (Obiectul Criteriu de Clasificare)

Apelul la notiunile enumerate determina obtinerea unei mari Independente în Structurile Proiectate, prin aplicarea, înca din faza de concepere, a unui Proces de Descompunere a ansamblului în Module Elementare Specializate. Se asigura de asemenea o permanenta analiza a continutului informational al fiecarei componente de structura, precum si a raporturilor dintre acestea. Ceea ce sporeste credibilitatea în utilitatea arsenalului oferit de Modelul Obiectelor Abstracte este posibilitatea implementarii lui directe în Modelul Relational utilizat curent în Bazele de Date.

428 Optimizarea Structurilor de Date

5.1.4.2.1 Implementarea Relationala a Modelului Obiectelor Abstracte

Modelul Obiectelor Abstracte prin conceptele promovate se preteaza pentru o Implementare Relationala (vezi sectiunile 4.2.4.7.3 si 4.2.4.8).

Folosind metoda de Clasificare a Relatiilor dupa Tip (Entitate, Legatura si Mixte) se poate ajunge la Formalisme de Implementare Automata a Structurilor de Baza care apar în viziunea conceptuala a Modelului Obiectelor Abstracte. Referindu-ne la procesele fundamentale rememoram în Tab. 5.1.4.2.1.1 corespondentele între Structura de Informatii (Modelul Obiectelor Abstracte) si Structura de Date (Modelul Relational).

Nivel conceptual Nivel de implementare Obiecte Abstracte Initiale Relatie de tip OARECARE AGREGARE Obiecte Abstracte Derivate Relatie de tip MIXT sau de tip

LEGATURA (Simpla sau Completa) Entitatea Clasificata Relatie de tip OARECARE GENERALIZAREA Entitatea care Clasifica Relatie de tip MIXT sau de tip

LEGATURA (Simpla sau Completa)

Tab. 5.1.4.2.1.1 Implementarea relationala a Modelului Obiectelor Abstracte

5.1.4.2.2 Definirea Restrictiilor

Viziunea pe care conceptul de Model de Date o are asupra alaturarii elementelor de:

- Structura declarata

- Restrictii atasate

- Operatii admise

aduce solutii simple problemelor de optimizare a structurilor. Dar ceea ce se impune nu este numai simplitatea solutiilor, ci si forma naturala de enuntare a Constrângerilor ridicate de realitatea structurilor de informatii si de implementare a acestora în structura de date prin construirea modelului de date care va sta la baza generarii nivelelor conceptuale ale diverselor Baze de Date.

Sunt vizate aici în special restrictiile de Utilizator care se adauga restrictiilor standard de asigurarea integritatii datelor. Aceste restrictii suplimentare se bucura de o mare libertate în formularea lor ceea ce permite un grad mare de adaptabilitate la realitati foarte diverse.

5.1.4.2.3 Definirea Procedurilor Stocate

Observatiile de mai sus înglobeaza si aportul sectiunii de Operatii în rezolvarea problemelor de îmbunatatire a controlului structurilor în timpul evolutiei lor în timp. Procedurile Stocate extind simpla supervizare a operatiilor de actualizare cu proceduri complexe care coreleaza procesele de adaugare, stergere si modificare a valorilor diferitelor atribute ce pot apartine la entitati diferite.

Optimizarea Structurilor de Date 429

Aceasta facilitate face posibila acceptarea, din motive de performanta, a redondantei Structurale, cu asigurarea procedurala a Consistentei datelor. Se ajunge asadar la definirea celor doua forme de asigurare a Consistentei Datelor:

- Structurala

- Procedurala 5.1.4.3 Concluzii finale

Întregul demers din sectiunea prezenta ne-a atras atentia asupra unui fapt exprimat simplu în îngrijirea sanatatii:

“ De ce sa ajungi sa Tratezi când poti simplu sa Îngrijesti ? ”

si care transpus în sfera programarii suna astfel:

“ De ce sa ajungi sa Optimizezi când poti simplu sa Proiectezi Optim ? ”

Rezultatele studiului analitic al Dependentelor în Structuri ramân de o nepretuita valoare în conceperea si realizarea constructiilor optime în domeniul Modelelor de Date si Informatii. E suficient sa amintim ca întreaga fundamentare a domeniului de Explorare a Datelor (Data Mining) se bazeaza pe descoperirea Dependentelor ce nu pot fi încorporate initial în descrierea Intensionala a Modelului întrucât depind de comportamentul Extensiunii sale variabile în timp.

A nu apela însa la întreaga paleta de instrumente pe care le ofera alaturi de Teoria Matematica, Teoria Sistemelor, Teoria Informatiei, Ingineria Programarii etc. înseamna a nu întelege complexitatea si rolul integrator pe care îl joaca în prezent domeniul Informaticii.

Am ajuns aici într-un punct important al prezentei lucrari si anume momentul în care s-a dovedit ca simpla abordare Formala a Structurii Datelor nu este suficienta pentru sisteme atât de complexe cum sunt Bazele de Date. Legatura Structurilor de Date cu Structurile de Informatii, legatura care da sens reprezentarilor din Sistemele de Calcul, evita adesea apelul la un arsenal prea sofisticat, acolo unde se cere prezenta doar a unei Idei Noi.

Foarte adesea o tratare Formala, care porneste de la structuri extrase din contextul lor real, ocolesc solutii mai directe de proiectare, simplificate prin recurgerea la o tratare Informala.

In acest sens cuprinderea în Sistemele cu Baze de Date a preocuparilor legate de descrierea Ontologica a Structurilor de Informatii si Date ni se pare o cale foarte atractiva si promitatoare pentru a fi abordata în cercetarile viitoare. Modelul Conceptual schitat poate fi înscris în aceste pregatiri.

Ramâne ca o stenica încurajare prezenta Raportului referitor la Descrierea Ontologiilor – vezi referinta [IDEF-5] , în suita de Standarde care orienteaza definirea Structurilor de Date si de Proceduri si care se afla deja, cel putin partial, încorporate în produse comerciale.

Ridicarea activitatilor de concepere, proiectare si implementare a Structurilor de Informatii si Date preia, ca urmare dezideratul impus de Optimizarea Structurilor si anume dezvoltarea procesului de Incorporare Maxima de Semantica din Spatiul Utilizatorului în Spatiul de Date.

430 Optimizarea Cererilor

5.2 Optimizarea Cererilor

Optimizarea Cererilor are drept obiectiv reducerea Timpului de Prelucrare a Cererilor, criteriu cantitativ mult simplificat în comparatie cu cel ridicat de Optimizarea Structurilor de Date. Cu toate acestea, datorita complexitatii de evaluare a variantelor de Prelucrare a Cererilor si în acest caz e recomandabil ca termenul de Optimizare sa fie înlocuit cu unul mai putin pretentios de Ameliorare.

Definitie:

Ameliorarea Cererilor consta în Refrazarea Cererilor de catre Procesorul Limbajului de Cereri în vederea reducerii timpului de compilare si executie a acestora.

5.2.1 Evaluarea Costurilor de Prelucrare a Cererilor

Pentru Ameliorarea Cererilor se fac urmatoarele remarci generale legate de elementele care intervin în calculele de evaluare a consumului de timp la Prelucrarea Cererilor. Întrucât principalul consumator de timp în Limbajul de Manipulare a Datelor Relationale e operatia de Reunire (Cuplare) sau, mai general, operatia de Produs Cartezian, durata Cererii se exprima în Numarul de Accese la Date, care asigura combinatia de Tuple din Operanzii angajati în Operatie. Sa consideram urmatoarele date care descriu un Produs Cartezian:

o Relatiile AB si CD care participa la Produsul Cartezian (Numele Relatiilor este construit prin Concatenarea Numelor de Atribute ce alcatuiesc Relatiile)

o Corespondentele Fizice cu Elementele de Gestiune atasate Relatiilor:

§ Relatie – Fisier

§ Tupla – Înregistrare

§ 1 Bloc = n Inregistari

§ 1 Tampon = 1 Bloc

§ Memoria Interna ⊂ m Tampoane

o Dimensiunile Elementelor de Gestiune Fizica angajate în Operatie:

§ Numar Tuple în Relatia AB = nAB

§ Numar Tuple în Relatia CD = nCD

§ Numar Inregistari / Bloc în Fisierul AB = bAB

§ Numar Inregistari / Bloc în Fisierul CD = bCD

§ Memoria Interna ⊂ m Blocuri

Calculul Numarului de Accese pentru realizarea Produsului Cartezian AB x CD conduce la urmatoarele expresii, în functie de situatia care poate interveni în prelucrare:

o Cazul Fisierelor Neblocate – în acest caz Numarul de Accese este dat de urmatoarea expresie:

nAB x nCD

Optimizarea Cererilor 431

o Cazul Fisierelor Blocate – fie urmatoarea Alocare de Tampoane:

m –1 pentru AB

1 pentru CD

Cu aceste date au loc urmatoarele evaluari:

• Numarul de Accese pentru citirea Fisierului AB va fi:

nAB x nCD

• Numarul de Accese pentru citirea Fisierului CD va fi:

(nCD / bCD) • ( nAB / ((m-1) • bAB))

• Numarul Total de Accese (Ta) va fi:

Ta = (nAB / bAB) • ( 1 + (nCD / ((m-1) • bCD))

o Pentru dimensiuni concrete presupuse de:

nAB = nCD = 10.000

bAB = bCD = 5

m = 100

o Rezulta un Numar Total Calculat de Accese:

Ta = 42.400

o Cu o Viteza de Citire de:

20 Blocuri / Secunda

Se ajunge la un Timp Total de Citire (Tc) de:

Tc = 35 minute

5.2.2 Reorganizarea Cererilor

In practica Operatiile ce urmeaza a fi realizate au unele particularitati ce pot fi exploatate pentru reducerea Timpului de Prelucrare a Cererilor. Sa analizam câteva cazuri: 5.2.2.1 Tratarea Produselor Carteziene

Fie Cererea urmatoare exprimata în Calculul Tuplelor (vezi sectiunea 4.2.4.5.2.2):

RANGE X of AB

RANGE Y of CD

RETRIEVE ( X. A)

WHERE X.B = Y.C and Y.D = 99

432 Optimizarea Cererilor

Cererea transpusa în Algebra Relationala ia forma:

π A ( σ (B = C) ∩ (D = 99) (AB x CD))

Exista urmatoarele solutii de reorganizare a Cererii de mai sus:

o Selectia poate migra în Produsul Cartezian:

π A ( σ (B = C) (AB x σ (D = 99) CD))

o Selectia σ (B = C) transforma Produsul Cartezian în Reunire Naturala:

π A (AB (ϕ (B = C) x σ (D = 99) CD))

o Posibilitati de simplificare a Evaluarii Formulei la Nivel Fizic:

§ Cazul fara Tabele de Index (TI)

• Se citeste CD cu:

(nCD / bCD) = 2.000 accese

• Daca rezultatul selectiei se poate pastra în memoria interna (în cele m-1 Tampoane), atunci se mai citeste AB cu:

(nAB / bAB) = 2.000 accese

• Se efectueaza un total de 4.000 accese pentru expresia:

(AB x σ (D = 99) CD)

• Se efectueaza în acelasi timp:

σ (B = C) si π A

§ Cazul cu Tabele de Index (TI)

• Tabela de Index (TID CD) reduce timpul la câteva accese de Blocuri din CD pentru calculul expresiei:

σ (D = 99) CD

• Tabela de Index (TIB AB) reduce timpul pentru Reunirea Naturala la câteva accese de Blocuri din AB pentru fiecare cautare de valoare distincta c din C pentru calculul expresiei:

AB (ϕ (B = C)

In Concluzie:

Reorganizarea Cererii a redus sub 1 / 10 Numarul de Accese.

Optimizarea Cererilor 433

5.2.2.2 Tratarea Reunirilor

Toate formele de Reunire consuma timp în acelasi mod ca si Produsele Carteziene. Solutii de remediere:

§ Indexarea Tabelelor de Baza

• Crearea de Tabele de Index adhoc (înainte de operare)

• Timpul de creare e proportional cu Cardinalitatea Relatiilor

§ Sortarea Tabelelor de Baza

• Sortarea Tabelelor de Baza dupa Atributele de Reunire

• Timpul de sortare în memoria externa e proportional cu n log n, unde n reprezinta Cardinalitatea Relatiei

Daca numarul de Valori ale Atributelor de Reunire e mic Tabelele de Index pot fi retinute în Memoria Interna si timpul devine proportional cu Cardinalitatea Relatiilor. In acest caz Indexarea e preferabila Sortarii.

5.2.3 Strategii Generale de Optimizare

Pe baza analizei costurilor implicate în Prelucrarea Cererilor pot fi recomandate urmatoarele Strategii Generale de Optimizare:

- Efectuarea Operatiilor de Selectie cât mai repede posibil pentru a reduce Cardinalitatea Operanzilor (Relatiilor)

- Preprocesarea Tabelelor în vederea pregatirii lor pentru operare prin Indexare sau Sortare. Ambele preprocesari permit localizarea Valorilor Izotipe în cei doi Operanzi.

- Retinerea Subexpresiilor Comune calculate, când Timpul de Calcul e mai mare decât Timpul de Regasire. Exemple:

§ Reuniri ce nu pot fi reduse prin Migrarea unei Relatii spre interior

§ Vederi ce apar ca operanzi si care trebuie calculate extensional si retinute în aceasta forma

- Operarea Cascadei de Selectii si Proiectii într-o singura trecere, când se refera la un singur Operand

- Combinarea Proiectiei cu o Operatie Binara ce o precede sau o succede, caz în care Proiectia nu va consuma timp de inspectie

- Combinarea Selectiilor cu un Produs Cartezian pentru a-l transforma în Reunire

§ Selectia pe R1 x R2 cu Compararea de Atribute din R1 si R2 transforma Produsul Cartezian în Reunire Naturala

§ Compararea pe Atribute doar din R1 sau din R2 face ca Selectia sa preceada Produsul Cartezian

434 Securitatea Bazelor de Date

PPAARRTTEEAA aa 66--aa

SSEECCUURRIITTAATTEEAA BBAAZZEELLOORR ddee DDAATTEE

Partea a 6-a este consacrata temei mai largi a mentinerii Securitatii Colectiilor de Date reunite în Baze de Date. Grupate în doua subiecte principale:

Protejarea Datelor contra Accesului Neautorizat Refacerea Continutului BD în caz de Accidente

Informatiile prezentate fac apel si la una din caracteristicile operationale importante ale BD si anume Prelucrarile Tranzactionale. Ca urmare Sectiunile acestei Parti sunt distribuite astfel:

6.1 – Controlul Accesului la Date – destinat analizei

Nivelelor de Protectie care se impun a fi instituite pentru asigurarea protectiei Volumelor mari de Informatii contra Acceselor Neautorizate. O gama larga de metode este trecuta în revista, ajungându-se pâna la prezentarea modului de implementare a Nivelelor de Confidentialitate în Accesul la Date din Sistemele de Aplicatii.

6.2 – Prelucrari Tranzactionale – acest grup de sectiuni

are o importanta crescuta, prin aceea ca nu adauga numai o functiune esentiala a BD, ci contribuie totodata la extinderea conceptului de Independenta promovat de SBD, în sfera Operatiilor încorporate în BD ca forme dinamice de Transformare a continutului acestora si care trebuie sa asigure trecerea permanenta dintr-o Stare Consistenta în alta Stare Consistenta..

6.3 – Refacerea Bazelor de Date – exploatând din plin calitatile Prelucrarilor Tranzactionale, Refacerea BD pune la dispozitia cititorului problematica unei functii implementate de toate SGBD-urile si care a fost aleasa si ca si caracteristica definitorie a SBD.

Optimizarea Cererilor 435

436 Securitatea Bazelor de Date / Controlul Accesului la Date

6 Securitatea Bazelor de Date

In definirea Bazelor de Date (vezi sectiunea 2.2), una din conditii era legata de:

“asigurarea Gestionarii Colectiilor Mari de Date”

având precizate ca functii garante ale Securitatii Volumelor Mari de Date:

o Controlul Accesului la Date al utilizatorilor, în special în regim de Multiacces

o Restaurarea continutului Colectiilor de Date, în stare Consistenta în caz de incident

Sectiunea de fata este consacrata prezentarii problematicii, conceptelor si solutiilor adoptate de Sistemele de Gestiune a Bazelor de Date pentru asigurarea acestor facilitati. 6.1 Controlul Accesului la Date

Controlul Accesului la Date concentreaza ansamblul masurilor luate în vederea protectiei Bazelor de Date împotriva acceselor neautorizate ale utilizatorilor în portiuni protejate ale Structurilor de Date.

6.1.1 Categorii de Informatii gestionate în Controlul Accesului la Date

Trei categorii de informatii concura la realizarea Accesului Selectiv la continutul unei Baze de Date:

o Utilizatorii de Resurse (U) – vezi Fig. 6.1.1.1

§ Administrator de Baza de Date ( ABD )

§ Grupuri de Utilizatori ( G i )

§ Subgrupuri de Utilizatori ( G i j )

§ Utilizator ( Ui )

o Resursele Oferite (Date si Proceduri) (R) – vezi Fig. 6.1.1.2

§ Aplicatii ( APL i )

§ Vederi ( V i j)

§ Relatii ( R k )

§ Atribute ( A kl )

o Drepturile Acordate (D)

§ Acordare / Revocare Drepturi (D 1) – vezi Tab. 6.1.1.3

§ Drepturi pentru Scriere Date (D 2)

§ Drepturi pentru Citire Date (D 3)

Securitatea Bazelor de Date / Controlul Accesului la Date 437

Fig. 6.1.1.1 Ierarhia de clasificare a Utilizatorilor

Un Subsistem Specializat de Control al Accesului încorporat într-un SGBD va fi însarcinat cu urmatoarele functiuni:

o Definirea / Stergerea Categoriilor de Informatii

o Acordarea / Revocarea Drepturilor

o Permiterea / Refuzul Accesului la Date

Asupra elementelor care fac obiectul functiei de Control a Accesului la Date se opereaza în prima faza o clasificare a acestora (vezi Figurile 6.1.1 si 6.1.2), care implica pe lânga gruparea lor si stabilirea unor Proprietati de Mostenire a Drepturilor Acordate la un Nivel de Ierarhie de catre Nivelele Subordonate. Trebuie subliniat faptul ca definirea Utilizatorilor (împreuna cu Conturile si Cuvintele de Trecere atasate) reprezinta o functie specifica de control a SGBD-urilor, care se adauga si completeaza pe cea existenta în Sistemele de Operare.

Fig. 6.1.1.2 Ierarhia de clasificare a Resurselor

ABD

G1 G2

G13G11

U2 U1 U3 U4

APL 1

V11 V12

R2 R1

A12 A11 A21 A22

APL 2

V21 V21

R3 R1

A12 A11 A31 A32

438 Securitatea Bazelor de Date / Controlul Accesului la Date

Utilizatori Resurse Drepturi

G1 V11 D 3

G11 R1 D 2

U1 A12 D 2

G13 - D 1

Tab. 6.1.1.3 Asocierea Utilizatori – Resurse - Drepturi

In faza a doua se definesc Drepturile de Acces la Date. Exista mai multe moduri de a defini aceste drepturi. Cele mai utilizate Drepturi sunt cele prezentate la începutul sectiunii si ele se reduc la cele doua operatii principale efectuate asupra Bazelor de Date: Citire si Scriere. Se considera în mod firesc ca privilegiul de Scriere îl implica pe cel de Citire.

In faza a treia se efectueaza o asociere de Drepturi de Acces la cuplurile Utilizatori – Resurse. Acordarea acestor Drepturi este privilegiul Administratorului Bazei de Date (ABD).

6.1.2 Controlul Drepturilor de Acces la Date cu ajutorul LMD

Pentru a se asigura totusi o elasticitate mai ridicata în Controlul Accesului de-a-lungul activitatilor foarte diverse care se efectueaza în cadrul Sistemelor cu Baze de Date (Conceptie, Proiectare, Testare, Implementare, Exploatare, Dezvoltare), Acordarea de Drepturi este cel mai adesea tratata la rândul ei ca un Drept care se poate acorda Utilizatorilor, la început de catre ABD, apoi de Utilizatorii care au câstigat acest drept, altor Utilizatori. Acest Drept este considerat ca maxim privilegiu, putându-se Acorda sau Revoca. Drepturile de Acces pot fi rafinate la nivelul diferitelor Operatii de Manipulare a Datelor (Creare Tabele, Adaugare, Stergere sau Modificare Date etc.). Comenzi specifice au fost încorporate în Limbajele de Manipulare Standardizate. Se dau mai jos câteva exemple în limbajul SQL:

- Acordarea Dreptului de Creare Tabele Grupului de Utilizatori G1

GRANT CREATETAB TO G1

sau în versiunea SQL2 de limbaj:

CREATE SCHEMA TEST AUTHORIZATION G1

- Acordarea Dreptului de Adaugare si Stergere în tabela BENEFICIAR Utilizatorului U1

GRANT INSERT, DELETE ON PRODUS TO U1

- Acordarea Dreptului de Citire în tabela CONTRACT Utilizatorului U2

GRANT SELECT ON CONTRACT TO U2

Securitatea Bazelor de Date / Controlul Accesului la Date 439

- Revocarea Dreptului de Citire în tabela CONTRACT Utilizatorului U2

REVOKE SELECT ON CONTRACT FROM U2

6.1.3 Controlul Confidentialitatii de Acces la Date

Asa dupa cum s-a mai amintit SGBD-urile implementeaza si alte forme, mai rafinate, de Control a Accesului provenite din solicitarile exprese ale unor Sisteme Informatice Speciale. In aceste cazuri se intervine în principal asupra fazei de Definire a Drepturilor si de Asociere a acestora Utilizatorilor si Resurselor (vezi Fig. 6.1.1.3).

Sa consideram un asemenea sistem special care solicita gestiunea automata a Confidentialitatii Datelor, pe baza urmatoarei clasificari a regimurilor de acces:

o Date Strict Secrete (SS)

o Date Secrete (SC)

o Date Clasificate (CL)

o Date Neclasificate (NC)

Aceasta clasificare determina si noile Drepturi Nuantate de Acces la Date, la care se poate remarca urmatoarea Ordine de Confidentialitate:

SS > SC > CL > NC

Daca se considera ca fiecare Utilizator sau Grup de Utilizatori are atasat un Drept Implicit de Acces, dat de o Confidentialitate atasata (conform Gradelor de Confidentialitate definite anterior), atunci Drepturile de Acces la Date asociate tabelar pot sa fie înlocuite prin definirea unor Reguli de Acces, dupa cum urmeaza:

o Un Utilizator poate CITI Atribute care au Gradul de Confidentialitate (GC) mai mic sau egal cu cel al Utilizatorului

GC Utilizator ≥ GC Atribut

o Un Utilizator poate SCRIE prin Poliinstantiere Tuple care au Gradul de Confidentialitate (GC) mai mare sau egal cu cel al Utilizatorului

GC Utilizator ≤ GC Tupla

Aceasta cerinta poate fi implementata în Modelul de Date al unui SGBD astfel:

- Se completeaza fiecare Tabela de Baza (Relatie) cu un numar de informatii interne (Informatii de Confidentialitate), gestionate de SGBD

• Gradul de Confidentialitate al Atributelor

• Gradul de Confidentialitate al Tuplelor Tupla Logica va arata atunci astfel:

R ( A1, GCa1, A2, GCa2, .. , An, GCan, GCt)

unde:

440 Securitatea Bazelor de Date / Controlul Accesului la Date

• Ai – Atributul i

• GCai – Gradul de Confidentialitate al Atributului Ai

• GCt – Gradul de Confidentialitate al Tuplei t

- Actualizarea Valorilor Gradelor de Confidentialitate se face astfel:

• Gradul de Confidentialitate al Atributelor se declara de catre Utilizator

• Gradul de Confidentialitate al Tuplelor se preia întotdeauna din Gradul de Confidentialitate al Utilizatorului care face actualizarea prin Vederea la care el are acces

- Se diversifica Identificatorul Relatiilor (Cheia Primara) astfel:

• Cheie Primara Aparenta – Identificatorul natural al Relatiei (Ansamblu de Atribute)

• Cheie Primara Interna – Identificatorul natural al Relatiei (Ansamblu de Atribute) + Gradele de Confidentialitate ale Atributelor din Identificator + Gradul de Confidentialitate al Tuplei

Se asigura astfel posibilitatea de Poliinstantiere a Tuplelor (Tuple ce descriu acelasi obiect cu descriptori nuantati de Gradul de Confidentialitate atasat)

- Sunt valabile urmatoarele Reguli de Integritate:

o Toate Componentele Cheii Primare Aparente trebuie sa fie nenule

o Toate Componentele Cheii Primare Aparente trebuie sa aiba un Grad de Confidentialitate mai mic sau cel mult egal cu Gradul de Confidentialitate Minim din Tupla (al tuturor Atributelor si al Tuplei)

o Toate Componentele Cheii Primare Aparente trebuie sa aiba un Grad de Confidentialitate egal în toate tuplele sinonime din cadrul Poliinstantierii

o Utilizatorul are dreptul sa rescrie numai Tuple la care are acces potrivit Gradului sau de Confidentialitate (GC t = GC Utilizator )

- Vederile Utilizatorilor se construiesc printr-o dubla filtrare:

o Se filtreaza Tuplele Relatiei care verifica conditia:

GC Utilizator ≥ GC Cheie Primara

o Se filtreaza Atributele Relatiei care verifica conditia:

GC Utilizator ≥ GC Atribut

Se asigura prin aceasta construirea Relatiilor Multinivel (Nivelul rezulta din Gradul de Confidentialitate cu care se realizeaza filtrarea). Se remarca faptul ca Gradul de Confidentialitate al Tuplei se neglijeaza la filtrare, Utilizatorul putând Deriva Vederi din Tuple cu un Grad de Confidentialitate mai mare, din care însa

Securitatea Bazelor de Date / Controlul Accesului la Date 441

nu poate vedea decât ceea ce i se permite de cel ce a creat Tupla. Utilizatorul poate modifica orice Valori de Atribute, dar le rescrie prin Poliinstantiere într-o noua Tupla cu Gradul propriu de Confidentialitate.

Vom încerca sa ilustram printr-un exemplu Modelul de Control a Datelor prin Securizare Multinivel. Fie o relatie ce descrie un ANGAJAT:

ANGAJAT ( Marca, Nume, Prenume, Salariu, Performanta) KEY Marca

Pentru încorporarea facilitatilor de Securizare a Accesului, Relatia Aparenta se completeaza cu informatiile care descriu Gradele de Confidentialitate asociate Atributelor, precum si întregii Tuple:

ANGAJAT ( Marca, GCmarca, Nume, GCnume, Prenume, GCprenume, Salariu, GCsalariu, Performanta, GCperformanta, GCtupla) KEY Marca

Am mentinut în descriere doar Cheia Primara Aparenta.

Fie Extensiunea la un moment dat a Relatiei redata în Tab. 6.1.3.1, cu marcarea si a Gradelor de Confidentialitate alese pentru fiecare Atribut si Tupla.

Marca Nume Prenume Salariu Performanta GCtupla

M1 NC N1 NC P1 NC S1 CL P1 SC SC

M2 CL N2 CL P2 CL S2 SC P2 CL SC

Tab. 6.1.3.1 Relatia Multinivel ANGAJAT - Extensia originala

Sa consideram o cerere simpla de interogare:

SELECT *

FROM ANGAJAT

adresata însa de Utilizatori cu Grade de Confidentialitate asociate diferite. Vom reprezenta Vederile derivate din relatia originala ANGAJAT pentru diferiti Utilizatori.

Utilizatorul 1 – Grad de Confidentialitate asociat CL:

Marca Nume Prenume Salariu Performanta GCtupla

M1 NC N1 NC P1 NC S1 CL null CL CL

M2 CL N2 CL P2 CL null CL P2 CL CL

Tab. 6.1.3.2 Relatia Multinivel ANGAJAT – Vederea Utilizatorului 1

442 Securitatea Bazelor de Date / Controlul Accesului la Date

Utilizatorul 2 – Grad de Confidentialitate asociat NC:

Marca Nume Prenume Salariu Performanta GCtupla

M1 NC N1 NC P1 NC null NC null NC NC

Tab. 6.1.3.3 Relatia Multinivel ANGAJAT – Vederea Utilizatorului 2

Sa consideram acum o cerere de actualizare:

UPDATE ANGAJAT

SET Performanta = ’P11’

WHERE Marca = ’M1’ Aceasta cerere va determina actualizarea tuplei prin crearea unei instante noi pentru Gradul de Confidentialitate al Utilizatorului care lanseaza cererea (vezi Tab. 5.1.4). Aceasta operatie este denumita Poliinstantiere.

Utilizatorul 4 – Grad de Confidentialitate asociat CL:

Marca Nume Prenume Salariu Performanta GCtupla

M1 NC N1 NC P1 NC S1 CL P1 SC SC

M1 NC N1 NC P1 NC S1 CL P11 CL CL

M2 CL N2 CL P2 CL S2 SC P2 CL SC

Tab. 6.1.3.4 Relatia Multinivel ANGAJAT – Extensia relatiei dupa Poliinstantiere

Se cuvine retinut din cele prezentate doar modul în care pot fi dezvoltate Metodele de Control a Accesului la Date. Regulile prezentate anterior sunt specifice Spatiului de Informatii care se cere modelat si care pot diferi de la un caz la altul. Este de asemenea important faptul ca un Model de Date care sa realizeze un Control Specializat de Acces la Date poate fi desigur implementat si la nivelul Sistemului de Aplicatii si nu al Sistemului de Gestiune al Bazei de Date. Implementarea în SGBD se justifica doar pentru comenzi speciale, cu o arie de aplicabilitate foarte larga sau cu un grad ridicat de interes.

Nu putem încheia sectiunea consacrata asigurarii Securitatii Datelor fara a mentiona si facilitatile de Încriptare a Datelor, care sunt încorporate în unele SGBD-uri. Functia mentionata asigura protectia Accesului de Date la Nivelul Intern (Fizic) al Bazelor de Date. Acest gen de securizare este utilizat pentru protectia:

o Transmiterii Datelor Confidentiale

o Stocarii Datelor Confidentiale

Securitatea Bazelor de Date / Prelucrari Tranzactionale 443

6.2 Prelucrari Tranzactionale

Definind Structuri de Date din ce în ce mai complexe, Bazele de Date au ajuns sa-si puna tot mai frecvent problema definirii si mentinerii Consistentei Datelor care sunt gestionate (vezi sectiunea 4.2.1.1.2). In acest sens, conditiile interne, definite la Nivel Logic, se cer urmarite, la Nivel Fizic, pe tot parcursul actualizarii Structurii de Date. S-a ajuns astfel la necesitatea utilizarii în cadrul Limbajelor de Manipulare a Datelor doar a Secventelor de Operatii, care mentin Consistenta Bazei de Date prin asigurarea trecerii ei dintr-o Stare Consistenta în alta Stare Consistenta. O asemenea Secventa de Operatii poarta numele de Tranzactie. Cu toate ca problema Prelucrarii Tranzactionale vizeaza în special multiaccesul la date, ea poate fi întâlnita si în cazul accesului unui singur utilizator la date. In general necesitatea tratarii Secventelor de Operatii ca un tot unitar, cu efect ”Totul sau Nimic”, se bazeaza pe posibilitatea întreruperii unei asemenea secvente printr-o interventie neprevazuta, care poate fi accidentala (întrerupere de functionare cu pierderea continutului Memoriei Interne) sau necontrolata (interventia altor Operatii din alte Tranzactii ce concureaza pentru aceleasi Resurse). Aceste interventii pot determina ca Starea Consistenta Initiala sa nu ajunga în Starea Consistenta Finala.

Notatii: UCk – Unitatea de Calcul k Tij – Secventa j din Tranzactia i

Fig. 6.2.1 Executia intermitenta si întretesuta a Tranzactiilor

In Fig. 6.2.1 sunt prezentate câteva cazuri de executie a Tranzactiilor. Înainte de analiza fiecarui caz în parte se cer facute urmatoarele precizari:

- Tranzactiile pot fi executate pe Sisteme de Calcul Uniprocesor (Cazurile 1, 2 si 3) sau Multiprocesor (Cazul 4)

- Fiecare Procesor (Unitate Centrala UC) executa serial Operatiile Tranzactiilor, repartizând fiecarei Tranzactii sarcini în cuante programate de timp . Aceasta conduce la o Executie Intermitenta si Întretesuta a Tranzactiilor Active

UC 1

UC 2

UC

Timp

T11 T12

T11 UC

UC T11 T21 T12 T22

T11

T21

Cazul 1

Cazul 2

Cazul 3

Cazul 4

T12

444 Securitatea Bazelor de Date / Prelucrari Tranzactionale

- Unitatea Centrala executa si alte operatii apartinând altor procese care trebuie executate (module ale Sistemului de Operare, alte Programe etc.); de aici provin si pauzele între prelucrari succesive ale Tranzactiilor, timp în care, desi nu are loc concurenta pentru Resursele Tranzactiilor, se pot produce multe evenimente cu efect de Întrerupere Necontrolata a Prelucrarii Tranzactiilor aflate în diferite Stari (vezi Fig. 6.2.3.1)

Cazurile din Fig. 6.2.1 pun în evidenta urmatoarele situatii speciale în gestiunea Tranzactiilor: Cazul 1:

Prezinta o Tranzactie T1 divizata în doua secvente de procesare T11 si T12 , care se termina normal, dar care releva intervalele de timp în care pot apare evenimente accidentale.

Cazul 2:

Prezinta o întrerupere accidentala aparuta în secventa de procesare T11 si care necesita masuri speciale, care sa asigure în final mentinerea Consistentei Datelor. Asemenea masuri sunt necesare si daca întreruperea survine în pauza dintre secventele de procesare T11 si T12 , caci Tranzactia T1 nu e înca terminata.

Cazul 3:

Prezinta doua Tranzactii T1 si T2, divizate fiecare în câte doua secvente de procesare T11, T12 si T21, T22, care se prelucreaza toate serial, din cauza prezentei unui singur procesor (UC). Desi prelucrarea se termina normal, în acest caz pot apare probleme daca Tranzactiile partajeaza aceleasi Resurse de Date si daca accesul la date nu este corect controlat (vezi sectiunea 6.2.1).

Cazul 4:

Prezinta doua Tranzactii T1 si T2, divizate fiecare în câte doua secvente de procesare T11, T12 si T21, T22, care se prelucreaza în paralel din cauza prezentei a doua procesoare (UC1 si UC2). Datorita concurentei marite în accesul la Resurse se impun în acest caz conditii speciale de Control al Tranzactiilor.

6.2.1 Erori în Tranzactii Necontrolate

Vom urmari câteva exemple în care Tranzactiile Necontrolate pot altera accesul la Baza de Date. Aceste situatii nedorite sunt întotdeauna concentrate în jurul operatiilor de Citire / Scriere din, respectiv în Baza de Date. In Fig. 6.2.1.1 absenta sincronizarii între operatiile de Citire si Scriere ale celor doua Tranzactii fac ca datele cu care se opereaza sa fie alterate (Dirty Data). Alterarea se produce prin Rescrierea datei de catre tranzactia T1, data care a fost deja citita de tranzactia T2. In cel de al doilea caz (vezi Fig. 6.2.1.2), întrucât tranzactia T2 citeste înainte de încheierea tranzactiei T1, ea risca, în situatia de esuare a primei tranzactii, sa ramâna cu o valoare citita eronata. Esuarea primei tranzactii poate fi datorata, chiar în absenta situatiilor neprevazute, unor conditii impuse de logica de programare a acestei tranzactii si care sunt în general legate de necesitatea consultarii Starii unor Resurse necesare. Datorita faptului ca tranzactia T2 a apucat deja sa scrie în Baza de Date, are loc si o pierdere de informatie (data X scrisa de T2), prin tentativa tranzactiei T1 de a reface Starea Initiala a Bazei de Date.

Securitatea Bazelor de Date / Prelucrari Tranzactionale 445

Fig. 6.2.1.1 Pierderea de actualizari prin Rescriere

Fig. 6.2.1.2 Desincronizare prin citire de Valori Temporare (Intermediare)

In cel de al treilea caz, reprezentat în diagrama din Fig. 6.2.1.3, Baza de Date nu este alterata, deoarece numai prima tranzactie T1 scrie, dar datele centralizate de tranzactia T2 sunt eronate, întrucât T1 rescrie elementul Z pe care T2 a apucat deja sa-l centralizeze în variabila S.

Tranzactia T1

Tranzactia T2

CITIRE element X

X=X+N

CITIRE element X

X=X+M

SCRIERE element XCITIRE element Y

SCRIERE element X

Y=Y+N SCRIERE element Y

Elementul X are valoare eronata Actualizarea din T1 e pierduta

fiind rescrisa de T2

Timp

Tranzactia T1

Tranzactia T2

CITIRE element X X=X+N

SCRIERE element X

CITIRE element X X=X+M

SCRIERE element X

CITIRE element Y

Tranzactie esuata

Se reface vechea valoare X

Elementul X are valoare eronata T1 a refacut pe X la valoarea initiala

la sfârsitul tranzactiei

Timp

446 Securitatea Bazelor de Date / Prelucrari Tranzactionale

Fig. 6.2.1.3 Sumare de Valori Temporare aflate în curs de actualizare 6.2.2 Tipurile de Întreruperi ale unei Tranzactii

Erorile care apar în actualizarea tranzactionala a Bazelor de Date sunt legate de întreruperea neprevazuta a unei Tranzactii. Motivele de esuare a unei Tranzactii sunt foarte diverse. Le prezentam pe cele mai importante, grupate pe categorii:

o Incidente Necatastrofale

§ Întreruperea neasteptata a Sistemului de Calcul (Echipamente sau Programe), prin pierderea continutului Memoriei Interne (Tranzactiile netransferate în Memoria Externa – în Baza de Date BD sau In Jurnalul Tranzactiilor JT)

§ O Eroare în executia Tranzactiei:

• Tentative de executie a operatiilor nepermise (ex. împartire cu 0, depasire numerica etc.)

• Erori de programare (ex. erori de logica de programare, parametrii de program eronati, prelucrare exceptii de program etc.)

§ O Conditie Logica programata de renuntare la Tranzactie (ex. resurse insuficiente)

§ Conditii derivate din Controlul Concurentei Tranzactiilor în accesul la resurse (ex. resurse blocate)

Tranzactia T1

Tranzactia T2

S=0 CITIRE element X

S=S+X CITIRE element Y

Y=Y-N SCRIERE element Y

Suma calculata S are valoare eronata T1 modifica ulterior valoarea Z

Timp

CITIRE element Y S=S+Y

CITIRE element Z S=S+Z

CITIRE element Z Z=Z+N

SCRIERE element Z

Securitatea Bazelor de Date / Prelucrari Tranzactionale 447

o Incidente Catastrofale

§ Erori Fizice ale Suportului de Memorare cu pierderea continutului de Date

§ Erori Fatale ale Sistemului de Calcul cu distrugerea Datelor Prelucrate 6.2.3 Starile unei Tranzactii

Dupa cum a fost mentionat în sectiunile introductive, operatiile cuprinse ca un întreg într-o tranzactie cuprind doua categorii de operatii:

o Operatii de Acces la Baza de Date

§ Operatii de Citire (Read Only)

§ Operatii de Citire / Scriere (Read-Write)

o Operatii cu Date din Memoria Interna

In gestiunea tranzactiilor atentia este concentrata în jurul operatiilor cu Baza de Date, datorita persistentei lor. Legate de operatiile de actualizare a datelor din Baza de Date se definesc si Starile unei Tranzactii ilustrate de nodurile diagramei din Fig. 6.2.3.1. Pentru ca Secventa de Operatii cuprinse într-o tranzactie sa poata fi tratata Atomic, utilizatorul trebuie sa dispuna de un set de Comenzi Specifice pentru Gestiunea Tranzactiilor. Un asemenea set de operatii este reprezentat pe comenzile înscrise pe arcele din figura mentionata anterior. El contine urmatoarele operatii:

o BEGIN_TRANSACTION – Declararea începutului tranzactiei

o END_TRANSACTION – Declararea sfârsitului tranzactiei. In acest punct se verifica:

§ Terminarea executiei comenzilor lansate READ si WRITE

§ Conditia de persistenta a actualizarilor efectuate, cu lansarea expresa a comenzilor:

• COMMIT_TRANSACTION - Acceptarea actualizarilor prin Transferul Noii Stari în Baza de Date

• ROLLBACK – Refuzarea actualizarilor prin Refacerea Starii Initiale a Bazei de Date

o READ – Citire din Baza de Date

o WRITE – Scriere în Baza de Date

o COMMIT_TRANSACTION – Semnalarea unei încheieri cu succes a Tranzactiei, cu urmatoarele consecinte:

• Declansarea actiunii de transferare în Baza de Date a Starii Noi, ce contine actualizarile efectuate în tranzactie si memorate în Jurnalul de Tranzactii

• Starea Noua este mentinuta în Jurnalul de Tranzactii pentru utilizarea ei eventuala în Procesul de Refacere a Bazei de Date (comanda REDO)

448 Securitatea Bazelor de Date / Prelucrari Tranzactionale

• daca actiunea de transferare în Baza de Date a Starii Noi este terminata prin înscrierea în Jurnalul de Tranzactiei a înregistrarii (comanda COMMIT), atunci aceasta Stare Noua nu mai poate fi eliminata din Baza de Date printr-o comanda de stergere (UNDO)

o ROLLBACK (ABORT) – Semnalarea unei încheieri fara succes a Tranzactiei, cu urmatoarele consecinte:

• Starea Noua, ce contine actualizarile efectuate în tranzactie, este abandonata

• Starea Initiala, ce contine datele existente în Baza de Date înainte de începerea Tranzactiei si care au fost în prealabil salvate în Jurnalul de Tranzactii, trebuie refacuta pentru cazul Operatiilor Tranzactionale deja transferate în Baza de Date

Un grup de Comenzi Aditionale completeaza setul de Comenzi Tranzactionale Curente, referindu-se la relatia dintre Subsistemul de Gestiune a Tranzactiilor si Subsistemul de Gestiune a Salvarii / Restaurarii Tranzactiilor. Din Comenzi Aditionale fac parte:

o UNDO – Similara cu operatia ROLLBACK, dar referitoare doar la o Operatie Singulara si nu la o întreaga Tranzactie (se refera la completarea actualizarii Starilor Initale)

o REDO – Determina refacerea anumitor operatii dintr-o tranzactie pentru asigurarea executarii actualizarii complete a Bazei de Date în caz de incident, aparut la transferul efectiv de date în Baza de Date (se refera la completarea actualizarii Starilor Finale)

Diagrama de Tranzitii din Fig. 6.2.3.1 reda si trecerea tranzactiei prin diferite Stari, potrivit Operatiilor lansate în cadrul unei Tranzactii. Starile unei Tranzactii sunt:

o Stare Activa

§ Tranzactia e activata de declaratia BEGIN TRANSACTION

§ Tranzactia poate lansa operatii READ si WRITE

o Stare Partial Executata

§ Tranzactia e încheiata de declaratia END TRANSACTION

§ Tranzactia efectueaza Controlul Interferarii cu alte tranzactii concurente

§ Tranzactia asteapta de la Subsistemul de Salvare / Restaurare permisiunea de începere a transferului actualizarilor în Baza de Date

o Stare Executata

§ Tranzactia a încheiat cu succes transferului actualizarilor în Baza de Date

o Stare Esuata

§ Tranzactia a primit raspuns negativ din partea controalelor si interogarilor efectuate

§ Tranzactia este abandonata prin operatia ABORT, emisa în starea sa Activa

Securitatea Bazelor de Date / Prelucrari Tranzactionale 449

Fig. 6.2.3.1 Diagrama de Stari ale unei Tranzactii

Tranzactie ACTIVA

Tranzactie PARTIAL

EXECUTATA

Tranzactie EXECUTATA

Tranzactie TERMINATA

Tranzactie ESUATA

BEGIN TRANSACTION

END TRANSACTION COMMIT

ABORT ABORT

READ WRITE

450 Securitatea Bazelor de Date / Prelucrari Tranzactionale

o Stare Terminata

§ Tranzactia a parasit sistemul

§ Tranzactia trebuie relansata (automat sau programat) 6.2.4 Jurnalizarea Tranzactiilor

Având în vedere faptul ca în cadrul Gestiunii Tranzactiilor trebuie luate în considerare si întreruperi brutale în functionarea Sistemelor de Calcul, evolutia fiecarei tranzactii se cere detaliat înregistrata pentru a putea fi regasita în procesul de Refacere a Starilor (Initiale sau Finale) ale Bazei de Date. Înregistrarea evolutiei unei Tranzactii se face într-o Memorie Externa, diferita de Baza de Date, denumita Jurnalul Tranzactiilor. In Tab. 6.2.4.1 se regasesc informatiile care vor fi memorate în Jurnalul Tranzactiilor, în momentul lansarii diverselor Operatii Tranzactionale, împreuna cu actiunile efectuate sau care sunt anuntate pentru declansare. Informatiile prezentate reprezinta un cadru general. Versiuni diferite ale acestor înregistrari sunt legate de natura Protocolului de Jurnalizare pe care le implementeaza diferite SGBD-uri. Observatiile care se impun sunt urmatoarele:

- Pentru a putea gestiona corect tranzactiile sistemul va genera automat un Identificator Intern al Tranzactiilor (T), care va permit în orice moment regruparea tuturor înregistrarilor care se refera la o anumita Tranzactie

- Jurnalul va contine atât Valorile Noi cât si Valorile Vechi ale fiecarei Date (Item), pentru a putea furniza datele necesare pentru toate Operatii Tranzactioinale de Refacere a continutului Bazei de Date (ROLLBACK, UNDO, REDO)

- Când o Tranzactie intra în Starea Executata (comanda COMMIT), toate Operatiile sunt înregistrate în Jurnalul Tranzactiilor (JT), care trebuie de asemenea sa contina înregistrat Indicatorul de Succes (adevarat)

- Tranzactiile cu înregistrare COMMIT în JT pot fi utilizate pentru orice Comenzi de Refacere

- Tranzactiile fara înregistrare COMMIT în JT pot fi utilizate numai pentru comenzi de Refacere a Valorilor Vechi (ROLLBACK sau UNDO)

- Scrierea informatiilor în JT este fortata periodic de catre Subsistemul de Salvare / Restaurare, prin efectuarea urmatoarele actiuni:

§ Se suspenda toate Tranzactiile

§ Pentru toate Tranzactiile Executate (în starea COMMIT) se forteaza scrierea datelor în JT

§ Sistemul scrie în JT o înregistrare de marcare a unui Punct de Control (CHECKPOINT)

§ Se reiau Tranzactiile suspendate

- Toate Tranzactiile din JT care au înscrise înregistrari COMMIT înainte de o înregistrare CHECKPOINT nu vor trebui Refacute cu Valorile Noi (REDO) în cazul unui incident

Securitatea Bazelor de Date / Prelucrari Tranzactionale 451

OperatieTranzactionala Parametri Actiuni

BEGIN_TRANSACTION T – Nr. Intern Tranzactie - înregistreaza o noua tranzactie

WRITE

T – Nr. Intern Tranzactie

X – Nume Câmp

Vv – Valoare Veche

Vn – Valoare Noua

- înregistreaza modificarea Valorilor unei Date (Veche si Noua)

READ T – Nr. Intern Tranzactie

X – Nume Câmp

- înregistreaza Numele Datei citite

COMMIT T – Nr. Intern Tranzactie

S – Indicator Succes (adevarat)

- marcheaza o Tranzactie reusita

- anunta pregatirea pentru transferul în BD a Starii Finale

ABORT T – Nr. Intern Tranzactie

S – Indicator de Succes (fals)

- marcheaza o Tranzactie abandonata

- anunta pregatirea pentru revenirea la Starea Initiala a BD

Tab. 6.2.4.1 Continutul Jurnalului de Tranzactii

6.2.5 Proprietatile unei Tranzactii Atomice

Pentru ca o Tranzactie sa îndeplineasca conditia de a fi Atomica (Nedecompozabila în efectul ei asupra Bazei de Date), ea trebuie sa îndeplineasca o suma de proprietati, denumite prescurtat proprietatile ACID (Atomicitate, Consistenta, Izolare, Durabilitate). Proprietatile ACID vor fi asigurate prin mecanismul de Control al Concurentei precum si de Metoda de Restaurare folosita de SGBD. Continutul Proprietatilor ACID este explicat mai jos:

o Atomicitate – Tranzactia e efectuata în întregime (cu toate operatiile elementare pe care le contine) sau deloc (cu revenire la Starea Initiala)

o Consistenta – o executie corecta a unei Tranzactii determina trecerea Bazei de Date dintr-o Stare Consistenta în alta Stare Consistenta

o Izolare – modificarile efectuate în cadrul unei Tranzactii trebuie sa ramâna invizibile pentru alte Tranzactii înainte de Încheierea Tranzactiei. In functie de Gradul de Protectie oferit de o Tranzactie se definesc urmatoarele Grade de Izolare:

§ Grad 0 – Tranzactia nu asigura Rescrierea Citirilor Alterate (DIRTY READS) ale tranzactiilor de grad superior

§ Grad 1 – Tranzactia nu e expusa Pierderilor de Actualizari

§ Grad 2 – Tranzactia nu e expusa Pierderilor de Actualizari si Citirilor Alterate

452 Securitatea Bazelor de Date / Prelucrari Tranzactionale

§ Grad 3 – Tranzactia nu e expusa Pierderilor de Actualizari si Citirilor Alterate oferind si posibilitatea Citirilor Repetabile (acest grad de izolare e considerat Izolare Adevarata)

o Durabilitate – modificarile efectuate de o Tranzactie Încheiata trebuie sa se mentina chiar în conditiile unor incidente aparute dupa încheierea ei

6.2.6 Planul de Operatii Tranzactionale

Erorile datorate lipsei de Control a Tranzactiilor prezentate în sectiunea 6.1.1 sugereaza o posibila Ordine Gresita în efectuarea Operatiilor care compun Tranzactiile Concurente. Sa definim în cele ce urmeaza câteva notiuni legate de modul de executie a Tranzactiilor.

Definitie:

Operatii Tranzactionale – ansamblul Operatiilor Principale continute în Tranzactii, a caror executie este importanta pentru mentinerea Consistentei Bazei de Date; tipurile acestor operatii pot fi:

• Citire Item X în Tranzactia i – ci (X)

• Scriere Item X în Tranzactia i – si (X)

• Executie Tranzactie i – ei

• Abortare Tranzactie i – ai

Definitie:

Plan de Operatii Tranzactionale – Secventa de Operatii, partial sau total ordonate, provenind din mai multe Tranzactii Concurente.

Exemple: Pentru exemplul din Fig. 6.2.1.1:

Cu Operatiile din Tranzactiile:

T1 : c1 (X) , s1 (X) , c1 (Y) , s1 (Y) , e1

T2 : c2 (X) , s2 (X) , e2

Se construieste Planul de Operatii Tranzactionale:

P1 : c1 (X) ; c2 (X) ; s1 (X) ; c1 (Y) ; s2 (X) ; e2 ; s1 (Y) ; e1

Pentru exemplul din Fig. 6.2.1.2:

Cu Operatiile din Tranzactiile:

T1 : c1 (X) , s1 (X) , c1 (Y) , a1

T2 : c2 (X) , s2 (X) , e2

Se construieste Planul de Operatii Tranzactionale:

P2 : c1 (X) ; s1 (X) ; c2 (X) ; s2 (X) ; e2 ; c1 (Y) ; a1

Securitatea Bazelor de Date / Prelucrari Tranzactionale 453

Definitie:

Operatii Conflictuale – Orice Pereche de Operatii dintr-un Plan de Operatii Tranzactionale care îndeplinesc urmatoarele conditii:

• Apartin la Tranzactii diferite

• Se refera la acelasi Element de Resursa (Câmp de Date)

• Contine cel putin o Operatie de Scriere Exemple de Operatii în Conflict:

- c1 (X) si s2 (X) din P1

- c2 (X) si s1 (X) din P1

- s1 (X) si s2 (X) din P1

Definitie:

Plan Complet de Operatii Tranzactionale – Un Plan de Operatii Tranzactionale care îndeplineste urmatoarele conditii:

• Planul contine toate Operatiile din Tranzactii

• Pentru fiecare Pereche de Operatii provenind din aceeasi Tranzactie ordinea din Plan si din Tranzactie e aceeasi

• Rezolvarea oricarui Conflict se face prin Inversarea Operatiilor aflate în conflict (aceasta nu va contrazice Regula 2, întrucât Operatiile în Conflict fac întotdeauna parte din Tranzactii diferite)

Intr-un Plan Complet de Operatii Tranzactionale se poate observa:

- Operatiile Neconflictuale sunt Partial Ordonate, întrucât ordinea lor e indiferenta

- Operatiile Conflictuale sunt Total Ordonate, întrucât ordinea lor e critica în Plan

- Planul nu va contine Tranzactii Active, ci numai Tranzactii Încheiate (prin COMMIT sau ABORT, ultimele operatii din Tranzactii) Întrucât în sistem se afla în fiecare moment o multime de Tranzactii în diferite Stari de Executie, se face o selectare a Tranzactiilor Încheiate. Pentru aceasta se face apel la conceptul de Proiectie a Tranzactiilor Încheiate ale unui Plan, reprezentând: Multimea Tranzactiilor care au executate operatiile COMMIT sau ABORT.

6.2.7 Proprietatile Tranzactiilor în Refacerea Bazei de Date

Fiind privite ca Unitati Atomice în actualizarea Bazelor de Date, este fireasca utilizarea Tranzactiilor în procesul de Refacere a continutului de date, în cazurile de alterare a acestuia. Cum Istoria Executiei Tranzactiilor e continuta în Planurile de Operatii Tranzactionale, ele vor folosi ca baza pentru Procesul de Refacere, care nu e întotdeauna simplu. Din punctul de vedere al acestui proces Planurile de Operatii Tranzactionale se împart în:

454 Securitatea Bazelor de Date / Prelucrari Tranzactionale

• Planuri Restaurabile

• Planuri Nerestaurabile

Pentru început sa mentionam dezideratul ca o Tranzactie deja Încheiata sa nu trebuiasca sa fie Refacuta prin fortarea unei operatii ROLLBACK (vezi sectiunea 6.2.3).

Intr-un Plan de Operatii Tranzactionale Dependenta între Tranzactii este data de prezenta Tranzactiilor care citesc din alte Tranzactii.

Definitie: Daca doua Tranzactii T1 si T2 cu proprietatile:

§ T1 citeste elementul X , sau altfel exprimat, contine operatia c1 (X)

§ T2 scrie elementul X , sau altfel exprimat, contine operatia s2 (X)

§ Operatia s2 (X) succede operatiei c1 (X) atunci se zice ca Tranzactia T1 citeste din Tranzactia T2.

Conditia de asigurare a Restaurarii Corecte este legata de existenta într-un Plan de Operatii Tranzactionale a Tranzactiilor Dependente si se exprima astfel:

Orice Tranzactie Dependenta Corecta trebuie sa astepte Încheierea Tranzactiei de care depinde.

Definitie: Plan Restaurabil – orice Plan care nu contine decât Tranzactii Dependente Corecte.

Exemple: Planuri Restaurabile:

P1 : c1 (X) ; c2 (X) ; s1 (X) ; c1 (Y) ; s2 (X) ; e2 ; s1 (Y) ; e1

Deoarece:

- T1 e dependenta de T2 (T1 citeste pe X pe care T2 îl scrie apoi)

- T2 încheie (e2) înainte de T1 (e1)

Planuri Nerestaurabile

P3 : c1 (X) ; s1 (X) ; c2 (X) ; c1 (Y) ; s2 (X) ; e2 ; a1

Deoarece:

- T2 e dependenta de T1 (T2 citeste pe X pe care T1 îl scrie apoi)

- T2 încheie (e2) înainte de T1 (a1) Simpla inversare a Operatiilor e2 cu a1 transforma Dependenta Incorecta a lui T2 de T1 (T1 → T2) în Dependenta Corecta.

Exista SGBD-uri care accepta Refacerile Cascadate (Refacerea Tranzactiilor Dependente Incorecte Încheiate) ca remediu pentru rezolvarea Dependentelor Incorecte. Solutia însa implica un timp crescut de procesare, care poate deveni prohibitiv.

O alta solutie o reprezinta Planurile de Operatii Tranzactionale Stricte, care nu accepta crearea de Tranzactii Dependente (se accepta doar accesul la Elementele Tranzactiilor

Securitatea Bazelor de Date / Prelucrari Tranzactionale 455

Încheiate. Si aceasta solutie devine consumatoare de timp, prin timpii de asteptare pe care îi implica.

6.2.8 Serializarea Tranzactiilor

Solutia cea mai sigura de evitare a Conflictelor între Operatii apartinând Tranzactiilor diferite este cea de Serializare a Tranzactiilor. Aceasta metoda consta în pornirea unei Tranzactii numai dupa încheierea Tranzactiei care contine Operatii Candidate de a intra în Conflict cu Operatiile primei Tranzactii.

Nu e întâmplator faptul ca si în acest caz de impas solutia este gasita într-o metoda care asigura Independenta Elementelor aflate în Conflict, în speta Independenta Tranzactiilor. Plata pentru aceasta Independenta consta în prelungirea timpului de procesare a unui Plan de Executie prin punerea în asteptare a Tranzactiilor. Remediul acestei întârzieri poate fi cautat în selectarea acelor Tranzactii Întretesute care sunt Echivalente cu Tranzactiile Serializate.

P4 : c1 (X) ; s1 (X) ; c1 (Y) ; s1 (Y) ; e1 ; c2 (X) ; s2 (X) ; e2

Fig. 6.2.8.1 Plan de Executie Serial ( P4 )

Exista ca urmare doua modalitati de a construi Planuri de Executie a Operatiilor Tranzactionale care concureaza la aceleasi Resurse:

- Planuri Seriale – care sunt Secvente de Operatii grupate pe Tranzactii, astfel încât sa se asigure executia neîntrerupta (Neîntretesuta) a fiecarei Tranzactii (ex. Figurile 6.2.8.1 si 6.2.8.2)

Tranzactia T1

Tranzactia T2

CITIRE element X X=X+N

SCRIERE element XCITIRE element Y

Y=Y+N SCRIERE element Y

CITIRE element X X=X+M

SCRIERE element X

Tranzactia T2 e pornita numai dupa terminarea Tranzactiei T1

Timp

456 Securitatea Bazelor de Date / Prelucrari Tranzactionale

- Planuri Neseriale – care sunt Secvente de Operatii grupate pe Tranzactii, astfel încât sa se asigure executia alternativa (Întretesuta) a Tranzactiilor (ex. Figurile 6.2.8.3 si 6.2.8.4)

Planurile Seriale sunt considerate întotdeauna Corecte, dar uneori Neperformante. Corectitudinea Planurilor Seriale provine din asigurarea maximei Independente pentru fiecare Tranzactie, care e lasata sa se execute fara Interferente si prin aceasta fara Dependente. Exemplu:

In Fig. 6.2.8.1 este reluat exemplul din Fig. 6.2.1.1, efectuându-se Serializarea Tranzactiilor T1 si T2. Aceeasi serializare este repetata în Fig. 6.2.8.2, însa cu Tranzactiile inversate T2 si T1. Ambele Planuri Seriale sunt Corecte.

P5 : c2 (X) ; s2 (X) ; e2 ; c 1 (X) ; s1 (X) ; c1 (Y) ; s1 (Y) ; e1

Fig. 6.2.8.2 Plan de Executie Serial ( P5 )

Pentru a ridica performanta în executia Tranzactiilor se recurge la Planuri Neseriale, a caror Corectitudine se masoara prin comparatie cu cea a Planurilor Seriale. In urma acestei comparatii vor rezulta:

- Planuri Neseriale Incorecte - ex. Fig. 6.2.8.3

- Planuri Neseriale Corecte - ex. Fig. 6.2.8.4

Transformarea Planurilor de Executie, din Seriale în Neseriale, a dezvoltat în Controlul Concurentei Teoria Serializabilitatii.

Obiectivul Serializarii consta în obtinerea unui Plan Neserial Corect dintr-un Plan Serial dat. Un Plan Neserial Corect se zice Serializabil. Conditia pe care trebuie sa o

Tranzactia T1

Tranzactia T2

CITIRE element X X=X+N

SCRIERE element XCITIRE element Y

Y=Y+N SCRIERE element Y

CITIRE element X X=X+M

SCRIERE element X

Tranzactia T1 e pornita numai dupa terminarea Tranzactiei T2

Timp

Securitatea Bazelor de Date / Prelucrari Tranzactionale 457

îndeplineasca un asemenea Plan este de a fi Echivalent cu un Plan Serial care contine aceleasi Tranzactii. Exista mai multe metode de a defini Conditiile de Echivalenta a doua Planuri de Executie a Operatiilor Tranzactionale:

o Echivalenta a Rezultatelor – Planurile produc aceleasi Stari Finale în Baza de Date

§ Valorile Finale înscrise de Tranzactii în cele doua Planuri sunt aceleasi

Conditia e prea putin restrictiva, întrucât poate fi verificata pentru cazuri particulare si de Planuri Neechivalente.

o Echivalenta a Conflictelor – Planurile contin aceleasi Operatii Conflictuale

§ Ordinea Operatiilor Conflictuale în cele doua Planuri este aceeasi

Conditia e suficienta pentru generarea de Planuri Echivalente. Nu este si necesara întrucât exista si alte genuri de Echivalente definite, mai putin restrictive (ex. Echivalenta Vederilor asupra Datelor Citite).

Exemple:

Plan Neserial Corect - ex. Fig. 6.2.8.4

La acest Plan Neserial Corect se poate ajunge în doua feluri:

o Pornind de la Planul Neserial Incorect din Fig. 6.1.1.2 se încearca construirea unui Plan Complet de Operatii Tranzactionale cu respectarea restrictiilor impuse de acest Plan (vezi sectiunea precedenta). In Fig. 6.2.8.3 sunt ilustrate inversarile:

c2 (X) ; s1 (X) cu s1 (X) ; c2 (X)

c2 (X) ; s1 (X) cu s1 (X) ; c2 (X)

Se remarca mentinerea Ordinii Operatiilor în fiecare Tranzactie:

c1 (X) ; s1 (X) ; c1 (Y) ; s1 (Y) în T1

c2 (X) ; s2 (X) ; c2 (Y) ; s2 (Y) în T2

si totodata mentinerea Independentei Secventelor de Operatii:

c2 (X) ; s2 (X) din T2

c1 (Y) ; s1 (Y) din T1

deoarece adreseaza Elemente diferite, X respectiv Y.

In final se constata ca ambele Planuri de Executie au acelasi efect asupra Bazei de Date întrucât ultimele Operatii de Scriere sunt efectuate de aceleasi Tranzactii în ambele Planuri de Executie:

X e scris ultima data de T2

Y e scris ultima data de T1

458 Securitatea Bazelor de Date / Prelucrari Tranzactionale

P6 : c1 (X) ; s1 (X) ; c2 (X) ; s2 (X) ; c1 (Y) ; s1 (Y) ; e1 ; e2

Fig. 6.2.8.3 Plan de Executie Neserial (P6 )

o Pornind de la Planul Serial Corect din Fig. 6.2.8.1 se întretes Operatiile Conflictuale cu respectarea conditiei de Echivalenta a Conflictelor. Se ajunge la Planul din Fig. 6.2.8.3. Comparând cele doua figuri se observa ca Planurile P1 si P3 sunt Echivalente deoarece:

§ Citirile în ambele Planuri sunt identice:

c2 (X) citeste din T1

c1 (X) , c1 (Y) citesc din BD

§ Scrierile în ambele Planuri sunt identice:

s2 (X) scrie în BD

s1 (Y) scrie în BD

In concluzie:

Se zice ca Planurile de Executie P1 si P3 sunt Echivalente. Totodata, deoarece cel de al doilea Plan este Echivalent cu primul el se numeste Plan Srializabil. Comparând cele doua Planuri se remarca:

Tranzactia T1

Tranzactia T2

CITIRE element X X=X+N

SCRIERE element X

CITIRE element X X=X+M

SCRIERE element X

CITIRE element Y

Y=Y+N SCRIERE element Y

Regruparea Operatiilor din Tranzactii se face prin inversarea

Operatiilor Conflictuale

Timp

Securitatea Bazelor de Date / Prelucrari Tranzactionale 459

- Planul de Executie P1 este un Plan Serial

§ Nu permite Intreteserea Operatiilor

§ Este simplu de Implementat

§ Este Neperformant în privinta utilizarii Timpului de Calcul

- Planul de Executie P3 este un Plan Serializabil

§ Permite Intreteserea Operatiilor

§ Este Performant în privinta utilizarii Timpului de Calcul

§ Este Echivalent cu Planul Serial

Exemple:

Plan Neserial Incorect - vezi Fig. 6.2.8.4

Planul P7 nu este Echivalent cu nici unul din Planurile Seriale P4 sau P5 întrucât Sursele Datelor citite difera.

P7 : c1 (X) ; c2 (X) ; s2 (X) ; s1 (X) ; c1 (Y) ; s1 (Y) ; e2 ; e1

Fig. 6.2.8.4 Plan de Executie Neserial (P7 )

P7 nu e echivalent cu P4 deoarece:

c2 (X) citeste din T1 în P4

c2 (X) citeste din BD în P7

Timp

SCRIERE element X

Tranzactia T1

Tranzactia T2

CITIRE element X X=X+N

CITIRE element X

X=X+M

Y=Y+N SCRIERE element Y

Planul e Nerializabil c2 (X) ; s2 (X) în Conflict

Prin inversare nu se ajunge la un Plan Serial (P1)

SCRIERE element X CITIRE element Y

Planul e Nerializabil s1 (X) ; s2 (X) în Conflict

Prin inversare nu se ajunge la un Plan Serial (P2)

460 Securitatea Bazelor de Date / Prelucrari Tranzactionale

P7 nu e echivalent cu P5 deoarece:

c2 (X) citeste din BD în P5

c2 (X) citeste din T1 în P7

P7 nu este nici Serializabil întrucât nu se pot reordona Operatiile Conflictuale:

c2 (X) ; s1 (X) nu pot fi inversate pentru a-l echivala pe P7 cu P4

s1 (X) ; s2 (X) nu pot fi inversate pentru a-l echivala pe P7 cu P5

Exista algoritmi construiti pentru Verificarea Serializabilitatii unui Plan de Executie. Un asemenea algoritm este reprezentat în Fig. 6.2.8.3.

Pentru fiecare Tranzactie Ti din P

Creeaza un Nod marcat Ti

Pentru fiecare Pereche de Noduri Ti ,Tj

Creeaza un Arc Ti , Tj daca:

Operatia sk (X) apare în Tranzactia Ti

Operatia ck+n (X) apare în Tranzactia Tj

Pentru fiecare Pereche de Noduri Ti ,Tj

Creeaza un Arc Ti , Tj daca:

Operatia ck (X) apare în Tranzactia Ti

Operatia sk+n (X) apare în Tranzactia Tj

Pentru fiecare Pereche de Noduri Ti ,Tj

Creeaza un Arc Ti , Tj daca:

Operatia sk (X) apare în Tranzactia Ti

Operatia sk+n (X) apare în Tranzactia Tj

Testarea Ciclurilor în Graf

Daca exista Planul e Neserializabil altfel e Serializabil

Fig. 6.2.8.3 Algoritm pentru crearea Grafului de Precedenta al unui Plan de Executie

Algoritmul de Verificare a Serializabilitatii unui Plan de Executie se bazeaza pe urmatoarele etape;

o Construirea unui Graf de Precedenta a Tranzactiilor

§ Nodurile reprezinta Tranzactii

§ Arcele reprezinta Precedenta de Executie a Tranzactiilor

Securitatea Bazelor de Date / Prelucrari Tranzactionale 461

o Verificarea daca Graful construit are Cicluri:

§ daca NU Planul de Executie e Serializabil

§ daca DA Planul de Executie nu e Serializabil

Un asemenea algoritm este reprezentat în Fig. 6.2.8.3.

In practica aceste metode analitice se dovedesc prea costisitoare, datorita conditiilor restrictive prea severe. Rezolvarea Conflictelor între Operatiile Tranzactionale poate fi facuta în cazuri concrete si prin alte metode mult mai simple.

Exemplu:

Sa consideram doua Tranzactii cu urmatoarele particularitati:

- Folosesc ca Operatii de Actualizare doar Adunarea si Scaderea, ceea ce face ca Operatiile între o Scriere si o Citire a aceluiasi element sa fie comutative

- Secventele de Operatii: Citire; Actualizare; Scriere nu vor fi întrerupte

In acest caz Planul de Executie:

P : c1 (X); s1 (X); c2 (X); s2 (X); c1 (X); s1 (X); c2 (X); s2 (X)

este Corect desi nu este Serializabil.

6.2.9 Controlul Concurentei

In vederea simplificarii modului de asigurare al Independentei Tranzactiilor, a fost introdus conceptul de Blocare a Resurselor. Aceasta metoda a fost implementata prin extinderea Limbajului de Manipulare a Datelor (sectiunea de Gestiune a Tranzactiilor) cu comenzi speciale de Blocare a Resurselor.

SGBD-urile au dezvoltat mai multe forme de Blocare a Resurselor:

o Blocarea Simpla (Binara)

§ Definirea Blocarii – Blocarea Resursei are doua Stari

• Blocata

o Tranzactia în curs are acces Exclusiv la Resursa

o Celelalte Tranzactii care solicita acces la aceeasi Resursa sunt puse în Asteptare (WAIT)

• Deblocata

o Tranzactia în curs a Încheiat accesul la Resursa

o Tranzactiile puse în Asteptare sunt activate

o Celelalte Tranzactii care solicita acces la aceeasi Resursa primesc acces

§ Informatii necesare – Baza de Date este completata cu urmatoarele Informatii Suplimentare gestionate automat de catre SGBD

462 Securitatea Bazelor de Date / Prelucrari Tranzactionale

• Se adauga în Baza de Date o Tabela de Control a Blocarii (TCB), sub forma unei Tabele Sistem care contine:

o Identificatorul Elementului de Resursa

o Marcajul de Blocare având urmatoarele Valori:

§ Blocat

§ Deblocat

• Actualizarea Tabelei TCB se face de catre Utilizator prin Comenzile:

o LOCK <Identificator Resursa> - pentru Blocare Resursa

o UNLOCK <Identificator Resursa> - pentru Deblocare Resursa

§ Descrierea Procedurii de Blocare Resurse

• Blocare Resursa

PROCEDURA Blocare_Resursa (X)

DACA Marcaj (Resursa) = ’Deblocat’

ATUNCI Marcaj (Resursa) = ’Blocat’

ALTFEL Pune Tranzactia în Asteptare

• Deblocare Resursa

PROCEDURA Deblocare_Resursa (X)

Marcaj (Resursa) = ’Deblocat’

DACA Exista Tranzactie în Asteptare

ATUNCI Reactiveaza Tranzactia în Asteptare

§ Reguli de Blocare a Resurselor

• Blocarea unei Resurse (X) trebuie sa preceada orice Operatie de Citire sau Scriere a acelei Resurse (X) din Tranzactie

• Deblocarea unei Resurse (X) trebuie sa succeada oricarei Operatie de Citire sau Scriere a acelei Resurse (X) din Tranzactie

• Blocarea unei Resurse (X) nu trebuie relansata daca Resursa (X) este deja Blocata

• Deblocarea nu trebuie lansata pe o Resursa (X) care nu e Blocata

o Blocare Nuantata (Partajata sau Exclusiva)

§ Definirea Blocarii – Blocarea Resursei are trei Stari

Securitatea Bazelor de Date / Prelucrari Tranzactionale 463

• Blocata la Citire

o Tranzactia în curs are Acces Partajat la Resursa cu alte Tranzactii care cer Acces în Citire, dar interzice Accesul în Scriere al oricarei alte Tranzactii

o Celelalte Tranzactii care solicita acces la aceeasi Resursa sunt puse în Asteptare (WAIT)

• Blocata la Scriere

o Tranzactia în curs are acces Exclusiv la Resursa

o Celelalte Tranzactii care solicita Acces în Citire sau în Scriere la aceeasi Resursa sunt puse în Asteptare (WAIT)

• Deblocata

o Tranzactia în curs a Încheiat accesul la Resursa

o Tranzactiile puse în Asteptare sunt activate

o Celelalte Tranzactii care solicita acces la aceeasi Resursa primesc acces

§ Informatii necesare – Baza de Date este completata cu urmatoarele Informatii Suplimentare gestionate automat de catre SGBD

• Se adauga în Baza de Date o Tabela de Control a Blocarii (TCB), sub forma unei Tabele Sistem care contine:

o Identificatorul Elementului de Resursa

o Marcajul de Blocare având urmatoarele Valori:

§ Blocat în Citire – utilizare Partajata

§ Blocat în Scriere– utilizare Exclusiva

§ Deblocat

o Numarul de Tranzactii care au cerut Blocare în Citire

• Actualizarea Tabelei TCB se face de catre Utilizator prin Comenzile:

o READ_LOCK <Identificator Resursa> - pentru Blocare în Citire

o WRITE_LOCK <Identificator Resursa> - pentru Blocare în Scriere

o UNLOCK <Identificator Resursa> - pentru Deblocare Resursa

§ Descrierea Procedurii de Blocare Resurse

• Blocare Resursa în Citire

464 Securitatea Bazelor de Date / Prelucrari Tranzactionale

PROCEDURA Blocare_Resursa_Citire (X)

DACA Marcaj (Resursa) = ’Deblocat’

ATUNCI Marcaj (Resursa) = ’Blocat’

Nr_Tranzactii = 1

ALTFEL

DACA Marcaj (Resursa) = ’Blocat în Citire’

ATUNCI Nr_Tranzactii = Nr_Tranzactii + 1

ALTFEL Pune Tranzactia în Asteptare

• Blocare Resursa în Scriere

PROCEDURA Blocare_Resursa_Scriere (X)

DACA Marcaj (Resursa) = ’Deblocat’

ATUNCI Marcaj (Resursa) = ’Blocat în Scriere’

ALTFEL Pune Tranzactia în Asteptare

• Deblocare Resursa

PROCEDURA Deblocare_Resursa (X)

DACA Marcaj (Resursa) = ’Blocat în Scriere’

Marcaj (Resursa) = ’Deblocat’

DACA Exista Tranzactie în Asteptare

ATUNCI Reactiveaza Tranzactia în Asteptare

ALTFEL

DACA Marcaj (Resursa) = ’Blocat în Citire’

ATUNCI Nr_Tranzactii = Nr_Tranzactii - 1

DACA Nr_Tranzactii = 0

ATUNCI Marcaj (Resursa) = ’Deblocat’

DACA Exista Tranzactie în Asteptare

ATUNCI Reactiveaza Tranzactia în Asteptare

§ Reguli de Blocare a Resurselor

• Blocarea în Citire sau în Scriere a unei Resurse (X) trebuie sa preceada orice Operatie de Citire a acelei Resurse (X) din Tranzactie

Securitatea Bazelor de Date / Prelucrari Tranzactionale 465

• Blocarea în Scriere a unei Resurse (X) trebuie sa preceada orice Operatie de Scriere a acelei Resurse (X) din Tranzactie

• Deblocarea unei Resurse (X) trebuie sa succeada oricarei Operatii de Citire sau Scriere a acelei Resurse (X) din Tranzactie

• Blocarea în Citire nu trebuie relansata pe o Resursa (X) deja Blocata în Citire sau în Scriere (restrictia poate fi relaxata în sistemele care accepta Scaderea Blocarii)

• Blocarea în Scriere a unei Resurse (X) nu trebuie relansata daca Resursa (X) este deja Blocata în Citire sau în Scriere (restrictia poate fi relaxata în sistemele care accepta Cresterea Blocarii)

• Deblocarea nu trebuie lansata pe o Resursa (X) care nu e Blocata în Citire sau în Scriere

Ca în toate problemele legate de procedeul Blocarii de Resurse si în acest caz exista doua situatii de impas în Executarea Tranzactiilor:

o Blocarea Reala a Tranzactiilor (Deadlock)

§ Definire - Resursele partajate de doua Tranzactii se Blocheaza în starea de Asteptare Reciproca (Tranzactia Ti asteapta dupa Resursa Rm blocata de Tj, iar Tranzactia Tj asteapta dupa Resursa Rn blocata de Ti)

§ Remediu – Blocarea Tuturor Resurselor necesare unei Tranzactii pe toata durata ei

o Blocarea Aparenta a Tranzactiilor (Livelock)

§ Definire - Datorita Prioritatii Scazute, o Tranzactie ramâne mereu în Asteptarea de Resurse

§ Remediu – Modificarea Dinamica a Prioritatilor Tranzactiilor

Tehnica de Blocare a Resurselor ofera o metoda practica de a controla executia Tranzactiilor. S-a încercat doar prezentarea conceptelor de baza, întrucât numeroase procedee vin sa aprofundeze si sa rafineze problematica complexa a Accesului Concurential la Resurse (Blocarea în Doua Faze, Blocarea prin Stampile de Timp, Blocarea Versionata etc.).

Câteva observatii finale se impun la adresa Metodei Blocarii Resurselor:

- Ofera variante foarte diverse de implementare datorita Controlului Programat (prin Comenzi) pe care îl ofera

- Nu garanteaza Serializabilitatea Planurilor de Executie a Tranzactiilor, dar solutia de rezolvare consta în esuarea, cel putin a uneia din Tranzactiile aflate în Conflict si relansarea ulterioara a Tranzactiilor Esuate

- Consuma Spatiu si Timp de prelucrare pentru Volume Mari de Resurse ce se cer accesate Concurential

466 Securitatea Bazelor de Date / Prelucrari Tranzactionale

6.2.10 Granularitatea Datelor

Granularitatea Datelor se refera la alegerea elementelor care sa formeze Resursele asupra carora vor actiona procedurile de Blocare / Deblocare. Acestea pot fi reprezentate de diferite Fragmente ale Bazei de Date:

§ Valoare de Atribut (Câmp de Date)

§ Tupla de Relatie (Rând de Tabela, sau Înregistrare de Fisier)

§ Relatie (Tabela sau Fisier)

§ Zona Fizica din Baza de Date (Bloc de Disc)

§ Baza de Date

Finetea Granularitatii masoara, pe de o parte marimea Gradului de imobilizare a Tranzactiilor Concurente, iar pe de alta parte complexitatea procedurilor de Control a Concurentei Tranzactiilor, care implica consum de Timp de Calcul si Spatiu de Memorare. Cele doua tendinte mentionate pot fi caracterizate dupa cum urmeaza:

- Resurse cu Granularitate Ridicata

o Elementele ce constituie Resursa au dimensiuni mici, ceea ce determina Imobilizari Reduse de Resurse

o Gradul de Siguranta în finalizarea Tranzactiilor Lansate este mai mic, datorita Conflictelor Multiple ce pot apare pe parcursul executarii Tranzactiilor

o Fluxul Tranzactiilor e crescut, datorita posibilitatii Lansarii Paralele a mai multor Tranzactii

o Solicita consum ridicat de Timp de Procesare si de Spatiu de Memorare, prin cresterea Informatiei Suplimentare de gestiune a proceselor de Blocare / Deblocare (Indicatori, Stampile de Timp etc.

- Resurse cu Granularitate Scazuta

o Elementele ce constituie Resursa au dimensiuni mari, ceea ce determina Imobilizari Extinse de Resurse

o Gradul de Siguranta în finalizarea Tranzactiilor Lansate e crescut de garantarea accesului nestânjenit la toate Resursele

o Fluxul Tranzactiilor e scazut datorita numarului mare de Tranzactii aflate în asteptarea unei Prelucrari mai mult Seriale

o Solicita consum suplimentar redus de Timp de Procesare si de Spatiu de Memorare, prin limitarea volumului Informatiilor de Control în gestiunea unui numar mai mic de Fragmente de Resurse

In general Granularitatea ramâne Fixa pe durata gestiunii Tranzactiilor, existând însa si SGBD-uri care accepta Granularitate Variabila, adaptata naturii diferitelor Tranzactii.

Securitatea Bazelor de Date / Refacerea Bazelor de Date 467

6.3 Refacerea Bazelor de Date

Pentru început dam o corespondenta utila între termenii utilizati în continuare si termenii consacrati din limba engleza. Am folosit urmatoarele traduceri:

- Refacere pentru Recovery

- Salvare pentru Save

- Restaurare pentru Restore

Refacerea Structurilor de Date reprezinta o Metoda de Garantare a Sigurantei în Functionarea unei Surse de Date. Ea este denumita uneori si Functie de Securitate a Datelor si consta din doua etape distincte:

o Salvarea Datelor – Ansamblul procedurilor prin care continutul unei Baze de Date este copiat în Structuri de Date exterioare Bazei de Date pentru a putea asigura ulterior Refacerea Datelor în cazurile celor mai grave accidente (inclusiv distrugerea fizica a suportului). Doua categorii de informatii se cer protejate prin Salvare:

§ Continutul Integral al unei Baze de Date, aflata într-o Stare Consistenta (vezi sectiunea 4.2.1.1.2) este înregistrat în Memoria Auxiliara de Referinta (Arhiva Bazei de Date)

§ Actualizarile operate asupra unei Baze de Date sunt înregistrate în Memoria Auxiliara a Tranzactiilor (Jurnalul Tranzactiilor)

o Restaurarea Datelor – Ansamblul procedurilor prin care, în caz de incidente survenite în functionarea BD, SGBD poate sa refaca o Stare Consistenta anterioara a Bazei de Date

6.3.1 Termeni si Concepte

Intrucât Tranzactiile reprezinta Elementele Atomice de trecere a unei Baze de Date dintr-o Stare Consistenta în alta, Refacerea Structurilor de Date este strâns legata de Actualizarea Tranzactionala a BD. Doua categorii de informatii sunt consemnate în Operatiile Critice din Tranzactii (vezi Tab. 6.2.4.1):

- Valoarea Înainte de Actualizare (Imaginea Anterioara)

- Valoarea Dupa Actualizare (Imaginea Ulterioara) Aceste informatii vor fi memorate în Jurnalul de Tranzactii, în vederea utilizarii lor ulterioare în caz de incident. Întrucât Imaginile Anterioara si Ulterioara sunt memorate în permanenta în Jurnalul Tranzactiilor, gestiunea acestei Colectii de Date este esentiala atât pentru Controlul Tranzactiilor, cât si pentru Controlul Procesul de Refacere a Bazelor de Date. Numeroase protocoale au fost dezvoltate pentru Gestiunea Datelor în fazele de Salvare / Restaurare. Unul dintre cele mai des utilizate este denumit: Prioritatea de Scriere a Jurnalului de Tranzactii. Îl redam succint:

- Toate înregistrarile UNDO trebuie sa fie scrise în Jurnalul de Tranzactii înaintea începerii transferului Imaginii Ulterioare în Baza de Date

468 Securitatea Bazelor de Date / Refacerea Bazelor de Date

- Toate înregistrarile REDO si UNDO trebuie sa fie scrise în Jurnalul de Tranzactii înaintea încheierii Operatiei COMMIT

Procesul de Refacere a Structurilor de Date este ilustrat în Fig. 6.3.1. El se bazeaza pe urmatoarele concepte:

o O Baza de Date, privita ca si Structura Dinamica porneste de la o Stare Consistenta BDi, denumita Stare de Referinta Initiala, accepta Transformari Atomice si Consistente (capabile de a reface o Starea Anterioara Consistenta pe care au modificat-o), denumite Tranzactii Tij, si trece printr-un numar de Stari Intermediare Consistente BDij, denumite si Puncte de Control (Checkpoints), pentru a ajunge în final într-o alta Stare Consistenta BD2, denumita Stare de Referinta Finala BDi+1.

o Stare de Referinta precum si Puncte de Control sunt alese de catre Administratorul Bazei de Date prin Localizare în Timp sau alte Conditii Programate (Numar de Tranzactii Efectuate, Starile Aplicatiilor etc.)

o Pentru a putea Reface în orice moment Stari Consistente Anterioare BDi, se cere înregistrat un Istoric de Evolutie a Bazei de Date, care sa fie înregistrat într-o Structura de Date diferita de cea a Bazei de Date (atât ca Structura Interna, cât si ca Suport de Memorare), denumita Arhiva. Arhiva de Date are doua componente, asa dupa cum s-a mentionat anterior:

§ Arhiva Starilor de Referinta – care contine Copiile Integrale ale Bazei de Date ABDi , la momente diferite de timp. Pentru Refacerea ultimei Stari Consistente este suficienta retinerea ultimei Stari de Referinta. Trebuie însa retinut ca din motive de securitate, pentru structuri complexe se retin mai multe Copii de Referinta ale Bazei de Date

§ Jurnalul Tranzactiilor – care contine Copia tuturor Actualizarilor Tranzactionale Corecte operate în Baza de Date si care sunt grupate, în Ordinea efectuarii lor în Baza de Date, într-o colectie de tip Jurnal JTi

o Refacerea unei Stari Consistente anterioare dupa un incident I (Fig. 6.3.1) poate fi facuta în doua moduri:

§ Refacerea la Cald se efectueaza în cazul Incidentelor Necatastrofale (sectiunea 6.2.2)

• Definire - revenirea la o Stare Consistenta anterioara fara întreruperea functionarii Bazei de Date BD (vezi secventa de operatii din partea superioara a Fig. 6.3.1)

• Procedura se realizeaza cu ajutorul urmatoarelor Colectii de Date:

o Baza de Date din momentul incidentului BD12, aflata într-o Stare Inconsistenta

o Ultimele Tranzactii (RT13 si RT12) memorate în Jurnalul de Tranzactii JT1 (Jurnalul Curent de Tranzactii), dupa ultima Stare Intermediara (Punct de Control) Consistenta

Securitatea Bazelor de Date / Refacerea Bazelor de Date 469

BDi – Baza de Date (Stare Consistenta de Referinta) SBD – Salvare Baza de Date RBD – Restaurare Baza de Date BDi j – Baza de Date (Stare Consistenta Intermediara – Punct de Control) T - Tranzactii ABD1 – Arhiva Baza de Date (Stare Consistenta de Referinta) ST – Salvare Tranzactii RT – Restaurare Tranzactii JT1 – Jurnal de Tranzactii (Tranzactii Consistente) I - Incident

Fig. 6.3.1 Procesul de Refacere (Salvare / Restaurare) al unei Baze de Date

Refacere la Cald

RBD 1

SBD 1

T23 T22 T21 T13 RT12 T11

RT13

ST12RT12 I

BD1

ABD2

BD2

ABD1

ABD3

BD3

JT1

JT2

BD1

BD2

BD3

BD21

BD12

BD22

BD11

BD12

BD21

BD22

ST11

ST13

RT12

T11

SBD 2 SBD 3

RBD 2 RBD 3

RT11

BD11

Refacere la Rece

470 Securitatea Bazelor de Date / Refacerea Bazelor de Date

• Procedura consta din urmatoarele Operatii:

o Refacerea continutului Bazei de Date BD11 pe baza modificarilor înregistrate în Jurnalul Tranzactiilor JT1, din toate Tranzactiile care succed Punctul de Control Consistent

• Efectul Procedurii de Refacere este Restaurarea Starii Consistente a Bazei de Date BD11, cea mai apropiata de Punctul de Control la care s-a produs Incidentul

§ Refacerea la Rece se efectueaza în cazul Incidentelor Catastrofale (sectiunea 6.2.2)

• Definire - revenirea la o Stare Consistenta anterioara cu întreruperea functionarii Bazei de Date BD si restaurarea unei Copii de Referinta din Arhiva de Date a sistemului ABDi (vezi secventa de operatii din partea inferioara a Fig. 6.3.1)

• Procedura se realizeaza cu ajutorul urmatoarelor Colectii de Date:

o O Copie Integrala a Bazei de Date (Copie de Referinta) ABD1 , de preferinta ultima, copie aflata într-o Stare Consistenta

o Tranzactiile RT11 înregistrate în Jurnalul de Tranzactii JT1, între momentul de salvare a Copiei de Referinta utilizata BD1 si Punctul de Control ce se cere restaurat BD11

• Procedura consta din urmatoarele Operatii:

o Restaurarea Starii Consistente a Bazei de Date memorata în Copia de Referinta cea mai apropiata de Incident BD1 si care e stocata în Arhiva de Date ABD1

o Actualizarea Copiei de Referinta BD1 cu toate Tranzactiile RT11 continute în Jurnalul Tranzactiilor JT1 si care au fost înregistrate dupa Salvarea Copiei de Referinta pâna la Punctul de Control Consistent BD11, cel mai apropiat de Incident si care se afla înregistrat tot în Jurnalul Tranzactiilor JT1

• Efectul Procedurii de Refacere este Restaurarea Starii Consistente a Bazei de Date BD11, cea mai apropiata de Punctul de Control la care s-a produs Incidentul

Problema Refacerii Bazelor de Date se complica atunci când se lucreaza cu Operatii de Refacere Cascadate (Operatii a caror executie poate declansa alte Refaceri din Tranzactii Încheiate, care sunt transferate deja în Baza de Date). Evitam aici prezentarea de detalii. Tinem sa dam numai o motivatie pentru restrictia întâlnita în multe SGBD-uri, prin care se interzic Planuri de Executie a Tranzactiilor ce implica Refaceri Cascadate.

Securitatea Bazelor de Date / Refacerea Bazelor de Date 471

6.3.2 Tehnici de Refacere

Tehnicile de Refacere a Bazelor de Date sunt strâns legate de Tehnicile de Actualizare Tranzactionala a Bazelor de Date. Dupa momentul în care sunt transferate în BD modificarile cuprinse într-o Tranzactie si care sunt în prealabil înregistrate în Jurnalul Tranzactiilor, sunt definite doua tehnici de prelucrare:

o Tehnica bazata pe Actualizarea Amânata în care Operatiile de Scriere (Operatiile WRITE) sunt efectuate în BD doar la încheierea Tranzactiei (Operatia COMMIT). Aceasta Tehnica de Actualizare determina aparitia urmatoarelor situatii pentru Refacerea BD (Refacere de tip NO-UNDO / REDO):

§ Tranzactie Neîncheiata (T4 si T5 din Fig. 6.3.2.1)

• BD e nealterata si Refacerea nu trebuie sa efectueze Operatii UNDO în BD, Actualizarile din Tranzactii fiind simplu abandonate

§ Tranzactie Încheiata + Incident în Transferul Actualizarilor în BD (candidate T2 si T3 din Fig. 6.3.2.1)

• BD poate fi Partial Actualizata si Refacerea trebuie sa efectueze Operatii REDO (datorita proprietatii de Idempotenta a Operatiei REDO ea poate fi repetata pentru actualizarile deja efectuate, efectul fiind acelasi ca la o singura executie)

o Tehnica bazata pe Actualizarea Imediata în care operatiile de Scriere sunt efectuate în BD imediat dupa înregistrarea operatiilor WRITE în Jurnalul Tranzactiilor. Aici se desprind doua cazuri, în functie de Protocolul de Actualizare utilizat:

§ Protocol ce încheie Tranzactia numai dupa terminarea tuturor Actualizarilor Imediate (Refacere de tip UNDO / NO-REDO)

• Tranzactie Neîncheiata (T4 si T5 din Fig. 6.3.2.1)

o BD poate fi Partial Actualizata si Refacerea trebuie sa efectueze Operatii UNDO

• Tranzactie Încheiata + Incident (candidate T2 si T3 din Fig. 6.3.2.1)

o BD este Complet Actualizata si Refacerea nu trebuie sa efectueze Operatii REDO

§ Protocol ce încheie Tranzactia înainte de terminarea tuturor Actualizarilor Imediate (Refacere de tip UNDO / REDO

• Tranzactie Neîncheiata (T4 si T5 din Fig. 6.3.2.1)

o BD poate fi Partial Actualizata si Refacerea trebuie sa efectueze Operatii UNDO

• Tranzactie Încheiata + Incident în Transferul Ultimelor Actualizari în BD (candidate T2 si T3 din Fig. 6.3.2.1)

o BD poate fi Partial Actualizata si Refacerea trebuie sa efectueze Operatii REDO

472 Securitatea Bazelor de Date / Refacerea Bazelor de Date

T1

T2

T3

T4

T5

Timp Punct de Control Incident

Tab. 6.3.2.1 Starea Tranzactiilor raportate la momentele de Incident / Punct de Control

In Tab. 6.3.2.2 se da o prezentare succinta a caracteristicilor celor doua Strategii principale utilizate în primul rând în Actualizarea Tranzactiilor în BD si de care se tine apoi cont si în procesul de Refacere a Bazei de Date.

Strategia Executia Tranzactiei

Zona de Memorie

Metoda de Refacere

Nume Algoritm de

Refacere

Starea Tranzactiei în Jurnal în BD din Jurnal în BD

înainte de COMMIT

da nu - - Amânata

NO-UNDO

/ REDO dupa COMMIT

da da - REDO

înainte de COMMIT

da partial ROLLBACK UNDO REDO

UNDO / REDO dupa

COMMIT da da - -

înainte de COMMIT

da total ROLLBACK UNDO

Imediata

UNDO /

NO-REDO dupa COMMIT

da da - -

Tab. 6.3.2.2 Strategii de Refacere a unei Baze de Date

In cele ce urmeaza se revine asupra Tehnicilor de Actualizare din punctul de vedere al Procesului de Refacere a Bazei de Date. Se mentioneaza faptul ca Refacerea la care se refera aceste tehnici vizeaza numai Incidentele Necatastrofale. In cazul Incidentelor Catastrofale vor fi luate în calcul doar Tranzactiile Încheiate care se relanseaza pe noua imagine a BD. 6.3.2.1 Tehnica bazata pe Actualizarea Amânata

Aceasta tehnica utilizeaza o strategie derivata din Protocolul Prioritatea de Scriere a Jurnalului de Tranzactii (vezi sectiunea 6.3.1), fiind considerat o varianta a acestuia.

Securitatea Bazelor de Date / Refacerea Bazelor de Date 473

Strategia consta din urmatoarele Reguli ce trebuiesc respectate:

- O Tranzactie nu poate opera nici-un transfer de date (Imagini Ulterioare) în Baza de Date înainte de Terminarea ei (înscrierea înregistrarii COMMIT în Jurnalul de Tranzactii)

- O Tranzactie nu poate fi Terminata înainte de Încheierea scrierii tuturor înregistrarilor în Jurnalul de Tranzactii (cu fortarea Scrierii Fizice pe suport a Jurnalului)

Principalele caracteristici ale acestei Tehnici de Refacere îi dau si numele NO-UNDO / REDO:

o Datele transferate din Jurnalul de Tranzactii în Baza de Date nu mai pot si nici nu mai trebuie refacute cu comanda UNDO (pentru Planuri Tranzactionale Necascadate)

o Operatia REDO este utilizata pentru cazurile de incident survenite în faza de transfer a Imaginii Ulterioare (datele noi actualizate) din Jurnalul de Tranzactii în Baza de Date (operatia declanseaza Reluarea Operatiilor de Transfer)

6.3.2.2 Tehnica bazata pe Actualizarea Imediata

Pentru a face cât mai repede vizibile actualizarile unei Tranzactii, în aceasta tehnica transferul Valorilor Noi din Jurnalul de Tranzactii în Baza de Date nu mai este Amânata pâna la Terminarea Tranzactiei, ci este efectuata Imediat ce este întâlnita o Operatie de Actualizare (Operatie WRITE).

Întrucât scrierea Jurnalului de Tranzactii îsi mentine si aici prioritatea, pentru a se putea garanta posibilitatea de Refacere a Bazei de Date, Protocolul Prioritatea de Scriere a Jurnalului de Tranzactii este utilizat si în acest caz.

Noutatea consta în faptul ca trebuie luate masuri de precautie pentru Refacerea continutului alterat al Bazei de Date în cazul esuarii Tranzactiei dupa efectuarea Actualizarilor Imediate, care preced Terminarea Tranzactiei. Refacerea va fi facuta prin efectuarea unei Operatii de ROLLBACK lansata asupra Tranzactiei memorate în Jurnalul Tranzactiilor si care se traduce în Operatii UNDO asupra Bazei de Date.

Se desprind doua variante ale acestei Strategii:

o Varianta UNDO / REDO – daca se asigura faptul ca toate Operatiile de Scriere ale unei Tranzactii sunt efectuate în Baza de Date înainte de Terminarea Tranzactiei (prin lansarea Operatiei COMMIT), atunci nu mai e necesara Operatia REDO, utila numai în cazul întreruperii transferului Imaginii Ulterioare din Jurnalul de Tranzactii în Baza de Date, faza care acum lipseste

o Varianta UNDO / REDO – daca, din motive de urgentare a executiei Operatiilor Tranzactionale, se permite Terminarea Tranzactiei înaintea încheierii ultimelor actualizari în Baza de Date, atunci este necesara utilizarea ambelor Operatii de Refacere, UNDO si REDO (vezi si sectiunea 6.3.2), ajungându-se la cea mai complexa Tehnica de Refacere

474 Securitatea Bazelor de Date / Refacerea Bazelor de Date

PPAARRTTEEAA aa 77--aa

BBAAZZEE ddee DDAATTEE EEVVOOLLUUAATTEE

Aceasta Parte adauga noi Concepte dezvoltate în cadrul SBD sau adoptate de acestea din alte domenii, dar care îsi gasesc o aplicabilitate directa în problematica Bazelor de Date. Ele sunt grupate în trei Grupe de Sectiuni:

7.1 – Baze de Date Deductive – sunt rememorate

conceptele referitoare la Limbajul Logic, utilizat în SBD pentru definirea Limbajelor Predicative (SQL, QBE). Se regasesc Formulele Bine Construite, care vor evolua spre Forme Clauzale si Clauze Horn, toate adecvate metodelor de reprezentare Predicativa practicata în Bazele de Date Relationale. Modelele Interpretative si Inferentiale prezentate ca Viziuni diferite ale acelorasi BDR pregatesc prezentarea Metodelor de abordare a Deducerii în BD.

7.2 – Baze de Date Distribuite – sunt trecute în revista

Tehnicile si Metodele de Proiectare Distribuita (Fragmentare, Replicare, Alocare), precum si de asigurare a asigurare a Multiaccesului Tranzactional Distribuit, corelat cu Functiile de Refacere a BDS.

7.3 – Baze de Date Obiectuale – sub semnul continuarii

promovarii conceptelor de Independenta se introduc conceptele de Stari Structurale, Metode si Mesaje utilizate în BDO. Este dezbatuta problema Identitatii si Referirii în contextul Claselor de Obiecte. Mostenirea, Polimorfismul si Poliinstantierea sunt de asemenea tratate.

O sectiune de Concluzii încheie Partea a 7-a.

7.4 – Consideratii Critice – o comparatie finala între viziunile Relationale si Obiectuale referitoare la Structurile de Date schiteaza locul pe care autorul îl vede rezervat fiecarui Model de Date în viitorul SBD. Conlucrarea lor printr-o specializare a fiecaruia este si Concluzia Finala.

Baze de Date Evoluate 475

7 Baze de Date Evoluate

Sectiunea prezenta urmareste sa contureze, prin câteva subiecte speciale, ce viitor au conceptele dezvoltate de Sistemele cu Baze de Date. Se vor gasi poate raspunsuri la întrebarea daca preocuparea legata de sensurile mai adânci ale acestor concepte merita si în prezent si mai ales în viitor atentie, sau daca sunt epuizate si învechite, amenintând sa se transforme, pe lunga cale a progresului, din Stimulent în Frâna. In goana dupa noutate multe din preocuparile Bazelor de Date au primit si primesc în continuare denumiri noi pentru a suscita interesul lumii informatice. Cunoastem însa tot atâtea reveniri la matca din care au izvorât aceste idei si care prin fecunditatea ei le ajuta în continuare sa rodeasca. Afirmam acestea convinsi fiind ca în absenta unei Surse de Date orice sistem de procesare ramâne în sfera exercitiului. Desigur ca adaptarea Surselor de Date la necesitatile specifice fiecarui domeniu va ramâne în permanenta în sarcina proiectantilor specializati. Am orientat prezenta lucrare spre Perenitatea Conceptelor si nu a Succeselor Actuale ale unor Termeni provenind din domeniul SBD, pentru a putea vorbi nu numai despre Trecut si Prezent, ci si despre Viitor si mai ales despre legatura dintre ele. Tratarea subiectelor speciale nu îsi propune o intrare în detalii tehnice, ci urmareste în primul rând dezvoltarea Conceptelor Fundamentate din domeniul Bazelor de Date în cadrul noilor constructii adaptate ritmului accelerat de evolutie a tehnologiei de prelucrare a informatiilor. Subiectele speciale vor trata urmatoarele tipuri de Baze de Date:

• Baze de Date Deductive

• Baze de Date Distribuite

• Baze de Date Obiectuale

Vom urmari în mod special în fiecare prezentare felul în care aceste noi tipuri de Baze de Date continua sa dezvolte conceptul de Independenta, a carui importanta consideram ca am argumentat-o substantial pâna în acest punct.

- Bazele de Date Deductive vor dezvolta aspectul de mentinere a Independentei Datelor Elementare memorate în Baza de Date prin dezvoltarea conceptului de Materializare a Datelor Virtuale prin Calcul Logic. Desi arsenalul pus în miscare este de data aceasta mult mai amplu, în final, Procedurile de Deductie vor actiona asemenea oricaror Functii de Calcul în determinarea valorii Datelor Virtuale.

- Bazele de Date Distribuite vor îmbogati Conceptul de Independenta prin adaugarea Independentei de Localizare a Surselor de Date, care nu face decât sa îmbogateasca Nivelul Intern de reprezentare a datelor cu noi Module de Acces Distribuit la Componentele (Tabele, Tuple, Proceduri Stocate etc.) repartizate pe diferite Statii. Introducerea în proiectare a operatiilor de Fragmentare si în arhitectura a Dictionarului de Localizare vor asigura aceste noi facilitati.

- Bazele de Date Obiectuale vor contribui sporit la îmbogatirea conceptului de Independenta prin regruparea Structurilor de Date cu Metodele de Prelucrare adecvate si construirea Obiectului ca Unitate Independenta prin excelenta. Conceptele de Proceduri Declansate migrate în Bazele de Date sunt un demn precursor al acestui Constructor, care ofera si azi baza reala de implementare a Nivelului Obiectual al unei BD.

476 Baze de DateEvoluate / Baze de Date Deductive

7.1 Baze de Date Deductive

In stradania de a creste Gradul de Independenta dintre diferitele Nivele Abstracte de Reprezentare si prelucrare a informatiilor si datelor, Modelul Relational a introdus în cadrul Nivelului Extern (nivelul de interfata dintru Utilizator si Structura de Date), conceptul de Materializare a Datelor. Cu ajutorul acestui concept se realizeaza o apropiere între notiunea de Data si Procedura , cea din urma, procedura, putând sa fie privita ca o Data Virtuala, prin prisma rezultatului executiei prelucrarii. Prin aceasta procedura poate sa fie memorata în Baza de Date pentru a descrie acele date care se calculeaza numai în momentul Invocarii Procedurii (al Apelului Procedurii). Materializarea datelor poate fi realizata prin proceduri care apeleaza la Calcul Aritmetic sau la Calcul Logic (vezi si sectiunea 2.1.1).

Acestei preocupari i-a iesit în întâmpinare interesul pentru dezvoltarea Sistemelor de Prelucrare bazate pe Calculul Logic (Programarea Logica), care au ajuns repede la necesitatea de a dezvolta o componenta proprie de Baza de Date, destinata a memora atât Faptele cât si Cunostintele necesare generarii unor Noi Fapte.

La aceasta confluenta au fost dezvoltate numeroase produse si metode specifice de prelucrare, dintre care amintim:

§ Baze de Date Logice

§ Modele de Date Inferentiale

§ Sisteme Expert

§ Baze de Date Deductive

§ Baze de Cunostinte

§ Definirea si Prelucrarea Logica Recursiva a Cererilor

§ Etc.

Principala noutate promovata a constat în construirea unei noi Viziuni asupra Sursei de Date a Sistemelor de Prelucrare [DATE95]:

o Sistemele cu Baze de Date (SBD) – se bazeaza pe Viziunea Interpretativa (de Model) asupra BD (Model-Theoretic View), având urmatoarele caracteristici de baza:

§ BD este o Colectie Structurata de Obiecte Heterogene (Valori de Domenii, Instante de Relatii, Restrictii de Integritate)

§ Raspunsul la Cereri se obtine prin Evaluarea unor Expresii (Formule) folosind informatiile din BD

o Sistemele cu Baze de Date Deductive (SBDD) – se bazeaza pe Viziunea Inferentiala (Proof-Theoretic View), având urmatoarele caracteristici de baza:

§ BD este o Colectie de Obiecte Omogene – Axiome , grupate în Axiome de Baza si Reguli de Deductie, denumite si Axiome Deductive

§ Raspunsul la Cereri se obtine prin Demonstrarea lor ca fiind o Consecventa Logica a Axiomelor admise (Raspunsul e privit ca o Teorema ce trebuie demonstrata)

Baze de DateEvoluate / Baze de Date Deductive 477

Pentru a putea utiliza facilitatile puse la dispozitie de Calculul Logic, trebuie sa se Defineasca si sa se Implementeze un Limbaj Logic (vezi sectiunea 4.2.4.5.2.1) si în continuare un Limbaj Predicativ. Modelul Relational a stimulat implementarea Limbajelor Predicative pentru regasirea si actualizarea informatiilor prin Limbajele de Manipulare a Datelor (LMD), dezvoltând cele doua variante de limbaje:

o Calculul Tuplelor – reprezentat de Limbajul SQL (vezi sectiunea 4.2.4.5.2.2)

o Calculul Domeniilor – reprezentat de Limbajul QBE (vezi sectiunea 4.2.4.5.2.3) Pentru a ilustra însa noutatea de abordare a Calculului Logic ca Sistem Deductiv se face în prealabil o prezentare a câtorva Concepte de Baza referitoare la Mecanismul de Inferenta bazat pe Fapte si Reguli de Deductie. 7.1.1 Inferenta bazata pe Calculul Propozitional

Reprezentând doar o baza pentru fundamentarea Inferentei ce va fi utilizata în Bazele de Date Deductive BDD, prezentarea Calculului Propozitional face o introducere necesara pentru familiarizarea cu conceptele de Deducere în Logica Formala. Calculul Propozitional va servi ca un instrument preliminar în Procedurile Automatizate de Rationare. Pentru început se reamintesc din Algebra Booleana urmatoarele Legi ce vor fi apelate în continuare:

o Legile Distributivitatii:

f ∩ (g ∪ h) = (f ∩ g) ∪ (f ∩ h)

f ∪ (g ∩ h) = (f ∪ g) ∩ (f ∪ h)

o Legile lui De Morgan:

¬ (f ∩ g) = ¬ f ∪ ¬ g

¬ (f ∪ g) = ¬ f ∩ ¬ g

Expresiile Generale de Calcul, care sunt prezente în orice Sistem de Calcul Simbolic, se gasesc în cazul de fata aplicate, în mod particular, la Calculul Valorii de Adevar (Adevarat sau Fals) al Formulelor. Aceste Formule vor fi alcatuite cu elementele Propozitiilor Logice definite mai jos si anume:

o Termeni – Orice Expresie Logica ce contine doar Constante acestea fiind reprezentate în cazul BDD de Valorile din Domeniile pe care sunt definite Relatiile. Însusirile comune Termenilor sunt:

• Nu au atasati Cuantificatori

• Daca sunt legati prin Conectori Logici, atunci sunt cuprinsi în paranteze

• Pot fi evaluati univoc cu Valoare de Adevar (Falsa sau Adevarata)

Exemple:

Beneficiarul 1 are Codul B1 – este Termen

Beneficiarul cu Codul B1 are sediul în Orasul O1– este Termen

478 Baze de DateEvoluate / Baze de Date Deductive

Beneficiarul cu Codul B1 a contractat Produsul cu Codul P1 – este Termen

Beneficiarul cu Codul B1 a contractat unele Produse – nu este Termen (contine Cuantificatorul „unele”)

Beneficiarul cu Codul B1 a contractat toate Produsele – nu este Termen (contine Cuantificatorul „toate”)

o Formule – Formulele în Calculul Propozitional (mai general si în Calculul Predicatelor – vezi sectiunea 7.1.2) utilizat în SBD reprezinta în primul rând o Expresie Conditionala ce defineste Rezultatul unei Cereri.

Definirea Formala a Formulei este urmatoarea:

Formula

: : = Termen

| NOT Termen

| Termen AND Formula

| Termen AND Formula

| Termen ⇒ Formula

Termen

: : = Formula - Atomica

| (Formula)

Evaluarea Formulelor se face în conformitate cu Valoarea de Adevar a Termenilor constituenti si a Tabelelor de Adevar asociate Conectorilor (Operatiilor Logice) ce leaga Termenii. Urmatoarele explicatii completeaza Definirea Formala:

• O Formula - Atomica este un Termen care nu include Conective si nu e încadrata în Paranteze

• Simbolul ⇒ reprezinta Conectorul Implicatiei Logice; este Adevarata urmatoarea Echivalenta de Expresii:

(f ⇒ g) ⇔ ( ¬ f ∪ g)

Pentru transpunerea Implicatiei Logice în Limbaj de Programare se poate folosi si corespondenta:

IF f THEN g

• Se adopta Regulile de Precedenta uzuale pentru Conectori si anume:

NOT precede AND precede OR precede ⇒

o Reguli de Inferenta – ofera baza de deductie a unor noi expresii în Calculul Propozitiilor. Forma generala a Regulilor de Deductie este:

¦ f ⇒ g

Baze de DateEvoluate / Baze de Date Deductive 479

unde se adopta pentru Semnificatia Simbolului ¦ urmatoarea afirmatie:

Este întotdeauna Adevarat

Simbolul ¦ este utilizat în Regulile de Deductie ca Metainstructiune Declarativa (Declaratie despre Declaratii)

Pot fi construite mai multe Seturi de Reguli de Deductie. (Pentru detalii legate de posibilitatile de alegere a Axiomelor Principale si a Regulile Principale de Inferenta în Calculul Propozitiilor vezi [STIH99] ). Prezentam în continuare un asemenea Set de Reguli propus în [DATE95] .

Reguli de Deducere

Numar Continut Denumire

1. ¦ (f ∩ g) ⇒ f Transformare ∩ ⇒

2. ¦ f ⇒ (f ∪ g) Transformare ⇒ ∪

3. ¦ ((f ⇒ g) ∩ (g ⇒ h)) ⇒ (f ⇒ h) Tranzitivitate ⇒

4. ¦ (f ∩ (f ⇒ g)) ⇒ g Modus Ponens

5. ¦ (f ⇒ (g ⇒ h)) ⇒ ((f ∩ g) ⇒ h) Transformare ⇒ ∩

6. ¦ ((f ∪ g) ∩ (¬ g ∪ h)) ⇒ (f ∪ h) Rezolutie

Tab. 7.1.1. Set de Reguli de Deducere în Calculul Propozitional

o Deducere – problema Deducerii în Calculul Propozitiilor consta în demonstrarea faptului ca o Formula data, care joaca rol de Concluzie:

g

este o Consecventa Logica a unui set de alte Formule, care joaca rol de Premize:

f 1 , f 2 , .. , f n

In expresie simbolica si apelând la o noua Metainstructiune Declarativa + , ce corespunde afirmatiei :

Este o Consecventa Logica

Deducerea se transcrie astfel:

f 1 , f 2 , .. , f n + g

care se citeste si astfel:

g este Deductibila din f 1 , f 2 , .. , f n

480 Baze de DateEvoluate / Baze de Date Deductive

Deducerea se poate realiza prin mai multe metode:

§ Înlantuirea Înainte – pornirea de la Premize si aplicarea Regulilor de Deductie asupra Premizelor si apoi în mod repetat, în mai multi pasi, asupra Premizelor si a Formulelor Deduse pâna la ajungerea la Concluzie

§ Adoptarea unei noi Premize – adaugarea la Premizele Initiale a unei Formule din Concluzie si deducerea celorlalte Formule ramase din Concluzie

Daca:

Concluzia g e de forma p ⇒ q

se adauga:

p la Premizele f 1 , f 2 , .. , f n

si se încearca Deducerea lui:

q

§ Înlantuirea Înapoi – se înlocuieste Premiza cu Concluzia Negata si Concluzia cu Premiza Negata si se încearca deducerea Noii Concluzii

In loc de Deducerea lui:

p ⇒ q

Se încearca Deducerea lui:

¬ q ⇒ ¬ p

§ Reducerea la Absurd – se încearca deducerea unei Contradictii prin Negarea Concluziei

In loc de Deducerea Directa a lui:

p ⇒ q

Se încearca Deducerea Contradictiei lui:

p ∩ ¬ q

care va determina indirect ca Adevarata Implicatia initiala:

§ Rezolutia – se aplica Regula 6 din Tab. 7.1.1

Se remarca capacitatea Rezolutiei de a elimina Subformule, proprietate care va fi utilizata si în Calculul Predicatelor. Ea consta în urmatoarea derivare:

Fiind date Formulele:

f ∪ g

¬ g ∪ h

Se poate deriva Formula:

Baze de DateEvoluate / Baze de Date Deductive 481

f ⇒ h

Sau, considerând pe h Adevarat, din Formulele:

f ∪ g

¬ g

se poate deriva direct Formula:

f

Exemplu: Fie Formulele din Calculul Propozitional:

A, B, C, D

Sa încercam Deducerea urmatoarei Consecvente Logice:

A ⇒ ((B ⇒ C) ∩ (¬ D ∪ A) ∩ B) + D ⇒ C

Pasii de Deductie sunt urmatorii:

§ Adoptarea unei noi Premize prin Reducerea la Absurd

• Adoptarea Concluziei Negate ca Premiza

• Scrierea Premizelor pe câte o linie separata (Liniile se considera legate prin Conjunctie)

A ⇒ (B ⇒ C)

¬ D ∪ A

B

¬ (D ⇒ C)

§ Conversia fiecarei linii în Forma Normala Conjunctiva

• Eliminare ⇒ (Regula 2)

• Aplicarea Legilor Distributivitatii si ale lui De Morgan

¬ A ∪ ¬ B ∪ C

¬ D ∪ A

B

D ∩ ¬ C

• Retranscrierea pe linii separate a Formulelor legate prin Conjunctie (Formulele din linia a 4-a)

¬ A ∪ ¬ B ∪ C

¬ D ∪ A

B

482 Baze de DateEvoluate / Baze de Date Deductive

D

¬ C

§ Aplicarea Legii Rezolutiei (eliminarea Formulelor ce apar si negate)

• Prima aplicare

¬ A ∪ ¬ B ∪ C

¬ D ∪ A ¬ D ∪ ¬ B ∪ C

B B

D D

¬ C ¬ C

• A doua aplicare

¬ D ∪ ¬ B ∪ C

B ¬ D ∪ C

D D

¬ C ¬ C

• A treia aplicare

¬ D ∪ C

D C

¬ C ¬ C

• A patra aplicare

C

¬ C ∅ Ajungerea la un Rezultat Vid denota infirmarea Ipotezei de Reducere la Absurd si prin aceasta verificarea Formulei de Demonstrat:

A ⇒ ((B ⇒ C) ∩ (¬ D ∪ A) ∩ B) + D ⇒ C

7.1.2 Inferenta bazata pe Calculul Predicativ

Principala noutate introdusa de Calculul Predicativ consta în admiterea în cadrul Formulelor a Cuantificatorilor, care cresc valoarea adevarurilor dovedite, extinzând sfera aplicabilitatii Procesului de Inferenta. Valoarea de Adevar va trebui în acest caz dovedita prin inspectia Multimii de Fapte (Tuple) pe care se extind afirmatiile continute în Formulele Cuantificate. Modul de Inspectie al Multimii de Fapte va depinde de Natura Cuantificatorilor (Existentiali sau Universali) atasati Formulelor utilizate în Calculul Predicativ (vezi sectiunea 4.2.4.5.2.2.2).

Baze de DateEvoluate / Baze de Date Deductive 483

7.1.3 Descrierea Formala a unui Limbaj Predicativ 7.1.3.1 Predicate Definitie:

Predicatul – este o Functie cu Valoare de Adevar, care returneaza Valorile Adevarat sau Fals pentru fiecare set de Argumente cu care este invocata.

Exemplu: Functia cu doua Argumente > (x,y) returneaza Adevarat, daca x > y, sau Fals daca x ≤ y.

Numarul de Argumente al Predicatului îi da n-aritatea. Se poate spune ca o Propozitie Logica poate fi privita ca un Predicat de n-aritate zero.

Prezenta Argumentelor în definirea Predicatului defineste proprietatea acestuia de Nesaturare si prin aceasta îi confera puterea de generalizare, prin concentrarea în reprezentare a unui numar sporit de cazuri concrete [FREG77].

Predicatele ce descriu Relatia Naturala de Ordine ”=”, ”>”, ”<” sunt în general încorporate în Sistemele Formale ca Predicate Implicite (recunoscute si tratate de Sistem), Utilizatorul având însa posibilitatea redefinirii lor sau a definirii unor noi Predicate.

In Sistemele cu Baze de Date Predicatele corespund Relatiilor, Lista Atributelor de Definitie jucând rolul de Argumente. Tuplele Relatiilor vor reprezenta Instante ale Predicatului, ca atare Fapte, în legatura cu care Proprietatea afirmata de Predicat poate fi evaluata ca Adevarata. Se poate spune ca Predicatele în SBD definesc Intensional Relatiile, reprezentând informal semnificatia acestora. (vezi si sectiunea 4.2.4.3). 7.1.3.2 Formule Bine Construite

Prezenta sectiune va extinde notiunea de Formula utilizata în Calculul Propozitional, apelându-se la expresia de Formula Bine Construita (FBC), expresie definita si cu ocazia prezentarii Limbajelor de Manipulare a Datelor Relationale (sectiunea 4.2.4.5).

Pentru Descrierea Formala a unui Limbaj Predicativ se apeleaza la un Set de Reguli de Definire, care sunt grupate în lista din Tab. 7.1.3. Legat de notiunile enumerate se fac urmatoarele precizari:

o Termenul poate fi privit simplu ca o Instanta de Predicat (eventual negata)

§ Fiecare Argument e reprezentat de:

• O Constanta

• O Variabila

• O Functie, având drept Argumente aceleasi elemente ca în cazul Argumentelor de Predicate)

§ Parantezele se omit pentru Predicatele de n-aritate zero

§ Functiile introduc posibilitatea de declarare a Expresiilor de Calcul

o Regulile de Precedenta se preiau din Calculul Propozitional

Baze de Date Deductive 484

Sectiune Regula

Capitol Subcapitol Numar Continut

1. Un Simbol de Constanta sau Variabila sunt Termeni

Definire Termeni

- 2. Daca f e Simbol de Functie n-ara si t1 , t2, .. tn sunt Termeni

Atunci f (t1, t2, .. tn) e Termen

3. Daca P e Simbol de Predicat n-ar si t1 , t2, .. tn sunt Termeni

Atunci P (t1, t2, .. tn) e Formula Atomica

4. O Formula Atomica e Formula

5. Daca F1 si F2 sunt Formule

Atunci F1 ∩ F2 , F1 ∪ F2 , ¬ F1 sunt Formule

6. Daca F1 e Formula

Atunci ∀ x F1 si ∃ x F1 sunt Formule

Definire Formule

(Fraze)

-

7. Daca F1 e Formula

Atunci ( F1) e Formula

8. ¬ (F1 ⇒ ¬ F2) se substituie cu F1 ∩ F2 Transformare

Operatori Logici 9. (¬ F1 ⇒ F2) se substituie cu F1 ∪ F2

Simplificare Formule

Transformare

Cuantificatori

10. ¬ ∀ x ¬ F1 se substituie cu ∃ x F1

Tab. 7.1.3. Lista Regulilor de Definire a FBC într-un Limbaj Predicativ

Baze de DateEvoluate / Baze de Date Deductive 485

o Variabilele care apar în Limbajul Predicativ pot fi (sectiunea 4.2.4.5.2.2.2):

§ Libere - Variabile fara Cuantificatori (Necuantificate)

§ Legate - Variabile cu Cuantificatori (Cuantificate)

o Formulele care apar în Limbajul Predicativ pot fi :

§ Deschise (Libere) - daca cel putin o Variabila este Libera

§ Închise (Legate) - daca toate Variabilele sunt Legate

Pentru uniformizarea expresiilor care apar în Calculului Logic, formulele cu care se opereaza vor fi exprimate în Forma Normala Prenex. Aceasta forma de exprimare este urmatoarea:

Q1 x1 , Q2 x2 , ... , Qn xn M

unde:

Qi - reprezinta Cuantificatori

Xi - reprezinta Variabile

M - reprezinta Matricea Formulei în exprimare Conjunctiva sau Disjunctiva

Regulile de Definire a constructiilor acceptate în expresiile unui Limbaj Predicativ se grupeaza în Definirea Formulelor, si Simplificarea Formulelor (transformarea Formulelor prin aplicarea Regulilor de Substituire a Operatorilor Logici si a Cuantificatorilor) . 7.1.4 Interpretare si Model

Pentru a putea fi utilizat în practica, un Sistem Formal (reprezentând partea Sintactica) trebuie sa fie completat prin atasarea unei Interpretari (care sa reprezinte partea Semantica). Interpretarea este extrasa din Spatiul Informatiilor, care este purtatorul de Semnificatii, datorita faptului ca reprezinta Domeniul de Interes al Utilizatorului. Ca o consecinta a capacitatii sale generalizatoare, un Sistem Formal va putea fi utilizat într-o multime de cazuri concrete, deci i se vor putea atasa tot atâtea Interpretari posibile. 7.1.4.1 Interpretarea Formulelor

Pentru a atasa o Interpretare unui ansamblu de Formule Bine Construite trebuie efectuate urmatoarele operatii :

o Selectarea unei Multimi de Valori D, numit Domeniul de Valori, în care Variabilele iau Valori, în forma unor Elemente Concrete, bine definite, ce vor reprezenta Constantele Sistemului Formal; provenind din Spatiul Informatiilor, Domeniul de Valori defineste Universul de Discurs al sistemului

o Atribuirea de Valori diferitelor Simboluri, dupa cum urmeaza:

§ La fiecare Simbol de Constanta - un Element din D

§ La fiecare Simbol de Functie n-ara - o Functie n-ara definita pe D n cu valori în D

486 Baze de DateEvoluate / Baze de Date Deductive

§ La fiecare Simbol de Predicat - o Relatie pe D n

Exemplu:

Fie Predicatul:

> (x, y)

si fie urmatoarele Formule Bine Construite (FBC):

f1 c2 > c1

f2 c2 > c3

f3 ∃ x (x > c2)

f4 ∀ x (x > c2)

unde:

c1, c2, c3 – sunt Constante

x, y – sunt Variabile

Varianta 1 - Sa consideram o prima Interpretare a FBC:

- Universul de Discurs este reprezentat de Multimea Numerelor Întregi :

0, 1, 2, 3

- Se Atribuie Constantelor urmatoarele Valori:

c1 = 1

c2 = 2

c3 = 3

- Se acorda Predicatului semnificatia de Relatie de Ordine Naturala a Numerelor

- Se Evalueaza FBC:

f1 2 > 1 - adevarata

f2 2 > 3 - falsa

f3 ∃ x (x > 2) - adevarata

f4 ∀ x (x > 2) - falsa

Varianta 2 - Sa consideram o a doua Interpretare a FBC:

- Universul de Discurs este reprezentat de Multimea Nivelelor de Securitate a Datelor într-un SBD (vezi sectiunea 6.1.2):

Nivel 0, Nivel 1, Nivel 2, Nivel 3

- Se Atribuie Constantelor urmatoarele Valori:

c1 = 1

c2 = 2

c3 = 3

Baze de DateEvoluate / Baze de Date Deductive 487

- Se acorda Predicatului semnificatia de Relatie de Ordine Naturala a Nivelelor de Securitate, descrisa ca mai jos:

• Nivel 3 - Date Strict Secrete (SS)

• Nivel 2 - Date Secrete (SC)

• Nivel 1 - Date Clasificate (CL)

• Nivel 0 - Date Neclasificate (NC)

- Se Evalueaza FBC:

f1 2 > 1 - adevarata

f2 2 > 3 - falsa

f3 ∃ x (x > 2) - adevarata

f4 ∀ x (x > 2) - falsa

Varianta 3 - Sa consideram o a treia Interpretare a FBC:

- Universul de Discurs este reprezentat de Multimea Numerelor Întregi:

0, 1, 2, 3

- Se Atribuie Constantelor urmatoarele Valori:

c1 = 1

c2 = 2

c3 = 3

- Se acorda Predicatului semnificatia de Relatie de Ordine Fuzzy a Numerelor si anume: ”Semnificativ mai mare”, fixat prin expresia:

x > 2y

- Se Evalueaza FBC:

f1 2 > 1 - falsa

f2 2 > 3 - falsa

f3 ∃ x (x > 2) - adevarata

f4 ∀ x (x > 2) - falsa

Nu întâmplator FBC alese pentru Evaluare au fost toate Formule Închise. Motivul trebuie gasit în faptul ca fiecare Formula pentru a putea sa fie Univoc Evaluata trebuie sa conduca la un singur raspuns (Adevarat sau Fals), ceea ce Formulele Deschise nu îl asigura. De exemplu Formula Deschisa :

x > 1

poate fi Evaluata doar prin scanarea Universului de Discurs si efectuarea Evaluarii pentru fiecare Element în parte. Rezultatul va fi întotdeauna o Data de Tip Multime , chiar atunci când Multimea e Vida sau cu un Element, fiind reprezentata de Multimea Elementelor care verifica Predicatul.

488 Baze de DateEvoluate / Baze de Date Deductive

Interpretarile în care Toate FBC sunt Evaluate ca Adevarate formeaza un Model.

Exemplu:

Nici-o Interpretare din exemplele anterioare nu reprezinta un Model datorita existentei Valorilor de Adevar False. Interpretarea întâia poate reprezenta un Model pentru urmatorul Set de FBC:

f1 2 > 1 - adevarata

f2 3 > 2 - adevarata

f3 ∃ x (x > 2) - adevarata

f4 ∀ x (x > 2 ∪ ¬ (x > 2 )) - adevarata

Ca si în cazul Interpretarilor, în general pot exista mai multe Modele pentru un Set de FBC. Un asemenea exemplu este oferit de o Baza de Date, care în Viziunea Interpretativa permite adaugarea de noi Fapte care satisfac Axiomele de Deductie dar nu satisfac Conditia de Minimalitate a Modelului (vezi si sectiunea 7.1.4.3). 7.1.4.2 Evaluarea Formulelor Bine Construite

Interpretarea Formulelor creeaza un Cadru Semantic care permite sa se acorde fiecarui Termen al Limbajului Formal o Valoare de Adevar. Aceasta determinare a Valorilor de Adevar pentru diferitele Formule ale Limbajului se efectueaza pe baza Regulilor de Evaluare, care sunt sistematic prezentate în continuare. Evaluarea trebuie sa cuprinda toti Termenii care pot intervenii în Formulele Bine Construite. Regulile de Evaluare sunt descrise cu ajutorul urmatoarelor Proceduri Generale de Evaluare:

o Pentru Formulele Închise (Legate):

§ Evaluarea Operatorilor Logici - se face conform cu Tabelele de Adevar

§ Evaluarea Predicatelor - un Predicat P (X 1, X 2, ... , X n) e considerat Adevarat pentru o anume Instantiere t, a Variabilelor X i cu Valorile a i din D, daca în urma acestei înlocuiri se obtine o Tupla r (a 1 , a 2 , ... , a n) din Relatia R ( X 1, X 2, ... , X n ) , asociata Predicatului P; în caz contrar Predicatul e considerat Fals

§ Evaluarea Cuantificatorilor, cu X Variabila Legata – conform expresiilor de mai jos:

D a

) a ( F ) X ( F X

D a

) a ( F ) X ( F X

i

i

i

i

U

I

∈≡∃

∈≡∀

o Pentru Formulele Deschise (Libere):

§ Formula Libera F cu n Variabile Libere e Adevarata daca Relatia n-ara pe care o defineste prin Instantierea Variabilelor Libere (înlocuirea Variabilelor cu Valori a i din D), face parte din D n; altfel ea e Falsa

Baze de DateEvoluate / Baze de Date Deductive 489

7.1.4.3 Model

Asa dupa cum s-a anticipat în sectiunea precedenta, definirea unui Model este strâns legata de Semantica acordata datelor din BD, care permit atasarea la o multime de Formule Bine Construite si o Interpretare adecvata. Legat de aceasta încarcare cu semnificatie a FBC se formuleaza urmatoarele definitii:

Definitie:

Modelul – reprezinta o Interpretare a unei Multimi Φ de Formule Bine Construite, în care Toate FBC sunt evaluate ca Adevarate, potrivit acceptiunilor impuse de aceasta Interpretare.

Definitie:

Model Minimal pentru o Multime de Formule Bine Construite Φ – reprezinta un Model în care nici-un Fapt nu-si poate modifica Valoarea de Adevar si sa mentina proprietatea de Model a Noii Interpretari.

Definitie:

Consecventa – Formula F este o Consecventa a lui Φ , daca este Adevarata în toate Modelele lui Φ (potrivit acceptiunilor tuturor Interpretarilor Posibile). Ea se noteaza astfel:

Φ ¦ F

cu semnificatia deja prezentata pentru Simbolul ¦ :

Este întotdeauna Adevarat

Determinarea adevarului asertiunii din definitia Consecventei e dificila datorita numarului foarte mare de Interpretari posibile. Pentru simplificare se construieste o Teorie Abstracta în forma Calculului de Predicate, care reprezinta un Sistem Formal.

Definitie:

Calculul de Predicate – este un Sistem Formal, denumit si Teorie Abstracta (T), ce contine:

§ Un Limbaj Logic de forma celui definit anterior

§ O multime de Axiome (Fapte adevarate)

§ O multime de Reguli de Deductie (Legi ce permit deducerea de noi Formule)

In cadrul acestei Teorii Abstracte se poate defini notiunea de Consecventa Logica, care sta la baza Deducerii de noi Adevaruri din Adevarurile deja cunoscute.

Definitie:

Consecventa Logica – Formula F este o Consecventa Logica a lui Φ daca este Deductibila din Φ . Ea se noteaza astfel:

490 Baze de DateEvoluate / Baze de Date Deductive

Φ + F

Pe baza definitiilor anterioare se poate afirma ca un Sistem Formal de genul Calculului de Predicate poate fi privit ca o Teorie Abstracta definita de o Multime de FBC, ordonate de o Relatie de Deductibilitate (+ ):

T = < Φ , + >

Definitie:

O Teorie Interpretata ( Ti ) - reprezinta un Sistem Sintactic si Semantic, care contine o Teoria Abstracta ( T ), la care se adauga o Multime de Postulate de Interpretare ( I ).

Daca exprimam Multimea de FBC Φ prin componentele sale:

Φ = Φ b ∪ Φ d

unde:

Φ b – reprezinta Axiomele de Baza

Φ d – reprezinta Axiomele Deductive

atunci Teoria Interpretata Ti ia forma:

Ti = < T, M >

unde:

T – reprezinta o Teorie Abstracta privita ca o Multime de FBC Φ

M - reprezinta Modelul atasat Teoriei Abstracte T

In final putem rescrie si aceste ultime simboluri prin expresiile:

T = < Φ b , + >

M = < Φ b , I , + >

unde:

I – reprezinta Postulatele de Interpretare ale Axiomelor de Baza Φ b

O Teorie T , exprimata prin ansamblul de FBC Φ si interpretarea I este:

o Valida – daca tot ce se Deduce e si Adevarat

Φ + F ⇒ Φ ¦ F

o Completa – daca tot ce e Adevarat se poate si Deduce

Φ ¦ F ⇒ Φ + F

Baze de DateEvoluate / Baze de Date Deductive 491

7.1.5 Forme Clauzale

Asa dupa cum Formulele din Calculul Propozitional pot fi convertite în Forme Normale Conjunctive (vezi sectiunea 7.1.3.2), Formulele din Calculul Predicativ vor putea fi convertite în Forme Clauzale, ce pot fi privite ca o Extensie a Formelor Normale Conjunctive. Rezultatul acestei conversii consta în pregatirea Expresiilor cu FBC pentru aplicarea Regulii de Rezolutie în vederea construirii sau verificarii Deductiilor în Bazele de Date (vezi Tab. 7.1.1).

Întrucât scopul prezentarilor din sectiunile consacrate Bazelor de Date Deductive este cel de a scoate în evidenta modul de utilizare a instrumentului de Deducere In Bazele de Date si nu de fundamentare a cestuia, vom prezenta utilizarea transformarilor în Forme Clauzale a FBC pe baza unui exemplu. Exemplu:

Sa se normalizeze prin transformare în Forme Clauzale urmatoarea expresie, reprezentând o FBC:

∀ x ( p (x) ∩ ∃ y ( ∀ z ( q ( y, z) ) ) )

unde:

p, q – sunt Predicate

x, y, z – sunt Variabile

Pasii de transformare sunt urmatorii (vezi sectiunea 7.1.1):

§ Eliminarea Implicatiei prin Transformarea:

(f ⇒ g) ⇔ ( ¬ f ∪ g)

In exemplul ales aceasta Transformare nu este necesara.

§ Aplicarea Transformarilor date de Legilor lui De Morgan, pentru migrarea Negatiilor de la Expresii la Termeni.

In exemplul ales nici aceasta Transformare nu este necesara.

§ Conversia FBC în Forme Normale PRENEX, prin migrarea spre exterior a Cuantificatorilor, cu eventuala redenumire a Variabilelor

∀ x ( ∃ y ( ∀ z ( p ( x ) ∩ q ( y, z ) ) ) )

§ Eliminarea Cuantificatorilor Existentiali prin introducerea Functiilor Skolem

• Introducerea Constantelor Skolem (denumite si Functii fara Argument)

FBC Cuantificata Existential:

∃ v ( r ( v ) )

Poate fi înlocuita cu FBC:

r ( a )

492 Baze de DateEvoluate / Baze de Date Deductive

Unde Constanta oarecare a aserteaza aceeasi conditie ca cea din FBC originara si anume ca:

Exista o asemenea Valoare pe care însa nu o cunoastem

• Introducerea Functiilor Skolem

FBC Cuantificata Universal si Existential:

∀ u ( ∃ v ( s ( u, v ) ) )

Poate fi înlocuita cu FBC:

∀ u ( s ( u, f ( u ) ) )

Unde Variabila Dublu Cuantificata v a fost înlocuita cu o Functie Oarecare, de Argument u (Variabila Cuantificata Universal), care aserteaza aceeasi conditie ca cea din FBC originala si anume ca:

Pentru fiecare Valoare a Variabilei u Exista o Valoare f (u) pe care însa nu o cunoastem

∀ x ( ∀ z ( p ( x ) ∩ q ( f ( x ), z ) ) )

§ Eliminarea Cuantificatorilor Universali, prin admiterea conventiei de Cuantificare Universala Implicita pentru toate Variabilele din FBC

p ( x ) ∩ q ( f ( x ), z )

§ Conversia FBC la o Forma Normala Conjunctiva, prezentata ca un Set de Clauze legate prin Conjunctii, fiecare Clauza fiind scris a pe câte o linie

p ( x )

AND

q ( f ( x ), z )

§ Forma Clauzala se obtine eliminând Conjunctia dintre linii, care se considera implicita

p ( x )

q ( f ( x ), z )

Definitie: Forma Clauzala Generala a FBC este un Set de Clauze, fiecare redactata pe o Linie si fiecare având Forma:

NOT A1 OR NOT A2 OR NOT .. OR NOT Am OR B1 OR B2 OR .. OR Bn

unde:

A1, A2, .. , Am , B1, B2, .. , Bn - sunt Termeni Nenegati

Expresia poate fi rescrisa în forma:

Baze de DateEvoluate / Baze de Date Deductive 493

A1 AND A2 AND .. AND Am ⇒ B1 OR B2 OR .. OR Bn

Definitie: Clauza Horn este o Clauza Generala rescrisa în forma:

A1 AND A2 AND .. AND Am ⇒ B1 OR B2 OR .. OR Bn

si care contine cel mult un Termen B (n=0 sau 1)

Se remarca legatura Clauzei Horn cu expresia Implicatiei Logice utilizate în Deducerea de Consecinte (Demonstrarea de Teoreme).

Daca consideram un Set de Axiome :

A1, A2, .. , Am

cu care dorim sa demonstram Consecinta (Teorema):

B ⇒ C

atunci, pentru a ajunge la:

A1, A2, .. , Am ¦ B ⇒ C

putem include între Axiome termenul Antecedent al Implicatiei B ca si Premiza Suplimentara si sa demonstram:

A1, A2, .. , Am , B ¦ C

Astfel am dovedit Adevarul:

A1, A2, .. , Am ¦ B ⇒ C

caci Adevarul lui C depinde de Adevarul lui B, luat în calcul ca si Premiza Suplimentara . 7.1.6 Deducere în Baze de Date

Întelesurile Lumii Reale a Utilizatorului, continute în Informatiile ce descriu Spatiul Informatiilor sunt transpuse în Datele reprezentate în Sistemul de Calcul sub forma Bazelor de Date. Conversia Informatiilor în Date si vice-versa e redata în Fig, 7.1.6.1. Putem privi Lumea Reala ca fiind populata cu doua Categorii de Informatii (vezi si Fig. 3.2.1):

- Informatii Directe – Informatii de Observatie (consemnari de Fapte)

- Informatii Indirecte – Informatii despre Informatiile Observate (Cunostinte) care se constituie ca Reguli de Deducere de Noi Informatii din Informatiile Acumulate)

Fig. 7.1.6.1. Conversia Informatii - Date

Atunci când se doreste dotarea SBD cu facilitati de Deducere trebuie pornit de la forma de reprezentare în aceste sisteme a celor doua categorii de informatii:

SPATIU de INFORMATII Informatii

BAZA de DATE Date

conversie

494 Baze de DateEvoluate / Baze de Date Deductive

o Faptele reprezentate de Informatiile Elementare sunt stocate în BD sub forma Enunturilor Propozitionale, memorate ca Tuple în Relatiile (Tabelele de Baza) care descriu, în calitate de Asertiuni (vezi sectiunea 4.1.1):

• Clasele de Entitati

• Relatiile între Clase de Entitati

Exemplu:

Fie o Baza de Date ce descrie Legatura de Paternitate în cadrul unei Clase de Entitati PERSOANE si care are Structura reprezentata de urmatoarea Schema de Relatii:

PERSOANA (Cod*, Nume Prenume, Sex, Data-Nasterii)

TATA (Tata*, Fiu*)

Pentru simplificare am considerat doar Relatia de Paternitate (TATA), utilizând în acest scop Atributul Sex din Relatia PERSOANA ca si Conditie de Selectie pentru generarea Instantelor din Relatia TATA, astfel încât Relatia TATA are asociata proprietatea (Predicatul):

p1 este TATA pentru p2

care conduce la Echivalenta:

p1 este TATA pentru p2 ⇔ (p1, p2) ∈ TATA

O extensiune a Bazei de Date este reprezentata în Tab. 7.1.6.2.

Fig. 7.1.6.2 Extensiunea BD PERSOANA / TATA

o Cunostintele care reprezinta Proprietati Generale fiind memorate sub forma Enunturilor Predicative, ce pot fi folosite ca Reguli de Deductie pentru generarea de noi Fapte Nememorate în Baza de Date, dar care pot fi generate prin Materializare, folosind Calculul Logic cu ocazia consultarii BD

PERSOANA Cod* Nume Prenume Sex Data-Nasterii

p1 N1 PR1 B D1 p2 N2 PR2 F D2 p3 N1 PR1 B D3 p4 N4 PR3 F D4 p5 N5 PR3 B D5 p6 N1 PR4 B D6 p7 N7 PR5 F D6 p8 N8 PR6 B D7

TATA Tata* Fiu*

p1 p3 p1 p5 p3 p6 p5 p8

Baze de DateEvoluate / Baze de Date Deductive 495

Exemplu:

Regula r 1

Daca p1 este TATA pentru p2

Atunci p2 este FIU pentru p1

Regula r 2

Toate persoanele au doi parinti

Regula r 3

Daca p1 este TATA pentru p2 si p2 este TATA pentru p3

Atunci p1 este BUNIC pentru p3

Proprietatile Generale pot fi utilizate pentru:

• Validarea Faptelor Elementare din Baza de Date prin utilizarea Restrictiilor de Utilizator (vezi si Viziunea Interpretativa a unei BD)

• Deducerea de noi Fapte inexistente în Baza de Date (vezi si Viziunea Inferentiala a unei BDD)

Declararea Proprietatilor Generale (Cunostintelor) folosind Limbajul Logic se face cu ajutorul Regulilor de Definire ale FBC, folosind un Limbaj Predicativ de genul celui prezentat în sectiunea 7.1.3.

Spre exemplificare se redau transcrise în FBC Regulile de Deductie prezentate anterior.

Regula r 1

∀x ∀y (TATA (x, y) ⇒ FIU (y, x)

Regula r 2

∀x (∃ y (PARINTE (x, y) ∩ ∃ z (PARINTE (x, z)

unde PARINTE poate fi privita ca o extensie a Relatiei TATA:

PARINTE Painte* Fiu*

p1 p3 p1 p5 p2 p3 p2 p5 p3 p6 p4 p6 p5 p8 p7 p8

Fig. 7.1.6.3 Extensiunea Tabelei de Baza PARINTE

496 Baze de DateEvoluate / Baze de Date Deductive

Regula r 3

∀x ∀z ((∃ y (TATA (x, y) ∩ TATA (y, z) ⇒ BUNIC(x, z)

Sa consideram ca Utilizatorul este interesat sa afle informatii legate de Relatia de Rudenie BUNIC. Se remarca imediat ca acest Grad de Rudenie nu este înregistrat direct în Baza de Date (nici Intensional, ca Predicat si ca urmare nici Extensional, ca Instante de Predicat, deci ca Fapte).

Exemplul 1:

Fie Întrebarea:

Al cui BUNIC este p1 ?

Desi solutia finala este oferita înca de la începutul prezentarii Bazelor de Date Deductive si anume cea de tratare a Informatiei solicitate ca Data Virtuala, prin modul de obtinere a rezultatului se contureaza doua abordari posibile:

o Abordarea Clasica

Data Virtuala este tratata ca o Vedere construita cu Informatiile continute în Tabelele de Baza si având Intensiunea:

CREATE VIEW BUNIC AS

SELECT TATA1.Tata AS ’Bunic’,

TATA2.Fiu AS ’Nepot’

FROM TATA TATA1, TATA TATA2

WHERE TATA1.Fiu=TATA2.Tata

si Extensiunea (în momentul executiei): BUNIC

Bunic* Nepot* p1 p6 p1 p8

Fig. 7.1.6.3 Extensiunea Vederii BUNIC

Acum ramâne doar de facut Selectia potrivita pe Vederea construita:

SELECT Nepot

FROM BUNIC

WHERE Bunic=’ p1’

pentru a obtine Raspunsul la Întrebarea pusa.

o Abordarea Inferentiala

§ Sa urmarim pentru început raspunsul la Întrebarea:

Este p1 BUNIC lui p6 ?

In aceasta abordare se parcurg urmatorii pasi de deducere:

Baze de DateEvoluate / Baze de Date Deductive 497

• Stabilirea Axiomelor de Baza ca Fapte memorate în BD:

TATA (p1, p3)

TATA (p1, p5)

TATA (p3, p6)

TATA (p5, p8)

• Stabilirea Axiomelor Deductive ca Reguli Generale memorate în BD sub forma FBC:

∀x ∀z (∃ y((TATA (x, y) ∩TATA (y, z)) ⇒ BUNIC(x, z))

care transpusa în Forma Clauzala ia aspectul unei Clauze Horn:

TATA (x, y) ∩ TATA (y, z) ⇒ BUNIC(x, z)

ce poate fi adaptata pentru aplicarea Regulii de Rezolutie (Tab. 7.1.1) prin eliminarea ⇒ (Tab. 7.1.3):

¬ TATA (x, y) ∪ ¬ TATA (y, z) ∪ BUNIC(x, z)

• Se aplica metoda Reducerii la Absurd (vezi sectiunea 7.1.1) si se introduce în Premize negarea Concluziei:

¬ BUNIC (p1, p6)

• Pentru a aplica Regula de Rezolutia (Tab. 7.1.1), în FBC aflate în Conjunctie, dar Negate, se fac înlocuirile (operatie numita Unificare):

x = p1

z = p6

se obtine:

¬ TATA (p1, y) ∪ ¬ TATA (y, p6)

• Din Axiomele de Baza se alege prima:

TATA (p1, p3)

care determina substitutia:

y = p3

si care face Fals primul Termen al FBC:

¬ TATA (p1, p3)

atunci cel de al doilea Termen trebuie sa fi neaparat Adevarat:

498 Baze de DateEvoluate / Baze de Date Deductive

¬ TATA (p3, p6)

• Dar din cea de a treia Axioma de Baza rezulta ca acest Termen este Fals, caci:

TATA (p3, p6)

De unde rezulta Contradictia, ce infirma Concluzia Negata:

¬ BUNIC (p1, p6)

Exemplul 2:

Sa urmarim acum raspunsul la Întrebarea:

Care sunt NEPOTII lui p1 ?

Exista aici doua variante posibile de rezolvare inferentiala:

- Sa se introduca o noua Axioma de Deductie

∀x ∀y ((BUNIC (x, y) ⇔ NEPOT(y, x))

- Sa se refrazeze Întrebarea:

Al cui BUNIC este p1 ?

In aceasta ultima varianta se parcurg urmatorii pasi de deducere:

• Stabilirea Axiomelor de Baza ca Fapte memorate în BD:

TATA (p1, p3)

TATA (p1, p5)

TATA (p3, p6)

TATA (p5, p8)

• Stabilirea Axiomelor Deductive ca Reguli Generale memorate în BD sub forma FBC:

∀x ∀z (∃ y ((TATA (x, y)∩TATA (y, z)) ⇒ BUNIC(x, z))

care transpusa în Forma Clauzala ia aspectul unei Clauze Horn:

TATA (x, y) ∩ TATA (y, z) ⇒ BUNIC(x, z)

ce poate fi transformata în:

¬ TATA (x, y) ∪ ¬ TATA (y, z) ∪ BUNIC(x, z)

• Se introduce o noua Premiza de forma:

¬ BUNIC (p1, r) ∪ REZULTAT (r)

Baze de DateEvoluate / Baze de Date Deductive 499

care afirma intuitiv:

Sau p1 nu este BUNICUL nimanui, sau este BUNICUL unor Persoane r

• Pentru a aplica Regula de Rezolutia (Tab. 7.1.1) între FBC aflate în Conjunctie, dar Negate, se fac înlocuirile (operatie numita Unificare):

x = p1

r = z

se obtine:

¬ TATA (p1, y) ∪ ¬ TATA (y, z) ∪ REZULTAT (z)

• Din Axiomele de Baza se alege prima:

TATA (p1, p3)

care determina substitutia:

y = p3

si care face Fals primul Termen al FBC:

¬ TATA (p1, p3)

ramânând de dovedit ca Adevarata FBC:

¬ TATA (p3, z) ∪ REZULTAT (z)

• Dar din cea de a treia Axioma de Baza:

TATA (p3, p6)

rezulta substitutia:

z = p3

care face primul Termen sa fie Fals si expresia sa se reduca la:

REZULTAT (p6)

De unde rezulta prima Solutie de Raspuns:

BUNIC (p1, p6)

• Urmând aceiasi pasi, dar alegând în locul primei Axiome de Baza pe cea de a doua, se ajunge în final la a doua solutie de raspuns:

BUNIC (p1, p8)

Se remarca faptul ca în acest caz, obtinerea tuturor solutiilor se realizeaza prin aplicarea succesiva a proceselor de Unificare si de Rezolutie.

500 Baze de DateEvoluate / Baze de Date Deductive

7.1.7 Viziunea Inferentiala a unei BDD

Diferitele Viziuni ale unei BD se dezvolta pornind de la posibilitatile de interpretare a Obiectelor unei Baze de Date ca Axiome . Iau nastere astfel doua Viziuni (Interpretativa si Inferentiala) ale aceleiasi BD [DATE95] si [ELMA94]:

- Viziunea Interpretativa – corespunde Modelele Relationale Traditionale, în care se înregistreaza Fapte interpretate ca Axiome de Baza si Reguli de Deductie pe post de Restrictii de Integritate (verifica consistenta între Faptele înregistrate în BD).

BD va contine în acest caz:

o Reguli de Deductie – Axiome Deductive (se utilizeaza pentru verificarea încadrarii Interpretarii într-un Model)

o Interpretare (daca Faptele declarate verifica toate Regulile de Deductie, atunci Interpretarea reprezinta un Model)

§ Fapte Declarate ce nu pot fi Deduse

§ Fapte Declarate ce pot fi Deduse (Validarea acestor Fapte, Logic Redondante de altfel, va trebui sa fie facuta cu ajutorul Regulilor de Deductie)

Cererile vor reprezenta Predicate a caror Instantiere e cautata în BD.

- Viziunea Inferentiala – corespunde Bazelor de Date Deductive, în care se înregistreaza ca Fapte Interpretate doar Axiomele ce nu pot fi deduse din Regulile de Deductie si care joaca acum rolul de Generatoare de Fapte Noi.

BDD va contine în acest caz:

o Reguli de Deductie – Axiome Deductive (se utilizeaza pentru deducerea de Fapte Noi)

o Interpretare (daca Faptele Declarate verifica toate Regulile de Deductie, atunci Interpretarea reprezinta un Model)

§ Fapte Declarate ce nu pot fi deduse

Faptele Deduse nu vor mai fi declarate în acest caz, eliminându-se Redondanta Logica.

Cererile vor reprezenta Concluzii ce trebuie demonstrate ca Adevarate.

Sa încercam în continuare sa trasam, prin enumerarea de caracteristici, o linie de demarcatie între cele doua tipuri de Viziuni asupra BD. Vom porni de la caracteristicile de baza conturate în sectiunea 7.1.

o Viziunea Interpretativa – reprezinta o Viziune Integratoare asupra Sursei de Date, care odata cu evolutia Tehnologiei de Prelucrare si a Conceptelor de Proiectare a reunit în componenta atât Structurile de Date, cât si Structurile de Proceduri strâns legate de primele si prin aceasta a contribuit la îmbogatirea Semantica a Modelului; vom regasi ca si componente (vezi si Fig. 4.2.1.1.1):

Baze de DateEvoluate / Baze de Date Deductive 501

§ Structura Datelor

• Clase de Entitati

o Simple (Nedecompozabile) - Domenii

o Compuse (Definite ca Relatii pe Domenii) – Tabele de Baza de tip Entitate

• Relatii între Clasele de Entitati

o Clase de Entitati Compuse (Definite ca Relatii între alte Relatii) – Tabele de Baza de tip Legatura

Structura Datelor poate fi precizata în doua moduri:

• Intensional – prin Nume pe post de Variabila (Element General sau Abstract – Definire de Element)

• Extensional – prin Valoare pe post de Constanta (Element Particular sau Concret – Instanta de Element)

§ Structura Procedurilor – vazute ca Date Virtuale implementate Functional (vezi sectiunea 2.1.1)

• Restrictii – vazute ca Functii ce returneaza o Valoare Logica de Data Virtuala

o Restrictii de Domeniu

o Restrictii de Tupla

o Restrictii de Tabele de Baza

o Restrictii de Legatura între Tabele

• Operatii – vazute ca Functii ce returneaza o Valoare de Data Virtuala si / sau efectueaza o suma de Transformari asupra Starilor Structurii

o Proceduri Stocate de Actualizare a BD

o Proceduri Stocate de Derivare a Datelor Functional Dependente din BD

o Viziunea Inferentiala – reprezinta o Viziune Unificatoare asupra Sursei de Date, care reduce Obiectele prezente într-un Model Structural la Continutul lor de Adevar din punct de vedere al Asertiunilor pe care le contin asupra Lumii Reale (Spatiului de Informatii); vom regasi ca si componente doar Axiome, grupate în doua categorii:

§ Axiome de Baza – reprezentate de Fapte descrise asertiv prin Propozitii Logice

§ Axiome Deductive – reprezentate de Reguli de Deductie descrise deductiv prin Formule Bine Construite (FBC), într-un Limbaj Predicativ

502 Baze de DateEvoluate / Baze de Date Deductive

Pentru a putea face corespondenta între Multimile de Obiecte prezente în cele doua Viziuni prezentate, sa sistematizam rezultatele pe care le-am consemnat cu ocazia trecerii în revista a Metodelor Inferentiale.

O Clauza este o expresie de forma:

A1 AND A2 AND .. AND Am ⇒ B1 OR B2 OR .. OR Bn

unde Termenii A si B sunt de forma:

r (x1, x2, .. , xt)

cu:

r - Predicat

x1, x2, .. , xt – Argumente ale Predicatului

Doua cazuri pot fi semnalate în legatura cu Formele Clauzale ce îmbraca forme specifice:

§ Forme Clauzale pentru care are loc Conditia:

m = 0 , n = 1

Clauza se reduce în acest caz la forma:

⇒ B1

sau eliminând implicatia la numai:

r (x1, x2, .. , xt)

pentru x – Constante, expresia ia forma unei Propozitii Logice, care e univoc Adevarata, corespunzând unei Tuple Fizice a Relatiei R.

Exemplu:

Cu datele din Relatia PERSOANA (vezi Fig. 7.1.6.2), expresia:

PERSOANA (p1, N1, PR1, B, D1)

reprezinta o Propozitie Logica în forma unei FBC Inchisa , cu Variabilele Fixate prin Valori concrete si exprima Adevarul:

Exista o Persoana cu Codul p1, Numele N1, Prenumele PR1, Sexul B si Data Nasterii D1

Predicatul r va corespunde Tuplei Logice ce defineste Intensional Relatia R. Expresia Predicativa r, cu x – Variabile Libere, reprezinta o Formula Bine Construita Deschisa (FBC) în Calculul Predicatelor.

Exemplu:

Cu datele din Relatia PERSOANA (vezi Fig. 7.1.6.2), expresia:

PERSOANA (Cod, Nume, Prenume, Sex, Data-Nasterii)

Baze de DateEvoluate / Baze de Date Deductive 503

reprezinta un Predicat în forma unei FBC Deschisa , cu Variabilele Libere atasate Multimii de Tuple Fizice (Universul de Discurs), continute în Extensiunea Relatiei R si exprima Proprietatea Definitorie (Intensiunea) aceleiasi Relatii R:

O Persoana are Cod, are Nume, are Prenume, are Sex si are Data-Nastere

Ansamblul Propozitiilor Logice reprezentate de Tuplele Fizice ale Relatiilor din Baza de Date vor fi privite ca Axiome de Baza.

In aceste conditii Formele Clauzale vor descrie Fapte consemnate prin Asertiuni sub forma de Propozitii Logice.

§ Forme Clauzale pentru care are loc conditia:

m > 0 , n = 1

Clauza ia forma:

A1 AND A2 AND .. AND Am ⇒ B1

o Formula Legata (FBC) ce defineste pe B1 prin Termenii Ai.

Exemplul 1:

Cu datele din Relatia PERSOANA si TATA (vezi Fig. 7.1.6.2), expresia:

TATA (x, y) AND TATA (y, z) ⇒ BUNIC(x, z)

reprezinta un Predicat în forma unei FBC Legata, cu Variabilele Cuantificate atasate Multimilor de Tuple Fizice (Universul de Discurs - Extensiunea Relatiilor PERSOANA si TATA).

Exemplul 2:

Restrictiile de Integritate de tip Identificare, denumite si Restrictii de Chei Candidate, pot fi exprimate prin acelasi gen de Forme Clauzale. Sa urmarim o asemenea formulare în cadrul Relatiei PERSOANA:

PERSOANA (p, n1, pr1, s1, d1) = PERSOANA (p, n2, pr2, s2, d2) ⇒ n1 = n2

PERSOANA (p, n1, pr1, s1, d1) = PERSOANA (p, n2, pr2, s2, d2) ⇒ pr1 = pr2

PERSOANA (p, n1, pr1, s1, d1) = PERSOANA (p, n2, pr2, s2, d2) ⇒ s1 = s2

PERSOANA (p, n1, pr1, s1, d1) = PERSOANA (p, n2, pr2, s2, d2) ⇒ d1 = d2

care descrie Unicitatea Cheii Primare Cod prin declararea Dependentelor Functionale:

Cod → Nume

Cod → Prenume

504 Baze de DateEvoluate / Baze de Date Deductive

Cod → Sex

Cod → Data-Nasterii

Exemplul 3:

Restrictiile de Integritate de tip Referire, denumite si Restrictii de Chei Straine, pot fi exprimate prin acelasi gen de Forme Clauzale. Sa urmarim o asemenea formulare în cadrul Relatiei TATA:

TATA (p1, p2) ⇒ PERSOANA (p1, n1, pr1, s1, d1)

TATA (p1, p2) ⇒ PERSOANA (p2, n2, pr2, s2, d2)

Exemplul 4:

Restrictiile de Domeniu, denumite si Restrictii de Tip, pot fi exprimate prin acelasi gen de Forme Clauzale. Sa urmarim o asemenea formulare în cadrul Relatiei PERSOANA:

PERSOANA (p1, n1, pr1, s1, d1) ⇒ COD (p1)

PERSOANA (p1, n1, pr1, s1, d1) ⇒ NUME (n1)

PERSOANA (p1, n1, pr1, s1, d1) ⇒ PRENUME (pr1)

PERSOANA (p1, n1, pr1, s1, d1) ⇒ DATA-NASTERII (d1)

Ansamblul Formulelor (FBC) ce definesc noi Predicate Adevarate, ce vor putea genera noi Propozitii Logice Adevarate, vor constitui Axiomele Deductive .

In aceste conditii Formele Clauzale vor descrie Cunostinte înregistrate ca Reguli de Deductie sub forma de FBC.

Definitie: Viziune Inferentiala (Proof-Theoretic View) – un Model de Date care interpreteaza ca Axiome de Baza doar Faptele ce nu pot fi Deduse, în timp ce Faptele ce pot fi Deduse, Axiomele Deductive, sunt tratate ca si Concluzii (Teoreme) ce se cer dovedite ca Adevarate (Demonstrate)

Pentru a detalia aceasta Viziune asupra Modelelor de Date redam urmatoarele exemplificari de interpretare a Obiectelor din BD ca Axiome:

o Axiomele de Baza – reprezentate de Extensiunea Relatiilor din BD

o Axiomele de Completitudine – tot ce nu este afirmat ca Adevarat prin Tuplele Fizice continute în Relatii se considera Fals (Presupunerea de Univers Închis)

o Axiomele de Unicitate – fiecare Nume de Termen este unic în sistem

o Axiomele de Închidere a Domeniilor – toate Constantele din sistem sunt cele continute în Domeniile BD

o Axiomele Implicite – necesare pentru descrierea Predicatelor de Sistem (Incorporate) folosite la constructia expresiilor (ex. relatia de egalitate ”=”)

Baze de DateEvoluate / Baze de Date Deductive 505

Printre noutatile pe care Viziunea Inferentiala le aduce în prelucrarea datelor enumeram:

- Prelucrarea Informatiilor Disjunctive (Beneficiarul b1 are Sediul în Orasul o1 sau o2)

- Prelucrarea Cererilor Recursive 7.1.8 Metode de Deducere în SBD

Am vazut care sunt posibilitatile de a interpreta continutul unei Baze de Date ca o Multime de Axiome si prin aceasta ca o Teorie Logica cu facilitati deductive. Întrebarea care se pune acum este legata de metodele prin care întreg arsenalul de instrumente oferit de Rationamentul Deductiv poate fi implementat în Sistemele cu Baze de Date, pe care le vom denumi Sisteme cu Baze de Date Deductive (SBDD).

Definitie:

Baza de Date Deductiva (BDD) – o BD care se bazeaza pe o Viziune Inferentiala (Proof-Theoretic View), asa cum a fost definita în sectiunea anterioara.

Vom oferi în continuare trei solutii de implementare a unei BDD, pentru a putea compara nu numai Fidelitatea în modul de implementare a Conceptelor, ci si Gradul de Acoperire al Raportului între Concepte si Performanta:

- SBD Pur Deductive

- SBD Deductive Mixte

- SBD Deductive Generative 7.1.8.1 SBD Pur Deductive

In aceasta varianta SBDD va apela doar la mecanismul de Inferenta descris anterior. Acest tip de implementare a unui SBDD este denumit si SBDD bazat pe Întrebari si Raspunsuri [DELO91], înteles în sensul ca orice Întrebari adresate BDD vor declansa de fiecare data mecanismul de Rationament Deductiv, care interpreteaza toate Cererile ca si Concluzii ce trebuie demonstrate ca Adevarate. In acest caz atât Procesul de Regasire a Faptelor Declarate, cât si Procesul de Deducere a Faptelor Deductibile apar unificate într-un singur Proces de Demonstrare de Teoreme .

Omogenitatea unei asemenea interpretari va trebui sa plateasca pretul reluarii procesului de Deducere a oricarui Raspuns din totalitatea Axiomelor memorate în Baza de Date, inclusiv cele Aditionale, sintetizate în finalul sectiunii precedente.

In aceasta varianta în Baza de Date Deductiva se memoreaza:

§ Axiome de Baza sub forma de Enunturi Propozitionale (Fapte) continute în Extensiunile Relatiilor

§ Axiome Deductive sub forma de Enunturi Predicative reprezentând Proprietati Generale (Reguli de Deductie)

Raspunsul se deduce ca o Demonstrare Automata de Teorema în cadrul unei Logici de Ordinul I (Logica ce nu contine Predicate în definirea altui Predicat).

506 Baze de DateEvoluate / Baze de Date Deductive

Se prezinta în continuare un set de exemple care sa ofere variante de Evaluare a diferitelor expresii FBC (Închise si Deschise). Se va utiliza în acest scop Structura de Date prezentata în Fig. 7.1.6.2, precum si Regulile de Deductie formulate în sectiunea 7.1.6. Exemplele sunt grupate dupa tipul Întrebarilor adresate Bazei de Date Deductive.

Exemplul 1:

Întrebari legate: Întrebarea i1

Este p1 TATA pentru p2 ?

formalizat

TATA (p1, p2)

Întrebarea i2

p2 are FII ?

formalizat

∃ x FIU (p2, x)

Întrebarea i3

p2 are BUNIC pe p4 ?

formalizat

BUNIC (p1, p4)

Forme intermediare de deducere pentru raspunsul la întrebarea i2:

∀x (TATA (x, p2) ⇒ FIU (p2,x) conform cu Regula r1 (sectiunea 7.1.6)

TATA (p4, p2) ⇒ FIU (p2, p4) conform cu Regula r1 (sectiunea 7.1.6)

FIU (p2, p4) e dedus ca Adevarat

Observatie: Problema Decidabilitatii e rezolvata practic prin neputinta de concluzie. Exemplul 2:

Întrebari libere: Întrebarea i4

FIII lui p1

Solutii:

FIU (p1, x) evaluata ca Formula Libera

S x FIU (p1, x) evaluata ca expresie de definire Multime (Asamblista)

In Varianta SBD Pur Deductive Evaluarea Întrebarilor se face numai Inferential, asa dupa cum se vede în Fig. 7.1.8.1.1.

Baze de DateEvoluate / Baze de Date Deductive 507

SBD

Fig. 7.1.8.1.1 Evaluarea Întrebarilor în varianta SBD Pur Deductiva

Întrebarile sunt considerate Concluzii ce trebuiesc dovedite ca Adevarate sau False pe baza Axiomelor (de Baza , Deductive sau Aditionale) memorate în BDD si considerate ca Premize ale Rationamentului Deductiv. In aceste conditii sunt luate în calcul de fiecare data toate Faptele stocate în Baza de Date, care alaturi de Regulile de Deductie, formeaza un volum foarte mare de Date (Axiome) ce trebuiesc consultate. Procesul de Inferenta va fi apelat si pentru informatii memorate ca Date Reale în BD si care ar avea nevoie doar de o Procedura de Regasire. Este vizibila caracteristica principala a Viziunii Inferentiale reflectata în Omogenitatea Structurii BD, care contine exclusiv Axiome .

In sinteza se pot retine ca definitorii pentru varianta de SBD Pur Deductiva urmatoarele caracteristici:

o Informatiile Elementare si Proprietatile Generale sunt tratate unitar

o Metoda putin aplicabila datorita lipsei de eficienta în consumul de Resurse

o Toate Raspunsurile sunt Deduse

o Volum foarte mare de Axiome

o Timpi de Raspuns mari

o Necesitatea reprezentarii Informatiilor Negative (enuntare de falsuri)

o Enuntarea ca Regula Generala “Tot ce nu e Adevarat e Fals” poate conduce la inconsistenta.

o Actualizarile trebuie corelate cu tot ce exista în Baza de Date (toate Faptele sunt tratate ca Axiome)

7.1.8.2 SBD Deductive Mixte Varianta SBD Deductive Mixte încearca sa îmbunatateasca Performanta de tratare a Cererilor, prin combinarea Metodei Pur Inferentiale cu Metoda Clasica de interogare a BD.

INTREBARI

INFORMATII

ELEMENTARE

PROPRIETATI GENERALE

RASPUNSURI DEDUSE

508 Baze de DateEvoluate / Baze de Date Deductive

In acest mod se evita declansarea Mecanismului Inferential pentru Cererile care pot fi simplu rezolvate doar printr-o Procedura de Regasire (sau, în termeni inferentiali, doar prin apelul la Axiomele de Baza).

Acest tip de implementare a unui SBDD este denumit si SBDD bazat pe Informatii Elementare si Proprietati Generale [DELO91], înteles în sensul Metodelor diferite de tratare a celor doua Categorii de Informatii în prelucrarea Întrebarilor.

Separarea celor doua Categorii de Informatii în BD este redata în Fig. 7.1.8.2.1 si 7.1.8.2.2. In prima reprezentare se detaliaza definirea celor doua Categorii de Informatii care pot fi întâlnite într-o Baza de Date (vezi Fig. 7.1.6.1):

o Fapte Declarate în forma Informatiilor Elementare (IE)

o Cunostinte în forma Proprietatilor Generale (PG)

Separarea apare necesara întrucât prima Categorie de Informatii (Informatiile Elementare) vor fi utilizate în cele doua faze ale procesului de tratare a Întrebarilor:

- Prima Faza – tratare pur Structurala si independenta a Informatiilor Elementare, prin consultarea lor directa cu ajutorul Procedurilor de Regasire

- A Doua Faza - tratare pur Inferentiala prin gruparea Informatiilor Elementare cu Proprietatile Generale, ambele în calitate de Axiome si construirea unei Teorii Interpretate cu valente deductive (Deducere de noi Fapte)

-

Fig. 7.1.8.2.1 Raportul Informatii Elementare – Proprietati Generale

Analiza este aprofundata în cadrul reprezentarii din Fig. 7.1.8.2.2., prin localizarea în cadrul BD a celor doua Categorii de Informatii. Se poate remarca adaugarea la Definirea Bazei de Date a Proprietatile Generale, ca sursa de Fapte Deduse, ce se vor adauga la Faptele Reale generate prin Instantierea Schemei Relationale. Împreuna vor constitui prin Interpretare Modelul Inferential ce va extinde continutul BDD.

Adoptând Viziunea Inferentiala si în aceasta varianta Faptele Declarate nu le includ pe cele ce ar putea sa fie Deduse si doar validate prin Proprietatile Generale continute în Regulile de Deductie.

Modelul generat în final va contine doua Categorii de Informatii:

o Fapte Declarate (ca atare Interpretate) si posibil de obtinut prin Regasire

o Fapte Deduse ca Adevarate (ca atare implicit Interpretate) si posibil de obtinut prin Deducere

INFORMATIILE ELEMENTARE - Reprezinta Interpretarea Proprietatilor Generale ce Definesc Structura (Axiome de Baza) - Verifica Validitatea Structurii (Axiome de Baza) - Reprezinta un Model (Definire+Interpretare)

PROPRIETATILE GENERALE - Definesc Axiomele Deductive ce stau la baza procesului Inferential - Impreuna cu Axiomele de Baza definesc Axiomele proprii unei Teorii

Baze de DateEvoluate / Baze de Date Deductive 509

Fig. 7.1.8.2.2 Structura Bazei de Date Deductive IE - PG

Mentinerea în descrierea BDD a componentelor traditionale ale unei Baze de Date Relationale (BDR) va face posibila exploatarea ei si cu instrumentele încetatenite de consultare a datelor. In aceasta consta si particularitatea acestei metode de extindere a unei BDR prin adaugarea de facilitati deductive, de unde si numele de BDD Mixta.

In Varianta SBD Deductiva Mixta Evaluarea Întrebarilor se face în doi pasi, asa dupa cum a fost descris procesul înca la începutul prezentei sectiuni. In Fig. 7.1.8.2.3 sunt reprezentate cele doua faze de prelucrare a Întrebarilor adresate BDD.

Fig. 7.1.8.2.3 Evaluarea Întrebarilor în varianta SBD Deductive Mixte

Daca în urma Pasului 1, bazat pe Regasirea Simpla din Informatiile Elementare memorate s-a gasit Raspunsul la Întrebare, Pasul 2 nu mai este lansat. In aceste conditii se evita punerea în miscare a întregului Mecanism Inferential, indiferent de natura Întrebarii.

Pasul 2 va relua Informatiile Elementare în totalitate, de data aceasta pe post de Axiome de Baza , pentru a le utiliza în Procesul de Deducere alaturi de celelalte Axiome .

SCHEMA RELATIONALA Descrie Structura

- Simbolurile Sistemului Formal - Axiomele aferente Restrictiilor BD

REALIZAREA (INSTANTIEREA) SCHEMEI RELATIONALA

- Contine Fapte Declarate

PROPRIETATI GENERALE Descriu Regulile Deductive

- Genereaza noi Fapte în BD

MODEL - Interpretarea Faptelor Declarate - Completarea cu Faptelor Deduse

+ +

INFORMATII ELEMENTARE

INFORMATII ELEMENTARE

+ PROPRIETATI

GENERALE

INTREBARI

RASPUNSURI DEDUSE

RASPUNSURI REGASITE

1

1

2

2

510 Baze de DateEvoluate / Baze de Date Deductive

In final se pot retine ca definitorii pentru varianta de SBD Deductiva Mixta urmatoarele caracteristici:

o Informatiile Elementare si Proprietatile Generale sunt tratate diferentiat

o Raspunsurile pot fi obtinute în primul pas prin simpla Regasire în Baza de Date

o Raspunsurile Deduse si care vor fi cautate prin Inferenta vor face obiectul celui de al doilea pas, ce va fi declansat doar dupa esecul primului pas

o Timpi mult mai mici de raspuns decât în cazul unei abordari Pur Inferentiale

o Volumul mare de Axiome se mentine în cel de al doilea pas 7.1.8.3 SBD Deductiv-Generative

A treia Varianta de implementare analizata porneste direct de la unul din Conceptele Fundamentale promovate de BD si anume definirea unui Nivel Extern în Arhitectura SBD (vezi sectiunea 2.1.1). Definirea acestui Nivel de Abstractizare asigura Independenta Datelor Reale din BD prin introducerea conceptelor de Date Virtuale, de Materializare a Datelor prin Functii de Calcul, de construire a Tabelelor Virtuale sub forma de Vederi.

Înca de la prima prezentare a acestor concepte s-a insistat asupra caracterului general al Functiilor care implementeaza Materializarea Datelor. Cuprinderea Calculului Logic în cadrul acestor Functii deschide calea directa catre asigurarea Facilitatilor Deductive ale BD.

Solutia însa ofera totodata mentinerea BD în zona Modelelor Stricte de Date cu toate avantajele care decurg din aceasta. Îl mentionam pe cel mai important si anume:

Mentinerea Structurii Ferme a Datelor cu posibilitati de realizare a unor performante ridicate în Prelucrarea Volumelor Mari de Date.

Noutatea metodei de implementare pe care o analizam aici consta însa în aplicarea procesului de Materializare a Datelor în forma sa integrala si anume de definire a Datelor Virtuale în cadrul performant al Vederilor, adecvat prelucrarilor specializate ale Motoarelor Relationale.

Ideea consta în Generarea de Vederi care sa implementeze Noi Obiecte derivate, prin exploatarea informatiilor continute în Regulile Generale încorporate în BDD.

Datorita modului de abordare, acest tip de implementare a unui SBDD este denumit si SBDD bazat pe Vederi Generate, înteles în sensul utilizarii Cunostintelor încorporate în Regulile Generale pentru Generarea de Vederi în Nivelul Extern al BDD.

Sa analizam aceasta metoda pe exemplul de BDD schitata în sectiunea 7.1.6:

- Structura de BD de la care se porneste, este cea reprezentata în Fig. 7.1.6.2 si care contine doua Tabele de Baza : PERSOANA si TATA

- Acestei BD i se adauga Regula de Deductie:

∀x ∀z (∃ y((TATA (x, y) ∩TATA (y, z)) ⇒ BUNIC(x, z))

care transpusa în Forma Clauzala Horn devine:

TATA (x, y) AND TATA (y, z) ⇒ BUNIC (x, z)

Baze de DateEvoluate / Baze de Date Deductive 511

- In Varianta Clasica de abordare a Cererilor cu încarcatura deductiva se ajunge la Vederea:

CREATE VIEW BUNIC AS

SELECT TATA1.Tata AS ’Bunic’,

TATA2.Fiu AS ’Nepot’

FROM TATA TATA1, TATA TATA2

WHERE TATA1.Fiu=TATA2.Tata

- Problema este cum se poate utiliza Regula de Deductie pentru generarea automata a Vederii definite pentru introducerea Conceptului de Bunic (eventual si Nepot) în BDD

Prezentarea unei Metode Formale de Generare a Vederilor pornind de la Reguli Generale de Deducere depaseste cadrul acestei prezentari. Ne vom rezuma doar sa observam corespondentele:

TATA1.Fiu ≡ y din Termenul TATA (x, y)

TATA2.Tata ≡ y din Termenul TATA (y, z)

Numele Vederii (Obiectului Nou) BUNIC ≡ BUNIC din Termenul BUNIC (x, z)

Atributul Bunic din Vederea BUNIC ≡ x din Termenul BUNIC (x, z)

Atributul Nepot din Vederea BUNIC ≡ z din Termenul BUNIC (x, z)

Corespondentele enumerate releva faptul ca exista o legatura strânsa între Elementele Componente ale Vederilor ca Obiecte de Definire a Bazelor de Date si Elementele ce descriu Proprietatile Generale în termenii Calculului Logic.

Aportul metodei de implementare prezentate este rezumat în Fig. 7.1.8.3.1. Principala remarca este cea legata de faptul ca Întrebarile sunt adresate unei BDR obisnuite, Raspunsurile fiind obtinute doar prin Consultarea Structurii acestei BDR (Tabele de Baza sau Vederi). Pentru a putea realiza acest lucru Vederile au fost împartite în doua categorii:

- Vederi Declarate odata cu definirea (sau actualizarea) BDR

- Vederi Generate automat prin interpretarea Regulilor Generale

A doua remarca consta în excluderea Procesului de Inferenta din Cautarea Raspunsurilor la Întrebari. El este înlocuit cu Procesul de Generare Automata a Vederilor. O discutie se impune aici, legata de raportul Calitate - Performanta. Transformarea Cunostintelor din Regulile Generale în Date Virtuale poate fi facut în mai multe moduri dintre care enumeram:

- Implementarea Directa a Procesului de Inferenta în corpul Functiilor care descriu Datele Virtuale – aceasta metoda însa va aduce prejudicii mari sub aspectul consumului de resurse, întrucât Procesului de Inferenta va fi declansat la fiecare invocare de Vedere (Run-Time)

512 Baze de DateEvoluate / Baze de Date Deductive

- Implementarea Indirecta a Procesului de Inferenta prin Transformarea Regulilor Generale exprimate în FBC în cadrul unui Limbaj Formalizat – metoda va gasi simplificari multiple, în functie de cazurile concrete ce apar

Faptul ca Regulile Generale de Deductie vor fi prelucrate numai cu ocazia introducerii lor în BDD (sau cu ocazia modificarii lor) reprezinta o sursa importanta de economie de timp si totodata o metoda eleganta si naturala de a genera Sabloane de Comportamente în urma sintetizarii Cunostintelor.

Este adevarat ca cea de a doua metoda poate face trecerea Sistemelor Deductive catre Sistemele Expert si prin aceasta desconsiderata de adeptii fideli ai Calculului Logic, dar ne exprimam convingerea ca apropierea de o Viziune Conceptuala a Modelelor de Date este în acest caz mai mare, prin introducerea unei Metode de Generare Automata de Concepte Noi, cu care vor opera apoi BD în mod curent, întrucât ele vor îmbogati chiar Structura BD, prin înregistrarea persistenta în Modelul de Date.

Fig. 7.1.8.3.1 Raportul Informatii Elementare – Proprietati Generale

In sinteza se pot retine ca definitorii pentru varianta de SBD Deductiv-Generativa urmatoarele caracteristici:

o Tratarea unitara a tuturor Raspunsurilor prin Proceduri de Regasire

o Transformarea Raspunsurilor Deduse în Date Virtuale (Derivate numai din Fapte)

o Utilizarea Regulilor de Deductie pentru Generarea de Vederi prin Proceduri Stocate, care reprezinta de drept formele de implementare în Modelele de Date a Operatiilor ca Obiecte ce descriu Transformarile din Sistem (vezi si sectiunile 4.1.2.8 si 4.2.1)

BDD

INTREBARI

BD

TABELE de BAZA

VEDERI DECLARATE

RASPUNSURI REGASITE

VEDERI GENERATE

PROPRIETATI GENERALE

Baze de DateEvoluate / Baze de Date Distribuite 513

7.2 Baze de Date Distribuite

Conceptul de Baze de Date Distribuite (BDS) apare pe aceeasi linie de promovare a Independentei în SBD. De data aceasta este vorba de Independenta de Localizare a Resurselor. Concentrarea acestora poate aduce mari prejudicii din mai multe puncte de vedere, dintre care enumeram pentru început:

- Control Centralizat îngreunat de necesitatea cunoasterii tuturor Detaliilor Locale

- Concentrarea unei mari Puteri de Calcul în Nodurile Centrale, care devin Noduri Vitale

- Supraîncarcarea Liniilor de Comunicatie cu Nodurile Centrale

- Cresterea Riscului de paralizare a Sistemului Centralizat prin pierderea Nodurilor Vitale

Problemele de distribuire se extind de la fazele initiale de Proiectare, trecând prin fazele intermediare de Implementare si ajungând pâna la fazele finale de Exploatare a BDS. Tehnicile de Fragmentare si Replicare, precum si Procesarea Cererilor Distribuite, specifice Proiectarii, alaturate Tehnicilor de Alocare întâlnite în Implementare, cât si celor de Control a Concurentei si a Securitatii, atasate fazei de Exploatare vor forma subiectele dezbatute în aceasta sectiune. In cele ce urmeaza se vor prezenta în mod succint solutii la principalele probleme pe care le-am enumerat mai sus în legatura cu SBDS.

7.2.1 Generalitati

In cazul general o Baza de Date Distribuita (BDS) este mai mult decât o simpla colectie de Baze de Date Locale si chiar decât o Baza de Date Centralizata Implementata Distribuit. Se da mai jos o Definire prin Caracteristici a unei BDS.

Definitie:

Baza de Date Distribuita – o Colectie de Date care prezinta urmatoarele caracteristici:

§ Este amplasata pe mai multe Statii de Calcul

§ Statiile de Calcul sunt conectate la o Retea de Comunicatii

§ Dispune de un Sistem de Gestiune a Bazelor de Date Distribuite (SGBDS) care ofera utilizatorilor:

• Impresia ca lucreaza pe Întreaga Baza de Date

• Posibilitatea de a declara Ce doresc nu Cum doresc

Sistemul de Gestiune a Bazelor de Date Distribuite va trebui sa asigure urmatoarele facilitati:

• Aplicatii Locale pe fiecare Statie de Calcul

• Aplicatii Globale pe mai multe Statie de Calcul

514 Baze de DateEvoluate / Baze de Date Distribuite

• Un Limbaj de Interogare de Nivel Înalt (cel mai uzitat e SQL cu facilitati de Cereri Distribuite)

• Diverse Grade de Transparenta, care sa ofere imaginea unei Baze de Date Unice;

Formele de Transparenta pe care le asigura un SGBDS sunt:

o Transparenta de Localizare – strategia de obtinere a datelor de la diversele Statii de Calcul din Retea apartine SGBDS-ului; Transparenta de Localizare se asigura prin intermediul urmatoarelor actiuni:

§ Memorarea Localizarii Datelor în BDS (Caile de Acces)

§ Memorarea Starii Tranzactiilor în BDS

§ Memorarea Starii de Avarie a Statiilor de Calcul si a Liniilor de Comunicatie

§ Executarea Algoritmilor de Optimizare a Cererilor Distribuite

§ Incorporarea Proprietatilor Atomice în Protocoalele pentru Tranzactii, secvente care apoi se pot executa distribuit

§ Activarea Mecanismelor de Salvare / Restaurare in Regim Distribuit

o Transparenta de Fragmentare – memorarea se face pe baza de Fragmente (de Baza de Date, de Relatii, de Fisiere Memorate) si pe diferite Statii de Calcul, reconstituirea lor fiind lasata în sarcina SGBDS-ului

o Transparenta de Tranzactie – fiecare Tranzactie este protejata de efectul de Concurenta la Resurse al altor Tranzactii

o Transparenta de Avarie – Utilizatorii si Aplicatiile care nu acceseaza Resursele Avariate pot continua nestingheriti lucrul

Exemplu:

Sa consideram:

§ Trei Unitati de Calcul conectate în Retea (U1, U2, U3 )

§ O Tabela FURNIZORI divizata în trei Fragmente (F1, F2, F3 )

§ Fragmentele sunt distribuite pe cele trei Unitati de Calcul

Si fie Cererea:

Numele tuturor FURNIZORILOR având Codul mai mare ca 1000?

Baze de DateEvoluate / Baze de Date Distribuite 515

Varianta I-a de redactare:

SELECT Nume

FROM F1

WHERE cod>’1000’

IF not found

SELECT Nume

FROM F2

WHERE cod>’1000’

ELSE

IF not found

SELECT Nume

FROM F3

WHERE cod>’1000’

ENDIF

ENDIF

Forme de Transparenta asigurate:

§ Transparenta de Localizare

Varianta a II-a de redactare:

SELECT Nume

FROM FURNIZORI

WHERE cod>’1000’

Forme de transparenta asigurate:

§ Transparenta de Localizare

§ Transparenta de Fragmentare 7.2.2 Solutii Generale de Proiectare

Pentru realizarea dezideratelor de distribuire enumerate mai sus vor trebui rezolvate urmatoarele probleme de proiectare:

o Autonomia Unitatilor de Calcul

Solutii:

§ Autonomie Totala – O Unitate de Calcul nu trebuie sa fie afectata de nici-un factor extern. Aceasta implica existenta pe Statiile Locale a tuturor Resurselor pentru o Functionare Independenta

516 Baze de DateEvoluate / Baze de Date Distribuite

§ Dependenta Partiala de Centru – implica existenta unor Resurse Gestionate de Statia Centrala, de care celelalte unitati ramân Dependente. Între aceste resurse mentionam:

• Dictionare (Cataloage) Centrale

• Planificatorul Central de Activitati

• Detectorul Central de Blocare a Accesului

Solutia preferata este cea care asigura Independenta sporita tuturor statiilor.

o Asigurarea Transparentei, Performantei si Consistentei de catre SGBDS

Observatii:

§ Realizarea Transparentei implica Consum Suplimentar de Timp de Prelucrare

§ Performantele pot fi ridicate prin realizarea Distribuirii prin Metoda de Replicare (Multiplicare)

§ Multiplicarea ridica probleme de Consistenta în Datele Distribuite

Observatiile facute cer ca SGBDS-ul sa ofere solutii pentru urmatoarele probleme:

• Asigurarea Consistentei Datelor (Structural sau Procedural)

• Optimizarea Cererilor Distribuite (vezi sectiunea urmatoare)

• Proceduri Rapide de Acces de la Distanta (Remote Acces)

Procedurile enumerate mai sus trebuie asigurate de catre SGBDS (inclusiv Replicarea), fara ca Utilizatorul sa intervina.

o Identificarea Obiectelor în BDS

Problemele care se ridica sunt legate de:

§ Asigurarea Numelor Unice fara îngradirea Utilizatorilor, prin completarea automata a numelor cu Identificatorii Utilizatorului si memorarea lor în Dictionarul de Date

§ Construirea Dictionarul de Date, care poate fi facuta în doua moduri:

• Dictionarul Centralizat construit unic pe Statia Centrala

o Accepta o gestiune mai simpla

o Viteza de acces poate creste

o Limiteaza Independenta Statiilor

• Dictionarul Distribuit, fiind construit în forma unei Relatii (Tabele de Baza) poate beneficia de Facilitatile de Distribuire (Fragmentare, Localizare pe fiecare Statie, Replicare pe celelalte Statii)

o Pretinde o gestiune mai complicata

Baze de DateEvoluate / Baze de Date Distribuite 517

o Viteza de acces poate scadea

o Asigura Independenta Statiilor

§ Definirea Relatiilor cu Acces Specializat:

• Relatii Locale vizibile numai pe Statiile Locale

• Relatii Globale vizibile pe Toate Statiile

§ Tratarea Localizarii Preferentiale – implica luarea în calcul a Tipului de Acces precum si a Costurilor de Replicare

o Executia si Optimizarea Cererilor

In Executia si Optimizarea Cererilor se urmareste Minimizarea Timpului de Executie, trebuind parcurse doua etape:

§ Alegerea Elementelor de Strategie

• Analiza Costurilor de Comunicatie

• Rezolvarea posibilitatilor de Calcul Paralel a Cererilor pe Unitati de Calcul diferite, eventual pe Statii diferite

§ Stabilirea Planului Operativ de Executie

• Descompunerea Cererilor în Operatii Seriale Paralele

• Construirea Arborelui de Structura a Cererilor

• Gruparea Operatiilor pe Unitati de Calcul

• Construirea Grafului de Procesare a Cererilor ce contine:

o In Noduri – Grupul de Operatii de executat pe o anumita Unitate de Calcul

o Pe Arce – Transferul de Date (Cereri sau Rezultate) între Unitatile de Calcul

• Utilizarea Modelelor de Optimizare a Costurilor

o Analitice – Metoda BRANCH and BOUNDS (metoda de Programare Dinamica bazata pe rezolvari succesive de Modele de Programare Liniara

o Euristice – Metode bazate pe eliminarea variantelor de calcul apreciate ca nefavorabile

Dificultatea principala a problemelor de Optimizare a Cererilor consta în necunoasterea cu precizie a Parametrilor de Calcul, precum si a evolutiei lor în timp.

o Utilizarea Protocoalelor pentru Gestiunea Tranzactiilor

Protocoalele pentru Gestiunea Tranzactiilor – sunt proceduri speciale care, în caz de esec a unei Tranzactii, trebuie sa viziteze toate Unitatile de Calcul pe la care a trecut înainte Tranzactia, în vederea Refacerii ei (operatia UNDO

518 Baze de DateEvoluate / Baze de Date Distribuite

TRANZACTION). Sunt cu atât mai necesare cu cât Resursele sunt mai Distribuite si mentinerea Consistentei Datelor este mult îngreunata.

o Utilizarea Vederilor si Instantaneelor (Snapshot-uri)

Construirea Nivelului Extern în Mediu Distribuit este mai dificila datorita prezentei Operanzilor pe Statii diferite. Apelul la Optimizatorul de Cereri în momentul construirii Vederilor este strict necesara (vezi exemplul de mai jos).

Ca o solutie în acest caz se recomanda folosirea Instantaneelor, care reprezinta Vederi Temporare Memorate, care în cazuri speciale pot dispune si de facilitati de Actualizare (vezi obiectul Vedere Indexata, implementat de Microsoft în SGBDS-ul SQL SERVER).

Exemplu de Prelucrare Cerere Distribuita:

Acest exemplu este ales pentru a dovedi importanta problematicii ridicate de Optimizarea Cererilor în Structurile Distribuite. Cresterea dramatica a timpilor de prelucrare pot prabusi proiecte, iar solutiile spectaculoase de reducere a duratelor de raspuns dau imaginea oscilatiei între Agonie si Extaz a echipelor de proiectare.

Sa consideram o Baza de Date Distribuita descrisa de urmatoarea Schema Relationala, fiecare Relatie având atasata estimarea Extensiunii în Numar de Tuple:

BENEFICIAR (Cod, Oras) – 10.000 tuple pe Statia U1

PRODUS (Cod, Culoare) – 100.000 tuple pe Statia U2

CONTRACT (Beneficiar, Produs, Cantitate) – 1.000.000 tuple pe Statia U1

Fie Cererea:

Codul BENEFICIARILOR din Orasul O1 care livreaza PRODUSE de Culoare C1

Expresia cererii în limbajul de interogare SQL este:

SELECT BENEFICIAR.Cod

FROM BENEFICIAR, PRODUS, CONTRACT

WHERE BENEFICIAR.Cod=’ O1’

AND PRODUS.Cod=’ C1’

AND BENEFICIAR.Cod=CONTRACT. Beneficiar

AND PRODUS.Cod=CONTRACT.Produs

Fie Distributia Statistica de Valori de Atribute (Valori Izotipe):

- Numar PRODUSE de Culoare C1=10

- Numar CONTRACTE ale BENEFICIARULUI din Orasul O1 =100.000

- Rata de Transfer pe Liniile de Comunicatie = 10.000 bauds (biti / secunda)

- Timpul de Acces la Date (Protocolul de Transfer) = 1 secunda / mesaj

- Timpul Total de Transfer = Numarul de Mesaje + Numarul de biti / 10.000

Baze de DateEvoluate / Baze de Date Distribuite 519

Sa evaluam Timpii de Raspuns în urmatoarele Strategii de Prelucrare:

Strategia 1

§ Mutare PRODUSE pe U1

§ Prelucrare Cerere pe U1

Timp necesar = 16,7 minute

Strategia 2

§ Mutare BENEFICIARI pe U2

§ Mutare CONTRACTE pe U2

§ Prelucrare Cerere pe U2

Timp necesar = 2,8 ore

Strategia 3

§ Procesare Intermediara Cerere pe U1

R = σ BENEFICIAR.Oras=’O1’ (BENEFICIAR ρ BENEFICIAR.Cod = CONTRACT..Beneficiar CONTRACT)

§ Procesare Intermediara Cerere pe U1

RR = σ BENEFICIAR.Oras=’O1’ (R)

§ Procesare Finala Cerere pe U1 cu Consultare U2

RR = σ PRODUS.Culoare=’C1’ (R ρ R.Produs = PRODUS.Cod PRODUS)

Timp necesar = 2,3 zile

Strategia 4

§ Procesare Intermediara Cerere pe U2

R = σ PRODUSD.Culoare=’C1’ (PRODUS)

§ Procesare Intermediara Cerere pe U2

RR = R ρ R.Produs = CONTRACT..Produs CONTRACT

§ Procesare Finala Cerere pe U2 cu Consultare U1

BENEFICIAR ρ BENEFICIAR.Oras = ‘O1” and BENEFICIAR.Cod = RR.Beneficiar RR

Timp necesar = 20 secunde

520 Baze de DateEvoluate / Baze de Date Distribuite

Strategia 5

§ Procesare Intermediara Cerere pe U2

R = σ PRODUSD.Culoare=’C1’ (PRODUS)

§ Mutare Rezultat Intermediar R pe U1

§ Procesare Intermediara Cerere pe U1

RR = R ρ R.Produs = CONTRACT..Produs CONTRACT

§ Procesare Finala Cerere pe U1

RR ρ BENEFICIAR.Oras = ‘O1” and RR.Beneficiar = BENEFICIAR.Cod BENEFICIAR

Timp necesar = 1 secunda

Se retine în final raportul timpilor de procesare între Strategia 3 si 5, raport care este impresionant – 200 de mii !

7.2.3 Proiectarea Structurilor de Date Distribuite

Întrucât Datele reprezinta Resursa Principala a SBD, este firesc ca problematica distribuirii acestor sisteme sa înceapa cu Definirea Cerintelor si Analiza Solutiilor legate Natura Distribuita a Informatiilor precum si de Conditiile Tehnice ce permit exploatarea acestei particularitati. 7.2.3.1 Generalitati

Dezvoltarea Tehnologiei de Calcul si în paralel a celei de Comunicatie a sporit diversitatea Arhitecturilor Hardware si Software ale Sistemelor de Aplicatii. Diversificarea a început prin încercarea de a utiliza în mod sporit Puterea de Calcul a tuturor Statiilor interconectate. Au luat nastere doua variante distincte de organizare a Sistemelor cu Baze de Date si anume:

o Varianta Centralizata având urmatoarele caracteristici :

§ O Statie Centrala (Calculator) Unica pe care sunt concentrate:

• Colectiile de Date ale Bazelor de Date

• Sistemul de Gestiune a Bazelor de Date (SGBD)

• Colectiile de Date ale Sistemului de Securitate

§ O multime de Terminale conectate local sau la distanta

o Varianta Distribuita având urmatoarele caracteristici :

§ O multime de Statii Distribuite (Calculatoare numite Noduri) pe care sunt repartizate :

• Colectiile de Date ale Bazelor de Date

Baze de DateEvoluate / Baze de Date Distribuite 521

• Sistemul de Gestiune a Bazelor de Date Distribuite (SGBDS)

• Colectiile de Date ale Sistemului de Securitate

§ O Retea de Comunicatii între Statii conectate local sau la distanta

Fig. 7.2.3.1.1. Arhitectura unui Sistem Distribuit cu Baze de Date

7.2.3.1.1 Baze de Date Distribuite ( BDS)

O Baza de Date Distribuita este o Colectie de Date care apartine Logic la acelasi Sistem dar care Fizic este repartizata pe Statii Distribuite într-o Retea de Calculatoare [ELMA94]. Avantajele potentiale ale unei Baze de Date Distribuite sunt:

- Permiterea abordarii unor Sisteme Informatice care au o Natura Distribuita (Distribuire Geografica a Compartimentelor unei Societati, a Magaziilor unui Centru de Depozitare etc.). Situatia care apare în aceste cazuri este cea de separare a unor Prelucrari Locale curente de Prelucrarile Globale solicitate de centralizarea rezultatelor. Aceasta permite definirea unor Date, Proceduri, Aplicatii si Utilizatori legate în special de o anumita Statie

- Cresterea Fiabilitatii (Reliability) si Disponibilitatii (Availability) Sistemului Informatic, cu urmatoarele acceptii de termeni:

o Fiabilitate în functionare - probabilitatea ca sistemul sa fie în functiune la un moment dat; Fiabilitatea unui Sistem este data de Masura Gradului de Toleranta la Erori, prin activitatea asumata de Sistem în supravegherea si înlaturarea Erorilor. Aceasta activitate implica:

Statia 2Statia 1 Statia 3 Statia n

Server Server

Client Client Client

BD Locala

BD Centrala

BD Centrala +

BD Locala

RETEA de COMUNICATII

522 Baze de DateEvoluate / Baze de Date Distribuite

§ Detectarea Erorilor

§ Localizarea Erorilor

§ Reconfigurarea Sistemului în stare de Avarie

§ Repararea Erorilor

§ Relansarea Sistemului dupa Refacere

§ Combinarea Partajarii Resurselor (Date si Proceduri) cu posibilitatea Controlului Local

§ Îmbunatatirea Performantelor prin repartizarea consumurilor de Timp si Spatiu pe mai multe unitati de calcul

o Disponibilitate în functionare - probabilitatea ca sistemul sa fie în functiune în orice moment

Pentru asigurarea avantajelor potentiale ale unei Baze de Date Distribuite aceasta trebuie sa asigure urmatoarele Functiuni Specializate:

- Accesarea Statiilor la Distanta pentru a transmite, prin intermediul unei Retele de Comunicatii, Date si Cereri, însotite de Mesaje de Protocol

- Memorarea într-un Catalog al Bazei de Date Distribuite a Amplasarii Datelor precum si a Copiilor de Date (Replicarii Datelor )

- Utilizarea Strategiilor de Executare Distribuita a Cererilor si Tranzactiilor adresate mai multor Statii

- Alegerea Copiei de Date celei mai potrivite pentru un acces

- Mentinerea Consistentei Copiilor de Date

- Refacerea Datelor dupa Incidente Locale si de Comunicatie 7.2.3.1.2 Arhitecturi Client - Server

Arhitecturile Client - Server îsi propun sa distribuie Resursele unui Sistem Informatic (Date si Proceduri) prin concretizarea a doua concepte:

o Specializarea Procedurilor Distribuite

o Localizarea Datelor Distribuite

Specializarea Procedurilor Distribuite este efectuata prin multiplicarea Unitatilor de Calcul pe care pot fi depozitate Colectiile de Date si prin diversificarea functiunilor Unitatilor de Calcul prezente în Reteaua de Comunicatii (Unitati de Calcul de tip Server si Unitati de Calcul de tip Client).

Colectiile de Date vor fi dispuse pe un numar de Unitati de Calcul denumite Servere, fiecare având un anume Grad de Partajare declarat de Administrator. La acestea se adauga un numar de Unitati de Calcul denumite Client, care se însarcineaza cu asigurarea Interfetei Sistemului de Aplicatii cu Utilizatorii.

Baze de DateEvoluate / Baze de Date Distribuite 523

Localizarea Datelor Distribuite se poate face în doua moduri:

- Manual de catre Utilizator - prin declararea în Calea de Acces la Colectiile de Date a Statiei si Directorului de Rezidenta, care permit Localizarea si Identificarea Datelor

- Automat de catre Sistem - prin memorarea în Dictionarul Global al Datelor a Informatiilor de Localizare si de Identificare a Datelor, care sa permita Utilizatorului sa se dezintereseze de Distributia Datelor, facilitate denumita Transparenta Distributiei

Functiile de prelucrare pe care trebuie sa le asigure SGBD-ul distribuit (SGBDS) vor fi specializate si repartizate între Unitatile Server si Unitatile Client dupa cum urmeaza:

- Pe Servere, denumite si Procesoare de Baze de Date sau Masini Back - End

§ Motorul Relational - Modulele de Acces Neprocedural la Baza de Date, care realizeaza functia de Acces la Date

- Pe Clienti, denumiti si Procesoare de Aplicatii sau Masini Front - End

§ Interfata cu Utilizatorul - adresarea Cererilor de Acces catre Bazele de Date de pe Servere si care realizeaza functia de Distribuire a Cererilor

§ Programarea Aplicatiei, care utilizeaza Datele Accesate si realizeaza functia de Interfata cu Utilizatorul

7.2.3.2 Tehnici de proiectare a BDS

Intre Tehnicile care asigura Distribuirea Datelor pe Statiile unui SBDS vom prezenta urmatoarele:

- Fragmentarea - care consta în împartirea Bazei de Date în Unitati Logice, numite Fragmente , ce pot fi memorate pe Statii diferite în vederea cresterii Controlului asupra Datelor

- Replicarea - care consta în Multiplicarea Datelor (Crearea de Replici) pe mai multe Statii, în vederea cresterii performantelor de exploatare a Colectiilor de Date:

• Cresterea Vitezei de Acces la Date prin alegerea Replicii celei mai Accesibile

• Cresterea Sigurantei de Acces la Date în caz de Incident

- Alocarea - care consta în repartizarea Fragmentelor precum si a Copiilor de Date (Replicilor) pe Statiile din Retea

Informatiile referitoare la Fragmentare, Replicare si Alocare sunt memorate în Catalogul Global al Sistemului , care e accesat de Modulele Software ale Componentei Client din SGBDS. Localizarea în cadrul SBDS a Catalogului Global al Sistemului reprezinta o preocupare aparte, legata de Gradul dorit de Independenta a Componentelor SBDS , asa dupa cum a fost anticipat înca în sectiunea 7.2.2.

524 Baze de DateEvoluate / Baze de Date Distribuite

7.2.3.2.1 Tehnica de Fragmentare

In aceasta sectiune se considera ca datele în Baza de Date sunt memorate unic, neexistând Copii de Siguranta ale datelor, deci nu exista Replicare. Discutia se va purta asupra Modelului Relational de Date, extinderea putându-se face si asupra celorlalte Modele de Baze de Date. Fie urmatoarea Structura Relationala descrisa prin Schema de Relatii prezentata mai jos: COMPARTIMENTE (Cod *, Nume, Responsabil, Data-numirii) SEDII (Compartiment *, Localitate *) ANGAJATI (Nr-asigurare *, Nume, Prenume, Sex, Data-nasterii, Salariu,

Compartiment) PROIECTE (Cod *, Nume, Localitate, Compartiment) PROIECTANTI (Nr-asigurare *, Proiect *, Ore ) FAMILII (Nr-asigurare *, Nume *, Sex, Data-nasterii, Relatia-de-familie)

Fig. 7.2.3.2.1.1 Descrierea Intensionala a BD PROIECTE / COMPARTMENTE

Pentru a putea discuta Distribuirea Datelor se transcrie si o Extensiune a BD.

COMPARTIMENTE Cod* Nume Responsabil Data-numirii

c1 n1 na1 d1 c2 n2 na2 d2 c3 n3 na3 d3

SEDII

Compartiment * Localitate * c1 l1 c2 l2 c3 l2 c3 l3 c3 l4

ANGAJATI

Numar asigurare*

Nume Prenume Sex Data nasterii

Salariu Compartiment

na1 n1 p1 s1 d1 sa1 c3 na2 n2 p2 s1 d2 sa2 c3 na3 n3 p3 s2 d3 sa3 c2 na4 n4 p4 s1 d4 sa1 c2 na5 n5 p5 s2 d5 sa3 c3 na6 n6 p6 s2 d6 sa4 c3 na7 n7 p7 s1 d7 sa5 c2 na8 n8 p8 s1 d8 sa1 c1

Baze de DateEvoluate / Baze de Date Distribuite 525

FAMILII Nr-asigurare * Nume * Sex Data-nasterii Relatia-de-familie

na1 n1 s1 d1 r1 na1 n2 s1 d2 r2 na1 n3 s2 d3 r3 na3 n4 s1 d4 r1 na5 n2 s1 d1 r1 na5 n5 s2 d5 r2 na5 n1 s2 d3 r2

PROIECTE

Cod * Nume Localitate Compartiment cp1 np1 l1 c3 cp2 np2 l2 c3 cp3 np3 l3 c3 cp4 np4 l4 c2 cp5 np5 l3 c1 cp6 np6 l4 c2

PROIECTANTI

Nr-asigurare * Cod - Proiect * Ore na1 cp1 o1 na1 cp2 o9 na5 cp3 o2 na6 cp1 o1 na6 cp2 o8 na2 cp2 o2 na2 cp3 o7 na2 cp4 o1 na2 cp5 o6 na3 cp6 o2 na3 cp4 o1 na7 cp4 o5 na7 cp6 o2 na4 cp6 o2 na4 cp4 o3 na8 cp4 o4

Fig. 7.2.3.2.1.2 Descrierea extensionala a BD PROIECTE / COMPARTMENTE

Sa consideram ca în Societatea Comerciala descrisa de informatiile continute în Structura de Date prezentata exista trei Compartimente: C1, C2, C3, dintre care unul, C1, este cel de Conducere, interesat în activitatea tuturor Compartimentelor Societatii Comerciale.

526 Baze de DateEvoluate / Baze de Date Distribuite

Înainte de a decide cum vor fi distribuite datele pe Statii vor trebui determinate Unitatile Logice ale Bazei de Date. Unitatile Logice pot fi definite ca :

§ Relatii Întregi

§ Fragmente Orizontale de Relatii

§ Fragmente Verticale de Relatii

§ Fragmente Mixte de Relatii

In vederea Fragmentarii se va avea în vedere Distribuirea Interesului legat de întretinerea si consultarea Colectiilor de Date. 7.2.3.2.1.1 Fragmentarea Orizontala

Un Fragment Orizontal e definit de o Submultime de Tuple ale unei Relatii, specificata printr-o Conditie de Fragmentare, impusa asupra unei Expresii de Atribute din Relatie. Conditia de Fragmentare mai este denumita si Conditia de Garda (vezi si sectiunea 7.2.3.4.3 ).

Generarea unui Fragment Orizontal se face printr-o operatie de Selectie:

σ C i R

In Relatia ANGAJATI se pot defini trei Fragmente Orizontale atasate Valorilor Conditiei de Fragmentare:

Compartiment . Cod = Ci

si anume:

• K1 - Compartiment . Cod = C1

• K2 - Compartiment . Cod = C2

• K3 - Compartiment . Cod = C3

Aceste Fragmente Orizontale vor defini Angajatii fiecarui Compartiment. Similar vor putea fi definite Fragmente Orizontale corespunzatoare Relatiilor: SEDII, PROIECTE si FAMILII. Fragmentele astfel definite vor putea fi apoi memorate distribuit pe Statiile atribuite Compartimentelor. Problema care se ridica în continuare este cea de Refacere a Relatiilor Fragmentate Orizontal. Operatia de Refacere este cea de Reuniune a mai multe Fragmente Orizontale. Din aceste motive are semnificatie operatia de Fragmentare Orizontala Completa si Disjuncta, definita prin expresia:

∪ R i = R [ Ω ]

unde:

- R [ Ω ] – reprezinta Extensiunea Relatiei R

- R i - reprezinta un Fragment Orizontal Disjunct al Relatiei R

Fragmentare Orizontala Completa si Disjuncta ofera garantia Refacerii Integrale a Relatiei Originare din Fragmente Orizontale Disjuncte, fara Pierdere de Informatie (cum ar putea fi cazul în cazul Fragmentelor Nedisjuncte).

Baze de DateEvoluate / Baze de Date Distribuite 527

7.2.3.2.1.2 Fragmentarea Verticala

Un Fragment Vertical e definit de o Submultime de Atribute ale unei Relatii, specificata printr-o Lista de Atribute de Fragmentare, selectate dupa anumite criterii din Lista de Atribute ce Definesc Relatia.

Generarea unui Fragment Vertical se face printr-o operatie de Proiectie:

π L i R

unde L i - reprezinta Lista Atributelor de Fragmentare (de Proiectie).

O Fragmentare Verticala Completa si Disjuncta (Li) se defineste a fi cea care îndeplineste urmatoarele conditii:

- Listele Atributelor de Proiectie L i includ toate Atributele de Definitie a Relatiei R ( Ω )

∪ L i = Ω

- Listele Atributelor de Proiectie L i nu partajeaza decât Cheia Primara a Relatiei R ( Ω )

L i ∩ L j = K ( R ) pt. ∀ i , j Exemplu:

Pentru Relatia ANGAJATI:

§ Lista de Atribute Informatii Personale:

Nume, Prenume, Sex, Data-nasterii

§ Lista de Atribute Informatii de Serviciu:

Nr-asigurare, Salariu, Compartiment

Pentru a putea Reuni cele doua Relatii, în vederea Recompunerii Relatiei Originare, se cere ca amândoua Listele de Atribute sa contina Identificatorul (Cheia Primara) a Relatiei Initiale. Ca urmare relatia ANGAJATI va arata dupa Fragmentarea Verticala ca mai jos:

ANGAJATI-1 ( Nr-asigurare, Nume, Prenume, Sex, Data-nasterii)

ANGAJATI-2 ( Nr-asigurare, Nr-asigurare, Salariu, Compartiment)

Cele doua Fragmente Verticale vor deservi scopuri de prelucrare diverse, oferind strictul necesar de informatii pentru fiecare.

7.2.3.2.1.3 Fragmentarea Mixta

Prin combinarea celor doua forme de fragmentare se ajunge la Fragmentarea Mixta. In aceasta forma generalizata un Fragment se defineste a fi o combinatie de Selectie - Proiectie a unei Relatii:

π L i R ( σ C i R )

528 Baze de DateEvoluate / Baze de Date Distribuite

Refacerea Relatiilor Originare se va face prin aplicarea repetata a unor operatii de Reunire (în cazul general de Reunire Exterioara Completa) pentru a recupera eventualele situatii de neconcordanta a Tuplelor).

O Schema de Fragmentare a unei Baze de Date este reprezentata de definirea unei multimi de Fragmente care sa îndeplineasca urmatoarele conditii:

- Sa contina toate Atributele Relatiilor din Schema de Definire initiala

- Fragmentele sa fie de regula (nu neaparat) Disjuncte, cu exceptia repetarii Cheii Primare

Fragmentele ca Unitati Logice de Distribuire a Datelor vor avea atasate prin operatia de Alocare , Statia de depozitare, putând fi de asemenea Multiplicate prin copiere (Replicare). 7.2.3.2.2 Tehnica de Replicare

Replicarea consta în asigurarea Copiilor de Date (Replicilor) necesare, care sa permita atingerea gradului dorit de Fiabilitate si Disponibilitate a sistemului. Replicarea opereaza la nivelul Unitatilor Logice create prin Fragmentare.

Replicarea sporeste Fiabilitatea si Disponibilitatea sistemului, cu pretul cresterii duratelor de:

- Actualizare a Datelor - întretinerea datelor trebuind efectuata atât pe colectiile initiale cât si pe toate copiile create prin replicare

- Acces la Date în conditiile de incident - accesul nu se va mai putea face pe colectiile initiale performante, ci pe copia învecinata cea mai apropiata

Exista doua extreme în utilizarea facilitatilor oferite de Replicare :

- BDS fara Replicare - viteza maxima , fiabilitate minima

- BDS cu Replicare totala - viteza minima , fiabilitate maxima

Declararea Copiilor de Fragmente este facuta în Schema de Replicare memorata în Catalogul Global al Sistemului Distribuit, pentru a fi pus la dispozitia tuturor utilizatorilor. 7.2.3.2.3 Tehnica de Alocare

Functia de Alocare se însarcineaza cu memorarea si gestionarea Localizarii pe Statiile Sistemului Distribuit a Resurselor de Date (Fragmente si Copii). Aceasta informatie este consemnata în Catalogul Global al Sistemului Distribuit, ea permitând realizarea facilitatii de Transparenta oferita de BDS.

Alegerea Gradului de Distribuire a Resurselor este, la nivel teoretic, o problema de Asigurare a unui Optim. In practica se cauta o Solutie Acceptabila, avându-se în vedere o serie de recomandari legate de Influentele, Pozitive si Negative pe care le implica Distribuirea Datelor:

- Interesul Local fata de anumite Colectii de Date restrânge necesitatea de Replicare

Baze de DateEvoluate / Baze de Date Distribuite 529

- Actualizari Multiple si Distribuite recomanda Replicare Totala

- Alocarea sa fie facuta în functie de Frecventa de Consultare a Datelor pe diferitele Statii

7.2.3.2.4 Studiu de Caz

Sa pornim cu datele initiale prezentate în sectiunea 7.2.3.2.1, la care sa adaugam urmatoarele informatii. Sa consideram ca Statiile Retelei Distribuite de Calculatoare sunt repartizate astfel :

- Statia C1 - la Compartimentul Central, care asigura Conducerea Societatii, realizând functiile:

§ Controlul întregii activitati a societatii (Angajati, Proiectanti, Proiecte )

§ Gestiunea Asigurarilor Sociale pentru Membrii Familiilor Angajatilor

- Statia C2 - la Compartimentul C2 cu functiile:

§ Gestiunea datelor Angajatilor lucrând la Compartimentul C2

§ Gestiunea datelor Proiectelor controlate de Compartimentul C2

- Statia C3 - la Compartimentul C3 cu functiile:

§ Gestiunea datelor Angajatilor lucrând la Compartimentul C3

§ Gestiunea datelor Proiectelor controlate de Compartimentul C3

Aceasta dispunere a statiilor precum si interesele de prelucrare ale acestora conduce la urmatoarea distribuire a datelor :

- Pe Statia C1 - toate datele din sistem

- Pe Statia C2 - datele din sistem care se refera la Angajatii si Proiectele Statiei C2

- Pe Statia C3 - datele din sistem care se refera la Angajatii si Proiectele Statiei C3

Pentru ANGAJATII Statiei C2 si C3 intereseaza doar Atributele:

Nr-asigurare , Nume , Prenume , Salariu , Compartiment

Problema devine mai delicata referitor la datele Relatiei de Legatura PROIECTANTI, unde interesul local al Statiei C2 si C3 este legat atât de PROIECTELE Compartimentelor, cât si de PROIECTELE la care lucreaza ANGAJATII Compartimentelor. Aceasta situatie da nastere la urmatoarele Fragmente de Date Disjuncte definite prin Conditiile de Garda descrise Intensional si prin Listele de Atribute prezente în Extensiunea Fragmentelor: PROIECTANTI - fragment 1 - Conditia de Garda:

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c3)

AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment = c3)

530 Baze de DateEvoluate / Baze de Date Distribuite

PROIECTANTI - fragment 1 Nr-asigurare * Cod-proiect * Ore

na1 cp1 o1 na1 cp2 o9 na5 cp3 o2 na6 cp1 o1 na6 cp2 o8 na2 cp2 o2 na2 cp3 o7

PROIECTANTI - fragment 2 - Conditia de Garda:

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c3) AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c2)

PROIECTANTI - fragment 2

Nr-asigurare * Cod-proiect * Ore na2 cp4 o1

PROIECTANTI - fragment 3 - Conditia de Garda:

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c3) AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c1)

PROIECTANTI - fragment 3

Nr-asigurare * Cod-proiect * Ore na2 cp5 o6

PROIECTANTI - fragment 4 - Conditia de Garda:

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c2) AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c3)

PROIECTANTI - fragment 4

Nr-asigurare * Cod-proiect * Ore PROIECTANTI - fragment 5 - Conditia de Garda:

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c2)

Baze de DateEvoluate / Baze de Date Distribuite 531

AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c2)

PROIECTANTI - fragment 5

Nr-asigurare * Cod-proiect * Ore na3 cp6 o2 na3 cp4 o1 na7 cp4 o5 na7 cp6 o2 na4 cp6 o2

PROIECTANTI - fragment 6 - Conditia de Garda:

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c2) AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c1)

PROIECTANTI - fragment 6

Nr-asigurare * Cod-proiect * Ore na4 cp4 o3

PROIECTANTI - fragment 7 - Conditia de Garda:

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c1) AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c3)

PROIECTANTI - fragment 7

Nr-asigurare * Cod-proiect * Ore PROIECTANTI - fragment 8 - Conditia de Garda:

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c1) AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c2)

PROIECTANTI - fragment 8

Nr-asigurare * Cod-proiect * Ore PROIECTANTI - fragment 9 - Conditia de Garda:

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c1)

532 Baze de DateEvoluate / Baze de Date Distribuite

AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c1)

PROIECTANTI - fragment 9

Nr-asigurare * Cod-proiect * Ore na8 cp4 o4

Ca urmare :

PROIECTANTII care lucreaza în COMPARTIMENTUL c3 sunt dati de:

PROIECTANTI 1 ∪ PROIECTANTI 2 ∪ PROIECTANTI 3

PROIECTANTII care lucreaza în COMPARTIMENTUL c2 sunt dati de:

PROIECTANTI 4 ∪ PROIECTANTI 5 ∪ PROIECTANTI 6

PROIECTANTII care lucreaza la PROIECTE din COMPARTIMENTUL c3 sunt dati de:

PROIECTANTI 1 ∪ PROIECTANTI 4 ∪ PROIECTANTI 7

PROIECTANTII care lucreaza la PROIECTE din COMPARTIMENTUL c2 sunt dati de:

PROIECTANTI 2 ∪ PROIECTANTI 5 ∪ PROIECTANTI 8

In aceste conditii este recomandata urmatoarea distribuire de date pe statii:

- pe Statia C3: PROIECTANTI 1 ∪ PROIECTANTI 2 ∪ PROIECTANTI 3 ∪ PROIECTANTI 4 ∪

PROIECTANTI 7 - pe Statia C2:

PROIECTANTI 4 ∪ PROIECTANTI 5 ∪ PROIECTANTI 6 ∪ PROIECTANTI 2 ∪ PROIECTANTI 8

Aceasta necesitate de distribuire a datelor conduce la replicarea Fragmentelor PROIECTANTI 2 si PROIECTANTI 4 pe ambele statii C2 si C3 . Avantajele create prin aceasta redondanta sunt date de permiterea realizarii operatiilor de Reunire (Cuplare) a Relatiei PROIECTANTI cu ambele Relatii ANGAJATI si PROIECTE exclusiv pe Statiile Locale.

Statia C1

Pe aceasta statie va fi implementata întreaga structura a Bazei de Date (vezi descrierea din Fig. 8.2.1.1) . Statia C2

COMPARTIMENTE Cod * Nume Responsabil Data-numirii

c2 n2 na2 d2

Baze de DateEvoluate / Baze de Date Distribuite 533

SEDII Cod-compartiment * Localitate *

c2 l2

ANGAJATI Nr-asigurare * Nume Prenume Salariu Compartiment

na3 n3 p3 sa3 c2 na4 n4 p4 sa1 c2 na7 n7 p7 sa5 c2

PROIECTE

Cod* Nume Localitate Compartiment cp4 np4 l4 c2 cp6 np6 l4 c2

PROIECTANTI

Nr-asigurare * Cod-proiect * Ore na1 cp1 o1 na1 cp2 o9 na5 cp3 o2 na6 cp1 o1 na6 cp2 o8 na2 cp2 o2 na2 cp3 o7 na2 cp4 o1 na2 cp5 o6

Statia C3

COMPARTIMENTE Cod* Nume Responsabil Data-numirii

c3 n3 na3 d3

SEDII Cod-compartiment * Localitate *

c3 l2 c3 l3 c3 l4

ANGAJATI

Nr-asigurare * Nume Prenume Salariu Compartiment na1 n1 p1 sa1 c3 na2 n2 p2 sa2 c3 na5 n5 p5 sa3 c3 na6 n6 p6 sa4 c3

534 Baze de DateEvoluate / Baze de Date Distribuite

PROIECTE Cod * Nume Localitate Compartiment cp1 np1 l1 c3 cp2 np2 l2 c3 cp3 np3 l3 c3

PROIECTANTI

Nr-asigurare * Cod-proiect * Ore na2 cp4 o1 na3 cp6 o2 na3 cp4 o1 na7 cp4 o5 na7 cp6 o2 na4 cp6 o2 na4 cp4 o3

Fig. 6.3.1.1 Baza de Date Distribuita PROIECTE/COMPARTMENTE

7.2.3.3 Tipuri de Baze de Date Distribuite

Exista diferite tipuri de Baze de Date Distribuite (BDS), toate însa având în comun capacitatea de distribuire a Resurselor (Date si Proceduri). Pentru a putea sesiza particularitatile diferitelor tipuri de BDS se prezinta în continuare caracteristicile specifice potrivit mai multor criterii de clasificare.

7.2.3.3.1 Criteriul de Omogenitate

Criteriul de Omogenitate se refera la Tipul SGBD-ului care este implementat pe unitatile Server si Client. Conform acestui criteriu BDS pot fi :

- Omogene - când acelasi SGBD ruleaza pe toate unitatile din sistemul distribuit

- Neomogene - când SGBD-uri de tipuri diferite, variante diferite, sau produse comerciale lansate de producatori diferiti, ruleaza pe unitatile din sistemul distribuit; în acest caz este necesar ca BDS sa contina module Software care sa asigure conversia necesara a Structurilor de Date precum si a Cererilor adresate Bazelor de Date Neomogene. Definirea unui Limbaj Unificat este adesea o solutie foarte recomandata de comunicare între SGBD-urile heterogene

7.2.3.3.2 Criteriul de Autonomie

Criteriul de Autonomie are în vedere modul de realizare a Accesului la Baza de Date Distribuita. Rezulta urmatoarele variante :

- BDS fara Autonomie Locala - orice acces la BDS este permis numai indirect, prin intermediul unei unitati Client, ceea ce va cere alinierea la conditiile impuse de Mediul de Dezvoltare implementat pe unitatea Client

Baze de DateEvoluate / Baze de Date Distribuite 535

- BDS cu Autonomie Locala - accesul la BDS este permis si direct, prin intermediul unei unitati Server, Utilizatorul putând alege în acest caz Medii Proprii de Dezvoltare

O Baza de Date Distribuita fara Autonomie Locala se apropie de viziunea unei Baze de Date Centralizate prin acea ca :

- Exista o Schema Unica de Descriere

- Accesul se face numai prin Mediul Client

- Nu exista Particularitati Locale pentru nici un Client

O Baza de Date Distribuita cu Autonomie Locala poarta numele si de Baza de Date Distribuita Federativa sau Sistem de Baze de Date Distribuite Multiple. Fiecare Server din Sistemul Distribuit este o BD Centralizata având:

- Un Mediu de Dezvoltare Local

- Utilizatori Locali, care acceseaza unitatea Server prin intermediul Mediului Propriu de Dezvoltare

- Utilizatori Globali, care acceseaza direct unitatea Server din alt Mediu de Dezvoltare

7.2.3.3.3 Criteriul de Transparenta

Acest criteriu ia în considerare proportia în care Sarcinile de Distribuire si de Localizare a Resurselor sunt preluate de Sistem sau lasate în sarcina Utilizatorului. Variantele extreme sunt urmatoarele:

- Grad Scazut de Transparenta - utilizatorul vede Fragmentarea, Replicarea si Alocarea , trebuind sa le controleze prin declarare în toate accesele

- Grad Înalt de Transparenta - sistemul gestioneaza automat Fragmentarea, Replicarea si Alocarea, prin memorarea informatiilor necesare în Baza de Date

7.2.3.4 Procesarea Cererilor în Baze de Date Distribuite

7.2.3.4.1 Costurile în Procesarea Distribuita

La problemele ridicate de Optimizarea Cererilor în Bazele de Date Centralizate, se adauga în cazul Bazelor de Date Distribuite câteva probleme specifice, dintre care de prima importanta este Evaluarea Costului Transferului Datelor prin Reteaua de Comunicatie, denumita prescurtat Costul Transferului de Date. Evaluarea acestui cost implica :

- Costul Transferului Fisierelor Intermediare de Date

- Costul Transferului Fisierului Final de Date

- Importanta Distantei de Transmisie a Datelor fata de Viteza de Transmisie din Retea

536 Baze de DateEvoluate / Baze de Date Distribuite

Criteriul de Optimizare utilizat în SGBDS se refera la Reducerea Costului Transferului de Date.

Fie urmatoarea Distribuire de Date în Retea:

Statia 1

ANGAJATI (Nr-asigurare*, Nume, Prenume, Sex, Data-nasterii, Salariu, Compartiment) - Extensiune - 10.000 înregistrari - Lungime înregistrare - 100 octeti - Lungime câmp Nr-asigurare - 9 octeti - Lungime câmp Compartiment - 4 octeti - Lungime câmp Nume - 15 octeti - Lungime câmp Prenume - 15 octeti

Statia 2

COMPARTIMENTE ( Cod * , Nume, Responsabil, Data-numirii ) - Extensiune - 100 înregistrari - Lungime înregistrare - 35 octeti - Lungime câmp Cod - 4 octeti - Lungime câmp Nume - 10 octeti - Lungime câmp Responsabil - 9 octeti

Consideram ca Relatiile nu sunt Fragmentate. Exemplul 1

Fie Cererea:

Pentru fiecare ANGAJAT, Numele si Prenumele ANGAJATULUI si Numele COMPARTIMENTULUI pentru care lucreaza.

Formularea în Algebra Relationala e urmatoarea:

π ANGAJATI.Nume , ANGAJATI.Prenume , COMPARTIMENTE.Nume

( ANGAJATI ρ ANGAJATI.Compartiment = COMPARTIMENTE.Cod COMPARTIMENTE )

Sa consideram ca Rezultatul e asteptat pe Statia 3 incluzând 10.000 de înregistrari a 40 de octeti. Se dau mai jos câteva Strategii de realizare a acestei Cereri Distribuite:

Strategia 1

- Transferare Relatii ANGAJATI si COMPARTIMENTE pe Statia 3

( 1.000.000 + 3.500 = 1.003.500 octeti )

- Executie Reunire pe Statia 3 Strategia 2

- Transferare Relatie ANGAJATI pe Statia 2

( 1.000.000 octeti )

Baze de DateEvoluate / Baze de Date Distribuite 537

- Executie Reunire pe Statia 2

- Transferare Relatie Rezultat pe Statia 3

( 40 x 10.000 = 400.000 octeti )

Strategia 3

- Transferare Relatie COMPARTIMENTE pe Statia 1

( 3.500 octeti )

- Executie Reunire pe Statia 1

- Transferare Relatie Rezultat pe Statia 3

( 40 x 10.000 = 400.000 octeti )

Potrivit criteriului ales Strategia Optima este Strategia 3 .

Exemplul 2

Fie Cererea:

Pentru fiecare COMPARTIMENT, Numele COMPARTIMENTULUI împreuna cu Numele si Prenumele Responsabilul de COMPARTIMENT

Formularea în Algebra Relationala este urmatoarea:

π COMPARTIMENTE.Nume , ANGAJATI.Nume , ANGAJATI.Prenume

( COMPARTIMENTE ρ COMPARTIMENTE.Responsabil = ANGAJATI.Nr-asigurare ANGAJATI )

Sa consideram ca Rezultatul e asteptat pe Statia 3 incluzând 100 de înregistrari a 40 de octeti. In aceste conditii rezulta urmatoarele Strategii de realizare ale acestei Cereri Distribuite:

Strategia 1

- Transferare Relatii ANGAJATI si COMPARTIMENTE pe Statia 3

( 1.000.000 + 3.500 = 1.003.500 octeti )

- Executie Reunire pe Statia 3

Strategia 2

- Transferare Relatie ANGAJATI pe Statia 2

( 1.000.000 octeti )

- Executie Reunire pe Statia 2

- Transferare Relatie Rezultat pe Statia 3

( 40 x 100 = 4000 octeti )

538 Baze de DateEvoluate / Baze de Date Distribuite

Strategia 3

- Transferare Relatie COMPARTIMENTE pe Statia 1

( 3.500 octeti )

- Executie Reunire pe Statia 1

- Transferare Relatie Rezultat pe Statia 3

( 40 x 100 = 4000 octeti )

Potrivit criteriului ales Strategia Optima este Strategia 3 .

Exemplul 3 Sa consideram aceleasi date ca în exemplele precedente, doar ca Rezultatele sunt asteptate pe Statia 2. Strategiile de realizare ale acestei noi Cereri Distribuite sunt:

Strategia 4

- Transferare Relatie ANGAJATI pe Statia 2

( 1.000.000 octeti )

- Executie Reunire pe Statia 3

Strategia 5

- Transferare Relatii COMPARTIMENTE pe Statia 1

( 3.500 octeti )

- Executie Reunire pe Statia 1

- Transferare Relatie Rezultat pe Statia 2

( 40 x 10.000 = 400.00 octeti ) - pentru exemplul 1

( 40 x 100 = 4000 octeti ) - pentru exemplul 2

Potrivit criteriului ales Strategia Optima este Strategia 3 .

7.2.3.4.2 Procesarea Cererilor Distribuite prin Operatia de SEMIJOIN

Ideea în cazul utilizarii Operatiei de SEMIJOIN (ϕ) este de a reduce Numarul Tuplelor Relatiei ce urmeaza a fi transferata pe o alta Statie. Reducerea se efectueaza astfel:

- Transferul pe Statia Vecina doar a Coloanei pe care se efectueaza Operatia de JOIN

- Efectuarea Operatiei de JOIN

- Proiectia Rezultatului pe Lista Atributelor din Rezultat

- Transferul Rezultatului înapoi pe Statia Initiala

- Efectuarea Operatiei de JOIN cu Relatia Initiala

Baze de DateEvoluate / Baze de Date Distribuite 539

Exemplu:

Ca exemplificare reluam prin aceasta metoda Strategia propusa pentru exemplele anterioare (1 si 2).

- Proiectia Relatiei COMPARTIMENTE pe Atributele de JOIN pe Statia 2

§ Pentru exemplul 1:

T = π COMPARTIMENTE.Cod (COMPARTIMENTE)

(4 x 100 = 400 octeti)

§ Pentru exemplul 2:

T = π COMPARTIMENTE.Responsabil (COMPARTIMENTE)

(9 x 100 = 900 octeti)

- Transferul Proiectiei pe Statia 1 - Operatie de JOIN si Proiectie pe Atributele partiale din Rezultat, pe Statia 1

§ Pentru exemplul 1:

R=π T.Cod, ANGAJATI.Nume, ANGAJATI.Prenume (T ρ T.Cod=ANGAJATI.Compartiment ANGAJATI)

( 34 x 10.000 = 340.000 octeti )

§ Pentru exemplul 2:

R=π T. Responsabil, ANGAJATI.Nume, ANGAJATI.Prenume (T ρ T. Responsabil =ANGAJATI. Nr-Asigurare ANGAJATI)

( 39 x 100 = 3.900 octeti) - Transferul Rezultatului R pe Statia 2 - Operatie de JOIN a lui R cu Relatia COMPARTIMENTE pentru preluarea

Atributului COMPARTIMENTE.Nume pe Statia 2 (fara nici-un Cost Suplimentar de Transfer de Date)

Se remarca eficienta metodei în cazul Exemplului 2 când transferul de ANGAJATI de pe Statia 1 pe Statia 2 e redus la numai 3.900 de octeti din 340.000 de octeti.

O operatie de SEMIJOIN se noteaza cu :

R ϕ A = B S

unde Listele de Atribute A si B au Domenii Compatibile.

Expresia este echivalenta cu urmatoarele operatii de algebra relationala :

π < R > ( R ρ A = B S )

Intr-un mediu distribuit unde R si S sunt dispuse pe statii diferite Operatia de Semijoin se implementeaza astfel :

§ Transferare F = π < B > S pe statia lui R

§ Reunire F ρ A = B R

540 Baze de DateEvoluate / Baze de Date Distribuite

7.2.3.4.3 Descompunerea Cererilor si Actualizarilor

In cazul BDS descompunerea operatiilor solicitate (Cereri sau Actualizari) trebuie sa ia în considerare Gradul de Transparenta oferit de SGBDS.

Fie BDS prezentata în exemplele anterioare si fie Cererea:

Numele si orele lucrate de angajatii care lucreaza pentru proiecte controlate de compartimentul 3

In cazul absentei transparentei utilizatorii trebuie sa specifice explicit daca cererea invoca :

- Relatiile ANGAJATI si PROIECTE de pe Statia 1

- Relatiile ANGAJATI si PROIECTE de pe Statia 3

De asemenea în cazul unei actualizari de date utilizatorii trebuie sa se preocupe de asigurarea mentinerii consistentei datelor în cazul replicarii lor, daca nu exista transparenta la replicare. In cazul existentei transparentei totale (la Fragmentare si Replicare), utilizatorii vor putea adresa Cererile ca si cum ar lucra pe o Baza de Date Centralizata. In acest caz sistemul se însarcineaza sa efectueze automat urmatoarele operatii :

- In cazul Cererilor

§ Descompunerea Cererilor în Subcereri

§ Distribuirea Subcererilor pe Statii

§ Alegerea Strategiei de Executare a Cererilor si de obtinere a Rezultatului Final

§ Alegerea (Materializarea) Replicii (Copie de Date) celei mai avantajoase

- In cazul Actualizarilor

§ Alegerea Algoritmului pentru Controlul Concurentei Distribuite

§ Mentinerea Consistentei Datelor la fiecare Actualizare

Acest lucru este posibil prin utilizarea informatiilor memorate în Catalogul BDS care contine:

- Pentru fiecare Fragment Vertical - Lista de Atribute

- Pentru fiecare Fragment Orizontal - Conditia de Garda

- Pentru fiecare Fragment Mixt - Ambele Seturi de Informatii

Conditia de Garda e numita astfel întrucât ea contine expresia care permite sau interzice actualizarea Fragmentului, putând totodata oferi informatii referitoare la ce date pot fi regasite în Fragment. In exemplele precedente aceste informatii sunt:

- Pentru Statia 1 - pentru toate relatiile § Lista de Atribute - * (Toate Atributele) § Conditia de Garda - Adevarata (Toate Tuplele)

- Pentru Statia 2 o Tabela ANGAJATI-2

Baze de DateEvoluate / Baze de Date Distribuite 541

§ Lista de Atribute - Nr-asigurare *, Nume, Prenume, Salariu, Compartiment

§ Conditia de Garda - ANGAJATI.Compartiment = 2 o Tabela COMPARTIMENTE-2 § Lista de Atribute - * (toate atributele) § Conditia de Garda - COMPARTIMENTE.Cod = 2

o Tabela SEDII-2 § Lista de Atribute - * (toate atributele) § Conditia de Garda - SEDII.Compartiment = 2

o Tabela PROIECTE-2 § Lista de Atribute - * (toate atributele) § Conditia de Garda - PROIECTE.Compartiment = 2

o Tabela PROIECTANTI-2 § Lista de Atribute - * (toate atributele)

§ Conditia de Garda - ANGAJATI.Nr-asigurare IN ( π Nr-asigurare ANGAJATI-2 ) OR Cod-proiect IN ( π Nr-asigurare PROIECTANTI-2)

- Pentru Statia 3 o Tabela ANGAJATI-3 § Lista de Atribute - Nr-asigurare *, Nume, Prenume, Salariu,

Compartiment § Conditia de Garda - ANGAJATI.Compartiment = 3

o Tabela COMPARTIMENTE-3 § Lista de Atribute - * (toate atributele) § Conditia de Garda - COMPARTIMENTE.Cod = 3

o Tabela SEDII-3 § Lista de Atribute - * ( toate atributele ) § Conditia de Garda - SEDII.Compartiment = 3

o Tabela PROIECTE-3 § Lista de Atribute - * (toate atributele) § Conditia de Garda - PROIECTE.Compartiment = 3

o Tabela PROIECTANTI-3 § Lista de Atribute - * (toate atributele) § Conditia de Garda - ANGAJATI.Nr-asigurare IN ( π Nr-asigurare

ANGAJATI-3 ) OR Cod-proiect IN ( π Nr-asigurare PROIECTANTI-3) Fie de inserat în relatia ANGAJATI tupla:

na7 n7 p7 s2 d7 sa7 c3 Sistemul de gestiune BDS va descompune aceasta operatie în doua:

- Inserare tupla în ANGAJATI-1 na7 n7 p7 s2 d7 sa7 c3

- Inserare tupla în ANGAJATI-3

na7 n7 p7 sa7 c3

542 Baze de DateEvoluate / Baze de Date Distribuite

Pentru descompunerea cererilor sistemul va putea determina care Fragment contine datele solicitate prin compararea Conditie de Selectie cu Conditia de Garda.

Fie cererea: Numele, Prenumele si Orele prestate, pentru orice ANGAJAT care lucreaza la un

PROIECT controlat de COMPARTIMENTUL 3

a carei specificare în SQL este :

SELECT Nume, Prenume, Ore FROM ANGAJATI, PROIECTE, PROIECTANTI WHERE PROIECTE.Compartiment=3 AND PROIECTE.Cod = PROIECTANTI.Cod-proiect AND ANGAJATI.Nr-asigurare = PROIECTANTI. Nr-asigurare

Consideram ca Cererea a fost lansata pe Statia 3 unde se si asteapta raspunsul. Sistemul poate determina din Conditiile de Garda pentru PROIECTE-3 si PROIECTANTI-3 ca toate Tuplele ce pot satisface conditia ANGAJATI.Compartiment=3 AND PROIECTANTI.Cod-proiect=PROIECTE.Cod se afla pe aceasta Statie. Ca urmare el poate descompune cererea în urmatoarele Subcereri:

- T1 = π PROIECTANTI -3.Nr-asigurare

(PROIECTE-3 ρ PROIECTE-3.Cod = PROIECTANTI -3.Cod-proiect PROIECTANTI-3)

- T2 = π ANGAJATI -1.Nr-asigurare, Nume, Prenume

(T1 ρ T1.Nr-asigurare = ANGAJTI -1.Nr-asigurare ANGAJATI-1)

- R = π T2 . Nume, Prenume, PROIECTANTI -3 . Ore

( T2 ρ* Nr-asigurare PROIECTANTI -3)

In expresiile de mai sus ρ* reprezinta operatia de JOIN NATURAL (ECHI - JOIN )cu Atributele din Conditie Omonime , fapt care face ca în conditie sa apara scrise o singura data (Ex. Nr.asigurare). Executia acestei Cereri Descompuse poate fi efectuata cu o Strategie de SEMIJOIN:

- Executie Subcerere T1 pe Statia 3 (pentru preluarea Nr.asigurare de la ANGAJATII care lucreaza la PROIECTE controlate de COMPARTIMENTUL 3)

- Transferul Rezultatului pe Statia 1

- Executia Subcererii T2 pe Statia 1 (pentru preluarea datelor ANGAJATILOR care lucreaza la PROIECTE controlate de COMPARTIMENTUL 3, dar nu fac parte din acesta )

- Transferul Rezultatului pe Statia 3

- Calculul Rezultatului R pe Statia 3 (pentru preluarea Orelor din relatia PROIECTANTI )

Baze de DateEvoluate / Baze de Date Distribuite 543

O Strategie Alternativa este :

- Transferul Cererii Initiale pe Statia 1

- Executia Cererii pe Statia 1

- Transferul Rezultatului pe Statia 3

Optimizatorul de Cereri va decide între cele doua Strategii posibile. 7.2.3.5 Controlul Concurentei si al Securitatii

Prolema Controlului Concurentei si al Securitatii în regim Distribuit face parte din domeniile aflate înca în curs de investigare, neexistând înca solutii practice general valabile. Daca gasim potrivit a face o incursiune în aceasta problematica este pentru a adauga noi dovezi de promovare a acelorasi Concepte Fundamentale sustinute cu perseverenta de SBD. Este vorba în primul rând de urmarirea Dependentelor existente între Elementele chemate sa asigure Coerenta Sistemelor Distribuite în conditii acceptabile de Performanta (Statii Centrale si Locale, Statii Omogene si Specializate, Dictionare Centrale si Distribuite, Marcaje de Blocare Concentrate sau Distribuite etc.).

Pe scurt, domeniul ofera un nou prilej de a asista la acelasi efort de asigurare a Maximei Independente în interiorul unei Structuri, de data aceasta Distribuita. 7.2.3.5.1 Generalitati

BDS ridica numeroase probleme specifice în ceea ce priveste subiectele care implica alaturi de Calcul si Comunicarea. Acest lucru complica în special Situatiile de Incident în care Sistemu l trebuie sa ia cunostinta de acest fapt tot prin intermediul Comunicatiei.

Problemele specifice de Concurenta si Securitate care apar în BDS fata de BD sunt sintetizate mai jos:

- Operarea cu mai multe Copii de Date – în caz de incident Procedurile de Securitate vor trebui sa refaca orice Copie Distrusa , aducând-o într-o Stare Consistenta cu celelalte Copii de Date, continând aceleasi Informatii

- La Caderea unei Statii - sistemul trebuie sa permita continuarea functionarii celorlalte Statii, iar, dupa repararea incidentului si refacerea Copiei Distruse, sa o aduca în concordanta cu celelalte Copii de Date, înainte de reconectarea la sistem, conform cu sarcina enuntata anterior

- Caderea Legaturilor de Comunicatie - cea mai delicata pana este Partitionarea Retelei de Comunicatii în mai multe Zone ramase Intern Conectate, dar Izolate de restul Zonelor

- Executia Operatiei COMMIT Distribuita (Executie Tranzactie Validata vezi sectiunea 6.2.3) - Caderea unor Statii pe care sunt Distribuite Datele în timpul Operatiei de COMMIT necesita lucrul cu un Protocol de COMMIT în Doi Pasi (vezi sectiunea 7.2.3.5.4)

544 Baze de DateEvoluate / Baze de Date Distribuite

- Realizarea Blocarii Distribuite - în cazul Blocarii mai multor Statii trebuiesc folosite Tehnici Speciale de Deblocare

7.2.3.5.2 Controlul Concurentei Distribuite cu Copie Distincta a Datelor

Ideea de baza costa în mentinerea unei Copii Distincte pentru toate Datele din sistem în vederea memorarii într-un singur loc a Starii de Blocare sau Deblocare a Datei. La aceasta Copie Unica vor apela toate Cererile de Blocare sau Deblocare a Datelor.

Solutia prezentata sugereaza deja problema care se ridica în legatura cu Localizarea acestei Copii Distincte oferindu-se pentru acest caz cele doua posibilitati extreme de Concentrare sau Distribuire a acestei Copii de Date si odata cu ea a Marcajelor de Blocare / Deblocare.

In continuare vor fi analizate metodele de Implementare Distribuita a Functiei de Asigurare a Concurentei. 7.2.3.5.2.1 Tehnica Statiei Primare

O Singura Statie în Sistem e aleasa ca si Coordonator pentru rezolvarea Cererilor Blocate. Exemplu:

Daca toate Tranzactiile se efectueaza potrivit Protocolului de Blocare în Doi Pasi (vezi sectiunea 7.2.3.5.4) este garantata Serializabilitatea Tranzactiei (vezi sectiunea 6.2.8).

Sa analizam caracteristicile acestei metode: Avantaje:

- Preia metoda de Control a Concurentei din BD Centralizate

- Utilizeaza Algoritmi Verificati în exploatarea BD Dezavantaje:

- Conduce la Strangularea Statiei Primare cu mesajele de Blocare / Deblocare

- Poate cauza Paralizarea Sistemului prin concentrarea Informatiilor de Control pe o Statie Unica, cu scaderea drastica a Sigurantei în Functionare (Fiabilitate si Disponibilitate – vezi sectiunea 7.2.3.1.1)

Tratamente:

- Prevederea ca în starea Blocare-Citire - Tranzactia sa poata accesa orice Copie a Datei

- Prevederea ca în starea Blocare-Scriere - Tranzactia sa poata scrie într-o Copie a Datei, în timp ce Sistemul va actualiza toate Copiile de Date înainte de lansarea Operatiei de Deblocare

In concluzie metoda prezinta o prima solutie de rezolvare a Controlului Concurentei, inspirata din BD Centralizate, cu toate caracteristicile care decurg de aici în privinta limitelor Centralizarii Gestiunii de Resurse.

Baze de DateEvoluate / Baze de Date Distribuite 545

7.2.3.5.2.2 Tehnica Statiei Primare cu Statie de Salvare

In aceasta tehnica se rezerva o Statie de Salvare pentru memorarea Starii de Blocare / Deblocare. Rezultatele acestei solutii sunt sintetizate mai jos:

- Creste Siguranta in Functionare prin specializarea unei Statii cu gestiunea exclusiva a Functiior de Blocare / Deblocare a Resurselor

- Scade Raspunsul la Tranzactii prin impunerea necesitatii de consultare a înca unei Statii pe parcursul fiecarei Tranzactii

- Creste Timpul de Demarare a Sistemului care trebuie sa genereze Copia de Salvare înainte de demararea lucrului

- Statia de Salvare poate înlocui Statia Primara în caz de Incident, caz în care Sistemul va alege o noua Statie de Salvare

7.2.3.5.2.3 Tehnica Copiei Primare

Tehnica Copiei Primare se bazeaza pe memorarea distribuita a acestei Copii de Date pe mai multe Statii. Efectele scontate sunt urmatoarele:

- O Cadere de Statie afecteaza doar datele localizate pe Statia Defecta

- Se poate Creste Disponibilitatea prin atasarea în configuratie a Statiilor de Salvare

7.2.3.5.2.4 Tehnica Alegerii Dinamice a Coordonatorului

In aceasta tehnica se ia în considerare problema Realegerii unei Noi Statii Coordonatoare în caz de defectiune. Metoda consta în:

- Utilizarea Copiilor de Salvare pentru efectuarea Tranzactiilor Neîncheiate (vezi sectiunea 6.3)

- Daca nu exista Copii de Salvare, Tranzactiile trebuie Relansate

- La incidente Sistemul Alege Noul Coordonator si efectueaza Copierea Datelor pe noua Statie Coordonatoare

- Alegerea Coordonatorului poate fi facuta prin Votul Tuturor Statiilor mentinute înca în functiune

7.2.3.5.3 Controlul Concurentei Distribuite prin Tehnica Votarii

In cazul Controlului Concurentei Distribuite prin Tehnica Votarii nu se pastreaza o Copie Distincta. Fiecare Statie care pastreaza o Data primeste Cererile de Blocare având memorate informatiile necesare pentru Starile de Blocare / Deblocare. Controlul Blocarii / Deblocarii este conferit acelei Statii Apelate de o Tranzactie care primeste Majoritatea Voturilor celorlalte Statii. In caz contrar Cererea de Blocare e suspendata.

546 Baze de DateEvoluate / Baze de Date Distribuite

Caracteristicile metodei sunt rezumate mai jos:

- Reprezinta o metoda Pur Distribuita de Control a Concurentei

- Determina Incarcarea Traficului din Retea

- Apar dificultati de Reluare la Incidente în Timpul Votarii 7.2.3.5.4 Securitatea Distribuita

Procedura care se ocupa cu Securitatea Distribuita este înca insuficient dezvoltata în conditiile de Distribuire a Resurselor, datorita dificultatilor implicate de Cunoasterea Reala a Naturii Defectelor. Aceste dificultati pot fi concentrate astfel:

- Greutatea de determinare a Caderii unei Statii

- Greutatea de determinare a Erorii de Comunicare

- Greutatea de determinare a Întârzierii în Raspunsul unei Statii

- Greutatea Executarii Tranzactiilor Validate în regim distribuit (ca solutie pentru acest caz a fost elaborat Protocolul în Doi Pasi, prezentat mai jos)

Pentru asigurarea conditiilor de salvare a informatiilor în caz de incident se utilizeaza, pentru construirea Copiilor de Siguranta, Protocolul de Executare a Tranzactiilor Validate în Doi Pasi.

Protocolul de Executare a Tranzactiilor Validate în Doi Pasi are drept obiectiv asigurarea posibilitatilor de revenire la Starea Initiala (starea Bazei de Date Distribuite înainte de Efectuarea Tranzactiei) în conditiile aparitiei unui incident în timpul Executiei Tranzactiei gata Validate.

Ideea de baza consta în Salvarea Tranzactiei Validate în Jurnalul de Securitate în cursul Primului Pas de executare a acesteia. Pasii de executare a Tranzactiilor Validate sunt urmatorii: Pasul 1

- Statiile comunica Managerulului de Securitate Verificarea Tranzactiei

- Managerul de Securitate lanseaza mesajul Preparati Comiterea

- Statiile încearca Scrierea în Jurnalul de Securitate si raspund OK sau Non OK

- La raspuns Non OK Tranzactia e Abandonata Pasul 2

- La raspuns OK Managerul de Securitate lanseaza mesajul Comiteti

- Statiile Actualizeaza BDS si înscriu mesajul de Commit Efectuat în jurnal

- Statiile raspund Ok sau Non OK

- La Non OK Managerul de Securitate lanseaza comanda ROLL-BACK (UNDO) si BDS ramâne coerenta

- La raspuns OK Tranzactia este Efectuata

Baze de DateEvoluate / Baze de Date Obiectuale 547

7.3 Baze de Date Obiectuale

Conceptul de Baze de Date Obiectuale este promovat în contextul mai general al Bazelor de Date Inteligente pe care îl partajeaza cu Bazele de Date Deductive si Bazele de Date Conceptuale. Sectiunea de fata îsi propune sa evidentieze conceptele proprii domeniului Procesarii Obiectuale, cu particularizare la crearea Structurilor Obiectuale în Baze de Date. 7.3.1 Generalitati

Conceptele Obiectuale au aparut si s-au impus pe doua directii distincte:

- In Programarea Clasica – introducerea conceptelor a survenit ca o extensie a Tipului Abstract de Date, care continua promovarea legaturii intrinseci între Structura de Data si Operatorii Atasati [WIRT76] – vezi si sectiunea 3.3. Aceasta Legatura fusese postulata de profesorul Wirth prin afirmatia:

Algoritmi + Structuri de Date = Programe

Acestei viziuni i-a ramas tributar conceptul de Obiect din Programarea Clasica, utilizându-l în permanenta ca un Element Structural în construirea de Programe , Structurile de Date (Proprietatile) fiind înfatisate ca Variabile de Program, iar Algoritmii Atasati (Metodele) evoluând spre Module Parametrizate.

Baze de Date Obiectuale Produse de Programare

Obiectuala Caracteristici Caracteristici

Detaliate Sintetice Detaliate Sintetice Obiecte Compuse Persistenta Tipuri de Date Utilizator Gestiune

Acces Fizic Încapsulare Clase de Obiecte Control

Concurenta Ierarhii de Clase Securitatea Datelor

Incorporare Dinamica

Cereri Ad-hoc

Independenta Datelor fata de Proceduri Generarea de Obiecte prin Procese de Abstractizare Omogenizarea Datelor si Procedurilor prin Virtualizare Obiecte si Operatii Abstracte Obiecte si Operatii Individuale Persistenta Obiectelor

Completitudine de Calcul

Încapsulare Mostenire Comunicare Identitate

Tab. 7.3.1.1 Comparatia Viziunii Obiectuale în Baze de Date si Programarea Obiectuala

- In Bazele de Date – Conceptele Obiectuale au fost construite în BD din Elementele de Structura promovate de-a-lungul timpului în chiar mediul BD. Nu e întâmplator faptul ca Modelul Obiectelor Abstracte îsi gaseste ca forma de implementare Modelul Relational (vezi sectiunea 4.1.2). Obiectul în BD dezvolta Modelul Entitate-Caracteristica-Valoare si pregateste pasul pentru implementarea

548 Baze de DateEvoluate / Baze de Date Obiectuale

Conceptului (vezi sectiunea 4.1.3). Mentinerea Independentei între Date si Proceduri (Proprietati si Metode) nu împiedica BD sa regrupeze în jurul Tabelelor de Baza , Procedurile Atasate (Restrictii de Integritate sau Proceduri Stocate ca forme de Dependenta Functionala interna). De asemenea este gasit un cadru natural de implementare în Nivelul Extern al BD si pentru Obiectele Individuale, în calitate de Viziuni Diversificate ale Utilizatorului (Vederile, ca Structuri Virtuale ce nu încalca Conditiile de Normalizare din BD).

In Fig. 7.3.1.1 este transcrisa o comparatie succinta între cele doua viziuni prezentate anterior. Comparatia porneste de la Caracteristicile de Detalii enuntate în [PARS89], fiind apoi completate cu câteva Caracteristici Sintetice semnificative. Concentrarea caracteristicilor într-o suma de termeni impune necesitatea unor lamuriri pe care le facem în explicatiile care urmeaza:

Explicatii:

- Persistenta – memorarea pe Suport Extern a structurile obiectuale

- Gestiune Acces Fizic – existenta Nivelului Intern de gestiune fizica a structurilor memorate

- Control Concurenta – Partajarea Resurselor în vederea asigurarii Multiaccesului Controlat la Date (în Citire sau Scriere)

- Control Acces – gestiunea Drepturilor de Acces la Date ale utilizatorilor

- Securitatea Datelor – Jurnalizarea Tranzactiilor în vederea Recuperarii în caz de Incident

- Cereri ad-hoc – existenta unui Limbaj de Interogare Interactiv

- Obiecte Compuse – admiterea Structurilor de Date Încorporate (Încuibarite)

- Tipuri de Date Utilizator – posibilitatea construirii Tipurilor de Date de Interes Particular (de catre utilizator)

- Încapsulare – construirea Unitatilor Independente (Structura – Proceduri) care comunica doar prin Mesaje

- Clase de Obiecte – definirea Tipurilor de Obiecte (Structura – Proceduri - Mesaje), împreuna cu Instantierea acestor Tipuri de Obiecte prin Valori (vezi si sectiunea 4.1.1.3.2)

- Ierarhii de Clase – acceptarea în procesul de definire a Legaturii de Descendenta / Ascendenta între Tipurile de Obiecte

- Incorporare Dinamica – proces de Construire Întârziata sau Reconstruire a Modulelor de Proceduri prin Instantiere Parametrizata

- Completitudine de Calcul – Ansamblul de Obiecte definite ca Structura +Metode+Mesaje ofera un Mediu de Programare ce îndeplineste Conditia de Completitudine (Ajungere la Rezultat într-un Numar Finit de Pasi)

In Fig. 7.3.1.2 este redata succesiunea cronologica a Modelelor de Date care s-au impus în domeniul Procesarii Datelor utilizând Concepte Obiectuale. Atasat sunt indicate si tipurile de Baze de Date dezvoltate pe baza acestor modele, împreuna cu câteva exemple de Sisteme de Gestiune a Bazelor de Date încorporate în produse comerciale. Tratarea e facuta dupa

Baze de DateEvoluate / Baze de Date Obiectuale 549

[PARS89] si indica pozitia Bazelor de Date Obiectuale si Deductive în ansamblul realizarilor din domeniu.

Fig. 7.3.1.2 Modele de Date, Baze de Date, SGBD-uri

Înainte de prezentarea Bazelor de Date Obiectuale prin caracteristicile lor principale se prezinta câteva definitii:

Model de Date

Baza de Date

SGBD

IERARHIC

IERARHICA

IMS 2000

Model de Date

Baza de Date

SGBD

RETEA

RETEA

CODASYL TOTAL

ADABAS

Model de Date

Baza de Date

SGBD

IERARHIC

IERARHIC

ORACLE INFORMIX

SQL SERVER

Model de Date

Baza de Date

SGBD

NENORMALIZAT SEMANTIC

OBIECTUALA

GemStone SIM

Model de Date

Baza de Date

SGBD

NESTRICTE (VAGI)

DEDUCTIVA

CORAL NAIL

550 Baze de DateEvoluate / Baze de Date Obiectuale

Definitia 1

Baza de Date Obiectuala – Baza de Date cu capabilitati de reprezentare si manipulare a Obiectelor Complexe.

Definitia 2

Baza de Date Obiectuala – Sistem orientat spre Prelucrarea Obiectelor având totodata capabilitati de Gestiune a Bazelor de Date dupa cum urmeaza:

§ Sistem de Interogare de Nivel Înalt

§ Sistem de Gestiune Fizica

• Persistenta – Sistem de Memorare / Regasire a Obiectelor bazat pe metode eficiente de acces

• Prelucrare Tranzactionala – Sistem de Gestiune a Tranzactiilor Atomice

• Controlul Concurentei – Sistem de Multiacces la Date

• Securitate a Datelor – Sistem de Jurnalizare a Tranzactiilor cu Gestiunea Punctelor de Reluare

§ Suport pentru Indexarea Obiectelor Complexe

Definitia 3

Baza de Date Obiectuala – o Baza de Date care asigura elementelor gestionate proprietatile obiectelor din Programarea Orientata Obiectual, ca urmare reuneste caracteristicile sintetice enumerate în Tab. 5.3.1.1 pentru ambele tipuri de produse.

In continuare sectiunile de prezentare vor urmari caracteristicile specifice Sistemelor de Prelucrare Orientate Obiectual. 7.3.2 Independenta Obiectelor

Nu întâmplator începem cu aceasta caracteristica, deoarece prin promovarea Conceptului de Independenta Modelul Obiectual se apropie cel mai mult de Sistemele cu Baze de Date în general si de Modelul Relational în special. Se poate obiecta ca fata de Modelul Relational cel Obiectual nu priveste Structurile de Date ca niste Structuri Normalizate (deci purtatoare de Maxima Independenta, ci ca Structuri Accesibile, deci cât mai aproape de Viziunile Utilizatorului asupra unui Spatiu de Informatii.

Se poate continua cu faptul ca Modelul Obiectual promoveaza deopotriva Viziunea Modelului Ierarhic si pe cea a Modelului Retea, fara a se sinchisi de faptul ca acestea nu sunt Structuri Elementare. Este adevarat si din acest motiv Modelul Obiectual nu va candida niciodata pentru o Reprezentare Interna de Date, ramânând un Învelis de Reprezentare a Structurilor de Utilizator (a diverselor si schimbatoarelor Viziuni ale Utilizatorului asupra Structurilor de Informatii). Dar Elementele care sunt folosite si în acest plan de reprezentare a structurilor îsi pastreaza în cel mai înalt grad o Independenta Locala, de Univers Închis, care comunica prin Mesaje cu alte Universuri Închise, fara a respecta Conditiile de Consistenta ale unei Viziuni Globale. De aceea aceasta reprezentare trebuie intens utilizata însa numai la

Baze de DateEvoluate / Baze de Date Obiectuale 551

Nivelul Extern , unde îsi gaseste maxima întrebuintare. Este o greseala foarte costisitoare implementarea lui la Nivele Inferioare unde lipsa de Elementaritate va avea un cuvânt greu de spus în ceea ce priveste problematica de Gestiune a unui Ansamblu de Informatii.

Modelul Obiectual s-a impus în domeniul Programarii Clasice, care îsi pastreaza si în prezent amprenta asupra lui. Începem si noi demersul cu acest domeniu, prezentând comparativ Arhitecturile de Date – Proceduri în cele doua Sisteme de Programare: Conventional si Obiectual.

o Arhitectura Conventionala a Sistemelor de Programare (Fig. 7.3.2.1)

§ Programele sunt colectii de Date si Proceduri care:

• Transmit Parametri

• Returneaza Rezultate

§ Executia Procedurilor este Centrala

o Arhitectura Obiectuala a Sistemelor de Programare (Fig. 7.3.2.2)

§ Universul Sistemului este alcatuit din:

• O Colectie de Obiecte având în componenta:

o Date denumite si Proprietati (Variabile) – care reprezinta Elementele Active pentru ca:

§ Se transmit (prin intermediul Mesajelor)

§ Se transforma (prin intermediul Metodelor)

o Proceduri denumite si Metode – care reprezinta Elementele Pasive pentru ca:

§ Nu se transmit (pot fi doar invocate)

§ Nu se transforma (actioneaza doar asupra Variabilelor)

§ Obiectele comunica prin Mesaje

Fig. 7.3.2.1 Arhitectura Conventionala a Sistemelor de Programare

Procedura 2

Procedura 3

Procedura 1

Data 1 Data 2

Data 3

Data 4

552 Bibliografie

Fig. 7.3.2.2 Arhitectura Obiectuala a Sistemelor de Programare

OBIECT 3

OBIECT 2 OBIECT 1

Mesaj 1

Proprietati

1

Metoda 1 Metoda 3

Metoda 6 Metoda 4

Metoda 2

Metoda 5

Proprietati

3

Metoda 1 Metoda 3

Metoda 6 Metoda 4

Metoda 2

Metoda 5

Proprietati

2

Metoda 1 Metoda 3

Metoda 6 Metoda 4

Metoda 2

Metoda 5

Mesaj 4

Mesaj 1

Mesaj 4

Mesaj 1

Mesaj 4

M6

M4

M4

M1

M2

M5

M3

M5

M6

M1

M2

M1

M6

M2

M3

M5

M4

M3

Baze de DateEvoluate / Baze de Date Obiectuale 553

7.3.2.1 Clase de Obiecte

Asa dupa cum s-a anticipat, termenul de Clasa de Obiecte este folosit pentru definirea Structurii Obiectelor.

Definitie:

Clasa de Obiecte – Constructorul care defineste în Modelul Obiectual:

§ Un Tip Abstract de Data

§ Multimea de Elemente Concrete (Instante) care pot apartine Colectiei de Obiecte potrivit Tipului de Data definit

Structura Clasei de Obiecte:

§ Definirea Tipului Abstract de Data – corespunde Entitatii Notiune

• Numele Clasei

• Structura de Date reprezentând Proprietatile care descriu Clasa de Obiecte (Variabilele de Instantiere)

• Operatiile atasate Tipului de Data si care sunt alcatuite din:

o Mesaje – Operatiile Externe care invoca Metodele, declansând Reactia (Transformarea) Obiectului (actioneaza ca un Selector al Metodelor fiind constituit din:

§ Nume Mesaj

§ Obiect de Destinatie

§ Argumentele de Apel (Invocare)

o Metode – Proceduri atasate Mesajelor Externe (actioneaza ca si Constructori de Comportament ; se mai zice ca implementeaza la nivel intern Mesajele)

§ Multimea de Elemente Concrete (Instantele) care pot apartine Colectiei de Obiecte potrivit Tipului de Data definit prin Clasa de Entitati Obiecte

Pentru a fixa notiunile, prezente în numar destul de mare sa recurgem la un exemplu pe care sa-l comentam în continuare. Facem de asemenea trimitere la conceptele de Entitate si Clasa de Entitati analizate în Sectiunea dedicata Modelelor de Informatii (sectiunea 4.1.1).

Exemplu:

Sa consideram o Clasa de Entitati SOCIETATE descris a de Modelul Obiectual din Fig. 7.3.2.1.1. Se fac urmatoarele observatii:

§ Atributele sunt implementate ca Proprietati ale Clasei

§ Atributele nu au restrictie de a fi Nedecompozabile, putând reprezenta si Multimi de Valori (spre exemplu: Angajati si Filiale)

554 Baze de DateEvoluate / Baze de Date Obiectuale

§ Atributele pot proveni din Domenii Interpretate (spre exemplu: Venit având Tipul de Data DOLLAR)

§ Metodele descriu Reactiile Clasei la Mesaje Exterioare (spre exemplu: Afla Profitul Societatii ca diferenta Intre Venituri si Cheltuieli)

Fig. 7.3.2.1.1 Arhitectura Modelului Obiectual al Clasei SOCIETATE

§ Mesajele au doua Componente la fel ca Apelurile de Proceduri din Programarea Clasica

• Formatul de Definire (aflat în Corpul Clasei Apelate)

• Formatul de Apel (apare în Metodele care Apeleaza)

Proprietati

Nume: STRING Adresa: STRING Cheltuieli: DO LLAR Venit: DOLLAR Angjati: MULTIME PersoanaManager: Persoana Filiale: MULTIME Companie

Societate

Metoda GET ProfitRETURN Venit - Cheltuieli

GET Profit

Metoda 1 …

M 1

Metoda 2 …

M 2

Metoda 3 …

M 3

GET Profit

Baze de DateEvoluate / Baze de Date Obiectuale 555

Fig. 7.3.2.1.2 Structura Clasei SOCIETATE

§ Structura Clasei contine trei Liste de Elemente (Fig. 7.3.2.1.2):

• Proprietati

• Mesaje (Formatul de Definire)

• Metode

Clasa SOCIETATE

Lista MESAJELOR definite

GET Profit GET Filiale GET Manager GET Total Angajati ADD Filiala

Lista METODELOR definite

Metoda GET Profit RETURN

Cheltuieli - Venit Metoda GET Filiale

… Metoda GET Manager

… Metoda GET Total Angajati

… Metoda ADD Filiala

…

Lista PROPRIETATILOR definite

Nume: STRING Adresa: STRING Cheltuieli: DOLLAR Venit: DOLLAR Angjati: MULTIME Persoana Manager: Persoana Filiale: MULTIME Companie

556 Baze de DateEvoluate / Baze de Date Obiectuale

§ Instantierea Obiectelor descrise de Clasa de Obiecte este efectuata prin acordarea de Valori Proprietatilor definite în Clasa (Fig. 7.3.2.1.3):

Fig. 7.3.2.1.3 Instantierile Clasei SOCIETATE

§ Mesajele (Forma de Apel) au în componenta lor urmatoarele elemente:

• Numele Mesajului

• Destinatarul Mesajului

• Lista de Argumente

Exemple:

GET Profit IBM

GET Manager FORD

§ Proprietatile Clasei, numite si Variabile de Instantiere, cer urmatoarele precizari:

• Reprezinta Atributele de Descriere a Structurilor de Date proprii Clasei

• Tipurile de Date admise sunt

o Scalar

o Multime

• Viziunea asupra Datelor nu este Normalizata

§ Tipul de Data poate fi:

• Fix – Tipul se declara în Clasa si ramâne neschimbat

IBM

SAP

FORD

Baze de DateEvoluate / Baze de Date Obiectuale 557

• Variabil (Tipul se poate modifica pe parcursul procesarii prin simpla atribuire de Valoare apartinând unui nou Tip de Data)

§ Tipul de data poate reprezenta un Selector pentru Variantele de Metode invocate (spre exemp lu: Varianta de Metoda de Adunare poate diferi în functie de Tipul Destinatiei din Mesajul denumit ’+’:

• Operanzi numerici – Adunare Numerica

• Operanzi flotanti – Adunare Flotanta

• Operanzi Sir de Caractere – Concatenare

Aceasta Selectie Întârziata a Metodei care se executa poarta numele de Încarcare Dinamica (Overload)

§ Crearea de Obiecte se face cu Metode Specializate continute în Clasa (pentru acest motiv Clasa de Obiecte mai este denumita si Generatorul de Obiecte sau ”Fabrica” de Obiecte)

Exemplu:

IBM:= NEW (SOCIETATE, ”IBM”, ” Bucuresti Str. Doamnei 11”)

unde:

NEW reprezinta un operator generic ce poate fi redefinit.

7.3.2.2 Metode si Mesaje

Transformarile sunt definite în Modelul Obiectual prin intermediul Metodelor si Mesajelor, ca elemente componente ale Clasei de Obiecte. Definitie:

Metoda – o Procedura (Secventa de Operatii), care descrie Reactia (Comportamentul) Obiectului la invocarea ei. Reprezinta Componenta Dinamica a Obiectului.

Definitie:

Mesajul – o Invocare de Metoda (Apel de Procedura) apartinând unui Obiect, pentru a determina o Reactie a acestuia. Reprezinta elementul de Comunicare între Obiecte.

Metoda descrie ca urmare Modul de Interpretare si de Prelucrare a unui Mesaj. Se mai zice ca Metoda este o Procedura care implementeaza un Mesaj.

Metodele si, odata cu ele, Mesajele pot fi de doua feluri:

§ Fixe – Neparametrizate

§ Variabile – Parametrizate

Parametrii se definesc în Metode (corespunzând în acest caz Parametrilor Formali din Programarea Clasica) si se utilizeaza în Mesaje (corespunzând de data aceasta Parametrilor Actuali din Programarea Clasica).

558 Baze de DateEvoluate / Baze de Date Obiectuale

Diferenta fata de Programarea Clasica consta în facilitatea oferita Metodelor de a fi Legate doar în momentul interpretarii Parametrilor Actuali, deci în functie de aceasta interpretate (Legare Întârziata – Late Binding)

7.3.2.3 Restrictii impuse Obiectelor

Spre deosebire de Modelul de Date Relational, care are Restrictiile si Operatiile migrate în Baza de Date alaturi de Structura acesteia, cu care colaboreaza pentru asigurarea Consistentei BDR, Modelul Obiectual lasa întreaga verificare a Coerentei Structurii Obiectelor pe seama Metodele atasate lor. Metodele preiau ca urmare si functia de verificare a Integritatii Structurale a Obiectului. Definitie:

Restrictiile Obiectelor – Conditii impuse Structurii sau Procedurilor atasate unui Obiect, în vederea Controlului Instantierii acestuia.

Se folosesc mai multe forme de Implementare a Restrictiilor:

o Restrictii impuse Structurii de Date si implementate sub forma Procedurilor:

§ Incorporate în Obiecte de Ansamblu

§ Atasate Variabilelor de Instantiere

o Restrictii impuse Metodelor si implementate tot sub forma Procedurilor:

§ Atasate înaintea Metodelor – PreConditii – reprezinta Restrictii ce se verifica înaintea intrarii în Metoda, conditionând executia acesteia

§ Atasate dupa Metode – PostConditii - reprezinta Restrictii ce se verifica la iesirea din Metoda permitând în acest moment fie:

• Alegerea unei continuari prin invocarea altor Metode

• Refacerea Tranzactionala a executiei Metodei 7.3.3 Mostenirea între Obiecte

Proprietatea de Mostenire se bazeaza pe descrierea succesiva a Tipurilor de Obiecte prin Transmiterea Ierarhica a Proprietatilor si a Comportamentelor, de la Obiecte mai putin specializate (mai generale) catre cele mai specializate (mai detaliate). Mecanismul folosit este cel de construire a Ierarhiilor de Mostenire.

Definitie:

Mostenirea – Preluarea unor Structuri (de Obiecte sau de Proceduri) deja definite.

Dupa cum se deduce din definirea Mostenirii aceasta implica urmatoarele conditii:

§ Existenta unei Ierarhii de Obiecte:

• Supraclase de Obiecte

• Subclase de Obiecte

§ Mostenirea se face de la Supraclasa la Subclasa

Baze de DateEvoluate / Baze de Date Obiectuale 559

§ Ierarhiile de Clase se mai numesc si Ierarhii de Mostenire

§ Structurile Mostenite sunt considerate Structuri Comune

Din punctul de vedere al naturii elementelor mostenite, se poate vorbi despre doua categorii de Mosteniri:

- Mostenire Structurala

- Mostenire Comportamentala

Sa urmarim pentru început cele doua forme de Mostenire pe un exemplu. Exemplu:

Fie o Societate (Companie) Generala alcatuita din doua subunitati cu regim diferit de functionare, cu si fara Profit. Functionarea diferentiata va cauza Structuri si Proceduri specifice în modul intern de gestionare.

Fig. 7.3.3.1 Supraclase si Subclase de Obiecte

In Fig. 7.3.3.1 este reprezentata o prima clasificare a Obiectului Generic SOCIETATE în doua Obiecte Subordonate, prin intermediul unei Ierarhii de Obiecte. Prima Clasa de Obiecte va purta numele de Supraclasa (Superclasa), iar cele de pe al doilea nivel de Subclase.

IBM

SAP

FORD

Societate

Societate Comerciala

Societate Non-Profit

IMS

EEE

560 Baze de DateEvoluate / Baze de Date Obiectuale

Aceste Clase de Obiecte vor putea avea în componenta:

- Proprietati de Descriere

§ Comune

• Se descriu în Superclasa

• Se mostenesc în Subclasa prin copiere la generare sau acces în timpul executiei

Exemplu: Cod, Nume, Adresa , Cont , Telefon

§ Specifice

• Se descriu în Subclasa

Exemplu: Valoare Profit

- Metode de Comportament

§ Comune

§ Se descriu în Superclasa

§ Se mostenesc în Subclasa prin apel indirect

Exemplu: Actualizare Proprietati Comune

§ Specifice

§ Se descriu în Subclasa (pot suprascrie o Metoda Comuna, având acelasi nume si câstigând astfel prioritate la apel – Polimorfism)

Exemplu: Calcul Valoare Profit, Întocmire Bilant 7.3.3.1 Mostenire Structurala

Mostenirea Structurala se refera la transmiterea Variabilelor de Instanta (Proprietatilor) între Obiecte, ordonate printr-o Ierarhie de Mostenire.

Mostenirea Structurala ridica o discutie importanta legata de problema Independentei Obiectelor. Pericolele care pândesc aici sunt:

- Introducerea de Redondanta prin Copiere (Multiplicare)

- Sacrificarea Încapsularii prin admiterea Accesului Extern

In discutie este modul în care Obiectele din Subclase primesc acces la Datele Mostenite, daca nu le Recopiaza . Accesul la Datele Mostenite se realizeaza prin doua mijloace:

o Acces Direct – Metodele Obiectelor vad Proprietatile Interne ale altor Obiecte (Proprietatile Mostenite); altfel spus Variabilele de Instanta sunt Vizibile

In acest caz Independenta Obiectelor este subminata prin:

• Modificarea Structurii Obiectelor din exterior

• Modificarea unui Obiect Mostenit, modifica implicit Structurile Mostenite de alte Obiecte

Baze de DateEvoluate / Baze de Date Obiectuale 561

o Acces Indirect – Proprietatile Mostenite de Obiecte sunt vizibile numai prin intermediul Metodelor Obiectelor de la care se mosteneste; altfel spus Variabilele de Instanta ramân Invizibile (Hidden Instance Variable)

Gestiunea Mostenirii Structurale ofera doua solutii de rezolvare a opozitiei:

Partajare prin Mostenire versus Independenta prin Încapsulare:

- Clasificarea Utilizatorilor de Obiecte

§ Utilizatori care Instantiaza – au drepturi de Creare de Obiecte si prin aceasta acces la Structura Interna a acestora

§ Utilizatori care Mostenesc – au drepturi de Mostenire de Proprietati si prin aceasta accesul la Structura Interna a acestora se face doar prin Accesul la Metode cu ajutorul Mesajelor Externe

- Clasificarea Variabilelor de Instanta

§ Variabile Publice– sunt Accesibile Direct

§ Variabile Private – sunt Inaccesibile

§ Variabile Vizibile:

• Sunt Accesibile Direct pentru Utilizatorii ce Mostenesc, daca nu exista Utilizatori ce Creeaza

• Sunt Private daca exista Utilizatori ce Creeaza Observatie:

Se mentine aici întrebarea daca atunci când Mostenirea este rezolvata fara Recopiere si fara posibilitati de Modificare a Structurilor Mostenite se mai poate vorbi despre Mostenire sau doar de Uzufruct (Dreptul de a folosi Informatiile din alte Obiecte) ? Modelul Relational utilizeaza acest gen de Partajare de Informatie prin Referire Asociativa în cadrul Structurilor Normalizate.

In Fig. 7.3.3.1.1 se prezinta o Ierarhie de Clase de Obiecte bazata pe Clasificarea Obiectelor luând în considerare criteriul de Gen Proxim – Diferenta Specifica. In acest caz au loc relatiile de legatura semantica:

Clasa Gen Proxim Are în subordine Clasele Diferenta Specifica

Clasa Diferenta Specifica Este, ca proprietati, Clasa Gen Proxim

De aici provin si facultatile Claselor Subordonate (Subclasele) de a mosteni proprietatile Claselor Supraordonate (Supraclasele).

Instantiat la nivelul cel mai de jos al ierarhiei, Obiectul AUTOVEHICOLUL MEU va mosteni toate proprietatile Supraclaselor (Fig. 7.3.3.1.2).

O analiza mai atenta releva faptul ca mostenirea se produce integral, atât asupra Tipului de Variabila de Instanta cât si a Valorii de Instanta propriuzise, ceea ce introduce o Redondanta evidenta In structura si prin aceasta o posibilitate de inconsistenta prin actualizare.

562 Baze de DateEvoluate / Baze de Date Obiectuale

Fig. 7.3.3.1.1 Exemplu de Mostenire Structurala – Ierarhia de Mostenire

Exemplu: Valoarea datei Tip Greutate Medie va fi repetata în toate instantele apartinând acestei categorii ceea ce implica dificultati de actualizare a cestei Valori de Instanta. Desigur ca nimic nu împiedica completarea Structurii de Obiecte prin adaugarea unui Obiect Categorie (vezi Modelul Obiectelor Abstracte, dar aceasta modificare va schimba necesitatile de Mostenire prin Copierea Datelor în Subclase, deplasând relatiile semantice din sfera Ierarhiilor de Clase în cea a Ierarhiilor de Instante.

Exemplul prezentat atrage atentia si asupra necesitatii deciziei de modelare a realitatii semantice prin Ierarhii de Clase sau Ierarhii de Instante, decizie ce va ramâne în sarcina competentei proiectantului.

Accesul la Variabilele de Instanta Mostenite va fi guvernat de Clasificarea Tipurilor de Variabile precum si a Tipurilor de Utilizatori, conform regulilor anterior stabilite. Aceste reguli pot fi diferit definite în produse comerciale diferite. Criteriul de apreciere ramâne si în acest caz gradul de mentinere a Uniformitatii si Încapsularii Obiectelor ca mijloace de masurare, mai generala, a Gradului de Independenta asigurat de structura.

VEHICOL Tip – Sir de Caractere

Greutate – Kg.

AUTOVEHICOL Tip – Sir de Caractere

Producator – Sir de Caractere

FORD Tip – Sir de Caractere

Culoare – Sir de Caractere An – Intreg

Dotari – Multime de Siruri de Caractere

Baze de DateEvoluate / Baze de Date Obiectuale 563

Fig. 7.3.3.1.2 Proprietati Mostenite Structural de Instanta de Obiect 7.3.3.2 Mostenirea Comportamentala

Mostenirea Comportamentala se refera la transmiterea Metodelor (Operatiilor) între Obiecte ordonate printr-o Ierarhie de Mostenire. Pentru a nu distruge Variabilitatea Comportamentala a Obiectelor (Polimorfism), mostenirea Metodelor este însotita întotdeauna de posibilitatea oferita de a Redefini , a rescrie (Override) o Metoda definita în Superclasa . Facilitatea se bazeaza pe un mecanism simplu de Localizare a Metodei Invocate prin acceptarea urmatoarelor reguli:

o Reguli de Definire

§ Numele Claselor trebuie sa fie Unice

§ Numele de Metode nu trebuie sa fie unice între Clase

§ Identificatorul Metodei poate fi:

• Necalificat - Numele Metodei

• Calificat - Numele Metodei e precedat de Numele Clasei

VEHICOL

Tip – Greutate Medie Greutate – 500 Kg.

VEHICOL Tip – 4 Usi

Producator – FORD

VEHICOL Tip – SIESTA

Culoaree – Alba An Fabricatie – 1984 Dotare – (Injectie, Aer Conditionat, STEREO)

Proprietati de VEHICOL

Proprietati de AUTOVEHICOL

Proprietati de FORD

Instanta AUTOVEHICOLUL MEU

564 Baze de DateEvoluate / Baze de Date Obiectuale

Fig. 7.3.3.2.1 Mostenire Comportamentala de Metode cu Polimorfism

Clasa SOCIETATE

Lista MESAJELOR definite

GET Profit …

Lista METODELOR definite

Metoda GET Profit RETURN

Cheltuieli - Venit …

Lista PROPRIETATILOR definite

…

Clasa SOCIETATE

INDIGENA

Lista MESAJELOR definite

GET Profit …

Lista METODELOR definite

Metoda GET Profit RETURN Cheltuieli - Venit

…

Lista PROPRIETATILOR definite

…

Clasa SOCIETATE

STRAINA

Lista MESAJELOR definite

GET Profit …

Lista METODELOR definite

Metoda GET Profit RETURN Cheltuieli – Venit - Impozit

…

Lista PROPRIETATILOR definite

…

Baze de DateEvoluate / Baze de Date Obiectuale 565

o Reguli de Apel (Invocare)

§ Metoda Necalificata e cautata în Ierarhia de Clase în mod Ascendent pe Ramura de Mostenire, începând cu Clasa în care s-a facut invocarea

§ Metoda Calificata e cautata direct în Clasa specificata în Identificatorul Metodei

Cu precizarile facute pâna aici se pot observa doua forme de Mostenire Comportamentala:

§ Mostenire Fidela - Preluare simultana de Metode + Mesaje

§ Mostenire cu Polimorfism - Preluare de Mesaje cu Modificarea sau Înlocuirea Metodelor

Exemplu:

Sa consideram Ierarhia de Clase: din Fig. 7.3.3.2.1.

Daca Metoda de Calcul Profit definit într-o Superclasa de Societate Comerciala corespunde Societatilor Comerciale Indigene ea poate fi preluata direct din Superclasa prin invocare:

Metoda GET Profit RETURN

Cheltuieli – Venit

Pentru Societati Comerciale Straine Metoda de Calcul Profit poate fi Redefinita în Subclasa Societate-Comerciala-Straina cu acelasi Nume, dar cu Continut diferit:

Metoda GET Profit RETURN

Cheltuieli – Venit - Impozit

In Fig. 7.3.3.2.1 se poate urmari modul de respectare a Regulilor de Definire prin Polimorfism si apoi de Invocare a Metodelor prin cautarea în Arborele de Apel construit pe Ierarhia de Clase de Obiecte.

Se poate observa cum Metoda Calificata de Apel scurtcircuiteaza orice Regula de Localizare prin precizarea directa a Metodei Dorite într-un caz concret.

7.3.3.2.1 Mostenire Simpla

Mostenirea Simpla, Structurala si / sau Comportamentala are loc în Ierarhii de Clase

cu Structura de tip Arbore. Parintele unei Clase fiind Unic, mostenirea se refera întotdeauna doar la o Superclasa Unica.

Mostenirea Simpla se poate extinde pe toata Ramura Ascendenta a Structurii Arborescente atasate Ierarhiei Claselor de Obiecte, conform cu Regula de Localizare enuntata anterior.

Mostenirea Simpla este forma cea mai obisnuita de Mostenire, cu atât mai mult ca implica Reguli Precise de preluare de Proprietati si Metode, spre deosebire de Mostenirea Multipla.

566 Baze de DateEvoluate / Baze de Date Obiectuale

7.3.3.2.2 Mostenire Multipla

Mostenirea Multipla, Structurala si Comportamentala are loc în Ierarhii de Clase cu Structura de tip Retea. Parintii unei Clase putând sa fie Multipli, Mostenirea se refera la toate Superclasele unei Clase.

Pentru a fi operanta Mostenirea Multipla trebuie condusa de un Set de Reguli de Mostenire.

Redam mai jos un asemenea Set de Reguli de Mostenire:

o Variabilele de Instanta Mostenite – Reuniunea tuturor Variabilelor de Instanta din Clasa si din Superclase. Aceasta Regula urmareste sa asigure aparitia unica a Variabilelor de Instanta Identice în diferite Superclase.

o Metodele Mostenite – Reuniunea tuturor Metodelor din Clasa si din Superclase cu prioritate pentru Metodele Redefinite în Clasa de Obiecte care apeleaza. Aceasta Regula urmareste sa asigure aparitia unica a Metodelor ce pot fi invocate, dar care pot fi si rescrise.

Fig. 7.3.3.2.2 Mostenire Multipla

Se remarca faptul ca Regula de Reuniune propusa nu asigura totusi Unicitate în cazul general. Spre exemplu în cazul în care apare ambiguitate determinata de Omonimie a Variabilelor de Instanta sau a Metodelor. E vorba de Obiecte cu acelasi nume, dar cu continut diferit (Tip de Data diferit sau Continut în Operatii diferit). In acest caz se recurge de Reguli Suplimentare de Rezolvare a Conflictelor. Exista solutii diferite de adoptat pentru aceasta decizie:

- Emitere de Eroare – Rezolvarea se poate face prin Calificare

- Acordare de Prioritati de Mostenire - Prin Liniarizarea Structurilor de t ip Retea pe baza acordarii de Prioritati Subiective Superclaselor (Un asemenea exemplu de descompunere preferentiala a unei Structuri de tip Retea este redat în Fig. 7.3.3.2.3, pornindu-se de la Mostenirea Multipla prezentata în Fig. 7.3.3.2.2. Prin declararea celor doua Ramuri Liniarizate se indica BDO modul de aplicare a Regulii de Localizare a Obiectelor sau Metodelor ce se doresc Mostenite).

Persoana

Angajat Student

Director Student-Angajat

Baze de DateEvoluate / Baze de Date Obiectuale 567

Fig. 7.3.3.2.3 Rezolvare de Conflict prin Liniarizarea Mostenirii Multiple

Persoana

Student

Angajat

Student-Angajat

Angajat

Persoana

Director

568 Baze de DateEvoluate / Baze de Date Obiectuale

Exemplu: Daca în Ierarhia de Obiecte din Fig. 7.3.3.2.2 consideram ca aceiasi Metoda exista cu acelasi Nume si în Clasa Student si în Clasa Angajat, atunci solutiile de rezolvare a Conflictului de Mostenire sunt urmatoarele:

- Sa se Semnaleze Inadvertenta, obligându-se Utilizatorul sa Redefineasca prin Rescriere Metoda în Clasa Student-Angajat

- Sa se descrie, prin Desfasurare Liniara , ca în Fig. 7.3.3.2.3, Prioritatile Preferentiale de Mostenire (în speta, Metodele Clasei Student vor suprascrie Metodele Clasei Angajat); Structura Liniara va fi memorata în BDO.

7.3.3.3 Meclase, Clase si Obiecte

Modelul Obiectual introduce un nou Nivel de Definire a Obiectelor – Metaclasa . Acest nivel este impus nu atât din punct de vedere Structural, cât Comportamental. El este nivelul unde se depun Metodele care se adreseaza Tuturor Claselor.

Definitie:

Metaclasa este o Clasa de Obiecte ale carei Instante sunt alte Clase de Obiecte. (Definitia e preluata din acceptia Limbajului Smaltalk [SMAL86].)

In aceste conditii Metaclasa devine Radacina Ierarhiei de Clase si în acest fel toate Clasele devin Subclase ale Supraclasei Unice Metaclasa . De aici provin o serie de confuzii legate de continutul semantic al celor trei termeni. Evitam intrarea în aceste dispute, oferind o definitie în termenii Modelului Formal prezentat în sectiunea 4.1.1, pentru descrierea Spatiului Entitate-Caracteristica-Valoare (ECV).

Daca facem echivalarea de termeni:

Obiect ≡ Entitate

putem în continuare prelua termenii introdusi în spatiul ECV, asa încât vom putea vorbi despre diferite înfatisari ale Obiectelor:

Clasa (C) ≡ Entitate Notiune – cu rolul de definire a continutului

Clasa (C) se va defini printr-o Lista de Proprietati (Variabilele de Instanta):

C = ( p 1 , p 2 , .. , p n )

Obiect (O) ≡ Entitate Obiect – cu rolul de materializare a continutului prin Valori

Obiect (O) se va defini printr-o Multime de Valori care concretizeaza (materializeaza) Variabilele de Instanta

O = ( v 1, v 2, .., vr .. , v e )

Cu aceste notiuni se ajunge la definirea exacta si cuprinzatoare a Clasei de Obiecte (CO):

Clasa de Obiecte - O multime ordonata construita cu notiunile anterioare astfel:

Baze de DateEvoluate / Baze de Date Obiectuale 569

CO ≡ ( C , O‘ )

C – Obiectul Notiune care defineste Clasa

C = ( p 1 , p 2 , .. , p n )

O – Multimea de Obiecte care instantiaza Clasa

O ‘ = ( v 1, v 2, .., vr .. , v n ) | v r ∈ Pr pt. ∀r ∈ S1,2, .. ,n

unde n este multimea proprietatilor ce definesc Clasa C.

Se regasesc aceleasi proprietati ca si în cazul Clasei de Entitati: C are pj

O este C

Definitia anterioara acopera si definirea Metaclasei (M) daca se fac câteva particularizari:

Metaclasa este Clasa

Lista de Proprietati se reduce la una - Nume de Clasa

M = ( n)

Multimea de Obiecte din Clasa este alcatuita din Instantele de Nume de Clasa

O ‘ = ( n 1), ( n 2,), .., (n m )

unde m este multimea Claselor ce fac parte din Clasa M.

Se remarca ca prin aceasta definire Clasa nu trebuie sa fie unica în Ierarhia de Clase, putându-se folosi aceasta forma de Clasa de Obiecte pentru definirea unei Taxonomii în cadrul Ierarhiei de Clase.

7.3.4 Identitatea Obiectelor

Identitatea Obiectelor este o preocupare principala a Modelului Obiectual. Ea provine din dezideratul pe care si-l propune în legatura cu Fidelitatea Modelarii Realitatii. Punctul de pornire este unul foarte profund legat de formele de identificare si anume:

o Identificarea Externa a Obiectului

§ Identificarea prin Adresa – identificarea cu ajutorul Referintei de Adresa (Pointerilor) atasate Obiectului

§ Identificarea prin Index - identificarea cu ajutorul Tabelelor de Index atasate Obiectului

o Identificarea Interna a Obiectului

§ Identificarea Explicita – identificarea cu ajutorul Caracteristicilor declarate în structura Obiectului

570 Baze de DateEvoluate / Baze de Date Obiectuale

§ Identificarea Implicita - identificarea printr-o Proprietate Incorporata speciala a Obiectului (un Identificator Intern)

Argumentele în favoarea ultimei Forme de Identificare sunt urmatoarele:

§ Identitatea este o Proprietatea Intrinseca a Obiectului si nu poate fi reprezentata de o Calitate Externa

§ Identificarea Obiectelor nu poate fi amestecata cu Strategia de Acces la Obiecte

§ Identitatea este o Proprietate Unica si Permanenta, ce trebuie mentinuta pe toata Durata de Viata a Obiectului

Exemplu: Sa consideram Obiectul PERSOANA. Pentru a fi fidela, reprezentarea acestui Obiect trebuie sa respecte Identitatea Persoanei din realitate, care se pastreaza si atunci când, în cursul vietii, îsi schimba aproape toate Însusirile de la nastere.

Problema Identitatii este continuata cu nuante aduse din Identitatea Claselor. Se face o deosebire între diferitele Forme de Identitate (Egalitate si Identitate) [SMAL86]:

§ Testul de Egalitate (O1 = O2 ) – testeaza Egalitatea Continutului Obiectelor

§ Testul de Identitate (O1 == O2 ) – testeaza daca Obiectele sunt Aceleasi

Exemplu: Doua patrate P1 si P2 cu aceeasi lungime de latura si aceeasi pozitie în plan pot fi definite ca doua obiecte distincte:

P1 = P2 - Egale ca Proprietati

¬ ( P1 == P2 ) – Neidentice Semantic

Aceste consideratii determina introducerea în Modelul Obiectual a unor noi Operatori de Transformare, specifici actiunilor care implica direct Identificarea Obiectelor:

o Unificarea Obiectelor (Merging) – operatie în urma careia doua Obiecte devin unul singur pe baza urmatoarelor constatari:

§ Egalitatea Continutului Obiectelor (a Structurii Obiectelor)

• Egalitate de Tip

• Egalitate de Variabile de Instante

• Egalitate de Valori

§ Identitatea Obiectelor

• Declarate Aceleasi prin Comparare Semantica

o Copierea Obiectelor (Copy) - doua Operatii Specifice de Copiere sunt adaugate Operatiei Traditionale de Asignare:

§ Asignarea – atasarea la o Variabila a unei Expresii

§ Copierea – atasarea la o Variabila a unei alte Variabile, având urmatoarele forme de realizare:

Baze de DateEvoluate / Baze de Date Obiectuale 571

Fig. 7.3.4.1 Atribuire si Copiere (Superficiala si Profunda)

Asignare S := O1 , O2

O3

• n 1

• v 1

• s 1

O4

• n 2

• v 2

• s 2

Obiect Nou S " = O3 , O4

Copiere Superficiala S ‘::= S

O1

• n 1

• v 1

• s 1

O2

• n 2

• v 2

• s 2

Obiect Existent S

Copiere Profunda S " :== S

Obiect Nou S = O1 , O2

Obiect Nou S ‘= O1 , O2

Obiect Existent S

Obiecte Existente O1 , O2

572 Baze de DateEvoluate / Baze de Date Obiectuale

• Copierea Superficiala (Shallow Copy) – Copierea Referirii la Continutul unui Obiect deja existent si descrisa astfel:

o Crearea unui Obiect Nou

o Actualizarea Continutului Obiectului Nou prin adaugare de Referiri la Continutul unor Obiecte Existente

• Copierea Profunda (Deep Copy) – Copierea Continutului unui Obiect Existent descrisa astfel:

o Crearea unui Obiect Nou

o Copierea Continutului Obiectelor Existente în Continutul Obiectelor Componente Noi

Obiect

Nume Continut O1 n1, v1 , s1 O2 n2, v2 , s2 S O1, O2 S’ O1, O2 O3 n1, v1 , s1 O4 n2, v2 , s2 S” O3, O4

Tab. 7.3.4.2 Identitatea (Numele) si Continutul (Structura) Obiectelor

Pentru a fixa notiunile prezentate se ilustreaza în Fig. 7.3.4.1, pe un Set de Obiecte, Operatiile de Asignare si Copiere (Superficiala si Profunda). In completare sunt selectate în Tab. 7.3.4.2 caracteristicile de Identitate si Structura pentru Obiectele utilizate în cadrul exemplificarii.

Comparatie Obiect 1 Operator Obiect 2 Rezultat

O1 = O2 Fals O1 = = O2 Fals S’ = S Adevarat S’ = = S Fals O3 = O1 Adevarat O3 = = O1 Fals O4 = O2 Adevarat O4 = = O2 Fals S” = S Fals S’ = = S Fals S” = S’ Fals S” = = S’ Fals

Tab. 7.3.4.3 Egalitatea si Identitatea Obiectelor

Baze de DateEvoluate / Baze de Date Obiectuale 573

Cu informatiile extrase se trece la o Comparare de Egalitate si de Identitate a Obiectelor reprezentate în Fig. 7.3.4.1. Rezultatele sunt retranscrise în (Tab. 7.3.4.3). O mentiune speciala se ere facuta în legatura cu implicarea Laturii Semantice în stabilirea Identitatii Obiectelor. Daca stabilirea Continutului Obiectelor este o problema de ”Inventar a Structurii”, decizia în ceea ce priveste Identitatea Obiectelor se bazeaza pe Acceptiunea Semantica ce se acorda acestora. In acest context câstiga sens operatia de Unificare, care implica întotdeauna o Declarare de Identitate Semantica.

Pentru o mai buna circumscriere a conceptului de Identificare în Modelul Obiectual prezentam obiectiile [PARS89] aduse Identificarii prin Chei (Atribute Identificatoare), ca forma de utilizare gresita a Starii Obiectelor (Structurii Obiectelor) în procesul de Identificare:

o Modificarea Cheilor Identificatoare – Cheile Identificatoare nu pot fi modificate chiar atunci când reprezinta Atribute definite de Utilizator si care în realitate trebuie la anumite momente sa fie modificate.

o Neuniformitatea – Atributele care identifica o Entitate pot fi diferite în diferite Contexte, sau pentru diferite Categorii de Utilizatori. Situatia creeaza complicatii, mai ales când apare problema Unificarii Colectiilor de Date de acelasi Tip, însa Identificate în mod diferit de Proprietarii lor diferiti.

o Cuplare Nenaturala – Utilizarea Cheilor Identificatoare impune necesitatea invocarii Operatiei de Cuplare (JOIN) pentru orice regasire de date, în locul unei regasiri mai firesti prin Expresia de Cale de Acces.

Observatie: Am retranscris obiectiile anterioare pentru a oferi cititorului o imagine cât mai fidela a Modelului Obiectual, dar nu putem sa nu adaugam în acest punct si o replica rezultata din dezbaterea conceptelor anterioare în lumina Viziunii Bazelor de Date Relationale:

o Modificarea Cheilor Identificatoare – Cheile Identificatoare pot fi si Chei Surogate (Chei Interne) al caror continut poate fi mentinut pe toata Durata de Viata a Entitatilor.

o Neuniformitatea – O Entitate poate avea mai multi Identificatori alaturi de o eventuala Cheie Surogata (generata automat, dar posibil de consultat), solutie de proiectare care da o rezolvare eleganta cazului de Unificare a Colectiilor de Date de acelasi Tip, dar Identificate în mod diferit de Proprietari diferiti.

o Cuplare Nenaturala – Procesul de recuperare a Informatiilor în Structurile Normalizate ale Modelelor Relationale trebuie sa ramâna un Proces Intern , Independent de Suport, Elementar (bazat pe Operatori Bine Definiti), Complet Controlabil de Motorul Relational implementat si care trebuie sa se mentina Transparent pentru Utilizator, fie el chiar Programator.

In scopul de a urmari Partajarea prin Referire în cadrul Modelului Obiectual, dam un exemplu de Structura Obiectuala pentru o Colectii de Date PERSONAL. Exemplu:

Fie Obiectele si Proprietatile descrise în Tab. 7.3.4.4, precum si conventiile grafice din Fig. 7.3.4.5. Cu ele se construieste Structura Obiectuala din Fig. 7.3.4.6. Se remarca modul de partajare a Obiectelor ADRESA si COPII de catre ambii SOTI, care împreuna pot face parte dintr-o Colectie de Obiecte descrisa ca o data de Tip Multime .

574 Baze de DateEvoluate / Baze de Date Obiectuale

Proprietate Proprietate Obiect

Nume Simbol

Obiect

Nume Simbol

Nume n Nume n

Vârsta v

COPIL

Vârsta v

Educatie e Oras o

Copii c Strada s

Adresa a

ADRESA

Numar n

SOT

Sotie s Titlu t

Nume n Institutie i

Vârsta v

EDUCATIE

An Absolvire a

Educatie e

Copii c

Adresa a

SOTIE

Sotie s

Fig. 7.3.4.4 Model Obiectual PERSOANE (Obiecte si Proprietati)

Fig. 7.3.4.5 Conventii de Reprezentare a Modelului Obiectual In încheierea prezentarii conceptului de Identificare facem precizarea ca dezideratul de pastrare a Identitatii Obiectelor pe toata Durata lor de Viata ridica si problema Temporalitatii Colectiilor de Date, care se cer gestionate. Aceasta proprietate deschide posibilitatea de a avea asupra Informatiilor doua Viziuni:

o O Viziune Curenta – Viziunea Starii Tuturor Obiectelor la un Moment Dat

o O Viziune Istorica – Viziunea Evolutiei Unor Obiecte într-un Interval de Timp

Colectie de Obiecte

OBIECT • Proprietate

Legatura OBIECT - Proprietate

Referinta Proprietate - OBIECT

Referinta Proprietate – Colectie de Obiecte

OBIECT • Proprietate

• Proprietate

Baze de DateEvoluate / Baze de Date Obiectuale 575

Sugestia cuprinderii Stampilei de Timp în Identificatori este o solutie rezonabila pentru asigurarea controlului permanent al Identitatii Obiectelor în vederea Sincronizarii Datelor Temporale, supuse unor permanente modificari.

Fig. 7.3.4.6 Model Obiectual PERSOANE (Structura)

7.3.5 Comunicarea între Obiecte

Facilitatea de Comunicare definita si implementata de Modelul Obiectual reprezinta înca o caracteristica importanta, datorita urmatoarelor avantaje pe care le asigura în domeniul Procedurilor Prelucrare:

PARINTI

SOT SOTIE

• o1

• s1

• n1

COPII

ADRESA

• c1

• a1

• c1

• e2

• v2

• n2

• n1

• v1

• e1

COPIL

• v1

• n1

COPIL

• v 2

• n 2

• i1

• a1

• t1

EDUCATIE EDUCATIE

• i2

• a2

• t2

• s 1

• s 2

• a1

576 Baze de DateEvoluate / Baze de Date Obiectuale

o Modularizarea Procedurilor prin regruparea în Metode a Operatiilor compatibile cu Structura de Date atasata fiecarui Obiect

o Sincronizarea Comportamentului Obiectelor prin perechile de Mesaje – Metode recunoscute de Obiectele aflate în dialog

o Incitatia la Paralelizarea Transformarilor la care sunt supuse Obiectele prelucratoare de Mesaje

o Imunitatea Procedurilor Încapsulate în Metode la modificarile survenite în Mediul Exterior

o Concordanta perfecta între Structura de Date si Structura Procedurilor prin restrângerea cadrului de concepere a acestora la Domeniul unui Obiect

Sistemul de construire a Procedurilor de Prelucrare prin asamblarea Mesajelor Transmise si Receptionate a schimbat radical viziunea clasica de procesare a datelor.

7.3.6 Solutii de Implementare pentru BDO

Daca Modelul Obiectual este în prezent bine conturat, asupra definirii Bazelor de Date Obiectuale se mentin înca serioase controverse. Exista doua variante de a implementa Modelul Obiectual într-o Baza de Date:

o Un Sistem de Programare Obiectuala cu Facilitati de Baza de Date

o O Baza de Date cu Facilitati de Prelucrare Obiectuala

Daca rezumam Capabilitatile Minimale ale unui Sistem cu Baze de Date astfel:

§ Un Limbaj de Interogare de nivel înalt cu facilitati de Optimizare asigurate de sistem

§ Suport de asigurare a Persistentei si a Tranzactiilor Atomice prin Controlul Concurentei si a posibilitatilor de Salvare / Restaurare

§ Definirea Structurilor de Date Complexe, Independente si a Strategiilor Performante de Acces

atunci o Baza de Date Obiectuala, folosind prima varianta prezentata anterior, poate fi definita în felul urmator:

Definitie:

O Baza de Date Obiectuala este un Sistem Obiectual care are adaugate Capabilitatile Minimale ale unui SBD.

Gasim aici un punct potrivit pentru a exprima o parere personala legata de eforturile de a înlocui Modelele existente de Baze de Date cu Modelul Obiectual. Modelul Relational va putea fi cu greu eliminat din Gestiunea Bazelor de Date, datorita Elementaritatii sale. Nivelele de Independenta dezvoltate si implementate în Modelul Relational, Referirea Asociativa, Normalizarea Structurilor sunt doar câteva concepte a caror neglijare va reprezenta o pierdere importanta pentru procesarea structurilor complexe de date. Modelul Obiectual însa va ramâne un candidat serios pentru construirea unor Nivele de Interfata al caror succes se va baza tocmai pe existenta la un nivel inferior al Modelului Relational.

Baze de DateEvoluate / Consideratii Critice 577

7.4 Consideratii Critice

Aceasta ultima sectiune se va ocupa cu partea cea mai sensibila si mai controversata a problemelor ridicate de prezenta lucrare si anume:

Care este viitorul tehnologiilor de prelucrare în domeniul modelarii Spatiilor de Informatii si Date ?

Pe baza investigatiilor facute se poate afirma ca desi Modelele Deductive si Obiectuale se situeaza pe drumul de evolutie a prelucrarii informatiilor si datelor. ele se afla în prezent într-un impas. Acest impas se bazeaza pe imposibilitatea confluentei celor doua preocupari de dezvoltare a calcului automat :

o Directia Programarii Clasice

o Directia Sistemelor cu Baze de Date

Dorinta de a impune doar propriile rezultate în dezvoltarile viitoare, reprezinta principalul punct de stagnare în obtinerea unor solutii practice convingatoare si când afirmam acest lucru ne gândim la impunerea unor produse pe piata comerciala. Solutia pe care o sustine autorul este cea de realizare a unei Capabilitatile Minimale Viziuni Conceptuale asupra ambelor domenii ce se cer analizate si proiectate :

o Spatiul Informatiilor numit si Spatiul Problemei sau Domeniul Lumii Reale

o Spatiul Datelor numit si Spatiul Programului sau Model de Calcul Implementat

Care sunt în prezent limitele impuse de Viziunile Traditionale în domeniul Prelucrarii Orientate pe Obiecte :

o Neglijarea importantei Separarii Datelor de Proceduri

§ Aceasta separare corespunde direct cercetarilor initiate de Modelul Obiectelor Abstracte (vezi sectiunea 3.3), care recunosc cele doua aspecte fundamentale si antinomice :

§ Starile Abstracte descrise de Structurile de Informatii si Date

§ Transformarile Abstracte descrise de Proceduri (Formalisme si Metode) Amestecarea Caracteristicilor care descriu Starea Sistemului, în calitate de Variabile de Descriere Obiect cu Variabilele de Lucru (Variabile Locale) nu favorizeaza aceasta distinctie

§ Viitorul trebuie sa apartina Prelucrarii de Volume Mari de Date, de Structuri Complexe si Deschise, care cere înca o data existenta clara a Nivelului de Separare Date – Proceduri. Sa insistam aici doar asupra Aspectului Dinamic, pe care îl implica aceasta constatare. Inexistenta Separarii Nivelelor de Abstractizare în Definirea Datelor face sa scape din vedere imunitatea necesara între Nivelul Logic (Conceptual) si cel Extern , care ar permite în permanenta Modificarea Dinamica a primului nivel. Nici SMALLTALK [SMAL86], nici POET [POET95] si nici C ++ , în calitate de Limbaje OO nu ofera aceasta facilitate (este vorba în speta, de posibilitatea adaugarii de Atribute la o Clasa de Obiecte care are create Instante). Solutia paleativa de

578 Baze de DateEvoluate / Consideratii Critice

creare a unor noi subclase de obiecte ni se pare partiala si improprie pentru frecventa cu care pot interveni cererile de modificare

o Evaluarea Incorecta a Modelului Relational de Reprezentare a Structurilor de Date

§ Principala caracteristica a Modelului Relational, alaturi de fundamentarea sa riguros matematica si decurgând direct din aceasta, consta în Elementaritatea sa. Din aceasta caracteristica rezulta si disponibilitatea Modelului în a descrie Structuri Avansate, sau mai general Orice Tip de Structura, caracteristica pe care o denumim Completitudinea Modelului. Am urmarit aceasta însusire derivata atunci când am încercat utilizarea Modelului Relational ca instrument de reprezentare si manipulare a Structurilor Speciale. In acest sens facem trimitere la sectiunile ce trateaza Implementarea Structurilor Fundamentale cu ajutorul Tipurilor de Relatii (sectiunea 4.2.4.8.2), Implementarea Relationala a Operatiilor de Abstractizare (sectiunea 4.2.4.7.3), Interpretarea Structurilor Relationale ca Baza de Axiome pentru Calculul Logic (sectiunea 7.1). Structurile complexe care trebuie sa dovedeasca Comportament Dinamic conduc inerent la solutia descrierii Structurii de Baza la nivel Atomic si Normalizat, ceea ce permite în permanenta reconstructia cea mai rapida a structurii dorite la un moment dat, prin eliminarea necesitatii pasului de descompunere a structurii ce trebuie reconstruita în Elemente Componente (de preferinta Atomice). Totodata acest Tip Elementar de Structura permite atasarea întregului arsenal al Calculului cu Predicate, daca privim Nivelul Logic al BDR ca o Descriere Intensionala de Predicate, iar Nivelul Fizic ca o Descriere Extensionala de Instante de Predicate.

§ Din primul comentariu rezulta constatarea fireasca ca Modelul Relational nu sta pe acelasi Nivel de Implementare cu Modelul Obiectual, asa încât Compararea lor în vederea stabilirii viitorului solutiilor de reprezentare a datelor si chiar în vederea alegerii solutiei celei mai adecvate pentru un anume proiect ni se pare incorecta.

§ Modelul Relational se va impune în viitor ca un Nivel Intern de Reprezentare a Informatiilor (a se vedea si preocuparile din domeniul Masinilor Baze de Date) lasând altor modele (spre exemplu Modelului Obiectual, Modelului Conceptual etc.) sa populeze nivelele care se apropie de utilizator.

§ Alegerea unui Model Ierarhic (cea mai Statica forma de Reprezentare a Structurilor) pentru Definirea si Memorarea Structurilor (vezi Ierarhia Claselor din Modelele Obiectuale ) este o neglijare a experientei dobândite cu iscusinta si truda pe calea utilizarii Sistemelor cu Baze de Date.

o Mistificarea Problemei Identitatii în Modelele de Reprezentare a Informatiilor

§ Modelele de Reprezentare a Informatiilor provenind din Limbajele de Programare OO declara ca Utilizatorul se poate desprinde de problema Identificarii, pe motiv ca Limbajul de Programare (sau Sistemul de Calcul ) se însarcineaza cu controlul acestui aspect [YOSH90].

Baze de DateEvoluate / Consideratii Critice 579

§ A feri pe Utilizator de aceasta problema cruciala înseamn a a porni la drum (din Spatiul Informatiilor) cu un Model Incomplet si Confuz de Reprezentare. Cum sa poti implementa Transformari descrise prin Operatii de Utilizator Corecte si Explicite daca Obiectele, pâna la nivel de Instanta, nu sunt perfect Identificabile si deci apelabile de catre utilizator ? Experienta de decenii în Prelucrarea Informatiilor cu ajutorul Sistemelor cu Baze de Date a dovedit acest lucru . Nu sustinem ca Sistemul de Calcul nu poate veni în sprijinul rezolvarii comode a multor aspecte de Identificare, dar Identificatorii Generati Automat trebuie sa fie pusi la dispozitia Utilizatorului Final si nu numai a Programatorului, în forma Directa sau sub forma unei Substitutii biunivoce cu cel putin o Cheie Candidata. Redam mai jos câteva solutii de generare automata integrala sau partiala a unor Identificatori:

§ Oferirea pentru identificare a unui Identificator Intern , neafectat de operatii de actualizare (Generare, Stergere sau Modificare).

§ Completarea eventualilor Candidati de Identificatori (Nediscriminanti) cu Momentul Actualizarii (Stampila de Timp: data, ora, minut, secunda), care va putea discerne si în cazul actualizarii în acces concurential. In concluzie, problema Ambiguitatii de Identificare în Spatiul Informatiilor nu trebuie ascunsa Utilizatorului Final, ci solutionata în mod transparent, pentru el si împreuna cu el.

§ Toate Formele de Identificare, analitic definite si expuse în [YOSH90] pot fi cu usurinta Implementate ca Metode (Proceduri Stocate) atasate unor Structuri de Date bine construite si Identificate prin Valoare (Asociativ), la nivelul Utilizatorului Final.

o Neglijarea importantei Regasirii Asociative a Informatiilor si Datelor

§ Regasirea Asociativa cu cele doua mari avantaje oferite :

• Îndepartarea Formei de Dependenta a Structurii de Valori a Datelor de Tipul Suportului de Memorare , prin evitarea Referirii prin Adresa

• Apropierea Structurii Fizice de Utilizator, care poate Referi prin Valori toate Informatiile din Spatiul de Informatii

este neglijata de Modelele Obiectuale promovate de Limbajele de Programare OO, care prefera sa se bucure în continuarea de facilitatea Referirii prin Adresa oferita programatorului.

§ Extinderea Referirii prin Adresa implica un aspect deosebit de riscant (aspect consemnat si rezolvat în istoria prelucrarii în Sistemele cu Baze de Date) si anume Scaderea Rezistentei la Defecte; orice incident de blocare neprevazuta în functionarea sistemelor de calcul poate conduce, în cazul Referirii prin Adresa, la efecte negative de proportie, imprevizibile, în special când e vorba de Volume Mari de Date si Structuri Complexe.

§ In versiunile de Limbaje de Programare OO cu Facilitati de Baze de Date [POET95], Structurile Secundare de Regasire Asociativa, de tip Tabele de Index, nu ocupa locul cuvenit în descrierea Structurilor de Date, fiind tratate

580 Baze de DateEvoluate / Consideratii Critice

ca un Tip de Data obisnuit pus la dispozitia Programatorului pentru a construi Structurile de Date dorite. Structurile Secundare trebuie sa-si mentina rolul de Structuri Anexa, gestionate de sistem si menite sa usureze si sa uniformizeze Accesul la Structurile de Baza , în conditiile garantarii Securitatii si Portabilitatii crescute a datelor.

o Accentuarea nejustificata a necesitatii Diversificarii Tipurilor de Date Explicite

§ Utilizatorul gândeste în Multimi si Clase, de aceea notiunile de Entitate, Caracteristica , Valoare , Relatie între Entitati, îi sunt mai familiare decât notiunile de Vector , Matrice, Lista de Articole , Sir De Biti etc..

§ Ca rezultat al observatiei precedente, implementarea Structurilor Interne Specifice, atasate Tipurilor de Date va trebui facuta sub forma de Încapsulare, pentru a feri Utilizatorul de contactul cu Structuri ce îi sunt straine si a-i oferi doar o corespondenta directa cu reprezentarile sale din Modelul Conceptual construit în Spatiul de Informatii

§ Multe din Tipurile de Date care se considera strict necesare vor trebui implementate în Nivelul Intern de reprezentare a datelor, în Structuri Atomice, Normalizate, care sa respecte Dependentele Functionale ale unei reprezentari consistente (ex. conversia datelor de Tip Multime - Set de Valori - în reprezentare Relationala Normalizata)

o Accentuarea limitelor momentane în Performantele Sistemelor de Calcul

§ Modelele de reprezentare ale viitorului pot fi gândite si daca se face abstractie de limitele actuale ale masinilor de calcul.

§ Structurile si procedurile gândite în acest fel pot constitui astfel si un stimulent în dezvoltarea într-o anumita directie a Arhitecturilor de Echipamente existente în prezent.

§ Încercarea de a compensa lipsa de performanta a echipamentelor prin solutii SOFTWARE poate reprezenta doar o rezolvare temporara, care abate însa atentia de la directiile reale de dezvoltare în perspectiva

Concluziile observatiilor de mai sus sunt:

o Pastrarea Viziunii Relationale Interne a datelor care asigura:

§ Completitudine prin capacitatea de reprezentare a oricaror structuri complexe de date

§ Elementaritatea reprezentarii (”mai simplu nu se poate”)

§ Portabilitatea necesara datelor

§ Consistenta necesara a datelor prin Normalizarea Structurilor

o Construirea unor Straturi Superioare de Reprezentare care sa respecte:

§ Comunicarea cu Utilizatorul prin apropierea reprezentarii de viziunea acestuia

§ Comunicarea cu Stratul Intern de reprezentare prin proiectarea automata în Reprezentare Relationala a Structurilor Externe implementate

ANEXE 581

AANNEEXXEE

O restrânsa sectiune de ANEXE încheie cele sapte Parti ale lucrarii. Ele suplimenteaza informatiile în doua zone considerate importante pentru o Monografie de Concepte si anume:

8 – Scurt Istoric al Evolutiei SBD – o succinta trecere în revista a aparitiei si afirmarii SBD, în Evenimente si Date Calendaristice. Informatiile ofera o utila perspectiva asupra momentului de aparitie al SBD, precum si a ritmului de dezvoltare a diferitelor domenii de preocupari, ce sunt progresiv incorporate în disciplina si a caror amploare e masurata prin diversitatea temelor abordate si care sunt totodata personalizate prin adaptare la specificul dezideratelor initial impuse. 9 – Principalele Surse de Informare – ofera cititorului, dornic sa completeze informarea în diferite directii de preocupari, Sursele Principale consultate; totodata pot fi operate interesante comparatii si delimitari în zonele unor concepte, suficient de dezbatute, pentru a putea profita întotdeauna de existenta mai multor surse de cunostinte si puncte de vedere.

582 Scurt Istoric al Evolutiei SBD

ANEXE 8 Scurt Istoric al Evolutiei SBD

Anii Evenimentul Urmari Deceniul 5

1945 Aparitia Benzii Magnetice (primul suport ce permite Cautarea)

Înlocuirea Cartelei si Benzii Perforate

Deceniul 6 1957 Instalarea Primului Calculator Comercial 1959 IBM lanseaza Sistemul RAMAC Se impune Accesul Direct

Deceniul 7 1961 Primul SGBD Generalizat, IDS – Integrated Data

Stored, proiectat de Bachman Baza pentru Modelul Retea fundamentat la Conference on Data Systems Language Database Task Group

Apare IMS – Information Management System, dezvoltat de IBM

Baza pentru Modelul Ierarhic

Apare IMS DB/DC (Database/Data Communication)

Implementeaza Vederi Retea pe o structura de baza de tip Ierarhic

1965 1970

SABRE, dezvoltat de IBM si American Airline Lanseaza Multiaccesul Utilizatorilor pe Retea de Communicatie

Deceniul 8 Explozie de SGBD-uri CODASYL DBTG, IDMS, IDS II, UNIVAC

DMS, CDC DMS, TOTAL

Continua fundamentarea teoretca Introducerea disciplinei de studiu SGBD Introducere domeniu de cercetare SGBD

1970 Modelul Relational e dezvoltat de Ted Codd cercetator la IBM

Se pun bazele Teoriei Bazelor de Date

1971 Raportul CODASYL al lui Database Task Group 1975 Prima Conferinta Internationala SIGMOD

organizata de catre ACM Special Interest Goup on Management of Data

Constituirea unui forum International pentru diseminarea Cercetarii în Baze de Date

1975 Prima Conferinta Internationala VLDB (Baze de Date de Volum Foarte Mare) organizata de catre Very Large Data Base Foundation

Constituirea unui nou forum International pentru diseminarea Cercetarii în Baze de Date

1976 Modelul Entitati - Relatii (ER) e descris de Chen Proiecte de Cercetare remarcabile System R - IBM, INGRES - Univ. Berkley,

System 2000 - Univ. Texas, Proiectul SOCRATE - Univ. Grenoble, ADABAS - Univ. Darmstadt

Apar Limbaje de Interogare dezvoltate SQUARE, SEQUEL (SQL), QBE, QUEL Deceniul 9 Apar SGBD-uri pentru Calculatoare Personale DBASE, PARADOX etc.

1983 Ancheta ANSI / SPARC semnaleaza prezenta a peste 100 SGBD-uri Relationale

DB2, ORACLE, SYBASE, INFORMIX etc.

Publicarea Standardelor preliminare SQL Aparitia Limbajelor de Generatia a Patra Propunerea ANSI - Limbaj de Definire Retea (NDL)

Realizarea de Aplicatii complete bazate pe Interfete Avansate (neprogramate)

1985

Tendinte Noi SGBD Expert, Orientate Obiectual, Arhitecturi Client-Server, SGBD Distribuite

Deceniul 10 Cereri de noi Capabilitati Baze de Date Spatiale, Temporale,

Multimedia, Active, Deductive Aparitia SGBD Obiectuale comerciale POET Surse de Date Multiple, Heterogene Noi Standarde: SQL2, PDES, STEP Utilizarea Calculului Paralel (Procesoare MPPs) Crestere performante SGBD

Tab. 8.1 Istoricul Evolutiei Sistemelor cu Baze de Date

Principalele Surse de Informare 583

9 Principalele Surse de Informare

Gasim util pentru cititor a completa Referintele Bibliografice din text cu precizarea Surselor Bibliografice principale, repartizate pe Sectiunile Lucrarii.

Se ofera astfel posibilitatea de a completa informatiile deosebit de vaste legate de fiecare subiect reunit în Monografia de Concepte ale unui domeniu de preocupari atât de fertil cum sunt Sistemele cu Baze de Date (vezi Tab. 8.1).

Totodata se îndeplineste prin aceasta informare o fireasca datorie de delimitare a aportului Colectivelor de Cercetare si Proiectare conduse de autor la interpretarea, dezvoltarea si utilizarea conceptelor prezentate, fata de sursa lor de provenienta.

Atasarea Sectiuni – Surse e continuta în Tab. 9.1.

Sectiune Sursa

Bibliografica Observatii

2.1.2 [ULMA80] 3.2 [ASBY56], [ABRI74] 3.2.2 [IRIM82] 3.4.5.1 [BARK01] 3.4.5.2 [ERWM01] 3.5 [JOUR75] 4.1.1 [ABRI74] 4.1.2 [SMIT82], [SMIT77] Cu extinderea unor concepte 4.2.1 [TSIC82] 4.2.4 [DATE95], [ELMA94], [ULMA80] 4.2.4.7 [DATE95], [ELMA94], [TSIC82] 4.2.4.7.2 [TSIC82] Cu extinderea unor concepte 4.2.4.7.4 [TSIC82], [DATE95], [ELMA94] 4.2.4.7.5 [TSIC82], [DATE95], [ELMA94] 4.2.4.8 [LELU97], [LELU84] 4.2.4.9 [PARS89] , [KINS80], [VALD89] 5.1.2 [DATE95], [ELMA94], [ULMA80], 5.1.3 [CODD71], [DATE95] 5.2 [ULMA80], [DATE95] 6.1 [ELMA94] 6.2 [ELMA94], [DATE95], [FORT97] 7.1 [DATE95] , [BOTE97], [STIH99], [PIA00], [FORT97] 7.2 [ELMA94], [DELO80], [PIA00], [FORT97] 7.3 [PARS89], [DITT91] 8 [ELMA94]

Tab. 9.1 Principalele Surse de Informare

584 POSFATA

PPOOSSTTFFAATTAA Am încercat sa adunam în sectiunile precedente nu numai selectiuni dintr-un volum

imens de cunostinte oferite de dezvoltarea domeniului Sistemelor cu Baze de Date în aproape o jumatate de veac, ci si experienta acumulata în nenumarate ore dedicate activitatii didactice, de cercetare si de proiectare pe tarâmul SBD. Daca e mult sau putin e greu de spus. Pot însa repeta marturisirea ca am dorit sa oferim în primul rând nu atât o suma de cunostinte acumulate, cât o Viziune în Timp câstigata asupra unui vast, peren si fertil domeniu de activitate.

Este dificil sa intri într-o Postfata. Ea impune o privire înapoi si ferice de constructorul care nu aude la sfârsit îndemnul:

“Vom face altul, pe râu în jos, Cu mult mai trainic si mai frumos !”

Ne sar însa în ajutor cuvintele lui K.R. Popper:

“ Cei ce refuza sa-si expuna ideile riscului de a fi respinse nu iau parte la Jocul Stiintei”

Îmi vine în minte o Pilda pe care o stiu din copilarie si pe care o reascult cu alta întelegere acum:

“In timp ce se întorceau cu Cobilitele pline de la râu, trei femei îsi lauda Feciorii: - Al meu cânta ca o Privighetoare! - Al meu sare-n joc ca un Ied! - Al meu nu are, din pacate, asa Daruri Alese...

Apropiindu-se de sat le-au iesit Feciorii în cale: Unul cânta ca o Privighetoare. Celalalt juca sarind ca un Ied. Cel de al treilea a luat Cobilita Mamei din spinare.”

Credem într-o Informatica care, si atunci când nu uimeste cântând si dansând, poate uneori Artificial, nu uita totusi sa ia Cobilita Utilizatorului si sa o care, deprinzând astfel o modesta, dar demna Obisnuinta.

Tinem sa-l informam pe cititor, ca asemenea Referintelor Bibliografice care au fost reduse la cele pe care el le poate consulta sau copia la Laboratorul de Baze de Date al Universitatii Tehnice din Cluj-Napoca, si ideile, unele considerate originale, ca de exemplu cele legate de Modelul Conceptual, Utilitatea Clasificarilor Relatiilor dupa Tipuri, Construirea Modulelor de Structuri Standard, Implementarea Relationala a Proceselor de Abstractizare sau Metodele de Abordare Semantica a Structurilor Ameliorate, daca nu chiar Optime, pot fi vazute în forme de implementare în Sisteme aflate în exploatare la Universitate sau la multi alti Beneficiari. Nu dorim sa exageram rezolvarea definitiva a unor probleme care necesita înca suficiente cautari în domeniul solutiilor teoretice si practice legate de Performanta si Independenta Nivelelor Externe, Ridicarea Nivelului Conceptual de Proiectare a Structurilor, Implementarea Viziunilor Obiectuale în SBD, Interfetele Utilizator Evoluate etc. Dorim însa sa atragem atentia celor interesati de material sa nu treaca prea usor nici peste partile care par prea simple si ca urmare cunoscute, nici peste cele care par prea complicat formalizate pentru a fi urmarite. Cheia prezentei Monografii de Concepte s-a dorit a fi tocmai legatura între cele doua extreme.

De altfel, toate ideile mari si perene trebuie sa devina în final foarte simple. Si daca, dupa ce a înteles ca merita sa zaboveasca asupra solutiilor finale propuse, Cititorul va resimti macar o data starea Socratica:

“ .. ca îsi aduce aminte de lucruri pe care nu le-a stiut niciodata ..”

autorul va primi, la rândul lui, sporita Rasplata pentru efortul depus.

Lista Figurilor si Tabelelor 585

Lista Figurilor si Tabelelor Fig. 1.2.1 Experimentul lui M. McKay.................................................................................................20 Fig. 2.1.1 Nivele de Abstractizare într-o Baza de Date...................................................................32 Fig. 2.4.1 Structura de informatii ce descrie componenta unui produs........................................38 Fig. 2.4.2. Structura generala de informatii pentru componenta unui produs.............................39 Tab. 2.4.3 Componenta unei Retele de Calculatoare.......................................................................40 Fig. 3.1.1.7.1. Submultimi în Relatie de Acoperire...........................................................................46 Fig. 3.1.1.7.2. Submultimi în Relatie de Partitie...............................................................................47 Fig. 3.1.4.1 Reprezentarea Recursiva a structurii unui Arbore.....................................................63 Tab. 3.2.3.1 Reprezentarea Informatiei prin Data ...........................................................................69 Fig. 3.4.1.1 Compararea Redondantei în Modelele de Date..........................................................75 Tab. 3.4.1.1.2 Raportul Structura Logica de Date - Structura Fizica de Date............................79 Fig. 3.4.1.2.2 Spatii si Planuri de descriere a Informatiilor si Datelor.......................................81 Fig. 3.4.1.2.1 Spatiul de Informatii – Structura Logica de Date – Structura Fizica de Date....82 Fig. 3.4.2.1 Structura de tip Echivalenta - Nivel ..............................................................................84 Fig. 3.4.2.2 Structura de tip Incluziune - Partitie.............................................................................86 Fig. 3.4.2.3 Structura de tip Incluziune - Acoperire.........................................................................89 Fig. 3.4.2.2.1.1 Colectie de Informatii STUDENTI ..........................................................................91 Fig. 3.4.2.2.1.1.1 Eliminarea Redondantei ........................................................................................92 Fig. 3.4.2.2.1.2.1 Inversarea Partiala (Indexarea)...........................................................................93 Fig. 3.4.2.2.1.3.1 Eliminarea Redondantei + Inversarea Partiala (Varianta 1).........................95 Fig. 3.4.2.2.1.3.2 Eliminarea Redondantei + Inversarea Partiala (Varianta 2).........................96 Fig. 3.4.2.2.1.4.1 Inversarea Totala....................................................................................................97 Fig. 3.4.2.2.1.5.1 Reorganizarea Structurii .......................................................................................98 Fig. 3.4.3.1.1. Reprezentarea Fizica..................................................................................................102 Fig. 3.4.3.1.2. Structura unei Universitati în Reprezentare Fizica..............................................103 Fig. 3.4.3.2.1 Conventiile grafice de reprezentare a Schemei Simbolice...................................104 Fig. 3.4.3.2.2 Reprezentarea Simbolica............................................................................................105 Fig. 3.4.3.2.3 Structura unei Universitati în Reprezentare Simbolica ........................................106 Fig. 3.4.3.3.1 Conventiile grafice pentru Arborelui de Structura în varianta Relationala.....107 Fig. 3.4.3.3.2 Structura unei Universitati în reprezentare Simbolica Concentrata..................108 Fig. 3.4.3.3.3 Structura unei Universitati în reprezentare Simbolica Extinsa............................109 Fig. 3.4.3.3.4 Structura unei Universitati reprezentata prin Arbore de Structura ..................110 Fig. 3.4.3.4.1 Conventiile grafice de reprezentare a Diagramei Entitati - Relatii ...................111 Fig. 3.4.3.4.2 Structura unei universitati în reprezentare Entitati – Relatii (Varianta 1).....112 Fig. 3.4.3.4.3 Structura unei Universitati în reprezentare Entitati – Relatii (Varianta 2) ......113 Fig. 3.4.3.4.4 Rezultatele la Examene în reprezentare Entitati – Relatii....................................114 Fig. 3.4.3.5.1 Rezultatele la Examene – Schema de Descriere.....................................................115 Fig. 3.4.4.1.1 Structura de Informatii în compartimentul Vânzari.............................................117 Fig. 3.4.4.2.1 Structura Partiala I (BENEFICIARI / CONTRACTE / PRODUSE) ................119 Fig. 3.4.4.2.2 Structura Partiala I (Diagrama Simbolica)..........................................................120 Fig. 3.4.4.2.3 Structura Partiala II (BENEFICIARI / PRODUSE / CONTRACTE)...............120 Fig. 3.4.4.2.4 Structura Partiala II (Diagrama Simbolica) .........................................................121 Fig. 3.4.4.2.5 Structura Partiala III (PRODUSE / CONTRACTE / BENEFICIARI) ..............121 Fig. 3.4.4.2.6 Structura Partiala III (Diagrama Simbolica)........................................................122 Fig. 3.4.4.2.7 Structura Partiala II (PRODUSE / BENEFICIARI / CONTRACTE) ................122

Lista Figurilor si Tabelelor 586

Fig. 3.4.4.2.8 Structura Partiala II (Diagrama Simbolica)..........................................................123 Fig. 3.4.4.2.9 Structura Partiala II (PRODUSE / BENEFICIARI si CONTRACTE) ..............123 Fig. 3.4.4.2.10 Structura Partiala V (Diagrama Simbolica)........................................................124 Fig. 3.4.4.3.1 Structura de ANSAMBLU (Diagrama Simbolica - Varianta Extinsa) ..............125 Fig. 3.4.4.3.2 Structura de ANSAMBLU (Diagrama Simbolica - Varianta Concentrata) .....125 Fig. 3.4.5.1.1 Copiii Angajatilor.........................................................................................................128 Fig. 3.4.5.1.2 Produsele unui Pachet.................................................................................................128 Fig. 3.4.5.1.3 Rândurile unei Comenzi ..............................................................................................128 Fig. 3.4.5.1.4 Copii adoptatii...............................................................................................................129 Fig. 3.4.5.1.5 Sotia Angajatului ..........................................................................................................129 Fig. 3.4.5.1.6 Angajatul Sotiei............................................................................................................130 Fig. 3.4.5.1.7 Certificatul unei Persoane..........................................................................................130 Fig. 3.4.5.1.8 Casatoriti........................................................................................................................130 Fig. 3.4.5.1.9 Membrii Echipei ..........................................................................................................131 Fig. 3.4.5.1.10 Echipele unei Persoane.............................................................................................131 Fig. 3.4.5.1.11 Jucatorii unui Joc......................................................................................................132 Fig. 3.4.5.1.12 Parteneri .....................................................................................................................132 Fig. 3.4.5.1.13 Ascendenta..................................................................................................................133 Fig. 3.4.5.1.14 Înlocuire......................................................................................................................134 Fig. 3.4.5.1.15 Componenta................................................................................................................134 Fig 3.4.5.2.1. Conventiile de reprezentare grafica IE si IDEF1X ................................................137 Fig 3.5.2.1.1 Structura de Control de tip Compozitie....................................................................139 Fig 3.5.2.2.1 Structura de Control de tip Selectie Simpla..............................................................140 Fig 3.5.2.2.2 Structura de Control de tip Selectie Multipla..........................................................140 Fig 3.5.2.3.1 Structura de Control de tip Repetitie (Repetitie Posibil Nula).............................141 Fig 3.5.2.3.2 Structura de Control de tip Repetitie (Repetitie Nenula)......................................141 Fig 3.5.2.4.1 Structura de Control de tip Substitutie......................................................................142 Tab. 3.5.3.1 Elementele Structurilor de Procedurii ......................................................................143 Fig. 3.5.4.1 Definirea în Sintaxa BNF a Procedurii.......................................................................145 Fig. 3.5.6.1 Arborele de Programare pentru procedura de Sortare prin Transpunere...........147 Fig. 3.5.6.2 Structura Simbolica de tip Retea (Arbore de Structura)..........................................148 Fig. 3.5.6.3 Procedura de Interogare (Descriere în Pseudo – Cod)...........................................149 Fig. 3.5.6.4 Procedura de Interogare (Arborele de Programare)...............................................150 Fig.4.1.1.2.1 Spatiul de Date cu model Ierarhic.............................................................................155 Fig. 4.1.1.2.2 Spatiul de Date cu model Retea ...............................................................................155 Fig. 4.1.1.2.3 Spatiul de Date cu model Relational.......................................................................156 Fig. 4.1.1.3.5.1 Valori Izonime...........................................................................................................163 Fig. 4.1.1.3.5.2 Valori Izotipe.............................................................................................................164 Tab. 4.1.1.3.6.1. Legatura Relatii de Asociere – Tipuri de Structura ..........................................165 Tab. 4.1.1.3.6.2. Legatura Relatii de Asociere – Tipuri de Structura ..........................................166 Tab. 4.1.1.4.1 Notiunile definite în Modelul ECV - Recapitulare................................................170 Fig. 4.1.1.4.1.2. Modelul ECV în expresii de Multimi si Relatii - Definire matematica..........172 Fig. 4.1.1.4.2.1 Modelul ECV reprezentat prin Multimi si Relatii..............................................173 Fig. 4.1.2.2.1.1 Exemplificarea procesului de Abstractizare prin Generalizare.......................175 Fig. 4.1.2.2.1.2. Generalizarea cu Atribut de tip Categorie..........................................................176 Fig. 4.1.2.2.1.3. Generalizarea cu Obiect Abstract de tip Criteriu de Clasificare....................177 Fig. 4.1.2.2.2.1 Exemplificarea procesului de Abstractizare prin Agregare.............................178

Lista Figurilor si Tabelelor 587

Fig. 4.1.2.3.1 Structura pe Blocuri a Categoriilor.........................................................................180 Fig. 4.1.2.3.2 Ierarhii de Generalizare.............................................................................................180 Fig. 4.1.2.3.3 Ierarhia de Agregare .................................................................................................181 Fig. 4.1.2.4.1 Realizarile OA AUTOVEHICOL .............................................................................183 Fig. 4.1.2.5.1 Ierarhie de Agregare în Planul Realizarilor...........................................................184 Fig. 4.1.2.5.2 Ierarhie de Generalizare în Planul Realizarilor....................................................185 Fig. 4.1.2.6.1 Viziunile Multiple ale Obiectului Abstract AUTOVEHICOL ..............................187 Tab. 4.1.2.6.2 Relativitatea viziunii utilizatorului asupra Obiectelor Abstracte......................188 Fig. 4.1.2.7.1 Sintaxa Abstracta pentru Limbajul de Definire a Obiectelor Abstracte.........189 Fig. 4.1.2.7.2 Structura Organizatorica Universitara (descriere ca structura de OA............190 Fig. 4.1.2.10.1.1 Modelul Obiectelor Abstracte (Metodologia de Proiectare)........................192 Fig. 4.1.2.10.2.1.1 Categorii Indirecte.............................................................................................193 Fig. 4.1.2.10.2.1.2 Categorii Directe................................................................................................193 Fig. 4.1.2.10.2.2.1 Componente Indirecte........................................................................................194 Fig. 4.1.2.10.2.2.2 Componente Directe...........................................................................................194 Fig. 4.1.2.10.2.4.1 Definire Roluri în Casatorie (Ierarhie de Agregare) ...................................196 Fig. 4.1.2.10.2.4.2 Definire Roluri în Casatorie (Ierarhie de Generalizare).............................196 Fig. 4.1.2.10.2.4.3 Definire Roluri în Casatorie (Ierarhie de Agregare – Varianta 1)............197 Fig. 4.1.2.10.2.4.4 Definire Roluri în Casatorie (Ierarhie de Agregare – Varianta 2)............198 Fig. 4.2.1.1.1 Componentele Modelelor Stricte de descriere a datelor....................................208 Tab. 4.2.1.1.2.1 Clasificarea Proprietatilor Obiectelor stocate într-un Model de Date ........212 Fig. 4.2.2.1.1 Componentele Modelului Ierarhic............................................................................215 Fig. 4.2.2.1.2 Descrierea Segmentelor BENEFICIAR (B) si PRODUS (P) ...............................215 Fig. 4.2.2.1.3 Arborele de Structura pentru Modelului Ierarhic..................................................216 Fig. 4.2.3.1.1 Componentele Modelului Retea ................................................................................218 Fig. 4.2.3.1.2 Relatia Fundamentala între BENEFICIAR si PRODUS .......................................220 Fig. 4.2.3.1.3 Diagrama Simbolica B-P-C.......................................................................................220 Fig. 4.2.3.1.2 Relatia Fundamentala între BENEFICIAR si PRODUS .......................................221 Fig. 4.2.3.1.3 Arbore Invers în Reprezentare Fizica.......................................................................221 Fig. 4.2.3.1.4 Arbore Invers în Reprezentare Simbolica...............................................................222 Fig. 4.2.3.1.4 Arbore Invers în Reprezentare Simbolica...............................................................222 Fig. 4.2.3.1.4 Descrierea Nodurilor ca Articole Principale.........................................................223 Fig. 4.2.3.1.4 Descrierea Arcelor ca Articole de Legatura...........................................................223 Tab. 4.2.4.1 Comparatie de termeni – SI / MR / SD.......................................................................225 Tab. 4.2.4.2 Domeniile Structurii Relationale COMPUS – COMPONENT ..............................226 Tab. 4.2.4.3 Relatia PRODUS ............................................................................................................226 Tab. 4.2.4.4 Relatia ANSAMBLU........................................................................................................226 Fig. 4.2.4.5 Schema de Descriere a structurii PRODUS - ANSAMBLU ....................................227 Fig. 4.2.4.6 Arbore de Structura PRODUS – ANSAMBLU ..........................................................227 Tab. 4.2.4.2.1 Structura Nenormalizata.............................................................................................229 Tab. 4.2.4.2.2 Structura Normalizata................................................................................................229 Tab. 4.2.4.4.1 Tipuri de Chei..............................................................................................................231 Fig. 4.2.4.4.2.1.1 Arbore de Structura BENEFICIAR – LOCALITATE......................................233 Tab. 4.2.4.5.1. Produsele Contractate de Beneficiarul cu Codul ’B2’.........................................244 Tab. 4.2.4.5.2 Numele si Contul Beneficiarului din Orasul ’O1’.................................................244 Tab. 4.2.5.1. Codul Produsului si Orasul în care trebuie livrate..................................................244 Tab. 4.2.4.5.1.1.1 Clasificarea Operatorilor din Algebra Relationala.......................................246

Lista Figurilor si Tabelelor 588

Fig. 4.2.4.5.1.1 Intensiunea relatiilor GRUPA si STUDENT.......................................................248 Tab. 4.2.4.5.1.1 Extensiunea relatiilor GRUPA si STUDENT .....................................................248 Fig. 4.2.4.5.1.2 Intensiunea relatiei PROFESOR ...........................................................................249 Tab. 4.2.4.5.1.1 Extensiunea relatiei PROFESOR .........................................................................249 Tab. 4.2.4.5.1.3 Variantele de Operatori de Reunire.....................................................................254 Fig. 4.2.4.5.1.4.1 Structura CERERE - STOC .................................................................................256 Fig. 4.2.4.5.1.4.2 Rezultatul Beneficiarii care au cerut toate Produsele din STOC .................256 Fig. 4.2.4.5.1.4.1 Set Complet de Operatori Relationali...............................................................257 Tab. 4.2.4.5.1.5.1 Corespondente Simboluri de Expresii – Clauze de Limbaj ..........................257 Fig. 4.2.4.5.1.5.1 Definirea în Sintaxa BNF a unui LMDR bazat pe Algebra Relationala.....258 Fig. 4.2.4.5.1.6.1 Implementarea procedurala a operatorilor Specific Relationali .................259 Tab. 4.2.4.5.2.1.1 Structura Enuntului în Limbajul Logic............................................................262 Fig. 4.2.4.5.2.1.2 Structura Enuntului în Limbajul Logic............................................................263 Tab. 4.2.4.5.2.1.3 Clasificarea Operatorilor Logico- Lingvistici...............................................263 Fig. 4.2.4.5.2.1.4 Descrierea formala a Relatiei ...........................................................................264 Fig. 4.2.4.5.2.2.2.1 Procedura de inspectie pentru Variabile Libere.........................................266 Fig. 4.2.4.5.2.2.2.2 Procedura de inspectie pentru Variabile Cuantificate Existential ..........266 Fig. 4.2.4.5.2.2.2.3 Procedura de inspectie pentru Variabile Cuantificate Universal............266 Fig. 4.2.4.5.2.2.4.2.1 Structura Blocului SELECT........................................................................271 Tab. 4.2.4.6.1.1 Legaturi între Constructorii Nivelelor de Abstractizare..................................285 Fig. 4.2.4.6.3.1 Intensiunea Vederii PCO........................................................................................288 Tab. 4.2.4.6.3.2 Extensiunea Vederii PCO......................................................................................288 Fig. 4.2.4.6.3.3 Intensiunea Vederii PC1.........................................................................................289 Tab. 4.2.4.6.3.4 Extensiunea Vederii PC1.........................................................................................289 Tab. 4.2.4.6.3.5 Dificultati de actualizare a Vederii PC1............................................................289 Fig. 4.2.4.7.1 Componentele Modelului Relational........................................................................292 Tab. 4.2.4.7.1.1 Baza de Date MEDICALA (Atributele Descriptoare).......................................293 Tab. 4.2.4.7.1.2 Baza de Date MEDICALA (Gruparea Atributelor în Clase de Entitati) .......293 Fig. 4.2.4.7.1.3 Baza de Date MEDICALA (Arborele de Structura)...........................................294 Fig. 4.2.4.7.1.4 Baza de Date MEDICALA (Diagrama Simbolica).............................................295 Fig. 4.2.4.7.1.8 Baza de Date MEDICALA (Diagrama Entitati-Relatii).....................................296 Fig. 4.2.4.7.2.1.1 Legatura Neidendificatoare 1 – n (Cheie Straina → Cheie Primara)........298 Fig. 4.2.4.7.2.1.2 Legatura Idendificatoare 1 - n (Cheie de Legatura → Cheie Primara)......298 Fig. 4.2.4.7.2.1.3 Legatura Idendificatoare 1 - 1 (Cheie de Legatura → Cheie Primara)......299 Fig. 4.2.4.7.2.1.4 Legatura Neidendificatoare m – n ( între Atribute de Legatura)..................299 Fig. 4.2.4.7.2.1.5 Legaturi Neidendificatoare 1- n (Atribute de Legatura→Cheie Primara)..300 Fig. 4.2.4.7.2.2.1.1.1 Relatie de tip Entitate Completa...................................................................301 Fig. 4.2.4.7.2.2.1.1.2 Relatie de tip Entitate Completa – Relatia SPITAL ..................................302 Fig. 4.2.4.7.2.2.1.2.1 Relatie de tip Entitate Incompleta ................................................................303 Fig. 4.2.4.7.2.2.1.2.2 Relatie de tip Entitate Incompleta – Relatia SPITAL extinsa .................303 Fig. 4.2.4.7.2.2.1.2.3 Relatie de tip Entitate Incompleta – DOCTOR / SPITAL .......................304 Fig. 4.2.4.7.2.2.2.1.1 Relatie de tip Legatura Simpla.....................................................................305 Fig. 4.2.4.7.2.2.2.1.2 Relatii de tip Legatura Simpla cascadate..................................................306 Fig. 4.2.4.7.2.2.2.2.1 Relatie de tip Legatura Completa................................................................307 Fig. 4.2.4.7.2.2.3.1 Relatie de tip Mixt..............................................................................................308 Fig. 4.2.4.7.2.2.3.2 Structura DOCUMENT / RANDURI..............................................................310 Fig. 4.2.4.7.3.2.1 Structura DOCUMENT / RANDURI ................................................................313

Lista Figurilor si Tabelelor 589

Fig. 4.2.4.7.5.1.1 Structuri de Date pentru operatia de Navigare în Tabele ............................320 Fig. 4.2.4.7.5.3.1 Nivele de Definire a Operatiilor.......................................................................323 Fig. 4.2.4.8.1.1 Structura STUDENT- varianta 1..........................................................................324 Fig. 4.2.4.8.1.2 Structura de Generalizare pentru STUDENT ....................................................325 Fig. 4.2.4.8.1.3 Structura STUDENT- varianta 2..........................................................................325 Fig. 4.2.4.8.1.4 Structura STUDENT- varianta 3..........................................................................326 Fig. 4.2.4.8.1.5 Structura STUDENT- varianta 4..........................................................................327 Fig. 4.2.4.8.2.1.1 Structura GRUPA / STUDENT- varianta 1 ....................................................328 Fig. 4.2.4.8.2.1.2 Structura GRUPA / STUDENT- varianta 2 ....................................................329 Fig. 4.2.4.8.2.2.1 Legatura m – n (Diagrama Simbolica ) ...........................................................330 Fig. 4.2.4.8.2.2.2 Legatura m – n (Arborele de Structura ) ..........................................................330 Fig. 4.2.4.8.2.2.3 Legatura m – n (Arborele de Structura) ..........................................................331 Fig. 4.2.4.8.2.2.4 Structura de Date Curse Aviatice.....................................................................333 Fig. 4.2.4.8.2.2.5 Structura de Date Societati Partenere.............................................................334 Fig. 4.2.4.8.2.2.6 Structura de Date Contracte / Parteneri .........................................................335 Fig. 4.2.4.8.2.2.7 Structura STUDENT - PARTENER .................................................................337 Fig. 4.2.4.8.2.2.8 Structura STUDENT - PRIETEN (varianta 1) ..............................................337 Fig. 4.2.4.8.2.2.9 Structura STUDENT - PRIETEN (varianta 2) ..............................................338 Fig. 4.2.4.8.2.2.10 Ierarhia de Generalizare pentru Entitatea TEMA.......................................340 Fig. 4.2.4.8.2.2.11 Structura COMUNICARE ca Entitate Agregata P x S x C x T..................340 Fig. 4.2.4.8.2.2.12 Gestiunea Comunicarilor – Legaturi Fundamentale..................................341 Fig. 4.2.4.8.2.2.13 Structura COMUNICARE ca Entitate Agregata E x C x T ........................343 Fig. 4.2.4.8.2.2.14 Structura Profesor – Student – Domeniu-de-Interes (Varianta 1)............344 Fig. 4.2.4.8.2.2.15 Structura Profesor – Student – Domeniu-de-Interes (Varianta 2)............344 Fig. 4.2.4.8.3.1 Reprezentarea structurii de tip Arborescenta.....................................................346 Fig. 4.2.4.8.3.2 Exemplul de Structura de Baza de tip Arborescenta.......................................347 Fig. 4.2.4.8.3.3 Construirea Structurilor Ierarhice prin Legaturi Relationale.........................348 Fig. 4.2.4.8.3.1.1 Reprezentarea relationala a Entitatii PRODUS ...............................................349 Fig. 4.2.4.8.3.2.1 Structura organizatorica a unei UNIVERSITATI (Viziune Ierarhica) .......350 Fig. 4.2.4.8.3.2.2 Structura Relationala cu Identificare Contextuala........................................351 Fig. 4.2.4.8.3.2.3 Structura Relationala cu Identificare Necontextuala...................................352 Fig. 4.2.4.8.3.2.4 Structura unei Universitati (Varianta 1)..........................................................353 Fig. 4.2.4.8.3.2.5 Structura unei Universitati (Varianta 2)...........................................................353 Fig. 4.2.4.8.3.2.6 Structura unei Universitati (Varianta 3)..........................................................354 Fig. 4.2.4.8.3.2.7 Structura P x S x M (Viziune Ierarhica)............................................................355 Fig. 4.2.4.8.3.2.8 Structura P x S x M (Viziune Relationala – Varianta 1) ..............................356 Fig. 4.2.4.8.3.2.9 Structura P x S x M (Viziune Relationala – Varianta 2)...............................357 Fig. 4.2.4.8.4.1 Matrice Bidimensionala – Diagrama simbolica.................................................358 Fig. 4.2.4.8.4.1 Matrice Bidimensionala – Arbore de Structura..................................................359 Fig. 4.2.4.8.5.1 Reprezentarea Listelor de Valori .........................................................................361 Fig. 5.1.2.3.1 Exemplificarea grafica a Dependentelor Multivalorice......................................379 Tab. 5.1.2.3.2 Extensiunea Tabelei de Baza COMANDA.............................................................381 Fig. 5.1.3.1 Gradele de normalizare ale relatiilor..........................................................................383 Fig. 5.1.3.1.1.2.1 Diagrama Simbolica BENEFICIARI - PRODUSE - CONTRACTE ............386 Fig. 5.1.3.1.3.1 Dependentele Functionale în relatia BENEFICIAR ...........................................386 Fig. 5.1.3.1.3.2 Dependentele Functionale în relatia PRODUS .................................................387 Fig. 5.1.3.1.3.3 Dependentele Functionale în relatia CONTRACT.............................................387

Lista Figurilor si Tabelelor 590

Fig. 5.1.3.1.2.1.1 Schema de Relatii BENEFICIAR-PRODUS-CONTRACT............................388 Fig. 5.1.3.1.2.2.1 Schema de Relatii BENEFICIAR-PRODUS-CONTRACT............................389 Fig. 5.1.3.1.2.3.1 Schema de Relatii BENEFICIAR-PRODUS-CONTRACT............................390 Fig. 5.1.3.2.2.1 Dependentele Functionale între atributele Oras si Tip .....................................392 Fig. 5.1.3.2.2.2 Dependentele Functionale în cadrul relatiei BC................................................392 Fig. 5.1.3.2.2.3 Dependentele Functionale în cadrul relatiilor BO si C ...................................393 Fig. 5.1.3.2.2.4 Dependentele Functionale în cadrul relatiilor B si O ......................................394 Fig . 5.1.3.2.2.5 Dependentele Functionale în cadrul relatiei BO..............................................396 Fig. 5.1.3.2.5.1.1 Dependentele Functionale în cadrul relatiei BN.............................................400 Fig. 5.1.3.2.5.2.1 Dependentele Functionale în cadrul relatiei BNC.........................................401 Tab. 5.1.3.2.5.2.2 Compararea definitiilor RN3 si BCNF.............................................................402 Tab. 5.1.3.2.6.1 Dependente Multivalorice......................................................................................403 Tab. 5.1.3.2.6.2 Reprezentarea conventionala sugestiva a Dependentelor Multivalorice......403 Fig . 5.1.3.2.6.3 Dependentele Functionale în cadrul relatiei CPM...........................................404 Fig . 5.1.3.2.6..4 Dependentele Functionale în cadrul relati ilor CP si PM...............................404 Fig . 5.1.3.2.7.1 Extensiunea relatiei SPT........................................................................................405 Fig. 5.1.3.2.7.2 Descompunerea si recompunerea relatiei SPT în varianta I-a.......................406 Fig. 5.1.3.2.7.3 Descompunerea si recompunerea relatiei SPT în varianta a II-a .................407 Fig. 5.1.4.1.1 Arborele de Structura proiectat BOTTOM-UP pentru structura BNC..............415 Tab. 5.1.4.1.2 Extensiunea Structurii CM – Forma 1 ..................................................................418 Tab. 5.1.4.1.3 Extensiunea Structurii CPM – Forma 2 ...............................................................418 Tab. 5.1.4.1.2 Extensiunea Structurii CPM – Forma 3 ...............................................................419 Fig. 5.1.4.1.2 Arborele de structura proiectat BOTTOM-UP pentru structura CPM.............420 Fig. 5.1.4.1.3 Structura SPT - Varianta I-a ......................................................................................424 Fig. 5.1.4.1.4 Structura SPT - Varianta a II-a.................................................................................426 Tab. 5.1.4.2.1.1 Implementarea relationala a Modelului Obiectelor Abstracte......................428 Fig. 6.1.1.1 Ierarhia de clasificare a Utilizatorilor.......................................................................437 Fig. 6.1.1.2 Ierarhia de clasificare a Resurselor...........................................................................437 Tab. 6.1.1.3 Asocierea Utilizatori – Resurse - Drepturi...............................................................438 Tab. 6.1.3.1 Relatia Multinivel ANGAJAT - Extensia originala .................................................441 Tab. 6.1.3.2 Relatia Multinivel ANGAJAT – Vederea Utilizatorului 1......................................441 Tab. 6.1.3.3 Relatia Multinivel ANGAJAT – Vederea Utilizatorului 2......................................442 Tab. 6.1.3.4 Relatia Multinivel ANGAJAT – Extensia relatiei dupa Poliinstantiere...............442 Fig. 6.2.1 Executia intermitenta si întretesuta a Tranzactiilor....................................................443 Fig. 6.2.1.1 Pierderea de actualizari prin Rescriere.....................................................................445 Fig. 6.2.1.2 Desincronizare prin citire de Valori Temporare (Intermediare)..........................445 Fig. 6.2.1.3 Sumare de Valori Temporare aflate în curs de actualizare...................................446 Fig. 6.2.3.1 Diagrama de Stari ale unei Tranzactii.......................................................................449 Tab. 6.2.4.1 Continutul Jurnalului de Tranzactii...........................................................................451 Fig. 6.2.8.1 Plan de Executie Serial ( P4 ) .....................................................................................455 Fig. 6.2.8.2 Plan de Executie Serial ( P5 ) .....................................................................................456 Fig. 6.2.8.3 Plan de Executie Neserial (P6 )...................................................................................458 Fig. 6.2.8.4 Plan de Executie Neserial (P7 )...................................................................................459 Fig. 6.2.8.3 Algoritm pentru crearea Grafului de Precedenta al unui Plan de Executie ........460 Fig. 6.3.1 Procesul de Refacere (Salvare / Restaurare) al unei Baze de Date.........................469 Tab. 6.3.2.1 Starea Tranzactiilor raportate la momentele de Incident / Punct de Control.....472 Tab. 6.3.2.2 Strategii de Refacere a unei Baze de Date................................................................472

Lista Figurilor si Tabelelor 591

Tab. 7.1.1. Set de Reguli de Deducere în Calculul Propozitional ..............................................479 Tab. 7.1.3. Lista Regulilor de Definire a FBC într-un Limbaj Predicativ..................................484 Fig. 7.1.6.1. Conversia Informatii - Date.........................................................................................493 Fig. 7.1.6.2 Extensiunea BD PERSOANA / TATA ..........................................................................494 Fig. 7.1.6.3 Extensiunea Tabelei de Baza PARINTE .....................................................................495 Fig. 7.1.6.3 Extensiunea Vederii BUNIC .........................................................................................496 Fig. 7.1.8.1.1 Evaluarea Întrebarilor în varianta SBD Pur Deductiva......................................507 Fig. 7.1.8.2.1 Raportul Informatii Elementare – Proprietati Generale......................................508 Fig. 7.1.8.2.2 Structura Bazei de Date Deductive IE - PG ..........................................................509 Fig. 7.1.8.2.3 Evaluarea Întrebarilor în varianta SBD Deductive Mixte...................................509 Fig. 7.1.8.3.1 Raportul Informatii Elementare – Proprietati Generale......................................512 Fig. 7.2.3.1.1. Arhitectura unui Sistem Distribuit cu Baze de Date.............................................521 Fig. 7.2.3.2.1.1 Descrierea Intensionala a BD PROIECTE / COMPARTMENTE...............524 Fig. 7.2.3.2.1.2 Descrierea extensionala a BD PROIECTE / COMPARTMENTE ..............525 Tab. 7.3.1.1 Comparatia Viziunii Obiectuale în Baze de Date si Programarea Obiectuala...547 Fig. 7.3.1.2 Modele de Date, Baze de Date, SGBD-uri .................................................................549 Fig. 7.3.2.1 Arhitectura Conventionala a Sistemelor de Programare..........................................551 Fig. 7.3.2.2 Arhitectura Obiectuala a Sistemelor de Programare................................................552 Fig. 7.3.2.1.1 Arhitectura Modelului Obiectual al Clasei COMPANIE .....................................554 Fig. 7.3.2.1.2 Structura Clasei COMPANIE....................................................................................555 Fig. 7.3.2.1.3 Instantierile Clasei COMPANIE...............................................................................556 Fig. 7.3.3.1 Supraclase si Subclase de Obiecte...............................................................................559 Fig. 7.3.3.1.1 Exemplu de Mostenire Structurala – Ierarhia de Mostenire...............................562 Fig. 7.3.3.1.2 Proprietati Mostenite Structural de Instanta de Obiect........................................563 Fig. 7.3.3.2.1 Mostenire Comportamentala de Metode cu Polimorfism.....................................564 Fig. 7.3.3.2.2 Mostenire Multipla......................................................................................................566 Fig. 7.3.3.2.3 Rezolvare de Conflict prin Liniarizarea Mostenirii Multiple.............................567 Fig. 7.3.4.1 Atribuire si Copiere (Superficiala si Profunda) ........................................................571 Tab. 7.3.4.2 Identitatea (Numele) si Continutul (Structura) Obiectelor....................................572 Tab. 7.3.4.3 Egalitatea si Identitatea Obiectelor.............................................................................572 Fig. 7.3.4.4 Model Obiectual PERSOANE (Obiecte si Proprietati) ............................................574 Fig. 7.3.4.5 Conventii de Reprezentare a Modelului Obiectual...................................................574 Fig. 7.3.4.6 Model Obiectual PERSOANE (Structura)..................................................................575 Tab. 8.1 Istoricul Evolutiei Sistemelor cu Baze de Date ..............................................................582 Tab. 9.1 Principalele Surse de Informare .......................................................................................583

Bibliografie 592

Bibliografie

[ABRI74] Abrial Jean Raymond., Data Semantics, Data Base Management, pp. 1-59, Northe Holand, Amsterdam, 1974

[APER83] Apers P.M.G., Query Processing and Data Allocation in Distributed Database

Systems, Mathematics Centrum,Ams terdam, 1983 [ASBY56] Asby W.R., An Introduction to Cybernetics, London Chapmann & Hall, 1956 [BARK01] Barker Richard , CASE Method – Entity Relationship Modelling, Oracle

Corporation UK Limited, Addison-Wesley Publishing Company, USA, 1995 [BENC79] Benci Guillame, Rolland Colette, Les Bases de Donnees – D’une conception

Cannonique a une Realisation Extensible, SCM Editions, Paris, 1979 [BERT01] Bertino Elisa, Catania Barbara, Zarri Gian Piero , Intelligent Database

Systems, ACM Press Books, Great Britain 2001 [BOTE97] Botezatu Petre, Introducere în Logica, Editura Polirom, Iasi, 1997 [BPR-95] Mayer Richard J. & Team, Delivering Results - Solving BPR from Art to

Engineering , Knowledge Based Systems, Incorporated, Texas, 1995 [BPWM01] - BPwin – Methods Guide 4.0 , Computer Associates International, Inc., USA,

2001 [CELK99] Celko Joe, Data & Databases : Concepts in Practice, Morgan Kaufmann

Publishers, San Francisco, California, USA, 1999 [CERI97] Ceri Stefano, Fraternali Pierro, Database Applications with Objects and

Rules, Addison Wesley Longman Limited, Edinburgh, England, 1997 [CARL00] Carlis John, Maguire Joseph, Mastering Data Modeling - A User-Driven

Approach, Addison – Wesley Publishing Company, USA, 2000 [CODD70] Codd Edgar F., Relational Model of Data for Large Shared Data Banks,

CACM, 1970 [CODD71] Codd Edgar F., Further Normalization of Data Base Relational Model of

Data, CACM, 1971 [DATE94] Date C.J., Relational Database – Writings 1991-1994, Addison Wesley

Publishing Company, 1995 [DATE95] Date C.J., An Introduction to Database, Addison Wesley Publishing Company,

1995

Bibliografie 593

[DATE98] Date C.J., Relational Database – Writings 1994-1997, Addison Wesley

Publishing Company, 1998 [DATE00] Date C.J., Darwen Hugh, Foundation for Future Database Systems, The Third

Manifesto, Second Edition, Addison Wesley Longman Inc., 2000 [DELO80] Delobel C., Litwin W. , Distributed Data Bases – Proceedings of the

International Symposium on Distributed Data Bases, North-Holland Publishing Company, Amsterdam, 1980

[DELO84] Delobel C., Adiba M., Bases de Donnees et Systemes Relationnelle,

Universite Grenoble, Dunod Informatique, 1984 [DELO91] Delobel C., Lecluse C., Richard P., Bases de Donnees des Systemes

Relationnelle aux Systemes a Objects, InterEditions, Paris, 1991 [DITT91] Dittrich K.R., Daya U. l, Buchmann A.P., On Object Oriented Database

Systems, Springer Verlag, 1991 [ELMA94] Elmasri Ramez, Navathe Shamkant B., Fundamentals of Database Systems,

Benjamin / Cummings Company, California, 1994 [ELMA99] Elmagarmid Ahmed, Rusinkiewicz Marek, Sheth Amit, Management of

Heterogeneous and Autonomous Database Systems, Morgan Kaufmann Publisher Inc., USA, California, 1999

[ERWG01] - ERwin – Getting Started, Computer Associates International, Inc., USA, 2001 [ERWM01] - ERwin – Methods Guide 4.0 , Computer Associates International, Inc., USA,

2001 [FORT97] – Fortier Paul J., Database Systems Handbook, McGraw-Hill Companies,

USA, 1997 [FREG77] Frege Gottlob, Scrieri Logico - Filozofice, Functie si Concept, pag. 235 – 271,

Despre Concept si Obiect, pag. 281-306, Editura Stiintifica si Enciclopedica, Bucuresti, 1977

[GOOS82] Goos G., Hartmanis J., Lectures Notes in Computer Science – Data Base

Design Techniques I, Requirments and Logical Structures, NYU Symposium, New York, 1982

[HALP01] Halpin Terry, Information Modeling and Relational Databases, Acadmic

Press, USA, 2001

Bibliografie 594

[HARR98] Harrington Jan L., Relational Database Design Clearly Explained, Academic Press, USA, 1998

[IICE-1] Mayer Richard J. & Team, Information Integration for Concurent Engineering

(IICE) – Process Description Capture Method Report, Knowledge Based Systems, Incorporated, Texas, 1995

[IDEF-4] Mayer Richard J. & Team, Information Integration for Concurent

Engineering (IICE) – IDEF4 Object-Oriented Design Method Report, Knowledge Based Systems, Incorporated, Texas, 1995

[IDEF-5] Mayer Richard J. & Team, Information Integration for Concurent

Engineering (IICE) – IDEF5 Ontology Description Capture Method Report, Knowledge Based Systems, Incorporated, Texas, 1995

[IDEF-9] Mayer Richard J. & Team, Information Integration for Concurent

Engineering (IICE) – IDEF9 Toward a Method for Business Constraint Discovery, Knowledge Based Systems, Incorporated, Texas, 1995

[IICE-2] Mayer Richard J. & Team, Information Integration for Concurent Engineering

(IICE) – Compendium of Methods Report, Knowledge Based Systems, Incorporated, Texas, 1995

[IDEF-1] Mayer Richard J. & Team, IDEF1 - Information Modeling , Knowledge Based

Systems, Incorporated, Texas, 1992 [IDEF92] Mayer Richard J. & Team, – Integration Definition for Information

Modeling , Knowledge Based Systems, Incorporated, Texas, 1992 [IDEF1X] National Institute of Standards and Technology, – Integration Definition for

Function Modeling (IDEF1X) – Draft Federal Information Standards Publication 183, Knowledge Based Systems, Incorporated, Texas, 1993

[IDEF-0] National Institute of Standards and Technology, – Integration Definition for

Function Modeling (IDEF0) – Draft Federal Information Standards Publication 183, Knowledge Based Systems, Incorporated, Texas, 1993

[IRIM82] Irimie Ioan, Continuturi ale Conceptului de Informatie, Simpozionul

Informatica si Conducere, Cluj-Napoca, 1982 [IRIM82] Gulutzan Peter, Peltzer Trudy, SQL – 99 Complete Really, An example-Based

Reference Manual of the New Standard , R&D Books Miller Freeman, Inc., USA, 1999

[JOUR75] Jourdon E., Structured Design, Yourdon Press, New York, 1975

Bibliografie 595

[KIMW89] Kim Won,Frederick Loschovsky, Object-Oriented Concepts, Databases and Applications, Addison Wesley Publishing Company, ACM Press, New York, 1989

[KINS80] Kinsley K.C. & Team, DBMS Feature Analysis, Technology Services

Company, Maryland, 1980 [KUMA98] Kumar Vijay, Hsu Meichun, Recovery Mechanisms in Database Systems,

Prentice Hall PTR, New Jersey, 1980 [LELU77] Lelutiu Alexandru , Proiectarea Sistemelor de Productie, Editura Dacia, Cluj-

Napoca, 1977 [LELU84] Lelutiu Alexandru , Proiectarea si Utilizarea Bazelor de Date în Limbajul

SOCRATE – Îndrumator de Lucrari, Universitatea Tehnica din Cluj-Napoca, 1984

[LELU97] Lelutiu Alexandru , Proiectarea Bazelor de Date Relationale – Îndrumator de

Lucrari de Laborator si de Proiectare, Editura Casa Cartii de Stiinta, Cluj-Napoca, 1997

[LELU94] Lelutiu Alexandru , Modelarea Relationala a Structurii de Descriere a

Mecanismelor, Referat de Doctorat, Universitatea Tehnica din Cluj-Napoca, 1994

[LEND80] Lendaris George, G., Structural Modeling – A tutorial Guide, IEEE

Transactions on Systems, Vol. SMC - 10, No 12, 1980 [MATT98] Mattison Rob, Understanding Database Management Systems – Second

Edition, McGraw-Hill Companies, Inc., USA, 1998 [MCGU99] McGuff, Kador John, Developing Analytical Database Applications,

Prentice-Hall PTR, Inc., USA, 1999 [MURC01] Murch Richard , Project Management – Best Practices for IT Professionals,

Prentice-Hall PTR, Inc., USA, 2001 [ONEI94] O’Neil Patrick , O’Neil Elizabeth, DATABASE - Principles, Programming and

Performance, Second Edition, Morgan Kaufmann Publishers, Academic Press, USA, 1994

[PAPA00] Papazoglou M., Spaccapietra S., Tari Zahir, Advances in Object-Oriented Data

Modeling , Massachusetts Institute of Technology, USA, 2000

Bibliografie 596

[PARS89] Parsaye Kamran, Chignell Mark, Khoshafian Setrag, Wong Harry, Intelligent Databases - Object Oriented, Deductive, Hypemedia Technologies, John Wiley & Sons, Inc., New York, 1989

[PIA00] Piatini Mario. Diaz Oscar, Advanced Database Technology and Design, Artech

House, Inc., Boston - London, 2000 [POET95] - Poet – Poet Software Corporated, USA, 1995 [RAMA98] – Ramakrishnan Raghu, Database Management Systems – WCB/McGraw-Hill

Companies, Inc., USA, 1998 [RATI00] - RATIONAL ROSE 2000e – Rose Extensibility User’s Guide, Rational Software

Corporation, Inc., USA, 2000 [SCHM83] Schmidt Joachim W. , Brodie Michael L., Relational Database Systems –

Ahalysis and Comparison, Springer Verlag, Berlin, Heidelberg, New York, 1983

[SHAV82] Shave M.J.R., Entities, Functions and Binary Relations – Steps to a Conceptual

Schema, CACI Inc-International, London, 1982 [SMAL86] - Smalltalk – User Guide, 1986 [SMIT82] Smith J.M., Smith D.C.P., Principles of DataBase Conceptual Design, ACM

Transaction on Database Systems, 1982 [SMIT77] Smith J.M., Smith D.C.P., Database Abstraction, Aggregation and

Generalization, ACM Transaction on Database Systems, 2(2), 105-133, 1997 [STIH99] Stihi Teodor, Introducere în Logica Simbolica, Editura BIC ALL, Bucuresti,

1999 [STON94] Stonebraker Michael, Readings in Database Systems, Morgan Kaufmann

Publisher Inc., San Mateo, California 1994 [STON99] Stonebraker Michael, Objektrelationale Datenbanken – Die naechste grosse

Welle, Uebersetzung Dobrowolski P., Carl Hanser Verlag Muenchen - Wien., 1999

[SUND75] Sundgren Bo, Theory of Data Bases, Petrocelli Charter, New York, 1975 [THAL00] Thalheim Bernhard , Entity – Relationship Modeling , Springer-Verlag, Berlin

Heidelberg, 2000 [TSIC82] Tsichritzis Dionysos C., Lochovsky Frederick , Data Models, Prentice-Hall, Inc.,

Englewood Cliffs, New Jersey, 1982

Bibliografie 597

[ULMA80] Ullman Jeffrey D., Principles of Database Systems, Computer Science Press,

Inc., USA, 1980 [ULMA89] Ullman Jeffrey D., Principles of Database and Knoledge-Base Systems,

Volume 1 & 2, Computer Science Press, Inc., USA, 1988-89 [VALD89] Valduriez Patrick, Gardarn Georges, Analysis and Comparison of Relational

Database Systems, Addison Wesley Publishing Company, New York, 1989 [VERM97] Vermeulen Robert, Upgrading Relational Databases with Objects – SIGS

Books, New York, 1997 [VOOS91] Vossen Gotfried, Data Models, Database Languages and Database

Management Systems – Addison Wesley Publishing Company, Workingham, England, 1991

[WEBE78] Weber Herber, Issues in Data Base Management – Proceedings of the Fourth

International Conference on Very Large Data Base, West Berlin, Germany, 1978

[WIEG99] Wiegers Karl E., Software Requirements, Microsoft Press, Washington, 1999 [WIRT71] Wirth N., Program Development by Stepwise Refinement , Communication of

ACM, Vol. 14, Nr. 4, 1971 [WIRT76] Wirth N., Algoriths + Data structures = Programs, Prentice Hall, 1976 [ZANI82] Zaniollo Carlo, Melkanoff Michel A., Relational Schemas for Database Systems,

Computer Science Department, University of California, Los Angeles, 1982 [ZDON90] Zdonik Stanley B., Maier David, Readings in Object-Oriented Database

Systems, Morgan Kaufmann Publisher Inc., USA, California, 1990 [YOSH90] Yoshifumi M., Object Identity, Equality and Relational Concept, Proceedings of

the International Conference on Deductive and Object Oriented Databases, North-Holland, 1990

Index de Termeni 598

Index de Termeni

A

Abordarea Sistemica a Proiectarii.......... 411 ABORT ...............................See ROLLBACK Abrial ........................................ 4, 23, 205, 589 Absorbtie ..................................................... 46 Abstractizare ............................................. 173 Acces............................................................. 72 Acces în Structuri Relationale ................ 231 Acces prin Inspectie................................. 237 Acces prin Selectie ................................... 237 Acoperire ................................ 45, 88, 164, 165 Acoperire Minimala ............................... 376 Acoperirea Dependentelor Functionale

................................................................. 376 Adaptabilitate.............................................. 72 Aditivitate ......................................... 373, 380 Agregarea de Domenii ............................ 311 Agregarea de Relatii ................................ 311 Agregarea Entitatilor............................... 327 Algebra Relationala .................................. 244 Alocarea...See Tehnici de proiectare a BDS Ameliorare................................................. 428 Ameliorarea Cererilor ........................... 428 Ansamblul de Entitati............................... 165 Ansamblul de Entitati Notiune ........... 166 Ansamblul de Entitati Obiect .............. 166 Ansambluri de Valori.............................. 162 Apartenenta................................................ 42 Aplicatie ....................................................... 59 Aplicatii Bijective ...................................... 59 Aplicatii Injective ...................................... 59 Aplicatii Surjective ................................... 59 Arbore .......................................................... 61 Arbore de Segmente................................. 213 Arbore Invers..................................... 63, 220 Arbore Invers cu mai multe Nivele ...... 87 Arbore Simplu........................................... 62 Arbore Simplu cu mai multe Nivele .... 87 Arbore Simplu cu un singur Nivel ....... 86 Arborele de Programare......................... 145 Arborele de Structura ............................... 106 Arborescenta .............................................. 87

Arhitectura Conventionala a Sistemelor de Programare ............................................. 548

Arhitectura Obiectuala a Sistemelor de Programare ............................................. 548

Arhitectura unui SGBDS ......................... 518 Arhitecturi Client - Server....................... 519 Arhiva Starilor de Referinta................ 465 Articol Principal ...................................... 216 Articole Fizice ........................................... 213 Ascendent al unui Vârf............................ 61 Asemanarea Elementelor ........................ 42 Ashby W. R. ............................................... 64 Asociativitate .............................................. 46 Aspectul Pragmatic al Informatiei........ 66 Aspectul Semantic al Informatiei.......... 67 Aspectul Sintactic al Informatiei........... 67 Atasarea Operatiilor la Structurile de

Date ........................................................ 212 Atomicitate ................See Proprietatile unei

Tranzactii Atomice Atomicitatea Relatiilor............................ 395 Atribut al unei relatii ............................. 370 Atribut Categorie .................................... 175 Atribut de Legatura............................... 296 Atribute ale unei relatii ......................... 369 Atribute în Ierarhia de Agregare

Categorii................................................. 181 Componente........................................... 181

Augmentare ...................................... 372, 380 Autonomia Unitatilor de Calcul ........ 512 Axiome de Baza ................................ 498, 501 Axiome de Completitudine..................... 501 Axiome de Unicitate ................................ 501 Axiome Deductive .................................... 498 Axiome Implicite ...................................... 501 Axiomele lui Armstrong ........................ 375

B

Baza de Date ............................................... 35 Baza de Date Deductiva ........................ 502 Baza de Date Distribuita................. 510, 518 Baza de Date Fizica ................................... 29 Baza de Date Logica.................................. 30 Baza de Date Obiectuala ............... 547, 573

Index de Termeni 599

Baza de Date Relationala .............. 227, 369 Baze de Date Deductive........................... 473 Baze de Date Evoluate............................. 472 Baze de Date Obiectuale .......................... 544 BDS ................. See Baza de Date Distribuita BDS cu Autonomie Locala .................... 532 BDS cu Replicare totala ......................... 525 BDS fara Autonomie Locala ................. 531 BDS fara Replicare.................................. 525 BEGIN_TRANSACTION .................... 444 Bloc ........................................ See Compozitia Blocare Nuantata...................See Blocarea

Resurselor Blocarea Aparenta a Tranzactiilor.......See

Blocarea Resurselor Blocarea Reala a Tranzactiilor............. 462 Blocarea Resurselor ............................... 458 Blocarea Simpla See Blocarea Resurselor Blocul SELECT ........................................ 270 Blocuri de Categorii ................................ 181 Bucla............................................................. 61

C

Calcul Aritmetic............See Materializarea datelor

Calcul Logic.......See Materializarea datelor Calculul Tuplelor.................................... 474 Calculul de Predicate ............................. 486 Calculul Domeniilor ........474. See Calculul

Relational Calculul Propozitional.............................. 474

Formule .................................................. 475 Reguli de Inferenta............................... 475 Termeni .................................................. 474

Calculul Relational ................................... 260 Calculul Relational al Domeniilor ......... 276 Calculul Relational al Tuplelor .............. 263 Calculul Tuplelor ..See Calculul Relational Cantitatea Elementara de Informatie ....... 66 Cantitatea Medie de Informatie ................ 66 Caracteristica................................... 151, 161 Caracteristici de descriere...................... 30 Caracteristicile de baza ale Multimii ....... 42 Cardinalitatea Intensiunii Relatiei.......... 370 Cardinalitatea Legaturii......................... 134 Cardinalitatea Legaturii ........... See Gradul

Legaturii

Cardinalitatea Subtuplei Logice a unei relatii ...................................................... 370

Cardinalitatea Tuplei Logice ............... 369 Cardinalitatea unei relatii .................... 370 Cardinalul Multimii Cât ......................... 55 Cardinalul Multimii de Tuple................. 236 CASE ...........See Computer-Aided Software

Engineering Catalogul Global al Sistemului ............. 520 Categorii Directe....................................... 192 Categorisirea Relatiilor........................... 296 Cereri ad-hoc ........................................... 545 Chei Candidate ........................................ 232 Chei de Acces............................................ 235 Chei de Identificare .................................. 232 Chei de Ordonare ...................................... 241 Chei Primare ............................................ 232 Chei Straine .............................................. 232 Cheie ........................................................... 182 Cheie Alternativa .......See Cheie Candidata Cheie Candidata...................... 230, 296, 374 Cheie de Inversare .................................... 90 Cheie de Legatura................................... 296 Cheie Interna ................See Cheie Surogata Cheie Neredondanta ............................... 230 Cheie Primara.......................... 230, 296, 374 Cheie Primara Aparenta ........................ 437 Cheie Primara Interna ............................ 437 Cheie Proprie ........................................... 230 Cheie Redondanta .................................. 230 Cheie Straina .................................... 230, 296 Cheie Surogata ................................ 230, 305 Circuit .......................................................... 61 Clasa........................................................... 565 Clasa de Ansambluri de Entitati ..... 167, 168 Clasa de Echivalenta ................................ 54 Clasa de Entitati ................................ 158, 159 Clasa de Entitati Membri........................ 164 Clasa de Entitati Obiect........................ 151 Clasa de Entitati Posesori....................... 164 Clasa de Instante atasata Conceptului 201 Clasa de Obiecte ............................. 550, 565 Clauza Horn ............................................. 490 Codomeniu al Relatiei . See - Domeniul de

Valori al Relatiei Colectii Mari de Date ............................. 212 Coloana .....................................See Atributul

Index de Termeni 600

Combinare de Elemente .......................... 47 COMMIT_TRANSACTION............... 444 Complementara unei multimi ................... 45 Complementaritate................................... 380 Completitudine de Calcul ..................... 545 Componente Directe................................. 193 Compozitia................................................ 138 Compozitie Generala............................... 380 Computer-Aided Software EngineeringSee

Programare Asistata de Calculator Comunicarea între Obiecte...................... 572 Comutativitate ........................................... 46 Concept ...................................................... 200

Definire Nesaturata .............................. 202 Definire Operationala .......................... 202 Definire Predicativa ............................. 202 Definire Structurala .............................. 202

Concept Derivat........................................ 200 Concept Primar ........................................ 200

Descriptor............................................... 200 Identificator ........................................... 200 Inlocuitor................................................ 200

Concepte Persistente .............................. 204 Conditia de Garda.................................... 537 Conditia de Proiectie a unei Relatii ....... 50 Conditii cu Membri ................................ 277 Consecventa.............................................. 486 Consecventa Logica................ 210, 476, 486 Conservarea Semantica......................... 376 Consistenta .........182. See Proprietatile unei

Tranzactii Atomice Consistenta a unei stari DBS k a BD ... 210 Consistenta Informationala ................. 368 Constante Skolem .................................... 488 Constituent de Cheie .............................. 230 Constrângeri ............................................ 114 Constructor al Nivelului Extern ............. 284 Constructor de Structura.......... 213, 216, 223 Context Unic ............................................. 213 Contexte Multiple..................................... 216 Continutul Conceptului ......................... 200 Control Acces ........................................... 545 Control Concurenta ............................... 545 Control Procedural al Consistentei....... 209 Controlul Accesului la Date .................. 433 Controlul Concurentei.............................. 458

Controlul Concurentei si al Securitatii................................................................. 540

Controlul Confidentialitatii de Acces la Date......................................................... 436

Controlul Drepturilor de Acces la Date 435 Copie de Referinta ...See Refacerea Bazelor

de Date Copie Distincta a Datelor ........................ 541 Copierea Profunda .................................. 569 Copierea Superficiala.............................. 569 Costul Transferului de Date .................. 532 Costurile de Prelucrare a Cererilor ........ 428 Criteriul de Autonomie ............................ 531 Criteriul de Omogenitate ......................... 531 Criteriul de Transparenta......................... 532 CRT .......See Calculul Relational al Tuplelor Cuantificare .............................................. 236 Cuantificator Existential ....................... 265 Cuantificator Universal ......................... 265 Cunostinte ................................................. 491 Cuplare .. See Reunire Natural. See Reunire Cuplarea Tabelelor..................................See Cuplu............................................................ 47 Cursor........................................................ 320

D

Data................................................... 64, 68, 70 Data Potentiala .................See Data Virtuala Data Reala................................................... 71 Data Virtuala .............................................. 71 Date Clasificate................................. 436, 484 Date de Tip Multime ............................... 358 Date Neclasificate ............................ 436, 484 Date Reale.................................................... 30 Date Secrete ....................................... 436, 484 Date Strict Secrete ............................ 436, 484 Date Virtuale .............................................. 30 Datele ca Stari ............................................ 70 Datele ca Stari Curente ........................... 71 Deducere .................................................... 476

Adoptarea unei noi Premize ................ 477 Inlantuirea Inainte.................................See Inlantuirea Inapoi.................................. 477 Reducerea la Absurd............................ 477 Rezolutia ................................................ 477

Deducere în Baze de Date ....................... 490 Deducerea de noi Fapte.......................... 492

Index de Termeni 601

Definire Extensionala a unei Relatii .... 49 Definire Formule .....See Limbaj Predicativ Definire Intensionala...................... 105, 107 Definire Intensionala a unei Relatii ..... 48 Dependenta ca Existenta........................ 135 Dependenta ca Identificare.................... 135 Dependenta de Reunire .......................... 407 Dependenta Functionala............... 371, 379 Dependenta Functionala Triviala...... 372 Dependenta Functionala Completa ... 373 Dependenta Functionala între doua

Multimi .................................................... 52 Dependenta Functionala Ireductibila ...See

Dependenta Functionala Completa Dependenta Functionala Minimala ... 372 Dependenta între Tranzactii .................. 451 Dependenta Ireductibila ........................... 372 Dependenta Multivalorica .................... 377 Dependenta Multivalorica Triviala ... 379 Dependenta Operationala ...................... 407 Dependente Directe ................................ 393 Dependente Functionale Minimale .... 376 Dependente Indirecte ............................. 394 Dependente Multivalorice ............... 377, 401 Dependente Multivalorice Netriviale... 403 Dependente Multivalorice Triviale....... 403 Dependente Tranzitive ..... See Dependente

Indirecte Derivare prin Definire

Definire prin Echivalenta .................... 203 Definire prin Generalizare .................. 203

Derivare prin Definire Definire prin Agregare......................... 202

Derivarea Conceptelor Derivare prin Transformare ................ 203

Derivarea Conceptelor .......................... 202 Derivare prin Definire .......................... 202

Descendent al unui Vârf.......................... 61 Descompunerea Cererilor........................ 537 Descrierea Formala a Limbajului

Predicativ............................................... 480 Descrierea Formala a Procedurilor ........ 143 Descrierea Ontologiilor ......................... 427 Descrierea Orientata a Intensiunii

Legaturilor ........................................... 105 Descriptori ................................................. 181 Determinant ..................................... 372, 397

Diagrama Bachman ......See Reprezentarea Simbolica

Diagrama Dependentelor Functionale... 384 Diagrama Entitati – Relatii...................... 110 Dictionarul Centralizat........................... 513 Dictionarul Distribuit ............................ 513 DIFERENTA ........................................... 249 Diferenta multimilor................................... 45 Diferenta simetrica a multimilor .............. 45 Distributivitate ......................................... 373 Domenii Comparabile............................ 315 Domenii Interpretate ............................... 315 Domeniu Primar ..................................... 230 Domeniul de Definitie al Relatiei .......... 49 Domeniul de Valori al Relatiei .............. 49 Domeniul Relatiei ............................. 49, 223 Drepturi Nuantate de Acces la Date .. 436 Drepturile de Acces la Date ................... 435 Drum Orientat ........................................... 61 Durabilitate ...............See Proprietatile unei

Tranzactii Atomice

E

ECD .....................See Expresie-de-Calcul-al-Domeniilor

Echivalenta......See - Relatii de Dependenta Echivalenta Elementelor.....................See o

Asemanarea Elementelor ECR......... See Expresie de Calcul Relational ECT.......See Expresie-de-Calcul-al-Tuplelor ECV..................See 4.1.1 Modelul Entitate –

Caracteristica – Valoare Element Atomic ....................................... 205 Elemente Agregate ................................. 206 Elemente Autoidentificabile.................. 206 Elemente Nedecompozabile................... 206 Elemente Autoidentificabile ................. 162 Eliminarea redondantei............................ 91 Eliminarea Redondantei............................. 91 Eliminarea Redondantei + Inversarea

Partiala ......................................................93 END_TRANSACTION ......................... 444 Engineering................................................ 208 Entitate........................................................ 346 Entitate........................................................ 157 Entitate – Caracteristica – Valoare ........ 156 Entitate Dependenta................................ 134

Index de Termeni 602

Entitate Independenta............................. 134 Entitate Notiune .............................. 151, 157 Entitate Obiect................................. 151, 157 Entropie Informationala ............................. 66 Enunturi Propozitionale ........................... 491 Etapele Normalizarii................................. 388 Evaluarea Formulelor............................... 485 Experimentul lui M. McKay ...................See Expresie de Calcul al Domeniilor ...... 263,

278, 279 Expresie de Calcul al Tuplelor ............ 263 Expresie de Calcul Relational............... 263 Expresii în CRT ......................................... 263 Expresiil în CRD.......See Expresii de Calcul

Relational al Domeniilor Extensiunea Relatiei ....................... 229, 370

F

Facilitati de Asertare.............................. 315 Facilitati de Declansare Proceduri

Amânata ................................................ 316 Imediata................................................. 316

Facilitati de Declansare Proceduri ..... 316 Fagin........................................................... 408 Fapte ........................................................... 491 Fapte Elementare..................................... 491 FBC..................See Formua Bine Construita Fidelitate Semantica............................... 368 Fidelitatea Descompunerii.................... 394 Filtrare ....................................................... 237 FIND........................................................... 220 Forma Clauzala........................................ 489 Forma Clauzala Generala .................... 489 Forma Clauzale........................................ 488 Forma Normala Prenex ........................ 482 Forma Normale Conjunctive................. 488 Forma Normale PRENEX ..................... 488 Formele de Transparenta ale unui

SGBDS ................................................... 511 Formula

Deschisa................................................. 482 Inchisa .................................................... 482

Formula Bine Construita.............. 264, 480 Formule Bine Construite ...................... 277 Fragment Vertical.................................... 524 Fragmentare ..See . Tehnici de proiectare a

BDS

Fragmentare Mixta ................................... 524 Fragmentare Orizontala ........................... 523 Fragmentare Verticala .............................. 524 Fragmentare Verticala Completa si

Disjuncta................................................ 524 Fragmente de Proceduri............................ 71 Functia de Acces Tranzactional la Date

................................................................... 32 Functia de asigurare a Accesului

Concurent la Date ................................. 32 Functia de asigurare a Integritatii Datelor

................................................................... 32 Functia de Control a Accesului la Date

................................................................... 32 Functia de Definire a Datelor .................. 32 Functia de Manipulare a Datelor ........... 32 Functia de Salvare / Restaurare a

Datelor ..................................................... 32 Functia de Utilizare a Datelor ................. 32 Functie ......................................................... 59 Functie Inversa......................................... 59 Functie Injectiva ....................................... 59 Functii ................................. 212, 276, 287, 472 Functii Skolem ......................................... 488 Functiile Obiectului Abstract.................. 185

Atribut .................................................... 185 Entitate.................................................... 185 Relatie ..................................................... 185

G

Generalizarea........................................... 174 Generalizarea Conceptului de Inversare .98 Generalizarea Entitatilor......................... 323 Gestiune Acces Fizic............................... 545 GET ............................................................ 220 GET NEXT ............................................... 215 GET UNIQUE ......................................... 215 Grade de Transparenta ........................... 511 Gradul de Confidentialitate al Atributelor

................................................................. 436 Gradul de Confidentialitate al Tuplelor436 Gradul de Consistenta............................. 177 Gradul de Omogenitate al unei Multimi 55 Gradul Legaturii .............................. 126, 134 Gradul Relatiei ........................................... 48 Gradul si Cardinalitatea Legaturii .... 134 Graf............................................................... 59

Index de Termeni 603

Graf de Precedenta a Tranzactiilor...... 457 Graf Neorientat ......................................... 61 Graf Tare Conex....................................... 61 Granularitatea Datelor......... See Controlul

Tranzactiilor

H

Header ...........................See Posesorul Listei

I

Identificare în Structuri Relationale ....... 231 Identificarea Externa a Obiectului......... 566

Identificarea prin Adresa..................... 566 Identificarea prin Index....................... 566

Identificarea Incompleta .......................... 194 Identificarea Interna a Obiectului.......... 566

Identificarea Explicita.......................... 566 Identificarea Implicita.......................... 567

Identificarea Obiectelor ........................ 513 Identificatori ............................................. 181 Identificatorul de Instanta .................... 201 Identificatorul de Realizare ................... 182 Identitate..................................................... 566 Identitatea Multimilor ................................ 43 Ierarhia de Agregare............................... 178 Ierarhia de Generalizare ........................ 178 Ierarhii de Clase...................................... 545 Ierarhii de Obiecte................................... 555 Ierarhii de Obiecte Abstracte .................. 178 Imagine Anterioara..............See Refacerea

Bazelor de Date Imagine Inversa Unica ............................. 59 Imagine Ulterioara .See Refacerea Bazelor

de Date Imagini Reciproce.................................... 184 IMPARTIRE............................................ 254 Implementarea Agregarii ......................... 311 Implementarea Generalizarii................... 311 Implicarea relatiilor .................................... 49 Imunitatea Fizica a Datelor ................... 31 Imunitatea Logica a Datelor .................. 32 Imunitatea Procedurilor ......................... 32 Incapsulare ............................................... 545 Inchiderea unei SuperChei ................... 375 Inchiderea Dependentelor Functionale

................................................................. 375

Incluziune de tip Arborescenta ............... 84 Incluziune de tip Retea ............................. 84 Incluziunea Multimilor .............................. 42 Inconsistenta ............................................. 215 Inconsistenta a unei stari DBS k a BD

................................................................. 210 Incorporare Dinamica........................... 545 Indecsi Pasivi ........................................... 238 Indecsi Activi............................................. 238 Indecsi Blocati.......................................... 239 Indecsi Clusterati ...........See Indecsi Blocati Indecsi Compusi ....................................... 239 Indecsi Conditionati ................................ 239 Indecsi Densi.......................................93, 239 Indecsi Individuali................................... 239 Indecsi Multipli ........................................ 239 Indecsi Neblocati...................................... 239 Indecsi Neclusterati..See Indecsi Neblocati Indecsi Neconditionati............................ 239 Indecsi Nedensi ..................................93, 239 Indecsi Neunici......................................... 239 Indecsi Simpli ........................................... 239 Indecsi Temporari.................................... 242 Indecsi Unici ............................................. 239 Independenta.............................................. 409

între Atribute ......................................... 410 între Date si Proceduri ......................... 409 între Datele Reale ................................. 409 între Nivelele de Reprezentare a Datelor

............................................................. 409 între Relatii ............................................ 410 între Tuple .............................................. 410 Relatiilor între Domenii fata de

Relatiile de Ordine........................... 410 Repezentarii Datelor fata de Suportul de

Memorare .......................................... 409 Independenta Datelor ...................... 35, 289 Independenta Elementelor de Structura

................................................................... 74 Independenta Entitatilor ...................... 134 Independenta Fizica a Datelor ............ 289 Independenta Functionala.................... 372 Independenta între Date si Proceduri . 32 Independenta Logica a Datelor ........... 289 Independenta Obiectelor.......................... 547 Independenta prin Incapsulare............. 558 Independenta Relatiilor ........................ 394

Index de Termeni 604

Independenta Tranzactiilor ................. 452 Indexarea .................. See Inversarea Partiala Individualitatea Elementului ...............See

Caracteristicile de baza ale Multimii Individualitatea Multimii .....................See

Caracteristicile de baza ale Multimii Informatie ....................................... 64, 65, 67 Instanta.............................................. 182, 550 Instanta de Concept................................. 201 Instanta Setului ........ See Setul de Articole Instantaneu .............................................. 321 Instructiune .............................................. 137 Insusire de Asociere ................................. 164 Integritatea de Identificare.................... 231 Integritatea de Referire .......................... 231 Integritatea Entitatii..... See Integritatea de

Identificare Integritatea Obiectelor Individuale ....... 190 Intensiunea Relatiei ........................ 229, 369 Intepretarea Formulelor ........................... 482 Interfata Fizica.......................................... 31 Interfata Logica......................................... 32 Interpretare si Model................................ 482 Intersectia multimilor................................. 45 INTERSECTIE ....................................... 248 Inversarea ...................................................98 Inversarea Partiala ...................................... 92 Inversarea Totala.........................................95 Izolare .......See Proprietatile unei Tranzactii

Atomice

J

Jurnalul Tranzactiilor ................... 447, 465

L

Langefors.................................................... 205 Latice............................................................. 46 Legatura Directa .See Descrierea Orientata

a Intensiunii Legaturilor Legatura Inversa .See Descrierea Orientata

a Intensiunii Legaturilor Legatura Recursiva ................................ 131 Legatura Relationala ............................. 296 Legaturi de Clasificare ........................... 135 Legaturi Identificatoare.......................... 136 Legaturi Neidentificatoare..................... 136

Legile Distributivitatii:............................ 474 Legile lui De Morgan:............................. 474 Limbaj Bidimensional............................. 280 Limbaj de Definire a Datelor................... 35 Limbaj de Descriere a Datelor .............. 30 Limbaj de Descriere Date ....................... 114 Limbaj de Manipulare a Datelor............ 35 Limbaj Logic ..................................... 260, 474 Limbaj Predicativ........................... 474, 480

Cuantificatori......................................... 482 Formula .................................................. 482 Interpretare............................................. 482 Matricea Formulei................................ 482 Model...................................................... 486 Model Minimal ..................................... 486 Regulile de Precedenta ........................ 480 Simbol de Constanta ............................ 482 Simbol de Functie n-ara ...................... 482 Simbol de Predicat ............................... 483 Termen.................................................... 480 Variabila ................................................. 482 Variabile ................................................. 482

Limbaj Unidimensional .......................... 280 Limbajul QBE ................................... 280, 474 Limbajul SQL.................................... 269, 474 LMD-uri Permisive .................................. 286 LMD-uri Restrictive ................................ 286 Lungime de Drum..................................... 61

M

Manipularea Structurilor Relationale. 243 Masura Gradului de Nedeterminare ......... 66 Materializarea Datelor..............30, 212. See Matrici Rare............................................... 356 Membrii Listei ......................................... 216 Mesaj ................................................ 550, 554 Metaclasa ................................................... 565 Metaclasa de Entitati ................................ 160 Metainstructiune Declarativa................ 476 Metoda ............................................. 550, 554 Metoda Bottom-Up.................................. 411 Metoda Mixta............................................ 411 Metoda Top-Down ................................... 411 Metode de Comportament ..................... 557 Metodologia de Proiectare în Modelul OA

................................................................. 191 Model de Date

Index de Termeni 605

Operatie .................................................. 212 Restrictii .................................................See Structura ................................................. 208

Model Fizic de Date................................... 81 Model Logic de Date.................................. 81 Model Strict de Date ................................ 291 Modele de Informatii................................ 151 Modele de Optimizare a Costurilor ... 514 Modele Heterogene ......... See Modele Vagi Modele Omogene ......... See Modele Stricte Modele Stricte .......................................... 206 Modele Vagi.............................................. 206 Model-Theoretic View..............See Viziunea

Interpretativa a BDD Modelul Conceptual ................................. 199 Modelul de Descriere a Datelor ............ 29 Modelul Entitate – Caracteristica –

Valoare ................................................... 151 Modelul Ierarhic ...................................... 213 Modelul Matematic al Informatiei......... 65 Modelul Obiectelor Abstracte......... 173, 425 Modelul Propozitional al Informatiei.... 67 Modelul Relational .................................. 223 Modelul Retea ........................................... 216 Modelul Semiotic al Informatiei............. 66 Modificari BD prin Extensie .................. 289 Modificari BD prin Incluziune .............. 289 Modificari BD prin Restructurare......... 289 ModificariBD prin Expansiune ............ 289 Modul Unic de Structura ...................... 313 Mostenire ................................................. 555 Mostenire Comportamentala......... 556, 560 Mostenire Multipla ................................... 563 Mostenire Simpla ...................................... 562 Mostenire Structurala ..................... 556, 557 Mostenirea între Obiecte ......................... 555 Multime de Ansambluri de Entitati

Obiect..................................................... 168 Multime de Entitati Obiect .................. 159 Multime de Valori Asociate ......... 377, 378 Multime Ordonata.................................... 55 Multimea............................................... 41, 44 Multimea de Instante ............................. 201 Multimea Cât ............................................. 55 Multimea Partilor....................................... 44 Multimea Partilor Nevide.......................... 44 Multimea Plina ........................................... 44

Multimea Totala .......................................... 43 Multimi Disjuncte....................................... 45

N

N-aritatea Legaturii................................. 135 Navigarea în Tabele................................ 318 Neproceduralitate ................................... 244 Nivel Intern................................................. 29 Nivel Logic .................................................. 69 Nivele de Abstractizare ........................... 29 Nivele de Definire a Operatiilor ............ 322 Nivelul .......................................................... 86 Nivelul Conceptual ................................... 29 Nivelul Extern .................................... 30, 284 Nivelul Fizic ................................................ 69 Nivelul Fizic / Logic de Descriere a

Datelor...................................................... 78 Nivelul unui Vârf ...................................... 61 Notiune ....................................................... 199 n-TUPLU..................................................... 47 Numele Conceptului ................................ 200

O

Obiect......................................................... 565 Obiect Abstract Autoidentificabil ......... 182 Obiect Abstract ............................... 173, 174 Obiect Abstract Agregat .......................... 177 Obiect Abstract Categorie .................... 175 Obiect Abstract de tip Rol....................... 194 Obiect Abstract Generic ....................... 175 Obiect Abstract Generice ........................ 174 Obiect Abstract Individuale................. 190 Obiect Abstract Primitiv ......................... 173 Obiect Primitiv........................................ 178 Obiecte Compuse .................................... 545 Observatorul în Modelul Semiotic ....... 66 Operatia de Clasificare ......................... 174 operatia de SEMIJOIN............................. 535 Operatie ..................................................... 137 Operatii...................................................... 114 Operatii Abstracte .......................... 173, 190 Operatii Abstracte de Utilizator ......... 190 Operatii Abstracte Primitive .......... 173, 190 Operatii Booleene pe Multimea Partilor

unei Multimi Totale................................ 45 Operatii Conflictuale............................... 450

Index de Termeni 606

Operatii de Specificare.......................... 321 Operatii de Actualizare ................. 275, 286 Operatii de Control................................... 138 Operatii de Memorare ........................... 269 Operatii de Regasire .............. 267, 270, 286 Operatii Neconflictuale........................... 450 Operatii Neprocedurale ........................... 321 Operatii Procedurale ................................ 318 Operatii Tranzactionale ........................ 449 Operatori Logico-Lingvistici ................. 263 Operatori Relationali................................ 244 Operatori Relationali Traditionali .......... 246 Operatori Specific Relationali.......250. See

Operatori Relationali Operatori Traditionali........... See Operatori

Relationali Optimalitate................................................. 72 Optimizarea Cererilor.....................514. See

Ameliorarea Cererilor Optimizarea Modelelor de Date ............. 367 Optimizarea Structurilor de Date ........... 367 Optionalitatea Legaturii ................. 126, 135 Ordinalul Multimii de Tuple................... 236 Ordine Cronologica................................. 241 Ordine Curenta ....................................... 236 Ordine de Inspectie a Tabelelor ......... 318 Ordine în Multimi ..................................... 47 Ordine Logica .......................................... 242 Ordine Naturala ...................................... 241 Ordonare Fizica ....................................... 241 Ordonare în Structuri Relationale .......... 231 Organizare .................................................... 72 Orientare pe Evenimente ...................... 212

P

Padure de Arbori ...................................... 61 Parcurgere Arbori în Endordine ............ 63 Parcurgere Arbori în Postordine .......... 63 Parcurgere Arbori în Preordine ............. 63 Partajare prin Mostenire........................ 558 Partitie ................................................... 45, 164 Partitionabilitate....................................... 380 Persistenta ................................................. 545 Plan Complet de Operatii

Tranzactionale ............................. 450, 454 Plan de Operatii Tranzactionale......... 449 Plan Nerestaurabil................................... 451

Plan Neserial ................See Plan de Operatii Tranzactionale

Plan Neserial Corect............... See - Planuri Neseriale Corecte

Plan Neserial Incorect ............ See - Planuri Neseriale

Plan Operativ de Executie...................... 514 Plan Restaurabil....................................... 451 Plan Serial .....................See Plan de Operatii

Tranzactionale Plan Serializabil . See Plan Neserial Corect Planurile de Descriere a Datelor............ 76 Plaurile de Operatii Tranzactionale

Stricte ..................................................... 451 Poliinstantiere .......................................... 439 Posesorul Listei........................................ 216 PostConditii.............................................. 555 Pozitia Curenta în Tabele .................... 318 PreConditii ............................................... 555 Predecesor al unui Vârf .......................... 61 Predicat ...................................................... 480 Prelucrare Tranzactionala........... 212, 440 Preordine .........See Traversarea Arborilor Principiul Conservarii Semantice........... 190 Procedura............................................ 70, 137 Proceduralitate ........................................ 244 Proceduri Stocate...................................... 212 Procedurile ca Stari Viitoare ................. 71 Procedurile ca Transformari ................... 70 Proces de Abstractizare ............................ 173 Proces de Engineering ....................109. See

Transformare Directa Proces de Engineering al unui Model de

Date........................................................... 79 Proces de Reengineering ........................See

Transformare Inversa Proces de Reengineering al unui Model de

Date........................................................... 79 Procesarea Cererilor în BDS................ 532 Produs Cartezian .................................... 250 Produs Cartezian a doua relatii .......... 371 Produs Cartezian de multimi..................... 48 Programare Asistata de Calculator....... 409 Proiectabilitate ......................................... 373 Proiectabilitate Inversa ......................... 373 Proiectare Conceptuala ......................... 173 Proiectia Conditionata ............................. 50

Index de Termeni 607

Proiectia Neconditionata......................... 50 Proiectia relatiilor ..................................... 50 Proiectia Relatiilor.............................. 50, 370 Proiectibilitate........................................... 380 PROIECTIE............................................. 251 Proof-Theoretic View ...............See Viziunea

Inferentiala a BDD Proprietate de Recursivitate ...................... 63 Proprietati

Echivalente.............................................. 44 Restrictive................................................ 44 Straine ...................................................... 44

Proprietati de Descriere ......................... 557 Proprietatile Arborilor Simpli................... 62 Proprietatile Conceptului ....................... 200 Proprietatile Dependentelor Functionale

................................................................. 372 Proprietatile Relatiei................................. 227 Proprietatile unei Tranzactii Atomice ... 448 Propritatile Relatiilor Binare ..................... 51 Protocoale pentru Gestiunea

Tranzactiilor ........................................ 514 Pseudo – Cod............................................ 144 Pseudo-Tranzitivitate .................... 373, 380 Puterea Carteziana................................... 48

Q

Query By Example.................................. 321

R

Rangul Proiectiei unei Relatii................. 50 Realizare a Obiectului Abstract Agregat

................................................................. 183 Realizare a Obiectului Abstract

Categorie ............................................... 175 Realizare de Componenta ....................... 182 Realizari de Obiecte Abstracte............... 181 REDO......................................................... 445 Redondanta ....................................... 182, 215 Redondanta Aparenta de Identificatori. 74 Redondanta de Descriptori................. 73, 74 Reengineering............................................ 208 Refacere la Rece See Refacerea Bazelor de

Date Refacerea Bazei de Date.................. 450, 464 Refacerea Bazelor de Date..................... 469

Reflexivitate ...................................... 372, 379 Refrazarea Cererilor..........See Ameliorarea

Cererilor Regrupare de Elemente...................... 43, 47 Reguli de Fundamentare ......................... 361 Reguli de Independenta a Datelor......... 365 Reguli de Integritate ................................ 363 Reguli de Manipulare a Datelor ............ 364 Reguli de Precedenta............................... 480 Reguli Generice ........................................ 209 Reguli Structurale .................................... 362 Regulile de Inferenta ale lui Armstrong

......................See Axiomele lui Armstrong Relatia.................................................. 59, 224 Relatii Asimetrice ....................................... 53 Relatii Binare.............................................. 51 Relatii Binare Functionale ......................... 52 Relatii binare pe aceeasi multime ............ 52 Relatii Binare pe Doua Multimi Distincte

................................................................... 51 Relatii Biunice............................................. 52 Relatii Complementare .............................. 51 Relatii Conexe ............................................. 54 Relatii de Asemanare ..............See Relatii de

Similitudine Relatii de Asociere.................................... 164 Relatii de Bine Ordonare ........................... 58 Relatii de Dependenta.............................. 68 Relatii de Echivalenta .......................... 54, 84 Relatii de Identitate .................................. 69 Relatii de Incluziune ........... See - Relatii de

Dependenta Relatii de Incluziune ................................. 84 Relatii de Ordine ................................. 55, 227 Relatii de Ordine Naturala..................... 69 Relatii de Ordine Partiala .......................... 56 Relatii de Ordine Partiala ......................... 84 Relatii de Ordine Totala ............................. 57 Relatii de Similitudine .............................See Relatii de tip Entitate................................ 300 Relatii de tip Legatura .............................. 303 Relatii de tip Mixt ..................................... 307 Relatii Derivate......................................... 299 Relatii Directe ........................................... 165 Relatii Identice ............................................ 53 Relatii între Multimi ................................... 47 Relatii Inverse...................................... 51, 165

Index de Termeni 608

Relatii n-are ................................................ 48 Relatii Nereflexive...................................... 53 Relatii Normala BCNF.......................... 397 Relatii Normala de Grad 1 ................... 389 Relatii Normala de Grad 2 ................... 391 Relatii Normala de Grad 3 ................... 393 Relatii Normala de Grad 4 ................... 403 Relatii Normala PJNF ........................... 407 Relatii Normale de Grad 5 ...................... 403 Relatii Normale RN4 .............................. 379 Relatii Normalizate BCNF.................... 376 Relatii Normalizate BCNF ...................... 376 Relatii Primare ......................................... 299 Relatii Reflexive ......................................... 53 Relatii Simetrice.......................................... 53 Relatii Totale ............................................... 53 Relatii Tranzitive ........................................ 54 Relatii Unice la Dreapta............................. 52 Relatii Unice la Stânga............................... 51 Relatii Virtuale ......................................... 284 Relatiile de tip Entitate Completa .......... 300 Relatiile de tip Entitate Incompleta ....... 301 Relatiile de tip Legatura Completa ........ 306 Relatiile de tip Legatura Simpla ............. 303 Reorganizare............................................... 72 Reorganizarea Cererilor........................... 429 Reorganizarea Structurii ............................97 Repetitia .................................................... 140 Repetitia Nenula...................................... 140 Repetitia Posibil Nula............................ 140 Repetitie Fixa ............................................ 143 Repetitie Variabila ................................. 143 Repetitivitatea Legaturii........................ 126 Replicarea ...513. See Tehnici de proiectare

a BDS Reprezentant al Clasei de Echivalenta 55 Reprezentarea Clasica ...See Reprezentarea

Fizica Reprezentarea Fizica ................................ 100 Reprezentarea Logica............................... 102 Resortarea Fizica ..................................... 242 Restaurarea Datelor .............See Refacerea

Bazelor de Date Restrictie

Dinamica ................................................ 210 Invalida...................................................See Statica ..................................................... 210

Restrictie Bine Formata ......................................... 210 Consistenta............................................. 210 Proprietati detaliate .............................. 210 Proprietati sintetice............................... 210 Realista................................................... 210 Realizabila ............................................. 210 Realizata................................................. 210

Restrictii .................................................... 114 Restrictii de Domeniu............................... 209 Restrictii de Identificare .......................... 209 Restrictii de Identitate ........................... 114 Restrictii de Referire...................... 114, 209 Restrictii Explicite............................ 209, 315 Restrictii Implicite............................ 209, 314 Restrictii între Relatii.............................. 395 Restrictii Logice........................................ 209 Restrictiile Obiectelor ........................... 555 Resurse cu Granularitate Ridicata.......See

Granularitatea Datelor Resurse cu Granularitate Scazuta........See

Granularitatea Datelor Reteaua ................................................ 87, 220 Reunire ...................................................... 252 Reunire EGALA ..................................... 253 Reunire EXTERNA

COMPLETA ......................................... 253 DREAPTA ............................................. 253 STANGA ............................................... 253

Reunire MAI MARE ............................. 253 Reunire MAI MICA............................... 253 Reunire NATURALA ............................ 253 Reunire Naturala .................................... 371 Reunire POSIBILA ................................ 253 REUNIUNE .............................................. 246 Reuniunea Disjuncta a Multimilor........... 48 Reuniunea Multimilor................................ 45 ROLLBACK ............................................ 445 Roluri Abstracte See Obiecte Abstracte de

tip Rol

S

Salvarea Datelor ..............See 6.3 Refacerea Bazelor de Date

SBD..................See Sistem cu Baza de Date SBD Deductive Mixte .............................. 504 SBD Deductiv-Generative....................... 507

Index de Termeni 609

SBD Pur Deductive .................................. 502 SBDD bazat pe Informatii Elementare si

Proprietati Generale............................ 505 SBDD bazat pe Intrebari si Raspunsuri

................................................................. 502 SBDD bazat pe Vederi Generate........... 507 Schema de Descriere ............................... 114 Schema Buna pentru o BD..................... 210 Schema inconsistenta a unei BD........... 210 Schema realizabila a unei BD ............. 210 Schema satisfacuta a unei stari DBS k 210 Securitatea Bazelor de Date .................... 433 Securitatea Datelor ................................. 545 Securitatea Distribuita.............................. 543 Secventa ................................See Compozitia Segment Ascendent .................................. 213 Segment de Articol................................... 213 Selectia....................................................... 138 Selectia Imediata...................................... 141 Selectia Multipla ...................................... 139 Selectia Simpla ......................................... 139 SELECTIE ............................................... 250 Semnul în Modelul Semiotic .................. 66 Sensul în Modelul Semiotic .................... 66 Serializarea Tranzactiilor......................... 452 Set Complet de Operatori Relationali ... 256 Setul de Articole ...................................... 216 Sfera Conceptului ................................... 201 SGBD.See Sistem de Gestiune a Bazelor de

Date SGBD Complet Relational .................... 260 SGBD Semirelational ............................. 260 Simbolica............See Reprezentarea Logica Sintaxa Abstracta...................................... 188 Sistem Complet de Evenimente ............... 65 Sistem cu Baza de Date.............................. 18 Sistem de Aplicatii .................................... 18 Sistem de Gestiune a Bazelor de Date ... 18,

32 Sisteme Informatii Elementare - Proprietati

Generale ................................................. 505 Sisteme Intrebari – Raspunsuri............... 509 Sistemul R .................................................. 269 Snippets............See Fragmente de Proceduri Sortarea Fizica ......................................... 241 Spatiul Calculatorului..See Spatiul Datelor Spatiul Datelor.................................... 79, 154

Spatiul Informatiilor .................. 69, 79, 151 Spatiul Problemei .......................See Spatiul

Informatiilor Spatiului Datelor ....................................... 69 Specializarea ............................................. 175 Stare Activa .....See Stari ale unei Tranzactii Stare Esuata ....See Stari ale unei Tranzactii Stare Executata ................ See Stari ale unei

Tranzactii Stare Partial Executata .. See Stari ale unei

Tranzactii Stare Terminata ............... See Stari ale unei

Tranzactii Stari Permise ............................................ 315 Starile unei Tranzactii ...................... 444, 446 Stergere Fizica ......................................... 235 Stergere Logica........................................ 235 Strategie de Acces la Segmente............. 215 Strategii de Acces..................................... 236 Strategii Generale de Optimizare ....... 431 Structura................................................... 114 Structura ....................................................... 72 Structura Contextuala............................... 73 Structura de Ansamblu............................. 115 Structura de tip Acoperire ..................... 353 Structura de tip Partitie .......................... 353 Structura Fizica de Date............................. 76 Structura Fundamentala m – n .............. 216 Structura Inghetata ................................... 73 Structura Logica de Date ........................... 76 Structura Necontextuala .......................... 73 Structura Recursiva................................... 63 Structura Reorganizabila......................... 73 Structuri 1 - n ............................................ 327 Structuri de Date Contextuale............... 213 Structuri de Proceduri .............................. 137 Structuri de tip Partitie............See Structuri

Fundamentale de tip 1-n Structuri Dedicate .................................... 73 Structuri Fundamentale ........................ 82, 89 Structuri Generale .................................... 73 Structuri Ierarhice .................................... 344 Structuri m - n........................................... 328 Structuri Matriciale ................................... 356 Structuri Partiale ....................................... 118 Structuri Principale.................................. 90 Structuri Secundare ................................. 90

Index de Termeni 610

Structurilor Fundamentale de tip 1-n . 213 Subarbore al unui Arbore ...................... 61 Subclase de Obiecte ................................ 555 Subentitate.................................................. 348 Submultimi Parti ........................................ 44 Substitutia ................................................. 141 Subtipuri de Entitati................................ 135 Subtupla Fizica a unei relatii ............... 370 Subtupla Logica a unei relatii ............. 370 Succesor al unui Vârf............................... 61 SuperCheie ............................................... 374 Supertipuri de Entitati ............................ 135 Supraclase de Obiecte ........................... 555

T

Tabel ..............................................See Relatia Tabela de Baza Curenta ........................ 235 Tabela Virtuala ....................................... 284 Tehnica Alegerii Dinamice a

Coordonatorului.................................... 542 Tehnica bazata pe Actualizarea Amânata

................................................................. 469 Tehnica bazata pe Actualizarea Imediata

................................................................. 470 Tehnica Copiei Primare ........................... 542 Tehnica de Alocare ................................... 525 Tehnica de Fragmentare .......................... 521 Tehnica de Replicare ................................ 525 Tehnica Statiei Primare ............................ 541 Tehnica Statiei Primare cu Statie de

Salvare .................................................... 542 Tehnici de proiectare a BDS................... 520 Tehnici de Refacere .................................. 468 Tehnici de Refacere a Bazelor de Date468

Actualizarea Amânata.......................... 468 Actualizarea Imediata .......................... 468

Teorie ......................................................... 487 Teorie Abstracta....................................... 487 Teorie Completa...................................... 487 Teorie Interpretata................................... 487 Teorie Valida ............................................ 487 Testul de Egalitate ................................... 567 Testul de Identitate .................................. 567 Tip Abstract de Data............................. 550 Tip General de Structura Relationala .... 313 Tipul Setului .............. See Setul de Articole Tipuri Suplimentare de Legaturi ...... 135

Tipuri de Baze de Date Distribuite ........ 531 Tipuri de Date Utilizator ...................... 545 Tipuri de Legaturi Relationale ................ 297 Tipuri de Modele de Date........................ 205 Tipuri de Relatii ........................................ 299 Tipuri de Relatii Binare pe Aceeasi

Multime .................................................... 54 Tipuri de Relatii de Ordine .................... 56 Tipuri de Structuri Fundamentale....... 82 Tipuri de Structuri Relationale ............... 296 Tipuri de transformari ................................ 90 Token .........................................See Instanta) Transformare Directa ............................ 109 Transformare Inversa ........................... 109 Transformarea Structurilor

Fundamentale ........................................ 90 Transformari de Concepte ................... 202 Transparenta de Avarie ....See Formele de

Transparenta ale unui SGBDS Transparenta de Fragmentare ..............See

Formele de Transparenta ale unui SGBDS

Transparenta de Localizare ..See Formele de Transparenta ale unui SGBDS

Transparenta de Tranzactie.. See Formele de Transparenta ale unui SGBDS

Tranzactie Atomica .................................. 448 Tranzactie Dependenta Corecta............ 451 Tranzactii Interetesute ............................ 452 Tranzactii Necontrolate............................ 441 Tranzactiile Serializate .......................... 452 Tranzitii Permise ..................................... 316 Tranzitivitate ................................... 373, 380 Tranzitivitate Restrânsa .......................... 380 Tratarea Produselor Carteziene .............. 429 Tratarea Reunirilor................................... 431 Traversarea Arborilor....................... 63, 213 Trrigeri ......212. See Facilitati de Declansare

Proceduri Tupla .......................................................... 224

Fizica .............................................. 224, 370 Logica ............................................. 224, 369

Tupla Curenta ......................................... 236 Tuple Logice disjuncte .......................... 371

U

Ullman Jeffrey D. ...................................... 29

Index de Termeni 611

UNDO......................................................... 445 Unificarea Obiectelor.............................. 567 Unitatea Elementelor ............................... 42 Utilizatori care Instantiaza .................... 558 Utilizatori care Mostenesc...................... 558

V

Validarea Faptelor Elementare ............ 492 Valoare ........................................................ 162 Valoare de Atribut .......................... 152, 370 Valoare de Categorie ............................. 176 Valori Izonime ......................................... 163 Valori Izotipe ........................................... 163 Vârf Terminal ............................................ 61 Vârfuri Adiacente ..................................... 61 Variabila

Legata ....................... 35, 264, 482, 485, 500 Libera .............................................. 264, 482

Variabila Cuantificata ............................. 264 Variabila Cuantificata Existential ....... 265 Variabila Cuantificata Universal ......... 265 Variabila de Instanta............................... 558 Variabila de Tupla.................................. 263 Variabila Necuantificata ......................... 264 Variabila Privata ...................................... 558 Variabila Publica ..................................... 558 Variabila Vizibila ..................................... 558 Vedere Actualizabila................................ 287 Vederea....................................................... 284 Viziune Structuralista ............................... 71 Viziunea Inferentiala a BDD ....... 473, 497,

498, 501 Viziunea Interpretativa a BDD ... 473, 497

Z

Zona de Lucru Curenta ........................ 235

612

Editat în 15.10.2002 la: Tiparit în 15.10.2002 la:

Casa de Soft EXPERT Cluj Casa CARTII de STIINTA SRL SRL Piata Cipariu 9 / 45 RC J12/493/1994 Str. Agricultorilor 20 / 26 RC J12/493/1994 3400 Cluj - Napoca Cod fiscal R5272847 3400 Cluj - Napoca Cod fiscal R253640 Tel. 064-190651 BRD filiala Cluj Tel. 064-143800 Banca Dacia Felix Cluj cont # 251100996219602 Fax 064-162151 cont # 4101017702805 Fondator : Dr. Ing. Alexandru Lelutiu Fondator : Dr. Tudor Codreanu Director tehnic : Ing. Marilena Fertea Director : Ing. Mircea Trifu