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 tarm ce depaseste Tehnica si Ingineria, patrunznd 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 dect a lua cunostinta de el, ci gndindu-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 gndit? 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 gndirea sa imaginea prietenului caruia i apartine acea lira. Si aceasta e o reminiscenta ca si atunci cnd vazndu-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 cnd e vorba de lucruri pe care timpul sau neatentia ne-a facut sa le uitam? SIMMIAS Sigur ca da. SOCRATE Dar, vaznd un cal sau o lira, nu pot oare sa-mi amintesc de un om, si vaznd portretul lui Simias sa-mi amintesc de Kebes? SIMMIAS Desigur. SOCRATE Si vaznd 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 o o o o Informatie - Data n conceperea, proiectarea si prelucrarea Structurilor Semantic Sintactic n reprezentarea continutului si formei Informatiei Nume Valoare n reprezentarea Structurile de Date si Informatii Plan Logic Fizic n descrierea Structurilor de Date si Informatii 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, deschiznd 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 c e permite generarea mai multor instante de Baze de Date adaptate resurselor disponibile, apelnd 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 cnd 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 I ubitor de Oameni, transmitea semenilor de atunci si de mai apoi mesajul, purtat din gura-n gura, ca Viata nu e un pret prea mare cnd 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

PREFATA

B.P. Hasdeu

Timpul este Judecatorul nenduplecat 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 cnd se analizeaza aportul lor n domeniul prelucrarii automate a informatiilor si datelor, dar mai ales cnd 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, pastrndu-si personalitatea p domeniul de rin preocupari, devenind tot mai prietenoase cu utilizatorii prin accesibilitatea conceptelor implementate. Tinta acestor sisteme a ramas permanent construirea unei viziuni ct mai unitare si ct 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, deschiznd orientarea spre organizarea obiectuala etc. Multe din facilitatile dezvoltate au usurat ntr-att utilizarea produselor comerciale care abunda piata informatica, nct a creat falsa impresie ca oricine se pricepe la Baze de Date, ca odata nsusite cteva cunostinte de operare, proiectarea SBD e la ndemna oricui. De aici s-a nascut si mentalitatea multor beneficiari ca achizitia unor asemenea aplicatii trebuie sa fie gratuita, neglijnd urmarile pe care diletantismul n proiectare le aduce mai devreme sau mai trziu, cnd de fapt totul trebuie reproiectat si de obicei abia acum se realizeaza faptul ca aceasta costa. Un alt pericol consta n faptul ca pna 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 cnd nu sunt nca suficient definite, mai ales n ceea ce priveste raportul lor cu sistemele traditionale, pe care refuza sa le nteleaga considerndu-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

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 nct 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 att Structurile de Date ct 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 o o o o o De ce Sistemele cu Baze de Date sunt nca n voga? Este conceptul de Independenta asociat cu SBD? Este Modelul Relational perisat? Model Relational sau Obiectual? Simplitatea Tabelei mai poate ascunde secrete? 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 binenteles 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 cuvntul meu de multumire pentru spijinul acordat cu generozitate si pasiune. Daca acest sprijin a fost cu adevarat folosit va putea hotar desigur numai cititorul. Exista ntre cei apropiati o categorie aparte pentru care cuvntul meu de multumire e de prisos, caci au alergat prea aproape de mine, ducndu-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 mpartasit singuratatea, asteptndu-ma. Autorul

Prefata
Cluj Napoca, septembrie 2002

Prefata

C U P R I N S
PREFATA .................................................................................................................................................. 5
1 Introducere......................................................................................................................................17 1.1 1.2 1.3 2 Importanta Sistemelor cu Baze de Date .........................................................................17 Aportul Sistemelor cu Baze de Date ...............................................................................19 Continutul Lucrarii .............................................................................................................21

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 2.3 2.4 Definitia Bazelor de Date ...................................................................................................36 Avantajele utilizarii Bazelor de Date ..............................................................................37 Exemple de Baze de Date ...................................................................................................38

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

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 3.5.3 3.5.4 3.5.5 3.5.6 4

Substitutia..................................................................................................................142 Elementele Structurilor de Proceduri........................................................................142 Descrierea Formala a Procedurilor............................................................................144 Descrierea n Pseudo - Cod ........................................................................................145 Arborele de Programare ..............................................................................................146

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 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 6.2.8 6.2.9 6.2.10

Tipurile de ntreruperi ale unei Tranzactii...............................................................446 Starile unei Tranzactii .................................................................................................447 Jurnalizarea Tranzactiilor ...........................................................................................450 Proprietatile unei Tranzactii Atomice.......................................................................451 Planul de Operatii Tranzactionale .............................................................................452 Proprietatile Tranzactiilor n Refacerea Bazei de Date .........................................453 Serializarea Tranzactiilor............................................................................................455 Controlul Concurentei.................................................................................................461 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 Amnata............................................................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 9 Scurt Istoric al Evolutiei SBD...................................................................................................582 Principalele Surse de Informare...............................................................................................583

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

16

Importanta Sistemelor cu Baze de Date

PARTEA 1 -a

INTRODUCERE

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 avnd 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 gndita ca o Monografie de Concepte, promovate ntr-un domeniu deosebit de peren.

Importanta Sistemelor cu Baze de Date

17

1
1.1

Introducere
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 ntruct, orict 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 ramna 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 dect sistemele de Restrictii ale Bazelor de Date? Ce Sistem de Constrngeri nu devine mai puternic cnd e implementat n centrul nucleului de informatii ca si Constrngeri Intrinseci? Ce Dependente ntre informatii ramn 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 strni 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 o o o o o o o

Importanta Sistemelor cu Baze de Date

Sistemele Informatice pentru Conducere privite ca Sisteme cu Baze de Date Bazele de Date din Sistemele de Programare Logica Bazele de Date pentru Prelucrarea Textelor si Metatextelor Bazele de Date Grafice pentru Proiectarea Asisteta de Calculator (CAD) Bazele de Date din Sistemele Informatice Geografice (GIS) Bazele de Date Orientate Obiectual 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). SGBDurile pot fi ntlnite ntre primele trei produse Software cerute, vndute si utilizate pe piata informatica. Rasfoiti la ntmplare 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 nvatamnt 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 rnd 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 avnd n centru o Colectie Structurata de Date de volum mare a carui continut e gestionat n mod direct de un SGBD, dar care pe lnga 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 cuvnt. Observatie Organizarea datelor ntr-o Baza de Date a adus, cu scurgerea timpului, n afara rezultatelor directe, si un cstig 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 att n zona constienta, ct 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 obtinnd 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.

+
Miscare Browniana

Retea Circulara Miscare Centrifuga

+
Miscare Browniana Retea Reticulara

Miscare Circulara

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 ramn 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.

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 att 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, apelndu-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 cteva 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 raspndite 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, ct 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, att 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 trziu 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 ntruct ea evita confuziile ntrun 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 adnceasca 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, att 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 cte ori se face o trecere n revista a constructorilor de structuri, punndu-se accentul cuvenit asupra faptului ca orice Model de Date este atunci stapnit cnd 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 ntlnite n literatura de specialitate (cu exceptia Arborelui de Structura a Datelor) interpretarea exemplelor foarte numeroase din lucrare va ntmpina dificultati. Aplicarea conceptelor cu care s-a nceput sectiunea continua cu transpunerea lor n slujba disciplinarii gndirii 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, ntruct 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), att 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. Cnd s-a reusit aceasta concentrare, reprezentarea cstiga 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 att a problemelor conceptuale, desfasurate n Spatiul Informatiilor, ct 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 nenlocuit 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, ncercnduse o marcare a acumularilor realizate pe linia descrierii structurale. ntruct atentia ramne 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 Constrngerilor, 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, rezervnd 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 cnd 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, D urabilitate). 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 strnsa 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 att sub aspectul evitarii redondantei, ct 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 rnd prin sublinirea structurii obiectuale ca forma de asigurare maxima a Independentei elementelor sale, fie ele Date sau Proceduri. In al doilea rnd 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.) utiliznd Tehnologia Obiectelor Active.

Continutul Lucrarii

27

PARTEA a 2 -a

SISTEME cu BAZE de DATE

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, consolidndu-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

Sisteme cu Baze de Date

Ca orice concept care si-a cstigat 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 pna 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 atta 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 tarmul 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 incluznd milioane de date care se cereau memorate, actualizate, regasite, calculate si transmise cu ajutorul dispozitivelor automate de calcul (calculatoare si retele de interconectare) sub aspect calitativ ca o crestere a complexitatii structurii datelor prelucrate att n ceea ce privea relatiile descrise ntre date, ct si a distribuirii datelor, puternic legate prin intercorelare, pe diferitele medii de stocare Prima etapa Separarea Numelor de Valorile datelor A doua etapa Cresterea Complexitatii datelor prelucrate A treia etapa - Separarea Datelor de Proceduri

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

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

Un nivel Abstract de descriere descriere cu ajutorul Numelor numit nivel Logic de descriere (descriere de Notiune) Gruparea (separarea) descrierii datelor ntr-o sectiune specializata numita Dictionarul datelor Definirea sistematica a Tipurilor de Date (prin generalizarea Datelor de acelasi Tip) Asocierea Restrictiilor impuse la Datele de acelasi Tip Asocierea Operatiilor adecvate diverselor Tipuri de Date

Prezenta nivelului abstract de descriere a datelor va facilita: o o o o

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, pna la date de tip nregistrare, tablouri de nregistrari, liste, arbori, stive, cozi, indecsi etc. Atunci cnd 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, att n definirea initiala a acestora prin actualizarea nivelului logic de descriere a datelor, ct 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. 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

o o

Retea Relational Nume Tipuri Limite de Valori

Setul de Caracteristici de descriere:

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 O multime de Vederi incluznd parti din datele descrise n Baza de Date Logica si memorate n Baza de Date Fizica 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 o Data Nasterii e memorata ntr-o Data Reala cu numele DN Daca Vrsta, 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 cte ori o Data poate fi exprimata ca fiind dependenta de alte date memorate n sistem, consistenta ansamblului de date nu poate fi mentinuta dect prin recalcularea automata a valorii dependente n functie de valorile momentane ale valorilor independente (argumentele functiei de calcul). n exemplul nostru Vrsta (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

U1 U2 vedere 1 U3 U4 U5 vedere 3 U6

vedere 2 BAZA de DATE LOGICA BAZA de DATE FIZICA

U7

vedere n

Un

nivel EXTERN

nivel CONCEPTUAL (LOGIC)

nivel INTERN (FIZIC)

INTERFATA LOGICA

INTERFATA FIZICA

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

Nivele de Abstractizare ntr-un SBD

33

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. Cnd trebuie sa se verifice fara ntrziere 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 o Functia de Definire a Datelor care asigura declararea elementelor care compun Structura de Date precum si a Relatiilor existente ntre ele Functia de Manipulare a Datelor care regrupeaza Operatiile de Intrare / Iesire, care asigura Adaugarea, Stergerea si Modificarea Valorilor Datelor memorate n Baza de Date 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 (cmpuri, tabele, fisiere, domenii, operatii de actualizare) Functia de asigurare a Integritatii Datelor care ofera posibilitatea de declarare a Restrictiilor impuse structurii de date (Unicitate, Referire, Compatibilitate etc.) Functia de asigurare a Accesului Concurent la Date care grupeaza operatiile de Blocare / Deblocare a accesului simultan la date Functia de Salvare / Restaurare a Datelor ce asigura crearea si folosirea Copiilor de Securitate n caz de incidente 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

o o o o

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 ct aceste elemente sunt mai precis delimitate, cu att sistemul este mai: o Adaptabil - ntelegnd prin aceasta capacitatea sa de a suporta modificari intervenite n definirea initiala a cerintelor si totodata deschiderea la dezvoltari ulterioare 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 strns 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 mbracnd forma unei Cutii Negre, ce are precizate spre exterior doar Datele de Intrare si Datele de Iesire ca rezultate ale prelucrarii A doua etapa - este caracterizata de revolutia provocata de Eliberarea Datelor de sub dominanta Procedurilor. Prin cstigarea 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 dobndita fata de proceduri se manifesta prin Separarea Numelor de Valorile Datelor punndu-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 separndu-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 rentlnirea 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.).

Rentlnirea 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, avnd 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 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

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

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 dect 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, exceptnd 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 att 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) 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 Independenta Datelor fata de Proceduri asigura Imunitatea Procedurilor legaturile strnse cu produsele de Construire a Modelelor de Date permit Generare Automata a Structurilor Logice de Date 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) 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, Constrngeri,Triggeri, Proceduri Stocate) posibilitatea adresarii de Cereri Instantanee Bazei de Date prin Limbaje Neprocedurale (SQL - Structure Query Language sau QBE - Query By Example) construirea Surselor de Date accesibile de pe diferite platforme Hardware si Software mbunatatirea dialogului Utilizator - Calculator dezvoltarea Interfetelor Utilizator cu mare grad de interactivitate

- Scurtarea duratelor de proiectare si implementare a proiectelor complexe

- Adaptabilitate la modificarea specificatiilor initiale

- Facilitati de definire a Proiectelor Integrate

- Controlul validitatii datelor

- Raspuns la ntrebari Neprevazute initial

- Flexibilitate de adaptare la noile Tehnologii de Proiectare

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.

COMPUS q COMPONENT
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 continnd 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:

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 q1 B q3 q4 q5 A q2 C q6

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 Informatii Tehnice si Tehnologice legate de structura produselor si de necesarul de materiale pentru fabricarea acestor produse Informatii Comerciale asupra Comenzilor de Produse si Componente de Produse Lista Componentelor care se cer achizitionate sau fabricate pentru onorarea Comenzii Lista Necesarului de Materiale necesare fabricarii produselor solicitate Lista Modificarilor n listele anterioare, modificari generate de schimbarea continutului Comenzilor

Date de Intrare: o o o o o

Date de Iesire:

40 o

Exemple de Baze de Date

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 SERVER (1) STATII de LUCRU (8)
Memorie Principala Memorie Cache Porturi Hard Disc Drive Controler de Disc CD drive Floppy Disc 128 Mb 1024 Kb 4 2 GB 2 GB SCASI Memorie Principala Memorie Cache Porturi Hard Disc Drive Controler de Disc CD drive Floppy Disc 32 Mb 1024 Kb 2 1 GB 1 GB IDE

Componenta
Memorie Interna

Memorie Externa

3.5 inches 5.25 inches

3.5 inches 5.25 inches

Display Tastatura Carcassa Mouse

Monitor Placa Video

Monitor Placa Video

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 Cunoscnd Disponibilul (Stocul) de Componente sa se determine Necesarul de Aprovizionat pentru fiecare tip de Componenta n vederea onorarii Comenzii Cunoscnd Disponibilul (Stocul) de Componente sa se determine Comenzile care se pot onora imediat sau care se cer amnate Amploarea Colectiilor de Date care formeaza Sursa de Date pentru asemenea prelucrari: o Calitativ - structuri de tip Padure de Arbori Cantitativ - mii de Noduri si sute de mii de Legaturi

o o

Se pot remarca doua aspecte legate de genul de prelucrari de date prezentat anterior: 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

PARTEA a 3 -a CONCEPTE de BAZA

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 rndul 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 nct 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

Concepte de Baza

Prezentarea Conceptelor de Baza este organizata n jurul a trei opozitii de termeni cu care opereaza frecvent Bazele de Date: o o o Multimi si Relatii ca elemente fundamentale de descriere a existentei Informatie si Data ca forme de reprezentare a Semnificatului si Semnificandului n SBD 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 ( rogramare Clasica, Programare Obiectuala, P 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 gndirii 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). Avnd 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 o

Caracteristicile de baza ale Multimii 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, intrnd 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 rnduri 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 Se zice:

Concepte de de Baza / Multimi

M 2 M 1 (M 2 e Inclus n M 1 sau M 2 e Parte Proprie a lui M 1 ) daca: x M2 x M1 Se zice: M 2 M 1 (M 2 e Strict Inclus n M 1 ) daca: x M2 x M1 si x M2 x M1 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 M1 x M2 sau: x M1 x M2 x M2 x M1 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, att Entitatea Notiune ct 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 purtnd 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 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 avnd n Elemente P(M) va avea 2 Multimile Parti).
n

Exista expresia de legatura:

