SISTEME DE GESTIUNE A BAZELOR DE DATE

1: SISTEME DE GESTIUNE A BAZELOR DE DATE

RELAIONALE

1.1. Definiii, terminologie

Apariia i dezvoltarea calculatoarelor electronice au condus la
amplificarea activitilor legate de stocarea, interogarea i administrarea
coleciilor de date. Astzi, cele mai multe dintre activitile noastre zilnice
necesit accesarea i actualizarea informaiei dintr-o baz de date:
extragerea unei sume de bani din contul bancar, rezervarea unei camere
de hotel, cumprarea unui bilet de avion, mprumutarea unei cri de la
bibliotec, pltirea facturilor de telefon, curent electric etc. Toate acestea se
pot face rapid i n siguran pentru c datele respective sunt bine
organizate ntr-o baz de date i administrate de un sistem de gestiune a
bazelor de date.
Baz de date (BD) = o colecie de date aflate n relaie unele cu altele
i structurat astfel nct s poat servi unui anumit scop
= un set de date corelate i organizate n scopul prelucrrii lor rapide i
concomitente de ctre mai multe persoane.
Exemple
1) baza de date a unui muzeu, n care sunt nregistrate operele de art
(grupate dup tip, autor, tehnic de lucru) i expoziiile itinerante (descrise
prin perioad, itinerariu, responsabil, custozi participani);
2) baza de date a unui magazin de muzic, n care sunt nregistrate
albumele de muzic n funcie tipul de suport fizic (CD, caset etc.), stil,
autori, soliti, anul apariiei etc.
Observaie
Termenul "Database" (baz de date, n limba englez) a aprut pentru
prima dat n titlul unei conferine organizate la Santa Monica, SUA, n
1964: Development and Management of Computer Centered DataBase.

1
 Sistem de gestiune a bazei de date

Baza de date

Programe i aplicatii Utilizatori

Figura 1: Structura simplificat a unei baze de date

Sistem de gestiune a bazelor de date (SGBD) = un ansamblu de

programe care permit crearea i administrarea unei baze de date. Prin
urmare, un SGBD (Database Management System) este un pachet
software de nivel nalt care permite proiectarea, construirea i
administrarea bazelor de date dedicate rezolvrii problemelor din cele mai
variate domenii ale vieii reale.
Exemple
IMS, DB2 (pn la DB9, de la IBM), Ingres II (de la Computer Associates
International Inc.), Oracle 8i (de la Oracle Corporation), Ms Access
(studiat n clasa a X-a), FoxPro (de la Microsoft), Paradox, Visual dBase
(de la Borland), Sybase Adapted Server (de la Sybase Inc.), IRIS (de la
Hewlett-Packard).
Atenie
Nu orice colecie de date este o baz de date. De exemplu, lista crilor
dintr-o bibliotec NU este o baz de date ci un simplu inventar de obiecte,
o list, un tabel. Prin urmare, fa de un inventar (un tabel), o baz de
date are urmtoarele proprieti:
reprezint un anumit aspect al lumii reale, numit microuniversul bazei
de date; orice modificare care se produce in acest microunivers se reflect
n baza de date (de exemplu: cumprarea unei noi casete n vederea
inchirierii, modificarea diferenei permise ntre cursul de cumprare i cel
de vnzare al valutei etc.);
2
 este o colecie de date coerent din punct de vedere logic i avnd un
neles intrinsec (de exemplu: din baza de date asociat bibliotecii liceului
nu vor face parte crile de telefon sau lista de materiale didactice din
laboratorul de chimie);
este proiectat, construit i populat cu date avnd permanent n
vedere un anumit scop; o baz de date este destinat utilizrii de ctre un
anumit grup de persoane i permite efectuarea unui anumit set de operaii.
Un SGBD foloseste in principiu trei limbaje: un limbaj de descriere al
datelor fizice, un limbaj de descriere al datelor logice si un limbaj de
prelucrare al datelor. Aceste limbaje pot fi de sine statatoare sau grefate pe
un limbaj de programare general (de exemplu, C, COBOL, PL/I etc.).
Arhitectura bazelor de date evidentiaza componentele acestora:
baza de date propriu-zisa in care se memoreaza datele;
sistemul de gestiune a bazei de date, care realizeaza gestiunea
si prelucrarea complexa a datelor;
un dictionar al bazei de date (metabaza de date ),ce contine
informatii despre date, despre structura acestora, statistici,
documentatie;
mijloace hard utilizate (comune sau specializate);
reguli administrative destinate bunei functionari a intregului
sistem.
personalul implicat (utilizatori finali, administrator, programatori,
operatori).
Dintre obiectivele care se impun unui SGBD enumerm :
sa furnizeze in timp util informatiile solicitate (timp de raspuns la o
interogare );
sa asigure costuri minime de prelucrare si intretinere, redundanta
minima;
sa aiba capacitatea de a satisface cu aceleasi date, necesitatiile
informationale, ale unui numar mare de utilizatori, sa permita adaptarea la
cerinte noi, raspunsuri la interogari neprevazute initial (flexibilitate );
sa permita exploatarea simultana a datelor de catre mai multi
utilizatori (sincronizare);
sa asigure securitatea datelor prin mecanisme de protectie impotriva
accesului neautorizat (confidentialitate);
sa contina facilitati destinate validari datelor si recuperarii lor in cazul
unor deteriorari accidentale (integritate);
sa permita valorificarea eforturilor anterioare si anticiparea nevoilor
viitoare (compatibilitate si expandabilitate);
sa permita, prin ierarhizarea datelor dupa criteriul frecventei acceselor,
reorganizari (eventual dinamice) care sporesc performantele bazei.

3
 Cuvntul dat este de origine latin i provine de la verbul a da. n
limba englez, substantivul dat (date, la plural) se traduce prin datum
(data, la plural). Exemple de date sunt: cantitile de mere obinute anual
ntr-o livad de pomi fructiferi, activitile turistice propuse de ghid
participanilor la o excursie; modificrile climatice suferite de o regiune a
globului terestru de-a lungul unui numr de ani, cursul bancar al unei valute
de-a lungul unei luni sau a unui an calendaristic etc.
Exist o diferen esenial ntre date, informaii i cunotine:
1. datele sunt informaii primare care au fost doar culese i inregistrate;
2. informaiile sunt date prelucrate, structurate (validate, corectate,
organizate, sortate, relaionate);
3. cunotinele sunt informaii contextualizate.
Arhitectura sistemelor de gestiune a bazelor de date este puternic
determinat de modelul de date al bazelor de date. Dincolo de definiiile
date pn acum, ce este de fapt o baz de date? Este un obiect
(asemenea numerelor, funciilor, mulimilor)? Este o metod (asemenea
algoritmilor, procedurilor)?

1.3. Modelarea datelor

1.3.1. Modelul de date

Dincolo de definiiile date pn acum, ce este de fapt o baz de
date? Este un obiect (asemenea numerelor, funciilor, mulimilor)? Este o
metod (asemenea algoritmilor, procedurilor)?
O baz de date este n primul rnd un model al microuniversului la
care se refer.

Definiie Model =
= (n sens strict) un sistem teoretic sau material cu ajutorul cruia pot fi
studiate indirect proprietile i transformrile unui alt sistem, mai complex,
cu care primul sistem prezint o analogie;
= (n sens larg) ceea ce poate servi ca orientare pentru reproduceri (un
tipar). (cf. DEX)

4
 Lume real
a

Ce (aspect al realitii) vrem s modelm?

Ce informaii sunt necesare
Cum vom exprima (reprezenta)
Reprezentarea propus ne permite
Cum "traducem" reprezentarea
Ct de bine lucreaz modelul (care
(vor fi implicate) n modelare?
acel aspect al realitii?
s efectum toate aciunile dorite?
n mediul de modelare ales?
este gradul su de adecvare la
realitatea modelat)?

Figura 1: Procesul de construire a unui model

#3 Sarcin de lucru: Construirea unui model

a) Comentai i ilustrai procesul de construire a unui model.
b) Adaptai acest proces la cazul bazelor de date.

O baz de date nregistreaz date despre un aspect al realitii

inconjurtoare, opernd simplificrile necesare i inerente: ntr-o baz de
date privind angajaii unei fabrici nu vom memora i informaii despre
romancierii sau solitii preferai de fiecare angajat (dei i aceste informaii
pot avea relevana lor) ci doar date despre starea civil, studii, experiena
anterioar etc. Ca urmare, un acelai aspect al realitii nconjurtoare
poate fi modelat n mai multe feluri, n funcie de scopul urmrit: activitatea
dintr-o coal poate fi modelat din punctul de vedere al activitii didactice,
al evidenei colare, al salarizrii personalului etc. Cu alte cuvinte, alegerea
unui anumit mod de reprezentare a situaiei reale pentru definirea bazei de
date depinde de scopul pentru care trebuie construit baza de date.

#4 Sarcin de lucru: Modele alternative

Un muzeu este o colecie de obiecte de art (de diferite categorii: picturi,
sculpturi, altele) expuse permanent sau prin expoziii tematice, itinerante
etc. Unele obiecte pot fi scoase temporar din expoziie i depozitate n
vederea restaurrii. Muzeul dispune de personal administrativ dar i de

5
personal specializat n organizarea de expoziii, restaurare, organizare de
cursuri (de specialitate sau de iniiere).
Propunei mai multe modele pentru activitile unui muzeu.

Figura 2: Modele multiple

#5 Sarcin de lucru: Modele multiple

Alegei un aspect din realitatea care v este familiar i propunei cel puin
trei modele ale acestuia; enunai scopul corespunztor fiecrui model.

O baz de date ofer un anumit grad de abstractizare a datelor

(asemenea celor mai multe limbaje de programare), ascunznd detaliile de
implementare, detalii care nu sunt necesare celor mai muli dintre utilizatori.
Cu alte cuvinte, programele specifice unei baze de date nu depind de
modul de stocare i accesare a datelor la nivel fizic. Acest concept se
numete independen a datelor, se realizeaz cu ajutorul unui model de
date (Data Model1) i este principalul mecanism care asigur partajarea
datelor din baza de date ntre diferitele aplicaii care le acceseaz.

Definiie Model de date =

= un ansamblu format din:
1) o colecie de concepte necesare pentru descrierea structurii bazei de
date (a tipurilor de date incluse n baza de date, a relaiilor dintre ele i a
restriciilor (Constraints) pe care trebuie s le respecte);
2) un set de operaii de baz (care s specifice modul de efectuare a
extragerii i actualizrii datelor din baza de date).

1
E.F. Codd este considerat a fi "printele" conceptului de model de date, n
general, i al conceptului de model de date relaional, n particular.
6
1.3.2. Modele de date: perspectiv istoric
Evoluia modelelor de date pentru bazele de date i SGBD-uri a fost
sugestiv sintetizat de R.G.G. Canttell n articolul su "What Are Next-
Generation DB Systems?", publicat n revista Communications of the ACM,
n octombrie 1991: "Istoria informaticii a cunoscut multe generaii de
sisteme de gestiune a datelor, ncepnd cu sistemele de fiiere indexate,
continund apoi cu sistemele de tip ierarhic i de tip reea, iar mai nou
cu sistemele relaionale. Acum suntem pe punctul de a intra ntr-o nou
generaie de sisteme de gestiune a bazelor de date care ofer administrare
de obiecte, i care accept tipuri de date mult mai complexe".
Cu toate c a generat o activitate de cercetare foarte susinut dar i
o activitate practic, industrial extrem de productiv, domeniul bazelor de
date este unul dintre cele mai tinere domenii ale informaticii. Este general
acceptat faptul c "rdcinile" sale trebuie cutate aproximativ acum 40 de
ani2 n obiectivul fixat de Preedintele J.F. Kennedy pentru programul
Apollo: aducerea primului om pe Lun pn la sfritul anilor '60. In acel
moment nu exista nici un instrument informatic care s funcioneze efectiv
i care s poat administra uriaele volume de date implicate n programul
spaial. Ca urmare, North American Aviation (NAA) primul contractor al
proiectului, a dezvoltat un software bazat pe o structur ierarhic (prile se
agreg n componente din ce n ce mai ample) denumit GUAM
(Generalized Update Access Method). Spre mijlocul anilor '60, IBM s-a
alturat NAA dezvoltnd n continuare GUAM i producnd unul dintre
primele sisteme comerciale de gestiune a bazelor de date: IMS
(Information Management System). IBM a preluat modelul ierarhic pentru
a respecta cerina de stocare a datelor pe benzi magnetice (deci n acces
secvenial). Ulterior, aceast restricie a fost nlturat i IMS continu s
fie principalul SGBD ieirarhic utilizat de majoritatea calculatoarelor
mainframe3.
Construirea bazelor de date a cunoscut o evoluie foarte rapid,
trecnd prin mai multe abordri, clasificate dup cum urmeaz:
sistemele de fiiere;
sistemele prerelaionale (sau "istorice"4): ierarhic i reea,
sistemul relaional;
sistemele postrelaionale: orientat obiect i hibrid (obiect-relaional);
sistemele semantice: multi-dimensional i logic (deductiv).

2
Data apariiei primului sistem comercial de gestiune a bazelor de date
3
Un calculator mainframe este un calculator cu capacitate de memorie i vitez de
lucru foarte mari, utilizat de marile corporaii pentru a stoca volume foarte mari de
date i pentru a coordona sute sau mii de terminale (inclusiv calculatoare
personale) conectate la el. Operarea unui mainframe necesit de obicei un
personal specializat.
4
numite i navigante sau tradiionale (legacy systems)
7
1.3.2.1. Modelele prerelaionale
Pot fi caracterizate ca modele de moment: au oferit soluii pentru
problemele vremii lor dar nu au avut un fundament teoretic puternic i
riguros.
(I.) Sistemul de gestiune bazat pe fiiere, considerat de fapt un
predecesor al sistemelor de gestiune a bazelor de date, este o colecie de
programe care realizeaz fiecare cte "un serviciu" pentru utilizatorii
datelor (de obicei: generarea de rapoarte). Fiecare program i definea i
i administra propriile date. Chiar dac a avut numeroase dezavanataje
(abordarea descentralizat n stocarea informaiilor, gradul mare de
redundan i dependen program-date), sistemul de gestiune bazat pe
fiiere a constituit un salt semnificativ fa de fiierele administrate manual:
saltul de la abordarea informaional la cea informatic.

(a) (b)

Figura 3: Modele de baze de date: (a) ierarhic; (b) reea

(II.) Att n modelul ierarhic ct i n modelul reea, datele erau

reprezentate ca mulimi de inregistrri (n sensul limbajului de programare
Pascal: colecii de date de diferite tipuri: Integer, Boolean, Real etc.).
Relaiile dintre ele erau reprezentate prin legaturi de tip pointer (adrese de
locaii fizice de memorie). Inregistrrile care formau baza de date erau
organizate:
n modelul ierarhic: ca o mulime de arbori;
n modelul reea: ca o mulime de grafuri.
Ambele modele prerelaionale permiteau accesul la date de-a lungul
unor drumuri (ci) predefinite, explicit stabilite la nivelul programelor de
aplicaii (de unde i numele de modele navigante). Ca urmare, orice
modificare a structurii bazei de date antrena modificarea acestor ci n
programele deja scrise. Exemple: pentru modelul ierarhic: IMS (amintit mai
8
sus); pentru modelul reea: IDS II (de la Honeywell), IMAGE (de la Hewlett
Packard).

Aplicaie: Modelarea activitii didactice

Intr-o facultate, cadrele didactice desfoar activiti didactice de curs sau
examen; aceste activiti sunt pentru studeni i se desfoar n locaii
(amfiteatre sau laboratoare). De asemenea, cadrele didactice particip la
proiecte de cercetare tiinific. Figura 5 prezint modelul ierarhic al
facultii; Figura 6 prezint modelul reea.

Facultate

Student Activitate didactic Locaie Cadru didactic

Curs Examen Proiect

Figura 5: Modelul ierarhic

9
 Desfurare

Curs Examen

Locaie
Inscriere
Activitate didactic
Facultate
Student

Predare

Proiect Cadru didactic

Figura 6: Modelul reea

1.3.2.2. Modelul relaional

Considerat drept cel mai important
eveniment din istoria bazelor de date, apariia
modelului relaional s-a produs n iunie 1970,
odat cu publicarea n revista Communications
of the ACM a articolului fundamental al lui

10
Edgar Frank Codd5 (de la IBM Research Laboratory): "A Relational Model
of Data for Large Shared Databanks". n acest articol, autorul aplica o serie
de concepte din algebra relaional pentru a rezolva problemele legate de
stocarea volumelor mari de date i enuna "celebrele" 12 reguli (condiii) pe
care trebuie s le ndeplineasc un SGBD pentru a fi declarat relaional.
S amintim ns existena unui precursor: modelul bazat pe teoria
mulimilor, propus de D.L. Childs n articolul su: "Feasability of a Set-
Theoretical Data Structure", aprut n 1968 n Proc. Fall Joint Computer
Conference.
Cele mai importante prototipuri de sisteme de gestiune a bazelor de
date de tip relaional au fost:
System R, dezvoltat la San Jose Research Laboratory din California
spre sfritul anilor '70. Acest model a condus la:
o apariia unui limbaj structurat de interogare a bazelor de date: SQL,
o producerea mai multor SGBD-uri relaionale comerciale: DB2 i
SQL/DS de la IBM i, respectiv, ORACLE de la Oracle Corporation
(n deceniul 9 al secolului trecut);
INGRES (Interactive Graphics Retrival System), dezvoltat la
Universitatea Berkeley din California;
Peterlee Relational Test Vehicle, dezvoltat la IBM UK Centre din
Peterlee, Marea Britanie.
Numrul sistemelor relaionale comerciale a ajuns acum la cteva
sute, dintre care cele mai cunoscute sunt: DB2 (de la IBM), Ingres II (de la
Computer Associates International Inc.), Oracle 8i (de la Oracle
Corporation), Ms Access, FoxPro (de la Microsoft), Paradox, Visual
dBase (de la Borland), Sybase Adapted Server (de la Sybase Inc.).
Succesul acestui model continu s fie att de mare nct multe sisteme
nerelaionale ofer acum i o interfa cu utilizatorii de tip relaional,
indiferent de modelul de date pe care se bazeaz de fapt.

#6 Sarcin de lucru: Un SGBD pentru bazele de date

relaionale
Recapitulai noiunile studiate n clasa a X-a privind sistemul de gestiune a
bazelor de date Ms Access.

Modelul relaional s-a dovedit a fi i un instrument didactic ideal de

