CURSBze de Date

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

Autor : Lector univ. dr. Paul
Conf. univ. dr. Mariana
1

pag

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

1. 1. Istoric,comentarii 5
1. . Definirea sistemelor de gestiune a bazelor de date relaţionale 6
1. 3. Regulile luiCodd 7
1. 4. Criterii minimale de definire a unui SGBDR 10
1. 5. Abstractizarea datelor 1
1. 6. Scheme, corespondenţe şi instanţe 14
1. 7. Independenţa datelor 15
1. 8. Principalele componente ale unui SGBD 15
1. 9. Obiectivele unui SGBD 18
1.10.Funcţiunile unui SGBD 0
!"#$
.1. Generalităţi, enumerări 5
.. Modelare E-R
..1.Concepte de bază 7
...Restricţii structurale 31
..3. Chei 34
.3. Modelul EE-R
.3.1. Problemele modelului E-R 35
.3.. Superclase şi subclase ale tipurilor de entitate 36
.3.3. Specializarea 37
.3.4. Generalizarea 38
.3.5. Condiţii impuse specializării şi generalizării 38
% &'(
3.1. Structura relaţionala a datelor
3.1.1. Domeniu 38
3.1.. Relaţie 39
3.1.3. Atribut 40
3.1.4. Operatorii modelului relaţional 41
3.. Algebra relaţională şi extensiile sale 41
) *'+&(,-*
4.1. Istoric, obiective 49
4.. Clauze şi operatori SQL
4..1.Clauzele SELECT, FROM şi WHERE 50
4...Ordonarea tuplelor (clauza ORDER BY 55
4..3.Gruparea rezultatelor (clauza GROUP BY 56
4..4.Interogări pe mai multe tabele 58
4..5.Subinterogări 59
4..6.Operatorii ANY şi ALL 6
4..7.Operatorul EXISTS 64
D

5.1.Redundanţa informaţiilor şi anomalii de actualizare 66
5..Dependenţe funcţionale 69
5.3.Forme normale
5.3.1.Prima formă normală 7
5.3..A doua formă normală 74
5.3.3.A treia forma normală 76
5.3.4.Forma normală Boyce-Codd 76
[ .#'(
6.1. Metodologia
6.1.1. Metodologia proiectării bazelor de date 80
6.1.. Prezentarea metodologiei 80
6.1.3. Crearea modelului logic 8
6.. Proiectarea logică a bazei de date ± Exemplu 98
6.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 118
6.3.. Anexa. Documentarea atributelor 119
6.3.3. Anexa. Documentarea tipurilor de relaţii din view-urile
³Locatari´ şi ³Cheltuieli 10
6.3.4. Anexa. Documentarea domeniilor atributelor 11
6.3.5. Anexa Descrierea relaţiilor din view-urile ³Locatari´ şi
³Cheltuieli 11
6.3.6. Anexa. Regulile date de întreprindere în cazul modelului
³Locatari´ şi ³Cheltuieli 1
6.3.7. Anexa. Modelul global de date al sistemului Asociaţia de
Locatari 1
/ '
7.1.Generaliăţi 14
7..Arhitectura unui SGBD distribuit 16
7.3.Proiectarea unei baze de date relaţionale distribuite 19
7.4.Alocarea datelor 130
7.5.Transparenţe în SGBDD 133
0 "&
8.1. Integritate 14
8.. Securitate 146
1 2("($
9.1.Tranzacţii 151
9.. Proprietăţile tranzacţiilor 15
9.3. Controlul concurenţei 15
9.4. Tehnici optimiste 158
9.5. Controlul recuperării 159
23 16
3

#(('#4"5$
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 ÷ ale acestui
sistem de prelucrare a datelor:
Separarea şi izolarea datelor
Duplicarea datelor
Dependenţa datelor
Incompatibilitatea fişierelor
Interogări fixe / proliferarea aplicaţiilor
Comentăm pe scurt în continuare semnificaţia acestora.

÷÷
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.
÷ ÷
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.
÷
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.
÷ ÷
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.
÷ ÷ ÷
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.
'$#3
1) În ce mod ajută calculatorul prelucrările de date?
) Care sunt inconvenientele sistemelor de fişiere?
#
1) Prelucrările de date pe calculator se fac mai rapid şi fără greşeli.
) Sistemele de fişiere duc la :
- Duplicarea datelor
- Dependenţa datelor
- Incompatibilitatea fişierelor
- Interogări fixe / proliferarea aplicaţiilor.
5

#

5
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: DB ş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.
4&'(
Î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ţie
Record(î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.
%
&
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.

÷

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

à ÷
÷ ÷

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

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.

Sistemele trebuie să permită declararea să manipularea sistematică a
valorilor 6 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ă).

÷ ÷ ÷ ÷
÷
÷ ÷

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

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 OI pentru SQL furnizează toate aceste
funcţii, deci orice limbaj care acceptă acest standard va satisface automat
această regulă.

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.

!

"
"
#
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.
$

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

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.

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.

ë ÷ ÷÷ ÷

÷ ÷÷ ÷
÷ ÷ ÷

÷÷
÷

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.

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, ÷
÷
÷ ÷ ! "÷÷
÷
÷
÷ ÷

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,
) Reguli structurale,
3) Reguli privind integritatea datelor,
4) Reguli privind manipularea datelor,
5) Reguli privind independenţa datelor.
) 4

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

pa care trebuie să la satisfacă un sistem de gestiune
a bazelor de date pentru a putea fi considerat releţional.
Un SGBD este

dacă satisface următoarela condiţii:
1. Toate datele din cadrul relaţiei sunt reprezentate prin valori în tabele,
. 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 #( 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 #( dacă satisface numai condiţiile 1. şi 3.

Un SGBD 4($($ 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 ' 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 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.
1
Clasificarea SGBD se poate realiza din mai multe puncte de vedere.
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.
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.
% 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.
) 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.
D '
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)
, trebuie alese doar acele proprietati (sau atribute) care intereseaza.
Acestea ar putea fi, de exemplu: ÷ ÷ ÷. 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:
- 3&337 sau 38. 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;
,3 # (&'). 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 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.
,3 4. Este dat de viziunea inginerului de sistem care realizeaza
structura fizica corespunzatoare descrierii datelor pe suportul fizic (periferic).
Acest nivel descrie 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.
Utilizator 1 Utilizator Utilizator n
Nivel
View 1 View «.. View n
extern
Nivel Schema
conceptual conceptuala
Nivel Schema
intern interna
Organizarea la
nivel fizic a datelor Baza de
date
Î& Arhitectura ANSI-SPARC pe trei nivele
[ .6#"
Descrierea generala a unei baze de date se numeste . ' .
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
. 8 (numite şi '.) care descriu diferitele view-uri ale
bazei de date. La nivelul conceptual exista .# iar la nivelul
cel mai de jos de abstractizare exista ..
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 #
# leaga schema conceptuala de schema interna. Datorita
acestei corespondente se identifica înregistrarea sau combinatia de înregistrari
15
la nivel fizic, care constituie â& & în schema conceptuala,
impreuna cu restrictiile de integritate corespunzatoare. Analog, fiecare schema
externa este legata de schema conceptuala prin # 8
#. 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 ' 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.
/ #
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
0 ##
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: *'+4
(Data Definition Language - DDL) şi *'+ #
(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.
*'+4* 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 (se mai utilizeaza şi termenii de
& sau ). Datele memorate în acest dictionar sunt
date despre date şi de aceea se mai numesc şi . 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.
*'+ # *! 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: # şi ,#. Un LMD
procedural trateaza înregistrarile individual şi specifica 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 ÷ 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
'+&. Intelegem prin interogare orice cerere de acces la datele
din baza de date, formulata într-un limbaj de interogare.
)*
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.

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.

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.

Un astfel de generator este o facilitate care regaseste date din baza de date şi
afiseaza aceste date sub forma unor grafice.
÷
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 '3
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:
&#.
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.
&"'
.
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.
% & 4 # . 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
0
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.
) #& 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.
D & & 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.
[ & #+' . 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.
Î
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:
Î 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,
1
-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.
Î # 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.
% Î 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.
) Î ' apare ca o functie complexa şi
este de competenta administratorului bazei de date.
'$#3
1) Enumeraţi momentele importante ale naşterii bazelor de data.
) 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?

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?
$#â'$
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.
) 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 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:
- 3&337 sau 38. 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;
,3 # (&'). Este dat de viziunea administratorului bazei de
date, care realizeaza structura conceptuală (schema) corespunzatoare descrierii
3
intregii baze de date şi administrează componentele bazei de date. Acest nivel
descrie 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.
,3 4. Este dat de viziunea inginerului de sistem care realizeaza
structura fizică corespunzatoare descrierii datelor pe suportul fizic (periferic).
Acest nivel descrie 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.
4
- 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.
. 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;
5
- 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.
% Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este
de competenţa administratorului bazei de date.
#
!

Numim 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;
() 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,
6
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 .. ş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:
(, şi ..
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 # sau &. 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.
!,
9,
.#
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
7
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.
#'
Conceptele primare ale modelului E-R includ : # ,
6#(,6'
Numim 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 # sau, 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 s.
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:
sau ). 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: , corespunzator
tuturor cadrelor didactice ale Facultatii de Stiinte şi , 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).
8
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 ' proprietaţile atasate unui tip de entitate.
Exemplu: entitatea poate fi descrisa de atributele# $
$$ ÷$ ÷.
Prin ' 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 $ 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 $ se poate descompune in
subdomeniile: ,÷,
.
In general putem considera ca fiecare entitate este reprezentabila cu ajutorul
unei multimi de perechi de forma %$ ÷$ &, cate o
pereche pentru fiecare atribut atasat tipului de entitate corespunzator.
Exemplu: o entitate a tipului de entitate poate fi reprezentata de
multimea: {($, Popescu), ($, Ion), ($ ,
15.11.1981), (, masculin), (, B-dul Garii, 1, Brasov, cod 00,
judetul Brasov), (÷, 068/444555), ($ ÷, 31455), (,
711)}
Atributele se pot clasifica în ÷ sau ; cu o ÷ sau cu
÷÷ ; respectiv .
Numim '# 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 '
Exemplu: atributul corespunzator tipului de entitate .
Numim '# 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 se poate descompune în atributele: , ,
, $ ÷ şi . 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 ' &$ 3 orice atribut care poate lua cate o
singură valoare pentru fiecare entitate.
9
Majoritatea atributelor sunt atribute cu o singură valoare.
Numim ' 3 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 ÷ 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 '3 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 este derivată din valoarea atributului
$ şi din data curenta. Valoarea atributului
÷$÷$$ se poate calcula numărând entităţile înregistrate.
#&4$,&,

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:
´ ' , care reprezinta tipuri de entitate;
´ ÷ , care reprezinta atribute;
´ ÷ , 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
numãr
nume bloc
locatari adresa
adresa scara
numãr
matricol apartament etaj

Î& Reprezentarea cu diagrama E-R a entitatii ÷
În exemplul din Figura .1. entitatea ÷ are următoarele atribute:

$ ÷, şi . Dintre aceste atribute, atributul este
atribut compus, care se descompune în $÷,,şi .
Explicatia sublinierii atributului $ ÷ se va da in sectiunea care se
ocupa de chei, tot in acest capitol.
Numim #( orice asociere între tipuri de entităţi.

