Universitatea “Transilvania” din Braşov

Centrul de pregătire a Resurselor umane

Centrul Regional pentru Învăţământ Deschis la DistanţăSpecializarea: Informatică

BAZE DE DATE

Autor : Lector univ. dr. Paul IACOB

1

Conf. univ. dr. Mariana NEAGU

CUPRINS pag0. IntroducereAplicaţii tradiţionale bazate pe fişiere; limitări 31. Sisteme de Gestiune a Bazelor de Date (SGBD)

1. 1. Istoric,comentarii 51. 2. Definirea sistemelor de gestiune a bazelor de date relaţionale 61. 3. Regulile luiCodd 71. 4. Criterii minimale de definire a unui SGBDR 101. 5. Abstractizarea datelor 121. 6. Scheme, corespondenţe şi instanţe 141. 7. Independenţa datelor 151. 8. Principalele componente ale unui SGBD 151. 9. Obiectivele unui SGBD 181.10.Funcţiunile unui SGBD 20

2. Modele de descriere a datelor şi modelarea conceptuală2.1. Generalităţi, enumerări 252.2. Modelare E-R

2.2.1.Concepte de bază 272.2.2.Restricţii structurale 312.2.3. Chei 34

2.3. Modelul EE-R2.3.1. Problemele modelului E-R 352.3.2. Superclase şi subclase ale tipurilor de entitate 362.3.3. Specializarea 372.3.4. Generalizarea 382.3.5. Condiţii impuse specializării şi generalizării 38

3. Algebra relaţionala3.1. Structura relaţionala a datelor

3.1.1. Domeniu 383.1.2. Relaţie 393.1.3. Atribut 403.1.4. Operatorii modelului relaţional 41

3.2. Algebra relaţională şi extensiile sale 414. Limbaje de interogare comerciale (modelul relaţional) - SQL

4.1. Istoric, obiective 494.2. Clauze şi operatori SQL

4.2.1.Clauzele SELECT, FROM şi WHERE 504.2.2.Ordonarea tuplelor (clauza ORDER BY 554.2.3.Gruparea rezultatelor (clauza GROUP BY 564.2.4.Interogări pe mai multe tabele 584.2.5.Subinterogări 594.2.6.Operatorii ANY şi ALL 624.2.7.Operatorul EXISTS 64

2

5. Normalizarea5.1.Redundanţa informaţiilor şi anomalii de actualizare 665.2.Dependenţe funcţionale 695.3.Forme normale

5.3.1.Prima formă normală 725.3.2.A doua formă normală 745.3.3.A treia forma normală 765.3.4.Forma normală Boyce-Codd 76

6. Ghid de proiectare al bazelor de date relaţionale6.1. Metodologia

6.1.1. Metodologia proiectării bazelor de date 806.1.2. Prezentarea metodologiei 806.1.3. Crearea modelului logic 82

6.2. Proiectarea logică a bazei de date – Exemplu 986.3. Utilizarea metodologiei de proiectare a bazelor de date relaţionale 101

6.3.1. Anexa. Documentarea tipurilor de entităţi în view-urile Locatari şi Cheltuieli 1186.3.2. Anexa. Documentarea atributelor 1196.3.3. Anexa. Documentarea tipurilor de relaţii din view-urile “Locatari” şi “Cheltuieli 1206.3.4. Anexa. Documentarea domeniilor atributelor 1216.3.5. Anexa Descrierea relaţiilor din view-urile “Locatari” şi “Cheltuieli 1216.3.6. Anexa. Regulile date de întreprindere în cazul modelului “Locatari” şi “Cheltuieli 1226.3.7. Anexa. Modelul global de date al sistemului Asociaţia de Locatari 122

7. Baze de date distribuite7.1.Generaliăţi 1247.2.Arhitectura unui SGBD distribuit 1267.3.Proiectarea unei baze de date relaţionale distribuite 1297.4.Alocarea datelor 1307.5.Transparenţe în SGBDD 133

8. Securitate şi integritate8.1. Integritate 1428.2. Securitate 146

9. Tranzacţii şi concurenţă.9.1.Tranzacţii 1519.2. Proprietăţile tranzacţiilor 1529.3. Controlul concurenţei 1529.4. Tehnici optimiste 1589.5. Controlul recuperării 159

Test de autoevaluare 162

3

IntroducereAplicaţii tradiţionale bazate pe fişiere; limitări

Pentru o mai bună înţelegere a evoluţiei prelucrărilor de date vom rezerva câteva rânduri la începutul cursului nostru pentru o scurtă trecere în revistă a metodelor tradiţionale de prelucrare a masivelor de date, aşa-numitele siteme tradiţionale bazate pe fişiere.

În primii ani, calculatoarele erau utilizate mai ales pentru a duce la bun sfârşit calcule laborioase în care nu erau implicate cantităţi prea mari de date, aşa-numitele calcule ştiinţifice. Odată cu apariţia limbajelor de nivel înalt şi a posibilităţii stocării de mari cantităţi de informaţie pe suport magnetic adresabil (memorie externa) s-a pus şi problema eficientizării prelucrării acestora. De data aceasta nu calculele creşteau costul în timp al prelucrărilor ci manipularea datelor, respectiv regăsirea, actualizarea, etc. S-a constatat ca un factor important al creşterii eficienţei prelucrărilor este modul de organizare al informaţiilor. De aici şi până la a gândi sisteme unitare de reprezentare şi manipulare a masivelor de date n-a mai fost decât un pas.

Prima variantă de prelucrare a cantităţilor mari de informaţie s-a bazat pe organizarea datelor sub forma înregistrărilor în fişiere tradiţionale pe suport adresabil. În această variantă se elaborau programe de aplicaţie care defineau şi manipulau propriile date şi aveau în general ca scop elaborarea de rapoarte pentru diverşi beneficiari. Aceste programe au avut menirea de a înlocui prelucrarea sistemelor de fişiere manuale care mai funcţionează şi astăzi în unele locuri cum ar fi cabinetele medicale. Aşadar prelucrările oferite de un sistem tradiţional bazat pe fişiere copiau în mare masură metodele manuale de prelucrare. Evident că puterea de calcul şi memorare caracteristică sitemelor de calcul au făcut ca gama prelucrărilor să crească simţitor, la aceasta adăugându-se viteza şi siguranţa prelucrărilor.

Cu toate ca la momentul respectiv abordarea tradiţională bazată pe fişiere a fost un evident progres, putem să amintim aici şi o serie de limitări ale acestui sistem de prelucrare a datelor:

Separarea şi izolarea datelorDuplicarea datelorDependenţa datelorIncompatibilitatea fişierelorInterogări fixe / proliferarea aplicaţiilor

Comentăm pe scurt în continuare semnificaţia acestora.

Separarea şi izolarea datelor

Accesul la date care se află în fişiere diferite este dificil deoarece cade în sarcina programatorului să sincronizeze înregistrările din fişiere în aşa fel încât datele extrase să fie corecte.

Duplicarea datelor

4

În situaţia în care se realizează prelucrări descentralizate de date, pe compartimente, este posibil să fie necesară duplicarea datelor.

Totuşi duplicarea este de evitat din următoarele motive:

-necesită costuri mari în timp şi spaţiu de memorie.

-duce la pierderea integrităţii datelor. Datele nu mai sunt consistente, deci nu se mai poate conta pe ele.

Dependenţa datelor

Aşa cum am subliniat deja, structura fizică şi modul de memorare al datelor este definit în fiecare program de aplicaţie în parte. Este evident cât de dificile sunt schimbările în structura datelor. Toate programele trebuie ajustate la noua structură de date. O simplă modificare a lungimii unui câmp poate genera probleme. Dependenţa se referă aşadar la dependenţa program-date.

Incompatibilitatea fişierelor

Această limitare se trage tot din dependenţa de programe a structurii fişierelor. Structura fiind descrisă în programe ea depinde de limbajul de programare. De exemplu, structura unui fişier declarată într-un program COBOL diferă de structura unui fişier generat de un program C. Dacă e necesară prelucrarea de date din ambele fişiere, programatorul este obligat să scrie programe de conversie, pentru a aduce fişierele la un format comun posibil de prelucrat.

Interogări fixe / proliferarea aplicaţiilor

Deoarece prelucrarea masivelor de date a devenit mai uşoara şi mai rapida cu ajutorul calculatorului, beneficiarii au lărgit gama prelucrărilor lansând interogări noi sau modificând interogări mai vechi, pentru obţinerea de informaţii mai complexe. Orice interogare nouă sau orice modificare a unei interogări mai vechi se rezolvă în sistemele tradiţionale prin realizarea de noi programe de către programatorul de aplicaţie. Inutil de sublimiat cât de costisitoare sunt acestea. Un efect secundar era că se înmulţeau programele aplicaţiei şi de multe ori şi fişierele de prelucrat.

Întrebări recapitulative

1) În ce mod ajută calculatorul prelucrările de date?

2) Care sunt inconvenientele sistemelor de fişiere?

Raspusuri

1) Prelucrările de date pe calculator se fac mai rapid şi fără greşeli.

2) Sistemele de fişiere duc la :

- Duplicarea datelor

- Dependenţa datelor

- Incompatibilitatea fişierelor

- Interogări fixe / proliferarea aplicaţiilor.

5

Capitolul 1 Sisteme de Gestiune a Bazelor de Date (SGBD)

1.1. Istoric; comentarii

Evoluţia metodelor şi tehnicilor de organizare a datelor a fost determinată de necesitatea de a avea un acces cât mai rapid şi mai uşor la un volum din ce în ce mai mare de informaţii precum şi de perfecţionarea echipamentelor de culegere, memorare, transmitere şi prelucrare a datelor.

Există afirmaţii conform cărora sistemul de baze de date îşi are rădăcinile în anii '60, în proiectul de aselenizare Apollo. Deoarece pe atunci nu exista un astfel de sistem, North American Aviation (actualmente Rockwell International) a dezvoltat, în calitate de principal colaborator la proiect, un pachet de programe cunoscut sub numele GUAM (Generalized Update Access Method), care se baza pe date organizate în mod ierarhic. Modelul de date ierarhic îşi are originea în acest proiect.

La mijlocul anilor '60, un pas înapoi s-a facut prin elaborarea sitemului IMS (Information Management System), de către IBM în colaborare cu NAA, pornind de la sistemul GUAM. Pasul înapoi se datoreaza faptului că manipularea ierarhiilor de date a fost restrânsă la organizarea secvenţială a datelor (o cerinţă dictată de piaţa la acel moment).

In aceeaşi perioada General Electric a dezvoltat sistemul IDS (Integrated Data Store). Conducator de proiect: Charles Bachmann. Proiectul a condus la modelul de date reţea (numele se datoreaza ca şi în modelul precedent, modului de organizare a datelor).

În acea perioada se căuta eficientizarea manipulării datelor şi se încerca stabilirea unor standarde. În 1965 CODASYL (the Conference On DAta SYstems Languages) care reunise reprezentanţi ai guvernului USA şi reprezentanţi ai lumii afacerilor şi comerţului, a reuşit să stabilească un grup de lucru (care a avut iniţial numele List Processing Task Force) cunoscut din 1967 sub numele Data Base Task Group (DBTG). Sarcina acestui grup era să stabilească specificaţii cu rol de standarde pentru un mediu care ar permite crearea de baze de date şi manipularea datelor.

Conceptul de bază de date s-a definit în 1969 cu ocazia prezentării primului proiect de raport CODASYL (Raportul final s-a prezentat în 1971). Ideea principală în organizarea datelor se baza pe existenţa a trei componente de bază:

schema de reţea - care reprezenta organizarea logica a întregii baze de date

subschema - care reprezenta o parte a bazei de date aşa cum e vazută de utilizator sau de programele de aplicaţie

6

un limbaj de gestionare a datelor - care definea caracteristicile datelor, structura lor şi care manipula datele

Pentru standardizare, s-au propus trei limbaje:

un limbaj de definire a datelor (LDD) la nivel de schemă

un limbaj ător la nivel de subschemă

un limbaj de manipulare a datelor (LMD)

Cu toate că nu a fost adoptată formal de ANSI (American National Standard Institute) propunerea DBTG a fost aplicată într-o serie de sisteme dezvoltate ulterior şi ea stă la baza conceptului modern de bază de date.

Proiectul ierarhic şi cel prezentat de CODASYL reprezintă prima generaţie de Sisteme de Gestiune a Bazelor de Date (SGBD).

În 1978 E.F.Codd de la IBM Research Laboratory a elaborat o lucrare care a avut o influenţă covârşitoare în dezvoltarea bazelor de date. Lucrarea trata despre modelul de date relaţional.

De aici încolo s-au proiectat multe sisteme dintre care mentionam System R dezvoltat la IBM's San Jose Research Laboratory din California, la sfârşitul anilor '70. Acest proiect a dus la:

dezvoltarea unui limbaj structurat de interogare (numit SQL) care de atunci a devenit un standard pentru sistemele relaţionale;

producerea în anii '80 de sisteme comerciale arhicunoscute dintre care menţionăm: DB2 şi SQL/DS de la IBM şi ORACLE de la ORACLE Corporation.

Alte exemple de sisteme relaţionale: INGRES de la Relational Technology Inc., Informix de la Informix Sofware Inc., Sybase de la Sybase Inc.. Dintre sitemele relaţionale pentru microcalculatoare enumerăm aici: Paradox şi dBase IV de la Borland, Access de la Microsoft, FoxPro şi R:base de la Microrim. Toate acestea constituie generatia a doua de SGBD.

1.2. Definirea sistemelor de gestiune a bazelor de date relaţionaleÎntr-o primă încercare de definire, se poate considera un sistem de gestiune

a bazelor de date relaţionale (SGBDR) ca reprezentând un SGBD care utilizează drept concepţie de organizare a datelor modelul relaţional. Astfel spus, un SGDBR reprezintă un sistem care suportă modelul relaţional.

Definiţia de mai sus este prea generală pentru a putea fi operaţională, deoareca modul de implemantare a modelului relaţional diferă, de regulă atât între diferitele SGBDR, cât şi în raport cu modelul “ teoretic”, cel definit în cadrul teoriei relaţionale, datorită eforturilor producătorilor de a realiza sisteme cât mai perfomante care să satisfacă cerinţele şi exagerările utilizatorilor. Cât de aproape (sau de departe) de modelul relaţional teoretic trebuie să fie modelul datelor efectiv utilizat de SGBD pentru a putea afirma că SGBD-ul respectiv utilizează sau nu modelul relaţional, deci este sau nu SGBDR?

7

Diversitatea modelelor relaţionale operaţionale au determinat, în mod natural existanţa unei mari diversităţii de SGBDR, pentru a căror prezentare a fost necesară nuanţarea terminologiei. Au apărut o serie de sintagme precum: sisteme cu interfaţă relaţională, sisteme pseudorelaţionale, sisteme complet relaţionale.

Conceptele specifice organizăriidatelor în fişiere, SGBDR şi teoriei relaţionale între care se pot stabili analogii

Organizarea datelor în fişiere SGBDR Teoria relaţionalăFişier Tabelă RelaţieRecord(înregistrare) Linie Tuplu Câmp Coloană Atribut

În general, conceptele utilizate la prezentarea SGBDR şi a modelelor relaţionale operaţionale diferă de cele din cadrul teoriei relaţionale. Figura de mai sus prezintă comparativ conceptele organizării datelor în fişiere, concepte SGBDR şi ale teoriei relaţionale.

Faptul că se pot stabili analogii între conceptele organizării datelor în fişiere şi conceptele relaţionale, i-au determinat pe unii producători să prezinte sisteme fără nici o legătură cu modelul relaţional drept SGBDR, în scopul asigurării succesului comercial al acestor sisteme.

1.3. Regulile lui Codd

Definirea unui SGBDR impune o detaliere a caracteristicilor pe care trebuie să le prezinte un SGBD pentru a putea fi considerat relaţional.În acest sens, Codd a formulat 13 reguli care exprimă cerinţele pe care trebuie să le prezinte un SGBD ca să fie relaţional. Deşi reguli au stârnit o serie de controverse, eu le voi prezenta în continuare, ele fiind deosebit de utile în evaluarea unui SGBDR.

R0: Regula privind gestionarea datelor la nivel de relaţie

Sistemul trebuie să gestioneze baza de date numai prin mecanisme relaţionale.

Acest lucru înseamnă că sistemul trebuie să-şi îndeplinească toate funcţiile prin manipulări în care unitatea de informaţie să fie mulţimea (relaţia), adică să utilizeze limbaje, precum SQL, care să opereze la un moment dat pe o întreagă relaţie.Deci SGBD nu trebuie să accepte operaţii non-relaţionale care să îndeplinească operaţiile de definire şi manipulare a datelor.

Unele sisteme utilizează mecanisme releţionale numai pentru o parte din funcţii, în special pentru interogare. Aceste sisteme se numesc sisteme cu interfaţă relaţională ţi nu SGBDR.

R1: Regula privind reprezenterea logică a datelor

Toate datele din daza de date relaţională trebuie să fie reprezentate explicit la nivel logic, într-un singur mod, şi anume ca valori în tabele de date.

8

Aceste lucru înseamnă că toate datele trebuie să fie memorate şi prelucrate în acelaşi mod. Informaţiile privind numele de tabele,coloane, domenii, definiţiile tabelelor virtuale, restricţii de integritate trebuie să fie memotare tot în tabele de date (cataloage).

Referinţa la 'nivelul logic' înseamnă că construcţia fizică nu este reprezentată şi nu necesită explicaţie.

R2: Regula privind garantarea accesului la date.Orice dată din baza de date relaţională trebuie să poată fi accesată prin

specificarea numelui da tabelă, valorii cheii primare şi numelui de coloană.Această regulă exprimă cerinţa ca linbajul de cereri al SGBDR să

permită accesul la fiecare valoare atomică din baza de date.

R3: Regula privind valorile nullSistemele trebuie să permită declararea să manipularea sistematică a

valorilor null, cu semnificaţia unor date lipsă sau inaplicabile. Valorile null, care diferă de şirurile de caractere ' spaţiu' sau de şirurile vide da caractere sunt deosebit de importante în implementarea restricţiilor de integritate (integritatea entităţii şi integritatea refereanţială).

R4: Regula privind metedatele

Descrierea bazei de date trebuie să se prezinte la nivel logic în acalaşi mod cu descrierea datelor propiu-zise, astfel încât utilizatorii autorizaţi să poată descrierii bazei de date aceleaşi operaţii ca şi asupra datelor obijnuite.

Acestă regulă specifică că trebuie să existe un unic limbaj de manipulare a metedatelor şi a datelor propui-zise, mai mult, există o unică structură logică folosită pentru a depozita informaţiile de sistem.

Sisteme nu trebuie să facă diferenţieri în definirea şi tratarea datelor şia metadatelor, utilizând o singură structură, şi anume cea relaţionala.

R5: Regula privind facilitaţile limbajelor utilizate

Un sistem relaţional trebuie să facă posibilă utilizarea mai multor limbaje, în mai multe moduri. Trebuie să existe însă cel puţin un limbaj de nivel înalt ale cărui instrucţiuni să poată exprima oricare din următoarele operaţii: definirea tabelelor de date, definirea tabelelor virtuale, manipularea datelor (interactiv dau prin program), definirea restricţiilor de integritate, autorizarea accesului, precizarea limitelor tranzacţiilor.

A se nota aici că noul standard O/I pentru SQL furnizează toate aceste funcţii, deci orice limbaj care acceptă acest standard va satisface automat această regulă.

R6: Regula privind actualizarea tabelelor virtuale

Toate tabelele virtuale care teoretic sunt posibil de actualizat trebuie să poată fi efectiv actualizabile.

9

Nu toate atributele din cadrul unei tabele virtuale, deci nu toate tabele virtuale sunt toeretic actualizabile.

R7: Regula privind inserările, modificările şi ştergerile în baza de date

Sistemul trebuie să ofere posibilitatea manipulării unei tabele (da bază sau virtuală) nunumai în cadrul operaţiilor de regăsire, ci şi în acţiuni de inserare, modificare şi ştergere a datelor.

Această regulă exprimă cerinţa ca prin operaţiile în care se schimbă bazei da date să se lucreze la un moment dat pe o întreagă relaţie.

R8: Regula privind independenţa fizică a datelor

Programele de aplicaţie nu trebuie să fie afectate de schimbările efectuate în modul de reprezentare a datelor sau în metodele de acces. O schimbare a structurii fizice a datelor nu trebuie să blocheze funcţionarea programelor de alpicaţie.

R9: Regula privind independenţa logică a datelor

Programele de aplicaţie nu trebuie să fie afectate de schimbările efectuate asupra relaţiilor bazei de date, schimbări care conservă datele şi care toeretic garantează valabilitatea programelor de apicaţie existente.

R10: Regula privind restricţiile de integritate

Restrictiile de integritate trebuie să fie definite în limbajul utilizat de sistem pentru definirea datelor ţi să fie memorate în cadrul bazei de date şi nu în cadrul programului de aplicaţie.

R11: Regula privind distribuirea geografică a datelor

Limbajul de manipulare a datelor utilizat de sistem trebuie să permită ca, în situaţia în care datele sunt distribuite, programele de aplicaţie să fie logic aceleaşi cu cele utilizate în cazul în care datele sunt fizic centralizate.

Utilizatorul trebuie să perceapă datele ca fiind centralizate. Sarcina de localizare a datelor, atunci când acestea sunt distribuite geografic precum şi sarcina recompunerii datelor trebuie să revină sistemului şi nu utilizatorului.

R12: Regula privind prelucrarea datelor la nivelul de bază

Dacă sistemul posedă un limbaj de bază (de nivel scăzut) orientat pe prelucrare de recorduri (tupuri) şi nu pe prelucrarea mulţimiilor (relaţiilor), acest limbaj nu trebuie să fie utilizat pentru a se evitarestricţiile de integritate sau restricţiile introduse prin utilizarea limbajelor de nivel înalt, adică accesul la toate dazele va fi controlat de SGBDR, altfel integritate bazelor de date nu poate fi compromisă fără cunoaşterea utilizatorului sau a administratorului bazei de date.

Pe parcursul anilor regulile lui Codd au generat o seamă de controverse. Câteva argumente sunt că aceste reguli nu sunt mai mult decât nişte exerciţii academice.

10

Unele revendicări ale produselor existente sunt că ele pot indeplini cea mai mare parte din reguli, dar nu toate. Această discuţie a generat într-o dispută între utilizatori şi teoreticienii prietăţilor esenţiale ale unui SGBDR.

Pentru a accentua implicaţia regulilor lui Codd în analiza unum SGBDR, aceste reguli au fost reorganizate în cinci categorii, şi anume:

1) Reguli fundamentale,2) Reguli structurale,3) Reguli privind integritatea datelor,4) Reguli privind manipularea datelor,5) Reguli privind independenţa datelor.

1.4. Criterii minimale de definire a unui SGBDR

Nici unul dintre SGBDR disponibile astăzi nu respectă întrutotul cerinţele exprimate de Codd, în cadrul celor 13 reguli. De aceea pentru caracterizarea unui SGBD nu sunt utilizate regulile lui Codd, fiind formulate în schimb o serie de cerinţe minimale pa care trebuie să la satisfacă un sistem de gestiune a bazelor de date pentru a putea fi considerat releţional.

Un SGBD este minimal relaţional dacă satisface următoarela condiţii:1. Toate datele din cadrul relaţiei sunt reprezentate prin valori în tabele,2. Nu există pointeri observabili de către utilizatori în tabele, în sensul că

operaţiile cu releţii nu fac apel la pointeri, indecşi, fişiere inverse, etc.3. Sistemul suportă operatori relaţionali de proiecţie, selecţie şi joing natural,

fără limitări împuse de considerente interne (cum ar fi de exemplu, necesitetea indexării atributelor). Unitatea de informaţie ciu care se lucrează în cadrul acestor operaţii trebuie să fie relaţia.Un SGBD este complet relaţional dacă este minimal ralaţional şi satisface

în plus următoarele condiţii: 4. Sistemul suportă toate operaţiile de bază ale algebrei relaţionale, fără

limitări înpuse de considerente interne.5. Sistemul suportă două dintre restricţiile de integritate de bază al modelului

relaţional şi anume unicitatea cheii unei relaţiişi restricţia referenţială.

Un SGBD este pseudorelaţional dacă satisface numai condiţiile 1. şi 3. Un SGBD cu interfaţărelaţională este un SGBD are satisface condiţiile

1. şi 3., cu observaţia că cerinţa 3. Este îndeplinită numai în raport cu funcţia de interogare

În ultimii ani, ca răspuns la necesitatea de a creşte complexitatea aplicaţiilor cu baze de date (încurajată şi de progresele apărute în programare odata cu programarea orientata obiect) au apărut modelul de date orientat obiect (Object-Oriented Data Model - OODM) şi modelul de date relaţional extins (Extended Relational Data Model - ERDM). Cu toate ca modelul de date ce sta la baza noilor modele nu este atat de clar ca în cazul modelului relaţional, se

11

poate considera ca aceste din urma dezvoltari reprezinta generatia a treia de SGBD.

In esenta, conceptul de baza de date poate fi definit ca fiind o colectie partajata de date aflate în interdependenta logica (impreuna cu o descriere a acestor date şi a relatiilor dintre ele), colectie desemnata pentru a rezolva nevoia de informatizare a unei intreprinderi (sau organizatii).

Baza de date trebuie sa în deplineasca urmatoarele conditii:

-sa asigure o independenta sporita a datelor fata de programe şi invers;

-structura bazei de date trebuie astfel conceputa în cat sa asigure informatiile necesare şi suficiente pentru cerintele de informare şi decizie;

- sa asigure o redundanta minima şi controlata a datelor;

- sa permita accesul rapid la informatiile stocate în baza.

Bazele de date sunt extrem de variate în functie de criteriile luate în considerare. Prezentam cateva criterii de clasificare:

- dupa orientare: generalizate, specializate;

- dupa modelul de date: ierarhice, retele, relaţionale, orientate obiect;

- dupa amploarea geografica: locale, distribuite;

Numim SGBD (Sistem de Gestiune al Bazelor de Date) un sistem software care permite, pe de o parte, definirea, crearea şi în tretinerea bazei de date şi pe de alta parte, permite accesul controlat la informatiile din baza de date în cauza.

SGBD este format din programe de software care interactioneaza cu programele de aplicaţie ale utilizatorilor şi cu baza de date. Sistemul de gestiune al bazei de date asigura realizarea urmatoarelor activitati:

- definirea structurii bazei de date;

- în carcarea datelor în baza de date;

- accesul la date (interogare, actualizare);

- în tretinerea bazei de date (colectarea şi reutilizarea spatiilor goale, refacerea bazei de date în cazul unui incident);

- reorganizarea bazei de date (restructurarea şi modificarea strategiei de acces);

- integritatea datelor;

- securitatea datelor.

Asadar, sistemul de gestiune al bazei de date apare ca un sistem complex de programe care asigura interfata în tre o baza de date şi utilizatorii acestuia.

12

Clasificarea SGBD se poate realiza din mai multe puncte de vedere.

1. Din punctul de vedere al sistemelor de calcul pe care se implementeaza. SGBD pot fi: sisteme de gestiune pentru calculatoarele mari; sisteme de gestiune pentru minicalculatoare; sisteme de gestiune pentru microcalculatoare.

In prezent se manifesta tendinta ca marea majoritate a sistemelor de gestiune a bazelor de date sa fie compatibile pe platforme cat mai largi de sisteme de calcul.

2. Din punctul de vedere al limbajului pe care il utilizeaza, sunt: sisteme cu limbaj gazda; sisteme cu limbaj autonom.

Sistemele cu limbaj gazda realizeaza activitatile de creare, actualizare şi interogare a bazei de date, utilizand limbajele de nivel în alt sau extensii ale acestora, proprii sistemului de calcul pe care se implementeaza baza de date. Avantajul acestor sisteme consta în posibilitatile sporite ce le ofera limbajele de nivel în alt la elaborarea unor proceduri complexe. Sistemele cu limbaj gazda prezinta dezavantajul ca formularea cerintelor nu este atit de simplificata ca în cazul sistemelor cu limbaj autonom.

3. Din punctul de vedere al conceptiei de organizare a datelor pe care le gestioneaza, SGBD se clasifica în : sisteme de gestiune a bazelor de date cu structuri ierarhice şi retea; sisteme de gestiune a bazelor de date relaţionale; sisteme de gestiune a bazelor de date orientate obiect.

4. Din punctul de vedere al modului de localizare a bazelor de date avem: sisteme de gestiune a bazelor de date centralizate; sisteme de gestiune a bazelor de date distribuite.

Marea majoritate a sistemelor de gestiune apărute în ultima perioada dispun şi de o componenta de gestiune distribuita a datelor.

1.5. Abstractizarea datelor

Un scop important al unui sistem de gestiune a bazelor de date este sa poata asigura o viziune abstracta asupra realitatii. Este necesar sa se retina din multimea vasta de informatii doar acele informatii care sunt necesare unei anumite aplicaţii.

Se poate face referire spre exemplu la în cercarea de modelare a unei aplicaţii într-o intreprindere. Trebuie modelate 'obiectele' şi relatiile dintre ele. Nu realitatea complexa în totalitatea ei intra în discutie ci doar o mica parte a ei, constituita din anumite 'obiecte' şi pentru acele obiecte se iau în considerare doar o parte din caracteristici (acele caracteristici care sunt importante pentru aplicaţia în cauza). Astfel în cazul modelarii 'obiectului' (sau entitatii) angajat, trebuie alese doar acele proprietati (sau atribute) care intereseaza. Acestea ar putea fi, de exemplu: numele, adresa, salariul. O multime

13

impresionanta de informatii, care contribuie la descrierea unei persoane anume, nu sunt luate în seama, deoarece nu prezinta interes pentru intreprindere. De exemplu, nu intereseaza daca persoana are ochii albastri, daca este blonda sau bruneta, daca asculta cu placere muzica sau daca este o fire sentimentala.

Mai mult decat faptul ca realitatea este reprezentata codificat şi foarte simplificat, deoarece baza de date este o resursa partajata, este foarte probabil ca fiecare utilizator sa doreasca doar o parte din informatiile stocate, functie de aplicaţia pe care o dezvolta.

Pentru a se rezolva aceste cerinte, se apeleaza la reprezentarea pe nivele a organizarii informatiilor într-o baza de date. In general este acceptata arhitectura pe trei nivele ANSI-SPARC.

DBTG a propus în 1971 reprezentarea pe doua nivele a organizarii datelor (s-au utilizat .termenii de schema şi subschema). O arhitectura şi o terminologie asemanatoare au fost propuse de ANSI prin SPARC (Standards Planning And Requirements Committee) în 1975. S-au propus atunci trei nivele de abstractizare şi un dictionar de date.

Componentele bazei de date pot fi structurate pe trei nivele, în functie de clasa utilizatorilor implicati şi de viziunea asupra structurarii informatiei, dupa cum urmeaza:

- nivelul logic de vizualizare (view) sau nivelul extern. Este dat de viziunea programatorului de aplicaţii, care realizeaza programele de aplicaţii pentru manipularea datelor la nivel de structura logica (subschema) corespunzatoare descrierii datelor aplicaţiei;

-nivelul conceptual (global). Este dat de viziunea administratorului bazei de date, care realizeaza structura conceptuala (schema) corespunzatoare descrierii întregii baze de date şi administreaza componentele bazei de date. Acest nivel descrie ce date sunt memorate în baza de date şi ce relatii sunt stabilite între date. Nivelul conceptual reprezinta:

-toate entitatile, atributele lor şi relatiile dintre ele;

-restrictiile impuse datelor

-informatiile semantice despre date

-informatiile privitoare la securitatea şi integritatea datelor.

-nivelul fizic. Este dat de viziunea inginerului de sistem care realizeaza structura fizica corespunzatoare descrierii datelor pe suportul fizic (periferic). Acest nivel descrie cum sunt memorate datele în baza de date. Nivelul intern se ocupa de:

-alocarea spatiului de memorie pentru date şi indexi;

-descrierea înregistrarilor pentru memorare;

-plasarea înregistrarilor pe suport;

14

-tehnicile de compresie şi de criptare a datelor.

Figura 1.1. Arhitectura ANSI-SPARC pe trei nivele

1.6. Scheme, corespondente şi instante

Descrierea generala a unei baze de date se numeste schema bazei de date. Conform nivelelor de abstractizare a datelor exista trei tipuri de scheme pentru fiecare baza de date. La nivelul cel mai înalt exista (in general) mai multe scheme externe (numite şi subscheme) care descriu diferitele view-uri ale bazei de date. La nivelul conceptual exista schema conceptuala iar la nivelul cel mai de jos de abstractizare exista schema interna.

Pentru fiecare baza de date o singura schema conceptuala descrie datele şi relatiile între ele, precum şi restictiile de integritate. Schemei conceptuale ii corespunde o schema interna care descrie organizarea fizica a datelor.

SGBD realizeaza corespondenta între cele trei nivele de abstractizare, realizand corespondenta între cele trei tipuri de scheme. Astfel corespondenta conceptual / intern leaga schema conceptuala de schema interna. Datorita acestei corespondente se identifica înregistrarea sau combinatia de înregistrari

15

View 1 View 2 View n

Schemaconceptuala

Schema interna

Baza de date

Utilizator 1 Utilizator 2 Utilizator n

Nivel extern

Nivelconceptual

Nivel intern

Organizarea la nivel fizic a datelor

…..

la nivel fizic, care constituie înregistrarea logica în schema conceptuala, impreuna cu restrictiile de integritate corespunzatoare. Analog, fiecare schema externa este legata de schema conceptuala prin corespondenta extern / conceptual. Aceasta corespondenta permite SGBD sa faca legatura între numele din view-urile utilizator şi partea corespunzatoare relevanta din schema conceptuala.

Este de retinut ca trebuie sa facem distinctie între descrierea bazei de date (schema bazei de date) şi baza de date propriu-zisa.

Numim instanta (cazul) unei baze de date datele aflate în baza de date la un anumit moment dat. Altfel spus, mai multe instante pot sa corespunda aceleiasi scheme conceptuale pentru o baza de date.

1.7. Independenta datelor

Un obiectiv major al arhitecturii pe trei nivele de abstractizare este realizarea independentei datelor. O aplicaţie, în general, este dependenta de date în sensul ca modificarea structurii de memorare a datelor sau a strategiei de acces la date afecteaza şi aplicaţia. Independenta datelor fata de aplicaţie este totusi necesara cel putin din urmatoarele considerente:

-diferite aplicaţii au nevoie de viziuni diferite asupra acelorasi date;

-administratorul bazei de date trebuie sa aiba libertatea de a schimba structura de memorare sau strategia de acces, ca răspuns la cerinte (schimbari de standarde, prioritatile aplicaţiilor, unitatile de memorare etc.), fara a modifica aplicaţiile existente, baza de date existenta, precum şi programele de exploatare a ei, care au fost folosite o perioada de timp şi care reprezinta o investitie majora la care nu trebuie sa se renunte prea usor.

De aceea, se impune ca atunci cand apar noi cerinte în cadrul sistemului informational, sistemele informatice sa poata functiona cu programele şi procedurile existente, iar datele existente sa poata fi convertite.

Independenta datelor trebuie privita din doua puncte de vedere: independenta fizica şi independenta logica a datelor.

Independenta fizica a datelor face ca memorarea datelor şi tehnicile fizice de memorarea sa poata fi modificate fara a determina rescrierea programelor de aplicaţie. Asadar independenta fizica a datelor reprezinta gradul de imunitate a schemei conceptuale la schimbarile suferite de schema interna.

Independenta logica a datelor se refera la posibilitatea adaugarii de noi în înregistari sau la extinderea structurii conceptuale (globale), fara ca acest lucru sa impuna rescrierea programelor existente. Cu alte cuvinte independenta logica a datelor reprezinta gradul de imunitate a schemelor externe la schimbarile suferite de schema conceptuala.

16

1.8. Principalele componente ale unui SGBD

Tinand seama de faptul ca exista diferite tipuri de sisteme de gestiune, care se diferentiaza:

-prin limbajele utilizate,

-prin anumite componente ce imprima diferite facilitati de exploatare a bazei de date,

-si prin faptul ca unele ofera posibilitatea lucrului în regim de teleprelucrare, altele numai în regim local, iar altele atat în regim local cat şi în regim de teleprelucrare,

ajungem la concluzia ca nu poate fi stabilita o arhitectura unica, valabila pentru toate sistemele, ci apar particularitati de la un sistem la altul.

Arhitectura unui SGBD evidentiaza componentele acestuia şi urmeaza standarde internationale. O astfel de arhitectura generala cuprinde urmatoarele componente:

- baza de date propriu-zisa în care se memoreaza colectia de date;

- sistemul de gestiune al bazei de date, care este un asamblu de programe (soft) care realizeaza gestiunea şi prelucrarea complexa a datelor;

- un set de proceduri manuale şi automate, precum şi reglementarile administrative, destinate bunei functionari a întregului sistem;

- un dictionar al bazei de date (metabaza de date), ce contine informatii despre date, structura acestora, elemente de descriere a semanticii, statistici, documentatie etc.

- mijloacele hard utilizate (comune, specializate etc.);

- personalul implicat: (categorii de utilizatori: finali - (neinformaticieni); de specialitate (administrator), analisti - programatori, gestionari, operatori).

Arhitectura bazei de date da o imagine despre modul general de organizare şi functionare a ei.

Sa detaliem cateva din componentele prezentate mai sus.

Limbajele untilizate într-un SGBD sunt de doua tipuri: Limbajul de definire a datelor (Data Definition Language - DDL) şi Limbajul de manipulare a datelor (Data Manipulation Language - DML). Aceste limbaje mai sunt cunoscute ca sublimbaje de date deoarece ele nu includ constructii adecvate oricaror necesitati de calcul, asemanatoare cu structurile puse la dispozitie de limbajele de nivel înalt.

Multe SGBD au facilitatea de a incorpora sublimbajul într-un limbaj de nivel înalt (numit limbaj gazda) cum ar fi COBOL, Fortran, Pascal, Ada, C. Pentru compilare, comenzile sublimbajului sunt înlocuite în limbajul gazda cu apeluri de functii. Fisierul preprocesat este compilat, plasat într-un modul obiect, link-

17

editat cu o biblioteca în care se afla functiile înlocuite, furnizate odata cu SGBD, şi este executat cand este necesar.

Limbajul de Definire a Datelor (LDD) este un limbaj descriptiv care permite administratorului bazei de date sau utilizatorilor sa descrie şi sa denumeasca entitatile şi relatiile care se pot stabili între acestea.

Schema bazei de date este definita cu ajutorul LDD. Rezultatul compilarii declaratiilor în acest limbaj este constituit dintr-o serie de tabele memorate într-un fisier special numit dictionar de date (se mai utilizeaza şi termenii de catalog de date sau director de date). Datele memorate în acest dictionar sunt date despre date şi de aceea se mai numesc şi metadate. Definitiile din dictionarul de date se refera la înregistrari, la datele din înregistrari şi la alte obiecte ce compun baza de date. SGBD consulta dictionarul de date înaintea oricarui acces la informatii.

Teoretic, se poate identifica cate un LDD pentru fiecare nivel de abstractizare al datelor, în realitate exista un singur limbaj care trateaza toate aspectele definirii datelor.

Limbajul de manipulare a datelor (LMD) furnizeaza un set operatii care suporta operatiile de manipulare de baza asupra datelor din baza de date. Operatii de baza sunt inserarea, stergerea, modificarea şi regasirea datelor în baza de date. Manipularea datelor se aplica la nivel conceptual şi extern.

Se cunosc doua tipuri de LMD: procedural şi non-procedural. Un LMD procedural trateaza înregistrarile individual şi specifica cum trebuie obtinut rezultatul unei interogari. Cu alte cuvinte trebuie sa se specifice un algoritm de prelucrare a înregistrarilor cu ajutorul operatiilor puse la dispozitie de limbaj.

In contrast, un LMD non-procedural specifica doar ce fel de rezultat trebuie obtinut. SGBD translateaza cererea din limbaj non-procedural transformand-o într-o procedura sau într-o serie de proceduri care manipuleaza datele conform cererii utilizatorului. Limbajele non-procedurale sunt mai usor de utilizat deoarece scutesc utilizatorii de la a cunoaste implementarea interna a structurilor de date şi de la a stabili algoritmi de obtinere a informatiilor.

Partea componenta a unui LMD care se refera la regasirea datelor se numeste limbaj de interogare. Intelegem prin interogare orice cerere de acces la datele din baza de date, formulata într-un limbaj de interogare.

4GL

4GL înseamna Fourth-Generation Language (Limbaj de Generatia a Patra). Nu exista înca un consens asupra semnificatiei acestei denumiri. In general 4GL desemneaza un limbaj de programare de mare rapiditate pentru programator. Ceea ce se programeaza în sute de linii de program într-un limbaj de generatia a treia, poate sa constituie cateva zeci de linii de program într-un limbaj de generatia a patra. Limbajele 4GL sunt non-procedurale şi se bazeaza pe tools-uri performante. Utilizatorul trebuie sa defineasca parametri pentru aceste tools-uri iar acestea genereaza programe de aplicaţie pe baza parametrilor

18

respectivi. Un avantaj important al utilizarii limbajelor 4GL este o productivitate deosebita în programare.

Un 4GL cuprinde:

-limbaje de interogare;

-generatoare de ecrane;

-generatoare de rapoarte;

-limbaje specializate cum ar fi spreadsheet-urile şi limbajele specifice bazelor de date;

-generatoare de aplicaţii, etc.

Exemple de limbaje de interogare 4GL sunt SQL şi QBE, limbaje comerciale asupra carora vom reveni ulterior.

Generatoare de ecrane

Un generator de ecrane este un tool cu ajutorul caruia se pot crea usor şi rapid ecrane pentru culegerea (introducerea) informatiilor necesare programelor sau chiar pentru introducerea şi modificarea datelor din baza de date.

Generatoare de rapoarte

Un generator de rapoarte ajuta la crearea de rapoarte (liste) pornind de la datele memorate în baza de date. Se cunosc doua tipuri de generatoare de rapoarte: orientat pe limbaj şi orientat visual. In primul caz se utilizeaza comenzile unui sublimbaj pentru a defini datele ce se vor include în raport, în al doilea caz, acelasi lucru se realizeaza cu ajutorul unei facilitati grafice similare cu generatorul de ecrane.

Generatoare de grafice

Un astfel de generator este o facilitate care regaseste date din baza de date şi afiseaza aceste date sub forma unor grafice.

Generatoare de aplicaţii

Utilizarea unui generator de aplicaţii poate reduce timpul necesar realizarii unei aplicaţii unitare. Generatoarele de aplicaţii constau în module predefinite care cuprind majoritatea functiilor de baza ce sunt prezente în majoritatea programelor. Aceste module constituie o biblioteca de functii la dispozitia utilizatorilor.

1.9. Obiectivele unui SGBD

Dupa cum este cunoscut, obiectivul informaticii il constituie culegerea, verificarea, transmitarea, stocarea şi prelucrarea automata a datelor cu ajutorul mijloacelor electronice de calcul, în scopul satisfacerii diferitelor nivele de conducere cu informatii necesare luarii deciziilor, în conditii de eficienta economica sporita.

19

In aceste conditii, necesitatea acuta de informare trebuie satisfacuta tinand seama de o serie de cerinte prin care sa se asigure:

-minimizarea costului procesului de prelucrare a datelor; creşterea vitezei de răspuns la întrebarile solicitate de utilizatori;

-adaptarea facila a sistemului informatic la evolutia in timp a sistemului informational din care face parte;

-posibilitatea răspunsului la anumite intrebari neanticipate de catre proiectantii de sistem;

-posibilitatea folosirii sistemului de informare dispunand de un minim de cunostinte despre modul lui de organizare in general şi despre informatica in special;

-integritatea şi securitatea datelor etc.

In acest context, sistemului de gestiune al bazei de date ii revin o serie de obiective, cum sunt:

1. Asigurarea independentei datelor.

Asa cum am aratat mai devreme, acest obiectiv consta in linii mari din indeplinirea urmatoarei cerinte: modificarile care se fac la un anumit nivel de structura de date nu trebuie sa fie 'vizibile' la nivelul de organizare imediat superior.

2. Asigurarea unei redundante minime şi controlate a datelor din baza de date.

Spre deosebire de sistemele clasice de prelucrare automata a datelor, stocarea datelor in cazul bazelor de date se face astfel incat, pe cat posibil, fiecare informatie sa apara o singura data. Totusi, nu sunt excluse nici cazurile in care, pentru a realiza performante sporite (mai ales in ce priveste timpul de acces la date şi implicit, timpul de răspuns la solicitarile utilizatorilor) sa se accepte o anumita redundanta a datelor. In acest caz se va institui insa un control automat al redundantei in vederea asigurarii coerentei datelor din baza.

3. Asigurarea unor facilitati sporite de utilizare a datelor. Aceasta presupune:

- folosirea datelor de catre mai multi utilizatori in diferite scopuri (aplicatii);

- accesul cat mai simplu al utilizatorilor la date, fara ca acestia sa fie nevoiti sa cunoasca structura intregii baze de date, acest lucru ramanand in sarcina administratorului bazei de date;

- existenta unor limbaje performante de regasire a datelor, care permit exprimarea cu usurinta a criteriilor de selectie a datelor şi indicarea unor reguli cat mai generale pentru editarea informatiilor solicitate;

- spre deosebire de sistemul traditional bazat pe fisiere, unde exista un singur criteriu de adresare (cel care a stat la baza organizarii fisierului) in

20

cazul bazelor de date, sistemul de gestiune trebuie sa ofere posibilitatea unui acces multicriterial, fara sortari suplimentare. Modificarea criteriului la fisierele clasice implica in majoritatea cazurilor reorganizarea lor;

- utilizarea unui limbaj cat mai apropiat de limbajul natural, cu posibilitatea exploatarii bazei de date in regim conversational. Aceasta ar oferi posibilitatea exploatarii in mod facil a bazei de date şi de catre utilizatorii neinformaticieni.

4. Sporirea gradului de securitate a datelor impotriva accesului neautorizat la ele. Administratorul bazei de date poate prevedea ca accesul la baza de date sa se faca numai prin canale corespunzatoare, şi poate, totodata, defini verificari de autorizare care sa se realizeze oricand se incearca accesul la anumite date.

5. Asigurarea integritatii datelor impotriva unor stergeri intentionate sau neintentionate, prin intermediul unor proceduri de validare, a unor protocoale de control concurent şi a unor proceduri de refacere a bazei de date dupa incidente.

6. Asigurarea partajabilitatii datelor. Partajabilitatea datelor trebuie inteleasa nu numai sub aspectul asigurarii accesului mai multor utilizatori la aceleasi date, ci şi acela al posibilitatii dezvoltarii unor aplicaţii fara a se modifica structura bazei de date.

1.10. Functiile unui SGBD

Sistemele de gestiune a bazelor de date dispun de o serie de componente ce permit efectuarea numeroaselor operatii necesare functionarii optime a sistemului. In functie de natura lor şi de scopul urmarit, operatiile pot fi grupate pe activitati. Activitatile accepta şi ele o grupare pe functii (una sau mai multe activitati, relativ omogene, realizeaza o anumita functie).

Tinand seama de complexitatea sistemului de gestiune, de facilitatile oferite de acesta, de limbajele utilizate şi de tipul bazei de date ce urmeaza a fi gestionata de SGBD, gruparea activitatilor pe functii are un oarecare caracter relativ. In situatia sistemelor de gestiune ce utilizeaza limbaje gazda de nivel inalt, identificarea şi delimitarea functiilor nu este atat de evidenta.

Totusi, in ciuda acestor particularitati, se pot prezenta cateva functii cu caracter de generalitate pentru toate sistemele de gestiune a bazelor de date şi anume:

1. Functia de descriere a datelor permite definirea structurii bazei de date cu ajutorul limbajului de definire. Definirea datelor poate fi realizata la nivel logic, conceptual şi fizic.

Aceasta functie asigura:

-descrierea atributelor (campurilor) din cadrul structurii bazei de date,

21

-descrierea legaturilor dintre entitatile bazei de date sau dintre atributele aceleiasi entitati,

-definirea eventualelor criterii de validare a datelor,

-definirea metodelor de acces la date,

-definirea aspectelor referitoare la asigurarea integritatii şi confidentialitatii datelor, etc.

Toate acestea se concretizeaza in schema bazei de date, memorate in cod intern.

2. Functia de manipulare a datelor este cea mai complexa functie şi realizeaza urmatoarele activitati:

- crearea (incarcarea) bazei de date;

- adaugarea de noi inregistrari;

- stergerea unor inregistrari;

- modificarea valorilor unor campuri;

- cautarea, sortarea şi editarea partiala sau totala a unei inregistrari virtuale etc.

Functia de manipulare a datelor se realizeaza prin intermediul limbajului de manipulare a datelor.

3. Functia de utilizare asigura multimea interfetelor necesare pentru comunicarea tuturor utlizatorilor cu baza de date. Sunt recunoscute mai multe categorii de utilizatori:

- utilizatori "liberi" sau conversationali. Aceastia reprezinta categoria beneficiarilor de informatii (utilizatori finali) care utilizeaza limbajele de interogare a bazei de date intr-o forma simplista. Ei apar ca utilizatori neinformaticieni;

- utilizatori programatori, care utilizeaza limbajele de manipulare, realizand proceduri complexe de exploatare a bazei de date;

- administratorul bazei de date apare ca un utilizator special şi are rolul hotarator in ceea ce priveste functionarea optima a intregului ansamblu.

4. Functia de administrare a bazei de date apare ca o functie complexa şi este de competenta administratorului bazei de date.

Întrebări recapitulative.

1) Enumeraţi momentele importante ale naşterii bazelor de data.

2) Daţi definiţia bazei de date.

3) Daţi definiţia SGBD-ului.

4) Ce înseamnă arhitectura ANSI-SPARC pe trei nivele?

5) Ce esste independenţa fizică a datelor?

22

6) Ce esste independenţa logică a datelor?

7) Care sunt componentele unui SGBD?

8) Care sunt obiectivele unui SGBD?

9) Care sunt functiunile unui SGBD?

Răspunsuri la întrebări.

1) Exista afirmatii conform carora sistemul de baze de date isi are radacinile in anii '60, in proiectul de aselenizare Apollo. North American Aviation a dezvoltat un pachet de programe cunoscut sub numele GUAM, care se baza pe date organizate in mod ierarhic. In aceeasi perioada General Electric a dezvoltat sistemul IDS (Integrated Data Store). Proiectul a condus la modelul de date retea. Conceptul de baza de date s-a definit in 1969 cu ocazia prezentarii primului proiect de raport CODASYL. Ideea principala in organizarea datelor se baza pe existenta a trei componente de baza:

schema de reţea - care reprezenta organizarea logică a intregii baze de date

subschema - care reprezenta o parte a bazei de date aşa cum e vazută de utilizator sau de programele de aplicaţei

un limbaj de gestionare a datelor - care definea caracteristicile datelor, structura lor şi care manipula datele.

In 1978 E.F.Codd de la IBM Research Laboratory a elaborat o lucrare care a avut o influenta covarsitoare in dezvoltarea bazelor de date. Lucrarea trata despre modelul de date relaţional.

În anul 1970 a început dezvoltarea unui limbaj structurat de interogare (numit SQL) care de atunci a devenit un standard pentru sistemele relaţionale.

2) Baza de date poate fi definită ca fiind o colecţie partajată de date aflate în interdependenţă logică colecţie desemnată pentru a rezolva nevoia de informatizare a unei intreprinderi (sau organizaţii).

3) Numim SGBD (Sistem de Gestiune al Bazelor de Date) un sistem software care permite, pe de o parte, definirea, crearea şi intreţinerea bazei de date şi pe de alta parte, permite accesul controlat la informaţiile din baza de date în cauză.

4) Componentele bazei de date pot fi structurate pe trei nivele, in functie de clasa utilizatorilor implicati şi de viziunea asupra structurarii informatiei, dupa cum urmeaza:

- nivelul logic de vizualizare (view) sau nivelul extern. Este dat de viziunea programatorului de aplicaţii, care realizează programele de aplicaţii pentru manipularea datelor la nivel de structura logica (subschema) corespunzatoare descrierii datelor aplicaţiei;

-nivelul conceptual (global). Este dat de viziunea administratorului bazei de date, care realizeaza structura conceptuală (schema) corespunzatoare descrierii

23

intregii baze de date şi administrează componentele bazei de date. Acest nivel descrie ce date sunt memorate în baza de date şi ce relaţii sunt stabilite intre date. Nivelul conceptual reprezintă:

-toate entităţile, atributele lor i relaţiile dintre ele;

-restricţiile impuse datelor

-informaţiile semantice despre date

-informaţiile privitoare la securitatea şi integritatea datelor.

-nivelul fizic. Este dat de viziunea inginerului de sistem care realizeaza structura fizică corespunzatoare descrierii datelor pe suportul fizic (periferic). Acest nivel descrie cum sunt memorate datele în baza de date.

5) Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de memorarea să poată fi modificate fără a determina rescrierea programelor de aplicaţie. Aşadar independenţa fizică a datelor reprezinta gradul de imunitate a schemei conceptuale la schimbarile suferite de schema internă.

6) Independenţa logică a datelor se refera la posibilitatea adaugării de noi înregistari sau la extinderea structurii conceptuale (globale), fără ca acest lucru să impună rescrierea programelor existente. Cu alte cuvinte independenţa logică a datelor reprezinta gradul de imunitate a schemelor externe la schimbările suferite de schema conceptuală.

7) Arhitectura unui SGBD evidenţiază componentele acestuia şi urmează standarde internaţionale. O astfel de arhitectură generală cuprinde urmatoarele componente:

- baza de date propriu-zisă în care se memorează colecţia de date;

- sistemul de gestiune al bazei de date, care este un asamblu de programe (soft) care realizează gestiunea şi prelucrarea complexă a datelor;

- un set de proceduri manuale şi automate, precum şi reglementările administrative, destinate bunei funcţionări a întregului sistem;

- un dicţionar al bazei de date (metabaza de date), ce conţine informaţii despre date, structura acestora, elemente de descriere a semanticii, statistici, documentaţie etc.

- mijloacele hard utilizate (comune, specializate etc.);

- personalul implicat: (categorii de utilizatori: finali - (neinformaticieni); de specialitate (administrator), analişti - programatori, gestionari, operatori).

8) Bazei de date îi revin o serie de obiective, cum sunt:

-Asigurarea independenţei datelor.

-Asigurarea unei redundanţe minime şi controlate a datelor din baza de date.

24

- Asigurarea unor facilităţi sporite de utilizare a datelor

- Sporirea gradului de securitate a datelor împotriva accesului neautorizat la date.

-Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate, prin intermediul unor proceduri de validare, a unor protocoale de control concurent şi a unor proceduri de refacere a bazei de date după incidente.

-Asigurarea partajabilitatii datelor. Partajabilitatea datelor trebuie inţeleasă nu numai sub aspectul asigurarii accesului mai multor utilizatori la aceleaşi date, ci şi acela al posibiliăţtii dezvoltarii unor aplicaţii fără a se modifica structura bazei de date.

9) Funcţiile unui SGBD

1. Funcţia de descriere a datelor permite definirea structurii bazei de date cu ajutorul limbajului de definire. Definirea datelor poate fi realizată la nivel logic, conceptual şi fizic.

Aceasta funcţie asigură:

-descrierea atributelor (câmpurilor) din cadrul structurii bazei de date,

-descrierea legăturilor dintre entităţile bazei de date sau dintre atributele aceleiasi entităţi,

-definirea eventualelor criterii de validare a datelor,

-definirea metodelor de acces la date,

-definirea aspectelor referitoare la asigurarea integrităţii şi confidenţialităţii datelor, etc.

2. Funcţia de manipulare a datelor este cea mai complexă funcţie şi realizează urmatoarele activităţi:

- crearea (incarcarea) bazei de date;

- adaugarea de noi inregistrări;

- ştergerea unor inregistări;

- modificarea valorilor unor câmpuri;

- căutarea, sortarea şi editarea parţială sau totală a unei inregistrări virtuale etc.

3. Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor utlizatorilor cu baza de date. Sunt recunoscute mai multe categorii de utilizatori:

- utilizatori "liberi" sau conversaţionali. Aceaştia reprezintă categoria beneficiarilor de informaţii (utilizatori finali) care utilizează limbajele de interogare a bazei de date intr-o formă simplistă. Ei apar ca utilizatori neinformaticieni;

25

- utilizatori programatori, care utilizează limbajele de manipulare, realizând proceduri complexe de exploatare a bazei de date;

- administratorul bazei de date apare ca un utilizator special şi are rolul hotarâtor în ceea ce priveşte funcţionarea optimă a întregului ansamblu.

3. Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de competenţa administratorului bazei de date.

Capitolul 2Modele de descriere a datelor

2.1. Generalitati

Numim model de date o colectie integrata de concepte pentru descrierea datelor, de relatii intre date şi de restrictii asupra datelor, toate intr-o organizare unitara.

Un model de date este o abstractie, o reprezentare a 'lumii reale' cu evidentierea caracteristicilor esentiale care descriu atat 'obiectele' cat şi relatiile dintre acestea. Un model de date are in principal rolul de a furniza conceptele de baza şi notatiile care sa permita proiectantilor şi utilizatorilor bazei de date sa comunice in mod neambiguu şi acurat legat de modul de organizare a datelor.

Un model de date cuprinde trei parti:

(1) o parte referitoare la structura, care consta intr-un set de reguli ce impun modul de alcatuire a bazei de date;

(2) o parte referitoare la manipularea datelor, care defineste tipul de operatii care sunt permise asupra datelor. Sunt incluse aici operatiile care sunt utilizate pentru a actualiza sau a regasi datele in baza de date precum şi operatiile pentru schimbarea structurii bazei de date;

(3) o parte referitoare la integritatea datelor, parte care cuprinde reguli de integritate care asigura acuratetea datelor.

Modele de date se pot realiza pentru fiecare nivel de abstractizare. Astfel putem vorbi de:

model extern de date (care reprezinta asa-numitul univers al discursului, adica punctul de vedere al utilizatorului);

model de date conceptual (care reprezinta structura logica a bazei de date, independenta de sitemul de gestiune ales);

model de date intern (care reprezinta schema conceptuala intr-un mod in care poate fi perceputa de SGBD).

Dintre diversele modele propuse in literatura de specialitate mentionam aici: modelele de date bazate pe obiecte, modelele de date bazate pe inregistrare,

26

ambele modele fiind utilizate pentru descrierea organizarii datelor la nivel extern şi conceptual. Trebuie sa mentionam şi modelele fizice de date, care descriu datele la nivel intern.

Modele de date bazate pe obiecte

Aceste modele utilizeaza concepte specifice modelului E-R prezentat in Sectiunea 2.2. şi anume: entitati, atribute, relatii. Cele mai cunoscute modele de date sunt: modelul entitate-relatie, modelul semantic, modelul functional, modelul orientat obiect.

Modele de date bazate pe inregistrare

Intr-un astfel de model baza de date consta dintr-un numar de inregistrari de format fix de tipuri eventual diferite. Fiecare tip de inregistrare defineste un numar fix de campuri, fiecare fiind in general de lungime fixa. Exista trei tipuri importante de modele de date bazate pe inregistrare: modelul de date relaţional, modelul de date retea şi modelul ierarhic de date.

Modelele ierarhic şi retea au fost dezvoltate mai intai, modelul relaţional aparand cu o intarziere de un deceniu.

Modele fizice de date

Aceste modele descriu efectiv modul in care datele sunt memorate in calculator, la nivel fizic. Informatia furnizata de aceste modele este cea referitoare la inregistarile fizice, la cai de acces, la organizarea inregistrarilor, etc.

Se considera ca schema conceptuala sta la baza structurarii unei baze de date. O schema conceptuala completa şi bine gandita permite o reprezentare interna eficienta şi permite realizarea de view-uri utilizator fara dificultate.

Modelarea conceptuala sau proiectarea conceptuala a bazei de date este procesul de construire a unui model care sa reprezinte modul in care este utilizata informatia de catre beneficiar, reprezentare care este independenta de detaliile de implemetare cum ar fi programele de aplicaţie, limbajele de programare, SGBD-ul utilizat sau orice alte consideratii fizice. Un astfel de model se numeste model de date conceptual sau model logic. Unii autori fac diferenta intre cele doua denumiri in sensul ca se considera ca modelul de date conceptual este intr-adevar independent de orice detalii fizice, pe cand modelul logic presupune cunoasterea modelului de date ce sta la baza SGBD-ului ce urmeaza a fi utilizat. In Capitolul 6 se va expune metodologia obtinerii unui model logic bazat pe modelul de date relaţional.

2.2. Modelare E-R (Entity-Relationship)

Modelul E-R (Entity-Relationship) este un model conceptual de nivel înalt, dezvoltat de Chen în 1976. Primele idei legate de utilizarea modelului E-R la proiectarea unei baze de date au fost expuse de Chen (1977) şi au fost

27

continuate de Sakai (1980). Conceptele de specializare şi generalizare au fost introduse de Smith şi Smith (1977) şi au fost utilizate ulterior de Lenzerini şi Santucci (1983) la definirea restrictiilor de cardinalitate. Modelul E-R constituie un mod de reprezentare a bazelor de date relaţionale şi de aceea este un instrument util in proiectarea acestora. În acest capitol, vom descrie conceptele primare care stau la baza modelului E-R, după care vom identifica problemele care pot apărea prin utilizarea unui astfel de model. Vom discuta de asemenea problemele generate prin utilizarea modelul E-R la reprezentarea unor aplicaţii. Având în vedere limitele modelului E-R, vom discuta un model mai complex, modelul EE-R şi conceptul principal asociat acestuia, conceptul de specializare/generalizare.

2.2.1. Concepte de baza

Conceptele primare ale modelului E-R includ : tip de entitate (multime-entitate), tip de relaţie (multime-relatie), atribute.

Numim entitate un obiect sau un concept ce se poate identifica in mod unic.

Notiunea de entitate este un concept de baza in cadrul modelului E-R. Ea reprezinta 'obiecte' concrete (cu existenta fizica) sau abstracte (cu existenta conceptuala).

Exemplu: Popescu Ion, posesor al buletinului de identitate seria ABC, numarul: 444555 este o entitate deoarece identifica in mod unic o persoana in acest univers. O entitate care reprezinta un obiect ceva mai abstract poate fi, de exemplu, un cont la banca identificabil in mod unic prin numarul sau şi numele bancii.

Numim tip de entitate sau multime-entitate un set de entitati de acelasi tip.

Exemplu: Multimea tuturor persoanelor care sunt studenti ai Facultatii de Stiinte pot defini multimea-entitate sau tipul de entitate student.

Tipul de entitate reprezintă o multime de 'obiecte' ce apartin lumii reale şi care sunt descrise de aceleasi proprietati.

Orice obiect care apartine unui tip de entitate şi care este identificabil in mod unic este numit simplu entitate. (se mai intalnesc denumirile: aparitia unei entitati sau instanta unei entitati). Un tip de entitate conţine mai multe entităţi. O baza de date este o colectie de tipuri de entitate din care fiecare contine un numar neprecizat de entitati de acelasi tip.

Tipurile de entitate nu sunt neaparat disjuncte. Aceasta inseamna ca pot exista entitati care sa apartina mai multor tipuri de entitate.

Exemplu: Se pot defini urmatoarele tipuri de entitate: profesor, corespunzator tuturor cadrelor didactice ale Facultatii de Stiinte şi student, corespunzator tuturor studentilor aceleiasi facultati. Se observa usor ca pot exista studenti care sunt in acelasi timp şi cadre didactice (studenti la master care sunt preparatori sau asistenti).

28

Un tip de entitate se identifică printr-un nume şi o listă de proprietati. O bază de date conţine în general mai multe tipuri de entităţi. Fiecare tip de entitate are propriul set de proprietati.

Numim atribute proprietaţile atasate unui tip de entitate.

Exemplu: entitatea student poate fi descrisa de atributele: nume_student, prenume_student, data_nasterii, sex, adresa, telefon, numar_matricol, grupa.

Prin domeniul atributului intelegem multimea valorilor care pot fi atribuite unui atribut simplu.

Atributele unei entitati contin valorile care descriu fiecare entitate şi cu ajutorul carora fiecare entitate se poate identifica in mod unic. Aceste valori reprezinta cea mai mare parte a datelor memorate intr-o baza de date.

Domeniul unui atribut nu se poate defini intotdeauna foarte exact. De exemplu, atributul nume_student trebuie să fie un şir de caractere dar poate lua ca valori doar un nume de familie existent. Unele domenii se pot descompune în mai multe subdomenii. De exemplu data_naşterii se poate descompune in subdomeniile: an, lună, zi.

In general putem considera ca fiecare entitate este reprezentabila cu ajutorul unei multimi de perechi de forma (nume_atribut, valoare_atribut), cate o pereche pentru fiecare atribut atasat tipului de entitate corespunzator.

Exemplu: o entitate a tipului de entitate student poate fi reprezentata de multimea: {(nume_student, Popescu), (prenume_student, Ion), (data_nasterii, 15.11.1981), (sex, masculin), (adresa, B-dul Garii, 12, Brasov, cod 2200, judetul Brasov), (telefon, 068/444555), (numar_matricol, 31455), (grupa, 7211)}

Atributele se pot clasifica în simple sau compuse; cu o singură valoare sau cu mai multe valori; respectiv derivate.

Numim atribut simplu orice atribut care are doar o singură componentă şi o existenţă independentă.

Aceste atribute nu se pot diviza în mai multe atribute distincte. Ele se mai numesc şi atribute atomice.

Exemplu: atributul sex corespunzator tipului de entitate student.

Numim atribut compus orice atribut care are mai multe componente, fiecare cu o existenţă independentă.

Aceste atribute se pot diviza în general in mai multe atribute simple.

Exemplu: atributul adresă se poate descompune în atributele: strada, număr, oraş, cod_poştal şi judeţ. Decizia ca un atribut compus să se descompună în mai multe atribute simple este dependentă de modul în care se va utiliza acel atribut: pe componente, sau ca un întreg.

Numim atribut cu o singură valoare orice atribut care poate lua cate o singură valoare pentru fiecare entitate.

29

Majoritatea atributelor sunt atribute cu o singură valoare.

Numim atribut cu mai multe valori orice atribut care poate lua mai multe valori pentru fiecare entitate.

Pentru atributele cu mai multe valori trebuie precizate numarul minim şi numarul maxim de valori pe care le poate lua atributul respectiv.

Exemplu: atributul telefon poate fi un atribut cu mai multe valori. In acest caz se poate limita de exemplu numarul numerelor de telefon la care poate fi gasit studentul la minim 0 şi la maxim 3. Deci se pot stabili numarul minim şi numarul maxim de valori pe care le poate lua atributul.

Numim atribut derivat orice atribut a cărui valoare se poate calcula din unul sau mai multe alte atribute. Aceste atribute nu trebuie neaparat sa descrie entitatea careia ii corespunde atributul derivat.

Exemple: valoarea pentru atributul vârsta este derivată din valoarea atributului data_naşterii şi din data curenta. Valoarea atributului numărul_total_de_entităţi se poate calcula numărând entităţile înregistrate.

Reprezentare grafică - diagrame E-R

Intreaga structura logica a unei baze de date poate fi reprezentata grafic cu ajutorul diagramelor E-R. O astfel de diagrama contine elemente grafice cum ar fi:

dreptunghiuri, care reprezinta tipuri de entitate; elipse, care reprezinta atribute; linii, care au rolul de a evidentia legaturile intre elementele

diagramei.

Dreptunghiurile şi elipsele sunt etichetate cu numele 'obiectului' reprezentat. Acestea nu sunt singurele elemente grafice utilizate intr-o diagrama E-R. Pe masura ce vom defini noi concepte vom reveni cu precizari legate de modul de a le reprezenta.

Un atribut se reprezintă printr-o elipsă, legată de entitatea careia îi este asociat cu o linie şi etichetată cu numele atributului. Elipsa este trasata cu linie punctată, dacă atributul este un atribut derivat şi respectiv cu linie dublă, daca atributul poate lua mai multe valori.

Dacă un atribut este compus, atunci componentele atributului se reprezintă prin elipse legate cu cate o linie de atributul compus.

30

locatari

nume

numãr matricol

adresa adresa adresa adresa adresa adresa

numãrbloc

scara

etajapartament

Figura 2.1. Reprezentarea cu diagrama E-R a entitatii locatari

În exemplul din Figura 2.1. entitatea locatari are următoarele atribute: număr_matricol, nume şi adresa. Dintre aceste atribute, atributul adresa este atribut compus, care se descompune în număr_bloc, scara, etaj şi apartament. Explicatia sublinierii atributului număr_matricol se va da in sectiunea care se ocupa de chei, tot in acest capitol.

Numim tip de relaţie orice asociere între tipuri de entităţi.

Numim relaţie orice asociere între entităti, când asocierea include cate o entitate pentru toate tipurile de entitate participante.

Fie E1, E2, ..., En tipuri de entitate. Formal, un tip de relatie este o submultime a urmatoarei multimi:

{( e1, e2, ..., en) | unde e1E1, e2E2, ..., enEn }

ceea ce inseamna ca ( e1, e2, ..., en) reprezinta formal o relatie.

Exemplu: Intr-o aplicaţie care ar servi unor evidente in cadrul asociatiilor de locatari putem considera tipul de entitate locatari descris de atributele: nume, adresa şi numar_matricol şi tipul de entitate scari descris de atributele numar_de_bloc şi scara. Intre tipul de entitate scari şi tipul de entitate locatari se poate stabili un tip de relatie numit este_locuita_de. Acest tip de relatie va contine relatii de tipul ('Scara A', 'Popescu Ion') care va fi interpretata: "Scara A este locuita de Popescu Ion".

Numim gradul relaţiei numărul entităţilor participante în relaţie. Asadar relatia reprezentata mai sus are gradul n. Entităţiile implicate intr-o relaţie se numesc participanţi. Dacă intr-o relaţie sunt doi participanţi, atunci relaţia se numeşte binară.

Tipurile de relatii se reprezinta in diagramele E-R cu ajutorul romburilor care sunt etichetate cu numele tipului de relatie.

31 locatari scari

numar matricol

nume

adresa

numar de bloc

scara

este locu- ita de

lucrator

manager

Figura 2.2. Reprezentarea cu diagrama E-R a relatiei este_locuita_de

Functia pe care o joaca o entitate intr-o relatie se numeste rolul entitatii. In general nu este necesar sa se specifice rolul entitatilor intr-o relatie, deoarece acesta este in general implicit.

Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în roluri diferite. In acest caz este necesar sa se precizeze rolurile entitatilor implicate. În cazul relaţiilor recursive, in diagrama E-R corespunzatoare, cele două arce de la entitate la relaţie şi înapoi, primesc diferite etichete, care sunt importante în înţelegerea corectă a relaţiei.

Exemplu: Daca am considera entitatile lucratori şi manageri care se refera la personalul aceleiasi intreprinderi, am face constatarea ca sunt descrise de aceleasi atribute deci apartin aceluiasi tip de entitate şi anume angajati. Relatia binara lucreaza_pentru, stabilita intre lucratori şi manageri este o relatie recursiva. Rolurile jucate de fiecare entitate se pot stabili recurgandu-se la perechi ordonate (muncitor, manager). Astfel relatia ('Popescu Ion', 'Ionescu Gheorghe') se interpreteaza "Popescu Ion lucreaza pentru (este subordonatul lui) Ionescu Gheorghe".

Figura 2.3. Reprezentarea cu diagrama E-R a relatiei recursive lucreaza_pentru

Unui tip de relatie i se pot asocia atribute descriptive in acelasi mod in care se pot asocia atribute unui tip de entitate.

Exemplu: Tipului de relatie este_locuita_de, care implica tipurile de entitate scari şi locatari, i se poate asocia atributul data care sa retina data la care locatarul L s-a mutat pe scara S. Dupa cum se observa, acest atribut descrie exclusiv tipul de relatie şi el nu mai are sens in afara ei.

2.2.2. Restrictii structurale

32

angajati lucreaza pentru

1 M

Este posibil sa se stabileasca diverse restrictii la care continutul unei baze de date trebuie sa se conformeze. Vom trata in continuare restricţiile care se pot impune entitatilor participante intr-o relatie. Aceste restrictii trebuie sa reflecte caracteristicile relatiilor asa cum se percep in 'lumea reala'. Doua tipuri importante de restrictii sunt de mentionat aici: restrictii de cardinalitate şi restrictii de participare.

a) Restrictii de cardinalitate Numim cardinalitate (polaritate) numărul relaţiilor posibile pentru o entitate participantă. Altfel spus, cardinalitatea exprima numarul entitatilor la care o alta entitate poate fi asociata prin intermediul unei relatii.

Observatie: Am utilizat in definitia de mai sus referiri la entitati şi la relatii pentru a fi mai expliciti. Restrictiile structurale se refera insa in mod evident la tipurile de relatie şi la tipurile de entitate asociate. Aceasta observatie ramane valabila şi in consideratiile ce urmeaza.

Majoritatea tipurilor de relatie au gradul doi. Cardinalitatea in acest caz poate fi de tipurile: unu-la-unu (1:1), unu-la-mai-multe (1:M), sau mai-multe-la-mai-multe (M:N).

Relaţiile unu-la-unu:

În relaţiile unu-la-unu, o entitate, apartinand unui tip de entitate, este legată de cel mult o entitate din celalalt tip de entitate implicat in relatia respectiva. Implicarea fiecarei entitati intr-o relatie data este numita "participarea entitatii".

In diagrama E-R se eticheteaza arcul dintre relaţie şi fiecare tip de entitate cu cardinalul relaţiei; in cazul relatiilor unu-la-unu fiecare din cele doua arce se eticheteaza cu 1.

Relaţiile unu-la-mai-multe:

In relaţia de tip unu-la-mai-multe orice entitate, apartinand primului tip de entitate, este legată de 0, 1, sau mai multe entităţi apartinand celui de-al doilea tip de entitate participant la relatie. Exemplificăm acest tip de relaţie prin relaţia este_locuita_de dintre tipurile de entităţi scari, respectiv locatari. In reprezentarea grafică a acestui tip de relatie, arcul dinspre tipul de entitate scari se eticheteaza cu 1 iar arcul dinspre tipul de entitate locatari se eticheteaza cu M (asa cum s-a şi realizat de fapt in Figura 2.2.). Modelul semantic din Figura 2.4. reprezinta relatia unu-la-mai-multe este_locuita_de.

Din exemplul de mai sus se observă usor că dacă relaţia directă este de unu-la-mai-multe, atunci relatia inversă este de unu-la-unu.Relaţiile mai-multe-la-mai-multe:

Acest tip de relaţie se deosebeşte de relaţia unu-la-mai-multe prin faptul că relaţia inversă nu este de unu-la-unu, ci de unu-la-mai-multe. Deci, dacă şi relaţia directă şi relaţia inversă sunt de tipul unu-la-mai-multe, atunci relaţia directa este de tipul mai-multe-la-mai-multe şi se notează cu (N:M).

33

Figura 2.4. Reprezentarea cu retele semantice a relaţiei 1:M este_locuita_de

b) Restrictii de participare

Numim restrictii de participare acele restrictii prin care se determină dacă existenţa unui tip de entitate depinde de faptul ca este legat sau nu de un alt tip de entitate prin intermediul relatiei in discutie.

Participarea unei entitati poate fi totală sau parţială. Participarea este totala daca existenta entitatii respective necesita existenta unei entitati asociate în relaţia dată. În caz contrar participarea se numeşte parţială. Termenii participare totala şi participare partiala pot fi inlocuiti cu participare obligatorie respectiv participare optionala. În diagrama E-R aceste tipuri de relaţii se reprezintă prin arc cu linie dublă pentru participarea totală, respectiv cu linie simplă pentru participarea parţială. Pentru participarea parţială, există un mod de notaţie prin care se etichetează arcele relaţiei cu perechea de numere ce reprezintă minimul, respectiv maximul entităţilor participante la relaţie.

Exemplu: Daca se considera filialele unei firme oarecare ca entitati in tipul de entitate filiala şi daca se considera tipul de entitate personal (unde entitatile reprezinta personalul firmei respective) se poate defini tipul de relatie are_alocat stabilit intre o filiala concreta şi personalul firmei. In acest caz, daca se considera ca fiecare filiala are alocat personal al firmei atunci participarea tipului de entitate filiala in relatia are_alocat este totala. Daca insa admitem ca unii membri ai personalului (de exemplu vanzatorii) nu lucreaza in birourile nici unei filiale, atunci participarea tipului de entitate personal in relatia are_alocat este partiala.

c) Dependenţele de existenţă

Numim tip slab de entitate un tip de entitate, a cărui existenţă este dependentă de existenta unui alt tip de entitate.

Numim tip tare de entitate un tip de entitate, a cărui existenţă nu depinde de existenta nici unui alt tip de entitate.

34

Sc.A

Sc.B

Sc.C

scari este locuita de

R1

R2

R3

Fam.1

Fam.2

Fam.3

locatarinr_blocscara

nr_blocscara

nr_blocscara

atributenr_matnumele

nr_matnumele

nr_matnumele

atribute

Entităţile slabe se mai numesc existential dependente sau subordonate iar entitatile tari se mai numesc părinte sau dominante.

In diagrama E-R tipurile de entitate tari se reprezinta cu un dreptunghi trasat cu linie simpla. Pentru tipurile de entitate slabe conturul dreptunghiului este trasat cu linie dubla. De asemenea aceasta notatie se extinde şi la relatii. Astfel: o relatie care leaga doua tipuri de entitate tari este reprezentata cu un romb trasat cu linie simpla iar relatia care leaga un tip de entitate tare de un tip de entitate slab este reprezentata cu un romb trasat cu linie dubla.

2.2.3. Chei

Conceptual este evident ca entitatile şi relatiile individuale care participa la modelarea unei baze de date sunt distincte intre ele. Diferenta intre entitati sau diferenta intre relatii se exprima cu ajutorul atributelor care le descriu.

Numim supercheie asociata unui tip de entitate, orice submultime a multimii de atribute ce descriu tipul de entitate, submultime care poate duce la identificarea in mod unic a oricarei entitati in cadrul tipului de entitate luat in considerare.

Este evident ca, daca o submultime de atribute formeaza o supercheie, atunci orice multime de atribute care include supercheia este tot o supercheie.

Numim cheie candidat orice supercheie care contine un numar minim de atribute. Pentru o cheie candidat nici o submultime proprie nu mai este supercheie. Putem spune ca o cheie candidat este caracterizata de urmatoarele proprietati:

-unicitatea, deoarece valoarea cheii este unica pentru fiecare entitate in parte;

-ireductibilitatea, deoarece nici o submultime proprie de atribute ale cheii nu are proprietatea de unicitate.

Observatie: Faptul ca valorile unei chei candidat sunt unice pentru fiecare entitate nu poate fi determinat decat cu ajutorul informatiilor semantice referitoare la valorile atributelor ce formeaza cheia. Trebuie sa se cunoasca semnificatiile din lumea reala a atributelor ce formeaza cheia pentru a se stabili daca acestea vor avea valori unice. Doar faptul ca, pentru o multime oarecare de entitati concrete, valorile difera intre ele nu este de ajuns.

Pentru un tip de entitate este posibil sa se poata determina una sau mai multe chei candidat.

Dintre acestea, cheia primară este cheia aleasa ca mijloc principal de identificare a entitatilor in cadrul tipului de entitate respectiv.

Cheia primară este in general cea mai scurtă dintre cheile candidat.

In diagrama E-R atributele care intră în componenţa cheii primare, se evidentiază prin sublinierea numelui atributului.

35

Numim cheie compusă orice cheie candidat care contine cel putin două atribute.

Probleme se ivesc atunci cand trebuie sa identificam in mod unic entitatile unui tip de entitate slab. Sa observam ca un tip de entitate tare are intotdeauna o cheie primara, deci are intotdeauna cel putin o cheie candidat. Un tip de entitate slab nu are cheie primara.

Numim discriminatorul unui tip de entitate slab, un set de atribute care permite realizarea unei distinctii intre entitatile care depind de o anume entitate tare. Asadar, cheia primara a unui tip de entitate slab este formata din cheia primara a tipului de entitate tare de care este dependenta existential, la care se adauga multimea atributelor care compun discriminatorul tipului de entitate slab.

Si relatiile au chei. Cu ajutorul cheilor se pot identifica in mod unic relatiile individuale.

Cheia primara a tipului de relatie este formata din reuniunea multimilor de atribute care formeaza cheile primare ale tipurilor de entitate participante.

2.3. Modelul Enhanced Entity-Relationship (EE-R)

2.3.1. Problemele modelului E-R

Vom examina mai intai unele probleme ce pot apărea la proiectarea unui model conceptual de date de tipul E-R. Aceste probleme apar in general datorita interpretarii gresite a semnificatiei unor relatii şi de aceea sunt cunoscute sub denumirea de capcane de conexiune (connection traps). Pentru a identifica o capcana de conexiune trebuie sa ne asiguram ca semnificatia oricarei relatii este pe deplin inteleasa şi in mod clar definita. Mentionam aici două tipuri importante de capcane de conexiune: de tip labirint (fan trap), respectiv de tip prăpastie (chasm trap).

Numim capcană de tip labirint (fan trap) cazul în care modelul reprezintă o relaţie între două tipuri de entitate, dar calea intre unele entitati individualizate este ambiguă.

Cu alte cuvinte, pornind de la o entitate, nu se ştie (după parcurgerea căii relaţiei), la ce entitate se ajunge în partea cealaltă. Această capcană se poate elimina prin rearanjarea ordinii relaţiilor dintre cele două tipuri de entităţi.

Numim capcană de tip prăpastie (chasm trap) situatia in care modelul sugerează existenţa relaţiei între cele două tipuri de entitate, dar calea dintre unele entităţi individualizate nu există.

O capcana de tip prapastie ar putea aparea in cazul relatiilor cu participare partiala. Problema se poate rezolva prin introducerea unei relaţii directe.

Ramane sa revenim asupra acestor aspecte in sectiunea care trateaza proiectarea unei baze de date.

36

Modelul E-R, discutat în capitolele de mai sus, este adecvat pentru descrierea multor scheme de baze de date. Din anii '80 incoace s-au dezvoltat foarte mult noi aplicaţii ale bazelor de date cum ar fi tools-urile: Computer Aided Design (CAD), Computer Aided Manufacturing (CAM), Computer Aided Software Engineering (CASE) şi aplicaţii multimedia. Modelul E-R s-a dovedit insuficient pentru aceste noi aplicaţii cu cerinte deosebite impuse bazelor de date, cerinte care nu fusesera formulate in cazul aplicaţiilor administrative traditionale. aplicaţiile cu mult mai complexe au necesitat adaugarea de concepte noi la modelul E-R. S-au propus mai multe modele semantice noi de date, unele din conceptele noi fiind incorporate cu succes chiar in modelul E-R obtinandu-se in acest mod noul model Enhanced Entity-Relationship (EE-R).

Modelul EE-R include toate conceptele modelului E-R, plus alte completări devenite necesare. Aceste concepte nou introduse sunt: specializarea / generalizarea, categorisirea şi agregarea. În acest capitol vom descrie conceptul de bază in modelul EE-R: specializarea / generalizarea.

Conceptul de specializare / generalizare este asociat cu modul de reprezentare a tipurilor de entitate utilizand superclase şi subclase, şi cu modul in care se realizeaza moştenirea atributelor.

2.3.2. Superclase şi subclase ale tipurilor de entitate

Vom descrie aceste concepte, având ca exemplu tipul de entitate locatari.

Numim superclasă un tip de entitate ce include subclase distincte care necesita reprezentarea într-un model de date.

Numim subclasă un tip de entitate care are un rol distinct şi care este de asemenea membru al unei superclase.

De exemplu superclasa locatari se divizează în două subclase şi anume: şef_de_scară şi familii. Relaţia dintre o superclasă şi o subclasă se numeşte relaţie superclasă / subclasă. Această relaţie este de tip unu-la-unu. Relaţia locatari / familii de exemplu, este o astfel de relaţie.

Fiecare membru al unei subclase este membru şi în superclasă, dar are un rol diferit. Există subclase case se suprapun, adică există membrii într-o subclasă care apar şi în cealaltă subclasă. Putem observa că exemplul de mai sus este exact de acest tip, pentru că şeful de scară poate să fie şi cap de familie. De ce se foloseşte clasificarea în subclase? Răspunsul este simplu daca ne referim la exemplul dat. Dacă nu am clasifica entităţiile din tipul de entitate locatari, atunci ar trebui să memorăm informaţiile specifice şefului de scară şi capului de familie pentru fiecare locatar. Deoarece majoritatea locatarilor nu aparţine niciunei categorii, pentru acest grup informatiile de mai sus ar fi informaţii vide, dar care însă ar ocupa mult spaţiu pe suportul magnetic.

Fiecare subclasă are ca atribute comune, atributele superclasei de care aparţine. Deci fiecare membru al unei subclase se caracterizează prin atributele superclasei plus alte atribute specifice subclasei. De exemplu subclasa familii se caracterizează prin toate atributele superclasei locatari (număr_matricol,

37

număr_bloc, scara, etaj, apartament şi nume), pe lângă care mai are şi atributele specifice (număr_persoane, număr_persoane_prezente, etc.)

Fiecare subclasă poate să aibă subclase, creîndu-se un arbore de clase, care se numeşte ierarhie de tipuri. Această ierarhie de tipuri include alte denumiri de ierarhii şi anume: ierarhia de specializări (de exemplu, tipul de entitate familii este o specializare a tipului de entitate locatari) şi ierarhia de generalizări (de exemplu, tipul de entitate locatari este o generalizare a tipului de entitate familii).

2.3.3. SpecializareaNumim specializare procesul de maximizare a diferenţelor intre membrii unui tip de entitate prin identificarea caracteristicilor lor distincte.Specializarea este o abordare top-down a definirii unor superclase, îmreună cu subclasele lor. Relaţia superclasă / subclasă se reprezintă grafic printr-un arc de la superclasă la un cerc, care la rândul lui este legat cu un arc de subclase. Pe arcele catre subclase se desenează un semn de incluziune de la subclasă la superclasă. Aceste semn de incluziune indică direcţia relaţiei superclasă / subclasă.

Atributele specifice doar subclasei sunt ataşate direct la dreptunghiul care reprezintă subclasa. Toate aceste notaţii se exemplifică în figura de mai jos:

Figura 2.5. Reprezentarea relatiei superclasa / subclasa in cazul tipului de entitate locatari

În exemplul de mai sus tipul superclasa locatari se compune din subclasele: sef_de_scară şi familii. Superclasa locatari va avea ca membri pe toţi locatarii unei scări. Dintre aceşti locatari, unii sunt cap de familie iar alţii sunt şef de scară. Aceşti membri ai tipului de entitate locatari vor apărea ca membri şi în subclasele sef_de_scară, respectiv familii.

Putem intalni mai multe specializari la acelasi tip de entitate daca se porneste de la caracteristici de diferentiere diferite.

Numim subclasă partajată subclasa care are mai multe superclase.

38

locatarinumar

matricol

numar bloc adresa

sef de scara

data intrarii în functie

familii

numar persoane

Membrii din subclasa partajată sunt membri în fiecare dintre superclase. De aceea ei moştenesc atributele fiecărei superclase. O astfel de moştenire se numeşte moştenire multiplă.

2.3.4. Generalizarea

Generalizare se numeşte procesul de minimizare a diferenţelor dintre entităţi, pentru identificarea caracteristicilor comune.

Procesul de generalizare este o aproximare bottom-up a superclaselor, din subclasele originale. Deci generalizarea este inversa specializării. De exemplu dacă privim tipurile de entităţi Familii şi Şef de scară, vom observa că unele atribute ale lor caracterizează ambele tipuri. De aici rezultă necesitatea creării unei superclase care să conţină toate atributele comune celor două tipuri.

2.3.5. Conditii impuse specializării şi generalizării

În acest capitol vom discuta despre restrictiile ce trebuie impuse în cazul specializării sau al generalizării.

Prima conditie se numeşte regula disjuncţiei. Această regulă specifică dacă subclasele unei clase sunt disjuncte, adică daca un membru al superclasei aparţine cel mult uneia dintre subclase. O specializare disjunctă se reprezintă cu un “d” înscris în cercul care leagă subclasele de superclase.

Dacă subclasele nu sunt disjuncte, adică daca un membru al superclasei poate să aparţină la mai multe subclase, atunci subclasele respective se numesc non disjuncte şi se notează cu “o” în cercul care leagă subclasele de superclase. În exemplul nostru, subclasele sef_de_scară şi familii - care sunt subclasele clasei locatari - sunt non disjuncte.

A doua conditie (a specializării) este regula participării, care poate fi totală sau parţială. Participarea este totală dacă toţi membrii superclasei sunt şi membri ai subclaselor. Pentru reprezentarea participării totale, arcul de la superclasă la cercul dintre superclasă şi subclasă se dublează.

În cazul participării parţiale nu toţi membrii superclasei apartin unei subclase. Acest tip de participare se reprezintă cu linie simplă între superclasă şi cerc. In exemplul nostru avem o participare parţială în cazul superclasei locatari, cu subclasele sef_de_scară şi familii.

Cele două reguli se aplică distinct la procesele de specializare, sau generalizare. De aceea putem avea, de exemplu, patru tipuri de specializări: disjunctă totală, disjunctă parţială, non disjunctă totală, sau non disjunctă parţială.

Capitolul 3 Algebra relaţională

39

In cadrul bazelor de date relaţionale, datele sunt organizate sub forma unor tablouri bidimensionale (tabele) de date, numite relaţii. Asocierile dintre relaţii se reprezintă explicit prin atribute de legătură. Aceste atribute figurează într-una din relaţiile implicate in asociere (de regulă, în cazul legaturilor de tip "unu la mulţi") sau sunt plasate într-o relaţie distinctă, construită special pentru exprimarea legaturilor între relaţii (în cazul legaturilor de tip "mulţi la mulţi"). O bază de date relaţională (BDR) reprezintă un ansamblu de relaţii, prin care se reprezintă atât datele cât şi legăturile dintre date. 2. Operatorii modelului relaţional. Definesc operaţiile care se pot efectua asupra relaţiilor, in scopul realizarii funcţiilor de prelucrare asupra bazei de date, respectiv consultarea, inserarea, modificarea şi ştergerea datelor. 3. Restricţiile de integritate ale modelului relaţional. Permit definirea stărilor coerente ale bazei de date. În continuare, vor fi prezentate pe larg aceste componente.3.1 Structura relaţionala a datelor Prezentarea structurii relaţionale a datelor impune definirea noţiunilor de: domeniu, relaţie, atribut şi schemă a unei relaţii.3.1.1. Domeniu Domeniul reprezintă un ansamblu de valori, caracterizat printr-un nume. Un domeniu se poate defini explicit, prin enumerarea tuturor valorilor apartinând acestuia sau implicit, prin precizarea proprietăţilor pe care le au valorile din cadrul domeniului respectiv. Sa considerăm, de exemplu domeniile D1, D2, D3, definite astfel: D1: ("F","M") D2 : (x / x aparţine N, x aparţine [0,100]) D3 :(s/s=şir de caractere)

În cazul lui D1 s-a recurs la o definire explicită, în timp ce pentru D2 şi D3 s-a utilizat definirea implicită. Pentru un ansamblu de domenii D1, D2, ..., Dn produsul catezian al acestora reprezinta ansamblul tuplurilor <v1, v2, ..., vn>, unde: v1 este o valoare apartinând domeniului D1, v2 este o valoare din D2 s.a.m.d. De exemplu, tuplurile: <"Maria", "F", 50>, <"Vasile", "M",15>,<"Vasile","M",20>, <"Vasile", "F",100> aparţin produsului cartezian: D3 x D1 x D2

3.1.2. Relaţie Să presupunem că se acordă o anumită semnificaţie valorilor domeniilor D1, D2, D3, definite anterior. Sa considerăm, de exemplu ca D1 cuprinde valorile referitoare la sexul unei persoane, D2 conţine valori care exprimă vârsta unei persoane şi D3 cuprinde numele unor persoane. Numai unele dintre tuplurile produsului cartezian: D3 x D1 x D2 pot avea o semnificaţie şi anume cele care conţin numele, sexul şi vârsta aceleiaşi persoane.Dintre cele 202 tupluri care au valoarea "Vasile" pe prima pozitie, numai unulpoate avea o semnificaţie, dacă presupunem că există o singură persoană cu

40

acest nume. Se desprinde de aici necesitatea definirii unei submulţimi de tupluri, din cadrul produsului cartezian al domeniilor, submulţime care să cuprindă numai tuplurile cu semnificaţie. Relaţia reprezintă un subansamblu al produsului cartezian al mai multor domenii, subansamblu caracterizat printr-un nume şi care conţine tupluri cu semnificatie. Considerând de exemplu că nu se cunosc decât două persoane definim realţia R prin tuplurile care descriu aceste persoane şi anume:R : (<"Maria", "F", 30>, <"Vasile", "M", 35>) Intr-o relaţie, tuplurile trebuie să fie distincte (nu se admit duplicări aletuplurilor) . O reprezentare comodă a relaţiei este tabelul bidimensional (tabela de date în care liniile reprezinta tuplurile, iar coloanele corespund domeniilor (fig.3.1.).

Fig. 3.1. Relaţie reprezentată sub forma unei tabele de date Reprezentarea tabelară este preferată adesea altor forme de reprezentare a relaţiilor, întrucat este uşor de înţeles şi de utilizat. În prezentarea conceptului de reţatie se recurge uneori la analogii cu alte concepte, extrem de bine cunoscute în domeniul prelucrării automate a datelor precum cel de fişier. Relaţia poate avea semnificaţia unui fişier,tuplul poate fi considerat drept o înregistrare, iar valorile din cadrul tuplului pot fi interpretate drept valori ale câmpurilor de înregistrare.În cadrul modelului relaţional nu intereseaza decat relaţiile finite, chiar dacăîn construirea relaţiilor se admit domenii infinite. Numărul tuplurilor dintr-orelaţie reprezinta cardinalul relaţiei, în timp ce numărul valorilor dintr-un tuplu defineste gradul relaţiei.

3.1.3. Atribut In timp ce tuplurile dintr-o relaţie trebuie să fie unice un domeniu poate apare de mai multe ori în produsul cartezian pe baza căruia este definită relaţia. Să considerăm, de exemplu că pentru o persoana dispunem de urmatoarele date: nume,sex, vârsta şi numele soţului/soţiei. O posibilitate de organizare a acestor date o reprezintă relatţa din fig.3.2.

R: D3 D1 D2“Maria” “F” 30“Vasile” “M” 35

41

Fig.3.2. Relaţia PERS

Relatia PERS reprezintă un subansamblu al produsului cartezian: D3 x D1 x D2 x D3. Semnificaţia valorilor din cadrul unui tuplu se stabileşte în acest caz nu numai pe baza domeniului de care aparţin valorile, ci şi in funcţie de poziţia ocupată în cadrul tuplului. Dependenţa fată de ordine a datelor inseamnă o reducere a flexibiltăţii organizarii datelor. Într-o organizare eficientă, flexibilă, ordinea liniilor şi a coloanelor din cadrul tabelei de date nu trebuie să prezinte nici o importanţă. Pentru a diferenţia coloanele care conţin valori ale aceluiaşi domeniu şi a elimina astfel dependenţa de poziţie în cadrul tabelei se asociază fiecarei coloane un nume distinct, ceea ce duce la aparitţa noţiunii de atribut. Atributul reprezintă coloana unei tabele de date, caracterizată printr-un nume. Numele coloanei (atributului) exprimă de obicei semnificaţia valorilor din cadrul coloanei respective.Schema unei relaţii Prin schema unei relaţii se întelege numele relaţiei, urmat de lista atributelor, pentru fiecare atribut precizându-se domeniul asociat. Astfel, pentru o relaţie R, cu atributele A1, A2, ..., An şi domeniile: D1, D2,..., Dm, cu m <= n, schema relaţiei R poate fi reprezentată într-una din formele prezentate in fig. 3.4.

R(A1:D1, …, An:Dm)

a)

A1:D1 … An:Dm

b)

3.1.4.Operatorii modelului relaţional Modelul relaţional ofera doua colecţii de operatori pe relaţii şi anume: - algebra relaţionala; - calculul relaţional. La rândul sau, calculul relaţional este de două tipuri: - calcul relaţional orientat pe tuplu;

- calcul relaţional orientat pe domeniu.Ne limităm, în cele ce urmează, la elemente de algebră relaţională.

3.2. Algebra relaţională şi extensiile sale E. F. Codd a introdus algebra relaţionala (AR) cu operaţii pe relaţii, fiecare operaţie având drept operanzi una sau mai multe relaţii şiproducând ca rezultat o altă relaţie. Unele operaţii ale AR pot fi definite prin intermediul altor operaţii. În acest sens, putem vorbi de: - operaţii de bază, precum: reuniunea, diferenţa, produsul cartezian etc. - operaţii derivate, ca: intersecţia, diviziunea etc.

42

Codd a introdus aşa numita AR standard, constituită din 6 operaţii de bază: reuniunea, diferenţa, produsul cartezian, proiecţia, selecţia şi joncţiunea precum şi din două operaţii derivate: intersecţia şi diviziunea. Ulterior, la operaţiile AR standard au fost adăugate şi alte operaţii, aşanumitele operaţii "adiţionale" sau extensii ale AR standard, precum:comple-mentara unei relaţii, splitarea (spargerea) unei relaţii, închiderea tranzitivă etc.

În continuare vor fi prezentate principalele operaţii ale AR, precum şi modul lor de utilizare. 1. Reuniunea. Reprezintă o operaţie a AR definita pe doua relaţii: R1 şi R2 ambele cu o aceeaşi schemă, operaţie care constă din construirea unei noi relaţii R3, cu schema identică cu R1 şi R2 şi având drept extensie tuplurile din R1 şi R2 luate impreună o singură dată. Notaţia uzuală pentru reuniune este: R1 U R2 Reprezentarea grafică a reuniunii este prezentata in fig. 3.3.

Fig.3.3. Reuniunea relatiilor ORASE şi MUNICIPII

In fig. 3.3. este ilustrata aceasta operatie .2. Diferenţa. Reprezintă operaţie din AR definită pe doua relaţii: R1 şi

R2, ambele cu o aceeaşi schemâ, operaţia constând din construirea unei noi relaţii R3, cu schema identică cu a operanzilor şi cu extensia formată din acele tupluri ale relaţiei R1 care nu se regăsesc şi în relaţia R2. Notaţia uzuală pentru operaţia de diferenţă a doua relaţii este: R1-R2 În fig. 3.4. este prezentat un exemplu de diferenţă a doua relaţii.

43

Fig.3.4. Diferenţa relaţiilor ORAŞE şi MUNICIPII

3. Produs cartezian. Reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2, operaţie care constă din construirea unei noi relaţii R3, a cărei schemă se obţine prin concatenarea schemelor relaţiilor R1 şi R2 şi a cărei extensie cuprinde toate combinaţiile tuplurilor din R1 cu cele din R2. Notaţia uzuală pentru desemnarea operaţiei este: R1xR2Fig. 3.5. prezintă un exemplu de produs cartezian a două relaţii.

ORAŞ:D1 JUDEŢ: D1 TRANSPORT:D3 TARIF:D4

Braşov Braşov tramvai 30Târgovişte Dâmboviţa tramvai 30Braşov Braşov autobuz 50Târgovişte Dâmboviţa autobuz 50Braşov Braşov troleibuz 50Târgovişte Dâmboviţa troleibuz 50

ORAŞ:D1 JUDEŢ:D1

Braşov BraşovTârgovişte Dâmboviţa

Fig.3.5. Produsul cartezian al relaţiilor ORAŞE şi TARIFE

4. Proiecţia. Reprezintă o operaţie din AR definită asupra unei relaţii R, operaţie care constă din construirea unei noi relaţii P, în care se regăsesc unele atribute din R, înseamnă efectuarea unor tăieturi verticale asupra lui R, care pot avea ca efect apariţia unor tupluri duplicate ce se cer a fi eliminate.

44

TRANSP:D3 TARIF:D3

tramvai 30autobuz 50troleibuz 50

TRANSP:

XTARIF:

ORAŞE:

Prin operaţia de proiecţie se trece de la o relaţie de grad n la o relaţie de gradp, mai mic decât cel iniţial (p < n) ceea ce explică şi numele de proiecţie atribuit operaţiei. Notaţia uzuală pentru operaţia de proiecţie este:ΠAi,Aj,…,Am(R) În fig.3.6 este exemplificată operaţia de proiecţie a unei relaţii.

Fig.3.6. Proiectia relaţiei ORAŞE pe atributul "Judeţ"

5. Selecţia. Roprezintă o operaţie din AR definită asupra unei relaţii R,operaţie care constă din construierea unei relaţii S, a cărei schemă este identicăcu cea a relaţiei R şi a cărei extensie este constituită din acele tupluri din R care satisfac o condiţie menţionată explicit în cadrul operaţiei. Întrucât cel mai adesea, nu toate tuplurile din R satisfac, această condiţie, selecţia înseamnă efectuarea unor tăieturi orizontale asupra relaţiei R, adică eliminarea de tupluri. Condiţia precizată în cadrul operaţiei de selecţie este în general de forma:

unde: "operator de comparaţie" poate fi: <, <=, >=, > sau <>. Notaţia folosită in mod uzual pentru desemnarea operaţiei de selecţie este următoarea:Σ(conditie)R În fig.3.7. este exemplificată operaţia de selecţie.

45

Fig.3.7. Selecţie efectuata asupra relaţiei ORAŞE

6. Joncţiunea (Joinul). Reprezintă o operaţie din AR definită pe două relaţii: R1 şi R2, operaţie care constă din construirea unei noi relaţii R3, prin concatenarea unor tupluri din R1 cu tupluri din R2. Se concateneaza acele tupluri din R1 şi R2 care satisfac o anumita condiţie, specificată explicit în cadrul operaţiei. Extensia relaţiei R3 va contine deci combinaţiile acelor tupluri care satisfac condiţia de concatenare.Notaţiiile uzuale pentru desemnarea operaţiei de joncţiune sunt:

Reprezentarea grafică a aeestei operaţii este prezentată în fig. 3.8.

Fig.3.8. Reprezentarea grafica a operaţiei de joncţiune In general, condiţia de concatenare menţionata in cadrul operaţiei de joncţiune este de forma:

In funcţie de operatorul do comparaţie din cadrul condiţiei de concatenare, joinul poate fi de mai multe tipuri. Cel mai important tip de join, în sensul celei mai frecvente utilizări este equijoinul.

Equijoinul reprezinta joncţiunea dirijată de o condiţie de forma:

46

Operatia de joncţiune se poate exprima cu ajutorul operaţiilor de produs cartezian şi selecţie, rezultatul unui join fiind acelaşi cu rezultatul unei selecţii operate asupra unui produs cartezian, adică: JOIN (R1,R2, condiţie) = RESTRICT(PRODUCT(R1,R2), condiţie) Produsul cartezian reprezintă o operaţie laborioasă şi foarte costisitoare, ceea ce face ca in locul produsului să fie utilizat joinul ori de câte ori acest lucru este posibil. Cu toate că apare drept o operaţie derivată, joinul este prezentat de obicei drept o operaţie de bază din AR, dată fiind importanţa sa in cadrul sistemelor relaţionale, în special la construirea relaţiilor virtuale. In cadrul fig.3.9. este ilustrată operaţia de equijoin. Au fost definite numeroase variante ale operaţiei de joncţiune, variante care diferă nu numai în funcţie de tipul condiţiilor de concatenare, ci şi după modul de definire a schemei şi respectiv, extensiei relaţiei rezultate prin joncţiune. Joncţiunea naturală. In cazul equijoinului, schema relaţiei conţine toate atributele celor doi operanzi (fig.3.10.) În toate tuplurile relaţiei rezultat vor exista de aceea cel puţin două valori egale. In sensul eliminării acestei redundanţe s-a introdus joncţiunea naturală, ca operaţie definită pe două relaţii: R1 şi R2, prin care este construită o noua relaţie R3, a cărei schemă este obţinută prin reuniunea atributelor din relaţiile R1 şi R2 (atributele cu acelaşi nume se iau o singură dată) şi a cărei extensie conţine tuplurile obţinute prin concatenarea tuplurilor din R1 cu tuplurile din R2 care prezintă aceleaşi valori pentru atributele cu acelaşi nume.

Fig.3.9. Operaţia de equijoin a relaţiilor ORAŞE şi ESTIMARI

Notaţia uzuală pentru joncţiunea naturală este: Reprezentarea grafică a acestei operaţii este prezentată în fig. 3.10.

47

Fig.3.10. Reprezentarea grafică a operaţiei de joncţiune naturală

Fig.3.11. Operaţia de joncţiune naturală a relaţiilor ORAŞE şi ESTIMĂRI

În fig.3.11. este exemplificată operaţia de joncţiune naturală.7. Intersecţia. Reprezintă o operaţie a AR definită pe două relaţii: R1

şi R2 ambele cu aceeaşi schemă, operaţie care constă din construirea unei noi relaţii R3, cu schema identică cu a operanzilor şi cu extensia formată din tuplurile comune lui R1 şi R2. Notaţile uzuale folosite pentru desemnarea operaţiei de intersecţie sunt:

Reprezentarea grafică a operaţiei de intersecţie este prezantată în fig. 3.12., iarun exemplu de intersecţie a doua relaţii figurează în fig. 3.13.

Fig.3.12. Reprezentarea grafica a operatiei de intersectie

48

Fig.3.13. Intersecţia relatiilor ORAŞE şi MUNICIPII Intersecţia reprezintă o operaţie derivată, care poate fi exprimată prin intermediul unor operaţii de bază. De exemplu, operaţia de intersecţie se poate exprima prin intermediul operaţiei de diferenţă, cu ajutorul următoarelor echivalenţe: R1 R2=R1-(R1-R2) R1 R2=R2-(R2-R1)

Exercitii recapitulative

Se dau următoarele relaţii cu schemele lor:-Scări (Nr_bloc, Scara, Lift)-Apartamente(Nr_bloc,Scara,Apartament,Suprafaţa,Cutii_poştale, Nr_prize_tv)- Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)-Locatari

Nr_Mat, Nr_bloc, Scara, Etaj, Apartament,Nume

Să se exprime în algebra relaţională cererile:1) (tabel nominal cu locatarii de pe scara = 3 din bloc = 34) = R12) (tabel nominal cu locatarii de pe scara = 1 din bloc = 34) = R23) (tabel nominal cu locatarii de pe scara = 2 din bloc = 34) = R34) tabel nominal cu locatarii de pe scările 1,2,3 ale blocului 345) lista apartamentelor cu suprafaţa mai mare decât 50 mp6) tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 şi nu

locuiesc şi pe scara 1 a aceluiaşi bloc

Răspunsuri la exerciţii

1) R1=nume(bloc=34 and scara=3(scari) (locatari))2) R2= nume (bloc=34 and scara=1(scari) (locatari))3) R3= nume (bloc=34 and scara=2(scari) (locatari))

49

4) R = R1 R2 R35) R = suprafaţa > 50(apartamente)6) R= (R1-R2)

Capitolul 4. Limbaje de interogare comerciale

4.1. Istoric, obiective

SQL (Structured Query Language), a fost conceput iniţial de firma IBM, pentru produsul dBASE, ca un limbaj standard de descriere a datelor şi de acces la informţtiile din bazele de date. Limbaj de interogare a bazelor de date relaţionale, SQL a fost utilizat pe scară largă şi pană în prezent au fost dezvoltate şapte versiuni ale standardului SQL, trei dintre ele aparţinînd Institutului National American de Standarde (ANSI), celelalte fiind concepute de firme de prestigiu ca IBM, Microsoft şi Borland sau de cãtre consorţii ca SAG (The SQL Access Group) şi X/Open.

Primul standard SQL a fost creat in anul 1989 de cãtre ANSI fiind cunoscut sub numele de ANSI-SQL'89 şi a fost revizuit in octombrie 1992 sub noua denumire: ANSI-SQL'92.

In anul 1992, firma Microsoft, in calitate de membru SAG, a lansat pe piata produsul ODBC (Open Database Connectivity), un standard API-SQL care defineste o interfatã de programare a aplicaţiilor (API) pentru accesul la bazele de date. Pe de alta parte, un alt membru SAG, firma Borland, a pregatit propriul sãu standard API-SQL denumit IDAPI (Integrated Database Application Programming Interface).

In încercarea de a extinde substantial limbajul SQL, ANSI pregateste noua generatie de standarde SQL, denumitã SQL3, care se adreseaza bazelor de date orientate obiect.

Mentionam aici şi standardul IBM pentru acces la bazele de date de pe platformele proprii, denumit DRDA (Distributed Relational Database Access). Interfata de programare API oferã o cale de comunicare între programe şi bazele de date prin apeluri de functii care substituie instructiunile SQL. Astfel, standardele API se bazeazã pe conectivitate şi anume pe conectarea utilizatorului la baza de date, precum şi pe schimbul de date şi mesaje SQL. Conceperea de interfete de programare API pentru SQL oferã posibilitatea gestionarii mai multor tipuri de baze de date cu costuri relativ scãzute.

Interfetele de programare API, realizate in cadrul grupului SAG de cãtre firmele Microsoft şi Borland, se bazeaza pe un subset al standardului ANSI. Gestiunea bazelor de date de diferite tipuri se poate face usor prin intermediul interfetelor inteligente, numite drivere. Acestea

50

receptioneazã mesajele de la clienti şi le traduc în instructiuni SQL sau API. Deci în loc de a interoga direct baza de date, clientul conveseazã cu interfata inteligentã, ceea ce asigurã independenta fatã de implementarea bazelor de date. Aceste interfete conduc la creşterea performantelor ,utilizînd dialectul SQL sau bibliotecile API.

Se pare ca în viitorul apropiat nu se întrevãd schimbãri majore în domeniul standardelor SQL.

4.2. Clauze şi operatori SQL

4.2.1. Clauzele SELECT, FROM şi WHERE

Clauzele SQL SELECT, FROM şi WHERE pot fi puse în corespondentã cu operatorii din algebra relaţionalã, dupa cum urmeaza:

clauza SELECT mentioneaza o lista de atribute şi corespunde proiectiei din algebra relaţionalã;

clauza FROM mentioneazã o listã de relatii (tabele) şi corespunde produsului cartezian din algebra relaţionala;

clauza WHERE descrie un predicat de selectie şi corespunde selectiei din algebra relaţionalã.

O interogare simpla SQL este de forma:

SELECT A1, A2, ..., An

FROM R1, R2, ..., Rm

WHERE P

Unde: Ai sunt atribute care apar în cel putin una dintre relatiile Ri;

Ri sunt relatii (tabele);

P este un predicat de selectie.

Interogarea este echivalentã cu urmatoarea expresie din algebra relaţionalã:

Inţelesul diferit al termenului "select" utilizat în SQL şi in algebra relaţională este un fapt istoric nefericit. In SQL, "select" desemneaza proiectia iar in algebra relaţionala acelasi termen desemneaza selectia dupa un predicat de selectie.

Lista de atribute care apare in clauza SELECT din SQL poate fi inlocuita cu simbolul * daca se doreste selectarea tuturor atributelor care apar in relatiile din clauza FROM.

Intotdeauna rezultatul unei interogari SQL este o relatie (o tabela).

Pentru a ilustra cu exemple modul in care se scriu interogarile SQL vom utiliza tabele cu urmatoarea structura:

Tabela FURNIZORI cu schema de relatie (cod_furnizor, nume_furnizor, adresa_furnizor).

51

Tabela FLORI cu schema de relatie (cod_produs, nume_produs, culoare, inaltime, pret_unitar).

Tabela COMENZI cu schema de relatie (nr_comanda, cod_produs, cod_furnizor, data_comenzii, timp_livrare, cantitate).

Presupunem ca aceste tabele constituie un model foarte simplificat de baza de date legata de evidentele unei florarii, evidente legate de florile pe care floraria le vinde de obicei (tabela FLORI), de comenzile pe care le face floraria (tabela COMENZI) şi de furnizorii de la care obisnuieste floraria sa cumpere flori (tabela FURNIZORI). Presupunem de asemenea ca atributul adresa_furnizor din schema de relatie corespunzatoare tabelei FURNIZORI este un atribut compus. El poate fi descompus in: oras, strada, numar.

EXEMPLE: Sa se exprime in SQL urmatoarele inteogari:

1) "Sa se afiseze toate datele despre toti furnizorii"

SELECT *FROM furnizori

2) "Sa se afiseze orasele de resedinta ale tuturor furnizorilor"

SELECT orasFROM furnizori

Ca rezultat al acestei interogari se va obtine o tabela cu o singura coloana, care contine numele oraselor de resedinta ale furnizorilor. Se va observa ca se repeta numele oraselor, deoarece se vor afisa orasele pentru fiecare furnizor in parte din tabela FURNIZORI.

O interogare SQL are urmatoarea forma generala:

SELECT [DISTINCT/ALL] <lista de atribute>FROM <lista de relatii>[WHERE <conditie> / GROUP BY< lista de atribute> / HAVING <conditie> / ORDER BY <lista de atribute>[ASC / DESC] / UNION <sub_interogare>]; ... ...

Dupã cum se observã, singurele elemente obligatorii intr-o interogare SQL sunt clauzele SELECT cu lista de atribute ce vor fi extrase şi clauza FROM cu relatiile din care fac parte atributele. Asadar o interogare SQL trebuie sa contina cel putin urmatoarele informatii:

SELECT <lista de atribute>FROM <lista de relatii>

restul clauzelor sunt optionale.

Lista de atribute poate consta din :

o serie de atribute separate prin virgulã care vor apãrea în tabela-rezultat în ordinea explicitatã în linia de comandã, de la stanga la dreapta;

52

toate atributele din relatia asupra careia se aplica interogarea, în ordinea în care au fost definite în aceastã relatie (in locul acestei liste se poate utiliza semnul "*");

expresii formate din urmatoarele elemente:

-atribute şi operatori aritmetici (de exemplu: cantitate*pret_unitar)

-functii standard (de exemplu CTOD( ));

-constante;

-variabile de memorie.

expresii care contin functii SQL agregat cum ar fi AVG( ), MAX( ), MIN( ), COUNT( ), SUM( ) ...

In exemplele de mai sus, pentru a evita repetarea unor informatii in tabelele rezultat se poate utiliza cuvintul cheie DISTINCT. Optiunea DISTINCT permite eliminarea tuplelor duplicat. In acest mod numai prima aparitie a unui tuplu este afisatã în tabela-rezultat.

EXEMPLU:

"Sa se afiseze toate orasele resedinte ale furnizorilor, dar sa apara fiecare oras o singura data in tabela-rezultat"

SELECT DISTINCT orasFROM furnizori

Aceasta interogare va avea ca rezultat o tabela care contine toate orasele in care isi au resedinta furnizorii din tabela FURNIZORI, dar fiecare oras va fi afisat o singura data.

Optiunea ALL permite dimpotrivã, afisarea tuplelor-duplicat. Aceastã optiune este implicitã.

Clauza FROM are forma generala:

FROM <<nume relatie>/ <nume view>[<alias>] ... >

si specifica relatiile (pot fi şi nume de view) din care vor fi regãsite datele. In cazul în care se operazã cu mai multe tabele, este utilã atribuirea unor prescurtãri, (numite alias) numelor de tabele ce vor fi utilizate în interogare.

EXEMPLE:

1) "Sa se afiseze codurile furnizorilor şi numerele de comanda corespunzatoare pentru toti furnizorii care a cel putin o comanda"

SELECT 1.cod_furnizor, B.numar_comandaFROM furnizori 1, comenzi BWHERE 1.cod_furnizor=B.cod_furnizor

2) "Sa se afiseze codurile furnizorilor, numele furnizorilor, cantitatile, şi numerele comenzilor pentru toti furnizorii care au cel putin o comanda"

53

SELECT A.cod_furnizor, nume_furnizor, cantitate, numar_comandaFROM furnizori A, comenzi BWHERE A.cod_furnizor=B.cod_furnizor

A se observa ca in al doilea exemplu nu s-a mai utilizat notatia cu alias pentru atributul numar_comanda din tabela comenzi deoarece nu este pericol de confuzie. In schimb s-a utilizat notatia pentru a deosebi atributul cod_furnizor din tabela furnizori de atributul cu acelasi nume din tabela comenzi.

Pentru a restrange tuplele ce apar în tabela-rezultat, se specificã o conditie de cãutare prin utilizarea unui predicat de selectie in clauza WHERE.

Clauza WHERE are forma generala:

WHERE <predicat> / <expresie>;

Numai tuplele care satisfac predicatul de selectie vor fi incluse in tabela-rezultat. Predicatul de cãutare poate fi specificat printr-o conditie logica in care se utilizeaza urmatoarele elemente:

operatori:

- aritmetici: + - / * ** ^

- relaţionali: < > <= >= <> != =

- logici: NOT AND OR

- operatori SQL: IN, EXISTS, ALL, ANY

sub-interogãri (exprimate prin interogari SQL),cu observatia cã acestea vor fi primele evaluate şi tabela-rezultat trebuie sã corespundã operatorilor ce i se aplicã în continuare.

Operatorii aritmetici

Acesti operatori sunt binecunoscuti şi mentionam aici doar faptul ca şi ** şi ^ reprezinta ridicarea la putere.

Ca operanzi, se pot utiliza atribute, constante, functii sau expresii algebrice. Expresiile algebrice pot aparea in clauzele SELECT sau WHERE.

EXEMPLU:

"Sa se afiseze codul produsului şi valoarea pe care o reprezinta cantitatea de produs comandata la diversi furnizori"

SELECT cod_produs, cantitate*pret_unitarFROM comenziWHERE cantitate<>0

Operatorii relaţionali

< mai mic> mai mare

54

! negarea operatorilor <, >, =. Se obtin operatorii: !=(diferit), !<(nu mai mic), !>(nu mai mare).

<= mai mic sau egal=> mai mare sau egal<> diferit

Facem observatia că valorile comparate trebuie să apartină unor tipuri de date compatibile (care se pot compara intre ele).

EXEMPLU:

"Sa se afiseze codurile plantelor de culoare alba."

SELECT cod-produsFROM floriWHERE culoare='alb'

Operatorii logici

Dacã o clauzã WHERE contine mai multe conditii formate prin utilizarea aceluiasi tip de oparator logic, evaluarea se va face de la stanga la dreapta. tipul de operator logic este dat de precedenta operatorilor. Operatorul NOT are cea mai mare prioritate, urmat de AND şi OR care practic sunt de prioritati egale.

Pentru a schimba ordinea de evaluare a unei expresii se utilizeazã parantezele rotunde ().

EXEMPLE:

1) "Sa se afiseze numele plantelor de culoare alba şi de inaltime minima 50 cm"

SELECT nume_plantaFROM floriWHERE culoare='alb' AND inaltime<50

2) "Sa se afiseze numele, culoarea şi inaltimea plantelor care fie au culoarea alba fie sunt de inaltime mai mica de 50 cm"

SELECT nume_planta, culoare, inaltimeFROM floriWHERE culoare='alb' OR inaltime<50

3) A se observa ca ultima interogare este echivalenta cu interogarea

SELECT nume_planta, culoare, inaltimeFROM floriWHERE culoare='alb' OR NOT inaltime>=50

55

4.2.2. Ordonarea tuplelor (clauza ORDER BY)

În exemplele anterioare, tuplele tabelei-rezultat apar în aceeasi ordine în care au fost introduse. Pentru modificarea ordinii de afisare se utilizeazã clauza ORDER BY. Forma generala a acestei clauze este:

ORDER BY <(<nume atribut>/<numãr întreg>)(ASC/ DESC)>,...

Tuplele sunt ordonate în mod implicit în ordine ascendentã (ASC). Ordinea este: 0,...,9,A,...,Z,a,...,z conform codului ASCII. Afisarea în ordine descrescãtoare se poate face prin utilizarea optiunii DESC.

EXEMPLU:

"Sa se afiseze datele despre florile din evidente in ordinea alfabetica a numelor florilor."

SELECT *FROM floriORDER BY nume_planta, ASC

A se observa ca daca ar fi lipsit mentiunea ASC, ordinea tuplelor ar fi fost aceeasi deoarece ordinea ascendenta este implicita.

În loc de precizarea numelui atributului dupã care se face ordonarea, se poate preciza pozitia atributului în lista de atribute specificate în comanda SELECT.

EXEMPLU:

SELECT oras, cod_furnizor, nume_furnizorFROM furnizoriORDER BY 1 DESC, 3 ASC

In urma executiei interogarii se va obtine o tabela cu numele oraselor sortate descrescator şi pentru fiecare oras, codurile furnizorilor şi apoi numele funizorilor in ordine alfabetica.

Operatorul IN permite simplificarea predicatului de cãutare. Predicatul IN testeazã dacã valoarea unui atribut specificat în lista de atribute din clauza WHERE se potriveste uneia din valorile listei specificate în predicatul IN (testeazã apartenenta la o multime).

EXEMPLU:

"Sa se afiseze toate datele despre furnizorii care au sediul in Bucuresti sau in Brasov sau in Cluj"

SELECT *FROM furnizoriWHERE oras IN ('BUCURESTI', 'BRASOV', 'CLUJ')

Functii standard

Functiile standard, cunoscute şi sub numele de functii agregat, apar in clauza SELECT şi se aplica atributelor din tabelele implicate in interogare. Functii standard sunt:

56

-valoarea medie - AVG

-valoarea minima - MIN

-valoarea maxima - MAX

-total(sumare) - SUM

-numãrãtoare - COUNT

NOTA: Nu este permisa utilizarea acestor functii in clauza WHERE deoarece ele actioneaza la nivel de atribut şi nu la nivel de tuplu.

EXEMPLE:

1) "Care este cantitatea minima comandata?"

SELECT MIN(cantitate)FROM comenzi

Spre exemplu,urmãtoarea interogare are ca rezultat afisarea cantitãtii totale şi a numãrului de produse din fisierul de comenzi.

SELECT SUM(cantitate), COUNT(*)FROM comenzi

2) "Care este cantitatea medie comandata?"

SELECT AVG(cantitate)FROM comenzi

3) "Care este cantitatea totala comandata din planta cu cod '202'?"

SELECT SUM(cantitate)FROM comenziWHERE cod_produs='202'

4) "Cate tuple contine tabela de flori?"

SELECT COUNT(*)FROM flori

5) "Cate culori de flori sunt inregistrate pentru florile din fisier?"

SELECT COUNT(DISTINCT culoare)FROM flori

4.2.3. Gruparea rezultatelor (clauza GROUP BY)

În multe cazuri, utilizatorul doreste anumite situatii sintetice, cum ar fi obtinerea de totaluri şi subtotaluri. Pentru aceaste operatii, limbajul SQL permite utilizarea clauzelor GROUP BY şi HAVING. Aceste clauze organizeazã tuplele în grupuri asupra cãrora se pot realiza anumite operatii, în special prin aplicarea functiilor agregat.

57

Clauza GROUP BY grupeazã tuplele din relatie dupã atributele cu aceeasi valoare care sunt specificate în clauzã, şi generezã un singur tuplu pentru fiecare grup de tuple cu aceeasi valoare pe atribut.

Atributele care apar în clauza SELECT pot fi de douã feluri:

- atribute care alcãtuiesc baza pentru grupare (cele care apar în clauza GROUP BY)

- atribute care nu participa la gruparea rezultatelor.

EXEMPLU:

1) "In ce orase exista furnizori ai florariei?"

SELECT orasFROM furnizoriGROUP BY oras

In urma executarii interogarii vor apare orasele din fisierul de furnizori listate o singura data.

2) "Cati furnizori au sediul in fiecare oras?"

SELECT oras, COUNT(*)FROM furnizoriGROUP BY oras

3) "In care orase locuiesc cel putin 3 furnizori?"

SELECT oras, COUNT(*)FROM furnizoriGROUP BY orasHAVING COUNT(*)>=3

Clauza GROUP BY se poate folosi şi cu clauzele ORDER BY şi WHERE.

EXEMPLE:

1) "Sa se afiseze in ordine alfabetica orasele in care exista furnizori ai florariei". (A se observa ca interogarea este asemanatoare cu interogarea 1) din exemplele anterioare. Diferenta consta in faptul ca lista de orase va fi ordonata alfabetic dupa numele oraselor.)

SELECT orasFROM furnizoriGROUP BY orasORDER BY oras

2) "Care furnizori livreaza in interval de cel mult 17 zile?"

SELECT cod_furnizorFROM comenziWHERE timp_livrare<17GROUP BY cod_furnizor

58

4.2.4. Interogari pe mai multe tabele

Una dintre operatiile cele mai frecvente realizate cu mai multe tabele este jonctiunea sau produsul cartezian. Jonctiunea aminteste de operatiile din algebra relaţionala şi chiar este posibil de realizat (urmand anumite structuri ale interogarii SQL) oricare dintre tipurile de jonctiune prezentate teoretic in cadrul algebrei relaţionale. Se pot de asemenea realiza operatii ca reuniunea, intersectia şi diferenta. Sintaxa interogarii SQL difera de la un SGBD la altul dar sub o forma directa sau printr-o constructie sintactica specifica se pot realiza oricare dintre operatiile amintite.

EXEMPLE:

1) "Sa se afiseze codurile furnizorilor, numele furnizorilor, cantitatile comandate şi numerele comenzilor"

SELECT 1.cod_furnizor, nume_furnizor, cantitate, nr_comandaFROM furnizori 1, comenzi bWHERE 1.cod_furnizor=b.cod_furnizor

A se observa scrierea cu notarea tuplelor care apartin fiecarei tabele pentru a evita orice confuzie in legatura cu tabela din care se va extrage informatia. Exista doua atribute in tabele diferite care au acelasi nume: atributele cod_furnizor. Modul de notare de mai sus este acceptat de sintaxa SQL şi diferentiaza atributul cod_furnizor din tabela furnizori de atributul cod_furnizor din tabela comenzi.

2) "Sa se afiseze datele de mai sus dar numai pentru furnizorii care au adresa in Brasov"

SELECT 1.cod_furnizor, nume_furnizor, cantitate, nr_comandaFROM furnizori 1, comenzi bWHERE 1.cod_furnizor=b.cod_furnizor AND oras='Brasov'

3) "Ce flori au aceeasi inaltime cu laleaua?" A se observa ca aceasta interogare necesita realizarea produsului cartezian al tabelei FLORI cu ea insasi.

SELECT p1.nume_planta, p2.nume_planta, p1.inaltime, p2.inaltimeFROM flori p1, flori p2WHERE p1.inaltime=p2.inaltime AND p2.nume_planta='LALEA'

Clauza UNION

Clauza UNION permite realizarea reuniunii de tabele. In cazul cand dorim sa reunim doua sau mai multe tabele, este obligatoriu ca acestea sa fie descrise de scheme de relatie identice (acelasi numar de atribute şi corespunzator – de la stanga la dreapta – atributele din tabele au acelasi nume şi aceeasi descriere). Aceste conditii sunt impuse tabelelor implicate in operatiile intersectie şi minus (diferenta). Operatiile reuniune, intersectie şi diferenta de tabele actioneaza analog cu aceleasi operatii aplicate la multimi.

59

Forma generala a reuniunii de tabele este:

SELECT A1 ,…, AmFROM [WHERE …]UNION

SELECT A1 ,…, AmFROM …[WHERE …]

EXEMPLE:

1) "Sa se afiseze numele plantelor şi codurile plantelor care au inaltimea fie mai mica decat 20 cm fie mai mare decat 50 cm."

SELECT nume_planta, cod_produsFROM floriWHERE culoare='alb' AND inaltime<20UNION

(SELECT nume_planta, cod_produsFROM floriWHERE culoare='alb' AND inaltime>50)

4.2.5. Subinterogari (clauze SELECT imbricate)

Unul din motivele pentru care SQL este considerat un limbaj puternic de interogare este acela cã oferã posibilitatea construirii interogãrilor complexe, formate din mai multe subinterogãri simple.

Aceste interogãri complexe sunt construite prin includerea în clauza WHERE a inca unei clauze SELECT. Forma generala a unei astfel de constructii este:

SELECT < lista atribute1 >FROM < lista relatii1 > WHERE < subinterogare >

Se observa ca aceasta constructie a fost deja utilizata in exemplul de mai sus care ilustreaza o clauza UNION.

In constructia de mai sus clauza SELECT interioarã genereazã valorile pentru conditia de cãutare a clauzei SELECT exterioare care o contine. Clauza SELECT exterioarã genereazã o relatie pe baza valorilor generate de cãtre clauza interioarã. Modul de constuire a interogãrii exterioare depinde de numãrul valorilor returnate de cãtre interogarea interioarã .În acest sens, putem distinge:

- subinterogãri care returneazã o singurã valoare

- subinterogãri care returneazã mai multe valori.

Din punctul de vedere al ordinii de evaluare al interogãrilor putem distinge:

subinterogãri simple

60

Interogarea interioarã este evaluatã prima, independent de interogarea exterioarã. Rezultatul evaluãrii interogãrii interioare este utilizat de cãtre interogarea exterioarã .

subinterogãri corelate

Valorile returnate de cãtre interogarea interioarã depind de valorile returnate de cãtre interogarea exterioarã. Interogarea interioarã este evaluatã repetat pentru fiecare tuplu cercetat de interogarea exterioara.

Subinterogãri simple care returnezã o singurã valoare

Aceste interogãri au urmãtoarea sintaxã:

SELECT < lista atribute >FROM < lista relatii > WHERE < atribut > (< subinterogare >)

unde este un operator relaţional: = < > >= <= !=

Vom considera urmãtorul exemplu:

EXEMPLU:

1) "Sã se afiseze numele plantelor care au inaltimea egala cu cea a lalelei".

SELECT nume_plantaFROM floriWHERE inaltime=

(SELECT inaltimeFROM floriWHERE nume_planta='LALEA')

Aceeasi interogare poate oferi lista numelor de plante in ordine alfabetica inversa daca se utilizeaza şi o clauza ORDER BY.

SELECT nume_plantaFROM floriWHERE inaltime=

(SELECT inaltimeFROM floriWHERE nume_planta='LALEA')ORDER BY nume_planta DESC

Procesul de evaluare a acestei interogãri se desfãsoarã astfel:

Se evalueazã în primul rînd interogarea interioarã. Conditia de evaluare a interogãrii interioare este nume_planta='LALEA'.

Valoarea obtinuta pentru atributul inaltime (sa presupunem ca laleaua are 30 cm) este stocata într-o tabela temporara. Rezultatul evaluãrii interogãrii interioare devine conditie de cãutare pentru interogarea exterioarã, care ar putea fi exprimata in aceasta faza ca:

SELECT nume_plantaFORM flori

61

WHERE inaltime=30

In urma executarii interogarii exterioare este creatã o relatie finalã, ce va contine tuplele a cãror inaltime este aceeasi cu valoarea stocata în tabela temporarã.

Interogarea interioarã poate contine în clauza WHERE şi conditii complexe, formate prin utilizarea operatorilor logici (NOT, AND, OR) şi a functiilor agregat (AVG, MAX, …).

EXEMPLU:

"Sa se afiseze numele plantelor care au inaltimea minima"

SELECT nume_plantaFORM floriWHERE inaltime=

(SELECT MIN(inaltime)FROM flori)

Subinterogãri simple care returnezã mai multe valori

Principiul de construire a acestui tip de interogare imbricatã utilizeazã în clauza WHERE conditii, care evaluate, genereazã o multime de valori. In aceastã categorie intrã operatorii (NOT) IN, (NOT) ANY, (NOT) ALL, (NOT) EXISTS.

EXEMPLE:

1) "Care furnizori mai au inca de executat livrari?"

SELECT nume_furnizorFROM furnizoriWHERE cod_furnizor IN

(SELECT cod_furnizorFROM comenziGROUP BY cod_furnizor)

2) "Care furnizori, dintre furnizorii obisnuiti ai florariei, nu mai au nimic de livrat?"

SELECT nume_furnizorFROM furnizoriWHERE cod_furnizor NOT IN

(SELECT cod_furnizorFROM comenziGROUP BY cod_furnizor)

A se observa ca cele doua interogari difera doar prin operatorul logic NOT. De asemenea se poate remarca faptul ca prima interogare aminteste de apartenenta din teoria multimilor iar a doua interogare corespunde operatiei minus (diferenta). Daca versiunea SQL nu are un cuvant rezervat pentru operatia diferenta intre tabele, se poate constru aceasta operatie cu ajutorul preicatului NOT IN ca in exemplul de mai sus.

62

3) "Care furnizori au numarul maxim de comenzi de flori?"

SELECT nume_furnizorFROM furnizoriWHERE cod_furnizor IN

(SELECT cod_furnizorFROM comenziGROUP BY cod_furnizorHAVING COUNT(*)=

(SELECT MAX(COUNT(cod_furnizor))FROM comenziGROUP BY cod_furnizor))

Subinterogãri corelate

În exemplele de panã acum, interogarea interioarã era evaluatã prima, dupã care valoarea sau valorile rezultate erau utilizate de cãtre clauza WHERE din interogarea exterioarã.

Exista şi o alt forma de subinterogare şi anume subinterogarea corelatã, caz în care interogarea exterioarã transmite repetat cîte o valoare pentru interogarea interioarã.

De fiecare datã cînd este transmisã o valoare, este evaluatã interogarea interioarã. Dacã ambele interogãri acceseazã acelasi tabel, trebuie asigurate alias-uri pentru fiecare referintã la tabelul respectiv. Ambele interogãri accesezã tuple diferite din acelasi tabel în acelasi moment.

EXEMPLU:

"Sa se afiseze culoarea, inaltimea şi numele plantelor pentru plantele cu inaltimea maxima, ordonate dupa culoare"

SELECT culoare, inaltime, nume_plantaFROM flori fWHERE inaltime=

(SELECT MAX(inaltime)FROM floriWHERE culoare=f.culoare)

ORDER BY culoare

A se observa ca şi interogarea anterioara se poate incadra in cazul ilustrat de exemplul de mai sus.

4.2.6. Operatorii ANY şi ALL

Operatorul ANY poate fi utilizat în combinatie cu oricare dintre operatorii relaţionali (= < > >= <= !=) pentru a se verifica dacã valoarea unui atribut este egala, mai mica, mai mare, etc…decat oricare dintre valorile mentionate odata cu operatorul. Urmãtoarele predicate sunt echivalente :

= ANY si IN

63

!= ANY si NOT IN

Operatorul ALL returneazã tuplele pentru care valorile atributului din clauza WHERE sunt mai mici, mai mari, mai mici sau egale, etc. … decat toate valorile generate de interogarea interioarã. Sã facem observatia cã acest operator nu poate fi utilizat cu operatorul relaţional =, ceea ce ar corespunde cazului banal în care toate valorile din listã sunt identice:

Pentru a stabili mai exact modul in care se selecteaza valorile cu operatorii ANY şi ALL dam mai jos o serie de cazuri concrete.

Sa presupunem ca interogarea este de forma:

SELECT …FROM …WHERE x < ALL (1, 2, 3, 4)

Sa observam ca daca inlocuim operatorul ALL cu expresia verbala toate putem citi "Valorile lui x trebuie sa fie mai mici decat toate valorile din paranteza ce urmeaza dupa ALL."

Atunci vom lua in considerare urmatoarele situatii:

Expresia din clauza WHERE Valori ale lui x care corespund

x < ALL 0, -1, -2, …

x <= ALL 1, 0, -1, -2, …

x > ALL 5, 6, 7, …

x >= ALL 4, 5, 6, ..

Daca vom studia o interogare de forma:

SELECT …FROM …WHERE x < ANY (1, 2, 3, 4)

Sa observam ca daca inlocuim operatorul ANY cu expresia verbala oricare putem citi "Valorile lui x trebuie sa fie mai mici decat oricare dintre valorile din paranteza ce urmeaza dupa ALL."

Vom lua in considerare urmatorul tabel:

Expresia din clauza WHERE Valori ale lui x care corespund

x < ANY 3, 2, 1, 0, -1, -2, …

x <= ANY 4, 3, 2, 1, 0, -1, -2, …

x > ANY 2, 3, 4, 5, 6, 7, …

x >= ANY 1, 2, 3, 4, 5, 6, ..

EXEMPLE:

64

1) "Sa se afiseze numele plantelor, pretul unitar şi culoarea pentru plantele care au minim 50 cm inaltime şi pretul minim din grupul de plante de inaltime sub 50 cm"

SELECT nume_planta, pret_unitar, culoareFROM floriWHERE pret_unitar<ALL

(SELECT pret_unitarFROM floriWHERE inaltime>=50)

2) "Sa se afiseze numele plantelor şi pretul unitar pentru plante mai mari de 50 cm, din care se exclude cea mai scumpa planta"

SELECT nume_planta, pret_unitarFROM floriWHERE inaltime>=50 AND pret_unitar<ANY

(SELECT pret_unitarFROM floriWHERE inaltime>=50)

3) "Sa se afiseze numele plantei şi pretul unitar pentru planta cea mai scumpa cu inaltimea mai mare sau egala cu 50 cm"

SELECT nume_planta, pret_unitarFROM floriWHERE inaltime>=50 AND NOT pret_unitar<ANY

(SELECT pret_unitarFROM floriWHERE inaltime>=50)

4.2.7. Operatorul EXISTS

Operatorul EXISTS verificã dacã pentru fiecare tuplu al relatiei existã tuple care satisfac conditia interogãrii interioare. In cazul în care existã asemenea tuple, EXISTS ia valoarea de adevãr TRUE. Astfel, operatorul EXISTS permite specificarea mai multor atribute în interogarea interioarã. Acest lucru este posibil deoarece nu se verificã valoarea unui anumit atribut ca în cazurile anterioare, ci se genereazã o valoare de adevãr (TRUE sau FALSE), dupã cum existã sau nu existã o anumitã valoare într-o relatie diferitã de cea utilizatã în interogarea exterioarã.

Ca şi operatorii ANY şi ALL, operatorul EXISTS apare in clauza WHERE.

EXEMPLU: "Care plante au un pret unitar egal sau mai mic cu cea mai ieftina planta de culoare alba?"

SELECT nume_planta, pret_unitar, culoareFROM flori fWHERE NOT EXISTS(SELECT *FROM flori

65

WHERE culoare='alb' AND pret_unitar>f.pret_unitar)

Interogarea SELECT interioarã defineste o tabela care contine acele tuple pentru care se verifica conditia din clauza WHERE interna. Daca nu exista nici o planta de culoare alba şi care sa aiba pretul unitar mai mare decat pretul unitar din tuplul curent, conditia NOT EXISTS este evaluatã la valoarea logica TRUE.

Exerciţii recapitulative

Se dau următoarele relaţii cu schemele lor:-Scări (Nr_bloc, Scara, Lift)-Apartamente(Nr_bloc,Scara,Apartament,Suprafaţa,Cutii_poştale, Nr_prize_tv)- Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)-Locatari

Nr_Mat, Nr_bloc, Scara, Etaj, Apartament,Nume

Să se exprime în SQL cererile:7) (tabel nominal cu locatarii de pe scara = 3 din bloc = 34) = R18) (tabel nominal cu locatarii de pe scara = 1 din bloc = 34) = R29) (tabel nominal cu locatarii de pe scara = 2 din bloc = 34) = R310) tabel nominal cu locatarii de pe scările 1,2,3 ale blocului 3411) lista apartamentelor cu suprafaţa mai mare decât 50 mp12) tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 şi nu

locuiesc şi pe scara 1 a aceluiaşi blocRăspunsuri la exerciţii

1) select numefrom scari, locatariwhere (scari.bloc=34) and(scari.bloc = locatari.bloc) and (scari.scara=3) and (scari.scara= locatar.scara)

2) select numefrom scari, locatariwhere (scari.bloc=34) and(scari.bloc = locatari.bloc)

and (scari.scara=1) and (scari.scara= locatar.scara)3) select nume

from scari, locatariwhere (scari.bloc=34) and(scari.bloc = locatari.bloc)

and (scari.scara=2) and (scari.scara= locatar.scara)4) select nume

from scari, locatariwhere (scari.bloc=34) and(scari.bloc = locatari.bloc)

and (scari.scara=3) and (scari.scara= locatar.scara)union select nume

from scari, locatariwhere (scari.bloc=34) and(scari.bloc = locatari.bloc)

and (scari.scara=1) and (scari.scara= locatar.scara)union select nume

from scari, locatari

66

where (scari.bloc=34) and(scari.bloc = locatari.bloc) and (scari.scara=2) and (scari.scara= locatar.scara)

5) select Nr_bloc,Scara,Apartamentfrom apartamentewhere suprafaţa > 50

6) select numefrom scari, locatariwhere (scari.bloc=34) and(scari.bloc = locatari.bloc) and (scari.scara=3) and (scari.scara= locatar.scara)and not in ( select nume

from scari, locatariwhere (scari.bloc=34) and(scari.bloc

locatari.bloc) and (scari.scara=1) and (scari.scara= locatar.scara))

Capitolul 5 Normalizarea

5.1. Redundanta informatiilor şi anomalii la actualizare

La proiectarea unei baze de date, un obiectiv foarte important, care trebuie urmarit cand se gandeste un model de date, este realizarea unei reprezentari corecte a datelor, a relatiilor dintre date şi a restrictiilor impuse asupra datelor. Pentru realizarea acestui obiectiv se utilizeaza tehnica normalizarii, care are ca scop principal identificarea setului celui mai adecvat de relatii care sa modeleze realitatea dorita.

Procesul de normalizare a fost introdus de E. F. Codd (1972). Iniţial s-au propus trei forme normale, notate 1NF, 2NF, respectiv 3NF. Mai târziu, prin enuntarea unei definitii mai tari a formei normale trei, s-a obtinut forma Boyce-Codd, după numele celor care au introdus aceasta forma normala: R. Boyce şi E. F. Codd (1974). Toate aceste forme normale se bazeaza pe dependentele functionale stabilite intre atributele unei relatii.

Formele normale cele mai folosite sunt: forma normală 3 şi forma normală Boyce-Codd. Există şi forme normale mai tari - forma normală 4 (4NF) şi forma normală 5 (5NF) - dar acestea se folosesc foarte rar.

Procesul de normalizare este o metodă formală care identifica relaţiile bazandu-se pe cheile primare ale acestora (sau pe cheile candidat în cazul BCNF) şi pe dependenţele funcţionale care exista intre atributele acestor relatii. Normalizarea sprijina proiectantul bazei de date, dandu-i posibilitatea sa aplice o serie de teste asupra relatiilor individuale, asa incat schema relaţionala poate fi normalizata la forma normala dorita, pentru a se preveni aparitia anomaliilor la actualizare.

Pentru a ilustra procesul de normalizare, vom utiliza exemple din sistemul

67

informatic Asociatie de locatari.

Partea cea mai importantă la proiectarea bazei de date este gruparea atributelor în relaţii cu scopul de a minimiza redundanţa informaţiilor şi (odata cu aceasta) spaţiul ocupat de relatii (tabele sau fişiere) pe suportul magnetic.

Fie relaţia Furnizori_Cheltuieli exemplificată mai jos. In exemple se vor simplifica numele atributelor.

Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt DataValoare

F100 Romgaz R1234567 C15 Incalzire 30.06.99 2,150,000

F100 Romgaz R1234567 C16 Apa calda 30.06.99 500,000

F110 Renel R7654321 C10 Iluminat 30.06.99 3,000,000

F110 Renel R7654321 C11 Lift 30.06.99 200,000

Figura 5.1. Relaţia Furnizori_Cheltuieli

Sa presupunem ca aplicaţia pe care o vom studia ca exemplu contine datele organizate intr-o singura relatie descrisa de urmatoarele schema de relatie:

Furnizori_Cheltuieli = (Cod_furn, Den_furn, Cod_fiscal, Cod_chelt, Den_chelt, Data, Valoare)

Dintre atribute, cele evidentiate constituie cheia primara pentru relatia respectiva. Relatia Furnizori_Cheltuieli are cheia compusa din atributele Cod_furn, Cod_Chelt şi Data. Datele sunt prost organizate in relatia prezentata.

Informaţia despre furnizori din relatia Furnizori_Cheltuieli este redundantă. Detaliile despre furnizor se repetă la fiecare introducere a unei cheltuieli noi.

Nu este insa singura problema pe care o organizare nepotrivita a datelor o poate genera.

O altă consecinta a redundanţei informatiilor din baza de date, o reprezinta problemele de actualizare a informaţiei stocate. Enumeram mai jos o parte dintre acestea.

Anomalii de adaugare

Anomaliile de inserare se pot clasifica în două tipuri:

Pentru a adauga detaliile despre o cheltuială către un furnizor, în relaţia Furnizori_Cheltuieli trebuie obligatoriu adăugate şi detaliile despre furnizorul în cauză, chiar dacă ele există deja în baza de date. Această anomalie poate duce la apariţia de informatii diferite despre acelasi furnizor

68

în înregistrări diferite. Informatia despre furnizor isi pierde in acest mod consistenta, nu ne mai putem baza pe corectitudinea datelor despre furnizor in baza de date.

Pentru a adăuga detalii despre un furnizor nou în relaţia Furnizori_Cheltuieli, trebuie neapărat adăugată şi o cheltuială pentru asociaţia de locatari către acel furnizor. În cazul în care încă nu a sosit factura de la furnizor, nu se poate înregistra nici o cheltuială şi deci trebuie introduse valori nule. Este nerecomandabil sa se lucreze cu valori nule deoarece se genereaza probleme la regasirea şi actualizarea informatiilor.

Anomalii de ştergere

În cazul ştergerii unei cheltuieli a asociaţiei de locatari către un furnizor nou (tot in cadrul relatiei Furnizori_Cheltuieli ), se va şterge şi furnizorul. Deci toate detaliile introduse despre acel furnizor vor fi pierdute, ceea ce duce la obligativitatea reintroducerii datelor la o nouă folosire al acelui furnizor.

Anomalii de modificare

Dacă în relaţia Furnizori_Cheltuieli dorim să schimbăm valoarea unui atribut al unui furnizor, va trebui să schimbăm datele pentru fiecare apariţie a acelui furnizor. De exemplu dacă dorim să schimbăm codul fiscal al furnizorului cu codul F100, va trebui să schimbăm acest atribut în toate tuplele in care apare furnizorul F100. Din nou, este posibil ca datele sa nu fie modificate corect. Este posibil sa ramana tuple cu datele nemodificate sau este posibil sa se modifice datele respective cu valori diferite in locuri diferite. (Nu dorim sa insistam asupra cauzelor care pot duce la aceste situatii.).

Anomaliile enumerate mai sus se pot evita prin folosirea (in acest caz) a două relatii distincte: Cheltuieli şi Furnizori. În acest caz dacă trebuie modificat un atribut al unui furnizor, modificarea se va xecuta intr-un singur loc în relatia Furnizori. Asemanator, daca e necesara o stergere in relatia Cheltuieli, aceasta nu va mai afecta furnizorii din relatia Furnizori. De asemenea orice cheltuiala adaugata şi orice furnizor nou adaugat nu se vor mai conditiona reciproc in nici un fel.

Descompuneri cu pierderi de informatii

In urma analizarii anomaliilor de actualizare prezentate mai sus am tras concluzia ca o descompunere a relatiilor care ne fac probleme este binevenita şi duce la rezolvarea problemelor. Este bine insa sa tratam descompunerile de relatii cu prudenta deoarece o descompunere neglijenta ne poate crea probleme la fel de mari cu acelea de care tocmai ne-am ocupat. Este posibil sa pierdem informatii daca nu suntem atenti la modul in care se realizeaza descompunerea.

In general se poate urmari ca in fiecare relatie sa se reprezinte informatii despre o singura multime-entitate. Criteriul este mai mult de ordin intuitiv şi el nu ne este de mare ajutor in cazul reprezentarii multimilor-relatie. In acest caz, intr-o relatie se intalnesc date despre mai multe multimi-entitate. Este necesar sa se stabileasca o modalitate riguroasa de a decide care sunt informatiile care

69

trebuie sa alcatuiasca o astfel de relatie.

Orice relatie se construieste pe baza unei scheme de relatie. Fie R o schema oarecare de relatie. Un set de scheme de relatie reprezinta o descompunere a lui R şi se noteaza {R1, R2, …, Rn} daca

= R

Aceasta inseamna ca orice atribut din schema de relatie initiala R se regaseste in cel putin o schema de relatie din descompunere. Daca ne raportam la relatiile care se bazeaza pe schemele de mai sus, fie r relatia construita pe schema R sie fie relatiile r1, r2, …, rn construite pe schemele de relatie ce formeaza descompunerea. In termenii algebrei relaţionale se poate considera egalitatea;

ri = pentru toti 1in.

Deci fiecare ri este proiectia relatiei r pe atributele care apar in schema de relatie Ri.

Descompunerile cu pierderi de informatii se pot clasifica in Descompuneri cu pierderi la jonctiune şi Descompuneri cu pierderea dependentelor. Pentru a clarifica lucrurile in aceasta directie este necesara mai intai definirea notiunii de dependenta functionala.

5.2. Dependenţe funcţionale

Unul din cele mai importante concepte asociate cu normalizarea este conceptul de dependenţă funcţională. Dependenţa funcţională descrie un anumit tip de legatura care se stabileste intre atributele aceleiasi relatii.

Fie o schema de relatie R şi fie submultimile de atribute A şi B din R. Se verifica AR şi BR. Spunem ca B depinde functional de A şi scriem AB daca pentru orice relatie legala r, construita pe schema de relatie R, se verifica urmatoarea situatie:

pentru orice pereche de tuple t1 şi t2 din r, pentru care t1[A]=t2[A], are loc intotdeauna şi t1[B]=t2[B].

Aceasta inseamna ca atunci cand un tuplu t1 are (pe submultimea de atribute A) aceeasi valoare cu alt tuplu t2, obligatoriu cele doua tuple vor avea aceeasi valoare şi pe submultimea de atribute B. Valorile din B sunt in mod unic determinate de valorile din A.

Numim determinant al unei dependente funcţionale, atributul, sau mulţimea atributelor din partea stângă a săgeţii.

O parte dintre dependenţele funcţionale pentru relaţia Furnizori_Cheltuieli sunt:

Cod_furn Den_furn

Cod_furn Cod_fiscal

70

Cod_chelt Den_chelt

Cod_chelt, Cod_furn, Data Valoare

Numele furnizorului este determinat in mod unic de codul furnizorului. La coduri egale, numele sunt identice.

Valoarea insa nu poate fi determinata in mod unic decat de combinatia cod cheltuiala, cod furnizor şi data. Intr-o anume data, un anumit furnizor, pentru un anumit serviciu (care duce la un anume cod cheltuiala) cere o suma bine determinata de bani. Nici una dintre valori nu poate determina valoarea şi nici in combinatii de cate doua. Daca nu se iau cele trei informatii impreuna se pot crea confuzii in legatura cu valoarea. (Acelasi cod de cheltuiala poate corespunde la valori diferite in date diferite. Acelasi furnizor poate avea chiar şi coduri de cheltuiala diferite darmite valoarea care le reprezinta, s.a.m.d. …)

Notiunea de dependenta functionala generalizeaza notiune de cheie. Se poate da urmatoarea definitie a supercheii:

Spunem ca submultimea deatribute K din schema de relatie R este o supercheie daca KR, adica pentru orice pereche de tuple t1 şi t2 din r, pentru care t1[K]=t2[K], are loc intotdeauna şi t1[R]=t2[R].

Dependentele functionale ne permit sa exprimam restrictii asupra relatiilor pe care nu le putem exprima cu ajutorul cheilor. Dependenţa funcţională este o proprietate legata de semantica atributelor în relaţii. Dependentele functionale pot fi stabilite de cine cunoaste exact legaturile intre valorile atributelor, deci de catre cineva care cunoaste foarte bine aplicaţia şi semnificatia informatiilor din relatii.

Nu se pot da retete pentru stabilirea dependentelor functionale, dar se pot da metode de a determina toate dependentele functionale dintr-o relatie daca se cunosc cateva dependente de la care poate porni algoritmul.

O metoda de a determina multimea tuturor dependentelor functionale dintr-o relatie se bazeaza pe asa-numitele Axiome ale lui Armstrong.

Regulile (Axiomele) lui Armstrong:

1) regula reflexivitatii – daca X este un subset de atribute din R şi YX, atunci are loc XY;

2) regula creşterii – daca X, Y şi W sunt subseturi de atribute din R şi daca XY atunc WXWY;

3) regula tranzitivitatii – daca X, Y şi Z sunt subseturi de atribute din R şi daca XY şi YZ atunci are loc şi XZ.

Cele trei reguli sunt suficiente şi formeaza un set complet pentru a se putea determina toate dependentele functionale daca se porneste de la un set de baza initial. Totusi se mai utilizeaza in mod obisnuit şi reguli suplimentare (care pot fi deduse din primele trei) deoarece usureaza calculele.

Astfel:

71

4) regula reuniunii – daca X, Y şi Z sunt subseturi de atribute din R şi daca XY şi XZ atunci şi XYZ;

5) regula descompunerii – daca daca X, Y şi Z sunt subseturi de atribute din R şi daca XYZ atunci au loc şi XY şi XZ;

6) regula pseudotranzitivitatii - daca X, Y, W şi Z sunt subseturi de atribute din R şi daca XY şi WYZ atunci şi WXZ

EXEMPLU:

Fie schema de relatie R={A, B, C, G, H, I} şi fie setul de dependente initial notat cu F şi format din dependentele: AB, AC, CGH, CGI, BH.

Pornind de la acest set initial se mai pot calcula şi urmatoarele dependente:

AH, utilizand regula tranzitivitatii aplicata la dependentele AB şi BH;

CGHI, utilizand regula reuniunii pentru dependentele CGH şi CGI;

si asa mai departe… …

Daca se noteaza cu F setul initial de dependente functionale, cu F+ se va nota inchiderea lui F (deci toate dependentele functionale care se pot defini pentru relatia in cauza.)

Putem reveni in acest moment pentru a trata descompunerile de relatii. Am subliniat mai inainte ca este necesar sa fim atenti la descompuneri pentru a evita pierderea de informatii.

Descompuneri fara pierderi la jonctiune

Fie o descompunere oarecare {R1, R2, …, Rn} a relatiei R, asa cum am definit-o formal la inceputul acestui capitol. Pentru o descompunere oarecare se verifica intotdeuna relatia:

r ri

unde prin X s-a notat produsul cartezian, operatie din algebra relaţionala. Altfel spus, orice tuplu din relatia r duce, prin descompunere, la cate un tuplu t i

in fiecare relatie ri. Cand se realizeaza produsul cartezian cu toate relatiile r i, se obtin in general mai multe tuple decat au fost in relatia initiala r, deoarece produsul cartezian are ca rezultat toate combinatiile posibile intre elementele participante.

Asupra relatiilor dintr-o baza de date se impun intotdeauna anumite restrictii sau conditii, care sa asigure corectitudinea informatiilor din respectiva baza de date.

In general spunem ca o relatie este legala daca satisface toate regulile sau restrictiile care sunt impuse la proiectarea bazei de date.

Fie C un set de restrictii asupra bazei de date. O descompunere {R1, R2, …, Rn} a unei scheme de relatie R este o descompunere fara pierderi la jonctiune

72

pentru R, daca pentru toate relatiile r definite pe schema R (care sunt legale sub restrictiile C) se verifica:

r=

Vom prezenta in continuare un criteriu cu ajutorul caruia se poate verifica daca este o descompunere fara pierderi la jonctiune sau nu.

Definitie. Fie R o schema de relatie şi fie descompunerea lui R reprezentata de {R1, R2}. Aceasta descompunere este fara pierderi la jonctiune daca cel putin una dintre urmatoarele dependente functionale se gasesc in F+:

R1R2R1

R1R2R2

Descompuneri cu pastrarea dependentelor

Pastrarea dependentelor duce la pastrarea consistentei informatiilor din baza de date. Se pot impune restrictii care permit sistemului sa verifice la orice actualizare a informatiilor ca nu se va crea o relatie ilegala.

Fie F setul initial de dependente functionale, definit pe o schema de relatie R. şi fie {R1, R2, …, Rn} o descompunere a lui R. Notam cu Fi restrictia la Ri a multimii de dependente functionale F. (Se cere ca dependentele functionale din Fi sa includa doar atribute care se regasesc in relatia Ri).

Vom obtine un set de multimi de dependente functionale F1, F2, …, Fn. Fie F'=

Fi, reuniunea seturilor de dependente funtionale. In general F'F. Dar s-ar

putea ca sa se verifice relatia F'+=F+. Daca se intampla asa atunci spunem ca descompunerea este o descompunere cu pastrarea dependentei.

5.3. Forme normale

Normalizarea este un proces de organizare a datelor in relatiile unei baze de date. Acest proces presupune respectarea unor reguli prin care baza de date se poate normaliza până la un anumit grad, adica se aduce la o anumita forma normala.

Normalizarea se execută trecând prin toate formele normale, până la forma normală cerută. La proiectarea unei baze de date e recomandabil sa se ajunga cel puţin pana la forma normală trei. Aceasta asigura evitarea anomaliilor descrise la inceputul acestui capitol.

5.3.1. Forma Normală Unu (1NF)

Numim Formă Nenormalizată (UNF) orice tabelă care conţine una sau mai multe grupuri repetitive pe atribute.

Forma Normală Unu (1NF): Spunem ca o relaţie se gaseste in Forma normala unu daca orice atribut este atomic, adica nu exista nici atribute compuse nici repetitive.

73

Pentru a transforma tabela din Figura 5.2 în forma normală unu, identificăm şi ştergem grupurile repetitive din tabelă. Eliminarea acestor grupuri repetitive se poate realiza în două moduri:

Conform primei modalităţi, eliminăm grupurile repetitive, prin crearea altor înregistrări, în care să fie introduse valorile din aceste grupuri, împreună cu celelalte valori ale atributelor din înregistrarea la care se lucrează. Tabele astefel rezultată va fi în formă normală unu.

În a doua modalitate, fiecere valoare a grupurilor repetitive le copiem într-o nouă relaţie împreună cu cheia primară din tabela iniţială. Putem avea mai multe grupuri repetitive. În acest caz creăm mai multe relaţii noi. Aceste relaţii noi, precum şi tabela normalizată vor fi în formă normală unu.

Pentru relaţia Furnizori_Cheltuieli:

Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt DataValoare

F100 Romgaz R1234567 C15 Incalzire 30.06.99 2,150,000

C16 Apa calda 30.06.99 500,000

F110 Renel R7654321 C10 Iluminat 30.06.99 3,000,000

C11 Lift 30.06.99 200,000

Figura 5.2. Tabela nenormalizată Furnizori_Cheltuieli.

Observăm că pentru furnizorul "Romgaz" avem două tipuri de cheltuieli. La fel şi pentru furnizorul "Renel".

Pentru a transforma această tabelă în 1NF, trebuie să avem o singură valoare la fiecare intersecţie linie coloană.

Daca vom normaliza dupa prima metoda, vom scrie repetiţiile pe diferite rânduri iar coloanele care nu conţin repetiţii, vor fii copiate corespunzator pe fiecare rând

Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt DataValoare

F100 Romgaz R1234567 C15 Incalzire 30.06.99 2,150,000

74

F100 Romgaz R1234567 C16 Apa calda 30.06.99 500,000

F110 Renel R7654321 C10 Iluminat 30.06.99 3,000,000

F110 Renel R7654321 C11 Lift 30.06.99 200,000

Figura 5.3. Tabela Furnizori_Cheltuieli în 1NF

În tabela normalizatã, cheia va fi (Cod_furn, Cod_chelt, Data).

Normalizând tabela iniţială după a doua modalitate, vom crea o a doua tabelă cu informaţiile care nu se repetă, împreună cu cheia primară din tabela iniţială. Deci cele două tabele vor fi următoarele:

Furnizori (Cod_furn, Den_furn, Cod_fiscal)

Cheltuieli (Cod_furn, Cod_chelt, Data, Den_chelt, Valoare)

Cele două tabele astfel create sunt în 1NF:

Cheltuieli

Cod_furn. Cod_chelt Data Den_chelt Valoare

F100 C15 30.06.99 Incalzire 1500000

F100 2 C16 30.06.99 Apa calda 500000

F110 3 C10 30.06.99 Iluminat 3000000

F110 4 C11 30.06.99 Lift 200000

Furnizori

Cod_furn Den_furn Cod_fiscal

F100 Romgaz R1234567

F110 Renel R7654321

Figura 5.5. Relaţiile Cheltuieli şi Furnizori, create prin metoda a doua de normalizare.

Pentru a demonstra trecerea la forma normală doi şi mai departe, vom folosi relaţia Furnizori_Cheltuieli, prezentata în figura 5.3.

5.3.2. Forma Normală Doi (2NF)

Forma normală doi se obtine utilizand conceptul de dependenţă funcţională totală.

Dependenţa funcţională totală. Dacă A este un subset de doua sau mai multe atribute şi B este atribut (sau subset de atribute) al aceleiasi relaţii, spunem ca B este total dependent funcţional de grupul de atribute A, dacă B este dependent funcţional de A, dar nu este dependent funcţional de nici un subset

75

de atribute din A.

De exemplu să luăm următoarea dependenţă funcţională:

Cod_chelt, Cod_furn, Data Valoare

Dependenţa funcţională este totala pentru ca Valoare nu depinde functional de nici un subset de atribute al grupului Cod_chelt, Cod_furn, Data.

Forma normală doi trebuie verificată doar la relaţiile care au cheie compusă pe poziţie de cheie primară. Relaţia la care cheia primară se compune dintr-un singul atribut, este în 2NF daca este in 1NF.

Forma Normală Doi (2NF). O relaţie este în forma normală doi, dacă este în forma normală unu şi fiecare atribut care nu aparţine cheii primare, este total dependent funcţional de cheia primară.

Vom demonstra aducerea la forma normală doi, folosind relaţia Furnizori_Cheltuieli. Putem trece la forma normală doi prin ştergerea atributelor care nu depind total de cheia primară şi trecerea lor într-o altă tabelă împreună cu determinantul lor. După efectuarea acestor transformări, vom obtine următoarele relaţii:

Relatia Cheltuieli:

Cod_furn. Cod_chelt Data Valoare

F100 C15 30.06.99 1500000

F100 C16 30.06.99 500000

F110 C10 30.06.99 3000000

F110 C11 30.06.99 200000

Relaţia Furnizori:

Cod_furn Den_furn Cod_fiscal

F100 Romgaz R1234567

F110 Renel R7654321

Relatia Tip_cheltuiala:

Cod_Chelt Den_chelt

C15 Incalzire

C16 Apa calda

C10 Iluminat

C11 Lift

Figura 5.5. Relaţiile rezultate după trecerea la 2NF a relaţiei Furnizori_Cheltuieli.

Relaţiile rezultate au următoarele scheme de relatie:

Furnizori = (Cod_furn., Den_furn, Cod_fiscal)

76

Tip cheltuială = (Cod_Chelt., Den_chelt)

Cheltuieli = (Cod_furn, Cod_chelt, Data, Valoare)

5.3.3. Forma Normală Trei (3NF)

Forma normală doi chiar dacă nu conţine atâta redundanţă ca forma normală unu, totuşi există cazuri în care pot apărea anomalii la actualizare. Aceste anomalii apar din cauza redundanţei generate de dependenţa tranzitivă.

Dependenţă tranzitivă. Dacă atributele A, B, C sunt în relaţiile AB şi BC, atunci spunem că atributul C este dependent tranzitiv de atributul A, via B.

Forma Normală Trei (3NF). Spunem ca o relaţie este în formă normala trei daca este deja in forma normală doi şi nici un atribut care nu aparţine cheii primare nu este tranzitiv dependent de cheia primara.

În cazul existenţei dependenţei tranzitive, ştergem coloanele care sunt tranzitiv dependente de cheia primară şi creăm o relaţie nouă cu aceste coloane, împreună cu determinantul lor, adică cheia primară.

Examinând relaţiile în forma normală de mai sus, observăm că nu există dependenţe tranzitive. Deci relaţiile sunt în formă normală trei.

5.3.4. Forma Normală Boyce-Codd (BCNF)

Baza de date trebuie proiectată astfel încât să nu conţină dependenţe parţiale sau tranzitive, pentru că altfel ne putem confrunta cu anomaliile descrise la inceputul capitolului.

Forma normală Boyce-Codd se obtine utilizand cheile candidat din relaţie. O relaţie cu o singură cheie candidat în formă normală trei este şi în formă normală Boyce-Codd.

Forma normală Boyce-Codd (BCNF). Spunem ca o relaţie este în forma normală Boyce-Codd dacă şi numai dacă orice determinant din relaţie este cheie candidat.

Să căutăm determinanţii din exemplul de mai sus:

Cod_furn Den_furn, Cod_fiscal

Cod_chelt Den_chelt

Cod_furn, Cod_chelt, Data Valoare

Toţi cei trei determinanţi sunt şi chei candidat in relatiile lor. Deci relatiile din exemplul de mai sus sunt în formă normală Boyce-Codd. Relaţiile în formă normală trei sunt în general şi în formă normală Boyce-Codd. În cazul în care relaţia nu este în formă normală Boyce-Codd, trecerea la BCNF se realizează prin ştergerea din relaţia iniţială a atributelor care sunt asociate unui determinant care nu este cheie candidat şi crearea unei noi relaţii cu aceste atribute şi determinantul lor.

Există situaţii când este foarte greu de descompus relatiile, ca să ajungem la BCNF. În aceste situaţii este indicata rămânerea la forma normală trei.

77

Concluzii

Forma Normală Unu (1NF)Trebuie să căutăm toate intersecţiile de linii şi coloane, unde există

repetiţii. Aceste repetiţii se pot elimina prin două madalităţi:

Crearea de noi înregistrări pentru fiecare valoare a repetiţiei, după care se caută o nouă cheie primară.

Ştergerea atributelor care conţin repetiţii şi crearea de noi relaţii care vor conţine atributele şterse, precum şi cheia primara din relaţia iniţială.

Forma Normală Doi (2NF)

Se caută dependenţele totale de cheia primara, adică toate atributele care depind funcţional de un subset de atribute a cheii primare. Dacă cheia primară este compusă dintr-un singur atribut, atunci relaţia este în forma normală doi, daca este deja in forma normala unu. Dacă există dependenţe partiale, ştergem atributele care depind parţial de cheia primara şi creăm o relaţie nouă care să se compună din atributele şterse împreună cu determinantul lor.

Forma Normală Trei (3NF)

Pentru a trece la forma normală trei, trebuie să eliminăm dependenţele tranzitive. Eliminarea se realizează prin ştergerea câmpurilor dependente tranzitiv de cheia primară din relaţia iniţială şi crearea unei noi relaţii cu aceste atribute şi determinantul lor.

Forma Normală Boyce-Codd (BCNF)

Cerinţa la forma normală Boyce-Codd este ca fiecare determinant din relaţie să fie cheie candidat. În cazul în care nu este îndeplinită această cerinţă, vom şterge atributele dependente funcţional de determinantul care nu este cheie candidat şi creăm o nouă relaţie în care să avem atributele şterse şi determinantul lor. În unele cazuri trecerea la forma normală Boyce-Codd complică foarte mult baza de date, caz în care este de preferat rămânerea la forma normală trei.Probleme recapitulative.1) Aduceţi la forma normală 1 urmărtoarea tabelă:Relaţia Furnizori_Cheltuieli:

CodFurn.

Denumire Codfiscal

Nr.Crt.

CodChelt.

DenumireCheltuială

Valoare

F100 Romgaz R1234567 1 C15 Chelt pt. Încălzire 15000002 C16 Chelt pt. Bucătării 500000

F110 Renel R7654321 3 C10 Chelt cu iluminatul 3000000

78

4 C11 Chelt pt. Func. liftului 2000002) Aduceţi la forma normală 2 schema:(Cod Furn., Denumire, Cod fiscal, Cod Chelt., Denumire cheltuială, Nr. Crt., Cod, Valoare)3) Aduceţi la forma normală 3 schema:carte = (c_carte, titlu, cod_domeniu, den_domeniu)

Raspunsuri la intrebări.1) Fie tabela din enunţ:CodFurn.

Denumire Codfiscal

Nr.Crt.

CodChelt.

DenumireCheltuială

Valoare

F100 Romgaz R1234567 1 C15 Chelt pt. Încălzire 15000002 C16 Chelt pt. Bucătării 500000

F110 Renel R7654321 3 C10 Chelt cu iluminatul 30000004 C11 Chelt pt. Func. liftului 200000

În această tabelă observăm că pentru furnizorul “Romgaz” avem două tipuri de cheltuieli. Grupul de atribute (nr.crt., cod chelt., denumire cheltuială, valoare) apare de mai multe ori. Pentru a transforma această tabelă în 1NF, trebuie să avem o singură valoare la fiecare intersecţie linie coloană.

În cazul primei modalităţi, scriem repetiţiile pe diferite rânduri iar coloanele care nu conţin repetiţii, vor fi copiate pe fiecare rând. După despărţirea repetiţiilor pe mai multe rânduri, identificăm o nouă cheie.CodFurn.

Denumire Codfiscal

Nr.Crt.

CodChelt.

DenumireCheltuială

Valoare

F100 Romgaz R1234567 1 C15 Chelt pt. Încălzire 1500000F100 Romgaz R1234567 2 C16 Chelt pt. Bucătării 500000F110 Renel R7654321 3 C10 Chelt cu iluminatul 3000000F110 Renel R7654321 4 C11 Chelt pt. Func. liftului 200000 Tabela Furnizori_Cheltuieli în 1NF creată prin prima modaliate de transformare.

În tabela normalizată, noua cheie va fi (Cod Furn., Nr. Crt., Cod Chelt.).

Normalizând tabela iniţială după a doua modalitate, vom crea o a doua tabelă cu informaţiile care nu se repetă, împreună cu cheia primară din tabela iniţială. Deci cele două tabele vor fi următoarele:

Furnizori (Cod Furn., Denumire, Cod fiscal)Cheltuieli (Cod Furn., Cod Chelt., Nr. Crt., Denumire cheltuială,

Valoare)Cele două tabele astfel create sunt în 1NF:

2) Fie R = (Cod Furn., Denumire, Cod fiscal, Cod Chelt., Denumire cheltuială, Nr. Crt., Cod, Valoare)

Vom avea dependentele functionale:K = (Cod Furn., Cod Chelt., Nr. Crt.) R deci K este cheie.d1 Cod Chelt Denumire cheltuialăd2 Cod Furn (Denumire, Cod fiscal)

79

Dependenţele d1 şi d2 sunt dependenţe parţiale de cheie.Relaţiile rezultate au următoarea formă:

Furnizori = (Cod Furn., Denumire, Cod fiscal)Tip cheltuială = (Cod Chelt., Denumire cheltuială)Cheltuieli = (Nr. Crt., Cod Furn., Cod Chelt., Valoare)

4) Fie relaţia din enunţ:carte = (c_carte, titlu, cod_domeniu, den_domeniu) cu cheia c_carte. În afara dependenţelor care definesc cheia mai avem dependenţa:

cod_domeniu den_domeniu şi pentru că c_carte este cheie avem şic_carte cod_domeniu deci den_domeniu depinde tranzitiv de cheie.Prin descompunere rezultă două scheme 3NF:carte1 = (c_carte, titlu, cod_domeniu) şidomeniu = (cod_domeniu, den_domeniu).

Capitolul 6. Ghid de proiectare a bazelor de date relaţionale

6.1. Metodologia de proiectarea a bazelor de date relaţionale.

În acest capitol vom învăţa despre: Scopul metodologiei de proiectarea a bazelor de date. Proiectarea bazelor de date are două faze mari: proiectarea logică şi

proiectarea fizică. Utilizatorii sistemului informatic au un rol important în proiectarea

bazelor de date. Cum documentăm procesul de proiectare a bazelor de date? Cum descompunem scopul proiectării în vederi (view-uri) specifice

utilizatorilor înrtreprinderii? Cum utilizăm modelarea Entity-Relationship (ER), pentru a crea un

model conceptual local, bazat pe informaţiile adunate despre view-urile utilizatorilor?

Cum proiectăm un model local conceptual într-un model local logic de date?

Cum creăm relaţiile pentru un model conceptual local? Cum validăm modelul logic de date, utilizând technica normalizării? Cum compunem modelele logice locale de date, bazate pe view-urile

specifice utilizatorilor, într-un model logic global de date al întreprinderii? Cum ne asigurăm că modelul global este o reprezentare adevărată şi

totală a părţii întreprinderii pe care vrem să o modelăm?Metodologia proiectării bazei de date se compune din două etape mari:

proiectarea logică, în care proiectantul decide asupra structurii logice a bazei de date, şi proiectarea fizică, în care proiectantul decide cum se va implementa structura logică în sistemul de gestiune a bazelor de date (SGBD).

În acest capitol vom prezenta pas cu pas, crearea unei baze de date. Vom utiliza modelarea ER descrisă în capitolul 2, pentru proiectarea bazei de

80

date; vom valida acest model prin normalizare, prezentat în capitolul 5; iar în final vom compune diferitele view-uri într-un model global al întreprinderii.

În acest capitol vom utiliza covintele “entitate” şi “relaţie” în locul expresiilor “tip de entitate” şi “tip de relaţie”. Unde această utilizare ar putea crea confuzii, vom specifica “tip de entitate”, respectiv “tip de relaţie”.

6.1.1. Metodologia proiectării bazelor de date

6.1.1.1. Ce este o metodologie de proiectare?

Definiţie: Metodologie de proiectare: O aproximare structurată, care utilizează proceduri, tehnici, instrumente şi documentaţii pentru a facilita procesul de proiectare.

Metodologia de proiectare se compune din etape, care la rândul lor se compun din paşi, care orientează proiectantul la fiecare nivel al creării bazei de date.

6.1.1.2. Proiectarea logică şi fizică a bazei de date

Definiţie: Proiectare logică: Procesul de construcţie a unui model de informaţii folosite într-o întreprindere, bazată pe modelul de date, dar independent de particularizările sistemului de gestiune a bazei de date şi a altor considerente fizice.

Proiectarea logică începe cu crearea modelului conceptual al bazei de date, care este independent de implementarea într-un SGBD. Modelul conceptual este apoi proiectat pe un model logic, care va influenţa mai târziu modelul de date în care se va implementa.

Definiţie: Proiectare fizică: Este procesul de descriere a implementării bazei de date într-un SGBD.

În această etapă a proiectării este creată baza de date într-un SGBD, împreună cu procedurile de actualizare. În această etapă există un feedback între proiectarea fizică şi cea logică, pentru că deciziile luate la implementarea fizică pot afecta baza de date logice.

6.1.2. Prezentarea metodologiei

În acest capitol vom prezenta o descriere a metodologiei de proiectare a bazelor de date. Prima dată să vedem care sunt paşii de urmat în proiectare:Pasul 1. Proiectarea logică a bazei de date relaţionale:

Crearea unui model conceptual local, pentru vederile utilizatorilor.Pasul 1.1. Identificarea tipurilor de entităţi.Pasul 1.2. Identificarea tipurilor de relaţii.Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi

şi tipurile de relaţii.Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.Pasul 1.5. Determinarea atributelor care compun cheile candidate şi

primare.Pasul 1.6. Specializare/generalizare (pas opţional).

81

Pasul 1.7. Desenarea diagramei entity-relationship.Pasul 1.8. Verificarea modelului conceptual local cu ajutorul

utilizatorului.Pasul 2. Crearea şi validarea modelului logic local.

Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.

Pasul 2.2. Crearea relaţiilor pentru modelul logic local.Pasul 2.3. Validarea modelului, utilizând normalizarea.Pasul 2.4. Validarea modelului din nou, utilizând tranzacţiile.Pasul 2.5. Desenarea diagramei ER.Pasul 2.6. Definirea regulilor de integritate a bazei de date.Pasul 2.7. Verificarea modelului logic local cu ajutorul

utilizatorului.Pasul 3. Crearea şi validarea modelului logic global de date.

Pasul 3.1. Compunerea medelelor logice locale într-un model logic global.

Pasul 3.2. Validarea modelului logic global.Pasul 3.3. Verificarea posibilităţii de a completa baza de date în

viitor.Pasul 3.4. Desenarea diagramei ER finale.Pasul 3.5. Verificarea modelului logic global cu ajutorul

utilizatorului.Pasul 4. Proiectarea fizică şi implementarea bazei de date relaţionale:

Translatarea modelului logic global în SGBD.Pasul 4.1. Proiectarea relaţiilor de bază în SGBD.Pasul 4.2. Crearea regulilor de integritate în SGBD.

Pasul 5. Proiectarea şi implementarea reprezentării fizice.Pasul 5.1. Analizarea tranzacţiilor.Pasul 5.2. Alegerea organizării fişierelor.Pasul 5.3. Alegerea indecsilor secundari.Pasul 5.4. Introducerea unei redundanţe comntrolate.Pasul 5.5. Estimarea spaţiului pe disc.

Pasul 6. Proiectarea şi implementarea unui mechanism de securitate.Pasul 6.1. Crearea view-urilor pentru utilizatori.Pasul 6.2. Proiectarea regulilor de acces la baza de date.

Pasul 7. Verificarea sistemului operaţional.Proiectarea logică a bazei de date se divide în trei paşi mari. Primul pas

are ca obiectiv, descompunerea proiectării sistemului informatic în vederi, care se pot discuta cu utilizatorii sistemului. Modelul de date astfel creat, se validează prin normalizare şi prin tranzacţii în pasul doi. În final, se generează modelul global al întreprinderii, cars este la rândul lui validat şi verificat cu ajutorul utilizatorului sistemului.

82

Factori critici pentru succesul proiectării logice: Lucrul interactiv cu utilizatorul sistemului. Folosirea unei metodologii structurate pentru procesul de proiectare a

bazei de date. Încorporarea regulilor de integritate în modelul logic de date. Combinarea validării conceptuale, prin normalizare şi prin tranzactii, la

proiectarea modelului logic de baze de date. Utilizarea diagramelor pentru a reprezenta cât mai multe modele logice

posibile. Crearea dicţionarului de date, ca supliment al modelului de date.

6.1.3. Crearea modelului logic

În acest capitol vom prezenta pas cu pas, proiectarea unei baze de date.Pasul 1. Crearea modelului conceptual local, pentru utilizatori.Obiectivul: Crearea unui model conceptual local, pentru view-urile

utilizatorilior.Primul pas în proiectarea bazei de date este de a colecta datele necesare

pentru realizarea sistemului, ceea ce putem culege, discutând cu viitorii tilizatori ai bazei de date. Acrastă discuţie presupune o despărţire în vederi, a bazei de date, vederi care pot lucra separat.

Despărţirea în vederi se poate realiza în mai multe moduri. O modaliate ar fi analiza datelor globale şi găsirea de părţi relativ independente. O altă modalitate ar fii analiza rapoartelor, procedurilor cerute şi/sau observarea sistemului existent în lucru.

Modelele conceptuale locale trebuie să conţină: tipuri de entităţi, tipuri de relaţii, atribute, domeniile atributelor, cheile candidat, chei primarePaşii din prima etapă a proiectării logice sunt: Pasul 1.1. Identificarea tipurilor de entităţi. Pasul 1.2. Identificarea tipurilor de relaţii. Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de

entităţi şi tipurile de relaţii. Pasul 1.4. Determinarea domeniilor de definiţie a atributelor. Pasul 1.5. Determinarea atributelor care compun cheile candidate

şi primare. Pasul 1.6. Specializare/generalizare (pas opţional). Pasul 1.7. Desenarea diagramei entity-relationship. Pasul 1.8. Verificarea modelului conceptual local cu ajutorul

utilizatorului.Pasul 1.1. Identificarea tipurilor de entităţiObiectivul: Identificarea tipurilor de entităţi principale în vederile

utilizatorilor.

83

Primul pas în proiectarea bazei de date este identificarea entităţiilor din datele furnizate de utilizatori. De exemplu, dacă avem informaţiile Nr_Mat, Nr_Bloc, Scara, Etaj, Apartament şi Nume, putem identifica entitatea Locatari. În general putem identifica entităţiile în mai multe moduri. De exemplu în locul entităţii Locatari, am putea crea o entitate Locatari cu atributele Nr_Mat şi Nume, iar celelelte informaţii în entitatea ProprietateLocatari.

Există cazuri când entităţiile sunt greu de identificat, pentru că modul de prezentare a viitorilor utilizatori necesită explicaţii. Utilizatorii descriu aceste entităţi, folosind sinonime şi omonime, ceea ce îngreunează identificarea entităţilor. Sinonimele prin care se descrie aceaşi entitate, se pot considera sinonime şi la crearea modelului logic, evidenţiind aceste sinonime ca diverse aliasuri ai entităţiilor.

Documentarea tipurilor de entităţiDupă identificarea entităţiilor, le dăm câte un nume, iar aceste nume le

vom evidenţia în dicţionarul de date, împreună cu explicaţiile despre entităţi, precum şi posibilele aliasuri.

Pasul 1.2. Identificarea tipurilor de relaţiiObiectivul: Identificarea relaţiilor importante dintre entităţi.După identificarea entităţiilor, va trebui să identificăm şi relaţiile

importante dintre aceste entităţi. Releţiile se descriu printr-un verb al relaţiei. De exemplu: Scările sunt Locuite de Locatari Furnizorii Provoacă Cheltuieli

La identificarea relaţiilor vom lua în considerare doar relaţiile care ne interesează. Degeaba există şi alte relaţii care să se poată identificate, dacă nu prezintă importanţă pentru problema noastră, atunci nu le luăm în consideraţie.

În cele mai multe din cazuri, relaţiile sunt binare, adică se realizează întrea exact două entităţi. Există şi relaţii mai complexe, care se realizează între mai multe entităţi, sau relaţii recursive, care pune în relaţie o singură entitate cu ea însăşi.

Determinarea cardinalităţii şi a participării la tipurile de relaţiiDupă identificarea tipurilor de relaţii, trebuie să determinăm

cardinalitatea lor, alegând dintre posibilităţiile: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Dacă se cunosc valori specifice ale cardinalităţiilor, aceste valori se scriu la documentarea relaţiilor. În continuare determinăm şi participarea la relaţie, care poate fii totală, sau parţială.

Documentarea tipurilor de relaţiiDupă identificarea tipurilor de relaţii, le denumim şi le introducem în

dicţionarul de date, împreună cu cardinalitatea şi participarea lor.Utilizarea modelării ERPentru vizualizarea sistemelor complicate, utilizăm diagrama ER,

pentru că este mult mai uşor de a cuprinde toate informaţiile. Vă propunem ca să utilizaţi întotdeauna diagrama ER, pentru o mai bună vizualizare a datelor.

Pasul 1.3. Identificarea şi asocierea de atribute la tipurile de entităţi şi tipurile de relaţii

84

Obiectivul: Asocierea de atribute la tipurile de entităţi şi la tipurile de relaţii.

Următorul pas în metodologie este identificarea atributelor. Aceste atribute se identifică în aceeaşi mod ca şi entităţiile. Pentru o mai uşoară identificare, trebuie să luăm entităţiile şi relaţiile ra rând şi să ne punem următoarea întrebare: Ce informaţii deţinem despre această … ? Răspunsul la această întrebare ne va da atributele căutate.

Atribute simple sau compuseEste important să notăm dacă un atribut este simplu sau compus.

Conform acestei informaţii va trebui să luăm decizii referitoare la acel atribut. Dacă un atribut este compus, atunci putem opta pentru descompunerea sa, dacă este necesară prelucrarea separată a detelor compuse, sau putem să-l lăsăm compus în caz contrar.

De exemplu, atributul Adresă conţine informaţiile (Nr_Bloc, Scara, Etaj, Apartament). Noi va trebui să prelucrăm aceste informaţii separat, deci vom descompune acest atribut în cele patru atribute simple.

Putem avea cazuri în care atributele simple să le compunem. De exemplu în cazul atributelor Nume_Familie şi Prenume, neavând nevoie de aceste informaţii separat, le vom compune în atributul Nume.

Atribute derivate (calculate)Sunt acele atribute, care se pot calcula din alte atribute existente în

baza de date. De exemplu numărul locatarilor de pe o scară se poate număra în tipul de entitate Locatari. Deci acest atribut este atribut derivat.

În general aceste atribute nu trebuie incluse în modelul de date, pentru că în cazul în care se modifică atributul din care se calculează atributul derivat, trebuie să se modifice şi acesta. În cazul în care nu se modifică, baza de date devine inconsistentă. De aceea este important de a menţiona dacă un atribut este sau nu derivat.

Dacă identificăm un atribut care să nu-l putem asocia nici unei entităţi sau relaţii, ne întoarcem la paşii anteriori, identificând noua relaţie sau entitate la care să asociem atributul respectiv.

În cazul în care putem asocia acelaşi atribut la mai multe entităţi, atunci va trebui să decidem dacă generalizăm sau nu aceste entităţi, proces care este descris la pasul 1.6.

Documentarea atributelorDupă identificarea atributelor, le asociem un nume, şi le înregistrăm în

dicţionarul de date, împreună cu următoarele informaţii: numele şi descrierea atributului, toate aliasurile şi sinonimele prin care este cunoscut atributul, tipul de date şi lungimea, valorile iniţiale ale atributelor (dacă există), dacă atributul acceptă sau nu valoarea nulă, dacă atributul este sau nu compus, şi dacă este atunci atributele simple care

îl compun, dacă atributul este sau nu derivat şi atributul din care derivă, dacă atributul acceptă sau nu mai multe valori.

85

Pasul 1.4. Determinarea domeniului atributelorObiectivul: Determinarea domeniului atributelor în modelul conceptual

local.Domeniul atributului este o mulţime de valori pe care o poate lua.

Pentru a controla în totalitate domeniul atributelor, se poate evidenţia următoarele: setul de valori admisibile pentru un atribut, operaţiile admisibile asupra unui atribut, ce atribute se pot compara cu atributul respectiv, în combinaţiile cu alte

atribute, mărimea şi formatul câmpului atributului.

Documentarea domeniilor atributelorActualizăm dicţionarul de date cu domeniul de definiţie al fiecărui

atribut.Pasul 1.5. Determinarea atributelor care compun cheile candidat şi

primareObiectivul: Identificarea cheilor candidat pentru fiecare entitate

şi alegerea cheilor primare în cazul în care sunt mai multe chei candidat.Identificarea cheilor şi selectarea cheilor primareO cheie candidat este un atribut, sau un grup de atribute care identifică

unic fiecare înregistrare din tipul de entitate. Putem identifica una, sau mai multe chei candidat. În acest caz trebuie să alegem dintre ele o cheie primară. Cheile candidat care nu sunt primare, se vor numi chei alternante. Pentru alegerea unei chei ca fiind cheie primară, vom ţine cont de următoarele: cheia candidat, care are un număr minim de atribute, cheia candidat, care îşi va schimba cel mai rar valoarea, cheia candidat, care este cel mai puţin probabil să sufere modificări în

viitor, cheia candidat, care este compusă din cele mai puţine caractere (în cazul

atributelor de tip caracter), cheia candidat, care este cel mai uşor de folosit din punctul de vedere al

utilizatorului.Prin procesul de identificare a cheilor primare, deducem şi dacă o

entitate este entitate “tare”, sau entitate “slabă”. Dacă reuşim să identificăm o cheie primară, atunci entitatea este tare, altfel este slabă. O entitate slabă nu poate exista fără o entitate tare, care să-i fie “părinte”. Cheia primară a entităţii slabe este derivată parţial sau total din cheia primară a entităţii tari.

Documentarea cheilor primare şi alternanteÎnscriem cheile primare şi pe cele alternante în dicţionarul de date.Pasul 1.6. Specializarea/generalizarea tipurilor de entităţi (pas

opţional)Obiectivul: Identificarea entităţiilor subclasă respectiv superclasă, între

entităţiile apropiate.În acest pas putem opta pentru a continua modelarea ER, folosind

procesul de generalizare sau specializare. Dacă alegem procesul de specializare, vom încerca să definim una, sau mai multe subclase ale entităţii

86

respective. Dacă însă alegem procesul de generalizare, vom căuta superclase pentru acea entitate.

Un exemplu pentru procesul de generalizare ar fii entităţiile Şef_de_scară şi Familii. Ambele entităţi au atribuite următoarele atribute: Nr_mat, Nr_bloc, Scara, Etaj, Apartament şi Nume. Pe lângă aceste atribute, entitatea Şef_de_scară mai are asociate atributul Data_intrare_func; iar entitatea Familii, atributele Nr_pers, Nr_pers_prezente şi Nr_chei. Deci, cele două entităţi având atribute în comun, le putem generaliza în entitatea Locatari, care va conţine atributele comune, şi entităţile Şef_de_scară şi Familii, conţinând doar atributele diferite - particularizările faţă de superclasă.

Pasul 1.7. Desenarea diagramei ER.Obiectivul: Desenarea unei diagrame ER. care va fi reprezentarea

conceptuală a vederilor utilizatorilor despre întreprindere.În momentul acesta suntem în măsură să prezentăm o giagramă

completă a modelului bazat pe vederile utilizatorilor despre întreprindere.Pasul 1.8. Verificarea modelului conceptual local cu ajutorul

utilizatoruluiObiectivul: Verificarea modelului conceptual local cu ajutorul

utilizatorului, pentru a vedea dacă modelul este o reprezentare adevărată a vederii utilizatorului despre întreprindere.

Înainte de a termina pasul 1, trebuie verificat modelul conceptual elaborat. Acest model include diagrama ER şi documentaţia anexată. În cazul în care apare orice fel de anomalie, repetăm procesul de mai înainte şi remediem problema.

Pasul 2. Crearea şi validarea modelului logic localObiectivul: Crearea unui model logic local bazată pe modelul

conceptual al utilizatorilor asupra întreprinderii şi validarea ei prin procesul de normalizare şi prin tehnica tranzacţiilor cerute.

În acest pas verificăm modelul conceptual creat în pasul anterior şi eliminăm din el structurile care sunt dificil de realizat într-un SGBD. Dacă la sfârşitul acestui proces modelul ete alterat, vom corecta aceste probleme şi ne vom referi în continuare la modelul rezultat, ca fiind modelul logic local. Vom valida modelul logic prin procesul de normalizare şi a tranzacţiilor.

Activităţile din acest pas sunt: Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local. Pasul 2.2. Crearea relaţiilor pentru modelul logic local. Pasul 2.3. Validarea modelului, utilizând normalizarea. Pasul 2.2. Validarea modelului din nou, utilizând tranzacţiile. Pasul 2.5. Desenarea diagramei ER. Pasul 2.6. Definirea regulilor de integritate ale bazei de date. Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.

Pasul 2.1. Proiectarea modelului conceptual local pe modelul logic local

Obiectivul: Verificarea modelului conceptual local pentru eliminarea structurilor care se pot implementa greu într-un SGBD şi proiectarea modelului rezultat la modelul logic local.

87

În pasul întâi am pregătit un model conceptual bazat pe informaţiile date de utilizator. Acest model trebuie prelucrat, pentru a putea fi uşor de prelucrat de sistemul de gestiune a bazelor de date. Obiectivele acestui pas sunt:(1) Eliminarea relaţiilor M:N.(2) Eliminarea relaţiilor complexe.(3) Eliminarea relaţiilor recursive.(4) Eliminarea relaţiilor cu atribute.(5) Reexaminarea relaţiilor 1:1.(6) Eliminarea relaţiilor redundante.

(1) Eliminarea relaţiilor multe-la-multeDacă în modelul de date apar relaţii de tipul multe-la-multe (M:N),

trebuie descompuse în două relaţii unu-la-multe (1:M) prin adăugarea unei noi entităţi suplimentare.

De exemplu, pot exista mai multe cheltuieli pentru o scară, dar şi o cheltuială (factură) poate să se refere la mai multe scări. Deci relaţia dintre entitatea Scări şi entitatea Cheltuieli este de M:N, ceea de este evidenţiat în figura 6.1.(a).

Sunt platite de

Scari

Nr_BlocScara

Lift

Cheltuieli

Nr_Crt

Cod_Cheltuiala (FK)Cod_Furnizor (FK)Nr_facturaData_facturaValoare_factura

Se calculeazaAu cheltuieli

Pe scari

Scara (FK)Nr_Crt (FK)Nr_Bloc (FK)

Cheltuieli

Nr_Crt

Cod_Furnizor (FK)Cod_cheltuialaNr_facturaData_facturaValoare_factura

Scari

Nr_BlocScara

Lift

Figura 6.1. (a). Relaţie de tipul N:M. (b). Relaţie transfornamtă în două relaţii 1:M.

88

Această relaţie se poate elimina, prin crearea unui tip de entitate suplimentar, care să facă legătura dintre scări şi cheltuieli. Diagrama acestor relaţii se vede în figura 6.1.(b).

Notăm, că tipul de entitate nou creat - Pe_scări - este tip de entitate slabă, pentru că depinde atît de tipul de entitate Scări, cât şi de tipul de entitate Cheltuieli.

(2) Eliminarea relaţiilor complexeO relaţie complexă este o relaţie între mai mult de couă tipuri de

entităţi. Dacă în modelul conceptual apar relaţii complexe, acestea trebuie eliminate. Se pot elimina prin crearea unui nou tip de entitate, care să fie în relaţie de tipul 1:M cu fiecare tip de entitate din relatia iniţială, partea cu M a relaţiei fiind spre tipul de entitate nou creat.

(3) Eliminarea relaţiilor recursiveRelaţiile recursive sunt nişte relaţii particulare, prin care un tip de

entitate este în relaţie cu el însuşi. Dacă apare o astfel de relaţie în modelul conceptual, ea trebuie eliminată. Eliminarea se poate rezolva prin crearea unei noi entităţi unde să se evidenţieze fiecare entitate care este legată de entitatea din tipul de entitate iniţial. În acest caz vom avea o relaţie de tipul 1:M între tipul de entitate iniţial şi tipul de entitate nou creat şi o relaţie de tipul 1:1 între tipul de entitate nou creat şi tipul de entitate iniţial.

(4) Eliminarea relaţiilor cu atributeDacă în modelul conceptual avem relaţie cu atribute, putem

descompune această relaţie, identificând un nou tip de entitate în care să înregistrăm atributele necesare.

(5) Reexaminarea relaţiilor de tipul 1:1În modelul conceptual putem avea entităţi între care să avem relaţie de

tipul 1:1. Se poate întâmpla ca aceste entităţi să fie de fapt aceeaşi entitate cu nume diferite. Dacă suntem în acest caz, unim cele două entităţi, cheia primară devenind cheia primară al uneia dintre entităţi.

(6) Eliminarea relaţiilor redundanteO relaţie este redundantă dacă se poate ajunge de la un tip de entitate la

alt tip de entitate pe mai multe drumuri. Vă amintim că noi vrem să ajungem la un model minimal şi deci relaţiile redundante nu sunt necesare. Decizia că o relaţie este redundantă trebuie să fie precedată de o analiză amănunţită a relaţiilor care compun cele două drumuri dintre cele două entităţi, pentru că pot apărea situaţii, când o relaţie este aparent redundantă, dar în realitate este nevoie de ea.

În finalul acestui pas putem spune că am eliminat din modelul conceptual acele structuri care sunt dificil de implementat şi deci este mai corect ca în continuare să ne referim la acest model ca fiind un model logic local de date.

Pasul 2.2. Crearea de relaţii peste modelul logic localObiectivul: Crearea de relaţii peste modelul logic.Relaţia pe care un tip de entitate o are cu alt tip de entitate este

reprezentată prin mecanismul cheie primară/cheie străină. Cheia străină pentru o entitate este reproducerea cheii primare a altei entităţi. Pentru a decide

89

entităţiile unde vom include copia cheii primare a altei entităţi, trebuie înainte să identificăm entităţile “părinte” şi “fiu”. Entităţile “părinte” se referă la acele entităţi ale căror chei primare se vor copia în entităţile “fiu”.

Pentru descrierea relaţiilor vom folosi un limbaj de definire a bazei de date (Database Definition Language - DDL). În acest limbaj, specificăm prima dată numele entităţii, urmat de atributele asociate între paranteze. După aceea identificăm cheia primară şi toate cheile alternante, precum şi/sau cheile străine.

Tipuri de entitaţi tariPentru tipurile de entităţi tari în modelul logic crearea unei relaţii

include toate atributele entităţii. Pentru atributele compuse al unei entităţi, vom include numai atributele simple din compunerea atributului compus în descrierea entităţii.

De exemplu tipul de entitate Familii, prezentată în figura 6.2. se descrie în următorul mod.

Familii (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers, Nr_pers_prezente, Nr_chei)

Cheie primară: Nr_mat

Trebuie sa plateasca

Familii

Nr_Mat

Nr_persNr_pers_prezenteNr_cheiNr_BlocScaraEtajApartamentFond_rulmentFond_reparatiiAlte_fonduri

Plati

DataNr_Mat (FK)

ValoareRestanta

Figura 6.2. Exemplu de model logic.

Tipurile de entităţi slabeDescrierea tipurilor de entităţi slabe se face la fel ca şi tipurile de

entităţi tari, cu o completare şi anume, evidenţierea cheii străine. De exemplu descrierea tipului de entitate de mai sus se descrie astfel:

Plăţi (Data, Nr_mat, Valoare, Restanţă)Cheie primară: Data, Nr_matCheie străină: Nr_mat se referă la Familii(Nr_mat)Menţionăm că în cazul acesta cheia străină este şi în compunerea chei

primare. Deci înainte de introducerea cheii străine, cheia primară nu identifica unic o entitate. La terminarea acestui pas, putem identifica cheile prinare pentru toate tipurile de entităţi din modelul logic.

90

Tipurile de relaţii binare de tipul unu-la-unu (1:1)Pentru fiecare tip de relaţie binară de tipul 1:1 între două tipuri de

entitate E1 şi E2 găsim o copie a cheii primare a tipului de entitate E1 în compunerea tipului de entitate E2, sub denumirea de cheie străină. Identificarea tipului de entitate “părinte” şi a tipului de entitate “fiu” depinde de participarea entităţilor la relaţie. Tipul de entitate care participă parţial la relaţie este desemnat ca fiind “părinte” iar cel cu participare totală “fiu”. Dacă ambele tipuri de entitate participă parţial sau total la relaţie, atunci tipurile de entităţi se pot evidenţia ca fiind “părinte” sau “fiu” arbitrar. În cazul în care participarea este totală, putem încerca să combinăm cele două tipuri de entităţi într-una singură. Această compunere poate să fie posibilă în cazul în care nici unul dintre cele două tipuri de entităţi nu mai ia parte la altă relaţie.

Tipurile de relaţii binare de tipul unu-la-multe 1:M

Pentru toate relaţiile 1:M între două entităţi E1 şi E2 în modelul logic de date, vom avea copia cheii primare a entităţii E1 în compunerea entităţii E2. Totdeauna entitatea de partea unu a relaţiei este considerată entitate “părinte”, iar cealaltă entitate “fiu”.

Atributele cu mai multe valoriPentru ficarea atribut A care permite mai multe valori din entitatea E1

în modelul logic de date, creăm o nouă relaţie care va conţine atributul A împreună cu cheia primară a entităţii E1 pe post de cheie străină. Cheia primară a noii relaţii va fi atributul A, sau dacă este necesar, compunerea ei cu cheia primară al lui E1.

Relaţiile superclasă/subclasăPentru fiecare relaţie superclasă/subclasă vom identifica superclasa ca

fiind entitatea “părinte”, iar subclasa entitatea “fiu”. Există multe moduri de a reprezenta relaţia aceasta. De exemplu să luăm relaţia prezentată în figura 6.1.3.

(Opţiunea 1)Locatari (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume,

Data_intrare_func, Nr_pers, Nr_pers_prez, Nr_chei)Cheie primară: Nr_mat(Opţiunea 2)Familii (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume,

Nr_pers, Nr_pers_prez, Nr_chei)Cheie primară: Nr_matŞef_de_scară (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume,

Data_intrare_func)Cheie primară: Nr_mat

Figura 6.1.3. Exemplu de relatie superclasă/subclasă

Documentarea relaţiilor şi a atributelor din cheile străine

91

Actualizăm dicţionarul de date, întroducând fiacare atribut nou introdus în compunerea unei chei la acest pas.

Pasul 2.3. Validarea, utilizând normalizarea

Obiectivul: Validarea modelului logic, utilizând tehnica normalizării.Examinăm procesul de normalizare după cum am descris în capitolul 5

Prin normalizare trebuie să demonstrăm că modelul creat este consistent, conţine redundanţă minimală şi are stabilitate maximă.

Normalizarea este procesul prin care se decide dacă atributele pot sau nu să rămână înpreună. Conceptul de bază a teoriei relaţiilor este că atributele sunt grupate împreună pentru că există o relaţie logică între ele. Câteodată baza de date nu este cea mai eficientă. Acesta se argumentează prin următoarele: Proiectarea normalizată organizează datele în funcţie de dependenţele

funcţionale. Deci acest proces este situat undeva între proiectarea conceptuală şi cea fizică.

Proiectul logic nu este un proiect final. El ajută priectantul să înţeleagă natura datelor în întreprindere. Proiectul fizic poate fi diferit. Există posibilitatea ca unele tipuri de entităţi să se denormalizeze. Totuşi normalizarea nu este un timp pierdut.

Proiectul normalizat este robust şi independent de anomaliile de actualizare prezentate în capitolul 5.

Calculatoarele moderne au mult mai multă putere de calcul, ca cele de acum câţiva ani. Din această cauză, câteodată este mai convenabilă implementarea unei baze de date cu puţină redundanţă, decât suportarea cheltuielilor pentru procedurile adiţionale.

Normalizarea produce o bază de date care va fi uşor extensibilă în viitor.Pasul 2.2. Validarea modelului prin tranzacţiiObiectivul: Verificarea ca modelul de date suporte toate tranzacţiile

cerute de utilizator.În acest pas se validează baza de date prin verificarea tranzacţiilor ce se

cer de catre utilizator. Luând în considerare tipurile de entităţi, relaţiile, cheile primare şi străine, încercăm să rezolvăm manual cerinţele utilizatorilor. Dacă reuşim să rezolvăm fiecare tranzacţie cerută, atuci înseamnă că modelul creat este valid. Dacă nu putem rezolva o tranzacţie, atunci este foarte posibil să fi omis un atribut, o relaţie, sau o entitate din modelul de date.

Trebuie să examinăm dacă baza de date suportă tranzacţiile cerute. Mai întâir fi prin rezolvarea de tranzacţii. De exemplu să luăm relaţia dintre Furnizori şi Cheltuieli exemplificată în figura 6.3.

92

Provoaca

Furnizori

Cod_Furnizor

DenumireCod_fiscal (AK1)ContBancaStradaNrBlScApLocalitateJudet

Cheltuieli

Nr_Crt

Cod_Furnizor (FK)Cod_cheltuialaNr_facturaData_facturaValoare_factura

Inserarea de detalii despre un nou furnizor.Cheia primară al acestei entităţi este Nr_furnizor. Deci prima dată

verific dacă numărul introdus nu există deja; după care, în caz că nu există acest cod, inserez detaliile despre furnizor. Dacă există deja codul, nu admit inserarea. Pot verifica şi existenţa codului fiscal, care pentru această entitate este cheie alternantă.

Ştergerea detaliilor despre un furnizorSe caută codul furnizorului de şters. Dacă există se şterge furnizorul,

actualizându-se şi cheia străină în entitatea Cheltuieli. Dacă nu există codul cerut, atunci apare un mesaj de eroare şi nu este şters nici un furnizor.

A doua modalitate de verificare trebuie folosită în cazul în care avem entităţi care nu iau parte direct la nici o tranzacţie. Pentru verificarea acestor entităţi, vom verifica nişte interogări pregătie special.

Pasul 2.5. Desenarea diagramei ER.Obiectivul: Desenarea diagramei Entity-Relationship, care este

reprezentarea logică a vederilor utilizatorilor aspra întreprinderii.Pasul 2.6. Identificarea regulilor de integritate.Obiectivul: Identificarea regulilor de integritate pentru vederile

utilizatorilor asupra întreprinderii.Regulile de integritate sunt importante pentru a proteja baza de date

împotriva posibilelor inconsistenţe. Dacă este necesar, putem produce un proiect fizic de bază de date, pentru a putea vedea mai uşor ce reguli sunt necesare.

Vom considera cinci tipuri de reguli de integritate: necesitatea datelor, reguli asupra domeniului atributelor, integritatea entităţilor, integritatea referinţelor, regulile întreprinderii.Necesitatea datelorExistă atribute care nu pot conţine valoarea nulă, ci trebuie să aibă

totdeauna o valoare. De exemplu fiecare cheltuială înregistrată trebuie să aibă

93

Figura 6.3. Exemplu de relaţie pentru validarea prin tranzacţii.

asociat un furnizor al serviciilor sau al obiectelor ce se plătesc prin acea cheltuială.

Aceste reguli deja le-am identificat, când am documentat atributele în pasul 1.3.

Reguli asupra domeniului atributelor.Unele atribute au un domeniu de definiţie bine definit. Aceste domenii

trebuie respectate. Domeniile de definiţie au fost deja identificate când am documentat domeniile atributelor în pasul 1.2.

Integritatea entităţilor.Cheia primară a entităţilor nu poate lua valori nule. De exemplu fiecare

furnizor trebuie să aibă un cod diferit de zero.Aceste reguli au fost deja identificate, când am documentat cheile

primare în pasul 1.5.Integritatea referinţelor

Cheia străina din tipul de entitate “fiu” face ligătura cu o entitate din tipul de entitate “părinte”. Deci, dacă cheia străină conţine o valoare, ea trebuie neapărat să se regăsească şi în tipul de entitate “părinte”. De exemplu tipul de entitate Cheltuieli conţine cheia străină Cod_furnizor, care se referă la Furnizori(Cod_furnizor). Dacă această cheie nu este nulă, atunci trebuie să găsim un furnizor care să aibă acel cod.

Prima întrebare pe care trebuie să ne-o ponem este: Poate fii cheia străină nulă? În cazul exemplului nostru asta ar însemna că există cheltuieli care nu se prătesc nimănui. Aceste cazuri nu sunt admise de lege, deci nu putem avea valoare nulă în cheia străină din tipul de entitate Cheltuieli.

În general dacă pariciparea tipului de entitate “fiu” este totală, atunci nu putem avea valoare nulă în cheia străină. În caz contrar putem avea valoare nulă.

Pentru a demonstra diferitele cazuri la definirea acestor reguli, folosim relaţia de mai sus dintre Furnizori şi Cheltuieli, care este de tipul 1:M. Considerăm următoarele cazuri:

Cazul 1: Inserarea unei entităţi în tipul de entitate “fiu” (Cheltuieli): Pentru a verifica integritatea referinţei, verificăm dacă atributele din componenţa cheii străine (Cod_furnizor) sunt vide, sau să existe entitate în tipul de entitate “părinte” care să aibă valoare cheii primare egală cu valoare cheii străine.

Cazul 2: Ştergerea unei entităţi din tipul de entitate “fiu” (Cheltuieli): Ştergerea unei entităţi din tipul de entitate “fiu” nu creează probleme la integritatea referinţelor.

Cazul 3: Actualizarea cheii străine în tipul de entitate “fiu” (Cheltuieli): Acest caz este similar cazului 1.

Cazul 4: Stergerea unei entităţi din tipul de entitate “părinte” (Furnizori): Dacă se şterge o entitate din tipul de entitate “părinte”, integritatea referinţelor se strică în cazul în care există entităţi în tipul de entitate “fiu”, care se referă la entitatea ştearsă. Există strategii severe de a rezolva integritatea referinţelor:

94

FĂRĂ ACŢIUNE Neacceptarea ştergerii unei entităţi din tipul de entitate părinte, dacă acesta este referit de o entitate din tipul de entitate fiu. În cazul nostru, nu se acceptă ştergerea furnizorului, dacă el are o factură de încasat.

CASCADĂ Dacă o entitate din tipul de entitate părinte este ştearsă, se şterg automat toate entităţiile din tipurile de entităţi fiu. Dacă tipurile de entităţi fiu au şi ei la rândul lor alte tipuri de entităţi fiu, se va efectua ştergerea în cascadă în toate tipurile de entităţi fiu, până la ultimul nivel. Cu alte cuvinte, dacă se şterge un furnizor, atunci automat se şterge fiacare factură pe carea are de încasat acest furnizor.

SETARE LA NUL Dacă o entitate din tipul de entitate părinte se şterge, atunci se vor seta la valoare nulă toate cheile străine ai tipurilor de entităţi fiu în cascadă până la ultimul nivel. În exemplul nortru, dacă se şterge un furnizor, atunci se vor seta la valoare nulă toate referinţele la acest furnizor în tipul de entitate Cheltuieli. Acesta înseamnă că nu vom ştii ca anumite cheltuieli la ce furnizor trebuie plătite.

SETARE IMPLICITĂ Este analog cazului de setare la nul, cu diferenţa că aici se setează cheia străină la o valoare implicită în loc de valoare nulă. În exemplul nostru putem seta cheia străină din Cheltuieli la o valoare a cheii primare din Furnizori, care să conţină un furnizor predefinit - de exemplu cu numele de “Furnizor şters”.

FĂRĂ MODIFICARE În cazul ştergerii unei entităţi din tipul de antitate părinte, nu se actualizează deloc cheile străine din tipurile de entităţi fiu.

Cazul 6: Modificarea cheii primare în tipul de entitate părinte (Furnizori): Dacă se modifică cheia primară din tipul de entitate părinte, integritatea referinţelor se strică. Pentru menţinerea integrităţii, se pot folosii toate cazurile descrise mai sus, dar cel mai indicat este folosirea cazului CASCADĂ.

Regulile întreprinderii.În final evidenţiem acele reguli care sunt date de realitatea ce se va

modela în baza de date.Documentarea tuturor regulilor de integritate.Trecem toate regulile de integritate în dicţionarul de date.Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.Obiectivul: Convingerea că modelul creat reprezintă în totalitate

realitatea care trebuie modelată în baza de date.La acest pas modelul local logic este clomplet şi este bine documentat.

Înainte de a trece la pasul 3, trebuie verificat modelul, să fie conform cu realitatea. În cazul în care se găsesc diferenţe, ne vom reîntoarce la paşii anteriori şi modificăm cele necasare.

Pasul 3. Crearea şi validarea modelului global logic de date.Obiectivul: Combinarea modelelor locale logice într-un model logic

global care să reprezinte întreprinderea care este modelată.A treia activitate majoră în proiectarea bazei de date logice este crearea

modelului logic global, prin compunerea tuturor modelelor locale. După combinarea modelelor locale, trebuie validat modelul global prin tehnica de

95

normalizare şi după aceea, prin tehnica tranzacţiilor. Acest proces utilizează aceleaşi tehnici pe care le-am descris la paşii 2.3. şi 2.2.

Acest proces este foarte important în proiectarea bazei de date, pentru că el demonstrează că reprezentarea întreprinderii este independentă de orice utilizator, funcţie sau aplicaţie. Activităţile din acest pas sunt: Pasul 3.1. Compunerea medelelor logice locale într-un model logic global. Pasul 3.2. Validarea modelului logic global. Pasul 3.3. Verificarea posibilităţii de a completa baza de date în viitor. Pasul 3.2. Desenarea diagramei ER finale. Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.

Pasul 3.1. Compunerea modelelor logice locale într-un model logic global.

Obiectivul: Compunerea tuturor modelelor logice locale într-un model logic global al întreprinderii.

În cazul unui sistem mic, cu puţine vederi ai utilizatorilor, este relativ uşor de a compune modelele logice locale. În cazul unui sistem mai mare însă, trebuie să urmăm un proces sistematic de realizare a modelului global. Paşii acestui proces sunt următoarele:(1) Verificarea numelor entităţilor şi a cheilor lor primare.(2) Verificarea numelor relaţiilor.(3) Compunerea entităţilor de pe view-urile locale.(4) Includerea (fără compunere) a entităţilor care apar pe doar una dintre

view-uri.(5) Compunerea relaţiilor de pe view-urile locale.(6) Includerea (fără compunere) a relaţilor care apar pe doar una dintre view-

uri.(7) Căutarea entităţilor şi a relaţilor care lipsesc (dacă există).(8) Căutarea cheilor străine.(9) Căutarea regulilor de integritate.(10) Desenarea modelului logic global.(11) Actualizarea documentaţiei.

Cel mai uşor de compus mai multe modele locale este compunerea succesivă a două câte două dintre modele.

(1) Verificarea numelor entităţilor şi a cheilor lor primare.Această verificare se face folosind şi dicţionarul creat în decursul

paşilor de dinainte. Probleme apar doar atunci când: Două entităţi au acelaşi nume, dar sunt de fapt diferiţi. Două entităţi sunt aceleaşi, dar nu au aceleaşi nume.

Probabil va fi necesară analizarea atributelor antităţilor, prntru a rezola această problemă. În particular, putem utiliza cheia primară şi numele entităţii, pentru a identifica entităţile echivalente.

(2) Verificarea numelor relaţiilor.Această activitate este asemănătoare celei descrise la entităţi.(3) Compunerea entităţilor de pe view-urile locale.

96

Examinăm numele şi atributele entităţilor ca vor fi compuse. Activităţile care se includ în acest pas sunt: Compunerea entităţilor cau au aceleaşi nume şi aceleaşi chei primare. Compunerea entităţilor care au aceleaşi nume, dar cu chei primare diferite. Compunerea entităţilor care au nume diferite, cu chei primare egale sau

diferite.Compunerea entităţilor care au aceleaşi nume şi aceleaşi chei

primare. În general entităţile cu aceleaşi chei primare reprezintă “lumea reală”, şi deci pot fi compuse. Atributele care apar în entităţile de pe ambele view-uri, vor fi trecute doar o singură dată. Dacă într-un view apare un atribut compus, iar într-un alt view acelaşi atribut dar descompus în atribute simple, atunci vom întreba, dacă se poate, utilizatorii pentru a decide asupra formei de utilizare a atributului.

Compunerea entităţilor care au aceleaşi nume, dar au chei primare diferite. În astfel de situaţii, căutăm două entităţi care au aceleaşi nume şi nu au aceleaşi chei primare, dar au aceleaşi chei candidat. Cele două entităţi pot fi compuse, urmând ca după compunere să alegem o cheie primară, restul rămănând chei alternante.

Compunerea entităţilor care nu au nume comune şi nu au aceleaşi chei primare. Aceste entităţi se pot depista prin analiza atributelor celor două entităţi.

(4) Includerea (fără compunere) a entităţilor care apar doar într-un view.

Pasul anterior identifică toate entităţile comune. Celelalte entităţi, se vor include în modelul logic global exact aşa cum apar în view-ul respectiv.

(5) Compunerea relaţiilor de pe modelele locale.În acest pas analizăm similitudinile dintre relaţii de pe diferite modele

locale. În timpul compunerii relaţiilor trebuie rezolvate şi conflictele dintre relaţii, ca şi regulile de cardinalitate şi participare. Putem compune relaţii care au aceleaşi nume şi acelaşi scop, sau acelaşi scop, dar nume diferite.

(6) Includerea (fără compunere) a relaţiilor care apar doar pe un view.

Relaţile care au rămas neincluse în modelul global după pasul anterior, se includ în modelul global fără modificare.

(7) Căutarea entităţilor şi relaţilor care lipsesc.Este unul din cei mai grei paşi din crearea modelului global. Trebuie

căutate acele entităţi şi relaţii, care s-au omis la paşii anteriori şi n-au ajuns în modelul global.

(8) Căutarea cheilor străine.În decursul paşilor anterioare, s-au modificat entităţi, chei primare şi

chei străine. În acest pas verificăm dacă cheile străine sunt corecte în fiecare entitate fiu şi efectuăm toate modificările necesare.

(9) Căutarea regulilor de integritate

97

Verificăm dacă regulile de integritate a modelului global nu sunt în conflict cu regulile definite la modelele locale. Fiecare problemă de acest gen se rezolvă cu ajutorul utilizatorului sistemului.

(10) Desenarea diagramei ER.Acum desenăm diagrama ER pentru modelul global de date.(11) Actualizarea documentaţiei.Actualizăm documentaţia, ca să reflecte toate modificările aduse în

acest pas modelului. Pasul 3.2. Validarea modelului logic global.Obiectivul: Validarea modelului global logic de date, folosind

normalizarea, după care folosind tranzacţile cerute.Acest pas este schivalent cu paşii 2.3. şi 2.4., unde am validat modelul

local de date.Pasul 3.3. Verificarea posibilităţilor de extindere a bazei de date în

viitor.Obiectivul: Determinarea ca dacă modelul se acomodează uşor la

modificări oricât de mari ce pot intervenii în viitor.Este important ca modelul creat să fie expansibil în viitor. Dacă

modelul nu are această calitate, viaţa lui poate fi scurtă şi pentru o mai mare modificare va trebui refăcută de la început.

Pasul 3.4. Desenarea diagramei Entitz-Relationship finale.Obiectivul: Desenarea unei diagrame ER, care să reprezinte modelul

global de date al întreprinderii.Pasul 3.5. Verificarea modelului global cu ajutorul utilizatorului.Obiectivul: Verificarea că modelul global reprezintă în totalitate

realitatea.În acest moment modelul global este complet şi documentat. Împreună

cu utilizatorul sistemului se verifică acest model şi se aduc eventualele corecturi prin întoarcerea la paşii în cauză.

6.2.Proiectarea logică a bazei de date - Exemplu

În acest capitol vom învăţa despre: Cum să folosim metodologia de proiectare a bazelor de date

relaţionele, descrisă în 6.1. Cum să folosim această metodologie pentru proiectarea bazei de date a

sistemului ‘Asociaţie de locatari’.În acest capitol vom explica detaliat, cum putem folosi metodologia

prezentată în 6.1. Vom exemplifica folosirea metodologiei cu proiectarea bazei de date pentru sistemul informatic al asociaţiei de locatari.

În decursul acestui capitol, vom folosii expresiile “entitate” şi “relaţie” în locul expresiilor “tip de entitate” respectiv “tip de relaţie”. În cazul în care pot apărea ambiguităţi, se va folosii “tip de entitate” respectiv “tip de realţie”.

6.2.1. Cerinţele utilizatorilor.

Analiza şi colectarea datelor îl vom începe la o asociaţie de locatari. Aici trebuie să cerem informaţiile necesare pentru realizarea sistemului.

98

Trebuie să colectăm informaţiile despre lucrul de zi cu zi a şefului asociaţiei de locatari. Vom mai avea nevoie de toate rapoartele pe care ei le întocmesc. Toate informaţiile despre sistemul de evidenţă a asociaţiei de locatari se pot împărţi în mai multe view-uri. Aceste view-uri sunt: Evidenţa locatarilor şi a apartamentelor din asociaţie, Evidenţa cheltuielilor locatarilor, Evidenţa personalului asociaţiei, Evidenţa obiectelor de inventar şi a mijloacelor fixe, Plata datoriilor asociaţiei către furnizori”.

6.2.1.1. Cerinţele la baza de date.

Evidenţa locatarilor şi a apartamentelor din asociaţie:(1) În baza de date vor fi memorate toţi locatarii asociaţiei de locatari.

Informaţiile necesare despre locatari sunt: adresa (număr bloc, scara, etajul şi apartamentul) şi numele. Ei vor fi unic determinaţi de un număr matricol unic pe toată asociaţia de locatari.

(2) Dintre locatari trebuie să evidenţiem pentru fiecare familie câte un reprezentant. Pentru fiecare familie trebuie să avem la dispoziţie informaţiile: numărul membrilor de familie, numărul persoanelor prezente în locuinţă în luna curentă şi numărul de chei de la uşa principală.

(3) Tot dintre locatari se alege câte un şef de scară pentru fiecare scară din asociaţie. Şef de scară trebuie să fie exact unul pe fiecare scară şi trebuie să locuiască în scara pentru care s-a ales. Pentru şeful de scară mai avem în plus informaţia: data intrării în funcţie.

(4) La evidenţa clădirilor din asociaţia de locatari, avem de memorat scările care aparţin asociaţiei. Scările sunt identificate unic prin numărul blocului şi litera scării. Mai trebuie să ştim despre fiecare scară dacă are lift.

(5) Pe fiecare scară avem mai multe apartamente. Despre apartamente trebuie să memorăm informaţiile următoare: nr. apartamentului, suprafaţa, numărul de cutii poştale şi numărul de prize tv.

Evidenţa cheltuielilor locatarilor(1) Fiecare cheltuială se înregistrează în momentul primilii facturii de la

furnizor. Cheltuielile sunt identificate unic printr-un număr de ordine care este continuu pe un an. Pentru fiecare cheltuială se înregistrează informaţiile: codul cheltuielii, codul furnizorului, numărul şi data facturii, valoarea facturii.

(2) Cheltuielile se pot referii la o singură scară sau la mai multe scări, sau se pot referi la o singură familie sau mai multe familii.

(3) Pentru fiecare familie se înregistrează lunar valoarea ce trebuie plătită asociaţiei. Dacă este cazul, se înregistrează şi restanţele.

(4) Când o familie îşi achită datoria la asociaţie, se emite o chitanţă, care trebuie să conţină informaţii despre valoarea plătită, data plăţii şi numele persoanei care a făcut plata. Chitanţa se identifică unic prin numărul său.

(5) Pentru a efectua mai uşor înregistrarea cheltuielilor, memorăm şi datele despre furnizori. Aceste date sunt: denumirea, codul fiscal, contul bancar

99

şi banca, adresa (strada, numărul, bl., sc., ap., localitatea şi judeţul). Furnizorii se pot identifica unic printr-un cod intern - cod furnizor.

(6) Pe lângă cheltuielile către furnizori există şi cheltuieli, care trebuiesc plătite de locatari, dar care rămân la asociaţie. Astfel de cheltuială este fondul de rulment, fondul de reparaţii, sau dacă este cazul, şi alte fonduri. Aceste cheltuieli se vor înregistra în acelaşi mod ca şi celelalte, cu diferenţa că aici se va introduce un “furnizor” special pregătit.

(7) Fiecare familie trebuie să aibă plătită o sumă la asociaţia de locatari pentru fondul de rulment. În cazuri speciale se adună bani şi pentru fondul de reparaţii, sau alte fonduri.

Evidenţa personalului asociaţiei.(1) Personalul asociaţiei se va memora în baza de date, identificarea făcându-

se după un număr matricol unic. Mai folosim informaţiile: numele, data naşterii, meseria, data angajării şi scările din asociaţie unde lucrează.

(2) Un angajat poate să lucreze în mai multe scări şi pe o scară pot să lucreze mai mulţi angajati.

Evidenţa mijloacelor fixe şi a obiectelor de inventar.(1) Mijloacele fixe şi obiactele de inventar se vor identifica unic, cu ajutorul

unui cod numit numar de inventar. Pentru aceste obiecte mai reţinem următoarele informaţii: numele, valoarea şi locul unde este amplasat.

Plata datoriilor asociaţiei către furnizori.(1) O factură sosită de la un furnizor se poate achita prin casă, sau prin ordin

de plată. Pentru aceste achitări reţinem informaţiile: valoarea achitată, data achitării şi numărul urdinului de plată sau a chitanţei.

6.2.1.2. Tranzacţiile cerute.

Evidenţa locatarilor şi a apartamentelor din asociaţie:(1) Listă cu locatarii de pe o scară,(2) Listă cu familiile de pe o scară,(3) Listă cu şefii de scară,(4) Listă cu proprietăţile apartamentelor ocupate pe o scară.

Evidenţa cheltuielilor locatarilor(1) Listă cu cheltuielile fiecărei familii pe scări,(2) Listă cu toate cheltuielile asociaţiei de locatari.(3) Chitanţa care se emite la fiecare plată.

Evidenţa personalului asociaţiei.(1) Listă cu personalul asociaţiei.

Evidenţa mijloacelor fixe şi a obiectelor de inventar.(1) Listă cu mijloacele fixe şi valoarea lor, din asociaţia de loacatari,(2) Listă cu obiectele de inventar ai asociaţiei de locatari.

Plata datoriilor asociaţiei către furnizori.(1) Listă cu facturile scadente primite de la furnizori,

100

(2) Situaţia plăţilor facturilor de la furnizori, înglobând facturile dintr-o perioadă dată, împreună cu modul lor de plată.

6.3. Utilizarea metodologiei de proiectare a bazelor de date relaţionale.

Pasul 1. Crearea modelelor conceptuale locale, bazate pe view-urile utilizatorilor:

Înainte să ne apucăm de crearea modelului conceptual local, să ne reamintim din ce se compune acest model: tipuri de entităţi, tipuri de relaţii, atribute, domeniile atributelor, chei candidat, chei primare.

În acest capitol vom exemplifica metodologia de proiectare pe două vederi ai sistemului informatic: Evidenţa locatarilor şi a apartamentelor din asociaţie, Evidenţa cheltuielilor locatarilor.

Pasul 1.1. Identificarea tipurilor de entităţi.Începem să identificăm tipurile de entităţi din toate vederile

utilizatorilor. Vom descrie separat identificarea acestor entităţi pentru cele două vederi.

În cazul evidenţei locatarilor şi al apartamentelor, tipurile de entităţi sunt:

Locatari ScăriŞef de scară ApartamenteFamilii

În cazul evidenţei plăţilor tipurile de entităţi sunt:Cheltuieli FurnizoriPlăţi ChitanţeFamilii Scări

Documentarea tipurilor de entităţiÎn documentarea tipurilor de entităţi includem o descriere amănunţită a

fiecărei entotăţi, împreună cu aliasurile lor. Aceste informaţii sunt prezentate în anexa 6.6.2.1.

Pasul 1.2. Identificarea tipurilor de relaţii.În continuare identificăm tipurile de relaţii. Tipurile de relaţii se

reprezintă prin verbe ale relaţiilor. Tipurile de relaţii din cele două view-uri sunt prezentate în tabelele de mai jos:

Tipuri de relaţii din view-ul “Locatari”:Tip de entitate Tip de relaţie Tip de entitateScări sunt locuite de Locatari

101

sunt locuite de Familiisunt conduse de Şef de scarăse compun din Apartamente

Tipuri de relaţii din view-ul “Cheltuieli”:Tip de entitate Tip de relaţie Tip de entitateFurnizorii provoacă CheltuieliCeltuieli sunt plătite de Familii

sunt plătite de ScăriFamilii trebuie să plătească Plăţi

primesc ChitanţeDacă la acest pas apar ambiguităţi, ele trebuie neapărat clarificate cu

utilizatorii.Determinarea cardinalităţii şi a participării pentru tipurile de relaţii.În contunuare vom determina cardinalul şi participarea relaţiilor

prezentate în tabelele de mai sus. Cardinalul poate să fie unul dentre următoarele: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Participarea poate să fie parţială sau totală.

Informaţiile pe baza cărora trebuie să determinăm aceste caracteristici ai tipurilor de relaţii, sunt prezentate în capitorul XX. În cazul în care apar ambiguităţi, ele trebuie clarificate cu ajutorul utilizatorului.

Să luăm de exemplu relaţia dintre Scări şi Locatari. Pentru a fi foarte siguri de cardinalul relaţiei, vom pune următoarea întrebare:

Întrebare: Pot locui pe o scară mai mulţi locatari?Răspuns: Da.Deci relaţia Scările sunt locuite de Locatari are cardinalul 1:M. În

continuare va trebui să aflăm şi cardinalul relaţiei inverse, adică a relaţiei Locatarii locuiesc în apartementele de pe Scări.

Întrebare: Un locatar poate locui în mai multe apartamente de pe scări diferite?

Răspuns : Nu.La această întrebare avem nevoie de o explicaţie: Dacă o persoană are

două locuinţe în aceaşi asociaţie de locatari, atunci el va apare în entitatea locatari de două ori, cu număr matricol diferit. Deci un număr matricol poate să locuiască doar într-un singur apartament.

Deci cardinalul acestei relaţii este de 1:1, de unde rezultă că relaţia iniţială are cardinalul 1:M.

Pentru a afla participarea entităţilor la relaţie, punem următoarele întrebări:

Întrebare: Fiecare scară este locuită de cel puţin un locatar?Răspuns : Nu.Întrebare: Fiecare locatar locuieşte într-unul din aceste scări?Răspuns: Da.Deci tipul de entitate scări partcipă parţial, iar tipul de entitate Locatari

participă total la relaţie.Fie relaţia Cheltuieli sunt plătite de Scări, din view-ul “Cheltuieli”. Să

determinăm cardinalul şi participarea ei:

102

Întrebare: Există cheltuială care se referă la mai multe scări?Răspuns : Da.Întrebare: Scările pot avea mai multe cheltuieli?Răspuns : Da.Întrebare: Fiecare cheltuială trebuie să fie asociată unei scări?Răspuns : Nu, pentru că poate fi asociată doar unor familii.Întrebare: Fiecare scară trebuie să aibă cheltuieli?Răspuns : Nu, pentru că pot fi scări fără locatari.După aceste întrebări şi răspunsuri, am ajuns la concluzia că relaţia are

cardinalul N:M (ambele relaţii - şi cea directă şi cea inversă - au cardinalul 1:M), iar participarea parţială de ambele părţi.

Cardinalul şi partciparea relaţiilor de mai sus sunt prezentate în anexa 6.3.3.

Utilizarea modelării ER.Pentru o înţelegere mai uşoară a relaţiilor dintre entităţi, se poate folosi

diagrama ER. Diagramele ER ale celor două view-uri ale căror relaţii au fost prezentate mai sus, se pot vedea în figura 6.3.1. (a) şi (b).

Menţionăm, că verbele care reprezintă relaţiile de cardinal 1:M se pun în direcţia unu-la-multe. În cazul în care relaţia a fost altfel evidenţiată, ea va fi redenumită.

Documentarea tipurilor de relaţii.Documantarea view-urilor care apar în figura 6.3.1. este realizată în

anexa 6.2.3.

Sunt conduse de

Sunt locuite de

Se compun dinSunt locuite deLocatari Scari

Sef de scara

Familii

Apartamente

103

Figura 6.3.1.(a) Diagrama ER. a view-ului “Locatari”.

Sunt platite de

Sunt locuite deSunt platite de

PrimescTrebuie sa plateasca

Provoaca

Scari

Cheltuieli

Familii Furnizori

Plati Chitante

Figura 6.3.1.(b). Diagrama ER a view-ului “Cheltuieli”Pasul 1.3. Identificarea şi asocierea atributelor la tipurile de releţii şi

tipurile de entităţi.În acest pas identificăm atributele ce se asociază tipurilor de entităţi sau

tipurilor de relaţii. Atributele sunt informaţii care caracterizează entităţile, resoective relaţiile. Aceste atribute le putem găsi în descrierea acordată de utilizatori. În cazul nostru, atributele identificate şi asociate entităţilor se pot regăsi în tabela 6.3.2.a. şi 6.3.2.b.Tabela 6.3.2.a. Atributele tipurilor de entităţi din view-ul “Locatari”:Tip de entitate AtributeLocatari Nr_Mat

Adresa (Nr_bloc, Scara, Etaj, Apartament)Nume

Familii Nr_MatAdresa (Nr_bloc, Scara, Etaj, Apartament)NumeNr_persNr_pers_prezNr_chei

Sef_Scara Nr_MatAdresa (Nr_bloc, Scara, Etaj, Apartament)NumeData_intrare_func

Scări Adresa (Nr_bloc, Scara)Lift

Apartamente ApartamentSuprafaţaCutii_poştaleNr_prize_tv

Tabela 6.3.2.b. Atributele tipurilor de entităţi din view-ul “Cheltuieli”:

104

Tip de entitate AtributeFamilii Nr_mat

Fond_rulmentFond_reparaţiiAlte_fonduri

Plăţi DataValoareRestanţă

Chitanţe Nr_ChitValoareData

Cheltuieli Nr_crtCod_cheltuialaNr_facturaData_facturaValoare

Furnizori Cod_furnizorDenumireCod_fiscalContBancaAdresa (Strada, Nr., Bl., Sc., Ap., Localitate, Jud)

Documentarea atributelor:Pentru documentaţie se descrie fiecare atribut, se menţionează tipul de

date folosit precum şi lungimea câmpului, reguli, valoarea implicită, toate aliasurile lui, dacă atributul este sau nu compus, dacă este derivat sau nu, dacă admite mai multe valori şi dacă admite valoarea nulă.

O parte a acestei documentaţii este exemplificată în anexa 6.3.2. Pasul 1.2. Determinarea domeniilor atributelor:În acest pas determinăm domeniile atributelor. Domeniul unui atribut

este nulţimea acelor valori, pe care le poate lua în lucrul de zi cu zi.Documentarea atributelor.Câteva din domeniile exemplului nostru sunt arătate în anexa 6.3.2.Pasul 1.5. Determinarea atributelor care aparţin cheilor candidat şi

primare:Acum vom examina tabelele 6.2.2.a. şi 6.2.2.b., şi vom căuta cheile

candidat pentru entităţile în cauză. Dintre aceste chei candidat vom selecta cheia primară, după criterii deja descrise în 6.1.

Cheile primare şi alternante pentru entităţile din view-ul “Locatari” şi view-ul “Cheltuieli”, sunt afişate în anexa 6.3.2. Menţionăm, că în acest pas nu asociem chei primare entităţilor slabe, acesastă operaţie fiind rezolvată în pasul 2.2.

Documentarea cheilor primare şi alternante. Documentăm atributele care compun cheile primare şi cheile

alternante. Un exemplu de documentare găsiţi în anexa 6.3.2.

105

Pasul 1.6. Specializarea/generalizarea tipurilor de entităţi (pas opţional).

În acest pas putem dezvolta modelul ER, utilizând procesul de specializare/generalizare asupra entităţilor identifcate în pasul 1.1. Dacă vrem să folosim procesul de specializare, vom căuta diferenţele dintre entităţi, iar în cazul procesului de generalizare, asemănările dintre ele.

De exemplu, în view-ul “Locatari”, entităţile Locatari, Familii şi Şef_scară au atributele Nr_mat, Adresa şi Nume în comun. Entitatea Familii mai are în plus atributele Nr_pers, Nr_pers_prez şi Nr_chei iar entitatea Şef_scară are în plus doar atributul Data_intreare_func. Entitatea Locatari are asociate doar atributele comune cu cele două entităţi. Deci putem generaliza entităţile Familii şi Şef_scară, punând pe post de superclasă entitatea Locatari, iar celelalte două fiind subclase. Relaţia superclasă-subclasă dintre entitatea Locatari şi Familii respectiv Şef_scară este o relaţie parţială şi nondisjunctă, pentru că în Locatari sunt toţi locatarii asociaţiei, deci şi acelea care nu sunt nici capi de familie şi nici şefi de scară iar pe de altă parte, şeful de scară poate să fie şi cap de familie. Figura 6.3.3. reprezintă diagrama celor trei entităţi după procesul de generalizare.

Pentru o mai bună înţelegere a modelului local creat, folosim diagrama ER. Această diagramă şi documentaţia creată se referă la modelul local conceptual.

Diagramele ER ale celor două view-uri ai exemplului nostru se pot vedea în figura 6.3.2.a., respectiv 6.3.2.b.

Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.

Înainte de a termina pasul 1, trebuie verificat modelul la care s-a ajuns. Dacă se descoperă erori, atunci ne întoarcem la pasurile anterioare şi le remediem. Vom repeta aceşti paşi până când modelul creat va fi în conformitate cu realitatea.

Se compun din

Sunt locuite deLocatari

Scari

Sef de scara Familii Apartamente

106

Figura 6.3.3. Exemplu de relţie superclasă - subclasă

Figura 6.3.2.a. Modelul conceptual local al view-ului “Locatari”

Sunt platite de

Sunt platite de

PrimescTrebuie sa plateasca

Provoaca

Scari

Cheltuieli

Familii Furnizori

Plati Chitante

Figura 6.3.2.b. Modelul conceptual local al view-ului “Cheltuieli”.Pasul 2.2. Crearea şi validarea modelului local de date.În acest pas revizuim modelul creat şi eliminăm acele structuri care se

pot implementa greu în sistemul de gestiune a bazelor de date. După aceea validăm modelul, utilizând metoda normalizării şi a tranzacţiilor.

Pasul 2.1. Proiectarea modelului local conceptual în modelul local logic.

În acest pas eliminăm acele structuri din baza de date, care sunt dificil de implementat în sistemul de gestiune al bazelor de date. Pentru a rezolva această problemă, se vor urma următorii paşi:

(1)Eliminarea relaţiilor de tipul N:M.(2)Eliminarea relaţiilor complexe.(3)Eliminarea relaţiilor recursive.(4)Eliminarea relaţiilor cu atribute.(5)Reexaminarea relaţiilor de tipul 1:1.(6)Eliminarea relaţiilor redundante.

(1)Eliminarea relaţiilor de tipul N:M.Cum putem observa şi în figura 6.2.2.b., relaţiile Cheltuieli Sunt plătite

de Familii şi Cheltuieli Sunt plătite de Scări au cardinalul de N:M. Vom descompune aceste relaţii în câte două relaţii de tipul unu-la-multe (1:M), numite în ambele cazuri Se calculează şi Au cheltuieli. Această modificare devină posibilă prin introducerea a doi entităţi noi, numite Pe_familii, respectiv Pe_scări. Aceste entităţi noi vor fi entităţi slabe, pentru că vor depinde de entăţile Cheltuieli, Familii şi Scări. Adică cheia primară a lor va fi derivat din cheia primară a entităţilor tari.

Modificările se pot observa în figura 6.3.5. Figura 6.3.5. View-ul “Cheltuieli”, după eliminarea relaţiilor N:M.

(2) Eliminarea relaţiilor complexe.În acest pas, eliminăm toate relaţiile complexe (care sunt între mai mult

decât două entităţi) din modelul conceptual. Această eliminare se poate rezolva prin crearea a noi entităţi.

Exemplul nostru nu conţine nici o relaţie complexă.(3) Eliminarea relaţiilor recursive.

107

Pasul acesta este pentru eliminarea tuturor relaţiilor recursive, adică acele relaţii care pun în relaţie o entitate cu el însăşi. În exemplul nostru nu avem astfel de cazuri.

(4) Eliminarea relaţiilor cu atribute.Se elimină toate acele relaţii, care au asociate atribute. Eliminarea se

realizează prin adăugarea a noi entităţi, care vor memora aceste atribute. Nu este cazul exemplului nostru.

(5) Reexaminarea relaţiilor de tipul 1:1.În foarte multe din cazuri, entităţile care sunt relaţionate prin relaţii cu

cardinalul 1:1, se pot îngloba într-o singură entitate. De aceea este indicată reexaminarea relaţiilor de tipul unu-la-unu.

Exemplul nostru nu conţine relaţii de acest tip.(6) Eliminarea relaţiilor redundante.Pot exista cazuri în care să avem relaţii redundante. Adică să se poată

ajunge de la o entitate la alte prin mai multe drumuri diferite. În acest caz relaţiile redundante trebuie eliminate, pentru că noi trebuie să ajungem la o bază de date minimală şi foarte stabilă. Nu este cazul exemplului nostru.

Desenarea diagramei ER.Modelul conceptual care este reprezentat în figura 6.2.a. şi b., s-a

modificat în acest pas. Am eliminat din acest model, toate structurile greu de implementat într-un sistem de gestiune a bazelor de date. Diagrama modificată se va numi în continuare modelul local logic al bazei de date. Acest model este prezentat în figura 6.3.6.a. şi 6.3.6.b.

Se compun din

Sunt locuite deLocatari

Scari

Sef de scara Familii Apartamente

PrimescTrebuie sa plateascaSe calculeaza

Se calculeaza

Au cheltuieli

Au cheltuieli

ProvoacaChitantePlati

FurnizoriFamilii Pe familii

Pe scari

Cheltuieli

Scari

108

Figura 6.3.6.a. Modelul logic local al view-ului “Locatari”.

Figura 6.3.6.b. Modelul logic local al view-ului “Cheltuieli”.Pasul 2.2. Crearea de relaţii peste modelul logic local.În acest pas vom crea relaţiile între entităţile din modelul logic local de

date, cu ajutorul mecanismului chei primare/chei străine.Pentru exemplificarea acestui proces, să luăm relaţia Furnizori

Provoacă Cheltuieli din view-ul “Cheltuieli”. Vom folosi limbajul de definire a bazelor de date (DBDL), pentru descrierea fiecărei relaţii.

Pentru fiecare entitate tare a modelului, creăm o relaţie care include toate atributele simple ale entităţii. Structura entităţii Furnizori este:

Furnizori (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str., Bl., Sc.,

Ap., Loc., Jud.)Cheie primară: Cod_furnizorPentru fiecare entitate slabă, descriem relaţia, incluzând atributele

simple ale entităţii, specificând cheia străină şi entitatea la care se referă această cheie străină. Structura entităţii Cheltuieli este:

Cheltuieli (Nr_crt, Cod_furnizor, Cod_cheltuială, Nr_factură, Data_factură,

Valoare)Cheie primară: Nr_crtCheie străină : Cod_furnizorAcest proces continuă, până când se vor prelucra toade relaţiile din

baza de date.Documentarea relaţiilor şi a atributelor din cheile străine.Relaţiile derivate pentru view-urile “Locatari” şi “Cheltuieli” se pot

vedea în anexa 6.3.5., la sfârşitul acestui capitol. La crearea relaţiilor trebuie actualizat şi dicţionarul de date, cu atributele nou introduse şi cu noile chei primare şi alternante.

Pasul 2.3. Validarea modelului prin normalizare.În acest pas validăm baza de date prin normalizare. Procesul de

normalizare este descris amănunţit în capitolul 4. Forma Normală Unu (1NF), eliminarea repetiţiilor din atribute. Forma Normală Doi (2NF), eliminarea dependenţelor parţiale de cheia

primară. Forma Normală Trei (3NF), eliminarea dependenţelor tranzitive de

cheia primară. Forma Normală Boyce-Codd (BCNF), eliminarea anomaliilor care au

mai rămas.Trebuie să analizăm fiecare relaţie care este descrisă în anexa 6.3.5.

Verificăm dacă relaţiile sunt în forma normală Boyce-Codd, iar dacă găsim una care nu satisface această formă normală, ne întoarcem la paşii precedenţi şi rezolvăm problema.

Pentru a exemplifica acest proces, să analizăm relaţia Furnizori Provoacă Cheltuieli, descrisă în anexa 6.3.5. Menţionăm că notaţiile de aici nu includ cheia străină.

109

Furnizori (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str, Nr, Bl, Sc, Ap,

Loc, Jud)Cheie primară: Cod_furnizorCheie alternantă: Cod_fiscalCod_furnizor Denumire, Cod_fiscal, Cont, Banca, Str, Nr, Bl, Sc, Ap, Loc, JudCod_fiscal Cod_furnizor, Denumire, Cont, Banca, Str, Nr, Bl, Sc, Ap, Loc, JudCheltuieli (Nr_crt, Cod_furnizor, Cod_cheltuială, Nr_factură, Data_factură, Valoare)Cheie primară: Nr_crtNr_crt Cod_furnizor, Cod_cheltuială, Nr_factură, Data_factură, Valoare

Pentru acest exemplu avem următoarele demonstraţii: Nu există grupuri repetitive în niciunul dintre entităţi. Deci relaţia este

în forma normală unu. Fiecare cheie se compune dintr-un singur atribut. De aceea nu putem

avea dependenţă parţială de cheie. Deci relaţia este în formă normală doi. Nu există dependenţe tranzitive de cheie, deci relaţia este în formă

normală trei. Fiecare determinant evidenţiat este cheie, deci relaţia este în formă

normală Boyce-Codd.Acest proces se continuă pentru fiecare relaţie care apare în anexa

6.3.5.Pasul 2.2. Validarea modelului prin tranzacţiile cerute.Pentru a valida prin tranzacţii un model logic de date, folosim

diagrama ER. din figura 6.3.6.a. respectiv 6.3.6.b. şi documentaţia întocmită. Încercăm să rezolvăm manual toate tranzacţiile cerute de utilizator, folosind doar datele şi relaţiile din modelul de date creat. Dacă nu putem rezolva o tranzacţie, înseamnă că am omis ceva la modelarea bazei de date şi deci trebuie să ne întoarcem la paşii anteriori şi să remediem eroarea. Pe de altă parte, dacă o parte a modelului de date nu este folosită la nici o tranzacţie, atunci - în caz că nu se prevede ca în viitor să folosim această parte a modelului - va trebui să-l considerăm redundant, şi să-l eliminăm din modelul de date.

Considerăm două posibilităţi de verificare a modelului de date. Conform primei metode, ne asigurăm că există în modelul de date toate entităţile şi relaţiile care sunt necesare pentru tranzacţia aleasă. Pentru a exemplifica această metodă, să verificăm următoarea tranzacţie:

Crearea şi modificarea de înregistrări cu detaliile unei cheltuieli. Pentru crearea înregistrării despre o cheltuială, după introducerea

datelor despre cheltuială, se vor selecta şi scările sau familiile la care este asociată. O cheltuială nu poate fi asociată şi unor familii şi unor scări.

Pentru a modifica o cheltuială, trebuie să ştim numărul cheltuielii din bazs de date. Căutăm acea cheltuială şi dacă există modificăm detaliile despre cheltuială, recreînd şi legăturile la familii sau scări, depinde cine

110

trebuie să plătească. Dacă nu există, atunci apare un mesaj de eroare şi procedura de modificare se întrerpe.

În cazul ştergerii unei cheltuieli, prima dată trebuie căutate înregistrările de legătură a acelor cheltuieli cu scări sau cu familii. Dacă există - se şterg, după care se şterge şi cheltuiala. Dacă nu există înseamnă că nu există nici cheltuiala şi se va afişa un mesaj de eroare.

A doua modaliate de a verifica modelul de date este de a desena căile generate de relaţii, pentru fiecare tranzacţie în parte. Aceste căi se notează cu o linie având o săgeată în direcţia tranzacţiei. Tranzacţiile descrise în capitolul 6.2.1.2. sunt reprezentate prin diagramele din figurile 6.3.7.a. respectiv 6.3.7.b.

Se compun din

Sunt locuite deLocatari

Scari

Sef de scara Familii Apartamente

T 1.

T 2.

T 3.T 4.

PrimescTrebuie sa plateascaSe calculeaza

Se calculeaza

Au cheltuieli

Au cheltuieli

ProvoacaChitantePlati

FurnizoriFamilii Pe familii

Pe scari

Cheltuieli

Scari

T 2.

T 2.

T 1.T 3.

Figura 6.3.7.b. Tranzacţiile cerute pentru view-ul “Cheltuieli”.Pasul 2.5. Desenarea diagramei ER.Diagrama ER din figura 6.2.7.a. şi 6.2.7.b. ne ajuta să identificăm uşor

relaţiile critice pentru tranzacţii, precum şi ariile din modelul creat, care nu iau parte la nici o tranzacţiie. După identificarea şi eliminarea acestor arii, redesenăm diagrama ER.

În cazul nostru acestă diagramă nu se modifică.Pasul 2.6. Definirea regulilor de integritate.În acest pas identificăm acele reguli care să ne garanteze că datele

introduse în baza de date rămân consistente. Putem identifica cinci tipuri de reguli: necesitatea datelor, domeniile atributelor, integritatea entităţilor, integritatea relaţiilor, reguli date de intreprindere.

Necesitatea datelor.

111

Figura 6.3.7.a.Diagrama tranzacţiilor cerute la view-ul “Locatari”.

Identificăm acele atribute ale bazei de date, care nu admit valoarea nulă. De exemplu atributele Nr_mat - din entitatea Locatari - şi Adresa (Nr_bloc, Scara) - din entitatea Scări.

Aceste reguli asupra atributelor modelului sunt descrise în pasul 1.3. şi sunt documentate în anexa 6.3.2.

Domeniile atributelor.Domeniile atributelor identifică valorile posibile pe care le poate loa un

atribut. De exemplu atributul Etaj din entitatea locatari poate lua valori între -1 şi 100. Domeniile atributelor sunt descrise în pasul 1.2. şi sunt documentate în anexa 6.3.2.

Integritatea entităţilor.Cheia primară a entităţilor nu poate lua valori nule. De exemplu

Nr_mat, chiea primară a entităţii Locatari nu poate lua valoarea nulă. Cheile primare ale fiecărei entităţi au fost identificate în pasul 1.6. iar ducumentarea cheilor se găseşte în anexa 6.3.5.

Integritatea relaţiilor.Relaţiile dintre entităţi sunt reprezentate prin copierea chei primare a

entităţii “părinte”, în cheia străină a entităţii “fiu”. Integritatea relaţiilor se referă la faptul că dacă cheia străină dintr-o entitate slabă conţine o valoare, atunci această valoare să exista şi în entitatea tare la care este asociat prin relaţie.

De exemplu dacă se înregistrează plăţi unei familii în entitatea Plăţi, atunci acea familie trebuie să existe şi în entitatea Familii. Atributele care compum cheile primare şi cheile străine sunt descrise în anexa 6.3.5.

Este important ca să identificăm regulile relaţiilor, pentru ca relaţiile dintre entităţi să rămână consistente. Menţionăm că relaţiile se descriu cu limbajul specific definirii bazelor de date (DDL).

Prima dată să considerăm cazul că cheile străine au valoare nulă. În general când participarea entităţii slabe la relaţie este totală, nu se permite valoare nulă în cheia străină. De exemplu să descriem relaţia Scări Se compun din Apartamente. Entitatea Apartamente (slabă) participă total la relaţie, deci nu admitem valori nule atributelor din cheia străină şi anume Nr_bloc şi Scara.

Pe de altă parte, dacă entitatea slabă participă parţial la relaţie, putem admite valoare nulă şi a cheii străine. Nu este cazul exemplului nostru, pentru că nu avem entitate slabă cu participare parţială.

Descriem relaţia Scări Se compun din Apartamente cu limbajul DDL:Scări (Nr_bloc, Scara, Lift)Cheie primară: Nr_bloc, ScaraApartamente (Nr_bloc, Scara, Apartament, Suprafaţa, Cutii_poştale, Nr_prize_tv)Cheie primară: Nr_bloc, Scara, ApartamentCheie străină : Nr_bloc, Scara Nenulă referindu-se la Scări (Nr_bloc, Scara)

În continuare considerăm cazul în care se modifică cheia primară a entităţii tari. Menţionăm că inserarea cheii primare, sau ştergerea cheii străine nu dăunează consistenţei bazei de date.

112

Pentru celelalte chei primare, definim modul de modificare şi ştergere a cheii primare. Putem alege între patru moduri: FĂRĂ ACŢIUNE, CASCADĂ, SETARE NULĂ şi SETARE IMPLICITĂ. Descriem aceste modalităţi de modificare/ştergere pe baza relaţiei Scări Se compun din Apartamente, extinzând în continuare limbajul DBDL.Scări (Nr_bloc, Scara, Lift)Cheie primară: Nr_bloc, ScaraApartamente (Nr_bloc, Scara, Apartament, Suprafaţa, Cutii_poştale, Nr_prize_tv)Cheie primară: Nr_bloc, Scara, ApartamentCheie străină : Nr_bloc, Scara Nenulă, Cascadă, referindu-se la Scări (Nr_bloc, Scara)

Această operaţie se execută pentru fiecare relaţie descrisă în anexa 6.3.5.

Regulile întreprinderii.Aceste reguli sunt definite de întreprindere şi reprezintă reguli ce

trebuie respectate şi în viaţa de zi cu zi. De exemplu lista cu plăţile locatarilor se poate tipării doar pe durată de o lună. Toate aceste reguli sunt prezentate în anexa 6.3.6.

Documentarea regulilor de integritate.Toate cele descrise mai sus se documentează în modelul de date.Pasul 2.7. Revizuirea modelului de date cu ajutorul utilizatorului.În acest pas revizuim modelul creat cu ajutorul utilizatorului. Este

foarte important ca modelul să fie o reprezentare fidelă a realităţii. Utilizatorul sistemului trebuie să verifice atât diagrama cât şi documentaţia întocmită. Dacă se găseşte o eroare, se vor reface paşii necesari pentru corectarea erorii.

Pasul 3. Crearea şi validarea modelului global de date.În acest pas creăm modelul global prin compunerea entităţilor de pe

diversele modele locale. Acest model global va trebui şi ea validat prin normalizare.

Pasul 3.1. Compunerea modelelor locale în modelul global.În pasul acesta compunem două modele locale într-un model global de

date. Mai multe modele globale se compun tot două câte două, până când ajungem la modelul global. Pentru început identificăm similarităţile dintre modelele locale, după care trebuie identificate şi rezolvate ariile de conflicte între modele iar în final se trec toate modelele într-un singur model. Paşii care trebuie urmaţi pentru compunerea modelelor sunt prezentaţi în continuare:

(1) Revizuirea numelor entităţilor şi cheile lor primare.Comparăm numele şi cheile primare dintre două modele locale,

comparaţie ce este prezentată în tabela 6.3.8.Tip de entitate(view-ul Locatari)

Cheie primară Tip de entitate(view-ul Cheltuieli)

Cheie primară

Scări Nr_bloc, Scară Scări Nr_bloc, ScarăFamilii Nr_mat Familii Nr_matLocatari Nr_mat

113

Şef de scară Nr_matApartamente Nr_bloc, Scara, Ap.

Plăţi Data, Nr_matChitanţe Nr_chitPe_familii Nr_crtPe_scări Nr_crtCheltuieli Nr_crtFurnizori Cod_furnizor

Tabela 6.3.8. O comparaţie între numele entităţilor şi ale cheilor lor primare.Aceste similarităţi dintre entităţi arată care sunt acele modele care se

suprapun. Entităţile care se suprapun se pot compune, creând o singură entitate cu toate atributele entităţii din cele două modele.

(2) Revizuirea numelor relaţiilor.În continuare, comparăm numele relaţiilor din două modele de date. O

comparaţie între modelele Locatari şi Cheltuieli este prezentată în tabela 6.3.9. Relaţiile sunt incluse în această tabelă doar o singură dată în direcţia de la entitatea tare la cea slabă.

Tip entitateview-ul Locatari

Tip de relaţie

Tip entitate view-ul Locatari

Tip entitate view-ul Cheltuieli

Tip de relaţie Tip entitate view-ul Cheltuieli

Scări Sunt locuite de Locatari Scări Au cheltuieli Pe_scăriSe compun din Apartamente

Familii Au cheltuieli Pe_familiiTrebuie să plătească

Plăţi

Primesc ChitanţeCheltuieli Se calculează Pe_familii

Se calculează Pe_scăriFurnizori Provoacă Cheltuieli

Tabela 6.3.9. Comparaţia tipurilor de relaţii. Informaţiile cuprinse în această tabelă arată încă o dată aria modelelor care se suprapun. Este important să inţelegem că acelaşi nume se relaţie în două modele nu înseamnă că acele relaţii au şi acelaşi rol. Trebuie să avem mare grijă la astfel de nume de relaţii (se numesc omonime). Mai există şi posibilitatea ca relaţii care reprezintă aceleaşi concepte să fie denumite cu nume diferite (sinonime).

Aceste probleme la identificarea relaţiilor se pot rezolva, analizând atributele (şi în particular domeniile cheilor) asociate entităţilor care fac parte din relaţie.

În final trebuie să ne asigurăm că relaţiile pe care le considerăm echivalente să reprezinte aceleaşi relaţii şi în “lumea reală”.

(3) Compunerea entităţilor din cele două modele.

114

În acest pas analizăm numele şi conţinutul entităţilor din ambele modele. În particular, utilizăm cheia primară să vedem care dintre entităţi sunt echivalente, chiar dacă apar sub nume diferite în cele două modele.

Acest pas include următoarele activităţi: Compunerea entităţilor cu aceleaşi nume şi aceleaşi chei primare. Compunerea entităţilor cu aceleaşi nume dar cu chei primare diferite. Compunerea entităţilor cu nume diferite dar cu chei primare aceleaşi

sau diferite.Compunerea entităţilor cu aceleaşi nume şi aceleaşi chei primare.Entităţile care sunt denumite cu aceleaşi nume şi aceleaşi chei primare

în cele două modele reprezintă în general aceleaţi concepte a “lumii reale”. Deci aceste entităţi sunt cele mai simplu de identificat. Astfel de entităţi sunt de exemplu entităţile Scări şi Familii.

Entităţile combinate vor include toate atributele celor două entităţi din cele două modele, eliminându-se dublurile. Exemplul de compunere a entităţii Familii este prezentată în figura 6.3.10.

Compunerea entităţilor cu aceleaşi nume dar cu chei primare diferite.În cazurile când entităţile au acelaşi nume dar cu chei primare diferite,

trebuie să identificăm şi cheile alternante a celor două entităţi. Dacă între cheile candidat ale unei entităţi apare cheia primară a celeilalte, atunci compunem entităţile şi alegem o cheie primară dintre cele două chei primare.

În exemplul nostru nu avem astfel de caz.Compunerea entităţilor cu nume diferite dar cu chei primare aceleaşi

sau diferite.Putem întâlni cazuri în care nici numele entităţilor şi nici cheile

primare şă nu fie la fel, dar ştim din atributele celor două entităţi că ele reprezintă aceleaşi concepte. Aceste entităţi se compun ca la cazul anterior, având în plus obligaţia de a alege un nume care poate să fie una dintre cele două nume, sau o nume nouă.Figura 6.2.10. Exemplu de compunere a două entităţi.(view-ul Locatari)Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)Cheie primară: Nr_matCheie străină : Nr_mat referindu-se la Locatari (Nr_mat)(view-ul Cheltuieli)Familii (Nr_mat, Fond_rulment, Fond_reparaţii, Alte_fonduri)Cheie primară: Nr_mat(modelul global)Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei, Fond_rulment, Fond_reparaţii, Alte_fonduri)Cheie primară: Nr_matCheie străină : Nr_mat referindu-se la Locatari (Nr_mat)

(4) Includerea (fără compunere) a entităţilor unice în cele două modele.

115

După includerea tuturor entităţilor comune în modelul global, mai rămân alte entităţi care nu sunt comune şi care încă nu au fost incluse. Aceste entităţi se vor include neschimbat în modelul global. Astfel de entităţi sunt: Cheltuieli din modelul Cheltuieli, respectiv Apartamente din modelul Locatari.

(5) Compunerea tipurilor de relaţii din modelele locale.În acest pas analizăm numele şi caracteristicile relaţiilor pentru a le

putea compune. Este important de rezolvat conflictele datorate din participarea şi cardinalul relaţiilor. Numele relaţiilor din cele două modele sunt listate în tabela 6.2.9.

Compunerea relaţiilor cu aceleaşi nume şi aceleaşi caracteristici.Aceste relaţii sunt cel mai uşor de identificat. Compunerea se rezolvă

prin simpla înscriere a relaţiei în modelul global. Pot exista situaţii când cardinalul sau participarea nu coincid în cele două modele. Cazul acesta trebuie clarificat cu utilizatorul sistemului. Atragem atenţia că pot exista relaţii cu aceleaşi denumiri dar care să aibă roluri diferite (omonime).

Compunerea relaţiilor cu nume diferite dar cu aceleaşi caracteristici.Identificăm acele relaţii care apar în ambele modele dar cu denumiri

diferite. Acestă identificare devine evidentă după ce observăm că relaţia leagă aceleaşi entităţi. Şi în acest caz trebuie rezolvată problema cardinalului şi a participării.

(6) Includerea (fără compunere) a relaţiilor unice pe cele două modele.

Identificăm toate relaţiile pe care nu am inclus-o încă şi le includem neschimbat în modelul global. Toate relaţiile descrise în tabela 6.3.9. sunt de acest tip.

(7) Verificarea dacă s-a omis vre-o entitate sau relaţie.Această acţiune de verificare este foarte importantă dar şi foarte grea

de rezolvat. Entităţile şi relaţiile compuse pot avea chiar alt nume decât cele de pe modelele locale ceea ce face greu de urmărit includerea entităţii sau a relaţiei în modelul global.

(8) Verificarea cheilor străine.În acest pas verificăm dacă toate entităţile slabe conţin cheia străină

asociată lor. Aceste chei trebuie să se formeze la compunerea entităţilor, însă tot la compunere se pot şi redenumi.

(9) Verificăm regulile de integritate.Verificăm toate regulile de integritate pe modelul global de date si,

dacă apar probleme la verificare, ne întoarcem la paşii anteriori şi le remediem.

(10) Desenarea modelului global de date.Acum desenăm modelul global de date. Modelul global al sistemului

de evidenţă a asociaţiei de locatari este prezentată în figura 6.3.11.Numele entităţilor şi a relaţiilor se poate schimba la această acţiune.(11) Completarea documentaţiei.

116

Este foarte importantă actualizarea documentaţiei, pentru a reflecta modificările efectuate asupra bazei de date. Anexa 6.3.7. descrie relaţiile modelului global prezentat în figura 6.3.11., folosind limbajul DDL.

Sunt

Este

Primesc Trebuie sa plateasca

Se calculeaza

Se calculeaza

Au cheltuieli

Au cheltuieli

Se compun din

Contin

Sunt locuite de

Provoaca

Se achita

Alocate

Personal

Patrimoniu

Locatari Scari

Sef de scara

Cheltuieli

Pe scari

Pe familiiFamilii

Furnizori

Achitari

Apartamente

PlatiChitante

117

Figura 6.3.11. Diagrama globală şi finală ER.Pasul 3.2. Validarea modelului global de date.În acelaşi mod cum am validat modelele locale, trebuie validat şi

modelul global, folosind normalizarea şi validarea prin tranzacţii. Acesta este foarte important pentru a verifica (şi demonstra) dacă nu cumva s-au introdus erori la crearea modelului global.

Pasul 3.3. Verificarea posibilităţii de extindere în viitor.Este important ca modelul creat să se poată extinde în viitor. De

exemplu în sistemul de evidenţă a asociaţiei de locatari se va putea introduce un modul care să rezolve salarizarea personalului asociaţiei. Modelul global al aplicaţiei este extensibil, extinderea putându-se realiza cu minime modificări.

Pasul 3.4. Desenarea diagramei ER finale.La acest pas observăm că nu am modificat nimic de la ultima diagramă

desenată, deci diagrama ER finală este diagrama din figura 6.3.11.Pasul 3.5. Verificarea modelului global cu ajutorul utilizatorului.Este important să reexaminăm modelul creat împreună cu utilizatorul,

pentru a vedea dacă îndeplineşte toate cerinţele. Dacă apar cerinţe care nu sunt îndeplinite, ne întoarcem la paşii anteriori şi remediem situaţia.

Anexa 6.3.1. Documentarea tipurilor de entităţi în view-urile Locatari şi CheltuieliTipurile de entităţi din view-ul “Locatari”:Nume tipde entitate

Descriere Aliasuri Entităţi

Locatari Oamenii care locuiesc în asociaţie

Persoanele care au domiciliul în asociaţie

Familii Familiile din asociaţie Cap_familie Câte o persoană din fiecare familie, considerată reprezentantul acesteia

Sef_Scara Persoana care se ocupă cu problemele unei scări.

Câte o persoană de pe fiecare scară din asociaţie

Scări Scările din asociaţie Fiecare scară care aparţine asociaţiei, împreună cu caracteristicele ei.

Apartamente Apartamentele din asociaţie

Fiecare apartament din asociaţie, împreună cu caracteristicile ei.

Tipurile de entităţi din view-ul “Cheltuieli”:Nume tipde entitate

Descriere Aliasuri Entităţi

Scări Scările din asociaţie Analog ca la “Locatari”Familii Familiile din asociaţie Cap_familie Analog ca la “Locatari”Furnizori Societăţile de la care vin

facturileFiecare furnizor cu care s-a lucrat vreodată în asociaţie

Cheltuieli Cheltuielile asociaţiei Fiecare factură, care

118

către furnizori reprezintă o cheltuială a locatarilor din asociaţie.

Plăţi Plăţile calculate Plăţile calculate pentru fiecare familie

Chitanţe Chitanţele emise Toate chitanţele emise către locatari.

Anexa 6.3.2. Documentarea atributelorAtributele tipurilor de entităţi din view-ul “Locatari”:Tip de entitate

Atribute Descriere Tip de date şi lungime

Reguli

Locatari Nr_MatEtajApartamentNume

Det. unic locatarii Etajul la care loc.ApartamentulNumele locatarului

ÎntregÎntreg [-1,100]Întreg25 de caractere

Cheie primară

Familii Ca la Locatari, plusNr_persNr_pers_prez

Nr_chei

Nr. pers. în familieNr. pers. prezente în luna curentăNr. de chei de la uşa principală

Ca la Locatari plusÎntregÎntreg

Întreg

Ca la Locatari

Sef_Scara Ca la Locatari plusDataIntrFunc Data intrării în func

Ca la Locatari plusDată

Ca la Locatari

Scări Adresa Lift

(Nr_bloc, Scara)Există sau nu lift Logic

Cheie primară

Apartamente Apartament SuprafaţaCutii_poştaleNr_prize_tv

ApartamentulSup. totală a ap.Nr. cutii poştaleNr. prize tv.

ÎntregRealÎntregÎntreg

Atributele tipurilor de entităţi din view-ul “Cheltuieli”:Tip de entitate

Atribute Descriere Tip de date şi lungime

Reguli

Familii Nr_matFond_rulmentFond_reparaţiiAlte_fonduri

Identifică familiaFond de rulmentFond de reparaţiiAlte fonduri

ÎntregRealRealReal

Cheie primară

Plăţi DataValoareRestanţă

Luna pt. care e plataSuma de platăSuma restantă

DatăRealReal

Chitanţe Nr_chitValoareData

Id. unic chitanţaValoarea plătităData plăţii

ÎntregRealDată

Cheie primară

119

Cheltuieli Nr_crtCod_cheltuialaNr_facturaData_facturaValoare

Identifică cheltuialaTipul cheltuieliiNumărul facturiiData facturiiValoarea cheltuialii

ÎntregÎntregÎntregDatăReal

Cheie primară

Furnizori Cod_furnizorDenumireCod_fiscalContBancaAdresa

Identifică furnizorulNumele societăţiiCodul fiscalContul bancarBancaStr,Nr,Bl,Sc,Ap,Loc

Întreg30 de caractere10 caractere25 de caractere20 de caractere

Cheie primară

Cheie alt.

Anexa 6.3.3. Documentarea tipurilor de relaţii din view-urile “Locatari” şi “Cheltuieli”Tipuri de relaţii din view-ul “Locatari”:Tip de entitate

Tip de relaţie Tip de entitate Cardinal Participare*

Scări sunt locuite de Locatari 1:M P:Tsunt locuite de Familii 1:M P:Tsunt conduse de Şef de scară 1:M P:Tse compun din Apartamente 1:M T:T

Tipuri de relaţii din view-ul “Cheltuieli”:Tip de entitate

Tip de relaţie Tip de entitate Cardinal Participare*

Furnizorii provoacă Cheltuieli 1:M P:TCeltuieli sunt plătite de Familii M:N P:P

sunt plătite de Scări M:N P:PFamilii trebuie să plătească Plăţi 1:M T:T

primesc Chitanţe 1:M P:T* P=parţial, T=total.

Anexa 6.3.4.Documentarea domeniilor atributelorNume domeniu Caracteristici ExempleEtaj Întreg între -1 şi 100 0=ParterString30 30 de caractere, lungime variabilă ROMGAZString10 10 caractere, lungime variabilăString20 20 de caractere, lungime variabilă

Anexa 6.3.5.Descrierea relaţiilor din view-urile “Locatari” şi “Cheltuieli”Descrierea relaţiilor din view-ul “Locatari”.Locatari (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers, Nr_pers_prez,

Nr_chei, Data_intrare_func)

120

Cheie primară: Nr_matCheie străină : Nr_bloc, Scara referindu-se la Scări (Nr_bloc, Scara)Scări (Nr_bloc, Scara, Lift)Cheie primară: Nr_bloc, ScaraApartamente (Nr_bloc, Scara, Apartament, Suprafaţa, Cutii_poştale, Nr_prize_tv)Cheie primară: Nr_bloc, Scara, ApartamentCheie străină : Nr_bloc, Scara referindu-se la Scări (Nr_bloc, Scara)Descrierea relaţiilor din view-ul “Cheltuieli”:Scări (Nr_bloc, Scara)Cheie primară: Nr_bloc, ScaraFamilii (Nr_mat, Fond_rulment, Fond_reparaţii, Alte_fonduri)Cheie primară: Nr_matPlăţi (Data, Nr_mat, Valoare, Restanţă)Cheie primară: Data, Nr_matCheie străină : Nr_mat referindu-se la Familii (Nr_mat)Chitanţe (Nr_chit, Nr_mat, Valoare, Data)Cheie primară: Nr_chitCheie străină : Nr_mat referindu-se la Familii (Nr_mat)Furnizori (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str, Nr, Bl, Sc, Ap,

Loc, Jud)Cheie primară: Cod_furnizorCheie alternantă: Cod_fiscalCheltuieli (Nr_crt, Cod_furnizor, Cod_cheltuială, Nr_factură, Data_factură, Valoare)Cheie primară: Nr_crtCheie străină : Cod_furnizor referindu-se la Furnizori (Cod_furnizor)Pe_familii (Nr_crt, Nr_mat)Cheie primară: Nr_crtCheie străină : Nr_crt referindu-se la Cheltuieli (Nr_crt)Cheie străină : Nr_mat referindu-se la Familii(Nr_mat)Pe_scări (Nr_crt, Nr_bloc, Scara)Cheie primară: Nr_crtCheie străină : Nr_crt referindu-se la Cheltuieli (Nr_crt)Cheie străină : Nr_bloc, Scara referindu-se la Scări (Nr_bloc, Scara)

Anexa 6.3.6.Regulile date de întreprindere în cazul modelului “Locatari” şi “Cheltuieli”(1)Lista de plăţi se elaborează doar pe o lună întreagă.(2)Fiecare familie trebuie să declare la începutul lunii dacă va lipsii un

membru al familiei toată luna.

121

(3)Nici o familie nu va putea să se mute până când nu si-a plătit toate datoriile.

Anexa 6.3.7. Modelul global de date al sistemului Asociaţia de LocatariLocatari (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume)Cheie primară: Nr_matCheie străină : Nr_bloc, Scara Nenulă, referindu-se la Scări (Nr_bloc, Scara)

la ştergere şi la modificare Cascadă.Familii (Nr_mat, Nr_pers, Nr_pers_prezente, Nr_chei, Fond_rulment,

Fond_reparaţii, Alte_fonduri)Cheie primară: Nr_matCheie străină : Nr_mat Nenulă, referindu-se la Locatari (Nr_mat)

la ştergere şi modificare Cascadă.Şef_de_scară (Nr_mat, Data_intrare_func)Cheie primară: Nr_matCheie străină : Nr_mat Nenulă, referindu-se la Locatari (Nr_mat)

la ştergere şi modificare Cascadă.Scări (Nr_bloc, Scara, Lift)Cheie primară: Nr_bloc, ScaraApartamente (Nr_bloc, Scara, Apartament, Suprafaţa, Cutii_poştale, Nr_prize_tv)Cheie primară: Nr_bloc, Scara, ApartamentCheie străină : Nr_bloc, Scara Nenulă, referindu-se la Scări (Nr_bloc, Scara)

la ştergere şi modificare Cascadă.Plăţi (Data, Nr_mat, Valoare, Restanţă)Cheie primară: Data, Nr_matCheie străină : Nr_mat Nenulă, referindu-se la Familii (Nr_mat)

la ştergere Fără acţiune, la modificare Cascadă.Chitanţe (Nr_chit, Nr_mat, Valoare, Data)Cheie primară: Nr_chitCheie străină : Nr_mat Nenulă, referindu-se la Familii (Nr_mat)

la ştergere Fără acţiune, la modificare Cascadă.Furnizori (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Strada, Nr, Bl, Sc,

Ap, Localitate, Judet)Cheie primară: Cod_furnizorCheie alternantă: Cod_fiscalCheltuieli (Nr_crt, Cod_furnizor, Cod_cheltuială, Nr_factură, Data_factură,

Valoare_factură)Cheie primară: Nr_crtCheie străină : Cod_furnizor Nenulă, referindu-se la Furnizori (Cod_furnizor)

la ştergere Fără acţiune, la modificare Cascadă.

122

Pe_familii (Nr_crt, Nr_mat)Cheie primară: Nr_crtCheie străină : Nr_crt Nenulă, referindu-se la Cheltuieli (Nr_crt)

la ştergere şi modificare Cascadă.Cheie străină : Nr_mat Nenulă, referindu-se la Familii(Nr_mat)

la ştergere şi modificare Cascadă.Pe_scări (Nr_crt, Nr_bloc, Scara)Cheie primară: Nr_crtCheie străină : Nr_crt Nenulă, referindu-se la Cheltuieli (Nr_crt)

la ştergere şi modificare Cascadă.Cheie străină : Nr_bloc, Scara Nenulă, referindu-se la Scări (Nr_bloc, Scara)

la ştergere şi modificare Cascadă.Personal (Nr_matricol, Nume, Data_naşterii, Meseria, Data_angajării)Cheie primară: Nr_matricolAlocate (Nr_matricol, Nr_bloc, Scara)Cheie primară: Nr_matricol, Nr_bloc, ScaraCheie străină : Nr_matricol Nenulă, referindu-se la Personal (Nr_matricol)

la ştergere şi modificare Cascadă.Cheie străină : Nr_bloc, Scara Nenulă, referindu-se la Scări (Nr_bloc, Scara)

la ştergere şi modificare Cascadă.Patrimoniu (Nr_inventar, Nr_bloc, Scara, Denumire, Inv_fix, Valoare)Cheie primară: Nr_inventarCheie străină : Nr_bloc, Scara Nenulă, referindu-se la Scări (Nr_bloc, Scara)

la ştergere şi modificare Cascadă.Achitări (Nr_crt, Nr_doc, Tip_op, Valoare_achit, Data)Cheie primară: Nr_Doc, Tip_OpCheie străină : Nr_crt Nenulă, referindu-se la Cheltuieli (Nr_crt)

la ştergere şi modificare Cascadă.

Capitolul 7. Baze de date distribuite7.1. Generalităţi

O baza de date distribuită (BDD) este o colecţie logic corelată de date partajate, distribuite fizic pe o reţea de calculatoare.

Un sistem de gestiune al unei baze de date distribuite (SGBDD) este un sistem software care permite gestionarea BDD şi face distribuirea transparentă pentru utilizator.

Sistemele de date distribuite sunt menite să rezolve problema "insulelor de informaţii". Ele au apărut ca o necesitate, în special in cazul reţelelor de

123

calculatoare, pentru a sprijini gestionarea datelor în situaţia când acestea se regăsesc fizic în diferite puncte ale reţelei.

Primele sisteme de baze de date distribuite au fost INGRES/STAR, versiune distribuită a lui INGRES, SQL*STAR versiune distribuită a lui ORACLE şi R* versiune distribuita a lui DB2.

Sistemul fizic (reţeaua) care constituie suportul unei baze de date distribuite poate fi format din calculatoare personale, minicomputere, staţii de lucru, etc. toate legate în reţea şi numite generic site-uri.

Putem reformula definiţia de la început spunând ca un sistem de baze de date distribuite constă dintr-o colecţie de site-uri, fiecare putând participa la executarea tranzacţiilor care accesează datele de pe un site sau de pe mai multe site-uri.

Printre cerinţele pe care trebuie să le asigure un sistem de baze de date distribuite menţionăm: autonomia locala în organizarea şi prelucrarea datelor, neutilizarea unei centralizări a evidenţei şi a datelor, posibilitatea de lucru continuu al site-urilor independent de schimbările in configuraţiile de lucru (adăugari sau eliminari de site-uri), independenţa localizării şi fragmentării datelor (transparenţa fizică), posibiliăţti de replicare (copiere) şi independenţa copiilor, prelucrarea distribuită a cererilor, administrarea distribuită a tranzacţiilor, independenţa de hardware, de sistemul de operare, de reţea şi de sistemul de gestiune a bazelor de date.

Un SGBDD constă dintr-o singură bază de date care este descompusă în fragmente, eventual unele fragmente sunt multiplicate, şi fiecare fragment sau copie se pastrează pe unul sau mai multe site-uri, sub controlul unui SGBD local. Fiecare site este capabil sa proceseze interogări utilizator în regim local, independent de restul reţelei, sau este capabil să participe la procesarea unor date situate în alte site-uri din reţea. Pentru a spune că un SGBD este distribuit trebuie să existe cle puţin o cerere globală.

Tranzacţiile într-o baza de date distribuită sunt clasificate în tranzacţii locale şi tranzacţii globale după site-urile pe care le solicită excutarea lor.

O configuratie pe retea reprezinta o baza de date distribuita daca diversele site-uri sunt "constiente" de existenta celorlalte site-uri şi daca fiecare site ofera un mediu in care se pot executa tranzactii locale şi globale.

Avantajele distribuirii bazelor de date:

- sistemul distribuit se modelează cel mai bine pe structura organizaţională a multor organizaţii, avand în vedere ca multe companii sunt localizate "distribuit" din punct de vedere geografic

- datele sunt partajabile dar administrarea lor se bucură de un grad înalt de autonomie locală

- disponibilitatea bazei de date este evident mai bună decât în cazul centralizat. Dacă se semnalează unele erori sau "ăderi" de sistem la nivel

124

local sistemul ]n întregime poate să continue să funcţioneze în condiţii satisfăcătoare

- fiabilitatea sistemului este îmbunătăţită. Se pot reface rapid fişiere distruse utilizând replici aflate pe alte site-uri

- performanţele în prelucrarea datelor se îmbunătăţesc prin posibilitatea prelucr[rii în paralel a unor interog[ri

- un sistem distribuit oferă avanatje economice dacă luăm în considerare costurile implementării şi întreţinerii unei reţele faţă de costurile corespunzătoare ale unui sistem centralizat de putere comparabilă de prelucrare. Costuri scazute se mai obtin daca se realizeaza prelucrări locale cât mai multe (în cază sistemul şi aplicaţiile permit acest lucru). De asemenea este mult mai convenabil să se "ajusteze" o reţea de calculatoare la nevoile organiza’iei (dac[ de exemplu este necesară adăugarea unor site-uri în plus) decât un calculator central de putere asemănătoare

- capacitatea de gestionare modulară a sistemului permite extensii ale acestuia sau rezolvarea unor "căderi" parţiale fără să se afecteze prea tare (uneori fără a se afecta deloc) mersul activităţilor pe ansamblul sistemului distribuit.

Printre dezavantajele distribuirii amintim complexitatea crescuta a unui astfel de sistem.

Acesta este un dezavantaj major din care decurg unele dezavantaje "consecinta" dintre care:

- este mai greu de gestionat şi de implementat un sistem distribuit

- costurile legate de un astfel de sistem sunt mult mai mari decat in cazul centralizat. Deja la nivelul proiectarii şi implementarii sistemului este necesar mai mult timp şi personal specializat. Ambele lucruri necesita costuri mai mari in bani. La aceste costuri se pot adauga acelea care vin din necesitatea asigurarii echipamentelor hardware performante şi a soft-ului necesar. De asemenea, in cazul exploatarii sistemului la costurile obisnuite se vor adauga costuri destul de ridicate de comunicatii.

- potential marit de erori. La erorile obisnuite in lucrul cu baze de date se pot adauga o serie de erori cum ar fi de exemplu cele generate de algoritmi distribuiti.

- este necesara o procesare suplimentara care se datoreaza schimburilor de mesaje intre site-uri şi a coordonarii acestora in general

- securitatea unui sistem distribuit este mai greu de asigurat decat in cazul unui sistem centralizat. Datele sunt mai usor disponibile unor persoane neautorizate deoarece se poate incerca acces la ele prin intermediul accesului intre calculatoare. Controlul la nivel fizic administrativ are mai putina pondere decat in cazul unui sistem centralizat.

125

- intergitatea datelor este de asemenea mai greu de realizat intr-un sistem distribuit. Integritatea se exprima de obicei in termeni de restrictii (reguli, conditii) pe care trebuie sa le verifice datele din baza de date. Datorita costurilor mari de comunicatii (in timp şi bani) uneori se renunta la verificarea unor reguli in detrimentul consistentei bazei de date.

- lipsa standardelor. Nu se poate vorbi de o lipsa totala de standarde dar, lucrul cu sisteme de date distribuite inca nu are la baza standarde internationale unanim acceptate. De aici decurg dezavantaje cum ar fi: probleme de comunicare care se pun deoarece standardele de comunicatii şi protocoalele de acces la date inca nu au standarde fixate şi acceptate pe scara larga. Nu exista foarte multa experienta privind lucrul distribuit şi proiectarea, gestionarea şi exploatarea unui sistem distribuit sunt mai dificile decat in cazul centralizat.

- un alt dezavantaj pe care il mentionam aici il constituie posibilitatea aparitiei unui flux mare de informatii intre site-uri şi de aici necesitatea rezolvarii unor probleme cum ar fi sincronizarea mesajelor, detectarea şi corectarea unor perturbari, eliminarea unor inconsistente datorate redundantelor, etc.

7.2. Functiile şi arhitectura unui SGBDD

Enumeram mai jos functiile principale ale unui SGBDD:

- toate functiile pe care le atribuim unui SGBD centralizat

- sa extinda comunicatiile pentru a furniza acces la site-urile din retea şi sa permita transferul de date şi realizarea interogarilor

- sa gestioneze un dictionar de date extins pentru detalii legate de modul de distribuire a datelor

- sa permita şi sa sustina procesarea distribuita a interogarilor

- sa faciliteze un control extins al concurentei in scopl mentinerii unui grad satisfacator al consistentei datelor

- sa ofere servicii de recovery extinse care sa rezolve caderi ale site-urilor şi ale comunicatiilor

Arhitectura ANSI-SPARC pe trei nivele a unei baze de date distribuite este redata grafic in pagina urmatoare, Fig 7.1. Dam mai jos cateva explicatii referitoare la unele elemente prezente in schema:

- schema conceptuala globala este o descriere logica a intregii baze de date, fara a se evidentia aspectul distribuit. La acest nivel se definesc entitatile, relatiile, restrictiile de integritate, informatiile generale de securitate a datelor.

- schemele de fragmentare descriu modelul logic al partitionarii bazei de date iar alocarea descrie repartizarea fragmentelor şi a eventualelor copii ale acestora pe site-urile retelei

126

- schemele locale de mapare redau fragmentele din schema de alocare in "obiecte" externe bazei de date locale. Aceasta descriere este independenta de SGBD-ul ales şi datorita acestui fapt se poate vorbi de SGBD heterogene.

Ca o paranteza mentionam aici clasificarea SGBD-urilor distribuite in heterogene şi omogene.

SGBD omogene reprezinta situatia cand pe toate site-urile din retea este hardware similar, sistem de operare identic si, cel mai important, SGBD local identic.

In cazul SGBD heterogene exista mai multe situatii dupa cum difera dotarea hardware, sistemele de operare si/sau SGBD-urile utilizate local pe site-uri. Diferentele pot fi impinse pana la a avea structuri ale bazei de date diferite (date de modele de date diferite) dar, evident, lucrul in acest caz este destul de greoi şi este supus multor limitari.

127

Schema externa globala

Schema externa globala

Schema conceptuala

globala

Schema de fragmentare

Schema de alocare

Schema locala de mapare

Fig.7.1. Arhitectura ANSI-SPARC pe trei nivele

128

Schema conceptuala

locala

Schema interna locala

In cadrul unui SGBDD putem identifica urmatoarele componente:

- o componentă locală SGBD (LSGBD)

- o componentă de comunicaţii de date (CD)

- un dicţionar de date global (DDG). Acest dicţionar are aceeaşi funcţionalitate ca şi und dicţionar de date în cazul SGBD centralizat dar conţine informaţii suplimentare referitoare la fragmentare şi la alocarea datelor. Şi DDG poate fi fragmentat şi replicat ca orice altă informaţie din baza de date distribuită

- componente de SGBD distribuit (SGBDD)

7.3. Proiectarea unei baze de date relaţionale distribuite

Proiectarea corectă a unei baze de date relaţionale distribuite necesită, pe lângă cerinţele cunoscute pentru sistemele centralizate, şi realizarea următoarelor:

- fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi stocate pe diferite site-uri în reţea

- replicarea – se pot realiza copii ale diferitelor relaţii sau ale fragmentelor

- alocarea fragmentelor şi a replicilor pe diferite site-uri

Definirea fragmentelor şi alocarea acestora pe site-uri au ca obiective:

- realizarea, pe cat posibil a accesului in regim de referinte locale. Acolo unde este necesar şi unde permite aplicaţia se recomanda utilizarea de copii ale fragmentelor

- obtinerea unei fiabilitati şi a unei disponibilitati deosebite ale bazei de date prin utilizarea optima a replicarii fragmentelor

- realizarea unor parametri deosebiti de performanta. Daca se aloca prost datele pe site-uri se ajunge fie la suprasolicitarea unui site (loc ingust) fie la utilizarea resurselor la un nivel inferior

- optimizarea capacitatii şi a costurilor de stocare. Capacitatea şi costuril de stocare trebuie puse in balanta cu tendinta de a avea referinte locale, deoarece au efecte contrare.

- optimizarea costurilor de comunicare. Aici sunt de luat in considerare mai ales costurile interogarilor intre site-uri. Trebuie sa se aiba in vedere ca, daca se pot micsora costurile de regasire atunci cand referintele sunt mai ales locale (sau cand fiecare site are propriile copii ale datelor) in schimb actualizarile in aceeasi situatie pot creşte costurile foarte mult (si riscul obtinerii inconsistentei) deoarece trebuie sa fie realizate asupra datelor de la toate site-urile.

129

7.4. Alocarea datelor

Se cunosc patru strategii de alocare a datelor într-o baza de date relaţională distribuită:

1. centralizat

Baza de date se află în întregime pe un singur site din reţea şi este gestionată de un singur DBMS. Spunem în acest caz că baza de date este procesată distribuit, ea de fapt nu mai este o bază de date distribuită in adevaratul sens al cuvântului. Dezavantajele sunt mai ales costurile mari de comunicaţii şi o fiabilitate şi o disponibilitate foarte scăzute, având în vedere că orice eroare care blochează accesul la baza de date, practic paralizează întreaga activitate în reţea pe această direcţie.

2. fragmentat (partiţionat)

Baza de date este partiţionată în mai multe fragmente disjuncte care sunt stocate pe diverse site-uri. Comentarii:

- aceasta parţitionare a datelor poate îmbunătăti frecvenţa referinţelor locale

- dacă nu există replici ale fragmentelor, costurile de stocare sunt reduse

- fiabilitatea şi disponibilitatea sunt scăzute dar nu aşa de mici ca în cazul centralizat

- dacă datele sunt distribuite corect, costurile de comunicare pot fi relativ scăzute

3. replicat complet

Pe fiecare site se găseste o copie completă a bazei de date. Comentarii:

- eficienţa referirilor locale, fiabilitatea şi disponibilitatea sunt maxime

- costurile de stocare sunt în schimb şi ele foarte mari, la fel sunt şi costurile de actualizare

4. replicat selectiv

Aceasta strategie este o combinaţie intre partiţionare, replicare şi centralizare cu scopul de a se cumula, pe cat posibil, avantajele fiecărei strategii şi să se elimine dezavantajele.

Definirea replicilor şi a fragmentelor, precum şi alocarea acestora trebuie sa se bazeze pe modul de utilizare a datelor din baza de date. In faza de analiza, la proiectarea bazei de date trebuie sa se tina cont de cele mai frecvent utilizate aplicaţii deoarece nu se poate realiza o alocare care sa optimizeze toate aplicaţiile simultan.

Printre criteriile care duc la decizia corecta de alocare a bazei de date:

- frecventa cu care se ruleaza o aplicaţie

- site-urile de la care se ruleaza cel mai frecvent aplicaţia

130

- modul de lucru al tranzactiilor executate de aplicaţie şi tipurile de acces la date

- etc.

7.4.1. Fragmentarea

La baza fragmentarii bazei de date exista, printre altele, urmatoaele motivari:

- mod de utilizare – in general intr-o aplicaţie utilizatorii au acces mai mult la view-uri decat la intreaga baza de date

- eficienta – se doreste ca datele sa fie stocate acolo unde sunt utilizate mai frecvent

- paralelism – o tranzactie poate fi divizata in mai multe subinterogari care opereaza pe fragmente in paralel şi astfel se castiga timp

- securitate – datele care nu sunt necesare sunt stocate in alta parte, deci nu sunt la dispozitia accesului neautoarizat

Dezavantajele lucrului cu fragmente ale bazei de date:

- performantele pot fi destul de scazute daca sunt necesare date ce apar in diverse fragmente

- controlul integritatii datelor este mai dificil daca datele şi dependentele functionale sunt fragmentate şi localizate pe diferite site-uri

Reguli de bază care duc la o fragmentare corectă a bazei de date:

1. completitudine – dacă relaţia R este descompusă în fragmentele R1, R2, …,Rn, trebuie luate măsuri care să prevină pierderea de informaţii

2. reconstrucţie – să fie posibil în orice moment să se refacă relaţia R de la care s-a pornit cu fragmentarea. Aceasta regulă conservă dependenţele funcţionale.

3. disjuncţie – dacă data di apare în fragmentul Ri atunci nu este permis să apară în nici un alt fragment. De la această regulă se admite doar o excepţie, cazul când o relaţie este fragmentată pe verticală.

Tipuri de fragmentare:

- pe orizontală

- pe verticală

- combinată

Fragmentarea pe orizontală:

Ne putem imagina că o tabelă se fragmentează orizontal ca mai jos:

131

Un fragment al unei relaţii partitionate pe orizontală constă dintr-o submulţime a tuplelor relaţiei respective.

Un fragment orizontal se produce prin selecţie:

Fiecare tuplu din relatia R apare într-un anume fragment, o singură dată. Dacă se doreşte reconstrucţia relaţiei, se utilizează reuniunea pentru a obţine relaţia R iniţiala.

R= R1R2…Rn

In general fragmentele unei relaţii R sunt disjuncte.

Fragmentarea pe verticală

Un fragment vertical dintr-o relaţie consta dintr-o relaţie care are ca atribute o submulţime a atributelor relaţiei iniţiale.

Un fragment vertical se produce prin proiecţie:

Dacă S1R şi S2R atunci şi .

Completitudinea este asigurată prin faptul că fiecare atribut apare cel puţin într- una din submulţimile S1 şi S2.

Reconstrucţia relaţiei iniţilale se realizează prin joncţiune naturală.

Aşadar la descompunerea relaţiei iniţiale în fragmente trebuie să se ţină seama de regulile care asigură o descompunere fără pierderi la joncţiune.

In cazul descompunerii pe verticală nu este posibil să se realizeze o disjuncţie totală. Se admite existenţa unor atribute comune, şi anume a atributelor care formează cheile primare (respectiv cheile externe). Fragmentele verticale se stabilesc prin determinarea afinităţilor între atribute, încă din faza de analiză.

Fragmentarea combinată (mixtă, hibridă, compusă)

1. fragmente verticale fragmentate orizontal

Expresia corespunzatoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai sus) este:

132

2. fragmente orizontale fragmentate vertical

Expresia corespunzătoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai sus) este:

7.5. Transparenta în SGBDD

Prima regula, considerata regula de baza in sistemele distribuite, este cerinta ca aspectul distribuit trebuie sa fie transparent pentru utilizator.

Cu alte cuvinte utilizatorul nu trebuie sa-si dea seama ca lucreaza cu o baza de date distribuita, deci nu trebuie sa aiba cunostinte in plus ca sa utilizeze resursele unei astfel de baze de date.

În realitate transparenţa poate fi realizată doar într-o anumită măsură. Tipuri de transparenţă:

1. transparenţa distribuirii

2. transparenţa tranzacţiilor

3. transparenţa performanţelor

7.5.1. Transparenta distribuirii

Dacă se realizează transparenţa distribuirii, utilizatorul percepe baza de date ca pe o entitate unitară din punct de veder logic.

Acest tip de transparenţă se poate descompune în două aspecte: utilizatorul nu trebuie să cunoască faptul că există fragmentarea datelor (transparenţa fragmentării) sau utilizatorul nu ştie de localizarea datelor pe reţea (transparenţa localizării).

Transparenţa fragmentării este cel mai înalt grad de transparenţa. Utilizatorul se adresează cu interogări bazei de date ca şi când ar fi localizată centralizat, deci nu trebuie să se preocupe de existenţa fragmentelor.

Transparenţa fragmentării este strâns legată de acordarea numelor (identificatorilor) în cadrul bazei de date distribuite. Şi într-o bază de date distribuită (ca şi în cazul centralizat) numele diferitelor "obiecte" trebuie să fie unic. Două site-uri nu pot conţine obiecte cu nume identice.

Sunt cateva solutii posibile:

1. Se poate crea un server central de nume care are menirea sa sigure ca numele date in aplicaţii distribuite sunt nume unice pe toata baza de date.

133

Aceasta abordare are dezavantajele ca se pierde autonomia locala a site-urilor, se poate ajunge la o suprasolicitarea serverului de nume (se creeaza un asa-numit loc ingust - "bottleneck") şi disponibilitatea bazei de date este redusa (daca serverul de nume iese din uz temporar, se blocheaza accesul la date)

2. Alternativa la solutia de mai sus este sa se recurga la prefixarea obiectelor cu un identificator de site, de fragment, de copie.

Exemplu: prin notatia s1.client.f3.c2 se poate desemna copia a doua a fragmentului 3 a tabelei client care se afla pe site-ul s1.

Consecinta cea mai grava a acestui mod de a numi obiectele este pierderea completa a transparentei. In aceasta situatie mai exista un mod prin care se poate "indulci" situatia: se utilizeaza alias-uri. De exemplu s1.client.f3.c2 poate avea ca alias numele client_local pentru utilizatorii site-ului s1.

Transparenta localizarii reprezinta un nivel mediu de transparenta. In aceasta situatie utilizatorul stie cum este fragmentata baza de date dar nu stie unde sunt plasate diferitele fragmente sau copii ale acestora.

In interogari vor aparea numele fragmentelor dar nu se vor face referiri la localizare. O interogare poate avea un format asemanator cu cel de mai jos:

select A1,…An

from f1where conditie1

unionselect A1,…An

from f2… … …

Avantajul major in cazul de mai sus consta in faptul ca se poate oricand reorganiza baza de date (ca locatii) fara ca aplicaţiile ce o utilizeaza sa trebuiasca modificate.

Transparenta maparii locale reprezinta cel mai jos nivel al transparentei distribuite. Utilizatorul trebuie sa specifice şi numele fragmentelor şi localizarea datelor.

7.5.2. Transparenţa tranzacţiilor

Acest tip de transparenţa asigură faptul că toate tranzacţiile distribuite păstrează integritatea şi consistenţa BDD.

O tranzacţie distribuită accesează date stocate la mai mult de o locaţie în reţea. Fiecare tranzacţie e divizata în sub-tranzacţii, câte una pentru fiecare site accesat. Sub-tranzacţiile se execută în paralel pe site-uri şi în mod concurent pe fiecare site. SGBDD are sarcini deosebite în legătură cu gestionarea tranzacţiilor distribuite dar acestea nu vor fi tratate in acest capitol.

În cadrul transparenţei tranzacţiilor se tratează în mod deosebit transparenţa concurenţei şi transparenţa erorilor.

134

SGBDD oferă transparenţă concurenţei dacă rezultatele tuturor tranzacţiilor concurente (distribuite sau nu) sunt executate independent şi sunt logic echivalente cu rezultatele obtinuţe în cazul în care tranzacţiile sunt executate pe rând, într-o ordine serială arbitrară.

Transparenţa erorilor necesită şi un mecanism de recovery care ne să asigure că tranzacţiile se comportă atomic în faţa erorilor: ori sunt executate toate operaţiile unei tranzacţii ori nici o operaţie nu este executată. Odată ce o tranzacţie s-a executat, transformările operate de ea asupra bazei de date sunt durabile (permanente).

7.5.3. Transparenţa performanţelor

Transparenţa performanţelor se asigură prin cerinţa ca sistemul considerat să aibă performanţe comparabile cu ale unui sistem centralizat. În această situaţie trebuie ca SGBDD să determine strategia cea mai eficientă de a executa fiecare interogare în parte. În acest scop un DQP (Distributed Query Processor) mapeaza o cerere de date într-o secvenţă ordonată de operatii asupra bazei de date. DQP decide ce fragment se accesează, ce copie se utilizează, care locaţie se utilizează. DQP produce o strategie de execuţie care este optimizată relativ la o funcţie de cost. Costul asociat cu o interogare distribuita include:

- timp de acces (input/output) la accesarea datelor fizice pe suportul respectiv,

- timp CPU la executatrea operatiilor asupra datelor in memoria principala,

- costuri de comunicatii asociate cu transmiterea datelor prin retea.

Întrebări recapitulative.

1) Ce este o bază de date distribuită?

2) Care sunt avantajele unui sistem distribuit?

3) Care este arhitectura unui sistem distribuit?

4) Ce diferenţe apar la proiectarea bazelor de date distribuite?

5) Cum se poate face proiectarea alocării datelor?

6) Cum se face o fragmentare corectă?

7) Ce este fragmentarea?

8) Ce tipuri de transparenţă trebuie să realizeze un sistem distribuit?

9) Ce este transparenţa distribuirii?

10) Ce este transparenţa tranzacţiilor?

11) Ce este transparenţa performanţelor?

Răspunsuri la întrebări.

1) Un SGBDD constă dintr-o singură bază de date care este descompusă în fragmente, eventual unele fragmente sunt

135

multiplicate, şi fiecare fragment sau copie se pastrează pe unul sau mai multe site-uri, sub controlul unui SGBD local. Fiecare site este capabil sa proceseze interogări utilizator în regim local, independent de restul reţelei, sau este capabil să participe la procesarea unor date situate în alte site-uri din reţea. Pentru a spune că un SGBD este distribuit trebuie să existe cle puţin o cerere globală.

2) Avantajele distribuirii bazelor de date sunt:

- sistemul distribuit se modelează cel mai bine pe structura organizaţională a multor organizaţii, avand în vedere ca multe companii sunt localizate "distribuit" din punct de vedere geografic

- datele sunt partajabile dar administrarea lor se bucură de un grad înalt de autonomie locală

- disponibilitatea bazei de date este evident mai bună decât în cazul centralizat. Dacă se semnalează unele erori sau "ăderi" de sistem la nivel local sistemul ]n întregime poate să continue să funcţioneze în condiţii satisfăcătoare

- fiabilitatea sistemului este îmbunătăţită. Se pot reface rapid fişiere distruse utilizând replici aflate pe alte site-uri

- performanţele în prelucrarea datelor se îmbunătăţesc prin posibilitatea prelucr[rii în paralel a unor interog[ri

- un sistem distribuit oferă avanatje economice dacă luăm în considerare costurile implementării şi întreţinerii unei reţele faţă de costurile corespunzătoare ale unui sistem centralizat de putere comparabilă de prelucrare. Costuri scazute se mai obtin daca se realizeaza prelucrări locale cât mai multe (în cază sistemul şi aplicaţiile permit acest lucru). De asemenea este mult mai convenabil să se "ajusteze" o reţea de calculatoare la nevoile organiza’iei (dacă de exemplu este necesară adăugarea unor site-uri în plus) decât un calculator central de putere asemănătoare

- capacitatea de gestionare modulară a sistemului permite extensii ale acestuia sau rezolvarea unor "căderi" parţiale fără să se afecteze prea tare (uneori fără a se afecta deloc) mersul activităţilor pe ansamblul sistemului distribuit.

3)

136

Schema externa globala

Schema externa globala

Schema conceptuala

globala

Arhitectura ANSI-SPARC pe trei nivele

In cadrul unui SGBDD putem identifica urmatoarele componente:

- o componentă locală SGBD (LSGBD)

- o componentă de comunicaţii de date (CD)

- un dicţionar de date global (DDG). Acest dicţionar are aceeaşi funcţionalitate ca şi und dicţionar de date în cazul SGBD centralizat dar conţine informaţii suplimentare referitoare la fragmentare şi la alocarea datelor. Şi DDG poate fi fragmentat şi replicat ca orice altă informaţie din baza de date distribuită

- componente de SGBD distribuit (SGBDD).

4) Proiectarea corectă a unei baze de date relaţionale distribuite necesită, pe lângă cerinţele cunoscute pentru sistemele centralizate, şi realizarea

137

Schema de fragmentare

Schema de alocare

Schema locala de mapare

Schema conceptuala

locala

Schema interna locala

următoarelor:

- fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi stocate pe diferite site-uri în reţea

- replicarea – se pot realiza copii ale diferitelor relaţii sau ale fragmentelor

- alocarea fragmentelor şi a replicilor pe diferite site-uri

5) Se cunosc patru strategii de alocare a datelor într-o baza de date relaţională distribuită:

a!. centralizat

Baza de date se află în întregime pe un singur site din reţea şi este gestionată de un singur DBMS. Spunem în acest caz că baza de date este procesată distribuit, ea de fapt nu mai este o bază de date distribuită in adevaratul sens al cuvântului. Dezavantajele sunt mai ales costurile mari de comunicaţii şi o fiabilitate şi o disponibilitate foarte scăzute, având în vedere că orice eroare care blochează accesul la baza de date, practic paralizează întreaga activitate în reţea pe această direcţie.

a2. fragmentat (partiţionat)

Baza de date este partiţionată în mai multe fragmente disjuncte care sunt stocate pe diverse site-uri. Comentarii:

- aceasta parţitionare a datelor poate îmbunătăti frecvenţa referinţelor locale

- dacă nu există replici ale fragmentelor, costurile de stocare sunt reduse

- fiabilitatea şi disponibilitatea sunt scăzute dar nu aşa de mici ca în cazul centralizat

- dacă datele sunt distribuite corect, costurile de comunicare pot fi relativ scăzute

a3. replicat complet

Pe fiecare site se găseste o copie completă a bazei de date. Comentarii:

- eficienţa referirilor locale, fiabilitatea şi disponibilitatea sunt maxime

- costurile de stocare sunt în schimb şi ele foarte mari, la fel sunt şi costurile de actualizare

a4. replicat selectiv

Aceasta strategie este o combinaţie intre partiţionare, replicare şi centralizare cu scopul de a se cumula, pe cat posibil, avantajele fiecărei strategii şi să se elimine dezavantajele.

6) Reguli de bază care duc la o fragmentare corectă a bazei de date:

- completitudine – dacă relaţia R este descompusă în fragmentele R1, R2, …,Rn, trebuie luate măsuri care să prevină pierderea de informaţii

138

- reconstrucţie – să fie posibil în orice moment să se refacă relaţia R de la care s-a pornit cu fragmentarea. Aceasta regulă conservă dependenţele funcţionale.

- disjuncţie – dacă data di apare în fragmentul Ri atunci nu este permis să apară în nici un alt fragment. De la această regulă se admite doar o excepţie, cazul când o relaţie este fragmentată pe verticală.

7) Tipurile de fragmentare sunt:

- pe orizontală

- pe verticală

- combinată

Fragmentarea pe orizontală:

Ne putem imagina că o tabelă se fragmentează orizontal ca mai jos:

Un fragment al unei relaţii partitionate pe orizontală constă dintr-o submulţime a tuplelor relaţiei respective.

Un fragment orizontal se produce prin selecţie:

Fiecare tuplu din relatia R apare într-un anume fragment, o singură dată. Dacă se doreşte reconstrucţia relaţiei, se utilizează reuniunea pentru a obţine relaţia R iniţiala.

R= R1R2…Rn

In general fragmentele unei relaţii R sunt disjuncte.

Fragmentarea pe verticală

Un fragment vertical dintr-o relaţie constă dintr-o relaţie care are ca atribute o submulţime a atributelor relaţiei iniţiale.

Un fragment vertical se produce prin proiecţie:

Dacă S1R şi S2R atunci şi .

Completitudinea este asigurată prin faptul că fiecare atribut apare cel puţin într- una din submulţimile S1 şi S2.

Reconstrucţia relaţiei iniţilale se realizează prin joncţiune naturală.

139

Aşadar la descompunerea relaţiei iniţiale în fragmente trebuie să se ţină seama de regulile care asigură o descompunere fără pierderi la joncţiune.

In cazul descompunerii pe verticală nu este posibil să se realizeze o disjuncţie totală. Se admite existenţa unor atribute comune, şi anume a atributelor care formează cheile primare (respectiv cheile externe).

Fragmentarea combinată (mixtă, hibridă, compusă)

Se poate face din fragmente verticale fragmentate orizontal:

Expresia corespunzatoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai sus) este:

Sau se poate face din fragmente orizontale fragmentate vertical

Expresia corespunzătoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai sus) este: .

8) Tipuri de transparenţă:

- transparenţa distribuirii

- transparenţa tranzacţiilor

- transparenţa performanţelor.

9) Transparenţa distribuirii se poate explica astfel:

Dacă se realizează transparenţa distribuirii, utilizatorul percepe baza de date ca pe o entitate unitară din punct de veder logic.

Acest tip de transparenţă se poate descompune în două aspecte: utilizatorul nu trebuie să cunoască faptul că există fragmentarea datelor (transparenţa fragmentării) sau utilizatorul nu ştie de localizarea datelor pe reţea (transparenţa localizării).

Transparenţa fragmentării este cel mai înalt grad de transparenţa. Utilizatorul se adresează cu interogări bazei de date ca şi când ar fi localizată centralizat, deci nu trebuie să se preocupe de existenţa fragmentelor.

Transparenţa fragmentării este strâns legată de acordarea numelor (identificatorilor) în cadrul bazei de date distribuite. Şi într-o bază de date

140

distribuită (ca şi în cazul centralizat) numele diferitelor "obiecte" trebuie să fie unic. Două site-uri nu pot conţine obiecte cu nume identice.

10) Transparenţa tranzacţiilor asigură faptul că toate tranzacţiile distribuite păstrează integritatea şi consistenţa BDD.

O tranzacţie distribuită accesează date stocate la mai mult de o locaţie în reţea. Fiecare tranzacţie e divizata în sub-tranzacţii, câte una pentru fiecare site accesat. Sub-tranzacţiile se execută în paralel pe site-uri şi în mod concurent pe fiecare site. În cadrul transparenţei tranzacţiilor se tratează în mod deosebit transparenţa concurenţei şi transparenţa erorilor.

SGBDD oferă transparenţă concurenţei dacă rezultatele tuturor tranzacţiilor concurente (distribuite sau nu) sunt executate independent şi sunt logic echivalente cu rezultatele obtinuţe în cazul în care tranzacţiile sunt executate pe rând, într-o ordine serială arbitrară.

Transparenţa erorilor înseamnă existenţa unui mecanism de recovery care ne să asigure că tranzacţiile se comportă atomic în faţa erorilor: ori sunt executate toate operaţiile unei tranzacţii ori nici o operaţie nu este executată. Odată ce o tranzacţie s-a executat, transformările operate de ea asupra bazei de date sunt durabile .

11) Transparenţa performanţelor se asigură prin cerinţa ca sistemul considerat să aibă performanţe comparabile cu ale unui sistem centralizat. În această situaţie trebuie ca SGBDD să determine strategia cea mai eficientă de a executa fiecare interogare în parte. În acest scop un DQP (Distributed Query Processor) mapează o cerere de date într-o secvenţă ordonată de operaţii asupra bazei de date. DQP decide ce fragment se accesează, ce copie se utilizează, care locaţie se utilizează. DQP produce o strategie de execuţie care este optimizată relativ la o funcţie de cost.

Capitolul 8Securitate şi integritate

8.1. Integritate

Integritatea bazelor de date se refera la corectitudinea informaţiilor şi presupune detectarea, corectarea şi prevenirea diferitelor erori care pot afecta datele introduse în bazele de date. Cand facem referiri la integritatea datelor, întelegem că datele sunt consistente relativ la toate restrictiile formulate

141

anterior (care se aplica datelor respective) şi ca urmare a acestui fapt, datele sunt considerate valide.

Conditiile de integritate numite şi reguli sau restrictii de integritate nu permit introducerea in baza de date a unor date aberante şi sunt exprimate prin conditii puse asupra datelor.

In general sunt acceptate mai multe criterii de clasificare a regulilor de integritate.

O serie de conditii sunt de tip structural, legate de anumite egalitati intre valori, şi exprimate prin dependente functionale sau prin declararea unor campuri cu valori unice (de cele mai multe ori aceste campuri sunt chei).

O alta serie de conditii se clasifica dupa unitatea la care se aplica restrictia si, in acest caz, exista restrictii pe domenii (ce privesc anumite valori pentru atribute) sau restrictii pe tabele (relatii). Restrictiile pe tabele pot fi unituplu (se refera la fiecare tuplu in parte) sau multituplu (se refera la combinatii de mai multe tupluri).

O restrictie de integritate de relatie unituplu impune ca in fiecare tuplu al unei relatii de baza, in campurile corespunzatoare cheii primare, sa apara valori diferite de valorile nule corespunzatoare. Aceasta regula se mai poate enunta şi sub forma: "intr-o baza de date relaţionala nu se inregistreaza nici o informatie despre ceva ce nu poate fi identificat."

Un exemplu de restrictie de integritate de relatie de tip multituplu este restrictia referentiala care se exprima prin conditia ca, pentru cheile externe, daca nu sunt nule, sa se admita valori corespunzatoare uneia din cheile primare existente in relatia referita. Verificarea acestei conditii are loc de cate ori se insereaza un nou tuplu ce contine o cheie externa sau se modifica valoarea unei chei externe a unui tuplu, semnalandu-se eventualele neconcordante şi anuland modificarile. Verificarea unicitatii cheii primare şi restrictiile rezultate din dependentele functionale şi multivaloare sunt alte exemple de acelasi tip.

Un alt criteriu de clasificare este acela prin care se deosebesc regulile de integritate ce se refera la diferitele stari ale bazei de date de regulile ce se refera la tranzitia dintr-o stare in alta.

Restrictiile pot fi clasificate şi din punct de vedere al momentului in care se aplica ele, astfel avem reguli imediate (ce se verifica in momentul in care se efectueaza operatia indicata) sau reguli amanate (ce se verifica numai dupa ce au fost executate şi alte operatii asociate dar inainte de a se modifica baza de date).

In functie de aria de aplicare, restrictiile pot fi impartite in restrictii generale, aplicabile tuturor relatiilor din baza de date şi restrictii particulare, care se pot aplica numai la anumite relatii.

Regulile de integritate se aplica relatiilor de baza in care sunt reprezentate efectiv datele bazei de date. Dintre regulile generale cel mai des folosite in

142

modelul relaţional sunt regulile ce privesc cheile primare (vezi unicitatea valorilor cheilor primare in cadrul relatiei) şi cheile externe.

Analizam in continuare cateva tipuri de restrictii de integritate.

I. Restrictii pentru integritatea entitatii

Enunt: Intr-o relatie de baza nici un atribut al unei chei primare nu poate avea valori nule.

Deja cunoastem ca se cere (in multe situatii) ca valorile cheilor primare sa fie unice. In majoritatea SGBD unicitatea cheii primare şi integritatea entitatii sunt conditii obligatorii.

II. Restrictii pentru integritatea referentiala

Enunt: Daca exista o cheie externa intr-o relatie, ori valoarea cheii externe trebuie sa se potriveasca cu valoarea unei chei candidat a vreunui tuplu in relatia de origine, ori valoarea cheii externe trebuie sa fie nula.

Cu late cuvinte, daca o valoare exista intr-o relatie pe post de cheie externa, ori ea trebuie sa se potriveasca cu valoarea unei chei primare dintr-o alta relatie ori sa fie nula.

Probleme serioase apar in momentul cand sunt de efectuat modificari sau stergeri de valori ale cheilor primare.

Daca se actualizeaza o cheie primara sau se sterge intregul tuplu şi daca

1) valoarea cheii primare nu apare nicaieri ca şi cheie externa

atunci se permite efectuarea operatiei

2) valoarea cheii primare apare in alta parte ca şi cheie externa

atunci

a) nu se permite efectuarea operatiei

b) se permite efectuarea operatiei dar de asemenea se seteaza aparitiile cheii externe la valorile nule sau o valoare implicita (daca s-a specificat vreuna)

c) se permite efectuarea operatiei dar de asemenea

(i) in cazul actualizarii – se propaga valoarea schimbata la aparitiile cheii externe unde cheia externa este o parte a cheii primare a relatiei si, de asemenea, se propaga schimbarile acolo unde aceasta din urma cheie primara este cheie externa intr-o alta relatie

(ii) in cazul stergerilor – se propaga stergerea , adica se sterg tuplele care au valori ale cheii externe care se potrivesc cu cheia primara

d) se intra in dialog cu utilizatorul

143

Toate acestea sunt reguli generale care, dupa caz, pot suferi mici transformari, in functie de aplicaţia concreta.

Situatiile descrise mai sus pot fi rezolvate in cadrul aplicaţiei sau se pot include in SGBD utilizand mecanismul trigger-elor. Mai multe SGBD permit sa se creeze şi sa se memoreze proceduri referitoare la baza de date şi aceste proceduri pot fi invocate cand au loc anumite evenimente, cum ar fi actualizari şi stergeri ale unor atribute.

Standardul SQL furnizeaza controale pentru integritatea referentiala in declaratiile de creare a tabelelor.

III. Restrictiile de domeniu

Aceste restrictii sunt intotdeauna restrictii de stare imediate. Aceste restrictii se pot referi la tipul de date pentru un atribut, la o lista de valori posibile, la un ordin de marime, la un format sau o forma, la o conditie exprimata cu o formula logica sau la o procedura care este apelata de cate ori are loc o modificare pentru domeniul specificat.

Exemplu: Restrictiile de domeniu referitoare la o data calendaristica pot fi exprimate (eventual) in felul urmator:

create domain ZI char(2)check is_integer(ZI) and num(ZI) >= 1 and num(ZI) <= 31;

create domain LUNA char(2)check is_integer(LUNA) and num(LUNA) >= 1 and

num(LUNA) <= 12;create domain AN char(2)

check is_integer(AN) and num(AN) >= 0 and num(AN) <= 99;create domain DATA(ZZ domain(ZI), LL domain(LUNA), AA

domain(AN))check if num(LL) in (1,3,5,7,8,10,12) then num(ZZ) < 31;check if num(LL) in (4,6,9,11) then num(ZZ) < 30;check if num(LL) = 2 and mod(num(AA),4) = 0 and

mod(num(AA),100) <> 0 then num(ZZ) < 29;check if num(LL) = 2 and mod(num(AA),4) <> 0

then num(ZZ) < 28;

Restrictiile de integritate pot fi exprimate prin intermediul limbajului de prelucrare a datelor sub forma unei egalitati sau ca o relatie intre rezultatele a doua cereri.

Integritatea datelor este strans corelata cu securitatea datelor unei baze de date.

Daca se definesc controalele de securitate in absenta celor de integritate, validitatea şi consistenta datelor se bazeaza exclusiv pe utilizarea corecta şi de buna credinta a sistemului de catre utilizatorii autorizati. Daca insa se definesc numai controale de integritate, datele au sansa sa fie consistente dar sunt susceptibile la pericolele care provin din lipsa securitatii.

144

Este important de mentionat aici ca restrictiile de integritate nu garanteaza corectitudinea datelor. Aceasta deoarece este aproape imposibil (in multe situatii) ca verificarea corectitudinii sa fie realizata automat.

Exemplu: Nu se poate verifica automat daca numele unei persoane este "Pop" sau "Popa", cum nu se poate verifica automat daca data nasterii este "10.01.2001" sau "01.01.2001", etc.

Pentru a asigura un grad multumitor de integritate a datelor trebuie prevazute restrictii de integritate in asociere cu principalele momente in care datele respective sunt manipulate, cum ar fi: introducerea, actualizarea şi stergerea. Acestea sunt operatii susceptibile de introducerea de date inconsistente in baza de date.

Restrictiile de integritate pot fi memorate in multe cazuri chiar in SGBD, dar gradul in care acest lucru este posibil depinde de SGBD.

Asociata cu integritatea datelor este şi protectia datelor impotriva unor evenimente de avarie cum ar fi caderea sistemului cauzata de defectarea unor componente hardware sau software.

Pierderea accidentala de consistenta a datelor poate rezulta din:

-incidente ce apar pe parcursul executarii tranzactiilor,

-anomalii datorate accesului concurent la baza de date,

-anomalii datorate lucrului cu date distribuite pe mai multe calculatoare intr-o retea,

-erori logice care apar din programele utilizator,

si altele.

Pentru reconstituirea bazelor de date in cazul cand pot sa apara inconsistente in general, majoritatea bazelor de date se copiaza periodic pe medii magnetice ce se pastreaza in locuri sigure. De asemenea se tine o evidenta a tuturor transformarilor efectuate in baza de date de cand s-a efectuat ultima copie. Fisierul care contine aceste modificari se numeste jurnal. Fiecare inregistrare din jurnal contine un identificator al programului care a facut modificarea, fosta valoare şi noua valoare introdusa pentru un element. Tot in jurnal se mai pastreaza diferitele momente importante din desfasurarea programelor (inceput, sfarsit, terminarea unor operatii, etc.). Toate mecanismele mentionate in acest paragraf sunt caracteristice lucrului cu tranzactii. La terminarea unei tranzactii, indiferent daca ea s-a incheiat normal sau prin eroare, baza de date trebuie sa aiba acelasi grad de integritate ca la momentul inceperii executiei tranzactiei respective.

Se spune despre o tranzactie ca este comisa daca au fost terminate toate calculele produse de ea in aria de lucru şi s-a facut o copie a rezultatelor ei in jurnal. Aparitia unor caderi dupa ce o tranzactie a fost comisa nu afecteaza continutul bazei de date deoarece se poate reconstitui baza de date cu ajutorul ultimei copii şi a jurnalului in care se gasesc toate rezultatele tranzactiilor

145

comise. Modificarile tranzactiilor abandonate sau necomise nu sunt luate in considerare la parcurgerea jurnalului pentru restaurarea bazei de date.

Se defineste strategia de comitere in doua faze astfel: o tranzactie poate sa scrie intr-o baza de date numai dupa ce a fost comisa şi o tranzactie poate fi comisa numai dupa ce a inregistrat in jurnal toate schimbarile de elemente produse de ea.

8.2. Securitate

Prin securitatea bazelor de date se intelege protejarea bazelor de date impotriva folosirii neautorizate a lor şi in special a modificarilor şi distrugerilor nedorite de date şi a citirilor nepermise de date. Pentru realizarea securitatii datelor din baza de date se utilizeaza controale tehnice şi administrative.

Securitatea este in general asociata cu urmatoarele situatii:

-acces fraudulos la date,

-pierderea confidentialitatii (secretului) datelor,

-pierderea caracterului privat al datelor,

-pierderea integritatii datelor,

-pierderea disponibilitatii datelor

Este mai dificila protejarea datelor impotriva accesului rauvoitor, intentionat. Se recunoaste ca de fapt nu exista protectie absolut sigura ci doar protectii şi masuri de securitate mai eficiente sau mai putin eficiente.

Forme de acces intentionat şi rauvoitor la datele unei baze de date:

-citire neautorizata a unor date,

-modificari neutorizate de date,

-distrugeri de date.

Notiunea de securitate a bazei de date este de obicei asociata cu accesul rauvoitor, pe cand integritatea se refera la evitarea pierdelor accidentale de consistenta. Adevarul este insa undeva la mijloc.

Pentru protectia bazei de date se pot lua masuri de asigurare a securitatii la mai multe nivele:

-la nivel fizic - locurile in care se afla calculatoarele trebuie protejate de accesul persoanelor neautorizate;

-la nivel uman – este recomandabil sa se acorde autorizatiile de acces cu multa grija şi sa se tina evidente stricte ale persoanelor autorizate

-la nivel sistem de operare – slabiciunile protectiei la nivel de sistem de operare trebuie eliminate sau compensate de alte masuri

146

-la nivel SGBD – sistemul ofera anumite facilitati care sprijina protectia datelor

Tehnici de asigurare a securitatii datelor:

1. Identificarea utilizatorilor.

Fiecarui utilizator in parte i se acorda anumite drepturi de operare pe diferite portiuni din baza de date la diferite nivele cum ar fi relatia, inregistrarea, pagina, atributul, etc. Drepturile se refera la posibilitatea citirii, inserarii, stergerii sau modificarii datelor respective. Identificarea se face de obicei prin parole stabilite fie de administratorul bazei de date fie de utilizator.

2. Protejarea datelor prin codificare (criptare).

Deoarece s-ar putea ajunge la date şi prin alte mijloace decat prin intermediul SGBD-ului (de exemplu prin citirea directa a mediului magnetic) se poate face o protectie prin pastrarea codificata a datelor pe mediul magnetic. Decodificarea datelor se poate face numai dupa identificarea utilizatorului prin garzi asociate lui.

3. Utilizarea view-urilor in aplicaţii.

Abilitatea view-urilor de a "ascunde" o parte din informatiile din baza de date poate fi utilizata şi pentru stabilirea unui anumit grad de securitate a datelor. Astfel se poate vorbi de acces la nivel de relatie (tabela) sau acces la nivel de view.

In unele sisteme nu sunt acceptate modificari prin intermediul view-urilor. Astfel de view-uri se numesc read-only (numai pentru citire) şi sunt utilizate mai ales in aplicaţiile in care datele pot fi citite de toti utilizatorii (baze de date publice) dar modificarile se fac numai cu aprobarea administratorului/proprietarului bazei de date.

Modificarile din view-uri nu sunt in general admise deoarece pot duce la efecte laterale ce privesc parti din baza de date ce nu apar in view-uri. De exemplu stergerea unui element din view poate sa duca la eliminarea unui alt element care are singura legatura cu elemntul sters şi care nu se afla in view.

4. Administrarea şi transmiterea drepturilor.

Se tine evidenta stricta a drepturilor de acces ale fiecarui utilizator la portiuni din baza de date şi se fixeaza reguli de transmitere de la un utilizator la altul a dreptului de acces.

Forme de autorizare:

-autorizare la citire (consultare)

-autorizare la inserare (adaugare)

-autorizare la actualizare (care exclude stergerile)

-autorizare la stergeri (la nivel de tuplu)

147

In situatiile de mai sus nu se pune problema modificarilor la nivel de schema a bazei de date.

Daca consideram şi acest aspect putem vorbi de:

-autorizare la nivel de index (creare-stergere de indexi)

-autorizare la nivel de relatii (creare)

-autorizare de modificari la nivel de relatii (stergeri sau adaugari de atribute in cadrul relatiilor)

-autorizari de stergeri ale relatiilor

Diferitele protectii pot fi indicate prin intermediul limbajului de prelucrare a datelor. Portiunile din baza de date ce pot fi folosite de utilizator pot fi definite prin operatii de selectie şi proiectie care fac invizibile alte portiuni ale bazei de date.

Conducerea organizatiei, care este proprietara bazei de date, trebuie sa ia masuri de securitate care reduc riscul de a se pierde informatii sau de a se distruge informatii. Prin pierdere de informatii se poate intelege ca se pierde caracterul privat al informatiilor, ele devin accesibile unui grup mai mare de persoane decat cel prevazut. Nu intotdeauna "scurgerile" de informatii lasa urme, deci nu se materializeaza intotdeauna in schimbari detectabile la nivelul bazei de date.

Problema securitatii cuprinde aspecte legale, sociale şi etice, aspecte privind controlul fizic (paza şi posibilitati de blocarea accesului la terminale), aspecte de politie (fixarea conditiilor de acces), aspecte operationale (modul de stabilire a parolelor), aspecte privind controlul hard (modul de acces hard la diferite componente), securitatea sistemului de operare (protejarea informatiilor şi anularea rezultatelor intermediare pentru pastrarea secretului datelor) aspecte privind notiunea de proprietate asupra datelor din baza de date şi altele asemanatoare.

Trebuie sa mentionam aici ca furturile şi fraudele nu sunt neaparat legate de baza de date, ele sunt un factor de risc pentru intreaga organizatie, gravitatea acestor fapte depinzand şi de profilul organizatiei in cauza.

In Comunitatea Europeana exista o preocupare serioasa legata de actualizarea legislatiei la noile nevoi generate de utilizarea intensiva a calculatoarelor. Se incearca in principal sa se adopte legi care sa protejeze persoana sau organizatia şi sa tina seama de nevoia ca anumite informatii sa aiba caracter privat, deci sa nu fie accesibile publicului larg sau nici macar unui grup relativ restrans, daca acest fapt ar dauna proprietarului informatiilor respective. Putem enumera aici o paleta larga de domenii care lucreaza cu informatii al caror caracter privat trebuie neaparat pastrat: domeniul bancar, domeniul medical, evidente administrativ-financiare, domeniul productiei in majoritatea firmelor de marca, etc.

148

Inrebari recapitulative.

1) Care sunt restricţiile de integritate?

2) Ce înseamnă integritatea entitatii?

3) Ce înseamnă integritatea referentiala?

4) Ce înseamnă restrictiile de domeniu?

5) Care este deosebirea între integritate şi securitate?

6) Cum poate fi încălcată securitatea datelor într-o baza de date ?

7) Enumeraţi măsuri de protecţie pentru asigurerea securităţii datelor.

8) Enumeraţi forme de autorizare.

Răspunsuri la întrebări.

1) Restricţiile de integritate

- integritatea entitatii

- integritatea referentiala

- restrictiile de domeniu

- restricţiile de intreprindere

2) Intr-o relaţie de baza nici un atribut al unei chei primare nu poate avea valori nule.

3) Daca exista o cheie externa intr-o relaţie, ori valoarea cheii externe trebuie să se potriveasca cu valoarea unei chei candidat a vreunui tuplu în relaţia de origine, ori valoarea cheii externe trebuie să fie nulă.

4) Aceste restricţii se pot referi la tipul de date pentru un atribut, la o listă de valori posibile, la un ordin de mărime, la un format sau o formă, la o condiţie exprimată cu o formulă logică sau la o procedură care este apelată de cate ori are loc o modificare pentru domeniul specificat.

5) Noţiunea de securitate a bazei de date este de obicei asociată cu accesul răuvoitor, pe cand integritatea se refera la evitarea pierdelor accidentale de consistenţă

6) Securitatea este in general asociată cu urmatoarele situaţii:

-acces fraudulos la date,

-pierderea confidenţialitatii (secretului) datelor,

-pierderea caracterului privat al datelor,

-pierderea disponibiliţatii datelor.

7) Pentru protectia bazei de date se pot lua masuri de asigurare a securităţii la mai multe nivele:

-la nivel fizic - locurile în care se afla calculatoarele trebuie protejate de accesul persoanelor neautorizate;

149

-la nivel uman – este recomandabil sa se acorde autorizaţiile de acces cu multa grijă şi să se ţină evidenţe stricte ale persoanelor autorizate

-la nivel sistem de operare – slăbiciunile protecţiei la nivel de sistem de operare trebuie eliminate sau compensate de alte măsuri

-la nivel SGBD – sistemul ofera anumite facilităţi care sprijina protecţia datelor.

8) Forme de autorizare:

-autorizare la citire (consultare)

-autorizare la inserare (adăugare)

-autorizare la actualizare (care exclude ştergerile)

-autorizare la ştergeri (la nivel de tuplu)

In situaţiile de mai sus nu se pune problema modificarilor la nivel de schemă a bazei de date.

Dacă considerăm şi acest aspect putem vorbi de:

-autorizare la nivel de index (creare-ştergere de indecşi)

-autorizare la nivel de relaţii (creare)

-autorizare de modificări la nivel de relaţii (ştergeri sau adăugari de atribute în cadrul relaţiilor)

-autorizări de ştergeri ale relaţiilor.

Capitolul 9 Tranzacţii şi concurenţă.

În acest capitol vom învaţa:- Ce este o tranzacţie- Care sînt proprietăţile tranzacţiilor- De ce este necesar controlul concurenţei- Ce urmăreşte controlul concurenţei- Ce este blocajul şi cum poate el asigura serializabilitatea- Cum funcţionează blocajul în două faze- Ce este blocajul ciclic- Cum se foloseşte ‘time stamp’-ul pentru a asigura

serializabilitatea- Ce sînt tehnicile de control optimist al tranzacţiei9.1. Tranzacţii.

Tranzacţia este o acţiune sau o serie de acţiuni, executate de un singur utilizator sau un program, care accesează sau schimbă conţinutul bazei de date.

Tranzacţia este o unitate logică de lucru a bazei de date. Nu există reguli de stabilire automată a acestei unităţi. Pentru a demonstra acest concept

150

o să dăm următoarele exemple. Fie schemele:Personal = (nrmat, nume, adresă, salariu)Proprietate = (nrprop, stradă, oraş, tip, nrmat)

care leagă proprietatea de o persoană prin nrmat printr-o relaţie de cardinalitate n la 1, Putem avea următoarele tranzacţii:

cit (nrmat = x, salariu)salariu = salariu * 1,1scrie (nrmat = x, salariu)

care măreşte salariul cu 10%

cit (nrmat =x )şterge (nrmat = x )pentru toate înregistrările din Proprietate begin

cit ( nrprop, nrmat)dacă (nrmat = x ) atunci

şterge (nrprop)end

care şterge persoana x şi toate proprietăţile ei.

O tranzacţie trebuie să transforme întotdeauna baza de date dintr-o stare consistentă într-o altă stare tot consistentă.

O tranzacţie se poate termina în două moduri. Dacă tranzacţia s-a terminat cu succes, atunci spunem că tranzacţia a făcut ‘commit’ şi baza de date a trecut în noua stare consistentă. Dacă tranzacţia nu s-a terminat cu succes atunci, ea este întreruptă şi, în acest caz , baza de date trebuie să fie readusă în starea consistentă în care era înainte să înceapă tranzacţia. Spunem, în acest caz, că tranzacţia face ‘roll back’ este derulată înapoi. O tranzacţie care a făcut ‘commit’ nu mai poate fi întreruptă, dar o tranzacţie întreruptă poate fi reluată mai târziu şi atunci s-ar putea să se termine cu succes.

Un SGBD trebuie să aibă posibilitatea de a defini şi mânui tranzacţii.Găsim astfel cuvintele cheie cu semnificaţie imediată BEGIN TRANSACTION, COMMIT, ROLLBACK.

151

9.2. Proprietăţile tranzacţiilor.Deşi nu avem reguli automate pentru construcţia tranzacţiilor ele trebuie să

respecte proprietăţile ACID. Atomicitate este proprietatea ‘totul sau nimic’. O tranzacţie este o unitate

indivizibilă care se execută în întregime sau deloc. Consistenţă o tranzacţie trebuie să transforme baza de date dintr-o formă

consistentă într-o altă formă tot consistentă. Independenţă o tranzacţie se execută inependent de oricare alta, adică

efectele parţiale ale unei tranzacţii incomplete nu trebuie să influenţeze o altă tranzacţie.

Durabilitate efectele unei tranzacţii terminată cu succes sunt definitiv înregistrate în baza de date şi nu se mai pot pierde în tranzacţiile întrerupte ulterior.

9.3. Controlul concurenţei.Dacă fiecare tranzacţie lucrează pe rînd, se pierde timp când calculatorul

stă să aştepte terminarea unei operaţii de intrare/ieşire, sau în timpul altei întreruperi. Pe de altă parte, dacă lăsăm să lucreze deodată, fiecare în timpul lăsat liber de cel din nainte, zicem că avem tranzacţii concurente. Concurenţa va mări randamentul timpului de lucru al calculatorului dar ea trebuie controlată pentru că altfel poate da naştere la inconsistenţă.

Prezentăm în continuare, trei exemple în care arătăm cum se poate pierde cinsistenţa.

În primul exemplu tranzacţia T1 citeşte contul lui x (balx) şi scade 10 din cont.Tranzacţia T2 citeşte contul lui x (balx) şi adună 100 la cont. Pornind cu un cont de 100, evident că dacă se executa mai întâi prima tranzacţie şi apoi a doua contul lui x ar fi fost 100-10+100=190. În cealaltă ordine am fi avut 100+100-10=190 aceeaşi valoare. Să considerăm următorul plan de tranzacţii. Un plan de tranzacţii este o secvenţă posibilă în timp a modului de execuţie a tranzacţiilor. Putem observa, în timpii înscrişi în stânga, cum evoluează contul din ultima coloană.

Time T1 T2 balx

A t1 begin_transaction 100A t2 begin_transaction cit(balx) 100A t3 cit(balx) balx = balx + 10 100A t4 balx = balx - 10 scrie(balx) 200A t5 scrie(balx) commit 90A t6 commit 90

Figura 9.1.

Problema se numeşte problema pierderii actualizării.Problema dependenţei de o tranzacţie neterminată apare când o

tranzacţie este lăsatăsă ‘vadă’ rezultatele intermediare alei alte tranzacţii înainte ca ea să facă ‘commit’. Aceleaşi tranzacţii ca în figura precedentă se desfăşoară acum după un alt plan.

Time T3 T4 balx

A t1 begin_transaction 100A t2 cit(balx) 100A t3 balx = balx + 10 100A t4 begin_transaction scrie(balx) 200A t5 cit(balx) 200A t6 balx = balx - 10 rollback 100A t7 scrie(balx) 190A t8 commit 190

Figura 9.2.

Rezultatul este 190, aţi putea spune că este bun, dar ţineţi cont că tranzacţia 4 a fost întreruptă şi, când se va relua, va mai mări cu 100 contul ceea ce va deveni incorect.

Chiar şi când unele tranzacţii numai citesc baza de date se pot întâmpla neplăceri. Această problemă este problema analizei inconsistente sau problema ‘citirii murdare’.

De exemplu tranzacţiile T5 şi T6 executate serial, adică una după alta, ar

trebui să dea rezultatele:

T5T6 balx=100-10=90, balz=25+10=35, sum=90+50+35+175sau T6T5 sum=100+50+25=175, balx=100-10=90, balz=25+10=35

şi putem vedea în figura următoare ce se poate întâmpla încazul concurenţei libere, necontrolate:

Time T5 T6 balx baly balz sum

A t1 begin_transaction 100 50 25A t2 begin_transaction sum = 0 100 50 25 0A t3 cit(balx) cit(balx) 100 50 25 0A t4 balx = balx -

10 sum = sum + balx

100 50 25 100

A t5 scrie(balx) cit(baly) 90 50 25 100A t6 cit(balz) sum = sum +

baly

90 50 25 150

A t7 balz = balz + 10

90 50 25 150

A t8 scrie(balz) 90 50 35 150A t9 commit cit(balz) 90 50 35 150A t10 sum = sum +

balz

90 50 35 185

A t11 commit 90 50 35 185

Figura 9.3.Nu putem, deci, lăsa concurenţa necontrolată, dar nici nu este profitabil să

o desfiinţăm de tot. Spunem că un plan de tranzacţii este serial cînd tranzacţiile se execută una după alta fără a intercala operaţii din altă tranzacţie. Spunem că un plan de tranzacţii este neserial când tranzacţiile sînt concurente , adică între

operaţiile unei tranzacţii se intercalează operaţiile alteia. Vom spune că un plan de tranzacţii este corect atunci când el are ca rezultat acelaşi cu unul executat serial; acesta se va numi serializabil. Aveţi deja exemple de planuri neserializabile.

Am văzut că problemele apar atunci când o tranzacţie ‘vede’ (citeşte) sau scrie într-un moment nepotrivit. Ideile de a controla concurenţa sînt legate de a nu lăsa pe celălalt (de a bloca) sau de a ţine cont de momente (de a marca timpul).

Ce înseamnă să blocăm ? Când o tranzacţie blochează partajat (part_bloc) o anumită unitate de memorie, o altă tranzacţir nu mai poate să rescrie tot acolo, iar când o tranzacţie blochează exclusiv (ex_bloc) o alta nu mai poate nici să o citească.

Despre ce unitate de memorie este vorba? Aceasta este problema granularităţii la care se face blocajul. Blocajul se poate face la nivel de:

- întreaga bază de date- tabela(fişier)- înregistrare (cel mai des)- câmp din înregistrareMai spunem că avem granularitate dinamică atunci când SGBD-ul poate

să schimbe granularitatea în timpul unei tranzacţii.Cititorul poate să demonstreze singur pe un exemplu (vezi problema ) că

numai simpla blocare urmată cândva de deblocare (debloc) nu asigură serializabilitatea.

Serializabilitatea este asigurată dacă se respectă protocolul de blocare în două faze. Acesta constă din împărţirea tranzacţiei în două faze una de blocări şi creşteri de blocaje şi a doua de descreşteri şi deblocaje. Aceasta înseamnă că după ce s-a făcut prima deblocare nu se mai pot face blocări.

Următoarele trei exemple reiau tranzacţiile T1 şiT2 din figura 9.1 respectiv T3 şi T4 din figura 9.2, şi T5 şi T6 din figura 9.3 cu protocolul în două faze şi realizează planuri serializabile.

Time T1 T2 balx

A t1 begin_transaction 100A t2 begin_transaction ex_bloc(balx) 100A t3 ex_bloc(balx) cit(balx) 100A t4 AŞTEAPTĂ balx = balx +100 100A t5 AŞTEAPTĂ scrie(balx) 200A t6 AŞTEAPTĂ debloc(balx) 200A t7 cit(balx) commit 200A t8 balx = balx -10 200A t9 scrie(balx) 190A t10 debloc(balx) 190A t11 commit 190

Figura 9.4.

Time T3 T4 balx

A t1 begin_transaction 100A t2 ex_bloc(balx) 100A t3 cit(balx) 100A t4 begin_transaction balx = balx +100 100A t5 ex_bloc(balx) scrie(balx) 200A t6 AŞTEAPTĂ debloc(balx) 100A t7 AŞTEAPTĂ rollback 100A t8 cit(balx) 100A t9 balx = balx -10 100A t10 scrie(balx) 90A t11 debloc(balx) 90A t12 commit 90

Figura 9.5.

Time T5 T6 balx baly balz sum

A t1 begin_transaction 100 50 25A t2 begin_transaction sum = 0 100 50 25 0A t3 ex_bloc(balx

) 100 50 25 0

A t4 cit(balx) part_bloc(balx) 100 50 25 0A t5 balx = balx -

10 AŞTEAPTĂ 100 50 25 0

A t6 scrie(balx) AŞTEAPTĂ 90 50 25 0A t7 ex_bloc(balz

) AŞTEAPTĂ 90 50 25 0

A t8 cit(balz) AŞTEAPTĂ 90 50 25 0A t9 balz = balz +

10 AŞTEAPTĂ 90 50 25 0

A t10 scrie(balz) AŞTEAPTĂ 90 50 35 0A t11 debloc(balx ,

balz) AŞTEAPTĂ 90 50 35 0

A t12 commit AŞTEAPTĂ 90 50 35 0A t13 cit(balx) 90 50 35 0A t14 sum = sum + balx 90 50 35 90A t15 part_bloc(baly) 90 50 35 90A t16 cit(baly) 90 50 35 90A t17 sum = sum + baly 90 50 35 140A t18 part_bloc(balz) 90 50 35 140A t19 cit(balz) 90 50 35 140A t20 sum = sum + balz 90 50 35 175A t21 debloc(balx,baly,balz

)90 50 35 175

A t22 commit 90 50 35 175

Figura 9.6.

Protocolul de blocare în două faze asigură serializanilitatea dar nu ne

scuteşte de probleme. Pezentăm în cele două exemple următoare rollback-ul în

cascadă şi blocajul ciclic.

Observaţi, în figura 9.7 la momentul t14 tranzacţia T7 face rollback (dintr-un motiv extern) şi, pentru că T8 este dependentă de T7 care a citit o înregistrare care a fost actualizată de T7, trebuie să facă şi T8 rollback, ceea ce pe urmă se întâmplă şi cu T9.

Time T7 T8 T9

A t1 begin_transactionA t2 ex_bloc(balx) A t3 cit(balx)A t4 part_bloc(baly)A t5 balx = baly +

balx A t6 scrie(balx)A t7 debloc(balx) begin_transactionA t8 … ex_bloc(balx) A t9 … cit(balx)A t10 … balx = balx +100 A t11 … scrie(balx)A t12 … debloc(balx) A t13 … …A t14 rollback …A t15 rollback begin_transactionA t16 part_bloc(bal

x)A t17 …A t18 rollback

Figura 9.7.O altă problemă este blocarea ciclică prezentată în exemplul

următor. Cele două trnzacţii T10 şi T11 se blochează reciproc.Time T10 T11

A t1 begin_transactionA t2 ex_bloc(balx) begin_transactionA t3 cit(balx) ex_bloc(baly) A t4 balx = balx -10 cit(baly)A t5 scrie(balx) baly = baly +100 A t6 ex_bloc(baly) scrie(baly)A t7 AŞTEAPTĂ ex_bloc(balx) A t8 AŞTEAPTĂ AŞTEAPTĂA t9 AŞTEAPTĂ AŞTEAPTĂA t10 … AŞTEAPTĂA t11 … …

Figura 9.8.

x

y

Blocajul ciclic este detectat , de obicei, prin constuirea unui graf de precedenţă care arată dependenţa între tranzacţii în felul următor:

- se crează un nod pentru fiecare tranzacţie- se crează o muchie direcţionată Ti Tj dacă tranzacţia Ti aşteaptă

să blocheze o înregistrare care este deja blocată de Tj.Pe acest graf se detectează un blocaj ciclic dacă există un circuit. Pentru figura 9.8 graful ar fi următorul:

Figura 9.9.

O altă metodă de a evita blocajul ciclic păstrând serializabilitatea este protocolul cu marcarea timpului (time stamp). Acest protocol ataşează un timp (timpul real din calculator sau un număr care se măreşte autmat de câte ori este solicitat) fiecărei tranzacţii (marc(T)) şi timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a unei înregistrări. Deci fiecare tranzacţie va avea o valoare de marcj şi fiecare înregiistrare prelucrată va avea două marcaje; unul care spune ce marcaj a avut tranzacţia care a citit-o (cit_marc) şi celălalt care spune ce marcaj a avut tranzacţia care a scris-o (scri_marc).

Numai în următoarele trei situaţii se pun probleme deosebite:1. Tranzacţia T cere să citească o înregistrare x care a fost deja actualizată de

o tranzacţie cu scri_marc(x) > marc(T), adică o înregistrare scrisă de o tranzacţie care a început mai târziu. Ce ar rescrie ea ar putea da naştere la inconsistenţă deci trnzacţia respectivă trebuie întreruptă.

2. Tranzacţia cere să scrie înregistrarea x a cărei valoare a fost deja citită de o tranzacţie care a început mai tîrziu marc(T) < cit_marc(x). Aceasta înseamnă că tranzacţia vrea să rescrie o înregistrare, pe care o altă tranzacţie începută mai târziu, a citit-o şi o foloseşte. Şi în acest caz tranzacţia trebuie întreruptă.

3. Tranzacţia cere să scrie o înregistrare x a cărei valoare a fost deja scrisă de o tranzacţie care a început mai târziu, adică marc(T) < scri_marc(x). Este o încercare de a scrie o valoare perimată şi în acest caz se ignoră această scriere.

În figura următoare se poate observa cum funcţionează acest protocol.

T10 T11

Time Op T7 T8 T9

A t1 begin_transactionA t2 cit(balx) cit(balx)A t3 balx = balx +10 balx = balx +100 A t4 scrie(balx) scrie(balx) begin_transactionA t5 cit(baly) cit(baly)A t6 baly = baly +20 baly = baly +20 begin_transactionA t7 cit(baly) cit(baly)A t8 scrie(baly) scrie(baly)**

A t9 baly = baly +30 baly = baly +30 A t10 scrie(baly) scrie(baly)A t11 balz=100 balz=100A t12 scrie(balz) scrie(balz)A t13 balz=50 balz=50 commitA t14 scrie(balz) scrie(balz)* begin_transactionA t15 cit(baly) commit cit(baly)A t16 baly = baly +20 baly = baly +20 A t17 scrie(baly) scrie(baly)A t18 commit

Figura 9.10.* la timpul t8 scrierea de către tranzacţia T13 violează regula 2 şi de aceea este întreruptă şi reluată la momentul t14

** la timpul t14 scrierea de către tranzacţia T12 poate fi ignorată conform celei de a treia reguli

9.4 Tehnici optimiste.Nu întotdeuna este necesar să pierdem timp în calculator controlând

concurenţa. Atunci când conflictele între tranzacţii sînt rare putem adopta aşa-numitele tehnici optimiste. Asta înseamnă să lăsăm tranzacţiile să ruleze fără să impunem întârzieri care să asigure serializabilitatea, iar când o tranzacţie vrea să facă ‘commit’ să efectuăm un control care să determine dacă a avut loc un conflict. Dacă a avut loc un conflict, tranzacţia trebuie întreruptă şi restartată. Pentru că am spus că aceeste conflicte sînt rare, aceste înteruperi şi restartări vor fi, şi ele, rare.

Distingem trei faze ale unui control optimist al concurenţei. Faza de citire. Această fază durează de la începutul tranzacţiei până

înainte de ‘commit’. Tranzacţia citeşte valorile de care are nevoie din baza de date şi le stochează in variabile locale. Actualizările nu sînt făcute direct în baza de date ci într-o copie locală.

Faza de validare. Urmează după faza de citire şi controlează dacă nu s–ar încălca serializabilitatea în cazul că s-ar aplica actulizarea în baza de date. Dacă avem o tranzacţie care numai citeşte baza (adică nu scrie), controlul constă în a verifica dacă datele citite sînt încă datele curente în bază şi, dacă este aşa, atunci se face ‘commit’, altfel se întrerupe şi se reia mai târziu. Dacă trnzacţia face şi rescrieri în bază, atunci se verifică dacă se păstrează serializabilitatea şi dacă baza de date rămâne într-o stare consistentă; dacă acest lucru nu se întâmplă, atunci se întrerupe.

Faza de scriere. Este o fază care este necesară numai la tranzacţiile care fac rescrieri. Dacă faza anterioară s-a terminat cu succes, atunci

actualizările efectuate în copia locală, sînt înregistrate definitiv în baza de date.

Iată cum se desfşoară acest tip de control:Fiecărei tranzacţii îi este ataşat, la începutul primei faze, un marcaj start(T), la

începutul celei de a doua faze, valid(T) şi la sfârşit fin(T), după scriere în copia locală, dacăeste cazul. Ca să treacă faza de validare trebuie să avem una din următoarele situaţii:

1) Toate tranzacţiile cu un marcaj mai mic, trebuie să se fi terminat înainte ca tranzacţia T să fi început; adică fin(S) < start(T).

2) Dacă tranzacţia start(S) < start(T) (S a început înaintea lui T) şi nu s-a terminat adică fin(S) < fin(T) atunci:

a. Datele scrise de tranzacţia anterioară S nu sînt cele citite de cea curentă T şi

b. Tranzacţia anterioară S îşi completează faza de scriere înainte ca tranzacţia curentă T să intre în faza de validare adică start(T) < fin(S) < valid(T).

Deşi tehnicile optimiste sînt eficiente când conflictele sînt rare totuşi pot apărea multe reluări (rollback); să reţinem că aceste reluări nu sînt în cascadă pentru că se lucrează pe o coppie locală.

Ce ne facem dacă apar totiţi inconsistenţe? Trebuie s{ [putem recupera baza de date într-o stare anterioară consistentă.

9.5 Controlul recuperării.Din diferite motive se poate întâmpla ca baza de date să ajungă într-o stare

incorectă sau să se piardă de tot. Un SGBD trebuie să prevadă mecanisme de recuperare automată sau manuală de recuperare a unei stări corecte a bazei de date şi posibilitatea de ajunge la zi cu actualizările ulterioare.

O tranzacţie este formată din paşi mici care se execută pe rând şi când a început acţiunea ‘commit’ ea nu s-a şi terminat. Datele sînt mai întâi duse într-un buffer (o memorie internă intermediară) şi pe urmă scrise în bază (pe disc). Dacă între scrierea în buffer şi scrierea pe disc apare vreo cădere, atunci SGBD-ul trebuie să reia scrierea (redo), iar dacă nu s-au umplut bufferele şi a apărut o cădere atunci SGBD-ul trebuie să facă întreruperea şi reluarea tranzacţiei (undo sau rollback).

Un SGBD trebuie să aibă un mecanism care să facă copii ale bazei de date ş jurnale ale tranzacţiilor după care ele să poată fi refăcute. Copiile se fac autmat, fără intervenţii manuale, şi recuperarea, în multe cazuri, trebuie să se facă tot automat.

Exerciţii recapitulative.1) Ce este o trnzacţie şi ce proprietăţi are?2) Daţi un exemplu de pierdere a consistenţei în cazul concurenţei

necontrolate.3) Ce este un plan de tranzacţii serializabil?4) Ce este blocajul?5) Ce este blocaju ciclic? Exemplu.6) Ce este protocolul de blocare în două faze?7) Care este protocolul de control cu marcarea timpului (time stamp)?8) Ce este o tehnică optimistă de control al concurenţei?Răspunsuri la exerciţii.

1) Tranzacţia este o acţiune sau o serie de acţiuni, executate de un singur utilizator sau un program, care accesează sau schimbă conţinutul bazei de date. Proprietăţile sunt:atomicitate,consitenţă, independenţă, durabilitate.

2) Tranzacţia T1 citeşte contul lui x (balx) şi scade 10 din cont. Tranzacţia T2

citeşte contul lui x (balx) şi adună 100 la cont. Pornind cu un cont de 100, evident că dacă se execută mai întâi prima tranzacţie şi apoi a doua contul lui x ar fi fost 100-10+100=190. În cealaltă ordine am fi avut 100+100-10=190 aceeaşi valoare. Să considerăm următorul plan de tranzacţii.

Time T1 T2 balx

A t1 begin_transaction 100A t2 begin_transaction cit(balx) 100A t3 cit(balx) balx = balx + 10 100A t4 balx = balx - 10 scrie(balx) 200A t5 scrie(balx) commit 90A t6 commit 90Se ved că balx are valoarea greşită 90.

3) Un plan de tranzacţii se va numi serializabil atunci când el are ca rezultat acelaşi cu unul executat serial.

4) Când o tranzacţie blochează partajat o anumită unitate de memorie, o altă tranzacţie nu mai poate să rescrie tot acolo, iar când o tranzacţie blochează exclusiv o alta nu mai poate nici să o citească.

5) Protocolul de blocare în două faze constă din împărţirea tranzacţiei în două faze una de blocări şi creşteri de blocaje şi a doua de descreşteri şi deblocaje. Aceasta înseamnă că după ce s-a făcut prima deblocare nu se mai pot face blocări.

6) Blocarea ciclică este prezentată în exemplul următor. Cele două trnzacţii T10 şi T11 se blochează reciproc.

Time T10 T11

A t1 begin_transactionA t2 ex_bloc(balx) begin_transactionA t3 cit(balx) ex_bloc(baly) A t4 balx = balx -10 cit(baly)A t5 scrie(balx) baly = baly +100 A t6 ex_bloc(baly) scrie(baly)A t7 AŞTEAPTĂ ex_bloc(balx) A t8 AŞTEAPTĂ AŞTEAPTĂA t9 AŞTEAPTĂ AŞTEAPTĂA t10 … AŞTEAPTĂA t11 … …

7) Protocolul cu marcarea timpului (time stamp) ataşează un timp fiecărei tranzacţii (marc(T)) şi timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a unei înregistrări. Deci fiecare tranzacţie va avea o valoare de marcaj şi fiecare înregistrare prelucrată va avea două marcaje; unul care spune ce marcaj a avut tranzacţia care a citit-o (cit_marc) şi celălalt care spune ce marcaj a avut tranzacţia care a scris-o (scri_marc).

Numai în următoarele trei situaţii se pun probleme deosebite:

1. Tranzacţia T cere să citească o înregistrare x care a fost deja actualizată de o tranzacţie cu scri_marc(x) > marc(T), adică o înregistrare scrisă de o tranzacţie care a început mai târziu. Ce ar rescrie ea ar putea da naştere la inconsistenţă deci trnzacţia respectivă trebuie întreruptă.

2. Tranzacţia cere să scrie înregistrarea x a cărei valoare a fost deja citită de o tranzacţie care a început mai tîrziu marc(T) < cit_marc(x). Aceasta înseamnă că tranzacţia vrea să rescrie o înregistrare, pe care o altă tranzacţie începută mai târziu, a citit-o şi o foloseşte. Şi în acest caz tranzacţia trebuie întreruptă.

3. Tranzacţia cere să scrie o înregistrare x a cărei valoare a fost deja scrisă de o tranzacţie care a început mai târziu, adică marc(T) < scri_marc(x). Este o încercare de a scrie o valoare perimată şi în acest caz se ignoră această scriere.

8) O tehnică optimistă înseamnă să lăsăm tranzacţiile să ruleze fără să impunem întârzieri care să asigure serializabilitatea, iar când o tranzacţie vrea să facă ‘commit’, să efectuăm un control care să determine dacă a avut loc un conflict. Dacă a avut loc un conflict, tranzacţia trebuie întreruptă şi restartată. Pentru că am spus că aceeste conflicte sînt rare, aceste înteruperi şi restartări vor fi, şi ele, rare.

Test de autoevaluareSe dă schema:Carte = (cod-carte,titlu,cod-domeniu,domeniu,5(cod-autor,nume-autor),cod-editură,editură,adresa) unde adresa=(oraş,strada,număr)1) Să se aducă la forma normală 1, 2, 3, şi să se specifice cheile folosin

dependenţele funcţionale.2) Pe forma finală să se exprime cererile:

a) Tabel cu editurile din Bucureştib) Tabel cu cărţile scrise de ‘Eminescu’c) Tabel cu cărţile scrise numai de ‘Eminescu’ in algebra relaţională şi in

SQL.Răspunsuri evaluate:Cheia in schema iniţială este cod-carte.1) Pentru că o să am nevoie de oraşul din adresă ea trebuie ruptă, iar grupul

repetitiv (cod-autor,nume-autor) trebiuie desfiinţat pentru a aduce la forma normală 1. Deci schema devine:Carten1=(cod-carte,titlu,cod-domeniu,domeniu,cod-autor,nume-autor,cod-editură,editură, oraş,strada,număr) unde cheia va fi K=( cod-carte, cod-autor)2 puncte

Dependenţele funcţionale sunt:I. cod-carte titluII. cod-carte cod-domeniuIII. cod-carte cod-editură IV. cod-domeniu domeniuV. cod-editură editură, VI. cod-editură oraş,VII. cod-editură strada,VIII. cod-editură numărIX. cod-autor nume-autor

1 punct unde dependenţa IX este parţială de cheieDeci forma normală 2 va fi:Carten21=(cod-carte,titlu,cod-domeniu,cod-editură,editură,oraş,strada,număr))carten22=(cod-autor,nume-autor) Carten23=(cod-carte,codautor)cu cheile subliniate după cum reiese din dependenţele:I. cod-carte titlu şi respectiv cod-autor nume-autorII. cod-carte cod-domeniuIII. cod-carte cod-editură IV. cod-domeniu domeniuV. cod-editură editură, VI. cod-editură oraş,VII. cod-editură strada,VIII cod-editură număr2 puncteDependenţele IV, V, VI, VII,VIII sunt tranzitive de cheie.Deci forma normală 3 va fi:Carten31=(cod-carte,titlu,cod-domeniu,cod-editură)Carten32=(cod-editură, editură,oraş,strada,număr)Carten33=( cod-domeniu,domeniu)carten22=(cod-autor,nume-autor) Carten23=(cod-carte,cod-autor) cu cheile subliniate.1 punct

2a) editură(oraş=’Bucureşti’(Carten32))select editurăfrom Carte32where oraş=’Bucureşti’2 puncte

2b) titlu (nume=’Eminescu’ (Carten31 JN Carten23 JN Carten22))select titlufrom Carten31, Carten23, Carten22where nume=’Eminescu’2 puncte

2c) titlu (nume=’Eminescu’ (Carten31 JN Carten23 JN Carten22)) \titlu (nume’Eminescu’ (Carten31 JN Carten23 JN Carten22))

select titlufrom Carten31, Carten23, Carten22where nume=’Eminescu’ and titlu not in

select titlufrom Carten31, Carten23, Carten22where nume’Eminescu’

3 puncte

BIBLIOGRAFIE

[1] L.Ţâmbulea - Structuri de date şi bănci de date, Universitatea Babeş-Bolyai, Cluj, 1992

[2] H.F.Korth, A.Silberschatz - Database System Concepts, McGraw Hill, New York, 1987

[3] I. Flores - Data Base Architecture, Van Nostrand Reinhold, 1981

[4] K. Weiskamp - The FoxPro Companion, Brady, New York, 1990

[5] * * * - FoxPro 2.0 Comentat şi exemplificat, Timisoara, 1992

[6] M. Stanescu şi colectiv - Limbaje de programare şi bănci de date, ASE, Bucuresti, 1992

[7] R Steiner - Theorie und Praxis relationaler Datenbanken, Vieweg Verlag, 1994

[8] A. Vulpe, D. Bucerzan - Lectii de FoxPro, editura Albastra, Cluj, 1997

[9] Connoly,