prezentare a principiilor bazelor de date, tocmai datorit fundamentrii sale
riguroase pe principii logice i matematice.
5
E.F. Codd s-a nscut la 23 august 1923 n Portland, Marea Britanie, i a murit n
18 aprilie 2003, n Florida. A fcut studii de matematic i chimie la Oxford i s-a
mutat n Statele Unite n 1948, pentru a lucra la IBM. A introdus termenul OLAP
(OnLine Analytical Processing) i a impus modelul relaional; a avut, de
asemenea, contribuii n domeniul modelelor de calculabilitate prin lucrrile sale
privind automatele celulare. A obinut de dou ori Premiul Turing: n 1981 i 1994.
11
 Ce este de fapt un model relaional de date? Informal, l putem defini
ca un model n care:
datele sunt percepute de utilizatori ca nite tabele i numai ca nite
tabele;
operaiile disponibile pentru utilizatori (spre exemplu, pentru obinerea
informaiilor) sunt operaii care genereaz noi tabele pe baza tabelelor
vechi: operaia de selecie (SELECT) extrage o submulime de rnduri
dintr-o tabel, operaia de proiecie (PROJECT) extrage o submulime de
coloane, operaia de juxtapunere (JOIN) asociaz dou tabele pe baza
valorilor identice pe care le conin n anumite coloane, de asemenea
identice; ori, toate aceste submulimi rezultate pot fi privite i ele nsele ca
nite tabele.

(a) (b) (c)

Figura 4: Operaii cu tabele: (a) selecie; (b) proiecie, (c) asociere

Numele modelului (model relaional) provine de la conceptul

matematic de relaie. Aa cum o funcie f : {1, 2,,n} N R
are mai multe reprezentri convenionale, dintre care cea mai comod este
cea de vector, tot astfel relaia poate avea mai multe reprezentri, una
dintre ele fiind tabela. Din acest motiv, cel puin la nivel informal,
termenii de relaie i tabel pot fi considerai sinonimi.
Principalele concepte cu care lucreaz modelul de date de tip
relaional sunt (exemplificarea se face pentru baza de date asociat unui
liceu):
entitatea (Profesori, Elevi, PersonalAuxiliar, Clase etc.),
relaia dintre entiti (PredLa, AreDirigintePe, AreLocIn etc.),
atributul (Nume, GradDidactic, DataNaterii, NrLocuri, Locaie etc.).

#7 Sarcin de lucru: Modelele ierarhic, reea i relaional

a) Realizai un tabel comparativ al modelelor de date ierarhic, reea i
relaional, urmrind organizarea datelor i a legaturilor dintre ele.
b) Enumerai cel puin trei avantaje i trei dezavanataje ale modelelor
ierarhic, respectiv reea, fa de modelul relaional.

12
1.3.2.3. Modelele postrelaionale
Chiar dac se regsete n descrierea unor situaii reale, cu o
organizare intrinsec piramidal, modelul ierarhic i-a atins rapid limitele. La
fel, modelul relaional a devenit impropriu pentru rezolvarea unor probleme
din realitatea nconjurtoare care presupun manipularea unor volume
uriae de informaie, a unei mari varieti de tipuri de date: hri
meteorologice sau geografice necesare previziunilor meteorologice sau
dirijrii traficului, imagini transmise prin satelit utilizate n msurarea
factorilor poluani, date neconvenionale pentru proiectarea asistat de
calculator n inginerie sau arhitectur, serii dinamice implicate n tranzaciile
bursiere sau bancare, stocarea obiectelor binare mari (BLOBs = Binary
Large Objects) necesare n digitalizarea informaiei coninut n fiierele
audio sau video. Au aprut astfel i s-au dezvoltat modelele postrelaionale,
de generaia a treia: modelul orientat obiect i modelul obiect-relaional.
(I.) Modelul orientat obiect permite inglobarea semanticii obiectelor celor
mai variate, la fel ca n limbajele de programare orientate-obiect. De altfel,
una dintre deosebirile majore fa de modelul relaional const n
distanarea de conceptul de independen fa de limbajele de programare
i dezvoltarea conceptului de integrare a limbajelor de programare n
sistemul de gestiune a bazei de date (invocarea unor funcii C++ mai
degrab dect inglobarea unui limbaj special pentru interogarea datelor, ca
de exemplu SQL). Acest fapt a fost determinat de:
utilizarea aproape exclusiv a limbajelor de programare orientate obiect
pentru dezvoltarea aplicaiilor software;
includerea n aproape orice aplicaie software a unei baze de date ca
element fundamental al acesteia.
Cele mai cunoscute prototipuri de baze de date orintate obiect sunt:
OPENOODB (de la Texas Instruments), IRIS (de la Hewlett Packard), iar ca
variant comercial: GEMSTONE/OPAL (de la GemStone Systems),
VERSANT (de la Versant Object Technology). Dei cu o cot de pia
semnificativ inferioar sistemului relaional (150 milioane dolari fa de 10
miliarde, numai n SUA n anul 1999), modelul orientat obiect este creditat
cu o cretere anual extrem de rapid: 50%.
n ciuda caracterului intuitiv i a altor avantaje evidente ale
modelului orientat obiect, modelul relaional continu s domine piaa
sistemelor de gestiune a bazelor de date. Motivele sunt numeroase:
fundamentarea matematic riguroas, simplitatea, volumul mare de date
deja stocate dup acest model i costul enorm al migrrii spre un model
complet diferit.
(II) Modelul hibrid extinde modelul relaional oferind un set de tipuri de
date mai bogat, i include i orientarea obiect. Se incearc astfel
combinarea avantajelor celor dou abordri: cea relaional i cea orientat
obiect. Astfel, atributele i instanele entitilor pot avea tipuri complexe i
pot evita unele dintre restriciile specifice modelului relaional. De exemplu,
13
n timp ce n modelul relaional fiecare atribut trebuie s ia pentru fiecare
instan a unei entiti o valoare i numai una din domeniul lui de definiie,
n modelul hibrid poate lua un subset de valori (de exemplu: pentru un
angajat oarecare, atributul Telefon poate lua ca valori numrul telefonului
fix de acas i de la servicu, al telefonului mobil propriu i de serviciu, dac
angajatul dispune de toate patru).
Cel mai cunoscut exemplu: Informix Universal Server care combin
tehnologiile relaionale i orientate obiect din dou produse preexistente:
Informix i Illustra.
Principalele avantaje i dezavantaje ale modelelor de date (i ale
sistemelor de gestiune a bazelor de date corespunztoare) au fost
sintetizate de M. Stonebraker prin diagrama din Figura 7 (vezi [18]):
modelul relaional permite realizarea chiar simultan a unor interogri
variate i rapide dar complexitatea datelor stocate nu difer prea mult de
complexitatea datelor memorate n baze de date de tip ierarhic sau reea;
cu modelul orientat obiect se poate stoca informaie variat i complex (de
la texte la sunete i imagini) dar viteza de interogare (n cazul imaginilor i
mai ales al sunetelor) este foarte sczut; modelul care pare s elimine
toate dezavantajele i s cumuleze toate avantajele modelelor anterioare
este modelul obiect-relaional.

Faciliti de SGBD relaionale SGBD hibride

interogare /
asistena multi-user SGBD prerelaionale SGBD orientate obiect

Complexitatea datelor /
posibile extinderi
Figura 7: Clasificarea Stonebraker pentru
sistemele de gestiune a bazelor de date

14
CAPITOLUL 2: PROIECTAREA BAZELOR DE DATE
1.3. Arhitectura SGBD
Datele din baza de date pot fi descrise pe trei nivele: extern, conceptual i
intern:

Nivelul extern:
Schema Schema Schema
imaginea fiecrui
extern 1 extern 2 extern 3
utilizator asupra BD

Nivelul conceptual
(structura logic a BD): Schema
ansamblul datelor stocate conceptual
n BD i a relaiilor dintre
ele (fr detalii de
implementare)

Nivelul intern:
implementarea fizic a BD Schema
(structuri de date, intern
indexare, acces)

Organizarea fizic a datelor,

coordonat de SGBD i
sistemul de operare Baza
de date

Figura 5: Arhitectura ANSI6-SPARC7 pe 3 nivele pentru bazele de date

Nivelul extern reprezint modul n care utilizatorul percepe datele. Intruct

anumite pri din baza de date sunt relevante pentru unii utilizatori dar
irelevante pentru alii putem spune c o baz de date are attea nivele
externe ci utilizatori o acceseaz. Mai mult, exist entiti care dei snt
reprezentate n baza de date nu apar la acest nivel deoarece snt irelevante
pentru anumii utilizatori.
Nivelul intern (nivelul fizic) reprezint modul n care SGDB-ul i sistemul
de operare percep datele. La acest nivel:

6
ANSI = American National Standards Institute
7
SPARC = Standards Planning and Requirements Committee
15
 este descris reprezentarea fizic a bazei de date n calculator
(sunt specificate: spaiul de stocare a datelor, modul de stocare a
acestora, structurile de date, organizarea fiierelor etc.);
sunt utilizate funcii ale sistemului de operare pentru plasarea
datelor pe dispozitivele de stocare, pentru construirea indecilor,
pentru citirea datelor etc.;
Nivelul conceptual (nivelul logic) realizeaz trecerea de la nivelul intern
la nivelul extern i asigur independena acestora. Acest nivel:
grupeaz percepiile tuturor utilizatorilor bazei de date (deoarece
conine fiecare viziune (view) din nivelul extern, direct sau indirect);
conine structura logic a bazei de date descris prin conceptele de
entitate, atribut i relaie, constrngeri referitoare la date, informaii
de securitate i integritate;
descrie datele stocate n baza de date i relaiile dintre ele dar nu
conine detalii referitoare modul de stocare a datelor pe suportul
fizic (numrului de octei ocupai pe disc etc.).
Scopul arhitecturii pe cele trei nivele este acela de separare a percepiei
fiecrui utilizator individual aspura datelor de modul de reprezentare fizic a
acestora n baza de date. Figura 2 ilustreaz acest lucru reprezentnd
nivelul intern, nivelul conceptual i dou vederi corespunztoare la nivelul
extern: una aparinnd unui utilizator de PL/I, cealalt aparinnd unui
utilizator de COBOL.

Nivel extern Nivel extern

(PL/I) (COBOL)

DCL 1 ANG, 01 ANGAJ.

2 ANG# CHAR(6), 02 CODANGAJ PIC
2 SAL FIXED X(6).
BIN(31); 02 CODDEPT PIC
X(6).
Nivel
conceptual

ANGAJAT
COD_ANGAJAT CHARACTER (6)
COD_DEPARTAMENT CHARACTER (4)
SALARIU NUMERIC (5)
Nivel intern

STORED__ANG BYTES=20
PREFIX TYPE=BYTE(6), OFFSET=0
ANG# TYPE=BYTE(6), OFFSET=6, INDEX=ANGX

16
 DEPT# TYPE=BYTE(4), OFFSET=12
SALAR TYPE=FULLWORD, OFFSET=16

Figura 6: Exemplu de arhitectur pe 3 niveluri

Observaie
n timp ce nivelele extern i conceptual trebuie s urmeze acelai model
(relaional, orientat-obiect etc.), nivelul intern nu are nimic de a face cu
modelul de date al bazei - el constnd din nregistrri memorate, pointeri,
indeci etc.
Intr-o baza de date sunt necesare trei nivele de independenta a
datelor:
independenta fizica: asigura posibilitatea modificarii schemei fizice a
datelor fara ca aceasta sa oblige la modificarea schemei conceptuale,
schemei logice si a programelor de aplicatie.
independenta logica: asigura posibilitatea modificarii schemei
conceptuale a datelor fara ca aceasta sa oblige la modificarea
schemei logice si a programelor de aplicatie.
independenta fata de strategiile de acces: permite programului sa
precizeze data pe care doreste sa o acceseze, dar nu modul cum
acceseaza aceasta data. SGBD va stabili drumul optim de acces la
date.

2.2. Proiectarea bazelor de date

Definiie Proiectarea unei baze de date =
= procesul de creare a unui proiect pentru baza de date care s asigure
desfurarea corect a activitilor i rezolvarea cerinelor utilizatorilor.

Principalele scopuri ale acestei etape sunt:

reprezentarea datelor i a relaiilor dintre date, conform cerinelor
formulate de utilizatori i condiiilor impuse de programele de calculator;
furnizarea unui model de date care s asigure orice tip de prelucrare a
datelor;
schiarea unui proiect astfel structurat nct s satisfac parametrii de
eficien specificai (de exemplu: obinerea datelor solicitate ntr-un interval
de timp cel mult egal cu o valoare t prestabilit).
Proiectarea bazei de date se poate face prin metoda:
bottom-up: se incepe cu stabilirea atributelor i prin analiza
asocierilor dintre ele se obin entitile i relaiile dintre entiti;
top-down: se dezvolt un model de date constnd din cteva entiti i
relaii, foarte generale. Apoi, modelul este rafinat, obinndu-se modele
din ce n ce mai detaliate;
17
 mixt: se combin i se itereaz metodele de mai sus.

Calea Victoriei nr: 321-323

Bucureti - 001234
Tel/fax: 313.4567
DEVIZ
Data___01-09-05____________ Devizul reprezint produse :
Atelierul __Costume__________ X vndute
achiziionate.
Adresa atelierului_____________str. Cetauia nr.8___________
Telefon__021331328_________
ef atelier_Sorin Andreescu_______

Am achizitionat de la / livrat ctre:___Teatrul de Dram___________________

cu adresa___Sf. Dumitru nr.2, Bucureti____________________________

Denumire produs Cantitate Preuri Total

costum epoc 2 300 RON 600 RON
frac 1 400 RON 400 RON

Total__1000 RON__

ef atelier: Furnizor / Client:

Sorin Andreescu

Figura 2 : Un deviz pentru costume de teatru

Aplicaie: Proiectarea unei baze de date prin metoda top-

down
Figura 2 reproduce un deviz pentru costumele de scen
confecionate i vndute de atelierul de costume al unui teatru. Utilizm
metoda top-down pentru a proiecta o baz de date pentru aceast
activitate a teatrului.
Pas 1. identificm orizontul bazei de date: activitatea sau activitile
pentru care dezvoltm baza de date (aici: din examinarea devizului
deducem c teatrul dispune de diverse ateliere - costume, decoruri etc. - i
c poate vinde sau achiziiona costume, decoruri etc.)