Numim ( orice asociere între entităti, când asocierea include cate o
entitate pentru toate tipurile de entitate participante.
Fie E1, E, ..., En tipuri de entitate. Formal, un tip de relatie este o submultime
a urmatoarei multimi:
{( e1, e, ..., en) | unde e1ÜE1, eÜE, ..., enÜEn }
ceea ce inseamna ca ( e1, e, ..., 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 ÷ descris de atributele:
$ ÷ şi tipul de entitate descris de atributele
$$÷ şi . Intre tipul de entitate şi tipul de entitate ÷
se poate stabili un tip de relatie numit $÷ $. 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 & ( numărul entităţilor participante în relaţie. Asadar
relatia reprezentata mai sus are gradul . Entităţiile implicate intr-o relaţie se
numesc ##(. Dacă intr-o relaţie sunt doi participanţi, atunci relaţia se
numeşte '$.
Tipurile de relatii se reprezinta in diagramele E-R cu ajutorul romburilor care
sunt etichetate cu numele tipului de relatie.
31
nume
numar de
bloc scara numar
matricol adresa
scari este locu- locatari

ita de
1 M
Î& Reprezentarea cu diagrama E-R a relatiei $÷ $
Functia pe care o joaca o entitate intr-o relatie se numeste entitatii. In

general nu este necesar sa se specifice rolul entitatilor intr-o relatie, deoarece
acesta este in general implicit.
Numim ( 3$ 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 ÷ şi care se refera la
personalul aceleiasi intreprinderi, am face constatarea ca sunt descrise de
aceleasi atribute deci apartin aceluiasi tip de entitate şi anume . Relatia
binara ÷
$ stabilita intre ÷ 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".
lucrator
angajati lucreaza
manager pentru
Î& % Reprezentarea cu diagrama E-R a relatiei recursive

÷
$
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 $÷ $ care implica tipurile de entitate
şi ÷ , i se poate asocia atributul 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.
3

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: ÷ şi
.

Numim # 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).
(,,:
Î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.
(,,,:
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 $÷ $ dintre tipurile de entităţi , respectiv ÷ . In
reprezentarea grafică a acestui tip de relatie, arcul dinspre tipul de entitate
se eticheteaza cu 1 iar arcul dinspre tipul de entitate ÷ se
eticheteaza cu M (asa cum s-a şi realizat de fapt in Figura ..). Modelul
semantic din Figura .4. reprezinta relatia unu-la-mai-multe $÷ $.
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.
(,,,,:
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
33
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).
' '

nr_mat
nr_bloc R1 numele
scara Sc.A ´ Fam.1
R
nr_mat
nr_bloc Sc.B ´ Fam. numele
scara R3
Sc.C ´ Fam.3 nr_mat
nr_bloc
numele
scara
Î& ) Reprezentarea cu retele semantice a relaţiei 1:M

$÷ $
'
##
Numim ## 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 ÷ sau ÷. Participarea este ÷
daca existenta entitatii respective necesita existenta unei entitati asociate în
relaţia dată. În caz contrar participarea se numeşte ÷. 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 ÷ ÷ daca se considera tipul de entitate ÷ (unde entitatile
reprezinta personalul firmei respective) se poate defini tipul de relatie
$÷ 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 ÷ ÷in relatia $÷ 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 ÷ in
relatia $÷ este partiala.
#(8($
Numim # ' un tip de entitate, a cărui existenţă este
dependentă de existenta unui alt tip de entitate.
34
Numim # un tip de entitate, a cărui existenţă nu depinde de
existenta nici unui alt tip de entitate.
Entităţile slabe se mai numesc ÷ sau iar
entitatile tari se mai numesc sau .
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.
% .
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 #. 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 . 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, . #$ 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.
35
In diagrama E-R atributele care intră în componenţa cheii primare, se
evidentiază prin sublinierea numelui atributului.
Numim . #$ 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 unui tip de entitate slab, un set de atribute care
permite realizarea unei distinctii intre entitatile care depind de o anume entitate
tare. Asadar, .##' 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.
.## este formata din reuniunea multimilor de
atribute care formeaza cheile primare ale tipurilor de entitate participante.
% !.9,
.#,

% ',

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 (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: ÷ (fan trap),
respectiv (chasm trap).
Numim #$#' (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 #$ # #$# (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.
36
Ramane sa revenim asupra acestor aspecte in sectiunea care trateaza
proiectarea unei baze de date.
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.
% #"'#
Vom descrie aceste concepte, având ca exemplu tipul de entitate ÷ .
Numim #$ un tip de entitate ce include subclase distincte care
necesita reprezentarea într-un model de date.
Numim '$ un tip de entitate care are un rol distinct şi care este de
asemenea membru al unei superclase.
De exemplu superclasa ÷ se divizează în două subclase şi anume:
$$ şi ÷ . 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
÷ ÷ 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
÷ , 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.
37
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 ÷
se caracterizează prin toate atributele superclasei ÷ ($ ÷,
$÷, , , şi ), pe lângă care mai are şi
atributele specifice ($, $$
, etc.)
Fiecare subclasă poate să aibă subclase, creîndu-se un arbore de clase, care se
numeşte .#. Această ierarhie de tipuri include alte denumiri de
ierarhii şi anume: . #$ (de exemplu, tipul de entitate
÷ este o specializare a tipului de entitate ÷ ) şi .
&$ (de exemplu, tipul de entitate ÷ este o generalizare a
tipului de entitate ÷ ).
% % #
Numim # 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:
numar
matricol locatari familii
numar numar
sef de scara
bloc adresa persoane
data
intrarii în
functie

Î& D Reprezentarea relatiei superclasa / subclasa in cazul tipului de
entitate ÷
În exemplul de mai sus tipul superclasa ÷ se compune din subclasele:

$$ şi ÷ . Superclasa ÷ 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 ÷ vor apărea ca membri şi în
subclasele $$, respectiv ÷ .
38
Putem intalni mai multe specializari la acelasi tip de entitate daca se porneste
de la caracteristici de diferentiere diferite.
Numim '$#+$ subclasa care are mai multe superclase.
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 "#$.
% )
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.
% D ##$"&$
În acest capitol vom discuta despre restrictiile ce trebuie impuse în cazul
specializării sau al generalizării.
Prima conditie se numeşte & +(. 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 ³´ î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
+ şi se notează cu ³´ în cercul care leagă subclasele de superclase. În
exemplul nostru, subclasele $$ şi ÷ - care sunt subclasele clasei
÷ - sunt non disjuncte.
A doua conditie (a specializării) este &##$, 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 ÷ , cu
subclasele $$şi ÷ .
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ă.
39
#%
&'($
In cadrul bazelor de date relaţionale, datele sunt organizate sub forma
unor tablouri bidimensionale (tabele) de date, numite(. 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.
# (. 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.
%
( & (. Permit
definirea stărilor coerente ale bazei de date.
În continuare, vor fi prezentate pe larg aceste componente.
% (
Prezentarea structurii relaţionale a datelor impune definirea noţiunilor
de: domeniu, relaţie, atribut şi schemă a unei relaţii.
%
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, D, D3, definite astfel:
D1: ("F","M")
D : (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 D şi
D3 s-a utilizat definirea implicită.
Pentru un ansamblu de domenii D1, D, ..., Dn produsul catezian al
acestora reprezinta ansamblul tuplurilor <v1, v, ..., vn>, unde: v1 este o
valoare apartinând domeniului D1, v este o valoare din D s.a.m.d.
De exemplu, tuplurile: <"Maria", "F", 50>, <"Vasile", "M",15>,
<"Vasile","M",0>, <"Vasile", "F",100> aparţin produsului cartezian: D3 x
D1 x D
%
(
Să presupunem că se acordă o anumită semnificaţie valorilor
domeniilor D1, D, D3, definite anterior.
Sa considerăm, de exemplu ca D1 cuprinde valorile referitoare la sexul
unei persoane, D conţine valori care exprimă vârsta unei persoane şi D3
cuprinde numele unor persoane.
40
Numai unele dintre tuplurile produsului cartezian: D3 x D1 x D pot
avea o semnificaţie şi anume cele care conţin numele, sexul şi vârsta aceleiaşi
persoane.
Dintre cele 0 tupluri care au valoarea "Vasile" pe prima pozitie, numai unul
poate avea o semnificaţie, dacă presupunem că există o singură persoană cu
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.

( 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 ale
tuplurilor) .
O reprezentare comodă a relaţiei este tabelul bidimensional (tabela de
date în care liniile reprezinta tuplurile, iar coloanele corespund domeniilor
(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-o
relaţie reprezinta relaţiei, în timp ce numărul valorilor dintr-un
tuplu defineste & relaţiei.

% % '
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.
41
O posibilitate de organizare a acestor date o reprezintă relatţa din
fig.3..
R: D3 D1 D
³Maria´ ³F´ 30
³Vasile´ ³M´ 35
Î& % Relaţia PERS
Relatia PERS reprezintă un subansamblu al produsului cartezian:

D3 x D1 x D 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.
' reprezintă coloana unei tabele de date, caracterizată printr-
un nume. Numele coloanei (atributului) exprimă de obicei semnificaţia
valorilor din cadrul coloanei respective.
.(
Prin . 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, A, ..., An şi domeniile: D1, D,..., 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) A1:D1 « An:Dm
a) b)
% ) #(
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ă.
% &'($"8
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 şi
producând ca rezultat o altă relaţie.
4
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.
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
au fost adăugate şi alte operaţii, aşa
numitele operaţii "adiţionale" sau8
, 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.

. Reprezintă o operaţie a AR definita pe doua relaţii: R1
şi R ambele cu o aceeaşi schemă, operaţie care constă din construirea unei
noi relaţii R3, cu schema identică cu R1 şi R şi având drept extensie tuplurile
din R1 şi R luate impreună o singură dată.
Notaţia uzuală pentru reuniune este: R1 U R
Reprezentarea grafică a reuniunii este prezentata in fig. 3.3.
Î& % % Reuniunea relatiilor ORASE şi MUNICIPII
In fig. 3.3. este ilustrata aceasta operatie .

4(. Reprezintă operaţie din AR definită pe doua relaţii: R1 şi
R, 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 R.
Notaţia uzuală pentru operaţia de diferenţă a doua relaţii este: R1-R
În fig. 3.4. este prezentat un exemplu de diferenţă a doua relaţii.
43
Î& % ) Diferenţa relaţiilor ORAŞE şi MUNICIPII
% . Reprezintă o operaţie a AR definită pe două

relaţii: R1 şi R, 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 R şi a cărei
extensie cuprinde toate combinaţiile tuplurilor din R1 cu cele din R.
Notaţia uzuală pentru desemnarea operaţiei este: R1xR
Fig. 3.5. prezintă un exemplu de produs cartezian a două relaţii.
TRANSP: ORAŞ:D1 JUDEŢ: D1 TRANSPORT:D3 TARIF:D4

Braşov Braşov tramvai 30
Târgovişte Dâmboviţa tramvai 30
Braşov Braşov autobuz 50
Târgovişte Dâmboviţa autobuz 50
Braşov Braşov troleibuz 50
Târgovişte Dâmboviţa troleibuz 50
ORAŞE:
TARIF:
ORAŞ:D1 JUDEŢ:D1 ;
TRANSP:D3 TARIF:D3
Braşov Braşov
tramvai 30
Târgovişte Dâmboviţa
autobuz 50
troleibuz 50
Î& % D. Produsul cartezian al relaţiilor ORAŞE şi TARIFE
) (. 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
Prin operaţia de proiecţie se trece de la o relaţie de grad n la o relaţie de grad
p, 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.
Î& % [ Proiectia relaţiei ORAŞE pe atributul "Judeţ"
D (. 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
Î& % / Selecţie efectuata asupra relaţiei ORAŞE
[ <(< Reprezintă o operaţie din AR definită pe două

relaţii: R1 şi R, operaţie care constă din construirea unei noi relaţii R3,
prin concatenarea unor tupluri din R1 cu tupluri din R. Se concateneaza acele
tupluri din R1 şi R 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.
Î& % 0. 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.

=+ 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,R, condiţie) = RESTRICT(PRODUCT(R1,R), 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.
<( $. 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 R, prin care este construită o noua relaţie R3, a cărei schemă este
obţinută prin reuniunea atributelor din relaţiile R1 şi R (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 R care prezintă aceleaşi valori
pentru atributele cu acelaşi nume.
Î& % 1 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
Î& % Reprezentarea grafică a operaţiei de joncţiune
naturalăo o

Î& % 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ă.

/ (. Reprezintă o operaţie a AR definită pe două relaţii: R1
şi R 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 R.
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.1., iar

un exemplu de intersecţie a doua relaţii figurează în fig. 3.13.
Î& % Reprezentarea grafica a operatiei de intersectie
48
Î& % %. 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:
R1m R=R1-(R1-R)
R1m R=R-(R-R1)
½

Se dau următoarele relaţii cu schemele lor:
,$ (Nr_bloc, Scara, Lift)
,#(Nr_bloc,Scara,Apartament,Suprafaţa,Cutii_poştale,
Nr_prize_tv)
-Î (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)
-*
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) = R1
) (tabel nominal cu locatarii de pe scara = 1 din bloc = 34) = R
3) (tabel nominal cu locatarii de pe scara = din bloc = 34) = R3
4) tabel nominal cu locatarii de pe scările 1,,3 ale blocului 34
5) lista apartamentelor cu suprafaţa mai mare decât 50 mp
6) tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 şi nu
locuiesc şi pe scara 1 a aceluiaşi bloc

1) R1=nume( bloc=34 and scara=3(scari) o (locatari))
) R= nume ( bloc=34 and scara=1(scari) o (locatari))
3) R3= nume ( bloc=34 and scara=(scari) o (locatari))
49
4) R = R1 M R M R3
5) R = suprafaţa > 50(apartamente)
6) R= (R1-R)

#)
*'+&

) 6'3
-* ( -9 *&&), 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 nstitutului ational merican de tandarde
( , celelalte fiind concepute de firme de prestigiu ca IBM,
Microsoft şi Borland sau de cãtre consorţii ca (2. -*
#) şi ;#.
Primul standard SQL a fost creat in anul 1989 de cãtre ANSI fiind
cunoscut sub numele de ,-*>01 " a fost revizuit in octombrie
199 sub noua denumire: ,-*>1
In anul 199, firma Microsoft, in calitate de membru SAG, a lansat pe
piata produsul (# ' 39), un standard
,-* care defineste o interfatã de programare a aplicaţiilor (
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
( &'## && 4).
In încercarea de a extinde substantial limbajul SQL, ANSI pregateste
noua generatie de standarde SQL, denumitã -*%6 care se adreseaza
bazelor de date orientate obiect.
Mentionam aici şi standardul IBM pentru acces la bazele de date de pe
platformele proprii, denumit
('
'
). 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.
) "#-*
) *26Î
!"?@

Clauzele SQL *26Î
!"?@
pot fi puse în corespondentã cu
operatorii din algebra relaţionalã, dupa cum urmeaza:
´ clauza *2 mentioneaza o lista de atribute şi corespunde proiectiei
din algebra relaţionalã;
´ clauza Î
! mentioneazã o listã de relatii (tabele) şi corespunde
produsului cartezian din algebra relaţionala;
´ clauza ?@
descrie un predicat de selectie şi corespunde selectiei din
algebra relaţionalã.
O interogare simpla SQL este de forma:
*26 6 6
Î
!
6
6 6

?@

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

sunt relatii (tabele);
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 Î
A
cu schema de relatie ($
$

$
).
51
Tabela Î*
cu schema de relatie ($ $ ÷
÷ $ ).
Tabela !A cu schema de relatie ($ $
$
$
$÷ ).
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 $

din schema de relatie corespunzatoare tabelei FURNIZORI este un atribut
compus. El poate fi descompus in: .
;! *: Sa se exprime in SQL urmatoarele inteogari:
i
÷
i
*2B
Î
!4
i
÷ ÷
÷i
*2
Î
!4
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:
*2C 2 2**DE'F
Î
!EF
C?@
EF
GE'F
@H EF

GE'F
CD E'I&FD5
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:
*2E'F
Î
!EF
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;
5
´ 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 "B");
´ expresii formate din urmatoarele elemente:
-atribute şi operatori aritmetici (de exemplu:
B#I)
-functii standard (de exemplu 2( ));
-constante;
-variabile de memorie.
´ expresii care contin functii SQL agregat cum ar fi H 6
!;6! 626!...
In exemplele de mai sus, pentru a evita repetarea unor informatii in
tabelele rezultat se poate utiliza cuvintul cheie 2 2.
Optiunea 2 2 permite eliminarea tuplelor duplicat. In acest
mod numai prima aparitie a unui tuplu este afisatã în tabela-rezultat.
;! *:
i
÷ ÷
÷
÷
÷i
*2 2 2
Î
!4
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 ** permite dimpotrivã, afisarea tuplelor-duplicat.
Aceastã optiune este implicitã.
Clauza Î
! are forma generala:
Î
!EEFE37FCEFD F
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.
;! *:
i
÷
÷ ÷

÷ i
*2 I46 I
Î
!46
?@
I4J I4
i
÷
÷ ÷
÷ ÷
÷
÷
÷ i
53
*2 I46 I46 6
I
Î
!46
?@
I4J I4
A se observa ca in al doilea exemplu nu s-a mai utilizat notatia cu alias pentru
atributul I din tabela deoarece nu este pericol de
confuzie. In schimb s-a utilizat notatia pentru a deosebi atributul I4
din tabela 4 de atributul cu acelasi nume din tabela
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:
?@
E#FE8#F5
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:EFEJFJEFKJJ
,logici: 2

- operatori SQL: 6; 26**6G
´ 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.
#
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.
;! *:
i
÷÷ ÷

÷
i
*2I#6B#I
Î
!
?@
EF
#(
< 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).
;! *:
i
÷÷÷÷÷i
*2,#
Î
!4
?@
J>'>
#&
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 ().
;! *:
i
÷ ÷÷ ÷ ÷ ÷ ()
i
*2I#
Î
!4
?@
J>'>ED
i
÷÷ ÷ ÷÷ ÷
÷ ÷ ()i
*2I#66
Î
!4
?@
J>'>
ED
% A se observa ca ultima interogare este echivalenta cu interogarea
*2I#66
Î
!4
?@
J>'>
2FJD

55
) #

G
În exemplele anterioare, tuplele tabelei-rezultat apar în aceeasi ordine în care
au fost introduse. Pentru modificarea ordinii de afisare se utilizeazã clauza

G Forma generala a acestei clauze este:

GEE'FELâ&FF6
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.
;! *:
i
÷ ÷ ÷ ÷
÷÷ ÷i
*2B
Î
!4

GI#6
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.
;! *:
*26I46I4
Î
!4

G6%
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.
# 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).
;! *:
i
÷
÷ !
! *÷i
*2B
Î
!4
?@
>
2 >6>
H>6>*<>
Î
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
,3,H
,3,!
,38,!;
,,!
,LL,2
NOTA: Nu este permisa utilizarea acestor functii in clauza WHERE deoarece
ele actioneaza la nivel de atribut şi nu la nivel de tuplu.
;! *:
i* +i
*2!
Î
!
Spre exemplu,urmãtoarea interogare are ca rezultat afisarea cantitãtii totale şi a
numãrului de produse din fisierul de comenzi.
*2!62B
Î
!
i* +i
*2H
Î
!
% i* ÷ ÷,-)-,+i
*2!
Î
!
?@
I#J> >
) i*÷ ÷÷ +i
*22B
Î
!4
D i*÷ ÷ ÷ ÷ +i
*22 2 2
Î
!4
) % #
G
În multe cazuri, utilizatorul doreste anumite situatii sintetice, cum ar fi
obtinerea de totaluri şi subtotaluri. Pentru aceaste operatii, limbajul SQL
permite utilizarea clauzelor
G " @H Aceste clauze
organizeazã tuplele în grupuri asupra cãrora se pot realiza anumite operatii, în
special prin aplicarea functiilor agregat.

57
Clauza
G 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 *2 pot fi de douã feluri:
- atribute care alcãtuiesc baza pentru grupare (cele care apar în clauza

G)
- atribute care nu participa la gruparea rezultatelor.
;! *:
i
÷ +i
*2
Î
!4

G
In urma executarii interogarii vor apare orasele din fisierul de furnizori listate
o singura data.
i*
÷ +i
*262B
Î
!4

G
% i÷ ÷ .
+i
*262B
Î
!4

G
@H 2BFJ%
Clauza
G se poate folosi şi cu clauzele

G şi ?@
.
;! *:
i
÷ ÷

÷ i. (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.)
*2
Î
!4

G

G
i*
÷
÷÷÷/0
÷+i
*2I4
Î
!
?@
#I3E/

GI4

58
) ) &#'
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.
;! *:
i
÷
÷ ÷
÷ ÷
÷
÷i
*2 I46I466I
Î
!46'
?@
I4J' I4
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
$
. Modul de notare de mai sus este acceptat de sintaxa SQL şi
diferentiaza atributul $
din tabela
de atributul
$
din tabela
.
i
÷