Elemente (reprezentate de

Pentru o Multime M avnd definite n Submultimi (Multimi Parti) oarecare (nedisjuncte) acestea genereaza n multimea data: C n0 + C n1 + C n2 + + C nn = 2 n Parti Disjuncte (obtinute prin Intersectia Submultimilor Oarecare pentru fiecare Combinatie de Submultimi) (C0 2 ) n + (C1 2 ) n + (C3 2 ) n + + (Cn2 ) 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 dect 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

M1

M2

M3

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:

Concepte de Baza / Multimi

47 M 1 M 2 M 3 .. M n = M

M2 M1

M4

M6 M5 M3

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

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 ntlnita la stabilirea Multimilor Parti (de tip Partitie sau Acoperire) prin definirea de Proprietati Secundare Combinare de Elemente - operatie ntlnita 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 nct 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 stng al perechii ordonate (m 1 , m 2 ) este elementul multimii formate dintr-un singur element, pe cnd membrul drept este constituit cu elementul ce nu se gaseste n aceasta multime. Definitia folosita extrage elementul m 1 din multime eliberndu-l de proprietatea de echivalenta si acordndu-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: m1 =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 pna 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 avnd 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 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. ntruct 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
n

se defineste ca o

50

Concepte de Baza / Relatii ntre Multimi

pe multimea Produsului Cartezian M 1 x M 2 x M Totala Extensionala prin:

x .. x M

, privit ca Multime

{ (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 distrugnd 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 (nendeplinita 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: R1 R2 Daca: R 2 e adevarata ori de cte ori R 1 e adevarata Aceasta proprietate determina existenta unei Legaturi de Dependenta (Incluziune) si ntre Domeniile de Valori ale celor doua Relatii. R1 R2 (n Intensiune) R1 R2 (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 reprezentnd 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 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

Proiectia de rang j a Relatiei n-are:

R, j = {m j|m k Mk

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 attea Tipuri de Relatii Binare. 3.1.2.6.1 Relatii Binare pe Doua Multimi Distincte In acest caz: R M 1 x M2 . unde: R = { (m 1 , m 2 ) | m i M i pentru i {1,2}si 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 Rc M1 x M2 proprietate: (m 1 , m 2 ) R c (m 1 , m 2 ) R Relatia Unica la Stnga 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 Stnga si Unica la Dreapta. Relatia Binara Functionala Relatia Binara Functionala este o Relatie Unica la Stnga sau Unica la Dreapta ntruct proprietatea de Unicitate nu e simetrica au loc urmatoarele determinari: pentru Relatia Unica la Stnga PR,M2 PR,M1 P R , M 2 determina functional pe P R , M 1 P R , M 1 depinde pentru Relatia Unica la Dreapta PR,M1 PR,M2 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: PR,M1xM2 . 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 functional de P R , M 2

In acest caz:

54

Concepte de Baza / Relatii ntre Multimi

R Mx M. unde: R = { (m 1 , m 2 ) | m i M pentru i {1,2} si P (m 1 , m 2 ) = adevarat}

Relatia Identica (Nula) Ri Mx M proprietate: m M (m , m) R si (m 1 , m 2 ) R (m 1 = m 2 ) Relatia Totala relatie identica cu Produsul Cartezian Rt = Mx M Relatia Reflexiva orice relatie ce contine o Relatie Identica Rr Mx M proprietate: m M (m , m) R r sau altfel exprimat: Rr Ri Relatia Nereflexiva orice relatie ce nu contine nici un element al Relatiei Identice Rn Mx M proprietate: m M (m , m) R n Relatia Simetrica contine toate perechile de cupluri simetrice Rs Mx 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 Ra Mx 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 Rt Mx M

proprietate: (m 1 , m 2 ) R t si (m 2 , m 3 ) R t (m 1 , m 3 ) R t sau altfel exprimat: Rt * Rt Rt Relatia Conexa Rx Mx M

proprietate: (m 1 , m 2 ) R x sau inclusiv (m 2 , m 1 ) R x

3.1.2.6.2.1 3.1.2.6.2.1.1

Tipuri de Relatii Binare pe Aceeasi Multime Relatia de Echivalenta

Relatia de Echivalenta este o Relatie Binara cu urmatoarele proprietati: Reflexivitate Simetrie Tranzitivitate
M )

Multimea tuturor Echivalentelor pe o multime data M se noteaza cu E ( de proprietatea: E( M ) P ( M x M ) .

si se bucura

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 |mEm 1 } . Reprezentant al Clasei de Echivalenta se considera a fi: m [m]E Multimea Ct , 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 Ct este o masura a Gradului de Omogenitate al unei Multimi M fata de o Echivalenta E. Pe baza definitiei Claselor de Echivalenta, [ m ] proprietati ale acestora: E

, pot fi demonstrate urmatoarele

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

[m] E = M
Rezulta din proprietatea de Reflexivitate a Echivalentei: m|mEm 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 Mo ( M , O )

Acest concept este preluat de Modelul Relational de organizare a datelor prin urmatoarele restrictii implicite: o o Orice Colectie de Date este privita ca o Multime (de tuple, sau nregistrari), deci neordonata Cu ajutorul acestor Colectii de Date, care constituie Structura de Baza a Modelului de Date, se poate construi, utiliznd conceptul de Relatie, orice structura de date orict de complexa Toti Operatorii implementati pe aceasta Structura de Baza nu pretind existenta prealabila a unei Ordini 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 Unei Colectii de Date i se pot adauga oricti Indecsi transformnd-o n tot attea Colectii Ordonate, care dispar odata cu eliminarea structurilor auxiliare atasate, ceea ce confera un caracter dinamic procesului de ordonare Procesul de Navigare n aceste Colectii de Date ramne si el dinamic prin posibilitatea modificarii Ordinii de Inspectie prin simpla nlocuire a Indexului Activ pe parcursul navigarii

o o

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:
3.1.2.6.2.1.2.1

Relatii de Ordine Partiala Relatii de Ordine Totala Relatii de Bine Ordonare

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 d Echivalenta ntre e

58

Concepte de Baza / Relatii ntre Multimi

submultimile sau elementele aflate pe acelasi nivel si ntre care, neexistnd 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 ntruct relatia ramne 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 ON . 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 M1 | m M1 ,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 - ON . 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

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 cnd Suportul relatiei atasate e ntregul DD Aplicatii Surjective aplicatii din DD pe DV cnd Domeniul Valorilor relatiei atasate e ntregul DV Aplicatii Bijective aplicatii ce sunt Relatii Biunice Functiile Injective sunt Relatii Unice la Stnga 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 nct 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 ntruct reprezentarea Structurilor de Informatii si de Date cu ajutorul Grafurilor este foarte frecvent ntlnita 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 Mi

Particulariznd aceste proprietati n cazul Functiilor obtinem:

Concepte de Baza / Grafuri si Arbori

61

In aceasta viziune Graful e privit nu doar ca o Multime de Arce ce leaga Perechi de Vrfuri, ci si c un set de alte caracteristici atasate Arcelor si Vrfurilor ce intra n legatura a (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 O Multime Nevida de Elemente X O Aplicatie T a lui X n Multimea Partilor lui X T : X P Definitia a II - a: Graful e reprezentat de expresia: G = (X , U) si contine: o O Multime Nevida de Elemente X numite Vrfuri sau Noduri: X = { x 1 , x 2 , .. , x n } o O Multime de Perechi de Elemente U:
( M )

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 Vrf x i toate Vrfurile x j pentru care exista Arcele (x i , x j) Predecesor al unui Vrf x forma (x j, x i )
i

toate Vrfurile x

pentru care exista un Arc de

Vrfuri Adiacente doua Vrfuri legate printr-un Arc Drum Orientat o Succesiune de Vrfuri Adiacente (x 1 , x 2 , .. , x d-1 , x d ) astfel nct: (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 Vrfuri defineste un Drum Orientat Lungime de Drum Numarul Arcelor unui Drum Bucla un Drum de Lungime 1 Descendent al unui Vrf x i toate Vrfurile x j din G astfel nct sa existe un Drum Orientat de la i la j Ascendent al unui Vrf x i toate Vrfurile x j din G astfel nct sa existe un Drum Orientat de la j la i

In cazul unui Graf Neorientat definitiile anterioare ramn valabile facnd urmatoarele substitutii: 3.1.4.3 Arbori Arborii reprezinta cazuri particulare de Grafuri, adica Grafuri avnd proprietati suplimentare, pe care le prezentam n continuare: Arbore un Graf Conex care are un singur Vrf, numit Radacina, fara nici-un Ascendent Vrf Terminal toate Vrfurile unui Arbore care nu au nici-un Descendent Nivelul unui Vrf Lungimea Drumului ntre Radacina si Vrf Subarbore al unui Arbore un Arbore a carui Radacina are un Ascendent ntrunul din Vrfurile Arborelui n care e continut Padure de Arbori o Multime Ordonata de Arbori (exemplu: multimea Subarborilor unui Arbore ) Arc Circuit cu Muchie cu Ciclu

Graf Tare Conex cu Graf Conex

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.) A

S1

S2

S3

Subarbore Arbore (Apel Recursiv)

A - Arbore R Radacina S Subarbore

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, ramnnd 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 Vrfuri exista un singur Drum ntr-un Arbore Simplu daca se exclude Radacina, celelalte Vrfuri pot fi mpartite ntr-un numar de multimi disjuncte de Vrfuri, fiecare multime alcatuind la rndul ei un Arbore, numit Subarbore al Arborelui initial

64 -

Concepte de Baza / Grafuri si Arbori

Arbore Invers un Arbore care are cel putin un Vrf 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 att de definirea structurii de Arbore utiliznd Reguli de Descriere, ct 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 cteva: 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 Stng, Subarbore Drept Parcurgere n Endordine Utilizata pentru Acumularea Informatiei din Descendenti n Ascendent (ex. Proceduri de Centralizare) Subarbore Stng, Subarbore Drept, Radacina Parcurgere n Postordine Utilizata pentru Transferul Informatiei ntre Descendenti cu consultarea Ascendentului Subarbore Stng, 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 o Ridicarea recursivitatii prin Liniarizarea Structurii 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, eliminnd 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 ct mai profitabile n practica. Investigatia este cu att mai necesara cu ct , avnd de a face cu Notiuni Primare, se poate vorbi mai degraba despre acceptiuni ale acestor concepte, despre Modele preferate n definirea lor, dect despre adoptarea unor Definitii unanim recunoscute de catre specialisti. ntruct se poate considera ca Teoria Informatiei se constituie n primul rnd ca o suma de Concepte si Modele - ntelegnd 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 cnd vorbesc despre ele. " particula de materie particula de reflectare

REALITATE nconjuratoare

preluare de informatii

IMAGINE reflectata

prelucrare de informatii 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

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 completnd-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 nct :

0 p( xi) 1 si p ( xi) = 1
1

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 :

E ( p1 , p2 , ... , pn ) = - pi log 2 pi
i =1

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 = - log 2 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 Unul Pragmatic - legat de modul n care Observatorul interpreteaza continutul informational al mesajului

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

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 ramne informatie si cnd este redondanta 100%, caz n care eliminarea nedeterminarii ramne potentiala sau cnd, 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 cmpul 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, reprezentnd 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. Informatie Nume Cantitate CantLiv Cantitatea-Livrata este 100 Cantitate CL Cantitate Data Valoare 100 100 1100100 64 Suta Tipul Datei: ntreg Tipul Datei: ntreg Zecimal Tipul Datei: Binar Tipul Datei: Hexazecimal Tipul Datei: Sir de Caractere Observatii

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, reprezentnd Sens, n timp ce Data se constituie n plan Sintactic, reprezentnd 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, caracteriznd 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 , n 1 ,o 1 , s1 , n 1 , c2 , n 2 ,o 2 , s2 , n 2 , .. Valori (Instante) de Entitati {c1 , n 1 ,{o 1 , s1 , n 1 }}, {c2 , n 2 ,{o 2 , s2 , n 2 }} ..

Relatii de Identitate si de Relatii de Ordine Naturala - aceste relatii apar ntre nsusiri, respectiv Valori ale Datelor, putndu-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 = o 1 { Beneficiar 1, Beneficiar 3, .. , Beneficiar n } { Beneficiar j}| Oras j = o 2 { 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 ( urnizor si Beneficiar) si sa transferam Egalitatea a F cestor 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 rnd 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 facnd parte din Spatiul Informatiilor, iar modelarea cu ajutorul datelor a unei descrieri prin informatii deja definite, se considera ca apartine Spatiului Datelor. Totodata, att n Spatiul Informatiilor ct 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, jalonnd 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 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 Cstigurile 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. D aici e deriva si amestecarea Datelor Interne (Variabilele de Program) cu Datele din Baza de Date (Atribute Cmpuri 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 trziu n utilizarea BD.

72

Concepte de Baza / Date si Proceduri

Asemanarea elementelor Date Proceduri este tot att 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. Procedurile pot fi privite ca Stari Viitoare sunt definite functional (prin precizarea unei Functii de Calcul). Valoarea rezultata din calcul poate fi Memorata, lund forma de Data Reala (Redondanta) sau numai Afisata, nfatisndu-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 putnd 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. ncepnd cu atasarea Fragmentelor de Proceduri (Snippets) la diferite momente de prelucrare a datelor de intrare (memorate n Componenta Client) si continund 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 coborrii 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 att mai necesara cu ct 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 ramnnd definite ca Entitati de sine statatoare (Obiecte) n Baza de Date. Dar si atunci cnd 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
3.4.1

Structuri de Informatii si Date

Structura, Organizare si Acces

Spunem ca un ansamblu e Structurat atunci cnd 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 dect cea primara de apartenenta a elementelor la multimea data, indica prezenta unei Structuri interne. ntruct 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 pna 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, ntruct 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.)

ntruct 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 o 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 Structura este Elementara (Atomica), n varianta Relationala (B, P, C) Structura este Necontextuala ceea ce o face Reorganizabila prin schimbarea dinamica a Viziunilor

Modelul Relational

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 ramne Necontextuala, Componentele pastrndu-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 Constrngeri de Cheie Candidata (Index unic) pentru combinatia B+P
Model Ierarhic Intensiune Model Relational Intensiune Extensiune 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} .. }

BENEFICIAR Cod Nume PRODUS Cod Nume CONTRACT Numar Cantitate END END Extensiune BPC {{ b1, {p1, {c1, c2, .. }, p2, {c1, c2, .. }, .. }, { b2, {p2, {c1, c2, .. }, p3, {c1, c2, .. }, .. }, .. }

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

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

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

ntruct, referitor la utilizarea termenilor de nivel Logic si Fizic, exista att n literatura de specialitate, ct 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: o Articolele Logice descrise n Programe Articolele Fizice, atunci cnd se cere o gestiune a Informatiilor de Control a Suportului 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

In Bazele 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

DESCRIERE ARTICOL prin NUME ( ARTICOL LOGIC )

DICTIONARE de DATE (SABLOANE de DESCRIERE)

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

Plan NUME

N1

N2

. . .

. . .

Nn

Plan VALORI ICB1 ICA1 V 11 V 12

. . .

. . .

V 1n

ICA 2
11

V 21

V 22

. . .

. . .

V 2n

. . .

ICA m
11

V m1

Vm2

. . .

. .

V mn

SB
1

REPREZENTARE VALORI ARTICOL LOGIC pe SUPORT ( INREGISTRARE LOGICA )

FISIERE de DATE pe SUPORT BLOCURI de INREGISTRARI

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

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

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.
Elementul Descris
ENTITATE NOTIUNE

Nivelul general de descriere

LOGIC

Mijlocul de descriere
NUME

Nivelul diferentiat de descriere Interpretare Viziune

ENTITATI + RELATII ARTICOL LOGIC / ARTICOL FIZIC ARTICOL FIZIC Gestiune Informatii + DATE Gestiune DATE + Proceduri Gestiune DATE + SUPORT

ENTITATE OBIECT SUPORT

LOGIC / FIZIC FIZIC

VALORI Reprezentare VALORI + Date de CONTROL

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, dect 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 gndeasca 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 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

Neglijnd 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 (utiliznd 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 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

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

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

SPATIUL INFORMATIILOR

STRUCTURA LOGICA de INFORMATII

1 n

STRUCTURA FIZICA de INFORMATII

1 n

STRUCTURA LOGICA de DATE

STRUCTURA FIZICA de DATE

SPATIUL DATELOR

Planul NUMELOR

Planul VALORILOR

Fig. 3.4.1.2.2 Spatii si Planuri de descriere a Informatiilor si Datelor Demersurile facute pna n prezent, ncepnd cu delimitarea diferentelor de acceptiune ntre Informatie si Data si terminnd 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, ntelegnd prin aceasta formele de proiectare care apeleaza la Modele de Date pentru descrierea tot mai directa a Spatiului de Informatii si continund apoi

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).

Caracteristici de descriere a INFORMATIILOR

STRUCTURA de INFORMATII

1 n

Caracteristici de descriere a DATELOR

STRUCTURA LOGICA de DATE ( STRUCTURA TEORETICA) 1 n

Caracteristici de descriere a SUPORTULUI

STRUCTURA FIZICA de DATE ( STRUCTURA de STOCARE)

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, pna la fundamentarea Proiectarii de Nivel nalt n cadrul Modelelor de Date, Modele ce ncorporeaza att Structura, ct 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 rezumndu-se la Planul Numelor, ntlnim 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.

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 rnd 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 s permita a industrializarea construirii de Structuri Complexe. 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. 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. Pentru a putea gndi 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. Cunoscnd 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 o Relatia de Echivalenta Relatia de Incluziune De tip Partitie De tip Acoperire

84

Structuri Fundamentale de Informatii si Date

- de Acoperire - de Partitie -

UM
i

= M = M si Mi I Mj = pt. i si j

UM
i

Diagrama VENN
E

E1

E2

E3

E4

E5

Structura GRAF E n

E1

E2

E3

E4

E5

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.

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 ntruct ea descrie relatia n care se afla elementele aflate pe acelasi nivel formnd 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 apartinnd oricarei relatii, fapt ce implica mentiunea ca Ordinea lor este indiferenta, iar atunci cnd 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 Adncime (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 o Incluziune de tip Arborescenta structura cu Ascendent Unic, de Tip Partitie 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
E

E1

E2

E "

E3

E4

E5

Structura GRAF E n

E1

E2

E3

E4

E5

Fig. 3.4.2.2 Structura de tip Incluziune - Partitie

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. Att Legatura de Posesiune ct si cea de Alaturare pot primi concretizari semantice dintre cele mai diferite. Din prima categorie mentionam una foarte des ntlnita si anume cea de: Compus Componente. Relatia de Echivalenta se defineste ca legatura care exista ntre Elementele apartinnd 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 dect n masura n care defineste Proprietatea Comuna, ntruct 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, dect prezenta ei. A fost nsa tratat ca prima forma de structurare ntruct 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 o Arborescenta

Structuri Fundamentale de Informatii si Date

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 indicnd 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, cnd 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.

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 indicnd 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 Multipl a 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 ramne 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

E1

E2

E "

E3

E4

E5

Structura GRAF E

E1

E2

E3

E4

E5

Fig. 3.4.2.3 Structura de tip Incluziune - Acoperire

Structuri Fundamentale de Informatii si Date

90

de tip ECHIVALENTA structura orizontala

structura PRIMARA

relatie n-n pe orizontala

raport de COORDONARE

NIVEL

STRUCTURI

relatie 1 -n pe verticala de tip PARTITIE structura EVOLUATA

raport de SUBORDONARE SIMPLA ascendent unic

ARBORESCENTA

de tip INCLUZIUNE structura verticala

relatie m-n pe verticala de tip ACOPERIRE

raport de SUBORDONARE MULTIPLA ascendent neunic

RETEA

Fig. 3.4.2.4. Structuri Fundamentale

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 s pecialitate, 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 o Perfectionarea Modelelor de Date pe care sunt construite succesiv Sistemele de Gestiune ale Bazelor de Date 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 M1 M2 M3 M4 M5 Nume N1 N2 N3 N4 N5 Vrsta V3 V2 V1 V3 V1 Localitate L2 L1 L2 L3 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, ntruct 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, Vrsta 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 ramnnd 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:
3.4.2.2.1.1

Disponibilitate Lungime Usurinta de Memorare Obisnuinta Utilizatorului

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 M1 M2 M3 M4 M5 Nume N1 N2 N3 N4 N5 Vrsta V3 V2 V1 V3 V1 Localitate Referinta R-L2 R-L1 R-L2 R-L3 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 cstigul 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 cstigul 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 avnd 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 o Strategia 1 Acces de la Entitate la Caracteristica (Fig. 3.4.2.2.1.1.1 acces de la STUDENT la Localitate) Strategia 2 Acces de la Caracteristica la Entitate (Fig. 3.4.2.2.1.2.1 - acces de la LOCALITATE la STUDENTI) LOCALITATI Localitate L1 L2 L3 Student Referinta R-S2 R-S5 R-S1 R-S3 R-S4

STUDENTI Marca M1 M2 M3 M4 M5 Nume N1 N2 N3 N4 N5 Vrsta V3 V2 V1 V3 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 o Prezenta Instantelor de Lungime Variabila n Colectia Secundara LOCALITATI 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 cnd 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 cnd 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 nti 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, ntruct 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 dect sa puna laolalta cele doua metode precedente, asigurnd posibilitatea accesului si de la STUDENTI la Localitatea de Resedinta, dar si de la o LOCALITATE la toti STUDENTII avnd Resedinta n aceasta Localitate. Numarul Variabil de Referinte se pastreaza n colectia LOCALITATI, complicnd gestiunea ei. STUDENTI Marca M1 M2 M3 M4 M5 Nume N1 N2 N3 N4 N5 Vrsta V3 V2 V1 V3 V1 Localitate Referinta R-L2 R-L1 R-L2 R-L3 R-L1

LOCALITATI Localitate L1 L2 L3 Student Referinta R-S2 R-S5 R-S1 R-S3 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 ramn de Lungime Fixa. Modificarea transforma Colectia de Date LOCALITATI din Index Dens (LOCALITATI n varianta 1 n Nedens ( OCALITATI n ) L 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 continund 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 L1 L2 L3 Student Referinta R-S2 R-S1 R-S4

STUDENTI Marca Nume Vrsta Localitate Referinta R-L2 R-S3 M2 M3 M4 M5 N2 N3 N4 N5 V2 V1 V3 V1 R-L1 R-S5 R-L2 R-L3 R-L1 Fig. 3.4.2.2.1.3.2 Eliminarea Redondantei + Inversarea Partiala (Varianta 2) Aceasta structura a fost introdusa de Modelul Retea, reprezentnd primii pasi pe calea obtinerii Structurilor de Date Integrate de tip m - n.
3.4.2.2.1.4 Inversarea Totala

Localitate Referinta Izotipa

M1

N1

V3

Inversarea Totala duce la o structura care a cstigat 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 ntruct s-a asigurat cte 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 M1 M2 M3 M4 M5 MARCI Marca M1 M2 M3 M4 M5 NUME Nume N1 N2 N3 N4 N5 VARSTE Vrsta V1 V2 V3 LOCALITATI Localitate L1 L2 L3 Student Referinta R-S3 R-S5 R-S2 R-S1 R-42 Student Referinta R-S2 R-S5 R-S1 R-S3 R-S4 Student Referinta R-S1 R-S2 R-S3 R-S4 R-S5 Student Referinta R-S1 R-S2 R-S3 R-S4 R-S5

Nume N1 N2 N3 N4 N5

Vrsta V3 V2 V1 V3 V1

Localitate L2 L1 L2 L3 L1

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 cmp fertil. Prin aceasta structura s-au obtinut urmatoarele efecte: Avantaje: Dezavantaje: Spatiul necesar Colectiilor Secundare depaseste n general pe cel al Colectiei Principale 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

In practica se foloseste, din motive de performanta, o Inversare Partiala n care Utilizatorul si alege singur Caracteristicile de Inversare genernd si eliminnd 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 L1 M2 M5 L2 M1 M3 L3 M5 N5 V1 N1 N3 V3 V1 N2 N5 V2 V1 Nume Vrsta

Fig. 3.4.2.2.1.5.1 Reorganizarea Structurii Aceasta Structura de Date sta la baza Modelului Ierarhic, stimulnd conceperea Procedurilor de Prelucrare organizate pe Aplicatii Independente.

Transformarea Structurilor Fundamentale

99

Remarcile care se pot face aici sunt urmatoarele: Avantaje: 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 cnd se opereaza cu volume mari de date Absenta posibilitatilor de combinare a Strategiilor de Acces descrise anterior Generalizarea Conceptului de Inversare 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

3.4.2.2.2

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-CaracteristicaValoare 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. Fixndu-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 Limiteaza accesul la nivelul Segmentelor din Colectia Principala

Retea pentru Colectiile Secundare

Modelul Retea Retea pentru Colectiile Principale Mentine rigiditate n Structura de Date prin inspectia secventiala a Listelor de Articole (Setului) Limiteaza accesul la nivelul Articolelor Principale

Retea pentru Colectiile Secundare

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 ntruct 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 putnd 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 o o o o Reprezentarea Fizica Reprezentarea Logica (Simbolica) Arborele de Structura Diagrama Entitati Relatii 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 att ca avantaje ct 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)
Entitate Obiect Clasa de Entitati Obiecte

- ascendent -

Entitate Obiect Clasa de Entitati Obiecte

Entitate Obiect Clasa de Entitati Obiecte

Entitate Obiect Clasa de Entitati Obiecte

- descendent / ascendent -

- descendent / ascendent -

- descendent / ascendent -

Entitate Obiect

Entitate Obiect

- descendent -

- descendent Fig. 3.4.3.1.1. Reprezentarea Fizica

Reprezentarea se poate continua pna cnd 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 nvatamnt 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

Reprezentarea Structurilor de Informatii si de Date

103

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 putnd sa fie extras prin filtrare cu ajutorul unei conditii prestabilite ( tructura S Organizatorica sau / si Structura Didactica). U

F1

F2

F3

FS 1

FS 2

P1

P2

P3

P1

P2

P3

P1

P2

P3

A1

A2

A3

A1

A2

A3

A1

A2

A3

G1

G2

G3

G1

G2

G3

G1

G2

G3

S1 Legenda

S2

S3

Sn

S1

S2

S3

Sn FS Formatie de Studiu

U Universitate F Facultate P Profil

A- An de Studenti G Grupa de Studenti 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.

104

Reprezentarea Structurilor de Informatii si de Date

Conventiile de reprezentare se reduc la cele continute n Fig. 3.4.3.2.1. 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 subnteleasa)

Entitate Notiune Clasa potentiala de Entitati Obiecte

1 i

m i

1 i m i n n

Sageata Punctata Legatura Derivata ntre Entitati Notiuni

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

Reprezentarea Structurilor de Informatii si de Date

105

proiectare, n cadrul laboratoarelor firmei IBM, formalismul mai poarta si numele de Diagrama Bachman.
Entitate Notiune 1 Clasa potentiala de Entitati Obiecte 1

1 i

Entitate Notiune 2 Clasa potentiala de Entitati Obiecte 2

1 m i n
Entitate Notiune 3 Clasa potentiala de Entitati Obiecte 3

i i n i 1 n

1 n

Entitate Notiune 4 Clasa potentiala de Entitati Obiecte 4

1 i

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 subnteleasa n acele scheme de reprezentare n care ne rezumam exclusiv la descrierea Naturii Legaturilor, n termenii Legaturilor Fundamentale ntre Informatii si Date. Atunci cnd 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: o Legaturi 1 1 Legaturi 1 n Legaturi m n m Ascendenti au n Descendenti 1 Document are n Rnduri 1 Producator are 1 Adresa 1 Grupa are n Studenti 1 Unitate este de n Tipuri

Concreta precizeaza un raport expres ntre Posesor si Membri ca de exemplu:

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

106

Reprezentarea Structurilor de Informatii si de Date

Exista si alte categorii de Legaturi Generale a caror semnificatie poate fi cuprinsa n Descrierea Intensionala rafinnd-o semantic, cum ar fi implementarea Rolurilor Abstracte a Subtipurilor de Clasificare (Disjuncte sau Nedisjuncte) etc. Cnd 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 Grupa) 1 1 n d
3 F U
2

la Entitatea

(1 Student apartine la 1

1 n d
2

1 d d n 1

FS

1 n

5 A

d d

1 n

d n n
3 G

d
1000

1
A - An de Studenti G Grupa de Studenti S - Student

Legenda U Universitate F Facultate P Profil FS Formatie de Studiu d Legatura de Descendenta

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 nvatamnt 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, ntruct apar doar Legaturi de Descendenta, mentionarea expresa a semnificatiei lor poate fi omisa ceea ce descarca schema de repetari de descrieri.

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. n Cerc Relatie R - Numele Relatiei n Numarul estimat de tuple n relatie

a i

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, marcnd 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

*
-

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)

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). o 1 U Entitate UNITATE o Legatura d Legatura f Legatura s Legatura Organizatorica Didactica Functionala Derivata de Structura d n 300 m s n 1 f 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 n

Apare ca strict necesara Descrierea Intensionala Nuantata a Legaturilor ntre Entitati, prin aceasta recuperndu-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 o Relatia de Legatura STRUCTURA (S) care va permite Implementarea Relationala a Legaturilor de Structura (Ascendenta si Descendenta)

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 o o Transformarea Legaturilor de Descendenta (Organizatorice, Didactice si Functionale) pe U n Legaturi de Ascendenta si Descendenta ntre U si S Mentinerea Legaturii Induse (Derivate) pe U (Legatura m n) Aparitia Legaturilor de Clasificare (c) ntre TU si U, respectiv ntre TS si S

Reprezentarea Structurilor de Informatii si de Date

109

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 de Categorisire m n 300

c n 1

50

TU

1 d e 1500 a

1 n

n c

TS

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 o o o U. t TU. i Semantica: Unitatile de un Tip & Tipul unei Unitati S. t TS. i Semantica: Structurile de un Tip & Tipul unei Structuri S. uc U. i Semantica: Descendentii unei Unitati & Ascendentul unei Unitati 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, ntruct 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

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 avnd de a face cu o Transformare Inversa (Proces de Reengineering), vezi secventa precedenta n ordine inversa

TU

*
i n a

*
S

TS

uc

*
Relatii

i ua

*
t

*
Atribute

U UNITATE S STRUCTURA UNITATII TU TIP UNITATE (Universitate, Facultate, Profil, Specializare, An, Grupa) TS TIP STRUCTURA (Organizatorica, Didactica, Functionala)

i Identificator t Tip n Nume a - Adresa uc Unitate Curenta 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.

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. n Entitate Notiune Clasa potentiala de Entitati Obiecte m I1 i 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)

n I2

m I1 i

n I2

I3 1 m I1 n m I4 m I1 i n I2 m I1 i n I2 n i 1 1 n I2 -

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

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

112

Reprezentarea Structurilor de Informatii si de Date

ROSE, CAEN, VISIO etc.) si care va utiliza n descriere inclusiv Intensiunile L egaturilor. 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 ramn valabile si n acest caz. Au rezultat schemele din Fig. 3.4.3.4.2, Fig. 3.4.3.4.3. 1 n o

n d U Entitate UNITATE 1

300

m s n

o Legatura Organizatorica d Legatura Didactica f Legatura Functionala s Legatura derivata de Structura

1 f

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, ntruct 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

Reprezentarea Structurilor de Informatii si de Date

113

m s

DISCIPLINA PROFESOR STUDENT NOTA - N P x D x S n

Se genereaza o Relatie de Legatura continnd Rezultatele la Examene

300

n c

50

TU

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

n 1500 n c 1 5

TS

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, neglijndu-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

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 O Nota e data de un singur Profesor, la o singura Disciplina, unui singur Student

Se remarca prezenta urmatoarei Restrictii Derivate:

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

800 dp m n 1 m n r 1 1

P
m

ps

400

10000

D
1

S
n 1 n ns

np

n n

30000

nd

P D S N

Entitate PROFESOR Entitate DISCIPLINA Entitate STUDENT Entitate NOTA N PxDxS

r Legatura polinara REZULTATE dp Legatura binara derivata DISCIPLINE / PROFESOR ps Legatura binara derivata STUDENTI / PROFESOR nd Legatura binara derivata NOTE / DISCIPLINA 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

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 o Elemente ce descriu Structura (Tabele de Baza, Atribute, Vederi) Elemente ce descriu Restrictii o Restrictii de Identitate (Chei Primare, Chei Candidate) Restrictii de Referire (Chei Straine) Constrngeri (Limite de Valori, Valori Compatibile, Restrictii semantice)

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 m entine 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 dobndeasca. 3.4.4.1 Structura de Ansamblu Sa consideram nucleul informatiilor dintr-un compartiment de Vnzari, 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 - Nume - Tip Societate - Adresa o - Telefon - Banca - Cont - Etc.

PRODUSE - Categorie de Informatii ce descrie Produsele n care Beneficiarii sunt interesati. Atributele care caracterizeaza aceasta Clasa de Entitati sunt: - Cod - Denumire - Pret - Culoare - Greutate - Stoc - Calitate - Etc.

CONTRACTE - Categorie de Informatii ce descrie Documentele Comerciale (Contractele) care stau la baza relatiilor de Vnzare Cumparare. Atributele care caracterizeaza aceasta Clasa de Entitati sunt: Antet Document - Beneficiar (Codul Beneficiarului) - Numar Contract - Data Contract - Clauze Contractuale Rnduri Document - Produs (Codul Produsului) - Cantitate Contractata - Pret de Livrare - Termen de Livrare

- Etc. - Etc. In cele ce urmeaza CONTRACTELE vor fi reprezentate de Antet, n timp ce Informatiile din Rnduri 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 } o Contractul C1 contine Pozitiile Contractuale referitoare la Produsele {P1 } Contractul C3 contine Pozitiile Contractuale referitoare la Produsele (P1 , P2} Contractul C2 contine Pozitiile Contractuale referitoare la Produsele {P1 , P2, P3 }

Beneficiarul B2 a stabilit Relatiile Comerciale din Contractele {C2 }

BENEFICIAR I

PRODUSE

P1 n B1 n B2 n
Obligatii Contractuale

n P3 n P2

n n

n C2
Relatii Contractuale

C1 C3 n

CONTRACTE

Pozitii Contractuale

Fig. 3.4.4.1.1 Structura de Informatii n compartimentul Vnzari Din aceste Informatii Primare iau nastere urmatoarele Informatii Derivate: o Pentru Beneficiarul B1 rezulta Obligatiile Comerciale referitoare la Produsele {P1 , P2 }

118 o

Structuri de Informatii la Utilizator

Pentru Beneficiarul B2 rezulta Obligatiile Comerciale referitoare la Produsele (P1 , P2 , P3 } Informatii descriptive ale Categoriilor (Grupurilor) definite: BENEFICIARI PRODUSE CONTRACTE

Din Fig. 3.4.4.1.1 rezulta prezenta n Spatiul Informatiilor a doua tipuri de informatii: -

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

Lund 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 o BENEFICIARI PRODUSE

Categorii de Informatii Dependente CONTRACTE

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 ct 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, neputnd 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 B2 n
BENEFICIARI
Relatii Contractuale

B1

C1

C2

C3

CONTRACTE
Pozitii Contractuale

P1

P2

P3

PRODUSE

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.

120

Structuri de Informatii la Utilizator

BENEFICIARI
Relatii Contractuale 1 n

PRODUSE
m n

Pozitii Contractuale

CONTRACTE

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 B1 n B2 n
Obligatii Contractuale

BENEFICIARI

P1

P2

P3

n
Pozitii Contractuale

PRODUSE

C1

C2

C3

CONTRACTE

Fig. 3.4.4.2.3 Structura Partiala II (BENEFICIARI / PRODUSE / CONTRACTE)

Structuri de Informatii la Utilizator

121

BENEFICIARI
m Obligatii Contractuale n

PRODUSE
Pozitii Contractuale m n

CONTRACTE

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 P1 n P2 n P3 n
Pozitii Contractuale

PRODUSE

C1 n

C2

C3 n

CONTRACTE
Relatii Contractuale

B1 n

B2

BENEFICIARI

Fig. 3.4.4.2.5 Structura Partiala III (PRODUSE / CONTRACTE / BENEFICIARI)

122

Structuri de Informatii la Utilizator

PRODUSE
m Pozitii Contractuale n

CONTRACTE

Relatii Contractuale

n 1

BENEFICIARI

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 P1 n P2 n P3 n
Obligatii Contractuale

PRODUSE

B1

B2

BENEFICIARI
Pozitii Contractuale

C1

C2

C3

CONTRACTE

Fig. 3.4.4.2.7 Structura Partiala II (PRODUSE / BENEFICIARI / CONTRACTE)

Structuri de Informatii la Utilizator

123

PRODUSE
m Obligatii Contractuale n

BENEFICIARI

1 Relatii Contractuale n

CONTRACTE

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

P1

P2

P3

n
Obligatii Contractuale

PRODUSE

B1

B2 n

BENEFICIARI
Pozitii Contractuale

C1

C2 n

C3

CONTRACTE

Fig. 3.4.4.2.9 Structura Partiala II (PRODUSE / BENEFICIARI si CONTRACTE)

124

Structuri de Informatii la Utilizator

PRODUSE
m Obligatii Contractuale n m Relatii Contractuale n

BENEFICIARI

CONTRACTE

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 ramn 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).

Structuri de Informatii la Utilizator

125

BENEFICIARI
1 Relatii Contractuale n Obligatii Contractuale m

CONTRACTE
n Obligatii Contractuale m n

PRODUSE

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, putnd 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.
BENEFICIARI
m Obligatii Contractuale

PRODUSE

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.

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), ramne 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, ntmplarea Neprevazuta. Necesita multa Educatie pregatirea Utilizatorilor n a ntelege ca Sistemul asteptat nu se poate construi acumulnd 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 l altul, am ales sa prezentam aceasta rafinare prin prizma a doua viziuni a 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) o Legaturi m - 1 Entitati Legaturi 1 - 1 Mai multe instante ale unei Entitati refera o instanta a altei 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 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

Optionalitatea Legaturii

Se r emarca 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 Recursiva Legatura porneste si se termina n Entitati diferite Legatura porneste si se termina n aceeasi Entitate

Aceeasi legatura poate fi clasificata dupa Criterii diferite. Rezulta urmatoarele cazuri de combinare:

128 o

Concepte de Baza / Diversificarea Tipurilor de Legaturi ntre Entitati

Legatura Nerecursiva Legatura m - 1 COPII Fig. 3.4.5.1.1 Copiii Angajatilor Un Copil nu poate apare n Baza de Date dect asociat cu un Angajat. Presupunerea poate conduce la solutii care impun aceasta restrictie si anume: Un Copil nu poate fi identificat dect n asociere cu un Angajat. Optionala la Mandatata
Produsele unui Pachet

Mandatata la Optionala
Copiii Angajatilor

ANGAJATI

PRODUS Fig. 3.4.5.1.2 Produsele unui Pachet

PACHET

Un Pachet nu poate apare n Baza de Date dect daca ambaleaza niste Produse. In acest caz restrictia semantica nu se reflecta si n modul de identificare a instantei de pachet ntruct un pachet poate contine n general mai multe produse. Ca atare restrictia semantica trebuie adaugata restrictiilor de identificare. Mandatata la Mandatata
Rndurile unei Comenzi

RANDURI Fig. 3.4.5.1.3 Rndurile unei Comenzi

COMANDA

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 Rndurile Comenzii. Doar aceasta viziune explica necesitatea restrictiei duble: Nici-un Rnd fara Comanda Nici-o Comanda fara cel putin un Rnd

Restrictia apare ca foarte utila n momentul n care Aplicatia o presupune, caci altfel Structura de Date poate face invizibile pentru prelucrari datele eronate: Rndurile necuprinse n Comenzi sau Comenzile fara Rnduri. Baza de Date avnd aceasta restrictie va mpiedica introducerea datelor eronate.

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 sfrsitul 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 ramne blocata). COPII ABANDONATI Fig. 3.4.5.1.4 Copii adoptatii Fie o Baza de Date continnd 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 ramn OPTIONALE putnd 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 Optionala la Optionala
Copii adoptatii

PERSOANE

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.
Sotia Angajatului

SOTIA ANGAJATULUI Fig. 3.4.5.1.5 Sotia Angajatului Optionala la Mandatata

ANGAJAT

ntruct, 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

130

Concepte de Baza / Diversificarea Tipurilor de Legaturi ntre Entitati

Angajatul Sotiei

ANGAJAT Fig. 3.4.5.1.6 Angajatul Sotiei

SOTIA ANGAJATULUI

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

CERTIFICAT De NASTERE

Certificatul unei Persoane

PERSOANA

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
Casatoriti

Fi BARBAT Fig. 3.4.5.1.8 Casatoriti

FEMEIE

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 ramne 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

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 ramnem n sfera declaratiilor Structurale. Legatura m - n Mandatata la Optionala
Membrii Echipei

MEMBRI Fig. 3.4.5.1.9 Membrii Echipei

ECHIPE

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 activnd n ramuri diferite de activitate). Optionala la Mandatata
Echipele unei Persoane

PERSOANE Fig. 3.4.5.1.10 Echipele unei Persoane

ECHIPE

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)

132 JUCATORI

Concepte de Baza / Diversificarea Tipurilor de Legaturi ntre Entitati

Mandatata la Mandatata
Jucatorii unui Joc

JOCURI 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, acceptndu-se participarea unui JUCATOR la mai multe JOCURI simultan si evident si reciproc. Optionala la Optionala
Parteneri

Barbati Fig. 3.4.5.1.12 Parteneri

Femei

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 n satisface toate u 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).

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.
Ascendenta

UNITATE Fig. 3.4.5.1.13 Ascendenta Legatura fundamentala implementata este de tip Ierarhie (vezi s ectiunea 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 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

Structura descrie perechi de instante de ANGAJATI ce apartin relatiei:

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.
Inlocuire

ANGAJAT 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
Componenta

PRODUS 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.

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: o Agentii guvernamentale Industria aerospatiala Piata bancara Corporatii majore

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 o 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) 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: 3.4.3.4.3 ) TIPUL-UNITATII sau TIPUL-STRUCTURII-UNITATII (Fig.

Independenta Entitatilor

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: Rndurile 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)

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 CodulUnitatii, Codul-Tipului-de-Unitate fiind doar un atribut descriptor, preluat din Entitatea Parinte TIP-UNITATE, care ramne 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

Repetitivitatea Legaturii Nerecursiva Legatura porneste si ajunge n Entitati diferite Recursiva Legatura porneste si ajunge n aceeasi Entitate 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 o o PROFESOR Entitate Specifica STUDENT Entitate Specifica CANDIDAT Entitate Specifica (Diferenta Specifica)

Tipuri Suplimentare de Legaturi

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 Descrierea Cardinalitatii IDEF1X Identificatoare Neidentificatoare Identificatoare IE Neidentificatoare

1 0,1,n

1 1,n

1 0,n

0,1 0,1,n neidentificatoare

0,1 0,1 neidentificatoare

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 o Bazele de Date nu au pregetat sa asimileze orice descoperire aparuta n alte domenii de cercetare Orice preluare a fost nsotita de introducerea ei n contextul propriu de preocupari, subordonata scopului principal urmarit: Integritate prin Independenta 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 comp lexitatii 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 avnd 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 o Principale reprezentate de Atribute din Baza de Date Auxiliare reprezentate de Variabilele de Program 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)

Operatii

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 Sfrsit (Fig. 3.5.2.1.1). Numarul de Aparitii (Instante) ale Blocului este 1. 1 BEGIN .. Operatiei .. END B

o1

on

o2 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.

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 stnga pentru conditia Adevarata, cel din dreapta pentru conditia Falsa (Fig. 3.5.2.2.1). Si Selectia are o singura Instanta. 1

IF Conditie THEN .. Operatiei .. ELSE .. Operatiej .. END

*
c 1 B1

1 B2

o1

o2

on

o1

o2

on

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). 1 B DO CASE CASE Conditie1 .. Operatiei .. CASE Conditie2 .. Operatiej .. CASE .. .. OTHER .. Operatiek .. END

1 C1 C2

1 .. C0

*
c1 1 B1

*
c2 1 B2

*
co 1 B0

o1

o2

on o1

o2

on

o1

o2

on

Fig 3.5.2.2.2 Structura de Control de tip Selectie Multipla

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 stnga n reprezentarea grafica), putndu-sa parasi Bucla daca la prima intrare Conditia de Iesire e satisfacuta r0 BEGIN IF Conditie THEN EXIT END .. Operatiei .. REDO END R

*
c 1 B1

o1

o2

on

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 executndu-se cel putin o data r>0 BEGIN .. Actiunej .. IF Conditie THEN EXIT END REDO END R

*
1 B1 c

o1

o2

on

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.

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. .. DO Nume-Procedura .. PROCEDURE Nume-Procedura BEGIN .. Operatiei .. END 1

*
a

1 B

o1

o2

on

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, conducnd la Proceduri Complexe. Respectnd o structura bine definita procesul de construire, dar mai ales de depanare a functionarii ei, pot fi tinute sub control. Cteva 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, putnd 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 (Ct Timp) considera pornirea de la o Conditie ndeplinita si se opreste la prima nendeplinire Varianta Nenula (Pentru) inspecteaza toata multimea de elemente selectndu-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:

Concepte de Baza / Structuri de Proceduri

143

Operatie

Atribuire Evaluare Neconditional Nerepetitiv BLOC Conditional

ACTIUNE CONDITIE COMPOZITIA Simpla SELECTIA Multipla

Grup Elementar (Grup de Operati) Element Grup Repetitiv BUCLA REPETITIA

Posibil Nula

Nenula

Fixa (CALL) SUBSTITUTIA Variabila (GO TO) 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 depinznd de Conditiile ntlnite 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, ramnnd 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 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 FOR - substitutie DO nume-procedura END - operatie operatie-specifica operatie de-control - operatie-specifica actiune conditie conditie [END] corp-procedura END [corp-procedura]

Concepte de Baza / Structuri de Proceduri

145

- operatie de-control structura-elementara Traducerea Mnemonicelor PROCEDURE BEGIN END DO - PROCEDURA - INCEPUT - SFARSIT - EXECUTA IF THEN ELSE WHILE FOR - DACA - ATUNCI - ALTFEL - CAT TIMP - 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 strns legat de specificul Structurilor de Date ce urmeaza a fi prelucrate. Pentru acest motiv Sistemele cu Baze de Date se preteaza pentru asemenea descrieri, ntruct 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 o o Preluarea Structurilor de Control din Limbajele Procedurale (vezi Fig. 3.5.3.1) Definirea unui Limbaj Formal general (vezi Fig. 3.5.4.1) 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 cteva 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 gndi 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) M
1

*
i=1 i<n C

*
n(i) n(i+1) T

i=i+1 n

j=i+1

m=n(j)

*
j >1 si n(j-1)>m

n(j)=n(j-1)
Legenda

j=j-1

n(j) =m

M Sortare Matrice I Initializare Index A Actualizare Index S Scanare Matrice C Test Conditie

T Transpunere Elemente E Extragere Element D Deplasare Elemente R Reamplasare Element

e - Element i, j Indecsi n - Nume m Variabila Interna

Fig. 3.5.6.1 Arborele de Programare pentru procedura de Sortare prin Transpunere

Concepte de Baza / Structuri de Proceduri

148

Operatia de Substitutie, care nu poate fi n viziunea structurala dect Fixa, invita la Modularizarea Procedurii, cu rezultate directe att n faza de constructie ct 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

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 ntmplator 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 A

b C

*
r

c1

c2

*
ri

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. Cnd 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

Concepte de Baza / Structuri de Proceduri

149

PROCEDURA Interogare Cerere-Raspuns (r) .. operatia o 1 DACA R=nedefinit . conditia c1 ATUNCI IESIRE .. operatia o 2 SFARSIT Initializare Contor .. operatia o 3 TEST CAZ CAZ R=A EXECUTA Scanare1 .. operatia o 4 CAZ R=E EXECUTA Scanare2 .. operatia o 5 ALTFEL EXECUTA Eroare (1) .. operatia o 6 SFARSIT EXECUTA Listare(R, Contor) .. operatia o 7 SFARSIT PROCEDURA Scanare1 Cerere-Raspuns (v) .. operatia o 8 PENTRU TOATE Instantele A avnd a > v ... conditia c2 Incrementare Contor .. operatia o 9 SFARSIT SFARSIT PROCEDURA Scanare2 Contor = Cardinal Multime de Instante E ... operatia o 10 SFARSIT PROCEDURA Listare PARAMETRII Nume-Entitate, Contor Listare Nume-Entitate, Contor SFARSIT

.. operatia o 11

PROCEDURA Eroare PARAMETRII Numar-Eroare TEST CAZ CAZ Numar-Eroare =1 . conditia c3 Listare Valoare Raspuns Eronata .. operatia o 12 CAZ .. .. ALTFEL .. SFARSIT SFARSIT Fig. 3.5.6.3 Procedura de Interogare (Descriere n Pseudo Cod)

Concepte de Baza / Structuri de Proceduri

150

1 1

o1
1

*
T o7

L
1

Te

*
c1 C1
1 1

*
c3
1 1 1

C2

o11

E1

E2

..

o2

o3 Tc o12
1

1 1

*
c2
1 1

C1

C2

S1

S2

..

o8 S

*
o4

*
o5

*
o6

*
c2

o9

o10

Legenda

I Interogare S 1 Scanare 1 S 2 Scanare 2 S Scanare Multime de Instante E

L Listare E Eroare T Test Raspuns 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 dect Variabile specifice unei Proceduri de Interogare si anume: Raspunsuri de Continuare sau Constante de Filtrare)

Concepte de Baza / Structuri de Proceduri

151

PARTEA a 4 -a MODELE de INFORMAT II si DATE

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-alungul 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
4.1

Modele de Informatii si Date

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, reprezentnd 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 pna acum, obtinndu-se noi Multimi de Informatii: Caracteristici descriptive pentru entitatea STUDENT
Marca Nume Prenume Vrsta Sex

Modele de Informatii / Modelul Entitate Caracteristica - Valoare

153

Sectie Responsabilitate Membru-n-Grupa 101 102 103 etc. Ionescu Varga Pop etc.

Valori ale Caracteristicii Marca

Valori ale Caracteristicii Nume

Valori ale Caracteristicii Prenume Andrei Stefan Maria etc. Valori ale Caracteristicii Vrsta
22 21 etc. Barbatesc Femeiesc Informatica Electronica etc. Da Nu

Valori ale Caracteristicii Sex

Valori ale Caracteristicii Specialitate