18
Pas 2. identificm principalele entititi i relaii: (aici: teatrul are mai multe
Ateliere care vnd diferite tipuri de Produse unor Clieni sau le
achiziioneaz de la Furnizori)
Pas 3. identificm tipurile de relaii dintre entiti (aici: un tip de produs
este vndut unui client sau mai multor clieni iar un client cumpr unul sau
mai multe produse; analog un tip de produs este achiziionat de la un
furnizor sau de la diveri furnizori iar un furnizor ofer unul sau mai multe
produse; aceste operaii au loc conform unui deviz: apare astfel o nou
entitate: Devize)
Pas 4. identificm atributele entititilor i relaiilor dintre entiti (aici:
Denumire, Adres, Telefon, Sef atelier pentru entitatea Ateliere;
Denumire, Cantitate, PreUnitar pentru entitatea Produse; Denumire,
Adres, Persoana de contact att pentru entitatea Client ct i pentru
entitatea Furnizor; Data operaiei, Tipul operaiei (vnzare sau
achiziionare), Denumirea atelierului, Denumirea clientului/Furnizorului,
Denumirea produsului, Preul total pe tip de produs, Preul total al
produselor pentru entitatea Devize
Pas 5. identificm restriciile care trebuie respectate: (aici: pe un deviz pot
aprea fie produse vndute fie produse achiziionate; pe un deviz nu pot
aprea mai mult de 4 categorii de produse; un deviz se refer la produsele
vndute sau achiziionate la o aceeai dat calendaristic, de la sau ctre
acelai partener (client sau furnizor)
Pas 6. identificm operaiile de baz (aici: ordonarea clienilor sau
furnizorilor dup nume, selectarea clienilor sau furnizorilor cu cea mai
recent comand, calcularea trimestrial a totalului ncasrilor i respectiv
plilor efectuate etc.).

#1 Sarcin de lucru: Proiectarea unei baze de date pentru un

spital
Figura 3 reproduce o foaie de observaie dintr-un spital. Analizai-o i
proiectai cu ajutorul ei o baz de date prin metoda top-down.

19
 Figura 3 : O foaie de observaie

2.3. Utilizarea modelelor de date n etapa de proiectare

Indiferent de metoda de proiectare folosit, identificarea entitilor i
relaiilor dintre ele necesit:
nelegerea semnificaiei datelor care circul n organizaia respectiv;
nelegerea cerinelor specifice modului de lucru din organizaie;
reprezentarea coerent i sugestiv a acestor informaii.

20
 Lum rea
ea l

Descriere verbal Analiza cerinelor

Ce (aspect al realitii) vrem s modelm?
Diagrama de structur Modelarea conceptual
a datelor Ce informaii sunt necesare n modelare?
Schema conceptual Proiectarea schemei conceptuale
Cum vom exprima (reprezenta) acel aspect al
realitii?
Schema detaliat Analiza funcionalitii
Reprezentarea propus ne permite s
efectum toate aciunile dorite?
Proiectarea la nivelul Definirea schemei
fizic Cum "traducem" reprezentarea n mediul de
modelare ales?
Analiza performanelor
Ct de bine lucreaz modelul (care este gradul
su de adecvare la realitatea modelat)?
Figura 4: Succesiunea fazelor n modelarea bazelor de date

#2 Sarcin de lucru: Criterii pentru un model de date optim

C. Fleming i B. von Halle (citai n [8]) au identificat cteva criterii pe care
ar trebui s le ndeplineasc un model de date pentru a fi considerat optim
Implementarea pe calculator
n raport cu realitatea modelat: corectitudine, simplitate, expresivitate,
neredundan, extensibilitate, integritate. Putei aduga i alte criterii?
Incercai s explicai aceste caracteristici i s descoperii eventuale
incompatibiliti ntre ele.

Instrumentul universal capabil s asigure realizarea acestor obiective

printr-o bun comunicare ntre specialitii care proiecteaz baza de date i
viitorii utilizatori ai acesteia este modelarea datelor. Cel mai frecvent
folosit model de date de nivel nalt este modelul entitate-relaie (Entity-
Relationship Model) iar cea mai larg utilizat reprezentare grafic a
21
acestuia (asupra careia vom reveni n capitolul urmtor) este diagrama
entitate-relaie (a se vedea Figura 5).

Adres Num
Num
a e
e

Elev Inva
Clasa
In

DataNaterii Locaie NrLocur

i

Figura 5: Diagrama entitate-relaie a bazei de date a unui liceu

#3 Sarcin de lucru: Diagrama ER

Examinai Figura 5 i incercai s creai o diagram similar pentru baza de
date a unei librrii / firme de inchiriere auto / agenii de organizare de
evenimente tiinifice.

2.4. Modelul conceptual al bazei de date

Definiie Proiectarea bazei de date la nivel conceptual =
= procesul de construire a unui model privind informaiile care circul ntr-o
organizaie, independent de orice implementare a acestora la nivel fizic.

Proiectarea conceptual a bazei de date constituie prima faz a

proiectrii i conduce la realizarea modelului conceptual. Acest model
este complet independent de orice detalii de implementare: ce SGBD, ce
programe de aplicaie (scrise n ce limbaj de programare) se vor folosi, pe
ce platform hardware i sub ce sistem de operare? Aceast faz a
proiectrii bazei de date se desfoar iterativ: fiecare variant a modelului
este testat n raport cu cerinele utilizatorilor (condiiile sau restriciile
formulate de acetia) pentru a verifica adecvarea modelului de date la
situaia real modelat.

#4 Sarcin de lucru: O baz de date pentru filarmonic

Cum construii modelul conceptual pentru baza de date a unei filarmonici?
Indicaie: filarmonica are ca angajai muzicieni, soliti, dirijori, personal
administrativ. Muzicienii cnt la instrumente muzicale, au un repertoriu i
particip la spectacole i turnee.

22
#5 Sarcin de lucru: "Arhimede": entitile i relaiile bazei de
date
Institutul "Arhimede" produce materiale didactice pentru coli. De exemplu,
departamentul su dedicat geometriei produce machete de figuri i corpuri
geometrice. Construii modelul conceptual al bazei de date a acestui
institut.

2.5. Modelul logic al bazei de date

Definiie Proiectarea bazei de date la nivel logic =
= procesul de construire a unui model privind informaiile care circul ntr-o
organizaie pe baza unui anumit model de date dar independent de
alegerea unui SGBD precum i de orice detalii de implementare la nivel
fizic.

Proiectarea logic a bazei de date este a doua faz a proiectrii i

conduce la realizarea modelului logic (de nivel nalt). Intruct pornete
obligatoriu de la modelul conceptual, deci se bazeaz implicit pe un anumit
tip de model de date: relaional, ierahic, orientat obiect etc., modelul logic
orienteaz proiectul bazei de date spre un anumit tip de SGBD: relaional,
ierarhic etc. fr a alege explicit ntre Ms Access i Oracle, de exemplu. n
continuare, detaliile de implementare fizic precum modul de stocare a
datelor, tipurile de indexare etc. sunt complet ignorate.
Pe parcursul acestei etape, modelul este permanent testat i
validat, cu ajutorul utilizatorilor, pentru a descoperi eventualele
neconcordane cu restriciile formulate de acetia. Tehnica folosit se
numete normalizare i urmrete asigurarea corectitudinii modelului logic
(de exemplu, prin eliminarea redundanelor n date, redundane care o
dat implementate pot genera erori n timpul operaiilor de actualizare a
bazei).
Proiectarea conceptual i proiectarea logic a bazei de date sunt
etape foarte importante, critice, pentru realizarea unui proiect bun al bazei
de date. Dac unul dintre ele nu reprezint corect aspectul modelat,
implementarea fizic a bazei de date va fi eronat i corectarea ulterioar:
aproape imposibil. De aceea, rafinarea modelului conceptual i a celui
logic este un proces iterativ, virtual infinit.

2.6. Modelul fizic al bazei de date

Definiie Proiectarea bazei de date
la nivel fizic =
= procesul de construire a unei specificaii privind
memorarea datelor din baza de date pe suporturile

23
fizice de memorie; sunt descrise: structura memoriei i metodele de
accesare menite s asigure accesul eficient la informaii.

Proiectarea fizic a bazei de date este ultima faz a proiectrii, cea

n care proiectantul alege modul concret de implementare a bazei de date.
Prima operaie const n alegerea unui anumit SGBD din clasa indicat
de modelul logic: ierarhic, relaional, hibrid etc. (din nou, modelul creat n
etapa anterior este esenial pentru desfurarea etapei curente). Urmeaz
comunicarea ntre modelul fizic (de nivel inferior) i cel logic, similar celei
dintre modelul logic i cel conceptual: orice decizie privind implementarea
fizic (ameliorarea performanelor, asigurarea securitii etc.) poate afecta
structura modelului logic. Cu toate acestea, modelul conceptual i modelul
logic trebuie s fie n continuare complet separate de modelul fizic al bazei
de date i fiecare trebuie s-i pstreze menirea sa: primele s rspund la
ntrebarea: "CE trebuie fcut"; ultimul la: "CUM trebuie fcut".
Aceast abordare a proiectrii bazelor de date este compatibil cu
arhitectura pe trei nivele a acestora, aa cum a fost ea stabilit de ANSI-
SPARC n 1975.

Schema
extern

Proiectarea la nivel logic / conceptual

Schema
conceptual

Schema
intern

Proiectarea la nivel fizic

Stocare
fizic

Figura 6: Modelarea datelor i arhitectura ANSI-SPARC

24
#6 Sarcin de lucru: "Hefaistos": un service auto;
de la sursa de date la implementare n Ms Access
Un service auto poate repara automobile, maini sport, vehicule de
teren, furgonete, microbuze, camioane i autocare.
a) Proiectai un formular cu ajutorul cruia eful fiecrui atelier de reparaii
(mecanic, electric, tinichigerie etc.) s nregistreze fiecare vehicul admis
pentru reparaii.
b) Preluai informaiile din formulare i construii cel
puin trei scheme pentru baza de date a service-ului.
c) Alegei una dintre ele i implementai proiectul n
Ms Access..

25
CAPITOLUL 3: MODELUL CONCEPTUAL AL
BAZELOR DE DATE RELATIOANLE
3.1. Prima etap a modelrii conceptuale
Aa cum am vzut n capitolul anterior, proiectarea unei baze de date
incepe cu analiza situaiei reale care trebuie modelat prin baza de date.
Aceast analiz necesit un dialog ntre proiectantul bazei de date i viitorii
ei utilizatori. Astfel, sunt puse n evident:
cerinele utilizatorilor privind datele care trebuie stocate i
administrate;
cerinele utilizatorilor privind operaiile care trebuie efectuate cu
aceste date.
Etapa urmtoare const n realizarea modelului conceptual al bazei
de date. n cazul modelului relaional, se ncepe cu o descriere detailat a
entititilor i atributelor, a relaiilor dintre entiti i a condiiilor pe care
trebuie s le ndeplineasc. Aceast descriere poate mbraca mai multe
forme schema conceptual, diagrama entitate-relaie (diagrama ER).

3.2. Entiti i instane

Conform Dicionarului Explicativ al Limbii Romne: o entitate este un
coninut de sine stttor, o existen determinat (ca ntindere, importan,
valoare etc.). In literatura dedicat bazelor de date exist mai multe definiii
pentru acest termen:

Definiii Entitate =
= un "lucru" sau un "obiect" din lumea real care poate fi distins (deosebit)
de toate celelalte lucruri sau obiecte.
= un obiect (precum o rachet, un tablou), un eveniment (precum naterea
unei persoane, marcarea unui gol), o activitate (producia de oel a unei
uzine, nchirierea unei maini) din lumea real care poate fi descris() prin
caracteristici bine definite (despre care exist date care pot fi stocate).

Vom face distincie ntre conceptele de entitate i instan a unei

entiti. Aceast distincie este similar celei dintre tipul de dat i valoare
ntr-un limbaj de programare.

Definiii Entitate i Instan

Prin entitate nelegem mulimea tuturor elementelor de un anumit tip (care
prezint aceleai caracteristici distinctive).
Prin instan a unei entiti nelegem un singur element, bine
individualizat, unic, din mulimea elementelor care formeaz entitatea
respectiv.
26
 (E) (e1, e2, e3)

Figura 1: O entitate (E) i 3 instane ale sale (e1, e2, e3)

Exemple
1) Fiecare client al unei bnci este o instan a entitii Clieni; fiecare
tablou dintr-un muzeu este o instan a entitii Tablouri,
2) Fiecare curs predat intr-o facultate este o instan a entitii
CursuriUniversitare etc.

#1 Sarcin de lucru: Entiti i instane

Formulai exemple de entiti specifice unui magazin ca unitate comercial,
respectiv magazinului ca ntreprindere unde lucreaz mai muli salariai.

Atenie
Entitile dintr-o baz de date pot fi disjuncte sau nu; n al doilea caz
avem de a face cu subentiti (de exemlu, entitile Piloi i
MecaniciDeBord sunt disjuncte i sunt subentiti ale entitii
PersonalNavigant).
Intr-o baz de date pot exista entiti a cror existen este determinat
de existena altora (de exemplu, entitatea PersoaneInIntretinere depinde de
entitatea Salariai); primele se numesc entiti dependente, celelalte se
numesc entiti principale.

#2 Sarcin de lucru: Entiti disjuncte; entiti dependente

a) Fie baza de date a unui liceu i entitile Persoane, CadreDidactice,
Elevi, PersonalAdministrativ. Identificai entitile disjuncte. In ce situaie se
afl entitile Persoane, CadreDidactice i PersonalAdministrativ?
b) Fie baza de date a unui club dotat cu sli de gimnastic, saloane de
cosmetic, solare i saun. Identificai entitile disjuncte, subentitile,
precum i entitile principale i pe cele dependente.
c) Fie baza de date a unei filarmonicii. Ce entiti cuprindea modelul
conceptual pe care l-ai realizat? Care dintre ele sunt entiti principale i
care sunt entiti dependente? Exist subentiti?
27
3.3. Atribute
Definiie Atribut =
= o caracteristic a unei entiti.

Un atribut posed un nume i pentru fiecare instan a entitii

poate lua o valoare dintr-o mulime fixat de valori, numit domeniul de
valori ale atributului.

Exemplu
Fie entitatea Tri; considerm atributele Nume, Continent, Capital,
FormDeGuvernmnt, Suprafa, SarbtoareNaional. Tabelul 1 prezint
cteva instane ale acestei entiti i valorile luate de atribute.

Conti- Forma de NrKm Srbtoare

NumeTar Capitala
nent guvernmnt Ptrai naional
Oslo Monarhie
Norvegia Europa 324219 05/17
constituional
Tokyo Monarhie
Japonia Asia 370073 04/29
constuitiional
Luxembu Monarhie
Luxemburg Europa 2586 06/23
rg constuitiional
Bucureti Republic
Romnia Europa 237500 12/01
constituional
America Brasilia Republic
Brazilia 8511965 09/07
de Sud federal
Viena Republic
Austria Europa 83849 10/26
federal
America Rio de Republic
Argentina 2776889 05/25
de Sud Janeiro prezidenial
Statele America Washing- Republic
9363123 07/04
Unite de Nord ton prezidenial
Paris Republic
Frana Europa 547026 07/14
prezidenial
Nairobi Republic
Kenya Africa 582645 12/12
prezidenial

Tabelul 1: Instanele entitii Tri i valorile atributelor sale

Atributele se pot clasifica dup complexitate n:

atribute compuse i atribute simple sau elementare, dup cum ele
se mai pot descompune sau nu n alte atribute, de mai mic complexitate.
Exist atribute care nu pot fi dect simple (atributele Capital, Suprafat,
Continent ale entitii Tari). Exist ns atribute care pot fi considerate fie
simple, fie compuse. De exemplu: atributul DataNasterii cu valorile: 1
28
ianuarie 2000, 2 Mai 1990 etc. poate fi privit fie ca un atribut simplu, fie ca
unul compus din atributele Zi, Lun, An. Este indicat s l tratm ca un
atribut compus dac prevedem necesitatea de a avea acces direct la luna
sau anul de natere al unei persoane nregistrate n baza de date. Dac
ns o astfel de necesitate nu este probabil i dac dorim s simplificm
structura entitii (i deci a bazei de date) atunci este preferabil s l tratm
ca atribut simplu;

Entitate Elev

Atribute compuse NumeElev Adresa

Strada Oras CodPostal

Atribute simple Nume Prenume NumeStr NrStr NrApt Sector

Figura 2: Exemple de atribute simple i compuse

Atributele se pot clasifica dup mulimea de valori n:

atribute cu valori unice i atribute cu valori multile, dup cum ele
pot lua pentru instanele entitii respective cte o singur valoare (de
exemplu, atributele Capital, Suprafat, Continent ale entitii Tri) sau,
dimpotriv, pentru unele instane pot lua cte o singur valoare, pentru
altele mai multe valori iar pentru altete nici o valoare (de exemplu, atributul
OrasCuMinimum2MilioaneLocuitori al entitii Tri). Cnd este cazul, se pot
defini limite inferioare i/sau superioare pentru numrul de valori pe care le
poate lua un astfel de atribut pentru o instan oarecare (de exemplu,
putem specifica faptul c atributul NrTelefon al entitii Persoane poate lua
minimum o valoare telefonul de serviciu i maximum trei.

#3 Sarcin de lucru: Atribute cu valori multiple

Identificai atributele cu valori unice i pe cele cu valori multiple care apar n
Figura 2.

Atributele se pot clasifica dup stabilitate n:

atribute de baz i atribute derivate, dup cum ele au valori de sine
stttoare sau care pot fi calculate din valorile altor atribute. De exemplu,
s considerm entitile corelate Cri, cu atributul NumrAutori i Autori,
cu atributul Titlu; atributul NumrAutori este un atribut derivat: valorile pe
care le ia pentru diferite instane ale entitii Cri pot fi calculate pe baza
numrului de apariii ale atributului Titlu pentru diferite instane ale entitii
Autori.
29
 Atenie
Asupra modului de lucru cu atribute cu valori multiple, respectiv derivate
vom reveni n paragraful referitor la normalizarea bazelor de date.

#4 Sarcin de lucru: Tipuri de atribute

La o policlinic se nregistreaz date despre: medicii i asistenii angajai,
pacienii consultai de fiecare medic, datele consultaiilor, medicamentele
prescrise. Reele pot fi reete noi, urmare a consultaiei sau reluri
(integrale sau pariale) ale reetei prescrise ca urmare a unei consultaii.
Acestea pot fi semnate i de ali doctori, nu neaprat de cel care a fcut
prescripia iniial. Reetele indic datele pacientului, diagnosticul, numele
medicamentului i concentraia lui, doza, i numrul total de pastile, fiole
etc., modul de administrare, periodiciatea eliberrii reetelor repetate.
a) Stabilii ce entiti fac parte din baza de date.
b) Identificai cel puin cte 3 atribute din fiecare categorie, conform
criteriilor de clasificare de mai sus.

3.4. Un atribut special: identificatorul unic

Utilizarea instanelor unei entiti ridic dou probleme foarte
importante:
modul de adresare a fiecrei instane a unei entiti;
determinarea instanelor care se repet.
S presupunem c dispunem de o
baz de date a trenurilor care circul n
Romnia i vrem s prelucrm informaiile
legate de un rapid care leag oraul Iai de
Bucureti. Ca s ne referim la aceast
instan a entitii Trenuri ar trebui s
enumerm toate valorile pe care le iau
atributele entitii. Dac ar fi 5 sau 10 atribute nu ar fi prea greu; dar dac
ar fi 50? Pentru a simplifica referirea la instanele unei entiti s-a recurs la
mecanismul identificatorului unic (sau al cheii primare).

Definiie Identificatorul unic (sau cheie primar) =

= un atribut sau cea mai mic mulime de atribute ale unei entiti care iau,
pentru fiecare instan a entitii respective, o valoare i numai una. Atunci
cnd nici un atribut sau grup de atribute ale entitii rezonabil de numeros
nu ia valori disticte pentru fiecare instan a acesteia se poate aduga un
atribut convenional care s ndeplineasc aceast condiie. De obicei,
acest atribut este denumit cu ajutorul prefixelor cod sau id.

30
 Exemple
1) Pentru entiti precum Elevi, Profesori, Angajai un exemplu de
identificator unic este codul numeric personal; un contraexemplu: numele
(chiar nsoit de prenume!) sau data naterii. Se poate utiliza i atributul
convenional CodElev (CodProfesor etc.), cu valori formate din iniialele
numelui i prenumelui, urmate de numere distincte formate din 2 sau 3 cifre
2) Pentru entitatea Comenzi putem folosi un atribut convenional (de
exemplu: CodComand, cu valori numere distincte de 5 cifre) sau putem
folosi trei atribute ale sale: NumeFurnizor, NumeClient, DataEmiterii.

O entitate (de exemplu: Angajai, avnd atributele Nume,

IniialaTatlui, Prenume, Adres, Funcie, CodDepartament, Salariu,
DataAngajrii) poate avea mai multe atribute care pot juca rolul de
identificator unic; de exemplu:
1. Nume, Prenume, Adres;
2. Nume, Prenume, IniialaTatlui, Adres;
3. Nume, Prenume, Funcie, CodDepartament
4. Nume, Prenume, Adres, Funcie, CodDepartament.
Toate aceste combinaii de atribute se numesc chei candidate. Prima
combinaie ndeplinete condiia de minimalitate (pe care a doua nu o
poate satisface). Ca atare, dintre cele
dou, numai ea poate constitui un
identificator unic sau o cheie primar
pentru entitatea Angajai, n timp ce a
doua este numai o cheie candidat. Acelai
lucru este valabil i pentru a treia i a
patra combinaie de atribute, ca i pentru
prima i a patra combinaie de atribute.
Dac avem de ales ntre cheile candidate (1) i (3) pe care o
preferm? In general, alegem cheia candidat:
compus din cel mai mic numr de atribute;
compus din atribute ale cror valori nu sunt susceptibile de modificri
n viitor;
care nu este susceptibil s-i piard unicitatea n viitor;
care are valorile cele mai mici (cuvintele cele mai scurte, numerele cu
cel mai mic numr de cifre etc.);
care este cel mai uor de utilizat.

#5 Sarcin de lucru: Entiti, atribute i chei primare

a) Dai exemple de instane ale entitii Elevi.
b) Dai exemple de valori ale atributului Vitez al entitii Microprocesor.

31
c) Descriei atributele urmtoarelor entiti i identificai un atribut / grup de
atribute cu proprietatea de identificator unic: (i) persoan; (ii) abonat
telefonic; (iii) automobil; (iv) calculator.

#6 Sarcin de lucru: Chei candidat

a) Determinai cele trei chei candidat ale relaiei R1 (Indicaie: una dintre
ele este format din dou atribute).
b) Determinai cele dou chei candidate ale relaiei R2.

A B C D A B C D E
a1 b1 c1 d1 a1 b1 c1 d1 e1
a2 b3 c1 d2 a2 b1 c1 d1 e2
a3 b4 c2 d2 a3 b1 c2 d1 e1
a4 b2 c2 d1 a4 b2 c1 d1 e1
R1 R2

#7 Sarcin de lucru: Chei candidat