!i
*2 I46I466I
Î
!46'
?@
I4J' I4J>3>
% i* ÷ ÷ ÷÷+i A se observa ca aceasta
interogare necesita realizarea produsului cartezian al tabelei FLORI cu ea
insasi.
*2 # I#6 # I#6 # 6
#
Î
!4#64#
?@
# J# # I#J>**>

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:
*26M6
Î
!
C?@
MD

*26M6
Î
!M
C?@
MD
;! *:
i
÷÷÷ ÷÷÷ ÷
-) ()i
*2I#6I#
Î
!4
?@
J>'>E

*2I#6I#
Î
!4
?@
J>'>FD
) D '&*2'
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 ?@

a inca unei clauze*2. Forma generala a unei astfel de constructii este:
*2E'F
Î
!EF
?@
E'&F
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:
´ '&L#
60
Interogarea interioarã este evaluatã prima, independent de interogarea
exterioarã. Rezultatul evaluãrii interogãrii interioare este utilizat de cãtre
interogarea exterioarã .
´ '&L
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.
'&L#L&L3
Aceste interogãri au urmãtoarea sintaxã:
*2E'F
Î
!EF
?@
E'FÊE'&F
unde Êeste un operator relaţional: JEFFJEJKJ
Vom considera urmãtorul exemplu:
;! *:
i1
÷÷÷ ÷ ÷÷÷÷ i
*2I#
Î
!4
?@
J
*2
Î
!4
?@
I#J>**>
Aceeasi interogare poate oferi lista numelor de plante in ordine alfabetica
inversa daca se utilizeaza şi o clauza ORDER BY.
*2I#
Î
!4
?@
J
*2
Î
!4
?@
I#J>**>

GI#
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 $÷2,ë ë ,.
Valoarea obtinuta pentru atributul ÷ (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:
*2I#
61
Î
!4
?@
J%
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, «).
;! *:
"Sa se afiseze numele plantelor care au inaltimea minima"
*2I#
Î
!4
?@
J
*2!
Î
!4
'&L#L3
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.
;! *:
i*
÷ +i
*2I4
Î
!4
?@
I4
*2I4
Î
!

GI4
i*

÷
÷ +i
*2I4
Î
!4
?@
I42
*2I4
Î
!

GI4
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
6
diferenta intre tabele, se poate constru aceasta operatie cu ajutorul preicatului
NOT IN ca in exemplul de mai sus.
% i*
÷
÷ +i
*2I4
Î
!4
?@
I4
*2I4
Î
!

GI4
@H 2BJ
*2
!;2I4
Î
!

GI4
'&L
Î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 '&L6 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.
;! *:
i
÷ ÷ ÷ ÷÷ ÷÷
÷ ÷i
*266I#
Î
!44
?@
J
*2!;
Î
!4
?@
J4

G
A se observa ca şi interogarea anterioara se poate incadra in cazul ilustrat de
exemplul de mai sus.
) [ #G"**
Operatorul G poate fi utilizat în combinatie cu oricare dintre operatorii
relaţionali (J E F FJ EJ !J pentru a se verifica dacã valoarea unui
63
atribut este egala, mai mica, mai mare, etc«decat oricare dintre valorile
mentionate odata cu operatorul. Urmãtoarele predicate sunt echivalente :
JG si
KJG si 2
Operatorul **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:
*2M
Î
!M
?@
8E**6 6%6)
Sa observam ca daca inlocuim operatorul ** cu expresia verbala
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:
8#?@
H8#
x < ALL 0, -1, -, «
x <= ALL 1, 0, -1, -, «
x > ALL 5, 6, 7, «
x >= ALL 4, 5, 6, ..
Daca vom studia o interogare de forma:
*2M
Î
!M
?@
8EG6 6%6)
Sa observam ca daca inlocuim operatorul G cu expresia verbala
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:
8#?@
H8#
x < ANY 3, , 1, 0, -1, -, «
x <= ANY 4, 3, , 1, 0, -1, -, «
x > ANY , 3, 4, 5, 6, 7, «
64
x >= ANY 1, , 3, 4, 5, 6, ..
;! *:
i
÷ ÷÷ ÷ ÷ ÷÷
() ÷ ÷ ÷÷ ÷
()i
*2I#6#I6
Î
!4
?@
#IE**
*2#I
Î
!4
?@
FJD
i
÷÷÷ ÷ ÷
() ÷ ÷i
*2I#6#I
Î
!4
?@
FJD#IEG
*2#I
Î
!4
?@
FJD
% i
÷÷ ÷ ÷
÷ ÷()i
*2I#6#I
Î
!4
?@
FJD2#IEG
*2#I
Î
!4
?@
FJD
) / #; 2
Operatorul ; 2 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.
;! *: i* ÷ ÷
÷÷÷+i
*2I#6#I6
Î
!44
65
?@
2; 2
*2B
Î
!4
?@
J>'>#IF4 #I
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:
,$ (Nr_bloc, Scara, Lift)
,#(Nr_bloc,Scara,Apartament,Suprafaţa,Cutii_poştale,
Nr_prize_tv)
-Î (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)
-*
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) = R1
8) (tabel nominal cu locatarii de pe scara = 1 din bloc = 34) = R
9) (tabel nominal cu locatarii de pe scara = din bloc = 34) = R3
10) tabel nominal cu locatarii de pe scările 1,,3 ale blocului 34
11) lista apartamentelor cu suprafaţa mai mare decât 50 mp
1) tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 şi nu
locuiesc şi pe scara 1 a aceluiaşi bloc
" ÷
1) nume
4scari, locatari
7. (scari.bloc=34) and(scari.bloc = locatari.bloc)
and (scari.scara=3) and (scari.scara= locatar.scara)
) nume
4scari, locatari
3) nume
4scari, locatari
and (scari.scara=) and (scari.scara= locatar.scara)
4) nume
4scari, locatari
nume
4scari, locatari
66
nume
4scari, locatari
and (scari.scara=) and (scari.scara= locatar.scara)
5) Nr_bloc,Scara,Apartament
4apartamente
7.suprafaţa > 50
6) nume
4scari, locatari
and not in ( nume
4scari, locatari
7. (scari.bloc=34) and(scari.bloc
locatari.bloc)
and (scari.scara=1) and (scari.scara=
locatar.scara))
#D