Valori ale Caracteristicii Responsabil-de-Grupa Valori ale Caracteristicii Membru-n-Grupa cu Responsabil-de-Grupa = Studentul-2
Sstudentul-1, Studentul-2, etc. etc. Studentul-1, Studentul-2, etc. Studentul-3, Studentul-4, etc. etc. 101 Ionescu Stefan Barbatesc Informatica Studentul-1, Studentul-2, etc. etc.

Valori ale Caracteristicii Membru-n-Grupa

Valori de Caracteristica (n general)

154

Modele de Informatii si Date

Student-1

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 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

Studenti

Student-2

Student-3

Fig. 4.1.1.1.1. Descrierea Clasei de Entitati STUDENTI

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 utiliznd 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 pseudolimbaj 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 Nume Prenume Varsta Sex Sectie Responsabil Grupa END

numeric 3 character 25 character 25 numeric 2 value-set (M , F) value-set (I , E , M) logical entity-set { STUDENTI }

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 Nume Prenume Varsta Sex Grupa END ENTITY GRUPA (10) BEGIN Cod Responsabil Sectie END

numeric 3 character 25 character 25 numeric 2 value-set (M , F) numeric 3

numeric 3 numeric 3 value-set (I , E , M)

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 concis - n fata unor categorii diverse de utilizatori - 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 StudentResponsabil

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 rnd 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 d efinirii formalismului general amintit. l numim general ntruct 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 binenteles 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 (Entitatea STUDENT de Entitatea GRUPA). spre a o deosebi de altele

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 ( ealizare sau R 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 cnd multimea selectata contine un singur element; Exemplu: Studentul cu Marca 101 Identificare Nediscriminanta - cnd multimea selectata poate contine mai multe elemente; Exemplu: Studentul cu Vrsta 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, urmnd 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 ntruct vom regasi n continutul ei: o o O Multime Ordonata (Multimea de Caracteristici) O Multime de Multimi Ordonate (Multimea de Entitati Obiect)

160
Definitie:

Modele de Informatii / Modelul Entitate Caracteristica - Valoare

Clasa de Entitati o Multime de Entitati Obiect, de acelasi fel, avnd 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 - Nume - Prenume - Vrsta - Sex - Sectie - Responsabil - 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, individualizndu-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 O Entitate Notiune (E i ) definirea n intensiune printr-o Lista de Caracteristici (Tupla de Nume) 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 o E i are c ij - O Entitate Notiune are Caracteristica c componenta de descriere
j

ca si

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 cnd 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 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 ntruct 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, avnd 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 rentlnit si n continuare cnd vor fi analizate notiunile de Caracteristica si Valoare.

162

Modele de Informatii / Modelul Entitate Caracteristica - Valoare

4.1.1.3.4 Definitia 1:

Caracteristica

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 reprezentnd intensiunea ei data de sensul acordat Caracteristicii. Exemple: Vrsta 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 rndul ei o Clasa de Entitati subordonata altei Clase de Entitati, pe lnga 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 O Entitate Notiune definirea n intensiune printr-un Nume de Caracteristica (nsusire sau Proprietate) 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 o

C j are v descriere

jk

- O Caracteristica are Valoarea vjk ca si componenta de

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 o o o o Caracteristica este definita ca o Clasa de Entitati Elementara, avnd ca Elemente Valorile Valorile sunt Entitati Nedecompozabile Proprietatile Caracteristicii sunt Valorile Rolul Valorii este de a descrie o Intensitate de nsusire (nsusire) 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) avnd 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: C1 C2 Cj

V1

E1

V2

Vj

Fig. 4.1.1.3.5.1 Valori Izonime

164 o

Modele de Informatii / Modelul Entitate Caracteristica - Valoare

Valori Izonime - reprezentnd 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. C1 E1 E2 C1 C1

V1

V2 Vi

En

Fig. 4.1.1.3.5.2 Valori Izotipe o Valori Izotipe - reprezentnd 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 (Constrngerile) impuse

In expresie analitica (Fig. 4.1.1.4.1.2) Multimea Valorilor V cuprinde toate valorile care pot fi ntlnite 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 o o Permite stabilirea legaturilor initiale care exista ntre Informatiile multiple care populeaza un Spatiu de Informatii Prin adaugarea de noi cunostinte se ajunge la stabilirea unor Clase de Echivalenta pe baza Criteriului de asemanare, nu numai Formala, ci si Informala Derivarea ulterioara a Atributelor ce descriu Clasele de Entitati va putea fi consolidata prin utilizarea unor Surse Comune care sa asigure Mostenirea de Proprietati Legaturile bazate pe Referinta Asociativa vor gasi terenul gata pregatit

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 Directa Directa Inversa 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 are Membru pe e j e i Poseda pe e j e j are Posesor pe e i e j e Posedat de e i e i are Descendent pe e j e j are Ascendent pe e i e i are Copil pe e j e j are Parinte pe e i

Formala

ei P ej M (e i , e j) A

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 ( osesori), Relatia de Asociere defineste, n general, pe Multimea P 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 ( ricare din multime, dar nici unul anume). Ea va contine o 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 ) 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:

Exemplu:

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 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

Clasa de Entitati n cazul n care este definit independent

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 o o Ansamblul de Entitati Notiune - Studentii unei Grupe Ansamblul de Entitati Obiect - Studentii Grupei 1 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
Element de Structura Nume Nivel

Modele de Informatii / Modelul Entitate Caracteristica - Valoare Definitie Nume Nivel

O existenta descrisa printr-un Nume General + O Multime Ordonata de Caracteristici O existenta descrisa printr-un Nume Particular + O Multime Ordonata de Valori O Entitate Notiune + O Multime de Entitati Obiect Proprietate descrisa prin Nume O Instanta (Valoare) de Caracteristica Proprietate descrisa printr-un Nume + O Multime de Valori Compatibile O Entitate Autoidentificabila STUDENT GRUPA

Exemple

Notiune

Entitate

Obiect

O Existenta Identificabila descrisa informational

Student 1 Grupa 1

Clasa Notiune Obiect Clasa

STUDENTI ={Student 1, Student 2,..} Marca Nume Prenume

Caracteristica

nsusire a unei Entitati

Valoare

Intensitate a unei nsusiri

Notiune O Relatie de Asociere ntre Ansamblu de Entitati Obiect O Clasa de Entitati Posesori si O Clasa de Entitati Membri Clasa

O Relatia de Asociere descrisa printr-un Nume General de Clasa de Entitati Posesori + Nume General de Clasa de Entitati Membri O Relatia de Asociere descrisa printr-un Nume Particular de Clasa de Entitati Posesori + Nume Particular de Clasa de Entitati Membri Un Ansamblu de Entitati Notiune + O Multime de Ansambluri de Entitati Obiect

101 Ionescu Andrei STUDENTII unei GRUPE

Studentii Grupei 1= {Student 1, Student 3,..}

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, individualizndu-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 4.1.1.4.1 Modelul formal ECV n termeni de Multimi si Relatii 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 o o o Marcarea diferentei ntre Multimile Neordonate { } si Ordonate ( ) Ilustrarea formelor de Generare a Multimilor, prin Regrupare si prin Combinare Conturarea prin suprafete texturate a continutului Claselor de Entitati, n diferitele lor contexte de aparitie, Entitate, Caracteristica, Ansamblu de Entitati Punctarea formei particulare de aparitiei a Relatiilor de Asociere ca legatura Posesor - Membri

Modele de Informatii / Modelul Entitate Caracteristica - Valoare

172

Notiune Nume Multimea Valorilor Multimea Caracteristicilor Multimea Entitatilor Notiune Caracteristica Entitate Notiune Entitate Obiect Multimea Entitatilor Obiect Clasa de Entitati Ansamblu de Entitati Notiune Ansamblu de Entitati Obiect Clasa de Ansambluri de Entitati Obiect Baza de Date Logica Baza de Date Fizica Simbol V C E Cj Ei E ir E i E i CE i A Ei s t Ei s t Ei s BDL BDF Expresie V = { v 1 , v 2 , .. , v p } C = { c 1 , c 2 , .. , c n } E = { e 1 , e 2 , .. , e n } Cj =P2R E i = (c 1 , c 2 , .. , c m ) C x C x .. x C E ir (v 1 , v 2 , .., v r .. , v e) E i C1 x C2 x .. x Cr .. x Ce E i = { ( v 1 , v 2 , .., v r .. , v e )} | v r Cr pt. r {1,2,..,e} CE i (E i , E i ) A E i x E j Ei s t A Ei s t = P 1 A { E i s 1 , E i s 2 , .. , E i s q } P ( E i ) BDL = { E 1 , E 2 , .. , E mb } BDF = { E 1 , E 2 , .. , E mb } Observatii

proiectie de rang 2 a lui R R = { cj } x V

E i are c j E ir este E i restrictie a lui A proiectie de rang 1 a lui A

Ei s

Fig. 4.1.1.4.1.2. Modelul ECV n expresii de Multimi si Relatii - Definire matematica

Modele de Informatii / Modelul Entitate Caracteristica - Valoare

VALORI V vk C
j

173
CARACTERISTICI C Ei ENTITATI Notiuni E

ENTITATE
Notiune Ei BAZA de DATE LOGICA BDL

(c 1 , c 2 , . , c i s , , c m )

C vk,j

C CARACTERISTICA Cj

CLASA de ENTITATI Ei

ENTITATE
Obiect Eir

BAZA de DATE FIZICA BDF

( v 1 , v 2 , . , v e )
Multimi de ENTITATI OBIECT E i ANSAMBLU de ENTITATI Obiecte Ei s t

CLASA de ANSAMBLURI de ENTITATI

C
is

Eis

Fig. 4.1.1.4.2.1 Modelul ECV reprezentat prin Multimi si Relatii

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 ntlnite 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, putndu-si gasi aplicatii mai largi dect 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, ntelegnd 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 o cel al Starilor unui Sistem si atunci conduce la definirea Obiectelor Abstracte 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 ( rimitive sau P 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 Prin Agregare - generarea unui Obiect Agregat dintr-o Relatie existenta ntre Multimi de Obiecte, corespunde operatiei de formare de multimi prin Combinare de Multimi Obiecte Generice

4.1.2.2.1

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.
Multimi de Obiecte Obiect Generic

{Cine, 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 }
O g Obiect Generic O c - Obiect Categorie O c este O g Generalizarea suprima diferentele ntre Categorii

Animal Persoana Verificare Vehicol Autovehicol Partener Og

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, individualizndu-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).

176 o

Modele de Informatii / Modelul Obiectelor Abstracte

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

PERSOANA Marca Nume M1 N1 M2 N2 M3 N3 M4 N4 M5 N5

Prenume P1 P2 P1 P3 P4

Vrsta V1 V2 V3 V2 V4

Tip-Persoana Student Profesor Student Profesor Angajat

Student Profesor Angajat

Obiect Abstract Generic

Obiecte Abstracte Categorie

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.

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 TIPPERSOANA Realizare a Obiectul Abstract TIP-PERSOANA, care va reprezenta o aparitie concreta de Valoare de Categorie (Profesor ca Valoare de Nume TIP-PERSOANA) Obiecte Abstracte Categorie Student Profesor Angajat

PERSOANA Marca Nume M1 N1 M2 N2 M3 N3 M4 N4 M5 N5

Prenume P1 P2 P1 P3 P4

Vrsta V1 V2 V3 V2 V4

Tip-Persoana C1 C2 C1 C2 C4

TIP-PERSOANA Cod Nume C1 Student C2 Profesor C3 Copil C4 Angajat Obiect Abstract Criteriu de Clasificare

Obiect Abstract Generic

Fig. 4.1.2.2.1.3. Generalizarea cu Obiect Abstract de tip Criteriu de Clasificare

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 TipPersoana 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), putnduse 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.
Relatii ntre Obiecte Un tip de Persoana are un Cod si un Nume O Persoana are o Marca, un Nume, un Prenume, o Vrsta 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 ) O a Obiect Agregat O c - Obiect Componenta O a are O c Agregarea suprima numele Componentelor Obiect Agregat Tip Persoana Persoana Tip Element Transport Contract Og

Fig. 4.1.2.2.2.1 Exemplificarea procesului de Abstractizare prin Agregare

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 desfasurndu-se simultan, pe mai multe nivele si conducnd la generarea, n doua planuri distincte, a Ierarhiilor de Abstractizare: Ierarhia de Generalizare Ierarhia de Agregare Abstracte

Ierarhia de Generalizare va fi alcatuita din Categoriile Obiectelor 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 VEHICOL

B1

B2

B3

Terestru C1

Aerian C2

Naval C3

Auto C4

Manual C5

Hipo C6

Persoane C7

Marfa C8

Fig. 4.1.2.3.1 Structura pe Blocuri a Categoriilor VEHICOL

Terestru

Auto

Aerian

Bicicleta C11

Camion C41

Turism C42

Avion C43

Planor C21

Marca M1

Marca M2

Marca M3

Marca M4

Fig. 4.1.2.3.2 Ierarhii de Generalizare

Modele de Informatii / Modelul Obiectelor Abstracte

181

INTRETINERE

TRANSPORT

MECANIC

Data

AUTOVEHICOL

Data

Destinatie

Incarcatura

Nume

Atelier

Numar

PRODUCATOR

Valoare

Categorie

Companie

Sediu

Fig. 4.1.2.3.3 Ierarhia de Agregare

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 ntruct atunci cnd 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. Prelund 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 o o Orice Realizare de Componentelor sale OA e reprezentata de Identificatorii Realizarilor

Realizarile Obiectelor Primitive sunt Autoidentificabile Realizarile Obiectelor Neprimitive sunt Identificabile Asociativ, prin declararea unui numar suficient de Identificatori de Componente (Atribute), care vor defini o Cheie Atributele Tipului de Obiect Abstract sunt Componentele si Categoriile (sub forma de Nume) Atributele Realizarii de Obiect Abstract sunt Realizarile de Componente si Categorii (sub forma de Valori) Identificarea OA este Asociativa, ntruct se face cu ajutorul Identificatorilor de Componente, deci a Valorilor de Componente

o o o

Un exemplu de reprezentare a unui OA n Planul Realizarilor e data n Fig. 4.1.2.4.1. AUTOVEHICOL Numar* Producator* N1 P1 N2 P2 N3 P1 N4 P3 N5 P4 Valoare V1 V2 V3 V4 V5 Categorie C42 C41 C41 C43 NULL

Identificatori de Realizari de Componente

Identificatori de Realizari de Categorii

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 o Fiecare OA are un Identificator (Cheie) Fiecare Realizare de Componenta este reprezentata de Identificatorul de Realizare (prin Referire Asociativa) si nu de Realizarea propriuzisa; Aceasta determina: Simplificarea reprezentarii asigurarea Consistentei prin eliminarea Redondanta si

184 o

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

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 ramn preponderente si ele atrag atentia, ntruct 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, punnd accent pe procesul mental de Reflectare a Realitatii Data* D1 D2 Mecanic M1 M1 MECANIC Nume* M1 M2 Atelier A1 A2

INTRETINERE Autovehicol* N1 N2

AUTOVEHICOL Numar* Producator* N1 P1 N2 P2 N3 P1 N4 P3

Valoare V1 V2 V3 V4

Categorie C42 C41 C41 C43

PRODUCATOR Companie * Sediu N1 S1 N2 S2

TRANSPORT Autovehicol* N1 N2 N3

Data* D1 D2 D1

Destinatie T1 T2 T1

Incarcatura I1 I2 I3

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:

Modele de Informatii / Modelul Obiectelor Abstracte

185

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 o o

Realizarile Obiectului Generic si ale Obiectelor Categorie, care descriu aceeasi realitate se numesc Imagini Reciproce (ale aceluiasi Obiect) In Imaginile Reciproce de OA, Componentele Comune trebuie sa fie identice 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 multime de Categorii Disjuncte ale unui OA formeaza un Bloc (vezi Fig. 4.1.2.3.1), care corespunde unui Criteriu de Clasificare Unic Avion (C43) Numar* N4

Imagini Reciproce ale OA Autovehicol N1

Producator* P4

Valoare V4

Nr-Aripi A1

Turism (C42) Numar* Producator* N1 P1 Camion (C41) Numar* Producator* N2 P2 N3 P1 AUTOVEHICOL Numar* Producator* N1 P1 N2 P2 N3 P1 N4 P3 N5 P4

Valoare V1

Nr-Usi U1

Valoare V2 V3

Tonaj T1 T2

Valoare V1 V2 V3 V4 V5

Categorie C42 C41 C41 C43 NULL

Fig. 4.1.2.5.2 Ierarhie de Generalizare n Planul Realizarilor

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 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 Realizare de OA Instanta de OA este considerata tot OA, dar n Planul Realizarilor OA Primitiv OA Nedecompozabil, care apare pe post de Atribut al unui alt OA, cu functia de : OA de tip Componenta cnd apare ca: Atribut Autoidentificabil pe post de Componenta Identificator de OA care refera de pe post de Componenta un alt OA

o o

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 Vehicol-Hipo (C6) INTRETINERE Autovehicol* N1 N2 Vehicol-Marfa (C8) Data* D1 D2 Mecanic M1 M1

Vehicol-Naval (C3)

Vehicol-Aerian (C2)

Vehicol-Manual (C5)

Vehicol-Terestru (C1)

Autovehicol (C4) N1 P1 V1 Auto C41

Vehicol-Persoane (C7)

VEHICOL Numar* N1 N2 N3 N4 N5

Producator* P1 P2 P1 P3 P4

Valoare V1 V2 V3 V4 V5

Mediu de Deplasare

Mijloc de Propulsie C4 C4 C4 C4 C4

Incarcatura

MIJLOC-PROPULSIE Cod* Nume Grad Poluare C4 Auto G1 C5 Manual G2 C6 Hipo G3

Putere Tipica P3 P2 P5

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 Fig. 4.1.2.6.1 Viziunile Multiple ale Obiectului Abstract AUTOVEHICOL

Modele de Informatii

188

COMPONENTA PRIMITIV CATEGORIE OBIECT ABSTRACT

AGREGARE

NEPRIMITIV GENERALIZARE

VALOARE de COMPONENTA VALOARE de CATEGORIE OBIECT ABSTRACT AGREGAT OBIECT ABSTRACT COMPONENTA OBIECT ABSTRACT GENERIC OBIECT ABSTRACT CATEGORIE

ATRIBUT

RELATIE NOTIUNE 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 o o Numirea OA cu ajutorul Simbolurilor Unice Precizarea Identificatorilor de Instanta pentru OA, prin intermediul Cheilor 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 nvatamnt 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. ntruct 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 o Definitie: Operatii Primitive - operatii ce actioneaza direct asupra Realizarilor de Obiecte Operatii de Utilizator - operatii ce actioneaza asupra Obiectelor Individuale

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 (ntruct o Valoare de Categorie defineste un OA Categorie, ca o submultime de Realizari ale OA Generic Fig. 4.1.2.6.1) 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) 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) Valorile Componentelor Cheie n Realizarile de Obiecte Abstracte trebuie sa fie Unice (fiecare Imagine trebuie sa fie identificabila n Planul de Agregare) Atributele oricarei Imagini trebuie sa fie Identificatori de Realizari de Obiecte Abstracte deja existente

2.

3.

4.

5.

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

Construirea Planului de Generalizare Determinarea corespondentei Obiect - Categorie mpartirea Categoriilor fiecarui obiect n Blocuri

Construirea Planului de Agregare Determinarea corespondentei Obiect Componenta

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

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 cnd 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. Cteva 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, ntruct 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 VEHICOL

Terestru

Acvatic

Amfibiu

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. VEHICOL

Terestru

Acvatic

Amfibiu

Fig. 4.1.2.10.2.1.2 Categorii Directe

194
4.1.2.10.2.2

Modele de Informatii / Modelul Obiectelor Abstracte

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 INSCRIERE CLASA

STUDENT

Curs*

An*

Instructor

Marca*

Nume

Prenume

Vrsta

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 INSCRIERE

STUDENT

CLASA

Marca*

Nume

Prenume

Vrsta

Curs*

An*

Instructor

Fig. 4.1.2.10.2.2.2 Componente Directe

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

Avnd 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. ntruct 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 ramn 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, ntruct 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 ntmpina dificultati datorita aparitiei si disparitiei lor, independenta de Valoarea Categoriei atasate (Rol n Casatorie)

Modele de Informatii / Modelul Obiectelor Abstracte

196
CNP Cod Numeric Personal

PERSOANA

CASATORIE CNP* Nume Prenume Vrsta

Ofiter al Starii Civile

Mire

Mireasa

Nas

Nasa

Numar*

Data*

Loc

Fig. 4.1.2.10.2.4.1 Definire Roluri n Casatorie (Ierarhie de Agregare) Bloc B1 Meserie Bloc B2 Rol n Casatorie

PERSOANA

B1

B2

Ofiter al Starii Civile C11

Doctor C12

Profesor C13

Balerina C14

Mire C21

Mireasa C22

Nas C23

Nasa C24

Fig. 4.1.2.10.2.4.2 Definire Roluri n Casatorie (Ierarhie de Generalizare)

Modele de Informatii / Modelul Obiectelor Abstracte

197 Balerina (C14) Nasa (C24) Nas (C23)

Profesor (13) Doctor (C12) Ofiter Stare Civila (C11)

Mireasa (C22) Mire (C21)

PERSOANA CNP* Nume N1 N2 N3 N4 N5 CASATORIE Numar* Data* N1 N2 N3 D1 D1 D2 P1 P2 P1 P3 P4

Prenume P1 P2 P3 P4 P5

Vrsta V1 V2 V3 V4 V5

Meserie C11 C12 C13 C13 C14

Rol n Casatorie NULL C23 C24 C21 C22

Loc L1 L1 L1

Ofiter Stare Civila N1 N1 N1

Mire N4 N6 N9

Mireasa N5 N7 N8

Nas N2 N2 N4

Nasa N3 N3 N5

Fig. 4.1.2.10.2.4.3 Definire Roluri n Casatorie (Ierarhie de Agregare Varianta 1)

Modele de Informatii / Modelul Obiectelor Abstracte

198

Balerina (C14) Profesor (13) Doctor (C12) Ofiter Stare Civila (C11)

PERSOANA CNP* Nume N1 N2 N3 N4 N5 CASATORIE Numar* Data* N1 N2 N3 D1 D1 D2 P1 P2 P1 P3 P4

Prenume P1 P2 P3 P4 P5

Vrsta V1 V2 V3 V4 V5

Meserie C11 C12 C13 C13 C14

Loc L1 L1 L1

Ofiter Stare Civila N1 N1 N1

Mire Pesoana N4 N6 N9

Mireasa Pesoana N5 N7 N8

Nas Pesoana N2 N2 N4

Nasa Pesoana N3 N3 N5

Fig. 4.1.2.10.2.4.4 Definire Roluri n Casatorie (Ierarhie de Agregare Varianta 2)

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 cuprinznd 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, implicnd 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 utiliznd 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 pna 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 adncire a sensurilor si semnificatiilor informatiilor implicate. Analiznd 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 o o o o o Este Forma Logica Elementara care reprezinta n planul cunoasterii rationale Reflectarea Claselor de Obiecte Reprezinta Sinteza Cunostintelor referitoare la un Obiect determinat Descrie Fiinta Obiectului, Unica si Constanta Exprima Esenta Obiectelor, prin precizarea Notelor lor Comune si Stabile Defineste o Clasa de Obiecte ca o Unitate Un Element al Ansamblului Termen: Notiune (Forma Logica) Nume (Forma Lingvistica)

ntruct 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 o o o Conceptul poate fi: Primar o o o o o Se Autodefineste Structural prin Instanta Unica (Numele se confunda cu Valoarea) Nu contine n Definitia Structurala alte Concepte Se Autoidentifica prin Valoarea Instantei Se Defineste Operational prin Metode Implicite de Sistem Apare la Nivelul Instantelor de Concepte avnd atributii de: o Derivat o o o o Se Defineste Structural cu ajutorul altor Concepte Poate avea i Instante (unde i reprezinta Cardinalitatea Conceptului) Se identifica prin conceptul de Identificator de Instanta Se Defineste Operational prin Metode Explicite de Utilizator 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 Agrega conceptele ... Se generalizeaza prin ... Este echivalent cu ... Deriva din ... prin transformarea ...

Exemple: ntreg, Real, Caracter, Sir de Caractere, Figura, Imagine etc.

202 Exemple: Vezi Formele de Derivare

Modele de Date

o 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)

Conceptul acopera definitia urmatoarelor notiuni: Clasa de Entitati Relatie Clasa de Obiecte

Conceptul acopera si notiunile de: Domeniu Caracteristica Atribut vazute ca si Clase de Entitati (vezi sectiunea 4.1.1.3.4)

Conceptul acopera si notiunea de: Valoare vazuta ca si Concept Primar

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

Conceptul se defineste sub doua aspecte: Structural ( .. are Proprietatile) sau Operational ( .. este rezultatul Transformarii), ambele pastrnd 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)

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 o La nivel Logic se face prin invocarea de Concepte prin Nume, care nsa nu implica Mostenire de Stari 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 NUME (Sir de Caractere) .. Definire prin Generalizare Conceptul 2 Categorie Unde:

Modele de Date

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

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 Conceptul 1 Conceptul 2 (Transformare) Se zice :

Derivare prin Transformare

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 putnd 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) Avnd n vedere faptul ca Transformarea se implementeaza n Concept ca si Proceduri de Utilizator, posibilitatea de generare a noi Concepte r mne a deosebit de mare. o Conceptul exclude Mostenirea de Structura de Concept. Mostenirea de Nume de Concepte nu duce dect la Redondanta si Inconsistenta posibila. Ea e nlocuita cu invocarea unui Concept n definirea altui Concept prin Nume sau a unei Instante prin Valoare 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 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: o o Mostenire prin legatura de Abstractizare prin Agregare Mostenire prin legatura de Abstractizare prin Generalizare Mostenire prin legatura de Echivalenta

o o

Modelul foloseste doar Regasirea Asociativa a Instantelor Modelul apeleaza la doua nivele de reprezentare a datelor: Reprezentare Conceptuala la Nivel Extern Reprezentare Relationala la Nivel Intern

Modelul foloseste notiunea de Concepte Persistente bazata pe memorarea Conceptelor definite utiliznd 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. Ramnem 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. Avnd 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. Ramne atunci ca Element Atomic de descriere tupla : ( Nume Obiect , Proprietate Obiect, Valoare Obiect) retinndu-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

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: o 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: Modele Stricte (Omogene) - care fac distinctie ntre Entitati, Caracteristici si Valori, tratndu-le n mod diferentiat ca: o Elemente Autoidentificabile Elemente Nedecompozabile Elemente Agregate - Valorile - Caracteristicile - Entitatile

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, defavorizndu-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, att la nivel de entitate ct si la nivel de caracteristica (exemplu: Sisteme de Gestiune Baze de Date) o Pretind Structura Ferma a datelor Impun Omogenizare fortata Realizeaza Performante Ridcate la prelucrari de Volum Mare Limiteaza utilizarea procedurilor de Adaptabilitate Inteligenta

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 o

Modele de Date

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

Model de Date

Gs S

Gr

Baza de Date Logica Ss Sc Ol

D Legenda

Baza de Date Fizica

On

Os

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) S s - Lista de Categorii, Proprietati, Relatii S c - Lista de Restrictii D - Realizare de BDL (Baza de Date Fizica) O - Operatii de Acces Admise LMD (Limbaj de Manipulare a Datelor) 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

Modele de Date

209

o o

Sa ofere tuturor procedurilor Facilitatile de Acces la Date conform criteriilor de performanta preconizate 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) mbogatirea Semanticii atasate Structurilor de Informatii si Date prin ncorporarea Operatiilor Compatibile cu Structurile Proiectate n corpul Modelului de Date Gruparea Obiectelor diverse (Structuri, Constrngeri, Reguli de Integritate, Restrictii, Operatii) n Modelul de Date Corelarea Conditiilor de Definire a Obiectelor Multiple Instrumente Formalismelor Grafice performante pentru reprezentarea si Inversa

Posibilitati sporite de Control a Structurilor Complexe o o

Facilitati de Adaptabilitate la Modificari crescute o o

Procese de Generare Directa (Engineering) (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 o o Descrierea Structurii Descrierea Restrictiilor 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 S c. Regulile de Specificare a Restrictiilor vin sa completeze semantica acordata datelor continute n structura, preciznd 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, implicnd acele Date, Dependente Functional de Date Reale si care se memoreaza n Baza de Date din motive de performanta la regasire, avnd nsa nevoie de un Control Procedural al Consistentei Restrictii Implicite Denumite si Restrictii de Sistem (Inerente), ele sunt legate de Tipul de Model utilizat, verificarea lor caznd 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

Restrictiile sunt de doua feluri Implicite si Explicite:

Modelele sunt cu att mai Restrictive , cu ct Restrictiile Implicite sunt mai multe, iar Restrictiile Explicite sunt mai putine. Analiznd 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 Dinamica prin Specificare Predicativa 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 o Consistenta Realizabila (posibil de satisfacut) Realista Bine Formata Realizata Realizabila Invalida - daca C i satisface proprietatile sintetice - daca C i e adevarata pentru starea curenta a BD (DBS k ) - daca exista o stare DBS care satisface C i - daca nu exista nici-o stare DBS care satisface C i

Proprietati detaliate ale unei Restrictii C i

Consecventa Logica - C i e o consecventa logica a unui set de alte restrictii C1 , .. , C n daca C i e satisfacuta cnd 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 o o o o o Consistenta a unei stari DBS satisfacute
k

a BD - daca toate Restrictiile Schemei sunt a BD - daca nu toate Restrictiile Schemei sunt
k

Inconsistenta a unei stari DBS satisfacute

Schema satisfacuta a unei stari DBS satisfacute

- daca toate Restrictiile Schemei sunt

k

Schema realizabila a unei BD - daca exista unele stari DBS schema O Schema Buna pentru o BD - o Schema care e:

care nu satisfac

Schema inconsistenta a unei BD - daca nici-o stare DBS k nu satisface schema Realizabila (poate fi satisfacuta) Disponibila pentru Specificatii Precise Disponibila pentru Validare

212

Modele de Informatii si Date

Entitati Proprietati Primare Structura Obiectelor Relatii

Integritatea Proprietatile Obiectelor Proprietati Secundare Integritatea Operationala Structurala

Integritatea Actualizarii Obiectelor Primitive

Integritatea Actualizarii Obiectelor Individuale

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 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 Orientarea pe Evenimente a Operatiilor efectuate asupra Datelor sunt stimulate de concentrarea lor n jurul Modificarilor operate n Structura Prelucrarile Tranzactionale, indispensabile n contextul structurilor complexe prelucrate n regim de multiacces, cer o Viziune Globala asupra ntregii colectii de Date 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

o o

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 dect 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), avnd 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 cstigarea 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 cmpuri care se memoreaza n Baza de Date), denumite Segmente de Articole, care prin reasamblare pot construi Articolele Logice (ansambluri de cmpuri 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 cmpurilor de date comune altor segmente si gruparea lor ntr-un Segment Ascendent Construirea unei structuri de date de forma unui Arbore de Segmente, putndu-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 Stng Subarbore Drept) Realizarea unei Structuri de Date Contextuale cu Context Unic reprezentat de drumul de la Radacina Arborelui pna 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

Memorie externa Segment tip 1 Segment tip 2 Segment tip 2 Segment tip 1 Segment tip 2 Segment tip 2 Segment tip 2 Segment tip 1 Segment tip 2

B1 P1 P2 B2 P1 P2 P3 . .

N1 N1 N2 N2 N1 N2 N3 . .

C1 C1 C2 C2 C1 C2 C3 . .

O1 V1 V2 O2 V1 V2 V3 . . . . S1 S2 S3 Q3 Q4 Q5 S1 S2 Q1 Q2

Beneficiarul 1 Produsul 1 contractat de Beneficiarul 1 Produsul 2 contractat de Beneficiarul 1 Beneficiarul 2 Produsul 1 contractat de Beneficiarul 2 Produsul 2 contractat de Beneficiarul 2 Produsul 3 contractat de Beneficiarul 2

B1
Articol Logic

N1

C1

O1

P1

N1

C1

V1

S1

Q1

Memorie interna

Produsul 1 contractat de Beneficiarul 1

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 Cmpuri de Date (Fig. 4.2.2.1.2): BENEFICIAR - B Cod Bi Nume (Denumire) - Ni Culoare - Ci Oras -Oi PRODUS - P Cod - Ci Nume (Denumire) - Ni Culoare - Ci Pret - Vi Stoc - Si Cantitate - Qi

Fig. 4.2.2.1.2 Descrierea Segmentelor BENEFICIAR (B) si PRODUS (P) ntruct 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.

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. *
c B

*
c

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: 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 Model simplu si natural de reprezentare a Relatiei Fundamentale Ierarhie (1n) Posibilitatea de utilizare si a suportilor secventiali de memorare a datelor (benzi magnetice), in calitate de suporti neadresabili

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 ct mai multe Structuri reale, complexe de date. Structurile care le realizeaza ambele Modele ramn nsa statice n timp, reconfigurarea lor implicnd 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 ) Identificator Codul Produsului (Pj) Descriptori Denumire, Culoare, Pret, Stoc (Nj, Cj, Vj, S j) Referinta de Adresa la Setul de Beneficiari Contractanti (rcj)

PRODUS

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

Memorie externa Beneficiarul unei Pozitii Contractuale rc 1 rc 3 BENEFICIARI

B1 B2 .

N1 N2 .

C1 C2 .

O1 O2 .

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

rc 2 Pozitii Contractuale ale unui Beneficiar POZITII CONTRACTUALE rc 4 rc 5 Produsul unei Pozitii Contractuale