Creai un exemplu de relaie cu exact patru atribute i patru instane (ca n
Sarcina de lucru #6) dar cu o singur cheie candidat, constnd din primele
trei atribute. Atenie: nici unul dintre tripletele din primele trei coloane nu
distinge cele patru instane ale entitii.

#8 Sarcin de lucru: Relaii n bazele de date i relaii algebrice

Explicai de ce:
a) ntre instanele unei entiti nu exist relaie de ordine?
b) nu sunt admise duplicate n instanele unei entiti?
c) o entitate poate avea mai multe chei candidate dar o singur cheie
primar?

3.5. Entitate sau atribut?

Suntem adeseori confruntai cu problema: fiind
dat o informaie care trebuie inclus n baza de date,
cum o modelm? Ca entitate sau ca atribut al unei
entiti deja existente? Spre exemplu: adresa unui
cadru didactic ar trebui s fie un atribut al entitii
CadruDidactic sau o entitate (corelat cu entitatea
CadruDidactic)?
Rspunsul depinde de:
semantica (semnificaia, nelesul) datelor,
modul n care vom utiliza informaia respectiv.

32
 n exemplul nostru, adresa va fi modelat ca entitate n oricare dintre
urmtoarele cazuri:
cadrul didactic are mai multe adrese (locuina din localitate, o locuin
de vacan, o alt coal la care pred etc). Motivul: ntr-o baz de date
corect proiectat (normalizat) un atribut nu poate lua simultan mai multe
valori pentru aceeai instan a unei entiti;
structura adresei (localitate, strad, sectorul/judeul etc.) este
important (de exemplu, trebuie s extragem din baza de date cadrele
didactice care locuiesc ntr-o anumit localitate sau ntr-un anumit sector
din Bucureti). Motivul: valorile atributelor sunt atomice.
In oricare dintre situaiile complementare (o singur adres, tratarea
adresei ca un tot unitar), este indicat modelarea prin atribut.

3.6. Relaii
Oridecteori un atribut al unei entiti se refer la alt
entitate din baza de date se stabilete, de fapt, o relaie ntre
cele dou entiti (de exemplu, atributul Destinaie al entitii
Trenuri se refer la oraul ctre care circul un tren, indicnd astfel
Hand osh
relaie
ak.ico
ntre entitatea Trenuri i entitatea Orae). Cnd proiectm baza de date,
aceste referiri nu ar trebui s fie reprezentate ca atribute ale entitilor ci ca
relaii (att n sensul real ct i n sensul matematic al cuvntului) ntre
entiti. Atributele prin care se stabilete aceast relaie se numesc chei
sau cmpuri de legatur.

Definiie Relaie ntr-o baz de date =

= o legtur logic ntre dou sau mai multe entiti.

Exemple
In baza de date a unei firme de transport putem identifica urmtoarele
relaii: un ofer Conduce o main; o marf AreCaDestinaie o localitate;
o main AjungeIn mai multe localiti.

#9 Sarcin de lucru: Entiti sau relaii?

O companie de publicitate are un departament
dedicat instruirii propriilor angajai. Trebuie construit
o baz de date care s stocheze informaii despre:
(1) cursurile oferite angajailor; (2) cursurile la care
cursantul trebuie s fi participat deja pentru a putea
nelege un anumit curs; (3) ofertele de cursuri; (4) instructori; (5) angajai;
(6) participrile angajailor la cursuri. Care dintre seturile de informaii (1)
(6) constituie entiti i care relaii ntre entiti?

33
#10 Sarcin de lucru: Relaii ntr-o baz de date
In Figura 3 sunt date dou relaii care pot face parte din baza de date a
unei bnci. Specificai: (a) atributele fiecrei relaii; (b) instanele fiecrei
relaii; (c) posibile domenii de definiie pentru atribute.

NrCon TipCont SoldCont Num Prenume Cod Cont

t e
12345 economii 12000 Sava Paul 901-22 12345
23456 investiii 1000 Bratu Maria 805-11 23456
34567 economii 25 Bratu Maria 805-11 12345

Figura 3: Dou entiti din baza de date a unei bnci

#11 Sarcin de lucru: Entitate / atribut / relaie

Examinai urmtoarele elemente: elev, Radu Stroe, 43%, repriz,
baz de date, joac, Stiinele Naturii, 12:45, vrst, 18, Universitatea
Craiova, funda.
a) Care dintre ele este: entitate / atribut / relaie?
b) Care dintre ele este entitate / instan a unei entiti?
c) Identificai relaiile dintre urmtoarele grupuri de entiti: (i) client-furnizor;
(ii) main de curse-pilot; (iii) regizor-actor; (iv) ar-form de guvernmnt;
(v) traseu turistic turist; (vi) traseu turistic- agentie de turism.

3.7. Schema conceptual i diagrama entitaterelaie

Modelul conceptual al bazelor de date relaionale poate fi reprezentat
printr-o schem conceptual sau printr-o diagram entitate-relaie.

Atenie
Entitile i atributele sunt denumite prin substantive; relaiile dintre
entiti sunt denumite prin verbe urmate de prepoziii; exist situaii n care
ordinea entitilor aflate n relaie este important (atunci avem de fapt
dou relaii care trebuie citite de la stnga la dreapta, respectiv de la
dreapta la stnga) i situaii n care ordinea nu este important.
Numele date entitilor, respectiv relaiilor, trebuie s fie unice la
nivelul bazei de date. Numele atributelor trebuie s fie unice numai la
nivelul aceleiai entiti; eventualele confuzii la nivelul bazei de date se
rezolv prin cuplarea numelui atributului cu numele entitii. Este totui
indicat pentru simplificarea referirilor ca cel puin numele atributelor
care constituie cheile primare s fie unice i la nivelul bazei de date.

34
 Schema conceptual a unei baze de date const din numele
entitilor urmate ntre acolade de numele atributelor respective. Cheile
primare sunt indicate prin subliniere.
Tabelul 2 i Tabelul 3 prezint conveniile de reprezentare grafic (n
diagramele ER) a entitilor, atributelor i relaiilor din modelul conceptual al
unei baze de date relaionale.

Reprezentare
Exemple
grafic

Entitate principal dreptunghi simplu

Salariai
Entitate
dreptunghi dublu
dependent

Atribut elips

PersInIntreinere
Atribut cu valori
elips dubl
multiple

Atribut derivat elips punctat

Culoare
elips i subliniere cu
Cheie primar linie continu

elips i subliniere cu
Cheie extern linie punctat

Relaie romb
Telefon
Tabelul 2: Un set de convenii pentru diagrama entitate-relaie

Vechime
35

NrMatric
CodClie
PredL
 Reprezentare
Exemple
grafic

Entitate dreptunghi cu colurile

rotunjite
Atribut Salariat
asterisc
obligatoriu * Adres
Atribut opional cerc o Durat
Cheie primar diez # CNP

linii cu i fr bifurcaii
Relaie

Tabelul 3: Alt set de convenii pentru diagrama entitate-relaie

Exemplu se vinde vinde

Figura 4 prezint schema conceptual i diagramele entitate-relaie
(realizate conform conveniilor de mai sus) pentru se
baza de vinde
vinde date a unei
companii cinematografice care deine mai multe studiouri unde se produc
filme n care joac actori.
se vinde vinde
Actori = {IdActor, Nume, Prenume};
Studiouri = {Nume, Adres}; se vinde vinde
Filme = {Titlu, An, Durat, Tip}.
se vinde vinde
(a)

36
 IdActor Num Prenume
e

Titlu An
Actori
JoacIn

Num Filme
e

Durat
Studiouri Produc
Tip

Adres

(b)

ACTOR FILM STUDIO

# Nume
IdActor joac este # Titlu se produce # Nume
* Prenume # An
* n jucat de oTip
Durat produce Adres
*
*

(c)

Figura 4: Compania cinematografic "Gable-Lancaster":

(a) schema conceptual; (b) i (c) diagrame entitate-relaie

#12 Sarcin de lucru: Diagrame ER versus schema

conceptual
Comparai modurile de reprezentare a modelului conceptual al unei baze
de date relaionale; ce avantaje / dezavanatje are fiecare?

#13 Sarcin de lucru: De la schema conceptual la diagrama

ER
Construii diagrama entitate-relaie pentru urmtoarea schem
conceptual: Preedinte= {Identificator, Nume, AfilierePartidPolitic,
StatDeProvenien}, Administraie = {Cod, IdentificatorPreedinte,
DatInceput, DatIncheiere, NumePremier}, Stat = {Cod, Nume,
DataAdmiteriiInUniune, Suprafa, Populaie, Capital}

37
#14 Sarcin de lucru: Atribut sau relaie n diagrama ER?
Construii diagrama entitate-relaie pentru fiecare dintre urmtorele cazuri:
a) un brbat (care are nume, adres, ocupaie) este obligatoriu cstorit cu
o femeie; o femeie (cu aceleai atribute) este obligatoriu cstorit cu un
brbat;
b) cele dou entiti au aceleai atribute ca la punctul (a) dar pot fi i
celibatari;
c) cele dou entiti au aceleai atribute ca la punctul (a), poti fi i
celibatari, pot avea sau nu copii (n primul caz, apare doar numrul copiilor)

#15 Sarcin de lucru: Scheme conceptuale i diagrame ER

a) Construii diagrama entitate-relaie pentru baza de date a clasei / liceului
n care nvati.
b) Construii diagrama entitate-relaie pentru baza de date a unei companii
de telefonie mobil / a unui service pentru repararea calculatoarelor / a unei
librrii.

#16 Sarcin de lucru: Modelul ierarhic vs modelul relaioanal

Figura 5 prezint modelul ierarhic al unei baze de date
privind angajaii companiei de telefonie mobil MobilTel:
compania are mai multe departamente; fiecare
departament are un numr de angajai, gestioneaz o
serie de proiecte i i desfoar activitatea n mai
multe birouri; pentru fiecare angajat se cunosc toate
slujbele deinute anterior precum i salariile obinute n
timpul fiecreia dintre ele; n fiecare birou funcioneaz mai multe telefoane
(cte unul pentru fiecare angajat care lucreaz n respectivul birou).
Baza de date conine urmtoarele informaii:
pentru fiecare departament: codul, denumirea i bugetul alocat;
pentru fiecare angajat: CNP, numele, prenumele, adresa, funcia, codul
proiectului la care lucreaz, numrul biroului n care lucreaz, numrul
telefonului de serviciu precum i denumirea serviciilor deinute anterior
i salariile de ncadrare primite n fiecare serviciu;
pentru fiecare proiect: codul i bugetul alocat;
pentru fiecare birou: numrul (unic la nivelul companiei), locaia
(cldirea i etajul), toate numerele de telefon din birou.
Construii schema conceptual i diagrama entitate-relaie.

38
 Departamente

Angajati Proiecte Birouri

Servicii detinute Telefoane

Salarii primite

Figura 5 : Modelul ierarhic al bazei de date Mobitel

#17 Sarcin de lucru: Diagrame i grafuri

O diagram entitate-relaie poate fi privit ca un graf. Cum interpretai din
punct de vedere al structurii organizaiei descrise prin diagrama entitate-
relaie urmtoarele afirmaii:
a) graful nu este conex;
b) graful este aciclic.

Atenie
n continuare, pentru reprezentarea grafic a modelului conceptual al
bazelor de date vom utiliza conveniile din Tabelul 2 deoarece considerm
c asocierea unei anumite forme geometrice pentru fiecare element al
modelului mrete sugestivitatea reprezentrii.

3.8. Gradul i cardinalitatea relaiilor

Relaiile sunt caracterizate prin grad i cardinalitate (sau tip).

Definiie Gradul unei relaii =

= numrul de entiti care particip la relaia respectiv.

Dup grad, relaiile pot fi

binare (ntre dou entiti; de exemplu: relaia JoacIn este o relaie
binar ntre entitile Actori i Filme);
ternare (ntre trei entiti; de exemplu: relaia LanseazMelodia este o
relaie ternar ntre entitile Compozitori, Textieri i Soliti);

39
 n-are (ntre mai multe entiti; de exemplu: relaia Monteaz este o
relaie de gradul cinci ntre entitile Regizori, Scenografi,
DesigneriCostume, Actori i PieseDeTeatru).

#18 Sarcin de lucru: Gradul unei relaii

Ce grad au relaiile dintre: (1) elevi i clase; (2) copiii i
prini; (3) juctori de tenis i arbitri (4) juctori de volei i
arbitri?

Definiie Cardinalitatea (tipul) unei relaii

binare =
= numrul de instane ale celor dou entiti care sunt asociate prin relaia
respectiv.

S considerm dou entiti E1 i E2; dup cardinalitate (sau tip),

relaiile dintre cele dou entiti pot fi
1 1 (one-to-one);
1 m (one-to-many);
n m (many-to-many).

Definiie Relaie 11 =
= o relaie ntre dou entiti E1 i E2 n care unei instane a entitii E 1 ii
corespunde o singura instan din entitatea E2 i reciproc.

Definiie Relaie 1m =
= o relaie ntre dou entiti E1 i E2 n care unei instane a entitii E 1
(numit entitate dominant) ii pot corespunde mai multe instane din
entitatea E2 dar unei instane din E2 nu-i poate corespunde dect cel mult
o instan din E1 .

Definiie Relaie nm =
= o relaie ntre dou entiti E1 i E2 n care unei instane a entitii E1 ii
pot corespunde mai multe instane din entitatea E 2 i, reciproc, unei
instane din entitatea E2 i pot corespunde mai multe instane din entitatea
E1 .

Exemple
40
In baza de date a unui liceu putem avea urmtoarele tipuri de relaii:
1-1: un elev are o singur foaie matricol (n care sunt nregistrate notele
sale); o foaie matricol aparine unui singur elev;
1-m: ntr-o clas inva mai muli elevi dar un elev nva ntr-o singur
clas;
n-m: un profesor pred la mai multe clase; la o clas predau mai muli
profesori.

#19 Sarcin de lucru: Cardinalitatea unei relaii

a) Ce cardinalitate au relaiile dintre: (1) soi i soii; (2) elevi i clase; (3)
copiii i prini; (4) juctori i echipe.
b) Ce cardinalitate au relaiile din diagrama entitate-relaie din Figura 6.
(Ordinea n pereche este important.)

Num Adres Sofer Data

e

CNP ValoarePagub

Client Accident

Dein Produ
e ce
Automobil

NrInmatricular Marc AnInmatriculare

e

Figura 6: Baza de date a unei agenii de asigurri auto

#20 Sarcin de lucru: Relaii: grad i cardinalitate

Figura 7 reprezint diagrama entitate-relaie a bazei de date a unui
aeroport.
a) Enumerai entitile, relaiile dintre ele i atributele acestora.
b) Ce tipuri de atribute observai? Care sunt cheile primare?
c) Ce grad i ce cardinalitate au relaiile?

41
 NrBile
t

NrPoart Pasageri PrimescLocu

ri

Pori
Imbarcare Pleac

DataPlecri Zboruri AuLoc Locuri

i uri

Ziua Ora NrZbo NrLo

r c

Figura 7: Baza de date a aeroportului "Montgolfier"

#21 Sarcin de lucru: Exemple de relaii: grad i cardinaliti

a) Dai exemple de relaii binare i ternare din baza de date a unui club de
volei.
b) Dai exemple de relaii 1-1, 1-m i n-m din baza de date a unei
institut de nvare a limbilor strine.

3.9. A fi sau a nu fi n modelul de date?

n etapa de modelare, proietantul bazei de date poate face o serie de
erori:
omiterea unor entiti, atribute i relaii necesare rezolvrii problemelor
legate de aspectul modelat;
includerea unor entiti, atribute i relaii parazite, care aglomereaz n
mod inutil modelul.
Pentru a le evita, este suficient s rspund la ntrebrile:
exist mai multe exemplare din entitatea respectiv? (Da, exist mai
muli elevi care inva intr-o clas i mai multe clase n coal, dar
exist o singur sal de sport i un singur amfiteatru);
Entitatea respectiv este semnificativ pentru baza de date? (Da,
cursurile liceale sunt urmate de elevi i nu de actori sau arhiteci,
deci entitile actori, arhiteci" nu trebuie incluse n baza de date a
liceului);
Atributul respectiv este semnificativ pentru baza de date? (Da, numrul
de banci din sala de clas trebuie nregistrat pentru c induce o

42
 restricie asupra numrului de elevi care pot nva n locaia respectiv;
n schimb, nu trebuie s nregistrm culoarea bncilor pentru c
aceast caracteristic nu are relevan pentru situaia modelat de
baza de date).

3.10. Modelul relaional: fundamentarea teoretic

Conceptul matematic aflat la baza modelului relaional al bazelor de
date este cel de relaie:

Definiie Relaie
Se numete relaie peste mulimile M1, M2, Mn orice submulime a
produsului lor cartezian: R M1, x M2, x x Mn

Exemplu
Fie mulimile Marca = {Dacia, Ford, Fiat, Audi, Opel, Volvo}, Tip = {benzin,
motorin}, CapacCil = {1100, 1200, 1300, 1400, 1600}, NrLoc = {4,5}, NrUi
= {2, 4, 5}. Atunci, entitatea Automobil poate fi reprezentat ca o relaie
peste aceste mulimi:
Automobil Marca x Tip x CapacCil x NrLoc x NrUi
Iat cteva instane ale acestei entiti: (Dacia, benzin, 1400, 5, 4),
(Dacia, motorin, 1400, 5, 4), (Dacia, benzin, 1100, 5, 4), (Dacia,
motorin, 1400, 5, 5), (Ford, motorin, 1400, 5, 5), (Ford, benzin, 1600, 5,
4), (Fiat, benzin, 1300, 5, 4), (Fiat, benzin, 1100, 5, 4), (Audi, motorin,
1600, 5, 4), (Opel, benzin, 1400, 5, 5), (Volvo, benzin, 1400, 5, 5),
(Volvo, motorin, 1600, 5, 4).

Dac generalizm exemplul de mai sus obinem:

E A1 x A2 x x An
unde am notat cu E entitatea i cu A1, A2, , An mulimile de valori
(domeniile) atributelor sale. Un element al acestei relaii (adic un tuplu al
produsului cartezian) reprezint o instan ei a entitii E i const din
valori particulare ale atributelor.
Pentru simplitatea reprezentrii, entitile nu sunt reprezentate ca
mulimi de tupluri (ca n exemplul nostru de mai sus) ci ca tabele (vezi
Tabelul 4), tot aa cum, n loc s notm cu <(3,5) instana relaiei de ordine
< N X N dintre numerele naturale 3 i 5, scriem 3 < 5.

Marca Tip CapacCil NrLoc NrUi

Dacia benzin 1400 5 4
Dacia motorin 1400 5 4
43
 Dacia benzin 1100 5 4