D
4"
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 (197). Iniţial s-au
propus trei forme normale, notate Î, Î, respectiv %Î. Mai târziu, prin
enuntarea unei definitii mai tari a formei normale trei, s-a obtinut forma
9,, 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: ÷ . şi ÷
!3*. Există şi forme normale mai tari - forma normală 4 ()Î) şi
forma normală 5 (DÎ) - 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
67
aparitia anomaliilor la actualizare.
Pentru a ilustra procesul de normalizare, vom utiliza exemple din sistemul
informatic ÷ .
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 4
$*'÷ ÷ exemplificată mai jos. In exemple se vor
simplifica numele atributelor.
I4I4I4I. I.
H
F100 Romgaz R134567 C15 Incalzire 30.06.99
,150,000
F100 Romgaz R134567 C16 Apa calda 30.06.99
500,000
F110 Renel R765431 C10 Iluminat 30.06.99
3,000,000
F110 Renel R765431 C11 Lift 30.06.99
00,000

Î&D Relaţia 4
$*'÷ ÷
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 = (I4, Den_furn, Cod_fiscal, I.6
Den_chelt, , Valoare)
Dintre atribute, cele evidentiate constituie cheia primara pentru relatia
respectiva. Relatia 4
$*'÷ ÷ are cheia compusa din atributele
*$, *$*'÷ şi . Datele sunt prost organizate in relatia
prezentata.
Informaţia despre furnizori din relatia 4
$*'÷ ÷ 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.
&
Anomaliile de inserare se pot clasifica în două tipuri:
´ Pentru a adauga detaliile despre o cheltuială către un furnizor, în relaţia
68
4
$*'÷ ÷ 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
î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
4
$*'÷ ÷ , 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.
"&
În cazul ştergerii unei cheltuieli a asociaţiei de locatari către un furnizor nou
(tot in cadrul relatiei 4
$*'÷ ÷ ), 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.
4
Dacă în relaţia 4
$*'÷ ÷ 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: *'÷ ÷ şi 4
. În acest caz dacă trebuie modificat un
atribut al unui furnizor, modificarea se va xecuta intr-un singur loc în relatia
4
. Asemanator, daca e necesara o stergere in relatia *'÷ ÷ , aceasta
nu va mai afecta furnizorii din relatia 4
. De asemenea orice cheltuiala
adaugata şi orice furnizor nou adaugat nu se vor mai conditiona reciproc in
nici un fel.
##4
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
69
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
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, R, «, Rn} daca

r" =R
Ú1
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, r, «, rn construite pe schemele de relatie ce
formeaza descompunerea. In termenii algebrei relaţionale se poate considera
egalitatea;
ri = "
(r) pentru toti 1pipn.
Deci fiecare este proiectia relatiei pe atributele care apar in schema de
relatie Ri.
Descompunerile cu pierderi de informatii se pot clasifica in #
#+ şi ###. Pentru
a clarifica lucrurile in aceasta directie este necesara mai intai definirea notiunii
de dependenta functionala.
D #(4(
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 AaR şi BaR. Spunem ca B depinde functional de A şi scriem A B
daca pentru orice relatie legala r, construita pe schema de relatie R, se verifica
urmatoarea situatie:
pentru orice pereche de tuple t1 şi t din r, pentru care t1[A]=t[A], are loc
intotdeauna şi t1[B]=t[B].
Aceasta inseamna ca atunci cand un tuplu t1 are (pe submultimea de atribute
A) aceeasi valoare cu alt tuplu t, 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 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 4
$*'÷ ÷
70
sunt:
Cod_furn Den_furn
Cod_furn Cod_fiscal
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 K R, adica pentru orice pereche de tuple t1 şi t din r, pentru
care t1[K]=t[K], are loc intotdeauna şi t1[R]=t[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.
&8&:
1) ÷ ÷ ± daca X este un subset de atribute din R şi Y X,
atunci are loc X Y;
) ÷ ± daca X, Y şi W sunt subseturi de atribute din R şi daca
X Y atunc WX WY;
3) ÷
± daca X, Y şi Z sunt subseturi de atribute din R şi
daca X Y şi Y Z atunci are loc şi X Z.
Cele trei reguli sunt suficiente şi formeaza un set complet pentru a se putea
71
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:
4) ÷ ± daca X, Y şi Z sunt subseturi de atribute din R şi daca
X Y şi X Z atunci şi X YZ;
5) ÷ ± daca daca X, Y şi Z sunt subseturi de atribute din
R şi daca X YZ atunci au loc şi X Y şi X Z;
6) ÷
- daca X, Y, W şi Z sunt subseturi de atribute
din R şi daca X Y şi WY Z atunci şi WX Z
;! *:
Fie schema de relatie R={A, B, C, G, H, I} şi fie setul de dependente initial
notat cu F şi format din dependentele: A B, A C, CG H, CG I, B H.
Pornind de la acest set initial se mai pot calcula şi urmatoarele dependente:
´ A H, utilizand regula tranzitivitatii aplicata la dependentele A B şi
B H;
´ CG HI, utilizand regula reuniunii pentru dependentele CG H şi CG I;
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.
#4#+
Fie o descompunere oarecare {R1, R, «, Rn} a relatiei R, asa cum am definit-
o formal la inceputul acestui capitol. Pentru o descompunere oarecare se
verifica intotdeuna relatia:
n
ra X ri
i Ú1
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 ti
in fiecare relatie ri. Cand se realizeaza produsul cartezian cu toate relatiile ri, 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.
7
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, R, «,
Rn} a unei scheme de relatie R este o descompunere fara pierderi la jonctiune
pentru R, daca pentru toate relatiile r definite pe schema R (care sunt legale
sub restrictiile C) se verifica:
n
r= " ( r)
i Ú1
Vom prezenta in continuare un criteriu cu ajutorul caruia se poate verifica daca

este o descompunere fara pierderi la jonctiune sau nu.
4 Fie R o schema de relatie şi fie descompunerea lui R reprezentata de
{R1, R}. Aceasta descompunere este fara pierderi la jonctiune daca cel putin
una dintre urmatoarele dependente functionale se gasesc in F+:
R1mR R1
R1mR R
###
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, R, «, 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, F, «, Fn. Fie

F'= r Fi, reuniunea seturilor de dependente funtionale. In general F'F. Dar
Ú1
s-ar putea ca sa se verifice relatia F'+=F+. Daca se intampla asa atunci spunem
ca descompunerea este o descompunere cu pastrarea dependentei.
D % Î
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.
D % Î$Î
Numim Î$$Î orice tabelă care conţine una sau mai
73
multe grupuri repetitive pe atribute.
Î $ Î: Spunem ca o relaţie se gaseste in Forma
normala unu daca orice atribut este atomic, adica nu exista nici atribute
compuse nici repetitive.
Pentru a transforma tabela din Figura 5. î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 4
$*'÷ ÷ :
I4I4I4I. I.
H
,150,000
C16 Apa calda 30.06.99
500,000
3,000,000
C11 Lift 30.06.99
00,000
Î&D Tabela nenormalizată 4
$*'÷ ÷ .
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

74
I4I4I4I. I.
H
,150,000
F100 Romgaz R134567 C16 Apa calda 30.06.99
500,000
3,000,000
F110 Renel R765431 C11 Lift 30.06.99
00,000
Î&D % Tabela 4
$*'÷ ÷ î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 (I4, Den_furn, Cod_fiscal)
Cheltuieli (I4, I., , Den_chelt, Valoare)
Cele două tabele astfel create sunt în 1NF:
O

I4 I. I. H
F100 C15 30.06.99 Incalzire 1500000
F100 C16 30.06.99 Apa calda 500000
F110 3 C10 30.06.99 Iluminat 3000000
F110 4 C11 30.06.99 Lift 00000
Î

I4 I4 I4
F100 Romgaz R134567
F110 Renel R765431
Î& D D Relaţiile *'÷ ÷ şi 4

, create prin metoda a doua de
normalizare.
Pentru a demonstra trecerea la forma normală doi şi mai departe, vom folosi
relaţia 4
$*'÷ ÷ , prezentata în figura 5.3.
D % Î$ Î
Forma normală doi se obtine utilizand conceptul de dependenţă funcţională
totală.
75
#(4($$ 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
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 NF daca este in 1NF.
Î$ Î 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
4
$*'÷ ÷ 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 O

:
I4 I. H
F100 C15 30.06.99 1500000
F100 C16 30.06.99 500000
F110 C10 30.06.99 3000000
F110 C11 30.06.99 00000
Relaţia Î

I4 I4 I4
F100 Romgaz R134567
F110 Renel R765431
Relatia à
&
:
I. I.
C15 Incalzire
C16 Apa calda
C10 Iluminat
C11 Lift
76
Î& D D Relaţiile rezultate după trecerea la NF a relaţiei
4
$*'÷ ÷ .
Relaţiile rezultate au următoarele scheme de relatie:
Furnizori = (I4., Den_furn, Cod_fiscal)
Tip cheltuială = (I.., Den_chelt)
Cheltuieli = (I4, I., , Valoare)
D % % Î$2%Î
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ă.
#($3$ Dacă atributele A, B, C sunt în relaţiile A B şi B C,
atunci spunem că atributul C este dependent tranzitiv de atributul A, via B.
Î$2%Î 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.
D % ) Î$9,Î
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.
Î $ 9, Î). 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
77
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.

Î$Î
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ă.
Î$ Î
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.
Î$2%Î
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.
Î$9,Î
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.
'#3
1) Aduceţi la forma normală 1 urmărtoarea tabelă:
Relaţia Furnizori_Cheltuieli:
78
H
Î 4 . .$
F100 Romgaz R134567 1 C15 Chelt pt. Încălzire 1500000
C16 Chelt pt. Bucătării 500000
F110 Renel R765431 3 C10 Chelt cu iluminatul 3000000
4 C11 Chelt pt. Func. liftului 00000
) Aduceţi la forma normală 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)
#'$
1) Fie tabela din enunţ:
H
Î 4 . .$
C16 Chelt pt. Bucătării 500000
4 C11 Chelt pt. Func. liftului 00000
Î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.
H
Î 4 . .$
F100 Romgaz R134567 C16 Chelt pt. Bucătării 500000
F110 Renel R765431 4 C11 Chelt pt. Func. liftului 00000
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:
79
) 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ă
d Cod Furn (Denumire, Cod fiscal)
Dependenţele d1 şi d 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 şi

c_carte cod_domeniu deci den_domeniu depinde tranzitiv de cheie.
Prin descompunere rezultă două scheme 3NF:
carte1 = (c_carte, titlu, cod_domeniu) şi
domeniu = (cod_domeniu, den_domeniu).

