Modelarea i interogarea conceptual a datelor i cunotinelor

Volumul I: Fundamentele modelrii datelor

Christian Manca

Lui Eric, Dianei, lui Miron, Vlad, Mihaelei i Simonei

Cuprins
1. Introducere ................................................................................... 6 1.1 Cui folosesc bazele de date? ............................................... 6 1.2 Date, informaii ................................................................... 6 1.3 Modelarea datelor ............................................................... 7 1.4 Modele ale datelor............................................................... 8 1.5 Baze de date ........................................................................ 8 1.6 Sisteme de gestiune a bazelor de date ................................. 9 1.7 Exemplu de problem tipic n baze de date ...................... 9 1.8 Ierarhia de niveluri a modelrii conceptuale a datelor ...... 10 1.9 Comentarii i referine bibliografice ................................. 11 2 Modelul entiti asociaii ................................................... 13 2.1 Structurarea datelor: generalizarea i agregarea ............... 13 2.2 Entiti, atribute, asociaii, chei i roluri ........................... 14 2.3 Diagrame entiti-asociaii (DEA)..................................... 20 2.4 Limbaje de manipulare a datelor peste DEA..................... 22 2.5 Probleme propuse spre rezolvare ...................................... 24 2.6 Comentarii i referine bibliografice ................................. 26

3 Modelul relaional ...................................................................... 27 3.1 Relaii ................................................................................ 27 3.2 Definiia formal a modelului relaional ........................... 30 3.3 Prima form normal ........................................................ 32 3.4 Constrngeri de integritate ................................................ 33 3.5 Principiul propagrii cheilor ............................................. 34 3.6 Proiectarea schemelor de bd relaionale ........................... 35 3.7 Introducere n algebra relaional ..................................... 36 3.7.1 Selecie ...................................................................... 37 3.7.2 Proiecie ..................................................................... 38 3.7.3 Join natural ................................................................ 39 3.7.4 Expresii algebrice relaionale .................................... 40 3.7.4.1 Expresii incluznd operatorii join i proiecie .................................. 41 3.8 Descompuneri fr pierderi............................................... 41 3.9 Constrngeri de integritate primitive ................................ 43 3.9.1 Constrngeri de domeniu ........................................... 43 3.9.2 Constrngeri de totalitate ........................................... 43 3.9.2.1 Valori nule ............................................................................................... 44 3.9.2.2 Constrngeri de totalitate ......................................................................... 45 3.9.3 Chei............................................................................ 46 3.9.3.1 Chei primare ...................................................................................... 47 3.9.3.2 Algoritmul de asisten a proiectrii cheilor ..................................... 48 3.9.4 Chei strine ................................................................ 52 3.9.4.1 Dependene de incluziune ........................................................................ 52 3.9.4.2 Chei strine .............................................................................................. 53 3.9.5 Constrngeri tuplu ..................................................... 55 3.9.6 Constrngeri primitive ............................................... 56 3.10 Traducerile DEA n MRD i MRD n DEA.................... 56 3.10.1 Implementarea principiului propagrii cheilor ............ 56 3.10.2 Algoritmul de traducere a DEA n scheme relaionale . 56
3

3.10.3 Algoritmul de traducere a schemelor relaionale n DEA59 3.11 Forma normal Boyce-Codd ......................................... 59 3.11.1 Dependene funcionale ......................................... 60 3.11.2 Anomalii de actualizare a datelor .......................... 61 3.11.3 Relaii n forma normal Boyce-Codd ................... 63 3.12 Contraexemple celebre de modelare relaional ........... 65 3.12.1 Problema codurilor potale .......................................... 65 3.12.2 Problema premizelor universitare ................................ 66 3.13 Principalele limite ale modelrii relaionale a datelor... 68 3.14 Probleme propuse spre rezolvare .................................. 70 3.15 Istoric i referine bibliografice ..................................... 77 5 Modelul matematic elementar al datelor.................................. 80 5.1 Schemele bazelor de date n MMED................................. 82 5.2 Reprezentarea mulimilor n MMED ................................ 82 5.2.1 Valori ......................................................................... 83 5.2.2 Obiecte ....................................................................... 84 5.2.2.1 Entiti ............................................................................................... 85 5.2.2.2 Asociaii ............................................................................................ 85 5.2.2.2.a Scheme ........................................................................................... 88 5.2.2.2.b Grafuri ............................................................................................ 88 5.2.2.2.c Ierarhii de asociaii ......................................................................... 89 5.3 Funcii ............................................................................... 91 5.3.1 Atribute ...................................................................... 91 5.3.1.1 Identificatori de obiecte..................................................................... 94 5.3.2 Funcii structurale ...................................................... 95 5.3.2.1 Funcii unitate.................................................................................... 95 5.3.3 Tipuri de obiecte ........................................................ 96 5.3.4 Instane ...................................................................... 97 5.3.5 Chei............................................................................ 97 5.3.6 Caracterizarea funciilor structurale .......................... 98 5.3.7 Formalizarea principiului propagrii cheilor ............. 99 5.3.8 Funcii calculate....................................................... 101 5.4 Constrngeri .................................................................... 103 5.4.1 Constrngeri provenite din modelul relaional ........ 105 5.4.1.1 Constrngeri de domeniu ................................................................ 105 5.4.1.2 Chei ................................................................................................. 106 5.4.1.3 Constrngeri de existen ................................................................ 107 5.4.1.4 Constrngeri obiect ......................................................................... 107 5.4.2 Constrngeri asociate mulimilor ............................ 108 5.4.2.1 Incluziunea ...................................................................................... 108 5.4.2.2 Egalitatea ......................................................................................... 109 5.4.2.3 Reuniunea ........................................................................................ 110 5.4.2.4 Disjuncia ........................................................................................ 110 5.4.2.5 Partiionarea .................................................................................... 111 5.4.3 Constrngeri asociate funciilor ............................... 112 5.4.3.1 Egalitatea ......................................................................................... 112 5.4.3.2 Idempotena ..................................................................................... 113 5.4.3.3 Surjectivitatea .................................................................................. 113 5.4.4 Sisteme de reprezentani .......................................... 114 5.4.5 Constrngeri asupra grafurilor de relaii binare....... 115 5.4.5.1 Reflexivitatea .................................................................................. 116
4

5.4.5.2 Simetria ........................................................................................... 116 5.4.5.3 Antisimetria ..................................................................................... 116 5.4.5.4 Tranzitivitatea ................................................................................. 117 5.4.5.5 Aciclicitatea..................................................................................... 117 5.4.6 Teoria buclelor nchise ............................................ 118 5.4.6.1 Bucle simple .......................................................................................... 118 5.4.6.2 Diagrame comutative de funcii ............................................................ 119 5.4.6.3 Comutativiti locale ............................................................................. 120 5.4.6.4 Comutativiti generalizate .................................................................... 121 5.4.6.5 Bucle nchise neinteresante ................................................................... 122 5.4.6.6 Algoritmul de asistena analizei buclelor nchise .................................. 123 5.5 Teoria asociaiilor ........................................................... 124 5.5.1 Structura asociaiilor ................................................ 124 5.5.1.1 Funcionalitile grafurilor de asociaii ........................................... 125 5.5.1.2 Proiectarea asistat de calculator a schemelor de asociaii ............. 127 5.6 Normalitatea versus corectitudinea schemelor ............... 129 5.6.1 Descrierea obiectelor ............................................... 129 5.6.1.1 Constrngeri primitive .................................................................... 131 5.6.1.2 Compatibilitate semantic ............................................................... 131 5.6.1.3 Anomalii de actualizare a datelor .................................................... 131 5.6.1.4 Descrierile fundamental i complet a obiectelor ......................... 132 5.6.2 Normalitate versus corectitudine semantic ............ 132 5.6.2.1 Normalitatea semantic a schemelor ............................................... 132 5.6.2.2 Corectitudinea modelrii versus normalitatea semantic ................ 133 5.6.2.2.1 Constrngeri obiect obligatorii .................................................... 133 5.6.2.2.2 Exemple ....................................................................................... 134 5.6.2.2.2.1 mprumuturi dintr-o bibliotec public .................................... 134 5.6.2.2.2.2 Rezervarea biletelor de cltorie cu avionul ............................ 135 5.6.2.2.3 Concluzii ...................................................................................... 140 5.7 Traducerea schemelor MMED n MRD i MEA ............. 141 5.7.1 Traducerea n MRD ................................................. 141 5.7.2 Traducerea n MEA .................................................. 143 5.8 Traducerea schemelor MRD i MEA n MMED ............. 143 5.9 Un exemplu relaional celebru modelat n MMED ......... 143 5.10 Problem dat la examen, rezolvri i punctaj ............ 147 5.10.1 Enun .................................................................... 147 5.10.2 Rezolvare ............................................................. 148 5.10.2.1 Diagrama Entiti-Asociaii (DEA) ................................................. 148 5.10.2.2 Schema conceptual n MMED ....................................................... 149 5.10.2.3 Bd relaional i un posibil coninut valid....................................... 151 5.10.2.4 Instruciunile SQL pentru calculul interogrii ................................. 153 5.11 Probleme propuse pentru rezolvare ............................. 154 5.12 Comentarii i referine bibliografice ........................... 158 6 Concluzii .................................................................................... 161 7 Bibliografie ................................................................................ 163

1. Introducere
1.1 Cui folosesc bazele de date?

De la savanii ce lucreaz n laboratoarele de cercetare (mari sau mici, prestigioase sau nu, ocupndu-se de astronomie, fizic nuclear, matematici, tiine ale naturii, medicin, calculatoare, lingvistic, antropologie etc.), la politicieni, militari, juriti, arhiteci, proiectani (de uzine, rafinrii, maini-unelte, automobile etc.), ingineri, economiti, bancheri, scriitori, ziariti, oameni de afaceri, profesori etc., aproape toi acetia i muli, muli alii folosesc azi calculatoarele, n orice ar civilizat a lumii, att la serviciu, ct i acas, n dou scopuri majore: pentru a crea, modifica i pstra documente (texte, foi de calcul tabelar, imagini etc.) i pentru a memora, actualiza i regsi informaii n baze de date i/sau de cunotine (despre obiecte, concrete sau abstracte, cum sunt, de exemplu, persoanele, ntreprinderile, cursele de avioane, rezultatele sportive, evoluiile meteorologice, crile, discurile etc.). Dar calculatoarele, orict de utile ar fi n acest scop, nu sunt obligatorii pentru crearea, meninerea i consultarea unei baze de date (indiferent de nivelul de civilizaie al unei comuniti umane oarecare): crile de bucate, mersurile autobuzelor, trenurilor, avioanelor i vapoarelor, dicionarele i enciclopediile, hrile, albumele de fotografii, cartotecile (unei biblioteci, unui serviciu de resurse umane, unui spital etc.), crile de telefoane, anuarele de tip Pagini aurii, cataloagele (colare, de mod, de mobilier, de timbre etc.) etc. constituie doar o mic parte din exemplele posibile de baze de date manuale (orict de primitive ar fi unele dintre ele). Chiar dac i acestea au nceput s fie create, ntreinute i consultate cu ajutorul calculatoarelor n majoritatea rilor civilizate, mai exist nc, pn i n asemenea ri, variante parial sau complet independente de calculator. Ca atare, ele sunt folosite (contient sau nu) i de majoritatea oamenilor din cele mai puin dezvoltate ri ale lumii. Urmtoarele seciuni ncearc s ofere un rspuns (deocamdat informal) la ntrebarea Ce sunt, n fond, bazele de date?, s prezinte un exemplu de problem tipic din acest domeniu, dup care s schieze o ierarhie a conceptualizrilor existente n cadrul acestei discipline centrale a tiinei calculatoarelor. 1.2 Date, informaii

Cuvntul dat provine din latinul datum = fapt i nseamn literal descriere de fenomene. Prin extensie, datele descriu nu numai fapte concrete ci i idei, virtualiti, concepte etc. Acceptm ca definiie informal de lucru pentru informaie = increment de cunotine ce poate fi dedus din date. Pentru noi deci, informal, datele reprezint descrieri de fenomene sau abstraciuni despre care se consider c merit a fi formulate, memorate i modificate n vederea regsirii (prin interogri a) informaiilor astfel ncapsulate. Memorarea datelor s-a fcut tradiional folosind un anume mijloc de comunicaie (de exemplu: imaginile, limbajele etc.) pe un suport (semi-)permanent particular (de exemplu: piatr, hrtie, pnz, hrtie foto, dischete, CD, DVD etc.) pentru a pstra, prelucra, regsi i transmite informaii.

1.3

Modelarea datelor

Este evident necesitatea unei interpretri a datelor care s fie suficient de abstract i n acelai timp suficient de puternic pentru a oferi o anumit nelegere asupra modului n care sunt conectate datele ntre ele. Un instrument intelectual care ofer o asemenea interpretare se numete model al datelor: un mecanism de abstracie care ne permite s vedem pdurea (i.e. informaia coninut de date) i nu doar copacii (i.e. valorile individuale ale datelor). Modelele sunt intensiv utilizate n mai toate disciplinele tiinifice pentru abstractizarea detaliilor i mbuntirea nelegerii domeniilor respective (de exemplu: modele matematice, fizice, economice etc.). Modelele datelor permit surprinderea parial a nelesului informaiilor: cunoaterea lumii fiind un proces nesfrit, nu se poate imagina un model care s surprind nelesul complet al ei. Este important ns surprinderea unei cantiti adecvate de semantic, n raport cu utilizarea dorit a datelor, chiar dac ele pot avea i alte nelesuri nc necunoscute, ascunse sau irelevante la orice moment de timp dat. Exist multe modele ale datelor. Un exemplu tipic l constituie hrile un model al lumii suficient de abstract (nu se schimb cnd este dobort un copac sau cnd se construiete o cas) i ndeajuns de puternic pentru a furniza o foarte bun i util interpretare utilizatorilor si. Ne intereseaz ns, n contextul acestei lucrri, doar o mulime foarte restrns de asemenea modele: acelea care pot fi uor codificate i manipulate pe un calculator. Asemenea modele organizeaz structuri de date particulare asupra crora se pot defini un numr de operaii permise. Atomii structurilor i constituie datele elementare. Informal, o dat elementar este un tuplu de forma: <nume obiect, proprieti obiect, valori proprieti, timp> (deoarece, uzual, o descriere de fenomen sau idee se refer la un obiect i la o mulime de proprieti ale sale, caracterizate, n orice moment de timp, prin cte o valoare). Majoritatea modelelor de date renun la timp, nlocuindu-l cu alte tipuri de proprieti explicite sau/i cu ordonri ntre obiecte. Aceasta din mai multe motive, dintre care amintim: 1. de cele mai multe ori ne intereseaz doar valoarea curent a datei, nu i istoria valorilor sale; 2. adesea ne intereseaz mai mult timpul relativ al fenomenelor (e.g. faptul c un fenomen are loc dup un altul) i nu cel absolut (e.g. ziua, ora, minutul i secunda producerii fenomenului); 3. modelarea aspectelor temporale este dificil (n actualul stadiu de dezvoltare al teoriei i practicii modelrii datelor). Un mod simplu, dar puternic de structurare a datelor elementare l reprezint reelele (grafurile) n care datele elementare sunt noduri, iar arcele care le unesc reprezint asociaii (legturi, relaii) ntre ele. Un alt mod foarte puternic de asociere a datelor l reprezint categoriile. Datele prezentnd anumite similitudini sunt plasate ntr-o aceeai categorie: de obicei, aceste similariti sunt factorizate ca proprieti ale categoriei. Dac pentru sistemele de cunotine generale sau n inteligena artificial sunt utile modelele care nu fac nici o presupunere despre categorii, n bazele de date (mai ales pentru cele destinate modelrii i asistenei conducerii afacerilor) sunt eficiente modelele simple, fornd omogenitatea datelor care, n plus, sunt strict clasificate att ca i tipuri de valori admise, ct i n ierarhii de tipuri, categorii, subclase, clase, superclase etc.

1.4

Modele ale datelor

Un model al lumii trebuie s surprind dou clase de proprieti ale acesteia: statice i dinamice, adic cele (relativ) invariante n timp, i cele reprezentnd evoluia. Definim un model al datelor ca fiind perechea MD = (G,O), unde G este o mulime de reguli de generare, iar O este o mulime de operaii.

G exprim proprietile statice ale domeniului modelat de MD i corespunde

limbajului de definire a datelor (LDD). El definete structurile datelor permise n MD. O exprim proprietile dinamice (tranzacionale 1) ale domeniului modelat de MD i corespunde limbajului de manipulare a datelor (LMD). El definete operaiile permise asupra structurilor definite de G. Detaliem, prin analogie cu conceptele din teoria sistemelor, G i O de mai sus: Regulile G genereaz spaiul strilor domeniului modelat de MD, i.e. mulimea tuturor configuraiilor de date posibile reprezentnd (informatic) acest domeniu. Terminologia consacrat n modelele de date identific spaiul strilor cu schema. Schema unei baze de date este un concept generic identificnd categoriile, proprietile lor, precum i relaiile ntre ele (e.g.: FURNIZOR, PIESE, CLIENI etc; NumeFurnizor, TipPies, AdresClient etc; FURNIZRI, PRODUCIE, STOCARE, DESERVIRE etc). G conine att reguli generice de definire a categoriilor i de structurare a lor (specificnd obiectele permise i relaiile permise ntre aceste obiecte) ct i reguli restrictive numite constrngeri 2- asupra categoriilor (ce exclud obiectele i relaiile ntre ele nepermise). Deci G = (GS, GC ), unde GS genereaz structura schemei (i.e. categoriile i relaiile ntre ele), iar GC genereaz constrngerile asociate schemei. Similar, o schem S generat de G este o pereche S=(SS,SC), format din structura schemei (SS) i din lista constrngerilor (SC) explicite (asociate S) ce nu trebuie violate. Operaiile din O sunt definite ca funcii parial definite pe mulimea spaiului strilor domeniului modelat de MD (pariale, cci pot viola unele din constrngerile din SC) i cu valori n aceeai mulime. n general, operaiile din O sunt mai degrab definite doar peste structura schemei i sunt nedefinite de ndat ce vreun element al SC este violat. 1.5 Baze de date

Se numete baz de date o colecie de date structurate ntr-un mod particular pe baza unei scheme. O bd este deci o structur relativ la o schem, reprezentnd informatic (via un model oarecare al datelor) un subunivers de interes din lumea nconjurtoare. Termenul de baz de date este folosit azi generic, prin abuz de notaie, pentru a desemna i orice model al datelor codificabil i manipulabil pe un calculator. Orice stare (instan) aparinnd spaiului strilor descrise de schema bazei de date se numete coninut al bd. G genereaz deci mulimea tuturor coninuturilor admisibile (valide) ale bd, n timp ce O definete mulimea tuturor tranziiilor posibile dintr-un coninut al bd n altul. Datele structurate ntr-o bd nceteaz astfel s mai reprezinte doar o succesiune de bii (din fericire nsemnnd ceva pentru un program inteligent), ci corespund unei codificri cu neles semantic a unei pri a lumii nconjurtoare.
nelegem prin tranzacie orice succesiune de operaii ce trebuie executat atomic (indivizibil). nelegem prin constrngere expresia formal (ntr-un formalism oarecare) a unei restricii din subuniversul de interes modelat. 8
1 2

Un coninut al unei bd memoreaz deci nu numai date (valori) ci i informaii (interpretri asociate acestor valori), constituind un punct de vedere asupra (fotografie a) domeniului de interes modelat de bd. n consecin, bazele de date ofer posibilitatea de a memora, actualiza i interoga date i informaii, n mod ct mai economic, rapid i elegant cu putin. 1.6 Sisteme de gestiune a bazelor de date

Se numete sistem de gestiune al bd orice sistem de programe furniznd faciliti de definire a schemelor bd (i.e. un LDD), operaii de interogare i actualizare a coninutului bd (i.e. un LMD), precum i alte faciliti externe MD reprezentat de bd. SGBD este interfaa ntre bd i utilizatorii ei. Dintre facilitile externe MD pe care trebuie s le asigure un SGBD, citm: Controlul accesului la date (nu oricine trebuie s aib acces n orice mod la orice dat memorat de bd). Meninerea integritii datelor memorate (coninutul bd trebuie s fie valid n orice moment de timp ntre dou tranzacii 3). Protecia la distrugeri accidentale ale datelor memorate i posibilitatea refacerii coninutului bd anterior unei (serii de) tranzacii (nici un accident de utilizare hardware, software sau de operare- nu trebuie s poat justifica pierderea sau alterarea informaiilor memorate de bd). Sincronizarea accesului simultan la date (interaciunea ntre activitile diverilor utilizatori simultani ai bd nu trebuie s produc nici pierderea integritii datelor memorate, nici rspunsuri eronate la ntrebrile formulate de acetia). 1.7 Exemplu de problem tipic n baze de date

Fie un magazin ce ofer cri, reviste, filme i muzic (imprimate pe casete, discuri, CD-uri, DVD-uri etc.) i fie un potenial cumprtor care apeleaz la un vnztor (sau direct la serviciile unui PC sau terminal cuplat la un calculator) pentru a afla rspunsul la urmtoarele ntrebri: Ce CD-uri avei cu muzic compus i/sau interpretat de Dinu Lipatti? Ce ali interprei i/sau acompaniatori i-au mai dat concursul la fiecare din ele? Ct cost fiecare? Ce opusuri muzicale conin fiecare n parte? Ce cas de discuri le-a nregistrat pe fiecare n parte, n ce an i n ce sal /studio? Care sunt calificativele pe care le au aceste CD-uri pentru calitatea nregistrrii? Evident c acest exemplu tipic subnelege dou subprobleme: Static: ce date i cum trebuie ele memorate astfel nct rspunsul la aceste ntrebri (i la oricare altele similare) s poat fi oricnd furnizat corect i prompt (avnd de asemenea n vedere faptul evident c stocul de CD-uri variaz continuu!)? Dinamic: cum se poate interoga bd corespunztoare pentru a afla rspunsurile?

Temporar, pe timpul tranziiei dintr-un coninut al bd n altul (conform unei tranzacii), integritatea bd poate fi violat. ns la terminarea execuiei oricrei tranzacii, coninutul bd nu trebuie s violeze nici una dintre constrngerile schemei bd (i.e. s fie admisibil). 9
3

Aa cum vom vedea n capitolele urmtoare, teoria proiectrii i interogrii bd ofer soluii la ambele subprobleme de mai sus. 1.8 Ierarhia de niveluri a modelrii conceptuale a datelor

Lucrarea exploreaz componenta abstract a ierarhiei de modelare conceptual a datelor prezentat n figura 1.1. n aceast ierarhie sunt considerate patru nivele, n funcie de tipul atomilor structurai de fiecare n parte i anume: cunotine obiecte valori bii. Uneltele de modelare la dispoziie pentru aceste nivele sunt, respectiv: bazele de cunotine bazele de date orientate obiect bazele de date convenionale sistemele de fiiere (de date, dar i de programe manipulnd aceste date). Considerm n plus c fiecare din cele patru nivele de mai sus sunt structurate intern pe trei subniveluri, mereu de tip: semantic sintactic fizic. Desigur c, n mod ideal, dintotdeauna a fost i va fi mereu de dorit s operm la nivel ct mai nalt (doar pe cel al cunotinelor, dac s-ar putea!), indiferent de volumul i complexitatea datelor implicate, de numrul de utilizatori concureni, de distanele i diferenele ce i despart etc.; i aceasta nu la orice vitez (ci instantaneu!), nu doar prin scris/citit texte (ci i prin imagini, sunete, vorbire, gesturi etc.!), n condiii de deplin fiabilitate i excludere a accesului neautorizat, fr posibilitatea alterrii sau pierderii informaiilor, totul la costuri ct mai mici cu putin. Practic ns, este evident c atingerea unor asemenea deziderate nu se poate face dect gradual, mbinnd mereu optim avansurile abstracte i tehnologice, att din hard, ct i din soft. Era natural ca evoluia modelrii conceptuale a datelor s nceap, cronologic, de pe nivelul minimal al fiierelor i programelor procesnd bii, octei, regitri, nregistrri n fiiere etc. Schematiznd evoluia domeniului studiat, considerm c apariia limbajelor de asamblare i a sistemelor de operare a nsemnat saltul pe subnivelul sintactic, n timp ce limbajele de programare de nivel nalt au permis apoi atingerea primului subnivel semantic. Primele modele ale datelor (ierarhic i reea, n aceast ordine) au propulsat modelarea pe nivelul imediat superior, al bazelor de date, constituind primele dou subniveluri ale acestora. Modelul relaional al datelor (vezi capitolul 3) este puntea de legtur ntre acest nivel i cel orientat obiect: el constituie att subnivelul semantic al bd convenionale, ct i nivelul fizic al celor orientate obiect. Modelele semantice iniiale (de tip entiti-asociaii sau funcional) se plaseaz pe subnivelul obiectual sintactic. Modelele semantice evoluate (partiii, laticeal, categorial, modelele de date orientate obiect etc.) ocup subnivelul obiectual semantic.

10

3.3 subnivel semantic

(MMED) Baze de cunotine

3.2 subnivel sintactic

Cunotine

(LDL, CORAL++)
3.1 subnivel fizic

(DATALOG)
2.3 subnivel semantic

MODELE SEMANTICE EVOLUATE (MDOO) Bd orientate obiect

2.2 subnivel sintactic

Obiecte

MODELE SEMANTICE PRIMITIVE (MEA, MFD) 2.1 subnivel fizic MODELUL

1.3 subnivel semantic

RELAIONAL Valori

Bd convenionale

1.2 subnivel sintactic 1.1 subnivel fizic 0.3 subnivel semantic 0.2 subnivel sintactic 0.1 subnivel fizic

(MODELUL REEA) (MODELUL IERARHIC)

LIMBAJE DE NIVEL NALT LIMBAJE DE ASAMBLARE PROGRAME BINARE Bii

Sisteme de fiiere

Fig. 1.1. O ierarhizare schematic a modelrii conceptuale a datelor

n sfrit, la nivelul cunotinelor am plasa nti, pe subnivelul fizic, clasa limbajelor reprezentate de Datalog, implementrile sale de tipul LDL i Coral++ pe subnivelul sintactic, n timp ce MMED este ales drept reprezentantul nivelului semantic. Lucrarea de fa este centrat pe bd orientate obiect, cu deschideri ctre bazele de cunotine; ea acoper toate subnivelurile ntre 2.2 i 3.3 inclusiv. 1.9 Comentarii i referine bibliografice

n concluzie, domeniul acestei lucrri l constituie o parte a miezului tiinei calculatoarelor i anume modelarea i interogarea conceptual a datelor i cunotinelor. Dintre foarte multele monografii excelente de bd i cunotine menionm pentru un posibil top 10 cronologic ce ar trebui consultat de orice viitor specialist urmtoarele: Principles of Database Systems de J. Ullman [336, 337, 338] din 1980 (prima ediie), respectiv 1982 (a doua ediie)
11

Principles of Database and Knowledge Base Systems de J. Ullman [342, 343] din 1988 (primul volum), respectiv 1989 (volumul doi) Fundamentals of Database Systems de R.A. ElMasri i S.B. Navathe [134] din 1988 Logic Programming and Databases de S. Ceri, G. Gottlob i L. Tanca [91] din 1989 Relational Databases and Knowledge Bases de G. Gardarin i P. Valduriez [152] din 1990 Relational Database Theory de P. Atzeni i V. De Antonellis [30] din 1993 Foundations of Databases, de S. Abiteboul, R. Hull i V. Vianu [72] din 1995 (actuala biblie n domeniu) Data on the Web: From Relations to Semistructured Data and XML de S. Abiteboul, P. Buneman, D. Suciu din [73] 1999 Database Design for Smarties: Using UML for Data Modeling, de R.J. Muller [271] din 1999. Entity-Relationship Modeling. Foundations of Database Technology, de B. Talheim [300] din 2000.

12

2 Modelul entiti asociaii

Cel mai uor tip de relaie este cel cu zeci de mii de oameni. Cel mai greu este cu unul singur. Joan Baez Exist mai multe modele ale datelor de nivel nalt ("infologic") care pot fi folosite pentru proiectarea bd. Un asemenea model este cu att mai bun cu ct ajut utilizatorii bd s gndeasc despre, s organizeze i s utilizeze datele. Majoritatea modelelor de acest nivel sunt foarte abstracte, fiind dezvoltate n general n aplicaii de inteligen artificial sau n sisteme de baze de cunotine generale. Un model simplu, concret, facilitnd comunicarea ntre utilizatorii, proiectanii i administratorii bd, este modelul entiti-asociaii (MEA). MEA specific o schem a universului de modelat (SUM), reprezentnd un punct de vedere complet asupra datelor sale, independent de orice consideraii de memorare i/sau eficien a implementrii. Iniial neformalizat, MEA se preteaz de fapt la formalizri algebrice riguroase. Principala sa atracie ns o constituie puterea sugestiv deosebit pe care i-o confer diagramele entiti-asociaii (DEA). Prima seciune discut cele dou mecanisme abstracte duale folosite n structurarea fundamental a datelor: generalizarea i agregarea. Seciunea 2.2 prezint principalele noiuni elementare ale acestei abordri: entiti, asociaii, atribute, chei i roluri (ale mulimilor de entiti n diverse tipuri de asociaii). Seciunea 2.3 introduce diagramele entiti-asociaii, principala unealt de modelare n MEA. Seciunea 2.4 prezint succint LMDMEA, un limbaj de manipulare a datelor n MEA, n timp ce seciunea 2.5 propune un algoritm de traducere din MEA n MRD. Capitolul se ncheie cu o seciune de probleme propuse spre rezolvare i una dedicat comentariilor i referinelor bibliografice. 2.1 Structurarea datelor: generalizarea i agregarea

Principalul mod n care realizm structurarea datelor l reprezint abstractizarea. Procesul de abstractizare reflect abilitatea noastr de a ignora detaliile i de a ne concentra asupra proprietilor generale, comune, ale unei mulimi 4 de obiecte. n modelarea datelor, abstractizarea se folosete pentru a obine categoriile de date, proprietile lor i relaiile dintre ele (ntr-un cuvnt: structura schemei). Sunt uzuale dou tipuri de abstractizri: generalizarea i agregarea. Forma elementar de abstracie a generalizrii, care distinge ntre nivelul obiectelor i cel al tipurilor de obiecte, se numete clasificare. Clasificarea definete deci tipuri, fiecare corespunznd unei clase de obiecte avnd proprieti similare. (Procesul de gndire invers clasificrii se numete instaniere). Exemple de clasificri: Ion Pop este un CONTABIL; Vasile Gheorghe este un INGINER; B.N.R. este un CLIENT etc. Exemple de instanieri: un CONTABIL este i Popa Ioan; un INGINER este i Gh. Gheorghe; un CLIENT este i Alimentara S.A. etc. Deasupra, generalizarea abstractizeaz tipuri mai complexe din cele deja definite 5 (inversul ei se numete specializare). Exemple de generalizri: DIR_ADJUNCT este un DIRECTOR; DIRECTOR este un ANGAJAT; ANGAJAT este o PERSOAN etc. Exemple de specializri: un DIRECTOR poate fi DIR_ADJUNCT; un ANGAJAT poate fi MUNCITOR; un PARTENER poate fi FURNIZOR etc.
nelegem prin mulime orice colecie de obiecte adecvat identificat i caracterizat de o condiie de apartenen. Reamintim c n teoria clasic a mulimilor, duplicatele nu au sens, condiia de apartenen nu implic nici o ordine i este independent de reprezentarea elementelor mulimii. De exemplu: {a | a=0 sau a=1}, {1,0} i {b | b cifr binar} sunt toate echivalente cu {0,1}. 5 Generalizarea corespunde conceptului ESTE-UN (O) din inteligena artificial. 13
4

Clasificarea i generalizarea mbuntesc nelegerea datelor, plasnd accentul pe similitudinile (de structur ale) obiectelor i abstractiznd diferenele de detaliu (valoare) ntre ele. Cu ajutorul lor structurm datele n ierarhii de generalizri. Un exemplu de asemenea ierarhie 6 este prezentat n figura 2.1. n principiu, un tip generalizat va avea toate proprietile comune tipurilor ce l constituie (i care deci pot fi motenite de acestea; exemplu: Nume caracterizeaz att PERSOANA ct i ANGAJAT, DIRECTOR, PRODUCTIV, INGINER, DIR-ADJUNCT etc.), dar i alte proprieti, caracterizndu-l doar pe el (i a cror motenire ierarhic ar putea fi interzis; exemplu: SalariulMediu poate fi o proprietate a ANGAJAT, a crei motenire n jos trebuie ns interzis). Evident c, n general, tipurile constitutive au i proprieti particulare, necomune i care nu pot fi deci factorizate ca proprieti ale tipului generalizat (de exemplu, ANGAJAT este n general caracterizat i prin valoarea proprietii NrLegitimaieServici, folosit chiar la identificarea unic a fiecrui ANGAJAT al ntreprinderii, care ns nu are sens pentru orice PERSOAN; ca atare, aceast proprietate nu va fi factorizat n nodul rdcin al ierarhiei de generalizri din figura 2.1, ci doar pn la nivelul nodului etichetat cu ANGAJAT). Agregarea este abstracia prin care un obiect (tip) este constituit din proprietile (tipurile) sale caracteristice 7 (inversul ei: rafinarea succesiv). Agregarea vizualizeaz gradual structura unui obiect (tip). Exemplu: tipul PERSOANA poate fi constituit din proprietile Nume, DataNatere, Domiciliu i Sex, unde, la rndul su, Domiciliu este alctuit din ara, Loc i Adresa etc. (vezi figura 2.2). Aa cum clasificarea i generalizarea pot fi vizualizate printr-o ierarhie de generalizri i agregarea poate fi deci vizualizat printr-o ierarhie de agregri. Cele dou tipuri de ierarhii se pot reprezenta ortogonal, ca n exemplul din figura 2.3. n cursul modelrii datelor, generalizarea i agregarea pot fi abordate att de jos n sus (prin sintetizare) ct i de sus n jos (prin descompunere). Exemple de sintetizare: DIRECTOR sau sau PRODUCTIV = ANGAJAT; Nume i DataNatere i Domiciliu i Sex = PERSOANA etc. Exemple de descompunere: PERSOANA = ANGAJAT sau COLAB-EXTERN; DataNatere = An i Luna i Zi etc. Ambele moduri de abstractizare sunt definite ca relaii ntre tipuri (de obiecte i deci de date). 2.2 Entiti, atribute, asociaii, chei i roluri

Numim entitate orice obiect existnd sau gndit a crui existen nu depinde de existena nici unui alt obiect, despre care se dorete meninerea de date i a crui unicitate intereseaz (i.e., dorim s l putem identifica unic n bd). Exemple: Ion Pop, Vasile Ion, CONTABIL, PERSOANA etc. Prin generalizare, entitile pot fi grupate n tipuri de entiti = o reprezentare corespunztoare unei categorizri a obiectelor. Un tip de entiti 8 este caracterizat de o agregare de proprieti 9. Facem s-i corespund fiecrei proprieti o unic funcie (n ge-

n general, o asemenea ierarhie nu este de tip arborescent, ci laticeal. Agregarea corespunde conceptului PARTE-A din inteligena artificial. 8 Matematic, un tip de entiti este o mulime atomic (i.e. nu un produs cartezian), iar o entitate este un element al mulimii respective. 9 Vom vedea c, matematic, aceasta nseamn un produs de funcii corespunztoare acestor proprieti (zise atribute). 14
6 7

neral parial) 10, avnd numele proprietii respective i pe care o numim tot proprietate, care asociaz fiecrei entiti din mulimea corespunznd tipului respectiv un element dintr-o mulime de valori. PERSOANA

ANGAJAT

COLAB-EXTERN generalizare

DIRECTOR

PRODUCTIV

NEPRODUCTIV

DIR_ADJUNCT .. DIR_TEHNIC

INGINER

... MAISTRU

CONTABIL ........ clasificare

Ion Pop .... Popa Ioan .... Vasile Ion .... Gh. Gheorghe ...Maria Ionescu ..........
Fig. 2.1 Exemplu de ierarhie de generalizri

PERSOANA

Nume

DataNaterii

Domiciliu

Sex

Prenume Familie An Luna

Zi ara

Loc

Adresa

Jude Localitate

Strada

Nr.

Ion

Pop

1955

12

16 Romnia

Sibiu

Sibiu

Porumbac

Fig. 2.2 Exemplu de ierarhie de agregri

10

Reamintim c, matematic, o funcie este o relaie binar, notat : E C (unde E D, iar D i C sunt mulimi numite domeniu, respectiv codomeniu), care satisface condiia de funcionalitate, adic: xE, !yC, astfel nct (x) = y (pentru orice element din subdomeniu exist un unic element corespunztor din codomeniu); dac E = D, atunci se numete total; n caz contrar, ea se numete parial. 15

generalizare PERSOANA ANGAJAT COLAB.EXTERN

agregare clasificare

Nume

c l a

Ion Pop

Lucia ene

Domiciliu

s i f

Porumbac 7, Sibiu, Ro.

Intr. Geneva 3 Bucureti, Ro.

DataNaterii

i c

16.12.1955

Sex

Fig. 2.3 Exemplu de reprezentare ortogonal a generalizrii i agregrii

Exemple de proprieti: Sex : PERSOANE {M,F}, DataNaterii : PERSOANE DATE etc. Observaie: nu exist o distincie universal absolut ntre tipuri de entiti i proprieti. De exemplu, ntr-o bd, CULOARE poate fi o proprietate pentru tipul de entiti AUTOMOBIL, dar n alta (e.g. modelnd o fabric de colorani) CULOARE ar putea fi un tip de entiti. Fie o relaie matematic 11 oarecare E ntre tipurile de entiti E1, E2,, En (n>1), nu neaprat toate distincte ntre ele, avnd graful G. Orice funcie definit pe G i cu valori ntr-o mulime oarecare de valori se numete atribut (al relaiei E). Un exemplu de atribut: fie STOCARE_PIESE o relaie definit peste tipurile de entiti PIESA i MAGAZIE. Funcia StocPiesa : STOCARE_PIESE NAT este un atribut asociind fiecrei perechi (piesai,magaziej) aparinnd relaiei STOCARE_PIESE valoarea stocului din piesai aflate n magaziaj (unde NAT este mulimea numerelor naturale).

11

Reamintim c o relaie matematic E peste E1, E2, , En este definit ca tuplul E = {E1, E2, , En, G} unde G numit graful lui E este o submulime nevid a produsului cartezian E1 E2 En. 16

De observat c proprietile (unei mulimi de entiti) sunt cazuri particulare de atribute (pentru n=1) definite nu pe graful unei relaii ntre tipuri de entiti, ci pe un singur tip de entiti. Orice tip de entiti este deci o agregare de atribute. Entitile aparinnd unor tipuri (distincte sau nu) de entiti pot fi asociate ntre ele. De exemplu, entitile Intel i Pentium4 pot fi asociate prin PRODUCE (sau COMERCIALIZEAZ sau PROIECTEAZ etc.). n general, orice relaie matematic definit peste o mulime de tipuri de entiti asociaz ntre ele entiti aparinnd acestor tipuri. Putem deci abstractiza i tipuri de asociaii ntre tipuri de entiti: relaii matematice definite peste aceste tipuri de entiti. Un element al unei asemenea relaii se numete asociaie (exemplu: <Intel, Pentium4>). i aceste tipuri sunt constituite structural din agregri de atribute: cele identificnd (unic!) entitile asociate, plus, eventual, atribute caracteriznd tipul de asociaie (i nu vreun tip de entiti implicat n asociaie; de exemplu, tipul de asociaii FURNIZARE, asociind tipurile de entiti FURNIZOR i PIESA, poate avea ca atribut PreFurnizare, funcie caracteriznd doar asociaia, dar nici unul dintre cele dou tipuri de entiti asociate, cci un furnizor poate furniza mai multe tipuri de piese, iar o aceeai pies poate fi furnizat de mai muli furnizori, de obicei la preuri diferite). Ca i n cazul tipurilor de entiti i atributelor, nu exist o distincie absolut ntre tipuri de entiti i tipuri de asociaii. O regul uzual pentru a le deosebi ar fi urmtoarea: dac existena tipului respectiv depinde de existena (a mcar) unui tip de entiti, atunci avem de-a face cu un tip de asociaii (de exemplu, nu vom modela, de obicei, STOCURI ca un tip de entiti agregat, s spunem, din atributele Piesa, Magazie i Stoc ci, mai degrab, ca un tip de asociaii ntre tipurile de entiti PIESE i MAGAZII: piesele i magaziile exist independent de stocuri, dar nu i vice-versa). Vom vedea n seciunea 2.3 i n capitolul 5 c, pentru a abstractiza un nou tip de asociaii, avem cteodat nevoie s asociem ntre ele i tipuri de asociaii i nu doar de entiti. Astfel, un tip de asociaii poate corespunde la rndul su unei generalizri de unul sau mai multe tipuri de asociaii. De exemplu, ACORD_GLOBAL (modelnd nc sistemul de salarizare din unele ntreprinderi de stat) poate fi vzut ca o generalizare a tipurilor ACORD_ORAR i ACORD_LUNAR (vezi figura 2.9). Atributele (mulimile de atribute) care identific unic (prin valorile lor) entitile sau asociaiile dintr-o mulime (corespunznd unui tip de entiti, respectiv de asociaii) i care, n plus, sunt minimale se numesc chei (ale tipului respectiv). O cheie este deci o funcie injectiv 12, cu proprietatea c nici o funcie obinut prin nlturarea vreuneia din componentele sale nu mai este injectiv. De exemplu, Seria i Numrul crii de identitate (C.I.) identific unic orice persoan adult i, mpreun, constituie o cheie a tipului de entiti PERSOANE, pentru c, n plus, ea este minimal: nici Seria, nici Numrul crii de identitate singure nu sunt injective (existnd foarte multe persoane care au aceeai serie a C.I., dar numere diferite, dup cum exist i destule persoane avnd acelai numr de C.I., dar serii distincte). O mulime de entiti poate avea mai multe chei (de exemplu, CodulNumericPersonal constituie i el o cheie a tipului PERSOANE). De notat c orice mulime corespunztoare unui tip de entiti sau asociaii are cel puin o cheie: duplicatele neavnd sens, n cel mai ru caz combinaia tuturor atributelor constituind tipul respectiv este o cheie (nici nu ne-ar interesa de altfel memorarea de date despre entiti sau asociaii pe care nu le putem distinge unic!).
Reamintim c o funcie : E C se numete injectiv, dac x1, x2E cu proprietatea c (x1) = (x2), atunci i x1 = x2 (orice dou elemente din subdomeniu pentru care valorile corespunztoare sunt egale trebuie s fie i ele egale sau, echivalent: pentru orice dou elemente distincte din subdomeniu, valorile corespunztoare trebuie i ele s fie distincte). Injectivitatea este dual funcionalitii. 17
12

O supercheie a oricrei mulimi corespunznd unui tip de asociaii este alctuit din concatenarea cheilor tuturor tipurilor de entiti participnd n asociaie (se numete super-cheie un produs injectiv de funcii, dar nu neaprat minimal). n modelarea bd s-a ajuns la concluzia c este recomandabil caracterizarea fiecrui tip de entiti (i a tipurilor de asociaii participnd la formarea unui nou tip de asociaii) printr-o aa numit cheie surogat, i.e. un atribut ale crui valori nu fac dect s identifice unic entitile din mulimea asociat tipului respectiv (deci este o cheie) fr a fi purttorul nici unei alte informaii de unde epitetul surogat. Valorile acestui atribut fie c sunt sau nu vizibile utilizatorilor vor fi generate i terse automat de SGBD. De exemplu: #CodUtilaj, #CodLocalitate, #CodPies etc. Singura semantic pe care eventual o asociem acestui tip de atribut este aceea de asignare a unor numere de inventar. Note despre inadecvarea codurilor structurate: Pn nu demult se foloseau nc (drept chei, dei nu numai) codurile structurate: coduri formate prin concatenarea mai multor coduri, fiecare codificnd o alt informaie (exemplu: actualul cod numeric personal este un cod structurat format din 3 coduri concatenate cel de sex, cel de dat a naterii i cel cu semnificaie doar pentru Ministerul de Interne). Experiena a demonstrat inadecvarea acestor tipuri de coduri din toate punctele de vedere: conceptual, ele provoac confuzii, amestecnd nelesuri (semantici) diferite; fizic, ele sunt aproape de nentreinut, cci rigiditatea structurrii implementate prin concatenare nu permite extinderea domeniilor de valori ale codurilor componente (exemplu: cum n codul numeric personal s-au prevzut doar 6 cifre pentru data naterii, ncepnd cu anul 2000 ntreg codul structurat a devenit neutilizabil i ar fi trebuit complet schimbat (pentru c nu se mai poate ti dac persoana este nscut n 2000 sau n 1900!) ceea ce atrage dup sine modificri importante n programele ce l manipuleaz; de aceea, astzi prima cifr (care codific sexul) nu mai este doar 1 sau 2, ci i 5 ori 6... i mai tragic este atunci cnd nsi structura astfel codificat se modific: cum includem ntr-un asemenea cod o nou component sau mai multe de exemplu localitatea i ara naterii sau nc o relaie ntre componentele existente de exemplu, faptul c o localitate a aparinut la un moment dat unei alte ri dect cea creia i aparine acum?). De aceea, codurile structurate sunt astzi desuete. Pentru exemplul de mai sus, trebuie evident specificate n model tipurile de entiti PERSOANE, SEXE, respectiv LOCALITI i RI, fiecare cu codul ei care va constitui i cheia surogat a respectivului tip de entiti ntre care vom putea stabili apoi oricte tipuri de asociaii distincte, precum i atributul DataNaterii al tipului PERSOANE. De remarcat de altfel c structurarea codurilor a aprut i s-a meninut din considerente fizice, de performan ale programelor ce le manipuleaz i de economisire a spaiului de memorare i nu din considerente logice, de modelare a datelor! ntr-o ierarhie de generalizri de tipuri de entiti sau asociaii, acestora, dar i atributelor corespunztoare li se pot asocia roluri. De exemplu, un PARTENER poate avea ntr-o ierarhie att rolul de FURNIZOR, ct i cele de BENEFICIAR, DEBITOR, CREDITOR, PLASAMENT, INVESTITOR etc. n principal, rolurile disting ntre diversele participri ale aceluiai tip (de entiti sau asociaii) n diferite generalizri i agregri sau tipuri de asociaii. Reprezentrile uzuale ale tipurilor de entiti i asociaii, rolurilor i atributelor sunt constituite fie din tabele, fie din grafuri, fie dintr-o combinaie a acestora. Cea mai comun reprezentare a lor este cea combinat: un graf avnd ca noduri tabelele (cu
18

coloanele etichetate de atribute) reprezentnd tipurile de entiti i asociaii, iar ca arce (etichetate de roluri) asociaiile ntre ele. ncheiem aceast seciune comentnd succint reprezentarea grafic a tipului de asociaii MICARE din figura 2.4. PIESA #Piesa DenPiesa MAGAZIE MICARE MAGAZIE

#Mag Mag #Piesa #MagS #MagD #Doc Cantit. #Mag Mag

surs

destinaie DOCUMENT #Doc TipDoc DataDoc

Fig. 2.4 Exemplu de reprezentare grafic a tipurilor de entiti i asociaii, atributelor, cheilor i rolurilor

Exemplul 2.1 Fie o bd modelnd evidena micrilor (transferurilor) de piese ntre mai multe magazii. O asemenea micare const n transferul (eventual simultan a) mai multor tipuri de piese, ntre o magazie (pe care o identificm drept surs) i o alta (destinaie). n general, sunt micate deodat mai multe piese de acelai tip. Orice micare este nregistrat pe un document pe care se specific, n plus, att data, ct i tipul micrii (consum, stocare etc.). Pe un asemenea document se nscriu, n general, mai multe micri (cu aceeai dat i de acelai tip). Distingem, n consecin, trei tipuri de entiti: PIESA, MAGAZIE i DOCUMENT, precum i un tip de asociaii: MICARE. Presupunem c nu ne intereseaz despre piese i magazii dect codul lor de identificare unic i denumirea corespunztoare, iar despre documente, doar numrul lor de ordine (care le identific unic), data i tipul. Despre micri ne intereseaz evident i cantitatea de piese de acelai tip (exprimat n numrul de buci) micate deodat (ntre aceleai magazii, pe un acelai document). Se observ n figura 2.4 c fiecare tip de entiti este caracterizat de cte o cheie surogat (#Cod) i de o mulime de alte atribute. Astfel: agregarea #Piesa, DenPiesa constituie tipul de entiti PIESA; agregarea #Mag, Mag constituie tipul de entiti MAGAZIE; iar agregarea #Doc, TipDoc, DataDoc constituie tipul de entiti DOCUMENT. Deoarece n fiecare asociaie de tip micare este implicat o pereche de magazii, tipul de entiti MAGAZIE este reprezentat n figura 2.4 de dou ori, iar arcele care unesc apariiile sale cu reprezentarea tipului de asociaii MICARE sunt etichetate corespunztor (surs i destinaie fiind cele dou roluri ale MAGAZIE n MICARE).
19

n sfrit, o linie din tabela MICARE (corespunznd unei micri) asociaz PIESA (identificat unic prin codul ei) care este micat n cantitatea memorat de Cantit., cu MAGAZIE surs (identificat unic prin #MagS), MAGAZIE destinaie (identificat unic prin #MagD) i DOCUMENTul pe care este nregistrat micarea (identificat unic prin #Doc). De remarcat c, trivial, valorile atributului Cantit. nu caracterizeaz nici PIESA, nici DOCUMENT i nici vreuna din cele dou magazii implicate n MICARE, ci doar relaia (ntre aceste tipuri de entiti) reprezentat de tipul de asociaii MICARE. 2.3 Diagrame entiti-asociaii (DEA)

Prezentm n continuare o versiune simplificat i uor modificat a MEA: subuniversul de modelat este constituit din mulimea tuturor tipurilor de entiti i asociaii, precum i din atributele lor caracteristice. SUM poate fi reprezentat de o diagram entiti-asociaii astfel: tipurile de entiti sunt reprezentate prin dreptunghiuri etichetate cu numele tipului respectiv; tipurile de asociaii sunt reprezentate prin romburi (sau, dac este nevoie de n conexiuni, cu poligoane regulate avnd n laturi) etichetate cu numele tipului; atributele sunt reprezentate prin cercuri (sau elipse) etichetate cu numele atributului; proprietile tipurilor de asociaii i/sau entiti descrise de atributele respective (i.e. agregrile) sunt reprezentate prin arce conectnd tipul i atributul respectiv (arce eventual etichetate de numele proprietii); implicarea unui tip (de entiti sau asociaii) ntr-un tip de asociaii este reprezentat printr-un arc conectnd reprezentrile tipurilor respective, arc eventual etichetat cu rolul tipului respectiv n acel tip de asociaii; cheile surogat sunt reprezentate ca atribute ale tipului respectiv, avnd numele format din numele tipului prefixat de caracterul '#' i, eventual, de cuvntul 'Cod' sau numai din '#Cod' (ori de cte ori nu este posibil vreo confuzie); generalizrile (i.e. relaia ESTE-UN(O) ntre diverse tipuri de entiti sau asociaii) sunt reprezentate prin arce etichetate cu rolul rezervat ESTE-UN(O). Un exemplu de DEA (pentru compartimentul Desfacere al unei ntreprinderi) este reprezentat n figura 2.5. De remarcat c MEA simplificat nu include n SUM nici o constrngere explicit n afara celor induse de clasificri (reprezentate prin tipuri de asociai etichetate tot cu ESTE-UN(O)) i a naturii tipurilor de asociaii (1-la-n, care trebuie explicitat sau n-la-m, care poate fi omis, fiind implicit). Se pot reprezenta totui n DEA i o parte din restul constrngerilor explicite: uzuale n acest sens sunt restriciile de cardinalitate. Dar, pentru a pstra DEA ct mai simple posibil i cum LMD definit peste aceste diagrame nu manipuleaz dect structurile schemei i nu i constrngerile asociate acestora, preferm simplificarea DEA descris mai sus. Asociaiile binare funcionale sunt uneori reprezentate simplificat. De exemplu, Oracle folosete aa-numita ghear (vezi figura 2.6), n care nu apar etichetele 1 sau n, dar captul n al arcului este o stilizare a unei gheare. Preferm reprezentarea standard din matematic: o sgeat, orientat de la n la 1 (adic exact ca n definiia funciei corespunztoare), o dubl sgeat pentru funciile injective, respectiv o sgeat pornind dintr-un semn de incluziune pentru aplicaiile canonice corespunztoare (vezi fig. 2.7).

20

JUDEE 1

#Jud Denumire

APART. LOC. din n LOCALITI 1 #Loc Denumire #Utilaj Tarif Norm Fizic

SEDIU CLIENT localizai n CLIENI beneficiar titular Denumire Adresa #Client

1 TIPURI_UTILAJE 1

CONTRACTARE Numr Schimburi Service

CLASIF_ MAINI

ESTE-O

CONTRACTE

ANEXE

MAINI

#Contract Data Contract

Termen Valabilitate

Tip Anex

#Maina Se-

An Fabricaie

Fig. 2.5 Un exemplu de diagram entiti-asociaii (DEA) 21

LOCALITI

JUDE

JUDEE

Fig. 2.6 Un exemplu de ghear folosit de Oracle n reprezentarea unui tip de asociaii funcional

PRIMARI ESTE-O PRIMAR

PERSOANE

ESTE-O PREFECI PREFECT

JUDE LOCALITI REEDIN

Fig. 2.7 Un exemplu de reprezentare sagital a tipurilor de asociaii funcionale

JUDEE

n plus, puterea MEA original este considerabil mrit printr-o extensie natural simpl (dar decisiv n creterea capacitii sale de surprindere a semanticii domeniilor de modelat): permitem, n plus fa de MEA prezentat n literatura de specialitate, ca un tip de asociaii s poat fi abstractizat nu numai din tipuri de entiti, ci i din tipuri de asociaii 13. Un exemplu natural de asemenea tip de asociaii este constituit de PARTICIPARECURS, care asociaz tipul de entiti CURSANT i tipul de asociaii SESIUNE_CURS (vezi figura 2.8). Grafic, un asemenea tip de asociaii se reprezint nchiznd n cte un dreptunghi (ca pe un tip de entiti!) punctat fiecare din tipurile de asociaii participnd n abstractizarea noului tip de asociaii (vezi i figura 2.9, n care universul de interes l constituie sistemul nc actual de salarizare n unele ntreprinderi de stat). 2.4 Limbaje de manipulare a datelor peste DEA

MEA permite definirea unor limbaje de manipulare a datelor de nivel foarte nalt, orientate spre utilizator. Dei independente de context (ca i limbajele de programare) ele seamn foarte mult cu limbajul natural. Variabilele unui asemenea limbaj sunt constituite din numele atributelor, tipurilor de entiti i asociaii. Sintaxa lor se bazeaz n rest pe cuvinte cheie -pentru clauzele standard- i roluri. DEA ajut foarte mult utilizatorii acestor LMD s navigheze prin schema modelului pentru a-i formula ntrebrile sau cererile de actualizare. Prezentm mai jos patru exemple de fraze (asupra schemei din figura 2.5) ntr-un asemenea LMD (LMDMEA, n care rolurile sunt scrise cu caractere italice, cuvintele cheie sunt ngroate n raport cu variabilele, comentariile ce ajut la crearea iluziei c LMDMEA este natural sunt scrise cu litere italice mici ngroate, iar constantele de tip ir de caractere sunt nchise ntre apostroafe). Exemplul 2.2: INSEREAZ CLIENI avnd Denumire = "Stefanel" I Adresa = "Calea Victoriei"; SELECTEAZ AnFabricaie MAINI care ESTE-O TIPURI-UTILAJE avnd Tarif = 24 I

Literatura de specialitate abund n semnalarea dificultilor ntlnite n modelarea folosind MEA (originalul sau variantele sale ulterioare, extinse), dintre care destule se datoreaz acestei neuniformiti n tratarea tipurilor de entiti, respectiv asociaii. 22
13

#Curs

Denumire #Sesiune curs

#Instructor

Nume

Prenume

CURSURI Data Inceput se in n LOCALITI #Loc Denumire

de SESIUNE CURS

predau

INSTRUCTOR

Durata

Cod Potal ABSOLVIRE CURS

Nota

PARTICIPARE CURS particip

absolv

CURSANI

#Cursant

Nume

Prenume

Fig. 2.8 Tipuri de asociaii construite peste un alt tip de asociaii

sunt contractate cu CONTRACTE avnd titular CLIENI avnd Adresa = "DOAMNEI,1" SAU care sunt localizai n LOCALITI din JUDE avnd Denumire = "Arge"; TERGE MAINI contractate cu CONTRACTE avnd titular CLIENI avnd Denumire = "Bancorex"; MODIFIC CONTRACTE avnd beneficiar CLIENI localizai n LOCALITI din JUDE avnd Denumire = "B" STABILIND TermenValabilitate = = TermenValabilitate + 5 I NumrSchimburiService = 3;

23

#Cod

REELE RETRIBUIE

Denumire #Cod

Val. retrib. orare

RETRIB. ORAR

GRADAII/TREPTE

Clasa #Cod CATEGORII Clasa

ACORD ORAR

RETRIB. FUNCIE

ANGAJAI

FUNCII

#Cod

Nume

Prenume

#Cod

Denumire

Fig. 2.9 O ierarhie de tipuri de asociaii modelnd salarizarea

Descrierea informal a universului de interes astfel modelat, mpreun cu DEA asociat i cu o mulime de operaii definite pe structura SUM (pe care se definete un asemenea LMD) constituie aa-numita bd infologic. 2.5 Probleme propuse spre rezolvare

2.1 Propunei tipurile de entiti i asociaii, atributele, cheile i eventualele roluri necesare pentru modelarea exemplului din seciunea introductiv (Exemplu de problem tipic n baze de date); construii DEA a modelului obinut; formulai n LMD-MEA cele 6 ntrebri aferente. 2.2 Construii i reprezentai grafic (ca n figura 2.1) o ierarhie de generalizri pentru munii Carpai cu urmtoarele niveluri: lanuri muntoase, sublanuri, masive, vrfuri. 2.3 Proiectai DEA pentru o bd potal de jucrie care s aib n vedere cel puin urmtoarele: continente, zone geografice subcontinentale (de exemplu: Europa Occidental, Europa Central i de Est, Orientul Mijlociu, Orientul ndeprtat etc.), ri, capitale, subdiviziuni administrative naionale (de exemplu: judee, state, departamente, landuri, provincii etc.), localiti, subdiviziunile lor administrative (sectoare, arondismente, poriuni de strzi etc.), coduri potale, monede, paritatea curent de schimb ntre ele, prefixe telefonice i coduri automobilistice naionale i internaionale. Traducei-o n MRD folosind algoritmul 3.1 i furnizai un coninut plauzibil. 2.4 Construii o DEA pentru urmtorul univers de interes (aprovizionare): Furnizori (#Cod, Denumire, Adresa, Localizare)
24

Produse (#Cod, Seria, AnFabricaie, araProvenien, Tip) TipuriProduse (#Cod, Denumire) Furnizare (#Cod, Furnizori, TipuriProduse, Pre) Localiti (#Cod, Denumire, ara) ri (#Cod, Denumire) innd cont de urmtoarele precizri suplimentare: un furnizor este localizat ntr-o unic localitate i furnizeaz mai multe tipuri de produse; un produs poate proveni din mai multe ri dar este de un unic tip, iar un tip poate fi furnizat de mai muli furnizori, la preuri diferite. Traducei-o n MRD folosind algoritmul 3.1 i furnizai un coninut plauzibil. 2.5 Construii o DEA pentru urmtorul univers de interes (tehnolog): TipuriProduse (#Cod, Denumire, CategorieProdus) TipuriCaracteristici (#Cod, Denumire, UnitateMsur, CategorieCaracteristic) Caracteristici (#Cod, TipuriProduse, TipuriCaracteristici, Valoare) CategoriiProduse (#Cod, Denumire, ClasaProdus) CategoriiCaracteristici (#Cod, Denumire, ClasaCaracteristic) ClaseProduse (#Cod, Denumire, ProcentTVA) ClaseCaracteristici (#Cod, Denumire) UnitiMsur (#Cod, Prescurtare, Denumire) Submultiplii(#Cod, UnitateMsur, UnitateMsurMultiplu, FactorMultiplicare) innd cont de urmtoarele precizri suplimentare: un tip de produse sau de caracteristici face parte dintr-o unic categorie; similar, o categorie de produse sau caracteristici face parte dintr-o unic clas; o caracteristic poate fi comun mai multor tipuri de produse, iar un produs poate avea mai multe caracteristici; pentru fiecare din ele, exist o unic valoare per tip de produs. Traducei DEA astfel obinut n MRD folosind algoritmul 3.1 i furnizai un coninut plauzibil. 2.6 Construii o DEA pentru urmtorul univers de interes (pli): Vnzarea/ cumprarea (produselor sau serviciilor) se face conform unor documente justificative (de diverse tipuri: facturi, contracte de vnzare-cumprare etc.) emise de vnztor cumprtorului, la data vnzrii/cumprrii. Plile pentru vnzri /cumprri se justific tot cu documente (de diverse tipuri: chitane pentru pli numerar, file de CEC i ordine de plat pentru plile bancare, procese verbale de compensare etc.) emise de cel care ncaseaz banii pentru cel care achit, respectiv de cel care dispune transferul bancar ctre furnizor. O plat nu se face ntotdeauna deodat, pentru o singur vnzare/cumprare, ci ealonat, n mai multe trane, cteodat grupnd mpreun trane corespunznd mai multor documente de vnzare /cumprare. Orice vnztor poate fi la rndul su cumprtor i vice-versa. Despre documente (fie ele de vnzare/cumprare sau de plat) intereseaz tipul, seria, data, emitentul, beneficiarul, suma; despre cele de vnzare/cumprrare mai intereseaz i data scadenei plii; despre documentele de plat bancare mai intereseaz i conturile emitentului i beneficiarului (numr, sucursala bancar ce gestioneaz contul i localitatea n care aceasta i are sediul); despre pli intereseaz valoarea tuturor tranelor achitate; despre vnztori i cumprtori intereseaz denumirea, codul fiscal i localitatea n care i au sediul. Traducei DEA astfel obinut n MRD folosind algoritmul 2.1 i furnizai un coninut plauzibil. 2.7 Construii o DEA pentru a modela metadatele MEA.

25

2.8 a. Asupra bd de la problema 2.4 (aprovizionare) s se scrie n LMDMEA interogarea pentru a afla produsele ce pot fi cumprate la cele mai mici preuri de la furnizorii care au sediul n rile n care sunt fabricate produsele respective. b. Asupra bd de la problema 2.5 (tehnolog) s se scrie n LMDMEA actualizarea pentru a modifica valorile tuturor caracteristicilor msurate n amperi prin nlocuirea acestora cu valorile corespunztoare n miliamperi. c. Asupra bd de la problema 2.6 (pli) s se scrie n LMDMEA interogarea pentru a afla toate plile (tip, data, suma, pltitor) efectuate pentru documentele a cror scaden este ziua curent. 2.9 a. Aplicai algoritmul 3.1 asupra DEA obinute la problema 2.7. b. Furnizai un coninut valid plauzibil al schemei relaionale astfel obinute (avnd cel puin doi tupli per relaie). 2.6 Comentarii i referine bibliografice

Era modern n modelarea datelor a fost deschis de Mealy [256] n 1967. Generalizarea i agregarea datelor se datoreaz lui Smith i Smith [318], care le-au introdus n 1977. Modelul entiti-asociaii, introdus de Chen n 1976 [103], a fost primul model conceptual al datelor de mare succes. Printre cercettorii cu o contribuie semnificativ la dezvoltarea LMD pentru acest model se numr i Victor Markowitz, autor al limbajului ERROL ("An Entity-Relationship, Role Oriented, Query Language", [372] 1983) care a constituit sursa inspiraiei pentru LMDMEA introdus n seciunea 2.4. n 1985, am publicat o prim ncercare de formalizare algebric a MEA [248], care considera i extensia modelului prin ncorporarea tipurilor de asociaii definite peste alte tipuri de asociaii. Astzi, biblia MEA este [300] a lui Bernard Thalheim. Chiar dac MEA este un model prea simplu, srac n privina constrngerilor posibil de exprimat, datorit ns deosebitei puteri sugestive a DEA, el este intens folosit i astzi n modelarea conceptual a datelor, ca adjuvant al modelelor altfel mai puternice. Desigur c o DEA a unui subunivers de interes complex este greu i de construit i de urmrit; de aceea, se prefer partiionarea SUM n subscheme simple, pentru a cror modelare sunt de un imens ajutor DEA aferente. De remarcat c DEA (alturi de organigrame etc.) stau i la baza diagramelor UML [319].

26

3 Modelul relaional
Modelul relaional al datelor (MRD), primul model matematic n baze de date (bd), att n ordine cronologic, ct i a importanei, constituie piatra unghiular n domeniu din cel puin urmtoarele patru puncte de vedere: 1. Majoritatea uneltelor de bd existente pe pia se bazeaz pe acest model de peste dou decenii, fie c este vorba de cele elementare, pentru PC-uri (e.g. Access, FoxPro, Delphi, Paradox, dBase etc.), fie c este vorba de cele pentru mini i mainframes (e.g. IBM DB/2, Oracle, Tandem NonStop SQL, Sybase SQL Server, MS SQL Server, Postgress etc.) i, n viitorul previzibil, nici un alt model nu pare capabil a i se substitui n aceast privin. 2. Orice model al datelor de nivel mai nalt trebuie s aib n componen un algoritm de traducere a bd n model relaional, deoarece cea mai natural modalitate de memorare a datelor discrete o constituie tabelele. 3. Majoritatea limbajelor de interogare, definire i manipulare a datelor existente se bazeaz pe cele relaionale (n special pe SQL i QBE). 4. Teoria matematic a proiectrii i interogrii bd relaionale (bdr) este nc deschis, de actualitate i fundamenteaz (sau mcar inspir) majoritatea demersurilor similare n alte modele ale datelor i/sau cunotinelor. Provocarea de a scrie o monografie asupra MRD este deci aproape obligatorie pentru orice specialist n domeniu, chiar dac literatura domeniului este deja foarte bogat, cel puin pentru a prezenta punctul de vedere propriu actual (i n limba matern): care sunt rezultatele i demonstraiile cele mai importante, care sunt principalele limite ale MRD, n general deci ce i ct trebuie aprofundat n domeniu? Pe lng rspunsurile proprii la aceste ntrebri, prezenta monografie ncearc s furnizeze i o colecie bogat de exemple concrete i corecte, care s sprijine intuiia cititorului i s-i serveasc drept bibliotec de soluii primare n domeniu. Prezentarea ncepe cu aspectele "statice", structurale, interesnd doar proiectarea schemelor de bd (n primele seciuni); apoi (n ultima seciune) sunt tratate i interogrile, ce in de "dinamica" bd; dat fiind ns strnsa interdependen ntre algebra relaional i descompunerea fr pierderi sau dependenele join, seciunea 1.5 conine deja o introducere n limbajul algebric relaional de interogare. Dup un scurt istoric (n seciunea 1.1), introducerea relaiilor n seciunea 1.2 (inclusiv motivarea diferenelor n raport cu noiunea matematic omonim) i a unei prime formalizri a MRD n seciunea 1.3, urmeaz, n seciunea 1.4, o scurt trecere n revist a primei forme normale. Capitolul 2 struie asupra constrngerilor de integritate, analiznd cheile (inclusiv cele primare i strine, dar, n special, dependenele cheie), valorile nule, constrngerile tuplu, cele implicate, cele triviale, ca i dependenele de incluziune tipate i funcional dependenele. Sunt apoi prezentate n Capitolul 3 anomaliile de actualizare a datelor care, mpreun cu cheile, impun i justific necesitatea formei normale Boyce-Codd. 3.1 Relaii "Orice fel de conexiune perceput sau imaginat ntre dou sau mai multe lucruri, precum i orice comparaie fcut de minte este o relaie." I. Taylor O bdr este reprezentat ca o mulime de tabele, fiecare dintre ele avnd ataat un nume unic n cadrul bd. Liniile tabelelor reprezint o legtur (n sensul de asociaie, relaie) ntre elementele unor mulimi de valori. Capul de tabel conine nume de atribute ce tre27

buie s fie distincte n cadrul fiecrei tabele. Pentru fiecare coloan n parte exist o mulime de valori posibile, numit domeniu 14. Figura 1.1 conine o reprezentare tabular a unor date despre cri i vnzarea lor. Analiznd cele patru tabele, se poate afirma c fiecare linie este un n-tuplu ordonat de valori <d1, d2, ..., dn>, n care fiecare valoare dj aparine domeniului coloanei j, j=1,2,...,n, unde n 1 este numrul de atribute al tabelei. n general, o asemenea tabel (zis n MRD relaie), memoreaz datele de interes despre o mulime de obiecte; fiecrui element al mulimii i corespunde o linie a tabelei; fiecrei proprieti de interes a elementelor mulimii i corespunde o coloan a tabelei; fiecare celul de la intersecia unei linii cu o coloan memoreaz valoarea proprietii respective pentru elementul respectiv. n teoria matematic a relaiilor, dat fiind un ir de mulimi D1, D2, ..., Dn (nu neaprat distincte!), o relaie este o submulime a produsului cartezian D1 D2 ... Dn. D1, D2, ..., Dn poart numele de domeniile relaiei, iar n de gradul (sau aritatea) ei. O relaie este deci o mulime de n-tupli de forma <d1, d2, ..., dn> astfel nct fiecare valoare dj aparine domeniului Dj, unde j = 1,2,..., n. Una dintre reprezentrile posibile ale relaiilor este, desigur, cea tabular (lipsit ns n matematic de numele coloanelor). Numrul de n-tupli ai unei relaii poart numele de cardinalul 15 ei. n general, dac domeniile sunt infinite, atunci i cardinalitatea relaiei poate fi infinit. Evident ns c n aplicaii concrete de bd cardinalul oricrei relaii este finit. n cele ce urmeaz, implicit, vom presupune relaii finite peste domenii infinite. Conform proprietilor fundamentale ale mulimilor i relaiilor, rezult urmtoarele: 1. ( i) ordinea n-tuplilor ntr-o relaie este irelevant (ii) n-tupli unei relaii sunt distinci (nu exist dubluri) 2. orice n-tuplu este o mulime ordonat de valori (adic orice a i-a valoare aparine celui de-al i-lea domeniu); ca atare, ordinea domeniilor unei relaii matematice este semnificativ. Dup cum se poate observa n exemplul 1.1, pentru a interpreta corect nelesul unei relaii matematice, referirea la domenii trebuie fcut folosind poziia acestora n irul definind relaia. Exemplul 1.1 S reprezentm printr-o relaie matematic, numit orar, informaii privind cursurile inute ntr-o facultate: orar ir ir dat dat, orar = {<Ionescu, Logic, 15.07.94, 30.05.95>, <Popescu, Algebr, 15.07.94, 30.06.95>, <Nicolescu, Fizic, 15.07.95, 20.01.96>}. Domeniul dat are aici dou roluri distincte, indicnd data de ncepere a cursurilor, respectiv cea de sfrit. Singurul mod de a distinge ntre ele este doar faptul c acestea ocup poziia a treia, respectiv a patra n irul domeniilor. Lucrurile sunt, desigur, similare i pentru domeniul ir. Pentru a evita acest neajuns, este de obicei adoptat n bdr o definiie alternativ a relaiilor: fiecrei apariii a unui domeniu i se asigneaz un rol. Rolurile sunt referite prin nume simbolice zise atribute, care corespund ct mai apropiat cu putin numelor coloanelor din reprezentarea tabular. Formal, legtura ntre atribute i domenii este stabilit de o funcie dom : X D definit pe mulimea atributelor X = {A1, A2, , An} i cu valori n mulimea domeniilor D.

Aici neles mai degrab ca n programare, drept domeniu de valori, dei este vorba de codomeniul atributului privit ca funcie definit pe relaia din care face parte. 15 n general, funcia cardinal (notat card(M) sau cardM, unde M e o mulime) este definit pe mulimea tuturor mulimilor i cu valori n mulimea naturalilor, asociind fiecrei mulimi numrul ei de elemente. Trivial, de exemplu, card = 0. 28
14

#Autor 1 2 3 4 #Carte 1 12 29 37 Autor 1 2 3 4

AUTORI Prenume Emil Constantin Mircea Mircea

Nume Cioran Noica Ciobanu Eliade Pre 6.000 8.000 6.000 12.000

CRI Titlu Silogismele amrciunii Devenirea ntru fiin Convorbiri cu Regele Mihai I De la Zalmoxis la Gingis-Han VNZTORI Vnztor Librria din fundul curii Dalles Kretzulescu VNZRI Vnztor 1 1 1 1 2 3 3 Carte 1 12 29 37 29 1 29

#Vnztor 1 2 3 #Vnzare 1 2 3 4 5 6 7

Cantitate 670 210 2.890 915 4.770 820 150

Fig. 1.1: Reprezentarea tabular a unei bdr

Similar, un tuplu peste mulimea atributelor X este o funcie t care asociaz fiecrui atribut Ai X o valoare din domeniul dom(Ai); aceast valoare se noteaz t[Ai]. Notaia se poate extinde la mulimi de atribute Y X: t[Y] indic restricia funciei t la atributele din Y. 16 Exemplul 1.2 n exemplul 1.1 s-ar putea defini urmtoarele atribute: Profesor cu dom(Profesor) = ir Curs cu dom(Curs) = ir nceput cu dom(nceput) = dat Sfrit cu dom(Sfrit) = dat Tuplul <Ionescu, Logic, 15.07.94, 30.05.95> din exemplul 1.1 poate fi descris funcional astfel: t[Profesor] = Ionescu, t[Curs] = Logic, t[nceput] = 15.07.94, t[Sfrit] = 30.05.95. Revenind la reprezentarea tabular, putem acum afirma i formal c o relaie poate fi prezentat n mod natural ca o tabel ale crei linii corespund tuplilor i n care coloaneAceast notaie conine o incoeren: dac A este un atribut, atunci t[A] este o valoare; simultan, dac X este un atribut, atunci t[X] este un tuplu, adic o funcie. De asemenea, dup cum vom vedea, mulimile coninnd un singur atribut sunt de obicei notate cu numele atributului; urmeaz c, dac X = A, atunci t[A] este att o valoare ct i un tuplu. Ambiguitatea aceasta este ns deseori irelevant, dar trebuie clarificat semnificaia notaiilor n toate cazurile relevante. 29
16

le conin valori ale cte unui atribut al relaiei (vezi figura 1.2). Este ns important de subliniat faptul c o relaie este o descriere formal a corespondenei ntre elementele unor mulimi, n timp ce o tabel este doar una dintre posibilele reprezentri ale relaiei. Analiznd reprezentarea tabular a relaiilor, se observ urmtoarele: Valorile oricrei coloane sunt omogene (i.e. valorile unui atribut aparin unui acelai domeniu: ntregi, iruri de caractere etc.). Liniile sunt distincte (relaiile sunt mulimi de tupli, deci nu pot conine niciodat duplicate). Ordinea coloanelor este irelevant (cci ele sunt ntotdeauna identificate printrun nume unic n cadrul relaiei i nu prin poziie). Ordinea liniilor este irelevant (cci ele sunt identificate prin coninut i nu prin poziie). Numele relaiei r A1 a1,1 . .. a1,k Tuplu ... ... ... ... An an,1 ... an,k Valorile unui atribut
Fig. 1.2: Atribute, tupli i valori ntr-o relaie

Numele atributelor

3.2

Definiia formal a modelului relaional

Un model al datelor este o unealt formal pentru descrierea informaiilor de interes n diverse aplicaii. Exist dou niveluri de descriere posibile: 1. Nivelul intensional, implicnd proprietile generale ale claselor de valori, precum i ale claselor de corespondene ntre acestea. 2. Nivelul extensional, implicnd valorile propriuzise i corespondenele ntre ele. n modelul relaional, primul nivel corespunde descrierii independente de timp a relaiilor (scheme), iar cel de-al doilea corespunde coninutului de date al relaiilor (instane) la un moment dat. Definiia 1.1 Schema relaiei const dintr-un nume (numele relaiei) i o mulime de nume de atribute. Notaia pentru o relaie numit R cu atribute A1, A2, , An este R(A1, A2, , An). Prin convenie, numele relaiilor se scriu italic, cu majuscule. Schema unei bazei de date const dintr-o mulime de scheme de relaii, fiecare din ele avnd nume distincte. Prin convenie, notaia pentru scheme utilizeaz litere mari italice i ngroate, de exemplu R. Din considerente tipografice, nu vom folosi ns ngroarea. Definiia 1.2 Coninutul (instana) relaiei (sau, simplu, relaia) definit peste o schem R(X) const dintr-o mulime finit de tupli peste X. Prin convenie, coninutul unei relaii se noteaz cu numele schemei sale scris ns cu liter mic (de exemplu r). Coninutul (instana) bazei de date (sau, simplu, baza de date) definit peste o schem R = {R1(X1), R2(X2), ..., Rn(Xn)} const dintr-o mulime de relaii {r1, r2, ..., rn}, unde fiecare ri este definit peste schema corespunztoare Ri. 17 Exemplul 1.3 Fie datele despre cri i vnzri din figura 1.1. Schema bd conine patru scheme de relaie:
Mai precis (dar mai puin clar), o baz de date ar putea fi definit ca o aplicaie asociind fiecare relaie r peste R(X) cu schema sa R(X). 30
17

AUTORI (#Autor, Prenume, Nume) CRI (#Carte, Autor, Titlu, Pre) VNZTORI (#Vnztor, Vnztor) i VNZRI (#Vnzare, Vnztor, Carte, Cantitate). Coninuturile relaiilor corespunztoare sunt: autori = {t1, t2, t3, t4} vnztori = {t5, t6, t7} cri = {t8, t9, t10, t11} i vnzri = {t12, t13, t14, t15, t16, t17, t18}, unde: t1[#Autor] = 1, t1[Prenume] = Emil, t1[Nume] = Cioran,..., t8[Titlu] = Silogismele amrciunii, t8[Pre] = 6.000 .a.m.d. Pentru a uura citirea, reprezentm relaiile cu ajutorul tabelelor, adoptnd notaia formal doar pentru valori individuale ale datelor. Pentru a reprezenta coninutul unei bd, ncadrm pe figura corespunztoare toate tabelele componente ntr-un dreptunghi, ca n figura 1.1. Alte convenii notaionale uzuale sunt urmtoarele: atributele se noteaz cu litere mari de la nceputul alfabetului, eventual cu indici i apostroafe (A,B,...,A1,A,...); mulimile de atribute la fel, dar folosind litere de la sfritul alfabetului (X,Y,...,X1,X, ...) sau prin juxtapunerea numelor atributelor implicate (de exemplu, X = A1A2...Ak); similar, reuniunea mulimilor de atribute se noteaz prin concatenarea numelor acestora (de exemplu, XA nseamn X {A}); cteodat, mai ales n cazul operanzilor din expresiile algebrice relaionale, n loc de numele relaiei se folosete notaia r(X), cu semnificaia "relaia r definit peste mulimea de atribute X". Pe lng atributele semantice, practica proiectrii bd a evideniat necesitatea includerii n schema oricrei relaii a unui atribut sintactic, cu rol de identificare unic minimal, numit cheie surogat; domeniul su este mulimea numerelor ntregi. Definiia 1.3 Se zice cheie surogat a unei relaii R, un atribut (n general notat cu #R) al crui domeniu este autonumber (i.e. o submulime a ntregilor ale cror elemente sunt automat generate de SGBDR) i care nu are nici o alt semnificaie dect numerotarea unic a tuplilor R. De exemplu, evident, #Autor, #Vnztor, #Carte i #Vnzare sunt cheile surogat ale relaiilor din figura 1.1. Cheile surogat furnizeaz fiecrui tuplu doar un numr de inventar unic n cadrul relaiei. De aceea, ele sunt referite drept atribute sintactice, spre deosebire de toate celelalte atribute care sunt referite drept semantice. Majoritatea SGBDR ofer pentru ele o mulime cu autonumrare (autonumber sau counter sau identity) ale crei valori sunt automat asignate de sistem la crearea fiecrei noi linii, fie incremental, fie aleatoriu. Vom vedea pe parcursul acestei monografii c exist suficiente motive pentru respectarea urmtoarei reguli de proiectare a bd: fiecare relaie trebuie s aib o cheie surogat (i numai una). Principalele dou motive ar fi acela al minimizrii spaiului necesar memorrii legturilor ntre tabele, precum i acela al posibilitii de formulare a unor interogri (vezi seciunea 1.7 i capitolul 7) altminteri imposibil de formulat.

31

3.3

Prima form normal

Calculele minii nu necesit efortul nostru contient, ci doar atenia i deschiderea ntru libera circulaie a informaiei. Dei creierul absoarbe universuri de informaie, puin este admis n contiina normal. Marilyn Ferguson n exemplele de relaii de pn acum, toate valorile oricrui atribut au fost atomice (adic indivizibile n bd). Asemenea atribute se zic simple. Exist ns i alte dou tipuri de atribute la care ne vom opri n cele ce urmeaz 18. Un atribut se zice multivaluat dac valorile sale sunt elemente ale mulimii prilor unei mulimi (de valori). Exemplul 1.4 Atributul CoduriDisciplineAbsolvite din relaia prezentat n figura 1.3 este multivaluat. Domeniul su este mulimea prilor mulimii tuturor cursurilor oferite studenilor de facultatea n cauz. CodS 0962 0962 1087 1152 An 1995 1996 1996 1996 ABSOLVIRE CoduriDisciplineAbsolvite {MA101, MA102, F100, PC101} {MA201, MA202, PC201, BD201, SD201} {} {MA101, F100}

Fig. 1.3.: O relaie cu un atribut multivaluat

Un atribut se zice structurat dac valorile sale sunt tupli (de valori), deci dac domeniul su este o relaie. Exemplul 1.5 Atributul NoteObinute din relaia prezentat n figura 1.4 este structurat. Domeniul su este produsul cartezian ntre mulimea disciplinelor i mulimea notelor posibile. EXAMINRI CodStudent DataExaminrii NoteObinute 0962 20.06.95 <MA101,9> 0962 15.02.96 <MA202,10> 1152 08.02.96 <F100,6>
Fig. 1.4.: O relaie cu un atribut structurat

Domeniile pot avea structuri i mai complexe, construite din compuneri de multivaluri i structurri. Exemplul 1.6 Atributul Examene din relaia prezentat n figura 1.5 este att multivaluat, ct i structurat. Valorile sale sunt relaii (adic mulimi de tupli). n asemenea cazuri, desigur, sunt necesare convenii de reprezentare tabular care s evidenieze nivelurile de structurare. Definiia 1.4 O schem de relaie se zice c este n prima form normal (FN1) (sau plat) dac toate atributele ei sunt simple. Altfel, relaia se zice ncuibat (nested n englez). n modelul relaional al datelor sunt utilizate doar relaii plate, astfel nct modul de reprezentare a datelor s fie simplu i uniform. Se poate arta uor c orice relaie ncuibat se poate transforma ntr-o relaie plat echivalent.

Tipuri provenind din modelele de date ierarhic i reea, anterioare celui relaional, dar care sunt nc frecvent utilizate n foile de calcul tabelar (exemplu: Excel). 32
18

CATALOG CodS 0962 Secia Calculatoare Data 20.06.95 30.06.95 07.07.95 14.07.95 15.02.96 14.07.95 15.02.96 Examene Disciplina MA101 MA102 PC101 F100 MA202 F100 MA202 Nota 9 10 10 6 10 4 4

1087

Automatizri

Fig. 1.5. : O relaie cu un atribut relaie (adic i multivaluat i structurat)

Exemplul 1.7 Figura 1.6 prezint o relaie plat echivalent celei din figura 1.5. Aplatizarea a fost evident realizat prin nlocuirea atributului multivaluat structurat Examene cu componentele sale Data, Disciplina, Nota. CodS 0962 0962 0962 0962 0962 1087 1087 3.4 Secia Calculatoare Calculatoare Calculatoare Calculatoare Calculatoare Automatizri Automatizri CATALOG Data 20.06.95 30.06.95 07.07.95 14.07.95 15.02.96 14.07.95 15.02.96 Disciplina MA101 MA102 PC101 F100 MA202 F100 MA202 Nota 9 10 10 6 10 4 4

Fig. 1.6. : Relaia n FN1 echivalent celei din figura 1.5

Constrngeri de integritate

Omul superficial consider libertatea ca fiind eliberarea de orice lege, de orice constrngere. neleptul o consider ns dimpotriv ca fiind potenta Lege a Legilor. Walt Whitman Nu orice coninut al unei relaii este acceptabil (valid) n interpretarea dorit pentru o bd, chiar dac tupli ei au aritatea corect, iar valorile componentelor aparin domeniilor corespunztoare. Exemplul 1.8 Fie relaia din figura 1.7, memornd date despre studenii unei faculti. Evident c este imposibil ca un student s aib vrsta peste 140 de ani, dup cum e interzis ca doi studeni s aib acelai numr matricol; deci aceast relaie este invalid. #Student 1 2 3 NSCRIERE NrMatricol Student 32897 Ionescu Gabriel 44135 Georgescu Radu 44135 Vasilescu Mihai AnNatere 1973 1856 1975

Fig. 1.7: O relaie cu valori invalide, cci neplauzibile

Ca atare, modelarea relaional a datelor permite impunerea unor condiii ce trebuie respectate de toi tupli bd, astfel nct interpretarea lor s poat fi ntotdeauna acceptabil. Pentru aceasta, modelele datelor includ constrngeri de integritate ce trebuie satisf33

cute de orice coninut al schemelor de bd. n exemplul de mai sus, desigur, asemenea constrngeri ar fi, de exemplu: 1966 AnNatere 1977, respectiv NrMatricol injectiv. Constrngerile de integritate sunt ustensile pentru mbuntirea modelrii datelor. Vom vedea n seciunile i capitolele urmtoare c unele dintre tipurile de constrngeri introduse (chei, funcional dependene etc.) pot fi folosite n evaluarea calitii schemelor relaionale i n sugerarea diverselor descompuneri posibile ale acestora. Deoarece constrngerile de integritate joac un rol crucial n modelarea datelor, este obligatorie studierea lor n profunzime. Definiia 1.5 Se zice constrngere de integritate (sau simplu constrngere) asupra schemei unei bd R orice funcie ce asociaz fiecrui coninut de date r al R o valoare boolean (r). O bd r peste R satisface dac (r) = adevrat i violeaz dac (r) = fals. n primul caz se mai zice i c ine n r. Definiia 1.6 Fie R o schem i mulimea constrngerilor asociat ei; se zice c sunt consistente (sau valide, sau legale) doar acele instane ale R ce satisfac (adic satisfac toate constrngerile ei); altfel, ele se zic inconsistente (invalide, ilegale). Fiecare constrngere formalizeaz o proprietate ce trebuie satisfcut de orice coninut acceptabil al bd corespunztoare. Exist mai multe clase de constrngeri. Desigur c exist att notaii (sintaxa) pentru a exprima constrngerile din fiecare clas, precum i reguli ce definesc funcia boolean asociat fiecrui tip de constrngeri n parte (semantica). n majoritatea cazurilor, aceste funcii logice pot fi exprimate cu ajutorul propoziiilor nchise ale unui calcul predicativ de ordin nti. n modelul relaional al datelor, clasele constrngerilor de integritate pot fi mprite n dou categorii: 1. Constrngeri intrarelaionale (ce implic doar o singur relaie a schemei bd); exemplu: 1966 AnNatere 1977 (figura 1.7) 2. Constrngeri interrelaionale (ce implic schemele mai multor relaii); exemplu: Autor #Autor (figura 1.1) De remarcat c validitatea instanelor relaionale nu poate fi echivalat cu corectitudinea absolut (n raport cu realitatea), ci doar cu cea relativ la mulimea constrngerilor impuse schemelor respective: de exemplu, nici mcar operatorii bd nu tiu n general dac data de natere a unui angajat introdus ntr-o bd de personal este sau nu corect, deci cu att mai puin ar putea garanta vreo constrngere c ea este corect. Constrngerile asigur deci doar plauzibilitatea datelor din bd. 3.5 Principiul propagrii cheilor

La prima vedere, ar putea prea ciudat c valorile atributului Autor din tabela CRI a bd din figura 1.1 sunt numere i nu iruri de caractere. Se observ ns c aceste numere nu sunt alese arbitrar, ci ele corespund ntocmai celor ale cheii surogat #Autor din tabela AUTORI: ntr-adevr, Emil Cioran (#Autor = 1) a scris Silogismele amrciunii, Constantin Noica (#Autor = 2) este autorul Devenirii ntru fiin, Mircea Ciobanu (#Autor = 3) cel al Convorbirilor cu Regele Mihai I, iar Mircea Eliade (#Autor = 4) este autorul crii De la Zalmoxis la Gingis-Han. Instana relaiei CRI din figura 1.1 satisface deci constrngerea interrelaional Autor #Autor. Similar, instana relaiei VNZRI din aceeai figur satisface alte dou asemenea constrngeri: Vnztor # Vnztor i Carte # Carte. nlocuirea irurilor de caractere cu numerele corespunztoare ale cheilor surogat are mai multe justificri: la prima vedere, n locul numerelor de inventar, ar trebui memorai tupli corespunztori, ceea ce este ns nu doar extrem de costisitor ca spaiu necesar, dar i imposibil, cci relaiile ar conine atribute structurate, deci nu ar mai fi n FN1
34

analiznd problema modalitilor de realizare a legturilor ntre relaii cu mai mult atenie, este uor de ajuns la concluzia c este suficient includerea n relaia ce refer a oricrui atribut sau submulime de atribute ce identific ntotdeauna unic tupli relaiei referite ntre o submulime de atribute i un atribut, ntotdeauna este preferabil (nu doar ca i spaiu necesar, dar i din punct de vedere al complexitii soluiei) s fie ales un atribut dintre atributele ce identific unic tupli unei relaii, cheia surogat merit ntotdeauna preferat atributelor semantice, nu doar pentru c ocup cel mai puin spaiu, dar mai ales pentru c elimin posibile anomalii de actualizare a datelor (vezi capitolul 5)

Asemenea nlocuiri se fac n spiritul a ceea ce se numete principiul propagrii cheilor: n locul unui ntreg tuplu, se propag doar o cheie a tabelei corespunztoare. De remarcat c, dei nu toi proiectanii de bd procedeaz aa, cea mai bun soluie este ntotdeauna propagarea cheilor surogat. Vom vedea n seciunea 2.4 c fiecare asemenea propagare d natere unei chei strine i este obligatoriu nsoit de o constrngere de tip dependen de incluziune. 3.6 Proiectarea schemelor de bd relaionale Poate c a crede n proiectarea fcut bine este precum credina n Dumnezeu: te transform ntr-un optimist. Sir Terence Conran Majoritatea exemplelor din capitolele urmtoare demonstreaz c FN1, chiar atunci cnd este completat cu constrngeri de integritate, nu este mai deloc mulumitoare i c este deci necesar proiectarea unor forme normale mult mai exigente. Problema proiectrii schemelor de bd relaionale este n esen urmtoarea: ce scheme de relaii trebuie incluse n schema unei bd? ce scheme de relaii nu trebuie n schimb incluse? ce atribute (nu) trebuie s includ schema fiecrei relaii n parte? ce constrngeri (nu) trebuie s includ schema bd? care sunt criteriile ce ar putea ierarhiza diverse soluii de proiectare alternative cu putin? Aparent paradoxal, rspunsul la ultima ntrebare, dei nu este deloc simplu, poate fi neles cel mai lesne chiar i n acest punct introductiv. Este adevrat c nu exist vreun consens nici mcar n aceast privin, dar credem c urmtoarele dousprezece axiome ar putea fi extrem de greu contestate: (i) (ii) (iii) Axioma non-redundanei: n orice bd, orice informaie fundamental trebuie memorat o singur dat. Axioma performanei: orice bd trebuie s asigure maximum de performan posibil (i.e. cel mai bun raport ntre viteza de rspuns i memoria ocupat). Axioma redundanei controlate: (numai i numai) pentru satisfacerea axiomei performanei, bd pot memora i informaii calculate din cele fundamentale (deci redundante), cu condiia ca aceast redundan s fie strict controlat (i.e. utilizatorii pot avea cel mult acces numai n citire la informaiile redundante, deci niciodat n scriere). Axioma minimalitii actualizrilor: n orice bd, inserarea unei noi informaii, precum i modificarea sau tergerea unei informaii existente trebuie s poat fi fcut ntr-un singur loc. Axioma corespondenei constrngerilor: pentru orice constrngere din subuniversul modelat, orice schem de bd trebuie s includ o constrngere de integritate formaliznd respectiva constrngere din realitate.

(iv) (v)

35

(vi) (vii)

(viii) (ix) (x) (xi)

(xii)

Axioma minimalitii constrngerilor: nici o schem de bd nu trebuie s includ vreo constrngere de integritate fr corespondent n realitatea modelat sau care este deductibil din restul constrngerilor. Axioma optimalitii constrngerilor: mulimea constrngerilor de integritate ale oricrei scheme de bd trebuie s fie optim (i.e. s nu existe nici o mulime echivalent de constrngeri a cror impunere s fie mai ieftin, adic s poat fi fcut mai repede). Axioma plauzibilitii: n orice moment, toate datele memorate de o bd trebuie s fie plauzibile. Axioma unicitii: n orice moment, tupli oricrei relaii ai bd trebuie s poat fi unic identificai pe baza valorilor unui sau mai multor atribute semantice (i nu doar a cheii sale surogat). Axioma minimei totaliti: n orice moment, orice tuplu trebuie s aib o valoare precizat pentru cel puin unul din atributele semantice ale relaiei respective. Axioma integritii referinelor: n orice moment, orice referin a unei relaii la o alt relaie (sau la ea nsi) trebuie s fie integr (i.e. n orice tuplu, orice atribut ale crui valori sunt referine la ali tupli trebuie s refere un tuplu existent al bd). Axioma mulimilor vide: orice relaie trebuie s poat admite att instane vide, ct i instane non-vide.

De exemplu, se tie deja din logica matematic faptul c, n general, nici mcar aanumita problem a implicaiei nu este decidabil (vezi capitolul 4). Acest lucru implic faptul c cel puin problema minimalitii constrngerilor, dar i cea a optimalitii lor sau cea a acceptrii de instane non-vide nu sunt ntotdeauna rezolvabile. Totui, un adevrat profesionist n proiectarea bd trebuie s aib mereu n vedere mcar toate axiomele de mai sus. ncercarea de a rspunde ct mai bine cu putin la toate celelalte ntrebri alctuind enunul problemei proiectrii bd relaionale, pentru garantarea celor mai bune caracteristici posibile ale soluiilor proiectrii n raport cu aceste axiome constituie principala provocare adresat de acest capitol: modelarea conceptual a datelor n cadrul modelului relaional, precum i limitele sale. 3.7 Introducere n algebra relaional

Fi ferm n refuzul tu de a rmne contient n timpul algebrei. n viaa adevrat, te asigur, nu exist algebr. Fran Lebowitz A doua provocare n ordinea importanei pentru aceast monografie este interogarea conceptual a bd relaionale (din nou incluznd i limitele corespunztoare). Bd nu sunt utilizate doar pentru memorarea (chiar dac structurat) a datelor gestionate de aplicaii, ci, mai ales, pentru a le putea regsi, actualiza i extrage din ele informaii (e.g.: totaluri, medii, maxime, minime etc.). Ca atare, modelele de care ne ocupm includ i limbaje pentru interogarea i actualizarea datelor. Actualizrile pot fi vzute ca funcii definite pe i cu valori n mulimea strilor bd; la rndul lor, interogrile sunt funcii definite pe mulimea strilor i cu valori n spaiul relaiilor peste toate schemele posibile. Prin urmare, cele dou familii de limbaje au multe lucruri n comun. Literatura de specialitate acord ns o mult mai mare atenie limbajelor de interogare (care sunt mai complexe) dect celor de actualizare. De fapt, chiar i schema unei bd poate fi interpretat ca o colecie de ntrebri, iar coninutul ei ca pe mulimea rspunsurilor corespunztoare. De exemplu, schema bd prezentat n figura 1.1 (i formalizat relaional n exemplul 1.3) este constituit din urmtoarele patru ntrebri: 1. Care sunt codul, prenumele i numelor autorilor de interes?
36

2. Care sunt codul autorului, codul, titlul i preul crilor de interes?" 3. Care sunt codul i denumirea vnztorilor de interes? 4. Care sunt codul vnzrii, al vnztorului i al crii (la care se refer ntrebrile 2 i 3 de mai sus), precum i cantitatea (i.e. numrul de exemplare) vndute?" Desigur c rspunsul la fiecare dintre aceste ntrebri n parte este oferit de coninutul relaiilor AUTORI, VNZTORI, CRI, respectiv VNZRI. n abordrile logice ale modelrii datelor, se consider chiar c fiecare tuplu n parte constituie rspunsul la o ntrebare: de exemplu, primul tuplu al relaiei CRI din figura 1.1 este interpretat drept "Este adevrat faptul c, printre crile de interes, se numr i cea cu titlul Silogismele amrciunii, cu codul 1 i preul de vnzare 6.000, avnd autorul cu cod 1"; iar primul tuplu al relaiei VNZRI e interpretat drept "Este adevrat faptul c din cartea avnd codul 1 s-au vndut de ctre vnztorul cu codul 1 cantitatea de 670 exemplare." Pe baza acestor ntrebri i rspunsuri (fundamentale) memorate de orice bd, se pot formula n orice moment o mulime de alte ntrebri (derivate) la care rspunsul poate fi calculat. De exemplu, referindu-ne din nou la bd din figura 1.1: "Ce autor, ce cod i ce pre are cartea cu titlul Devenirea ntru fiin?"; "Exist vreo carte de autorul Gabriel Liiceanu printre cele de interes?"; "Ce titluri de cri ale autorului Mircea Eliade au fost editate i la ce preuri?"; "Cte exemplare s-au revndut n total din cartea cu titlul Convorbiri cu Regele Mihai I?"; "Care este mulimea codurilor de cri ce nu au fost revndute n cel puin 100 de exemplare?"; "Care este totalul ncasrilor vnztorului Dalles pentru crile de interes?" etc. Desigur c sunt posibile i ntrebri la care rspunsul nu poate fi calculat pornind doar de la informaiile memorate de bd, fie din lipsa unor valori, fie pentru c ntrebrile nu sunt corect sau sunt ambiguu formulate. De exemplu, considernd din nou figura 1.1, la ntrebarea "Ce pre are cartea cu titlul Pe culmile disperrii?" nu s-ar putea rspunde dect c "Momentan, nu exist nici o carte cu titlul Pe culmile disperrii printre cele despre care sunt deinute date!"; sau la ntrebarea "n ce an a fost scris cartea cu titlul De la Zalmoxis la Gingis-Han?" nu se poate rspunde dect cel mult c "Pentru nici o carte nu este memorat anul scrierii!"; n timp ce la ntrebarea "Care este codul crilor vndute ntr-o cantitate mai mare dect titlul lor?" nu se poate rspunde dect ceva de tipul "ntrebare incorect formulat, deoarece cantitile nu sunt comparabile cu titlurile!". Limbajele de interogare a datelor sunt tocmai uneltele ce permit formularea, verificarea corectitudinii i calcularea rspunsurilor la toate ntrebrile corecte posibil de derivat pe marginea oricrei bd. Dei abia volumul II se ocup n detaliu de interogri, este nevoie deja s prezentm n urmtoarea seciune cei trei operatori fundamentali ai algebrei relaionale, principalul limbaj de interogare al modelului relaional, i anume: selecia, proiecia i join-ul 19 natural. 3.7.1 Selecie Gndurile mi sunt companioni; le pot aduna laolalt, selecta, deine, alunga. Walter Savage Landor Operatorul unar de selecie este definit cu ajutorul formulelor logice ale calculului propoziional, pe care le revedem n cele ce urmeaz particularizate n context relaional.

n englez, "join" nseamn, printre altele, "a mbina/mbinare", sens care red cel mai exact n romn semnificaia avut n vedere de E.F.Codd pentru denumirea acestui operator. Am fi putut s-l traducem deci perfect prin "operatorul de mbinare a relaiilor", dar nu facem acest lucru i preferm n loc acest barbarism, ntruct "join" a intrat deja de mult n jargonul de bd. 37
19

Definiia 1.7 Fie r o relaie peste mulimea X de atribute; o formul propoziional (sau, simplu, propoziie) F peste X se definete recursiv, pornind de la atomi i folosind operatorii logicii propoziionale, astfel: Atomii peste X sunt de forma A1A2 sau A1a, unde A1, A2 X, a este o constant, iar este unul dintre operatorii de comparaie: =, , , , <, >. 20 Orice atom peste X este o formul propoziional peste X; dac F1, F2 sunt propoziii peste X, atunci (F1), (F1), F1 F2, F1 F2 sunt propoziii peste X. Nimic altceva nu este formul propoziional. O propoziie peste X poate fi privit ca fiind o funcie boolean ce asociaz fiecrui tuplu o valoare de adevr. Un atom are valoarea adevrat pentru un tuplu t dac t[A1] t[A2] (respectiv t[A1] a) este adevrat, iar n caz contrar, desigur, atomul are valoarea fals. O propoziie de forma (F) este adevrat pentru t dac i numai dac F este adevrat pentru t; o propoziie de forma (F) este adevrat pentru t d.s.n.d. F este fals pentru t. F1 F2 este adevrat pentru t d.s.n.d. att F1 ct i F2 sunt adevrate pentru t; F1 F2 este adevrat pentru t d.s.n.d. cel puin una dintre propoziiile F1, F2 este adevrat pentru t. Definiia 1.8 Fie o relaie r(X) i o propoziie F peste X; se zice selecia lui r n raport cu F i se noteaz cu F(r) relaia avnd tot schema X, dar care conine doar acei tupli din r ce satisfac F, adic: F(r) = { t r | F(t) = adevrat}. Figura 1.8 prezint un exemplu de selecie asupra relaiei VNZRI din figura 1.1 i anume formalizarea relaional a ntrebrii "Ce vnzri s-au fcut n cantiti depind 1.000?", precum i rspunsul aferent. Se observ c, n general, selecia permite formalizarea ntrebrilor de tipul "Ce tupli ai relaiei ... satisfac predicatul logic urmtor: ...?". 21 Cantitate > 1.000(VNZRI) #Vnzare Vnztor Carte Cantitate 3 1 29 2.890 5 2 29 4.770
Fig. 1.8.: Un exemplu de selecie

3.7.2 Proiecie n cele din urm, un desen nu este pur i simplu un desen, indiferent de ct de suficient n sine i este execuia. Este un simbol, i cu ct mai n profunzime se ntlnesc liniile imaginare ale proieciilor, cu att mai bine. Paul Klee Definiia 1.9 Fie o relaie r(X) i o submulime proprie Y a lui X; se zice proiecia lui r pe Y i se noteaz cu Y (r) relaia peste atributele Y ce conine restricia tuplilor lui r la atributele din Y, adic: Y (r) = { t[Y] | t r }. 22 Proiecia este, ntr-un fel, ortogonal seleciei: n timp ce proiecia ia n considerare toi tupli operandului peste o submulime a atributelor acestuia, selecia consider o submulime a tuplilor operandului peste toate atributele sale. De aceea, se mai spune c proiecia calculeaz descompuneri verticale, n timp ce selecia calculeaz descompuneri orizontale ale relaiilor.

Desigur c aceti operatori de comparaie cer ca domeniile implicate s fie mulimi ordonate, ceea ce constituie probabil o presupunere rezonabil pentru orice aplicaie: n general, bd memoreaz numere, iruri de caractere, constante logice i date calendaristice. Evident ns c, de exemplu, cel mai adesea, compararea cu alt operator dect egalitatea a coninutului sau adreselor unor fotografii, fiiere audio sau video nu are sens. 21 Evident c dac toi tupli unui coninut r satisfac F, atunci (r) este aplicaia unitate, n timp ce dac F nici unul nu o satisface, atunci coninutul calculat de acest operator este vid. 22 Evident c, pentru orice relaie r, dac Y = X, atunci este aplicaia unitate, n timp ce = . Y 38
20

Figura 1.9 prezint un exemplu de proiecie asupra relaiei VNZRI din figura 1.1 i anume formalizarea relaional a ntrebrii "Care este submulimea vnzrilor restrns la codul crii i cantitatea vndut?", precum i rspunsul aferent. #Carte, Cantitate(VNZRI) #Carte Cantitate 1 670 12 210 29 2.890 37 915 29 4.770 1 820 29 150
Fig. 1.9.: Un exemplu de proiecie

Se observ c, n general, proiecia permite formalizarea ntrebrilor de tipul "Ce tupli are relaia obinut restrngnd tupli relaiei ... la urmtoarea submulime a atributelor ei: ...?". De notat c, datorit cerinei de unicitate a tuplilor impus de definiia matematic a mulimilor, prin proiecie se pot pierde informaii n raport cu cele memorate de relaia proiectat: de exemplu, chiar dac n VNZRI ar mai fi existat i tuplul <8,2,1, 670>, rezultatul proieciei din figura 1.9 nu s-ar fi schimbat cu nimic. Evident c singurul mod n care acest tip de pierdere a informaiilor poate fi evitat este includerea unei chei (iar n cazul existenei valorilor nule, aceasta trebuie neaprat s fie cheia primar!) n lista atributelor dup care se face proiecia (vezi seciunea 2.3 i problema 86). Pentru a feri programatorii neavizai sau neateni de asemenea pierderi de informaii, majoritatea implementrilor comerciale (bazate pe limbajul SQL) nu elimin automat duplicatele din rspuns (a se vedea predicatele SQL DISTINCT i DISTINCTROW). 3.7.3 Join natural Fiecare dintre cei doi ochi poate avea viziunea sa separat; dar atunci cnd privim orice, viziunea noastr, dei n sine divizat, se mbin unitar pentru a se oferi ntreag obiectului privit. John Calvin Definiia 1.10 Fie r1(YX) i r2(XZ) dou relaii astfel nct YX XZ = X; se zice join r2 relaia definit peste natural 23 (sau simplu, join) ntre r1 i r2 i se noteaz cu r1 YXZ i care conine toi tupli (peste YXZ) ce rezult din concatenarea acelor tupli din r1 i din r2 ale cror valori pentru atributele X coincid, adic: r2 = { t peste YXZ | (t1 r1, t2 r2), t[XY] = t1[XY] t[XZ] = t2[XZ] }. r1 Definiia 1.11 Se spune c doi tupli t1r1, t2r2 sunt joinabili dac ei contribuie la formarea joinului, adic dac t1[X] = t2[X]. Dac un tuplu nu contribuie la formarea joinului, el se zice ncurc-lume (dangling n englez). Dac nici una din cele dou relaii nu conine asemenea tupli ncurc-lume, atunci se zice c rezultatul joinului lor natural este un join complet.

Vom vedea n capitolul 7 c operatorul join este mai general dect cel natural definit aici: se poate defini -joinul pentru orice operator de comparaie aplicabil domeniilor respective: de exemplu, oricare dintre =, , , , <, >. Dac este operatorul =, atunci joinul se zice echijoin. Trivial, joinul natural este un caz particular de echijoin. Mai general ns, join-ul nu este de fapt un operator fundamental, ci unul derivat din compunerea seleciei cu produsul cartezian. 39
23

Se observ c, n general, joinul natural permite formalizarea ntrebrilor de tipul "Ce tupli are relaia obinut prin concatenarea tuplilor relaiei ... cu toi tupli relaiei ... care au aceleai valori pentru atributele comune celor dou relaii?". Este interesant de remarcat faptul c definiia 1.10 are sens chiar dac X este mulimea vid (adic cele dou relaii nu au nici un atribut comun). n acest caz, orice tupli t1r1, t2r2 sunt joinabili, iar joinul natural astfel obinut este chiar produsul cartezian al celor dou relaii. 24 Join-ul se poate generaliza i pentru cazurile n care atributele din cele dou relaii nu au acelai nume, dar au domenii comparabile prin egalitate: de exemplu, r1 (XAY) A = B r2(ZBW) = { t peste XAYZW | (t1 r1, t2 r2), t[XAY] = t1[XAY] t[ZW] = t2[ZW] t1[A] = t2[B] }. Exemplul 1.9 Figura 1.10 prezint joinul (complet) dintre relaiile CRI i VNZRI din figura 1.1 pentru #Carte = Carte. Se observ, de exemplu, c primul tuplu din CRI este joinabil numai cu primul i cu penultimul dintre tuplii VNZRI. Acest join reprezint formalizarea relaional a ntrebrii "n ce cantiti au fost vndute crile de interes de ctre fiecare vnztor n parte?", precum i rspunsul aferent. Din definiia sa, rezult c joinul este, ntr-un anumit sens, inversul proieciei: aa cum se poate spune despre proiecie c genereaz descompuneri verticale, putem afirma c joinul calculeaz compuneri verticale; vom clarifica ns natura exact a dualitii ntre aceti doi operatori n subseciunea 1.7.4.1. Dup cum am afirmat nc de la nceputul acestui capitol, n modelul relaional nu exist pointeri i nici vreun alt fel de referine explicite ntre date, toate informaiile fiind memorate folosind exclusiv valori ale datelor. Drept urmare, legturile ntre relaii sunt reprezentate prin existena unor atribute semantic identice n schema relaiilor implicate, ceea ce face ca joinul natural s fie operatorul fundamental n corelarea datelor. 3.7.4 Expresii algebrice relaionale Compunnd operatorii relaionali introdui n cele trei subseciuni anterioare, se pot obine expresii de algebr relaional orict de complexe. Fcnd din nou apel la relaiile din figura 1.1, exemplificm acest lucru cu relaia din figura 1.11, descris de urmtoarea expresie relaional SPJ (Selecie-Proiecie-Join) : CRI #Carte = Carte VNZRI
#Carte 1 1 12 29 29 29 37 Autor 1 1 2 3 3 3 4 Titlu Silogismele amrciunii Silogismele amrciunii Devenirea ntru fiin Convorbiri cu Regele Mihai I Convorbiri cu Regele Mihai I Convorbiri cu Regele Mihai I De la Zalmoxis la Gingis-Han Pre 6.000 6.000 8.000 6.000 6.000 6.000 12.000 #Vnzare 1 2 3 4 5 6 7 Vnztor 1 3 1 1 2 3 1 CantiTate 670 820 210 2.890 4.770 150 915

Fig. 1.10.: Un exemplu de join natural

Evident c aceasta reprezint formalizarea relaional a ntrebrii "Ce titluri de cri au fost vndute i n ce cantiti, pentru cantiti de cel puin 1.000 exemplare?", precum i rspunsul aferent.
n plus, evident, dac Y = Z = i r1 = r2 = r, atunci r1 joinul natural este idempotent. 40
24

r2 = r

r = r, deci n aceste condiii

Titlu,Cantitate(CRI #Carte = Carte Cantitate 1.000(VNZRI)) Titlu Cantitate Convorbiri cu Regele Mihai I 2.890 Convorbiri cu Regele Mihai I 4.770
Fig. 1.11.: Rezultatul evalurii unei expresii algebrice relaionale SPJ

3.7.4.1

Expresii incluznd operatorii join i proiecie

Expresiile relaionale care includ operatorii join i proiecie se bucur de foarte multe proprieti interesante. Evident c, de exemplu, operatorul join este asociativ i comutam tiv. Ca atare, se poate scrie r2 ... rm, mN*, iar joinul poai=1 ri = r1 te fi deci considerat i ca un operator n-ar, n 1, dup cum urmeaz: date fiind r1(X1), n ..., rn(Xn), se poate defini: i=1 ri = {t[X1 ... Xn] | (t1r1,..., tnrn), t[Xi] = ti[Xi], i=1,2,...,n}. Mult mai interesante sunt ns proprietile ce clarific natura exact a dualitii existente ntre join i proiecie, despre care am amintit deja n subseciunea 1.7.3. Exemplul 1.10 Dac proiectm relaia din figura 1.10 pe atributele #Vnzare, Vnztor, #Carte, Cantitate obinem la loc relaia VNZRI. Similar, dac o proiectm pe atributele #Carte, Autor, Titlu, Pre obinem relaia CRI. De notat c aceste egaliti sunt adevrate doar n cazul joinurilor complete; n general, dac joinul nu este complet, se obin prin proiecie submulimi ale relaiilor originale ce conin toi tupli cu excepia celor ncurc-lume. Lema urmtoare (a crei demonstraie este lsat n seama cititorului vezi problema 8) arat c acest lucru nu este ntmpltor: LEMA 1.1 Fie relaiile r1(X1), ..., rm(Xm), m 1; 1. Xj( 2. Xj( 3. Xj(
m i=1ri) rj, j, 1jm. m i=1ri) = rj, j, 1jm r1, ..., rm au un join complet. m m m k=1 ( Xk( i=1ri))) = Xj( i=1ri), j, 1jm.

Primul punct al lemei stabilete c proiectnd rezultatul joinului a m relaii peste schema oricrui operand se obine o relaie inclus n acel operand. Al doilea punct precizeaz c incluziunea de mai sus devine egalitate numai n cazul joinurilor complete. Ultimul punct al lemei stabilete c operatorul compus de la primul punct este idempotent (adic aplicarea sa repetat de oricte ori produce exact acelai rezultat ca i o singur aplicare). Rezultate oarecum duale celor de mai sus pot fi demonstrate pentru expresiile ce compun n ordine invers proiecia i joinul natural (vezi problema 9): LEMA 1.2 Fie r(X) o relaie i X1, ..., Xm mulimi de atribute a.. mj=1Xj=X. 1. 2. 3.8
m i=1(Xi(r)) m k=1(Xk(

m i=1(Xi(r))))

m i=1(Xi(r)).

Descompuneri fr pierderi

Exist i o noiune dual celei de join complet:

41

Definiia 1.12 Se zice c r are o descompunere fr pierderi 25 n raport cu X1, ..., Xm m dac i=1(Xi(r)) = r, adic dac r poate fi reconstruit exact din proieciile sale. Figurile 1.12 i 1.13 prezint o asemenea decompoziie, respectiv o descompunere cu pierderi 26. r Localitate Jude Primar Prefect Sibiu Sibiu Ionescu Popescu Oradea Bihor Georgescu Popescu Localitate Sibiu Oradea

Localitate,Primar,Prefect(r)

Primar Ionescu Georgescu

Prefect Popescu Popescu Jude Sibiu Bihor

Localitate,Jude(r)

Localitate Sibiu Oradea

Jude Sibiu Bihor

Localitate,Primar,Prefect(r)
Localitate Sibiu Oradea

Localitate,Jude(r)

Primar Ionescu Georgescu

Prefect Popescu Popescu

Fig. 1.12.: Un exemplu de descompunere fr pierderi

Localitate Sibiu Oradea

Jude Sibiu Bihor

r Primar Ionescu Georgescu

Prefect Popescu Popescu Jude Sibiu Bihor Prefect Popescu Popescu

Localitate,Primar,Prefect(r)
Localitate Sibiu Oradea

Primar Ionescu Georgescu

Prefect Popescu Popescu Jude Sibiu Bihor Sibiu Bihor

Jude,Prefect(r)

Localitate,Primar,Prefect(r)
Localitate Sibiu Sibiu Oradea Oradea

Jude,Prefect(r)

Primar Ionescu Ionescu Georgescu Georgescu

Prefect Popescu Popescu Popescu Popescu

Fig. 1.13.: Un exemplu de descompunere cu pierderi

De remarcat c denumirea consacrat de descompunere cu/fr pierderi nu trebuie s induc n eroare: de fapt, nu este niciodat vorba de pierderi de informaie ci, dimpotriv, de apariia nejustificat semantic a unor informaii false. 26 De remarcat c nu coninutul, ci schema relaiilor este rspunztoare de faptul c o descompunere se face sau nu cu pierderi: n acest exemplu, datorit constrngerilor suplimentare induse de semantica funciilor f : Localitate Jude, g : Localitate Primar, h : Primar Localitate, i : Primar Prefect, j : Jude Prefect i k : Prefect Jude (unde, desigur, h = g-1, k = j-1), schema r este suprancrcat de fapt cu nelesul a dou relaii (una de localiti, iar cealalt de judee). n plus, pentru o modelare corect, acestei scheme ar trebui s-i fie evident impuse i urmtoarele patru constrngeri de tip comutativitate de diagrame de funcii (imposibil ns de exprimat n MRD): jf = ig, f h = ki, i = jf h, f = kig. 42
25

3.9

Constrngeri de integritate primitive Programarea cu ajutorul constrngerilor reprezint una dintre abordrile de pn acum ale tiinei calculatoarelor care este cea mai apropiat de Sfntul Graal al programrii: utilizatorul formuleaz problema, iar calculatorul o rezolv. Eugene C. Freuder, Constraints, 1997

Acest capitol se concentreaz asupra celor cinci tipuri de constrngeri oferite de aproape toate sistemele de gestiune a bazelor de date relaionale: domeniu, totalitate, chei, chei strine i tuplu. n modelul relaional exist i alte tipuri de constrngeri (asupra crora ne vom focaliza n capitolele urmtoare): dependene funcionale, multivaluate, join, constrngeri de existen etc. 3.9.1 Constrngeri de domeniu Vom vedea cu ocazia definirii formei normale domenii-chei (seciunea 5.4) c pn i mulimile de valori ale atributelor (domeniile n jargon relaional) joac un rol similar cu cel al constrngerilor. Definiia 2.1 Definiiile domeniilor relaionale se zic constrngeri de domeniu, iar mulimea de constrngeri asociat oricrei scheme de relaie conine, pentru fiecare domeniu al relaiei, cte o asemenea constrngere (care are forma dom(A) = DA, unde DA este mulimea tuturor valorilor admisibile pentru atributul A). De exemplu: dom(Sex) = {M,F}; dom(Validat) = {Da,Nu}; dom(AnNatere) = {n NAT(4) | 1920 n 1982}; dom(Nume) = CHAR(32) etc. Sugerm ca ele s figureze n antetul relaiilor, pe a doua linie, imediat sub numele atributelor corespunztoare, ca n figura 2.1. Abrevierile NAT(n) i CHAR(n) semnific submulimile numerelor naturale care se pot scrie cu maxim n cifre, respectiv irurilor de caractere (peste un alfabet CHAR oarecare; de obicei acesta este ANSI sau UNICODE) avnd lungime maxim n (n natural strict pozitiv). n general, SGBDR implementeaz constrngerile de domeniu folosind tipurile de date asociate atributelor, precum i aa-numitele reguli de validare. #Student autonumber 1 2 3 NSCRIERE NrMatricol Student NAT(5) CHAR(64) 32897 44135 44136 Ionescu Gabriel Georgescu Radu Vasilescu Mihai AnNatere NAT(4), >1965, <1978 1973 1966 1975

Fig. 2.1: Exemplu de precizare a constrngerilor de domeniu

3.9.2 Constrngeri de totalitate Exemplele de pn acum sugereaz faptul c orice relaie poate fi vzut ca o reprezentare a unei pri a informaiei disponibile la un moment dat ntr-o anume aplicaie de interes. Fiind ns posibil ca nu toate datele unei bd s fie cunoscute n orice moment, este rezonabil s admitem ca relaiile s poat conine i valori necunoscute. Pentru aceasta, domeniile relaiilor sunt extinse prin adugarea unei aa-numite valori nule, care se noteaz cu simbolul (sau , sau NULL, sau nimic). 27 Din considerenPentru a nu exista pericolul de confuzie cu denumirea cifrei 0, vom folosi "valori non-nule" pentru negaia valorilor nule (i nu "valori nenule", care nseamn non-zero). 43
27

te didactice, n aceast seciune vom folosi ; n general ns, le vom semnala nescriind nimic n loc.
3.9.2.1 Valori nule

Raportul ANSI [17] distinge ntre 14 tipuri de valori nule: 11 dintre acestea se datoreaz ns considerentelor de implementare sau sunt particularizri ale celorlalte 3 pentru diverse subuniversuri de interes n modelare; aceste trei tipuri generale sunt urmtoarele: valoare inexistent (inaplicabil), valoare (temporar) necunoscut i disjuncia logic a acestora, zis valoare lipsit de informaie 28 (i.e. nu se tie dac aceast valoare exist sau nu, iar n caz c ea ar exista nu se tie nimic despre natura ei). Exemplul 2.1 Fie bd din figura 2.2. Mrturiile istorice nu las loc ndoielilor cu privire la erudiia domnitorului Dimitrie Cantemir, care vorbea fluent, printre altele, att franceza, engleza, ct i rusa. Cum ns nici una dintre aceste trei limbi nu exista n zorii primului mileniu cretin, este evident c cele trei valori nule din dreptul lui Decebal au semnificaia de valoare inaplicabil. Cu toii l-am putut auzi pe M.S. Regele Mihai I vorbind englez i francez, dar niciodat rus; cum n-am ntlnit nici o referire n literatur n legtur cu acest subiect, valoarea nul corespunztoare este de tip necunoscut (temporar, deoarece chestiunea s-ar putea nc lmuri). n schimb, dei la cumpna dintre secolele XVII i XVIII toate aceste trei limbi moderne erau de mult n uz, iar Constantin Brncoveanu a fost unul dintre cei mai luminai domni romni (i nu numai), istoria nici nu ne pomenete nimic despre acest subiect i nici nu se ntrevd anse pentru viitor n acest sens; ca atare, valorile nule din dreptul su sunt lipsite de informaie. #Pers 1 2 3 4 5 Personalitate Decebal Constantin Brncoveanu Dimitrie Cantemir Mihai I POLIGLOI Englez Francez Rus

Da Da

Da Da

Da

Fig. 2.2: O relaie coninnd toate cele trei tipuri de valori nule

Pentru a evita notaii excesiv de complicate, nu vom prezenta aici definiii formale pentru aceste trei tipuri de valori nule. Schim totui n continuare formalizarea lor n logica de ordin nti (pentru cazul simplu n care un tuplu conine o singur valoare nul): date fiind o schem de relaie oarecare R(A1, A2, , An) i predicatul R asociat ei, pentru fiecare tuplu t al unui coninut r al acesteia se obine propoziia: R(t[A1], t[A2], , t[An]). Valorile temporar necunoscute pot fi tratate cu ajutorul cuantificatorului existenial: dac t are o asemenea valoare nul pentru atributul Ak, formula corespunztoare devine: x(R(t[A1], t[A2], , t[Ak-1], x, t[Ak+1], , t[An])). n cazul exemplului de mai sus: x(Poligloi(4, Mihai I, Da, Da, x)). Valorile inexistente pot fi, evident, tratate simetric folosind formule negate de tipul: x(R(t[A1], t[A2], , t[Ak-1], x, t[Ak+1], , t[An])). Acestea ns ascund ntr-un anumit sens informaia pozitiv din cele n-1 valori precizate; de aceea, o asemenea formul trebuie cuplat cu una pozitiv peste un predicat (n-1)ar, provenit tot din R dar fr Ak: R-k(t[A1], t[A2], , t[Ak-1], t[Ak+1], , t[An]). De exemplu, pentru relaia din figura 2.2, ar fi necesar urmtoarea propoziie:
De notat c acest tip de nul este folositor n special n SGBDR-urile ce permit modificarea schemelor relaiilor fr oprirea operaiilor de actualizare a instanelor acestora. 44
28

xyz(Poligloi(1,Decebal,x,y,z)) Poligloi-3-4-5(1,Decebal). n sfrit, cel mai indicat mod de a exprima lipsa complet de informaie despre valoarea unui atribut este folosirea unui predicat care s nu-l menioneze: R-k(t[A1], ..., t[Ak-1], t[Ak+1], ..., t[An]). Corespunztor, pentru exemplul de mai sus: Poligloi-3-4-5(2, Constantin Brncoveanu). Necesitatea celei de-a doua propoziii (pozitive) pentru cazul valorilor nule inexistente sugereaz faptul c tupli relaionali ncapsuleaz mai mult informaie dect cea oferit de propoziiile bazate pe predicatul R asociat relaiei respective: de fapt, pe lng informaiile asociate ntregii mulimi de atribute X a schemei R(X), orice asemenea tuplu conine i informaii despre submulimile lui X. Formalizarea acestei constatri impune, evident, introducerea mai multor simboli predicativi per relaie, i.e. cte unul pentru fiecare asemenea submulime de interes a X. Se pot astfel asocia relaiei formule cuantificate generale ce statueaz implicaia ntre fiecare predicat m-ar (corespunznd unei submulimi oarecare Y X), 1 m n, i toate predicatele (m-1)-are (corespunznd submulimilor lui Y avnd cardinalitate (m-1)): a1(...an(R(a1, ..., an) R-k(a1, ..., ak-1, ak+1, ..., an)) ...). Lsm cititorului ca exerciiu (vezi problema 3) demonstrarea faptului c propoziia corespunznd valorilor nule lipsite de informaie (R-k(t[A1], ..., t[Ak-1], t[Ak+1], ..., t[An])) este echivalent cu disjuncia formulelor asociate celorlalte dou tipuri de valori nule: x(R(t[A1], ..., t[Ak-1], x, t[Ak+1], ..., t[An])) (x(R(t[A1], ..., t[Ak-1], x, t[Ak+1], ..., t[An])) R-k(t[A1], ..., t[Ak-1], t[Ak+1], ..., t[An]).
3.9.2.2 Constrngeri de totalitate

Evident c o linie precum ultima din figura 2.2 nu poate fi interpretat inteligent nicicum; ce personalitate nu tia, sau nu avea cum s tie, sau noi n-avem cum ti dac tia vreuna din cele trei limbi? Rezult c, pentru a-i asigura acestei relaii instane acceptabile, ar trebui ca atributul Personalitate s nu admit nicicnd nuluri. Acest lucru se poate face adugnd schemei POLIGLOI o aa-numit constrngere de totalitate corespunztoare. Definiia 2.2 Fie A un atribut al unei relaii R; se noteaz A constrngerea de totalitate impunnd ca A s nu admit valori nule. 29 De exemplu, schemei POLIGLOI ar trebui s i se adauge constrngerea Personalitate. Sugerm ca toate constrngerile de acest tip s fie listate n antetul relaiilor, dup numele acestora, precum n figura 2.3. De notat c orice schem de relaie R ar trebui s aib cel puin un atribut semantic (i.e. cu excepia cheii surogat #R, care este prin definiie un atribut sintactic) care s nu admit nuluri. De obicei, acesta va fi atributul memornd numele (sau descrierea, codul etc.) obiectelor modelate de tupli relaiei. Vom vedea n seciunea 4.8.3 c totalitatea este un caz particular al constrngerilor de existen. SGBDR implementeaz constrngerile de totalitate sub numele de atribute non-nule sau obligatorii. nainte de a ncheia aceast subseciune, merit semnalat i problema nulurilor murdare, adic a irurilor de caractere care dei nu sunt nule, par a fi astfel, deoarece sunt alctuite exclusiv din caractere netipribile (de exemplu: spaiu, tab, CR/LF etc.). Unele SGBDR (de exemplu Access, dar nu i MS SQL Server!) le consider drept iruri de lungime nul i le pot interzice; evident, dac o asemenea facilitate exist, ea

29

i.e. privit ca funcie, A s fie peste tot definit i fr mbogirea codomeniului ei cu simbolul distins 45

trebuie folosit, iar n caz contrar, ea merit adugat explicit aplicaiilor de bd (ca trgaciuri). NSCRIERE NrMatricol, Student #Student NrMatricol Student AnNatere autonumber NAT(5) CHAR(64) NAT(4), >1965, <1978 1 32897 Ionescu Gabriel 1973 2 44135 Georgescu Radu 1966 3 44136 Vasilescu Mihai 1975
Fig. 2.3: Exemplu de precizare a constrngerilor de totalitate

3.9.3 Chei Cheia porii paradisului nu poate fi duplicat. Doug Horton Majoritatea atributelor trebuie s poat admite valori duplicate: de exemplu, DataNaterii i LocNatere pot memora oricte dubluri, deoarece n aceeai zi i/sau n aceeai localitate se pot nate mai multe persoane. Alte atribute ns nu trebuie s admit dect valori unice, precum, de exemplu Numeara i CodAutoInternaional, deoarece nu pot exista dou ri cu acelai nume sau acelai cod auto. Uneori, cum este cazul SerieCI i NumrCI, dei mai multe atribute admit fiecare n parte valori duplicate, produsul 30 lor nu trebuie s admit dect valori unice. Unicitatea valorilor atributelor se poate impune cu ajutorul constrngerilor de tip dependene cheie (sau simplu chei). Definiia 2.3 O submulime K a atributelor unei relaii r se zice cheie a lui r dac satisface urmtoarele dou proprieti: Identificare unic: r nu conine nici o pereche de tupli care s aib aceleai valori pentru toate atributele din K (i.e. (t1, t2), t1[K] t2[K]) Minimalitate: nici o submulime proprie a lui K nu satisface proprietatea de identificare unic. O mulime K ce satisface doar proprietatea de identificare unic se zice supercheie. 31 Evident, orice cheie este supercheie, iar orice supercheie format dintr-un singur atribut este cheie. Deoarece relaiile sunt mulimi i nu pot deci conine duplicate, mulimea tuturor atributelor oricrei relaii este supercheie. Ca atare, orice relaie are cel puin o cheie. Desigur c, n general, este posibil ca o relaie s aib mai multe chei. De exemplu, n figura 2.4 este evident (din regulile i practica domeniului aplicaiei modelate) c atributele Matricol i CodNPersonal trebuie s fie chei. #S 1 2 3 4 5 CodNPersonal 2730812400217 1751229310018 1770107200412 2790530100782 1780714500356 STUDENI Prenume Nume Matricol Mihaela Ionescu 5497 Gabriel Ionescu 8970 Ioan Gavril 9999 Irina Dumitrescu 1020 Vlad Georgescu 4850 nscriere 15.07.91 15.07.93 15.02.96 15.07.95 15.07.94

Fig. 2.4 : O relaie cu mai multe chei

Reamintim c date fiind dou funcii f : A B i g : A C, se zice produs al lor funcia fg : A B C, care asociaz xA cu perechea (f(x), g(x))= fg(x). 31 Atributele fiind funcii, o supercheie este deci un produs injectiv de funcii, n timp ce o cheie este sau o funcie injectiv sau un produs minimal injectiv de funcii. 46
30

Exemplul 2.2 Fie relaia STUDENI din figura 2.4. Evident c nu pot exista dou persoane avnd acelai cod numeric personal i deci, cu att mai mult, orice doi studeni trebuie s aib coduri personale distincte. Similar, numrul matricol asignat fiecrui student este unic n cadrul universitii. Rezult c att CodNPersonal, ct i Matricol trebuie s fie chei ale relaiei, iar aceste dou constrngeri de integritate trebuie obligatoriu adugate acestei scheme de relaie. Desigur c, de exemplu, este posibil ca, n general, s nu existe studeni nscrii simultan i avnd exact acelai prenume i acelai nume; aceasta ar putea duce la concluzia c i mulimea de atribute K = {Prenume, Nume, nscriere} constituie o supercheie (i, deoarece nici una dintre submulimile ei proprii nu ar putea identifica unic tupli relaiei, K ar fi cheie). Impunerea acestei constrngeri ns ar fi nu doar nenatural, ci i inutil de restrictiv, nepermind niciodat memorarea n bd a unor asemenea cazuri care, totui, ar putea aprea la un moment dat. De observat i c, ntmpltor, i valorile Prenume sunt distincte; evident ns c, n general, acest lucru nu poate fi adevrat. n sfrit, cheia surogat #S este prin definiie cheie. n concluzie, niciodat nu trebuie asertat vreo cheie care nu este cheie n realitatea modelat, pentru c astfel s-ar interzice coninuturi plauzibile, dar nici nu trebuie vreodat ignorat vreo cheie, cci aceasta ar avea ca efect posibilitatea memorrii de coninuturi implauzibile. SGBDR implementeaz cheile cu ajutorul fiierelor de index unici (sau fr duplicate) 32.
3.9.3.1 Chei primare

De remarcat c dac ar fi permise valori nule i pentru chei, atunci desigur c ar trebui relaxat definiia identificrii unice (n sensul restrngerii ei la tuplii ce nu au valori nule n atributele implicate n chei). Lucrul acesta ar conduce ns la unele situaii nedorite. Exemplul urmtor sugereaz c e preferabil s fie restrns permisiunea apariiei unor asemenea cazuri. Exemplul 2.3 Fie bd din exemplul 2.2, dar cu coninutul din figura 2.5, unde primul tuplu al relaiei are valori nule pentru ambele chei i, n consecin, nu poate fi identificat STUDENI CodNPersonal Prenume Nume Matricol nscriere Victor Popescu 15.07.91 1751229310018 Gabriel Ionescu 15.07.93 Irina Popa 9999 15.02.96 2790530100782 Irina Popa
Fig. 2.5 : O relaie inadmisibil cu valori nule pentru toate cheile

n nici un mod. Dac, de exemplu, am vrea s adugm relaiei nc un tuplu cu Prenume=Victor i Nume=Popescu, n-am putea ti dac acesta s-ar referi la acelai student ca i primul tuplu (ceea ce ar fi o eroare) sau nu. O problem similar apare i pentru ultimii doi tupli ai acestei relaii: dei fiecare dintre ei are o valoare non-nul pentru cte una dintre chei, nu putem
32

De remarcat c unele implementri celebre, ca de exemplu MS Access i SQL Server, nu impun cheilor i condiia de minimalitate (deci ofer doar superchei)! 47

ti dac ei se refer la studeni diferii, aa cum ar trebui s se ntmple ntotdeauna. Cea mai simpl soluie ce permite identificarea unic a fiecrui tuplu al unei relaii este aceea de a alege una dintre cheile relaiei (care se zice atunci cheie primar) i a nu permite pentru ea, niciodat, vreo valoare nul. Pentru toate celelalte chei ale relaiei ns, valorile nule pot fi permise fr restricii. Definiia 2.4 Se zice cheie primar (a unei relaii) orice cheie care nu admite nuluri. O relaie nu poate avea dect o singur cheie primar. Cheia primar este scoas n eviden prin sublinierea atributelor ce o compun, ca n exemplul din figura 2.6, unde #S a fost ales drept cheie primar. Sugerm ca toate cheile s fie listate ntr-o parantez, imediat dup numele relaiei, ca n figura 2.6. Cea mai bun practic este aceea de a dota fiecare relaie cu cte o cheie primar, iar cheile surogat s fie ntotdeauna alese drept chei primare. n concluzie, relaii precum cea din figura 2.6 nu sunt permise, n timp ce relaia din figura 2.7 sau cele din figurile 2.1, 2.3 i 2.5 sunt valide. n general ns, dac nu este explicit menionat altfel, presupunem n cele ce urmeaz c relaiile au doar valori nonnule. STUDENI (#S, CodNPersonal, Matricol) Matricol #S CodNPersonal Prenume Nume Matricol nscriere 1 Victor Popescu 7432 15.07.91 Irina 9999 15.02.96 2 3 2790530100782 Irina Popa 9305
Fig. 2.6: O relaie cu valori nule, dar nu i n cheia primar

De notat c orice relaie trebuie s aib cel puin dou chei: cea primar i cel puin una semantic. ntr-adevr, fie de exemplu relaia din figura 2.7: analiznd ultimii ei doi tupli rezult c nu pot exista dect urmtoarele dou cazuri: Este vorba despre doi autori distinci, avnd acelai nume i prenume; n acest caz, schema relaiei trebuie mbogit cu cel puin un alt atribut care s permit identificarea unic a tuturor autorilor (de exemplu, DataNaterii). Este vorba despre acelai autor, caz n care schema relaiei trebuie completat cu cheia PrenumeNume, care s nu permit duplicarea perechilor (nume, prenume). AUTORI (#Autor) Prenume, Nume Nume #Autor Prenume 1 Lucian Blaga 2 Emil Cioran 3 Mircea Ciobanu 4 Mircea Eliade 5 Mircea Eliade
Fig. 2.7 : O relaie invalid din cauza lipsei unei chei semantice

3.9.3.2

Algoritmul de asisten a proiectrii cheilor

Mreia artei nu rezid n gsirea a ceea ce este comun, ci a ceea ce este unic. Isaac Bashevis Singer Cheile sunt cele mai importante constrngeri de integritate din schema oricrei relaii. Identificarea i includerea tuturor constrngerilor, deci n particular a tuturor cheilor, n schema oricrei bd este crucial pentru modelarea corect a oricrui subunivers de interes.
48

La fel ca n cazul oricrui alt tip de constrngeri, numai inteligena uman poate s identifice cheile: nu poate exista nici un algoritm sau dispozitiv hardware care s poat decide, de exemplu, dac nlimea persoanelor, Capitala rilor sau produsul SerieCI NumrCI (pentru crile de identitate) sunt sau nu chei. Datorit complexitii problemei depistrii cheilor, este foarte util recursul la un algoritm de asisten. nainte de a-l prezenta, sunt ns necesare cteva consideraii preliminare. Pentru tot restul acestei subseciuni, fie R o relaie oarecare cu n+1 atribute A0=#R, A1, ..., An, n>0 natural, din care n semantice (al n+1-lea fiind cheia surogat). Propoziia 2.1 Nu pot exista mai mult de 2n-2 chei semantice. Demonstraie: Evident c toate Ai, 1 i n, pot fi chei, dup cum i orice produs de dou atribute Ai Aj sau de trei Ai Aj Ak sau ... sau produsul tuturor celor n atribute pot fi chei. Numrul total de produse de atribute este evident: Cn0 + Cn1 + ... + Cnn = 2n; desigur ns c mulimea vid (corespunznd Cn0) nu poate fi cheie; mai mult, produsul tuturor celor n atribute nu poate fi cheie dect singur (cci dac mai exist vreo alt cheie, el nu mai este minimal injectiv), deci putem elimina i Cnn (n acest caz numrul cheilor fiind 1). Q.e.d. Corolar 2.2 Procesul de depistare a cheilor poate ncepe cu atributele i se poate ncheia cu produsele de maxim n - 1 atribute. Demonstraie: Evident din propoziia 2.1, cci nu are rost s ne ntrebm nici dac mulimea vid este cheie i nici dac ntreg produsul A1...An este cheie: dac s-a gsit deja cel puin o cheie pn la pasul n - 1, atunci A1...An nu poate fi cheie (cci e injectiv, dar nu minimal); n caz contrar, A1...An trebuie s fie cheie (altfel instanele R n-ar mai fi mulimi). Q.e.d. n Propoziia 2.3 Nu toate cele 2 -2 combinaii posibile pot fi simultan chei. Demonstraie: Fie Ai cheie, 1 i n; conform definiiei, nici un produs de atribute incluznd Ai nu mai poate fi cheie (cci, dei injectiv, el nu este minimal injectiv); similar, dac un produs oarecare de k atribute, 1 < k < n, este cheie, atunci nici un produs de atribute ce include produsul celor k nu poate fi cheie. Q.e.d. Teorema 2.4 Numrul maxim de chei semantice este Cn[n/2]. Demonstraie: Numim lan de lungime n alctuit din produse de atribute o secven M1 M2 Mn-1 A1...An cu proprietatea c Mi= i, oricare ar fi i=1, 2,, n-1 (adic Mi are i atribute); evident, numrul de lanuri de lungime n ce pot fi construite cu n atribute este n!. Fie X un produs de r atribute,X= r, 0 < r < n; numrul de lanuri de lungime n ce includ X i au forma M1 Mr-1 X Mr+1 . A1...An este egal cu r!(n-r)!. Fie 1 i, j n, i j; prin definiie, Xi i Xj pot fi simultan chei dac i numai dac Xi Xj i Xj Xi. Evident c dac Xi i Xj nu sunt comparabile prin incluziune, atunci orice lan incluznd Xi este diferit de orice lan incluznd Xj. Notnd cu p numrul de chei posibile simultan i cu ni =Mi, rezult c p p 1 p n ni !(n ni )! n!. Cum max C n i = Cn[n/2], rezult c ni 1 [n/2 ] 1 ni n Cn i =1 i =1 c max p Cn[n/2].
n

Invers, considernd familia submulimilor A1, ..., An avnd m= [n/2] elemente, se demonstreaz uor c max p Cn[n/2]. n consecin, rezult c max p = Cn[n/2]. Q.e.d. Propoziia 2.5 Dac toate produsele de atribute de lungime i sunt superchei, 0 < i < n, atunci i toate produsele de lungime i + 1 sunt superchei.
49

Demonstraie: Presupunem prin absurd c exist un produs de lungime i + 1, Mi+1 = Aj0...Aji, care nu este injectiv; din ipotez, tim c Aj1...Aji este injectiv; conform unui rezultat elementar, produsul funciei Aj1...Aji cu funcia Aj0 rmne injectiv, deci presupunerea este fals. Q.e.d. Corolar 2.6 Dac generarea produselor de atribute se face cresctor (n raport cu lungimea lor) i dac la pasul i al generrii, 0 < i < n, se obin doar superchei, atunci procesul cutrii cheilor se poate opri la pasul i. Demonstraie: Evident din propoziia 2.5, nlocuind recursiv pe i + 1 cu j i aplicnd principiul induciei finite. Q.e.d. Rezultatele de mai sus ne permit proiectarea algoritmului din figura 2.8. Algoritm 2.7 (asistena proiectrii cheilor unei relaii) Intrare: Mulimea atributelor semantice A1, ..., An ale unei relaii R. Ieire: Mulimea cheilor R, KR . Strategie: KR = ; k = 0; // iniializarea mulimii cheilor i a cardinalului ei i = 1; // iniializare cardinal produse DoarSuperchei = false; // produsul vid nu este injectiv repet ct timp i < n i k < Cn[n/2] i not DoarSuperchei genereaz toate 0 j Cni produse de i atribute Pj care nu sunt superchei; dac j = 0 atunci DoarSuperchei = true; altfel l = 1; repet ct timp l j i k < Cn[n/2] ntreab utilizatorul dac produsul Pl este minimal injectiv; dac rspunsul este afirmativ atunci k = k + 1; KR = KR { Pl }; sfrit dac; l = l + 1; sfrit repet; sfrit dac; i = i + 1; sfrit repet; dac k = 0 atunci // nu s-a gsit nici o cheie A1...An trebuie k = 1; // s fie cheie KR = { A1...An }; sfrit dac; Sfrit Algoritm 2.7.
Fig. 2.8.: Algoritmul de asistena proiectrii cheilor unei relaii

Exemplul 2.4. S aplicm algoritmul 2.7 asupra relaiei din figura 2.9 (n = 5, Cn[n/2] = 5!/(3!*2!) = 10): JUDEE (#J, Reedina, Judeara, araPrefixTel, araCodAuto) Jude, ara #J Jude ara PrefixTel CodAuto Reedina autonr CHAR(32) NAT(3) NAT(4) CHAR(8) NAT(6) 1 Bucureti 1 21 B 1 2 Constana 1 241 CT 2
Fig. 2.9.: Cheile tabelei JUDEE

i = 1 (k = 0, DoarSuperchei = false):
50

Jude? nu este cheie deoarece n ri diferite pot exista judee cu acelai nume; ara? nu este cheie deoarece o ar are mai multe judee; PrefixTel? nu este cheie deoarece judee din ri diferite pot avea acelai prefix telefonic; CodAuto? nu este cheie deoarece judee din ri diferite pot avea acelai cod automobilistic; Reedina? este cheie deoarece o aceeai localitate nu poate fi simultan reedina a dou sau mai multe judee: KR = {Reedina}; - i = 2 (k = 1, DoarSuperchei = false): Judeara? este cheie deoarece ntr-o aceeai ar nu pot exista dou sau mai multe judee cu acelai nume: KR = {Reedina, Judeara}; JudePrefixTel? nu este cheie deoarece n ri diferite pot exista dou sau mai multe judee cu acelai nume i acelai prefix telefonic; JudeCodAuto? nu este cheie deoarece n ri diferite pot exista dou sau mai multe judee cu acelai nume i acelai cod automobilistic; araPrefixTel? este cheie deoarece ntr-o aceeai ar nu pot exista dou sau mai multe judee cu acelai prefix telefonic: KR = {Reedina,Jude ara,araPrefixTel}; araCodAuto? este cheie deoarece ntr-o aceeai ar nu pot exista dou sau mai multe judee cu acelai cod automobilistic: KR = {Reedina, Judeara, araPrefixTel, araCodAuto}; PrefixTelCodAuto? nu este cheie deoarece n ri diferite pot exista dou sau mai multe judee cu acelai cod automobilistic i acelai prefix telefonic. De remarcat c orice produs coninnd Reedina este supercheie, deci nici mcar nu mai este generat. - i = 3 (k = 4, DoarSuperchei = false) JudePrefixTelCodAuto? nu este cheie deoarece n ri diferite pot exista dou sau mai multe judee cu aceleai nume, cod automobilistic i prefix telefonic. De remarcat c toate celelalte produse sunt superchei, deci nici mcar nu mai sunt generate. - i = 4 (k = 4, DoarSuperchei = false) Toate produsele sunt superchei, deci nici mcar nu mai sunt generate (iar DoarSuperchei = true). n concluzie, deoarece se iese din bucla extern cu k=4, KR={Reedina,Judeara,araPrefixTel,araCodAuto}. Teorema 2.8 (caracterizarea algoritmului 2.7) Algoritmul 2.7 are urmtoarele proprieti: (i) complexitate O(2n) (ii) este complet (iii) este solid (iv) este optim Demonstraie: (i) complexitate O(2n): nti i nti, n mod trivial, algoritmul nu bucleaz la infinit: n cel mai ru caz, n care produsul tuturor celor n atribute este unica cheie, el va trebui s analizeze, conform propoziiei 2.1, toate cele 2n 2 produse de atribute candidate; rezult deci evident i c 2n este complexitatea sa.
51

(ii) completitudine: cum mulimea cheilor este inclus n cea a atributelor i a produselor lor, iar algoritmul inspecteaz fiecare element al acestei mulimi cu excepia doar a supercheilor (ce nu pot fi chei prin definiie), rezult c algoritmul genereaz toate posibilele chei. (iii) soliditate: cum algoritmul elimin chiar din generare orice supercheie nainte de a o supune ateniei utilizatorului, toate atributele i produsele lor pentru care utilizatorul rspunde afirmativ la ntrebarea asupra minimal injectivitii lor sunt chei. (iv) optimalitate: cum algoritmul elimin toate supercheile din generare, iar dac toate rspunsurile au fost negative genereaz automat unica cheie posibil, rezult c numrul de ntrebri pe care le pune algoritmul utilizatorului este minimum cu putin. Q.e.d. De remarcat c algoritmul 2.7 nu poate evident garanta dect corectitudinea sintactic a cheilor, nu i pe cea semantic: aceasta din urm trebuie asigurat de proiectantul de bd ce l utilizeaz. Evident c, din pcate, nu este posibil gsirea unui algoritm mai performant dect 2.7, cci nici un proiectant n-ar trebui s-i poat permite s ignore vreo cheie. Din fericire, numrul de atribute al relaiilor este n general foarte mic, iar performanele actuale ale calculatoarelor uzuale sunt suficient de mulumitoare, astfel nct timpul maxim de ateptare al utilizatorului ntre dou ntrebri succesive s fie deja sensibil mai mic dect timpul mediu de reflecie necesar pentru a rspunde la ntrebri. De reinut i c aplicarea algoritmului 2.7 exact ca n exemplul 2.4 (adic trecnd ordonat n revist n scris toate posibilitile i justificnd n cazul fiecreia de ce este luat sau nu n considerare, precum i de ce, atunci cnd este luat, rspunsul corespunztor este afirmativ sau negativ) ar trebui s constituie un standard obligatoriu de proiectare i documentare a proiectrii cheilor, echivalent cu o demonstraie formal a corectitudinii mulimii cheilor gsite; n plus, aceast documentaie poate constitui i una din bazele de discuie, negociere i validare a schemei bd ntre proiectant i beneficiar.
3.9.4 Chei strine

Interdependendena urmeaz independenei. Stephen R. Covey n figura 2.9, conform principiului propagrii cheilor, este evident c schema bd include cel puin nc dou alte relaii, ARI i LOCALITI, iar schema relaiei JUDEE trebuie s satisfac i constrngerile ara #ara, respectiv Reedina #Localitate. n aceast seciune vom vedea c acest lucru nu este deloc ntmpltor: fiecrei chei propagate conform acestui principiu trebuie s-i corespund o constrngere de tip dependen de incluziune.
3.9.4.1 Dependene de incluziune

Cel mai interesant tip de constrngeri interrelaionale este constituit de dependenele de incluziune (DIN). Acestea sunt folosite n modelul relaional pentru a exprima incluziunea ntre proiecii ale relaiilor. Pentru simplitate, prezentm deocamdat doar un caz special de asemenea dependene. Definiia 2.5 Dat fiind o schem R = {R1(X1), R2(X2),..., Rn(Xn)}, o dependen tipat de incluziune (DTIN) se noteaz Ri[Y] Rj[Y], unde Y Xi Xj, 1 i, j n. Ea este satisfcut de o bd r = {r1, r2, ..., rn} a lui R dac Y (ri) Y (rj) 33. Exemplul 2.5 Fie o bd avnd schema R = {R1(#Autor, Prenume, Nume), R2(#Carte, Carte, Autor)}, n care prima relaie memoreaz mulimea autorilor, iar cea de-a doua memoreaz mulimea crilor (de interes) scrise de ace33

n termeni funcionali, constrngerea aceasta s-ar scrie Im(Ri[Y]) Im(Rj[Y]), unde f : A B, Im(f)={yB | xA, f(x)=y} B, zis imaginea lui f, este mulimea tutror valorilor lui f. 52

tia. Este natural impunerea cerinei ca, n a doua relaie, pentru a se putea meniona, tipri, clasifica etc. autorul fiecrei cri, acesta s figureze printre cei din prima relaie. Evident c DTIN R2(Autor) R1(#Autor) exprim exact aceast constrngere. Se poate uor verifica c bd din figura 2.10 satisface aceast DTIN, n timp ce bd din figura 2.11 nu o satisface. n jargon relaional, se mai zice i c dependenele de incluziune definesc chei strine.
3.9.4.2 Chei strine

Cheia universului tu este faptul c poi alege. Frederick Carl Friseke Definiia 2.6 O submulime X a atributelor unei relaii r1 se zice cheie strin (a lui r1, din r2), dac mulimea valorilor tuplilor din r1[X] este inclus n mulimea valorilor pentru o cheie (primar sau nu a) unei relaii r2. De notat c nu este neaprat ca r1 r2. Cheile strine furnizeaz principalul mijloc de a lega ntre ei tupli din relaii diferite sau dintr-o aceeai relaie. Din considerente de optimalitate, aa cum am vzut deja n seciunea 1.5, se recomand ca ntotdeauna cheile strine s fie incluse n chei primare surogat. Exemplul 2.6 Fie bd din figura 1.1, unde cheile primare sunt #Autor, #Carte, #Vnztor, respectiv #Vnzare; evident mai exist urmtoarele chei: PrenumeNume, Vnztor, AutorTitlu i VnztorCarte. n relaia VNZRI, atributul Carte este cheie strin (cci valorile sale trebuie s fie mereu incluse printre cele ale cheii primare #Carte din relaia CRI). Acest lucru nu este, desigur, ntmpltor, cci tocmai (i numai!) valorile acestui atribut identific unic n VNZRI titlurile de cri vndute de fiecare vnztor n parte. Similar, evident, acelai lucru este valabil i pentru Vnztor, ca i pentru Autor din relaia CRI. r1 #Autor Prenume Nume 1 Lucian Blaga 2 Emil Cioran 3 Mircea Ciobanu 4 Mircea Eliade #C 1 2 3 4 5 6 r2 Carte Eonul dogmatic Cunoaterea luciferic Cenzura transcendent Noi convorbiri cu Regele Mihai I al Romniei Regele Mihai i exilul romnesc Erotica mistic n Bengal Autor 1 1 1 3 3 4

Fig. 2.10.: O baz de date ce satisface DTIN R2(Autor) R1(#Autor)

De notat c denumirea de cheie strin este parial justificat de principiul propagrii cheilor: un asemenea atribut (sau produs de atribute) provine prin propagarea unei chei a unei tabele. Epitetul strin se datoreaz faptului c, n general, este referit o cheie a unei alte tabele; acest lucru nu este ns obligatoriu, cci o cheie strin poate re53

feri propria-i tabel: de exemplu, n figura 2.12, Printe este o cheie strin obinut prin propagarea #Dir. #Autor 1 2 3 #C 1 2 3 4 5 6 r1 Prenume Lucian Emil Mircea r2 Carte Eonul dogmatic Cunoaterea luciferic Cenzura transcendent Noi convorbiri cu Regele Mihai I al Romniei Regele Mihai i exilul romnesc Erotica mistic n Bengal Autor 1 1 1 3 3 4 Nume Blaga Cioran Ciobanu

Fig. 2.11.: O baz de date ce violeaz DTIN R2(Autor) R1(#Autor)

DIRECTOARE (#Dir, PrinteDirector) Director, Printe #Dir #Dir Printe Director autonumber NAT(8) CHAR(256) 1 \ 2 1 WINDOWS 3 2 system32 4 2 system
Fig. 2.12.: Un exemplu de cheie strin referind propria-i tabel

A nu se face ns nicicnd confuzia ntre o cheie strin i o cheie: o cheie strin poate fi i cheie (precum Reedina din figura 2.9), dar n general ea nu este cheie (vezi, de exemplu, Autor, Carte, Vnztor din figura 1.1, ara din figura 2.9, Autor din figurile 2.10 i 2.11, precum i Printe din figura 2.12 care nu sunt nici una chei). Fiecrei chei strine trebuie s-i fie asociat dependena de incluziune corespunztoare. Sugerm ca notaia pentru aceste constrngeri s fie similar celei folosite n figura 2.12: se adaug n antetul tabelei, imediat dup constrngerile de totalitate, cte o incluziune pentru fiecare cheie strin. SGBDR implementeaz cheile strine tot cu ajutorul fiierelor index. Unele dintre ele permit i definirea, modificarea, tergerea i vizualizarea grafic a legturilor ntre tabele realizate prin chei strine (folosind diagrame de legturi). Impunerea dependenelor de incluziune aferente se mai numete i forarea integritii referinelor. n coninuturile ce violeaz integritatea referinelor (deci cel puin o dependen de incluziune), valorile oricrei chei strine ce nu corespund nici unei valori din cheia referit (precum valoarea 4 din coloana Autor a ultimei linii din tabela r2 a figurii 2.11) se zic pointeri zbuci (dangling pointers n englez) 34. De notat i faptul c impunerea integritii referinelor se poate face n mai multe moduri pentru fiecare dintre cele trei tipuri de operaii de actualizare a datelor: inserare, modificare, tergere.

34

De notat c n multe SGBDR, precum MS Access i SQL Server, impunerea integritii referinelor trebuie cerut explicit, cci ea nu face parte din standardul implicit! 54

Pentru inserarea unui rnd, se poate impune o ordine de inserare: n figura 2.9 de exemplu, nainte de a putea insera un jude dintr-o ar inexistent n tabela RI, trebuie inserat ara respectiv n RI. Alternativ ns, se pot face simultan inseriile n cele dou tabele dac actualizarea datelor se face nu direct n ele, ci ntr-un join al lor. Un alt avantaj major al referirii exclusiv la chei surogat cu autonumrare este eliminarea necesitii de a ne mai preocupa de modificrile valorilor referite: valorile acestora nu pot fi modificate niciodat. n cazul n care ns o cheie strin refer altceva dect o cheie cu autonumrare, pentru a impune integritatea referinelor trebuie s cerem explicit cascadarea modificrilor (adic propagarea lor automat la toate cheile strine implicate). Pentru tergerea unui tuplu este ntotdeauna preferabil interzicerea ei dac acel tuplu este referit de ali tupli: n figura 1.1, de exemplu, tentativa de tergere a oricrui tuplu din AUTORI trebuie respins, cci toi sunt referii de cte un tuplu din CRI. Alternativa cascadrii tergerilor nu ar trebui niciodat folosit dect la cererea expres a utilizatorilor bd, deoarece ea este extrem de periculoas, putnd conduce foarte uor la pierderea datelor din erori de operare: n figura 1.1 de exemplu, ntr-un asemenea scenariu, tergerea celui de-al treilea tuplu al primei tabele (corespunznd scriitorului Mircea Ciobanu) ar avea drept efect i tergerea automat al celui de-al treilea tuplu din a doua tabel, precum i a celor trei tupli corespunztori (3, 5 i 7) din ultima. Unele SGBDR (de exemplu MS Access) ofer un instrument puternic (lookup wizard) pentru gestionarea actualizrii valorilor cheilor strine: acestea pot fi implementate ca liste derulante (combo boxes) din care se pot alege doar valorile existente n cheia referit, iar acestea pot fi ascunse utilizatorului i nlocuite cu orice cheie semantic a tabelei referite. Atunci cnd aceast facilitate nu este oferit, ea merit implementat de aplicaiile construite peste bazele de date respective.
3.9.5 Constrngeri tuplu

Sintaxa i vocabularul sunt constrngeri copleitoare - reguli ce ne conduc. Limbajul ne folosete atunci cnd vorbim credem c noi suntem cei care l folosete, dar de fapt limbajul gndete, iar noi suntem sclavii si. Harry Mathews Ultima clas de constrngeri fundamentale este format din constrngerile tuplu. Acestea sunt exprimate cu ajutorul formulelor propoziionale ce au fost introduse n subseciunea 1.7.1, cu restricia c exist o unic variabil, implicit cuantificat existenial (care, de obicei, se i omite, deoarece nu exist nici un pericol de ambiguitate). Nu exist nici o definiie unanim acceptat mcar teoretic pentru acest tip de constrngeri; mai mult, adesea ele sunt confundate cu cele de domeniu: de exemplu, o bun parte a literaturii de specialitate folosete pentru ilustrare exemple precum CantStoc 0 sau Salariu > 0, care fac parte de fapt din constrngerile de domeniu ce trebuie asociate atributelor respective. Implementrile curente n SGBDR comerciale ofer posibilitatea de a folosi pentru fiecare astfel de constrngere doar atributele unei singure relaii (ceea ce exclude constrngerile tuplu interrelaionale). Exemplul 2.7 Fie relaia din figura 2.13; o constrngere evident ar fi aceea c, pentru orice angajat, salariul net trebuie s fie cel mult egal cu salariul brut. Putem exprima formal aceast restricie cu ajutorul constrngerii tuplu: SalariuNet SalariuBrut. Evident, predicatul asociat ar fi urmtorul: (tsalarii)(t[SalariuNet] t[SalariuBrut]). Trivial, relaia din figura 2.13 satisface aceast constrngere, n timp ce relaia din figura 2.14 nu o satisface, din cauza celui de-al doilea tuplu al ei.
55

Sugerm ca toate constrngerile tuplu ale unei relaii s fie menionate tot n antetul schemei sale, dup dependenele de incluziune, ca n figura 2.13. SALARII (#A, Matricol, Persoana) Matricol, Persoana, Persoana #Persoane, SalariuNet SalariuBrut #A Matricol Persoana SalariuBrut SalariuNet auto NAT(4) NAT(4) NAT(12) NAT(12) 1 101 1 500.000 400.000 2 102 2 650.000 450.000 3 103 3 480.000 385.000
Fig. 2.13.: O relaie satisfcnd constrngerea tuplu din exemplul 2.7

SALARII (#A, Matricol, Persoana) Matricol, Persoana, Persoana #Persoane #A Matricol Persoana SalariuBrut SalariuNet auto NAT(4) NAT(4) NAT(12) NAT(12) 1 101 1 500.000 400.000 2 102 2 650.000 750.000 3 103 3 480.000 385.000
Fig. 2.14.: O relaie violnd constrngerea tuplu din exemplul 2.7

3.9.6 Constrngeri primitive

Definiia 2.7 O constrngere se zice primitiv dac ea este de tip domeniu, totalitate, cheie, incluziune sau tuplu.
3.10 Traducerile DEA n MRD i MRD n DEA

Fcnd abstracie de sgei, corespondena ntre DEA i MRD este imediat: fiecrui tip de entiti sau de asociaii i facem s-i corespund o tabel avnd drept coloane toate elipsele ataate tipului respectiv. Pentru sgei, se folosete principiul propagrii cheilor.
3.10.1 Implementarea principiului propagrii cheilor

Pentru tipurile de asociaii binare funcionale (i.e. de tip 1-la-n, adic funcii matematice) putem elimina din schem tabela corespunztoare dac adugm la tabela tipului etichetat cu n cheia surogat a tipului etichetat cu 1, conform principiului propagrii cheilor a crui formalizare este dat n subseciunea 5.3.7. Evident c, pentru a menine integritatea referinelor, mai este suplimentar necesar adugarea la schema relaional a constrngerii de tip incluziune asupra cheii strine astfel introduse (prin propagare) n valorile cheii surogat a relaiei corespunztoare tipului etichetat cu 1. Exemplul 2.3 Pentru fragmentul DEA din figura 2.5 incluznd doar tipurile de entiti CLIENI, LOCALITI i tipul de asociaii SEDIU-CLIENT, n locul schemei relaionale corespunztoare din figura 2.10 se obine schema simplificat echivalent din figura 2.11. De notat c acesteia din urm a trebuit s i se adauge constrngerea de tip incluziune SediuClient #Loc.
3.10.2 Algoritmul de traducere a DEA n scheme relaionale

Traducerea DEA n scheme relaionale se face conform algoritmului 2.1 prezentat n figura 2.12. Se observ c schemele relaionale astfel obinute conin doar tabele i atribute, nu i constrngeri. Aceasta se ntmpl deoarece puterea expresiv a MEA este mai mic dect cea a MRD: dependenele de incluziune sunt ncorporate implicit n
56

DEA, iar n unele dintre variantele sale se pot specifica i cheile primare, constrngerile de existen i chiar domeniile atributelor, dar nu i celelalte dou tipuri de constrngeri CLIENI (#Client, Denumire) LOCALITI(#Loc, Denumire) #Client Denumire #Loc Denumire 1 IER 1 Paris 2 DMS 2 Baug 3 DATASIS 3 Bucureti SEDIU-CLIENT(#Client) #Client #Loc 1 1 2 2 3 1
Fig. 2.10 Schema relaional corespunztoare unui fragment al DEA din figura 2.5 i un posibil coninut valid al ei

LOCALITI (#Loc, Denumire) #Loc Denumire 1 Paris 2 Baug 3 Bucureti CLIENI (#Client, Denumire) Sediu_Client #Loc #Client Denumire Sediu_Client 1 IER 1 2 DMS 2 3 DATASIS 1
Fig. 2.11 Schema relaional obinut din figura 2.10 dup propagarea cheii #Loc

fundamentale ale modelului relaional, cheile i constrngerile tuplu. De aceea, pentru a obine o schem relaional complet, dup aplicarea acestui algoritm mai este necesar cel puin un pas de proiectare n care s fie specificate i aceste constrngeri. Din aceast cauz, nu am complicat DEA nici cu domeniile atributelor, cheile primare i constrngerile de existen. Exemplul 2.4 Traducerea DEA din figura 2.13 conform algoritmului 2.1 are ca rezultat schema relaional din figura 2.14. Se observ c lipsesc din ea nu doar toate dependenele de domeniu i constrngerile de existen, ci i cheile Client, FacturaDocP, DataFNrF i DataDocPNrDocP, precum i constrngerea tuplu Beneficiar Pltitor. De remarcat c, pentru a putea garanta numai coninuturi plauzibile, pe lng aceste constrngeri ar mai trebui adugat nc una (de tip comutativitate generalizat, vezi ultimul capitol): pltitorul oricrei pli trebuie s fie ntotdeauna clientul cruia i s-a emis factura achitat de plata respectiv. Din nefericire, asemenea tipuri de constrngeri nu pot fi formalizate n MRD, iar impunerea lor se poate face doar cu ajutorul procedurilor de tip trgaci ale aplicaiilor gestionnd bd relaional. Teorema 2.2 (i) Algoritmul 2.1 este liniar (ii) Aplicaia definit de algoritmul 2.1 este surjectiv (iii) Aplicaia definit de algoritmul 2.1 nu este injectiv
57

Algoritmul 2.1 (traducerea DEA n MRD): Intrare: o DEA Ieire: schema relaional corespunztoare Program abstract: repet pentru fiecare dreptunghi al DEA genereaz o tabel cu numele tipului de entiti corespunztor repet pentru toate elipsele ataate dreptunghiului curent adaug tabelei cte un atribut cu numele corespunztor sfrepet; declar cheia surogat drept cheie primar sfrepet; // traducere dreptunghiuri repet pentru fiecare romb al DEA (de jos n sus n cadrul ierarhiilor de asociaii) genereaz o tabel cu numele tipului de asociaii corespunztor repet pentru toate dreptunghiurile i romburile ataate rombului curent adaug tabelei cte un atribut cheie strin cu numele corespunztor (neadmi nd valori nule) i cte o dependen de incluziune a crei parte stng este cheia strin, iar cea dreapt cheia primar a tabelei corespunznd dreptunghiului/rombului curent sfrepet; repet pentru toate elipsele ataate rombului curent adaug tabelei cte un atribut cu numele corespunztor sfrepet; declar cheia surogat drept cheie primar sfrepet; // traducere romburi repet pentru fiecare sgeat a DEA adaug tabelei corespunztoare dreptunghiului/rombului din care pleac sgeata un nou atribut (cheie strin) cu numele etichetnd sgeata i o dependen de incluziune a crei parte stng este noua cheia strin, iar cea dreapt cheia primar a tabelei corespunznd dreptunghiului/rombului n care ajunge sgeata sfrepet; // traducere sgei (cf. principiului propagrii cheilor) sfalgoritm 2.1;
Fig. 2.12 Algoritmul de traducere a DEA n scheme relaionale

Demonstraie: (i) Trivial, cci algoritmul 2.1 este finit, nu bucleaz niciodat la infinit i depinde doar de cardinalul DEA (i.e. numrul de dreptunghiuri + cel de romburi + cel de sgei + cel de elipse). (ii) Fie S = {R1(A11,, A1k1),, Rn(An1,, Ankn)} o schem relaional oarecare avnd ataat o mulime de dependene de incluziune I ={dijkl: Aij Akl | AijRiS, AklRkS}; pentru fiecare schem de relaie Ri din S construim un dreptunghi etichetat Ri, cruia i atam, pentru fiecare atribut Aij al Ri, cte o elips etichetat cu numele acestuia; n sfrit, pentru fiecare dependen de incluziune dijkl din I, ducem o sgeat de la Ri la Rk, etichetat cu dijkl. (iii) Fie DEA din figura 2.15 (evident modelnd alternativ acelai subunivers ca i cea din figura 2.13, cu diferena c ACHITRI este considerat i el un tip de entiti i nu unul de asociaii). Aplicnd algoritmul 2.1 asupra acestei DEA se obine, evident, exact schema relaional din figura 2.14 Q.e.d. Tot n ultimul capitol se caracterizeaz formal i natura acestei dualiti (care provine din echivalena puterilor expresive ale MEA i Modelul Funcional al Datelor).

58

#C NrF ClientF

CLIENI Beneficiar

Client Pltitor NrDocP

#F

FACTURI

ACHITRI

PLI

#P

DataF

TotalF

#A

Plata

DataDocP

Suma

Fig. 2.13 Un exemplu simplu de DEA care utilizeaz ns toate conceptele MEA

#F 1 2 3

FACTURI (#F) ClientF #C DataF NrF TotalF ClientF 01.10.2002 45321 5.200 1 01.10.2002 45322 2.500 2 01.11.2002 45330 5.200 1

ACHITRII (#A) Factura #F, DocP #P #A Factura DocP Plata 1 1 1 5.200 2 2 1 5.200 3 3 2 1.500 CLIENI (#C) #C Client 1 IER 2 DMS 3 DATASIS PLI (#P) Beneficiar #C, Pltitor #C DataDocP NrDocP Suma Pltitor 30.11.2002 320 10.400 1 01.12.2002 45322 1.500 2

#P 1 2

Beneficiar 3 3

Fig. 2.14 Schema relaional corespunztoare DEA din figura 2.13 obinut conform algoritmului 2.1 i un posibil coninut valid al ei

3.10.3 Algoritmul de traducere a schemelor relaionale n DEA

Traducerea schemelor relaionale n DEA se poate face foarte uor, conform algoritmului cerut de problema 110.
3.11 Forma normal Boyce-Codd

Raiunea este substana universului, proiectul lumii este absolut raional. Hegel Forma normal 1, chiar dac completat cu constrngeri de integritate fundamentale, nu este ndeobte mulumitoare. Exemplul urmtor demonstreaz faptul c sunt necesare standarde de proiectare a bd mult mai nalte.
59

Exemplul 3.1 Fie bd electoral referitoare la alegerile locale (deja prezentat n figurile 2.12 i 2.13) i fie relaia ALEGERI din figura 3.1. Pe lng mprirea teritorial-administrativ uzual n localiti i judee, pentru alegeri ara este mprit pe circumscripii electorale; niciodat o circumscripie electoral nu reunete localiti din judee diferite, invers ns fiind posibile cazuri n #C CLIENI Client NrF ClientF Factura #F FACTURI ACHITRI Beneficiar Pltitor DocP PLI #P NrDocP

DataF

TotalF

#A

Plata

DataDocP

Suma

Fig. 2.15 O DEA care are exact aceeai traducere n MRD ca i cea din figura 2.13

care exist mai multe circumscripii ntr-un acelai jude (de exemplu, Bucureti); fiecare localitate aparine unui jude; orice circumscripie electoral este constituit dintr-o mulime de centre de votare; pentru fiecare centru de votare intereseaz i tipul su (de exemplu: municipal, urban, rural, UM MAN, UM MI, vapoare civile, vapoare militare, ambasade etc.); ca atare, centrele sunt unic identificate de cheia semantic TipNrCrt; valorile atributului NrCrt sunt unice n cadrul fiecrui tip n parte, dar nu sunt unice pe ar; fiecare centru de votare este organizat ntr-o localitate; fiecare localitate are un primar; fiecare jude are un prefect. Inspectnd aceast relaie este evident c ea prezint foarte multe redundane, precum, de exemplu: judeul i prefectul se repet pentru toate localitile unui acelai jude ALEGERI (#C, TipNrCrt) #C Tip NrCrt Jude Localitate Circum- Primar Prefect scripie 1 U 01 Alba Sebe 1 Pop Vcrescu 2 R 02 Alba Lancrm 1 Octavian Vcrescu 3 S 01 Clrai Oltenia 3 Ilici Serghei 4 M 01 Vaslui Vaslui 6 Vasilescu Nstsescu 5 M 02 Vaslui Vaslui 9 Vasilescu Nstsescu 6 M 01 Alba Alba-Iulia 8 Ionescu Vcrescu
Fig. 3.1. : O bd cu o singur relaie pentru aplicaia "alegeri locale"

localitatea i primarul se repet pentru toate centrele de votare dintr-o aceeai localitate.

Vom vedea n seciunea 3.2 c toate aceste neajunsuri sunt datorate unor aa-numite anomalii de proiectare a schemei acestei bd.
3.11.1 Dependene funcionale

Multe lucruri dificil de proiectat se dovedesc performane uoare. Samuel Johnson Definiia 3.1 Fie dou atribute A i B ale unei relaii r; B se zice funcional dependent de A (sau c A determin funcional pe B) d.s.n.d. oricrei valori a lui A i corespunde o
60

unic valoare a lui B. Simbolic, acest lucru se noteaz A B (sau B A). Orice asemenea aseriune se numete funcional dependen (sau simplu, dependen, iar prescurtat FD). Aceast noiune se poate extinde i la mulimi de atribute: fie X i Y dou asemenea submulimi nevide X i Y ale U 35; spunem c Y este funcional dependent de X n r dac oricrui (sub)tuplu avnd valoarea x pentru atributele X din r i corespunde n r un singur tuplu avnd valoarea y pentru atributele Y. X se zice partea stng, iar Y partea dreapt a FD. Definiia 3.2 Formal, date fiind XY U, r(U) satisface FD X Y (sau, echivalent, FD X Y ine n r), dac: (t1,t2r)(t1[X] = t2[X]) (t1[Y] = t2[Y]). Dei definiiile de mai sus sunt formulate n termenii coninutului relaiilor, orice FD corespunde de fapt unei constrngeri de integritate asupra schemei relaiei; aceasta nseamn c ea constituie aseriunea formal a unei proprieti ce trebuie s fie valid pentru orice coninut posibil al schemei relaionale. mpreun cu dependenele cheie, clasa de constrngeri cea mai studiat este cea a funcional dependenelor: pe baza FD se definesc mai multe forme normale, dintre care introducem n acest capitol pe cea mai important (FNBC). Evident c dac XY=U, XY ine n r d.s.n.d. cheie(X) ine n r (vezi problema 84). Rezult c dependenele de cheie sunt un caz particular al FD. Exemplul 3.2 Relaia din figura 3.2 satisface dependena de cheie cheie(Tip, NrCrt) i FD Localitate Primar, dar nu satisface nici dependena cheie(Tip), nici FD Localitate NrCrt. Se poate demonstra uor (vezi problema 11) urmtorul rezultat, fundamental n abordarea relaional: Propoziia 3.1 Fie r(U) o relaie i X1, X2, X U astfel nct X1X2 = U i X = X1 X2; descompunerea r(U) peste X1, X2 este fr pierderi dac r(U) satisface cel puin una dintre FD X X1 sau X X2.
3.11.2 Anomalii de actualizare a datelor

O greeal uzual pe care o fac oamenii atunci cnd ncearc s proiecteze ceva absolut infailibil este subestimarea ingenuitii idioilor. Douglas Adams Foarte multe probleme apar atunci cnd trebuie actualizate datele relaiei din figura 3.1. Prima din ele, zis anomalie de modificare, este datorat tocmai redundanelor semnalate mai sus: de exemplu, dac se schimb primarul unei localiti, trebuie actualizai toi tuplii referind acea localitate (deci datele tuturor centrelor de votare din acea localitate), n loc de un singur tuplu, aa cum ar fi firesc. Aceeai anomalie se observ i pentru cazul n care s-ar schimba prefectul unui jude sau apartenena unei localiti la un jude etc. Exist nc alte dou tipuri de anomalii, zise de inserie, respectiv de tergere, dup cum rezult, de exemplu, din urmtoarele dou consideraii:

faptul c, dac nu se cunoate tipul sau numrul curent al unui nou centru de votare, nu se pot insera n relaie informaii despre o nou circumscripie sau localitate sau despre un nou jude se zice anomalie de inserie, iar

Evident c i X sunt FD triviale (i.e. in n orice coninut), complet neinteresante, n timp ce FD de tipul Y, care implic faptul c Y este o funcie constant, ar trebui factorizat afar din orice relaie, eliminnd Y, devenit complet neinteresant, din schema bd. 61
35

faptul c, dac se terg din bd toate centrele de votare dintr-o localitate, atunci se pierd i informaiile despre acea localitate, se zice anomalie de tergere.

n general, prezena anomaliilor de tipul celor semnalate mai sus (i care sunt desemnate generic prin anomalii de actualizare a datelor) se datoreaz suprancrcrii unei singure relaii cu diverse informaii despre structura subuniversului modelat. n particular, revenind la exemplul de mai sus, coninutul relaiei ALEGERI ncearc s in cont de toate informaiile furnizate de primul paragraf al acestei seciuni, n timp ce schema sa memoreaz doar faptul c produsul TipNrCrt este cheie. Pentru a defini formal anomaliile de actualizare, este nevoie de introducerea n prealabil a noiunii de compatibilitate (semantic) ntre coninutul (instana) unei relaii i tupli. Sintactic, orice tuplu al unei relaii este trivial compatibil cu relaia respectiv (din moment ce i aparine, tuplul are exact aceleai coloane cu relaia). Pentru a insera un nou tuplu ntr-o relaie, este iar trivial cerina compatibilitii sale sintactice cu relaia. Evident ns c aceast compatibilitate nu este suficient n nici unul din cele dou cazuri de mai sus, deoarece att tergerea unui tuplu dintr-o relaie, ct i inseria unuia nou pot viola constrngerile de integritate asociate relaiei. Definiia 3.3 Fie r o relaie peste schema R(U) i t un tuplu peste U, tr; t se zice compatibil (semantic) cu r dac el nu violeaz constrngerile primitive: 1. pentru orice atribut A U, t[A] dom(A) (t nu violeaz constrngerile de domeniu); 2. pentru orice cheie K a lui R i pentru orice tuplu t r, t[K] t[K] (t nu violeaz dependenele cheie); 3. pentru orice constrngere de totalitate A, t[A] (t nu violeaz constrngerile de totalitate); 4. pentru orice dependen de incluziune A B, t[A] B (t nu violeaz dependenele de incluziune); 5. pentru orice constrngere tuplu c, t satisface c (t nu violeaz constrngerile tuplu); de exemplu, dac c: A B, t[A] t[A]. n esen deci, t este compatibil cu r dac r {t} nu violeaz constrngerile primitive. Definiia 3.4 O schem de relaie R se zice a avea o anomalie de inserie dac exist: 1. un coninut valid r al R i 2. un tuplu t compatibil cu R astfel nct r {t} nu este un coninut valid al R. Definiia 3.5 Similar, o schem de relaie R se zice a avea o anomalie de tergere dac exist: 1. un coninut valid r al R i 2. un tuplu t r astfel nct r {t} nu este un coninut valid al R. Definiia 3.6 O schem de relaie R se zice a avea o anomalie (de actualizare a datelor) dac ea are vreo anomalie de inserie sau de tergere. Studiul problemelor legate de eliminarea acestor anomalii a condus la definirea formelor normale (FN) din ce n ce mai nalte pentru scheme de relaii; aceste FN iau n considerare tocmai proprietile de tip constrngeri de integritate ale aplicaiilor modelate (de exemplu, "orice jude are un unic prefect" etc.). De departe, cea mai important dintre constrngerile avute n vedere de MRD este FD.

62

3.11.3 Relaii n forma normal Boyce-Codd

Fiecare stratagem a omului, fiecare unealt, fiecare instrument, fiecare ustensil, fiecare articol de folosin de orice tip ar fi au evoluat pornind de la nceputuri foarte simple. Robert Collier Definiia 3.7 O schem R(U) se zice a fi n forma normal Boyce-Codd (FNBC) dac X Y, Y X, X este supercheie n R(U) 36. Altfel spus, nici un atribut nu poate depinde funcional de vreo mulime de atribute ce nu conine o cheie. n esen, aceasta nseamn c orice FD ar trebui s poat fi descris de chei. Revenind la bd ALEGERI din figura 3.1, se pot identifica urmtoarele ase FD: TipNrCrt Localitate, Circumscripie Jude, Localitate JudePrimarCircumscripie, Primar Localitate, Jude Prefect, Prefect Jude. Deoarece, de exemplu, Circumscripie nu este cheie (dup cum nici Localitate i nici Jude nu sunt, dei toate aceste trei atribute alctuiesc singure partea stng a cte unei FD) rezult c relaia nu este n FNBC. n schimb, schema de bd urmtoare este alctuit numai din relaii n FNBC: CENTRE(#C, Tip, NrCrt, Localitate, Circumscripie) cheie(TipNrCrt), Localitate #L, Circumscripie #CS JUDEE(#J, Jude, Prefect) cheie(Jude), cheie(Prefect), Prefect #P CIRCUMSCRIPII(#CS, Circumscripie, Jude) cheie(Circumscripie), Jude #J LOCALITI(#L, Localitate, Jude, Primar, Circumscripie) cheie(LocalitateJude), cheie(Primar), Jude #J, Primar #P, Circumscripie #CS PERSOANE(#P, Nume) cheie(Nume) Bd obinut conform acestei scheme din relaia ALEGERI prin proiecii (i adugarea de chei primare surogat) este prezentat n figura 3.2. Se zice c schema acestei bd a fost obinut prin descompunerea unicei relaii ALEGERI a bd echivalente. Este uor de remarcat faptul c din aceast bd n FNBC au fost eliminate toate anomaliile de actualizare a datelor semnalate anterior. De exemplu, schimbarea primarului unei localiti, a prefectului unui jude, sau a apartenenei unei localiti la un jude impun acum doar modificarea tuplului corespunztor din LOCALITI sau JUDEE; se pot insera noi circumscripii, localiti sau judee, fr ca ele s aib vreun centru de votare deja memorat n bd; tergerea tuturor centrelor de votare dintr-o localitate nu conduce i la pierderea informaiilor despre acea localitate (care sunt independent pstrate n relaia LOCALITI) etc. Exemplul de normalizare de mai sus (i.e. nlocuirea unei scheme nenormalizate cu una normalizat echivalent) sugereaz c n procesul de proiectare a schemei unei bd ar putea fi nevoie s descompunem acele relaii a cror schem este nesatisfctoare n mai multe relaii mai mici, dar a cror schem respect o anumit form normal. Pentru a rspunde ns la unele interogri asupra bd, ar putea fi necesar i schema relaiilor originare. De exemplu, dac am vrea s aflm prefecii n a cror jurisdicie intr centrele de votare, relaia ALEGERI trebuie reconstruit pentru a fi apoi din nou proiectat pe atributele Tip, NrCrt, Prefect: Tip,NrCrt,Prefect(CENTRE LOCALITI JUDEE)
Dac Y X, X Y este trivial; evident c FD triviale nu contrazic FNBC chiar dac X nu este supercheie. 63
36

CENTRE (#C, TipNrCrt) Localitate #L, Circumscripie #CS Tip NrCrt Localitate Circumscripie #C 1 U 01 2 1 2 R 02 3 1 3 S 01 4 2 4 M 01 5 3 5 M 02 5 5 6 m 01 1 4 JUDEE (#J, Jude, Prefect)Prefect #P Jude Prefect #J 1 Alba 1 2 Clrai 2 3 Vaslui 3 CIRCUMSCRIPII (#CS, Circumscripie) Jude #J Circumscripie Jude #CS 1 1 Alba 2 3 Clrai 3 6 Vaslui 4 8 Alba 5 9 Vaslui LOCALITI (#L, LocalitateJude, Primar) Jude #J, Primar #P, Circumscripie #CS Jude Circumscripie Primar #L Localitate 1 Alba-Iulia 1 1 4 2 Sebe 1 1 5 3 Lancrm 1 2 6 4 Oltenia 2 3 7 5 Vaslui 3 5 8 PERSOANE (#P, Nume) Nume #P 1 Vcrescu 2 Serghei 3 Nstsescu 4 Ionescu 5 Pop 6 Octavian 7 Ilici 8 Vasilescu Fig. 3.2.: O bd descompus n FNBC pentru aplicaia "alegeri locale"

De remarcat c joinul relaiilor CENTRE, LOCALITI i JUDEE reconstruiete ntotdeauna exact relaia ALEGERI, ceea ce, am vzut, nseamn c descompunerea ALEGERI conform acestor trei scheme de relaii se face fr pierderi. Se mai poate observa c, similar, acelai lucru este adevrat i pentru descompunerea ce include i relaia CIRCUMSCRIPII 37. Vom vedea n capitolele urmtoare c proprietatea de descompunere fr pierderi este fundamental. Dup cum tim deja, ea nu este ns garantabil oricror descompuneri. Exemplul 3.3 ne arat c exist i descompuneri n FNBC ce nu au aceast proprietate.
Faptul c CENTRE LOCALITI JUDEE CIRCUMSCRIPII= ALEGERI = CENTRE LOCALITI JUDEE = ALEGERI CIRCUMSCRIPII, precum i acela c ambele descompuneri ale ALEGERI, att cea exclusiv, ct i cea inclusiv CIRCUMSCRIPII se fac fr pierderi se datoreaz unei constrngerii suplimentare din realitate, de tip comutativitate de diagrame de funcii (deci neformalizabil n MRD): (LOCALITI JUDEE) = (CIRCUMSCRIPII JUDEE) (LOCALITI CIRCUMSCRIPII). 64
37

Exemplul 3.3 Fie schema R(Localitate, Jude, Primar, Prefect) cu aceleai date ca n ALEGERI din figura 3.1 i cu aceleai FD ntre atributele ei ca mai sus i anume: Localitate Jude, Localitate Primar, Jude Prefect, Primar Localitate, Prefect Jude. Descompunerea lui R n relaiile LOCALITI (Localitate, Primar, Prefect) i JUDEE(Jude, Prefect) este n FNBC dar se face cu pierderi i, ca atare, reconstrucia R din aceste dou descompuneri ale sale nu este posibil.
3.12 Contraexemple celebre de modelare relaional

Orice teorie este o profeie auto-mplinit ce ordon experienei s se supun cadrului pe care ea l ofer. Ruth Hubbard Acest capitol discut cteva exemple de modelare 38 i proiectare celebre n literatura consacrat modelului relaional al datelor care, la o analiz atent, se vdesc de fapt a fi mai degrab contraexemple. Recapitulnd, abordarea relaional a modelrii datelor presupune existena unei mulimi finite universale a tuturor obiectelor de modelat ntr-o bd, a unei colecii finiteV de mulimi de valori (zise domenii), a unei mulimi finite de funcii A Hom(,V ) (zise atribute) i a unei mulimi finite D de propoziii particulare din calculul predicatelor de ordinul nti (zise dependene). Indiferent de tipul de metodologie folosit (ascendent, prin sintetizare sau descendent, prin descompunere) proiectarea schemei unei bdr pleac, n general, de la A i D cu scopul de a obine o colecie finit de submulimi Ri A (zise scheme de relaii) care s memoreze mulimea C = Ri A a Ri Im(a) (zis instana bd). Bdr astfel proiectat trebuie s ndeplineasc minimum dou condiii: 1. i{1,...,n} Ri = A 2. C s satisfac simultan toate dependenele din D. n general, se caut obinerea de scheme care s includ implicit n structura relaiilor Ri toate dependenele dD sau o acoperire minimal a lor. Eventualele funcionaliti ntre atributele unei relaii urmeaz a fi implementate specificnd o mulime de chei (submulimi minimal injective de atribute ale schemei) asociate tabelei memornd instana relaiei respective. Foarte rar sunt considerate teoretic i alte tipuri de constrngeri n afara dependenelor i i mai rar este analizat impactul acestora asupra proiectrii bd. Practic, SGBDR ofer cel mult posibilitatea specificrii unor trgaciuri (triggers), fiecare n parte impunnd o asemenea constrngere particular. Urmtoarele exemple de modelare sugereaz faptul c abordarea relaional a proiectrii bd nu este, n general, cea mai bun soluie.
3.12.1 Problema codurilor potale

Americanii au nevoie de telefon, noi nu. Noi avem o grmad de mesageri. Sir William Preece, inginer ef al Potei Britanice, 1876. Fie schema de relaie LAC, unde L=Localiti, A=Adrese, C=Coduri potale, cu fd LA C (orice adres dintr-o localitate are un singur cod potal) i C L (orice cod potal este asignat unei singure localiti, dar nu neaprat i unei singure adrese din acea localitate unde prin adres se nelege, de exemplu, strada i numrul).

38

Simplificnd, prin modelarea datelor nelegem formularea problemei de proiectare a bd (n termenii unui model oarecare al datelor). 65

Schema are cheile LA i AC, este n FN3, dar nu i n FNBC. Se poate dovedi uor c schema admite descompuneri fr pierderi n FNBC, dar nici una care s pstreze i dependena LA C. Descompunerile ei nefiind deci practic interesante, vom analiza doar schema original. Fie urmtoarea instan a acesteia (valid n raport cu cheile tabelei): CODIF_POTA (LocalitateAdresa, AdresaCodPotal) Localitate Adresa Sibiu Carpailor, 10 Iai tefan cel Mare, 12 CodPotal 2400 2400

Fig. 6.1: Relaia FN3 (dar nu FNBC) CODIF_POTA

Aceast instan este ns evident aberant, cci dou localiti distincte nu pot avea acelai cod. Construirea unui asemenea contraexemplu este posibil deoarece specificarea cheii AC este inutil (ea neputnd impune C L), iar forarea cheii C imposibil (cci C nu este injectiv). Greeala de modelare provine evident din lipsa de finee a rafinrii soluiei, ceea ce conduce la suprancrcarea semantic a atributelor L i C. O soluie natural n FNDC i deci i n FNBC (vezi figura 6.2) se obine distingnd ntre localitile (mici) crora li s-a asignat un singur cod potal (indiferent de adrese) i cele (mari) care au fost zonate pe (poriuni de) strzi sau chiar imobile (crora li s-a asignat cte un cod n parte). E adevrat c aceast soluie e puin mai complicat, conducnd la o schem cu 3 tabele i 3 fd (CodPotaLm Loc, LOC Adresa CodPotaLM, Adresa CodPotaLM LOC), n loc de 1, respectiv 2, deoarece trebuie impus corespunztor partiionrii oraelor i partiionarea codurilor potale. Aceast soluie prezint dou avantaje suplimentare deloc neglijabile: pe lng o reflectare corect a semanticii modelate (ceea ce simplific mult formularea de interogri) i reprezentarea este mult mai natural i optim, cci nu se repet fiecare localitate mic de sute de ori (pentru fiecare adres a sa n parte) i nici nu este obligatorie memorarea adreselor din aceste localiti (lucru care poate nici nu intereseaz!). De remarcat ns c nici aceast soluie nu este corect, deci pe deplin satisfctoare, deoarece mai este nevoie de dou constrngeri suplimentare, de tip disjuncie de mulimi, de neexprimat n termeni relaionali: Im(Loc) Im(LOC) = (o localitate este ori nezonat, ori zonat) i Im(CodPotaLm) Im(CodPotaLM) = (un cod potal este asignat ori unei localiti, ori unei zone a unei localiti).
3.12.2 Problema premizelor universitare

A nu fi de acord cu trei sferturi dintre britanici este una dintre primele condiii ale echilibrului mental. Oscar Wilde Fie schema de relaie CSPA, unde C = Cursuri, S = Studeni, P = Premize, A = Ani, cu fd SPA (un student a absolvit o premiz ntr-un singur an) i dmv ncastrate (embedded) C>>S | P (un student se poate nscrie la mai multe cursuri ntr-un singur an; un curs poate fi condiionat de absolvirea mai multor premize; iar absolvirea unui curs poate constitui o premiz a nscrierii la mai multe cursuri; menionm c printr-o premiz se nelege tot un curs). Schema are doar cheia CSPA i admite descompunerea n FN4 CS, CP, SPA (cu cheia SP) care are proprietatea jfp i i pstreaz toate dependenele.

66

LOCALITI (#L, LocalitateJude) Localitate, Jude, Jude JUDEE.#J #L 1 2 3 4 Localitate Sibiu Iai Lancrm Podu Dmboviei Jude 25 10 1 4

CODIF_LOC_MICI (#Lm, CodPotaLm) Loc, CodPotaLm, Loc #L #Lm Loc 1 3 2 4 CodPotaLm 515801 117357

CODIF_LOC_MARI (#LM, LOCAdresa, AdresaCodPotaLM) LOC, Adresa, CodPotaLM, LOC #L #LM 1 2 3 4 5 LOC 1 1 1 2 2 Adresa Carpailor, 10 Carpailor, 12 Aleea elimbr, 1 Bd. tefan cel Mare i Sfnt, 1 Bd. tefan cel Mare i Sfnt, 3
Fig. 6.2: Bdr FNDC CODIF_POTA

CodPotaLM 550119 550119 550346 700124 700164

Am artat [Ma1,Ma2] c dmv ncastrate nu se impun obiectiv: necesitatea lor este doar un rezultat al slbiciunilor MRD, cci att conceptul de dmv, ct i presupunerea existenei unor relaii universale sunt nejustificat de tari. Acest lucru este trivial verificabil i n cazul particular al exemplului de fa. Trebuie recunoscut cu onestitate faptul c explicaia ce am dat mai sus C >> S | P modeleaz corect realitatea considerat i c aceast explicaie definete pur i simplu dou relaii matematice, una peste C i S, cealalt peste C i P. Lsnd la o parte modul transcendent n care se poate ajunge, n general, la concluzia c unei scheme relaionale trebuie s i se adauge o anumit dmv ncastrat (singura indicaie c ar putea fi eventual nevoie de asemenea dependene fiind furnizat doar sintactic, de algoritmul de testare a proprietii jfp!), s artm doar c i aceast schem permite instane aberante. Fie, de exemplu: C c1 S s1 C c1 c1 c2 c5 P c2 c3 c5 c1 S s1 P c4 A a1

Fiecare coninut n parte este valid n raport cu cheile tabelei respective. Se observ ns imediat c acest coninut al bd este aberant, cci s1 nu ar trebui s aib dreptul s se nscrie la c1 (deoarece el nu a absolvit nici una din premizele c2 i c3 necesare acestuia). Cauza este deci de aceeai natur cu cea semnalat pentru exemplele de mai sus: proprietatea jfp este prea slab i nu poate mpiedica memorarea de tupli aberani n tabelele descompunerii (ba, lucru i mai grav, joinul natural ce intervine n definirea acestei proprieti disimuleaz existena unor asemenea tupli!). Pe scurt, necazul cu aceast
67

descompunere este c CS nu poate mpiedica nscrierea la un curs studenilor care nu iau luat premizele necesare acelui curs. Acesta nu este ns singurul necaz cu aceast schem relaional: ea nu poate impune nici condiia ca mulimea premizelor oricrui curs s fie inclus n mulimea cursurilor (de exemplu, c4 din SPA, dar nu numai: de unde putem ti oare c c3 din CP este la rndul lui curs?). i mai grav este ns faptul c o asemenea schem nu poate mpiedica condiionrile circulare de cursuri! (Mai bine deci c MRD nu este capabil s exprime constrngerea ce ar interzice studenilor nscrierea la cursurile pentru care nu i-au luat premizele necesare cci, n acest caz, nici un student n-ar reui vreodat s se nscrie la c1, c2 sau c5!).
3.13 Principalele limite ale modelrii relaionale a datelor

Americanii sunt de acord cu orice nu blocheaz traficul rutier. Dan Roth Din subseciunile precedente, reiese clar c: - MRD nu este ntotdeauna capabil s ofere soluii corecte de proiectare nici mcar pentru baze de date (bd) extrem de simple; - abordarea relaional a modelrii datelor nu incit, n general, la formularea complet i neambigu a problemelor de modelat i cu att mai puin la analiza lor aprofundat (pentru a vedea dac i n ce condiii ele au soluie); i, n sfrit, c - nsei exemplele din literatura relaional ilustrnd metodologia de proiectare a bd constituie de prea multe ori adevrate contraexemple de modelare a datelor. Aceast seciune dorete s contribuie la impunerea concluziei c MRD este total inadecvat modelrii datelor; el ar trebui utilizat doar pentru implementarea datalogic [TL] a unor modele de date infologice [TL] (semantice [McL]). Abordarea relaional a modelrii datelor i leagn utilizatorii n iluzia c, eventual ajutai de calculator, ar putea proiecta orice bd avnd doar o viziune simplist i superficial asupra ei. Sperm s fi reuit prin cele cteva contraexemple de modelare discutate n aceast seciune s demonstrm c soluiile astfel obinute nu pot fi dect la fel de superficiale i simpliste. Convingerea noastr este c, pentru a putea reprezenta satisfctor realitatea ntr-o bd, modelele datelor trebuie s ncorporeze mult mai mult matematic dect MRD. Pentru utilizrile curente (gestiune economic, administrativ, tehnologic etc.) este suficient teoria elementar a mulimilor, relaiilor i funciilor [Ma2]. (ns, de ndat ce vom fi confruntai cu proiectarea de bd tiinifice sau de reprezentarea cunotinelor, deja apanaj al inteligenei artificiale, va trebui s apelm i la teoriile matematice modelnd domeniile respective [Ma1].) Considerm c trecerea la utilizarea de astfel de modele ale datelor este posibil i, mai mult, constituie unica alternativ demn de avut n vedere: pe lng faptul (trivial) c matematica este un limbaj universal, iar teoria elementar a mulimilor, relaiilor i funciilor este predat n coala general azi obligatorie aproape pretutindeni, nici nu ntrezrim vreo abordare n acelai timp corect i fructuoas a modelrii datelor care si permit s ignore sau s nu foloseasc adecvat matematica cunoscut. Se consider (pe bun dreptate!) c, pentru a fi satisfctoare, soluia proiectrii trebuie s pstreze dependenele (pd) [Ull]. De asemenea, schema obinut trebuie s satisfac i proprietatea jfp [Ull]. Dei teoria proiectrii bdr demonstreaz [Ull] c: - nu ntotdeauna exist soluii care s satisfac ambele aceste cerine (pd i jfp) - chiar i n cazul existenei soluiilor satisfcnd aceste cerine, nu toate au vreun corespondent intuitiv (neles semantic) - proprietatea jfp nu previne, n general, memorarea de tupli aberani n instana bd (lucru considerat, e drept, ca un avantaj al descompunerii [Ull] sic!)
68

- dei MRD impune limitri severe de modelare (ex.: nu sunt permise mai multe dependene de acelai tip ntre aceleai dou atribute!), literatura evit n general recunoaterea inadecvrii acestei abordri a modelrii datelor. Dimpotriv, prin proliferarea de noi i noi tipuri de dependene (fiecare reuind s formalizeze rezolvarea nc unui exemplu particular de modelare), de FN asociate acestora i de algoritmi de aducere a schemelor n aceste FN, se acrediteaz din ce n ce mai mult ideea c modelarea datelor se poate face n termeni relaionali (i nc asistat de calculator). Iat i cteva alte reflexii pe marginea acestor patru exemple celebre de modelare i proiectare a bdr ntlnite n literatur: fiecare n parte ilustreaz toate cele trei teze deja formulate n debutul seciunii, ns operm o distincie pur didactic ntre ele considernd c 3.12.1, dei extrem de simplu, nu are soluie relaional; 3.12.2 i 3.12.3 sugereaz c problemele de modelat trebuiesc analizate mult mai n profunzime dect se obinuiete, de obicei, n abordarea relaional; n fine, 3.12.4 se vdete a fi un adevrat contraexemplu de modelare a datelor. Nici unul din aceste exemple nu are soluii adecvate n MRD; pentru toate este necesar considerarea unei mulimi de constrngeri mult mai largi dect dependenele (dar i a unui cu totul alt tip de model al datelor): avem n vedere, n special, comutativiti de diagrame precum i egaliti (incluziuni) de imagini i preimagini de funcii i relaii [Ma1]. O analiz mai detaliat a acestor exemple (ca i a altora), nsoit de soluionarea lor ntr-un model al datelor bazat pe teoria elementar a mulimilor, relaiilor i funciilor poate fi gsit n [Ma2]. Concluzia ce am dori s se impun de la sine n urma prezentrii acestor contraexemple este urmtoarea: modelarea datelor trebuie fcut la un nivel ierarhic superior MRD, n termenii unui model infologic (semantic). Doar implementarea datalogic a acestuia va face uz (i) de modelul relaional (cci cea mai natural reprezentare a grafurilor de relaii / funcii ce nu pot fi specificate analitic o constituie, ntr-adevr, tabelele). Nivelul datalogic al oricrei bd trebuie s rmn transparent att proiectantului ct, mai ales, utilizatorului acesteia: nu numai pentru a-l scuti de navigri laborioase (i necesitnd cunotine de specialitate), ci, n special, pentru a-i interzice accesul direct la tabele [Ma1], [Ma2]. Modelul relaional a oscilat mult vreme ntre dou strategii (n esen echivalente) de modelare a datelor, ambele pur sintactice: strategia ascendent a "sintetizrii" schemelor de relaie dintr-o mulime de atribute, respectiv strategia descendent a "descompunerii" unei unice relaii "universale", alctuite din mulimea tuturor atributelor, n mai multe scheme de relaie. Cel de-al doilea tip de strategie s-a impus n timp tot din considerente pur sintactice, legate n esen de descoperirea unor algoritmi de descompunere cu performane superioare celor de sintez. De remarcat c atributele sunt privite n abordarea relaional drept nume pentru mulimi de valori ("domeniile relaiilor") i c scopul comun al sintetizrii i descompunerii l constituie obinerea "automatizabil" a unei colecii de scheme relaionale ntr-o anumit form normal. La rndul lor, formele normale sunt introduse ca garani ai satisfacerii "automate" a unor mulimi de constrngeri de anumite tipuri ("dependene"). Modelarea relaional a datelor are meritul incontestabil c atrage pentru prima oar atenia asupra faptului c proiectarea "ad-hoc" a schemelor de fiiere conduce n general la apariia anomaliilor de actualizare. "Netratate", acestea induc pierderi i/sau alterri de informaii; tratamentul lor ulterior implic costisitoare tranzacii procedurale, ce n69

seamn att timp i efort de programare, ct i timp suplimentar de execuie a programelor aferente. n consecin, abordarea relaional propune prevenirea acestor anomalii printr-o proiectare riguroas a schemelor de fiiere, care s ia n considerare i constrngerile de integritate impuse de "realitatea" domeniilor modelate. n plus, bazndu-se pe o uniformizare simplificatoare ("aplatizarea" realizat de prima normalizare), pe formalizarea relaional a fiierelor i pe dependenele abstractiznd anumite tipuri de constrngeri de integritate, modelul relaional i propune iniial s ofere o proiectare algoritmic, efectiv i eficient calculabil, a schemelor de relaii n diferitele forme normale aferente dependenelor. 39 Aceast abordare a modelrii datelor are ns limitele ei, att din punct de vedere sintactic, ct i semantic. Enumerm n continuare doar pe cele de esen:
nti i nti, pe ct este de adevrat faptul c relaiile (cu tuplii i atributele lor) constituie o abstractizare excelent a fiierelor de date, pe att de puin evident este acela c fiierele ar constitui o abstractizare mulumitoare a semanticii oricrui domeniu de interes al "realitii", chiar nsoite fiind de constrngeri de integritate; simplitatea relaiei ca unic unealt de modelare constituie, desigur, un uria avantaj sintactic, dar induce o inevitabil srcie semantic, insuficient atenuabil prin adugarea dependenelor apoi, s-au putut defini forme normale doar pentru cteva tipuri particulare de constrngeri; n plus, nici una dintre aceste forme normale nu este pe deplin mulumitoare (n sensul c nu asigur nici mcar garantarea satisfacerii tuturor tipurilor de constrngeri formalizate ca dependene) mai mult, nu se poate n general obine o schem de bd n orice form normal dorit, pornind de la orice mulime de dependene, iar n destule dintre cazurile particulare n care acest lucru este totui posibil, algoritmii de calcul afereni sunt exponeniali sau polinomiali (dar tot foarte leni pentru aplicaii "reale", chiar i n al doilea caz, deoarece polinoamele au grad mare); mai mult, majoritatea algoritmilor sunt nedeterminiti, revenind tot proiectantului aplicaiei s aleag dintre mai multele soluii calculate pe aceea care i se pare c ar avea cel mai mult "sens" n sfrit, lucru deja semnalat n capitolul 3, considerm c este extrem de gritoare mprejurarea c cea mai nalt form normal a MRD este definit doar n termeni de chei i constrngeri de domeniu i este caracterizabil strict n termeni de anomalii i nu n cei ai vreunui tip de dependen (fie el FD, DMV, DJ etc.). 3.14 Probleme propuse spre rezolvare

1. 2.

3. 4. 5. 6.
39

Formalizai diferena dintre definiia produsului cartezian uzual n teoria mulimilor i cea din modelul relaional al datelor. S se demonstreze c propoziia corespunznd valorilor nule lipsite de informaie (R-k(t[A1], ..., t[Ak-1], t[Ak+1], ..., t[An])) este echivalent cu disjuncia formulelor asociate celorlalte dou tipuri de valori nule: x(R(t[A1], ..., t[Ak-1], x, t[Ak+1], ..., t[An])) (x(R(t[A1], ..., t[Ak-1], x, t[Ak+1], ..., t[An])) R-k(t[A1], ..., t[Ak-1], t[Ak+1], ..., t[An])). S se demonstreze propoziia 12. S se demonstreze propoziia 4.2. Calculai cardinalitatea minim i cea maxim a joinului a n relaii, n natural, n termenii cardinalitii operanzilor. S se demonstreze c operatorul join este comutativ i asociativ.

Dei nu este circumscris "staticii" modelrii, ci "dinamicii" tranzacionale asupra modelelor rezultate, se cuvine desigur a meniona i aici contribuia suplimentar esenial a modelului relaional n formalizarea dual a interogrilor, att algebric ct i logic de ordin nti. Aceasta a permis nu doar obinerea de algoritmi optimizai de calcul al rspunsurilor pentru clase importante de ntrebri, ci i semnalarea eventualelor ambiguiti n formularea lor. 70

Demonstrai c operatorii de selecie i proiecie sunt monotoni. 40 Extindei definiia monotoniei la operatori n-ari i demonstrai c i operatorul join este monoton. 8. S se demonstreze lema 9. 9. S se demonstreze lema 10. 10. S se demonstreze propoziia 22. 11. Fie n = cardU; s se arate c numrul de FD triviale peste R(U) este 3n 2n. 12. Ar crete puterea expresiv a FD dac am admite i FD fr nici un atribut n partea stng i/sau n cea dreapt? De ce? 13. Demonstrai lema 4.6 (indicaie: folosii inducia dup lungimea derivrii). 14. Demonstrai lema 4.7. 15. Demonstrai sau infirmai soliditatea urmtoarelor reguli de deducie pentru FD: a. dac X Y, atunci X Y; b. dac X Y, atunci Y X; c. dac X Y, atunci X Y; d. dac X Y i Z X, atunci Z Y; e. dac X Y i Z X i Y V, atunci Z V. 16. O mulime de reguli de inferen S se zice independent dac nici o submulime proprie a sa S nu permite, pentru orice mulime de constrngeri, derivarea tuturor constrngerilor derivabile cu ajutorul S. Demonstrai c mulimea {FD1, FD2, FD3} este independent. 17. Gsii legturi ntre diversele reguli de derivare din text i cele din problema 15. Gsii, printre toate aceste reguli de derivare, mulimi de reguli complete i independente. 18. Demonstrai corolarul 4.9. 19. Demonstrai c X, X+ este cea mai mic nchidere coninnd X. 20. Gsii o mulime solid i complet de reguli de derivare pentru constrngerile tuplu (indicaie: sunt necesare presupuneri suplimentare asupra domeniilor atributelor). 21. Demonstrai lema 67. 22. Demonstrai tranzitivitatea aplicaiilor de coninere (i.e. pentru orice pereche : T1 T2 i : T2 T3 exist o aplicaie de coninere de la T1 la T3). 23. Demonstrai corolarul 96. 24. Demonstrai corolarul 98. 25. Furnizai un exemplu de relaie pentru care condiiile necesare din teorema 99 nu sunt obligatorii. 26. Formulai o caracterizare a problemei implicaiei pentru DIN bazat pe vnare (cu presupunerea c algoritmul se termin). 27. Gsii condiii suficiente de terminare a vnrii pentru DIN. 28. Demonstrai lema 102. 29. Demonstrai lema 103. 30. Demonstrai lema 104. 31. Demonstrai propoziia 105 (indicaie: folosii inducia dup numrul de pai necesari n vnare pentru a aduga tuplul t la ri). 32. Proiectai un algoritm de rezolvare a problemei implicaiei pentru DIN cu urmtoarele specificaii: Intrare: o schem de bd, o mulime I de DIN, o schem de relaie Ri i o list de atribute L1 din Xi;
40

7.

Reamintim c un operator unar f se zice monoton dac r1, r2, (r1 r2 ) f (r1 ) f (r2 ) 71

Ieire: toate schemele de relaii Rj i listele de atribute L2 cu proprietatea c I implic Ri[L1] Rj[L2]. 33. Simplificai regulile de inferen pentru subclasa DIN tipate; proiectai un algoritm eficient de rezolvare a problemei implicaiei pentru aceast subclas. 34. Construii o mulime de reguli de inferen solid i complet pentru DIN unare; proiectai un algoritm de complexitate liniar pentru problema implicaiei corespunztoare. 35. Artai c implicaia finit i cea restricionat coincid pentru FD. 36. Gsii o mulime de FD i de DIN i o FD astfel nct nu implic (nerestrictiv) , dar implic finit . 37. Demonstrai punctul 2 al lemei 112. 38. Demonstrai lema 116 (indicaie: infinitatea domeniilor este esenial!). 39. Demonstrai lema 117 (indicaie: aceeai ca la problema de mai sus!). 40. Definii noiunile de satisfacere puternic i slab pentru DIN i demonstrai teorema similar 118. 41. Demonstrai c dac o mulime F de FD este slab satisfcut de o relaie r i dac exist o relaie r fr valori nule, obinut din r prin substituii, ce satisface F, atunci r satisface (n contextul implicaiei uzuale, lipsite de valori nule) toate FD implicate de F. 42. Demonstrai c regulile de inferen FD1, FD2 i FD4 sunt solide pentru FD i n prezena valorilor nule necunoscute. 43. Demonstrai teorema 121. 44. Proiectai, pornind de la figura 25, un algoritm de calcul a nchiderii unei mulimi de atribute n raport cu o mulime de FD, n contextul satisfacerii slabe. 45. Demonstrai soliditatea regulilor de inferen FD1, FD2 i FD4 pentru FDN. 46. Demonstrai teorema 123. 47. Demonstrai c dac F i G sunt mulimi de FDN echivalente, atunci, oricare ar fi Y A F, exist o FDN Z A G astfel nct Z Y. 48. Demonstrai c pentru orice mulime F de FDN exist i este unic o submulime a sa ce constituie o acoperire neredundant pentru F. 49. Demonstrai teorema 125. 50. Studiai problema implicaiei pentru reuniunea claselor FDN i CE. 51. Demonstrai c (teorema de caracterizare a schemelor de relaii cu FD avnd o singur cheie): dat fiind o schem [R, F], cu R(U) i F = {X1 Y1, , Xk Yk}, R are o unic cheie d.s.n.d. U Z1Zk este o supercheie, unde Zi = Yi Xi, 1 ik. 52. O schem de relaie [R,F] se zice a fi n forma normal 2 (FN2) dac F+ nu conine nici o FD parial K A (o FD X A F+ se zice parial dac X X astfel nct X A F+), unde K este o cheie, iar A un atribut neprim (i.e. un atribut care nu face parte din nici o cheie). Demonstrai c FN2 este strict mai slab dect FN3. 53. O schem de relaie [R,F] se zice a fi n forma normal 2 special (FN2S) dac K,AR, K cheie, X K, A X, astfel nct X A F+. Demonstrai c FN2S este strict mai slab dect FN3, dar strict mai puternic dect FN2. 54. O schem de relaie [R,F] se zice a fi n forma normal 3 (FN3) dac pentru orice FD netrivial X A F, unde A este neprim, X este o supercheie (unde, vezi i problema 51 mai sus, un atribut A se zice prim dac face parte din cel puin o cheie i neprim n caz contrar). S se demonstreze c: a. [R,F] este n FN3 dac nici un atribut neprim nu este tranzitiv dependent de nici o cheie a R (unde un atribut A se zice tranzitiv dependent de o mulime de
72

atribute X dac exist o mulime de atribute Y astfel nct X Y, Y A F+, Y X F+, iar A X; rezult, evident, conform definiiei cheilor, c A este tranzitiv dependent de o cheie K dac exist o mulime de atribute X care nu este supercheie, nici nu conine A, dar X A F+). b. FN3 este strict mai slab dect FNBC, dar strict mai puternic dect FN2S. 55. O schem de relaie [R,F] se zice a fi n forma normal cu chei elementare (FNKE) dac oricare ar fi FD netrivial X A F, ori X este o cheie elementar, ori A face parte dintr-o asemenea cheie (unde o cheie K se zice elementar dac exist mcar un atribut A R astfel nct K K cu proprietatea c K A F+). Demonstrai c FNKE este strict mai slab dect FNBC, dar strict mai puternic dect FN3. 56. Fie o schem R(U); demonstrai c dac R satisface DMV X Y, atunci ea satisface i DMV X U XY (proprietatea de complementaritate a DMV). 57. Construii i demonstrai o teorem de caracterizare a DMV triviale. 58. Demonstrai c o relaie poate satisface X YZ, dei violeaz X Y. 59. Artai c, n general, dat fiind o mulime F de FD, nu este posibil gsirea unei mulimi M de DMV astfel nct o relaie satisface F d.s.n.d. ea satisface M. 60. Demonstrai c X Y i X Z implic X Y - Z (i deci, datorit complementaritii, X Y Z). 61. Demonstrai tranzitivitatea DMV. 62. Fie schema STUDENI(#Student, #Curs, Credit, Student, Sex, Vrsta, Curs). Identificai FD i cheile ei. Proiectai o schem echivalent n FNBC. Se poate obine i o schem n FNDC? Justificai rspunsul. 63. Fie schema STUDENI(#Student, #Laborator, #PC, Student, Laborator, PC) avnd urmtoarele FD: #Student Student #Student Laborator #Student #Laborator #Student PC #Laborator PC #Laborator Laborator #PC PC #PC #Laborator Laborator #Laborator Analizai eventualele anomalii ale schemei i proiectai o schem echivalent n FNDC. 64 a. Demonstrai teorema 131. b. Artai c ea nu ar mai avea loc dac definiia FN4 s-ar referi doar la DMV din i nu la cele din +. 65 Demonstrai teorema 133. 66. a. Demonstrai (corolarul 134) c o schem [R,F] este n FNBC (respectiv FN4) dac oricare ar fi FD (respectiv DMV) d F exist o unic dependen de cheie care implic d. b. Artai c un rezultat similar pentru FNPJ (deci d fiind DJ) nu este adevrat. 67. a. Stabilii valoarea de adevr a urmtoarei propoziii: Orice relaie cu dou atribute este n forma normal proiecie join (FNPJ). b. Construii i demonstrai o propoziie care s furnizeze condiia necesar i suficient pentru ca o relaie cu dou atribute s fie n FNPJ. 68. Demonstrai teorema 136. 69. a. Demonstrai c n absena ipotezei c domeniile conin cel puin dou valori distincte pentru orice atribut, lema 138.a. nu mai este adevrat. b. Completai demonstraia lemei 138.a. lund n considerare i DMV. c. Demonstrai lema 138.b. 70. Fie urmtoarea schem de bd:
73

a) b)

a) b)

PERSOANA (#Cod, Prenume, Nume, Sex, DataNaterii) TATA (Tat, Copil) MAMA (Mam, Copil) Scriei o expresie SPJ pentru calculul ambilor prini ai tuturor persoanelor memorate de bd. Furnizai cteva coninuturi valide ale acestei scheme i calculai, pentru fiecare n parte, rezultatul expresiei SPJ pe care ai proiectat-o. 71. Fie o bd tehnologic pentru memorarea unor repere (piese, subansamble, module, produse etc.) compuse din alte repere. Structura tehnologic a unui reper poate fi vizualizat sub forma unui arbore n care, la fiecare nivel, se pot afla ori repere atomice (n frunzele arborelui), ori repere compuse (n nodurile non-frunz). Proiectai o bd n FNPJ, considernd codul, denumirea, preul i compunerea reperelor. Furnizai un posibil coninut valid. 72. n contextul bd de la exerciiul anterior scriei expresiile SPJ pentru calculul urmtoarelor interogri: Submulimea compunerilor memorate (denumire reper, denumire reper compus imediat superior); Submulimea reperelor (denumire, pre) pentru care preul este numai cu 1.000 mai mic dect preul reperului imediat superior n a crui componen intr. Pentru fiecare din aceste expresii, calculai rspunsurile pentru coninutul propus la problema 71 de mai sus. 73. Fie o bd de personal n care intereseaz numele, prenumele, sexul, data i locul naterii, adresa i localitatea domiciliului, data angajrii, data ncetrii angajrii i angajatorul (firma, organizaia administrativ etc.) fiecrei persoane, precum i denumirea, localitatea i eventualele subordonri ntre angajatori (e.g.: Microsoft Romnia srl, cu sediul n Bucureti, Romnia, este subordonat Microsoft Central and Eastern Europe GmbH, cu sediul n Munchen, Germania, care este subordonata Microsoft Corporation, cu sediul n Redmond, S.U.A.). Specificai schema n FNPJ a acestei bd i prezentai un posibil coninut valid al ei. 74. n contextul bd de la exerciiul anterior scriei expresiile SPJ pentru calculul urmtoarelor interogri: Submulimea subordonrilor memorate (denumire organizaie subordonat, denumire organizaie imediat superioar); Submulimea persoanelor (nume, prenume, data i locul naterii) care au lucrat n decursul timpului n aceeai localitate n care s-au nscut, la o organizaie cu sediul n aceeai localitate cu organizaia creia i este subordonat. Pentru fiecare din aceste expresii, calculai rspunsurile pentru coninutul propus la problema 73 de mai sus. 75. Considerai mulimea cursurilor oferite de o universitate, cu presupunerea c fiecare din ele are asociat o submulime (posibil vid) de cursuri (zise precondiii) ce trebuie absolvite nainte de a fi permis nscrierea la ele. Date fiind dou atribute, cheia surogat i denumirea cursului, proiectai o bd universitar n FNPJ pentru a memora cursurile i precondiiile lor. Exemplificai cu un posibil coninut valid. Extindei bd (tot n FNPJ) i coninutul de mai sus (meninnd validitatea) cu urmtoarele informaii: un student (caracterizat de cod, prenume, nume i cursurile absolvite, precum i cele la care s-a nscris) se poate nscrie la mai multe cursuri, dac a absolvit toate precondiiile acestora (evident c la orice curs se pot nscrie mai muli studeni); pentru fiecare curs pot fi recomandate mai multe cri (iar o carte poate fi recomandat la mai multe cursuri); pentru cursuri mai intereseaz i crile recomandate i studenii nscrii; pentru cri intereseaz codul, titlul i cursurile la care sunt recomandate. Ilustrai cu un coninut valid al acestei bd. 76. n contextul bd de la exerciiul anterior scriei expresiile SPJ pentru calculul urmtoarelor interogri:
74

a) b) c) d)

a) Submulimea cursurilor cu cel puin o precondiie (denumire curs, denumire precondiie); b) Submulimea cursurilor (denumire) la care s-a nscris mcar un student; c) Submulimea studenilor (prenume, nume) nscrii la cursurile la care este recomandat cartea cu titlul Tratat de algebr; d) Submulimea studenilor (prenume, nume i denumire curs absolvit) care au absolvit cursuri a cror denumire este aceeai cu titlul uneia din crile recomandate la curs. Pentru fiecare din aceste expresii, calculai rspunsurile pentru coninutul propus la problema 75 de mai sus. 77. Proiectai o baz de date administrativ-geografic n FNPJ care s memoreze denumirea, codul potal, numrul de locuitori i subdiviziunea administrativ (jude, stat, canton, departament, land, provincie, voievodat etc.) de care aparin localitile, denumirea, codul automobilistic, prefixul telefonic, localitatea de reedin i ara de care aparin subdiviziunile administrative ale rilor, denumirea, codul automobilistic, prefixul telefonic, denumirea subdiviziunilor administrative i capitala rilor lumii. Ilustrai cu un coninut valid al acestei bd. 78. n contextul bd de la exerciiul anterior scriei expresiile SPJ pentru calculul urmtoarelor interogri: Submulimea subdiviziunilor administrative (denumire, denumire ara, denumire capital) care includ capitale cu cel puin 1.000.000 de locuitori; Submulimea judeelor din Romnia (denumire, cod auto, prefix telefonic, denumire localitate reedin) care au reedina ntr-o localitate a crei denumire este diferit de cea a judeului; Submulimea rilor (denumire, cod auto, prefix telefonic, denumire capitala) care au aceeai denumire cu cea a capitalei lor; Submulimea capitalelor (denumire ara, denumire capitala, denumire subdiviziune administrativ, denumire reedin subdiviziune) care nu sunt i reedin a subdiviziunii administrative din care fac parte. Pentru fiecare din aceste expresii, calculai rspunsurile pentru coninutul propus la problema 77 de mai sus. 79. Artai c algoritmul 74 are complexitate O(| | || ||). 80. Artai c egalabilitatea (vezi definiia 90) este o relaie de echivalen. 81. Demonstrai teorema 97. 82. Demonstrai teorema 113. 83. Artai c n orice coninut al unei scheme R(U), dac XY = U, atunci X Y cheie(X). 84. Demonstrai c un rezultat similar corolarului 134 nu are loc pentru FNPJ i DJ. 85. Demonstrai punctul 2 al teoremei 141. 86. Demonstrai c: YX, card(X) = card(Y(X)) K Y, K cheie. 87. Demonstrai propoziia 4.1. 88. Fie un SGBD relaional care ofer scheme n FNDC. Proiectai pentru metadatele sale: a. o DEA b. o bd n FNDC. 89. Construii i reprezentai n conveniile DEA un graf n care noduri s fie toate conceptele MRD, iar arcele s reprezinte relaia se bazeaz pe (indicaii: spargei schema n subscheme interconectate; definiiile sunt entiti;
75

propoziiile, lemele, teoremele i corolarele sunt asociaii). Care sunt mulimile de elemente minimale, respectiv maximale ale grafului astfel obinut? 90. Artai c joinul natural a dou relaii avnd scheme identice este egal cu intersecia acestora. 91. Date fiind dou relaii r1(X1) i r2(X2), unde X2 X1, se zice mprirea lui r1 la r2 i se noteaz cu r1r2 relaia peste X1 X2 coninnd tuplii t cu proprietatea c, t2r2, t1 r1 astfel nct t1 este o combinaie a lui t cu t2 (adic, astfel nct t1[X2]=t2 i t1[X1 X2]=t). Artai c: mprirea este un operator derivat (i.e. care se poate obine prin compunerea altor operatori); mprirea este un fel de invers a produsului cartezian, demonstrnd urmtoarea egalitate: (r1r2)r2 = r1. 92. Demonstrai c orice expresie AR poate fi transformat ntr-o expresie echivalent ale crei relaii constante sunt toate definite peste un singur atribut i conin un singur tuplu. 93. Demonstrai c orice expresie AR poate fi transformat ntr-o expresie echivalent n care seleciile au doar condiii atomice, proieciile elimin doar cte un singur atribut, iar ceilali operatori sunt doar reuniuni sau redenumiri sau diferene sau produse carteziene. 94. Discutai ipoteza care cere ca orice formul sau subformul s aib cel puin o variabil liber; n particular, considerai implicaiile sale asupra semanticii expresiilor (valoarea acestora pentru substituii) i asupra echivalenei CRD cu AR. 95. Formulai interogrile din problema 92 n CRD. 96. Demonstrai lema 164. 97. Demonstrai lema 165. 98. Demonstrai teorema 169 (AR este independent de domeniu). 99. Demonstrai c rezultatul unei expresii CRD-ID conine doar valori din domeniul activ al expresiei i al bd curente (indicaie: folosii lema 172). 100. Formulai interogrile din problema 92 n CRD cu declaraii de domeniu al valorilor. 101. Pe baza cunotinelor Dvs. de QBE, discutai de ce acesta poate fi considerat o implementare a CRD-DV. Gsii, n msura posibilitilor, o metod de transformare a expresiilor ntre aceste dou limbaje. 102. Discutai posibilele extensii ale AR pentru a o face echivalent cu CRD, permind astfel expresii dependente de domeniu. 103. Propunei extensii ale AR i ale CR ce ar putea formaliza interogri de tipul Ci ani a domnit fiecare domnitor n parte? sau Ce domnitori i-au nceput domnia cu cel puin 25 de ani naintea morii?. 104. Formulai interogrile din problema 92 n CRT. 105. Demonstrai teorema 178. 106. Oferii o demonstraie complet a teoremei 182 (echivalena CRT i CRD). 107. Demonstrai corolarul 183. 108. Propunei extensii ale CRT-DV care l-ar face echivalent cu celelalte limbaje discutate n acest capitol. 109. Demonstrai teorema 185. 110. Proiectai (i implementai ntr-un limbaj la alegere) algoritmul de traducere a schemelor relaionale n DEA. Enunai i demonstrai teorema aferent proprietilor sale.

76

3.15

Istoric i referine bibliografice

Adevrata menire a istoriei este s prezinte evenimentele, crora s le adauge doar sfaturi, lsnd reprourile i concluziile n sarcina libertii de a judeca a fiecrui om. Francis Bacon Modelul relaional al datelor a fost introdus n 1970 de matematicianul englez E.F.Codd, cercettor IBM [106], avnd drept scop declarat asigurarea independenei datelor (de nivelul fizic, al oricror implementri posibile) i depirea restriciilor impuse de modelele datelor existente pn atunci. Primele modele ale datelor n ordine cronologic, cel ierarhic i apoi cel reea, includ referine explicite la caracteristici de implementare la nivel fizic, precum pointerii, care aproape exclud dintre potenialii utilizatori ai bd de acest tip pe nespecialitii n programarea calculatoarelor. n plus, aceste modele nu dispun de definiii formale ce le-ar putea asigura consistena i precizia. Desigur c succesul MRD nu se explic ns numai prin naltul grad de independen logic asigurat (fa de orice posibil implementare fizic) sau prin formalizarea sa matematic; el se datoreaz i simplitii unicei structuri folosite pentru organizarea datelor (o variant a relaiei matematice n-are), naturaleei i expresivitii reprezentrii acesteia sub form de tabele i mai ales puterii i eleganei limbajelor de interogare relaionale. Exist foarte multe cri de specialitate ce prezint i discut aceste prime trei modele ale datelor, precum Abiteboul, Hull i Vianu [??], Atzeni i De Antonellis [30], Date[118, 120], ElMasri i Navathe [134], Korth i Silberschatz [211], Maier [239], Tsichritzis i Lochovski [334], Ullman [337, 338, 339, 342, 343]. Primele implementri ale modelului relaional au aprut la nceputul anilor 1980 (abia la un deceniu dup definiia sa abstract); i asupra acestora exist cri, precum Date [118,120] sau Stonebraker [323]. ncepnd cu 1985, o adevrat avalan de implementri pe calculatoare personale a nclinat definitiv balana n favoarea modelului relaional, fcnd aproape complet uitate i desuete modelele ierarhic i reea. ElMasri i Navathe [134], Korth i Silberschatz [211], Valduriez i Gardarin [344] indic i discut bun parte din aceste implementri, furniznd multe alte referine suplimentare. Majoritatea operatorilor algebrei relaionale au fost definii de Codd [106], odat cu introducerea modelului relaional n 1970. Prezentrile ulterioare ale altor autori [123,134,211,337,342] difer foarte puin de cele originale. Pentru seciunea 1.7, am preferat s urmrim prezentarea din [30]. Valorile nule necunoscute (mpreun cu o extensie a algebrei relaionale ce include o logic cu trei valori i un aa numit principiu de substituie a nulurilor) au fost introduse de Codd [81]; critica abordrii sale se datoreaz lui Grant [117]. Biskup [51,52] extinde i aprofundeaz cercetrile n domeniu. Vassiliou [224,226] consider att nulurile necunoscute, ct i pe cele inexistente n termenii semanticii denotaionale. Valorile inexistente au fost studiate i de Lien [152] i de Lerat i Lipsky [151]; nulurile lipsite de informaie au fost abordate de Zaniolo [233,235], Keller [134], Atzeni i Morfuni [28,29] i Atzeni i De Bernardis [26]. Lipski [155,156] propune o prim generalizare a valorilor nule, prin folosirea valorilor parial specificate (submulimi nevide ale domeniului atributului corespunztor n care nulurile pot lua valori). O alt generalizare, bazat pe asocierea de probabiliti fiecrei valori dintr-un domeniu, se datoreaz lui Wong [230] (o valoare specificat se poate reprezenta asignndu-i probabilitatea 1, n timp ce toate celelalte valori ale domeniului au probabilitatea 0; un nul inexistent se reprezint asociind probabilitatea 0 tuturor valorilor domeniului; un nul necunoscut, prin probabilitatea 1/n
77

asociat tuturor valorilor, unde n este cardinalul domeniului respectiv 41; iar nulurile parial specificate de o submulime de cardinalitate k, asociind probabilitatea 1/k tuturor acestor valori i probabilitatea 0 restului domeniului). Korth i Ullman [145], Maier [160], Sagiv [191], Imielinski i Lipski [125] au propus i studiat folosirea de indici pentru a distinge ntre diversele valori nule (zise i nuluri marcate, acestea permit, de exemplu, memorarea informaiei c anumite valori nule trebuie s coincid). Cheile au fost studiate prima oar de Codd [108,110]. Algoritmul de asisten a proiectrii cheilor a fost propus de Manca n contextul Modelului Matematic Elementar al Datelor (MMED) [info iasi, iks2002, micd], iniial pentru cheile structurale ale asociailor [sea 2004/1] i apoi pentru cheile tipurilor de obiecte [balcani 2004]. Teorema 2.4 a fost publicat n 1988 [mamaia 1989]. (?? si propoziiile anterioare ??) Dependenele de incluziune au fost luate n considerare mult mai trziu (ncepnd cu Casanova .a. [86,87]), lucru oarecum surprinztor dac avem n vedere att nelesul lor, mult mai concret dect al multor alte clase de constrngeri, ct i marea lor importan practic n orice implementare. Constrngerile tuplu nu au fost niciodat studiate formal; desigur ns c importana lor nu a putut fi subestimat de nici o implementare (a se vedea, de exemplu, Date [118]). Manca [iks 2002] a generalizat constrngerile tuplu n MMED introducnd constrngerile obiect. Manca, Dragomir i Crasovschi [dba 2003] au introdus i studiat un calcul obiectual de ordin I care permite exprimarea att a constrngerilor obiect, ct i a celor de domeniu. Constrngerile primitive au fost introduse de Fagin [??] i includeau doar pe cele de domeniu i cheile; Manca a extins definiia lor incluznd n aceast categorie i constrngerile de totalitate, dependenele de incluziune i constrngerile tuplu. Funcional dependenele au fost studiate prima oar de Codd [108,110]. Formele normale FN1, FN2, FN3 i FNBC au fost introduse de Codd [108] (primele trei, n 1972) i [110] (FNBC, n 1974). O definiie mult mai elegant pentru FD i se datoreaz lui Breazu [info cluj]: A B d.s.n.d., prin definiie, KerA KerB, unde pentru orice funcie f, Kerf = {(x,y) | f(x) = f(y)}. Astfel definit (funcional), FD admite o teorem caracterizare extrem de puternic: A B d.s.n.d. ! f : dom(A) dom() cu proprietatea c f A = B. Breazu i Manca [78] au introdus alte cteva forme normale: FN2L i FN3L (locale n raport cu o cheie oarecare), FN2S i FN3S (speciale, n care se renun la condiia ca atributele din partea dreapt a FD s fie neprime), dovedind c FN2L i FN2S, respectiv FN3L, FN3S i FNBC sunt echivalente. Studiul formal al anomaliilor se datoreaz lui Bernstein i Goodman [67] (1980), LeDoux i Parker [221] (1982) i mai ales lui Chan [94] (1989). Dei iniial normalizarea a dorit s ofere o proiectare automat a schemelor de bd, n ultimii ani, din ce n ce mai muli cercettori n domeniu sunt de acord c o asemenea abordare este greit. n locul ei, se recunoate fie i numai implicit (dar, de exemplu, n [30] i explicit!) c proiectantul de bd trebuie s fac nti uz de un model conceptual (semantic) al datelor, mcar de tip entiti-asociaii, urmnd ca schema astfel rezultat s fie tradus (manual sau automat) ntr-o schem relaional normalizat. n acest context, teoria normalizrii asigur doar repere i caracterizeaz inta unor asemenea proceduri. Seciunea 3.11 se bazeaz pe [teza doctorat] i [206]. Studiul puterii expresive a algebrei relaionale prezentat n subseciunea 7.2.1 se datoreaz lui Paredaens [278] (1978); rezultatele similare pentru calculul relaional au fost obinute de Bancilhon [44] n acelai an. Dintre operatorii algebrici propui suplimentar i relevani doar n manipularea valorilor nule menionm: augmentarea (unar, producnd o relaie peste atributele operandului plus alte atribute i ai crui tupli sunt provenii din cei ai operandului prin
41

Dac domeniul este infinit, trebuie recurs, desigur, la distribuii. 78

extinderea lor cu valori nule), joinul (natural) extern (outer join, adic LEFT i RIGHT) [148]; i proiecia total [191], o proiecie uzual urmat de eliminarea tuturor tuplilor ce conin valori nule. Este uor de demonstrat c aceti operatori sunt derivai, cci se pot obine din cei fundamentali i din relaii constante coninnd valori nule.

79

5 Modelul matematic elementar al datelor

Esena matematicii este libertatea ei. Cantor Modelul matematic elementar al datelor (MMED) este bazat pe teoria algebric elementar a mulimilor, relaiilor i funciilor, ca i pe logica predicatelor de ordin nti cu egalitate. MMED a pornit de la interpretri funcionale i logice ale MRD, precum i de la o formalizare a MEA, incorpornd din ce n ce mai multe tipuri de constrngeri, dar i puterea inferenelor oferit de Datalog. Drept urmare, MMED este un instrument de modelare conceptual a bazelor de date deductive definite (bddd). MatBase este un sistem de gestiune prototip al bazelor de cunotine (SGBC) bazate pe MMED, adesea folosit n acest ultim capitol pentru exemplificri. MatBase este de asemenea folosit intens la laboratoarele de bd din cadrul facultii de Matematic i Informatic a Universitii Ovidius din Constana, att pentru a ilustra modelarea i interogarea conceptual a datelor i cunotinelor, MMED, MRD, Datalog i conceptele cheie aferente (e.g. tranzacii, trgaciuri, evenimente, concuren, distribuire, nchideri tranzitive, semantica celor mai mici puncte fixe etc.), ct i programarea n SQL, Datalog, Access VB i ADO. MMED permite modelarea orientat obiect a datelor. Rigoarea sa matematic sporit (n raport cu MRD, MEA, MFD, de exemplu) confer schemelor de bd n MMED mai mare naturalee i putere de exprimare att semantic, ct i sintactic. Prima seciune a acestui ultim capitol prezint definiia schemelor de bd n accepiunea MMED. Cea de-a doua introducere colecia mulimilor (de valori ale atributelor, respectiv de obiecte). Subseciunea 5.2.2 introduce clasa mulimilor de obiecte cu cele dou subclase ale sale, entitile i asociaiile. n legtur cu acestea din urm sunt discutate pentru nceput doar grafurile i ierarhiile de asociaii. Seciunea 5.3 discut funciile (att cele de tip atribut, ct i cele structurale), tipurile de obiecte (echivalentul fiierelor abstracte din modelarea funcional), corespondena lor cu relaiile din MRD, coninutul bd, cheile i atributele calculate. Cheile sunt studiate n subseciunea 5.3.5, naintea tuturor celorlalte tipuri de constrngeri, nu doar pentru c sunt cele mai importante dintre toate, dar i pentru c pe teoria lor se bazeaz tot restul teoriei MMED. Subseciunea 5.3.6 este dedicat caracterizrii funciilor structurale: se demonstreaz c aceste funcii sunt reprezentani ai claselor de echivalen ale funcional dependenelor din MRD. Este formalizat apoi n 5.3.7 i principiul propagrii cheilor, pe baza cruia sunt implementate aceste funcii n modelul relaional. Seciunea 5.4 prezint cele 17 clase ale constrngerilor de integritate exprimabile n MMED: constrngerile obiect (extensia constrngerilor tuplu), constrngerile de domeniu, de existen, minimal injectivitile (dependenele cheie), incluziunea, egalitatea, reuniunea, disjuncia i partiionarea mulimilor, surjectivitatea, idempotena i egalitatea funciilor, sistemele de reprezentani, precum i reflexivitatea, simetria, antisimetria, tranzitivitatea i aciclicitatea grafurilor de asociaii binare. Seciunea 5.5 conine teoria asociaiilor: sunt definite, studiate i caracterizate formal funcionalitile interne i cheile structurale ale asociaiilor. n final, este propus i evaluat un algoritm eficient de asisten a proiectrii schemelor de asociaii. Astfel echipate, asociaiile se dovedesc un substitut mult mai puternic, riguros, natural i elegant oferit de MMED n locul dependenelor multivaluate i join din modelul relaional. Seciunea 5.6 definete nti noiunea de constrngere primitiv, care nglobeaz n MMED 16 din cele 17 tipuri (excepia fiind constituit de cele obiect). Pe baza unei noi accepiuni, orientat obiect, a compatibilitii semantice, sunt reformalizate n consecin anomaliile de actualizare a datelor, descrierile fundamentale i complete ale obiectelor precum i forma normal semantic a schemelor MMED. Aceasta din urm este dovedit a fi strict mai nalt dect FNDC; apogeul acestei seciuni l constituie teorema fundamental a MMED, ce precizeaz condiiile n care o schem de bd este semantic
80

normalizat. Subseciunea 5.6.2.3 pledeaz ns pentru primatul corectitudinii semantice a modelrii asupra normalitii schemelor (chiar dac acest lucru impune sacrificarea normalitii schemelor i recursul la constrngeri obiect), cu ajutorul a dou exemple relativ simple dar frecvente n practic (i anume modelarea constrngerilor de tip disjuncie a intervalelor de timp n care sunt ocupate resurse partajabile succesiv, dar nu i simultan, a crei soluionare general, adic gsirea i consacrarea de noi concepte matematice capabile s formalizeze elegant orice constrngeri de acest tip, rmne o problem deschis). Seciunea 5.7 prezint algoritmii liniari de translaie a schemelor de bd din MMED n MRD i MEA; ea include i teorema ce dovedete c schemele de bd relaionale astfel obinute sunt n FNDC i c aplicaia stabilit de acest algoritm este surjectiv dar neinjectiv. Aceasta conduce la definirea unei relaii de echivalen ntre schemele MMED, care motiveaz introducerea unui algoritm liniar i injectiv de traducere a schemei oricrei asociaii ntr-o schem echivalent ce face uz numai de funcii i chei. Pe baza acestui algoritm, se demonstreaz apoi c puterea expresiv a MEA este aceeai cu cea a MFD, deci c cele dou modele sunt echivalente. Subseciunea 5.7.4 ofer un exemplu de modelare n MMED, complet i corect, a unei probleme celebre i interesante propuse de Ullman, inclusiv traducerea ei n modelul relaional. Acest exemplu ofer pretextul unei comparaii concrete ntre abordarea relaional i cea propus de MMED. Seciunea 5.8 atrage atenia asupra capcanelor pe care adesea le ascund diagramele entiti-asociaii nchise, fie de o funcie circular, de un poligon funcional comutativ, ns de attea ori chiar i de cele implicnd i (sau numai) asociaii, nu neaprat binare. Sunt introduse cu aceast ocazie conceptele de diagram parial comutativ, respectiv diagram comutativ generalizat i este propus un algoritm corespunztor de asisten a modelrii diagramelor nchise. n seciunea 5.9 este prezentat modelarea ncruciat a MEA, MRD i MMED. Astfel, 5.9.1 prezint modelarea formal a MEA n MEA, i apoi MMED precum i schema relaional rezultat din traducerea schemei MMED conform algoritmilor prezentai n seciunea 5.7. Similar, 5.9.2 descrie MMED n el nsui (ceea ce constituie i cea mai compact formalizare cu putin a acestui model), n DEA i apoi n MRD (schem ce, evident, ar trebui s constituie nucleul proiectului metacatalogului de date al oricrui SGBD bazat pe acest model, ceea ce este, de exemplu, cazul MatBase), n timp ce 5.9.2 prezint acelai lucru pentru cel mai interesant fragment al MRD (i singurul curent implementat de altfel de majoritatea SGBD relaionale comerciale) i anume schemele n FNDC. Seciunea 5.10 ncearc sintetizarea unei metodologii de modelare conceptual a datelor, pornind de la formularea informal utiliznd DEA, trecnd la formalizare n termenii MMED, urmat de traducerea n MRD i apoi ntr-un SGBD relaional la dispoziie, totul exemplificat cu cteva subuniversuri clasice de interes i cu sublinierea greelilor tipice n fiecare dintre etapele modelrii. Seciunea 5.11 prezint limbajul de interogare a datelor MMEDQL, asociat MMED. Urmtoarele dou seciuni includ probleme de modelare conceptual a datelor propuse la examene, integral rezolvate i cu punctajul aferent, respectiv probleme propuse spre rezolvare. Capitolul se ncheie printr-o seciune final dedicat comentariilor privind evoluia MMED i a MatBase, precum i referinelor bibliografice aferente.

81

5.1

Schemele bazelor de date n MMED

Definiia 5.1. Schema oricrei bd n MMED este un cvadruplu (S, M, C, P ), unde: (S , ) este un poset 42 nevid de mulimi; M S S este o mulime finit nevid de funcii parial definite 43; C este o mulime finit de clauze Horn (nchise) numite constrngeri; P este o mulime finit de programe Datalog. Semnificaia simbolurilor S, M, C, P utilizate n definiia 5.1 de mai sus provine de la denumirea englez a noiunilor de mulime, funcie, constrngere, respectiv program, i anume: Set, Mapping, Constraint, Program. MatBase este de asemenea un SGBDC. Ecranul cu care debuteaz aplicaia, afind meniul principal, este cel prezentat n figura 5.1.

Fig. 5.1: Meniul principal al MatBase

5.2

Reprezentarea mulimilor n MMED

Definiia 5.2. La rndul su, S = V , unde: (, ) este un poset nevid de mulimi de obiecte; (V, ) este un poset nevid de mulimi de valori; este mulimea vid.

Poset (din Partially Ordered Set) = mulime parial ordonat De notat c parial definirea poate fi nlturat prin adugarea la orice codomeniu a unei valori distinse cu semnificaia valoare necunoscut. Acest lucru nu este uzual n bd, unde teoria valorilor nule distinge ntre cel puin trei tipuri de valori nule (n raportul ANSI sunt 17!). 82
42 43

Exemplul E5.1: {PERSOANE, LOCALITI, RI} , {NAT, RAT, BOOL, CHAR, DATE} V, unde: NAT este mulimea numerelor naturale, RAT a celor raionale, BOOL={adevrat, fals} CHAR este monoidul liber generat peste un alfabet oarecare (n general ANSI extins), iar DATE este mulimea datelor calendaristice. Ecranul afind meniul mulimilor dintr-o bd MatBase, care se obine selectnd Sets din meniul principal, este cel prezentat n figura 5.2.

Fig. 5.2: Meniul mulimilor MatBase

5.2.1 Valori

Orice bd sau baz de cunotine i deci model al datelor manipuleaz valori: numere, iruri de caractere, date calendaristice, constante booleene etc. MMED are ncorporat, ca atare, o colecie finit nevidV de mulimi de valori, parial ordonat prin incluziune. (V , ) este deci un poset. Mulimile dinV sunt, n general, infinite (dei orice implementare se va rezuma, desigur, la submulimi finite). Uzual,V include: BOOL = adevrat, fals, NAT INT RAT (naturalii, ntregii, raionalii), PRE RAT (preurile, i.e. submulimea tuturor numerelor raionale pozitive cu 2 zecimale), CHAR* (monoidul liber generat peste un alfabet oarecare fixat CHAR, n general ANSI extins), DATA (mulimea datelor calendaristice), TIMP (mulimea valorilor de timp ntr-o interpretare oarecare fixat, de exemplu secunde) etc. Aceste mulimi de valori fundamentale nu pot fi niciodat modificate sau eliminate din MatBase. Cel puin o submulime a NAT face ntotdeauna parte dinV.
83

MMED ofer n plus trei constructori de mulimi, ce pot fi aplicai i pentru a defini noi mulimi de valori i anume: Enum, care presupune enumerarea elementelor mulimii, ASet, care este un evaluator de operaii algebrice cu mulimi, i PSet, care este un evaluator de mulimi definite cu predicate de ordin nti. Exemplul 5.2: Enum(CULORI)= 'rou','oranj','galben','verde','albastru' Exemplul 5.3: ASet(A) = A B C Exemplul 5.4: PSet(AN_COLAR_2003) = xDATA01.10.03 x 30.06.04 Ecranul afind colecia mulimilor de valori dintr-o bd MatBase, care se obine selectnd Values din meniul Sets, este prezentat n figura 5.3.

Fig. 5.3: Colecia mulimilor de valori pentru o bd MatBase

5.2.2 Obiecte

MMED include i o colecie finit nevid de mulimi de obiecte, parial ordonat, despre care intereseaz memorarea de date; (, ) este deci tot un poset. Definiia 5.3. este partiionat n dou clase = E , unde:

E este o clas nevid de mulimi de entiti, iar este o clasa de mulimi de asociaii,
corespunznd mulimilor atomice precum persoane, cri, opusuri muzicale, idei etc., respectiv produselor carteziene (i.e., n particular, relaiilor matematice, cu excepia celor binare funcionale, care sunt modelate, vezi 5.3.2 cu ajutorul funciilor structurale) precum relaiile de prietenie, mprumuturile de la o bibliotec, interpretrile muzicale,
84

teoriile formale, stocurile, zborurile aeriene etc. Coleciile mulimilor de valori, respectiv de obiecte sunt disjuncte prin definiie. Exemplul 5.5: dac, de exemplu, s-ar dori memorarea de date despre culori, altele dect numele lor (de exemplu: lungimea de und, temperatura, poziia n spectru etc.), trebuie declarat o mulime de culori n , care nu ar avea nici o legtur cu CULORI definit mai sus nV prin enumerare. i mulimile de obiecte pot fi teoretic infinite, dei practic ele vor fi ntotdeauna finite. nu poate fi vid: ea trebuie s includ cel puin o mulime de entiti. Ecranul afind colecia mulimilor de obiecte dintr-o bd MatBase, care se obine selectnd All Objects din meniul Sets, este prezentat n figura 5.4. n MatBase exist peste 60 de mulimi de obiecte sistem, majoritatea transparente pentru proiectantul sau utilizatorul de bd, dar necesare sistemului pentru gestionarea utilizatorilor, a drepturilor lor de acces, a schemelor de bd i tranzaciilor definite de acetia etc. n funcie de drepturile de acces pe care le au, ei pot (explicit sau implicit) s modifice, adauge i/sau s tearg elemente n/din ele. Exemplul 5.6: UTILIZATORI, TIP_ACCES, CONCEPTE, ACCES_CONCEPT, IDENTIFICATORI, SINONIME, BAZE_DATE, MULIMI, ENTITI, FUNCII, STRUCT_PROD_FUNCT, ASOCIAII, SORTURI_ASOC, ATRIBUTE, CHEI, CONSTRNGERI sunt toate obiecte sistem, fie ele mulimi de entiti, fie mulimi de asociaii.
5.2.2.1 Entiti

Exemplul 5.7: {UTILIZATORI, CONCEPTE, TIP_ACCES, SINONIME, BAZE_DATE, ENTITI, MULIMI, FUNCII, ASOCIAII, ATRIBUTE, CHEI, CONSTRNGERI} E, adic aparin clasei mulimilor de entiti. Evident c utilizatorii MatBase nu pot terge nici una din cele peste 65 mulimi de entiti sistem, dar le modific coninutul odat cu declararea de noi scheme de bd sau cu ocazia actualizrii schemelor existente. Desigur c i utilizatorii MatBase pot defini mulimi de entiti. Ecranul afind colecia mulimilor de entiti dintr-o bd MatBase, care se obine selectnd Entities din meniul Sets, este prezentat n figura 5.5. Exemplul 5.8: PERSOANE, CADRE_DIDACTICE, ANGAJAI, STUDENI, CURSURI, FACULTI, UNIVERSITI sunt entiti definite de utilizator. n general, construcia acestor mulimi se face enumerativ, dei sunt cazuri n care este nevoie i de constructorii ASet i PSet pentru aceasta. Exemplul 5.9: ASet(PERSOANE) = CADRE_DIDACTICE ANGAJAI STUDENI PSet(PROFESORI) = x CADRE_DIDACTICE Titlu(x) = 'profesor'.
5.2.2.2 Asociaii Mulimile de obiecte sunt interconectate i ierarhizate n aproape orice subunivers de interes nu doar cu ajutorul incluziunii, ci i cu ajutorul relaiilor (matematice). Definiia 5.4. Orice asociaie A este o pereche A = (SA, GA), unde:

SA = (MSA ;MKA) este schema asociaiei; GA este graful asociaiei.

85

Fig. 5.4: Colecia mulimilor de obiecte pentru o bd MatBase

n mod evident, asociaiile nu sunt concepte fundamentale, ci derivate [164]: orice asociaie poate fi nlocuit cu o mulime de entiti, plus o mulime de funcii structurale (corespunztoare proieciilor sale canonice, al cror produs are imaginea egal cu graful asociaiei) i una de constrngeri de tip cheie (i.e. minimal injectiviti). Pentru teoria asociaiilor, a se vedea 5.5. Exemplul 5.10: n MatBase, UTILIZATORI, CONCEPTE i TIP_ACCES sunt suporii asociaiei ternare ACCES_CONCEPT, care memoreaz diversele drepturi de acces (e.g. citire, scriere, creare, tergere etc.) pe care le au utilizatorii la conceptele gestionate de sistem (e.g. bd, entiti, asociaii, atribute, funcii, constrngeri etc.). Un triplet oarecare (u, c, a) al acesteia memoreaz faptul c utilizatorul u are asupra conceptului c dreptul a.

86

Fig. 5.5: Colecia mulimilor de entiti pentru o bd MatBase

Exemplul 5.11: ntr-o bd universitar, ABSOLVIRE ar putea fi o asociaie binar definit peste STUDENI i CURSURI. O pereche oarecare (s, c) a ei memoreaz faptul c studentul s a absolvit disciplina predat la cursul c. Colecia tuturor relaiilor matematice de interes, definite peste mulimi de obiecte din i care nu sunt funcii 44 alctuiesc clasa asociaiilor, notat . Orice bd real include cel puin o asemenea mulime, dei acest lucru nu este obligatoriu.

44

Vom studia n seciunea 5.4 asociaiile "degenerate" n funcii. 87

Evident c utilizatorii MatBase nu pot terge nici una din cele peste 10 mulimi de asociaii sistem oferite 45, dar pot s le modifice coninutul odat cu declararea de noi scheme de bd sau cu ocazia actualizrii schemelor existente.
5.2.2.2.a Scheme

Definiia 5.5. Schema unei asociaii A este o pereche SA = (MSA ;MKA), cu:

MSA o mulime nevid de supori; MKA P (MSA) o mulime nevid de chei structurale.
Exemplul 5.12: Asociaia MPRUMUTURI_CRI are schema (CRI, CITITORI, DATE-MPRUMUTURI; {CRI, DATE_MPRUMUTURI}). Denumirea de cheie structural provine din faptul c fiecrei asemenea submulimi de supori i corespunde biunivoc produsul minimal injectiv al proieciilor carteziene canonice ale suporilor respectivi.
5.2.2.2.b Grafuri Definiia 5.6. Graful asociaiei GA este o submulime nevid a produsului cartezian a mulimilor din MSA (i.e a suporilor). Din definiia relaiilor matematice, ne reamintim c acestea sunt privite pur i simplu ca submulimi ale produsului cartezian peste mulimile suport. Relaiile matematice genereaz deci noi mulimi. n MMED, aceste noi mulimi se numesc grafuri de asociaii i sunt evident considerate tot mulimi de obiecte. Vom vedea ns, n seciunea 5.5.1, c grafurile asociaiilor nu sunt doar mulimi amorfe de obiecte, ci ele sunt structurate de funcionaliti interne, exprimabile cu ajutorul constrngerilor de tip minimal injectiviti. MMED pstreaz pentru asociaii definiia alternativ a relaiilor matematice din modelul relaional, unde ordinea suporilor este nlocuit cu roluri. Desigur c acelai lucru s-ar putea obine considernd o relaie de echivalen adecvat peste mulimea tuturor produselor carteziene posibile (peste o mulime de supori oarecare), echivalen care s partiioneze produsele n clase coninnd elemente echivalente ce difer ntre ele doar printr-o permutare a suporilor. Esenial ns n orice asemenea abordare imun la permutri este, evident, cerina unicitii numelor suporilor oricrei asociaii.

Exemplul 5.13: ntr-o bd universitar, ar putea fi nevoie de o asociaie COND_NSCRIERE care s memoreze, pentru fiecare curs, submulimea cursurilor a cror absolvire prealabil condiioneaz nscrierea la acel curs. Matematic, aceast relaie este deci definit peste CURSURI CURSURI. n bd ns, trebuie asociat un rol cel puin uneia dintre cele dou apariii ale CURSURI, pentru a putea distinge unic suporii prin nume. De exemplu, COND_NSCRIERE ar putea fi definit peste CURSURI (la care se permite nscrierea) i PRECONDIII CURSURI (a cror absolvire condiioneaz nscrierea). Ecranul afind colecia mulimilor de asociaii dintr-o bd MatBase, care se obine selectnd Relationships din meniul Sets, este prezentat n figura 5.6. n MatBase, nu doar pentru a permite unicitatea numelor suporilor oricrei asociaii, ci i pentru a da utilizatorilor posibilitatea de a defini sinonime pentru oricare dintre conceptele manipulate, sunt oferite trei mulimi de entiti i dou funcii sistem dedicate acestui scop i anume (vezi i problema 5.26):
Alte asemenea exemple, pe lng ACCES_CONCEPT, ar fi SORTURI_ASOC, care memoreaz pentru fiecare asociaie mulimile sale suport i STRUCT_PROD_FUNCT, care, pentru fiecare funcie produs de funcii, memoreaz funciile ce compun produsul respectiv. 88
45

Fig. 5.6: Colecia mulimilor de asociaii pentru o bd MatBase

CONCEPTE, o reuniune a mulimilor de entiti de tip (scheme de) bd, entiti, asociaii, atribute, funcii, constrngeri etc., adic a orice este identificat prin (unul sau mai multe) nume. SINONIME, ale crei elemente sunt toate numele de concepte cunoscute sistemului. IDENTIFICATORI, care este mulimea ct a SINONIME factorizat de relaia de echivalen sinonimie (dou sinonime sunt echivalente dac i numai dac denumesc acelai concept). Sinonimie : SINONIME IDENTIFICATORI, surjecia canonic asociat relaiei de echivalen sinonimie. Identificare : IDENTIFICATORI CONCEPTE, surjecia de identificare. De remarcat c IDENTIFICATORI este un sistem de reprezentani pentru SINONIME, adic IDENTIFICATORI SINONIME, iar Sinonimie este idempotent.
5.2.2.2.c Ierarhii de asociaii MMED ncurajeaz n mod natural construcia ierarhic de asociaii peste grafuri ale altor asociaii 46, fr nici o restricie de adncime a ncuibrii lor una n alta. Aceasta permite att o proiectare structurat a schemei bd, ct i garantarea meninerii implicite a unor constrngeri (ce nu mai trebuie deci explicitate). O factorizare corect a schemei de bd cu ajutorul ierarhizrii asociaiilor asigur, n plus, normalitatea schemei i evit anomaliile de actualizare.
A se compara cu modelul entiti-asociaii original, unde asociaiile se pot construi doar peste entiti, nu i peste asociaii. 89
46

Exemplul 5.14: Fie LOC mulimea de localiti n care, de-a lungul timpului, au fost gzduite concursuri olimpice, iar PROBE mulimea acestor concursuri ce constituie olimpiadele sportive. Pentru a memora date despre desfurarea concursurilor, trebuie definit i o asociaie LOCALIZ_CON-CURS peste cele dou mulimi de entiti suport de mai sus (LOC i PROBE, vezi DEA din figura 5.7 i bd relaional din figura 5.8). O pereche oarecare (l, c) LOCALIZ_CONCURS memoreaz faptul c n localitatea l a avut loc un concurs olimpic c. Aceast asociaie binar nu este evident funcional, deoarece unele concursuri se desfoar n mai multe localiti, iar ntr-o localitate se organizeaz adesea mai multe concursuri. Dac s-ar dori i informaii privind participarea sportivilor la aceste concursuri, cea mai natural modelare ar considera o relaie binar PARTICIPRI, definit peste mulimea de entiti SPORTIVI i peste graful asociaiei LOCALIZ_CONCURS. O pereche oarecare (s, (l, c)) PARTICIPRI memoreaz faptul c sportivul s a luat parte la concursul (l, c). Nici aceast asociaie nu este funcional, deoarece un sportiv poate participa la mai multe concursuri, iar concursurile, evident, nu sunt organizate pentru un singur sportiv! Schema MMED a acestei bd, simplificat pentru a furniza doar numele diverselor tipuri de entiti precum i definiia tipurilor de asociaii implicate este deci urmtoarea: LOC PROBE SPORTIVI LOCALIZ_CONCURS = (LOC, PROBE) PARTICIPARI = (SPORTIVI, LOCALIZ_CONCURS) Desigur c PARTICIPRI ar putea fi definit direct peste cele trei mulimi de entiti suport, chiar dac acest lucru este nenatural. O asemenea modelare nenormalizat ar putea ns da natere la redundane inutile i deci la anomalii de actualizare: de exemplu, dac ar interesa i data de nceput, de sfrit (ori durata) concursurilor, bugetul lor, sau arbitrii ori numrul de spectatori etc., aceste informaii ar fi evident multiplicate inutil pentru fiecare dintre sportivii participani la concursuri! PARTICIPRI

SPORTIVI

LOCALIZ_CONCURS

PROBE
Fig. 5.7 Un exemplu de ierarhie de asociaii 90

LOC

5.3

Funcii

Definiia 5.7. Mulimea funciilor M este suma direct M = A F, unde:

A V este o mulime finit nevid de funcii pariale numite atribute; F este o mulime finit de funcii pariale numite funcii structurale.
Ecranul afind meniul funciilor dintr-o bd MatBase, care se obine selectnd Mappings din meniul principal, este cel prezentat n figura 5.9.
5.3.1 Atribute

n orice bd sau bc, obiectele prezint interes n special prin prisma proprietilor lor. Exemplul 5.15: despre PERSOANE intereseaz, de obicei, numele, prenumele, sexul, data naterii, un cod de identificare (codul numeric personal, numrul dosarului de asigurare social etc.), domiciliul, numrul de telefon etc. Aceste proprieti descriu, caracterizeaz i disting unic obiectele. i n MMED, la fel ca i n MRD, proprietile fundamentale ale obiectelor sunt formalizate cu ajutorul atributelor. Ca atare, MMED ofer i o mulime finit nevid de atribute A . Definiia 5.8. Un atribut este o funcie, n general parial, definit pe o mulime de obiecte O i cu valori ntr-o mulime de valori V V , i.e. A V . Exemplul 5.16: Iat cteva exemple de atribute: Nume : PERSOANE CHAR(64) Sex : PERSOANE 'F', 'M' DataNatere : PERSOANE DATA Localitate : LOCALITI CHAR(32) etc. Ecranul afind mulimea atributelor dintr-o bd MatBase, care se obine selectnd Attributes din meniul Mappings, este prezentat n figura 5.10. De notat c, datorit necesitii de a permite valori nule, total definirea funciilor este privit i n MMED ca o constrngere, exact ca n MRD (i anume, trivial, drept un caz particular al constrngerilor de existen). Exemplul 5.17: dac atributul Nume de mai sus nu trebuie s admit valori nule (i.e. trebuie s fie total definit), acest lucru trebuie explicit specificat i se face, de exemplu, astfel: Nume : PERSOANE CHAR(64), total. MMED accept urmtoarea prescurtare convenabil pentru definiia atributelor: dac ea este plasat imediat dup cea a mulimii de obiecte domeniu corespunztoare (deci nici o ambiguitate nu este posibil) atunci domeniul poate fi omis, fiind subneles. Exemplul 5.18: urmtoarele definiii sunt echivalentele abreviate ale celor de mai sus: PERSOANE Nume CHAR(64), total Sex 'F', 'M' DataNatere DATA Exemplul 5.19: n MatBase, A este iniializat cu peste 70 de atribute sistem, dintre care, de exemplu: Parola : UTILIZATORI CHAR(16) Den_tip_acces : TIP_ACCES 'interzis', 'citire', 'inserie', 'tergere', 'modif.', 'cit.struct.', 'act.struct.', 'creare bd' Aritate_asoc : ASOCIAII NAT.
91

LOC (#Loc, {Localitate,ara}) ara #ara, Localitate, ara #Loc Localitate 1 2 3 4 5 6 7 8 Albertville Chamonix Grenoble Atlanta Chicago Los Angeles New York San Francisco ara 3 3 3 2 2 2 2 2

RI (#ara, ara) PROBE (#Proba, {Disciplina,Olimp.}) ara Disciplina #Discipl.., #ara ara Olimp. #Olimp., 1 RO Disciplina, Olimp. 2 USA Disciplina Olimp. #Proba 3 F 1 1 2 4 CAN 5 BR 2 2 2 6 S 7 AG 3 4 1 DISCIPLINE (#Discipl., 4 5 1 Discipl.) Discipl. #Discipl. Discipl. OLIMPIADE (#Olimp., An) 1 fotbal An, Tip 2 tenis An Tip #Olimp. 3 100mG 1 1994 I 4 hochei 2 1996 V 5 skiF 3 1998 I 6 bob4 4 2000 V

LOCALIZ_CONCURS (#LocConcurs, {Loc,Concurs}) Loc #Loc, Concurs #Proba, Loc, Concurs #LocConcurs 1 2 3 4 5 6 7 8 Loc 4 5 6 7 8 1 2 3 Concurs 1 1 1 1 1 3 3 3 DataInc. 15.06.96 20.06.96 16.06.96 15.06.96 18.06.96 17.01.94 19.01.94 18.01.94 DataSf. 15.07.96 12.07.96 14.07.96 12.07.96 10.07.96 10.02.94 05.02.94 07.02.94 Spect. 250K 200K 300K 250K 150K 20K 10K 15K ncasri 150K$ 100K$ 200K$ 250K$ 100K$ 75K$ 25K$ 50K$

SPORTIVI (#Sp) ara #ara, ara, Prenume, Nume, Sex #Sp. Prenume Nume Sex 1 2 3 4 5 6 7 8 Gheorghe Gheorghe Jean Diego R. Dean Owen Michael Popescu Hagi Tigana Maradona Ronaldo Evason Nolan Nylander M M M M M M M M

ara 1 1 3 7 5 4 4 6

PARTICIPRI(#Part,{Sportiv,LocConcurs}) Sportiv #Sp., LocConcurs #LocConcurs, Sportiv, LocConcurs #Part Sportiv LocConcurs Prezene 1 1 1 2 2 1 3 1 3 2 1 2 4 2 2 1 5 2 3 1 6 4 3 1 7 8 6 4

Fig. 5.8: O bd cu o ierarhie de asociaii

92

Fig. 5.9: Meniul funciilor MatBase

Desigur c aceste atribute pot fi cel mult vizualizate de utilizatori (dac au acest drept de acces) dar n nici un caz terse, dei valorile lor sunt modificate explicit sau implicit odat cu definirea de noi (scheme de) bd sau actualizarea bd existente. De remarcat c nici MMED nu permite atribute nenormalizate, adic cu valori n produse carteziene de mulimi de valori, cu excepia celor lund valori n mulimile sistem DATA sau TIMP (cci, trivial, ambele aceste mulimi de valori sunt, de fapt, produse carteziene) 47. Este natural i obligatorie ns asigurarea posibilitii de a defini atribute i pe grafuri de asociaii. Exemplul 5.20: revenind la Exemplul 5.11, s-ar putea dori adugarea urmtoarelor atribute definite pe asociaia ABSOLVIRE: DataAbsolvirii DATA Nota NAT. Exemplul 5.21: similar, referindu-ne de aceast dat la Exemplul 5.14, s-ar putea defini pe asociaia LOCALIZ_CONCURS atributele: Data_nceput DATA Data_sfrit DATA ncasri PRE TotalSpectatori NAT.
Evident c rmne la latitudinea implementrilor MMED dac aceste mulimi de valori de tip produse carteziene sunt memorate ca tupli sau ca valori atomice, n funcie de criteriul principal de optimizare ales (spaiu de memorare sau timp de rspuns). n modelare ns, chiar i acestea sunt privite drept mulimi atomice. 93
47

Fig. 5.10: Mulimea atributelor pentru o bd MatBase

5.3.1.1 Identificatori de obiecte

MMED furnizeaz automat pentru orice mulime de obiecte un identificator de obiect (idob), folosit exclusiv pentru identificarea (sintactic) unic i minimal a obiectelor i tipurilor n bd. Notat cu numele mulimii de obiecte prefixat de caracterul '#', o asemenea cheie este ntotdeauna peste tot definit (i.e. nu admite valori nule), are codomeniul NAT i nu face dect s numeroteze obiectele n mod unic (n cadrul mulimii de obiecte respective): #O : O NAT, #O injectiv, deci cheie. Cum cheile sunt echivalente (vezi propoziia 4.10), din consideraii legate de optimizarea procesrii legturilor ntre tipuri, navigrii prin schema bd i interogrilor, MMED distinge unic cu ajutorul identificatorilor de obiect i tipurile de obiecte. Exemplul 5.22: #PERSOANE: PERSOANE NAT este identificatorul de obiect ataat mulimii PERSOANE. De remarcat c MMED adaug cte un identificator de obiect i grafurilor de asociaii, n primul rnd pentru evitarea anomaliilor de actualizare. Exemplul 5.23: Revenind la Exemplul 5.14, identificatorul de obiect ataat asociaiei LOCALIZ_CONCURS este: #Localiz_Concurs : LOCALIZ_CONCURS NAT Evident c, n cursul traducerii schemelor MMED n MRD, identificatorii de obiect sunt implementai prin chei surogat.
94

De remarcat abrevierea standard pentru funciile (minimal) injective folosind dubla sgeat. Exemplul 5.24: Definiia de mai sus este echivalent cu: cheie #Localiz_Concurs : LOCALIZ_CONCURS NAT.
5.3.2 Funcii structurale

n componena MMED intr i o mulime finit de funcii structurale F (prescurtat funcii). Definiia 5.9. O funcie structural este o funcie, n general parial, definit pe o mulime de obiecte O1 i cu valori ntr-o mulime de obiecte O2. Orice asemenea funcie structureaz suplimentar posetul (, ). 48 Nici F nu este niciodat vid n vreo implementare, chiar dac schema bd utilizator nu ar conine funcii, cci MatBase are nevoie de peste 60 de funcii sistem. Exemplul 5.25:
Sinonimie : SINONIME IDENTIFICATORI, Proprietar_BD : BAZE_DATE UTILIZATORI, Domeniu : FUNCII OBIECTE, Codomeniu : FUNCII MULIMI F. Desigur c nici aceste funcii nu pot fi eliminate din model de nici un utilizator, dar, n funcie de drepturile de acces pe care le au, utilizatorii pot (explicit sau implicit) s adauge sau s tearg elemente n/din ele.

Proiectanii / utilizatorii bd pot defini i ei funcii n MMED. Exemplul 5.26: Exemple de funcii structurale definite de utilizator sunt: nscriere : STUDENI CURSURI Curs : CURSURI FACULTI Predare : CURSURI CADRE_DIDACTICE LocMunc : CADRE_DIDACTICE CATEDRE Organizare : CATEDRE FACULTI Decan : FACULTI CADRE_DIDACTICE. Formal, F , adic F este inclus n mulimea tuturor funciilor definite pe i cu valori n mulimi din . Evident c funciile sunt un caz particular de relaii, deci de asociaii (i anume, asociaii binare funcionale). Spre deosebire de acestea ns, funciile nu genereaz noi mulimi de obiecte (ci doar stabilesc pointeri ntre obiecte existente) i nici nu au o structur intern complex 49, aa cum vom vedea n seciunea 5.3.7 c este, n general, cazul asociaiilor. Din acest punct de vedere, desigur, am putea considera funciile ca fiind nite asociaii binare degenerate. Ecranul afind mulimea funciilor structurale dintr-o bd MatBase, care se obine selectnd Structural functions din meniul Mappings, este prezentat n figura 5.11.
5.3.2.1 Funcii unitate

Definiia 5.10: O funcie 1M : M M definit astfel: 1M(x) = x ,xM, se numete funcie unitate. Exemplul 5.27: Pentru mulimea RI, din figura 5.8, 1RI(2) = 2.
Desigur c i atributele sunt funcii matematice; ele ns nu structureaz schema bd, ci doar "valueaz" proprietile obiectelor modelate. 49 Funcionalitatea n sine constituie structura intern a acestor asociaii binare. Funciile injective au, evident, dou funcionaliti, att de la domeniu la codomeniu, ct i invers. 95
48

Fig. 5.11: Mulimea funciilor structurale pentru o bd MatBase

Evident c, astfel definite, funciile unitate sunt funcii structurale. Importana lor este pus n eviden n subseciunea 5.8.3. Matematic, pot fi desigur definite funcii unitate i pe mulimi de valori, ns acestea nu au nici o relevan din punctul de vedere al bazelor de date.
5.3.3 Tipuri de obiecte

Definiia 5.11. Definim urmtoarea relaie de echivalen (egalitatea domeniilor): orice funcii f, gM sunt echivalente dac i numai dac, prin definiie, au acelai domeniu (i.e. dom(f) = dom(g)). M este canonic partiionat de aceast relaie de echivalen, care grupeaz toate funciile definite pe o aceeai mulime de obiecte, iar mulimea ct astfel obinut este evident izomorf cu . Definiia 5.12. Reprezentanii claselor de echivalen alctuind aceast mulime ct se numesc tipuri (de obiecte). Ca atare, tipul de obiecte corespunztor unei mulimi $ fixate oarecare de obiecte O este: O = f M dom(f) = O M . Notaia folosit pentru tipuri este deci cea standard n matematic pentru clasele de echivalen: numele reprezentantului clasei cruia i se adaug cciula. Desigur c, prin abuz notaional, ca i n matematic, cciula poate fi omis atunci cnd nu este nici un pericol de ambiguitate. Tipurile de obiecte sunt adesea interpretate drept produsul familiei tuturor atributelor definite pe mulimea respectiv de obiecte: $ O = a : O codom( a ).
dom ( a ) =O

96

Definiia 5.13. Valoarea

dom ( a ) =O

a ( o ) pentru un element oarecare oO, constituie des-

crierea fundamental (primitiv) a acelui obiect n bd (fundamental doar, deoarece o descriere complet trebuie s includ i legturile sale cu alte obiecte prin intermediul asociaiilor). Exemplul 5.28: Orice persoan ar putea fi descris de tipul de obiecte: $ P = #Persona, Nume, Prenume, Sex, DataNaterii, LocNatere, notat alternativ cu: $ P = #PersonaNumePrenumeSexDataNateriiLocNatere.
De notat c tipul asociaiilor conine implicit toate proieciile canonice aferente, deoarece altfel nu ar putea fi distinse elementele asociate.

Exemplul 5.29: Revenind la Exemplul 5.14 (a se vedea figura 5.5), tipul P corespunztor asociaiei PARTICIPRI include proieciile canonice: Sportiv = prSPORTIVIPARTICIPRI i LocConcurs = prLOCALIZ_CONCURSPARTICIPRI. n absena oricreia dintre ele, evident c nu am putea stabili graful acestei asociaii. n concluzie, orice participare ar putea fi descris de tipul de o$ biecte: P = #ParticipriSportivLocConcursPrezene. Similar, tipul L corespunztor asociaiei LOCALIZ_CONCURS include proieciile canonice: Loc = prLOC LOCALIZ_CONCURS i Concurs = prPROBELOCALIZ_CONCURS. Orice localizare a concursurilor ar putea fi descris de tipul de obiecte: L = #LocConcursLocConcursDataInc.DataSf.Spect.ncasri.
5.3.4 Instane

Dat fiind orice funcie : A B, ne reamintim c imaginea ei este mulimea valorilor calculate de funcie: Im() = (A) = y Bx A, y = (x) B. Exemplul 5.30: n bd din figura 5.5, imaginea atributului ara (definit pe RI) este {RO,USA,F,CAN,BR,S,AG}, n timp ce imaginea funciei structurale ara (definit pe LOC) este {2,3}.
Definiia 5.14. Pentru orice mulime de obiecte O Im() se numete instan (sau coninut) a(l) mulimii; se numete instan (sau coninut) a(l) unei bd reuniunea imaginilor tuturor tipurilor definite n schema acelei bd. Dac este colecia tuturor mulimilor de obiecte, atunci instana bd este notat, prin extensie, cu: Im( ) = O Im(). Exemplul 5.31: n bd din figura 5.5, instana mulimii de obiecte PARTICIPRI este exact coninutul tabelei omonime, adic mulimea liniilor sale; instana ntregii bd este reuniunea coninuturilor tuturor celor opt tabele ale sale.
5.3.5 Chei

$ Definiia 5.15. Orice (sub)produs K al unui tip oarecare O se numete cheie (a lui O) dac i numai dac (privit ca un produs de funcii) K este minimal injectiv (adic dac este injectiv i nici o submulime proprie a sa nu este injectiv). Evident c orice atribut injectiv sau funcie structural injectiv este cheie i c orice tip poate avea mai multe chei simultan. Trivial, doar valorile cheilor identific unic obiectele n bd.
97

Exemplul 5.32: Capitala : RI LOCALITI este injectiv, deci cheie; produsul SerieBINrBI : PERSOANE CHAR(2)NAT(6) este minimal injectiv, deci cheie.

$ Definiia 5.16. Orice submulime S a unui tip oarecare O se numete supercheie (a lui O) dac i numai dac (privit ca un produs de funcii) S este injectiv (dar nu neaprat minimal injectiv). Evident, orice cheie este o supercheie i orice funcie injectiv este supercheie. Propoziia 5.17. Orice tip de obiecte minus identificatorul de obiect corespunztor este supercheie. 50 Corolarul 5.18. Orice tip de obiecte minus identificatorul de obiect corespunztor are cel puin o cheie. 51 Se observ c orice tip poate avea mai multe chei (ntotdeauna cel puin dou: identificatorul de obiect al mulimii i nsui tipul minus identificatorul de obiect corespunztor sau o submulime a acestuia). Definiia 5.19. n cazul asociaiilor, cheile formate numai din proieciile canonice se numesc chei structurale.
Exemplul 5.33: MagazieProdus este cheia structural a asociaiei STOCURI (unde Magazie i Produs sunt abrevieri ale prMAGAZIISTOCURI, respectiv prPRODUSESTOCURI).
5.3.6 Caracterizarea funciilor structurale

Funciile structurale pot fi privite drept reprezentani ai unor clase de echivalen alctuite din funcional dependene. Definiia 5.20. Fie S o mulime i f o funcie definit pe S; definim relaia nucleu ataat funciei f prin: Kerf = {(x,y)SSf(x)=f(y)}. Definiia 5.21. Fie S o mulime i f, g dou funcii total definite pe S; spunem c g depinde funcional de f (sau f determin funcional g) i notm cu f g dac i numai dac Kerf Kerg. Relaia f g se numete funcional dependen (fd).
Exemplul 5.34: Fie S = PERSOANE, f = CNP, g = Nume; evident c ntre aceste dou atribute exist fd CNP Nume. Propoziia 5.22.(caracterizarea fd): f g ! h: Imf Img a.. g = h f. Demonstraie: () Fie funcia h : Imf Img a.. yImf, h(y) = z, unde y = f(x) i z = g(x). Demonstrm c h este total definit: yImf, xS, y = f(x); cum g este total definit, xS, zImg, z = g(x) yImf, h(y) = z. Demonstrm c h este bine definit: fie t, uImf, t = u; din definiia lui h , x,yS a.. h(t) = v, unde t=f(x), v=g(x), iar h(u)=w, unde u=f(y) i w=g(y); t=u f(x) = f(y) (x,y)Kerf; dar Kerf Kerg (x,y)Kerg g(x) = g(y) v = w h(t) = h(u). Demonstrm c g = h f; xS, notm z = g(x)Img i y = f(x)Imf; conform definiiei lui h, h(y) = z h(f(x)) = g(x) h f = g. Demonstrm c h este unic: presupunem c h' : Imf Img a. h' f = g xImf, yS, x = f(y) a.. h'(f(y)) = g(y); conform definiiei lui h, h(x) = g(y) h(x) = h'(x) h h'. () Presupunem prin reducere la absurd c: f g; Kerf Kerg (x,y)Kerf a.. (x,y)Kerg (x,y)S2, f(x) = f(y) i g(x) g(y); cum h este funcie, din f(x) = f(y)
Demonstraia este evident, cci mulimile (deci i cele de obiecte) nu admit duplicate; ca atare, orice tip e injectiv. 51 n cel mai ru caz, cheia este ntreg tipul! 98
50

h(f(x)) = h(f(y)); conform definiiei lui h g(x) = g(y) contradicie cu Q.e.d. presupunerea fcut f g. Propoziia 5.34. (caracterizarea funciilor structurale) : F, o funcie : A B

unde A,B i kA A cu proprietatea c kA este cheie i b B urmtoarele dou afirmaii sunt adevrate:
(i ) k A b (ii) exist o unic funcie fd : ImkA Imb a.. fd kA = b . A B
kA ImkA fd b Imb

Demonstraie: (i) Fie (x,y)KerkA; cum kA este cheie kA injectiv x = y b(x) = b(y) (x,y)Kerb. (ii) Definim fd : ImkA Imb a.. yImkA, fd(y) = z, unde y = kA(x) i z = b(x). Demonstrm c fd este total definit: yImkA, xA, y = kA(x); cum bd este total definit, xA, zImb, z = bd(x). Demonstrm c fd este bine definit: fie t, uImkA, t = u; conform definiiei lui fd, x,yA a.. fd(t) = v, unde t = kA(x), v = b(x) i fd(u) = w, unde u = kA(y) i w = b(y); t = u kA(x) =kA(y) x = y (kA este cheie, deci injectiv) bd(x) = bd(y) v = w fd(t) = fd(u). Demonstrm c b = fdkA; xA, notm z = b(x)Imb i y = kA(x)ImkA; conform definiiei lui fd, fd(y) = z fd(kA(x)) = b(x) fd kA = b. Demonstrm c fd este unic: presupunem c fd' : ImkA Imb a.. fd' kA = b; xImkA, yA, x = kA(y) a.. fd'(kA(y)) = b(y); conform definiiei lui fd, fd(x) = b(y) fd(x) = fd'(x) fdfd'. Q.e.d. Observaia 5.35:

a) m 2, cci orice tip are, pe lng identificatorul de obiect, cel puin o cheie. b) dac m este numrul cheilor tipului A iar n este cardinalul tipului B , atunci este reprezentantul clasei de echivalen a celor mn funcional dependene de forma kA i bj, kA i A kA i cheie, bj B . c) Utilizatorul MMED nu are nevoie s specifice nici o FD inter-tipuri; specificarea funciilor din F este suficient n acest sens. d) Comparativ cu fd, funciile structurale sunt, d.p.d.v. semantic, mult mai naturale, iar d.p.d.v. sintactic mai compacte. e) Corobornd subpunctul de mai sus cu observaia (5.4.b), rezult c n MMED nu este nevoie de specificarea nici unei FD ntre atributele din A . De notat i c, exact ca n cazul atributelor, pentru a permite valori nule, total definirea funciilor structurale este de asemenea considerat ca fiind o constrngere.
5.3.7 Formalizarea principiului propagrii cheilor

Evident c, atunci cnd traducem funciile structurale n MRD, ar fi o risip de spaiu s le implementm printr-o tabel; mult mai economic, ele pot fi implementate ca atribute, conform aa numitului principiu al propagrii cheilor, enunat deja n subseciunea 2.5.1 i formalizat de urmtoarea teorem:
99

Teorema 5.36.(principiul propagrii cheilor): pentru orice funcie : A B

F, i pentru orice cheie k, k B , exist o unic funcie p a.. p = k .

A p B k

Imk Demonstraie: Definim p: A Imk a.. xA, p(x) = y, unde y = k(x). Demonstrm c p este total definit: xA, yImk, y = k(x) = p(x). Demonstrm c p este total definit: fie x,yA, x = y; conform definiiei lui k, k(x) = =k(y) p(x) = p(y). Demonstrm c p = k f: xA, notm prin y = k(x)Imk; conform definiiei lui p, p(x) = y k(f(x)) = p(x) k f = p. p este unic: presupunem c p' : A Imk a.. k f = p' xA, Demonstrm c k(f(x)) =p'(x); conform definiiei lui p, p(x) = k(x) p(x) = p'(x) p p'. Q.e.d. Corolarul 5.37. injectiv p injectiv. Demonstraie: Fie x,yA, a.. p(x) = p(y); presupunem c xy; cum f este injectiv f(x) f(y); cum k este injectiv, k(f(x)) k(f(y)) p(x) p(y), contradicie. Q.e.d. De observat n modelul relaional kp se numete cheie strin, iar comutativitatea diagramei de mai sus trebuie explicit asertat n schema bd printr-o dependen de incluziune, n timp ce MMED garanteaz automat validitatea oricrei asemenea incluziuni. Observaia 5.38. a) Dac p nu este cheie, atunci MMED nu trebuie s adauge nici o FD la schema bd, deoarece singurele FD n care p este implicat sunt cele triviale i cele acoperite de principiul funciilor structurale (care sunt reprezentate prin cheia strin propagat). b) Nici dac p este cheie nu trebuie adugat explicit de utilizatorii MMED nici o constrngere suplimentar, ntruct sistemul adaug automat dependena de cheie corespunztoare. c) Avnd n vedere a) i b) de mai sus, observaia 5.11.c) rmne valid i n prezena funciilor structurale.

Prezentm n continuare un exemplu de aplicare a propagrii cheilor n MMED:

Exemplul 5.36 : Fie tipurile de obiecte LOCALITI = #Loc, Localitate i JUDEE = #Jud, Jude, CodAuto, PrefixTel. 52 Fie funcia JudLoc : LOCALITI JUDEE, care precizeaz crui jude i aparine fiecare localitate n parte. Un posibil coninut al acestei bd, inclusiv graful JudLoc, este prezentat n figura 5.12. Propagarea cheii Jude = #Jud JudLoc n tipul LOCALITI, care va avea deci structura LOCALITI = #Loc, Localitate, Jude, permite eliminarea tabelei corespunztoare tipului de asociaii degenerat JudLoc din schema bd. Coninutul noii bd astfel obinute este prezentat n figura 5.13.

Prin abuz de notaie, nu mai punem "cciuli" numelor pentru tipurile de obiecte LOCALITI i JUDEE, nefiind posibil nici o confuzie n acest caz. 100
52

Dac mbogim aceast bd cu mulimile de obiecte PERSOANE i RI i cu funciile structurale LocNatere : PERSOANE LOCALITI i araJud : JUDEE RI se obine, similar, schema relaional din figura 5.14.
5.3.8 Funcii calculate

Definiia 5.39. Se numete funcie calculat o funcie ale crei valori se pot obine oricnd din evaluarea unei expresii de calcul. Pentru o mai uoar monitorizare a schemei i coninutului bd gestionate, metacatalogul MMED nglobeaz i peste 20 de atribute sistem calculate. Exemplul 5.37: Tipul de entiti BAZE_DATE include i atributele calculate *Nr_concepte (ce memoreaz cardinalul CONCEPTE pentru fiecare bd n parte), *Nr_obiecte (ce memoreaz suma cardinalelor tuturor elementelor din MULIMI pentru fiecare bd) i *Koct_ocup (ce ine minte totalul spaiului ocupat cu memorarea schemei i coninutului fiecrei bd).

La rndul lor, tipurile ASOCIAII i CHEI au fiecare cte un atribut calculat numit *Aritate (ce memoreaz aritatea fiecrei asociaii, respectiv chei, i.e. numrul de supori, respectiv de atribute implicate). Desigur c MMED permite i utilizatorilor definirea de atribute calculate, pentru care trebuie precizate, nu doar numele, ci i formula de calcul corespunztoare fiecruia n parte; actualizarea valorilor acestor atribute este fcut de sistem, ori de cte ori se impune acest lucru.
Exemplul 5.38: *Vrsta = azi() - DataNaterii *TVA = Coef_TVA x Valoare *DePlat = Total - Achitat etc.

De remarcat c numele atributelor calculate este ntotdeauna prefixat de *. Evident, atributele calculate au menirea de a mri viteza de rspuns la interogri; preul pltit n schimb este, pe de-o parte, spaiul de memorare suplimentar implicat, iar, pe de alta, obligativitatea actualizrii permanente i protejrii valorilor calculate, care trebuie s fie accesibile utilizatorilor bd numai n citire, pentru a menine integritatea bd. n plus, trebuie ntotdeauna avute n vedere particularitile exploatrii bd: dac costuri le calculrii i memorrii acestor atribute derivate sunt sensibil mai mari dect ctigurile de vitez aferente, trivial, trebuie renunat la introducerea lor n schem. De exemplu, dac volumul i frecvena actualizrii datelor implicate sunt mult mai mari fa de totalul timpului de interogare ctigat (pentru c, desigur, conteaz mult i frecvena acestor interogri, nu doar timpul necesar unei singure execuii), atunci introducerea de atribute calculate n schem are efect contrar celui scontat, i.e. degradarea performanelor bd. Sunt ns desigur cazuri n care ctigurile sunt substaniale; de exemplu, n bd cu frecven i volum de actualizri a datelor reduse, n timp ce interogrile sunt extrem de frecvente i altfel (i.e. n absena unor atribute calculate) costisitoare. Figura 5.15 prezint un asemenea exemplu convingtor. n concluzie, redundana datelor indus de atributele calculate trebuie s fie ntotdeauna att justificat, ct i strict controlat. Exact ca i n cazul atributelor, MMED permite natural i definirea de funcii structurale calculate.
Exemplul 5.39: *araNatere = araJud JudLoc LocNatere : PERSOANE RI.

101

LOCALITI(#Loc) JudLoc (#Loc) Loc #Loc Localitate #Loc #Jud 1 Bucureti 1 1 2 Sibiu 2 3 100 Lancrm 100 6 3 Timioara 3 2 210 Spna 210 5 200 irnea 200 4 105 Rinari 205 3

JUDEE (#Jud, Jude, CodAuto, PrefixTel) Jude Jude CodAuto PrefixTel #Jud 1 Bucureti B 1 2 Timi TM 56 3 Sibiu SB 69 4 Braov BV 68 5 Maramure MM 62 6 Alba AB 58 7 Hunedoara HD 54 8 Lpuna LP 2

Fig. 5.12 O bd nainte de propagarea cheii pentru o funcie structural LOCALITI (#Loc) Jude #Jud Loc Localitate Jude #Loc 1 Bucureti 1 2 Sibiu 3 100 Lancrm 6 3 Timioara 2 210 Spna 5 200 irnea 4 105 Rinari 3 JUDEE (#Jud, Jude, CodAuto, PrefixTel) Jude #Jud 1 2 3 4 5 6 7 8 Jude Bucureti Timi Sibiu Braov Maramure Alba Hunedoara Lpuna CodAuto B TM SB BV MM AB HD LP PrefixTel 1 56 69 68 62 58 54 2

Fig. 5.13 Bd din figura 5.12 dup propagarea cheii pentru funcia structural PERSOANE (#Pers) LocNatere #Loc, Nume LOCALITI (#Loc) Jude #Jud Nume LocNatere #Pers Prenume Loc 1 Lucian Blaga 100 Localitate Jude #Loc 2 Emil Cioran 105 1 Bucureti 1 3 Constantin Noica 320 2 Cmpulung 2 4 Vasile Voiculescu 1 100 Lancrm 6 5 Mircea Eliade 1 101 Blandiana 6 6 Eugen Ionescu 290 320 Vitneti 8 7 Dan Barbilian 2 290 Slatina 7 8 Ana Blandiana 101 105 Rinari 3 JUDEE (#Jud, Jude, CodAuto, PrefixTel) ara #ara, RI (#ara, ara) ara #ara ara Jude Jude CodAuto PrefixTel ara 1 Romnia #Jud 1 Bucureti B 1 1 2 U.S.A. 2 Arge AG 48 1 3 Frana 3 Sibiu SB 69 1 4 Elveia 4 Braov BV 68 1 5 Italia 5 Maramure MM 62 1 6 Austria 6 Alba AB 58 1 7 Germania 7 Olt OT 49 1 8 Danemarca 8 Teleorman TR 47 1 9 Spania Fig. 5.14 O bd obinut n urma propagrii cheilor pentru trei funcii structurale

102

Figura 5.15 prezint tabela PERSOANE a bd de mai sus, creia i s-a adugat ns, pentru mrirea vitezei interogrilor, funcia calculat *araNatere. Se observ c memorarea ei scutete dou joinuri, scurtcircuitnd tabelele LOCALITI i JUDEE.
PERSOANE (#Pers) LocNatere #Loc, araNatere #ara, Nume #Pers Prenume Nume LocNatere *araNatere 1 Lucian Blaga 100 1 2 Emil Cioran 105 1 3 Constantin Noica 320 1 4 Vasile Voiculescu 1 1 5 Mircea Eliade 1 1 6 Eugen Ionescu 290 1 7 Dan Barbilian 2 1 8 Ana Blandiana 101 1 Fig. 5.15 Tipul PERSOANE al bd din figura 5.14 mbogit cu atributul calculat *araNatere

n plus, dac n general este adevrat c pentru aceste funcii se memoreaz doar expresia de calcul (precum n cazul procedurilor catalogate SQL), mult mai adesea totui dect n cazul atributelor calculate este aleas soluia dual, a memorrii i actualizrii permanente a valorilor aferente, pentru c, dup reuniune, n ciuda algoritmilor extrem de performani la dispoziie, joinul rmne cel mai scump operator relaional; ca atare, economisirea n acest mod a calculrii frecvente a unui lung lan de joinuri (n special pentru tabele cu cardinalitate foarte mare) este spectaculoas (mai ales c ea este adesea fcut cu un cost aproape insesizabil).
5.4 Constrngeri

Pentru a permite o modelare a datelor ct mai corect, orice model al datelor include posibilitatea asertrii explicite a unor clase de constrngeri. n MMED, sunt permise 18 asemenea clase, care sunt detaliate n aceast seciune: constrngeri de domeniu (i.e., de fapt, codomeniu al atributelor) constrngeri obiect (i.e. extinderea constrngerilor tuplu la obiecte) constrngeri de existen (i.e. de domeniu a funciilor atribut i / sau structurale) incluziunea, egalitatea, reuniunea, disjuncia i partiionarea mulimilor (de obiecte sau valori) minimal injectivitatea, surjectivitatea, egalitatea i idempotena funciilor (atribute sau funcii structurale) sisteme de reprezentani reflexivitatea, simetria, antisimetria, tranzitivitatea i aciclicitatea grafurilor de relaii binare. Deci MMED include n definiia sa i o mulime finit C de constrngeri de integritate. Sintactic, acestea ar putea fi exprimate cu ajutorul formulelor calculului predicativ de ordin nti. Practic ns, doar primele dou clase (domeniu i obiect) folosesc aceast sintax. Toate celelalte 16 clase beneficiaz de abrevieri sintactice consacrate (standard n matematic, ori de cte ori posibil pe calculator) pentru tipurile particulare respective de asemenea formule logice. Ecranul afind meniul constrngerilor dintr-o bd MatBase, care se obine selectnd Constraints din meniul principal, este cel prezentat n figura 5.16.

103

Fig. 5.16: Meniul constrngerilor MatBase

Ecranul afind mulimea tuturor constrngerilor dintr-o bd MatBase, care se obine selectnd All constraints din meniul Constraints, este prezentat n figura 5.17. De remarcat c n MMED nu este nevoie i nici nu este permis specificarea de FD, DMV sau DJ. DMV i DJ sunt formalizate cu ajuto-

Fig. 5.17: Mulimea tuturor constrngerilor dintr-o bd MatBase 104

rul asociaiilor, iar singurele FD implicit manipulate de MMED sunt cele induse de chei i de funciile structurale. Observaia 5.40:
a) De fapt, MMED folosete din modelul relaional doar constrngerile de existen, dependenele de domeniu, de cheie, precum i pe cele de incluziune, adic exact ce este necesar pentru FNDC i pentru manipularea valorilor nule. b) Lucrul cel mai important de remarcat ns este c, aa cum vom dovedi rnd pe rnd n subseciunile urmtoare, considerarea acestor clase de constrngeri nu este o chestiune de gust: ignorarea lor poate conduce la grave anomalii de actualizarea datelor. Ca atare, MMED le include printre constrngerile primitive i modific corespunztor accepiunea relaional a noiunilor de constrngere primitiv, compatibilitate semantic i anomalie de actualizare.
5.4.1 Constrngeri provenite din modelul relaional

Nu vom mai rediscuta n detaliu tipurile de constrngeri binecunoscute din modelul relaional, care sunt preluate i de MMED, cu minore diferene. De remarcat c dependenele de incluziune au fost generalizate ca incluziuni de mulimi, cele tuplu au fost generalizate n constrngeri obiect i c nu exist chei strine.
5.4.1.1 Constrngeri de domeniu

Ne reamintim c prin constrngeri de domeniu, MRD nelege de fapt specificarea codomeniilor atributelor. Am definit pn acum n MMED aceste codomenii mai degrab generic: este momentul s intrm n detalii, deoarece, pe de-o parte, astfel vom putea modela mult mai apropiat de realitate orice subunivers, iar pe de alta, resursele de memorie ale calculatoarelor sunt limitate i nici inteligena lor nu strlucete nc mcar n aceast privin. n subseciunea 5.2.2.1 am prezentat cei trei constructori de mulimi la dispoziie, precum i (pentru Enum i PSet) dou exemple de mulimi de valori construite cu acetia (CULORI, respectiv EXERC_FINANCIAR), submulimi, evident, prima din ele a tipului CHAR*, iar cea de-a doua a tipului DATE. Pe lng aceti constructori, MMED ofer nc un tip de abrevieri standard pentru specificarea mulimilor de valori: NAT(n) NAT, n NAT, semnific submulimea naturalilor cu cel mult n cifre (de exemplu, dac n = 2, a naturalilor x cu proprietatea c 0 x 99). Similar, se admit n MMED prescurtri de tipul INT(n), RAT(n), PRE(n). CHAR(n) semnific submulimea irurilor cu cel mult n simboluri ai alfabetului CHAR. DATE(d,e), respectiv TIME(s,t) semnific submulimile datelor calendaristice cuprinse (inclusiv) ntre datele d e, respectiv ale momentelor de timp dintre s t.
Exemplul 5.40: n loc de Nume : PERSOANE CHAR*, este uzual modelarea de tip Nume : PERSOANE CHAR(32) (dac numele persoanelor poate avea cel mult 32 de caractere n contextul respectiv). Similar, n loc de o definiie generic de tip DataNaterii : PERSOANE DATA, este preferabil una mai precis, de forma DataNaterii : PERSOANE DATA(1.1.1900,31.12.2000) (admind c intereseaz doar persoanele nscute n secolul XX), iar n loc de Nivel : DIRECTOARE NAT, ceva de forma Nivel : DIRECTOARE NAT(4) (admind c maximum posibil de nivele n ierarhia directoarelor este de 10.000).

Desigur c, n general, se pot defini constrngeri de domeniu suplimentare, exprimabile tot cu ajutorul clauzelor Horn din logica de ordin nti, la fel ca i n cazul
105

constrngerilor obiect, doar c strict referind mulimi de valori i elemente ale acestora (i nu obiecte).
Exemplul 5.41: card(CULORI) > 2 sau pentru VRSTA NAT(3), (xVRSTA)(x<150).

De notat c, parial, n limitele oferite de unealta de implementare a SGBD bazat pe MMED (fie c este vorba, de exemplu, doar de un limbaj de programare, doar de un motor relaional sau de o combinaie a acestora), majoritatea constrngerilor de domeniu nu trebuie explicitate dect mai degrab generic, fiind implicit presupuse. Desigur ns c att ultimele dou exemple furnizate, dar i cele, de exemplu, de tip DATE(d,e) trebuie explicitate n schema MMED corespunztoare. Evident i aceast subclas este o mulime, deci nu admite duplicate; mai mult, toate considerentele de la sfritul subseciunii dedicate constrngerilor obiect se aplic desigur, mutatis mutandis i constrngerilor de domeniu explicite.
5.4.1.2 Chei

Minimal injectivitatea funciilor se exprim prin constrngeri cheie astfel:

pentru orice atribut (produs de atribute) injectiv a, prin declaraia cheie a sau prin folosirea n definiie a dublei sgei , n loc de cea simpl, , obinuit pentru orice funcie structural injectiv , prin folosirea n definiia funciei a dublei sgei (MMED adugnd implicit n schema bd att cheia propagat kp corespunztoare, ct i declaraia cheie kp aferent) pentru orice cheie structural ks a unei asociaii, prin includerea ei n lista cheilor structurale din definiia asociaiei (MMED adugnd implicit n schema bd declaraia cheie ks).
Exemplul 5.42: Fie din nou bd din exemplele 5.11 i 5.12; este evident c ea satisface dependenele cheie cheie #Dir i cheie TataDirector. Uzual ns, prima se scrie, odat cu definiia #Dir, sub forma abreviat: DIRECTOARE #Dir NAT(8). Dei nu este uzual, a doua dependen de cheie se poate i ea scrie alternativ sub forma: TataDirector : DIRECTOARE DIRECTOARE CHAR(256). Exemplul 5.43: Similar, reconsidernd, bd din figura 5.8 (exemplul 5.9), dac ar fi nevoie i de adugarea capitalelor (la ri), formalizarea cea mai elegant s-ar obine evident cu ajutorul unei funcii structurale injective (cci nu doar fiecare ar are o unic capital, ci, mai mult, nici o localitate nu poate fi simultan capital a mai multor ri) Capitala : RI LOCALITI. Exemplul 5.44: n sfrit, rmnnd la acelai exemplu, dar revenind i la observaia 5.27b, notm c declaraia tipului de asociaii CODIF_POTAL = (CODURI_POTA, LOCALITI, ADRESE, CODURI_POTA, LOCALITI, LOCALITI, ADRESE) conine implicit urmtoarele dou dependene cheie, induse de cele dou chei structurale ale sale i anume: cheie prCODURI_POTACODIF_POTAL prLOCALITICODIF_POTAL

i cheie prADRESECODIF_POTAL prLOCALITICODIF_POTAL, n timp ce declaraia STOCURI = (MAGAZII , PIESE) (vezi, de exemplu,
106

subseciunea 1.2) conine implicit dependena cheie prMAGAZIISTOCURI prPIESESTOCURI (conform lemei 5.6, observaiei 5.27c i algoritmului 5.31). De remarcat c produsele minimal injective de funcii pot fi inclusiv mixte, adic alctuite att din atribute, ct i din funcii structurale. Pe lng condiia de minimalitate ce trebuie ndeplinit de orice cheie produs de funcii, este evident i c domeniul tuturor funciilor alctuind un produs trebuie s fie acelai (i.e. toate trebuie s aparin aceluiai tip de obiecte).
5.4.1.3 Constrngeri de existen

Constrngerile de existen (CE) beneficiaz n MMED de dou tipuri de sintax: una proprie, pentru subclasa total definirilor, i.e. pentru cele de forma , unde : D C este o funcie structural sau atribut i anume: : D C, total. cea uzual n MRD, pentru subclasa celor generale, de tipul X Y, unde X i Y sunt, n general, produse de funcii structurale i/sau atribute, i.e. X,Y P(A F ). Exemplul 5.45: (sintaxa proprie) Fie din nou bd din exemplul 5.11; evident c, n general, funcia Tata trebuie s admit valori nule (pentru directoarele rdcin), deci ea nu trebuie s fie total definit. n schimb, trivial, nici unul dintre cele trei atribute ale tipului DIRECTOARE nu trebuie s admit valori nule, deci toate trebuie s fie total (i.e. peste tot) definite. Deoarece, prin definiie (vezi 5.3.3.1), toi identificatorii de obiect sunt implicit funcii totale, nu este nevoie ca acest lucru s fie explicitat pentru #Dir; definiiile corecte ale Director i Nivel trebuie ns s fie de forma: Director : DIRECTOARE CHAR(256), total Nivel : DIRECTOARE NAT(4), total Exemplul 5.46: (sintaxa uzual) Fie urmtorul fragment al schemei bd Bibliotecar: EXEMPLARE={#Exemplar, NrInventar, Datamprumut}, PERSOANE={#Persoana, Prenume, Nume, mprumut}, mprumuttor : EXEMPLARE PERSOANE. Constrngerea pentru orice exemplar, valorile acestor dou funcii pot fi ori ambele nule, ori ambele nenule (i.e. este interzis ca pentru vreun exemplar una dintre ele s fie definit, iar cealalt nu) se formalizeaz evident cu ajutorul urmtoarelor dou constrngeri de existen: Datamprumut mprumuttor mprumuttor Datamprumut

Evident c nu are rost memorarea n vreo bd nici a aceleiai constrngeri de existen de mai multe ori (i.e. submulimea CE a constrngerilor este o mulime), nici a CE triviale de tip X X sau X .
5.4.1.4 Constrngeri obiect

Constrngerile obiect constituie o extensie natural a constrngerilor tuplu, de la linii de tabele la obiecte. Ca atare, cum obiectele sunt din punct de vedere matematic elemente ale unor mulimi, orice formul logic de ordin nti referind doar mulimi din V, atribute din A i funcii structurale din F este o constrngere obiect.
107

Exemplul 5.47: Fie o bd cu schema DIRECTOARE = {#Dir,Director,Nivel}, Tata : DIRECTOARE DIRECTOARE; constrngerea obiect dac un director are tat, atunci nivelul acestuia (de adncime, n arborele de directoare) trebuie s fie cu 1 mai mic dect al su poate fi formalizat cu ajutorul predicatului: (xDIRECTOARE) (yDIRECTOARE)(y=Tata(x))(NivelTata(x)=Nivel(x) - 1) Evident c puterea deosebit a logicii de ordin nti poate conduce, teoretic, la formularea unei mulimi de constrngeri obiect incoerent (i.e. pentru care s nu existe nici un coninut valid al bd respective) sau care s induc anomalii de actualizare; chiar i constrngerile de domeniu, dup cum am vzut n subseciunea 2.8.2, pot conduce la situaii limit, n care doar coninutul vid s fie consistent. n practic ns, n primul rnd, proiectanii bd au misiunea de a modela exact domeniile de interes; n prezena vreuneia din situaiile de mai sus, ei pot decide dac este vorba de vreo eroare de modelare, sau dac nsui domeniul de interes modelat este de vin. Primul caz, desigur, poate fi rezolvat de proiectant singur; n cel de-al doilea, evident, trebuie ncunotinai responsabilii domeniului respectiv (mergnd, dac este cazul, pn la Legiuitor!) pentru relaxarea constrngerilor n cauz. n al doilea rnd, implementarea MMED poate restrnge drastic subclasa de propoziii logice acceptate drept constrngeri obiect, astfel nct asemenea riscuri s fie aproape eliminate (majoritatea SGBD operaionale fac acest lucru). Ca atare, pentru a evita nedecidabilitatea, orice constrngere obiect trebuie exprimat sub forma unei clauze Horn. Subclasa constrngerilor obiect fiind o mulime, ea nu admite duplicate (i.e. nu ar avea nici un rost memorarea de mai multe ori n vreo bd a unei aceleiai constrngeri). De notat ns c aceast constrngere este mult mai uor de implementat pur sintactic, dect i semantic, deoarece echivalena semantic a dou propoziii din logica de ordin nti (fie ele doar de tip clauze Horn) necesit recursul la un demonstrator logic de teoreme sofisticat, scump i, cel mai adesea, nu suficient de performant.
5.4.2 Constrngeri asociate mulimilor 5.4.2.1 Incluziunea

AttV ct i sunt poset-uri (mulimi parial ordonate de incluziuni). Ar putea deci fi nevoie, n schema unei bd, de o constrngere de incluziune ntre mulimi de valori.
Exemplul 5.48: SPECTRU CULORI.

Mult mai interesante sunt ns incluziunile ntre mulimi de obiecte care modeleaz ierarhii (laticeale), de tip generalizare (IS-A), ale mulimilor de obiecte i care permit n MMED motenirea atributelor i cheilor. Exemplul 5.49: CADRE_DIDACTICE ANGAJAI PERSOANE sau STUDENI PERSOANE. Constrngerile de tip incluziune sunt implementate de MMED tot cu ajutorul DIN din modelul relaional. Din punctul de vedere al incluziunii (dar i egalitii, i.e. dublei incluziuni a) mulimilor, este evident c, pentru a evita anomaliile de actualizare, este suficient relaxarea definiiei constrngerilor primitive prin includerea printre acestea i a dependenelor de incluziune. De notat c dac partea stng a unei asemenea incluziuni este necunoscut n momentul asertrii constrngerii respective, atunci aceasta servete i de definiie a noii mulimi corespunztoare.
Exemplul 5.50 : n schema:
108

CURSURI #Curs NAT(8) Curs CHAR(256), total PRECONDIII CURSURI COND_NSCRIERE = (CURSURI, PRECONDIII) mulimea de obiecte PRECONDIII este i automat definit de MMED n momentul ntlnirii constrngerii PRECONDIII CURSURI.

Evident c, exact ca i n cazul tuturor celorlalte tipuri de constrngeri, subclasa dependenelor de incluziune fiind o mulime nu admite nici ea duplicate (i.e. nu are rost memorarea n vreo bd de mai multe ori a unei aceleiai incluziuni). Mai mult ns, clasa dependenelor de incluziune trebuie s mai satisfac i urmtoarele (meta)constrngeri: Nu are rost (deci trebuie interzis) memorarea incluziunilor triviale de tip M, oricare ar fi mulimea M, deoarece ele sunt trivial deductibile. Idem a celor duale (i.e. de tip M , care nu afirm dect c M trebuie s fie mereu vid), deoarece, trivial, n bd nu sunt interesante mulimile ce trebuie mereu s fie vide (evident, cu excepia mulimii vide nsi), fie ele de obiecte sau de valori. Idem a celor de tip M M i ele fiind trivial deductibile (de notat c aceasta nseamn, aparent paradoxal, c n bd incluziunile nu trebuie s fie reflexive! Idem a celor de tip M N, unde M i N aparin ns unor subclase de mulimi diferite, deoarece, evident, (dei netriviale) ele sunt excluse prin definiie n MMED (fiindcV, E i sunt toate disjuncte ntre ele dou cte dou). Evident, orice mulime de incluziuni trebuind, prin definiie, s fie tranzitiv, nu are rost nici (deci trebuie interzis i) memorarea de incluziuni tranzitiv deductibile din cele deja existente (e.g., dac o mulime de dependene de incluziune conine M N i N Q, atunci trebuie interzis memorarea i a M Q, oricare ar fi mulimile M, N, Q. Aparent la fel de paradoxal ca i precedenta (care, n fond, impune n bd nontranzitivitatea incluziunilor ce sunt matematic, prin definiie, tranzitive) este i metaconstrngerea ce impune oricrei mulimi de incluziuni s fie aciclic (n caz contrar, desigur, procesul de impunere al unor asemenea incluziuni ar putea bucla la infinit). n fine, o ultim asemenea metaconstrngere este natural: cum incluziunile i disjunciile (acelorai perechi de mulimi) se exclud reciproc, orice incluziune M N interzice coexistena unei disjuncii omonime M N = (ca i a simetricei sale N M = ), oricare ar fi mulimile M, N.
5.4.2.2 Egalitatea

Pe lng incluziune, chiar dac nu la fel de frecvent, este nevoie adesea n modelarea datelor de a impune egalitatea (i.e. dubla incluziune) ntre mulimi. Egalitatea este folosit n special pentru a defini asociaii, sinonime i partiii n schema bd, dar nu numai.
Exemplul 5.51: Egalitatea COND_NSCRIERE= (CURSURI, PRECONDIII) definete asociaia binar COND_NSCRIERE (n acelai spirit n care sunt definite relaiile matematice: de exemplu, R=(M1, M2, GR)). Exemplul 5.52: n schimb, revenind la exemplul 1.1 (figura 1.4), pentru a putea defini tipul de asociaii MICRI_ PIESE (respectnd condiia ca numele suporilor s fie unici), urmtoarele dou constrngeri definesc, de fapt, dou sinonime pentru tipul de entiti MAGAZII: MAGAZII
109

#Mag NAT(4) Mag CHAR(64), total MAGAZII_SURS = MAGAZII MAGAZII_DESTINAIE = MAGAZII PIESE #Piesa NAT(16) DenPiesa CHAR(32), total DOCUMENTE #Doc NAT(16) TipDoc CHAR(2), total DataDoc DATE(1.1.2002, azi()), total MICRI_PIESE = (MAGAZII_SURS, MAGAZII_DESTINAIE, PIESE, DOCUMENTE). Exemplul 5.53: n fine, n schema urmtoare (n care, n momentul asertrii constrngerii de egalitate, ambele mulimi implicate sunt deja definite), egalitatea este o pur constrngere: AEROPORTURI #A NAT(16) CodAeroport CHAR(8), total Aeroport CHAR(64), total AEROP_SURS AEROPORTURI AEROP_DESTINAIE AEROPORTURI AEROP_SURS = AEROP_DESTINAIE

De notat c, aa cum este de ateptat, MMED nu memoreaz constrngerile de egalitatea mulimilor ca atare, ci folosete pentru aceasta dublele incluziuni corespunztoare.
5.4.2.3 Reuniunea

Cteodat este nevoie de a impune i constrngeri coninnd reuniuni ntre mulimi. Exemplul 5.54: PERSOANE = STUDENI ANGAJAI impune excluderea oricrui alt tip de persoane ntr-o bd universitar, cu excepia studenilor i angajailor.
5.4.2.4 Disjuncia

Pe lng incluziuni, MMED include printre constrngerile primitive relative la mulimi i disjuncia acestora. 53
Exemplul 5.55: Exemple de disjuncii apar chiar n definiia MMED, precum V = , E = sau F = 54, n timp ce altele pot fi deduse din ea, precum F A = (trivial, din definiia celor dou clase de funcii i fiindc V = ).

Evident c i modelarea uzual n bd are nevoie de acest tip de constrngeri; exemplu: SENATORI DEPUTAI = .
Reamintim c dou mulimi oarecari M i N se zic disjuncte dac intersecia lor este vid, i.e. dac MN=. n MMED, disjuncia se poate abrevia sintactic i prin disjuncte {M,N}. 54 Disjuncie aparent paradoxal, fiindc n matematic funciile sunt un caz particular de relaii binare: n bd ns, funciile structurale se propag ntotdeauna, mbogind tipul de obiecte al domeniului lor, fr a da natere la noi mulimi de obiecte, n timp ce graful asociaiilor constituie ntotdeauna un nou tip de obiecte al schemei. 110
53

Similar cazului incluziunilor, pe lng faptul c i subclasa disjunciilor este o mulime (care deci nu admite duplicate) ea trebuie s se mai supun unui set de metaconstrngeri similare i anume: Nu are rost (deci trebuie interzis) memorarea disjunciilor triviale de tip M = sau M = , oricare ar fi mulimea M, deoarece ele sunt trivial deductibile. Idem pentru disjunciile imposibile de tip M M = , oricare ar fi mulimea M, deoarece, trivial, M M = M (de notat c aceasta nseamn c n bd disjunciile nu trebuie s fie vreodat reflexive, ceea ce, de aceast dat este consistent cu definiia lor matematic). Idem a celor simetrice (i.e. de tip N M = , atunci cnd este deja memorat n bd simetrica sa M N = , oricare ar fi mulimile M i N), deoarece acestea sunt trivial deductibile (de notat c aceasta nseamn, aparent paradoxal, c n bd disjunciile nu trebuie s fie simetrice). Idem a celor de tip M N = , unde M i N aparin ns unor subclase de mulimi diferite, deoarece, evident, (dei netriviale matematic) ele sunt triviale prin definiie n MMED (fiindcV, E i sunt toate disjuncte ntre ele dou cte dou). n fine, o ultim asemenea metaconstrngere (dual ultimei de la incluziuni) este natural: cum incluziunile i disjunciile (acelorai perechi de mulimi) se exclud reciproc, orice disjuncie M N = interzice coexistena incluziunilor simetrice omonime M N i M N, oricare ar fi mulimile M, N.
5.4.2.5 Partiionarea

Dei nu sunt constrngeri primitive (ele putnd fi trivial nlocuite cu conjuncii de incluziuni, reuniune i disjuncii), MMED ofer, pentru comoditate i elegan sporit n proiectare i o subclas de constrngeri de tip partiionarea mulimilor. 55 Evident c cel mai uzual exemplu de partiionare l ofer clasele de echivalen.
Exemplul 5.56: Conform definiiei, n MMED are evident loc constrngerea de partiionare =E .. Mai mult, pentru o modelare elegant unitar a funciilor (indiferent c sunt atribute sau funcii structurale) i constrngerilor, este convenabil adugarea la model a unei supermulimi S partiionat n trei blocuri: S = V {} (de notat, n legtur cu al treilea bloc, faptul evident c, pe de-o parte, este neaprat nevoie n modelare de mulimea vid, dar pe de alta, c nu intereseaz mulimi vide nici de obiecte, nici de valori). Aceast partiionare corespunde desigur claselor de echivalen induse de valorile atributului TipM : S {V,E,A,N,C}, total. Exemplul 5.57: O alt partiionare sistem evident n MMED este cea a mulimii constrngerilor: CONSTRNGERI = MINIMAL_INJ EGALITI_ FUNCII CONSTR_EXISTEN INCLUZIUNI DISJUNCII SIST_REPREZ CONSTR_OBIECT CONSTR_DOMENIU. Exemplul 5.58 : Desigur c exist i subuniversuri de interes utilizator care pot beneficia n modelare de acest tip de constrngeri, precum, de exemplu urmtorul:
55

Reamintim c, dat fiind o mulime oarecare M i o colecie de submulimi ale sale S1, S2, ..., Sn, cu proprietatea c Si M, i, 1 i n > 0, Si Sj = , i, j, i j, 1 i, j n i M = S1 S2 ... Sn, Si se zic blocurile partiiei astfel definite pe M, iar M se zice partiionat n blocurile Si, ceea ce se noteaz prescurtat de obicei prin M = S1 S2 ... Sn. 111

CETENI = VOTANI NEVOTANI VOTANI = CANDIDAI NECANDIDAI CANDIDAI = ALEI NEALEI ALEI = PARLAMENTARI ALEI_LOCALI PARLAMENTARI = SENATORI DEPUTAI PARLAMENTARI = GRUPURI_P INDEPENDENI FSN = PSD PRM PD GRUPURI_P = FSN UDMR PNL MINORITAI

De notat c, aa cum este de ateptat, MMED nu memoreaz constrngerile de tip partiionri ca atare, ci folosete pentru aceasta incluziunile, reuniunea i disjunciile corespunztoare.
5.4.3 Constrngeri asociate funciilor

Fie c este vorba de funcii structurale, de atribute sau de produse ori compuneri ale acestora (mixte sau nu), adesea, inclusiv n cazuri de modelare extrem de simple, egalitatea funciilor este foarte frecvent ntlnit. Chiar dac mult mai rar n asemenea exemple, vom vedea totui c idempotena i surjectivitatea sunt la rndul preioase pentru modelarea cu acuratee a datelor.
5.4.3.1 Egalitatea

Precum n cazul general al oricrui fel de egalitate, egalitatea funciilor poate fi folosit n MMED pentru a defini sinonime pentru funcii. Revenind la exemplul 6.10, acesta este cazul pentru declaraia: Jude = #Jud Apart_Jud. 56 Mult mai important ns este egalitatea funciilor ce impune comutativitatea diagramelor de funcii.
Exemplul 5.59: Revenind la exemplul 5.10, trebuie remarcat n legtur cu modelarea sa relaional de ctre Ullman, c este obligatorie adugarea la schema bd a constrngerii de comutativitate a urmtoarei diagrame de funcii 57 (unde k1 este funcionalitatea corespunztoare cheii structurale Localiti, Adrese, iar prLOCALITI este proiecia CODIF_POTA pe LOCALITI): ADRESE LOCALITI k1 CODURI_POTA Loc_Codif prLOCALITI LOCALITI

Formalizarea acestei constrngeri n MMED este, evident, urmtoarea: Loc_Codif k1 = prLOCALITI. Similar, ar mai trebui adugat schemei i constrngerea de acelai tip Localiz_Adresa k2 = prLOCALITi, unde k2 este funcionalitatea corespunztoare cheii structurale LOCALITI, CODURI_POTA.

De remarcat c, n general, definirea unui sinonim este o constrngere: noul sinonim este "constrns" s aib aceleai proprieti i comportament cu toate sinonimele sale. 57 Din nou, desigur, de remarcat c modelul relaional nu permite modelarea funciilor dect cu ajutorul FD, deci cu att mai puin asemenea constrngeri. 112
56

De notat c, prin tranzitivitate, aceste dou constrngeri garanteaz i pe urmtoarea (unde prADRESE este proiecia CODIF_POTA pe ADRESE): Loc_Codif k1 = Localiz_ Adresa prADRESE O modelare neatent ar putea totui s-o includ n schem, dei ea este implicat; de remarcat c, dei echivalent, chiar modelarea incluznd aceast ultim constrngere n locul oricreia dintre primele dou ar fi o soluie mai ineficient i mai puin elegant, cci astfel ar trebui calculat o compunere de funcii n plus!
MMED distinge ntre cele dou semantici posibile ale unei egaliti de funcii astfel: dac toate funciile implicate sunt deja cunoscute sistemului, atunci este vorba de o constrngere de tip comutativitate de diagrame de funcii; dac una dintre funcii este necunoscut, atunci MMED consider egalitatea ca fiind definiia acestei funcii (astfel calculate). Formalizarea relaional a conceptului de anomalie de actualizare se limiteaz la inserie (de tupli compatibili) i tergere, deoarece modificarea unui tuplu ntr-o relaie poate fi asimilat cu succesiunea tergere i apoi inserie. Din acest punct sintactic de vedere, constrngerile de tip comutativitate de diagrame de funcii nu pot conduce la anomalii de actualizare. Semantic ns, evident c sunt posibile anomalii; referindu-ne din nou la exemplul din figurile 5.6, 5.7 i 5.8, modificarea valorii Loc_Codif(2), de pild, din valoarea 1 n orice alt valoare ar viola constrngerea: Loc_Codif k1 = prLOCALITATI (unde, n terminologia mai precis a figurilor sus-menionate, k1= CODURI_POTA, iar prLOCALITATI = LOCALITI). i constrngerile de tip egalitate de funcii sunt ns considerate primitive n MMED.
5.4.3.2 Idempotena

Am menionat deja, la exemplul 5.4, c funcia SINONIMIE este idempotent 58. Evident c idempotena este un caz particular al egalitii de (compuneri de) funcii. Fiind ns extrem de important n modelarea sistemelor de reprezentani, MMED ofer sintaxa specializat: idemp .
Exemplul 5.60: Fie o bd avnd schema {PIESE, Echivalena : PIESE PIESE} i constrngerea suplimentar natural orice pies aleas pentru a echivala alte piese i este propriul echivalent. Evident c cea mai elegant modelare a acestei constrngeri o constituie: idemp Echivalena.

Nefiind fundamentale, aa cum este de ateptat, MMED nu memoreaz constrngerile de tip idempotene ca atare, ci folosete pentru aceasta compunerea i egalitatea funciilor.
5.4.3.3 Surjectivitatea

Dual injectivitii i total definirii, surjectivitatea are, n sine, suficient importan pentru a o scoate din anonimatul constrngerilor obiect.
Exemplul 5.61: Revenind la bd din exemplul 5.10, pentru a ne asigura c este ntotdeauna memorat codul potal al oricrei localiti, este obligatorie surjectivitatea funciei structurale Loc_Codif : CODURI_POTA LOCALITI.

58

Reamintim c o funcie se numete idempotent dac = . 113

n plus, surjectivitile canonice au o importan covritoare n modelarea sistemelor de reprezentani. Sintaxa surj este folosit n MMED pentru a include n schema bd constrngerea este surjectiv. Evident c, n accepiune relaional, includerea acestui tip de constrngere n schema unei bd poate conduce la anomalii de actualizare. Referindu-ne la exemplul din Figurile 5.6, 5.7 i 5.8, tergerea din tabela CODURI_POTA a oricrui tuplu cu excepia celui de-al doilea sau al treilea ar viola constrngerea surj Loc_Codif. n accepiunea MMED ns, constrngerile primitive includ i surjectivitile. Acest tip de constrngere trebuie ns mereu inclus n schema unei bd dup o analiz foarte atent, deoarece, n caz contrar, impunerea unei surjectiviti poate conduce, n cel mai bun caz, la necesitatea proiectrii unor interogri speciale pentru introducerea i actualizarea datelor, care trebuie s foreze o anumit ordine de operare, iar n cel mai ru caz, chiar la imposibilitatea actualizrii datelor implicate.
Exemplul 5.5.62: Reconsidernd exemplul 5.20, evident c toate cele trei funcii structurale trebuie s fie surjective (deoarece: nu exist ef fr subordonat, n cel mai ru caz eful fiindu-i unicul subordonat; nu exist departament fr angajai i nici fr ef). S presupunem bd vid i coninnd numai una din aceste constrngeri, de exemplu surj LocMunc. Evident c dac am ncerca s introducem nti departamentele i apoi angajaii, aceast constrngere ne-ar mpiedica s procedm n aceast ordine nc de la primul departament introdus, obligndu-ne s introducem simultan cel puin un angajat cu locul de munc n acel departament, plus aceast informaie; chiar dac am ncerca n schimb s introducem nti angajaii, tot n-am putea ns introduce departamentele dect simultan cu specificarea locului de munc a cel puin unui angajat din acel departament (deci i ordinea de introducere a angajailor ar fi obligatoriu de sincronizat cu cea a departamentelor). Mai ru, dac toate cele trei surjectiviti ar fi impuse de la nceput se poate demonstra imediat c bd ar rmne venic vid, fiindc interaciunea dintre ele conduce la un aa numit blocaj fatal.

n general deci, surjectivitatea este genul de constrngere ce trebuie impus mai degrab bd statice (de tip geologic, geografic, astronomic etc.), dup terminarea completrii lor cu date, pentru a prentmpina apoi tergerea sau modificarea eronat a acestora i nu la nceput, naintea populrii bd cu toate datele implicate n surjectiviti.
5.4.4 Sisteme de reprezentani

Nevoia de a utiliza sisteme de reprezentani 59 n proiectarea bd apare frecvent. De exemplu, piesele de tip t sunt echivalente cu cele de tip s, putnd deci fi substituite una alteia n subansamblele ce necesit asemenea piese; facilitile de tip f sunt echivalente cu cele de tip g, putnd fi deci substituite una alteia n procesul de instruire; sinonimele sunt echivalente ntre ele, putnd fi deci interanjabil folosite pentru numirea conceptelor etc.

59

Dat fiind o mulime oarecare fixat M i o relaie de echivalen ~ peste ea, se obine o partiionare a M n clase de echivalen constituind mulimea ct M/~. ntre M i M/~ se stabilete cu aceast ocazie o surjecie canonic : M M/~, care asociaz fiecrui element al mulimii M clasa sa de echivalen. Dac pentru fiecare clas de echivalen se alege cte un unic reprezentant din M, atunci M/~ M, iar M/~ se zice sistem de reprezentani. 114

Exemplul 5.63 : Reconsidernd exemplul 5.20, este evident c EFI este un sistem de reprezentani pentru ANGAJAI, iar ef este surjecia canonic asociat.

Aparent, modelarea sistemelor de reprezentani se poate face n MMED foarte simplu, incluznd n schema bd mulimile de entiti M i M/~, constrngerea M/~ M i funcia structural . Dar lucrurile se complic ntructva atunci cnd realizm c graful nu poate fi aciclic! Din fericire, urmtoarea propoziie simplific mult modelarea sistemelor de reprezentani: Propoziia 5.41: (ciclicitatea sistemelor de reprezentani) Graful oricrei surjecii canonice asociate unui sistem de reprezentani este ciclic. Demonstraie: Fie idemp i s presupunem prin absurd c graful este aciclic; din definiie, xM/~ ( (x)) = (x), deci exist cel puin cte o bucl per reprezentant n graful , ceea ce nseamn c presupunerea fcut este ntr-adevr absurd. Q.e.d. Ca atare, pentru modelarea unui sistem de reprezentani pentru o mulime de obiecte oarecare M, MMED ofer sintaxa prescurtat de tip SRM = reprez M, cu nelesul c se adaug la schema bd urmtoarele: un nou tip de obiecte (mai exact, entiti) cu numele SRM o nou funcie structural: SRM : M SRM trei constrngeri: SRM M, surj SRM i idemp SRM.
Exemplul 5.64: Revenind din nou la exemplul 5.20, este acum evident de ce Echivalena trebuie s fie idempotent.
5.4.5 Constrngeri asupra grafurilor de relaii binare

Evident c subseciunile anterioare ofer deja suficiente motive pentru ndreptirea includerii printre constrngerile primitive ale MMED tuturor acestor subclase. nainte de a analiza i altele, este ns nevoie s ncepem aceast subseciune prin a preciza exact ce nelegem prin grafuri de relaii binare. Aa cum ne vor demonstra exemplele din subseciunile urmtoare, este nevoie s numim astfel n mod generic de fapt trei tipuri distincte de concepte matematice i anume:

grafuri propriu-zise de asociaii binare (i.e. nefuncionale) grafuri de funcii structurale (nelese ca mulimi de perechi de forma (x, f (x))) produse binare de funcii structurale (nelese ca mulimi de perechi de forma (f (x), g(x))).

Desigur c, n fiecare din ultimele dou subcazuri, pentru a putea vorbi despre oricare din aceste cinci proprieti ale relaiilor binare, este necesar ndeplinirea cte unei condiii suplimentare (de omogenitate) i anume: n subcazul doi, Im(f ) dom(f ) (imaginea f trebuie s fie o submulime a domeniului ei) n subcazul trei, codom(f ) = codom(g) (codomeniile celor dou funcii trebuie s fie aceleai). 60 Ca atare, prin abuz de notaie, vom vorbi, de exemplu, despre aciclicitatea unei funcii, dar i a unui produs de dou funcii, exact ca despre cea a unei relaii binare i

60 Aceast condiie simplificatoare este evident prea puternic: de fapt, este suficient ca imaginile celor dou funcii s fie identice. n plus ns, trivial, pentru ca produsul s poat fi definit, este n primul rnd nevoie ca domeniile celor dou funcii s coincid. 115

vom scrie, corespunztor: aciclic A=(B,C), aciclic f : B C, respectiv aciclic fg, unde f, g : B C.
5.4.5.1 Reflexivitatea

Privite drept constrngeri de bd, nici incluziunile, nici disjunciile nu trebuie s fie reflexive. 61 Chiar dac ntlnit mai rar n modelare, acest tip de constrngeri este totui indispensabil (mai ales sub form negat) modelrii corecte a unei clase de subuniversuri de interes uzuale. Sintaxa acestui tip de constrngeri este de tip reflexiv x.
Exemplul 5.65: Fie orice competiie sportiv cu doi adversari (e.g. scrim, tenis, fotbal etc.). Evident c niciodat, nimeni (fie el sportiv sau echip) nu va juca mpotriva lui nsui, deci orice asemenea graf nu trebuie s fie reflexiv. Exemplu 5.66: Fie o bd pentru un campionat (local, naional sau internaional) de fotbal i urmtorul extras al schemei sale: GAZDE ECHIPE, EDIII, MECIURI = (GAZDE, ECHIPE, EDIII), Scor : MECIURI NAT(2). Pentru o modelare corect, aceast schem trebuie n mod trivial s includ i constrngerea: (reflexiv prGAZDEMECIURI prECHIPEMECIURI).

Ca atare, MMED include i reflexivitatea printre constrngerile sale primitive.

5.4.5.2 Simetria

Privite drept constrngeri de bd, disjunciile nu trebuie s fie simetrice. 62 Chiar dac ntlnit rar, i acest tip de constrngeri este totui indispensabil unei modelri corecte a unei ntregi clase de subuniversuri de interes uzuale. Sintaxa acestui tip de constrngeri este de tip simetric x.
Exemplul 5.67a: Revenind la exemplul anterior, este evident, datorit algoritmului de tip tur-retur, c n orice ediie, orice pereche posibil de echipe trebuie s joace dou meciuri, alternnd ntre ei postura de gazd, deci orice asemenea subgraf trebuie s fie simetric. Ca atare, pentru o modelare corect, aceast schem trebuie n mod trivial s includ i constrngerea: xIm(prEDIIIMECIURI) (simetric prGAZDEMECIURI(x)prECHIPEMECIURI(x))

n consecin, MMED include i simetria printre constrngerile sale primitive.

5.4.5.3 Antisimetria

Chiar dac constrngerile de antisimetrie 63 sunt mult mai rar ntlnite n modelarea datelor, totui i ele trebuie incluse printre constrngerile primitive ale MMED. Sintaxa acestui tip de constrngeri este de tip antisimetric x.
Exemplul 5.67b: Graful funciei ef trebuie s fie antisimetric: dac un angajat este eful altuia, iar acela este eful su, atunci nu poate fi vorba dect de el nsui, adic: (x,y ANGAJAI)(x=ef(y) y=ef(x) x=y). Ca atare,
Reamintim c o relaie binar R peste o mulime M se zice reflexiv dac aR a, aM. Reamintim c o relaie binar R peste o mulime M se zice simetric dac aR b bR a, a,bM. 63 Reamintim c o relaie binar R peste o mulime M se zice antisimetric dac aR b bR a a = b, a,bM. 116
61 62

pentru o modelare corect, orice schem ce include aceast funcie trebuie n mod trivial s includ i constrngerea: antisimetric ef.
5.4.5.4 Tranzitivitatea

Privite drept constrngeri de bd, incluziunile nu trebuie s fie tranzitive. 64 Chiar dac nu foarte des ntlnit n modelare, acest tip de constrngeri este totui indispensabil (mai ales sub form negat) modelrii corecte a unor subuniversuri de interes uzuale. Sintaxa acestui tip de constrngeri este de tip tranzitiv x.
Exemplul 5.68: Revenind la exemplul 5.25, este evident, datorit algoritmului de tip fiecare-cu-fiecare i n tur i n retur, c n orice ediie, dac o pereche oarecare de echipe (e,f) joac ntre ele, iar f joac i cu o alt echipa g, atunci i f trebuie s joace cu g, deci orice asemenea subgraf trebuie s fie tranzitiv. Ca atare, pentru o modelare corect, aceast schem trebuie n mod trivial s includ i constrngerea:

(xIm(prEDIIIMECIURI))(tranzitiv prGAZDEMECIURI(x) prECHIPEMECIURI(x)). Ca atare, MMED include i tranzitivitatea printre constrngerile sale primitive.
5.4.5.5 Aciclicitatea

Este foarte adesea nevoie de impunerea aciclicitii grafurilor de relaii binare omogene, pentru a evita ori buclarea la infinit, ori imposibilitatea de a intra ntr-o bucl. Aciclicitile grafurilor se pot formaliza matematic tot cu ajutorul formulelor calculului predicativ de ordin nti. Notaia ns ar fi mult mai greoaie dect prescurtarea oferit de MMED i care este de tip aciclic x.
Exemplul 5.69: Modelrii relaionale propuse de Ullman pentru exemplul 5.3 i lipsete pentru a fi corect tocmai constrngerea ca graful asociaiei COND_NSCRIERE = (CURSURI, PRECONDIII) s fie aciclic: n absena unei asemenea constrngeri, coninutul acestei relaii ar putea include simultan tuplii (c,c') i (c',c), ceea ce ar mpiedica orice student s se nscrie vreodat la cursurile c sau c'!

Problema aciclicitii grafurilor este, desigur, mult mai complicat dect n contraexemplul de mai sus, deoarece trebuie interzise ciclurile de orice lungime i nu doar cele de lungime 2.
Exemplul 5.70 : COND_NSCRIERE nu ar trebui s poat memora simultan nici tuplii (c,c'), (c',c''), (c'',c), cci i acetia formeaz un ciclu (de lungime 3) i aa mai departe. Ca atare, modelarea corect n MMED a acestui exemplu include i constrngerea aciclic COND_NSCRIERE.

Evident c i ignorarea acestui tip de constrngeri conduce la anomalii de actualizare: de exemplu, inseria unui tuplu compatibil n accepiune relaional cu un coninut valid al COND_NSCRIERE care nchide vreo bucl n graful acestei asociaii, conduce la o anomalie de inserie. n consecin, MMED include i aciclicitatea printre constrngerile primitive. De remarcat c aciclicitatea este o generalizare recursiv a non-reflexivitii.

Reamintim c o relaie binar R peste o mulime M se zice tranzitiv dac aR b bR c aR c, a,b,cM. 117
64

5.4.6 Teoria buclelor nchise

Privite drept grafuri, DEA pot prezenta bucle nchise. Cteodat, acestea sunt complet neinteresante. De cele mai multe ori ns, buclele nchise constituie adevrate capcane n modelarea datelor, cci ori ascund constrngeri, ori dezvluie necesitatea simplificrii modelului prin renunarea la una dintre funciile care nchid bucla. Concluzia acestei subseciuni trebuie s fie aceea c orice bucl nchis trebuie riguros analizat, trebuie desfcut dac acest lucru este cu putin, iar dac nu, completat cu toate constrngerile necesare.
5.4.6.1 Bucle simple

Aparent, pentru a modela structura de directoare a unei partiii, este suficient definirea unei submulimi DIRECTOARE FIIERE i a unei funcii Tata, conform urmtoarei DEA:
DIRECTOARE Tata

Dup cum tim ns, exist dou constrngeri adiionale: nici un director nu-i poate fi strmo i directorul rdcin nu are tat. Prima dintre ele se poate modela simplu, folosind aciclicitatea; pentru a doua, este necesar o constrngere obiect. Ca atare, modelul corect este urmtorul:
DIRECTOARE FIIERE Submulimea fiierelor de tip director (ale partiiei curente). Tata : DIRECTOARE DIRECTOARE, aciclic Nici un director nu-i poate fi strmo (ierarhia directoarelor este arborescent). PropDirRdcin : (!xDIRECTOARE)(Tata(x)=NULL) Exist un unic director (rdcina arborelui) care nu are tat.

De remarcat c, n prezena partiiilor, constrngerea PropDirRdcin poate fi nlocuit elegant folosind imagini de funcii:
PARTIII Mulimea partiiilor de interes. DIRECTOARE FIIERE Submulimea fiierelor de tip director. Rdcini : PARTIII DIRECTOARE, total Fiecrei partiii i corespunde un unic director rdcin. Tata : DIRECTOARE Im(Rdcini) DIRECTOARE, total, aciclic Nici un director nu-i poate fi strmo (ierarhia directoarelor este arborescent); directoarele rdcin nu au tat.

Desigur c acest exemplu nu constituie vreo excepie, cci sunt multe cazuri de asemenea funcii care trebuie s fie aciclice, precum, de exemplu: ef : ANGAJAT ANGAJAT, aciclic Strmo : PERSOANE PERSOANE, aciclic n mod trivial, trebuie analizate cu aceeai atenie i buclele simple nchise definite de asociaii: exemplul 5.70 ne-a artat deja c trebuie s adugm constrngerea aciclic COND_NSCRIERE urmtoarei DEA:

118

COND_NSCRIERE PRECONDIII CURSURI

Modelul corect pentru ea este deci urmtorul:

PRECONDIII CURSURI Submulimea cursurilor a cror absolvire condiioneaz nscrierea la alte cursuri. COND_NSCRIERE = (PRECONDIII, CURSURI) aciclic Mulimea condiiilor de nscriere la cursuri.

De remarcat c, n mod evident, nici o bucl simpl nu ar putea fi eliminat fr a se pierde informaii.
5.4.6.2 Diagrame comutative de funcii

Diagramele comutative de funcii pot fi trivial modelate cu ajutorul constrngerilor de tip egaliti de funcii. De exemplu, pentru urmtoarea DEA (modelnd o mulime de baze de date locale, nedistribuite i nereplicate) exist evident constrngerea orice fiier memornd o parte a unei bd trebuie s aparin unui director de pe calculatorul gzduind server-ul de bd ce gestioneaz acea bd:
Director FIIERE DIRECTOARE Calculator Bd BDATE Server SERVERE CALCULATOARE Gazd

Schema MMED corespunztoare trebuie deci s includ i constrngerea ComutFiiere: Gazd Server Bd = Calculator Director, unde: Director : FIIERE DIRECTOARE, total Calculator : DIRECTOARE CALCULATOARE, total Bd : FIIERE BDATE Server : BDATE SERVERE, total Gazd : SERVERE CALCULATOARE, total De remarcat c aceast bucl nu poate fi deschis fr a pierde informaii, cci nici una dintre funciile de mai sus nu este calculabil din celelalte (nici una nu admite invers). Acest lucru este natural, deoarece partea stng a egalitii de funcii modeleaz metacataloagele serverelor de bd, n timp ce partea dreapt modeleaz structura directoarelor sistemelor de operare. Desigur c, n general, implementarea unei astfel de constrngeri este costisitoare, att n termenii efortului de programare necesar, ct i n cei ai performanei aplicaiei de bd corespunztoare. Ca atare, atunci cnd desfiinarea buclei este posibil, acest lucru trebuie obligatoriu fcut, mai ales c i modelul echivalent rezultat este mai simplu. De foarte multe ori, din egalitatea de funcii aferent comutativitii se poate calcula una dintre ele n funcie de celelalte; n asemenea cazuri, aceast funcie trebuie eliminat din model (sau pstrat doar ca funcie calculat), iar egalitatea aferent de funcii se va transforma astfel dintr-o constrngere ntr-o interogare. De exemplu, urmtoarea DEA prezint un asemenea caz tipic:
119

CLIENI LocCli LOCALITI ara CLIENI LocCli ara LOCALITI araCli RI LocCli ara LOCALITI CLIENI araCli RI

*araCli
RI

LocCli: CLIENI LOCALITI LocCli: CLIENI LOCALITI ara : LOCALITI RI, total ara : LOCALITI RI, total araCli : CLIENI RI *araCli = ara LocCli araCli = ara LocCli

De remarcat c egalitatea de funcii este o constrngere n modelul din stnga (formaliznd: orice client este localizat n ara creia i aparine localitatea n care el este localizat), pentru c topate funciile implicate sunt definite ca fundamentale, n timp ce n partea dreapt ea constituie definiia funciei calculate *araCli. Aa cum este ntotdeauna de ateptat n asemenea cazuri, soluia alternativ de modelare este mai bun nu doar la nivelurile relaional i fizic (att n termenii spaiului de memorare, ct i n cei ai timpilor de execuie), ci i la nivel conceptual, deoarece este mai natural i deci elegant.
5.4.6.3 Comutativiti locale

Chiar dac o diagram nchis nu comut, ea nu trebuie considerat ca fiind neinteresant fr o analiz mai aprofundat. Primul lucru ce mai trebuie investigat n acest caz este eventuala comutare prin intermediul unei funcii unitate. Figura urmtoare prezint o asemenea diagram: dei necomutativ, ea are evident nevoie de o constrngere care s asigure plauzibilitatea datelor valide i anume capitala oricrei ri trebuie s fie un ora din aceea ar.
RI Capitala Jude ORAE JUDEE Capitala : RI ORAE Jude : ORAE JUDEE, total ara : JUDEE RI, total 1RI : RI RI, total C1 : ara Jude Capitala = 1RI
Fig. 12: Exemplu de diagram local comutativ

ara

1RI

n MMED, comutativitile implicnd funcii unitate se zic locale. De remarcat c nu este nevoie de vreo declaraie explicit n model pentru aceste funcii (exact ca i n cazul altor funcii standard n matematic precum incluziunile sau proieciile Carteziene canonice, imaginile i preimaginile funciilor etc.).
120

Fiind bijective, funciile unitate pot fi privite n asemenea cazuri ca nchiznd comutativ n sens convenional diagrame echivalente, n care bucla lor este desfurat prin instanierea separat a domeniului i codomeniului, ca n figura urmtoare:
RI Capitala ORAE Jude

1RI

RI ara JUDEE

Fig. 13: Transformarea ntr-o comutativitate convenional

Evident, spre deosebire de cazul comutativitilor standard, nu exist pentru cele locale nici o soluie alternativ de modelare (cci funciile unitate nu pot fi ignorate i nici nu poart vreo semantic). Trivial, comutativitile locale trebuie luate n considerare i n cazul celor convenionale, deoarece se poate ntmpla ca o diagram s comute att n sens clasic, ct i local.
5.4.6.4 Comutativiti generalizate

n 5.6.2.2, sunt prezentate exemple de diagrame comutative implicnd nu doar funcii, dar i asociaii. Figura 15 prezint o subdiagram de acest tip. De remarcat cheile structurale ale celor dou asociaii, ROUTE_CONFIGS i FLIGHTS: cum rutele aeriene nu pot nchide bucle (re-ateriznd pe un acelai aeroport), urmeaz c ROUTES AIRPORTS este cheie; cum, n mod trivial, pe orice rut,orice escal se face de ctre orice avion pe un unic aeroport, rezult c i ROUTES POSITIONS este cheie. Similar, ROUTES TAKEOFFTIMES este cheie n FLIGHTS, deoarece, evident, pentru orice rut, n orice moment, exist un unic avion ce o deservete; i cum un avion nu poate zbura la un moment dat dect pe o unic rut, rezult n mod trivial c i PLANES TAKEOFFTIMES este cheie. De remarcat i funcia structural Flight, definit pe asociaia FLIGHTS, care modeleaz o ierarhie mixt de tipuri de obiecte. Constrngerea C1 formalizeaz comutativitatea sub-diagramei din Fig. 15 (orice zbor trebuie asigurat cu un tip de avion ce are toate tipurile de locuri rezervate de biletele emise pentru acel zbor; i.e., de exemplu, o instan a bd n care un bilet pentru locul nr. 21 la clasa Business a fost eliberat pentru un avion care are doar 20 de locuri la aceasta clas sau nu are de loc asemenea locuri ar trebui evident respins ca invalid). Desigur c singurul lucru ce difer n acest exemplu fa de cele din subseciunile precedente este acela c este n plus implicat i o proiecie Cartezian canonic (i anume prPLANES(FLIGHTS)), ceea ce ar face ca ruperea buclei s fie i mai costisitoare. Constrngerea C2 este impus de analiza sub-diagramei nchise din Fig. 16: pe orice bilet, aeroporturile de mbarcare i destinaie trebuie s aparin rutei pentru care s-a cumprat / rezervat biletul i, mai mult, poziia n rut a celui de mbarcare trebuie s fie strict mai mic dect a celui de destinaie. De notat c aceast constrngere nu este nici ea de tip convenional, ci este o comutativitate generalizat: n asemenea comutativiti, cel puin un graf implicat este al unei asociaii (deci relaii nonfuncionale). Trivial, asemenea bucle nchise nu pot fi niciodat rupte, deci singura soluie de modelare cu putin este adugarea constrngerii respective la schema bd. Comutativitile locale trebuie evident verificate i n cazul celor generalizate.

121

ROUTE_CONFIGS = (ROUTES, POSITIONS, AIRPORTS; {ROUTES, POSITIONS}, {ROUTES, AIRPORTS}) FLIGHTS = (ROUTES, PLANES, TAKEOFFTIMES; {ROUTES, TAKEOFFTIMES}, {PLANES, TAKEOFFTIMES}) Source : TICKETS AIRPORTS, total Destination : TICKETS AIRPORTS, total Seat : TICKETS SEATS, total PlaneType : PLANES PLANE_TYPES, total PlaneTypeConfig : SEATS PLANE_TYPES, total Flight : TICKETS FLIGHTS, total C1: PlaneType prPLANES(FLIGHTS) Flight = PlaneTypeConfig Seat C2: (tTICKETS)(x,yROUTE_CONFIGS) (prROUTES(ROUTE_CONFIGS)(x) = prROUTES(ROUTE_CONFIGS)(y) = = prROUTES(FLIGHTS)(Flight(t)) (Source(t) = prAIRPORTS(ROUTE_CONFIGS)(x) Destination(t) = prAIRPORTS(ROUTE_CONFIGS)(y) prPOSITIONS(ROUTE_CONFIGS)(x) < prPOSITIONS(ROUTE_CONFIGS)(y) Source(t) = prAIRPORTS(ROUTE_CONFIGS)(y) Destination(t) = prAIRPORTS(ROUTE_CONFIGS)(x) prPOSITIONS(ROUTE_CONFIGS)(y) < prPOSITIONS(ROUTE_CONFIGS)(x)))
Fig. 14: Subschem MMED a unei bd simple pentru rezervarea de bilete aeriene

PlaneType PLANE_TYPES PlaneTypeConfig Seat SEATS PLANES

prPLANES(FLIGHTS) FLIGHTS Flight TICKETS

Fig. 15: Subdiagrama nchis a crei analiz duce la formalizarea constrngerii C1

5.4.6.5 Bucle nchise neinteresante

Din fericire, nu toate sub-diagramele nchise conin asemenea constrngeri suplimentare. Fig. 17 i 18 prezint un asemenea exemplu. n mod evident, n aceast diagram Proprietar Utilizator Gazd (cci utilizatorul curent al unui calculator ce gzduiete i nite bd nu este n general proprietarul vreuneia dintre ele) i nu exist nici o comutativitate local (ct despre cele generalizate, nici nu se poate pune problema n absena oricrei asociaii).
Flight TICKETS FLIGHTS ROUTES POSITIONS Source ROUTE_CONFIGS Destination AIRPORTS
Fig. 16: Subdiagrama nchis a crei analiz duce la formalizarea constrngerii C2

122

PERSOANE Proprietar Utilizator BDs Gazd CALCULATOARE

Gazd : BDs CALCULATOARE, total Proprietar : BDs PERSOANE, total Utilizator:CALCULATOAREPERSOANE

Fig. 18: Schema MMED corespunztoare

Fig. 17: Exemplu de diagram nchis neinteresant

Cu toate acestea, nici o diagram nchis nu trebuie declarat ca fiind neinteresant dect dup o analiz aprofundat, pentru care recomandm urmtorul algoritm de asisten a modelrii buclelor nchise.
5.4.6.6 Algoritmul de asistena analizei buclelor nchise

Algoritmul 5.42 (asistena modelrii buclelor nchise) Intrare: o diagram E-A Ieire: mulimea tuturor constrngerilor implicate de buclele nchise ale diagramei Strategie:
for (toate sub-diagramele nchise) { if (sub-diagrama este o bucl simpl) { verific dac bucla nu trebuie s fie aciclic, cheie, surjectiv, idempotent, reflexiv, tranzitiv, simetric, antisimetric, surjecia canonic a unui sistem de reprezentani i/sau implicat n vreo constrngere obiect; } elseif (sub-diagrama comut convenional) { formalizeaz constrngerea de comutativitate corespunztoare; analizeaz dac bucla poate fi rupt sau nu; if (bucla se poate rupe) simplific schema eliminnd funcia calculabil; eventual, dac considerente de performan o impun, adaug la schem funcia calculat corespunztoare; } elseif (asociaii non-funcionale implicate n bucl) for (toate nodurile buclei)//nodurile sunt mulimi de obiecte verific dac exist vreo comutativitate generalizat asociat nodului current; n caz afirmativ, formalizeaz constrngerea obiect corespunztoare; for (toate nodurile buclei) // nodurile sunt mulimi de obiecte verific dac exist vreo comutativitate local asociat nodului current; n caz afirmativ, formalizeaz constrngerea obiect corespunztoare; }; adaug toate constrngerile suplimentare gsite aplicnd algoritmul la schema bd; };

SfAlgoritm 5.42
Fig. 19: Algoritmul de asisten a modelrii buclelor nchise

123

5.5

Teoria asociaiilor

5.5.1 Structura asociaiilor

Pentru a putea defini corect elementele grafului unei asociaii este desigur nevoie mai nti de identificarea unic a elementelor asociate din fiecare mulime suport a asociaiei. MMED folosete pentru aceasta tocmai identificatorii de obiect ai suporilor. 65 Fie un tip oarecare fixat de asociaii A , fie r aritatea sa (i.e. numrul mulimilor suport pe care este definit asociaia), fie S1, S2,, Sr suporii lui A, iar #S1, #S2, ,#Sr identificatorii de obiect ai suporilor. Extindem canonic identificatorii de obiect #Si, 1 i r, de la supori la graful asociaiei A astfel: Ai : A NAT, Ai(o1,..., oi,..., or) = #Si(oi), oj, 1 i, j r. Propoziia 5.42 : Extensiile canonice Ai, 1 i r, nu sunt n general injective. Dem : Fie asociaia STOCURI, iar A1 i A2 proieciile sale canonice pe PRODUSE i MAGAZII. Dac A1 ar fi injectiv, ar nsemna c orice produs ar necesita o magazie proprie pentru a fi stocat; dac A2 ar fi injectiv, ar nsemna c nici o magazie n-ar putea stoca mai mult de un singur produs. Mai mult, dac ambele ar fi injective, atunci orice magazie ar putea stoca un singur produs i orice produs n-ar putea fi stocat n mai mult de o magazie. Evident, aceste situaii nu sunt n general plauzibile, deci, A1 i A2 nu sunt injective.

Lema 5.43 Produsul

= Ai al tuturor extensiilor canonice de mai

1i r

sus este ntotdeauna injectiv. Dem: Prin definiie, mulimile nu admit duplicate. Cum graful asociaiei este o mulime, SA este injectiv . $ Corolar 5.44 card A r. Observaia 5.45 a) Aceast lem sugereaz faptul c orice tip de asociaii conine obligatoriu extensiile canonice la graful asociaiei ale identificatorilor de obiect ai suporilor $ acesteia. Produsul SA , zis suportul grafului asociaiei, identific unic elementele mulimii de asociaii, ca i tipul nsui.
$ A = A0, A1,..., Ar,..., An = A0 SA Ar+1,..., An, r < n, unde atributele de la r + 1 la nNAT sunt eventualele atribute explicit definite de proiectantul bd pe graful asociaiei A. c) Privind dual, este evident c proieciile canonice ale grafului unei asociaii pe supori sunt exact extensiile canonice corespunztoare: prSi A = Ai, i, 1 i r.
Exemplul 5.71 Revenind la exemplul 5.69 de mai sus (mbogit de exemplul 5.70) i preciznd cteva atribute naturale suplimentare definite peste cele cinci mulimi de entiti i trei de asociaii implicate, se poate obine bd prezentat n figura 5.1.
Desigur c orice cheie este suficient pentru identificarea unic a obiectelor; MMED alege natural dintre ele identificatorul de obiect din considerente legate de izolarea asociaiilor n ierarhii, de optimizare simultan a spaiului de memorare necesar i a vitezei de execuie a programelor, ca i din considerente de omogenitate a tratrii asociaiilor i entitilor. 124
65

b) Notnd cu A0 = #A identificatorul de obiect al lui A, rezult c:

Identificatorii de obiect pentru fiecare mulime n parte sunt, evident: #Loc, #ara, #Discipl., #Olimp., #Proba, #LocConcurs, #Sp. i #Part. n PROBE, Disciplina i Olimp. sunt extensiile canonice ale #Discipl., respectiv #Olimp.; similar, n LOCALIZ_CONCURS, Loc i Concurs extind canonic #Loc, respectiv #Proba; n PARTICIPRI, Sportiv extinde #Sp., iar LocConcurs pe #LocConcurs; se poate observa c nici una dintre aceste extensii nu este injectiv, dar produsul lor corespunztor dou cte dou este injectiv (identificnd unic programul olimpiadelor, localizarea desfurrii concursurilor, respectiv participarea sportivilor la ele). De exemplu, tipul LOCALIZ_CONCURS = {#LocConcurs, Loc, Concurs, DataInc., DataSf., Spect., ncasri} are dou chei: #LocConcurs i {Loc, Concurs}. Ca atare, de exemplu, cel de-al cincilea tuplu al acestei relaii memoreaz informaia c la San Francisco, ntre 18.06.96 i 10.07.96, s-a desfurat o parte a turneului olimpic de fotbal (organizat n cadrul Jocurilor Olimpice 1996), la care au asistat 150.000 spectatori, ce au asigurat ncasri de 100.000$. Similar, de exemplu, ultimii doi tupli ai PARTICIPRI memoreaz informaia c Michael Nylander a participat la turneul de hochei din cadrul Jocurilor Olimpice 1994, jucnd de 4 ori la Albertville i de 2 ori la Grenoble. De remarcat, n plus, importana deosebit a identificatorilor de obiect pentru grafurile asociaiilor: de exemplu, sintactic, PARTICIPRI ar fi putut fi la fel de corect definit i n absena #LocConcurs, extinznd canonic n schimb Loc i Concurs (cheile fiind echivalente). Aceast soluie ar fi condus ns la o grav anomalie de actualizare: dac n LOCALIZ_CONCURS se actualizeaz vreuna din valorile Loc sau Concurs ale unui tuplu referit n PARTICIPRI, exact aceeai modificare ar fi trebuit fcut n toi tuplii PARTICIPRI implicai! Iar dac, recursiv, PARTICIPRI n-ar avea identificatorul de obiect #Part i ar fi la rndul ei suportul unei alte asociaii ierarhic superioar, anomalia de actualizare semnalat s-ar propaga pn la rdcina acestui arbore de ierarhizri! Evident ns c, n prezena identificatorilor de obiect #LocConcurs i #Part (care izoleaz sintactic ntre ele nivelurile ierarhiei de asociaii), schema de bd nu prezint nici o asemenea anomalie.
5.5.1.1 Funcionalitile grafurilor de asociaii

Ca i relaiile matematice din care provin, grafurile de asociaii pot avea funcionaliti interne. Exemplele cele mai convingtoare le constituie, desigur, grafurile relaiilor binare funcionale, pentru care sunt posibile 3 cazuri: nici o funcionalitate (relaii binare oarecari), o funcionalitate (funcii oarecari) sau dou funcionaliti (funcii injective). Asemenea funcionaliti pot exista ns i n cazul general al relaiilor n-are, n > 2. Altfel spus, revenind la lema 5.43, este natural s ne ntrebm dac suportul grafului oricrei asociaii este nu doar injectiv, ci minimal injectiv. Urmtorul exemplu ne arat c acest lucru nu este n general adevrat.
Exemplul 5.72 Fie o bd potal cu urmtoarele tipuri de obiecte: LOCALITI = #Loc, Den_Loc, Jude, CODURI_POTA = #Cod i ADRESE = #Adr, Adresa, Loc, Careu, Descr_imobil, unde Adresa memoreaz numele strzii i numrul imobilului, Loc este cheie strin propagat de funcia Localiz_Adresa : ADRESE LOCALITI, iar Careu memoreaz coordonatele careului n care se afl localizat imobilul de la
125

adresa curent (n paginile unui ghid cu hri caroiate ale tuturor localitilor). 66 Peste aceste trei tipuri de entiti este definit tipul de asociaii CODIF_POTAL=(CODURI_POTA,LOCALITI,ADRESE), care memoreaz codificarea potal a adreselor din fiecare localitate, dup urmtoarele reguli: ( i) codurile potale sunt toate distincte ntre ele ( ii) pentru unele localiti (mici) exist cte un singur cod potal, indiferent de adresa imobilelor n cadrul localitii (iii) n alte localiti (foarte mari) fiecare imobil (sau grup de imobile adiacente) are asociat un unic cod potal. Figura 5.10 prezint un posibil coninut al acestei bd (din care am selectat doar atributele relevante n contextul discuiei). 67 Ullman [337] formalizeaz constrngerile (i) i (ii) prin #Cod Loc, iar (iii) prin Loc Adr #Cod. n plus, este evident c (iii) implic i Loc #Cod Adr. Aceste FD pun n eviden faptul c, astfel definit, graful CODIF_POTAL are trei funcionaliti interne.
$ Definiia 5.46 Fie SA suportul grafului unei asociaii oarecari A ; A se zice $ funcional (sau avnd o funcionalitate intern) de la X la Y, X, Y SA (X, Y ), dac X Y. $ Fie r aritatea lui SA . Propoziia 5.47: SA poate avea cel mult (2r-1)2 funcionaliti. Dem: Fie 1 i, j n; numrul tuturor funcionalitilor ce au i supori n partea stng i j i n cea dreapt este C n C nj .Deci, numrul tuturor funcionalitilor lui SA este:
n n 1 1 i C n C nj = C n C n + ... + C nn + C n2 C n + .. + C nn + .. + C nn C n + .. + C n = j =1 1 1 i =1
n

1 1 1 = C n + .. + C nn C n + .. + C nn = C n + .. + C nn

)(

) (

) = (C
2

0 n

1 0 + C n + ... + C nn C n

) = (2
2

LOCALITI (#Loc) ADRESE (#Adr) Loc. #Loc, Adresa CODIF_POTAL (#CodLoc, Den_Loc LocAdr) Loc#Loc, Adr#Adr #Loc 1 2 100 3 210 200 105 Den_Loc Bucureti Sibiu Lancrm Timioara Spna irnea Rinari #Adr 10 12 3873 1005 1006 1201 2010 2020 16 3500 3212 Adresa Bd. Carol I, nr. 37 Bd. Carol I, nr. 39 fund. Ilici, nr. 2 Bd. Carol I, nr. 39 Bd. Carol I, nr. 37 str. M.A.aguna, nr.1 Bd. M. Viteazu, nr. 8 Bd. C. Sylva, nr. 12 Bd. L. Blaga, nr. 1 str. S.I.Ptra, nr.15 str. L. Blaga, nr. 1 Loc. 1 1 1 2 2 105 3 3 1 210 100 #Cod 2400 1900 71137 71139 75992 72231 1200 6810 1412 2401 74415 Loc 2 3 1 1 1 1 100 210 200 105 1 Adr

10 12 3873 16

111

Figura 5.10 Un exemplu de graf al unei asociaii ternare cu funcionaliti interne

$ Propoziia 5.48 SA nu este ntotdeauna minimal injectiv.

Pentru o descriere complet n MMED a acestei bd vezi i figura 5.7 De remarcat c, datorit regulii (i), drept valori ale identificatorului de obiect #Cod au fost alese chiar codurile potale. 126
66 67

Dem.: ntr-adevr, revenind la exemplul 5.10, se observ c att LocAdr, ct i $ Loc#Cod sunt minimal injective, deci chei n SA = LocAdr#Cod, care e doar supercheie. Includerea n schema asociaiilor a tuturor cheilor suportului grafului este crucial; n caz contrar, s-ar permite memorarea de informaii invalide. Exemplul 5.73: nespecificarea celor dou chei de mai sus ar permite existena simultan n graful CODIF_POTA a tuplilor aberani (c, l, a) i (c', l, a), cu c c', ceea ce ar nsemna c imobilului situat la adresa a n localitatea l i corespund dou coduri potale distincte!

Evident ns c nu orice funcionalitate a unui graf de asociaii ne dezvluie o cheie a sa. Contraexemplul clasic l ofer chiar #Cod Loc din exemplul 5.10: datorit faptului c pentru majoritatea localitilor exist cte un singur cod potal pentru toate adresele din fiecare localitate, #Cod nu este o cheie a CODIF_POTAL. 68 Din acest motiv, Ullman [337] propune CODIF_POTAL drept exemplul clasic de relaie care este n FN3, dar nu i n FNBC. 69 Observaia 5.59 $ a) Teorema 5.58 caracterizeaz doar cheile SA , zise chei structurale ale asociaiei. Cum pe graful oricrei asociaii se pot defini oricte atribute, este posibil ca asociaia s mai aib i alte chei n afara celor structurale. b) Cheile structurale se declar n MMED odat cu asociaia; exemplificm sintaxa folosit tot cu ajutorul exemplului 5.10: CODIF_POTAL = (CODURI_POTA, LOCALITI, ADRESE, CODURI_POTA, LOCALITI, LOCALITI, ADRESE). Colecia suporilor grafului este deci urmat de mulimea cheilor structurale. $ $ Lema 5.42 ne asigur c SA conine ntotdeauna cel puin o cheie; dac SA este $ cheie, atunci lista cheilor structurale poate fi vid, MMED completnd-o implicit cu SA
5.5.1.2 Proiectarea asistat de calculator a schemelor de asociaii

Teorema 5.58 ofer i instrumente sintactice suficient de puternice pentru a permite proiectarea unui algoritm de asisten a specificrii tuturor cheilor structurale ale unei asociaii. S observm ns nti c, n cazul particular al asociaiilor ternare, din cele 49 de funcionaliti posibile, 19 sunt triviale, nc 18 sunt redundante, iar alte 6 nu sunt pline. Rmn deci 6 funcionaliti, din care, simultan, doar maxim 3 pot fi datorate cheilor. n total ns, exist 18 combinaii posibile de chei. 70 Similar, n cazul asociaiilor cuaternare, rmn 14 funcionaliti pline, neredundante, din care, simultan, pot coexista maxim 6 chei.

68 "Surpriza" furnizat de interpretarea "oricare ar fi" a valorilor nule este c, ntr-un asemenea context, #Cod devine cheie! 69 n MMED, CODIF_POTA este n FNBC, asertarea #Cod Loc pentru graful ei fiind imposibil! De fapt, cf. propoziiei 5.10.(ii), aceast FD este o consecin a unei funcii Loc_Codif : CODURI_POTA LOCALITI, care, conform lemei privind propagarea cheilor, are ca efect adugarea #Cod Loc_Codif la tipul CODURI_POTA. Desigur ns c n MRD, care nu este "tipat", aa ceva nu poate fi formalizat! 70 De exemplu, dac suporii sunt A, B, C, atunci cele 6 funcionaliti pline, neredundante sunt: A BC, B AC, C AB, AB C, AC B, BC A. Simultan, pot fi cte 3 chei doar A, B, C i AB, BC, AC; cte 2 doar A, B, A, C, B, C, A, BC, B, AC, C, AB, AB, BC, AC, BC, AB, AC; iar doar una: A, B, C, AB, AC, BC, ABC. n total deci sunt 18 posibiliti, care, evident, justific chiar i pentru cazul cel mai simplu (r=3) necesitatea Algoritmului 5.31. 127

Corolar 5.60 (i) Eliminnd din mulimea tuturor funcionalitilor posibile ale unui graf de asociaii orice funcionalitate trivial, redundant sau non-plin, din funcionalitile rmase nc se mai pot depista toate cheile structurale ale asociaiei. $ $ (ii) Dac K este cheie structural a unei asociaii SA , atunci, S SA K, KS nu $ poate fi cheie n SA . $ Fie r = card SA . $ Propoziia 5.61 SA are cel mult 2r-2 funcionaliti pline i neredundante. 71 Dem: Fie 1 i < n. Exist cel mult C n C ni funcionaliti pline i neredundante care au
n i i supori n partea stng . Cum C n i = 1, i{1,,n}, atunci numrul tuturor funcio-

n i

1 n1 2 n 2 n1 1 nalitilor pline i neredundante sunt este: C n C n1 + C n C n2 + ... + C n C1 =

1 n 0 1 n n 0 n C n + ... + C n 1 = C n + C n + ... + C n 1 + C n C n C n = 2n 2.
$ Propoziia 5.62 SA are cel mult Cr 2 chei structurale. 72 Demonstraia acestei propoziii este similar cu demonstraia lemei lui Sperner. Pe baza 5.60, 5.61 i 5.62 se poate proiecta algoritmul 5.63 de asistare a specificrii cheilor structurale ale oricrei asociaii (vezi figura 5.11). Teorema 5.64 (Caracterizarea algoritmului 5.63): (i) Complexitatea algoritmului este O(2n) (ii) Algoritmul 5.63 este solid i complet. (iii) Algoritmul 5.63 este optimal, i.e. pune proiectantului schemei de bd numrul minim cu putin de ntrebri necesare pentru a specifica toate cheile asociaiilor. Dem: (i) Trivial, deoarece algoritmul conine 3 bucle, toate finite, prima depinznd de n, r

n dar mpreun cu a doua avnd C 1 + ... + C n 1 = 2n-2 numr maxim de pai, iar cea de-a n

de pai. treia avnd cel (ii) Se observ c algoritmul genereaz toate cheile posibile, deoarece sunt generate, n cazul cel mai defavorabil, toate cele 2n-2 submulimi ale oricrui tip de cardinal n,
respectiv toate cele maxim Cn 2 chei posibile simultan. Mai mult, cum se verific nti minimalitatea fiecreia din ele i abia apoi se ntreab proiectantul dac produsul curent este sau nu cheie, rezult c algoritmul calculeaz la fiecare pas doar cheile posibile n acel moment. (iii) n cel mai ru caz (i.e. toate rspunsurile proiectantului sunt nu) trebuie desigur puse 2n-2 ntrebri (deoarece sunt excluse att mulimea vid, ct i SA ), adic exact numrul ntrebrilor generate de algoritm, ntruct nici o posibil cheie nu este procesat mai mult de o singur dat. n toate celelalte cazuri, deoarece algoritmul ncepe cu proieciile atomice i adaug produselor la fiecare bucl exterioar cte o nou proiecie (pn la n-1), rezult c fiecare cheie n parte elimin numrul maxim posibil de ntrebri ulterioare. n

n mult Cn 2

71

$ SA .
72

$ n partea stng a FD corespunztoare se gsesc elementele mulimii prilor lui SA , cu excepia i

k

Partea ntreag a lui r/2 definete coeficientul maxim dintre toi Cr . 128

Observaia 5.65 Desigur c algoritmul 5.63 nu poate garanta dect corectitudinea sintactic a structurii cheilor unei asociaii; rspunderea pentru corectitudinea semantic nu poate reveni dect proiectantului schemei bd! Algoritmul 5.63 asist ns riguros i eficient proiectarea cci: pornete cu posibilele chei de aritate minim (1), care sunt i cel mai uor de descoperit (validat) de ctre proiectant i care, dac se vdesc a fi chei structurale, elimin din curs cele mai multe dintre restul de posibiliti rmase; nu se termin nainte de epuizarea tuturor posibilitilor de a mai descoperi / valida nc o cheie structural; nu propune pentru validare dect posibile chei structurale; se termin de ndat ce au fost validate numrul maxim de chei posibile simultan; dac nu a fost validat nici o posibil cheie structural, adaug automat la schema asociaiei cheia maximal format din toi suporii asociaiei; n general, pentru orice asociaie definit n schema bd i pentru orice cheie structural a unei asociaii, algoritmul adaug schemei bd dependena de cheie corespunztoare. Este drept c, n peste 25 de ani de experien n domeniu, nu am ntlnit nici n practica modelrii datelor i nici n literatura de specialitate dect cteva asociaii ternare, una-dou cuaternare i nici una de aritate mai mare dect 5.73 Avnd ns n vedere faptul c, deja pentru cazul ternar, sunt att de multe configuraii posibile de chei structurale, se justific pe deplin proiectarea i recursul la algoritmul 5.63.
5.6 Normalitatea versus corectitudinea schemelor

5.6.1 Descrierea obiectelor

Chiar i incluziunile, egalitile i disjunciile pot conduce la anomalii de actualizare n accepiunea relaional. De exemplu, tergerea tuplului corespunztor unei persoane dintr-o bd memornd ierarhia CADRE_DIDACTICE ANGAJAI PERSOANE poate conduce la un coninut invalid (dac acea persoan este, de exemplu, cadru didactic). De aceea, MMED consider o abordare orientat obiect a noiunilor de constrngere primitiv, compatibilitate semantic i anomalie de actualizare. Astfel, pe lng descrierea primitiv (fundamental) a obiectelor memorat de tipul corespunztor de obiecte, orice obiect beneficiaz n MMED de o descriere complet: completnd descrierea primitiv, aceasta include i mulimea tuturor legturilor sale cu alte obiecte (nu neaprat de acelai tip), adic, n fond, mulimea tuturor acestor obiecte. Formal, descrierea primitiv a oricrui obiect este dat de imaginea tipului de obiect corespunztor (aici interpretat ca produsul familiei tuturor atributelor definite pe mulimea respectiv de obiecte, vezi 5.3.2) pentru mulimea format din acel obiect; descrierea complet a obiectului include i imaginea, pentru aceeai mulime, a tuturor funciilor structurale definite pe respectiva mulime de obiecte, ca i a tuturor suporilor de grafuri ale asociaiilor care sunt construite i peste mulimea respectiv de obiecte.

Ne-am hazarda chiar s propunem drept "axiom" urmtoarea conjectur: "Nu exist asociaii de aritate mai mare dect 5. Orice asemenea exemplu este, de fapt, un contraexemplu de modelare a datelor: ori unul sau mai muli supori sunt inutili, ori semantica asociaiei este suprancrcat cu semantica a dou sau mai multe asociaii, eventual ierarhic structurate, a cror aritate este, pentru fiecare n parte, cel mult 5. Dac totui asemenea asociaii exist, atunci ele depesc capacitatea noastr de a le decela i formaliza! 129
73

 Intrri: mulimea suporilor unei asociaii oarecare ( SA i r = card SA ) Ieiri: mulimea cheilor structurale ale asociaiei (K, k = cardK). Procedeu: (bazat pe corolarul 6.28 i propoziiile 6.29 i 6.30) K =; k = 0;

repet pn la specificarea a maxim C chei structurale sau pn la epuizarea celor maxim 2r-2 funcionaliti pline i neredundante; dac partea stng (ps) a funcionalitii curente nu include nici o cheie structural atunci propune proiectantului ps drept cheie structural; dac proiectantul valideaz minimal injectivitatea ps atunci K = K {ps}; k = k + 1; sfdac; sfdac; sfrepet; $ dac k == 0 // nici o cheie structural; doar SA este cheie! $ atunci k = 1; K = { SA }; sfdac; Program abstract: k = 0; kmax = C ; i = 1; dowhile i r - 1 and k kmax j = 1; jmax = Cri ; dowhile j jmax $ genereaz Ti, j, a j-a submulime cu i elemente a lui SA ; l = 1; supercheie = fals; dowhile l k and not supercheie if K(l) Ti , j then supercheie = adevrat; else l = l + 1; endif enddowhile; if not supercheie then ntreab proiectantul schemei asociaiei dac Ti, j este cheie structural; if rspunsul este afirmativ then k = k + 1; K(k) = Ti, j; endif endif; j = j + 1; enddowhile; i = i + 1; enddowhile; $ if k == 0 // nici o cheie structural; doar SA este cheie! $ then k = 1; K(1) = SA ; endif; Sfrit algoritm 5.63
Fig. 5.12 Algoritmul de asistena specificrii cheilor structurale 130
r 2 r

r 2 r

Exemplul 5.74 Revenind la exemplul 5.7 i figura 5.1, descrierea primitiv a obiectului x localitatea cu numele Grenoble este Localitate(x) = Grenoble, n timp ce descrierea sa complet este: Localitate(x) = Grenoble, ara(x) = F, LOCALIZ_CONCURS(x,) = Concurs() = 5, PARTICIPARE(,x) = Sportiv() = 1, Sportiv() = 2, Sportiv() = 4 .
5.6.1.1 Constrngeri primitive

n accepia MMED, o constrngere se numete primitiv dac ea este constrngere de domeniu sau dependen cheie sau dependen tipat de incluziune sau disjuncie de mulimi sau surjectivitate de funcii sau egalitate de funcii sau aciclicitate de graf de asociaii. Evident c egalitatea mulimilor este acoperit de (duble) incluziuni, idempotena de egalitatea funciilor, iar sistemele de reprezentani de incluziuni, surjectiviti i idempotene. Ca atare, dei nu sunt primitive nici n MMED, toate constrngerile de tip egalitate de mulimi, idempoten a funciilor i sisteme de reprezentani sunt implicate de constrngeri primitive.
5.6.1.2 Compatibilitate semantic

Simpla lrgire a clasei constrngerilor primitive (n raport cu modelul relaional) nu este suficient pentru a putea oferi definiia i caracterizarea unei forme normale semantice n MMED. Pentru aceasta, este nevoie i de modificarea accepiunii pentru compatibilitate de la cea sintactic relaional, implicnd un tuplu i o relaie, la una semantic, implicnd obiecte i o baz de date n ansamblul ei. n MMED, un obiect (entitate sau asociaie) se zice compatibil (semantic) cu o baz de date dac el nu violeaz constrngerile primitive (n accepia MMED) asociate schemei acelei bd.
5.6.1.3 Anomalii de actualizare a datelor

Despre o schem de bd n MMED se spune c are o anomalie de inserie, dac exist un coninut valid al schemei i un obiect compatibil cu acest coninut astfel nct adugarea obiectului la bd conduce la un coninut invalid. Despre o schem de bd n MMED se spune c are o anomalie de tergere, dac: exist un coninut valid al schemei i un obiect al acestui coninut astfel nct tergerea obiectului din bd conduce la un coninut invalid. Similar, despre o schem de bd n MMED se spune c are o anomalie de modificare, dac exist un coninut valid al schemei i un obiect al acestui coninut astfel nct modificarea descrierii complete a obiectului conduce la un coninut invalid. n concluzie, o schem de relaie n MMED se zice a avea o anomalie de actualizare a datelor dac ea are vreo anomalie de inserie, de tergere sau de modificare.
131

5.6.1.4 Descrierile fundamental i complet a obiectelor

Chiar i incluziunile, egalitile i disjunciile pot conduce la anomalii de actualizare n accepiunea relaional. De exemplu, tergerea tuplului corespunztor unei persoane dintr-o bd memornd ierarhia CADRE_DIDACTICE ANGAJAI PERSOANE poate conduce la un coninut invalid (dac acea persoan este, de exemplu, cadru didactic). De aceea, MMED consider o abordare orientat obiect a noiunilor de constrngere primitiv, compatibilitate semantic i anomalie de actualizare. Astfel, pe lng descrierea primitiv (fundamental) a obiectelor memorat de tipul corespunztor de obiecte, orice obiect beneficiaz n MMED de o descriere complet: pe lng descrierea primitiv, aceasta include i mulimea tuturor legturilor sale cu alte obiecte (nu neaprat de acelai tip), adic, n fond, mulimea tuturor acestor obiecte. Formal, descrierea primitiv a oricrui obiect este dat de imaginea tipului de obiect corespunztor (aici interpretat ca produsul familiei tuturor atributelor definite pe mulimea respectiv de obiecte, vezi 5.3.2) pentru mulimea format din acel obiect; descrierea complet a obiectului include i imaginea, pentru aceeai mulime, a tuturor funciilor structurale definite pe respectiva mulime de obiecte, ca i a tuturor suporilor de grafuri ale asociaiilor care sunt construite i peste mulimea respectiv de obiecte. De exemplu, revenind la exemplul 5.7 i figura 5.1, descrierea primitiv a obiectului x localitatea cu numele Grenoble este Localitate(x) = Grenoble n timp ce descrierea sa complet este: Localitate(x) = Grenoble, ara(x) = F, LOCALIZ_CONCURS(x,) = Concurs() = 5, PARTICIPARE(,x) = Sportiv() = 1, Sportiv() = 2, Sportiv() = 4 .
5.6.2 Normalitate versus corectitudine semantic 5.6.2.1 Normalitatea semantic a schemelor

ntreg eafodajul MMED a fost articulat cu grija de a asigura normalitatea semantic a schemelor de bd proiectate n acest model. Definiiile i caracterizrile date tuturor conceptelor manipulate de MMED fac uoar (chiar dac laborioas) demonstrarea urmtoarei teoreme fundamentale: Teorema 5.70 (Teorema fundamental a MMED) Orice schem de bd n MMED lipsit de constrngeri obiect este n FSN. 74 Observaia 5.71 a) Includerea de constrngeri tuplu n schema unei bd n MMED nu nseamn automat pierderea normalitii semantice a schemei; conform definiiei FSN, dac ele sunt implicate de nchiderea mulimii de constrngeri primitive ale schemei, aceasta evident rmne n FSN. b) Aparent, renunarea la constrngerile tuplu ar constitui un avantaj, cci atunci orice schem ar fi n FSN; aceste constrngeri reprezint ns potenialul infinit de putere al modelrii acurate a datelor! Dac le-am ignora, pe de-o parte, nu am fi capabili s exprimm orice alt constrngere necesar, n afara celor implicate de cele de tip primitiv; pe de alt parte, ne-am interzice accesul la inepuizabilul rezervor de urmtoare tipuri de constrngeri pe care, n viitor, vom fi nevoii (de alte domenii de interes sau de rafinarea n continuare a celor cunoscute) s le includem n clasa celor primitive! c) Deoarece n majoritatea cazurilor practice este nevoie doar de constrngeri de tuplu banale (de tipul celor prezentate n exemplele din Subseciunea 1.3.6),

74

Forma normal semantic, vezi [teza doctorat] 132

implementrile MMED pot limita sever recursul la acest tip de constrngeri astfel nct s poat garanta normalitatea semantic a tuturor schemelor manipulate. d) Considerm c, alturi de contribuiile aduse de F i , bogia taxonomic a C garanteaz superioritatea MMED n raport nu doar cu MRD, ci i cu majoritatea celorlalte modele obiectuale propuse de literatura domeniului.
5.6.2.2 Corectitudinea modelrii versus normalitatea semantic

E.F.Codd a introdus modelul relaional al datelor pentru a elimina anomaliile de actualizare inerente modelelor anterioare. De atunci, preocuparea principal a cercettorilor n domeniu a fost aceea de a furniza proiectanilor de scheme de bd unelte conceptuale ct mai puternice cu putin pentru o modelare corect a datelor. Ne reamintim c, n MRD, formalizarea anomaliilor de actualizare face apel la conceptul de compatibilitate (semantic) ntre instanele relaiilor i tuplii acestora: un tuplu se zice compatibil cu o relaie dac el nu violeaz constrngerile primitive (i.e. de domeniu sau dependene cheie) asociate schemei relaionale n cauz. Majoritatea modelelor semantice ale datelor definesc i ele cel puin o form normal de tip FNDC. Ceea ce difer n acest caz este doar accepiunea asupra constrngerilor primitive i a compatibilitii, aa cum se poate observa, de exemplu, n seciunea 5.7, unde forma semantic normal (FSN) a MMED presupune o clas de constrngeri primitive mult mai larg dect n MRD, iar compatibilitatea semantic se refer la instanele tipurilor de obiecte i obiectele acestora (n loc de relaii i tupli). Indiferent de modelul datelor considerat, acest tip de abordare are urmtorul neajuns evident: de dragul pstrrii simplitii modelului, dar mai ales pentru a evita probleme de coeren, de complexitate exponenial a calculului i de nedecidabilitate, clasele de constrngeri primitive considerate sunt ct se poate de srace, acoperind doar majoritatea tipurilor de restricii frecvent ntlnite n modelarea datelor; pe de alt parte ns, aa cum vom dovedi n seciunea a treia a articolului, formele normale bazate pe aceste constrngeri primitive nu permit o modelare corect nici mcar n cazuri relativ simple i foarte des ntlnite n practic.
5.6.2.2.1 Constrngeri obiect obligatorii Desigur c majoritatea modelelor, printre care i MRD i MMED, ca i implementrile acestora admit pe lng constrngerile primitive i predicate ale unei subclase a logicii de ordinul nti (i.e. constrngerile obiect n MMED, respectiv tuplu n MRD). Acestea nu au fost ns niciodat studiate formal din cel puin dou motive: nti, pentru c sunt n general considerate (din pcate!) ca fiind foarte simple i deci aproape lipsite de proprieti de adncime (vezi, de exemplu, [1]; singurul argument ns n sprijinul acestei afirmaii superficiale ar putea fi acela c, ntr-adevr, exemplul tipic favorit n literatur pentru expedierea acestui tip de constrngeri este celebra restricie banal salariul nici unui angajat nu l poate depi pe cel al efului su direct!) n al doilea rnd ns pentru c, de fapt, aceste constrngeri sunt mult prea generale, prea complicate i pot conduce la scheme incoerente sau chiar la nedecidabilitate. 75 Dac un tip de constrngeri nu are o frecven suficient de mare de apariie sau dac frecvena sa este mare dar problema implicaiei corespunztoare nu este rezolvabil ori nu e nc rezolvat exist, evident, doar dou alternative de modelare: includem n model constrngerea obiect aferent, sacrificnd normalitatea schemei n favoarea
75 Chiar banalul principiu de rezoluie Robinson, dei solid i complet pentru predicatele de ordin nti, este decidabil doar pentru clauze Horn; pentru formule oarecare, dac clauza de demonstrat nu este o consecin logic, procesul de demonstraie poate continua la infinit 133

corectitudinii modelrii sau, dimpotriv, o ignorm - sacrificnd astfel corectitudinea pe altarul normalizrii. Sunt probabil cazuri n care posibilitatea apariiei unor anomalii minore de actualizare (i deci a unor instane de bd consistente doar sintactic, n raport cu modelul datelor utilizat, dar inconsistente semantic, n raport cu subuniversul modelat) este preferabil costurilor implicate de impunerea constrngerilor obiect aferente. n general ns, considerm c trebuie aleas prima soluie, deoarece criteriul primordial de evaluare al oricrei modelri a datelor nu trebuie s fie normalitatea schemelor (i.e. unul din mijloace), ci corectitudinea modelrii (i.e. scopul principal). Sperm c exemplele furnizate n subseciunea urmtoare sunt suficient de convingtoare n acest sens.
5.6.2.2.2 Exemple Prezentm n aceast seciune dou exemple de modelare n MMED, ambele n acelai timp simple (dar nu triviale sau evidente) i frecvent ntlnite n realitate, care necesit constrngeri obiect pentru o modelare corect a aspectelor lor eseniale.
5.6.2.2.2.1 mprumuturi dintr-o bibliotec public

Fie o bd pentru gestionarea mprumuturilor (de exemplare de cri, CD-uri, casete video, audio etc.) ctre abonai. Intereseaz evident data mprumuturilor de exemplare ctre abonai, precum i cea a retururilor de ctre acetia a exemplarelor mprumutate, att cea prevzut teoretic la momentul mprumutului, ct i cea efectiv. Presupunem, pentru simplitate, c despre exemplare intereseaz doar un numr de inventar, tipul i titlul lor, iar despre abonaii bibliotecii doar numele i prenumele. n plus, acceptm convenia conform creia att timp ct un exemplar mprumutat nu a fost nc returnat, data returului efectiv pentru el este null (nul, neprecizat). Figura 3.1 prezint schema acestei bd n MMED, n timp ce figura 3.2 pe cea n MRD echivalent, mpreun cu un posibil coninut valid al ei (cheile fiecrei tabele sunt indicate n paranteza de dup numele tabelei). Se observ c schema tipului de asociaii MPRUMUTURI are cheia structural {EXEMPLARE, DATAMPRUMUT}, deoarece nici un exemplar nu poate fi simultan mprumutat la mai mult de un abonat. Asociaia este evident ternar i nu binar (peste ABONAI i EXEMPLARE), deoarece un abonat poate s remprumute un acelai exemplar la o alt dat. Din aceast cauz a fost necesar abstractizarea tipului de entiti vectorial DATA_MPRUMUT (care nu e nevoie s fie memorat i separat n MRD). Desigur c se impun trei constrngeri obiect evidente, care pot fi implementate banal n majoritatea SGBD 76 i anume C1, C2 i C3. Primele dou formalizeaz restriciile ce afirm c nici un exemplar nu poate fi returnat sau programat pentru returnare de ctre un abonat nainte de a fi mprumutat de acel abonat. Dei este puin mai complicat sintactic, C3 formalizeaz o restricie la fel de simpl, dar esenial pentru corectitudinea modelului: nici un exemplar nu poate fi simultan mprumutat la mai muli abonai. De notat c, dac SGBD la dispoziie dispune de o cea mai mare dat calendaristic cu putin sau dac interpretarea valorilor nule s-ar face de aceast manier (adic valoarea nul s fie considerat mai mare dect orice alt valoare), C3 s-ar putea simplifica semnificativ; majoritatea SGBD curente ns nu dispun de vreo cea mai mare valoare i nici nu accept comparaii cu valori nule. Este adevrat c primele dou constrngeri ar putea fi relativ uor impuse i manual, de utilizatorul bd, ntru-ct implic doar date de pe o aceeai linie a tabelei; ultima ns, care presupune verificarea tuturor liniilor care se refer la acelai exemplar cu cel specificat de linia curent, nu ar trebui n nici un caz lsat n grija operatorului uman.
De exemplu, n Access 2002, primele dou cu ajutorul aa numitelor reguli de validare de nivel tabel, iar ultima printr-o procedur VBA asociat evenimentului BeforeInsert. 134
76

Cum aceste constrngeri nu sunt primitive i nici implicate de acestea, schema de mai sus nu este n forma semantic normal. Evident ns c n absena lor, orice greeal de introducere a secvenei datelor calendaristice conduce la coninuturi invalide inacceptabile.
EXEMPLARE ABONAI #Exemplar NAT(4) #Abonat NAT(3) NrInventar CHAR(16), total Prenume CHAR(16), total Nume CHAR(16), total TITLURI #Titlu NAT(2) DenTitlu CHAR(32), total TIPURI #Tip NAT(2) DenTip CHAR(16), total DATA_MPRUMUT #Data DATE

Titlu : EXEMPLARE TITLURI, total Tip : TITLURI TIPURI MPRUMUTURI=(EXEMPLARE, ABONAI, DATA_MPRUMUT;{EXEMPLARE,DATA_MPRUMUT}) #mprumut NAT(8) DataRetProg DATE, total DataRetEfectiv DATE, total C0: cheie PrenumeNume C1: (xmprumuturi)(x[Datamprumut] x[DataRetProg]) C2: (xmprumuturi)(x[Datamprumut] x[DataRetEfectiv]) C3: (x,ymprumuturi)((x[Exemplare] = y[Exemplare]) ((y[DataRetEfectiv] = null x[DataRetEfectiv] null y[Datamprumut] x[DataRetEfectiv]) (x[DataRetEfectiv] = null y[DataRetEfectiv] null x[Datamprumut] y[DataRetEfectiv]) (x[DataRetEfectiv] null y[DataRetEfectiv] null (x[Datamprumut] y[DataRetEfectiv] y[Datamprumut] x[DataRetEfectiv]))) Fig. 5.13 Schema MMED pentru bd mprumuturi dintr-o bibliotec

5.6.2.2.2.2 Rezervarea biletelor de cltorie cu avionul

Fie urmtorul subunivers de interes (despre obiectele cruia sunt interesante doar proprietile din paranteze): companii aeriene, care posed avioane, propun rute aeriene, organizeaz zboruri pe aceste rute i emit bilete de cltorie cu avionul (cod, prescurtare, denumire, localitate) avioane (cod, numr, tip, proprietar) tipuri avioane (cod, prescurtare, denumire) locuri n tipurile de avioane (cod, numr, clasa) clase de cltorie (cod, prescurtare, denumire) aeroporturi (cod, denumire, localitate) rute aeriene (cod, indicativ, companie) configuraii rute (ruta aerian, aeroport, poziie aeroport n rut, moment aterizare relativ la momentul decolrii de pe aeroportul iniial al rutei, durata escalei pe aeroport); nu sunt admise rute n care un aeroport s figureze de mai multe ori (i.e. nici un zbor nu reviziteaz vreun aeroport) zboruri (cod, ruta, avion, momentul decolrii de pe aeroportul iniial) pasageri (cod, paaport, prenume, nume, localitate de domiciliu) bilete (cod, numr, data emiterii, emitent, zbor, pasager, loc, pre, aeroport mbarcare, aeroport destinaie) localiti (cod, denumire, fus orar).
135

Exemplare (#Exemplar, NrInventar) Titlu #Titlu, NrInventar, Titlu Titlu #Exemplar NrInventar 1 19930712001 2 2 19930712002 2 3 19850215030 4 4 19950815047 1 5 19970114102 3 Abonai (#Abonat, PrenumeNume) Prenume, Nume Nume #Abonat Prenume 1 Ion Vcrescu 2 Ruxandra Popescu 3 Daniel Ionescu

Titluri (#Titlu, DenTitlu) Tip #Tip, DenTitlu Tip DenTitlu #Titlu 1 4 Supa de varz 2 1 Loviluie i deform 3 3 Parfum de femeie 4 2 Oratoriul de Crciun 5 4 Amadeus 6 2 Variaiunile Goldberg Tipuri (#Tip, DenTip) DenTip #Tip DenTip 1 Carte 2 CD 3 Caset video 4 DVD

mprumuturi (#mprumut, ExemplareDatamprumut) Exemplare #Exemplar, Abonai #Abonat, Exemplare, Abonai, Datamprumut, DataRetProg Exemplare Abonai Datamprumut DataRetProg DataRetEfectiv #mprumut 1 1 1 12.07.1997 12.10.1997 24.12.1999 2 2 1 12.07.1997 12.10.1997 3 4 2 12.07.1997 10.08.1997 04.08.1997 4 1 1 24.12.1999 01.02.2000 5 5 3 24.12.1999 05.01.2000 15.01.2000 6 3 3 24.12.1999 05.01.2000 08.01.2000 7 5 2 15.01.2000 22.01.2000 Fig. 5.14 Schema MRD pentru bd mprumuturi dintr-o bibliotec i un posibil coninut valid

Pentru simplitate, se presupun urmtoarele: configuraia rutelor aeriene este corect memorat (ca ordine a aeroporturilor iniial, destinaie i escale intermediare) i nu se mai modific, iar un zbor al unei companii nu se face neaprat doar cu avioane proprietatea acelei companii. Schema MMED a unei bd corespunztoare pentru rezervarea de locuri (emiterea de bilete de cltorie) este prezentat n figura 5.15. Rezultatul traducerii ei n MRD, mpreun cu un posibil coninut valid al acestuia sunt prezentate n figura 5.16. De notat cheile structurale ale celor dou tipuri de asociaii, ConfigRute i Zboruri. Deoarece se cere ca rutele s nu nchid bucle, rezult c un aeroport figureaz n cel mult o poziie a oricrei rute, deci {Rute,Aeroporturi} este cheie n ConfigRute; cum pe orice rut, n orice poziie, exist un unic aeroport i {Rute,Poziii} este cheie. Similar, n Zboruri, {Rute,DataPlec} este cheie deoarece orice rut este deservit la un moment dat de un singur avion; cum un avion nu poate zbura la un moment dat dect pe o unic rut, rezult c i {Avioane,DataPlec} este cheie.

136

Companii #Comp NAT(3) PrescComp CHAR(8), total DenComp CHAR(32), total Localiti #Loc NAT(4) DenLoc CHAR(32), total FusOrar NAT(2), total Avioane #Avion NAT(3) NrAvion CHAR(16), total TipuriAvioane #Tip NAT(2) PrescTip CHAR(4), total DenTip CHAR(16), total

Locuri #Locuri NAT(6) NrLoc NAT(3), total ClaseCltorie #Clasa NAT(9) PrescClasa CHAR(1), total DenClasa CHAR(8), total Aeroporturi #Aerop NAT(4) DenAerop CHAR(32), total Rute #Ruta NAT(6) Indicativ CHAR(8), total

Poziii #Poz NAT(2) DataPlec #Data DATE Pasageri #Pasager NAT(8) Paaport CHAR(16), total Prenume CHAR(16), total Nume CHAR(16), total Bilete #Bilet NAT(10) NrBilet CHAR(16), total DataEmit DATE, total Pre PRE(4), total

LocComp : Companii Localiti Proprietar : Avioane Companii ClasifAvion : Avioane TipuriAvioane, total ClasifLoc : Locuri ClaseCltorie, total CompAvion : Locuri TipuriAvioane, total Companie : Rute Companii, total LocAerop : Aeroporturi Localiti, total

LocDomicil : Pasageri Localiti Emitent : Bilete Companii, total Loc : Bilete Locuri, total Zbor : Bilete Zboruri, total Pasager : Bilete Pasageri, total Aeromb : Bilete Aeroporturi, total AeroDest : Bilete Aeroporturi, total

ConfigRute (Rute, Poziii, Aeroporturi; {Rute, Poziii}, {Rute, Aeroporturi}) #CR NAT(8) MomentAteriz TIMP, total DurataEscala TIMP, total Zboruri (Rute, Avioane, DataPlec; {Rute, DataPlec}, {Avioane, DataPlec}) #Zbor NAT(10) C0: cheie PaaportLocDomicil, ProprietarNrAvion, NrLocCompAvion, NrBiletEmitentDataEmit, ZborLocAeromb, ZborLocAeroDest C1: ClasifAvion prAvioane(Zboruri) Zbor = CompAvion Loc C2: (bBilete)(zZboruri)(x,yConfigRute)(Zbor(b) = z z[Rute] = y[Rute] = x[Rute]) ((Aeromb(b) = x[Aeroport] AeroDest(b) = y[Aeroport] x[Poziii] < y[Poziii]) (Aeromb(b) = y[Aeroport] AeroDest(b) = x[Aeroport] y[Poziii] < x[Poziii])) C3: (lLocuri) (b,cBilete) (zZboruri)((u,v,x,yConfigRute) (Loc(b) = Loc(c) = l Zbor(b) = Zbor(c) = z z[Rute] = u[Rute] = v[Rute] = x[Rute] = y[Rute] Aeromb(b) = x[Aeroport] AeroDest(b) = y[Aeroport] Aeromb(c) = u[Aeroport] AeroDest(c) = v[Aeroport]) (x[Poziii] v[Poziii] u[Poziii] y[Poziii]) Fig. 5.15 Schema MMED pentru bd Rezervri bilete avion

137

Bilete (#Bilet, NrBiletEmitentDataEmit, ZborLocAeromb, ZborLocAeroDest) Emitent #Comp, Loc #Locuri, Zbor #Zbor, Pasager #Pasager, Aeromb #Aerop, AeroDest #Aerop, NrBilet, DataEmit, Pre, Emitent, Loc, Zbor, Pasager, Aeromb, AeroDest NrBilet DataEmit Pre Emitent Loc Zbor Pasager Aeromb AeroDest #Bilet 1 TAROM197 27.12.1999 300 3 1 1 2 1 3 2 TAROM225 12.12.1999 200 3 1 1 1 3 6 3 SA1012008 03.01.2000 200 1 6 5 3 3 7 4 SA1009975 29.12.1999 200 1 6 5 4 7 8 Companii (#Comp, PrescComp, DenComp) LocComp #Loc, PrescComp, DenComp DenComp LocComp #Comp PrescComp 1 CHSA Swiss Air 1 2 ROTAROM TAROM S.A. 2 3 ROITA Ion iriac Air srl 2 4 FAF Air France 3 Avioane (#Avion, ProprietarNrAvion) Proprietar #Comp, ClasifAvion #Tip, NrAvion, ClasifAvion Proprietar ClasifAvion #Avion NrAvion 1 BAC01 2 1 2 B727-0 2 2 3 B727-1 1 2 4 A300-2 1 3 5 B727-0 4 2 6 A300-077 4 3 Locuri (#Locuri, NrLocCompAvion) ClasifLoc #Clasa, CompAvion #Tip, NrLoc, ClasifLoc, CompAvion NrLoc ClasifLoc CompAvion #Locuri 1 1 3 3 2 21 2 3 3 101 1 3 4 1 3 2 5 31 2 2 6 191 1 2 Zboruri (#Zbor, RuteDataPlec, AvioaneDataPlec) Rute #Ruta, Avioane #Avion, Rute, Avioane, DataPlec #Zbor Rute Avioane DataPlec 1 1 3 03.01.2000 09:00 2 1 2 10.01.2000 09:00 3 2 3 03.01.2000 12:00 4 2 2 10.01.2000 12:00 5 3 5 03.01.2000 06:00 6 4 5 04.01.2000 12:00 Localiti (#Loc, DenLoc) DenLoc, FusOrar FusOrar #Loc DenLoc 1 Zurich 1 2 Bucureti 2 3 Paris 1 4 Londra 0 5 NewYork -5 6 Munchen 1 7 Los Angeles -11 Rute (#Ruta, Indicativ) Companie #Comp, Indicativ, Companie Companie #Ruta Indicativ 1 RO101 2 2 RO102 2 3 CH100 1 4 CH101 1 TipuriAvioane (#Tip, PrescTip, DenTip) PrescTip, DenTip #Tip PrescTip DenTip 1 RBAC RomBac 1-11 2 B727 Boeing 727 3 A300 AirBus 300 ClaseCltorie (#Clasa, PrescClasa, DenClasa) PrescClasa, DenClasa #Clasa PrescClasa DenClasa 1 E Economy 2 B Business 3 L Luxus Aeroporturi (#Aerop, DenAerop) LocAerop #Loc, DenAerop, LocAerop LocAerop #Aerop DenAerop 1 Otopeni 2 2 Bneasa 2 3 Zurich 1 4 Charles de Gaulle 3 5 Orly 3 6 Gatewick 4 7 JFK 5 8 Malibu 7

138

ConfigRute (#CR, RutePoziii, RuteAeroporturi) Rute #Ruta, Aeroporturi #Aerop, Rute, Poziii, Aeroporturi, MomentAteriz, DurataEscala Poziii Aeroporturi MomentAteriz DurataEscala #CR Rute 1 1 1 1 0 0 2 1 2 3 120 30 3 1 3 6 210 90 4 2 1 6 0 0 5 2 2 4 60 60 6 2 3 1 300 0 7 3 1 8 0 0 8 3 2 7 480 30 9 3 3 6 870 30 10 3 4 3 960 120 11 4 1 3 0 0 12 4 2 4 60 30 13 4 3 7 450 30 14 4 4 8 960 120 Pasageri (#Pasager, PaaportLocDomicil) LocDomicil #Loc, Paaport, Prenume, Nume Prenume Nume LocDomicil #Pasager Paaport 1 US-0512008 Valer John 5 2 RSR-690101001 Bob Punescu 2 3 CH-1234567 Francois Muller 6 4 US-131313 Bab Madonna 7 Fig. 5.16 Schema MRD pentru bd Rezervri bilete avion i un posibil coninut valid al ei ClasifAvion TipuriAvioane CompAvion Locuri Loc Fig. 5.17 Diagrama comutativ de funcii care conduce la constrngerea C1 Zbor Bilete Zboruri Aeromb ConfigRute AeroDest Rute Avioane prAvioane(Zboruri) Zboruri Zbor Bilete

Aeroporturi

Fig. 5.18 Subdiagramele entiti-asociaii implicate n constrngerea C2

139

Constrngerea C1 se impune n urma analizei diagramei entiti-asociaii a schemei, dac se observ c exist subdiagrama din figura 5.17, care trebuie s comute (deoarece zborul pentru care se emite orice bilet trebuie fcut cu un avion de acelai tip cu cel pentru care s-a rezervat loc cu acel bilet). Similar, trebuie nchise i subdiagramele de funcii i relaii din figura 5.18 (deoarece, pentru orice bilet, aeroporturile de mbarcare i destinaie trebuie s aparin rutei pe care se efectueaz zborul pentru care s-a emis biletul, iar poziia n rut a aeroportului de mbarcare trebuie s fie mai mic dect cea a celui de destinaie), adic exact ceea ce formalizeaz constrngerea obiect C2. n sfrit, C3 formalizeaz constrngerea cheie de bolt a acestei scheme: nici un loc nu poate fi ocupat simultan de mai mult de un pasager. Se observ c, deoarece diagrama la care se refer C3 o include pe cea din figura 5.18, aceast ultim constrngere obiect ar putea fi lesne extins pentru a ngloba C2, lucru preferabil ntotdeauna ntr-o implementare (cci se economisete timp SGBD i deci utilizator!); preferm ns aceast soluie din motive didactice, de claritate a expunerii. Evident c toate aceste trei constrngeri explicite ar fi aproape imposibil de impus manual, de utilizatorul bd, ntruct ele implic foarte multe linii din multe tabele; prima dintre ele, fiind primitiv n MMED, nu afecteaz normalitatea semantic a schemei. Ultimele dou ns nefiind primitive i nici implicate de acestea, schema din figura 5.15 nu este n forma semantic normal. Dar desigur c n absena lor, orice greeal de introducere a datelor conduce la coninuturi invalide inacceptabile.
5.6.2.2.3 Concluzii n esen, acest articol se dorete o pledoarie contra fetiizrii formelor normale i pentru primatul absolut al corectitudinii modelrii, chiar i atunci cnd se folosesc modele i forme semantice normale, de nivel nalt, evideniind necesitatea recursului la constrngerile obiect ori de cte ori restul tipurilor de constrngeri nu poate formaliza corect toate restriciile domeniilor de interes modelate. n asemenea cazuri, de fapt, dac formalizarea constrngerilor obiect este corect i semantic (n raport cu domeniul modelat) schemele astfel rezultate sunt ntr-o form normal mai nalt dect cea mai nalt dintre cele oferite de modelul respectiv; iar dac i implementarea constrngerilor obiect (cu ajutorul facilitilor oferite de SGBD la dispoziie) este corect, singurul eventual neajuns l-ar putea constitui scderea vitezei de procesare a actualizrilor de ctre bd respectiv (incoerena i nedecidabilitatea putnd fi evident surmontate n orice caz particular n care domeniul de modelat e coerent i decidabil!). De remarcat c, n ciuda aparenelor, cele dou probleme analizate n seciunea anterioar sunt n fond similare i c multe alte subuniversuri de interes din jurul nostru sunt i ele de acelai tip. Amintim aici doar cteva dintre ele: o bibliotec personal; agenii de voiaj auto, CFR sau de navigaie fluvial/maritim; companii de taximetre; cabinete de servicii medicale, juridice, cosmetice etc.; hoteluri, sli de spectacole (muzicale, teatru, cinema etc.) etc. Toate acestea i multe altele au nevoie pentru o modelare corect de constrngeri obiect, dintre care una le este comun: disjuncia intervalelor de timp n care sunt ocupate resurse partajabile succesiv, dar nu simultan. Evident c toate tipurile de constrngeri introduse n literatur pot fi formalizate cu ajutorul constrngerilor obiect. Trecerea unora dintre ele n clasa celor primitive se face atunci cnd sunt ndeplinite simultan urmtoarele dou condiii: frecvena de apariie a lor n modelare este mare, iar problema implicaiei pentru ele (mpreun cu celelalte tipuri de constrngeri primitive) este decidabil (i, de preferin, de complexitate cel mult polinomial). Evoluia modelrii datelor este, din acest punct de vedere, formalizabil cu ajutorul urmtorului algoritm:

140

Repet ct timp exemplele de modelare mai scot n eviden restricii formalizabile doar ca i constrngeri obiect Dac noul tip de constrngeri ntlnit apare suficient de frecvent Atunci Dac se rezolv problema implicaiei pentru acest tip n modelele datelor existente Atunci adaug noul tip la clasa constrngerilor primitive Altfel Dac problema implicaiei se poate rezolva doar ntr-un alt cadru formal de modelare Atunci creeaz un nou model al datelor n care noul tip de constrngeri este primitiv

De exemplu, i pentru c n MRD comutativitile de diagrame de funcii, sistemele de reprezentani, aciclicitile grafurilor etc. nu pot fi formalizate altfel dect prin constrngeri obiect, am introdus MMED, n care ele pot fi considerate primitive! (Celelalte motive principale ale acestui demers sunt legate de convingerea ferm c n modelarea conceptual a datelor: funciile structurale sunt preferabile dependenelor funcionale, care sunt utile doar n teoria cheilor structurale ale tipurilor de asociaii; iar tipurile de asociaii sunt net preferabile dependenelor multivaluate i join). Este evident faptul c ne e ndeobte mult mai la ndemn s mbogim clasa tipurilor de constrngeri primitive cu predicate consacrate de mult n matematic (precum comutativiti de diagrame de funcii, sisteme de reprezentani etc.), pentru care exist rezultate de adncime i abrevieri sintactice binecunoscute. Ca atare, considerm c provocarea major n aceast direcie o constituie mai degrab extragerea din acest uria rezervor de predicate de ordin nti a noi tipuri de constrngeri primitive pentru care nu exist nc conceptualizri consacrate. De exemplu, pornind de la tipul de constrngeri semnalat n aceast seciune, considerm c un domeniu extrem de promitor i fecund n aceast direcie l-ar constitui ncercarea de formalizare matematic a modelrii unora dintre aspectele dinamice, tranzacionale, deci temporale ale datelor.
5.7 Traducerea schemelor MMED n MRD i MEA

5.7.1 Traducerea n MRD

Fundamentat de subseciunile 5.3.5, 5.4.2, 5.5.2 i 5.6.1, algoritmul 5.72 de translaie a schemelor de bd din MMED n model relaional prezentat n continuare genereaz scheme relaionale nalt normalizate. Din punct de vedere sintactic, pe baza corolarului 5.3.b), subseciunilor 5.3.5 i 5.4.2, observaiilor 5.9, 5.14.c), 5.36 i teoremei 5.35 se poate uor demonstra urmtoarea teorem (vezi problema ?): Teorema 5.73 a) (normalitatea schemelor de bd traduse din MMED n model relaional) Schemele de bd relaionale generate de algoritmul 5.72 din scheme MMED n FSN sunt n FNDC. b) (proprietile aplicaiei de traducerea schemelor MMED n MRD) Aplicaia stabilit de traducerea schemelor MMED n modelul relaional prin algoritmul 5.72 este surjectiv, dar neinjectiv.
141

Algoritmul 5.72 (traducerea schemelor de bd din MMED n MRD) Intrri: o schem de bd n MMED; Ieiri: schema echivalent n MRD. Program abstract: Repet pentru fiecare dintre mulimile de entiti ale schemei genereaz o schem de relaie coninnd toate atributele definite pe mulimea de entiti curent; dac nu exist explicit, genereaz cheia surogat a tipului (injectiv; cardinalul codomeniului ei este egal cu cel specificat de proiectantul schemei MMED pentru mulimea de entiti curent) din identificatorul de obiect aferent; repet pentru fiecare dintre aceste atribute n parte adaug o constrngere de domeniu corespunztoare (domeniul atributului relaional = codomeniul atributului MMED corespunztor) Sfrepet; // generare relaii corespunztoare tipurilor de entiti Repet pentru fiecare dintre mulimile de asociaii ale schemei genereaz o schem de relaie coninnd toate atributele definite pe mulimea de asociaii curent; dac nu exist explicit, genereaz cheia surogat a tipului (injectiv; cardinalul codomeniului ei este egal cu cel specificat de proiectantul schemei MMED pentru mulimea de entiti curent) din identificatorul de obiect aferent; genereaz suportul grafului asociaiei (extinznd canonic identificatorii de obiect ai tuturor suporilor asociaiei curente); repet pentru fiecare dintre aceste atribute n parte adaug o constrngere de domeniu corespunztoare (domeniul atributului relaional = codomeniul atributului MMED corespunztor) dac asociaia nu are chei structurale explicite atunci genereaz o cheie structural cu toate atributele formnd suportul grafului asociaiei; (altfel) sfdac; Sfrepet; // generare relaii corespunztoare tipurilor de asociaii Repet pentru fiecare dintre funciile structurale : A B ale schemei adaug la schema relaiei corespunztoare mulimii de obiecte A un atribut avnd numele funciei ; adaug o constrngere de domeniu de tip: dom() = dom(#B), unde #B este cheia surogat a B (dom() este domeniul relaional al atributului ); adaug o dependen de incluziune de tip RA() RB(#B), unde RA i RB sunt schemele de relaie generate pentru mulimile de obiecte A, respectiv B; Sfrepet; // propagarea cheilor Repet pentru toate funciile injective j din schema MMED (fie ele simple sau produse de atribute sau funcii structurale) dac j este identificator de obiect, declar cheia surogat corespunztoare drept cheie primar a tabelei sale altfel adaug tabelei corespunztoare dom(j) constrngerea cheie(j); Sfrepet; Repet pentru toate celelalte constrngeri de integritate explicite ce exist i n MRD tradu fiecare tip de constrngere conform implementrii MMED (de exemplu, absolut toate n constrngeri tuplu); Sfrepet; Sfrit algoritm 5.72
Fig. 5.72 Algoritmul de traducere a schemelor MMED n MRD 142

5.7.2 Traducerea n MEA

Traducerea schemelor MMED n DEA se poate face foarte uor, conform algoritmului cerut de problema 5.33.
5.8 Traducerea schemelor MRD i MEA n MMED

Traducerea schemelor relaionale i a DEA n MMED se poate face foarte uor, conform algoritmilor cerui de problemele 5.34, respectiv 5.35.
5.9 Un exemplu relaional celebru modelat n MMED

Figura 5.19 prezint schema bd din exemplul 5.10 exprimat n MMED (precizare notaional: tot ce urmeaz dup ;, pn la sfritul liniei, constituie comentarii, ignorate de MMED, dar memorate ca i descrieri ataate conceptului comentat). De remarcat cel puin dou lucruri n legtur cu modelarea n MMED a acestui celebru exemplu de proiectare a bd: relaional, acest exemplu nu are nici o soluie corect (nu doar folosind exclusiv FD, cum l prezint Ullman, ci nici chiar fcnd apel la DMV i DJ); n MMED, soluia nu este doar corect, ci i extrem de natural i elegant. Spaiul restrns al acestei lucrri ne mpiedic, din pcate, s prezentm contrastiv (i nu doar n raport cu MRD, ci i cu alte modele semantice ale datelor) multe alte posibile exemple de acest tip. Sperm ns c acest exemplu n MMED este edificator asupra puterii sale de modelare deosebite. Figurile 5.20 i 5.21 prezint schema relaional corespunztoare obinut din bd conceptual din figura 5.19 n urma aplicrii algoritmului 5.72, precum i un posibil coninut parial al acesteia. Observaii notaionale necesare nelegerii schemei din figura 5.21: len este funcia ce calculeaz lungimea unui ir de caractere, iar maxnat este valoarea maxim admis pentru un natural ntr-o implementare oarecare (de notat c algoritmul calculeaz corect cardinalul maxim al tipului de asociaii CODIF_POTA ca fiind produsul cardinalelor maxime ale suporilor CODURI_POTA, LOCALITI i ADRESE; cum, astfel, codomeniul #Codif_Pota rezult a fi NAT(120), o valoare mult prea mare pentru orice implementare, este folosit maxnat n loc).

143

Tipuri de obiecte (inclusiv constrngerile primitive aferente)

Entiti i atributele lor
JUDEE #Jud NAT(2) Den_Jud CHAR(32) Auto CHAR(2) Prefix_Tel NAT(2) LOCALITI #Loc NAT(4) Den_Loc CHAR(32) CODURI_POSTA #Cod NAT(5) Cod_Potal NAT(5) ADRESE #Adr NAT(6) Adresa CHAR(64) Descr_imobil CHAR(16) CAREURI #Careu NAT(8) Pagina NAT(3) X-careu CHAR(1) Y-careu NAT(1) ; mulimea judeelor Romniei ; identificatorul de obiecte ; denumire jude ; codul automobilistic al judeului (injectiv!) ; prefixul telefonic al judeului (injectiv!) ; mulimea localitilor de interes ; identificatorul de obiecte ; denumire localitate ; mulimea codurilor potale ; identificatorul de obiecte ; codul potal propriu-zis (injectiv!) ; mulimea adreselor (strada i numrul) de ; interes din toate localitile ; identificatorul de obiecte ; strada i numrul ; descrierea imobilului de la adresa curent ; mulimea careurilor n care sunt ; mprite hrile localitilor ; identificatorul de obiecte ; nr. paginii din ghidul cu hri de ; localiti n care se afl careul ; coordonata X a careului n pagin ; coordonata Y a careului n pagin

Asociaii, cheile structurale i atributele lor

CODIF_POSTA = ; asocierea codurilor potale la localiti i adrese = (CODURI_POSTA, LOCALITATI, ADRESE ; k1=LOCALITATI, ADRESE, k2=CODURI_POSTA, LOCALITATI)

Funcii structurale (inclusiv constrngerile primitive aferente)

Apart_Jud : LOCALITATI JUDETE ; precizeaz apartenena localitilor la judee Capitala_Jud : JUDEE LOCALITI ; precizeaz reedinele de jude (injectiv!) Localiz_Adresa : ADRESE LOCALITI ; precizeaz localitatea fiecrei adrese Careu : ADRESE CAREURI ; precizeaz careul n care se afl fiecare adres surj Loc_Codif : CODURI_POTA LOCALITI ; precizeaz localitatea ; corespunztoare fiecrui cod potal n parte

Constrngeri primitive de integritate suplimentare

Apart_Jud Capitala_Jud = 1JUDETE ; reedina judeului aparine judeului respectiv Loc_Codif k1 = prLOCALITATI CODIF_POSTA ; vezi 5.6.4 Localiz_Adresa k2 = prLOCALITATI CODIF_POSTA ; vezi 5.6.4

Fig. 5.21 Un exemplu relaional celebru modelat n MMED

144

JUDEE
#Jud 1 2 3 4 Den_Jud Mun. Bucureti Sibiu Iai Maramure Auto B SB IS MM #Loc 1 2 3 4 5 6 7 8 Prefix_tel 1 69 32 62 Capitala_Jud 1 3 7 5 Den_Loc Mun. Bucureti Constana Sibiu Cluj Baia-Mare Suceava Iai Bora Apart_Jud 1 32 2 5 4 9 3 4

CAREURI
#Careu 1 2 3 4 5 6 7 8 Pagina 1 1 1 1 2 2 2 2 ADRESE #Adr 1 2 3 4 5 6 X-careu A A B B A A B B Y-careu 1 2 1 2 1 2 1 2

LOCALITI

Adresa Cal.Victoriei 1 Cal.Victoriei 3 Baba Novac 1 Copou 12 os.Alba-Iulia 2 os.Alba-Iulia 2

Descr_imobil bv bv bn vv cc bn

Localiz_Adresa 1 1 1 7 3 4

Careu 1 1 7 865 412 231

CODIF_POTA
#Codif _Pota 1 2 3 4 5 6 Coduri_Pota 3 3 2 5 4 7 Localiti 1 1 1 7 3 4 Adrese 1 2 3 4 5 6

CODURI_POTA
#Cod 1 2 3 4 5 6 7 8 9 Cod_Potal 8700 71123 72413 2400 6600 5800 3400 4880 4800 Loc_Codif 2 1 1 3 7 6 4 8 5

Fig. 5.22 Schema relaional corespunztoare bd din figura 5.21 i un posibil coninut (parial) al ei

145

Constrngeri primitive (n accepiunea relaional)

Constrngeri de domeniu
codom(#Jud) = xNATx < 100 codom(Den_Jud) = x CHARlen(x) 32 codom(Auto) = x NATx < 100 codom(Prefix_Tel) = x NATx < 100 codom(Capitala_Jud) = x NATx < 10000 codom(#Loc) = x NATx < 10000 codom(Den_Loc) = x CHARlen(x) 32 codom(Apart_Jud) = x NATx < 100 codom(#Cod) = x NATx < 100000 codom(Cod_Potal) = x NATx < 100000 codom(Loc_Codif) = x NATx < 10000 codom(#Adr) = x NATx < 1000000 codom(Adresa) = xCHARlen(x) 64 codom(Descr_imobil) = x CHARlen(x) 16 codom(Localiz_Adresa) = x NATx < 10000 codom(Careu) = x NATx < 100000000 codom(#Careu) = x NATx < 100000000 codom(Pagina) = x NATx < 1000 codom(X-careu) = x CHARlen(x) 1 codom(Y-careu) = x NATx < 10 codom(#Codif_Pota) = x NATx < maxnat codom(Coduri_Pota) = x NATx < 100000 codom(Localiti) = x NATx < 10000 codom(Adrese) = x NATx < 1000000

Constrngeri cheie
cheie(#Jud) cheie(Auto) cheie(Prefix_Tel) cheie(Capitala_Jud) cheie(#Loc) cheie(#Cod) cheie(Cod_Potal) cheie(#Adr) cheie(#Careu) cheie(#Codif_Pota) cheie(LocalitiAdrese) cheie(Coduri_PotaLocaliti)

Dependene de incluziune
Im(Apart_Jud) Im(#Jud) Im(Capitala_Jud) Im(#Loc) Im(Localiz_Adresa) Im(#Loc) Im(Careu) Im(#Careu) Im(Loc_Codif) Im(#Loc) Im(Coduri_Pota) Im(#Cod) Im(Localiti) Im(#Loc) Im(Adrese) Im(#Adr)

Constrngeri tuplu suplimentare (primitive n MMED dar nu i n modelul relaional)

y Im(#Loc), x Im(#Cod), y = Loc_Codif(x) x Im(#Jud), x = Apart_Jud(Capitala_Jud(x)) ; surj Loc_Codif ; Apart_Jud Capitala_Jud = 1JUDETE ;Loc_Codif k1 = ;= prLOCALITATI CODIF_POSTA x Im(#Codif_Pota), Localiti(x) = Localiz_Adresa(Adrese(x)) ;Localiz_Adresa k2 = ;= prLOCALITATI CODIF_POSTA Fig. 5.23 Constrngerile de integritate corespunztoare bd din figura 5.21

x Im(#Codif_Pota), Localiti(x) = Loc_Codif(Coduri_Pota(x))

146

5.10

Problem dat la examen, rezolvri i punctaj

5.10.1 Enun

1. (7p) Fie submulimea metacatalogului unui SGBD relaional dotat cu SQL care memoreaz serverele de bd interconectate (id, denumire, calculatorul gazd), administratorii lor (administrator, server), bazele de date memorate de acestea (id, denumire, server, proprietar), fiierele propriu-zise n care se memoreaz bd (id, nume, extensie, dimensiune n Kilooctei, director memorare, bd memorat), directoarele (id, nume, nivel adncime, director tat, unitatea fizic de disc), unitile de discuri fizice (id, id. logic, capacitate n Gigaoctei, calculator), calculatoarele (id, denumire, utilizator curent) i utilizatorii (id, cont, parola). a. (0,5p) S se proiecteze DEA corespunztoare. b. (4p) S se proiecteze schema conceptual MMED corespunztoare. c. (1p) S se traduc schema de la punctul b. n bd relaional corespunztoare i s se prezinte un posibil coninut valid al ei (minim doi tupli per relaie) pentru care rspunsul la ntrebarea de la punctul d const n minim doi tupli. d. (1,5p) S se scrie instruciunea SQL pentru a calcula rspunsul la urmtoarea ntrebare: Care sunt utilizatorii (nume cont, numr servere, numr baze de date), n ordinea descresctoare a numrului de servere, apoi a celui de bd i, n sfrit, cresctoare a numelor de cont, care sunt proprietari a cel puin dou bd memorate pe servere ce au doar un singur administrator i anume unul dintre aceti proprietari? i s se calculeze rspunsul ei pentru coninutul de la punctul c.
Indicaii: - nu pot exista doi utilizatori avnd acelai nume de cont; idem pentru servere, pentru bd de pe un server, pentru fiierele dintr-un director, pentru subdirectoarele unui director, pentru identificatorii logici ai unitilor de discuri ale unui calculator, pentru calculatoare etc.; - un server e gzduit pe un singur calculator, o bd este memorat de un singur server (ns, posibil, n mai multe fiiere) i are un unic proprietar, un fiier memoreaz date ale unei singure bd, o unitate de disc este montat ntr-un unic calculator, un calculator poate avea, la orice moment dat, un singur utilizator curent etc.; - un administrator poate administra mai multe servere, iar un server poate fi administrat de mai muli administratori.

Observaii: timp de lucru: 3h se pot consulta orice surse documentare (curs, laborator, cri, PC, Internet etc.), dar este interzis colaborarea cu colegii.

Succes!

147

5.10.2 Rezolvare
5.10.2.1 Diagrama Entiti-Asociaii (DEA)
Cont Utilizatori Parola #U

Administratori Proprietar #A #C Gazda Servere #D Server BazeDate #BD BD BD Tata Director Fiiere Directoare Dimens. #S Server Disc Discuri Disc Calculatoare Calculator Calculator Utilizator

#F

Fiier

Extensie

Kocteti

#Dir

Director

Nivel

148

5.10.2.2

Schema conceptual n MMED

Schema conceptual corespunztoare n modelul matematic elementar al datelor (MMED) este urmtoarea (4p.):
Utilizatori #U NAT(4), total Cont CHAR(64), total Parola CHAR(16) Servere #S NAT(2) Server CHAR(32), total Calculatoare #C NAT(4) Calculator CHAR(64), total Utilizator : Calculatoare Utilizatori Gazda : Servere Calculatoare, total Discuri #D NAT(6) Disc CHAR(1), total GOcteti RAT(4) Calculator : Discuri Calculatoare, total

KBD: cheie ServerBD (pe orice server, numele bd gzduite sunt unice)
Fiiere #F NAT(8) Fiier CHAR(255), total Extensie CHAR(255) KOcteti RAT(8) BD : Fiiere BazeDate Directoare Fiiere Nivel NAT(4), total Director : Fiiere Directoare, total

FiierExtensie cheie? Nu, pentru c n directoare diferite pot exista fiiere cu aceleai nume i extensie. FiierKOcteti cheie? Nu, pentru c pot exista fiiere cu aceleai nume i dimensiune. FiierBD cheie? Nu, pentru c pot exista fiiere cu aceleai nume i memornd aceeai bd (dar cu extensii diferite sau cu aceeai extensie dar n directoare diferite). FiierDirector cheie? Nu, pentru c n acelai director pot exista mai multe fiiere cu aceleai nume (dar extensii diferite). ExtensieKOcteti cheie? Nu, pentru c pot exista fiiere cu aceleai extensie i dimensiune. ExtensieBD cheie? Nu, pentru c pot exista fiiere cu aceeai extensie i memornd aceeai bd (dar cu nume diferite sau cu acelai nume dar n directoare diferite). ExtensieDirector cheie? Nu, pentru c n acelai director pot exista mai multe fiiere cu aceeai extensie (dar nume diferite).

KDisc: cheie CalculatorDisc (pe orice calculator, numele discurilor sale sunt unice)
BazeDate #BD NAT(6) BD CHAR(64), total Proprietar : BazeDate Utilizatori, total Server : BazeDate Servere, total ProprietarBD cheie? Nu, pentru c orici utilizatori pot fi proprietari ai orictori bd cu acelai nume. ProprietarServer cheie? Nu, pentru c orici utilizatori pot fi proprietari ai orictori bd gzduite de un acelai server.

149

KOctetiBD cheie? Nu, pentru c pot exista fiiere cu aceeai dimensiune i memornd aceeai bd. KOctetiDirector cheie? Nu, pentru c n acelai director pot exista mai multe fiiere cu aceeai dimensiune.
BDDirector cheie? Nu, pentru c n acelai director pot exista mai multe fiiere memornd aceeai bd.

KOctetiBDDirector cheie? Nu, pentru c pot exista mai multe fiiere cu aceeai dimensiune n acelai director memornd aceeai bd. FiierExtensieKOctetiBD cheie? Nu, pentru c pot exista mai multe fiiere cu aceleai nume, extensie i dimensiune memornd aceeai bd n directoare diferite. ExtensieKOctetiBDDirector cheie? Nu, pentru c pot exista mai multe fiiere cu aceleai extensie i dimensiune memornd aceeai bd n acelai director (dar cu nume diferite).
aciclic Tata : Directoare Directoare Disc : Directoare Discuri, total DiscTata cheie? Nu, pentru c pe acelai disc pot exista mai multe directoare avnd acelai tat.

FiierExtensieKOcteti cheie? Nu, pentru c n directoare diferite pot exista fiiere cu aceleai nume, extensie i dimensiune. FiierExtensieBD cheie? Nu, pentru c n directoare diferite pot exista fiiere cu aceleai nume i extensie memornd aceeai bd. KFis: cheie FiierExtensieDirector (n acelai director nu pot exista mai multe fiiere cu aceleai nume i extensie) ExtensieKOctetiBD cheie? Nu, pentru c pot exista mai multe fiiere cu aceleai extensie i dimensiune memornd aceeai bd. ExtensieKOctetiDirector cheie? Nu, pentru c pot exista mai multe fiiere cu aceleai extensie i dimensiune n aceleai director.

KDir: cheie DiscTataDirector (pe orice disc, orice director are un unic tat)
Administratori =(Servere, Utilizatori) #A NAT(6)

ComutBucla: Calculator Disc Director = Gazda Server BD

150

5.10.2.3

Bd relaional i un posibil coninut valid

Bd relaional corespunztoare schemei MMED i un posibil coninut valid al ei este urmtoarea (1p):
Utilizatori (#U, Cont)
#U Cont Parola 1 Administrator shefu 2 Cristi diana

Servere (#S, Server) Gazda #C

#S Server 1 SHEFU 2 CRISTI 3 CRISTI2000 Gazda 1 2 2

Calculatoare (#C, Calculator) Utilizator #U

#C 1 2 3 Calculator Utilizator SHEFU 1 Cristi 2 Constantin 2

BazeDate (#BD, ServerBD) Server #S, Proprietar #U

#BD BD Server Proprietar 1 EmakerTemplate 1 2 2 EmakerTemplate 2 2 3 HDS 1 1 5 eMakerTemplate2000 2 2

Discuri (#D, DiscCalculator) Calculator #C

#D Disc GOcteti Calculator 1 C 60 1 2 D 40 1 3 C 30 2 4 C 20 3

Fiiere (#F, DirectorFiierExtensie) Director #Dir, BD #BD

#F Fiier 1 master 2 eMaker 3 master 4 eMaker Extensie Kocteti Director BD mdf 12000 7 2 mdf 4000 7 2 ldf 1 7 2 ldf 1 7 2

Directoare (#Dir, DiscTataDirector) Disc #D, Tata #Dir

#Dir Director 1 \ 3 eMaker 4 HDS 5 \ 6 eMaker 7 Repository Nivel Tata Disc 1 1 2 1 1 2 1 1 1 3 2 5 3 3 6 3

Administratori (#A, ServereUtilizatori) Servere #S, Utilizatori #U

#A Servere Utilizatori 1 1 1 2 1 2 3 2 2 5 3 2

151

5.10.2.4

Instruciunile SQL pentru calculul interogrii

SELECT Utilizatori.Cont, Count(NrBD.[#S]) AS NrServere, Sum(NrBD.NrBD) AS NrBazeDate FROM (Utilizatori INNER JOIN NrBD ON Utilizatori.[#U] = NrBD.[#U]) INNER JOIN NrAdmin ON NrBD.[#S] = NrAdmin.[#S] GROUP BY Utilizatori.Cont, NrAdmin.NrAdm, NrBD.NrBD, Utilizatori.Cont HAVING (((NrAdmin.NrAdm)=1) AND ((NrBD.NrBD)>1)) ORDER BY Count(NrBD.[#S]) DESC, Sum(NrBD.NrBD) DESC, Utilizatori.Cont;
unde : NrBD: SELECT BazeDate.[#U], BazeDate.[#S], Count(BazeDate.[#BD]) AS NrBD FROM BazeDate GROUP BY BazeDate.[#U], BazeDate.[#S];

iar NrAdmin: SELECT Administratori.[#S], Count(Administratori.[#U]) NrAdm FROM Administratori GROUP BY Administratori.[#S];

AS

154

Error! No text of specified style in document.

5.11

Probleme propuse pentru rezolvare

5.1 Demonstrai propoziia 5.2 i corolarul 5.3 5.2 Demonstrai propoziia 5.10 5.3 Demonstrai lema 5.12 i corolarul 5.13 5.4 Demonstrai propoziia 5.16 5.5 Demonstrai propoziia 5.22 5.6 Demonstrai propoziia 5.23 5.7 Demonstrai propoziia 5.24 5.8 Demonstrai propoziia 5.25 5.9 Demonstrai teorema 5.26 5.10 Demonstrai propoziia 5.30 5.11 Demonstrai teorema 5.32 5.12 Demonstrai propoziia 5.33 5.13 Demonstrai propoziia 5.37 5.14 Demonstrai teorema 5.38 5.15 Demonstrai teorema 5.39 5.16 Demonstrai teorema 5.41 5.17 Demonstrai teorema 5.44 5.18 Proiectai n MMED i traducei n MRD schemele corespunztoare problemelor 1, 2 i 3 propuse n subseciunea 1.12 5.19 Proiectai n MMED i traducei n MRD schemele corespunztoare problemelor 12, 13, 15, 17 i 19 propuse n subseciunea 2.9 5.20 Proiectai n MMED i traducei n MRD schemele corespunztoare problemelor 1, 2 i 3 propuse n subseciunea 4.4 5.21 Fie urmtoarea schem relaional (n care cheile produs de atribute sunt nchise n acolade): PRODUSE (#Produs, Produs) SUBANSAMBLE (#Sub, {Produs, Component}) PIESE (#Piesa, Piesa) PRI (#Parte, {Produs, Parte}) CONINUTURI (#Coninut, {Produs, Piesa}) ECHIPE (#Echipa, Echipa) ANGAJAI (#Ang, LocMunc, Funcie) POSTURI (#Post, Post) PRODUCIE ({Productor, Produs}) EFI (#ef) EFIE ({ef, Subaltern})

154

Error! No text of specified style in document.

155

MANOPER ({Angajat, Produs}) FURNIZRI ({Client, Produs, Departament}) Produs #Produs Component #Produs Parte #Piesa LocMunc #Echipa Productor #Echipa #ef #Ang ef #ef Subaltern #Ang Angajat #Ang Departament #Echipa Descoperii toate greelile de proiectare a schemei, clasificai-le i explicai ce i de ce este greit pe categorii de greeli. Proiectai corect att schema relaional, ct i cea corespunztoare n MMED. Exist vreo constrngere evident formalizabil n MMED, dar care nu poate fi exprimat n termeni relaionali? 5.22 Proiectai n MMED i traducei n MRD schemele ct mai utilizabile real cu putin corespunztoare urmtoarelor subuniversuri de interes: a. O bibliotec public (considerai cel puin: cititori, bibliotecari, corpuri de cldire, etaje, sli, rafturi, etaje de raft, cri, autori, categorii, subclase i clase de domenii, edituri, ediii, mprumuturi) b. Un proces de producie (considerai cel puin: produse finite, precum i piese, subansamble i materii prime ce intr n componena produselor finite, pe oricte niveluri de asamblare, toate generalizate ntr-o ierarhie pe 4 nivele de tip categorii, subclase, clase i superclase; norme de timp, consumuri materiale, manoper i regie, precum i abateri de la norme, adic costuri normate, scriptice i costuri actuale, faptice; echipe de lucru i efi pe mcar 3 nivele; o magazie de intrare, pentru ingrediente i una de ieire, pentru produsele finite; comenzi, aprovizionare, stocuri i livrare) c. O farmacie (considerai cel puin: articole la vnzare, ntr-o ierarhie pe 4 nivele; substane active din componena

155

156

Error! No text of specified style in document.

medicamentelor i dozajul acestora; maladii; reete; balana de gratuiti i compensri; carnete de sntate; medici acreditai s elibereze reete n specialitatea lor; specializri medicale; aprovizionare; producie; vnzare; expirare i perisabiliti) d. O agenie de voiaj (considerai cel puin: destinaii; itinerarii; obiective turistice; voiaje; mijloace de transport; faciliti de cazare, mas i agrement; rezervri; schimburi valutare; vize; clieni) 5.23 *Proiectai n MMED i traducei n MRD schemele ct mai utilizabile real cu putin corespunztoare urmtoarelor subuniversuri de interes: a. O agenie de plasare for de munc b. O agenie imobiliar c. O firm de contabilitate d. Un birou de avocatur e. Un hotel f. Un salon de frumusee g. Un cabinet stomatologic h. O expoziie/trg internaional de produse i servicii 5.24 **Proiectai n MMED i traducei n MRD schema ct mai utilizabil real cu putin pentru o baz de date contabil. 5.25 ***Proiectai n MMED i traducei n MRD schema ct mai utilizabil real cu putin pentru o baz de date de gestiune cuplabil la una de contabilitate. 5.26 Construii DEA i proiectai schema MMED pentru fragmentul metacatalogului MatBase prezentat n exemplul 5.4. 5.27 Construii DEA i proiectai schema MMED pentru bd prezentat n exemplele 5.5, 5.7 i n figura 5.1. 5.28 Implementai algoritmul 5.31 (de asisten a specificrii cheilor structurale ale asociaiilor) ntr-un limbaj de programare oarecare (e.g. TransactSQL, PL/SQL, C, C++, C#, VB, VBA, Java etc.), folosind eventual un motor relaional oarecare (e.g. Access, MS SQL Server, Oracle etc.). 5.29 **Implementai algoritmul 5.34 (de traducerea schemelor de bd din MMED n MRD) ntr-un limbaj de programare oarecare (e.g. TransactSQL, PL/SQL, C, C++, C#, VB, VBA, Java etc.), folosind

156

Error! No text of specified style in document.

157

eventual un motor relaional oarecare (e.g. Access, MS SQL Server, Oracle etc.). 5.30 ***a. Construii DEA pentru schema meta-catalogului de date al unui SGBD bazat pe MMED (indicaie: vezi i proiectul prototipului MatBase [253,20]). ****b. Pe baza DEA construite la punctul anterior, proiectai schema MMED corespunztoare (indicaie: folosii din plin algoritmul 5.31!). **c. Folosind algoritmul 5.43, traducei schema MMED obinut la punctul anterior n MRD. ****d. Folosind schema relaional obinut la punctul anterior, proiectai un SGBD bazat pe MMED oferind doar constrngerile relaional primitive. *****e. Implementai proiectul de la punctul anterior ntr-un limbaj de programare oarecare (e.g. TransactSQL, PL/SQL, C, C++, C#, VB, VBA, Java etc.), folosind un motor relaional oarecare (e.g. Access, MS SQL Server, Oracle etc.). ******f. Renunai n implementarea de la punctul de mai sus la serviciile motorului relaional. *******g. Extindei SGBD obinut la punctul de mai sus pentru a oferi toate constrngerile primitive din MMED. ********h. Adugai i constrngerile obiect. 5.31 *******a. Studiai problema implicaiei pentru cte una din clasele de constrngeri primitive MMED. *********b. Studiai problema coerenei mulimilor de constrngeri primitive MMED. *********c. Studiai i propunei spre consacrare matematic conceptele necesare formalizrii unei noi subclase de constrngeri primitive MMED care s formalizeze restriciile aferente obiectelor partajabile n timp, dar nu simultan. 5.32 **********Proiectai o unealt software pentru analiza programelor COBOL i asistena traducerii lor n Java sau C#. 5.33 *** Proiectai (i implementai ntr-un limbaj la alegere) algoritmul de traducere a schemelor MMED n DEA. Enunai i demonstrai teorema aferent proprietilor sale.

157

158

Error! No text of specified style in document.

5.34 5.35

*** Proiectai (i implementai ntr-un limbaj la alegere) algoritmul de traducere a schemelor relaionale n MMED. Enunai i demonstrai teorema aferent proprietilor sale. *** Proiectai (i implementai ntr-un limbaj la alegere) algoritmul de traducere a DEA n MMED. Enunai i demonstrai teorema aferent proprietilor sale.

Legend: *= problem colar complex **= problem real complex ***= problem colar dificil (proiect de an) ****= problem real dificil *****= problem colar foarte dificil (proiect de licen) ******= problem real foarte dificil *******= problem de masterat n bd ********= problem real, pentru profesioniti ai bd *********= problem de doctorat n bd **********= problem postdoctoral
5.12 Comentarii i referine bibliografice

Credem c, pentru o modelare ct mai corect a datelor, cu ct mai mult matematic este folosit, cu att mai bine. Pe de alt parte, avem convingerea c algebra elementar mpreun cu logica predicatelor de ordin nti folosite de MMED sunt suficiente pentru majoritatea aplicaiilor de bd i bc curente. n plus, dei formalismul matematic pe care se bazeaz MMED pare mult mai complicat dect cel al modelului relaional sau funcional, de fapt, pe de o parte, conveniile notaionale ale MMED simplific mult acest neajuns, iar, pe de alt parte, aproape toi utilizatorii de bd din ziua de azi au absolvit liceul! Desigur c, pe msur ce aplicaiile de modelare a datelor i tehnologia bd, bc i programrii calculatoarelor vor evolua, va fi nevoie din ce n ce mai mare de matematic n domeniu. Probabil c poset-urile vor fi nlocuite n curnd cu latici, apoi cu categorii, iar mulimea constrngerilor primitive va include din ce n ce mai multe subclase, fiecare n parte din ce n ce mai puternice. Vor rezista doar modelele datelor capabile s ncorporeze ntreaga matematic! Modelul matematic elementar al datelor i are obria n abordarea funcional proprie prezentat n capitolul 3. El este

158

Error! No text of specified style in document.

159

desigur puternic influenat att de modelul relaional, de cel entitiasociaii (capitolul 2), de cel logic (capitolul 4), ct i de cel orientat obiect. n 1983 [246] este prezentat o prim formalizare algebric a modelului entiti-asociaii, care este apoi rafinat n mai 1985 [248]. Ea st la baza introducerii n octombrie 1985 a unei prime variante a MMED [250]. Merit poate menionat i faptul c n [246] este prezentat, n embrionul MMED, schema unei bd uriae, cu aproape 1.000 de concepte! Modelarea sistemelor de reprezentani a fost introdus i studiat n 1987 [252], unde se gsesc inclusiv algoritmii de implementare corespunztori soluiei propuse pentru aceast problem. mbogiri succesive ale subclasei constrngerilor primitive, mereu acompaniate de rafinri corespunztoare ale ntregului model, au fost publicate n 1986 [251], 1990 [254], 1997 [255], dar mai ales ntre 2000 i 2006. O contribuie substanial a avut (n special n formalizarea logic elegant a constrngerilor) Simona Manca. A contribuit (n special sugernd utilizarea lemei lui Sperner n demonstraia teoremei ce stabilete numrul maxim de chei simultan posibile) Lavinia Crasovschi. Proiectarea i implementarea unui SGBD experimental bazat pe MMED a fost demarat n 1986 de ctre o mic echip a Oficiului de Calcul al I.I.R.U.C. Bucureti. n 1988 a fost finalizat primul proiect, denumit MatBase [253]. Proiectarea schemei bd a meta-catalogului MatBase fiind la rndul ei fcut tot n MMED, se poate spune c acest proiect conine i o modelare complet, de detaliu, a MMED n MMED! n paralel, n 1987, Marcel Rou a reuit parial, ca lucrare de Diplom la Facultatea de Automatic din U.P.B., o implementare coal a MatBase. O alt implementare parial similar a unui prototip al MatBase, ns mai puternic, a fost realizat, n C i Paradox Engine, de Ana Maria Alupului n 1994 [20], tot ca lucrare de Diplom la Facultatea de Automatic din U.P.B. Ca urmare a crerii n 1990 a unui Laborator de Cercetare-Dezvoltare al Centrului de Calcul I.I.R.U.C., sunt finalizate aproape concomitent, n acelai an, proiectul unei elegante interfee algebrice utilizator pentru MMED, datorate lui Adrian Lungu [235], care a constituit punctul de plecare pentru MMEDQL; FastBase, un subsis-

159

160

Error! No text of specified style in document.

tem de gestiune a cilor de acces generalizate la date, bazat pe arbori B prefix simpli (care s-a constituit ulterior n nivelul fizic al MatBase), datorat lui Ivanov [254]; precum i modulul de asisten a proiectrii schemelor de asociaii [254]. La prototipul precedent, implementat n VBA, DAO i Access 2000, a contribuit semnificativ Lavinia Crasovschi. La noua versiune curent, care folosete C#, ADO i XML .NET, plus MS SQL Server 2000, i-au adus contribuia, n ordine cronologic, Raluca Bulancea, Ana-Maria Roculete, Elena Unciuleanu, Bogdan Dancu, Petre Secicar, Vlad Manca, Alina erbancea i Stelian Giuroiu.

160

Error! No text of specified style in document.

161

6 Concluzii
Probabilitatea de a proiecta corect o bd la calculator, chiar folosind un SGBDR evoluat, este aproape nul, deci neglijabil. O schem corect se poate obine doar dup un efort intelectual intens, repetitiv la noi i noi nivele de abstractizare i sau rafinare, folosind nti hrtia i creionul sau un SGBDC de ultim or precum MatBase i apelnd la cel puin cele trei modele ale datelor de tipul celor prezentate n aceast monografie. Primul pas decisiv l constituie o analiz aprofundat a domeniului modelat; aceasta este mult uurat de cunoaterea sa n detaliu, de experiena analistului afacerii respective (i mai ales de biblioteca sa de sub-modele), dar nu are sori de real izbnd fr o cooperare strns cu beneficiarii bd, singurii n msur s ofere detalii, s valideze soluia propus i s stabileasc tachetele abstractizrii i rafinrii. Al doilea pas const n proiectarea DEA corespunztoare; n cazul profesional, al bd complexe, sunt proiectate zeci sau sute de sub-diagrame interconectate ntre ele, nti fr elipse, pentru a pune n eviden structura domeniului modelat. Aceste DEA trebuie s constituie principalul mod de comunicare cu i validare de ctre clieni, deoarece sunt simple i extrem de sugestive. Dup traducerea (automatizat de MatBase) a acestora ntr-o schem MMED, urmeaz cel mai dificil pas, rafinarea matematic a schemei, care trebuie s descopere toate i numai constrngerile necesare eliminrii oricror poteniale anomalii de actualizare a datelor. Acest proces este iterativ i este esenial actualizarea corespunztoare a DEA (i ea automatizat de MatBase) i revalidarea acestora de ctre beneficiari pas cu pas, pe msur ce sunt fcute modificri n schem. Al patrulea pas const n aplicarea algoritmului de traducere din MMED n MRD (i el inclus n MatBase). Al cincilea, const n implementarea schemei relaionale rezultate la pasul anterior pe un SGBDR la dispoziie (ales de proiectant sau impus de beneficiar), efectund eventuale optimizri (e.g. adugnd coloane i/sau tabele calculate, proceduri catalogate etc.). n MatBase, i acest pas este transparent utilizatorului, fiind automat fcut de sistem.

161

162

Error! No text of specified style in document.

n al aselea pas (final), toate constrngerile ce nu au putut fi traduse n MRD, trebuie implementate n codul aplicaiilor ce gestioneaz actualizarea bd respective (utilizatorilor trebuind s li se interzic accesul direct la tabelele gestionate de SGBDR). O bd corect proiectat este ntotdeauna natural, simpl, elegant, oricnd uor modificabil i care incit la aplicaii (de actualizare, interogare etc. a ei) avnd exact aceleai caliti. Dimpotriv, o bd incorect proiectat este nenatural, complicat, lipsit de elegan, greu de modifiicat i care conduce la aplicaii avnd exact aceleai defecte, plus costuri proporional mai mari. Scopul acestei monografii poate fi rezumat n concluzie la ncercarea de a transmite cititorului tiina i un minim de experien necesare proiectrii riguroase, deci corecte a oricrei bd.

162

Error! No text of specified style in document.

163

7 Bibliografie
Dac am vzut mai departe, e pentru c am stat pe umeri de gigani. Isaac Newton

[1]

[2] [3] [4] [5] [6] [7]

[8] [9]

[10]

S. Abiteboul. Updates, a new frontier. In ICDT'88 (Second International Conference on Data Base Theory), Bruges, Lecture Notes in Computer Science 326. Berlin: SpringerVerlag, 1988, 1-18. S. Abiteboul and C. Beeri. On the power of languages for the manipulation of complex objects. Technical Report 846. INRIA, 1988. S. Abiteboul and N. Bidoit. Nonfirst normal form relations: An algebra allowing data restructuring. Journal of Comp. and System Sc. 33(1):361-393. 1986. S. Abiteboul and S. Grumbach. Base de donns et objects structurs. Technique et Science Informatiques 6(5):383404. 1987. S. Abiteboul and R. Hull. IFO: A formal semantics database model. ACM Trans. on Database Syst. 12(4):297314. 1987. S. Abiteboul and P. Kanellakis. Object identity as a query language primitive. In ACM SIGMOD International Conf. on Manageement of Data, 1989:159-173. S. Abiteboul , P Kanellakis, and G. Grahne. On the representation and querying of possible worlds. In ACM SIGMOD International Conf. on Management of Data, 1987:34-48. S. Abiteboul and V. Vianu. Equivalence and optimization of relational transactions. Journal of the ACM 35(1):70120. 1988. S. Abiteboul and V. Vianu. Procedural and declarative database update languages. In Seventh ACM SIGACT SIGMOD SIGART Symp. on Principles of Database Systems, 1988:240-250. S. Abiteboul and V. Vianu. A transaction-based approach to relational database specification. Journal of the ACM 36(4):758-789. 1989.

163

164

Error! No text of specified style in document.

[11] [12] [13] [14] [15]

[16] [17] [18] [19] [20] [21] [22] [23]

S. Abiteboul and V. Vianu. Procedural languages for database queries and updates. Journal of Comp. and Syst. Sc. 41(2):181-229. 1990. S. Abiteboul and V. Vianu. Datalog extensions for database queries and updates. Journal of Comp. and Syst. Sc. 43(1):62-124. 1991. J. Admek, H. Herrlich, and G. Strecker. Abstract and Concrete Categories. John Wiley & Sons, 1990. R. Ahad, and D. Dedo. OpenODB from Hewlett-Packard: A commercial object-oriented dbms. In Journal of ObjectOriented Programming, 4(9): 31-35, 1992. Ahad, Rafiul and Cheng, Tu-Ting. HP OpenODB: An Object.Oriented Database Management Systems for Commercial Applications. Hewlett-Packard Journal, vol.44, no.3, June 1993. p.20. A. V. Aho, C. Beeri, and J. D. Ullman. The theory of joins in relational databases. ACM Trans. on Database Syst. 4(3):297-314. 1979. A. V. Aho, Y. Sagiv, and J. D. Ullman. Efficient optimization of a class of relational expressions. ACM Trans. on Database Syst. 4(4):435-454. 1979. A. V. Aho, Y. Sagiv, and J. D. Ullman. Equivalence of relational expressions. SIAM Journal on Computing 8(2):218-246. 1979. A. V. Aho and J. D. Ullman. Universality of data retrieval languages. In Sixth ACM Symp. on Principles of Programming Languages, 1979:110-117. A.M. Alupului. Implementarea MatBase. Lucrare de Diplom pentru titlul de inginer, Univ. Politehnic Buc., Fac. Automatic, 1994. W. W. Amstrong. Dependency structure of database relationships. In IFIP Congress, 1974:580-583. W. W. Amstrong and C. Delobel. Decompositions and functional dependencies in relations. ACM Trans. on Database Syst. 5(4):404-430. 1980. ANSI/X3/SPARC Study Group on Database Management Systems. Interim Report 75-0208. FDT-Bulletin ACM SIGMOD 7(2). 1975

164

Error! No text of specified style in document.

165

[24] [25]

[26]

[27] [28]

[29] [30] [31]

[32]

[33] [34]

M.A. Arbib, and E.G. Manes. Arrows, Structures, and Functors. The Categorical Imperative. Academic Press, New York, 1975. H. Arisawa, K. Moriya, and T. Miura. Operations and the properties of non-first-normal-form databases. In Ninth International Conf. on Very Large Data Bases, Florence, 1983:197-204. A. K. Arora and C. R. Carlson. The information preserving properties of certain relational database transformations. In Fourth International Conf. on Very Large Data Bases, Berlin, 1978:352-359. Astrahan, M. M. et al. System R: A Relational Approach to Database Management. ACM TODS, vol. 1, no. 2, June 1976, pp. 97-137. M.P. Atkinson, and K.G. Kulkarni. Experimenting with the functional data model. In Databases - Role and Structure, Stocker, Gray, and Atkinson eds., Cambridge Univ. Press, 1984. Atwood, Thomas. ODMG-93: The Object DBMS Standard, Part 2. Object Magazine, Jan. 1994, p.32. P. Atzeni, and V. de Antonellis. Relational Database Theory. The Benjamin/Cummings Publishing Company, Inc., 1993. P. Atzeni, G. Ausiello, C. Batini, and M. Moscarini. Inclusion and equivalence between relational database schemata. Theoretical Computer Science 19(2):267-285. 1982. P. Atzeni and E. P. F. Chan. Efficient query answering in the representative instance approach. In Fourth ACM SIGACT SIGMOD Symp. on Principles of Database Systems, 1985:181-188. P. Atzeni and E. P. F. Chan. Efficient optimization of simple chase join expressions. ACM Trans. on Database Syst. 14(2):212-230. 1989. P. Atzeni and E. P. F. Chan. Efficient and optimal query answering on independent schemes. Theoretical Computer Science 77(3):291-308. 1990.

165

166

Error! No text of specified style in document.

[35]

[36] [37] [38] [39] [40]

[41]

[42] [43] [44]

[45] [46]

P. Atzeni and M. C. De Bernardis. A new basis for the weak instance model. In Sixth ACM SIGACT SIGMOD SIGART Symp. on Principles of Database Systems, 1987:79-86. P. Atzeni and M. C. De Bernardis. A new interpretation for null values in the weak instance model. Journal of Comp. and System Sc. 41(1):25-43. 1990. P. Atzeni and N. M. Morfuni. Functional dependencies in relations with null values. Information Processing Letters 18(4):233-238. 1984. P. Atzeni and N. M. Morfuni. Functional dependencies and constraints on null values in database relations. Information and Control 70(1):1-31. 1986. P. Atzeni and D. S. Parker Jr. Assumptions in relational database theory. In ACM SIGACT SIGMOD Symposium on Principles of Database Systems, 1982:1-9. P. Atzeni and R. Torlone. Updating databases in the weak instance model. In Eighth ACM SIGACT SIGMOD SIGACT Symposium on Principles of Database Systems, 1989:101109. P. Atzeni and R. Torlone. Efficient updates to independent database schemes in the weak instance model. In ACM SIGMOD International Conf. on Management of Data, 1990:84-93. G. Ausiello, C. Batini, and M. Moscarini. On the equivalence among database schemata. In Proc. International Conference on Databases. Aberdeen, 1980. J. Backus. Can programming be liberated from the von Neumann style? A functional style and its algebra of programs. In Commun. ACM 21(8): 613-641, 1978. F. Bancilhon. On the completeness of query languages for relational databases. Mathematical Foundations of Computer Science, LNCS 64 Berlin:Springer-Verlag, 1978, 112-124. F. Bancilhon, and P. Buneman, editors. Advances in Database Programming Languages. ACM Press, 1990. F. Bancilhon, D. Maier, Y. Sagiv, and J. D. Ullman. Magic sets and other strange ways to implement logic programs.

166

Error! No text of specified style in document.

167

[47]

[48]

[49] [50] [51] [52] [53]

[54] [55]

[56]

[57]

In Fifth ACM SIGACT SIGMOD Symp. on Principles of Database Systems, 1986:1-15. F. Bancilhon and R. Ramakrishnan. An amateur's introduction to recursive query processing strategies. In ACM SIGMOD International Conf. on Management of Data, 1986:16-52. F. Bancilhon, P. Richard, and M. Scholl. VERSO: A relational back end database machine. In D. K. Hsiao, editor, Advanced Database Machine Architecture. Englewood Cliffs, N.J.:Prentice-Hall, 1983, 1-8. D.W. Barnes and J.M. Mack. An Algebraic Introduction to Mathematical Logic. Springer Verlag, 1975. C. Batini, S. Ceri, and S. B. Navathe. Database Design with the Entity-Relationship Model. Menlo Park, Calif.: Benjamin/Cummings, 1991. Bayer, R. and McCreight, E.M. Organization and Maintenance of Large Ordered Indeces. Acta Informatica, vol. 1, no.3, 1972, pp.173-189. Bayer, R. and Unterauer, K. Prefix B trees. ACM TODS, vol.2, no.1, March 1977, pp. 11-26. C. Beeri. Data models and languages for databases. In ICDT'88 (Second International Conference on Data Base Theory), Bruges, Lecture Notes in Computer Science 326. Berlin: Springer-Verlag, 1988, 19-37. C. Beeri and P. A. Bernstein. Computational problems related to the design of normal form relational schemas. ACM Trans. on Database Syst. 4(1):30-59.. 1979. C. Beeri, P. A. Bernstein, and N. Goodmon. A sophisticate's introduction to database normalization theory. In Fourth International Conf. on Very Large Data Bases, Berlin, 1978:113-124. C. Beeri, R. Fagin, and J. H. Howard. A complete axiomatization for functional and multivalued dependencies. In ACM SIGMOD International Conf. on Management of Data, 1978:47-61. C. Beeri and P. Honeyman. Preserving functional dependencies. SIAM Journal on Computing 10(3):647-656. 1981.

167

168

Error! No text of specified style in document.

[58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68]

[69]

C. Beeri and M. Kifer. An integrated approach to logical design of relational database schemes. ACM Trans. on Database Syst. 11(2):134-158. 1986. C. Beeri, A. O. Mendelzon, Y. Sagiv, and J. D. Ullman. Equivalence of relational database schemas. SIAM Journal on Computing 10(2):352-370. 1981. C. Beeri, and R. Ramakrishnan. On the power of magic. Proc. of the ACM Symp. on Principles of Db Systems, 1987. C. Beeri and J. Rissanen. Faithful representation of relational database schemata. Report RJ 2722. IBM Research. San Jose, 1980. C. Beeri and M. Y. Vardi. Formal systems for tuple and equality-generating dependencies. SIAM Journal on Computing 13(1):76-98. 1984. C. Beeri and M. Y. Vardi. A proof procedure for data dependencies. Journal of the ACM 31(4):718-741. 1894. P. A. Bernstein. Synthesizing third normal form relations from functional dependencies. ACM Trans. on Database Syst. 1(4):277-298.1976. Bernstein, P.A. Middleware: An Architecture for Distributed System Services. DEC Corp., Cambridge Res. Lab., March 1993. Bernstein, P.A. and Goodman, Nathan. Concurrency Control in Distributed Database Systems. ACM Computing Surveys, vol.13, no.2, June 1981, pp. 185-222. P. A. Bernstein and N. Goodman. What does Boyce-Codd form do? In Sixth International Conf. on Very Large Data Bases, Montreal, 1980:245-259. J. Biskup. A formal approach to null values in database relations. In H.Gallaire, J. Minker, and J. M. Nicolas, editors, Advances in Database Theory. New York: Plenum, 1981, 299-341. J. Biskup. A foundation of Codd's relational maybeoperations. ACM Trans. on Database Syst. 8(4):608-636. 1983.

168

Error! No text of specified style in document.

169

[70] [71] [72] [73] [74] [75] [76]

[77] [78]

[79]

[80] [81] [82]

J. Biskup, U. Dayal, and P.A. Bernstein. Synthesizing independent database schemes. In ACM SIGMOD International Conf. on Management of Data, 1979:143-151. Bobrowski, Steve. Database Security in a Client/Server World. DBMS, vol. 7, no. 10, Sept. 1994, p. 48. Bobrowski, Steve. Parallel Oracle 7.1. DBMS, vol. 6, no. 12, Dec. 1993, p. 89. Bontempo, Charles J. and Saracco, Cynthia Maro. Database Management Principles and Products. Prentice Hall, New Jersey, 1995. Borland Int. Borland PARADOX 7.0 for Windows 95. Borland, 1992. V. Breazu. Semantics in Complete Lattices for Relational Database Functional Dependencies. Analele tiinifice ale Univ. "Al.I. Cuza", Iai, tom XXVIII, s.Ia, 1982, f.1 V. Breazu i C. Manca. Asupra unui model funcional n teoria matematic a bazelor de date. Comparaie cu modelul relaional. Comun. la al 6-lea Simpozion CONDINF'80, Cluj, 1980. V. Breazu i C. Manca. On the Description Power of a Functional Database Model. In Fourth Int. Conf. on Control Syst. and Comp. Sci., 4: 223-226, May 1981. V. Breazu i C. Manca. Forme normale pentru scheme cu dependene funcionale n modelul relaional al bazelor de date. In Conf. Na. de Electron., Telecom., Automat. i Calc.. I.P.B., S.12, 1982: 152-156. M. L. Brodie and J. Mylopoulos. Knowledge bases and databases: Semantic vs computational theories of information. In G. Ariav and J. Clifford, editors, New Directions for Database Systems. New York: Ablex, 1986. M. L. Brodie and J. Mylopoulos, editors. On Knowledge Base Management Systems. Berlin: Springer-Verlag, 1986. M. L. Brodie, J. Mylopoulos, and J. Schmidt, editors. On Conceptual Modelling. Berlin: Springer-Verlag, 1984. F. Bry. Query Evaluation in Recursive databases: Bottomup and Top-down Reconciled. In IEEE Trans. on Knowledge and Data Engineering, 2, 1990.

169

170

Error! No text of specified style in document.

[83] [84] [85]

[86]

[87]

[88] [89] [90] [91] [92] [93]

[94] [95]

P. Buneman, and R.E. Frankel. FQL - A functional query language. In ACM SIGMOD Conf., Boston, 1979: 52-58. P. Butterworth, A. Otis, and J. Stein. The Gemstone object database management system. Comm. of the ACM 34(10):64-77. 1991. F. Cacace, S. Ceri, S. Crespi-Reghizzi, L. Tanca, and R. Zicari. Integrating object-oriented data modelling with a rule-based programming paradigm. In ACM SIGMOD International Conf. on Management of Data, 1990:225-236. M. A. Casanova. The theory of functional and subset dependencies over relational expressions. Technical Report 3/81. Rio de Janeiro: Dept. de Informatica, Pontificia Unversidade Catolica. 1981. M. A. Casanova, R. Fagin, and C. H. Papadimitriou. Inclusion dependencies and their interaction with functional dependencies. Journal of Comp. and System Sc. 28(1):2959. 1984 S. Ceri, S. Crespi-Reghizzi, A. Di Maio, and L. A. Lavazza. ALGRES. IEEE Trans. on Software Eng. SE-14(11). 1988. S. Ceri, S. Crespi-Reghizzi, G. Lamperti, L. A. Lavazza, and R. Zicari. ALGRES: An advanced database system for complex applications. IEEE Software 7(4):68-78. 1990. S. Ceri and G. Gottlob. Normalization of relations and Prolog. Communications of the ACM 29(6):524-544. 1986. S. Ceri, G. Gottlob, and L. Tanca. Logic Programming and Data Bases. Berlin: Springer-Verlag, 1989. D. D. Chamberlin et al. A history and evaluation of System R. Communications of the ACM 24(10). 1981. E. P. F. Chan. Optimal computation of total projections with unions of simple chase join expressions. In ACM SIGMOD International Conf. on Management of Data, 1984:149-163. E. P. F. Chan. A desing theory for solving the anomalies problem. SIAM Journal on Computating 18(3):429-448. 1989. E. P. F. Chan and H. Hernndez. On the desirability of acyclic BCNF database schemes. Theoretical Computer Science 62(1-2). 1988.

170

Error! No text of specified style in document.

171

[96] [97] [98] [99]

[100] [101]

[102] [103] [104] [105] [106] [107]

E. P. F. Chan and A. O. Mendelzon. Independent and separable database schemes. SIAM Journal on Computing 16(5):841-851. 1987. A. K. Chandra. Theory of database queries. In Seventh ACM SIGACT SIGMOD SIGART Symp. on Principles of Database Systems, 1988:1-9. A. K. Chandra and D. Harel. Computable queries for relational databases. Journal of Comp. and System Sc. 21:333-347. 1980. A. K. Chandra, H. R. Lewis, and J. A. Makowsky. Embedded implicational dependencies and their inference problem. In Thirteenth ACM SIGACT Symp. on Theory of Computing, 1981:342-354. A. K. Chandra and M. Y. Vardi. The implication problem for functional and inclusion dependencies is undecidable. SIAM Journal on Computating 14(3):671-677. 1985. C.C. Chang. On the Evaluation of Queries Containing Derived Relations in a Relational Database. In H. Gallaire, J. Minker, and J. Nicolas, eds., Advances in Database Theory, Vol. I, Plenum Press, 1981. C.C. Chang and H.J. Keisler. Model Theory. North-Holland Publishing Company, 1973. P. P. Chen. The entity-relationship model: Toward a unified view of data. ACM Trans. on Database Syst. 1(1):9-36. 1976. Cheng, J.M. et al. IBM DB2 Performance: Design, Implementation, and Tuning. IBM Systems Journal, vol. 23, no. 2, 1984. D. Chimenti, R. Gamboa, R. Krishnamurti, S. Naqvi, S. Tsur, and C. Zaniolo. The LDL system prototype. IEEE Trans. on Knowledge and Data Eng. 2(1):76-90. 1990. E. F. Codd. A relational model for large shared data banks. Communications of the ACM 13(6):377-387. 1970. E. F. Codd. A database sublanguage founded on the relational calculus. In ACM SIGFIDET Workshop on Data Description, Access and Control, 1971:35-61.

171

172

Error! No text of specified style in document.

[108] [109] [110] [111] [112] [113] [114] [115] [116] [117]

[118] [119] [120] [121] [122] [123]

E. F. Codd. Further normalization of the data base relational model. In R. Rustin, editor, Data Base Systems. Englewood Cliffs, N. J. : Prentice-Hall, 1972, 33-64. E. F. Codd. Relational completeness of data base sublanguages. In R. Rustin, editor, Data Base Systems. Englewood Cliffs, N. J. : Prentice-Hall, 1972, 65-98. E. F. Codd. Recent investigations into relational database systems. In IFIP Congress, 1974:1017-1021. E. F. Codd. Extending the database relational model to capture more meaning. ACM Trans. on Database Syst. 4(4):397-434. 1979. E. F. Codd. 'Universal' relation fails to replace relational model. Letter to the editor. IEEE Software 5(4):4-6. 1988 . Comer, D. The Ubiquitous B-tree. Computing Surveys, vol.11, no.2, June 1979, pp.121-137. S. Cosmadakis, P. C. Kanellakis, and N. Spyratos. Partition Semantics for Relations. unpub. paper, 1985. S. Cosmadakis, P. C. Kanellakis, and M. Vardi. Polymonial-time implication problems for unary inclusion dependencies. Journal of the ACM 37(1):15-46. 1990. Crus, R.A. Data Recovery in IBM DB2. IBM Systems Journal, vol. 23, no. 2, 1984, pp.178-188. P. Dadam et al. A DBMS prototype to support extended NF 2 relations: An integrated view of flat tables and hierarchies. In ACM SIGMOD International Conf. on Management of Data, 1986:356-367. C. J. Date. An Introduction to Database Systems. Volume 2. Reading, Mass.: Addison Wesley, 1983. C. J. Date. A Guide to DB2. Reading, Mass.: Addison Wesley, 1984. C. J. Date. An Introduction to Database Systems. 4th ed. Volume 1. Reading, Mass.: Addison Wesley, 1986 C. J. Date. A Guide to INGRES. Reading, Mass.: Addison Wesley, 1987. Date, C.J. and White, Colin. A Guide to DB2. Fourth Edition. Addison Wesley, 1992. Date, C.J. An Introduction to Database Systems. Sixth Edition. Addison-Wesley, 1994.

172

Error! No text of specified style in document.

173

[124]

[125] [126]

[128]

[129] [130] [131] [132] [133] [134] [135] [136]

U. Dayal, and others. Simplifying complex objects: The PROBE approach to modelling and querying them. In Schek and Schlageter, eds., Informatik Fachberichte 136: 17-38, Springer Verlag, 1987, P. DeBra and J. Paredaens. An algorithm for horizontal decompositions. Information Processing Letters 17(2):9195. 1983. P. DeBra and J. Paredaens. Horizontal decompositions for handling exceptions to functional dependencies. In H. Gallaire, J. Minker, and J.-M. Nicolas, editors, Advances in Database Theory. Volume 2. New York: Plenum, 1984, 123-144. C. Delobel and R. C. Casey. Decomposition of a database and the theory of Boolean switching functions. IBM Journal of Research and Development 17(5):370-386. 1972. R. Demolombe. Syntactical characterization of a subset of domain independent formulas. Report. Toulouse: ONERACERT, 1982. O. Deux et al. The O2 system. Communications of the ACM 34(10):34-49. 1991. R. Di Paola. The recursive unsolvability of the decision problem for the class of definite formulas. Journal of the ACM 16(2):324-327. 1969. A. Diller. Z, An Introduction to Formal Methods, 2nd ed. John Wiley & Sons, 1994. H.-D. Ebbinghaus, J. Flum, and W. Thomas. Mathematical Logic. Springer Verlag, 1984. R. A. ElMasri and S. B. Navathe. Fundamentals of Database Systems. Second edition. Redwood City, Calif.: Benjamin/Cummings, 1994. R. A. ElMasri and S. B. Navathe. Fundamentals of Database Systems. Menlo Park, Calif.: Benjamin/Cummings, 1988. H. B. Enderton. A Mathematical Introduction to Logic. New York: Academic Press, 1972.

173

174

Error! No text of specified style in document.

[137] [138]

[139] [140] [141] [142] [143] [144]

[145] [146] [147] [148]

Fagin, R. A Normal Form for Relational Databases that Is Based on Domains and Keys. ACM TODS, vol.6, no.3, 1981, pp.387-415. R. Fagin. The decomposition versus the synthetical approach to relational database design. In Third International Conf. on Very Large Data Bases, Tokyo, 1977:441-446. R. Fagin. Multivalued dependencies and a new normal form for relational databases. ACM Trans. on Database Syst. 2(3):262-278. 1977. R. Fagin. Normal forms and relational database operators. In ACM SIGMOD International Conf. on Management of Data, 1979:123-134. R. Fagin. A normal form for relational databases that is based on domains and keys. ACM Trans. on Database Syst. 6(3):310-319. 1981. R. Fagin. Horn clauses and database dependencies. Journal of the ACM 29(4):952-983. 1982. R. Fagin, A. O. Mendelzon, and J. D. Ullman. A simplified universal relation assumption and its properties. ACM Trans. on Database Syst. 7(3):343-360. 1982. P. C. Fischer, L. V. Saxton, S. J. Thomas, and D. Van Gucht. Interactions between dependencies and nested relational structures. Journal of Comp. and System Sc. 31(2):343-354. 1985. P. C. Fischer and S. J. Thomas. Operators for non-firstnormal-form relations. In Proc. of IEEE Computer Software Applications, 1983:464-475. P. C. Fischer and D. Van Gucht. Weak multivalued dependencies. In Third ACM Symposium on Principles of Database Systems, 1984:266-274. D.H. Fishman, and very many others. Iris: An ObjectOriented Database Management System. In ACM Trans. Office Inf. Syst., 5(1): 48-69, 1987. A. L. Furtado and L. Kerschberg. An algebra of quotient relations. In ACM SIGMOD International Conf. on Management of Data, 1977:1-8.

174

Error! No text of specified style in document.

175

[149] [150] [151] [152] [153] [154] [155] [156]

[157]

[158] [159] [160] [161]

H. Gallaire and J. Minker, editors. Logic and Databases. New York: Plenum, 1978. H. Gallaire, J. Minker, and J. M. Nicolas, editors. Advances in Database Theory. Volume 1. New York: Plenum, 1981. H. Gallaire, J. Minker, and J. M. Nicolas, editors. Advances in Database Theory. Volume 2. New York: Plenum, 1984. H. Gallaire, J. Minker, and J. M. Nicolas. Logic and databases: A deductive approach. ACM Computing Surveys 16(2):153-185. 1984. G. Gardarin and P. Valduriez. Relational Databases and Knowledge Bases. Reading, Mass.: Addison Wesley, 1990. M. R. Garey and D. S. Johnson. Computers and Intractability. San Francisco: W. H. Freeman and Company, 1979. Gifford, Dwayne et al. Access 95 Unleashed. SAMS Publishing, Indianapolis, 1996. J.A. Goguen, J.W. Thatcher, E.G. Wagner, and J.B. Wright. A Junction Between Computer Science and Category Theory, I: Basic Concepts and Examples (Part 1). IBM T.J. Watson Research Center Report RC 4526, 1973. J.A. Goguen, J.W. Thatcher, E.G. Wagner, and J.B. Wright. A Junction Between Computer Science and Category Theory, II: Basic Concepts and Examples (Part 2). IBM T.J. Watson Research Center Report RC 5908, 1976. B. S. Goldstein. Constraints on null values in relational databases. In Seventh Int'l Conf. on Very Large Data Bases, 1981:101-111. G. Goos and J. Hartmanis, editors. Category Theory Applied to Computation and Control. Proc. 1st Int. Symp., San Francisco, 1974. LNCS 25, Springer-Verlag, 1975. Gotlieb, L. R. Computing join of relations. ACM SIGMOD International Symposium on Management of Data, 1975, pp. 55-63. M. Graham, A. O. Mendelzon, and M. Y. Vardi. Notions of dependency satisfaction. Journal of the ACM 33(1):105129. 1986.

175

176

Error! No text of specified style in document.

[162] [163]

[164] [165] [166] [167] [168] [169] [170] [171] [172] [173] [174] [175]

M. Graham and M. Yannakakis. Independent database schemas. Journal of Comp. and System Sc. 28(1):121-141. 1984. G. Grahne. Horn tables - an efficient tool for handling incomplete information in databases. In Eighth ACM SIGACT SIGMOD SIGART Symposium on Principles of Database Systems, 1989:75-82. J. Grant. Null values in a relational database. Information Processing Letters 6(5):156-159. 1977. J. Grant and J. Minker. The impact of logic programming on databases. Communications of the ACM 35(3):66-81. 1992. G. Grtzer. Lattice Theory. First Concepts and Distributive Lattices. W.H. Freeman and Co., San Francisco, 1971. A. Gray, James and Reuter, Andreas. Transaction Processing: Concepts and Techniques. Morgan Kaufman, U.S.A., 1993. Haderle, D.J. and Jackson, R.D. IBM DB2 Overview. IBM Systems Journal, vol. 23, no. 2, 1984, pp.112-125. Haerder, T. Implementing a Generalized Access Path Structure for A Relational Database System. ACM TODS, vol.3, no.3, Sept. 1978, pp. 285-298. M. Hammer, and D. McLeod. The Semantic Data Model: a Modelling Mechanism for Database Applications. In ACM SIGMOD Int. Conf. on the Manag. of Data, 1978. H. Hernndez and E. P. F. Chan. Constant-timemaintainable BCNF database schemes. ACM Trans. on Database Syst. 16(4)571-599. 1991. H. Herrlich, and G.E. Strecker. Category Theory, An Introduction, 2nd ed. Heldermann Verlag, Berlin, 1979. P. Hilton, and Z-C. Wu. A Course in Modern Algebra. John Wiley & Sons, 1974. P. Honeyman. Testing satisfaction of functional dependencies. Journal of the ACM 29(3):668-677. 1982. Hsiao, Hui-I. Parallel Database System Technology. IBM Res. Rep. 18866, IBM T.J. Watson Res. Center, April 1993.

176

Error! No text of specified style in document.

177

[176] [177]

[178] [179] [180] [181] [182] [183] [184] [185] [186] [187] [188]

R. Hull. A survey of theoretical research on typed complex database objects. In J. Paredaens, editor, Databases. New York: Academic Press, 1988, 193-256. R. Hull and M. Yoshikawa. ILOG.: Declarative creation and manipulation of object identifiers. In Sixteenth International Conference on Very Large Data Bases, Brisbane, 1990:455-468. R. B. Hull. Relative information capacity of simple relational schemata. SIAM Journal on Computing 15(3):856-886. 1986. R. B. Hull and R. King. Semantic database modelling: Survey, applications and research issues. ACM Comp. Surveys 19(3):201-260. 1987. IBM Corp. Distributed Relational Database Architecture Reference. SC26-4651, 1990. IBM Corp. Distributed Relational Database Architecture. Connectivity Guide. Prentice Hall, New Jersey, Teresa Hopper, editor, 1995. T. Imielinski and W. Lipski. On representing incomplete information in relational databases. In Seventh International Conf. on Very Large Data Bases, Cannes, 1981:388-397. T. Imielinski and W. Lipski. Incomplete information and dependencies in relational databases. In ACM SIGMOD International Conf. on Management of Data, 1893:178-184. T. Imielinski and W. Lipski. Incomplete information and dependencies in relational databases. Journal of ACM 31(4):761-791. 1984. M. Ito, M. Iwasaki, and T. Kasami. Some results on the representative instance in relational databases. SIAM Journal on Computing 14(2):334-354. 1985. V. Ivanov. Implementing FastBase. unpub. paper, subm. to 13th ISDBMS, Mamaia, 1990. Jacobson, Ivar et al. Object-Oriented Software Engineering. A Use Case Driven Approach. Revised Fourth Printing. Addison-Wesley, ACM Press, 1994. G. Jaeschke and H. -J. Schek. Remarks on the algebra for non first normal form relations. In ACM SIGACT SIGMOD Symp. on Principles of Database Systems, 1982:124-138.

177

178

Error! No text of specified style in document.

[189] [190] [191] [192]

[193]

[194] [195] [196] [197] [198] [199] [200] [201]

James, Phil and Weingarten, Jan. Internet Guide for Windows 95. Ventana Communications Group, U.S.A., 1995. J. H. Jou and P. C. Fischer. The complexity of recognizing 3NF relation schemes. Information Processing Letters 14(4):187-190. 1983. Y. Kambayashi, K. Tanaka, and K. Takeda. Synthesis of unnormalized relations incorporating more meaning. Inf. Sci. 29:201-247. 1983. P. Kandzia and H. Klein. On equivalence of relational databases in connection with normalization. In Workshop on Formal Bases for Databases. Toulouse: ONERA-CERT, 1979. P. C. Kanellakis, S. Cosmadakis, and M. Vardi. Unary inclusion dependencies have polynomial-time inference problems. In Fifteenth ACM SIGACT Symp. on Theory of Computing, 1983:264-277. A. Kato. An abstract Relational Model and Natural Join Functors. In Bull. of Informatics and Cybern., 20: 95-106, 1983. Y. Kawahara. Categorical Relational Database Models. Bulletin of Informatics and Cybern. Vol. 21, No. 1-2, 1984. A. M. Keller. Set-theoretic problems of null completion in relational databases. Information Processing Letters 22(5):261-265. 1986. A. Kemper, and G. Moerkotte. Object-Oriented Database Management. Prentice-Hall, 1994. W. Kent. Limitations of record-based information models. ACM Trans. on Database Syst. 4(1): 107-131, 1979. W. Kent. Consequences of assuming a universal relation. ACM Trans. on Database Syst. 6(4):539-556. 1981. W. Kent. The universal relation revisited. ACM Trans. on Database Syst. 8(4):644-648. 1983. L. Kerschberg, editor. Proc. First Workshop on Expert Database Systems. Menlo Park. Calif.: Benjamin/Cummings, 1986.

178

Error! No text of specified style in document.

179

[202] [203] [204] [205] [206] [207] [208] [209] [210] [211] [212] [213]

[214] [215]

L. Kerschberg., editor. Proc. First Conf. on Expert Database Systems. Menlo Park, Calif.: Benjamin/Cummings, 1987. L. Kerschberg., editor. Proc. Second Conf. on Expert Database Systems. Menlo Park, Calif.: Benjamin/Cummings, 1988. L. Kerschberg., editor. Proc. Third Conf. on Expert Database Systems. Menlo Park, Calif.: Benjamin/Cummings, 1990. L. Kerschberg, and J.E.S. Pacheco. A Functional Database Model. In Comp. Sci. Monograph, Pontificia Universidade Catolica, Rio de Janeiro, 1976. M. Kifer, and E. Lozinskii. A Framework for an Efficient Implementation of Deductive Databases. In Proc. Sixth Advanced Db Symp., Tokyo, 1986. W. Kim. Object-oriented databases: Definition and research directions. IEEE Trans. on Knowledge and Data Eng. 2(3):327-341. 1990. W. Kim, J. F. Garza, N. Ballou, and D. Woelk. Architecture of the ORION next-generation database system. IEEE Trans. on Knowledge and Data Eng. 2(1):109-124. 1990. S.C. Kleene. Mathematical Logic. John Wiley & Sons, Inc., 1967. A. Klug. Equivalence of relational algebra and relational calculus query languages having aggregate functions. Journal of the ACM 29(3):699-717. 1982. Knuth, Donald E. The Art of Computer Programming. Volume 3: Sorting and Searching. Addison-Wesley, 1973. H. F. Korth and A. Silberschatz. Database Systems Concepts. New York: McGraw-Hill, 1986. H. F. Korth and J. D. Ullman. System/U: A system based on the universal relation assumption. XP1 Workschop on Relational Database Theory, State University of New York, Stonybrook, N. Y. 1980. R. Kowalsky. Logic for Data Description. In Logic and Databases, Plenum Press, 1978:77-103. R. Kowalsky. Logic as a Database Language. In Seminar on Theoretical Issues in Databases, Cosenza, Italia, 1981.

179

180

Error! No text of specified style in document.

[216] [217] [218] [219] [220] [221] [222] [223] [224] [225] [226] [227] [228] [229] [230]

K.G. Kulkarni. Evaluation of Functional Data Models for DB Design and Use. Ph.D. Thesis, Univ. of Edinburgh, 1983. K.G. Kulkarni. Extended Functional Data Model - User Manual. Univ. of Edinburgh, 1983. G. M. Kuper. The Logical Data Model: A New Approach to Database Logic. Ph. D. diss. Standford University, 1985. G. M. Kuper and M. Y. Vardi. A new approach to database logic. In Third ACM SIGACT SIGMOD Symp. on Principles of Database Systems, 1984:86-96. M. Lacroix and A. Pirotte. Generalized joins. ACM SIGMOD Record 8(3):14-15. 1976. C. Lamb, G. Landis, J. Orenstein, and D Weinreb. The ObjectStore database System. Communications of the ACM 34(10)50-63, 1991. C. H. LeDoux and D. S. Parker. Reflections on BoyceCodd normal form. In Eighth International Conf. on Very Large Data Bases, Mexico-City, 1982:131-141. T.T. Lee. An Algebraic Theory of Relational Databases. The Bell System Tech. Journal, Vol. 62, No.10, 1983. R.M. Lee, and R. Gerritsen. Extended Semantics for Generalization Hierarchies. In SIGMOD Int. Conf. on Manag. of Data, 1978:18-25. N. Lerat and W. Lipski, Jr. Nonaplicable nulls. Theoretical Computer Science 46(1):67-82. 1986. Y. E. Lien. Multivalued dependencies with null values in relational databases. In Fifth International Conf. on Very Large Data Bases, 1979:61-66. Y. E. Lien. On the equivalence of database model. Journal of the ACM 29(2):333-362. 1992. Linthicum, David. Client/Server Protocols: Choosing the Right Connection. DBMS, Jan. 1994, p.60. Linthicum, David. Operating Systems for Database Servers. DBMS, Feb. 1994, p.62. W. Lipski, Jr. Two NP-complete problems related to informational retrival. In Fundamentals of Computation, Theory, Lectures Notes in Computer Science 56. Berlin: Springer-Verlag, 1977, 452-458.

180

Error! No text of specified style in document.

181

[231] [232] [233] [234] [235] [236] [237] [238]

[239] [240] [241] [242] [243]

W. Lipski, Jr. On semantic issues connected with incomplete information databases. ACM Trans. on Database Syst. 4(3):262-296. 1979. W. Lipski, Jr. On databases with incomplete information. Journal of the ACM 28(1):41-70. 1981. J. W. Lloyd. Foundations of Logic Programming. 2nd ed. Berlin: Springer-Verlag, 1987. G. M. Lohman, B. Lindsay, H. Pirahesh, and K. B. Schiefer. Extensions to Starburst: Objects, types, functions, rules. Communications of the ACM 34(10):94-109. 1991. C. L. Lucchesi and S. L. Osborn. Candidate keys for relations. Journal of Comp. and System Sc. 17(2):270-279. 1978. A. Lungu. Using Elementary Algebra for Querying Databases. unpub. paper, subm. to 13th ISDBMS, Mamaia 1990. S. Mac Lane. Categories for the Working Mathematicians. Springer-Verlag, 1971. D. Maier. Discarding the universal relation assumption: Preliminary report. XP1 Workshop on Relational Database Theory, State University of New York, Stonybrook. N. Y. 1980. D. Maier. Minimum covers in the relational database model. Journal of the ACM 27(4):664-674. 1980. D. Maier. The Theory of Relational Databases. Potomac, Md.: Computer Science Press, 1983. D. Maier, A. O. Mendelzon, F.Sandri, and J. D. Ullman. Adequacy of decompositions in relational databases. Journal of Comp. and System Sc. 21(3):368-379. 1980. D. Maier, A. O. Mendelzon, and Y. Sagiv. Testing implications of data dependencies. ACM Trans. on Database Syst. 4(4):455-468. 1979. D. Maier, D. Rozenshtein, and D. S. Warren. Window functions. In P. C. Kanellakis and F. P. Preparata, editors, Advances in Computing Research. Volume 3. Greenwich, Ct.: JAI Press, 1986, 213-246.

181

182

Error! No text of specified style in document.

[244] [245] [246] [247] [248] [249] [250] [251] [252] [253] [254] [255] [265] [256]

D. Maier and J. D. Ullman. Fragments of relations: First hack. XP2 Workshop on Relational Database Theory, Penn State University, State College, Pennsylvania, 1981. D. Maier, J. D. Ullman, and M. Vardi. On the foundations of the universal relation model. ACM Trans. on Database Syst. 9(2):283-308. 1984. A. Makinouchi. A consideration on normal form of not necessarly normalized relations. In Third International Conf. on Very Large Data Base, Tokyo, 1977:447-453. C. Manca. Modelarea ntreprinderilor cu ajutorul bazelor de date. Un prim model al bd I.I.R.U.C. Raport tehnic IIRUC RTCC#5, martie 1983. C. Manca. On using logic for relational database design. In Fifth Int. Conf. on Control Syst. and Comp. Sci., 3: 164168, June 1983. C. Manca. A Formal Viewpoint on the Entity-Relationship Data Model. In Sixth Int. Conf. on Control Syst. and Comp. Sci., 2: 174-178, May 1985. C. Manca. Cteva contraexemple de proiectare a bd demonstrnd c modelarea datelor nu trebuie abordat relaional. In INFO IAI'85, 1985: 303-313. C. Manca. Introducere ntr-un model al datelor bazat pe teoria elementar a mulimilor, relaiilor i funciilor. In INFO IAI'85, 1985: 314-320. C. Manca. Introducere ntr-un model matematic al datelor. Comunic. la INFOTEC'86, ITCI Bucureti, 1986. C. Manca. Baze de date, sisteme de reprezentani i surjecii canonice asociate relaiilor de echivalen. In INFO IAI'87, 1987: 99-110. C. Manca. Proiectul nucleului SGBD MatBase. Raport tehnic IIRUC RTCC#20, nov. 1988. C. Manca. A Deeper Insight into the Mathematical Data Model. In 13th Int. Seminar on DBMS, ISDBMS. Mamaia, 1990: 122-134. C. Manca. Modelul relaional al datelor. Matthews, Carole Boggs and Shepard, Patricia. Paradox 4. The Complete Reference. Osborne McGraw-Hill, California, 1993.

182

Error! No text of specified style in document.

183

[257] [258] [259] [260] [261] [262] [263] [264] [265] [266] [267] [268] [269] [270] [271] [272]

G.H. Mealy. Another Look at Data. In AFIPS Fall Joint Comp. Conf., (31): 525-534, 1967. E. Mendelson. Introduction to Mathematical Logic. New York: Van Nostrand-Rehinold, 1978. A. O. Mendelzon. Database states and their tableau. ACM Trans. on Database Syst. 9(2):264-282. 1984. Microsoft Corp. Getting Results with Microsoft Office for Windows 95. Microsoft Press, Washington, 1995. Microsoft Corp. Microsoft Office for Windows 95 Resource Kit. Microsoft Press, Washington, 1995. Microsoft Corp. Microsoft Visual FoxPro Resource Kit. Microsoft Press, Washington, 1995. Microsoft Corp. Microsoft Windows 95 Resource Kit. Microsoft Press, Washington, 1995. J. Minker, editor. Foundations of Deductive Databases and Logic Programming. Los Altos, Calif.: Morgan Kauffman, 1988. J. C. Mitchell. The implication problem for functional and inclusion dependencies. Information and Control 56(1)154173. 1983. Mohan, C.H. et al. Parallelism in Relational Database Management Systems. IBM System Journal, vol. 33, no.2, 1994, p. 349. K. Morris, and many others. YAWN! (Yet Another Window on NAIL!). In Proc. IEEE Int. Conf. on Data Engineering, 1987. I. Mumick, H. Pirahesh, and R. Ramakrishnan. The Magic of Duplicates and Aggregates. In VLDB, 1990. S. Naqvi and S. Tsur. A Logical Language for Data and Knowledge Bases. Potomac, Md.: Computer Science Press, 1989. J.-M. Nicolas. Logic for improving integrity checking in relational databases. Acta Informatica 18(3):227-253. 1982. Norton, Peter and Mueller, John. Peter Nortons Complete Guide to Windows 95. SAMS Pub., Indianapolis, 1995. Obermarck, Ron. Distributed Deadlock Detection Algorithm. TODS, June 1982, pp. 187-208.

183

184

Error! No text of specified style in document.

[273]

[274] [275] [276] [277] [278] [279] [280] [281] [282] [283] [284] [285] [286]

A. Ohori, P. Buneman, and V. Breazu-Tannen. Database programming in Machiavelli: A polymorphyc language with static type inference. In ACM SIGMOD Conf. on Manag. of Data, Portland, 1989. Oracle Corp. Oracle7 Relational Database Management System Feature Summary (including release 7.1). Oracle Corp. manual A14822, May 1994. S. L. Osborn. Towards a universal relation interface. In Fifth International Conf. on Very Large Data Bases, Rio de Janeiro, 1979:52-60. Z. M. Ozsoyoglu and L. Y. Yuan. A new normal form for nested relations. ACM Trans. on Database Syst. 12(1):111136. 1987. Papadimitriou, Christos. The Theory of Database Concurency Control. Computer Science Press, 1986. J. Paredaens. About functional dependencies in a database structure and their coverings. Report 342. Philips MBLE Lab. 1977. J. Paredaens. On the expressive power of the relational algebra. Information Processing Letters 7(2):107-111. 1978. G. Phipps, M. Derr, and K. Ross. GLUE-NAIL!: A Deductive Database System. In SIGMOD, 1991. A. Pirotte. High-level database languages. In H. Gallaire and J. Minker, editors, Logic and Databases. New York: Plenum, 1978, 409-435. I. Purdea i G. Pic. Tratat de algebr modern, Vol. I. Ed. Acad. R.S.R., 1977. I. Purdea. Tratat de algebr modern, Vol. II. Ed. Acad. R.S.R., 1982. H.R. Quillian. Semantic memory. In Semantic Inf. Processing, M. Minskz, ed., M.I.T. Press, 1968. G. Radu. Algebra categoriilor i functorilor. Junimea, Iai, 1988. R. Ramakrishnan, D. Srivastava, and S. Sudarshan. CORAL: Control, Relations and Logic. In VLDB, 1992.

184

Error! No text of specified style in document.

185

[287] [288] [289] [290] [291]

[292] [293] [294]

[295] [296] [297] [298] [299]

R. Ramakrishnan, D. Srivastava, S. Sudarshan, and P. Sheshadri. Implementation of the CORAL deductive database system. In SIGMOD, 1993. R. Ramakrishnan, and J. Ullman. Survey of Research in Deductive Database Systems. In Journal of Logic Programming, 1994. R. Reiter. On closed world databases. In H. Gallaire and J. Minker, editors, Logic and Databases. New York: Plenum, 1978, 55-76. R. Reiter. Data Bases: A Logical Perspective. In Workshop on Data Abstraction, Databases, and Conceptual Modelling, Pingree Park, Colorado, 1980:174-176. R. Reiter. Towards a logic reconstruction of relational database theory. In M. L. Brodie, J. Mylopoulos, and J. W. Schmidt, editors, On conceptual Modelling. Berlin: Springer-Verlag, 1984. R. Reiter. Foundations for knowledge-based systems. In IFIP Congress, 1986. Relational Technology. Distributed INGRES for the UNIX and VMS Operating Systems. Release 6.3. Relational Technology, Nov. 1989. J. Rissanen. Theory of joins for relational databases - a tutorial survey. In Mathematical Foundations of Computer Science, Lecture Notes in Computer Science 64. Berlin: Springer-Verlag, 1979, 537-551. J. Rissanen. Independent components of relations. ACM Trans. on Database Syst. 2(4):314-325. 1982. J. Rissanen. On equivalence of database schemes. In ACM SIGACT SIGMOD Symp. on Principles of Database System, 1982:23-26. J. Rissanen and C. Delobel. Decomposition of files, a basis for data storage and retrieval. Report RJ 1220. IBM Research, San Jose, 1973. I. Rival, ed. Ordered Sets. Proc. of NATO Adv. Study Inst., Banf, Canada, 1981. D. Reidel Pub. Company, 1982. J.W. Robbin. Mathematical Logic. A First Course. W.A. Benjamin, Inc., 1969.

185

186

Error! No text of specified style in document.

[300] [301] [302] [303] [304] [305]

[306] [307] [308] [309] [310]

[311]

R.Rogers. Mathematical Logic and Formalized Theories. North-Holland Publishing Company, 2nd printing, 1974. Rosenberg, A.L. and Snyder, L. Time- and SpaceOptimality in B trees. ACM TODS, vol. 6, no.1, March 1981, pp.174-183. M. A. Roth and H. F. Korth. The design of NF relational databases into nested normal form. In ACM SIGMOD International Conf. on Management of Data, 1987:143-159. M. A. Roth, H. F. Korth, and D. S. Batory. SQL/NF: A query language for 1NF relational databases. Information Systems 12(1):99-114. 1987. M. A. Roth, H. F. Korth, and A. Silberschatz. Extended algebra and calculus for 1NF relational databases. ACM Trans. on Database Syst. 13(4):389-417. 1988. F. Sandri and J. D. Ullman. Template dependencies: A large class of dependencies in the relational model and its complete axiomatization. Journal of the ACM 29(2):363372. 1982. Y. Sagiv. Can we use the universal instance assumption without using nulls? In ACM SIGMOD International Conf. on Management of Data, 1981:108-120. Y. Sagiv. A characterization of globally consistent databases and their correct access paths. ACM Trans. on Database Systems 8(2):266-286. 1983. Y. Sagiv. Evaluation of queries in independent database schemes. Journal of the ACM 38(1):120-161. 1991. H.-J. Schek. Towards a basic relational NF2 algebra processor. In Eleventh International Conference on Very Large Data Bases, Stockolm, 1985:173-182. H.-J. Schek, H. B. Paul, M. H. Scholl, and G. Weikum. The DASDBS project: Objectives, experiences, and future prospects. IEEE Trans. on Knowledge and Data Eng. 2(1):25-43. 1990. H.-J. Schek and P. Pistor. Data structures for an integrated database management and information retrival system. Eighth International Conf. on Very Large Data Bases, Mexico City, 1982.

186

Error! No text of specified style in document.

187

[312] [313] [314] [315] [316] [317] [318] [319] [320] [321] [322] [323] [324] [325] [326]

H.-J. Schek and M. H. Scholl. The relational model with relation-valued attributes. Information Systems, 11(2). 1986. E. Sciore. The Universal Instance and Database Design. Ph. D. diss. Princetown University (Dept. of EECS), 1980. E. Sciore. A complete axiomatization of full join dependencies. Journal of the ACM 29(2):373-393. 1982. D.W. Shipman. The Functional Data Model and the Data Language DAPLEX. ACM Trans. on Database Syst. 6(1): 140-173, 1981. A. Silberschatz, M. Stonebraker, and J. D. Ullman. Database systems: Achivements and opportunities. Communications of the ACM 34(10):110-120. 1991. J. M. Smith. A normal form for abstract syntax. In Fourth International Conf. on Very Large Data Bases, Berlin, 1978:156-162. J.M. Smith, S. Fox, and T. Landers. Reference Manual for ADAPLEX. Computer Corporation of America, 1981. J. M. Smith and D. P. C. Smith. Database abstractions: Aggregation and generalization. ACM Trans. on Database Syst. 2(2):105-133. 1977. J. M. Smith and D. P. C. Smith. Principles of Database Conceptual Design. In Database Design Techniques, Part I. Lect. Notes in Comp. Sci., 132, Springer-Verlag, 1982. N. Spyratos. The Partition Model: A Deductive Database Model. ACM ToDS, Vol. 12, No.1: 1-32, 1987. D. Srivastava, R. Ramakrishnan, S. Sudarshan, and P. Sheshadri. CORAL++; Adding Object-orientation to a Logic Database Language. In VLDB, 1993. P.M. Stocker, P.M.D. Gray, and M.P. Atkinson eds. Databases - Role and Structure. An Advanced Course. Cambridge University Press, 1984. M. Stonebraker, editor. The INGRES Papers. Reading, Mass.: Addison Wesley, 1986. M. Stonebraker. Future trends in database systems. IEEE Trans. on Knowledge and Data Eng. 1(1):33-44. 1989. Stonebraker, Michael. Object-Relational Database Systems. Illustra Information Technologies, (nedatat).

187

188

Error! No text of specified style in document.

[327] [328] [329] [330] [331]

[332] [333]

[334] [335] [336] [337] [338] [339] [340]

M. Stonebraker and G. Kemnitz. The Postgres nextgeneration database management system. Comm. of the ACM 34(10)78-93. 1991. Sybase. Whats New in SYBASE SQL Server Release 10.0?. Sybase, Doc. ID 36440-01-1000-04, May 1994. Tandem Computers. NonStop SQL, A Distributed, HighPerformance, High-Availability Implementation of SQL. Tech. Rep. 87.4, Tandem Computers, April 1994. T. J. Teorey and J. P. Fry. Database Design. Englewood Cliffs, N. J.: Prentice-Hall, 1982. J.W. Thatcher, E.G. Wagner, and J.B. Wright. Notes on Algebraic Fundamentals for Theoretical Computer Science. Reprint from J.W. de Bakker and J. van Leeuwen, eds., Found. of Comp. Sci. III, Part 2: Languages, Logic, Semantics, Mathematical Centre Tracts 109: 83-163, 1979. S. J. Thomas. A non-first-normal-form relational database model. Ph. D. diss. Vanderbilt University, Nashville, Tenn. 1983. S. J. Thomas and P. C. Fischer. Nested relational structures. In P. C. Kanellakis and F. P. Preparata, editors, Advances in Computing Research. Volume 3. Greenwich, Ct.: JAI Press, 1986, 269-307. R. Topor. Domain-independent formulas and databases. Theoretical Computer Science 52:281-306. 1986. D. Tsichritzis and F. H. Lochovski. Data Models. Englewood Cliffs, N. J.: Prentice-Hall, 1982. D.-M. Tsou and P. C. Fischer. Decomposition of a relation scheme into Boyce-Codd normal form. SIGACT News 14(3):23-29. 1982. Ullman, Jeffrey D. Principles of Database Systems. Computer Science Press, 1980. J. D. Ullman. Principles of Database Systems. 2nd ed. Potomac, Md.: Computer Science Press, 1982. J. D. Ullman. Principles of Database Systems. Potomac, Md.: Computer Science Press, 1982. J. D. Ullman. The U. R. strikes back. In ACM SIGACT SIGMOD Symp. on Principles of Database Systems, 1982:10-22.

188

Error! No text of specified style in document.

189

[341] [342] [343] [344] [345] [346] [347] [348] [349] [350] [351] [352] [353]

J. D. Ullman. On Kent's 'Consequences of assuming a universal relation'. ACM Trans. on Database Syst. 8(4):637643. 1983. J. D. Ullman. Implementation of logical query languages for databases. ACM Trans. on Database Syst. 10(3):289321. 1985. J. D. Ullman. Principles of Database and Knowledge Base Systems. Volume 1. Potomac, Md.: Computer Science Press, 1988. J. D. Ullman. Principles of Database and Knowledge Base Systems. Volume 2. Potomac, Md.: Computer Science Press, 1989. P. Valduriez and G. Gardarin. Analysis and Comparison of Relational Database Systems. Reading, Mass.: Addison Wesley, 1989. M. Y. Vardi. The decision problem for database dependencies. Information Processing Letters 12(5):251254. 1981. M. Y. Vardi. The Implication and finite implication problems for typed template dependencies. Journal of Comp. and System Sc. 28(1):3-28. 1984. M. Y. Vardi. Response to a letter to the editor. IEEE Software 5(4):4-6. 1988. M. Y. Vardi. The universal relation data model for logical independence. IEEE Software 5(2):80-85. 1988. Y. Vassiliou. Null values in database management: A denotational semantics approach. ACM SIGMOD International Conf. on Management of Data, 1979:162-169. Y. Vassiliou. A Formal Treatment of Imperfection in Database Management. Ph. D. diss. University of Toronto, 1980. Y. Vassiliou. Functional dependencies and incomplete information. In Sixth International Conf. on Very Large Data Bases, Montreal, 1980:260-269. Verso, J. (pen name for Verso team). Verso: A database machine based on non-1NF relations. Technical Report 523. INRIA, 1980.

189

190

Error! No text of specified style in document.

[354] [355] [356] [357] [358] [359] [360] [361] [362] [363] [364] [365] [366] [367]

L. Vielle. Recursive Axioms in Deductive Databases: The Query-Subquery Approach. In Proc. Int. Conf. on Expert DB Syst., 1986. L. Vielle. Database Complete Proof Production Based on SLD-resolution. In Proc 4th Int. Conf. on Logic Programming, 1987. L. Vielle. From QSQ towards QoSaQ: Global Optimization of Recursive Queries. In Proc. Int. Conf. on Expert DB Syst., 1988. K. Wang and M. H. Graham. Constant-time maintainability: A generalization of independence. ACM Trans. on Database Syst. 17(2):201-246. 1992. D. Warren. Memoing for Logic Programs. CACM, 35:3, ACM, march 1992. K. Whang, and S. Navathe. Integrating Expert Systems with DBMS - an Extended Disjunctive Normal Form Approach. In Information Sciences, 64, march 1992. K. Wilkinson, P. Lyngbaek, and W. Hasan. The IRIS architecture and implementation. IEEE Trans. on Knowledge and Data Eng. 2(1):63-75. 1990. E. Wong. A statistical approach to incomplete information in database systems. ACM Trans. on Database Syst. 7(3):470-488. 1982. M. Yannakakis and C. Papadimitriou. Algebraic dependencies. Journal of Comp. and System Sc. 21(1):2-41. 1982. C. Zaniolo. Analysis and Design of Relational Schemata for Database Systems. Ph. D. diss. UCLA, 1976. C. Zaniolo. Relational views in a database system; support for queries. In IEEE Int. Conference on Computer Software and Applications, 1977:267-275. C. Zaniolo. A new normal form for the design of relational database schemas. ACM Trans. on Database Syst. 7(3):489499. 1982. C. Zaniolo. Database relations with null values. Journal of Comp. and System Sc. 28(1):142-166. 1984. C. Zaniolo, editor. Special Issues on Databases and Logic. Data Engineering, 10(4). IEEE Computer Society, 1987.

190

Error! No text of specified style in document.

191

[368] [369] [370] [371] [372]

[373] [374] [375]

C. Zaniolo and M. A. Melkanoff. On the design of relational database schemata. ACM Trans. on Database Syst. 6(1):1-47. 1981. C. Zaniolo and M. A. Melkanoff. On the design of relational database schemata for database systems. ACM Trans. on Database Syst. 7(1):24-59. 1982. M. M. Zloof. Query-by-example: A database language. IBM Systems Journal 16(4):324-343. 1977. C. Manca. Modelarea conceptual a datelor. Tez de doctorat, Universitatea Politehnic Bucureti, Facultatea Automatic i Calculatoare, 1997. C. Manca. Normalizare versus corectitudinea modelrii conceptuale a datelor. Constrngeri tuplu de neocolit nici n Modelul Matematic Elementar al Datelor. In Proc. Conferinei de Informatic Teoretic i Tehnologii Informatice CITTI2000, 25-27 mai 2000, Constana, pp.207-216. V. Markovitz. ERROL An Entity-Relationship RoleOriented Language. Master thesis, Technion University, Haiffa, 1982. R. Barker. ORACLE CASE*Method Entity Relationship Modelling. Addison Wesley, 1990. R. Barker, C. Longman. ORACLE CASE*Method Function and Process Modelling. Addison Wesley, 1992.

191