Dacia motorin 1400 5 5
Ford motorin 1400 5 5
Ford benzin 1600 5 4
Fiat benzin 1300 5 4
Fiat benzin 1100 5 4
Audi motorin 1600 5 4
Opel benzin 1400 5 5
Volvo benzin 1400 5 5
Volvo motorin 1600 5 4
Tabelul 4: O entitate, o relaie matematic, o tabel

Puterea i elegana modelului relaional este dat de faptul c i relaiile

dintre entiti pot fi reprezentate tot prin tabele. Tabelul 5 ilustreaz relaia
JoacIn dintre entitile Actori i Filme din exemplul privind compania
cinematografic "Gable-Lancaster".

Nume Adresa Titlu An TipRol NrScen

e
Brad Pitt 1, Dawn Ave. Babel 2007 principal 50
Angelina 1, Dawn Ave. Tomb 2001 principal 45
Jolie Rider
Viigo 342, Sunset Stapnul 2002 secundar 20
Mortensen Ave. Inelelor
Lauren 5, Main Str. Fetele 2000 principal 40
Graham Gilmore
Lauren Bad 2003 secundar 15
Graham Santa
Tabelul 5: Reprezentarea prin tabel a relaiei JoacIn

Atenie
Orice entitate este reprezentat printr-o tabel; numele entitii devine
numele tabelei;
Oricrui atribut al unei entiti i corespunde o coloan (numit i cmp)
n tabela corespunztoare entitii; numele atributului devine antetul
coloanei respective din tabel;
Orice instan a unei entiti este reprezentat printr-un rnd n tabela
asociat entitii, numit nregistrare; fiecare celul din nregistrare
conine valoarea luat de atributul corespunztor pentru instana resp.
Exist o diferen ntre tabelele care reprezint entiti i cele care
reprezint relaii dintre entiti: n al doilea caz unele dintre coloane
corespund atributelor relaiei dintre entiti (aici: TipRol i NrScene) dar

44
 altele repet atribute ale entitilor corelate (aici: coloanele Nume,
Adresa, respectiv Titlu, An).

3.11. Stabilirea relaiilor ntre entiti

La nivelul modelului conceptual, cardinalitatea relaiilor este o
caracteristic instrinsec a acestora; atunci cnd proiectm ns baza de
date relaiile dintre entiti trebuie definite n mod efectiv. Acest lucru se
realizeaz n mod diferit pentru fiecare tip de relaie.
Fie dou entiti U i V i fie T 1 i T2 tabelele prin care sunt
reprezentate (conform conveniilor din paragraful anterior). Pentru
simplitate, vom presupune c entitile aflate n relaie sunt identificate prin
chei primare formate dintr-un singur atribut.

3.11.1. Rezolvarea relaiilor 1-1

S presupunem c proiectm baza de date a unei
policlinici. n fiecare cabinet lucreaz un singur medic i o
singur asistent. Este evident c din punctul de vedere
al ocuprii cabinetelor, al lucrului n echip cele dou
entiti, Medici i Asistente, se afl n relaia 1-1.

Metod: Stabilirea unei relaii 11

Pentru a stabili o relaie 1-1 ntre dou entiti (aici: relaia LucreazCu
ntre entitile Medici i Asistente) procedm astfel:
pentru ambele entiti utilizm aceelai atribut pe post de cheie primar
(aici atributul CodCabinet);

CodCabin CodCabin
et et
Grad

Medici 1 Lucreaz 1 Asistente

Cu

Prenume Nume

Nume Prenume

Figura 8: O relaie de tip 1-1

45
 Figura 9: Implementarea unei relaii 1-1 n Ms Access

3.11.2. Rezolvarea relaiilor 1-m

n acest caz, trebuie s definim noiunea de cheie extern:

Definiie Cheie extern

Fie dou entiti U i V (de exemplu: Clase i Elevi) avnd atributele a1
(cheie primar), a2, , an i respectiv b1 (cheie primar), b2, , bm, a1,
(de exemplu: CodClas, Locaie, nrBanci, nrTable, respectiv CNP, Nume,
Prenume, Adresa, CodClas). Prin cheie extern nelegem un atribut al
entitii V a crui mulime de valori coincide cu mulimea valorilor cheii

46
primare din entitatea U (aici: atributul CodClas este cheie primar pentru
entitatea Clase i cheie extern pentru entitatea Elevi).

Atenie
In diagrama entitate-relaie, cheile externe se reprezint la fel ca i
cheile primare, dar sublinierea se face punctat.
Observm c n timp ce, la nivelul entitii U, valorile luate de atributul
a1 sunt unice (el fiind cheie primar), la nivelul entitii V valorile luate de
atributul a1 pot fi duplicate (el fiind cheie extern).
Din punctul de vedere al relaiei 1-m dintre entitile U i V, entitatea
U poate fi privit drept entitate principal iar entitatea V drept entitate
secundar.

#22 Sarcin de lucru: Chei primare i chei externe

a) Pentru entitile Judete i Orase, indicai atributele care pot juca rolul de
cheie primar, respectiv extern.
b) Gsii dou entiti aflate n relaia 1-m i specificai cheia primar i
cheia extern.
c) Aceeai intrebare pentru cazul unor chei formate din mai multe atribute.
d) Explicai de ce n cmpul unei chei primare nu sunt admise duplicate dar
n cmpul unei chei externe sunt admise?

Observm c apariia atributului CodClas printre atributele entitii

Elevi ne permite s evideniem caracteristicile clasei n care nva fiecare
elev fr a le mai repeta pentru fiecare dintre ei. Acest lucru este posibil
prin stabilirea relaiei InCareInva ntre entitile Clase i Elevi. Am artat
mai sus c aceast relaie este de tip 1-m.

CNP
CodClas Nume
Locai
e
1 m
Clase InCareInva Elevi

NrTable Prenume

NrBanc CodClas
i

Figura 9 : O relaie de tip 1-m

47
 Metod: Stabilirea unei relaii 1m
Pentru a stabili o relaie 1-m ntre dou entiti (aici relaia InCareInva
ntre entitile Clase i Elevi) procedm astfel:
(1.) includem n descrirea ambelor entiti un acelai atribut (aici:
CodClas);
(2.) definim acest atribut drept cheie primar pentru entitatea principal i
drept cheie extern pentru entitatea secundar.

3.11.3. Rezolvarea relaiilor n-m

In acest caz, ne bazm pe faptul c n modelul relaional nu numai
entitile ci i relaiile dintre ele sunt relaii n sens matematic i, ca urmare,
pot fi reprezentate prin tabele. Am observat, de asemenea, c relaiile
dintre entiti pot avea atribute (inclusiv chei primare).
S considerm baza de date a unei firme de distribuie de carte; ea
trebuie s conin cel puin entitile Clieni (librrii, biblioteci, persoane
particulare etc.) i Furnizori (edituri, tipografii etc.). Evident, fiecare client
poate comanda cri de la mai multe edituri sau tipografii iar fiecare furnizor
poate lucra cu mai multe librrii, biblioteci etc. Avem de face cu o relaie n-
m, fie ea numit Comand.

Metod: Stabilirea unei relaii nm

Pentru a o stabili o relaie n-m ntre dou entiti (aici: relaia Comand
ntre entitile Clieni i Furnizori) procedm astfel:
(1.) includem n descrierea relaiei (aici: Comand) pe post de chei
externe dou atribute care s corespund atributelor care
funcioneaz drept chei primare pentru cele dou entiti (aici:
CodClient i CodFurnizor);
(2.) reducem astfel stabilirea unei relaii n-m (aici: relaia dintre Clieni i
Furnizori) la stabilirea a dou relaii 1-m (aici: relaiile dintre Clieni i
Comand i respectiv dintre Furnizori i Comand).

Aplicaie: O relaie de tip nm n baza de date a unei firme

de distribuie
Ilustrm acest procedeu pentru relaia Comand, de tip nm, dintre
entitile Clieni (avnd atributele: CodClient, TipClient, NumeClient,
AdresClient) i Furnizori (avnd atributele CodFurnizor, TIpFurnizor,
NumeFurnizor, AdresFurnizor). Fie T1 i T2 tabelele prin care se
reprezint aceste entiti.
(1.) reprezentm relaia Comand dintre cele dou entiti prin tabela T3
(de obicei aceast tabel se numete tabel de jonciune). Aceast tabel
conine coloanele: CodComand (cheia sa primar), CodFurnizor ,

48
CodClient (cheile externe asociate entitilor Clieni i respectiv Furnizori)
i DataEmiterii;
(2.) stabilim relaiile 1-m ntre tabelele T 1 i T3 (pe baza atributului
codClient), respectiv ntre tabelele T2 i T3 (pe baza atributului
codFurnizor).
Figura 10 prezint diagrama entitate-relaie a bazei de date a acestei firme.

CodC CodC CodF Cod

l TipCl l Tip F
F

n m
Clieni Comand Furnizori

AdresaC CodComanda AdresaF

l
Nume NumeF
Cl DataEmiterii

Figura 10: O relaie de tip n-m

49
50
 Figura 11: Implementarea unei relaii de tip n-m n Ms Access

Atenie
Observm c singurele relaii dintre entiti care trebuie s fie reprezentate
prin tabele sunt relaiile de cardinalitate n-m. Tabela corespunztoare
trebuie s conin cel puin cheile externe necesare relaionrii celor dou
entiti; n acest caz cheia primar a relaiei este format din cele dou
atribute, altfel: se poate aduga relaiei un alt atribut care va fi definit drept
cheie primar a acesteia.

3.12. Reguli de integritate pentru bazele de date

Dup modelarea bazei de date la nivel structural (definirea entitilor,
a atributelor lor i a relaiilor dintre ele) urmeaz nivelul operaional al
modelrii:
stabilirea tipurilor de operaii care se pot efectua asupra datelor stocate
(sortare, cutare, vizualizare, adugare, tergere, modificare etc.,
prezentate mai jos);
verificarea respectrii regulilor de integritate (ceea ce va asigura
corectitudinea i consistena datelor).
Distingem urmtoarele tipuri principale de reguli integritate:
a entitilor;
a relaiior (numit i regula de integritate referenial);
La acestea se adaug i regulile de integritate impuse de situaia real
modelat prin baza de date, numite restriciile contextuale.

51
3.12.1. Valorea special Null a atributelor
Pentru a putea formula prima regul de integritate trebuie s
analizm situaia unei valori speciale pe care o pot lua atributele entitilor:
valoarea Null.

Definiie Null =
= valoarea pe care o ia un atribut pentru o instan a unei entiti atunci
cnd pentru respectiva instan:
nu exist o valoare (de exemplu, pentru entitatea Angajai, n cazul
salariailor civili de sex feminin, atributul SerieNrLivretMilitar nu poate
lua nici o valoare, deci i se atribuie valoarea Null),
exist o valoare dar nu a fost nregistrat (de exemplu, atributul
SerieNrCarteIdentitate),
nu tim dac exist sau nu o valoare (de exemplu, atributul
NrApartament).

Prin urmare, aceast valoare artificial, care nu trebuie confundat

cu valoarea 0 sau cu stringul vid a fost incorporat modelului relaional al
bazelor de date pentru a permite tratarea excepiilor i a datelor
incomplete. In ciuda alternativei, mult mai "nocive": introducerea unor date
false, utilizarea valorii Null este inc destul de controversat (E.F. Codd a
susinut-o iar C.J. Date o respinge); exist SGBD-uri care nu
implementeaz valoarea Null.

#23 Sarcin de lucru: Exemplificare: valoarea Null

Pentru o baz de date aleas, indicai cel puin un exemplu i cel puin un
contraexemplu de atribut care ia valoarea Null.

#24 Sarcin de lucru: Atribute cu valoarea NULL

Un muzeu este o colecie de obiecte de art (de
diferite categorii: picturi, sculpturi, altele). Fiecare obiect
este caracterizat prin creator (dac este cunoscut), titlu,
anul n care a fost creat (dac este cunoscut) i o scurt
descriere. O pictur mai este descris i prin tip
(acuarel, ulei etc.), suport (carton, pnz, lemn etc.), stil
(abstract, impresionist, clasic etc.). O sculptur mai este
descris i prin materialul n care a fost creat (lemn,
marmur, piatr etc.), nlime, greutate, stil. Obiectele de
art care nu fac parte din cele dou categorii de mai sus mai sunt descrise
prin tip (fotografii, gravuri, tapiserii etc.) i stil. Obiectele de art sunt
clasificate n: proprieti ale muzeului (caz n care se nregistreaz data i
preul achiziionrii, starea obiectului: expus sau depozitat) i mprumuturi
(caz n care se nregistreaz colecia de apartenen, data mprumutului i
52
data returnrii). Baza de date trebuie s stocheze i informaii despre autori
(cei cunoscui): nume, data naterii, data decesului (unde este cazul), ara
de origine, epoca istoric i curentul artistic crora le-a aparinut, stilul
predominant al operei acestuia, precum i despre alte colecii cu care
colaboreaz: nume, tip (particular, muzeu), descrire, adres, telefon,
persoan de contact.
a) Realizai schema conceptual i diagrama ER a bazei de date.
b) Construii tabelele corespunztoare entitilor i relaiilor (cel puin cte
5 instane) pe care le-ai descoperit n etapa de analiz.

3.12.2. Integritatea entitilor

Prima regul de integritate se aplic cheilor primare.

Definiie
Oricare ar fi entitatea E din baza de date, nici un atribut care face parte
din cheia sa primar nu poate lua valoarea Null pentru nici o instan a
entitii.

Dac am permite ca un atribut din componena cheii primare a

entitii s ia valoarea Null, am contrazice cerina de minimalitate a cheii
primare (ar insemna ca restul atributelor care formeaz cheia i care iau
numai valori din domeniile lor respective de valori ar fi suficiente pentru a
identifica n mod unic fiecare instan a entitii).

3.12.3. Integritatea referenial

A doua regul de integritate se aplic cheilor externe.

Definiie
Fie dou entiti U i V relaionate; pentru orice instan a entitii V
(secundar) valoarea cheii externe trebuie s corespund valorii cheii
primare a unei instane oarecare a entitii U (principal) sau s fie Null.

Exemplu
Fie baza de date a liceului i entitile Clase
i Elevi aflate n relaie 1-m (vezi Figura 9). Regula
de integritate referenial nu ne permite s
nregistrm datele personale ale unui elev i s-l
includem intr-o clas care "nu exist" (adic s dm
atributului su CodClas cheie extern pentru entitatea Elevi o valoare
pe care nu a luat-o atributul CodClas cheie primar pentru entitatea
Clase pentru nici una dintre instanele entitii Clase).

53
 Atenie
Dac totui trebuie s nregistrm datele unui elev nainte de a
inregistra datele clasei din care face parte putem face acest lucru dnd
atributului CodClas al entitii Elev valoarea Null (lucru permis, ntruct
aici atributul CodClas este cheie extern i nu primar).

Figura 12: Stabilirea integritii refereniale n Ms Access

3.12.4. Restricii contextuale

In etapa de analiz a situaiei reale care trebuie modelat prin baza
de date, n discuiile dintre proiectanii bazei de date i viitorii ei proprietari
i utilizatori, pot aprea informaii suplimentare privind restriciile pe care
trebuie s le ndeplineasc datele stocate i operaiile efectuate asupra lor.

Definiie Restricii contextuale =

= reguli suplimentare privind modul de nregistrare a datelor i de efectuare
a operaiilor, specifice situaiei reale sau impuse de diferitele categorii de
54
participani de proiectarea, construirea, administrarea i utilizarea bazei de
date.

Exemple de restricii contextuale pentru :

1) baza de date a unei scoli: o clas poate avea
minimum 20 i maximum 25 de elevi;
2) baza de date a unui teatru dramatic: o pies nu
poate dura mai mult de 2 ore i jumtate; ntr-o
stagiune maximum 3 premiere pot fi regizate de
regizori care nu sunt angajaii permaneni ai
teatrului.

#25 Sarcin de lucru: Agora: restricii contextuale

a) Construii schema conceptual i diagrama entitate-relaie pentru o
baz de date care s stocheze informaii despre activitatea parlamentar a
unei ri oarecare, pe parcursul unei sesiuni legislative. Trebuie nregistrate
urmtoarele date: (1) circumscripiile electorale, descrise prin regiune i
unitate administrativ-teritorial; (2) membrii, indicai prin nume,
circumscripie, data primei alegeri n parlament, partidul din care fac parte;
(3) legile discutate, descrise prin nume, data votrii, dac au fost aprobate
sau nu, cine le-a iniiat; (4) cum a fost votat fiecare lege de ctre fiecare
membru al parlamentului (Da, Nu, Abinere, Absen).
b) Enumerai toate ipotezele de lucru i restriciile impuse asupra
modelului bazei de date.

#26 Sarcin de lucru: CorporeSano: restricii contextuale

a) Construii schema conceptual i diagrama entitate-
relaie pentru o baz de date care s stocheze informaii
despre sportivii i jocurile desfurate de-a lungul unui an
competiional (alegnd sportul preferat).
b) Trebuie avut n vedere c nu toi sportivii unui club
particip la toate jocurile echipei, c i pot schimba
uneori poziia pe care joac. Enumerai i alte ipotezele
de lucru, precum i restriciile impuse asupra modelului
bazei de date.

#27 Sarcin de lucru: Gradul i tipul relaiilor; restricii

contextuale
Fie urmtoarea schem conceptual: ComisVoiajor = {CNP, Nume,
DataAngajrii, CodDepartament}, Deplasare = {CNP, OraPlecare,
OraDestinaie, DataPlecrii, DataSosirii, CodDeplasare}, Cheltuieli = {
CodDeplasare, NumrCont, SumaTotal}.

55
a) Construii diagrama ER.
b) Specificai gradul i tipul relaiilor dintre aceste entiti.
c) Care sunt cheile primare i externe?
d) Ce restricii trebuie s impunei asupra acestei scheme?

#28 Sarcin de lucru: Restricii contextuale; scheme alternative

Proiectai o baz de date pentru o banc, cu mai multe
sucursale, n care trebuie stocate date despre clieni i
conturi. Trebuie respectate urmtoarele restricii
contextuale: Fiecare cont este administrat de o anumit
sucursal i numai de una; un client poate avea mai
multe conturi i un cont poate fi deinut de mai muli
clieni (so i soie, prini i copii).
a) Cum vei reprezenta combinaia clieni-conturi-
sucursale? Argumentai soluia propus.
b) Care dintre urmtoarele soluii nu respect toate restricii contextuale
enunate? (I) ntre cele trei entiti exist o relaie ternar; (II) ntre cele
trei entiti exist dou relaii binare; (III) exist numai dou entiti: Clieni
i Sucursale iar DeineUnContIn este o relaie ntre ele.