#[
.#'(
[ !&#'(
Î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?
80
´ 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 , pentru proiectarea bazei de
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´.
'

[ 1.1. Ce este o metodologie de proiectare?

Definiţie: !&#: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.
[ 1. Proiectarea logică şi fizică a bazei de date

Definiţie: &$: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: 4$: 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.
(

Î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. &$ ' (:
Crearea unui model conceptual local, pentru vederile utilizatorilor.
Pasul 1.1.Identificarea tipurilor de entităţi.
81
Pasul 1..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 .Crearea şi validarea modelului logic local.
Pasul .1.Proiectarea modelului conceptual local pe un model logic
local.
Pasul ..Crearea relaţiilor pentru modelul logic local.
Pasul .3.Validarea modelului, utilizând normalizarea.
Pasul .4.Validarea modelului din nou, utilizând tranzacţiile.
Pasul .5.Desenarea diagramei ER.
Pasul .6.Definirea regulilor de integritate a bazei de date.
Pasul .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..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. 4$ " # ' (:
Translatarea modelului logic global în SGBD.
Pasul 4.1.Proiectarea relaţiilor de bază în SGBD.
Pasul 4..Crearea regulilor de integritate în SGBD.
Pasul 5.Proiectarea şi implementarea reprezentării fizice.
Pasul 5.1.Analizarea tranzacţiilor.
Pasul 5..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..Proiectarea regulilor de acces la baza de date.
8
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.
4 ÷ ÷ #
´ 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.
O

În acest capitol vom prezenta pas cu pas, proiectarea unei baze de date.
#6#
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 primare
Paşii din prima etapă a proiectării logice sunt:
´ Pasul 1.1. Identificarea tipurilor de entităţi.
´ Pasul 1.. 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.
83
´ 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.
÷// ÷
Obiectivul: Identificarea tipurilor de entităţi principale în vederile
utilizatorilor.
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.
÷
După 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.
÷/ ÷÷
Obiectivul: 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 ë Locatari
´ Furnizorii 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.
÷ ÷ ÷÷
După 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ă.
84
÷÷
După identificarea tipurilor de relaţii, le denumim şi le introducem în
dicţionarul de date, împreună cu cardinalitatea şi participarea lor.
5 ÷
÷ "
Pentru 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.
÷/. ÷ ÷
÷÷
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: * 6+ Răspunsul la
această întrebare ne va da atributele căutate.
÷
Este 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.
%÷÷&
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.
÷
După identificarea atributelor, le asociem un nume, şi le înregistrăm în
dicţionarul de date, împreună cu următoarele informaţii:
85
´ 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.
÷/7 ÷ ÷
Obiectivul: 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.
÷ ÷
Actualizăm dicţionarul de date cu domeniul de definiţie al fiecărui
atribut.
÷ /( ÷ ' ÷

Obiectivul: Identificarea cheilor candidat pentru fiecare entitate
şi alegerea cheilor primare în cazul în care sunt mai multe chei candidat.
' ÷ ÷' ÷
O 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
86
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.
' ÷ ÷
Înscriem cheile primare şi pe cele alternante în dicţionarul de date.
÷ /8 ÷
÷
÷ %
÷&
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
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ă.
÷/0 "
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.
÷ /9 : ÷÷ ÷ ÷÷ ÷
÷
÷
Obiectivul: 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.
"3&
Obiectivul: 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:
87
´ Pasul .1. Proiectarea modelului conceptual local pe un model logic local.
´ Pasul .. Crearea relaţiilor pentru modelul logic local.
´ Pasul .3. Validarea modelului, utilizând normalizarea.
´ Pasul .. Validarea modelului din nou, utilizând tranzacţiile.
´ Pasul .5. Desenarea diagramei ER.
´ Pasul .6. Definirea regulilor de integritate ale bazei de date.
´ Pasul .7. Verificarea modelului logic local cu ajutorul utilizatorului.
÷ .1. ÷÷ ÷ ÷÷ ÷÷ ÷
÷÷
Obiectivul: Verificarea modelului conceptual local pentru eliminarea
structurilor care se pot implementa greu într-un SGBD şi proiectarea
modelului rezultat la modelul logic local.
Î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.
() 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.
%/&÷ ÷ ÷÷÷÷
Dacă î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).
88
ë

Ô

ë

ë
ë

Ô

ë

ë

Ô

ë

Î& [ (a). Relaţie de tipul N:M. (b). Relaţie transfornamtă în două
relaţii 1:M.
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 [ (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.
%-&÷ ÷ ÷÷
O 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.
%.&÷ ÷ ÷
Relaţ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.
%7&÷ ÷ ÷
89
Dacă î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.
%(&" ÷ ÷ ÷/#/
Î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.
%8&÷ ÷ ÷
O 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 &
.
÷*÷ ÷÷÷ ÷÷
Obiectivul: 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
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.
à
Pentru 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 [ se descrie
în următorul mod.
Î(Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers,
Nr_pers_prezente, Nr_chei)
.#$: Nr_mat
90

Î&[ Exemplu de model
logic.
à ÷ ÷
Descrierea 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:
$( (Data, Nr_mat, Valoare, Restanţă)
.#$:Data, Nr_mat
.$$: Nr_mat 4$ 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.
à ÷÷ ÷÷%/#/&
Pentru fiecare tip de relaţie binară de tipul 1:1 între două tipuri de
entitate E1 şi E găsim o copie a cheii primare a tipului de entitate E1 în
compunerea tipului de entitate E, 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.
à ÷÷ ÷÷÷/#;
Pentru toate relaţiile 1:M între două entităţi E1 şi E în modelul logic
de date, vom avea copia cheii primare a entităţii E1 în compunerea entităţii E.
Totdeauna entitatea de partea unu a relaţiei este considerată entitate ³părinte´,
iar cealaltă entitate ³fiu´.
÷ ÷÷
91
Pentru 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.
"÷ ÷÷÷
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)
* (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume,
Data_intrare_func, Nr_pers, Nr_pers_prez, Nr_chei)
.#$:Nr_mat
(Opţiunea )
Î (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume,
Nr_pers, Nr_pers_prez, Nr_chei)
.#$: Nr_mat
N4II$(Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume,
Data_intrare_func)
.#$: Nr_mat
Î&[ % Exemplu de relatie superclasă/subclasă
÷ ÷ ÷ ' ÷

Actualizăm dicţionarul de date, întroducând fiacare atribut nou introdus
în compunerea unei chei la acest pas.
9
÷.3.:÷ ÷
÷

Obiectivul: Validarea modelului logic, utilizând tehnica normalizării.

Examinăm procesul de normalizare după cum am descris în capitolul D
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 D
´ 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.
÷..:÷ ÷÷

Obiectivul: 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 [ %
93
Î& [ % Exemplu de relaţie

pentru validarea prin tranzacţii.

Ô

ë

Ô
ë

÷

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

Se 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.
÷.5 "
Obiectivul: Desenarea diagramei Entity-Relationship, care este
reprezentarea logică a vederilor utilizatorilor aspra întreprinderii.
÷.6. ÷ ÷
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.
^ ÷
94
Există atribute care nu pot conţine valoarea nulă, ci trebuie să aibă
totdeauna o valoare. De exemplu fiecare cheltuială înregistrată trebuie să aibă
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.
"÷ ÷ ÷
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..
÷
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.
÷
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:
*
÷/# ÷ = >%*'÷ ÷ &#
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.
*
÷-#< ÷ = >%*'÷ ÷ &#
Ştergerea unei entităţi din tipul de entitate ³fiu´ nu creează probleme la
integritatea referinţelor.
*
÷ .# ÷
' ÷ = >
%*'÷ ÷ &#Acest caz este similar cazului 1.
*
÷ 7# ÷ = >
%4
&# 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
95
entitate ³fiu´, care se referă la entitatea ştearsă. Există strategii severe de a
rezolva integritatea referinţelor:
´ 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.
*
÷ 8# ; ' ÷
%4
&# 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Ă.
"÷ ÷
În final evidenţiem acele reguli care sunt date de realitatea ce se va
modela în baza de date.
÷ ÷
Trecem toate regulile de integritate în dicţionarul de date.
÷.7.: ÷÷ ÷ ÷÷÷ ÷
÷
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.
÷3.* ÷ ÷÷ ÷÷÷
Obiectivul: Combinarea modelelor locale logice într-un model logic
global care să reprezinte întreprinderea care este modelată.
96
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
normalizare şi după aceea, prin tehnica tranzacţiilor. Acest proces utilizează
aceleaşi tehnici pe care le-am descris la paşii .3. şi ..
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.. Validarea modelului logic global.
´ Pasul 3.3. Verificarea posibilităţii de a completa baza de date în viitor.
´ Pasul 3.. Desenarea diagramei ER finale.
´ Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.
÷ 3.1. * ÷÷ ÷ ÷÷ ÷ ÷
÷÷
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.
() 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.
%/&: ÷ ÷ ' ÷÷
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.
97
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.
%-&: ÷÷ ÷
Această activitate este asemănătoare celei descrise la entităţi.
%.&* ÷ ? ÷÷÷
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.
* ÷ ÷ ÷ '
Î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.
* ÷ ÷ '
Î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.
* ÷ ÷ '
Aceste entităţi se pot depista prin analiza atributelor celor două
entităţi.
%7&÷ % & ÷
?
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.
%(&*÷ ÷÷÷÷÷
Î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.
%8&÷ % & ÷ ÷
?
Relaţile care au rămas neincluse în modelul global după pasul anterior,
se includ în modelul global fără modificare.
%0&* ÷ ÷ ÷÷
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.
%9&*' ÷
98
Î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.
%@&*÷ ÷
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.
%/)& "
Acum desenăm diagrama ER pentru modelul global de date.
%//& ÷

Actualizăm documentaţia, ca să reflecte toate modificările aduse în
acest pas modelului.
÷.-:÷ ÷÷ ÷ ÷÷
Obiectivul: Validarea modelului global logic de date, folosind
normalizarea, după care folosind tranzacţile cerute.
Acest pas este schivalent cu paşii 3. şi ) , unde am validat modelul
local de date.
÷ .. : ÷ ÷

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.
÷.7
"÷ ' ÷
Obiectivul: Desenarea unei diagrame ER, care să reprezinte modelul
global de date al întreprinderii.
÷.(: ÷÷ ÷÷÷ ÷
÷
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ă.
[ &$',8#
Î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´.
99
[ (
Analiza şi colectarea datelor îl vom începe la o asociaţie de locatari.
Aici trebuie să cerem informaţiile necesare pentru realizarea sistemului.
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´.
[ ('
3("#(:
(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.
() 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.
3(.
(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.
() 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.
100
(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
ş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.
3(#(
(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ă.
() Un angajat poate să lucreze în mai multe scări şi pe o scară pot să lucreze
mai mulţi angajati.
3(+48"'3
(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.
($4
(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.
[ 2(
3("#(:
(1) Listă cu locatarii de pe o scară,
() Listă cu familiile de pe o scară,
(3) Listă cu şefii de scară,
(4) Listă cu proprietăţile apartamentelor ocupate pe o scară.
3(.
(1) Listă cu cheltuielile fiecărei familii pe scări,
() Listă cu toate cheltuielile asociaţiei de locatari.
(3) Chitanţa care se emite la fiecare plată.
3(#(
(1) Listă cu personalul asociaţiei.
3(+48"'3
(1) Listă cu mijloacele fixe şi valoarea lor, din asociaţia de loacatari,
101
() Listă cu obiectele de inventar ai asociaţiei de locatari.
($4
(1) Listă cu facturile scadente primite de la furnizori,
() Situaţia plăţilor facturilor de la furnizori, înglobând facturile dintr-o
perioadă dată, împreună cu modul lor de plată.
[ % & # '

(
#6'#37,
:
Î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,
´ 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.
÷// ÷
Î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ă Apartamente
Familii
În cazul evidenţei plăţilor tipurile de entităţi sunt:
Cheltuieli Furnizori
Plăţi Chitanţe
Familii Scări
÷
Î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..1.
÷1.. ÷÷
Î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:
10
Tipuri de relaţii din view-ul ³Locatari´:
Tip de entitate Tip de relaţie Tip de entitate
Scări sunt locuite de Locatari
sunt locuite de Familii
sunt 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 entitate
Furnizorii provoacă Cheltuieli
Celtuieli sunt plătite de Familii
sunt plătite de Scări
Familii trebuie să plătească Plăţi
primesc Chitanţe
Dacă la acest pas apar ambiguităţi, ele trebuie neapărat clarificate cu
utilizatorii.
÷ ÷÷
Î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 ;; Î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 ÷ Locatari are cardinalul 1:M. În
continuare va trebui să aflăm şi cardinalul relaţiei inverse, adică a relaţiei
Locatarii ÷ 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.
103
Deci tipul de entitate scări partcipă parţial, iar tipul de entitate Locatari
participă total la relaţie.
Fie relaţia Cheltuieli ÷ Scări, din view-ul ³Cheltuieli´. Să
determinăm cardinalul şi participarea ei:
Î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.
5 ÷
÷ "
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 [ % 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ă.
÷÷

Documantarea view-urilor care apar în figura 6.3.1. este realizată în
anexa 6..3.
ë ë

ë
ë

ë
ë

Î&[ % Diagrama ER. a view-ului ³Locatari´.
104
ë
ë
ë

ë

Î&[ % ' Diagrama ER a view-ului ³Cheltuieli´
÷/. ÷÷ ÷÷
÷
Î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..a. şi 6.3..b.
2'[ % Atributele tipurilor de entităţi din view-ul ³Locatari´:
2# '
Locatari Nr_Mat
Adresa (Nr_bloc, Scara, Etaj, Apartament)
Nume
Familii Nr_Mat
Nume
Nr_pers
Nr_pers_prez
Nr_chei
Sef_Scara Nr_Mat
Nume
Data_intrare_func
Scări Adresa (Nr_bloc, Scara)
Lift
Apartamente Apartament
Suprafaţa
Cutii_poştale
Nr_prize_tv
105
2'[ % ' Atributele tipurilor de entităţi din view-ul ³Cheltuieli´:
2# '
Familii Nr_mat
Fond_rulment
Fond_reparaţii
Alte_fonduri
Plăţi Data
Valoare
Restanţă
Chitanţe Nr_Chit
Valoare
Data
Cheltuieli Nr_crt
Cod_cheltuiala
Nr_factura
Data_factura
Valoare
Furnizori Cod_furnizor
Denumire
Cod_fiscal
Cont
Banca
Adresa (Strada, Nr., Bl., Sc., Ap., Localitate, Jud)
÷#
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..
÷/ ÷ ÷#
Î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.
÷
Câteva din domeniile exemplului nostru sunt arătate în anexa 6.3..
÷ /( ÷ ' ÷
#
Acum vom examina tabelele 6...a. şi 6...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.. Menţionăm, că în acest pas nu
asociem chei primare entităţilor slabe, acesastă operaţie fiind rezolvată în pasul
..
' ÷ ÷
106
Documentăm atributele care compun cheile primare şi cheile
alternante. Un exemplu de documentare găsiţi în anexa 6.3..
÷ /8 ÷
÷
÷ %
÷&
Î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.

Î&[ % % Exemplu
de relţie superclasă - subclasă

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..a., respectiv 6.3..b.
÷ /9 : ÷÷ ÷ ÷÷ ÷
÷
÷
Î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.
ë

ë
ë
ë

Î&[ % Modelul conceptual local al view-ului ³Locatari´
107
ë
ë

ë
Î&[ % ' Modelul conceptual local al view-ului ³Cheltuieli´.

÷..* ÷ ÷÷ ÷÷
Î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.
÷ .1. ÷÷ ÷÷ ÷ ÷÷ ÷÷
÷
Î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.
()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.
%/&÷ ÷ ÷ ÷^#;
Cum putem observa şi în figura 6...b., relaţiile Cheltuieli ÷
Familii şi Cheltuieli ÷ 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 ÷÷
şi '÷ ÷ . 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.
108
Î&[ % D View-ul ³Cheltuieli´, după eliminarea relaţiilor N:M.
%-&÷ ÷ ÷÷
Î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ă.
%.&÷ ÷ ÷
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.
%7&÷ ÷ ÷
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.
%(&" ÷ ÷ ÷/#/
Î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.
%8&÷ ÷ ÷
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.
"
Modelul conceptual care este reprezentat în figura 6..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.
109
ë

ë
ë
ë

Î&[ % [ Modelul logic local al view-ului ³Locatari´.
ë

ë

ë

Î&[ % [ ' Modelul logic local al view-ului ³Cheltuieli´.

÷..*÷ ÷÷÷ ÷÷
Î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
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:
Î (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str.,
Bl., Sc.,
Ap., Loc., Jud.)
.#$: Cod_furnizor
Pentru 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:
. (Nr_crt, Cod_furnizor, Cod_cheltuială, Nr_factură,
Data_factură,
Valoare)
.#$: Nr_crt
.$$: Cod_furnizor
110
Acest proces continuă, până când se vor prelucra toade relaţiile din
baza de date.
÷ ÷ ÷ ' ÷
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.
÷.3.:÷ ÷÷ ÷

În acest pas validăm baza de date prin normalizare. Procesul de
normalizare este descris amănunţit în capitolul )
´ Forma Normală Unu (1NF), eliminarea repetiţiilor din atribute.
´ Forma Normală Doi (NF), 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
Cheltuieli, descrisă în anexa 6.3.5. Menţionăm că notaţiile de aici nu
includ cheia străină.
Î (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str, Nr, Bl, Sc,
Ap,
Loc, Jud)
.#$: Cod_furnizor
.$: Cod_fiscal
Cod_furnizor Denumire, Cod_fiscal, Cont, Banca, Str, Nr, Bl, Sc, Ap, Loc,
Jud
Cod_fiscal Cod_furnizor, Denumire, Cont, Banca, Str, Nr, Bl, Sc, Ap, Loc,
Jud
. (Nr_crt, Cod_furnizor, Cod_cheltuială, Nr_factură, Data_factură,
Valoare)
.#$: Nr_crt
Nr_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.
111
Acest proces se continuă pentru fiecare relaţie care apare în anexa
6.3.5.
÷..:÷ ÷÷
÷
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:
"4â&$.
´ 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 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..1.. sunt reprezentate prin diagramele din figurile 6.3.7.a. respectiv 6.3.7.b.
T 1. ë

Î&[ % /
Diagrama tranzacţiilor cerute la
T 4.
T 3. ë
view-ul ³Locatari´.
T .
ë
ë

11
ë

T .
ë

T 3.
T 1.

T .

ë

Î&[ % / ' Tranzacţiile cerute pentru view-ul ³Cheltuieli´.

÷.5. "
Diagrama ER din figura 6..7.a. şi 6..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ă.
÷.6. ÷ ÷
Î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,
´ integritatea entităţilor,
´ integritatea relaţiilor,
´ reguli date de intreprindere.
^ ÷
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..
÷ ÷
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.. şi sunt documentate în
anexa 6.3..
÷
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.
÷ ÷
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,
113
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
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 Apartamente cu limbajul DDL:
$ (Nr_bloc, Scara, Lift)
.#$: Nr_bloc, Scara
# (Nr_bloc, Scara, Apartament, Suprafaţa, Cutii_poştale,
Nr_prize_tv)
.#$: Nr_bloc, Scara, Apartament
.$$: Nr_bloc, Scara $ 4, 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.
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 Apartamente,
extinzând în continuare limbajul DBDL.
.#$: Nr_bloc, Scara
Nr_prize_tv)
.$$: Nr_bloc, Scara $6$6
4, Scări (Nr_bloc, Scara)
Această operaţie se execută pentru fiecare relaţie descrisă în anexa
6.3.5.
"÷ ÷
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.
114
÷ ÷
Toate cele descrise mai sus se documentează în modelul de date.
÷.7."
÷÷ ÷ ÷
÷
Î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.
÷3. * ÷ ÷÷ ÷÷
Î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.
÷./*÷÷÷÷÷÷÷÷
Î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:
%/&"
÷ ÷ ' ÷÷
Comparăm numele şi cheile primare dintre două modele locale,
comparaţie ce este prezentată în tabela [ % 8.
2# .#$ 2# .#$
37,* 37,
.
Scări Nr_bloc, Scară Scări Nr_bloc, Scară
Familii Nr_mat Familii Nr_mat
Locatari Nr_mat
Şef de scară Nr_mat
Apartamente Nr_bloc, Scara, Ap.
Plăţi Data, Nr_mat
Chitanţe Nr_chit
Pe_familii Nr_crt
Pe_scări Nr_crt
Cheltuieli Nr_crt
Furnizori Cod_furnizor
2'[ % 0 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.
%-&"
÷÷ ÷
Î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ă.
115
2# 2# 2# 2# 2#( 2#
( 37, 37, 37,
37, * . .
*
Scări ÷ Locatari Scări '÷ ÷ Pe_scări
Apartamente
Familii '÷ ÷ Pe_familii
à Plăţi
÷
Chitanţe
Cheltuieli ÷÷
Pe_familii
÷÷
Pe_scări
Furnizori Cheltuieli
2'[ % 1 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ă´.
%.&* ÷ ÷÷
Î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.
* ÷÷ ÷ '
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.
* ÷÷ '
Î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
116
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.
* ÷ ' ÷

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ă.
Î&[ Exemplu de compunere a două entităţi.
37,*
Î (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)
.#$: Nr_mat
.$$: Nr_mat 4, Locatari (Nr_mat)
37,.
Î (Nr_mat, Fond_rulment, Fond_reparaţii, Alte_fonduri)
.#$: Nr_mat
È
(modelul global)
Î (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei, Fond_rulment,
Fond_reparaţii,
Alte_fonduri)
.#$: Nr_mat
.$$: Nr_mat 4, Locatari (Nr_mat)
%7&÷ % & ÷ ÷
÷
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.
%(&* ÷÷ ÷÷÷÷
Î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 [ 9.
*÷ ÷÷ ÷
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).
*÷ ÷ ÷
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ă
117
aceleaşi entităţi. Şi în acest caz trebuie rezolvată problema cardinalului şi a
participării.
%8&÷ % & ÷ ÷ ÷
÷
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 [ % 9. sunt de
acest tip.
%0&: ÷
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.
%9&: ' ÷
Î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.
%@&: ÷ ÷
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.
%/)& ÷÷ ÷÷
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.
%//&*÷
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.
118
ë

ë

ë

ë

ë
ë
ë

ë

Î&[ % Diagrama globală şi finală ER.

÷3.:÷ ÷÷ ÷÷
Î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.
÷3.3.: ÷
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.
÷3.4 " ÷
La acest pas observăm că nu am modificat nimic de la ultima diagramă
desenată, deci diagrama ER finală este diagrama din figura [ % 11.
÷3.5.: ÷÷ ÷÷÷ ÷
÷
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.
8[ %
Documentarea tipurilor de entităţi în view-urile Locatari şi Cheltuieli
Tipurile de entităţi din view-ul ³Locatari´:
# $(

Locatari Oamenii care locuiesc în Persoanele care au domiciliul
asociaţie în asociaţie
Familii Familiile din asociaţie Cap_familie Câte o persoană din fiecare
119
familie, considerată
reprezentantul acesteia
Sef_Scara Persoana care se ocupă Câte o persoană de pe fiecare
cu problemele unei scări. 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 Fiecare apartament din
asociaţie asociaţie, împreună cu
caracteristicile ei.
Tipurile de entităţi din view-ul ³Cheltuieli´:

# $(

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 Fiecare furnizor cu care s-a
facturile lucrat vreodată în asociaţie
Cheltuieli Cheltuielile asociaţiei Fiecare factură, care
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.

8[ %
Documentarea atributelor
Atributele tipurilor de entităţi din view-ul ³Locatari´:
2# ' 2# "
&
&
Locatari Nr_Mat Det. unic locatarii Întreg Cheie primară
Etaj Etajul la care loc. Întreg [-1,100]
Apartament Apartamentul Întreg
Nume Numele locatarului 5 de caractere
Familii Ca la Locatari, Ca la Locatari Ca la Locatari
plus plus
Nr_pers Nr. pers. în familie Întreg
Nr_pers_prez Nr. pers. prezente în Întreg
luna curentă
Nr_chei Nr. de chei de la uşa Întreg
principală
Sef_Scara Ca la Locatari Ca la Locatari Ca la Locatari
plus plus
DataIntrFunc Data intrării în func Dată
10
Scări Adresa (Nr_bloc, Scara) Cheie primară
Lift Există sau nu lift Logic
Apartamente Apartament Apartamentul Întreg
Suprafaţa Sup. totală a ap. Real
Cutii_poştale Nr. cutii poştale Întreg
Nr_prize_tv Nr. prize tv. Întreg
Atributele tipurilor de entităţi din view-ul ³Cheltuieli´:
2# ' 2# "
&
&
Familii Nr_mat Identifică familia Întreg Cheie primară
Fond_rulment Fond de rulment Real
Fond_reparaţii Fond de reparaţii Real
Alte_fonduri Alte fonduri Real
Plăţi Data Luna pt. care e plata Dată
Valoare Suma de plată Real
Restanţă Suma restantă Real
Chitanţe Nr_chit Id. unic chitanţa Întreg Cheie primară
Valoare Valoarea plătită Real
Data Data plăţii Dată
Cheltuieli Nr_crt Identifică cheltuiala Întreg Cheie primară
Cod_cheltuiala Tipul cheltuielii Întreg
Nr_factura Numărul facturii Întreg
Data_factura Data facturii Dată
Valoare Valoarea cheltuialii Real
Furnizori Cod_furnizor Identifică furnizorul Întreg Cheie primară
Denumire Numele societăţii 30 de caractere
Cod_fiscal Codul fiscal 10 caractere Cheie alt.
Cont Contul bancar 5 de caractere
Banca Banca 0 de caractere
Adresa Str,Nr,Bl,Sc,Ap,Loc
8[ % %
Documentarea tipurilor de relaţii din view-urile ³Locatari´ şi ³Cheltuieli´
Tipuri de relaţii din view-ul ³Locatari´:
2# 2#( 2# #B

Scări sunt locuite de Locatari 1:M P:T
sunt locuite de Familii 1:M P:T
sunt conduse de Şef de scară 1:M P:T
se compun din Apartamente 1:M T:T
Tipuri de relaţii din view-ul ³Cheltuieli´:
2# 2#( 2# #B

Furnizorii provoacă Cheltuieli 1:M P:T
Celtuieli sunt plătite de Familii M:N P:P
11
sunt plătite de Scări M:N P:P
Familii trebuie să plătească Plăţi 1:M T:T
primesc Chitanţe 1:M P:T
* P=parţial, T=total.
8[ % )
Documentarea domeniilor atributelor
8#
Etaj Întreg între -1 şi 100 0=Parter
String30 30 de caractere, lungime variabilă ROMGAZ
String10 10 caractere, lungime variabilă
String0 0 de caractere, lungime variabilă
8[ % D
Descrierea relaţiilor din view-urile ³Locatari´ şi ³Cheltuieli´
Descrierea relaţiilor din view-ul ³Locatari´.
* (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers,
Nr_pers_prez,
Nr_chei, Data_intrare_func)
.#$: Nr_mat
.$$: Nr_bloc, Scara 4, Scări (Nr_bloc, Scara)
.#$: Nr_bloc, Scara
Nr_prize_tv)
.$$: Nr_bloc, Scara 4, Scări (Nr_bloc,
Scara)
Descrierea relaţiilor din view-ul ³Cheltuieli´:
$ (Nr_bloc, Scara)
.#$: Nr_bloc, Scara
Î (Nr_mat, Fond_rulment, Fond_reparaţii, Alte_fonduri)
.#$: Nr_mat
.#$: Data, Nr_mat
.$$: Nr_mat 4, Familii (Nr_mat)
.( (Nr_chit, Nr_mat, Valoare, Data)
.#$: Nr_chit
.$$: Nr_mat 4, Familii (Nr_mat)
Î (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str, Nr, Bl, Sc,
Ap,
Loc, Jud)
.#$: Cod_furnizor
.$: Cod_fiscal
Valoare)
1
.#$: Nr_crt
.$$: Cod_furnizor 4, Furnizori (Cod_furnizor)
I4 (Nr_crt, Nr_mat)
.#$: Nr_crt
.$$: Nr_crt 4, Cheltuieli (Nr_crt)
.$$: Nr_mat 4, Familii(Nr_mat)
I$ (Nr_crt, Nr_bloc, Scara)
.#$: Nr_crt
.$$: Nr_crt 4, Cheltuieli
(Nr_crt)
.$$: Nr_bloc, Scara 4, Scări (Nr_bloc,
Scara)
8[ % [
Regulile date de întreprindere în cazul modelului ³Locatari´ şi ³Cheltuieli´
(1)Lista de plăţi se elaborează doar pe o lună întreagă.
()Fiecare familie trebuie să declare la începutul lunii dacă va lipsii un
membru al familiei toată luna.
(3)Nici o familie nu va putea să se mute până când nu si-a plătit toate
datoriile.
8[ % /
Modelul global de date al sistemului Asociaţia de Locatari
* (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume)
.#$: Nr_mat
. $$ : Nr_bloc, Scara $6 4, Scări (Nr_bloc,
Scara)
la ştergere şi la modificare $
Î (Nr_mat, Nr_pers, Nr_pers_prezente, Nr_chei, Fond_rulment,
Fond_reparaţii, Alte_fonduri)
.#$: Nr_mat
.$$: Nr_mat $64, Locatari (Nr_mat)
la ştergere şi modificare $
N4II$ (Nr_mat, Data_intrare_func)
.#$: Nr_mat
.$$: Nr_mat $6 4, Locatari (Nr_mat)
.#$: Nr_bloc, Scara
Nr_prize_tv)
.$$: Nr_bloc, Scara $64, Scări (Nr_bloc,
Scara)
13
.#$: Data, Nr_mat
.$$: Nr_mat $64, Familii (Nr_mat)
la ştergere Î$$(, la modificare $
.( (Nr_chit, Nr_mat, Valoare, Data)
.#$: Nr_chit
.$$: Nr_mat $64, Familii (Nr_mat)
Î (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Strada, Nr, Bl,
Sc,
Ap, Localitate, Judet)
.#$: Cod_furnizor
.$: Cod_fiscal
Valoare_factură)
.#$: Nr_crt
.$$: Cod_furnizor $6 4, Furnizori
(Cod_furnizor)
I4 (Nr_crt, Nr_mat)
.#$: Nr_crt
.$$: Nr_crt $64, Cheltuieli (Nr_crt)
.$$: Nr_mat $64, Familii(Nr_mat)
I$ (Nr_crt, Nr_bloc, Scara)
.#$: Nr_crt
.$$: Nr_crt $64, Cheltuieli (Nr_crt)
.$$: Nr_bloc, Scara $6 4, Scări (Nr_bloc,
Scara)
(Nr_matricol, Nume, Data_naşterii, Meseria, Data_angajării)
.#$: Nr_matricol
(Nr_matricol, Nr_bloc, Scara)
.#$: Nr_matricol, Nr_bloc, Scara
.$$:Nr_matricol $64,Personal (Nr_matricol)
Scara)
(Nr_inventar, Nr_bloc, Scara, Denumire, Inv_fix, Valoare)
.#$: Nr_inventar
Scara)
.$ (Nr_crt, Nr_doc, Tip_op, Valoare_achit, Data)
14
.#$:Nr_Doc, Tip_Op
.$$:Nr_crt $64,Cheltuieli (Nr_crt)

#/
'
/ $(
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
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 DB.
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
15
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
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
16
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.
- 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.
/ Î".
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
17
- 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
- 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.
18
Schema Schema
externa externa
globala globala
Schema
conceptuala
globala
Schema de
fragmentare
Schema de alocare
Schema locala
de mapare
Schema
conceptuala
locala
Schema
interna locala
Fig.7.1. Arhitectura ANSI-SPARC pe trei nivele
19
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)
/ % '('
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.
130
/ )
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
, 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.
. 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
131
- modul de lucru al tranzactiilor executate de aplicaţie şi tipurile de acces
la date
- etc.
/ ) Î&
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, R,
«,Rn, trebuie luate măsuri care să prevină pierderea de informaţii
. 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ă
Î&#$:
Ne putem imagina că o tabelă se fragmentează orizontal ca mai jos:
13
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= R1MRM«MRn
In general fragmentele unei relaţii R sunt disjuncte.
Î&#3$
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ă S1aR şi SaR atunci 1 Ú 1 ( " ) şi Ú ( ") .
Completitudinea este asigurată prin faptul că fiecare atribut apare cel puţin
într- una din submulţimile S1 şi S.
Reconstrucţia relaţiei iniţilale se realizează prin joncţiune naturală.
( " ) Ú 1 A ^
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ă.
Î&'$8$6.'$6#$
1. fragmente verticale fragmentate orizontal
133
Expresia corespunzatoare în algebra relaţională (pentru fiecare dreptunghi din
figura de mai sus) este: C ( B1 ,..., B ( R ))
. fragmente orizontale fragmentate vertical
Expresia corespunzătoare în algebra relaţională (pentru fiecare dreptunghi din

figura de mai sus) este: 1 ,..., (A ( " ))
/ D 2#â
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
. transparenţa tranzacţiilor
3. transparenţa performanţelor
/ D 2#'
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.
134
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.
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)
. 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 /÷ .- se poate desemna copia a doua a
fragmentului 3 a tabelei ÷ care se afla pe site-ul /.
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 ÷ -uri. De exemplu /÷ .-
poate avea ca alias numele ÷ $÷÷ pentru utilizatorii site-ului /.
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 f1
where /
union
select A1,«An
from f
«««
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.
/ D 2#((
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
135
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.
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).
/ D % 2#(#4(
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.
'$#3
1) Ce este o bază de date distribuită?
) 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?
136
11) Ce este transparenţa performanţelor?
$#â'$
1) 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ă.
) 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.
137
3) Schema Schema
externa externa
globala globala
Schema
conceptuala
globala
Schema de
fragmentare
Schema de alocare
Schema locala
de mapare
Schema
conceptuala
locala
Schema
interna locala
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
138
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
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
, 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.
a. 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
139
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, R,
«,Rn, trebuie luate măsuri care să prevină pierderea de informaţii
- 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ă
Î&#$:
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= R1MRM«MRn
In general fragmentele unei relaţii R sunt disjuncte.
Î&#3$
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.
140
Un fragment vertical se produce prin proiecţie:
Dacă S1aR şi SaR atunci 1 Ú 1 ( " ) şi Ú ( R) .
Completitudinea este asigurată prin faptul că fiecare atribut apare cel puţin
într- una din submulţimile S1 şi S.
Reconstrucţia relaţiei iniţilale se realizează prin joncţiune naturală.

( R ) Ú 1 D
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).
Î&'$8$6.'$6#$
Se poate face din fragmente verticale fragmentate orizontal:
Expresia corespunzatoare în algebra relaţională (pentru fiecare dreptunghi din

figura de mai sus) este: A ( 1 ,..., ( " ))
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: 1 ,..., (A ( " )) .
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.
141
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.
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.

14
#0
"&

0 &
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
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
143
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
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
se permite efectuarea operatiei
) valoarea cheii primare apare in alta parte ca şi cheie externa

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
144
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
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()

check is_integer(ZI) and num(ZI) >= 1 and num(ZI) <= 31;
create domain LUNA char()
check is_integer(LUNA) and num(LUNA) >= 1 and
num(LUNA) <= 1;
create domain AN char()
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,1) then num(ZZ) < 31;
check if num(LL) in (4,6,9,11) then num(ZZ) < 30;
check if num(LL) = and mod(num(AA),4) = 0 and
mod(num(AA),100) <> 0 then num(ZZ) < 9;
check if num(LL) = and mod(num(AA),4) <> 0
then num(ZZ) < 8;
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.
145
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.
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.001" sau "01.01.001", 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
146
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
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.
0
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:
147
-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
-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.
. 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:
148
-autorizare la citire (consultare)
-autorizare la inserare (adaugare)
-autorizare la actualizare (care exclude stergerile)
-autorizare la stergeri (la nivel de tuplu)
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
149
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.
'#3
1) Care sunt restricţiile de integritate?
) 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.

$#â'$
1) Restricţiile de integritate
- integritatea entitatii
- integritatea referentiala
- restrictiile de domeniu
- restricţiile de intreprindere
) 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,
150
-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;
-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.

#1
2("($

Î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ţiei
151
1 2(
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 &$ de lucru a bazei de date. Nu există
reguli de stabilire automată a acestei unităţi. Pentru a demonstra acest concept
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) cit (nrmat =x )

salariu = salariu * 1,1 şterge (nrmat = x )
scrie (nrmat = x, salariu) pentru toate înregistrările din
Proprietate
care măreşte salariul cu 10% 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ă
2
2 6!! 26
**Q.
15
1 #$((
Deşi nu avem reguli automate pentru construcţia tranzacţiilor ele trebuie să
respecte proprietăţile .
´ este proprietatea µtotul sau nimic¶. O tranzacţie este o unitate
indivizibilă care se execută în întregime sau deloc.
´ ($ o tranzacţie trebuie să transforme baza de date dintr-o formă
consistentă într-o altă formă tot consistentă.
´ #($ 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.
´ ' 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.
1 % (
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 . Concurenţa
va mări randamentul timpului de lucru al calculatorului dar ea trebuie
$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 T 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 #( 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 T balx
A t1 begin_transaction 100
A t begin_transaction cit(balx) 100
A t3 cit(balx) balx = balx + 10 100
A t4 balx = balx - 10 scrie(balx) 00
A t5 scrie(balx) commit 90
A t6 commit 90
Î&1
Problema se numeşte #'#$.

' #( ( $ 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.
153
Time T3 T4 balx
A t cit(balx) 100
A t3 balx = balx + 10 100
A t4 begin_transaction scrie(balx) 00
A t5 cit(balx) 00
A t6 balx = balx - 10 'R 100
A t7 scrie(balx) 190
A t8 commit 190
Î&1
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 #' sau problema
µ¶.
De exemplu tranzacţiile T5 şi T6 executate serial, adică una după alta, ar
trebui să dea rezultatele:
T5 T6 balx=100-10=90, balz=5+10=35, sum=90+5 0+35+175
sau T6 T5 sum=100+50+5=175, bal x=100-10=90, bal z=5+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 5
A t begin_transaction sum = 0 100 50 5 0
A t3 cit(balx) cit(balx) 100 50 5 0
A t4 balx = balx - sum = sum + 100 50 5 100
10 balx
A t5 scrie(balx) cit(baly) 90 50 5 100
A t6 cit(balz) sum = sum + 90 50 5 150
baly
A t7 balz = balz + 90 50 5 150
10
A t8 scrie(balz) 90 50 35 150
A t9 commit cit(balz) 90 50 35 150
A t10 sum = sum + 90 50 35 185
balz
A t11 commit 90 50 35 185
Î&1 %
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 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 când tranzacţiile sînt concurente , adică între
154
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 '. 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 ') sau de a ţine cont de momente (de a #).
Ce înseamnă să blocăm ? Când o tranzacţie '.$ #+
(part_bloc) o anumită unitate de memorie, o altă tranzacţir nu mai poate să rescrie
tot acolo, iar când o tranzacţie '.$83 (ex_bloc) o alta nu mai poate
nici să o citească.
Despre ce unitate de memorie este vorba? Aceasta este problema
&$( 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 înregistrare
Mai 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ă #'â
$4 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 şiT din figura 9.1 respectiv
T3 şi T4 din figura 9., şi T 5 şi T6 din figura 9.3 cu protocolul în două faze şi
realizează planuri serializabile.
Time T1 T balx
A t begin_transaction ex_bloc(balx) 100
A t3 ex_bloc(balx) cit(balx) 100
A t4 N2 2S balx = balx +100 100
A t5 N2 2S scrie(balx) 00
A t6 N2 2S debloc(balx) 00
A t7 cit(balx) commit 00
A t8 balx = balx -10 00
A t10 debloc(balx) 190
A t11 commit 190
Î&1 )
155
Time T3 T4 balx
A t ex_bloc(balx) 100
A t3 cit(balx) 100
A t4 begin_transaction balx = balx +100 100
A t5 ex_bloc(balx) scrie(balx) 00
A t6 N2 2S debloc(balx) 100
A t7 N2 2S 'R 100
A t8 cit(balx) 100
A t9 balx = balx -10 100
A t11 debloc(balx) 90
A t1 commit 90
Î&1 D
Time T5 T6 balx baly balz sum
A t1 begin_transaction 100 50 5
A t begin_transaction sum = 0 100 50 5 0
A t3 100 50 5 0
ex_bloc(balx)
A t4 cit(balx) part_bloc(balx) 100 50 5 0
A t5 balx = balx - AŞTEAPTĂ 100 50 5 0
10
A t6 scrie(balx) AŞTEAPTĂ 90 50 5 0
A t7 AŞTEAPTĂ 90 50 5 0
ex_bloc(balz)
A t8 cit(balz) AŞTEAPTĂ 90 50 5 0
A t9 balz = balz + AŞTEAPTĂ 90 50 5 0
10
A t10 scrie(balz) AŞTEAPTĂ 90 50 35 0
A t11 debloc(balx AŞTEAPTĂ 90 50 35 0
, balz)
A t1 commit AŞTEAPTĂ 90 50 35 0
A t13 cit(balx) 90 50 35 0
A t14 sum = sum + balx 90 50 35 90
A t15 part_bloc(baly) 90 50 35 90
A t16 cit(baly) 90 50 35 90
A t17 sum = sum + baly 90 50 35 140
A t18 part_bloc(balz) 90 50 35 140
A t19 cit(balz) 90 50 35 140
A t0 sum = sum + balz 90 50 35 175
A t1 90 50 35 175
debloc(balx,baly,balz)
A t commit 90 50 35 175
Î&1 [
156
Protocolul de blocare în două faze asigură serializanilitatea dar nu ne
scuteşte de probleme. Pezentăm în cele două exemple următoare 'R,â
$ şi '+.
Observaţi, în figura 9.7 la momentul t 14 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_transaction
A t 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_transaction
A t8 « ex_bloc(balx)
A t9 « cit(balx)
A t10 « balx = balx +100
A t11 « scrie(balx)
A t1 « debloc(balx)
A t13 « «
A t14 'R «
A t15 'R begin_transaction
A t16
part_bloc(balx)
A t17 «
A t18 'R
Î&1 /
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 t ex_bloc(balx) begin_transaction
A 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 t10 « AŞTEAPTĂ
A t11 « «
Î&1 0
157
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:
y
T10 T11
x
Î&1 1
O altă metodă de a evita blocajul ciclic păstrând serializabilitatea este

protocolul cu # (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ă.
. 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.
158
Time Op T7 T8 T9
A t cit(balx) cit(balx)
A t3 balx = balx +10 balx = balx +100
A t4 scrie(balx) scrie(balx) begin_transaction
A t5 cit(baly) cit(baly)
A t6 baly = baly +0 baly = baly +0 begin_transaction
A 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=100
A t1 scrie(balz) scrie(balz)
A t13 balz=50 balz=50 commit
A t14 scrie(balz) scrie(balz)* begin_transaction
A t15 cit(baly) commit cit(baly)
A t16 baly = baly +0 baly = baly +0
A t17 scrie(baly) scrie(baly)
A t18 commit
Î&1
* la timpul t 8 scrierea de către tranzacţia T13 violează regula şi de aceea
este întreruptă şi reluată la momentul t14
** la timpul t 14 scrierea de către tranzacţia T1 poate fi ignorată conform celei
de a treia reguli
1 )2.#
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.
4
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ă.
4
÷ 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.
159
4
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).
) 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ă.
1 D#$
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 (), 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 (
sau 'R).
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.
8(#3
1) Ce este o trnzacţie şi ce proprietăţi are?
) 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?
160

$#8(
/& à

÷

' ÷

÷# ÷
) Tranzacţia T1 citeşte contul lui x (balx) şi scade 10 din cont. Tranzacţia T
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 T balx
A t begin_transaction cit(balx) 100
A t3 cit(balx) balx = balx + 10 100
A t4 balx = balx - 10 scrie(balx) 00
A t5 scrie(balx) commit 90
A t6 commit 90
Se ved că balx are valoarea greşită 90.
3) Un plan de tranzacţii se va numi ' 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 t ex_bloc(balx) begin_transaction
A 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 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).
161
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ă.
. 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.
23
Se 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, , 3, şi să se specifice cheile folosin
dependenţele funcţionale.
) Pe forma finală să se exprime cererile:
a) Tabel cu editurile din Bucureşti
b) 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)

Dependenţele funcţionale sunt:
I. cod-carte titlu
II. cod-carte cod-domeniu
III. cod-carte cod-editură
IV. cod-domeniu domeniu
V. cod-editură editură,
VI. cod-editură oraş,
VII. cod-editură strada,
16
VIII. cod-editură număr
IX. cod-autor nume-autor

unde dependenţa IX este parţială de cheie
Deci forma normală va fi:
Carten1=(cod-carte,titlu,cod-domeniu,cod-editură,editură,oraş,strada,număr))
carten=(cod-autor,nume-autor)
Carten3=(cod-carte,codautor)
cu cheile subliniate după cum reiese din dependenţele:
I. cod-carte titlu şi respectiv cod-autor nume-autor
II. cod-carte cod-domeniu
III. cod-carte cod-editură
IV. cod-domeniu domeniu
V. cod-editură editură,
VI. cod-editură oraş,
VII. cod-editură strada,
VIII cod-editură număr

Dependenţele IV, V, VI, VII,VIII sunt tranzitive de cheie.
Deci forma normală 3 va fi:
Carten31=(cod-carte,titlu,cod-domeniu,cod-editură)
Carten3=(cod-editură, editură,oraş,strada,număr)
Carten33=( cod-domeniu,domeniu)
carten=(cod-autor,nume-autor)
Carten3=(cod-carte,cod-autor) cu cheile subliniate.

a) editură( oraş=¶Bucureşti¶(Carten3))

select editură
from Carte3
where oraş=¶Bucureşti¶

b) titlu (nume=¶Eminescu¶ (Carten31 JN Carten3 JN Carten))
select titlu
from Carten31, Carten3, Carten
where nume=¶Eminescu¶

c) titlu(nume=¶Eminescu¶ (Carten31 JN Carten3 JN Carten)) \
titlu ( nume ¶Eminescu¶ (Carten31 J N Carten3 JN Carten))
select titlu
where nume=¶Eminescu¶ and titlu not in
select titlu
163
where nume ¶Eminescu¶

*
Î
[1] L.Ţâmbulea - Structuri de date şi bănci de date, Universitatea Babeş-

Bolyai, Cluj, 199
[] 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 .0 Comentat şi exemplificat, Timisoara, 199
[6] M. Stanescu şi colectiv - Limbaje de programare şi bănci de date, ASE,
Bucuresti, 199
[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,
164

CURSBze de Date

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CURSBze de Date

Încărcat de

Drepturi de autor:

Formate disponibile



   

Organizarea datelor în fişiere SGBDR Teoria relaţională

În general, conceptele utilizate la prezentarea SGBDR şi a modelelor

Nici unul dintre SGBDR disponibile astăzi nu respectă întrutotul cerinţele

Un SGBD este #( dacă satisface numai condiţiile 1. şi 3.

În ultimii ani, ca răspuns la necesitatea de a creşte complexitatea aplicaţiilor cu

In esenta, conceptul de '   poate fi definit ca fiind o colectie

Bazele de date sunt extrem de variate în functie de criteriile luate în

Numim   un sistem software

 Din punctul de vedere al sistemelor de calcul pe care se

Din punctul de vedere al limbajului pe care il utilizeaza, sunt: sisteme

% Din punctul de vedere al conceptiei de organizare a datelor pe care le

) Din punctul de vedere al modului de localizare a bazelor de date

Utilizator 1 Utilizator  Utilizator n

Î&  Arhitectura ANSI-SPARC pe trei nivele

Pentru fiecare baza de date o singura schema conceptuala descrie datele şi

SGBD realizeaza corespondenta între cele trei nivele de abstractizare,

Este de retinut ca trebuie sa facem distinctie între descrierea bazei de date

Numim ' datele aflate în baza de date la un

Arhitectura unui SGBD evidentiaza componentele acestuia şi urmeaza

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

Modele de date bazate pe obiecte

Modele fizice de date

Se considera ca schema conceptuala sta la baza structurarii unei baze de date.

În exemplul din Figura .1. entitatea ÷  are următoarele atribute:

Numim #( orice asociere între tipuri de entităţi.

scari este locu- locatari

Î& Reprezentarea cu diagrama E-R a relatiei $÷  $ 

Functia pe care o joaca o entitate intr-o relatie se numeste  entitatii. In

Î& % Reprezentarea cu diagrama E-R a relatiei recursive

Î& ) Reprezentarea cu retele semantice a relaţiei 1:M

Conceptual este evident ca entitatile şi relatiile individuale care participa la

Numim #. asociata unui tip de entitate, orice submultime a multimii

În exemplul de mai sus tipul superclasa ÷  se compune din subclasele:

Î& %  Relaţie reprezentată sub forma unei tabele de date

Î& % Relaţia PERS

Relatia PERS reprezintă un subansamblu al produsului cartezian:

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

  Î& % % Reuniunea relatiilor ORASE şi MUNICIPII

In fig. 3.3. este ilustrata aceasta operatie .

 %   . Reprezintă o operaţie a AR definită pe două

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

Î& % D. Produsul cartezian al relaţiilor ORAŞE şi TARIFE

)  (. Reprezintă o operaţie din AR definită asupra unei relaţii

Î& % [ Proiectia relaţiei ORAŞE pe atributul "Judeţ"

 D  (. Roprezintă o operaţie din AR definită asupra unei relaţii R,

 [ <(< Reprezintă o operaţie din AR definită pe două

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

Î& % 0. Reprezentarea grafica a operaţiei de joncţiune

In funcţie de operatorul do comparaţie din cadrul condiţiei de

  Î& % 1 Operaţia de equijoin a relaţiilor ORAŞE şi ESTIMARI

În fig.3.11. este exemplificată operaţia de joncţiune naturală.

Reprezentarea grafică a operaţiei de intersecţie este prezantată în fig. 3.1., iar

Î& %  Reprezentarea grafica a operatiei de intersectie

Inţelesul diferit al termenului "select" utilizat în SQL şi in algebra relaţională

Aceasta inseamna ca orice atribut din schema de relatie initiala R se regaseste

Vom prezenta in continuare un criteriu cu ajutorul caruia se poate verifica daca

Î& D D  Relaţiile *'÷ ÷ şi 4

În această tabelă observăm că pentru furnizorul ³Romgaz´ avem două

cod_domeniu den_domeniu şi pentru că c_carte este cheie avem şi

[  1.1. Ce este o metodologie de proiectare?

[  1. Proiectarea logică şi fizică a bazei de date

 (    

Un SGBD este #( dacă satisface numai condiţiile 1. şi 3.

In esenta, conceptul de ' poate fi definit ca fiind o colectie

Numim un sistem software

Din punctul de vedere al sistemelor de calcul pe care se

% Din punctul de vedere al conceptiei de organizare a datelor pe care le

Utilizator 1 Utilizator Utilizator n

Î& Arhitectura ANSI-SPARC pe trei nivele

Numim ' datele aflate în baza de date la un

În exemplul din Figura .1. entitatea ÷ are următoarele atribute:

Numim #( orice asociere între tipuri de entităţi.

Î& Reprezentarea cu diagrama E-R a relatiei $÷ $

Functia pe care o joaca o entitate intr-o relatie se numeste entitatii. In

Î& % Reprezentarea cu diagrama E-R a relatiei recursive

Î& ) Reprezentarea cu retele semantice a relaţiei 1:M

Numim #. asociata unui tip de entitate, orice submultime a multimii

În exemplul de mai sus tipul superclasa ÷ se compune din subclasele:

Î& % Relaţie reprezentată sub forma unei tabele de date

Î& % Relaţia PERS

Î& % % Reuniunea relatiilor ORASE şi MUNICIPII

% . Reprezintă o operaţie a AR definită pe două

Î& % D. Produsul cartezian al relaţiilor ORAŞE şi TARIFE

) (. Reprezintă o operaţie din AR definită asupra unei relaţii

Î& % [ Proiectia relaţiei ORAŞE pe atributul "Judeţ"

D (. Roprezintă o operaţie din AR definită asupra unei relaţii R,

[ <(< Reprezintă o operaţie din AR definită pe două

Î& % 0. Reprezentarea grafica a operaţiei de joncţiune

Î& % 1 Operaţia de equijoin a relaţiilor ORAŞE şi ESTIMARI

Reprezentarea grafică a operaţiei de intersecţie este prezantată în fig. 3.1., iar

Î& % Reprezentarea grafica a operatiei de intersectie

Î& D D Relaţiile *'÷ ÷ şi 4

[ 1.1. Ce este o metodologie de proiectare?

[ 1. Proiectarea logică şi fizică a bazei de date

(

O

ë

Î&[ % Exemplu de relatie superclasă/subclasă

÷ ÷ ÷ ' ÷

÷

[ % & # '

÷÷

ë ë

Î&[ % Diagrama ER. a view-ului ³Locatari´.

Î&[ % Modelul conceptual local al view-ului ³Locatari´

Î&[ % ' Modelul conceptual local al view-ului ³Cheltuieli´.

Î&[ % [ Modelul logic local al view-ului ³Locatari´.

Î&[ % [ ' Modelul logic local al view-ului ³Cheltuieli´.

Î&[ % / ' Tranzacţiile cerute pentru view-ul ³Cheltuieli´.

Î&[ % Diagrama globală şi finală ER.

Dacă S1aR şi SaR atunci 1 Ú 1 ( " ) şi Ú ( ") .

. fragmente orizontale fragmentate vertical

Dacă S1aR şi SaR atunci 1 Ú 1 ( " ) şi Ú ( R) .

create domain ZI char()

Problema se numeşte #'#$.