rb 1 rb 1 rb 2 rb 2 rb 2

Q1 Q2 Q3 Q4 Q5 .

rp 1 rp 2 rp 1 rp 2 rp 3

rc 3 rc 4 -

P1 P2 P3 .

N1 N2 N3 .

C1 C2 C3 .

V1 V2 V3 .

S1 S2 S3 .

rc 1 rc 2 rc 5

Pozitii Contractuale ale unui Produs

PRODUSE Memorie interna

rc 1

B1 N1
rb 1

N1 C1 Q1

C1 V1
rp 1

O1 S1
rc 3 rc 1

Beneficiar Produs

P1
rc 2

Pozitie Contractuala

Fig. 4.2.3.1.1 Componentele Modelului Retea

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 o Valorile Caracteristicilor Simple ansamblul Insusirilor Descriptoare ale Claselor de Entitati 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 ncepnd cu rci din Beneficiar se citeste Produsul punctat de Referinta de Adresa rpk din Pozitia Contractuala n curs de prelucrare 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)

Reconstituirea Ierarhiei Inverse (Beneficiarii care au contractat un Produs)

220

Modele de Date / Modelul Retea

Pentru fiecare Articol de Legatura din Lista de Articole ncepnd cu rci din Produs se citeste Beneficiarul punctat de Referinta de Adresa rbj din Pozitia Contractuala n curs de prelucrare BENEFICIAR m Produsele contractate de un Beneficiar n PRODUS Beneficiarii care au contractat un Produs

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 descrisa n Spatiul Informatiilor (Fig. 4.2.3.1.2), precum si dubla -n 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 POZITIECONTRACT se afla nregistrat n doua Liste de Articole: POZITIILECONTRACTUALE ale unui BENEFICIAR (Legatura B.c C.b) POZITIILECONTRACTUALE ale unui PRODUS (Legatura P.c C.p)

BENEFICIAR 1 Produsele contractate de un Beneficiar n

PRODUS 1 Beneficiarii care au contractat un Produs n

POZITIE CONTRACTUALA

Fig. 4.2.3.1.3 Diagrama Simbolica B-P-C

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. B *
c

P
t C o

*
c

*
b

*
p q

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). 1

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).

222

Modele de Date / Modelul Retea

NOD 1 Arce n Iesire n ARC 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

1 Arce n Intrare n

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 strnsa 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

Modele de Date NOD

Nume Identificator 1 2 3 4 5 6 7 8 Descriptor1 D11 D12 D13 D14 D15 D16 D17 D18 Caracteristici Descriptor2 D21 D22 D23 D24 D25 D26 D27 D28 .. .. .. .. .. .. .. .. Primul Arc n Intrare NULL Arc 12 Arc 13 Arc 24 Arc 25 Arc 36 Arc 57 Arc 58 Primul Arc n Iesire Arc 12 Arc 24 Arc 35 NULL Arc 57 NULL NULL NULL

223

Nodk

Nod 1 Nod 2 Nod 3 Nod 4 Nod 5 Nod 6 Nod 7 Nod 8

Fig. 4.2.3.1.4 Descrierea Nodurilor ca Articole Principale

Nodi

ARC
Nume Identificator Nod Nod Ascendent Descendent 1 2 1 3 2 4 2 5 3 5 3 6 5 7 5 8 Caracteristici Descriptor1 (Intensitate de Legatura) D12 .. D22 .. D23 .. D24 .. D25 .. D26 .. D27 .. D28 .. Arc Succesor n Intrare NULL NULL NULL Arc 35 NULL NULL NULL NULL Arc Succesor n Iesire Arc 13 NULL Arc 25 Arc 35 Arc 36 NULL Arc 58 NULL

Nodj

Arc 12 Arc 13 Arc 24 Arc 25 Arc 35 Arc 36 Arc 57 Arc 58

Fig. 4.2.3.1.4 Descrierea Arcelor ca Articole de Legatura

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, orientndul 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, avnd 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

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 (v 1 , v2 .. vi ), astfel nct 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
Clasa de Entitati Obiecte Notiune

Modelul Relational
Relatie Definita (Tabela de Baza) Instantiata (Vedere)

Spatiul Datelor
Fisier Omogen Memorat Definit

Entitate

Notiune Obiect Nume

Tupla

Logica Fizica Domeniu Atribut

Articol

Logic Fizic Tip

Caracteristica Valoare

Data

Nume Valoare

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 Rndurile Tabelei si Tuplele Relatiei pe de alta parte. Exemplu: Sa reluam exemplul din Fig. 2.4.2, COMPUS COMPONENT dndu-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 Valori {A, B, C, D, E, F} {N1, N2, N3, N4, N5, N6} {C1, C2, C3} {G1, G2, G3, G4} ATRIBUT Relatie Nume Cod PRODUS Cod-Compus ANSAMBLU ANSAMBLU Cod-Component Nume PRODUS Culoare PRODUS Greutate PRODUS

Nume Cod Nume Culoare Greutate

Tab. 4.2.4.2 Domeniile Structurii Relationale COMPUS COMPONENT PRODUS COD* A B C D E F NUME N1 N2 N3 N4 N5 N6 CULOARE C1 C2 C3 C1 C3 C1 GREUTATE G1 G2 G2 G3 G4 G1

Tab. 4.2.4.3 Relatia PRODUS ANSAMBLU COD-COMPUS* A B B B C C COD-COMPONENT* B C D E F E CANTITATE Q1 Q2 Q3 Q4 Q5 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 observatii: Structuri Relationale de Date se pot face urmatoarele

Domeniul descrie natura unei Multimi de Valori (Nume, Tip, Restrictii impuse) Relatia se descrie ca o Multime de Atribute provenite din Domenii anterior definite

P
c

AN P-PRODUS AN-ANSAMBLU c-cod n-nume cl-culoare g-greutate cs-cod-compus cp-cod-component q-cantitate

*
n

cl

cs g

cp

Fig. 4.2.4.6 Arbore de Structura PRODUS ANSAMBLU Relatiile pot fi categorisite n: o o Relatii ce stabilesc doar legatura ntre Domenii (ex. PRODUS) 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 dect 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

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 Tupl a 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). 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. Ordinea Domeniilor e indiferenta Definirea Relatiei ramne 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. Toate Atributele sunt Date Elementare (Nedecompozabile) Prin aceasta restrictie, care cere ca, n Tabelele de Baza, Cmpurile 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, ntruct 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 Beneficiar
B1 B1 B1 B1 B1 B2 B2 B3 B4

Obligatie Produs Cantitate

P1 P2 P3 P4 P5 P1 P2 P2 P5 Q1 Q2 Q3 Q2 Q4 Q5 Q1 Q3 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
B1 B1 B1 B1 B1 B2 B2 B3 B4

Produs
P1 P2 P3 P4 P5 P1 P2 P2 P5

Cantitate
Q1 Q2 Q3 Q2 Q4 Q5 Q1 Q3 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 dect 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 oricnd 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 ntlni 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 o Numele Domeniilor Numele Relatiei Numele Atributele (cu Domeniile asociate) Restrictii de Identificare Declarare Chei Candidate o o Cheia Primara Chei Candidate (Alternative)

Restrictiile de Integritate

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 o De Corectitudine (tipuri, limite, liste de valori etc.) 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 Proprie Neredondanta n Chei Candidate - 1 Cheie Primara - n-1 Chei Candidate Straina Compuse Simpla Compusa 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 ramne 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 ramna 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. m Atribute Componente 1 Atribut Component m Atribute Componente 1 Cheie Candidata Compusa Simpla Compusa Simple m Atribute Componente 1 Atribut Component m Atribute Componente 1 Atribut Component

232

Modele de Date / Modelul Relational / Cheile Relatiilor

4.2.4.4.1

Reguli de Integritate a Relatiilor

Avnd 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). Integritatea de Referire Cheia Straina poate fi nedefinita, dar atunci cnd ea e definita, Valoarea ei trebuie sa faca parte din Ansamblul Valorilor memorate n Cheia Primara pe care Cheia Straina o refera. Identificare, Acces si Ordonare n Structuri Relationale

4.2.4.4.2

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 o o Chei Primare - desemnate sa asigure Integritatea Entitatii (posibilitatea de localizare unica a fiecarei Entitati Obiect (Tuple) Chei Straine - desemnate sa asigure Integritatea de Referire 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.

B
c

BENEFICIAR c - Cod n - Nume l - Localitate

LOCALITATE c - Cod n - Nume 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).

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 nct 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 r efuzata, sistemul mentinnd 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

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 c usurinta parametrizate si introduse ca Module de u 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 ( RACLE, INFORMIX, SYBASE, dar chiar si VISUAL FOX) O 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. ntruct 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 ( daugari, Stergeri, Modificari), la A 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
4.2.4.4.2.2

Modele de Date / Modelul Relational / Identificare, Acces si Ordonare

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 strns 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. ntruct 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), mentinndu-se posibilitatea de demarcare ulterioara (comanda RECALL) cu reintegrarea Tuplei n Tabela de Baza 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 ramne unica n Baza de Date, ea este nsa vazuta prin intermediul unei anumite Zone de Lucru 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 avnd 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)

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 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, indicnd 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, permitnd 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) Cuantificare - definirea Ariei de Cautare data de Multimea de Tuple pe care se face cautarea pe baza Ordinii Tuplelor n Tabela de

Definirea unei Submultimi de Tuple se realizeaza prin doua procedee:

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 o o o ALL - Toate Tuplele din Tabela de Baza REST - Restul Tuplelor, ncepnd cu Pozitia Curenta NEXT n - Urmatoarele n Tuple 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 WHILE expresie (Ct Timp Expresia e Adevarata) - Toate Tuplele consecutive din Aria de Cautare, ce satisfac Conditia Logica continuta n Expresie, ncepnd cu Tupla Curenta si terminnd la prima Tupla care nu mai ndeplineste Conditia

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) Interna - pe baza Numarului de nregistrare (comanda GO) 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

Directa - cautarea se realizeaza prin Adresare Rapida o o

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 pna n prezent problema Independentei Procedurilor fata de Strategiile de Acces nu este n totalitate rezolvata, ntruct 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 oricte 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) o o Indecsi Densi - localizeaza o Tupla Indecsi Nedensi - localizeaza o Multime de Tuple 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) 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, putnd include si apeluri de Functii de Sistem sau de Utilizator . 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

Tabele de Index dupa Numarul Indecsilor Memorati ntr-un Fisier de Indecsi

Tabele de Index dupa Complexitatea Expresiei de Indexare

Tabele de Index dupa Numarul Tuplelor care participa la indexare

Tabele de Index dupa Modul de Tratare al Omonimelor (Tuple avnd aceeasi Valoare a Expresiei de Indexare) Indecsi Neunici - participa toate Omonimele Indecsi Unici - participa doar Prima Tupla ntlnita dintr-o Multime de Omonime 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

Tabele de Index dupa Modul de Organizare a Tabelei de Baza

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 rnd 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 cnd 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. Cnd 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 o o o o o -

Modele de Date / Modelul Relational / Identificare, Acces si Ordonare

PRIOR precedenta tupla FIRST prima tupla LAST ultima tupla ABSOLUTE i tupla cu Numarul Intern de Identificare i 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 cnd: Tabela de Baza este construita ca un Fisier Secvential de nregistrari Adaugarea de Tuple se efectueaza printr-o scriere de nregistrari la sfrsitul 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 sfrsitul 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 ntruct 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, ntruct este solicitata foarte frecvent n procesul de actualizare pe post de Cheie de Acces (inclusiv pentru Cautarea n Vecinatate) Atributul Nume, prezent n majoritatea Tabelelor, daca ndeplineste si conditia de a fi discriminat (Cheie Candidata) poate reprezenta o alternativa, atunci cnd principalele Rapoarte Finale folosesc aceasta Ordine de Inspectie 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

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)

ntruct Ordinea Logica se implementeaza prin Structurile Auxiliare de tip Index, o Tabela de Baza poate admite oricte 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, putnd 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 suprancarcarii cu Indecsi Activi a Listelor de Indecsi. ntruct 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) avnd att ca Operanzi, ct si ca Rezultat, chiar Constructorul de Structura Relatia, ceea ce va permite n orice moment concatenarea Expresiilor Relationale ntruct 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 avnd 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 N1 N2

Cont C1 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* P1 P3 P3 P2 P3 P4 Oras O1 O1 O1 O2 O2 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 o Precizarea detaliata a Secventei de Operatii din Algebra Relationala, care trebuie executate pentru a obtine Rezultatul Specificarea Rezultatului prin Formularea unei Definitii a Rezultatului cerut n termenii Calculului Relational, lasnd sistemul (SGBD) sa stabileasca secventa de operatii ce trebuiesc executate pentru obtinerea Rezultatului

ntruct 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 o Prin precizarea Operatiilor pe Multimi (Reuniune, Intersectie, Negare, Diferenta etc.) Prin definirea unui Predicat care sa constituie nsusirea Definitorie a Rezultatului, privit ca o noua Multime Proceduralitate bazata pe enumerarea succesiva a operatorilor de Algebra Relationala Neproceduralitate bazata pe specificarea cu ajutorul Calculului Relational a Rezultatului (ntotdeauna o Relatie) Metoda bazata pe Algebra Relationala

Diferenta dintre cele doua cai prezentate anterior este cea ntre: o o

4.2.4.5.1

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 avnd drept Operanzi Relatii, si care produc de fiecare data ca Rezultat o noua Relatie. Avnd 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

Traditionali pe Multimi

Operatori Relationali

REUNIUNE INTERSECTIE DIFERENTA PRODUS CARTEZIAN SELECTIE PROIECTIE

Specific Relationali

REUNIRE (CUPLARE)

IMPARTIRE

UNION INTERSECT MINUS TIMES SELECT PROJECT = < JOIN > NATURALA POSIBILA EXTERIOARA DIVIDEBY

R1 R2 R1 R2 R1 \ R2 R1 x R2 ls (R1 ) lp (R1 ) (R1 ) (e1 = e2) (R2 ) (R1 ) (e1 < e2) (R2 ) (R1 ) (e1 > e2) (R2 ) (R1 ) (e) (R2 ) (R1 ) p (e) (R2 ) (R1 ) x (e) (R2 ) 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

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 ( 1 ALIASES R1 ) si se aplica R 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 o o o o o o

este un operator binar este un operator comutativ rezultatul contine toate Atributele ce refera Domenii Comune gradul relatiei Rezultat este acelasi cu gradul relatiilor initiale relatia Rezultat va contine tuple care exista n prima sau a doua Relatie Initiala tuplele Duplicate vor fi eliminate din Rezultat, folosind Integritatea de Identificare (vezi sectiunea 5.2.4.4.1) 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* C1 C2 C3 C4 C5 C6 STUDENT Marca* M1 M2 M3 M4 M5 M6 Nume N1 N2 N3 N4 N5 N6 Prenume P1 P2 P3 P1 P3 P1 Sex S1 S2 S2 S1 S2 S1 Grupa G1 G2 G2 G3 G4 G1 NUME N1 N2 N3 N4 N5 N6 Limba-predare L1 L2 L1 L1 L2 L1

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* M1 M12 M13 Nume N1 N12 N13 Prenume P1 P12 P13 Sex S1 S2 S1 Titlu T1 T2 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 o o o o o este un operator binar este un operator comutativ rezultatul contine toate Atributele ce refera Domenii Comune gradul relatiei Rezultat este acelasi cu gradul relatiilor initiale relatia Rezultat va contine numai tuplele care exista n ambele Relatii Initiale 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

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: Considernd 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 o o o o o este un operator binar este un operator necomutativ rezultatul contine toate Atributele ce refera Domenii Comune gradul relatiei Rezultat este acelasi cu gradul relatiilor initiale relatia Rezultat va contine numai tuplele care exista n prima Relatie si nu exista n a doua 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: Considernd 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 o o este un operator binar este un operator comutativ 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)

ntruct 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

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: < condi tie 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 o o o este un operator unar Conditia de Selectie e construita numai cu Valori de Atribute apartinnd unei singure Tuple gradul relatiei Rezultat este acelasi cu gradul relatiei initiale numarul de tuple n Rezultat este mai mic sau egal cu numarul tuplelor din relatia initiala

Exemplul 7: Considernd 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

de relatie >)

Forma generala a operatiei este:

< lista de attribute de proiectie > ( < nume

unde - desemneaza operatorul PROIECTIE < lista de attribute de proiectie > - este Lista Atributelor de Definitie pentru relatia Rezultat Defineste o noua relatie avnd 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 o este un operator unar tuplele Duplicate vor fi eliminate din Rezultat, pastrnd Integritatea de Identificare (vezi sectiunea 4.2.4.4.1) n Relatia Rezultat Lista de Atribute de Proiectie e continuta n Lista Atributelor de Definitie ale relatiei initiale gradul relatiei Rezultat este egala cu numarul atributelor cuprinse n Lista de Atribute de Proiectie

o o

Modele de Date / Modelul Relational / Manipularea Datelor

253

numarul de tuple n Rezultat este mai mic sau egal cu numarul tuplelor din relatia initiala

Exemplul 8: Considernd 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 o o o o o o este un operator unar este un operator comutativ Rezultatul contine numai Valori de Atribute din Tuplele care satisfac Conditia de Reunire tuplele Duplicate vor fi eliminate din Rezultat, pastrnd Integritatea de Identificare (vezi sectiunea 5.2.4.4.1) n Rezultat tuplele cu Valori Nule pentru Atributele din Conditia de Reunire vor lipsi din Rezultat gradul relatiei Rezultat este egala cu (n + m), unde n este numarul tuplelor n relatia 1 si m este numarul tuplelor n relatia 2 numarul de tuple n Rezultat este mai mic sau egal cu numarul tuplelor din Produsul Cartezian al relatiilor initiale

Exemplul 9: Considernd 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 Reunire EGALA Reunire MAI MICA Reunire MAI MARE Reunire NATURALA

Subvarianta de Operator de Reunire

Mnemonica

Descriere

EQUIJOIN LESSJOIN GREATHERJOIN NATURAL JOIN STANGA LEFT OUTER JOIN RIGHT OUTER JOIN FULL OUTER JOIN POSSIBLE JOIN

Operatorul de Comparatie din Conditia de Reunire este = Operatorul de Comparatie din Conditia de Reunire este < Operatorul de Comparatie din Conditia de Reunire este > Conditia de Reunire contine doar Atribute Omonime din relatiile initiale (membrul drept al conditiei poate fi omis) Rezultatul contine toate tuplele din relatia din Stnga (cu valori NULE n locul atributelor din tuplele corespondente care lipsesc la Dreapta) Rezultatul contine toate tuplele din relatia din Dreapta (cu valori NULE n locul atributelor din tuplele corespondente care lipsesc la Stnga) Rezultatul contine toate tuplele din ambele relatii (cu valori NULE n locul atributelor din tuplele corespondente care lipsesc la Stnga sau la Dreapta) Conditia de Reunire e adevarata doar pentru Valori Nedefinite de Atribute

Reunire EXTERNA

DREAPTA COMPLETA

Reunire POSIBILA

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 o o R Rezultat R1 Dempartit 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 nct {am+n} \ {an} = {am } , atunci: operatorul IMPARTIRE construieste o relatie R ({am }), definita pe Lista de Atribute {am } si avnd 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 B1 B1 B1 B1 B2 B2 B3 B4 P1 P2 P3 P4 P5 P1 P2 P2 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 o o o o este un operator binar este un operator necomutativ Lista de Atribute reprezinta DIFERENTA dintre Listele de Atribute ale Relatiilor Initiale gradul r elatiei Rezultat este egal cu diferenta gradelor Relatiilor Initiale 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
4.2.4.5.1.5
(Condition)

R2 = ( Condition) (R1 x R2 )

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 SELECTIE PROIECTIE Simbol n Expresii Clauza de Limbaj WHERE expresie booleana [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 - atribuire - lista-atribute nume-sinonim ALIASES nume-relatie nume-relatie [lista-atribute] := expresie-algebrica 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 primitiva WHERE expresie-booleana nume-relatie nume-sinonim (expresie-algebrica) - proiectie primitiva primitiva [lista-atribute] - operatie-infixata - operator-infixat proiectie operator-infixat proiectie 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 cnd 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 cnd nu se foloseste descrierea Cererilor prin Expresii de Algebra Relationala, corespondentele prezentate introduc o disciplina necesara n Prelucrarea Procedurala a Structurilor Relationale, prin educarea gndirii 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 o o Conditiile de Selectie Listele de Atribute 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? R1 =

Solutie n pasi utiliznd rezultatele Intermediare R1 si R2:

(BENEFICIAR.Nume,CONTRACT.Produs) (BENEFICIAR

< BENEFICIAR.Cod=CONTRACT.Beneficiar > CONTRACT)

R2 = < R1. Produs =P2 >(R1) R=

< R2. Nume >(R2)

R=

Solutie directa, ntr-un singur pas: < CONTRACT.Produs =P2 (BENEFICIAR

< BENEFICIAR.Cod=CONTRACT.Beneficiar > CONTRACT))

< BENEFICIAR. Nume >(

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 cteva concluzii legate de Limbajului de Manipulare bazat pe Algebra Relationala: o o o Este putin familiar Utilizatorului Final confruntat adesea cu dificultatea de decizie n ceea ce priveste Corectitudinea Expresiilor pe care le utilizeaza Se impune ca un mijloc de evaluare a Completitudinii Relationale a altor limbaje Ramne 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

Avnd n vedere rigurozitatea de definire a Limbajului de Manipulare bazat pe Algebra Relationala, el ramne 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 att de puternic ca si cel bazat pe Algebra Relationala (care permite redactarea unei singure Expresie de Calcul pentru aflarea Rezultatului oricarei Cereri). 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

Semirelationale SGBD-uri care ofera:

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. Utiliznd Operatiile LogicoLingvistice 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 SUBIECT (univers de discurs) - 1 Subiect MULTIME - n Subiecte RELATIE ENUNT cu Subiect Determinat cu Subiect Nedeterminat Nedeterminat

CONSTANTA LIBERA (fara cuantificatori) LEGATA (cu cuantificatori)

VARIABILA

PROPOZITIE

PREDICAT (proprietate)

PREDICAT

Tab. 4.2.4.5.2.1.1 Structura Enuntului n Limbajul Logic

Modele de Date / Modelul Relational / Manipularea Datelor

263 Limbajul LOGICII PROPOZITIILOR Limbajul LOGICII PREDICATELOR

Enunturi Initiale

Operatii Logico-Linvistice

PROPOZITII Enunturi Finale PREDICATE

Fig. 4.2.4.5.2.1.2 Structura Enuntului n Limbajul Logic

Operatori LOGICI Operatori Logico-Lingvistici

NEGATIA CONJUNCTIA DISJUNCTIA IMPLICATIA ECHIVALENTA EXISTENTIALI UNIVERSALI

CUANTIFICATORI

Tab. 4.2.4.5.2.1.3 Clasificarea Operatorilor Logico- Lingvistici

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 nct relatie tupla-logica lista-atribute { tupla-logica : predicat } (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-deCalcul-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

Variabilele de Tuple Variabile ce inspecteaza multimea Tuplelor unei Relatii Exemple: X Tupla X X.A Valoarea Atributului A n Tupla X

Conditii Expresii Booleene avnd ca elemente: Constante, Variabile si Operatori Logici x 1 OC x 2 unde: x este:

Modele de Date / Modelul Relational / Manipularea Datelor

265

o o o

Constanta Atribut din Relatie (X.A)

OC este Operator de Comparatie (=, <, >, .. )

Formule Bine Construite (FBC) Expresii cu urmatoarele proprietati: Contin ca elemente: Conditii Operatori Logici Cuantificatori Orice Conditie e FBC Daca f e FBC, atunci: o o ( f ) e FBC NOT ( f ) e FBC

Respecta urmatoarele Reguli:

Daca f si g sunt FBC, atunci: o o (f AND g) e FBC (f OR g) e FBC X ( f ) e FBC X ( f ) e FBC

Daca f e FBC si X e Variabila Libera, atunci: o o

4.2.4.5.2.2.2

Nimic altceva nu e FBC

Variabile Libere si Legate

Variabilele Libere sunt Variabile Necuatificate pe cnd 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. 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 raspunznduse 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 raspunzndu-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 o Intr-o Conditie toate Variabilele de Tuple (VT) sunt Variabile Legate Variabilele de Tuple (VT) n constructiile FBC de tipul: o (f) NOT ( f )

sunt Libere sau Legate dupa cum sunt n f. Variabilele de Tuple (VT) n constructiile FBC de tipul: o ( f AND g ) ( f OR g )

sunt Libere sau Legate dupa cum sunt n f sau n g. 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 o Produsul Cartezian se face cu Tuplele identificate de Variabilele de Tuple X x Y x .. x Z Formula f joaca simultan rolurile de: o Conditie de Selectie pentru determinarea valorilor Variabilelor de Tuple Conditie de Reunire pentru definirea unei submultimi a Produsului Cartezian

Proiectia se face pe Lista de Atribute A, B, .. , C

268
4.2.4.5.2.2.4 4.2.4.5.2.2.4.1

Modele de Date / Modelul Relational / Manipularea Datelor

Implementare Calcului Relational al Tuplelor 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, utiliznd 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 avnd 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, avnd 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, utiliznd aceleasi Variabile de Tuple, se normalizeaza forma de exprimare a Predicatului prin gruparea cuantificatorilor ( orma f 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 cteva observatii:
4.2.4.5.2.2.4.2

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)
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 raspndit 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 avnd 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, jucnd n acest caz rol dublu: o o 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: Conditie de Selectie Conditie de Reunire

272 SELECT Cod FROM B

Modele de Date / Modelul Relational / Manipularea Datelor

Regasire Filtrata (cu Predicat) Codurile pentru toti BENEFCIARII din Orasul O1 avnd 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, avnd 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 o

Adevarat daca Multimea de Tuple returnata de blocul SELECT urmator este NEVIDA 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 ntruct 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) 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 SELECT Codp FROM C

Modele de Date / Modelul Relational / Manipularea Datelor

WHERE C.Codp = P2 o Operatii de Actualizare Operatiile de Actualizare nu prezinta interes pentru fizionomia ECR n CRT. De aceea se fac doar cteva 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 = B1AND 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 o -

Este riguros definit n detaliu si facut public Inovatiile eventuale trebuie sa astepte validarea Comisiilor de Standardizare 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

Limbajul SQL se preteaza la numeroase variante de utilizare si extensii posibile: o

Componente de Software apartinnd 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. Incorporarea Bibliotecilor de Functii Clauze speciale pentru Editare Date Facilitati de pregatire a Rapoartelor Finale Introducerea facilitatilor de Prelucrare Procedurala (Extensia PL SQL)

Extensii posibile

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

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: o D X Valoarea X din Domeniul D Conditii Expresii Booleene avnd ca elemente: Constante, Variabile si Operatori Logici Comparatii Simple x 1 OC x 2 unde: o x este: o Constanta Valoare de Domeniu (DX)

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 o Constanta Variabila de Domeniu

Interpretare Tuplele din Relatia R care satisfac toti Termenii (membrii) Conditiei

Formule Bine Construite (FBC) Expresii cu urmatoarele proprietati (identice cu cele din CRT): Contin ca elemente: Conditii Operatori Logici Cuantificatori Orice Conditie e FBC Daca f e FBC, atunci: o o ( f ) e FBC NOT ( f ) e FBC

Respecta urmatoarele Reguli:

Modele de Date / Modelul Relational / Manipularea Datelor

279

Daca f si g sunt FBC, atunci: o o (f AND g) e FBC (f OR g) e FBC X ( f ) e FBC X ( f ) e FBC

Daca f e FBC si X e Variabila Libera, atunci: o o

4.2.4.5.2.3.2

Nimic altceva nu e FBC

Variabile Libere si Legate

Definirea Variabilele Libere si Legate este aceeasi ca n cazul CRT. Specifica ramne 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 o Produsul Cartezian se face cu Tuplele identificate de Variabilele de Domeniu D, E, .. ,F prin intermediul Conditiilor cu Termeni din f 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
4.2.4.5.2.3.4 4.2.4.5.2.3.4.1

Modele de Date / Modelul Relational / Manipularea Datelor

Implementare Calcului Relational al Domeniilor Exemple de ECD

Ca exemplu de implementare a Expresiilor de Calcul al Domeniilor (ECD) se prezinta cteva 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 avnd Tipul 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)

OrasX, TipbY WHERE B (Oras : OrasX, Oras : O1, Tip : TipbY, Tip : T3)

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, considernd 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 dect 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: Exemplu: Utilizatorul introduce Numele Relatiei Sistemul raspunde afisnd Lista de Atribute de Definitie Utilizatorul introduce Valorile din Conditiile de Filtrare Sistemul raspunde afisnd Tuplele care satisfac Conditia de Filtrare Utilizatorul introduce Valorile din Conditiile de Reunire Sistemul raspunde afisnd Tabela Rezultat cu Lista de Atribute de Definitie mpreuna cu Tuplele care satisfac Conditia de Reunire 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 ncarcnd Tabela cu Valori din Sursa de Date, care corespund Valorilor introduse de Utilizator

Conventii de Limbaj: P.nume-Valoare-de-Exemplu Afiseaza Valoare pe Coloana P. ALL Afiseaza toate Valorile pe Coloane VsIntroducere Valoare de Exemplu (sSimbol de Identificare Valoare Variabila) V Introducere Valoare Constanta

282

Modele de Date / Modelul Relational / Manipularea Datelor

Regasire Simpla Codul tuturor PRODUSELOR Contractate: C Se remarca: Comanda de afisare P. Valoarea de Exemplu: PX (o Valoare Simbolica) Codb Codp P. PX Cantitate

Toate Atributele BENEFICIARILOR: B Cod P. BX Nume P. NY Tip P. TZ Oras P. OV

Sau mai simplu: B P Cod BX Nume NY Tip TZ Oras OV

Regasire Filtrata Codul BENEFICIARILOR din Orasul O1 si avnd Tipul T1: B P Cod BX Nume Tip T1 Oras O1

Codul BENEFICIARILOR din Orasul O1 sau avnd Tipul T1: B P Cod BX BY Nume Tip T1 Oras O1

Valorile de Exemplu diferite (BX , BY) pe aceeasi coloana, indica selectarea valorilor returnate din Tuple diferite. Codul BENEFICIARILOR din Orasul O1 si avnd Tipul > T1 si <T2: B P Cod BX BX Nume Tip > T1 < T2 Oras O1

Valorile de Exemplu identice (BX) pe aceeasi coloana, indica selectarea valorilor returnate din aceeasi Tupla, permitndu-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 P Conventii: DO(n) Descrescator UP(n) Crescator n Ordinea atributului n Cheia de Ordonare Cod BX Nume DO NY Tip Oras

Regasire din mai multe Tabele cuplate Codurile si Numele BENEFICIARILOR care au contractat PRODUSUL P2: B P Cod BX Nume NY Tip Oras

Codb BX

Codp P2

Cantitate

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 BX Nume P . NY Tip Oras

P P

Cod PX

Nume

Greutate

Culoare rosu

Codb BX

Codp PX

Cantitate

Regasire cu Negatie Numele BENEFICIARILOR care nu au contractat PRODUSUL P2:

284

Modele de Date / Modelul Relational / Manipularea Datelor

Cod BX

Nume P. NY

Tip

Oras

Codb BX

Codp P2

Cantitate

Regasire cu cuplarea aceleasi Tabele Codul PRODUSELOR contractate de mai mult de un BENEFICIAR: C Codb BX BX Codp P. PY PY Cantitate

Conditia ( BX) evita perechile de Coduri ale aceluiasi BENEFICIAR. Regasire cu Tabela de Conditii Perechile deCoduri ale BENEFICIARILOR avnd resedinta n acelasi Oras: B Cod BX BY Nume Tip Oras OX OX

CONDITII BX < BY REZULTAT P Primul BX Al-Doilea 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 ntruct 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, nepretndu-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, att n interior, ntre Elementele Structurii, ct 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 CONCEPTUAL Constructor TABELA de BAZA TB INTERN FISIER MEMORAT FM EXTERN VEDERE VD 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 VD TB FM TB FM Legatura -

Vederea este un element al Nivelului de Descriere a Structurilor de Date, ntelegnd 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 rndul 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 pna 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 o o Clauza ORDERBY Date Virtuale (Date calculate) 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 Operatii n LMD asupra Vederilor

4.2.4.6.2

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, pna 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) Operatii de Regasire care sunt considerate Operatii Simple orice Vedere poate fi privita ca o Relatie Derivata (Tabela Derivata) Operatii de Actualizare care sunt considerate Operatii Dificile - cuprind ansamblul operatiilor de transfer a Valorilor de Date catre Baza de Date (INSERT, DELETE, UPDATE)

Operatiile asupra Vederilor se clasifica n: o o

Din punctul de vedere al raportului cu operatiile de actualizare Limbajele de Manipulare a Datelor (LMD) continute n SGBD-urile se mpart n: o o LMD-uri Restrictive nu permit actualizari asupra Vederilor (nu accepta Vederi Actualizabile) 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 o o o

Modele de Date / Modelul Relational / Nivelul Extern

Vederea sa fie derivata dintr-o singura Tabela de Baza Fiecare Tupla Virtuala a Vederilor instantiate sa corespunda unei singure Tuple Reale din Tabela de Baza 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 continnd 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 C1 C2 C3 C3 Oras O1 O2 O3 O2 Cod correspondent n P P1, P4, P6 P2 P3 P5

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?

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 P1 P2 P3 P4 Nume N1 N2 N3 N4 Culoare C1 C2 C3 C3 Greutate G1 G2 G3 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 dect 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 Se evita actualizarea Se evita actualizarea