#29 Sarcin de lucru: Entiti, chei i restricii contextuale

Fie urmtoarea schem conceptual a unei baze de date: Clieni =
{CodClient, Nume, Adres, Ora}, Comenzi = {CodComand, Data,
CodClient, PreTotal}, ProdusComandat = {CodComand, CodProdus,
Cantitate}, Produs = {CodProdus, PreUnitar}, Expediere = {CodComand,
CodDepozit, DataExpedierii}, Depozit = {CodDepozit, Adres, Ora}.
a) Enumerai entitile, relaiile (inclusiv tipul lor) i atributele exprimate prin
fiecare relaie din schema de mai sus.
b) Pe lng ipoteza: "O comand poate fi onorat i expediat de mai
multe depozite" mai putei face i alte ipoteze?
c) Indicai cheile primare i cheile externe.

3.13. Exerciii recapitulative

#30 Sarcin de lucru: Scheme
conceptuale
Banca de investiii "ABC" are 5 sucursale n
Arad, Bacau, Iai, Roman i Sibiu. Principala
comunicare dintre sucursale const n transferurile
de bani.
a) Construii schemele conceptuale i diagramele
ER ale sucursalelor.
b) Analizai elementele comune i pe cele distincte.

56
#31 Sarcin de lucru: Scheme conceptuale i diagrame ER
a) Construii diagrama entitate-relaie pentru baza de date a bibliotecii
liceului n care nvati.
b) Construii diagrama entitate-relaie pentru baza de date a unei companii
de televiziune prin cablu / a unui furnizor de internet.

#32 Sarcin de lucru: Diagrame entitate-relaie alternative

Atunci cnd realizeaz modelul conceptual al bazei de date pentru o
anumit organizaie proiectantul are de ales ntre mai multe variante.
a) Ce criterii are la dispoziie pentru a alege varianta cea mai adecvat?
b) Realizai trei diagrame entitate-relaie pentru activitatea din coal.
Enumerai calitile fiecreia. Argumentai alegerea uneia dintre ele.

#33 Sarcin de lucru: DistriMar: diagrama ER

Compania DistriMar are nevoie de urmtoarele informaii despre clieni,
mrfuri, i comenzi:
pentru fiecare client: codul clientului (unic), denumirea, adresele la care
trebuie s i expedieze mrfurile (cel puin una pentru fiecare client),
suma datorat pentru mrfurile expediate, limita creditului si reducerea
acordate;
pentru fiecare comand: informaii de identificare (precum: codul
clientului, adresa pentru expediere, data comenzii) i detalii pentru
fiecare marf expediat (precum: codul i cantitatea mrfii);
pentru fiecare marf: codul (unic), furnizorii, stocul fiecrui furnizor,
nivelul critic al stocului pentru fiecare furnizor, denumirea i descrierea
mrfii.
a) Identificai gradul i cardinalitatea relaiilor.
b) Construii schema conceptual i diagrama entitate-relaie.

#34 Sarcin de lucru: "MarcoPolo": diagrama ER

O baz de date conine informaii despre agenii de vnzri, zonele
geografice n care lucreaz fiecare (le vom numi pe scurt zone) i produse.
Fiecare agent i desfoar activitatea n una sau
mai multe zone (care i-au fost explicit alocate); n
fiecare zon i desfoar activitatea unul sau mai
muli ageni. Analog, fiecare agent vinde unul sau
mai multe produse i un produs este vndut de unul
sau mai muli ageni. Fiecare produs poate fi vndut n
oricare dintre zone dar un acelai produs nu poate fi
vndut ntr-o anumit zon de mai muli ageni.
Fiecare agent vinde acelai set de produse n fiecare dintre zonele care i-
au fost alocate.
a) Identificai restruciile contextuale.
57
b) Construii diagrama entitate-relaie pentru aceast baz de date.

#35 Sarcin de lucru: Compania fluvial "Nautilus"

O firm de vase fluviale dorete s i eficientizeze activitatea prin utilizarea
unei baze de date. Construii aceast baz de date tiind c:
Firma dispune de trei tipuri de vase: cargouri
(caracterizate prin clas - transport mrfuri
perisabile, cereale, utilaje - i numr de macarale
de punte); tancuri petroliere (caracterizate prin tipul
de echipare n funcie de combustibilul
transportat: motorin, benzin etc.) i vase de
pasageri (caracterizate prin: clasa de confort i
numrul maxim de pasageri la clasa I i la clasa "turist"). Fiecare vas are
un echipaj format din cpitan, secund, un numr de ofieri i de marinari i
este descris prin capacitate total i util, lungime, pescaj, vitez de
deplasare, tip de combustibil folosit, portul de baz i portul n care a fost
inregistrat (pot sau nu s coincid).
Baza de date trebuie s conin i informaiile necesare remunerrii
echipajului precum i informaii utile companiilor de asigurri. Astfel,
salariile depind de calificare i de postul pe care este curent incadrat
marinarul (tipul vasului, poziia n echipaj); echipajul primete i prime
pentru voiajul efectuat, n funcie de durata voiajului i de vechimea n
companie a marinarului; dac un ofier este supracalificat pentru postul pe
care lucreaz primete o compensaie financiar. Compania de asigurri
trebuie s cunoasc n orice moment locaia fiecrui vas, portul din care a
plecat i data plecrii, portul destinaie i data estimat a sosirii, numrul de
ofieri i numrul total de persoane aflate la bord, valoarea mrfii
transportate (dac e cazul); sunt inregistrate i vasele aflate n docuri
pentru reparaii (data nceperii reparaiei, data estimat a finalizrii,
descrierea reparaiei, motivul i costul.
a) Ce tipuri de entiti i atribute apar? Ce cardinalitate au relaiile dintre
entiti?
b) Realizai schema conceptual i diagrama entitate-relaie

#36 Sarcin de lucru: "Codd": inventar de articole

Un colectiv de cercetare al unei faculti de informatic public anual o
analiz a tuturor articolelor tiinifice care tratateaz subiectul "baze de
date". Fiecare articol poate avea unul sau mai muli autori, poate aborda
unul sau mai multe subiecte (normalizare, optimizare, modelul relaional,
modelul orientat obiect, vizualizri etc.) dar nu poate aprea dect ntr-o
singur revist. Revistele sunt identificate prin titlu, volum, an de apariie,
numr. Fiecare numr poate conine mai multe articole. Fiecare articol
conine o serie de referine la alte articole. Autorii pot scrie mai multe
articole care apar n diverse (numere de) reviste.
58
Pentru a le simplifica munca, proiectai o baz de date din care cercattorii
s poate afla uor: ce autori au scris unul sau mai multe articole referitoare
la un anumit subiect (de exemplu: normalizare); ce articol trateaz un
anumit subiect sau a fost citat ntr-un articol care trateaz un anumit
subiect;etc.

#37 Sarcin de lucru: Editura "Gutenberg": analiz i model

conceptual
Considerm o problem similar celei anterioare: editurile specializate
public diferite tipuri de reviste tiinifice i/sau cri. O revist/carte este
publicat de o singur editur. Un autor poate
scrie articole i/sau cri. O revist conine
mai multe articole iar un articol poate avea
unul sau mai muli autori. Un articol poate
apare ntr-o singur revist. Fiecare articol
este recenzat de unul sau mai muli specialiti
din domeniu, care pot fi i ei la rndul lor
autori sau nu. Evident, un autor nu-i poate
recenza propria lucrare. Fiecare
autor/recenzent lucreaz i este pltit de o
singur editur, dar numai n cazul crilor, nu
i al articolelor.
Transformai aceste specificaii ntr-o schem
conceptual i realizai diagrama entitate-
relaie.

#38 Sarcin de lucru: Fuziune cu probleme

S facem presupunerea (destul de nerealist!) c dou
bnci diferite, "Harpagon" i "Shylock", care au decis s
fuzioneze, constat c utilizeaz aceeai diagram entitate-
relaie. Evident, noua banc, "Harlock", va dispune de o baz
de date unic. Acest lucru poate genera probleme? Care? Ce soluii
propunei? Cum va afecta implementarea lor diagrama entitate-relaie a noii
baze de date?

#39 Sarcin de lucru: Fuziune internaional

cu probleme
Relum ipoteza din Sarcina de lucru #7 dar avem n
vedere n plus faptul c banca "Harpagon" este situat n
Frana iar "Shylock" n Anglia. Ca urmare, modul de
identificare a clienilor este diferit pentru "Harpagon" fa
de "Shylock". Genereaz aceasta noi probleme? Cum le
rezolvai?

59
#40 Sarcin de lucru: Bazele de date i WWW
a) Accesai site-ul web al unui productor de echipamente de calcul (de
exemplu: www. ibm.com, www. dell.com etc.) i ncercai s realizai
diagrama entitate-relaie a unei baze de date pentru acest site.
b) Acelai enun n cazul site-ului web al unui distribuitor de carte precum
www.amazon.com.

60
CAPITOLUL 4: NORMALIZAREA BAZELOR DE DATE
4.1. Introducere: definiii, terminologie
Normalizarea poate fi privit ca ultima etap n proiectarea unei baze
de date. Aa cum am vzut, acest proces de tip top-down ncepe cu
identificarea principalelor entiti i relaii; urmeaz ca acestea s fie
examinate (inclusiv la nivelul raporturilor dintre atributele care le
caracterizeaz) n scopul eliminrii tuturor "defectelor" lor i transformrii
ntr-un set de relaii adecvat, coerent i bine structurat.
Aceast tehnic a fost iniiat tot de E.F. Codd (a se vedea [6]). El a
propus iniial trei seturi de reguli pe care o relaie trebuie s le satisfac
pentru a fi coerent i pe care le-a denumit prima (FN1), a doua (FN2),
respectiv a treia (FN3) form normal (dnd astfel i numele tehnicii
nsi). Ulterior, R. Boyce a introdus, mpreun cu E.F. Codd, o definiie mai
tare a FN3 denumit forma normal Boyce-Codd (FNBC). In fine, au mai
fost definite nc dou forme normale: a patra (FN4) i a cincea (FN5)
form normal, care ns au n vedere situaii destul de rar intalnite.
S remarcm caracterul "progresiv" al acestor forme normale
(ilustrat i prin Figura 1): o relaie aflat n FN3 este automat n FN2 i deci
i n FN1. De fapt, cteodat din punct de vedere al performanelor n
exploatare este preferabil ca baza de date s fie lsat intr-o form
normal inferioar (se execut procesul invers normalizrii, denumit
denormalizare a bazei de date).

Figura 1: Formele normale

Este justificat ntrebarea: cte forme normale mai ateapt s fie

descoperite? Rspunsul a fost dat de Ronald Fagin n 1981 (a se vedea
[11]). In acest articol este introdus o form normal care se bazeaz pe
noiunile de domeniu de valori i cheie primar (notat FN/DK) i se
demonstreaz c o relaie este n FN/DK dac i numai dac nu prezint
61
anomalii la modificarea datelor. Aceast teorem arat c nu mai este
nevoie de nicio alt form normal (cel puin din punctul de vedere al
eliminrii anomaliilor la modificarea datelor).

Definiie Normalizare =
= un proces prin care un set de relaii care ncalc anumite principii de
proiectare este nlocuit cu un alt set de relaii adecvat, coerent i bine
structurat.
Acest proces se desfoar n mai multe etape: n fiecare etap se
urmrete eliminarea unui alt tip de defecte ale relaiilor astfel nct, pe
msur ce relaiile trec n forme normale superioare, ele devin din ce n ce
mai puin vulnerabile fa de anomaliile de actualizare a datelor.

Pentru a prezenta procesul de normalizare, este necesar s definim

urmtoarele dou concepte:
anomalie la actualizare,
dependen funcional.
Pentru simplificare, vom utiliza acolo unde este cazul
reprezentarea prin tabele a entitilor i relaiilor din baza de date.

4.2. Anomalii la actualizare

Unul dintre principalele obiective n proiectarea bazelor de date este
eliminarea redundanelor (a nregistrrii acelorai date de mai multe ori).
Fie, de exemplu, entitile :
Elevi {CNP, CodClas, Nume, Prenume, Adres};
Clase {CodClas, Locaie, NrBanci, NrTable};
EleviClase {CNP, Nume, Prenume, Adres, CodClas, Locaie, NrBanci,
NrTable}.
Dac n baza de date includem tabelele Elevi i Clase nu vom avea
redundane n date; n schimb, dac includem tabelele Clase i EleviClase
(sau Elevi i EleviClase) redundana va fi evident.
Tabelele care conin date redundante pot genera probleme n
momentul actualizrii informaiei. Acestea se numesc anomalii la
actualizare i sunt de trei tipuri:
1. anomalii la adugare;
2. anomalii la tergere;
3. anomalii la modificare.
Le vom ilustra prin exemple pentru cazul n care n baza de date includem
tabelele Clase i EleviClase definite n schema conceptual de mai sus:

CodClas Locaie NrBanci NrTable

XIB Cam23 18 3
XA Cam12 21 2
IXC Cam15 18 2
62
 (a) Entitatea Clase

CNP Nume Pr Ad CodCl Loc NrB NrT

n r
1900530123 Savu Ion B IXC Cam09 15 2
1900924456 Rosu R CJ XA Cam15 21 3
2900225789 Banu M B XA Cam15 21 3
2900807246 Rona C AR IXC Cam09 15 2
1901010357 Mares D DJ XIB Cam23 18 3
(b) Entitatea EleviClase

Figura 2: Dou relaii care pot produce anomalii de actualizare

(1.) Distingem dou tipuri de anomalii la adugare:

(a.)

CNP Nume Pr Ad CodCl Loc NrB NrT

n r
1900530123 Savu Ion B IXC Cam09 15 2
1900924456 Rosu R CJ XA Cam15 21 3
2900225789 Banu M B XA Cam15 21 3
2900807246 Rona C AR IXC Cam09 15 2
1901010357 Mares D DJ XIB Cam23 18 3
1900404135 Olaru S TL XIB Cam23 18 3
2901010555 Manu D PL XIB Cam23 18 2

Figura 3 : Repetarea datelor despre clas la

nregistrarea fiecrui nou elev trebuie s se fac exact

(b.)

CNP Nume Pr Ad CodCl Loc NrB NrT

n r
1900530123 Savu Ion B XIB Cam23 18 3
1900924456 Rosu R CJ XIB Cam23 18 3
2900225789 Banu M B XA Cam15 21 3
2900807246 Rona C AR IXC Cam09 15 2
1901010357 Mares D DJ XIB Cam21 21 3
Nul Null Nul Nul XE Cam11 16 2
l

Figura 4: Adugarea unei 63 noi clase (n care nu exist nc

elevi) necesit introducerea valorii Null n celulele destinate
datelor despre elevi, deci inclusiv n cheia primar. Acest
lucru contravine regulii de integritate a entitilor
(2.) Anomalii la tergere

CodClas Locaie NrBanci NrTable

XA Cam12 21 2
IXC Cam15 18 2

CNP Nume Pr Ad CodCl Loc NrB NrT

n r
1900530123 Savu Ion B XIB Cam23 18 3
1900924456 Rosu R CJ XIB Cam23 18 3
2900225789 Banu M B XA Cam15 21 3
2900807246 Rona C AR IXC Cam09 15 2
1901010357 Mares D DJ XIB Cam21 21 3
Figura 5: Datele despre clasa a XIB au fost terse din tabela Clase
dar datele elevilor din acea clas au rmas n tabela EleviClase

(3.) Anomalii la modificare

CodClas Locaie NrBanci NrTable

XIB Cam23 20 4
XA Cam12 21 2
IXC Cam15 18 2

Figura 6: In tabela Clase s-au operat modificri n datele

care descriu una dintre clase dar n tabela EleviClase au
rmas nc datele vechi despre respectiva clas

CNP Nume Pr Ad CodCl Loc NrB NrT

n r
1900530123 Savu Ion B XIB Cam23 18 3
1900924456 Rosu R CJ XIB Cam23 18 3
2900225789 Banu M B XA Cam15 21 3
2900807246 Rona C AR IXC Cam09 15 2
1901010357 Mares D DJ XIB Cam21 21 3

64
4.3. Dependene funcionale
Procesul de normalizare se bazeaz pe examinarea relaiilor dintre
atributele entitilor, oglindite prin conceptul de dependen funcional.

Definiie Dependen funcional =

= o restricie care apare ntre atributele unei entiti la nivelul semanticii
(semnificaiei) acestora: fie a1 i a2 atributele unei entiti E; spunem c
atributul a2 este dependent funcional de atributul a1 dac fiecrei valori
a atributului a1 i corespunde o valoare i numai una a atributului a2 .

Atenie
Observm c unei valori a atributului a 2 i pot corespunde mai multe
valori ale atributului a1. (putem spune c a1 este argumentul iar a2 este
imaginea unei funcii n sensul matematic al cuvntului).
Se pot afla n dependen funcional nu numai atribute individuale ci i
grupuri de atribute. Vom ignora dependenele triviale, adic dependenele
a1 a2 n care a2 depinde funcional de un subset al a1.

Notm dependena funcional a atributelor a1 i a2 prin

a1 a2
i o reprezentm grafic ca n Figura 7.

atributul a2 depinde
a1 a2
funcional de a1
Figura 7: Reprezentarea grafic a dependenei funcionale

Definiie Determinantul unei dependene funcionale =

= atributul care, prin valorile sale, determin valorile celuilalt atribut (adic:
atributul aflat, n oricare dintre cele dou reprezentri, n stnga sgeii).

Exemple
1) Fie entitatea Elevi = {CNP, Nume, Prenume, Adresa, codClas};
atributul Nume depinde funcional de atributul CNP (atributul CNP este
determinantul dependenei).
2) Fie entitatea Clase = {CodClas, Locaie, NrBanci, NrTable); fiecare
dintre atributele Locaie, NrBanci, NrTable depind funcional de atributul
CodClas (care este deci determinantul dependenei funcionale).

65
3) Fie entitatea Medici = {CodCabinet, Grad, Nume, Prenume); atributul
CodCabinet depinde de grupul de atribute {Nume, Prenume, Grad}.

Atenie
Examinarea dependenelor funcionale dintre atributele unei entiti ne
permite s determinm care dintre cheile candidate trebuie s fie aleas
drept cheie primar: este aleas cheia candidat care apare ca determinant
n toate dependenele funcionale identificate la nivelul entitii respective
( a se vedea al doilea exemplu de mai sus.

#1 Sarcin de lucru: Dependen funcional?

Propunem urmtoarea regul privind dependenele funcionale:
"dac i atunci ".
Demonstrai c aceast regul nu este valabil gsind o relaie r
care satisface i dar nu satisface .

4.4. Procesul de normalizare

Normalizarea unei baze de date este un proces care se desfoar n
mai muli pai. Fiecare pas (cu excepia aducerii bazei de date la FN1)
presupune:
1. identificarea dependenelor funcionale;
2. verificarea ndeplinirii unor anumite proprieti denumite generic forme
normale.
Pe msur ce procesul de normalizare progreseaz, relaiile care
compun baza de date (fie c acestea corespund unor entiti sau unor
relaii dintre entiti) devin din ce n ce mai riguroase (forma normal pe
care o satisfac este mai restrictiv: a se vedea Figura 1 de mai sus).
Din punctul de vedere al modelului relaional, singura form normal
obligatorie pentru toate relaiile din baza de date este FN1; dac ns dorim
s evitm toate anomaliile de actualizare (analizate mai sus) este necesar
s continum procesul de normalizare cel puin pn la FN3.

Atenie
Reamintim faptul c n modelul relaional, orice entitate i relaie dintre
entiti este modelat matematic prin conceptul de relaie i reprezentat
convenional printr-o tabel. In continuare, prin relaie vom nelege
modelul matematic al unei entiti sau al unei relaii ntre entiti,
reprezentat convenional printr-o tabel, ca mai sus.

4.5. Prima form normal (FN1)

Dup definirea structurii i a operaiilor cu baza de date, urmeaz
introducerea datelor (crearea instanelor entitilor i a relaiilor dintre ele).
66
Acest lucru nseamn n principal transferarea datelor concrete din
formularele de culegere a datelor n tabelele asociate entitilor / relaiilor.
Dup parcurgerea acestui pas, se obin de obicei tabele
nenormalizate, adic tabele n care unele celule conin mai multe
valori ale aceluiai atribut sau repet valori din alte celule.

Exemplu
Fie baza de date a unei firme de transport auto
care se ocup cu transportul de persoane; dintre
entitile care apar intr-o astfel de baz de date
enumerm: Angajai, Vehicule, Garaje, Clieni,
Trasee. S presupunem c formularele de culegere date completate de
eful fiecrui garaj conin (pe lng adresa garajului): tipul vehiculelor
deinute (limuzin, microbuz, autocar), numerele de nmatriculare ale
acestora, datele de identificare ale oferilor care le conduc. Transcrirea
direct a datelor din aceste formulare n tabela Garaje poate conduce la
rezultatul din Figura 8.

Figura 8: Tabela Garaje11 n Ms Access

Dac examinm celulele din coloana tipAuto (precum i din coloana

Soferi) constatm c tabela Garaje se afl n form nenormalizat. Ca
urmare, tabela trebuie trecut n FN1.

Definiie Relaie aflat n prima forma normal (FN1) =

= o relaie cu proprietatea c oricare dintre celulele tabelei care o reprezint
convenional conine o valoare i numai una (nu exist atribute cu valori
multiple).

67
 Se cunosc dou metode de a aduce o relaie n FN1; o vom prezenta
pe cea mai eficient dintre ele (vom presupune c un singur atribut nu
respect condiia din FN1):

Metod: Aducerea unei relaii la FN1

Fie E o entitate (aici: Garaje), a atributul su (aici: tipAuto) responsabil
pentru forma nenormalizat a tabelei T corespunztoare entitii (aici:
tabela Garaje11).
Aducerea tabelei la FN1 necesit:
(1.) eliminarea atributului a din entitatea E / a coloanei corespunztoare
din tabela T (aici: a coloanei TipAuto din tabela Garaje11; denumim
Garaje22 tabela astfel rezultat);
(2.) crearea pornind de la atributul a a unei noi entiti E' ; fie T' tabela
care o reprezint (aici: pe baza atributului TipAuto crem entitatea
Vehicule cu cheia primar NrInmatr i atributele: TipAuto, Marca, NrStele,
NrLocuri, Culoare);
(3.) stabilirea relaiei dintre cele dou entiti, relaie care este dup caz
de tip 1-m sau n-m (aici: relaia dintre entitile Garaje i Vehicule
este de tip 1-m). Prin urmare, cheia primar a entitii E trebuie s
inclus cu rol de cheie extern printre atributele entitii E' (aici:
includem atributul CodGaraj cu rol de cheie primar pentru entitatea
Garaje pe post de cheie extern pentru entitatea Vehicule).

Figura 9: Tabela Garaje dup prima modificare

68
 Figura 10: Tabela nou creat, Vehicule

Figura 11: Relaiile dintre noile tabele

Atenie
Intr-o relaie pot exista mai multe atribute cu valori
multiple, deci care s fie fiecare la rndul su
responsabile pentru forma nenormalizat a relaiei
(tabelei). In acest caz, aducerea relaiei la FN1 se
desfoare n tot atia pai cte astfel de atribute
exist (aici: noua tabel Garaje22 este tot n form nenormalizat din
cauza atributului Soferi). Prin urmare, vom proceda pentru acest atribut
69
aa cum am procedat i pentru atributul TipAuto: a se vedea Figura 12
(tabela Garaje33 aflat acum n FN1) i Figura 13 (tabela Soferi nou
creat) precum i Figura 14 (tabela de jonciune Conduc prin care vom
realiza relaia de tip nm dintre entitile nou create Soferi i Vehicule).

Figura 12: Tabela Garaje33 (complet normalizat)

70
 Figura 13: Tabela nou creat, Soferi

Figura 14: Tabela de jocntiune Conduce

71
 Atenie
Procesul de aducere la FN1 a evideniat
necesitatea inregistrrii unor informaii noi: numerele
de nmatriculare ale autovehiculelor (la primul pas),
datele personale ale oferilor (la al doilea pas). Pe de
alt parte, n forma iniial, nenormalizat, tabela Garaje11 coninea o serie
de informaii auxiliare (ce tip de vehicule se afl n fiecare garaj, ce oferi le
conduc) care se pot pierde la normalizare. Acest lucru poate fi evitat dac
ntre noile entiti aprute prin normalizare se stabilesc relaiile
corespunztoare (aici: la primul pas s-a stabilit o relaie 1-m ntre entitatea
Garaje modificat i entitatea Vehicule nou creat, iar la pasul al doilea s-
a stabilit o relaie nm ntre entitile nou create Soferi i Vehicule,
deoarece n principiu un ofer poate conduce mai multe vehicule i un
vehicul poate fi condus de mai muli oferi iar o restricie contextual a
bazei de date poate stipula ce vehicule poate conduce fiecare ofer i ce
oferi pot conduce fiecare vehicul. De aceea, am creat tabela de jonciune
Conduc cu atributele CNP, NrInmatr. Acestea sunt chei primare n
tabelele Soferi respectiv Vehicule i sunt chei externe n tabela Conduc,
dar formeaz mpreun cheia primar pentru tabela Conduc).

72
 Figura 15: Setul de relaii rezultat dup incheierea operatiei
de aducere la FN1 a entitii Garaje

4.6. A doua form normal (FN2)

O relaie care este n FN1 dar nu este n FN2 poate suferi de anomalii
de modificare, ca n exemplul de mai jos.

Exemplu
Fie baza de date a unui institut de cercetri care
are mai multe filiale i n care salariaii sunt pltii n
funcie de numrul de ore lucrate n cadrul unui
proiect de cercetare sau al altuia. Dintre entitile
care apar ntr-o astfel de baz de date enumerm:
Filiale = {CodFil, NumeFil, LocFil}, Angajai = {CNP,
CodFil, NumeAng, Adresa, SalariuPeOra}, Proiecte
= {CodPrj, TitluPrj, CodFil, DataPredrii}. Pe lng
acestea, am mai introdus n baza de date i entitatea AngajaiProiecte =
{CNP, NumeAng, CodPrj, TitluPrj, NrOre, DataPredrii} cu instanele din
Figura 16.
S presupunem c data de predare a proiectului tr1 a fost devansat cu o
lun; dac nu operm aceast modificare n ambele nregistrri din tabel

73
care se refer la acest proiect atunci apare o anomalie de actualizare i
baza de date ii pierde consistena.

Figura 16: Tabela AngajaiProiecte

Atenie
FN2 se refer numai la relaii a cror cheie primar este format din
mai multe atribute deoarece se bazeaz pe conceptul de dependen
funcional complet.

Definiie Dependena funcional complet

Fie a1 i a2 dou (mulimi de) atribute ale entitii E; spunem c a2
este complet dependent funcional de a1 dac i numai dac a2 este
dependent funcional de a1 dar nu este dependent funcional de nicio
submulime proprie a lui a1.
Dac, dimpotriv, putem elimina un atribut din mulimea de atribute a1 iar
a2 continu s fie dependent funcional de a1 atunci spunem c a2 este
doar parial dependent funcional de a1.

Contraexemplu
S examinm relaia Vehicule din exemplul de mai sus: dependena
funcional
NrInmatr, TipAuto CodGaraj
nu este complet: atributul CodGaraj este dependent funcional de un
subset al {NrInmatr, TipAuto }, i anume de NrInmatr.
74
 Definiie A doua form normal
O relaie este n FN2 dac i numai dac:
(1) este deja n FN1;
(2) oricare dintre atributele sale care nu fac parte din cheia primar este
complet dependent funcional de cheia primar.

Metod: Aducerea unei relaii la FN2

Fie E o entitate aflat n FN1; aducerea ei la FN2 necesit:
(1.) identificarea tuturor dependenelor funcionale dintre atributele entitii
E;
(2.) descompunerea relaiei E ntr-un numr de noi relaii astfel:
o fiecare dependen funcional complet definete o nou relaie;
o din fiecare dependen funcional parial se elimin acea parte a
cheii primare care este rspunztoare de incompletitudinea
dependenei i apoi se definete noua relaie.
(3.) stabilirea relaiilor dintre noile entiti (n scopul recuperrii informaii
de legatur, pierdute eventual prin inlocuirea entitii iniiale cu entitile
normalizate).

Aplicaie: Aducerea unei relaii la FN2

Ilustrm metoda de mai sus pentru entitatea AngajaiProiecte din
Figura 17. La prima vedere, fiecare dintre atributele entitii: NumeAng,
titluPrj, nrOre, dataPredrii depinde funcional de cheia primar a acesteia:
CNP, codPrj. Aplicnd definiia dependenei funcionale complete observm
c numai atributul nrOre depinde funcional complet de ambele atribute
care formeaz cheia primar (a se vedea dependena funcional d.f.1 din
Figura 17). Celelalte dependene sunt pariale; din ele obinem urmtoarele
dependene complete: d.f.2 i d.f.3. Ca urmare, vom nlocui entitatea
AngajaiProiecte cu entitile AP1, AP2, AP3 (Figura 18) i vom stabili
relaiile dintre ele (Figura 19).

d.f.2
d.f.1

CNP codPrj nrOre NumeAng titluPrj dataPredrii

d.f.3

75
 Figura 17: Dependenele funcionale complete din entitatea
AngajaiProiecte

AP1 AP2
CNP codPrj nrOre CNP NumeAn
g
AP3
codPrj titluPrj dataPredrii

Figura 18: Normalizarea entitii AngajaiProiecte

Figura 19: Relaiile dintre noile tabele aflate n FN2

4.7. A treia form normal (FN3)

O relaie care este n FN2 dar nu este n FN3 poate suferi de anomalii
de modificare, ca n exemplul de mai jos.

76
 Exemplu
Fie baza de date a institutului de cercetri descris n
paragraful anterior. S presupunem c am mai introdus n
baza de date i entitatea AngajaiFiliale = {CNP, NumeAng,
Adresa, Oras, CodFil, NumeFil, LocFil} cu instanele din
Figura 20.
In cazul n care una dintre filiale ii schimb sediul (de
exemplu filiala CercAero se mut de la Hui la Iai), operarea modificrii
numai n una dintre cele dou nregistrri care se refer la filiala respectiv
determin apariia unei anomalii de actualizare i baza de date ii pierde
consistena.

Figura 20: Tabela AngajaiFiliale

Atenie
FN3 se bazeaz pe conceptul de dependene funcionale tranzitive.

Definiie Dependene funcioanle tranzitive

Fie a1 , a2 i a3 trei atribute ale unei entii E cu proprietatea c:
(1) a1 a2 i a2 a3
(2) a1 nu depinde funcional nici de a2 nici de a3
Atunci: a1 a3 ( a3 depinde funcional de a1 via a2 ).

77
 Exemplu
S examinm relaia EleviClase din paragraful 4.2:

CNP Nume Prn Adr CodCl Loc NrB NrT

1900530123 Savu Ion B IXC Cam09 15 2
1900924456 Rosu R CJ XA Cam15 21 3
2900225789 Banu M B XA Cam15 21 3
2900807246 Rona C AR IXC Cam09 15 2
1901010357 Mares D DJ XIB Cam23 18 3

Avem urmtoarele dependene funcionale: CNP CodCl i CodCl

Loc; atunci avem i CNP Loc via atributul CodCl deoarece atributul
CNP nu depinde funcional nici de CodCl nici de Loc.

Definiie A treia form normal

O relaie este n FN3 dac i numai dac:
(1) este deja n FN2;
(2) nici unul dintre atributele sale care nu fac parte din cheia primar nu
este, prin tranzitivitate, dependent funcional de cheia primar.

Metod: Aducerea unei relaii la FN3

Fie E o entitate (aici: AngajaiFiliale) aflat n FN2 i a1 , a2 i a3 trei
atribute ale sale cu proprietatea c: a1 a2 i a2 a3 (aici: CNP,
CodFil , LocFil : CNP CodFil , CodFil LocFil):
Aducerea tabelei la FN3 necesit:
(1.) identificarea tuturor dependenelor tranzitive dintre atributele entitii
E;
(2.) descompunerea relaiei E ntr-un numr de noi relaii astfel:
o atributul a1 impreun cu toate atributele care depind funcional de
el (deci inclusiv a2 ) formeaz o nou relaie (aici: atributele CNP,
NumeAng, Adresa, Oras, codFil formeaz entitatea Ang1);
o atributul a2 impreun cu atributul a3 i cu alte atribute care depind
funcional de a1 prin tranzitivitate formeaz o nou relaie (aici:

78
 atributul NumeFil se adaug atributelor CodFil i LocFil pentru a
forma entitatea Fil1);
(3.) definirea atributului a2 drept cheie primar a celei de-a doua entiti
nou create;
(4.) stabilirea relaiilor dintre noile entiti (n scopul recuperrii informaiilor
de legatur, pierdute eventual prin inlocuirea entitii iniiale cu entiti
normalizate).

CNP NumeAn Adresa Oras CodFil NumeFil LocFil

g

Figura 21: Dependenele funcionale tranzitive din entitatea AngajaiFiliale

CNP NumeAng Adresa Oras CodFil

CodFi NumeFi LocFi
l l l
Figura 22: Normalizarea entitii AngajaiFiliale

Atenie
Observm c atributul care asigur tranzitivitatea (atributul notat a2) nu este
nici cheie primar n relaia respectiv nici mcar parte a cheii primare.
Tocmai din acest motiv, dependena a2 a3 nu este dezirabil la nivelul
relaiei respective.

Condiie de verificat Soluie (normalizare)

Toate atributele relaiei
FN1
trebuie s fie atomice
Relaia este n FN1;
Cheia sa primar const
din mai multe atribute;
FN2 Toate atributele care nu
fac parte din cheia primar
sunt complet dependente
funcional de cheia primar
Fiecare atribut neatomic se
transform intr-o nou relaie
Fiecare parte a cheii primare,
mpreun cu atributele care
depind funcional complet de ea
formeaz o nou relaie;
Se stabilesc relaiile necesare
ntre noile relaii care au nlocuit-
o pe cea iniial

79
 Relaia este n FN2;
Nici un atribut care nu
face parte dintr-o cheie
candidat nu este funcional
dependent de un alt atribut
care nu face nici el parte
dintr-o cheie candidat (nici
un atribut care nu face
FN3
parte dintr-o cheie
candidat nu este funcional
dependent de cheia
primar prin tranzitivitate)
Se pstreaz n relaia iniial
numai cheia primar i atributele
care depind funcional de ea
direct (inclusiv atributul
"incriminat");
Se creeaz cte o nou
relaie din fiecare atribut care nu
face parte din cheia primar
mpreun cu toate atributele
(care nu fac nici ele parte din
cheia primar a relaiei iniiale)
care sunt dependente funcional
de acesta;
Se stabilesc relaiile necesare
ntre noile relaii i relaia iniial
modificat

Tabelul 1: Recapitulare a primelor trei etape din procesul de normalizare

#2 Sarcin de lucru: Anomalii; normalizare

Fie relaia
Student cu urmtoarele Atribut ExValoare Atribut ExValoare
atribute (i exemple de CodSt RD001 NumeP Sima Ion
valori ale instanelor). NumeSt Ridu Doru LocP Cam. 504
a) Determinai Spec Informatica TelP 2112
anomaliile de AnStudii 3 CodFac FI
actualizare i Grupa 389 TelFac 1234567
depenedenele DenUniv Univ. din DenFac Fac. de
funcionale. Bucureti Informatic
b) Normalizai relaia. Medie 9,40 Credite 180
c) Care dintre formele
normale este mai practic n acest caz? Argumentai rspunsul.

#3 Sarcin de lucru: Dependene funcionale

Enumerai dependenele funcionale netriviale din tabelul alturat.
Atribut_A Atribut_B Atribut_C
a1 b1 c1
a1 b1 c2
a2 b1 c1
a2 b1 c3

80
#4 Sarcin de lucru: Dependene funcionale
Enumerai dependenele funcionale din relaiile R1, respectiv R2.
A B C D A B C D
a1 b1 c1 d1 a1 b2 c1 d1
a1 b1 c2 d2 a1 b1 c2 d2
a1 b2 c3 d1 a2 b2 c1 d3
a1 b2 c4 d4 a2 b1 c2 d4
R1 a2 b3 c4 d5
R2

#5 Sarcin de lucru: Orar: dependene funcionale

Entitatea Orar are urmtoarele atribute: Zi = {luni, mari, miercuri,
joi, vineri}, OrStart = {8, 9, , 19}, CodSal, CodProfesor, NumeMaterie
= {LRomn, Matematic, }. S se determine:
a) dependenele funcionale;
b) cheile candidat.

#6 Sarcin de lucru: Dependene funcionale

a) Care dintre urmtoarele dependene funcionale are loc n relaia
alturat: (1) A B, (2) B C, (3) C B, (4) A B C Cod
B A, (5) C A ? 10 b1 c1 i1
b) n cazul n care una dintre dependene nu 10 b2 c2 i2
are loc indicai nregistrrile responsabile pentru 11 b4 c1 i3
aceasta i cauza. 12 b3 c4 i4
c) Aceast relaie are o cheie candidat? 13 b1 c1 i5
Explicai rspunsul, indiferent dac este 14 b3 c4 i6
afirmativ sau negativ.