INSERT INTO PC1 < P3, N3, G3, C3, O3 >

UPDATE PC1 SET Culoare = C5 WHERE Cod = P1

Atributul Oras nu apare n Vederea PC1 si ar putea fi definit ca NONULL n P P3 nu exista n Vederea PC1, dar exista n P si provoaca ncalcarea Restrictiei de Integritate de Identificare 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 o Independenta Fizica a Datelor modificarile survenite n Nivelul Fizic imunitatea Nivelului Conceptual la

Independenta Logica a Datelor imunitatea Nivelului Extern la modificarile survenite n Nivelul Conceptual

ntruct 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 rndul lor se subdivid n: o Modificari prin Expansiune adaugari de Atribute noi n Relatii existente Modificari prin Incluziune adaugari de Relatii noi n Baza de Date

Modificari prin Restructurare divizare Relatii prin Proiectie pentru Optimizarea Structurii 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 o Proiectari Defectuoase ce se cer corectate 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

Sa analizam acum comportarea Vederii n cazurile mai sus mentionate:

Exemplu: Sa consideram ca din motive de proiectare Relatia B a trebuit sa fie descompusa n alte doua Relatii BX si BY avnd 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 ramn mascate prin pastrarea Numelui unei Vederi vechi, a carei redefinire regrupeaza datele noi, furniznd 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 ramn 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 ramn 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 o o Utilizatorii ramn imuni la Extensia Bazei de Date Utilizatorii pot ramne imuni la Restructurarea Bazei de Date, daca se respecta restrictiile impuse Vederilor Actualizabile 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 o Aceeasi data poate fi diferit vazuta de Utilizatori diferiti 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).
GENERALIZARE IERARHII de OBIECTE IERARHII de INSTANTE de SISTEM

LOGICA STRUCTURA FIZICA

AGREGARE GENERALIZARE AGREGARE

IMPLICITE MODEL

RESTRICTII
EXPLICITE NAVIGARE de UTILIZATOR

OPERATII
SPECIFICARE

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 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) , Complicatii, Precautii)

Modele de Date / Modelul Relational ca Model Strict de Date cs Cod Spital na Numar Asigurare n Nume a Adresa t Telefon tp Total Paturi ct Cod Sectie p Profesie s Schimb sl Salariu sp Specializare na Numar Asigurare cd Cod Diagnostic td Tip Diagnostic cm - Complicatii pr Precautii nl Numar Laborator nt Numar Test tt Tip Test dp Data Programarii op Ora Programarii nf Numar Fisa ni Numar Inregistrare dn Data Nasterii sx Sex r - Rezultat np Numar Pat dc Data Ocuparii

293
m Marca

Tab. 4.2.4.7.1.1 Baza de Date MEDICALA (Atributele Descriptoare) Simbol RELATIE SP SC PE DO PA DI LA TE LS DP OC Nume RELATIE SPITAL SECTIE PERSONAL DOCTOR PACIENT DIAGNOSTIC LABORATOR TEST LABORATOR / SPITAL DOCTOR / PACIENT PACIENT / PAT Lista ATRIBUTE cs,n,a,t,tp cs,ct,n,tp cs,ct,m,n,p,s,sl cs,m,n,sp ni,n,a,dn,sx,na ni,cd,td,cm,pr nl,n,a,t ni,nl,nt,tt,dp,op,nf,r cs,nl m,ni cs,ct,ni,np,dc Identificatori cs cs,ct cs,m m ni ni,cd,td nl ni,nl,nt cs,nl m,ni cs,ct,ni,np Chei de Legatura cs cs ni ni, nl cs, nl m,ni cs,ct Chei Straine cs cs, ct m ni ni, nl cs, nl m,ni cs,ct Tip RELATIE Ec M M Ei Ec M Ec M Ls Ls Lc

Tab. 4.2.4.7.1.2 Baza de Date MEDICALA (Gruparea Atributelor n Clase de Entitati)

Modele de Date / Modelul Relational ca Model Strict de Date

294 s PE

SP cs a

t SC cs ct

tp

cs

ct

*
PA ni

DI cd

sl p n *
pr cm

DO

sp n

cs

*
LA

na sx
dn

nf

*
sp

cd

ni

td

nl

OC

* *
DP

TE ni nl nt

sp tt cs

LS nl m

cs ni

ct

* *

* * * ni

np

Fig. 4.2.4.7.1.3 Baza de Date MEDICALA (Arborele de Structura)

Modele de Date / Modelul Relational ca Model Strict de Date

295

SP

OC

TE

SC DO PA

LA

PE

DP

DI

LS

Fig. 4.2.4.7.1.4 Baza de Date MEDICALA (Diagrama Simbolica)

296

Modele de Informatii si Date

SP

ST/ SP

DO/ SP

LA/ SP

ST

DO

LA

PE/ ST

PA/ ST

DO/ PA

TE/ LA

PE

PA

PA/ TE

TE

PA/ DI

DI

Fig. 4.2.4.7.1.8 Baza de Date MEDICALA (Diagrama Entitati-Relatii)

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 att mai acuta, cu ct 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: sau o o o o o depinde functional de determina functional pe

Cheie Primara - orice Cheie Candidata aleasa la un moment dat, pe criterii de preferinta, ca Prim Identificator al Relatiei 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) Cheie Straina - orice Atribut de Legatura al unei relatii, care este Cheie Primara n alta relatie Cheie de Legatura - orice Cheie Straina, care este totodata constituent de Cheie Primara n relatia n care este definit Legatura Relationala - orice legatura ntre doua Atribute de Legatura din Relatii diferite

298
4.2.4.7.2.1

Modele de Date / Modelul Relational ca Model Strict de Date

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 d i R2 d

*
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 d i1 R2 d

i2

R1 . i - Cheie Primara R2 . i 1 + R2 . i 2 - Cheie Primara R2 . i 1 - 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

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 d i R2 d

*
R1 . i - Cheie Primara R2 . i - Cheie Primara R2 . i 1 - 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 d i R2

*
R1 R2 R1 R2

*
. i - Cheie Primara . i - Cheie Primara . d - Atribut de Legatura . 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

300

Modele de Date / Modelul Relational ca Model Strict de Date

(R . i), care va migra n ambele Relatii, evitndu-se astfel Redondanta si mai ales posibilitatea de Inconsistenta (Fig. 4.2.4.7.2.1.5)

R1 d

R1 d i

R2 d

*
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 LegaturaCheie 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 strns 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, ntruct acestea indica Numarul de Relatii cu care are Legaturi o Relatie data. Vom vedea n continuare ca aceasta abordare va ntlni 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

ntruct 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 o Relatii de tip Entitate - existenta lor nu depinde n esenta de prezenta altor Relatii Relatii de tip Legatura - existenta lor depinde de prezenta altor Relatii, fara de care ele si pierd semnificatia

Modele de Date / Modelul Relational ca Model Strict de Date

301

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:
4.2.4.7.2.2.1.1

Relatii de tip Entitate Completa Relatii de tip Entitate Incompleta

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.
Ec

*
d1

d2

..

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, grupnd cele mai multe Referinte Relationale din partea altor Relatii din structura (vezi si Fig. 4.2.4.7.2.2.1.1.2).

302

Modele de Date / Modelul Relational ca Model Strict de Date

SP

cs

*
n

tp t

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 ( implementata ca un Descriptor, pe post de Cheie r), Straina.

Modele de Date / Modelul Relational ca Model Strict de Date

303

Ec

Ei

*
d1

d2

..

*
d1

d2

..

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).
PR

SP

a t

cs g

tp

*
n

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 ramna 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.

304

Modele de Date / Modelul Relational ca Model Strict de Date

SP

tp

DO

sp

cs

*
n

cs t

*
m n

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, permitnd construirea Nivelelor de Agregare a Relatiilor de diferite Grade, ntelegnd prin aceasta c Relatiile Agregate pot participa n continuare n alte Nivele de a Agregare. Intre Domeniile pe care sunt definite Relatiile de Legatura figureaza ntotdeauna Domeniile Cheilor de Legatura. Pe lnga acestea pot participa nsa si alte Domenii care descriu Atribute proprii Relatiilor de Legatura. Subtipurile Relatiilor de tip Legatura sunt:
4.2.4.7.2.2.2.1

Relatii de tip Legatura Simpla Relatii de tip Legatura Completa

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 att Structuri Fundamentale de tip 1 - n, ct si m - n ntre Entitatile reprezentate de Relatiile legate. Structura manifesta toate caracteristicile Relatiei Matematice: o o Independenta Legaturii, definita ca o existenta de sine statatoare 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

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 . i 1 si Ls . i 2 DF Ls . i 1 Pentru Legaturi m n: Ls . i 1 DF Ls . i 2 si Ls . i 2 DF Ls . i 1 Structura schematica a Legaturii Simple este redata n Fig. 4.2.4.7.2.2.2.1.1. E1 i i DF Ls . i 2

E2

*
d1

d2

.. Ls

*
d1

d2

..

i1

i2

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 , avnd 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 . i p

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 . i m { E1 . ip (E1 . ip =Ls . i1p si E2 . im =Ls . i2p) pentru p } ntruct 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 ramn 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.
E1

E2

E3

*
d1

d2

..
Ls1

*
d1 i

d2

..

*
d1

d2

..

*
i1

i2

*
i1

Ls2

i2

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.

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 lnga 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. i 1 , Lc. i 2 } DF Lc. di Lc. i 1 DF Lc. di Lc. i 2 DF Lc. di E1 i i E2

*
d1

d2

.. Lc

*
d1

d2

..

*
.. d1

i1

i2

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).

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 indicnd Numarul de Teste efectuate de un Laborator pentru un anume Spital In DP Atributul Numar Consultatii indicnd 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. Apartinnd Identificatorului, Cheia migrata determina o dependenta mai puternica a Relatiei Mixte de Relatiile cu care intra n Legatura. Dependenta mai strnsa 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. E i i1 Em

*
d1

d2

..

* *
i2 d1

d2

..

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 ramne Functional Dependent de Cheia Primara a Legaturii {E. i, E m . i 2 }: { E m . i 1 , E m . i 2 } DF E m . di dar: E m . i 1 E. i deci: { E. i, E m . i 2 } DF E m . di

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 continnd Date Comune pentru ntregul Document O Multime de RANDURI continnd 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) o Descriptori RANDURILE contin: Identificatorul de Rnd Descriptori Codul Obiectului (Produs / Serviciu) Unitatea de Masura Cantitatea (Tranzactia Fizica) Valoarea Unitara (baza Tranzactiei Valorice) Etc. Identificatorul Intern de Document Numarul Rndului Termenul Scadent Conditii de Livrare / Plata Etc. Identificatorul Intern de Document Emitent (Societate / Persoana) Numarul Documentului Data Documentului Cheie Candidata

310

Modele de Date / Modelul Relational ca Model Strict de Date

A id

* *
nd dt

*
em

ts

.. cd d

* *
nr co

um

.. vu

ct

Fig. 4.2.4.7.2.2.3.2 Structura DOCUMENT / RANDURI Actualizarea acestei structuri trebuie facuta Tranzactional (cu Validarea Restrictiei la sfrsitul 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 ntruct 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

Comparnd 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 ramne 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

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 Cmpurilor 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 gndire 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, utiliznd 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 o Prin Generalizare Prin Abstractizare

312
4.2.4.7.3.1

Modele de Date / Modelul Relational ca Model Strict de Date

Implementarea Agregarii

Agregarea mbraca doua forme de aparitie: o o Agregarea de Domenii (forma primara de generare a Claselor de Entitati) Agregarea de Relatii (forma evoluata de combinare a Descriptorilor mai multor Clase de Entitati)

Agregarea de Domenii este poate cea mai vulnerabila atunci cnd se neglijeaza continutul semantic al Informatiilor din Spatiul Utilizatorului. Pericolul consta n introducerea n structura Relatiilor a Dependentelor Functionale nedorite (vezi sectiunea 5.1). Cteva 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.
Implementarea Generalizarii

4.2.4.7.3.2

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)
V CT CC

* * *
n p

v
VC

*
n b

i - Identificator n - Nume p - Producator v - Valoare c - Cod

* *
v c

V VEHICOL CT CATEGORIE CC CRITERIU VC VEHICOL CATEGORIE

Fig. 4.2.4.7.3.2.1 Structura DOCUMENT / RANDURI

314

Modele de Date / Modelul Relational ca Model Strict de Date

Relatia VEHICOL-CATEGORIE (VC) specializeaza Instantele VEHICOL, prin atasarea Categoriilor pentru fiecare Criteriu

de

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 cnd 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 att mai mult nlesnita cu ct 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: Cnd 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 cte o Categorie asa nct E2 va Generaliza aceste Entitati-Categorie. Cnd 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. Trecnd 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, reducndu-se activitatile artizanale Restrictii impuse Datelor

4.2.4.7.4

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: o 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

Ordinea Tuplelor e indiferenta Fara a impune vreo restrictie ordinea tuplelor ramne 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 ntruct 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
4.2.4.7.4.2

Atributele unei Relatii sunt Date Elementare (Cmpuri Nedecompozabile)

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 ({v 1 , v 2 , v 3 , ..} )

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 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

Facilitati de Asertare (declarare de Predicate)

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 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 Amnata se declanseaza la sfrsitul 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)

Exemplu: Alocare unica de Pat

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 Operatii asupra datelor

4.2.4.7.5

Modelul Relational permite doua categorii de Operatii asupra datelor: o o Operatii Procedurale bazate pe precizarea Succesiunii de Operatii care sa conduca la rezultat n urma parcurgerii Structurii de Date (Navigare) 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 Sfrsit 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 MEMORIE INTERNA BAZA de DATE

CURSOR 1
- NUME - ORDINE Index Curent - POZITIE Variabila Sistem

TABELA de BAZA 1 - Nume - Indecsi atasati

CURSOR 2
- NUME - ORDINE Index Curent - POZITIE Variabila Sistem

TABELA de BAZA 2 - Nume - Indecsi atasati

CURSOR n TABELA de BAZA m - Nume - Indecsi atasati

- NUME - ORDINE Index Curent - POZITIE Variabila Sistem

Fig. 4.2.4.7.5.1.1 Structuri de Date pentru operatia de Navigare n Tabele

Modele de Date / Modelul Relational ca Model Strict de Date

321

Cursorul ca Structura este descris de urmatoarele elemente: o o o Nume Cursor construit din Numele Tabelei de Baza sub forma unui Alias Index Curent purtatorul Ordinii de Inspectie Numar nregistrare Curenta Valoare reprezentnd 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 (numarnregistrare, 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.numarnregistrare AND cod-sectie=2 EXIT LOOP2 IF STATUS-CHECK OUTPUT SELECT FROM p:nume, o:numarnregistrare, numar-pat END LOOP2 END LOOP1

322
4.2.4.7.5.2

Modele de Date / Modelul Relational ca Model Strict de Date

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 o Final se transmite Utilizatorului 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 o Prin redactarea de Comenzi ex. comenzile limbajului SQL (Structure Query Language) Prin intermediul Ecranelor de Descriere cu Selectie de Optiuni cu Completare de Optiuni (Fill n Blanks) variante ale limbajului QBE (Query By Example) Comenzi de Regasire Comenzi de Actualizare Comenzi Speciale

Comenzile Limbajului SQL (Limbaj Standardizat de acces la BD) se mpart n:

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, continnd 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 AND

WHERE pacient.numar-nregistrare=ocupare.numar-nregistrare ocupare.cod-sectie=2

4.2.4.7.5.3 Nivele de Definire a Operatiilor

Pentru a completa i aginea Limbajelor de Manipulare a Datelor n Bazele de Date m 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))

Comparnd 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.
Impunere Secvente de Operatii (Navigare)

Nivel Imperativ

Procedurale

Nivele de Definire a Operatiilor

Specificare Operatoriala Nivele de Specificare Specificare Predicativa

Neprocedurale

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 ramne de referinta si n ceea ce priveste formarea Modului de Gndire 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 ramne cel mai raspndit 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), pna 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.).

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 gndi 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 att exemple simbolice, caz n care intereseaza doar raporturilor de structura ale diferitelor elemente, ct si exemple concrete, prin care se ncarca cu semantica domeniului ales, elementele care participa la construirea structurilor. 4.2.4.8.1 Exemplul 1 Descrierea sumara a unei Colectii de Date STUDENTI se face cu Relatia urmatoare: STUDENT (Marca*, Nume, Data-nastere) Neexistnd 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 cteva 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.
Ec

Generalizarea Entitatilor

*
n

Fig. 4.2.4.8.1.1 Structura STUDENT- varianta 1

Modele de Date / Modelul Relational / Construirea Structurilor de Date

325

STUDENT

Sex - Feminin - Masculin

Finantare - Buget - Plata

Situatie Scolara - Promovat - Nepromovat

Stare - Continuare - Retras - Exmatriculat - Transferat

..

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)
X F SS ST

*
m

st ss

*
n

Fig. 4.2.4.8.1.3 Structura STUDENT- varianta 2 Caracterul dinamic al Extensiei Ierarhiilor de Generalizare poate provoaca dificultati.

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
C S

m c n

*
n

st

ss

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:

Modele de Date / Modelul Relational / Construirea Structurilor de Date

327

Tipul Entitatii de Generalizare {Criteriu, Categorie} care va permite: o o nregistrarea n Baza de Date si a Criteriilor alaturi de Categorii Diferentierea Categoriilor de Criterii

Ascendentul Entitatii de Generalizare (Cod) care va permite: o o Deducerea Criteriilor la care apartin Categoriile 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)
C S

a c

CS

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 binenteles 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 regndirea ei. Ar mai fi de subliniat faptul ca teama orgolioasa legata de pierderea personalitatii de specialist n programare este complet nejustificata atunci cnd 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 cte ori aceasta e posibil.

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)
G S

a c

*
n

g d

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. Pentru a ne apropia de cazul real am mentinut proprietatile de Clasificare ale Entitatii GRUPA, n care Atributul Nume ( e definit pe Multimea de Valori n) {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 facut -a 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) .

Modele de Date / Modelul Relational / Construirea Structurilor de Date

329

STUDENT (Marca*, Nume, Data-nastere) GRUPA (Cod*, Nume, Tip, Ascendent) GRUPA-STUDENT (Grupa*, Student*)
GS Grupa G1 G1 G2 G2

Student S1 S2 S3 S4

a c

GS

*
n

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 dect Eliminarea Grupei din Cheia Primara, ntruct 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 utiliznd 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 O Instanta Posesor e1i din E1 are e2j Instante Membri din E2 , pentru j {1 .. n} O Instanta Membru e2j din E2 are e1i Instante Posesori din E1 , pentru i {1 .. m}

330

Modele de Date / Modelul Relational / Construirea Structurilor de Date

E1
Membrii unui Posesor

m n

Posesorii unui Membru

E2
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.

E1 i d i1

L d i

E2

i2

*
legatura 1 - n

*
legatura 1 - m

*
i - Identificator d - Descriptor

E Relatie de tip Entitate L Relatie de tip Legatura

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

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. i 1 = E 1 . i Adauga Tupla e2 j din E2 cu E2 . i = L. i 2 n Rezultat Sfrsit Afisaza Rezultat pentru e1i Sfrsit

Rezultate e11 { e21 , e22 } e12 { e21 , e23 }

ENTITATE1 Tupla Idntificator e11 i11 e12 i12

Descriptor d 11 d 12

ENTITATE2 Tupla Idntificator e21 i21 e22 i22 e23 i23 Idntificator2 i21 i22 i21 i23 Descriptor d1 d2 d3 d4

Descriptor d 21 d 22 d 23

LEGATURA Tupla Idntificator1 l1 i11 l2 i11 l3 i12 l4 i12

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. i 2 = E 2 . i Adauga Tupla e1i din E1 cu E1 . i = L. i 1 n Rezultat Sfrsit Afisaza Rezultat pentru e2 j Sfrsit Rezultate e21 { e11 , e12 } e22 { e11 } e23 { e12 }

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
m n c p q

A
t c

L
n nr

D
o

*
nr

*
C

*
l

*
cd i a p d

P PILOT A AVION L LOCALITATE D DECOLARE C CURSA

m Marca n Nume p Prenume g Grad c Cod

q Capacitate t Tip nr Numar z Zi o Ora

cd - Comandant i - nsotitor a - Avion P Localitate Pornire d - Localitate Destinatie

l - Decolare

Fig. 4.2.4.8.2.2.4 Structura de Date Curse Aviatice

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 ntruct: o In calitate de Caracteristica o Ar descrie Entitatea SOCIETATE, indiferent de Legatura ei cu alte Entitati S-ar regasi ntre Atributele Entitatii SOCIETATE 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, SocietateFurnizoare)

In calitate de Rol

P
s t

*
p

*
S SOCIETATE T TIP-PARTENER (Producator, Beneficiar, Furnizor) P PARTENER c Cod d Denumire s Societate p Partener n Nume t Tip

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, TermenContract)

Modele de Date

335

PR
pt

P
t

*
p

*
c

*
C
tc

*
pi

PC
v ct

nr

rd

*
S SOCIETATE T TIP-PARTENER P PARTENER C CONTRACT PC POZITIE CONTRACT c Cod d Denumire n Nume s Societate p Partener t Tip pi Parteneri nr Numar Contract v Valoare tc Termen Contractual pr - Produs rd Numar Rnd pt - Pret ct - Cantitate

Fig. 4.2.4.8.2.2.6 Structura de Date Contracte / Parteneri

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 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 Rndurile 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 Rnd*, Produs, Cantitate) Este evidentiata cascadarea Relatiilor de Legatura prin introducerea unei Relatii de Legatura de Grad 3 (POZITIE CONTRACT), care nu poate fi evitata ntruct are Atribute Proprii ( r, ct). Aceasta noua Relatie asigura totodata o constructie detaliata a structurii p BENEFICIARPRODUSCONTRACT cu mentinerea Independentei necesare ntre Entitati (POZITIE CONTRACT, pe post de Rnd 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 nct 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, transformnd-o n relatie de Prietenie (Fig. 4.2.4.8.2.2.8).

*
m n v s1

*
Fig. 4.2.4.8.2.2.7 Structura STUDENT - PARTENER

*
s2

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)
STUDENT

m
M1 M2 M3 M4 M5 M6 M7

n
N1 N2 N3 N4 N5 N6 N7

d
D1 D2 D1 D3 D4 D1 D1

p
M2 M4 M5
NULL NULL

M3
NULL

Fig. 4.2.4.8.2.2.8 Structura STUDENT - PRIETEN (varianta 1)

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 Membrii Clasei de Echivalenta (restul Elementelor introduse n Echivalenta) apar n coloana p si n coloana m Reprezentantul lipseste din multimea Membrilor (nu apare n coloana p)

o o

Dificultati de actualizare datorate necesitatii de gestiune a proprietatilor de Simetrie si Tranzitivitate a relatiei de Echivalenta

S
m s1

P
s2

PRIETEN

S1
M1 M1 M3 M5 M6 M7

S2
M2 M4 M5
NULL

*
n v

M3
NULL

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 ( x, Mx) n P (pentru respectarea M proprietatii de Simetrie) La fiecare introducere de Tupla ( Mx, My) n P se poate genera automat n P cte o Tupla (My, Mz) pentru: x (Mx, Mz) P (pentru respectarea Reflexivitate) proprietatii de Simetrie si

Modele de Date / Modelul Relational / Construirea Structurilor de Date

339

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

Dificultatile de actualizare constau n cresterea numarului de Tuple n P, impunndu-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. Relaxnd Relatia de Prietenie prin eliminarea conditiei de Tranzitivitate se trece la o structura m n care nu poate fi implementa dect n Varianta 2. Nici conditia de Simetrie nu poate fi luata n calcul cnd se vorbeste de Prietenie. Grupele de Prieteni formeaza pe Multimea Studentilor (si nu numai a lor) mai degraba o Acoperire dect 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 indicnd 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 cnd Relatiile de Legatura Intermediare sunt Relatii Complete, ntruct 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 ntro 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

TEMA

Domeniu 1

Domeniu 2

..

Tema 1

Tema 1

..

Tema 1

Tema 1

..

Fig. 4.2.4.8.2.2.10 Ierarhia de Generalizare pentru Entitatea TEMA

P
m m

S
c n a s

C
c l d t

a n t

CM

* * * * p
c

Fig. 4.2.4.8.2.2.11 Structura COMUNICARE ca Entitate Agregata P x S x C x T

Modele de Date / Modelul Relational / Construirea Structurilor de Date

341

Legatura care asigura construirea Ierarhiei de Generalizare n Spatiul Datelor este de tip Recursiv, ntruct att Criteriile (Blocurile de Categorii), ct 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 o o Generalizarea Conferintelor prin Tematici (Domenii) (C.t T.c) Generalizarea Comunicarilor prin Teme (CM.t T.c) 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). PROFESOR
P colaboreaza cu S

STUDENT

P prezinta CM P participa laC C gazduieste CM

S prezinta CM

COMUNICARE

S se preocupa de T T e prezenta n CM

C e n domeniul D

CONFERINTA
P se preocupa de T

TEMA

S participa la C

T e n domeniul D

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 cteva 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)

342 o

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)

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 ( Profesor si o un 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 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)

In aceste conditii, structura initiala trebuie modificata dupa cum urmeaza:

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 ctorva Liste de Atribute si Referiri Asociative pare nensemnata. Cnd 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 jucnd 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

P
m m

S
s

E
c p n e

ES

* *

C
c p r a c l d t

*
CM

a n t

* * *
c

Fig. 4.2.4.8.2.2.13 Structura COMUNICARE ca Entitate Agregata E x C x T

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, purtnd n ea toate Relele implicate de Dependentele Nedorite.

*
m n p s dn d

*
m n p s dn d

Fig. 4.2.4.8.2.2.14 Structura Profesor Student Domeniu-de-Interes (Varianta 1) Sa analizam fisurile din structura: o o o Prezenta aceluiasi Descriptor, Domeniu-de-Interes, repetat n doua Atribute ale structurii cauznd Redondanta si implicit Inconsistenta Absenta unei Chei Primare dintr-o Legatura Relationala, care, asa cum s-a vazut n repetate rnduri, nu poate implementa dect Legaturi Fundamentale 1 n 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.

*
m n m p s dn d

*
n p s dn d

T
c

a n t

Fig. 4.2.4.8.2.2.15 Structura Profesor Student Domeniu-de-Interes (Varianta 2)

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, asigurnd 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 formnd 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 (Cmpuri 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 - E1 , E 3 Subentitati - E2

Structura esentiala pentru orice colectie ampla d date, Arborescenta, a prezentat e atractie nca de la aparitia primelor preocupari legate de Bazele de Date. Nu ntmplator 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 dect structuri de tip Partitie, Ierarhii cu Ascendent Unic, adica Arborescente (vezi sectiunea 3.4.2). Trecnd 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. Utiliznd 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 BD

Modele de Date

E1 d11

E3 d31

*
i11 E2 d21

*
i31

*
i21 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

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 utiliznd 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

R1

R2

R3

*
i11 d11 d12

*
i11

*
i21 d21 d22

*
i11

*
i21

*
i31

d31

d32

R RELATIE i - Identificator (Atribut) d - Descriptor (Atribut) Identificatori Contextuali R1 i11 R2 i11 + i 21 R3 i11 + i 21 + i 31

Fig. 4.2.4.8.3.3 Construirea Structurilor Ierarhice prin Legaturi Relationale

Modele de Date

349

Reprezentarea grafica, utiliznd 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

*
c d u p

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 ramne 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, avnd 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)

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.

U
i d

*
F
i d

*
A
i d

*
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 aparndu-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 ramn 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 ( ), s-a atasat la structura relatia TIP ( U 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)

Modele de Date / Modelul Relational / Construirea Structurilor de Date

351

U
c1 d c1

F
c2 d c1 c2

A
c3

U - UNIVERSITATE F - FACULTATE A AN U . c1 = F. c1 = A. c2 F. c2 = A. c2 F . c1 + F . c2 A . c3 A . c1 + A . c2 + A . c3 - Cod Universitate si Identificator Universitate - Cod Facultate n cadrul Universitatii - Identificator Facultate - Cod An n cadrul Facultatii - Identificator An

Fig. 4.2.4.8.3.2.2 Structura Relationala cu Identificare Contextuala

Modele de Date / Modelul Relational / Construirea Structurilor de Date

352

U
c1 d c1

F
c2 d c2

A
c3

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

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
c d t

U
d

*
T TIP UNITATE U UNITATE

*
c i - Identificator d - Descriptor

t Tip 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
c d t c

U
d

*
c

S
a

*
T TIP UNITATE U UNITATE L STRUCTURA c - Cod d - Descriptor a - Ascendent

*
t Tip

Fig. 4.2.4.8.3.2.5 Structura unei Universitati (Varianta 2)

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 nct o Unitate de Structura (ex. un Departament) sa participe n mai mult dect 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), trecndu-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 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

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 d tu

U
c d

*
S
c a ts TS c

* *
tu Tip Unitate ts Tip Structura d

*
TU TIP UNITATE U UNITATE L LEGATURA TS TIP STRUCTURA c - Cod d - Descriptor a - Ascendent

Fig. 4.2.4.8.3.2.6 Structura unei Universitati (Varianta 3)

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
c P PRODUS S SUBANSAMBLU M - MATERIAL c - cod d - descriptor q - consum d

*
S
c d q

*
M
c d q

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 cnd 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 ( onsumuri de C Semifabricate si de Materiale). Dezvoltarea structurii n sensul unificarii Cataloagelor ntrunul 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).

Modele de Date

356

P
c c d

S
c d

SP
c1 q c2 c1

MP

c2

c3

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)

Modele de Date / Modelul Relational / Construirea Structurilor de Date

357

T
P PRODUS T TIP PRODUS
(Ansamblu, Subansamblu, Material)

P
c d

C - CONSUM c - cod d - descriptor t - tip q - consum

*
C
c1 c2

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: Adncimi 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 ntruct 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 cstiga n interes acolo unde este vorba de Multimi (Seturi) de Matrici, avnd o Structura Rara (multe Elemente Absente, Nedefinite sau Nule).

358

Modele de Date / Modelul Relational / Construirea Structurilor de Date

Principalul cstig 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. SET

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, permitnd 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 ( dentificatori I 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.

Modele de Date / Modelul Relational / Construirea Structurilor de Date

359

S
n d

M
n

*
L
n

*
m d

d s

C
n

*
l

E
v c

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, avnd un Tip Consacrat, cu Operatori Asociati, ce asigura oricnd 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

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 dect 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

Numele Categoriilor corespund Valorilor Atributului Nume din Entitatea Categorie si va avea Valorile: {foarte bun, bun, mediocru, slab, foarte slab}

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 o Functia de Dependenta pote fi implementeaza ca o Procedura Stocata Declansata pe Evenimentul de Actualizare Medie 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
n

ct

*
n cm

*
p s dn md

S - STUDENT C - CATEGORIE

c - Cod n Nume p Prenume s Sex

dn Data Nasterii md - Medie ct - Categorie cm Conditiede-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 a fara unei Entitati de tip Criteriu, ale carui Categorii sa fie Valorile din Lista de Valori, nu respecta Conditiile Minimale ale Modelului Relational de Date.

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, m ulti producatori de SGBD considernd 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]. 4.2.4.9.1 Reguli de Fundamentare Reguli Structurale Reguli de Integritate Reguli de Manipulare a Datelor Reguli de Independenta a Datelor 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 Hrtiei 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, incluznd: 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, ntelegnd 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, att sub forma de definire Intensionala (prin Nume), ct 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 o

Modele de Date / Modelul Relational / Conditiile ca o BD sa fie Relationala

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. Pna 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 Constrngeri definite de Utilizator pentru implementarea Regulilor Proprii extrase din Spatiul Informatiilor (asa numita Business Logic). Constrngerile pot fi definite ca Reguli de Corectitudine sau de Compatibilitate, la nivel de Coloana, Rnd, Tabela sau Baza de Date. 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.

Regula 10

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: o Regula 2 Fiecare Data Elementara dintr-o BDR, reprezentnd 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) Definirea Datelor Definirea Vederilor Manipularea Datelor (Interactiva si Programata) Definirea Restrictiilor Autorizarea Accesului Prelucrari Tranzactionale

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 att pentru Operatii de Regasire ct 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, ntruct 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

PARTEA a 5 -a OPTIMIZAREA MODELELOR de DATE

ncercnd 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 ntlnite 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, avnd 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

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 o 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 Viteza de Prelucrare a Cererilor criteriu cantitativ ce urmareste reducerea timpului de compilare si executie a Cererilor adresate Structurilor de Date

Criterii de evaluare a Structurii Procedurilor

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 ntruct primul va insista asupra Normalizarii accentuate a Structurilor, pe cnd 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 att mai mult cu ct criteriile de evaluare a structurii acestora sunt mai complexe, implicnd 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 dect 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, att sub aspect calitativ (preluare maxima de semantica n structura), ct 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 Constrngere 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, utiliznd proceduri speciale de actualizare a Datelor Dependente (Proceduri Tranzactionale sau de Replicare)

Se remarca faptul ca problema Consistentei este strns legata de cea a Redondantei n Structurile de Date. Prioritara ramne nsa asigurarea Consistentei, care se mentine si atunci cnd 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, ramne 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 avnd diferite grade n, (n 1), fiecare avnd forma: R (A 1 , A 2 , .. , A n ) o Atribute ale relatiei R lista A 1 , A 2 , .. , A n , reprezentnd 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; Tupla Logica a unei relatii R ( ) ansamblul Atributelor care descriu o relatie privite ca o multime si ca atare avnd 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 | |=n

Optimizarea Structurilor de Date

(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: mr = | R | o Cardinalitatea Subtuplei Logice a unei relatii numarul de Atribute din Subtupla: ns = | | 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( ) ntruct: R o o

e ea nsasi o relatie pe submultimea de atribute .

Tuple Logice disjuncte tuple a caror intersectii de multimi de Atribute sunt vide ( ) 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 o Definitii si Notatii 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: ( r1 , r2 ) R | ( r1 [ ] = r2 [ ] ) ( r1 [ ] = r2 [ ] ) altfel spus: egalitatea Valorilor atributelor implica egalitatea Valorilor atributelor

374

Optimizarea Structurilor de Date

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: ( r1 , r2 ) R | ( r1 [ ] = r2 [ ] ) ( r1 [ ] r2 [ ] ) altfel spus:

egalitatea Valorilor atributelor nu implica egalitatea Valorilor atributelor o Dependenta Functionala Triviala orice DF : pentru care : o Determinant DT membrul stng al unei Dependente Functionale care nu include o Dependenta Triviala: DT o Orice Determinant implica o Dependenta Functionala Minimala (Ireductibila) vezi definitiile ulterioare
Proprietatile Formale ale Dependentelor Functionale

5.1.2.2.1.1

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 : pentru care: z . o Dependenta Functionala Compusa orice DF, c : pentru care: = { A 1 , A 2 , .. , A k } , cu k >1 o Dependenta Functionala Completa (Ireductibila) orice DF compusa, t : pentru care: = { A 1 , A 2 , .. , A k } , cu k >1 si:
t t c z

376 unde: .

Optimizarea Structurilor de Date

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, ntruct 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: o Simplitatea Uzualitatea Obisnuinta etc.

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 ntruct: 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 o o 1. Reflexivitate 2. Augmentare B A A B A B AC BC

3. Tranzitivitate A B si B C A C 4. Autodeterminare A A 5. Descompunere A BC A B si A C 6. Reuniune A B

S

Reguli Derivate
o o o o
S+

si

A C

A BC AC BD

7. Compunere A B si C D

nchiderea a unei SuperChei implicata de Dependentele Functionale D multimea tuturor A tributelor 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 ct 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 stng 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 o o Relatii Normalizate BCNF Relatii Normalizate Candidata. BCNF sunt relatii n care orice Determinant e Cheie

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}

M r [ ] M (r[ ])

n n n
r [ ])

nn n n n

n n

Multimea R ( )

Multimea Partilor R ()

Domeniul de definitie

Domeniul de valori

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 nct: , , si: = - ( )

380 iar: = - ( )

Optimizarea Structurilor de Date

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 d o extensie posibila a Tabelei de Baza atasata Relatiei a anterior descris a:

Optimizarea Structurilor de Date

381 Depozit Produs D1 D1 D2 D2 D1 D1 D1 D2 D2 D2 P1 P1 P1 P1 P1 P1 P2 P2 P1 P1

r[ ]= (D1, P1)

r[ ]= (D2, P1)

NumarComanda NC1 NC1 NC2 NC2 NC3 NC3 NC4 NC5 NC6 NC6

MarcaProdus MP1 MP2 MP3 MP4 MP1 MP2 MP5 MP6 MP3 MP4

M (r[ ] ) = {MP1, MP2)

M (r[ ] ) = {MP3, 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. Proprietatile Formale ale Dependentelor Multivalorice:

5.1.2.3.1

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

382 Complementaritate

Optimizarea Structurilor de Date

daca si numai daca unde: = -( Augmentare si ( ) ( ) Tranzitivitate si ( - ) Tranzitivitate Restrnsa 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 dect 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 nenlocuit, pe care l joaca acest proces n construirea Structurilor de Date 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, transformndu-se ntr-un obiect de studiu cu posibile aplicari viitoare RN + RNN RN1 RN2 RN3 RBCNF RN4 RN5 -PJNF

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

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 avnd 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 cteva 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 nct cunoasterea Spatiului de Informatii n detaliu, cu toate nuantele de interpretare atasate elementelor componente este strict necesara. 5.1.3.1 Studiu de Caz ntruct 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
5.1.3.1.1.1

Spatiul Informatiilor
Descrierea Spatiului de Informatii

Clase de Entitati BENEFICIAR produse - societati comerciale interesate n achizitionarea unor

Optimizarea Structurilor de Date

385

PRODUSE

- portofoliul de produse oferit de un producator

CONTRACTE - specificarea cantitatilor contractate de fiecare beneficiar din fiecare produs Clasa de Entitati BENEFICIAR Cod Nume Oras Tip - simbol de identificare al societatii comerciale - denumirea societatii comerciale - orasul de resedinta al societatii comerciale (unic) - forma de organizare a societatii comerciale (SRL, SA, RA)

Atribute

Clasa de Entitati PRODUS Cod Nume - simbol de identificare al produsului oferit - 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 Cantitate - produsul contractat - cantitatea contractata

Identificatori BENEFICIAR PRODUS CONTRACT - Cod Beneficiar - Cod Produs - 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 o

Optimizarea Structurilor de Date

Un PRODUS poate fi contractat n diferite cantitati specificate n CONTRACTE (sageata continua PRODUS CONTRACT) Un BENEFICIAR poate contracta diferite PRODUSE (sageata punctata BENEFICIAR PRODUS) Un PRODUS poate fi contractat de diferiti BENEFICIARI (sageata punctata PRODUS - BENEFICIAR)
m n

Legaturi derivate:

BENEFICIAR
1 n

PRODUS
1 n

CONTRACT
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
Nume

Cod

Oras Tip

Fig. 5.1.3.1.3.1 Dependentele Functionale n relatia BENEFICIAR

Optimizarea Structurilor de Date

387

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
Nume

Culoare Cod Greutate 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

Beneficiar Cantitate
Produs

Fig. 5.1.3.1.3.3 Dependentele Functionale n relatia CONTRACT 5.1.3.1.2

5.1.3.1.2.1

Spatiul Datelor
Descriere Intensionala

Pentru descrierea Intensionala a Structurii de Date se foloseste Schema de Relatii reprezentata n Fig. 5.1.3.1.2.1.1.

388 Schema de Relatii contine urmatoarele Informatii: Descrierea Domeniilor Descrierea Relatiilor + Atributelor Descriptoare

Optimizarea Structurilor de Date

Descrierea Identificatorilor (Chei Primare, Chei Candidate) Descrierea Referirilor Relationale (Chei Straine)

Schema de Relatii DOMAIN DOMAIN DOMAIN DOMAIN DOMAIN DOMAIN DOMAIN DOMAIN DOMAIN RELATION Cod Nume Oras Tip codb numeb oras tipb codp numep culoare greutate cantitate CHAR (5) CHAR (20) CHAR (15) CHAR (2) CHAR (5) CHAR (30) CHAR (15) NUMERIC (8) NUMERIC (10)

BENEFICIAR DOMAIN DOMAIN DOMAIN DOMAIN PRIMARY KEY

codb numeb oras tipb Cod

RELATION PRODUS Cod DOMAIN Nume DOMAIN Culoare DOMAIN Greutate DOMAIN Oras DOMAIN PRIMARY KEY

codp numep culoare greutate oras 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) o n

o n n

t n c

n n

g n l n

C
b

q n p

c - Cod n - Nume o - Oras t - Tip societate

B - BENEFICIARI P PRODUSE C - CONTRACTE l - Culoare g - Greutate q - Cantitate

b - Cod Beneficiar p - Cod Produs

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*
B1 B2 B3 B4 B5

Nume
N1 N2 N3 N4 N5

Oras
O1 O2 O2 O1 O3

Tip
T1 T2 T2 T1 T3

390

Optimizarea Structurilor de Date

PRODUS Cod*
P1 P2 P3 P4 P5 P6

Nume
N1 N2 N3 N4 N5 N6

Culoare
C1 C2 C3 C1 C3 C1

Greutate
G1 G2 G2 G3 G1 G4

Oras
O1 O2 O3 O1 O2 O1

CONTRACT Beneficiar*
B1 B1 B1 B1 B1 B2 B2 B3 B4

Produs*
P1 P2 P3 P4 P5 P1 P2 P2 P5

Cantitate
Q1 Q2 Q3 Q2 Q4 Q5 Q1 Q3 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 o Maximum de Control n Gestiunea Datelor, garantat de Maxima Independenta a Elementelor Componente Respectarea Fidelitatii Semantice a Datelor fata de Informatiile din Spatiul Utilizatorului 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 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 Si asa pare bine, si asa pare bine forma mult mai pernicioasa n absenta unui Instrument de Masura

Cu alte cuvinte se urmarea realizarea dezideratului:

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, lund 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, impunnd 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 o 5.1.3.2.2 Modelul Relational pretinde aceasta minima forma de normalizare pentru toate Relatiile din Structura Relatiile B, P, C respecta fiecare aceasta Conditie Minima 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 avnd urmatoarele caracteristici principale: o o o o Orientarea prelucrarii catre Obiective Partiale Urmarirea unor Criterii Locale de Performanta Complexitate redusa a Structurii de Date 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 o Din: SRL, SA, RA etc. 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. Oras Tip

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): Oras Beneficiar Cantitate Produs Tip

Fig. 5.1.3.2.2.2 Dependentele Functionale n cadrul relatiei BC Observatii: o o Atributele Oras si Tip nu sunt Complet Dependente de Cheia Primara (Beneficiar, Produs) 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 dect la aparitia unui CONTRACT pentru un PRODUS Px, deoarece lipseste Cheia Primara compusa ( eneficiar, Produs) care sa permita adaugarea unei B tuple n relatia BC 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

Optimizarea Structurilor de Date

393

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 . Oras Cod Tip Beneficiar Cantitate Produs

Fig. 5.1.3.2.2.3 Dependentele Functionale n cadrul relatiilor BO si C Observatii: o o o o o o o Eliminarea Dependentei Incomplete a atributelor Oras si Tip de Cheia Primara (Beneficiar, Produs) In plan semantic n relatia BC descriptorii Oras si Tip nu descriau relatia contractuala (deci CONTRACTUL), ci BENEFICIARUL O relatie RN1 care nu e RN2 trebuie sa aiba o cheie primara compusa Transformarea relatiei RN1 ntr-o relatie RN2 se face prin descompunerea relatiei initiale folosind operatia de Proiectie Transformarea e reversibila prin aplicarea operatiei de Reunire (JOIN) Transformarea relatiei RN1 ntr-o relatie RN2 se face fara pierdere de informatie 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)

394

Optimizarea Structurilor de Date

5.1.3.2.3 Observatii: o o

Relatii Normale de Grad 3

In relatia BO se mentine nsa Neindependenta Atributelor Descriptoare Oras si Tip 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 dect la aparitia n relatia BO a unei instante Bx a entitatii BENEFICIAR si aceasta ntruct 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 avnd 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.

Cod

Oras

Oras

Tip

Fig. 5.1.3.2.2.4 Dependentele Functionale n cadrul relatiilor B si O

Optimizarea Structurilor de Date

395

Observatii: o o Eliminarea Dependentei ntre atributele descriptoare Oras si Tip 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 o o o o 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 Transformarea relatiei RN2 ntr-o relatie RN3 se face prin descompunerea relatiei initiale folosind operatia de Proiectie Transformarea e reversibila prin aplicarea operatiei de Reunire (JOIN) Transformarea relatiei RN2 ntr-o relatie RN3 se face fara pierdere de informatie Relatiile B si O ajung si ele n forma RN4 Eliminarea Dificultatilor de Actualizare ale relatiei BO

Parcurgnd primele trei etape de mbunatatire a structurilor relationale al retinut faptul ca principalul proces de simplificare a acestora consta n Descompunerea Relatiilor . Ce se ntmpla nsa atunci cnd 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) Oras Cod Tip 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: o Dependentele Conservate se verifica Dependentele continute n relatiile derivate

Recomandare descompunerea sa urmareasca doar Dependentele Directe care contin informatia primara Se masoara prin posibilitatea de Actualizare Independenta a relatiilor derivate prin descompunere

Independenta Relatiilor

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 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

Recomandari:

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, avnd 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 R elatiilor 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 Observatii: o

Relatii Normale BCNF

Formele de normalizare RN1 si RN2 ramn 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 o o

Sinteza normalizarii structurilor relationale are la baza cercetarile efectuate de numerosi specialisti ntre care Codd, Heath, Boyce, Kent etc. Aceasta sinteza a survenit prin elaborarea unei definitii concentrate a primelor trei forme de normalizare pornind numai de la notiunea de Determinant 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 o Definitiile relatiilor RN2, RN3 sunt continute n definitia BCNF 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 o Adaugarea atributului Nume cu semantica de Denumire a Societatii Comerciale 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 o

Optimizarea Structurilor de Date

Revenirea la semnificatia initiala a Tipului de Societate (SRL, SA, RA, etc.), atributul devenind astfel Independent de Descriptorul Oras RELATION BN (Cod, Nume, Oras, Tip) KEY (Cod) Candidate (Nume)

Ajungem la schema de relatii:

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). Cod Oras

Nume

Tip

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 o Adaugarea atributului Nume cu semantica descrisa anterior 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 pna n prezent, utiliznd definitiile Formelor Normale RN3 si BCNF. Observatii: o definitia BCNF e mai completa dect definitia NF3 ntruct: Relatia BNC e normalizata conform NF3 si nenormalizata conform BCNF

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

Beneficiar

Produs

Cantitate

Nume

Fig. 5.1.3.2.5.2.1 Dependentele Functionale n cadrul relatiei BNC o Definitia BCNF e conceptual mai simpla dect definitia NF3 ntruct: Definitia BCNF apeleaza doar la conceptul de: o Determinant

Definitia NF3 apeleaza la conceptele de: Cheie Primara Dependenta Completa Dependenta Tranzitiva

Declararea Cheilor Candidate ntr-o relatie permite usor separarea Determinantilor Viciosi (Determinantii care nu sunt Chei Candidate), informnd 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. Cstigul 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 ramn 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, ntruct 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.

Optimizarea Structurilor de Date

402

Relatia

Chei candidate

Determinanti Beneficiar

Dependente functionale Beneficiar Oras Beneficiar Tip Oras Tip (Beneficiar, Produs) Cantitate Cod Oras Oras Tip (Beneficiar, Produs) Cantitate Cod Oras Oras Tip Cod Oras Cod Tip Cod Nume Nume Oras Nume Tip Nume Cod (Beneficiar, Produs) Cantitate (Beneficiar, Produs) Nume Beneficiar Nume (Nume, Produs) Cantitate (Nume, Produs) Beneficiar Nume Beneficiar

Forma de normalizare RN3 BCNF nu nu

BC BO C B O BN

(Beneficiar, Produs) Cod (Beneficiar, Produs) Cod Oras Cod

Oras (Beneficiar, Produs) Cod Oras (Beneficiar, Produs) Cod Oras Cod

nu da da da

nu da da da

da

da

Nume

Nume

BNC

(Beneficiar, Produs)

(Beneficiar, Produs) Beneficiar (Nume, Produs) Nume

(Beneficiar, Nume)

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 C1 C1 C1 C1 C2 C2 Profesor P1 P1 P2 P2 P3 P3 Manual M1 M2 M1 M2 M3 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 ntruct ncalca Gradul de Normalizare RN1, tabela fiind aici utilizata doar pentru evidentierea Dependentelor Multivalorice ca forma generalizata de reprezentare a Dependentelor Functionale Curs C1 C2 Profesor {P1,P2} {P3} Manual {M1,M2} {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) { (Cx, P1, M1), (Cx, P2, M2) } { (Cx, P2, M1) , (Cx, P1, M2) } Dependentele Multivalorice se reprezinta astfel: Curs Profesor Curs Manual

care n exprimare conditionala ia forma:

404 -

Optimizarea Structurilor de Date

Deoarece potrivit proprietatii de complementaritate Multivalorice (vezi sectiunea 5.1.2.3.1): Curs Manual Curs Profesor reprezentarea anterioara poate fi simplificata astfel: Curs Profesor Manual

Dependentelor

Diagrama Dependentelor Functionale pentru relatia CPM va arata ca n Fig. 5.1.3.2.6.3. Profesor Curs

Manual 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 o n CP si CM 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:

Curs

Profesor

Profesor

Manual

Fig . 5.1.3.2.6..4 Dependentele Functionale n cadrul relatiilor CP si PM

Optimizarea Structurilor de Date

405

Definitie: Relatie Normala de Grad 4 o relatie e n forma RN4 cnd 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 putnd fi privita ca un caz particulara n care multimile atasate unui Determinant au cardinalitate unitara Prezenta unei Dependente Multivalorice Netriviale este un motiv necesar si suficient pentru a descompune relatia n componente O relatie continnd doar Dependente Multivalorice Triviale este considerata Atomica Relatii Normale de Grad 5 (PJNF)

o o

5.1.3.2.7

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 S1 S1 S2 S1 Profesor P1 P2 P1 P1 Proiect T2 T1 T1 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

SPT Student S1 S1 S2 S1 SP =

Profesor P1 P2 P1 P1

Proiect T2 T1 T1 T1 PT= PT ( SPT)

SP

( SPT)

SP Student

PT Profesor Profesor Proiect

S1 S1 S2

P1 P2 P1
SPT = SP

P1 P2 P1

T2 T1 T1

PT

SPT Student

Profesor

Proiect

S1 S1 S1 S2 S2

P1 P1 P2 P1 P1

T2 T1 T1 T2 T1

Tupla intrusa

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 o peratii 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.

Optimizarea Structurilor de Date

407

SPT Student S1 S1 S2 S1

Profesor P1 P2 P1 P1

Proiect T2 T1 T1 T1

SP =

SP ( SPT)

PT= PT ( SPT) PT

TS= TS ( SPT) TS Proiect T2 T1 T1

SP Student S1 S1 S2

Profesor P1 P2 P1 SPT = SP P PT

Profesor P1 P2 P1

Proiect T2 T1 T1

Student S1 S1 S2

SPT Student S1 S1 S1 S2 S1

Profesor P1 P1 P2 P1 P1

Proiect T2 T1 T1 T2 T1

Tupla intrusa
SPT = SPT TS TS SPT = SPT Student S1 S1 S2 S1

Profesor P1 P2 P1 P1

Proiect T2 T1 T1 T1

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

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 ( PT) ntre trei clase de entitati ( P, T), legatura care reprezinta activitatile de S S, 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 amndoi 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 S1 S1 Profesor P1 P2 Proiect T2 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)

Stergere daca din extensia care verifica restrictiile semantice impuse: Student S1 S1 S2 S1 Profesor P1 P2 P1 P1 Proiect T2 T1 T1 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

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), neputnd 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 niciun avantaj, fiecare proiectie continnd 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). 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. 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. Dependentele Operationale (de Reunire) DR generalizeaza Dependentele Multivalorice DM, care introduc si ele Restrictii de Actualizare a relatiilor si acestea generalizeaza la rndul lor Dependentele Functionale DF, singurele care se trateaza doar Structural folosind conceptele de Determinant si Cheie Candidata Pentru acest motiv Dependentele Operationale (de Reunire) DR sunt considerate ca forma cea mai nalta de Dependenta ntre Atributele unei Relatii

Observatii: o

Pentru alti operatori exista si alte Forme de Dependenta. 5.1.3.2.8 o o o Concluzii Normalizarea urmareste Optimizarea Structurilor de Date din punct de vedere al Calitatii Structurii Scopul Normalizarii este asigurarea Fidelitatii maxime a Modelului de Date fata de realitatea din Spatiul de Informatii Limbajele formale de Manipulare Relationala a Datelor (LMD) nu pretind dect minima Conditie de Calitate a Structurilor Relationale de Date si anume Forma Normala FN1 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 cteva 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 2 Care sunt, pentru activitatea de proiectare, rezultatele finale ale analizei Dependentelor existente n structuri? 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)? Care este rolul pe care Analiza si Sinteza Formala a Dependentelor l joaca n Proiectarea Structurilor? Exista o metoda riguroasa de Proiectare Informala a Structurilor Optime? 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

3 4 Raspunsuri: 1

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 att a Claselor de Entitati, ct 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

Coborrea 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, sfrsind 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 cstigul principal al preocuparilor de Normalizare si anume necesitatea coborrii 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. Ramne 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

Cstigul cel mai mare al Tratarii Analitice a Dependentelor n cadrul Structurilor de Date consta n oferirea unui Instrument Fundamentat Teoretic pentru formarea Gndirii 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

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 cnd e vorba despre Proiectarea Structurilor de Informatii si de Date? In primul rnd 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 o Nivelele superioare - Structurile Finale (Nenormalizate) Nivele de Utilizator (deservesc necesitatile de informare ale Utilizatorului.) Nivelele intermediare Structurile Intermediare (Nenormalizate) Nivele Mixte (de Utilizator si / sau de Sistem)

414 o

Optimizarea Structurilor de Date

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, putndu-se ajunge pna 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 cnd 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

Nivel 7

BNC b

Nivel 6

BO b

BN tl n tb n b

tl n n n tb n

BT b tb n

* p*
BC b

*
n

q n

*
Nivel 5

*
C
Nivel 4

q n p

q n

*
FB
Nivel 3

b a n

lb

lp

*
p

SD q n

*
l

*
B t n

*
P

a n

Nivel 2

c
Nivel 1

L t n

*
c

n n

r n

g n

*
c
c - cod n - nume a adresa

*
n

r - culoare g - greutate b - cod beneficiar

Legenda B BENEFICIAR BO vedere BENEFICIAR-ORAS P PRODUS BN vedere BENEFICIAR-NUME C CONTRACT BT vedere BENEFICIAR-TIP L LOCALITATE BNC vedere BENEFICIAR-NUMEFB FILIALA BENEFICIAR -CONTRACT SD STOC-DEPOZIT BC vedere BENEFICIAR-CONTRCT t - tip tb tip societate lb oras beneficiar q - cantitate tl tip localitate lp oras produs p - cod produs l localitate

Fig. 5.1.4.1.1 Arborele de Structura proiectat BOTTOM-UP pentru structura BNC

416 Observatii: o

Optimizarea Structurilor de Date

Se remarca construirea pe Nivele a Structurii de Date Nivelele Inferioare (1, 2) reprezinta Structura Elementara (de Baza) Constructiile sunt simple ntruct 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 (nti 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

Reprezinta Date de Centralizare (prin nsumarea Cantitatilor pe Beneficiari si Produse, indiferent de Localitatile de Sediu) Deserveste exclusiv necesitati de consultare si nu de actualizare ntmplator Structura e Normalizata (dar contine Date Calculate) Consistenta Virtuale e asigurata prin Materializarea Datelor

o o o

Nivelele Superioare (6,7) sunt destinate Viziunilor particulare ale diversilor Utilizatori Reprezinta Date Finale extrase din Baza de Date Poate deservi restrictionata necesitati de consultare si de actualizare

Structurile apar Denormalizate, dar aceasta calitate nu intereseaza pe proiectant pe acest Nivel Consistenta e asigurata, n ciuda denormalizarii, Materializare a Datelor Virtuale prin aceeasi

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 att pentru BENEFICIAR ct si pentru PRODUS Acceptarea Sediilor multiple pentru acelasi BENEFICIAR si pentru acelasi PRODUS 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)

Rezolvarea fireasca a Dependentelor Artificiale din Structuri

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 C1 C1 C2 C2 Manual M1 M2 M3 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 C1 C1 C1 C1

Profesor P1 P1 P2 P2

Manual M5 M6 M7 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 C1 C1 C1 C1 C1 C1 C1 C1 C2 C2 Profesor P1 P1 P1 P1 P2 P2 P2 P2 P3 P3 Manual M1 M2 M5 M6 M1 M2 M7 M8 M3 M4

Tab. 5.1.4.1.2 Extensiunea Structurii CPM Forma 3 Se remarca mentinerea Dependentelor Multivalorice initiale restrnse: 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 putndu-se modifica prin simple adaugari de Tuple n Relatiile de Legatura CM si / sau CPM1 .

420

Optimizarea Structurilor de Date

Nivel 5

CPM

*
p

* *
CPM

Nivel 4

CPM

m p

*
Nivel 3 Nivel 2

* *

*
p

CPM 1

CP p c c

CM

*
C

*
f n n n

*
P

*
t n c

*
M

Nivel 1

*
Legenda

n n

n n

r n

C CURSURI P PROFESORI M MANUALE c Cod n Nume t Titlu f Fel r Cuprins

CP PROFESORI / CURSURI PM MANUALE / PROFESORI CM MANUALE / CURSURI

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

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, lasnd-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 ntruct pe aceste Nivele se definesc Dependentele Multivalorice ca si Clase de Entitati distincte (Relatiile de Legatura CP si CM reprezinta si ele la rndul 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 mentine Complet Independenta ea se va lega tot de -si 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 o Atribute c, p, m Cheie primara c,p,m

Dependente Functionale

Optimizarea Structurilor de Date

423

Curs Profesor Curs Manual Structura Normalizata

In structura CPM Structura o o Atribute c, p, m Cheie Primara c, p, m Curs Profesor Curs Manual Curs, Profesor Manual Structura Denormalizata (Consistenta rezolvata prin Materializarea Datelor)

Dependente Functionale, datorate reunirii a 2 structuri intermediare

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 n erealista 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) Ramne 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 Observatii pentru varianta I-a: o

Optimizarea Structurilor de Date

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

Nivel 3

SPT
s

*
p

Nivel 2

SP

PT

TS

s
Nivel 1

*
S

*
a n

*
P

*
t n

*
T

n n

*
Legenda

n n

n n

f n

S STUDENTI P PROFESORI T PROIECTE

SP STUDENTI / PROFESORI PT PROFESORI / 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

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)

Analiza exemplului prezentat releva nca o data faptul ca solutia ce se propune porneste de la o abordare naturala a problemei conceperii unei structuri, ncepnd 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)(s 1 ,p1 ,z) SPT and (x, p1 , t1 ) SPT and (s,y, t1 ) SPT (s 1 ,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 ntruct 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

Nivel 3

SPT

*
p

Nivel 2

SPT

*
t n

*
T

Nivel 1

S
an c

n n

*
Legenda

n n

n n

f n

S STUDENTI P PROFESORI T PROIECTE

SP STUDENTI / PROFESORI PT PROFESORI / 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

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 o o Toate Entitatile sunt Obiecte Abstracte Toate Caracteristicile (Atributele) Entitatilor sunt si ele Obiecte Abstracte Toate Atributele unei Entitati reprezinta Identificatori si se clasifica n: o Atribute Autoidentificabile Caracteristici Elementare (Atribute care se Autorefera) toate

Atribute Identificatoare (Atribute care refera Entitati) Caracteristici ce Identifica prin Referire Asociativa alte Entitati Obiecte Abstracte Primitive Caracteristici Elementare Obiecte Abstracte Derivate (Generate) Entitati

Orice Structura de Obiecte Abstracte contine:

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
AGREGARE Obiecte Abstracte Initiale Obiecte Abstracte Derivate Entitatea Clasificata Entitatea care Clasifica

Nivel de implementare
Relatie de tip OARECARE Relatie de tip MIXT sau de LEGATURA (Simpla sau Completa) Relatie de tip OARECARE Relatie de tip MIXT sau de LEGATURA (Simpla sau Completa) tip

GENERALIZAREA

tip

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 Constrngerilor 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 cnd poti simplu sa ngrijesti ? si care transpus n sfera programarii suna astfel: De ce sa ajungi sa Optimizezi cnd poti simplu sa Proiectezi Optim ? Rezultatele studiului analitic al Dependentelor n Structuri ramn 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 ntruct 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 att 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. Ramne 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. ntruct 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 o Relatiile AB si CD care participa la Produsul Cartezian (Numele Relatiilor este construit prin Concatenarea Numelor de Atribute ce alcatuiesc Relatiile) Corespondentele Fizice cu Elementele de Gestiune atasate Relatiilor: o Relatie Fisier Tupla nregistrare 1 Bloc = n Inregistari 1 Tampon = 1 Bloc Memoria Interna m Tampoane 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

Dimensiunile Elementelor de Gestiune Fizica angajate n Operatie:

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

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 cteva 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 Cererea transpusa n Algebra Relationala ia forma:

Optimizarea Cererilor

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)
o Selectia

(AB x

(D = 99) CD))

(B = C)

transforma Produsul Cartezian n Reunire Naturala: (AB (

A
o

(B = C) x (D = 99) CD))

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 cteva accese de Blocuri din CD pentru calculul expresiei:

(D = 99) CD
Tabela de Index (TIB AB) reduce timpul pentru Reunirea Naturala la cteva accese de Blocuri din AB pentru fiecare cautare de valoare distincta c din C pentru calculul expresiei: AB ( In Concluzie: Reorganizarea Cererii a redus sub 1 / 10 Numarul de Accese.

(B = C)

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 ct 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, cnd Timpul de Calcul e mai mare dect 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, cnd 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

PARTEA a 6 -a SECURITATEA BAZELOR de DATE

Partea a 6 este consacrata temei mai largi a mentinerii -a 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, ajungndu-se pna 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 exploatnd 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

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

avnd precizate ca functii garante ale Securitatii Volumelor Mari de Date: o o Controlul Accesului la Date al utilizatorilor, n special n regim de Multiacces 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 o o Administrator de Baza de Date ( ABD ) Grupuri de Utilizatori ( G i ) Subgrupuri de Utilizatori ( G i j ) Utilizator ( Ui ) Aplicatii ( APL i ) Vederi ( V i j ) Relatii ( R k ) Atribute ( A kl ) Acordare / Revocare Drepturi (D 1 ) vezi Tab. 6.1.1.3 Drepturi pentru Scriere Date (D 2 ) Drepturi pentru Citire Date (D 3 )

Resursele Oferite (Date si Proceduri) (R) vezi Fig. 6.1.1.2

Drepturile Acordate (D)

Securitatea Bazelor de Date / Controlul Accesului la Date

437

ABD

G1

G2

G11

G13

U1

U2

U3

U4

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 o o Definirea / Stergerea Categoriilor de Informatii Acordarea / Revocarea Drepturilor 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 lnga 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. APL 1 APL 2

V11

V12

V21

V21

R1

R2

R1

R3

A11

A12

A21

A22

A11

A12

A31

A32

Fig. 6.1.1.2 Ierarhia de clasificare a Resurselor

438

Securitatea Bazelor de Date / Controlul Accesului la Date

Utilizatori G1 G11 U1 G13

Resurse V11 R1 A12 -

Drepturi D3 D2 D2 D1

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 rndul ei ca un Drept care se poate acorda Utilizatorilor, la nceput de catre ABD, apoi de Utilizatorii care au cstigat acest drept, altor Utilizatori. Acest Drept este considerat ca maxim privilegiu, putndu-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 cteva 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 o o o Date Strict Secrete (SS) Date Secrete (SC) Date Clasificate (CL) 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 Gradul de Confidentialitate al Atributelor se declara d e 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 Cheie Primara Aparenta Identificatorul natural al Relatiei (Ansamblu de Atribute)

Actualizarea Valorilor Gradelor de Confidentialitate se face astfel:

Se diversifica Identificatorul Relatiilor (Cheia Primara) astfel:

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 o Toate Componentele Cheii Primare Aparente trebuie sa fie nenule 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) Toate Componentele Cheii Primare Aparente trebuie sa aiba un Grad de Confidentialitate egal n toate tuplele sinonime din cadrul Poliinstantierii Utilizatorul are dreptul sa rescrie numai Tuple la care are acces potrivit Gradului sau de Confidentialitate (GC t = GC Utilizator ) 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 putnd Deriva Vederi din Tuple cu un Grad de Confidentialitate mai mare, din care nsa

o -

Vederile Utilizatorilor se construiesc printr-o dubla filtrare: o

Securitatea Bazelor de Date / Controlul Accesului la Date

441

nu poate vedea dect 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, GC marca, Nume, GC nume , Prenume, GC prenume , Salariu, GC salariu, Performanta, GC performanta, GC tupla ) 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 M1 NC M2 CL Nume N1 NC N2 CL Prenume P1 NC P2 CL Salariu S1 CL S2 SC Performanta P1 SC P2 CL GC tupla SC 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 M1 NC M2 CL Nume N1 NC N2 CL Prenume P1 NC P2 CL Salariu S1 CL null CL Performanta null CL P2 CL GC tupla 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 M1 NC Nume N1 NC Prenume P1 NC Salariu null NC Performanta null NC GC tupla 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 M1 NC M1 NC M2 CL Nume N1 NC N1 NC N2 CL Prenume P1 NC P1 NC P2 CL Salariu S1 CL S1 CL S2 SC Performanta P1 SC P11 CL P2 CL GC tupla SC 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 o Transmiterii Datelor Confidentiale 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 ajuns astfel la -a 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 ntlnita 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
T11 T11 UC T11 UC T11 UC 1 UC 2 T21 T12 T21 T12 T22 T12

UC

Cazul 1 Cazul 2 Cazul 3

Cazul 4

Timp

Fig. 6.2.1 Executia intermitenta si ntretesuta a Tranzactiilor In Fig. 6.2.1 sunt prezentate cteva 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, repartiznd fiecarei Tranzactii sarcini n cuante programate de timp. Aceasta conduce la o Executie Intermitenta si ntretesuta a Tranzactiilor Active

444 -