#7 Sarcin de lucru: Dependene funcionale

Fie relaia alturat.
a) Enumerai dependenele funcionale. A B C D
b) Fie nregistrrile urmtoare: (a5, b6, c7, d8); a1 b1 c1 d1
(a2, b2, c1, d8); (a3, b1, c4, d3); (a1, b1, c2, d5). a1 b1 c2 d2
Care dintre ele nu poate fi adugat tabelei fr a a2 b1 c1 d3
contrazice dependenele identificate la pct (a)? a2 b1 c3 d4

#8 Sarcin de lucru: Dependene funcionale

a) Identificai cea mai mic mulime de instane ale relaiei R = {A, B, C, D,
E, F, G} care respect urmtoarele dependene funcionale: {B, C, D}A,
{B, C} E, A F, F G, C D, A G. Aducei relaia n FN3.

81
b) Acelai enun pentru R = {A, B, C, D, E, F, G, H} i dependenele
funcionale: A {B, C}, {A, B, E} {C, D, G, H}, C {G, D}, D G, E
F.

#9 Sarcin de lucru: Dependene funcionale; normalizare

a) Determinai cea mai mic mulime de relaii aflate n FN3 cunoscnd
urmtorul set de dependene funcionale: A B, A C, B C, B D,
D B, ABE F, E J, EG H, H G.
b) Indicai cheile candidate i cheile primare ale acestor relaii.

#10 Sarcin de lucru: Normalizare

Aducei n forma normal 3 urmtoarele relaii:
a) Elevi = {CNP, Nume, Adresa, Clasa, Scoala, NumeDiriginte,
SpecialitateDiriginte};
b) Studeni = {CNP, Nume, Adresa, ScoalaAbsolvit, CodCurs, TitluCurs,
CodProfesor, NumeProfesor};
c) Compozitor ={CodCompozitor, TitluLucrare, TipLucrare, Cheie,
DatConcert, LocaieConcert, Solist, Orchestr, Dirijor}.

#11 Sarcin de lucru: AdresB: dependene funcionale, FN?

Entitatea AdresB descrie adresele din oraul Bucureti i are urmtoarele
atribute: nume (unic), strada, sector, codPotal. Determinai::
a) dependenele funcionale;
b) cheile candidate;
c) ce form normal respect aceast relaie.

#12 Sarcin de lucru: Dependene funcionale; FN3

Considerm urmtoarea schem pentru o baz de date privind sportivii
unui club de atletism: Sportivi = {cod,
CodProbSportiv, ProbSportiv, Copii,
PerformaneSportive}; DataNaterii = {Zi, Lun,
An}, ParticipriConcursuri = {An, Ora}.
a) Corectai schema.
b) Determinai dependenele funcionale i aducei
baza de date la FN3.

#13 Sarcin de lucru: Dependene funcionale; FN3

Considerm urmtoarea schem pentru o baz de date privind activitatea
unei universiti: Studeni = {CNP, Nume, Adresa, Facultate, An, Grupa,
MediiAnuale}, Profesori = {CNP, Nume, Adresa, Facultate, GradDidactic,
Vechime, Salariu, Curs}.
a) Enunai toate restriciile care trebuie ndeplinite i corectai schema.
b) Determinai dependenele funcionale i aducei baza de date la FN3.
82
#14 Sarcin de lucru: Identificare anomaliilor i aducere la FN3
Pentru baza de date a aeroportului "Montgolfier" descris n Figura 4 de
mai sus:
a) Identificai anomaliile.
b) Aducei baza de date n FN3.

#15 Sarcin de lucru: Anomalii; normalizare

Fie urmtoarele opt instane ale CodP NumeAn SalariuAn
relaiei Proiect: g g
a) Care dintre dependenele 100A Jianu 320
funcionale de mai jos sunt 100A Sava 250
corecte / greite?
100B Sava 250
CodP NumeAng , CodP
200A Jianu 320
SalariuAng , {CodP, NumeAng}
200B Jianu 320
SalariuAng , NumeAng
200C Poga 140
SalariuAng , SalariuAng 200C Sava 250
CodP , SalariuAng {CodP, 200D Poga 140
NumeAng}.
b) Care este cheia primar a relaiei?
c) Este relaia n FN1, FN2 sau FN3?
d) Care sunt anomaliile pe care le prezint relaia?
e) Relaia conine o depeneden tranzitiv? Dac da, care este aceasta?
f) Aducei relaia n FN3

#16 Sarcin de lucru: Anomalii; normalizare

Fie urmtoarele apte instane ale relaiei OreProiect:
(a) Care dintre NumeAng CodP CodJob Telefon TotalOre
dependenele
Dima 100A B-1 12345 12
funcionale de
Dima 100A P-1 12345 12
mai jos sunt
corecte i care Dima 200B B-1 12345 12
nu? Dima 200B P-1 12345 12
NumeAng Pinu 100A C-1 67890 26
CodP , Pinu 200A C-1 67890 26
NumeAng Pinu 200D C-1 67890 26
CodJob , NumeAng Telefon , NumeAng TotalOre , {CodP, NumeAng}
TotalOre , {NumeAng, Telefon} CodJob , CodP CodJob , CodJob
CodP.
(b) Care este cheia primar a relaiei?
Este relaia n FN1, FN2 sau FN3?
Care sunt anomaliile pe care le prezint relaia?
83
Relaia conine o depeneden tranzitiv? Dac da, care este aceasta?
(c) Aducei relaia n FN3?

#17 Sarcin de lucru: Anomalii; normalizare

Fie relaia Student cu
urmtoarele atribute (i Atribut ExValoare Atribut ExValoare
exemple de valori ale CodSt RD001 NumeP Sima Ion
instanelor). NumeSt Ridu Doru LocP Cam. 504
a) Determinai Spec Informatica TelP 2112
anomaliile de AnStudii 3 CodFac FI
actualizare i Grupa 389 TelFac 1234567
depenedenele DenUni Univ. din DenFac Fac. de
funcionale. v Bucureti Informatic
b) Normalizai relaia. Medie 9,40 Credite 180
c) Care dintre formele
normale este mai practic n acest caz? Argumentai rspunsul.

#18 Sarcin de lucru: Dependene funcionale; normalizare

Fie R o relaie care descrie cursurile inute ntr-o universitate: R =
{CodCurs, CodFacultate, CodCatedra, CNP_Profesor, NivelCurs,
NrCredite, An, Semestru, ZiDinSaptOreDinZi, NrStudeni, Locaie}. S
presupunem c au loc urmtoarele dependenele funcionale: {CodCurs}
{CodCatedra, NivelCurs, NrCredite}, {CodCurs, CodFacultate, An,
Semestru} {ZiDinSaptOreDinZi, Locaie, NrStudeni, CNP_Profesor},
{Locaie, ZiDinSaptOreDinZi, An, Semestru} {CNP_Profesor, CodCurs,
CodFacultate}.
a) Ce chei candidat i ce cheie primar putei indentifica?
b) Cum normalizai relaia R?

#19 Sarcin de lucru: Normalizare

Considerm urmtoarea relaie: VnzareAuto =
{CodAuto, DataVnzrii, CodVnztor, %Comision,
SumaBonificat} i dependenele funcionale:
DataVnzrii SumaBonificat i CodVnztor
%Comision.
a) Presupunnd c un automobil poate fi vndut de mai muli angajai,
care va fi cheia primar a relaiei?
b) Este relaia n FN1, FN2 sau FN3? Justificai rspunsul.
c) Aducei relaia n FN3.

#20 Sarcin de lucru: Normalizare

Considerm relaia: Carte = {TitluCarte, Domeniu, NumeAutor,
AfiliereAutor, Pre, Editur} cu urmtoarele dependenele funcionale:
84
TitluCarte {Editur, Domeniu}, Domeniu Pre,
NumeAutor AfiliereAutor.
a) Este relaia n FN1, FN2 sau FN3? Justificai rspunsul.
b) Aducei relaia n FN3

#21
Catalog.ico
Sarcin de lucru: Restricii contextuale; normalizare
Fie urmtoarea schem conceptual pentru baza de date a unui depozit:
Comenzi = {CodComand, DataComenzii, CodClient, SumaTotal},
ProdusComandat = {CodComand, Cod Produs, CantitateTotal,
CostTotal, %Bonificaie}. Considerm urmtoarele restricii contextuale:
fiecare produs are o alt bonificaie; PreTotal se refer la un singur produs
comandat; DataComenzii este data la care s-a fcut
comanda (nu data la care a fost expediat);
SumaTotal reprezint totalul ncasrilor dintr-o
comand.
a) Ce alte restricii mai trebuie enunate?
b) Sunt relaiile normalizate? Dac nu, cum le
putei normaliza?

#22 Sarcin de lucru: Dependene funcionale; normalizare

Instana alturat a
Atribut ExValoare Atribut ExValoare
entitii Angajai conine
numeroase erori CodAng DI001 Categ 23
(atribute cu valori Nume Dima Ina Salariu 2000 RON
multiple, convenii de Diplome Master, Funcie Agent
denumire ignorate etc.). Doctorat Vnzri
a) Corectai erorile. Calif Nivel 1, Depen- Radu (so),
b) Identificai Nivel 2 deni Dina (fiic)
dependenele CodDep Vnzr DataN 12 III 1960
funcionale i normalizai t
relaia. DenDep Vnzri DataA 1 IV 2006
c) Construii schema t
conceptual i diagrama SefDept Riga Sorin LbStr Engl. Fran.
entitate-relaie.

#23 Sarcin de lucru: MobilTel: normalizarea

Pentru baza de date MobilTel, se cere:
a) aducerea relaiilor din baza de date n FN1, FN2, FN3;
d) implementarea n Ms Access a bazei de date dup normalizare.

#24 Sarcin de lucru: DistriMar: normalizarea

Pentru baza de date DistriMar, se cere:
a) aducerea relaiilor din baza de date n FN1, FN2, FN3;
85
d) implementarea n Ms Access a bazei de date dup normalizare.

#25 Sarcin de lucru: "MarcoPolo": normalizare

Fie diagrama entitate-relaie a bazei de date "Marco
Polo"; aducei toate relaiile la FN3.

#26 Sarcin de lucru: Dependene funcionale;

normalizare
Considerm cazul general al unei entiti (relaii, n sens matematic) R
avnd atributele A, B, C, (fr a arta care dintre ele constituie chei
candidate). Rspundei la fiecare ntrebare prin "Da" sau "Nu" i justificai
rspunsul.
a) Fie R (A,B,C,D) i dependenele funcionale: A B, A C, A D;
(1) Este A o cheie candidat? (2) Este relaia R n FN3?
b) Fie R (A,B,C,D) i dependenele funcionale: A B, B C, C D;
(1) Avem i A D? (2) Este A o cheie candidat?
c) Fie R (A,B,C) i dependenele funcionale: A B, B C, C A;
(1) Este A singura cheie candidat? (2) Este R n FN2 sau FN3?
d) Fie R (A,B,C) i dependenele funcionale: A B, B C, C A;
(1) Este A singura cheie candidat? (2) Este R n FN2 sau FN3?
e) Fie R (A,B,C) i dependenele funcionale: AB C, C A;
(1) Este AB o cheie candidat? (2) Este C o cheie candidat?
(3) Este R n FN3?
f) Fie R (A,B,C,D) i dependenele funcionale: A B, C D;
(1) Este A o cheie candidat? (2) Este C o cheie candidat?
(3) Este relaia R n FN3?
g) Fie R (A,B,C) i dependenele funcionale: AB C, AC B, BC A;
(1) Este A o cheie candidat? (2) Este BC o cheie candidat?
(3) Este R n FN3?
h) Fie R (A,B,C) i dependenele funcionale: AB C, AC B;
(1) Este ABC o cheie candidat? (2) Este AC o cheie candidat?
(3) Este R n FN3?

#27 Sarcin de lucru: Dependene funcionale; normalizare

Acelai enun ca mai sus; n plus, indicm cheile candidate prin
subliniere.
a) Fie R (A,B,C) i dependena funcional: BC A;
(1) Este BC o cheie candidat? (2) Este relaia R n FN3?
b) Fie R (A,B,C) i dependena funcional: A C;
(1) Este AB C nc o dependena funcional?
(2) Este relaia R n FN3?
c) Fie R (A,B,C,D) i dependena funcional: C B;
86
 (1) Este relaia R n FN3?

#28 Sarcin de lucru: Dependene funcionale; normalizare

Fie relaia R i cteva seturi de dependene funcionale; indicai
pentru fiecare: (1) dac respect sau FN3; (2) cum poate fi nlocuit cu o
mulime de relaii aflate n FN3:
a) Fie R (A,B,C,D) i dependenele funcionale: AB C, C D, D A;
b) Fie R (A,B,C,D) i dependenele funcionale: B C , B D;
c) Fie R (A,B,C,D) i dependenele funcionale: AB C , BC D ,
CD A , AD B;
d) Fie R (A,B,C,D) i dependenele funcionale: A B , B C , C D,
D A;
e) Fie R (A,B,C,D,E) i dependenele funcionale: AB C , DE C ,
B D;
f) Fie R (A,B,C,D,E) i dependenele funcionale: AB C , C D,
D B , D E.

#29 Sarcin de lucru: Dependene funcionale; normalizare

Directorul unei firme de
Atribut ExValo Atribut ExValoare
consultan v solicit
are
s evaluai o baz de
date care conine CodClient CD003 Regiune NE
relaia alturat: Nume Cristea CodCons1 CD07
Baza a fost proiectat Prenume Dorina NumeC1 Conu Dan
pentru a-i permite Data 5/02/07 CodCons2 DL02
directorului s coreleze Contract 1234 NumeC2 Deca Lina
clienii cu consultanii Clasa1 SGBD CodCons3
n funcie de clasa de Clasa2 Reele NumeC3
probleme i regiunea Clasa3 CodCons4
geografic. Clasa4 NumeC4
a) Identificai
restriciile contextuale (de exemplu: dac un client solicit consultan
privind reelel de calculatoare i sistemele de gestiune a bazelor de date
atunci trebuie ncheiate dou contracte de consultan pentru c un
consultant poate avea mai multe specializri dar nu neaprat ceel solicitate
de client).
b) Identificai dependenele funcionale i normalizai relaia.
c) Construii schema conceptual i diagrama entitate-relaie.

#30 Sarcin de lucru: Agenia "InstantAngaj";

normalizare

87
O agenie de intermediere de angajri are ca obiect de activitate gsirea
unor compatibiliti ntre calificrile de care dispun solicitanii de serviciu i
serviciile oferite de diverse firme. Mai multe firme pot oferi servicii similare
i aceeai firm poate oferi mai multe posturi de acelai tip (de exemplu: 3
posturi de ofer de ambulan). Fiecare ofert de servicu primete un
numr unic de identificare i este descris prin denumire, salariile minim i
maxim oferite, numrul de posturi libere, durata contractului pentru fiecare
post (dac nu este pe durat nelimitat). Datele nregistrate pentru fiecare
solicitant sunt: CNP, nume, adres, vrst, numere de telefon, adrese
email, precum i diplomele / calificrile obinute, principalele servicii
deinute anterior i perioadele respective, nivelul salariilor primite n fiecare
serviciu. Sunt inregistrate, de asemenea, situaiile de coinciden ntre
ofertele primite din partea firmelor i solicitrile primite din partea
persoanelor, inclusiv data calendaristic la care a aprut coincidena i
dac ea s-a materializat ntr-o angajare propriu-zis.
a) Este nevoie s inregistrai date despre firmele ofertante?
b) Aducei pe rnd baza de date n FN1, FN2, FN3.

88
 BIBLIOGRAFIE
1. BONTEMPO, Charles J., MARO SARACCO, Cynthia: Database
Management Principles and Products, Prentice Hall, Upper
Saddle River, NJ, 1995.
2. BOWERS, David S.: From Data To Database, Chapman & Hall, London,
UK, ediia a 2a, 1993.
3. CANTTELL, R.G.G.: "What Are Next-Generation DB Systems?", CACM
vol. 34, no. 10 (Oct.1991).
4. CHILDS, D.L.: "Feasability of a Set-Theoretical Data Structure", n Proc
Fall Joint Computer Conference, 1968, p. 557-564.
5. CHEN, P.P.: "The Entity-Relationship Model Toward a Unified View of
Data", ACM Trans. Database Systems, vol. 1, no. 1, (1976), p.
9-36.
6. CODD,E.F.: "A Relational Model of Data for Large Shared Databanks",
Comm. ACM, vol. 13 (1970), no. 6, p. 377-387.
7. CODD Edgar Frank: "Further Normalization of the Data Base Relational
Model", n R. RUSTIN (editor): Data Base Systems, Prentice
Hall Inc. Englewood Cliffs, NJ, 1972.
8. CONNOLLY,Thomas, BEGG,Carolyn, STRACHAN, nne: Database
Systems, A Practical Approach to Design, Implementation, and
Management, 2nd ed., Addison-Wesley, Harlow, 1999.
9. DATE, . J.: An Introduction to Database Systems, Addison-Wesley,
Reading, Mass., 2000.
10. ELMASRI, amez, NAVATHE, Shamkant B.: Fundamentals if Database
Systems, 3RD ed., Addison Wesley, Reading, Mass., 2000.
11. FAGIN, R.: "A Normal Form for Relational Databases That is Based on
Domains and Keys", n Transactions on Database Systems 6
(Sept.1981).
12. FLEMING, C, von HALLE, B.: Handbook of Relational Database
Design, Addison-Wesley, Reading MA., 1989.
13. GARCIA-MOLINA, Hector, ULLMAN, Jeffrey D., WIDOM, Jennifer: A
First Course in Database Systems, Prentice Hall, Upper Saddle
River, NJ, 2000.
14. KROENKE, David M.: Database Processing: Fundamentals, Design &
Impelmentation, Ediia a 7a, Prentice-Hall Inc., Upper Saddle
River, NJ, 2000.
15. O'NEIL, Patrick: Database - principles, programming, performance,
Morgan Kaufmann Publ.Inc., San Fransisco, 1994.
16. ROB, Peter, CORONEL, Carlos: database Systems: Design,
Implementation, and Management, International Thomson Publ.,
Cambridge MA., 1997

89
17. SILBERSCHATZ, Abraham, KORTH, Henry F., SUDARSHAN, S.:
Database System Concepts, McGraw-Hill Co.Inc., New York,
1997.
18. STONEBRAKER, M.: Object-Relational DBMSs: The Next Great Wave,
Morgan Kaufmann Publ. Inc., San Francisco Ca., 1996.
***(DEX)*** Dicionarului Explicativ al Limbii Romne, Editura Acedemiei,
Bucureti, 1984

90