Securitatea Bazelor de Date / Prelucrari Tranzactionale

Unitatea Centrala executa si alte operatii apartinnd 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 cte doua secvente de procesare T11 , T12 si T21 , T22 , care se prelucreaza toate serial, din cauza prezentei unui singur procesor ( C). Desi prelucrarea se termina normal, n acest caz pot apare probleme U 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 cte 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 cteva 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), ntruct tranzactia T2 citeste nainte de ncheierea tranzactiei T1 , ea risca, n situatia de esuare a primei tranzactii, sa ramna 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

Tranzactia

Tranzactia

T1
CITIRE element X
X=X+N

T2

CITIRE element X
X=X+M

SCRIERE element X CITIRE element Y SCRIERE element X

Y=Y+N

Elementul X are valoare eronata Actualizarea din T1 e pierduta fiind rescrisa de T2

SCRIERE element Y

Timp

Fig. 6.2.1.1 Pierderea de actualizari prin Rescriere

Tranzactia Tranzactia

T1
CITIRE element X

T2

X=X+N
SCRIERE element X CITIRE element X
X=X+M

SCRIERE element X CITIRE element Y

Elementul X are valoare eronata T1 a refacut pe X la valoarea initiala la sfrsitul tranzactiei

Tranzactie esuata Se reface vechea valoare X

Timp

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, ntruct T1 rescrie elementul Z pe care T2 a apucat deja sa-l centralizeze n variabila S.

446

Securitatea Bazelor de Date / Prelucrari Tranzactionale

Tranzactia

Tranzactia

T1

T2
S=0 CITIRE element X

S=S+X
CITIRE element Y

Y=Y-N
SCRIERE element Y CITIRE element Y

S=S+Y
CITIRE element Z

S=S+Z
CITIRE element Z

Suma calculata S are valoare eronata T1 modifica ulterior valoarea Z

Z=Z+N
SCRIERE element Z

Timp

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)

Securitatea Bazelor de Date / Prelucrari Tranzactionale

447

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 o Operatii de Citire (Read Only) Operatii de Citire / Scriere (Read-Write)

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 o BEGIN_TRANSACTION Declararea nceputului tranzactiei END_TRANSACTION Declararea sfrsitului tranzactiei. In acest punct se verifica: Terminarea executiei comenzilor lansate READ si WRITE Conditia de persistenta a actualizarilor efectuate, cu lansarea expresa a comenzilor: o o o COMMIT_TRANSACTION - Acceptarea Transferul Noii Stari n Baza de Date actualizarilor prin

ROLLBACK Refuzarea actualizarilor prin Refacerea Starii Initiale a Bazei de Date

READ Citire din Baza de Date WRITE Scriere n Baza de Date COMMIT_TRANSACTION Semnalarea Tranzactiei, cu urmatoarele consecinte: unei ncheieri cu succes a

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)

ROLLBACK (ABORT) Semnalarea unei ncheieri f succes a Tranzactiei, ara 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) 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 o o o Tranzactia e activata de declaratia BEGIN TRANSACTION Tranzactia poate lansa operatii READ si WRITE 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 Tranzactia a ncheiat cu succes transferului actualizarilor n Baza de Date Tranzactia a primit raspuns negativ din partea controalelor si interogarilor efectuate Tranzactia este abandonata prin operatia ABORT, emisa n starea sa Activa

Stare Partial Executata

Stare Executata Stare Esuata

Securitatea Bazelor de Date / Prelucrari Tranzactionale

449

READ WRITE

BEGIN TRANSACTION
Tranzactie

END TRANSACTION

Tranzactie

COMMIT
Tranzactie

ACTIVA

PARTIAL EXECUTATA

EXECUTATA

ABORT ABORT

Tranzactie

Tranzactie

ESUATA

TERMINATA

Fig. 6.2.3.1 Diagrama de Stari ale unei Tranzactii

450

Securitatea Bazelor de Date / Prelucrari Tranzactionale

Stare Terminata Tranzactia a parasit sistemul Tranzactia trebuie relansata (automat sau programat)

6.2.4 Jurnalizarea Tranzactiilor Avnd 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 att Valorile Noi ct 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) Cnd 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 BEGIN_TRANSACTION

Parametri T Nr. Intern Tranzactie T Nr. Intern Tranzactie

Actiuni - nregistreaza o noua tranzactie - nregistreaza modificarea Valorilor unei Date (Veche si Noua)

WRITE

X Nume Cmp Vv Valoare Veche Vn Valoare Noua

READ

T Nr. Intern Tranzactie X Nume Cmp

- nregistreaza Numele Datei citite - marcheaza o Tranzactie reusita - anunta pregatirea pentru transferul n BD a Starii Finale - marcheaza abandonata o Tranzactie

COMMIT

T Nr. Intern Tranzactie S Indicator Succes (adevarat)

ABORT

T Nr. Intern Tranzactie S Indicator de Succes (fals)

- 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 o o Atomicitate Tranzactia e efectuata n ntregime (cu toate operatiile elementare pe care le contine) sau deloc (cu revenire la Starea Initiala) Consistenta o executie corecta a unei Tranzactii determina trecerea Bazei de Date dintr-o Stare Consistenta n alta Stare Consistenta Izolare modificarile efectuate n cadrul unei Tranzactii trebuie sa ramna 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)

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 cteva 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: 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) , s 1 (X) , c1 (Y) , s 1 (Y) , e1 T2 : c2 (X) , s 2 (X) , e2 Se construieste Planul de Operatii Tranzactionale: P1 : c1 (X) ; c2 (X) ; s 1 (X) ; c1 (Y) ; s 2 (X) ; e2 ; s 1 (Y) ; e1 Pentru exemplul din Fig. 6.2.1.2: Cu Operatiile din Tranzactiile: T1 : c1 (X) , s 1 (X) , c1 (Y) , a1 T2 : c2 (X) , s 2 (X) , e2 Se construieste Planul de Operatii Tranzactionale: P2 : c1 (X) ; s 1 (X) ; c2 (X) ; s 2 (X) ; e2 ; c1 (Y) ; a1 Citire Item X n Tranzactia i ci (X) Scriere Item X n Tranzactia i si (X) Executie Tranzactie i ei Abortare Tranzactie i ai

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 (Cmp de Date) Contine cel putin o Operatie de Scriere

Exemple de Operatii n Conflict: 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, ntruct Operatiile n Conflict fac ntotdeauna parte din Tranzactii diferite) c1 (X) si s 2 (X) din P1 c2 (X) si s 1 (X) din P1 s 1 (X) si s 2 (X) din P1

Intr-un Plan Complet de Operatii Tranzactionale se poate observa: Operatiile Neconflictuale sunt Partial Ordonate, ntruct ordinea lor e indiferenta Operatiile Conflictuale sunt Total Ordonate, ntruct ordinea lor e critica n Plan Planul nu va contine Tranzactii Active, ci numai Tranzactii ncheiate (prin COMMIT sau ABORT, ultimele operatii din Tranzactii) ntruct 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, reprezentnd: 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 s 2 (X)

Operatia s 2 (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 dect Tranzactii Dependente Corecte. Exemple: Planuri Restaurabile: P1 : c1 (X) ; c2 (X) ; s 1 (X) ; c1 (Y) ; s 2 (X) ; e2 ; s 1 (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) ; s 1 (X) ; c2 (X) ; c1 (Y) ; s 2 (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 (a 1 ) 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 apartinnd 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 ntmplator 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 ntrzieri poate fi cautat n selectarea acelor Tranzactii ntretesute care sunt Echivalente cu Tranzactiile Serializate.
Tranzactia Tranzactia

T1
CITIRE element X
X=X+N

T2

SCRIERE element X CITIRE element Y

Y=Y+N

SCRIERE element Y CITIRE element X

X=X+M

Tranzactia T2 e pornita numai dupa terminarea Tranzactiei T1

SCRIERE element X

Timp

P4 : c1 (X) ; s 1 (X) ; c1 (Y) ; s 1 (Y) ; e1 ; c2 (X) ; s 2 (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 nct sa se asigure executia nentrerupta (Nentretesuta) a fiecarei Tranzactii (ex. Figurile 6.2.8.1 si 6.2.8.2)

456 -

Securitatea Bazelor de Date / Prelucrari Tranzactionale

Planuri Neseriale care sunt Secvente de Operatii grupate pe Tranzactii, astfel nct 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, efectundu-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.
Tranzactia Tranzactia

T1

T2
CITIRE element X
X=X+M

SCRIERE element X CITIRE element X

X=X+N

SCRIERE element X CITIRE element Y

Y=Y+N

Tranzactia T1 e pornita numai dupa terminarea Tranzactiei T2

SCRIERE element Y

Timp

P5 : c2 (X) ; s 2 (X) ; e2 ; c 1 (X) ; s 1 (X) ; c1 (Y) ; s 1 (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

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, ntruct 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 ntruct 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) ; s 1 (X) cu s 1 (X) ; c2 (X) c2 (X) ; s 1 (X) cu s 1 (X) ; c2 (X) Se remarca mentinerea Ordinii Operatiilor n fiecare Tranzactie: c1 (X) ; s 1 (X) ; c1 (Y) ; s 1 (Y) n T1 c2 (X) ; s 2 (X) ; c2 (Y) ; s 2 (Y) n T2 si totodata mentinerea Independentei Secventelor de Operatii: c2 (X) ; s 2 (X) din T2 c1 (Y) ; s 1 (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 ntruct 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

Tranzactia

Tranzactia

T1
CITIRE element X
X=X+N

T2
Regruparea Operatiilor din Tranzactii se face prin inversarea Operatiilor Conflictuale CITIRE element X
X=X+M

SCRIERE element X

SCRIERE element X CITIRE element Y

Y=Y+N

SCRIERE element Y

Timp

P6 : c1 (X) ; s 1 (X) ; c2 (X) ; s 2 (X) ; c1 (Y) ; s 1 (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. Comparnd 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: s 2 (X) scrie n BD s 1 (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. Comparnd cele doua Planuri se remarca:

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 Permite Intreteserea Operatiilor Este Performant n privinta utilizarii Timpului de Calcul Este Echivalent cu Planul Serial

Planul de Executie P3 este un Plan Serializabil

Exemple: Plan Neserial Incorect - vezi Fig. 6.2.8.4 Planul P7 nu este Echivalent cu nici unul din Planurile Seriale P4 sau P5 ntruct Sursele Datelor citite difera.
Tranzactia Tranzactia

T1
CITIRE element X
X=X+N

T2

CITIRE element X
X=X+M

SCRIERE element X CITIRE element Y SCRIERE element X

Y=Y+N

Planul e Nerializabil c2 (X) ; s 2 (X) n Conflict Prin inversare nu se ajunge la un Plan Serial (P1 ) Planul e Nerializabil s 1 (X) ; s 2 (X) n Conflict Prin inversare nu se ajunge la un Plan Serial (P2 )

SCRIERE element Y

Timp

P7 : c1 (X) ; c2 (X) ; s 2 (X) ; s 1 (X) ; c1 (Y) ; s 1 (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

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 ntruct nu se pot reordona Operatiile Conflictuale: c2 (X) ; s 1 (X) nu pot fi inversate pentru a-l echivala pe P7 cu P4 s 1 (X) ; s 2 (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 s k (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 s k+n (X) apare n Tranzactia Tj Pentru fiecare Pereche de Noduri Ti ,Tj Creeaza un Arc {Ti , Tj} daca: Operatia s k (X) apare n Tranzactia Ti Operatia s k+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

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); s 1 (X); c2 (X); s 2 (X); c1 (X); s 1 (X); c2 (X); s 2 (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 o Tranzactia n curs are acces Exclusiv la Resursa Celelalte Tranzactii care solicita acces la aceeasi Resursa sunt puse n Asteptare (WAIT) Tranzactia n curs a ncheiat accesul la Resursa Tranzactiile puse n Asteptare sunt activate Celelalte Tranzactii care solicita acces la aceeasi Resursa primesc acces

Deblocata o o o

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 o Identificatorul Elementului de Resursa Marcajul de Blocare avnd urmatoarele Valori: Blocat Deblocat

Actualizarea Tabelei TCB se face de catre Utilizator prin Comenzile: o o LOCK <Identificator Resursa> - pentru Blocare Resursa 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 o 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

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 Celelalte Tranzactii care solicita acces la aceeasi Resursa sunt puse n Asteptare (WAIT) Tranzactia n curs are acces Exclusiv la Resursa Celelalte Tranzactii care solicita Acces n Citire sau n Scriere la aceeasi Resursa sunt puse n Asteptare (WAIT)

Blocata la Scriere o o

Deblocata o o o Tranzactia n curs a ncheiat accesul la Resursa Tranzactiile puse n Asteptare sunt activate 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 o Identificatorul Elementului de Resursa Marcajul de Blocare avnd urmatoarele Valori: o Blocat n Citire utilizare Partajata Blocat n Scriere utilizare Exclusiva Deblocat

Numarul de Tranzactii care au cerut Blocare n Citire

Actualizarea Tabelei TCB se face de catre Utilizator prin Comenzile: o o o READ_LOCK <Identificator Resursa> - pentru Blocare n Citire WRITE_LOCK <Identificator Resursa> - pentru Blocare n Scriere 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 Definire - Datorita Prioritatii Scazute, o Tranzactie ramne mereu n Asteptarea de Resurse Remediu Modificarea Dinamica a Prioritatilor Tranzactiilor

Blocarea Aparenta a Tranzactiilor (Livelock)

Tehnica de Blocare a Resurselor ofera o metoda practica de a controla executia Tranzactiilor. S-a ncercat doar prezentarea conceptelor de baza, ntruct 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.). Cteva 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 (Cmp de Date) Tupla de Relatie (Rnd 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 o Elementele ce constituie Resursa au dimensiuni mici, ceea ce determina Imobilizari Reduse de Resurse Gradul de Siguranta n finalizarea Tranzactiilor Lansate este mai mic, datorita Conflictelor Multiple ce pot apare pe parcursul executarii Tranzactiilor Fluxul Tranzactiilor e crescut, datorita posibilitatii Lansarii Paralele a mai multor Tranzactii 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. Elementele ce constituie Resursa au dimensiuni mari, ceea ce determina Imobilizari Extinse de Resurse Gradul de Siguranta n finalizarea Tranzactiilor Lansate e crescut de garantarea accesului nestnjenit la toate Resursele Fluxul Tranzactiilor e scazut datorita numarului mare de Tranzactii aflate n asteptarea unei Prelucrari mai mult Seriale 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

o o

Resurse cu Granularitate Scazuta o o o o

In general Granularitatea ramne Fixa pe durata gestiunii Tranzactiilor, existnd 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)

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 Intruct Tranzactiile reprezinta Elementele Atomice de trecere a unei Baze de Date dintr-o Stare Consistenta n alta, Refacerea Structurilor de Date este strns 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. ntruct Imaginile Anterioara si Ulterioara sunt memorate n permanenta n Jurnalul Tranzactiilor, gestiunea acestei Colectii de Date este esentiala att pentru Controlul Tranzactiilor, ct 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 . 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.) 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 (att ca Structura Interna, ct 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

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 o Baza de Date din momentul incidentului BD12 , aflata ntr-o Stare Inconsistenta Ultimele Tranzactii ( T13 si RT12 ) memorate n Jurnalul R de Tranzactii JT1 (Jurnalul Curent de Tranzactii), dupa ultima Stare Intermediara (Punct de Control) Consistenta

Securitatea Bazelor de Date / Refacerea Bazelor de Date

T11

469

RT12

T13

T21

T22

T23

BD1

BD11

BD12

BD2

BD21

BD22

BD3

SBD

RT12 ST11

ST12

I RT13 ST13 SBD

2

SBD

Refacere la Cald

T11

ABD1 JT1

ABD2

JT2

ABD3

RBD 1

RT11

RT12

RBD 2

RBD 3

Refacere la Rece

BD1

BD11

BD12

BD2

BD21

BD22

BD3

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

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 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 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 Actualizarea Copiei de Referinta BD1 cu toate Tranzactiile RT11 continute n Jurnalul Tranzactiilor JT1 si care au fost nregistrate dupa Salvarea Copiei de Referinta pna la Punctul de Control Consistent BD11, cel mai apropiat de Incident si care se afla nregistrat tot n Jurnalul Tranzactiilor JT1

Procedura consta din urmatoarele Operatii: o

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 cnd 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 ntlnita 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 strns 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 Amnata 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 Nencheiata (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)

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 Nencheiata (T4 si T5 din Fig. 6.3.2.1) o BD poate fi Partial Actualizata si Refacerea trebuie sa efectueze Operatii UNDO BD este Complet Actualizata si Refacerea nu trebuie sa efectueze Operatii REDO

Tranzactie ncheiata + Incident (candidate T2 si T3 din Fig. 6.3.2.1) o

Protocol ce ncheie Tranzactia nainte de terminarea tuturor Actualizarilor Imediate (Refacere de tip UNDO / REDO Tranzactie Nencheiata (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 T1

Securitatea Bazelor de Date / Refacerea Bazelor de Date

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 rnd n Actualizarea Tranzactiilor n BD si de care se tine apoi cont si n procesul de Refacere a Bazei de Date. Strategia Nume Algoritm de Refacere NO-UNDO / REDO Executia Tranzactiei Starea Tranzactiei nainte de COMMIT dupa COMMIT nainte de COMMIT dupa COMMIT nainte de COMMIT dupa COMMIT Zona de Memorie n Jurnal n BD da da da da da da nu da partial da total da Metoda de Refacere din Jurnal ROLLBACK ROLLBACK n BD REDO UNDO REDO UNDO -

Amnata

UNDO / REDO Imediata UNDO / NO-REDO

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 Amnata 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) 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 ct mai repede vizibile actualizarile unei Tranzactii, n aceasta tehnica transferul Valorilor Noi din Jurnalul de Tranzactii n Baza de Date nu mai este Amnata pna la Terminarea Tranzactiei, ci este efectuata Imediat ce este ntlnita o Operatie de Actualizare (Operatie WRITE). ntruct 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 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), ajungndu-se la cea mai complexa Tehnica de Refacere

474

Securitatea Bazelor de Date / Refacerea Bazelor de Date

PARTEA a 7 -a BAZE de DATE EVOLUATE

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

Baze de Date Evoluate

Sectiunea prezenta urmareste sa contureze, prin cteva 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 adnci ale acestor concepte merita si n prezent si mai ales n viitor atentie, sau daca sunt epuizate si nvechite, amenintnd sa se transforme, pe lunga cale a progresului, din Stimulent n Frna. 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 attea reveniri la matca din care au izvort 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 ramne n sfera exercitiului. Desigur ca adaptarea Surselor de Date la necesitatile specifice fiecarui domeniu va ramne 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 rnd 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 pna 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 dect 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 d Fragmentare si n e 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, putnd 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 ntmpinare 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 att Faptele ct 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), avnd urmatoarele caracteristici de baza: o 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

Sistemele cu Baze de Date Deductive (SBDD) se bazeaza pe Viziunea Inferentiala (Proof-Theoretic View), avnd 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), dezvoltnd 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 ctorva Concepte de Baza referitoare la Mecanismul de Inferenta bazat pe Fapte si Reguli de Deductie. 7.1.1 Inferenta bazata pe Calculul Propozitional Reprezentnd 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: Exemple: Beneficiarul 1 are Codul B1 este Termen Beneficiarul cu Codul B1 are sediul n Orasul O1 este Termen 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)

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 rnd 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 Este ntotdeauna Adevarat

urmatoarea afirmatie:

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 1. 2. 3. 4. 5. 6. Continut (f g) f f (f g) ((f g) (g h)) (f h) (f (f g)) g (f (g h)) ((f g) h) ((f g) ( g h)) (f h) Denumire Transformare Transformare Tranzitivitate Modus Ponens Transformare 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 apelnd la o noua Metainstructiune Declarativa + , ce corespunde afirmatiei : Este o Consecventa Logica Deducerea se transcrie astfel: f 1 , f 2 , .. , f n + care se citeste si astfel: g este Deductibila din f 1 , f 2 , .. , f n g

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 pna 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, considernd 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) + Pasii de Deductie sunt urmatorii: Adoptarea unei noi Premize prin Reducerea la Absurd Adoptarea Concluziei Negate ca Premiza Scrierea Premizelor p e cte 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 D C

482 D C

Baze de DateEvoluate / Baze de Date Deductive

Aplicarea Legii Rezolutiei (eliminarea Formulelor ce apar si negate) Prima aplicare A B C D A B D C A doua aplicare D B C B D C A treia aplicare D C D C A patra aplicare C C C C D C D C D B C B D 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) + 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, extinznd 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). D C

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 avnd nsa posibilitatea redefinirii lor sau a definirii unor noi Predicate. In Sistemele cu Baze de Date Predicatele corespund Relatiilor, Lista Atributelor de Definitie jucnd 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, reprezentnd 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, apelndu-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 O Constanta O Variabila O Functie, avnd 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

Regulile de Precedenta se preiau din Calculul Propozitional

Baze de Date Deductive

484 Regula Subcapitol Numar 1. 2. Continut Un Simbol de Constanta sau Variabila sunt Termeni 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 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 7. Transformare 8. 9. 10. Daca F1 e Formula Atunci ( F1 ) e Formula (F1 F2 ) se substituie cu F1 F2 ( F1 F2 ) se substituie cu F1 F2 x F1 se substituie cu x F1

Sectiune Capitol Definire Termeni

Definire Formule (Fraze)

5.

Simplificare Formule

Operatori Logici Transformare Cuantificatori

Tab. 7.1.3. Lista Regulilor de Definire a FBC ntr-un Limbaj Predicativ

Baze de DateEvoluate / Baze de Date Deductive

485

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) Deschise (Libere) - daca cel putin o Variabila este Libera nchise (Legate) - daca toate Variabilele sunt Legate

Formulele care apar n Limbajul Predicativ pot fi :

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 (reprezentnd 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 attea 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 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 valori n D
n

cu

486 Exemplu: Fie Predicatul: > (x, y)

Baze de DateEvoluate / Baze de Date Deductive

La fiecare Simbol de Predicat - o Relatie pe D n

si fie urmatoarele Formule Bine Construite (FBC): f1 f2 f3 f4 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 f2 f3 f4 2>1 2>3 x (x > 2) x (x > 2) - adevarata - falsa - adevarata - falsa c2 > c1 c2 > c3 x (x > c2 ) x (x > c2 )

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) f1 f2 f3 f4 2>1 2>3 x (x > 2) x (x > 2) - adevarata - falsa - adevarata - falsa

Se Evalueaza FBC:

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 f2 f3 f4 2>1 2>3 x (x > 2) x (x > 2) - falsa - falsa - adevarata - falsa

Nu ntmplator 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 cnd 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 ntia poate reprezenta un Model pentru urmatorul Set de FBC: f1 f2 f3 f4 2>1 3>2 x (x > 2) x (x > 2 (x > 2 )) - adevarata - adevarata - adevarata - 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: X F ( X ) I F ( ai ) a i D
X F ( X )

U F ( ai ) a i D

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 strns 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

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: = 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,+ > >
b

>

M=< b , I,+ unde:

I reprezinta Postulatele de Interpretare ale Axiomelor de Baza O Teorie T , exprimata prin ansamblul de FBC si interpretarea I este: o Valida daca tot ce se Deduce e si Adevarat o + F F

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). ntruct 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, reprezentnd 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 cte o linie p(x) AND q ( f ( x ), z ) Forma Clauzala se obtine eliminnd 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 avnd Forma: NOT A1 OR NOT A2 OR NOT .. OR NOT Am OR B 1 OR B 2 OR .. OR B n unde: A1 , A2 , .. , Am , B 1 , B 2 , .. , B n - 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 B 2 OR .. OR B n Definitie: Clauza Horn este o Clauza Generala rescrisa n forma: A1 AND A2 AND .. AND Am B1 OR B 2 OR .. OR B n 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 Astfel am dovedit Adevarul: A1 , A2 , .. , Am B C 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) conversie BAZA de DATE Date

SPATIU de INFORMATII Informatii

Fig. 7.1.6.1. Conversia Informatii - Date Atunci cnd se doreste dotarea SBD cu facilitati de Deducere trebuie pornit de la forma de reprezentare n aceste sisteme a celor doua categorii de informatii:

494 o

Baze de DateEvoluate / Baze de Date Deductive

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): 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), utiliznd n acest scop Atributul Sex din Relatia PERSOANA ca si Conditie de Selectie pentru generarea Instantelor din Relatia TATA, astfel nct 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. Clasele de Entitati Relatiile ntre Clase de Entitati

PERSOANA
Cod* p1 p2 p3 p4 p5 p6 p7 p8 Nume N1 N2 N1 N4 N5 N1 N7 N8 Prenume PR1 PR2 PR1 PR3 PR3 PR4 PR5 PR6 Sex B F B F B B F B Data-Nasterii D1 D2 D3 D4 D5 D6 D6 D7

TATA
Tata* p1 p1 p3 p5 Fiu* p3 p5 p6 p8

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

Baze de DateEvoluate / Baze de Date Deductive

495

Exemplu: Regula r 1 Daca p 1 este TATA pentru p 2 Atunci p 2 este FIU pentru p 1 Regula r 2 Toate persoanele au doi parinti Regula r 3 Daca p 1 este TATA pentru p 2 si p 2 este TATA pentru p 3 Atunci p 1 este BUNIC pentru p 3 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* p1 p1 p2 p2 p3 p4 p5 p7 Fiu* p3 p5 p3 p5 p6 p6 p8 p8

Fig. 7.1.6.3 Extensiunea Tabelei de Baza PARINTE

496 Regula r 3

Baze de DateEvoluate / Baze de Date Deductive

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 avnd 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* p1 p1 Nepot* p6 p8

Fig. 7.1.6.3 Extensiunea Vederii BUNIC Acum ramne 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 ) ramnnd 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 ) Urmnd aceiasi pasi, dar alegnd 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 o Reguli de Deductie Axiome Deductive (se utilizeaza pentru verificarea ncadrarii Interpretarii ntr-un Model) 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 o Reguli de Deductie Axiome Deductive (se utilizeaza pentru deducerea de Fapte Noi) 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, eliminndu-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 att Structurile de Date, ct si Structurile de Proceduri strns 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 o Simple (Nedecompozabile) - Domenii 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 o o o Restrictii de Domeniu Restrictii de Tupla Restrictii de Tabele de Baza 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 o Proceduri Stocate de Actualizare a BD Proceduri Stocate de Derivare a Datelor Functional Dependente din BD

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 B 2 OR .. OR B n 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 eliminnd implicatia la numai: r (x1 , x2 , .. , xt) pentru x Constante, expresia ia forma unei Propozitii Logice, care e univoc Adevarata, corespunznd 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 p 1 , 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 , s 1 , d1 ) = PERSOANA (p, n2 , pr2 , s 2 , d2 ) n1 = n2 PERSOANA (p, n1 , pr1 , s 1 , d1 ) = PERSOANA (p, n2 , pr2 , s 2 , d2 ) pr1 = pr2 PERSOANA (p, n1 , pr1 , s 1 , d1 ) = PERSOANA (p, n2 , pr2 , s 2 , d2 ) s 1 = s 2 PERSOANA (p, n1 , pr1 , s 1 , d1 ) = PERSOANA (p, n2 , pr2 , s 2 , 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 , s 1 , d1 ) TATA (p1 , p2 ) PERSOANA (p2 , n2 , pr2 , s 2 , 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 , s 1 , d1 ) COD (p1 ) PERSOANA (p1 , n1 , pr1 , s 1 , d1 ) NUME (n1 ) PERSOANA (p1 , n1 , pr1 , s 1 , d1 ) PRENUME (pr1 ) PERSOANA (p1 , n1 , pr1 , s 1 , 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 o o o o Axiomele de Baza reprezentate de Extensiunea Relatiilor din BD Axiomele de Completitudine tot ce nu este afirmat ca Adevarat prin Tuplele Fizice continute n Relatii se considera Fals (Presupunerea de Univers nchis) Axiomele de Unicitate fiecare Nume de Termen este unic n sistem Axiomele de nchidere a Domeniilor toate Constantele din sistem sunt cele continute n Domeniile BD 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 att Procesul de Regasire a Faptelor Declarate, ct 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 reprezentnd 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) TATA (p4 , p2 ) FIU (p2 , p4 ) FIU (p2 , p4 ) conform cu Regula r1 (sectiunea 7.1.6) conform cu Regula r1 (sectiunea 7.1.6) 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

INFORMATII ELEMENTARE INTREBARI PROPRIETATI GENERALE RASPUNSURI DEDUSE

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 o o o o o o o Informatiile Elementare si Proprietatile Generale sunt tratate unitar Metoda putin aplicabila datorita lipsei de eficienta n consumul de Resurse Toate Raspunsurile sunt Deduse Volum foarte mare de Axiome Timpi de Raspuns mari Necesitatea reprezentarii Informatiilor Negative (enuntare de falsuri) Enuntarea ca Regula Generala Tot ce nu e Adevarat e Fals poate conduce la inconsistenta. 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.

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 ntlnite ntr-o Baza de Date (vezi Fig. 7.1.6.1): o o Fapte Declarate n forma Informatiilor Elementare (IE) Cunostinte n forma Proprietatilor Generale (PG)

Separarea apare necesara ntruct 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)

INFORMATIILE ELEMENTARE

PROPRIETATILE GENERALE - Definesc Axiomele Deductive ce stau a l baza procesului Inferential - Impreuna cu Axiomele de Baza definesc Axiomele proprii unei Teorii

Reprezinta Interpretarea Proprietatilor Generale ce Definesc Structura (Axiome de Baza) - Verifica Validitatea Structurii (Axiome de Baza) - Reprezinta un Model (Definire+Interpretare)

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. Adoptnd 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 o Fapte Declarate (ca atare Interpretate) si posibil de obtinut prin Regasire Fapte Deduse ca Adevarate (ca atare implicit Interpretate) si posibil de obtinut prin Deducere

Baze de DateEvoluate / Baze de Date Deductive

509

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

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. 1 1 INTREBARI INFORMATII ELEMENTARE + PROPRIETATI GENERALE INFORMATII ELEMENTARE RASPUNSURI REGASITE

RASPUNSURI DEDUSE 2

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.

510

Baze de DateEvoluate / Baze de Date Deductive

In final se pot retine ca definitorii pentru varianta de SBD Deductiva Mixta urmatoarele caracteristici: o o o o o Informatiile Elementare si Proprietatile Generale sunt tratate diferentiat Raspunsurile pot fi obtinute n primul pas prin simpla Regasire n Baza de Date 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 Timpi mult mai mici de raspuns dect n cazul unei abordari Pur Inferentiale 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 strnsa 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, ntruct 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, ntruct ele vor mbogati chiar Structura BD, prin nregistrarea persistenta n Modelul de Date.

BD TABELE de BAZA INTREBARI VEDERI DECLARATE VEDERI GENERATE RASPUNSURI REGASITE

PROPRIETATI GENERALE BDD 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 o o Tratarea unitara a tuturor Raspunsurilor prin Proceduri de Regasire Transformarea Raspunsurilor Deduse n Date Virtuale (Derivate numai din Fapte) 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)

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 Suprancarcarea 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, trecnd prin fazele intermediare de Implementare si ajungnd pna la fazele finale de Exploatare a BDS. Tehnicile de Fragmentare si Replicare, precum si Procesarea Cererilor Distribuite, specifice Proiectarii, alaturate Tehnicilor de Alocare ntlnite n Implementare, ct 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 dect o simpla colectie de Baze de Date Locale si chiar dect 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 Cererilor Distribuite de Optimizare a

Incorporarea Proprietatilor Atomice n Protocoalele pentru Tranzactii, secvente care apoi se pot executa distribuit Activarea Mecanismelor de Salvare / Restaurare in Regim Distribuit

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 Transparenta de Tranzactie fiecare Tranzactie este protejata de efectul de Concurenta la Resurse al altor Tranzactii 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 avnd 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 ramn 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 o o Accepta o gestiune mai simpla Viteza de acces poate creste 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 o o

Viteza de acces poate scadea 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

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 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 o In Noduri Grupul de Operatii de executat pe o anumita Unitate de Calcul Pe Arce Transferul de Date (Cereri sau Rezultate) ntre Unitatile de Calcul

Stabilirea Planului Operativ de Executie

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 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.

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 att mai necesare cu ct 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 SGBDSul 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 avnd 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 C 1 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 R= Procesare Intermediara Cerere pe U1

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 Strategia 5

Baze de DateEvoluate / Baze de Date Distribuite

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

RR

Procesare Finala Cerere pe U1

B ENEFICIAR.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 ntruct 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 avnd urmatoarele caracteristici : O Statie Centrala (Calculator) Unica pe care sunt concentrate: o 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 multime de Statii Distribuite (Calculatoare numite Noduri) pe care sunt repartizate : Colectiile de Date ale Bazelor de Date

Varianta Distribuita avnd urmatoarele caracteristici :

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

BD Locala

BD Centrala

BD Centrala + BD Locala

Server Client
Statia 1

Server Client

Client
Statia 2 Statia 3

Statia n

RETEA de COMUNICATII

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:

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

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: 7.2.3.1.2 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 Arhitecturi Client - Server

Arhitecturile Client - Server si propun sa distribuie Resursele unui Sistem Informatic (Date si Proceduri) prin concretizarea a doua concepte: o o Specializarea Procedurilor Distribuite 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 avnd 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, neexistnd Copii de Siguranta ale datelor, deci nu exista Replicare. Discutia se va purta asupra Modelului Relational de Date, extinderea putndu-se face si asupra celorlalte Modele de Baze de Date. Fie urmatoarea Structura Relationala descrisa prin Schema de Relatii prezentata mai jos: COMPARTIMENTE SEDII ANGAJATI PROIECTE PROIECTANTI FAMILII (Cod *, Nume, Responsabil, Data-numirii) (Compartiment *, Localitate *) (Nr-asigurare *, Nume, Prenume, Sex, Data-nasterii, Salariu, Compartiment) (Cod *, Nume, Localitate, Compartiment) (Nr-asigurare *, Proiect *, Ore ) (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 c1 n1 c2 n2 c3 n3 Responsabil na1 na2 na3 Data-numirii d1 d2 d3

SEDII Compartiment * c1 c2 c3 c3 c3 ANGAJATI Numar asigurare* na1 na2 na3 na4 na5 na6 na7 na8

Localitate * l1 l2 l2 l3 l4

Nume n1 n2 n3 n4 n5 n6 n7 n8

Prenume p1 p2 p3 p4 p5 p6 p7 p8

Sex s1 s1 s2 s1 s2 s2 s1 s1

Data nasterii d1 d2 d3 d4 d5 d6 d7 d8

Salariu sa1 sa2 sa3 sa1 sa3 sa4 sa5 sa1

Compartiment c3 c3 c2 c2 c3 c3 c2 c1

Baze de DateEvoluate / Baze de Date Distribuite

525

FAMILII Nr-asigurare * na1 na1 na1 na3 na5 na5 na5 PROIECTE Cod * cp1 cp2 cp3 cp4 cp5 cp6 Nume * n1 n2 n3 n4 n2 n5 n1 Sex s1 s1 s2 s1 s1 s2 s2 Data-nasterii d1 d2 d3 d4 d1 d5 d3 Relatia-de-familie r1 r2 r3 r1 r1 r2 r2

Nume np 1 np 2 np 3 np 4 np 5 np 6

Localitate l1 l2 l3 l4 l3 l4

Compartiment c3 c3 c3 c2 c1 c2

PROIECTANTI Nr-asigurare * na1 na1 na5 na6 na6 na2 na2 na2 na2 na3 na3 na7 na7 na4 na4 na8

Cod - Proiect * cp1 cp2 cp3 cp1 cp2 cp2 cp3 cp4 cp5 cp6 cp4 cp4 cp6 cp6 cp4 cp4

Ore o1 o9 o2 o1 o8 o2 o7 o1 o6 o2 o1 o5 o2 o2 o3 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:

Ci 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 m ulte Fragmente Orizontale. Din aceste motive are semnificatie operatia de Fragmentare Orizontala Completa si Disjuncta, definita prin expresia: Ri =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:

Li

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( ) Li = Listele Atributelor de Proiectie L i nu partajeaza dect 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 amndoua 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:

Li

R(

Ci

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, putnd 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 att pe colectiile initiale ct 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 BDS fara Replicare - viteza maxima , fiabilitate minima BDS cu Replicare totala - viteza minima , fiabilitate maxima

Exista doua extreme n utilizarea facilitatilor oferite de Replicare : -

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 permitnd 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, avndu-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 restrnge 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 Studiu de Caz

7.2.3.2.4

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, realiznd functiile: Controlul ntregii activitati a societatii (Angajati, Proiectanti, Proiecte ) Gestiunea Asigurarilor Sociale pentru Membrii Familiilor Angajatilor Gestiunea datelor Angajatilor lucrnd la Compartimentul C2 Gestiunea datelor Proiectelor controlate de Compartimentul C2 Gestiunea datelor Angajatilor lucrnd la Compartimentul C3 Gestiunea datelor Proiectelor controlate de Compartimentul C3

Statia C 2 - la Compartimentul C2 cu functiile:

Statia C 3 - la Compartimentul C3 cu functiile:

Aceasta dispunere a statiilor precum si interesele de prelucrare ale acestora conduce la urmatoarea distribuire a datelor : -

Pe Statia C 1 - toate datele din sistem Pe Statia C 2 - datele din sistem care se refera la Angajatii si Proiectele Statiei C2 Pe Statia C 3 - datele din sistem care se refera la Angajatii si Proiectele Statiei C3 Nr-asigurare , Nume , Prenume , Salariu , Compartiment

Pentru ANGAJATII Statiei C2 si C3 intereseaza doar Atributele:

Problema devine mai delicata referitor la datele Relatiei de Legatura PROIECTANTI, unde interesul local al Statiei C2 si C3 este legat att de PROIECTELE Compartimentelor, ct 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=c 3 ) 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 * na1 cp1 na1 cp2 na5 cp3 na6 cp1 na6 cp2 na2 cp2 na2 cp3 PROIECTANTI - fragment 2 - Conditia de Garda:

Ore o1 o9 o2 o1 o8 o2 o7

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c 3 ) AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c 2 ) PROIECTANTI - fragment 2 Nr-asigurare * Cod-proiect * na2 cp4 PROIECTANTI - fragment 3 - Conditia de Garda:

Ore o1

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c 3 ) AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c 1 ) PROIECTANTI - fragment 3 Nr-asigurare * Cod-proiect * na2 cp5 PROIECTANTI - fragment 4 - Conditia de Garda:

Ore o6

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c 2 ) AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c 3 ) PROIECTANTI - fragment 4 Nr-asigurare * Cod-proiect * PROIECTANTI - fragment 5 - Conditia de Garda:

Ore

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c 2 )

Baze de DateEvoluate / Baze de Date Distribuite

531

AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c 2 ) PROIECTANTI - fragment 5 Nr-asigurare * Cod-proiect * na3 cp6 na3 cp4 na7 cp4 na7 cp6 na4 cp6 PROIECTANTI - fragment 6 - Conditia de Garda:

Ore o2 o1 o5 o2 o2

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c 2 ) AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c 1 ) PROIECTANTI - fragment 6 Nr-asigurare * Cod-proiect * na4 cp4 PROIECTANTI - fragment 7 - Conditia de Garda:

Ore o3

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c 1 ) AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c 3 ) PROIECTANTI - fragment 7 Nr-asigurare * Cod-proiect * PROIECTANTI - fragment 8 - Conditia de Garda:

Ore

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c 1 ) AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c 2 ) PROIECTANTI - fragment 8 Nr-asigurare * Cod-proiect * PROIECTANTI - fragment 9 - Conditia de Garda:

Ore

Nr-asigurare IN (SELECT Nr-asigurare FROM angajati WHERE compartiment=c 1 )

532

Baze de DateEvoluate / Baze de Date Distribuite

AND Cod-proiect IN (SELECT Cod FROM proiecte WHERE compartiment=c 1 ) PROIECTANTI - fragment 9 Nr-asigurare * Cod-proiect * na8 cp4 Ca urmare :

Ore o4

PROIECTANTII care lucreaza n COMPARTIMENTUL c3 sunt d ati 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 c2 n2 Responsabil na2 Data-numirii d2

Baze de DateEvoluate / Baze de Date Distribuite

533

SEDII Cod-compartiment * c2 ANGAJATI Nr-asigurare * na3 na4 na7 PROIECTE Cod* cp4 cp6 Localitate * l2

Nume n3 n4 n7

Prenume p3 p4 p7

Salariu sa3 sa1 sa5

Compartiment c2 c2 c2

Nume np 4 np 6

Localitate l4 l4

Compartiment c2 c2

PROIECTANTI Nr-asigurare * na1 na1 na5 na6 na6 na2 na2 na2 na2 Statia C 3 COMPARTIMENTE Cod* Nume c3 n3 SEDII

Cod-proiect * cp1 cp2 cp3 cp1 cp2 cp2 cp3 cp4 cp5

Ore o1 o9 o2 o1 o8 o2 o7 o1 o6

Responsabil na3

Data-numirii d3

Cod-compartiment * c3 c3 c3 ANGAJATI Nr-asigurare * na1 na2 na5 na6

Localitate * l2 l3 l4

Nume n1 n2 n5 n6

Prenume p1 p2 p5 p6

Salariu sa1 sa2 sa3 sa4

Compartiment c3 c3 c3 c3

534

Baze de DateEvoluate / Baze de Date Distribuite

PROIECTE Cod * cp1 cp2 cp3

Nume np 1 np 2 np 3

Localitate l1 l2 l3

Compartiment c3 c3 c3

PROIECTANTI Nr-asigurare * na2 na3 na3 na7 na7 na4 na4

Cod-proiect * cp4 cp6 cp4 cp4 cp6 cp6 cp4

Ore o1 o2 o1 o5 o2 o2 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 avnd 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 - cnd acelasi SGBD ruleaza pe toate unitatile din sistemul distribuit Neomogene - cnd 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 Criteriul de Autonomie

7.2.3.3.2

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 putnd 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 avnd: 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 Criteriul de Transparenta

7.2.3.3.3

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 cteva 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 cmp Nr-asigurare - 9 octeti Lungime cmp Compartiment - 4 octeti Lungime cmp Nume - 15 octeti Lungime cmp Prenume - 15 octeti Statia 2 COMPARTIMENTE ( Cod * , Nume, Responsabil, Data-numirii ) Extensiune - 100 nregistrari Lungime nregistrare - 35 octeti Lungime cmp Cod - 4 octeti Lungime cmp Nume - 10 octeti Lungime cmp 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 incluznd 10.000 de nregistrari a 40 de octeti. Se dau mai jos cteva 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 incluznd 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 Strategia 3 -

Baze de DateEvoluate / Baze de Date Distribuite

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 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 Strategia 5

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:
T.Cod=ANGAJATI.Compartiment

R= T.Cod, ANGAJATI.Nume, ANGAJATI.Prenume (T Pentru exemplul 2:

ANGAJATI)

( 34 x 10.000 = 340.000 octeti ) 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 cnd 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 Reunire F= F

< B>

S pe statia lui R

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 Pentru fiecare Fragment Orizontal Pentru fiecare Fragment Mixt - Lista de Atribute - Conditia de Garda - Ambele Seturi de Informatii

Conditia de Garda e numita astfel ntruct ea contine expresia care permite sau interzice actualizarea Fragmentului, putnd 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 Tabela COMPARTIMENTE-2 Lista de Atribute - * (toate atributele) Conditia de Garda - COMPARTIMENTE.Cod = 2 Tabela SEDII-2 Lista de Atribute - * (toate atributele) Conditia de Garda - SEDII.Compartiment = 2 Tabela PROIECTE-2 Lista de Atribute - * (toate atributele) Conditia de Garda - PROIECTE.Compartiment = 2 Tabela PROIECTANTI-2 Lista de Atribute - * (toate atributele)

ANGAJATI-3 ) OR Cod-proiect IN ( Fie de inserat n relatia ANGAJATI tupla: na7 n7 p7 s2 d7

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
Nr-asigurare

PROIECTANTI-3)

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 c onditia ANGAJATI.Compartiment=3 AND PROIECTANTI.Codproiect=PROIECTE.Cod se afla pe aceasta Statie. Ca urmare el poate descompune cererea n urmatoarele Subcereri: - T1 = PROIECTANTI -3.Nr-asigurare - T2 = ANGAJATI -1.Nr-asigurare, Nume, Prenume (T1 (PROIECTE-3
PROIECTE-3.Cod = PROIECTANTI -3.Cod-proiect

PROIECTANTI-3)

-R =

T2 . Nume, Prenume, PROIECTANTI -3 . Ore ( T2 * Nr-asigurare PROIECTANTI -3)

T1.Nr-asigurare = ANGAJTI -1.Nr-asigurare

ANGAJATI-1)

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, neexistnd 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 rnd 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, aducnd-o ntr-o Stare Consistenta cu celelalte Copii de Date, continnd 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 Controlul Concurentei Distribuite cu Copie Distincta a Datelor

7.2.3.5.2

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) 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

Tratamente: -

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
Tehnica Copiei Primare

7.2.3.5.2.3

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
Tehnica Alegerii Dinamice a Coordonatorului

7.2.3.5.2.4

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 Nencheiate (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 Controlul Concurentei Distribuite prin Tehnica Votarii

7.2.3.5.3

In cazul Controlului Concurentei Distribuite prin Tehnica Votarii nu se pastreaza o Copie Distincta. Fiecare Statie care pastreaza o Data primeste Cererile de Blocare avnd memorate informatiile necesare pentru Starile de Blocare / Deblocare. Controlul Blocarii / Deblocarii este conferit acelei Statii Apelate de o T ranzactie 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: 7.2.3.5.4 Reprezinta o metoda Pur Distribuita de Control a Concurentei Determina Incarcarea Traficului din Retea Apar dificultati de Reluare la Incidente n Timpul Votarii 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 ntrzierii 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 ramne 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, utilizndu-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) evolund spre Module Parametrizate.

Baze de Date Obiectuale Caracteristici Sintetice

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

Detaliate
Persistenta Gestiune Acces Fizic Control Concurenta Securitatea Datelor Cereri Ad-hoc

Produse de Programare Obiectuala Caracteristici Detaliate Sintetice

Obiecte Compuse Tipuri de Date Utilizator ncapsulare Clase de Obiecte Ierarhii de Clase Incorporare Dinamica 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 ntmplator 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 cteva 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 Multiaccesului Controlat la Date (n Citire sau Scriere) vederea asigurarii

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 ntrziata 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 utiliznd Concepte Obiectuale. Atasat sunt indicate si tipurile de Baze de Date dezvoltate pe baza acestor modele, mpreuna cu cteva 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. 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

Model de Date Baza de Date SGBD

NESTRICTE (VAGI)

OBIECTUALA
GemStone SIM

DEDUCTIVA
CORAL NAIL

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 cteva definitii:

550 Definitia 1

Baze de DateEvoluate / Baze de Date Obiectuale

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 avnd totodata capabilitati de Gestiune a Bazelor de Date dupa cum urmeaza: Sistem de Interogare de Nivel nalt Sistem de Gestiune Fizica 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 ntmplator 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 ct 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, ramnnd 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 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

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 cuvnt 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, prezentnd 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: o Transmit Parametri Returneaza Rezultate

Executia Procedurilor este Centrala

Arhitectura Obiectuala a Sistemelor de Programare (Fig. 7.3.2.2) Universul Sistemului este alcatuit din: O Colectie de Obiecte avnd n componenta: o Date denumite si Proprietati (Variabile) care reprezinta Elementele Active pentru ca: o Se transmit (prin intermediul Mesajelor) Se transforma (prin intermediul Metodelor) care reprezinta

Proceduri denumite si Metode Elementele Pasive pentru ca:

Nu se transmit (pot fi doar invocate) Nu se transforma (actioneaza doar asupra Variabilelor)

Obiectele comunica prin Mesaje

Data 1

Data 2 Procedura 2 Procedura 1 Data 3

Data 4

Procedura 3

Fig. 7.3.2.1 Arhitectura Conventionala a Sistemelor de Programare

552

Bibliografie

OBIECT 1

M2

OBIECT 2 Mesaj 1

M2

Metoda 2
M1 M3

Metoda 2
M1 M3

Metoda 1
Proprietati 1

Metoda 3

Metoda 1
Proprietati 2

Metoda 3

M6

M4

Mesaj 4

M6

M4

Metoda 6
M5

Metoda 4
M2

Metoda 6
M5

Metoda 4 Metoda 5

Metoda 5
M1

Metoda 2
M3

Mesaj 1

Metoda 1
Proprietati 3

Metoda 3

Mesaj 1

M6

M4

Mesaj 4

Metoda 6
M5

Metoda 4 Mesaj 4

OBIECT 3

Metoda 5

Fig. 7.3.2.2 Arhitectura Obiectuala a Sistemelor de Programare

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 Definirea Tipului Abstract de Data corespunde Entitatii Notiune Numele Clasei Structura de Date reprezentnd 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, declansnd Reactia (Transformarea) Obiectului (actioneaza ca un Selector al Metodelor fiind constituit din: o Nume Mesaj Obiect de Destinatie Argumentele de Apel (Invocare)

Structura Clasei de Obiecte:

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, putnd 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 avnd Tipul de Data DOLLAR) Metodele descriu Reactiile Clasei la Mesaje Exterioare (spre exemplu: Afla Profitul Societatii ca diferenta Intre Venituri si Cheltuieli)

Societate

GET Profit Metoda GET Profit RETURN Venit - Cheltuieli M1 Metoda 1 Proprietati Nume: STRING Adresa: STRING Cheltuieli: DO LLAR Venit: DOLLAR Angjati: MULTIME Persoana Manager: Persoana Filiale: MULTIME Companie

M2 M3 Metoda 3 Metoda 2

GET Profit

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)

Baze de DateEvoluate / Baze de Date Obiectuale

555

Clasa SOCIETATE Lista PROPRIETATILOR definite

Nume: STRING Adresa: STRING Cheltuieli: DOLLAR Venit: DOLLAR Angjati: MULTIME Persoana Manager: Persoana Filiale: MULTIME Companie

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

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

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):

IBM

SAP

FORD

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 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 o Scalar Multime

Exemple:

Viziunea asupra Datelor nu este Normalizata

Tipul de Data poate fi: Fix Tipul se declara n Clasa si ramne neschimbat

Baze de DateEvoluate / Baze de Date Obiectuale

557

Variabil (Tipul se poate modifica pe parcursul procesarii prin simpla atribuire de Valoare apartinnd 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 ntrziata 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) apartinnd 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 (corespunznd n acest caz Parametrilor Formali din Programarea Clasica) si se utilizeaza n Mesaje (corespunznd 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 ntrziata 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: o Incorporate n Obiecte de Ansamblu Atasate Variabilelor de Instantiere Atasate naintea Metodelor PreConditii reprezinta Restrictii ce se verifica naintea intrarii n Metoda, conditionnd executia acesteia Atasate dupa Metode PostConditii - reprezinta Restrictii ce se verifica la iesirea din Metoda permitnd n acest moment fie: Alegerea unei continuari prin invocarea altor Metode Refacerea Tranzactionala a executiei Metodei

Restrictii impuse Metodelor si implementate tot sub forma Procedurilor:

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. Societate

Societate Comerciala

Societate Non-Profit

IBM

SAP

IMS EEE

FORD

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.

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 mo stenesc 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 mo stenesc n Subclasa prin apel indirect Exemplu: Actualizare Proprietati Comune Specifice Se descriu n Subclasa (pot suprascrie o Metoda Comuna, avnd acelasi nume si cstignd astfel prioritate la apel Polimorfism)

Exemplu: Calcul Valoare Profit, ntocmire Bilant 7.3.3.1 Mostenire Structurala Mostenirea Structurala se refera la transmiterea Variabilelor (Proprietatilor) ntre Obiecte, ordonate printr-o Ierarhie de Mostenire. de Instanta

Mostenirea Structurala ridica o discutie importanta legata de problema Independentei Obiectelor. Pericolele care pndesc 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

Acces Indirect Proprietatile Mostenite de Obiecte sunt vizibile numai prin intermediul Metodelor Obiectelor de la care se mosteneste; altfel spus Variabilele de Instanta ramn Invizibile (Hidden Instance Variable) Partajare prin Mostenire versus Independenta prin ncapsulare:

Gestiunea Mostenirii Structurale ofera doua solutii de rezolvare a opozitiei:

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 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

Clasificarea Variabilelor de Instanta

Observatie: Se mentine aici ntrebarea daca atunci cnd 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 lund 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, att asupra Tipului de Variabila de Instanta ct 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

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

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 apartinnd 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, deplasnd 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 ramne 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 ramne 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.

Baze de DateEvoluate / Baze de Date Obiectuale

563

Instanta AUTOVEHICOLUL MEU

Proprietati de VEHICOL

VEHICOL Tip Greutate Medie Greutate 500 Kg.

Proprietati de AUTOVEHICOL

VEHICOL Tip 4 Usi Producator FORD

Proprietati de FORD

VEHICOL Tip SIESTA Culoaree Alba An Fabricatie 1984 Dotare (Injectie, Aer Conditionat, STEREO)

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

564

Baze de DateEvoluate / Baze de Date Obiectuale

Clasa SOCIETATE Lista PROPRIETATILOR definite

Lista MESAJELOR definite

GET Profit

Lista METODELOR definite

Metoda GET Profit RETURN Cheltuieli - Venit

Clasa SOCIETATE INDIGENA Lista PROPRIETATILOR definite

Clasa SOCIETATE STRAINA Lista PROPRIETATILOR definite

Lista MESAJELOR definite

GET Profit

Lista MESAJELOR definite

GET Profit

Lista METODELOR definite

Metoda GET Profit RETURN Cheltuieli - Venit

Lista METODELOR definite

Metoda GET Profit RETURN Cheltuieli Venit - Impozit

Fig. 7.3.3.2.1 Mostenire Comportamentala de Metode cu Polimorfism

Baze de DateEvoluate / Baze de Date Obiectuale

565

Reguli de Apel (Invocare) Metoda Necalificata e cautata n Ierarhia de Clase n mod Ascendent pe Ramura de Mostenire, ncepnd cu Clasa n care s-a facut invocarea Metoda Calificata e cautata direct n Clasa specificata n Identificatorul Metodei

Cu precizarile facute pna aici se pot observa doua forme de Mostenire Comportamentala: 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

Mostenire Fidela - Preluare simultana de Metode + Mesaje Mostenire cu Polimorfism - Preluare de Mesaje cu Modificarea sau nlocuirea Metodelor

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 att 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 putnd 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. 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. Persoana

Angajat

Student

Director

Student-Angajat

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 tip 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).

Baze de DateEvoluate / Baze de Date Obiectuale

567

Persoana

Angajat

Student

Persoana Student-Angajat

Angajat

Director

Fig. 7.3.3.2.3 Rezolvare de Conflict prin Liniarizarea Mostenirii Multiple

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, obligndu-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 att din punct de vedere Structural, ct 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 nct 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 (materializeaza) Variabilele de Instanta Multime de Valori care concretizeaza

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 cteva 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, putndu-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 o Identificarea prin Adresa identificarea cu ajutorul Referintei de Adresa (Pointerilor) atasate Obiectului Identificarea prin Index - identificarea cu ajutorul Tabelelor de Index atasate Obiectului Identificarea Explicita identificarea cu ajutorul Caracteristicilor declarate n structura Obiectului

Identificarea Interna a Obiectului

570

Baze de DateEvoluate / Baze de Date Obiectuale Identificarea Implicita - identificarea printr-o Proprietate Incorporata speciala a Obiectului (un Identificator Intern) 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 cnd, n cursul vietii, si schimba aproape toate nsusirile de la nastere.

Argumentele n favoarea ultimei Forme de Identificare sunt urmatoarele:

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) o Egalitate de Tip Egalitate de Variabile de Instante Egalitate de Valori

Identitatea Obiectelor Declarate Aceleasi prin Comparare Semantica

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, avnd urmatoarele forme de realizare:

Baze de DateEvoluate / Baze de Date Obiectuale

571

O1

O2

n1

v1

s1

n2 Asignare S := { O1 , O2 }

v2

s2

Obiecte Existente O1 , O2

Obiect Nou S = { O1 , O2 }

Obiect Existent S

Copiere Superficiala S ::= S

Obiect Nou S = { O1 , O2 }

Obiect Existent S

Copiere Profunda S " :== S

Obiect Nou S " = { O3 , O4 }

O3

O4

n1

v1

s1

n2

v2

s2

Fig. 7.3.4.1 Atribuire si Copiere (Superficiala si Profunda)

572

Baze de DateEvoluate / Baze de Date Obiectuale Copierea Superficiala (Shallow Copy) Copierea Referirii la Continutul unui Obiect deja existent si descrisa astfel: o o Crearea unui Obiect Nou 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 o Crearea unui Obiect Nou Copierea Continutului Obiectelor Existente n Continutul Obiectelor Componente Noi Nume O1 O2 S S O3 O4 S Obiect Continut {n1 , v1 , s 1 } {n2 , v2 , s 2 } {O1 , O2 } {O1 , O2 } {n1 , v1 , s 1 } {n2 , v2 , s 2 } {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. Obiect 1 O1 O1 S S O3 O3 O4 O4 S S S S Comparatie Operator Obiect 2 = O2 == O2 = S == S = O1 == O1 = O2 == O2 = S == S = S == S Rezultat Fals Fals Adevarat Fals Adevarat Fals Adevarat Fals Fals Fals Fals 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 cstiga 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 cnd reprezinta Atribute definite de Utilizator si care n realitate trebuie la anumite momente sa fie modificate. Neuniformitatea Atributele care identifica o Entitate pot fi diferite n diferite Contexte, sau pentru diferite Categorii de Utilizatori. Situatia creeaza complicatii, mai ales cnd apare problema Unificarii Colectiilor de Date de acelasi Tip, nsa Identificate n mod diferit de Proprietarii lor diferiti. 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 ct 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. 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. Cuplare Nenaturala Procesul de recuperare a Informatiilor n Structurile Normalizate ale Modelelor Relationale trebuie sa ramna 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

Obiect

Proprietate Nume Nume Vrsta Simbol n v e c a s n v e c a s

Obiect

Proprietate Nume Simbol n v o s n t i a

COPIL

Nume Vrsta Oras

SOT

Educatie Copii Adresa Sotie Nume Vrsta

ADRESA

Strada Numar Titlu

EDUCATIE

Institutie An Absolvire

SOTIE

Educatie Copii Adresa Sotie

Fig. 7.3.4.4 Model Obiectual PERSOANE (Obiecte si Proprietati) Legatura OBIECT - Proprietate

OBIECT

Proprietate OBIECT

Proprietate

Referinta Proprietate - OBIECT

Proprietate

Referinta Proprietate Colectie de Obiecte

Colectie de Obiecte

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 O Viziune Curenta Viziunea Starii Tuturor Obiectelor la un Moment Dat O Viziune Istorica Viziunea Evolutiei Unor Obiecte ntr-un Interval de Timp

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. PARINTI

SOT

SOTIE

c1 a1 s1

s2

n1

v1

e1

a1 c1

e2

v2

n2

EDUCATIE

ADRESA

EDUCATIE

t1 i1 a1

o1

s1 COPII

n1

t2

i2

a2

COPIL

COPIL

n1

v1

n2

v2

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:

576 o o o o o

Baze de DateEvoluate / Baze de Date Obiectuale Modularizarea Procedurilor prin regruparea n Metode a Operatiilor compatibile cu Structura de Date atasata fiecarui Obiect Sincronizarea Comportamentului Obiectelor prin perechile de Mesaje Metode recunoscute de Obiectele aflate n dialog Incitatia la Paralelizarea Transformarilor la care sunt supuse Obiectele prelucratoare de Mesaje Imunitatea Procedurilor ncapsulate n Metode la modificarile survenite n Mediul Exterior Concordanta perfecta ntre Structura de Date si Structura Procedurilor prin restrngerea 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 o Un Sistem de Programare Obiectuala cu Facilitati de Baza de Date O Baza de Date cu Facilitati de Prelucrare Obiectuala 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

Daca rezumam Capabilitatile Minima le ale unui Sistem cu Baze de Date astfel:

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 cteva concepte a caror neglijare va reprezenta o pierdere importanta pentru procesarea structurilor complexe de date. Modelul Obiectual nsa va ramne 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 o Directia Programarii Clasice 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 cnd afirmam acest lucru ne gndim 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 o Spatiul Informatiilor numit si Spatiul Problemei sau Domeniul Lumii Reale 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 decurgnd 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 cnd 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 nct 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) lasnd 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 dobndite cu iscusinta si truda pe calea utilizarii Sistemelor cu Baze de Date. 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].

Mistificarea Problemei Identitatii n Modelele de Reprezentare a Informatiilor

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, pna 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 cteva 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.

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 cnd 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 gndeste n Multimi si Clase, de aceea notiunile de Entitate, Caracteristica , Valoare , Relatie ntre Entitati, i sunt mai familiare dect 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) Modelele de reprezentare ale viitorului pot fi gndite si daca se face abstractie de limitele actuale ale masinilor de calcul. Structurile si procedurile gndite 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

Accentuarea limitelor momentane n Performantele Sistemelor de Calcul

Concluziile observatiilor de mai sus sunt: o Pastrarea Viziunii Relationale Interne a datelor care asigura: o 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 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

Construirea unor Straturi Superioare de Reprezentare care sa respecte:

ANEXE

581

ANEXE

O restrnsa 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
1945

Evenimentul

Urmari

1957 1959 1961

1965 1970

1970 1971 1975 1975

1976

1983 1985

Deceniul 5 Aparitia Benzii Magnetice (primul suport ce nlocuirea Cartelei si Benzii Perforate permite Cautarea) Deceniul 6 Instalarea Primului Calculator Comercial IBM lanseaza Sistemul RAMAC Se impune Accesul Direct Deceniul 7 Primul SGBD Generalizat, IDS Integrated Data Baza pentru Modelul Retea fundamentat la Stored, proiectat de Bachman Conference on Data Systems Language Database Task Group Apare IMS Information Management System, Baza pentru Modelul Ierarhic dezvoltat de IBM Apare IMS DB/DC (Database/Data Implementeaza Vederi Retea pe o structura de baza de tip Ierarhic Communication) 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 Modelul Relational e dezvoltat de Ted Codd Se pun bazele Teoriei Bazelor de Date cercetator la IBM Raportul CODASYL al lui Database Task Group Prima Conferinta Internationala SIGMOD Constituirea unui forum International pentru organizata de catre ACM Special Interest Goup on diseminarea Cercetarii n Baze de Date Management of Data Prima Conferinta Internationala VLDB (Baze de Constituirea unui nou forum International Date de Volum Foarte Mare) organizata de catre pentru diseminarea Cercetarii n Baze de Date Very Large Data Base Foundation Modelul Entitati - Relatii (ER) e descris de Chen Proiecte de Cercet are 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. Ancheta ANSI / SPARC semnaleaza prezenta a DB2, ORACLE, SYBASE, INFORMIX etc. peste 100 SGBD-uri Relationale Publicarea Standardelor preliminare SQL Realizarea de Aplicatii complete bazate pe Aparitia Limbajelor de Generatia a Patra Interfete Avansate (neprogramate) Propunerea ANSI - Limbaj de Definire Retea (NDL) 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

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 att 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 2.1.2 3.2 3.2.2 3.4.5.1 3.4.5.2 3.5 4.1.1 4.1.2 4.2.1 4.2.4 4.2.4.7 4.2.4.7.2 4.2.4.7.4 4.2.4.7.5 4.2.4.8 4.2.4.9 5.1.2 5.1.3 5.2 6.1 6.2 7.1 7.2 7.3 8 Sursa Bibliografica Observatii

[ULMA80] [ASBY56], [ABRI74] [IRIM82] [BARK01] [ERWM01] [JOUR75] [ABRI74] [SMIT82], [SMIT77] [TSIC82] [DATE95], [ELMA94], [ULMA80] [DATE95], [ELMA94], [TSIC82] [TSIC82] [TSIC82], [DATE95], [ELMA94] [TSIC82], [DATE95], [ELMA94] [LELU97], [LELU84] [PARS89] , [KINS80], [VALD89] [DATE95], [ELMA94], [ULMA80], [CODD71], [DATE95] [ULMA80], [DATE95] [ELMA94] [ELMA94], [DATE95], [FORT97] [DATE95] , [BOTE97], [STIH99], [PIA00], [FORT97] [ELMA94], [DELO80], [PIA00], [FORT97] [PARS89], [DITT91] [ELMA94]

Cu extinderea unor concepte

Cu extinderea unor concepte

Tab. 9.1 Principalele Surse de Informare

584

POSFATA

POSTFATA
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 tarmul SBD. Daca e mult sau putin e greu de spus. Pot nsa repeta marturisirea ca am dorit sa oferim n primul rnd nu att o suma de cunostinte acumulate, ct o Viziune n Timp cstigata 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 sfrsit ndemnul:
Vom face altul, pe ru 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 ru, trei femei si lauda Feciorii: - Al meu cnta 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 cnta 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 cnd nu uimeste cntnd si dansnd, poate uneori Artificial, nu uita totusi sa ia Cobilita Utilizatorului si sa o care, deprinznd 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 ClujNapoca, 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 rndul 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 Vnzari.............................................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 Rndurile 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 LegaturaCheie 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 relatiilor 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 Dune 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 Wes ley 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, ClujNapoca, 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, ClujNapoca, 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 S ystems 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] ONeil Patrick, ONeil 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 Users 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 Ar bore 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 Vrf............................ 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 Ct ......................... 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 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

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 Constrngeri ............................................ 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

Index de Termeni

601 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-alDomeniilor 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

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 Vrf.......................... 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

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 Amnata ................................................ 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 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

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

Index de Termeni

604 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

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

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 Ct............................................. 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 Vrf ...................................... 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 Vrf .......................... 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 Stnga............................... 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 B D ............. 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 Vrf............................... 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 Amnata ................................................................. 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 Amnata.......................... 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 Restrnsa.......................... 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 Vrf Terminal ............................................ 61 Vrfuri 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

SRL Piata Cipariu 9 / 45 3400 Cluj - Napoca Tel. 064-190651 RC J12/493/1994 Cod fiscal R5272847 BRD filiala Cluj cont # 251100996219602 Fondator : Dr. Ing. Alexandru Lelutiu Director tehnic : Ing. Marilena Fertea

Casa CARTII de STIINTA

SRL Str. Agricultorilor 20 / 26 RC J12/493/1994 3400 Cluj - Napoca Cod fiscal R253640 Tel. 064-143800 Banca Dacia Felix Cluj Fax 064-162151 cont # 4101017702805 Fondator : Dr. Tudor Codreanu Director : Ing. Mircea Trifu