BD1

__________________________________________________________________Luminia Scripcariu
CUPRINS
PREFA ............................................................................................................................... 3
CAPITOLUL I. INTRODUCERE N TEORIA BAZELOR DE DATE ............................. 5

I.1 Definiii i aplicativitate ......................................................................................... 6
I.2 Categorii de personal .............................................................................................. 8
I.3 Noiuni specifice bazelor de date ........................................................................... 9
I.4 Modelarea datelor ................................................................................................. 14
I.5 Modelarea fizic ................................................................................................... 16
I.6 Arhitectura bazelor de date ................................................................................... 19
I.7 Rezumatul capitolului ........................................................................................... 21
I.8 Termeni specifici .................................................................................................. 21
I.9 Aplicaie propus .................................................................................................. 22
I.10 Test-gril ............................................................................................................. 23
CAPITOLUL II. ELEMENTELE SPECIFICE BAZELOR DE DATE ............................... 25

II.1 Entitate ................................................................................................................ 26
II.2 Atribut ................................................................................................................. 27
II.3 Relaie ................................................................................................................. 30
II.4 Diagrama entitate - relaie ................................................................................... 31
II.5 Cardinalitatea unei relaii .................................................................................... 33
II.6 Vedere ................................................................................................................. 35
II.7 Regulile lui Codd ................................................................................................ 37
II.8 Tranzacia ............................................................................................................ 39
II.9 Rezumatul capitolului ......................................................................................... 41
II.10 Termeni specifici .............................................................................................. 41
II.11 Aplicaie propus .............................................................................................. 42
II.12 Test-gril ........................................................................................................... 43
CAPITOLUL III. DIAGRAMA ENTITATE-RELAIE ..................................................... 45

III.1 Alegerea setului de entiti i atribute ............................................................... 46
III.2 Conceptele modelului entitate-relaie ................................................................ 47
1
Proiectarea bazelor de date____________________________________________________________
III.3 Reprezentarea grafic a diagramei ER ............................................................ 49

III.4 Capcane de conectare ........................................................................................ 52
III.5 Interpretarea diagramei ER ............................................................................... 53
III.6 Matricea relaiilor ............................................................................................... 55
III.7 Normalizarea ...................................................................................................... 57
III.8 Rezumatul capitolului ........................................................................................ 64
III.9 Termeni specifici ............................................................................................... 65
III.10 Test-gril .......................................................................................................... 66
CAPITOLUL IV. ASPECTE PARTICULARE ALE MODELRII DATELOR ............... 67

IV.1 Relaii redundante ............................................................................................. 68
IV.2 Rezolvarea relaiilor M:M .................................................................................. 69
IV.3 Relaii ierarhice. Relaii recursive ...................................................................... 71
IV.4 Transferabilitatea relaiilor ................................................................................ 74
IV.5 Subtipuri i supertipuri ....................................................................................... 75
IV.6 Modelarea istoricului unui atribut. Modelarea timpului ................................... 78
IV.7 Modelarea generic ............................................................................................ 80
IV.8 Modelarea fizic ................................................................................................. 84
IV.9 Rezumatul capitolului ........................................................................................ 87
IV.10 Termeni specifici ............................................................................................. 88
IV.11 Aplicaie propus ............................................................................................. 88
IV.12 Test-gril .......................................................................................................... 89
CAPITOLUL V. FINALIZAREA PROIECTRII BAZEI DE DATE ................................ 91

V.1 Analiza CRUD ................................................................................................ 92
V.2 Secven, index, rol ............................................................................................. 93
V.3 Tranzacii ............................................................................................................ 94
V.4 Etapele ciclului de via al unei aplicaii cu BD ................................................ 97
V.5 Rezumatul capitolului ......................................................................................... 99
V.6 Termeni specifici ................................................................................................ 99
V.7 Test-gril ........................................................................................................... 100
BIBLIOGRAFIE .................................................................................................................. 101

2
PREFA
Bazele de date reprezint o aplicaie fundamental din domeniile programrii

i al reelelor de calculatoare. Potenialul de utilizare a bazelor de date este uria, iar
popularitatea lor, la ora actual, nu poate fi contestat.
Proiectarea bazei de date reprezint o etap esenial i critic pentru succesul

oricrei aplicaii cu baze de date, cu accesare local sau online. Orice eroare sau
omisiune din etapa de proiectare va determina erori n interogarea i actualizarea
bazei de date, implementat ca aplicaie, ntr-un limbaj de programare specific.
Eventualele erori sesizate de utilizatori pot fi cu greu corectate dup ce programarea
aplicaiei s-a ncheiat. Programatorul de baze de date nu este interesat de specificul
bazei de date. Doar proiectantul i beneficiarul acesteia pot s sesizeze i s remedieze
erorile, n faza de proiectare a bazei de date, prin consultare reciproc i repetat.
Aceast carte este dedicat proiectrii sistematice a bazelor de date relaionale

i prezentrii tuturor aspectelor i a problemelor care pot s apar pe durata acestui
proces. Aa cum spunea Codd, nu orice baz de date tabelar este i relaional. Multe
condiii trebuie ndeplinite astfel nct baza de date proiectat s fie relaional i
optimizat. Eventualele erori de operare n baza de date pe care le pot face utilizatorii
mai puin sau deloc specializai n acest domeniu, trebuie anticipate i prevenite, prin
msuri specifice de proiectare, care trebuie transmise programatorilor n documentaia
bazei de date.
Cartea se adreseaz studenilor i tuturor celor interesai de proiectarea bazelor

de date, fiind un bun instrument de studiu, prin modul de prezentare a noiunilor, prin
exemplele date, precum i prin aplicaiile i testele propuse spre rezolvare, pentru
verificarea cunotinelor.
Conf. dr.ing. Luminia SCRIPCARIU
Universitatea Tehnic Gheorghe Asachi din Iai
3
CAPITOLUL I
INTRODUCERE N TEORIA BAZELOR DE DATE
DIN CUPRINS:
I.1 DEFINIII I APLICATIVITATE
I.2 CATEGORII DE PERSONAL
I.3 NOIUNI SPECIFICE BAZELOR DE DATE
I.4 MODELAREA DATELOR
I.5 MODELAREA FIZIC
I.6 ARHITECTURA BAZELOR DE DATE
I.7 REZUMATUL CAPITOLULUI
I.8 TERMENI SPECIFICI
I.9 APLICAIE PROPUS
I.10 TEST-GRIL
Baze de date_________________________________________________________________
I.1 DEFINIII I APLICATIVITATE
Ci dintre noi au folosit o baz de date sau mai precis ci dintre noi au beneficiat de
serviciile unui server de baze de date? n prezent, aproape n toate activitile se acceseaz o
baz de date, pentru gestionarea persoanelor, serviciilor sau a obiectelor cu care se lucreaz.
Orice aplicaie online are n spate o baz de date. Dac folosii un program de mesagerie,
primul pas este acela de autentificare. Numele de utilizator i parola de acces pe care le
introducei sunt comparate cu datele dumneavoastr personale stocate n baza de date de pe
serverul de autentificare. Dac ai fcut vreodat cumprturi online, datele dumneavoastr ca
i client exist deja n baza de date a magazinului online. De asemenea, orice activitate
administrativ sau financiar desfurat de diverse instituii (serviciul de eviden a
populaiei, direciile de taxe i impozite, ageniile de asigurare, aplicaiile online de plat a
facturilor etc.) utilizeaz baze de date care permit organizarea eficient a informaiilor i
accesul rapid, sigur, local i de la distan la acestea.
Baza de date (BD, Database - DB) constituie o aplicaie fundamental n toate domeniile de
activitate, civile sau de aprare: financiar, administrativ, educaional, informaional, de
comunicaii i, nu n ultimul rnd, cel al calculatoarelor.
Sistemele de baze de date, ca aplicaii software, reprezint poate cea mai important realizare
din domeniul ingineriei programrii pe calculator.
Prin baz de date se nelege orice colecie partajat de date, ntre care exist relaii logice,
care conine descrierea datelor i este proiectat pentru a satisface necesitile
informaionale ale unei organizaii sau ale unui grup de utilizatori.
Iniial a aprut necesitatea computerizrii sistemului de ndosariere. O prim soluie a acestei

probleme a constituit-o sistemul bazat pe fiiere, cu mai multe programe de aplicaie care
ofer diverse servicii utilizatorilor, printre care i generarea de rapoarte. Dei foarte folosit,
acest sistem se dovedete a fi extrem de redundant i greu de actualizat prin dublarea datelor
i complexitatea relativ mare. n acest context, bazele de date au oferit o modalitate eficient
de tratare distribuit a datelor, ntr-o resurs comun partajat n care se include i descrierea
acestora n aa-numitul catalog de sistem.
6
___________________________________________________________Luminia Scripcariu
n prezent, orice activitate de gestiune din orice domeniu de activitate implic folosirea unei
baze de date, cu acces local sau de la distan, cu caracter public sau privat. Orice BD este
gndit ca o resurs unic, utilizat simultan de mai muli utilizatori.
Complexitatea i dimensiunea BD evolueaz rapid, determinnd reproiectarea algoritmilor de
stocare i acces al fiierelor i chiar schimbarea unor principii de administrare a acestora.
Avantajele utilizrii bazelor de date sunt numeroase. BD asigur independena program-date,
sunt scalabile, flexibile, portabile i permit controlul accesului i al manipulrii datelor.
BD stocheaz datele, eliminnd redundanele, i, prin prelucrarea acestora, furnizeaz
informaii.
n funcie de aplicaia pe care o deservete, BD pot fi centralizate sau distribuite n reea, iar
modalitile de gestionare difer de la caz la caz. Sistemul de programe software care permite
crearea, administrarea i accesarea bazei de date este numit sistem de gestiune a bazei de
date (SGBD).
Sistemul de gestiune a bazelor de date (SGBD, Database Management System - DBMS)

administreaz BD i controleaz accesul la BD.
De exemplu, pentru BD cu un volum mic sau mediu de date se pot folosi ca SGBD
programele MS Access, Visual Fox, Dbase, FoxPro iar n cazul BD care stocheaz un volum
mare de date sunt recomandate programele produse de compania Oracle.
Aplicaiile cu baze de date faciliteaz accesul la informaii i reduc timpul de efectuare a

anumitor operaiuni fiind utilizate n prezent de magazinele online pentru comer electronic,
de bnci pentru tranzacii electronice de la distan, n universiti, coli, biblioteci i n
sistemele administrative pentru gestionarea informaiilor i nu numai. Este dificil de cuprins
n cteva cuvinte aplicaiile care folosesc baze de date.
Din anii 90, de cnd Internetul i World Wide Web-ul sunt folosite pentru diverse aplicaii
online (e-commerce, e-learning, e-banking i altele), bazele de date au devenit eseniale
pentru gestionarea i prelucrarea unui volum tot mai mare de date. De asemenea, securitatea
bazelor de date n ceea ce privete accesul la acestea dar i asigurarea confidenialitii
informaiilor cu caracter privat constituie un element-cheie n dezvoltarea sistemelor de baze
de date.
7
Baze de date_________________________________________________________________
Securitatea unei aplicaii de baze de date are n vedere stabilirea drepturilor de acces la
BD, a drepturilor de citire, scriere, modificare sau tergere a obiectelor i datelor din baza
de date i chiar a ntregii baze de date.
I.2 CATEGORII DE PERSONAL
Diferitele categorii de personal implicate n aplicaiile de BD necesit o anumit pregtire

precum i diferite competene i abiliti, fiind necesar pregtirea de personal specializat n
acest domeniu.
Categoriile de persoane implicate n mediul BD sunt:

proiectani
programatori
administratori de sistem
administratori de baze de date.
Proiectanii bazei de date se ocup de culegerea informaiilor care descriu cerinele i

aspectele specifice ale aplicaiei dorite de client, sistematizarea acestora i transpunerea lor n
noiuni de BD (entiti, atribute, relaii). n diferitele faze ale proiectrii se optimizeaz
modelul BD i periodic au loc consultri ntre proiectani i reprezentani ai categoriilor
specifice de personal ale clientului (manageri, personal tehnic, administrativ, financiar-
contabil etc.) pentru a se identifica toate cerinele la care trebuie s rspund aplicaia final
de BD. Odat trecut aplicaia n faza de programare, este dificil sau chiar imposibil s se
rezolve noi cerine.
Trebuie tiut c cele mai multe probleme (bug-uri) ale sistemelor de BD referitoare la
actualizarea datelor i chiar de securitate a BD dar nu numai, pot fi rezolvate doar n faza de
proiectare i mai puin n faza programrii.
Programatorii de BD de cele mai multe ori nu sunt familiarizai cu noiunile specifice
proiectului, sarcina lor fiind doar aceea de a-l transpune pe acesta n limbaj de programare, ca
aplicaie software performant, cu o interfa de utilizator eficient.
Administratorul de sistem instaleaz, configureaz, securizeaz i monitorizeaz
funcionarea aplicaiei de BD.
8
Administratorul bazei de date (DBA Database Administrator) se ocup de popularea cu

date a BD, precum i de gestionarea i ntreinerea datelor (arhivarea datelor vechi,
tergerea datelor perimate, urmrirea coerenei BD etc.)
O categorie aparte o constituie utilizatorii BD care trebuie s fie instruii referitor la modul
de utilizare a BD, la facilitile i informaiile pe care aceasta le ofer.
Scopul ntregii activiti de proiectare, programare i administrare a BD const n punerea la
dispoziia utilizatorului final a unor BD permanent actualizate, coerente i uor accesibile.
I.3 NOIUNI SPECIFICE BAZELOR DE DATE
BD opereaz n termeni de entitate, atribut, relaie.
O entitate este un obiect distinct inclus n BD asociat unei persoane, firme, unui loc,
document sau concept etc.
Fiecrei categorii de obiecte descrise n BD i se asociaz un tip de entitate cu un nume

sugestiv. De exemplu, studenii dintr-o facultate sunt descrii de tipul de entitate
STUDENI, al entitii STUDENT. Fiecare student, prin numele i prenumele su, este
reprezentat ca o entitate distinct din BD.
Fiecare entitate este descris printr-un set de atribute. De exemplu, entitatea STUDENT
poate avea mai multe atribute: nume, prenume, cod numeric personal (CNP), numr matricol,
specializare i altele.
Un atribut este o proprietate care descrie un anumit aspect al unui tip de entitate.
Atributele pot lua valori unice sau multiple, pot fi impuse sau opionale, pot avea caracter
volatil sau nu, i de asemenea pot juca un anumit rol n descrierea unui tip de entitate, numit
cheie.
Cheia este un atribut sau un grup de atribute care identific n mod unic o entitate.
9
Baze de date_________________________________________________________________
Pentru un tip de entitate, pot fi mai multe atribute de tip cheie, dar un singur atribut sau set de
atribute este folosit la un anumit moment pentru identificarea unic a entitilor nregistrate
ntr-un tabel din BD i acela se numete cheie primar (PK Primary Key).
Celelalte chei sunt denumite chei alternative sau chei candidat.
Proiectarea unei baze de date ncepe cu identificarea entitilor i a atributelor care vor fi
folosite pentru modelarea datelor. Proiectarea este n general fcut de o echip cu mai multe
persoane care trebuie s pun cap la cap, ntr-o aplicaie unic, ceea ce a realizat fiecare n
parte. Este posibil ca pentru acelai obiect sau atribut s se foloseasc denumiri diferite. De
exemplu, pentru entitatea student, unul dintre proiectani poate folosi atributul numr
matricol, altul cod_student, altul id_student, toate acestea avnd de fapt acelai rol, acela de
identificare fr echivoc a fiecrui student n parte. Este necesar ca atunci cnd se reunesc
entitile i atributele create de toi membrii echipei de proiectare, s se defineasc n mod
unic toate elementele din BD i descrierea lor s apar n clar n dicionarul de sistem. De
asemenea, este util stabilirea unor convenii de lucru, care s permit proiectarea ntr-un
mod unitar a BD de ctre toi membrii echipei.
ntre diferitele tipuri de entiti, se stabilesc relaii care descriu interaciunile dintre obiectele
reprezentate n BD.
O relaie reprezint o asociaie ntre mai multe entiti.
De exemplu, studenii de la o anumit specializare i dintr-un anumit an de studiu, studiaz

un anumite discipline. Rezult astfel c exist o relaie ntre tipul de entitate STUDENI i cel
numit DISCIPLINE.
BD poate fi modelat grafic sub forma unei diagrame Entitate-Relaie (ERD Entity -
Relation Diagram) n care sunt reprezentate entitile, relaiile i atributele, sub forma unui
graf neorientat.
Prin convenie, entitile sunt reprezentate sub form de dreptunghiuri, relaiile cu linii i
romburi iar atributele ca ovale n jurul entitii descrise (figura I.1).
Se folosesc i alte convenii de reprezentare a diagramei ER. De exemplu, atributele pot fi
enumerate unul sub cellalt, n dreptunghiul aferent entitii pe care o descriu (figura I.2).
Prin convenie, cheia primar se scrie pe prima poziie i se subliniaz.
10
Orice BD este creat cu scopul de a manipula datele prin operaii specifice (introducere,
extragere, tergere, modificare) i de a extrage informaiile eficient, folosind un limbaj de
manipulare a datelor (DML Data Manipulation Language).
prenume
CNP
nume
STUDENT
numr specializarea
matricol
studiaz
An de Titular
studiu DISCIPLINA de curs
Codul denumire
disciplinei
Figura I.1 Diagram Entitate - Relaie
STUDENT
numr matricol
nume
prenume
CNP
specializarea
Figura I.2 Exemplu de reprezentare grafic a unui tip de entitate,

cu atribute specifice
Crearea structurii n care sunt stocate datele se realizeaz cu ajutorul unui limbaj de definire
a datelor (DDL Data Definition Language). Acesta permite denumirea entitilor BD i a
relaiilor logice dintre acestea n schema bazei de date, cu specificarea tipurilor i
structurilor de date, precum i a modurilor de vizualizare personalizate.
11
Baze de date_________________________________________________________________
Acea parte a unui limbaj DML utilizat pentru regsirea datelor n BD se numete limbaj de
interogare (Query Language).
DDL i DML sunt considerate sublimbaje de date care pot fi ncorporate ntr-un limbaj de
nivel nalt denumit i limbaj gazd.
SQL Structured Query Language este limbajul specific bazelor de date.
Prima aplicaie de baze de date a fost creat de compania Oracle n anii 80, iar limbajul SQL
(Structured Query Language) a devenit limbajul de programare standard pentru aplicaiile cu
baze de date.
SQL este un limbaj de interogare a BD, neprocedural, care constituie limbajul standard
pentru SGBD relaionale. SQL include comenzi de definire a structurii BD, de manipulare a
datelor precum i de securizare a accesului la BD prin stabilirea i/sau revocarea drepturilor
utilizatorilor.
Un alt limbaj de manipulare a datelor din BD este limbajul QBE (Query by Example).
SQL i QBE sunt limbaje din a patra generaie (4GL Fourth Generation Language) care
definesc ce trebuie fcut i nu cum se procedeaz. Limbajele din generaia a treia sunt
procedurale i complicate sintactic.
Limbajele 4GL sunt de mai multe tipuri:
limbaje de prezentare (de interogare, generatoare de rapoarte, generatoare grafice
etc.)
limbaje de specialitate (de exemplu, pentru calcul tabelar)
generatoare de aplicaii (care construiesc aplicaii folosind datele din BD)
limbaje de nivel foarte nalt (care genereaz codul-surs al aplicaiei).
Rezolvarea tranzaciilor concurente, n funcie de cerinele clientului, reprezint un alt aspect

critic al aplicaiei cu BD.
Tranzacia reprezint o operaie de manipulare a datelor din BD .
Controlul tranzaciilor este avut n vedere n faza de programare, pe baza documentaiei BD

care nsoete proiectul BD.
SGBD are rolul s menin coerena BD, chiar i n cazul efecturii unor tranzacii
concurente.
12
De exemplu, n timp ce un client lanseaz comanda de achiziie a unui produs de la un

magazin online, administratorul de date mrete cu 5 % preurile produselor. ntrebarea este
dac n acel moment, clientul cumpr produsul cu preul iniial afiat sau cu preul mrit.
Rezolvarea acestor tranzacii simultane concurente se face de ctre SGBD pe baza politicii
firmei. Doar aceasta poate stabili principiile de soluionare a tranzaciilor concurente.
Programatorul BD aplic aceste principii. Dac nu se au n vedere cazurile critice, este foarte
posibil s apar erori n utilizarea BD (erori de afiare, pierderea unor sume de bani,
nclcarea prevederilor legale i altele).
Utilizatorii BD sunt n general persoane cu interese diferite referitoare la informaiile care pot
fi extrase din BD. De aceea, este necesar s se creeze aa-numite vederi din BD, n mod
distinct pentru fiecare categorie de utilizatori n parte.
Vederea extern reprezint forma de vizualizare a anumitor informaii incluse n BD care

acceseaz anumite atribute ale uneia sau ale mai multor entiti, prezentate n formatul dorit
de utilizor.
De exemplu, departamentul tehnic al unei firme poate solicita ca aplicaia de BD s genereze

rapoarte cu parametrii tehnici ai echipamentelor folosite, fr a se specifica i costurile
acestora. n acelai timp, cei de la departamentul financiar-contabil sunt interesai de preurile
de achiziie i de vnzare ale echipamentelor, nu i de detaliile tehnice.
Ordinea atributelor unei entiti sau a coloanelor dintr-un tabel din BD nu este important,
deoarece extragerea informaiilor i crearea vederilor externe se va face independent de
aceasta.
De exemplu, pe baza tabelului asociat entitii STUDENT, vom putea afia lista ordonat
alfabetic a studenilor, ntr-un tabel n care s cuprind coloanele: numele i prenumele, CNP,
numrul matricol. Nu este obligatoriu ca o vedere extern s afieze toate atributele unei
entitii. n plus, o vedere extern poate fi creat pe baza mai multor tabele din BD. Nici
ordinea nregistrrilor dintr-un tabel nu are nici un rol, pentru c la crearea vederilor externe
se vor putea ordona informaiile dup preferinele beneficiarilor (alfabetic, cresctor, dup
dat etc.).
SGBD permite personalizarea BD pentru a satisface cerinele utilizatorilor, simultan cu
realizarea independenei program-date.
13
Baze de date_________________________________________________________________
n prezent, se dezvolt SGBD multiutilizator pentru BD cu capaciti mari de stocare pentru

aplicaii grafice, video, multimedia n general, cu interfee grafice de utilizator (GUI
Graphic User Interface).
De asemenea, SGBD are rolul de a asigurara securitatea BD i confidenialitea informaiilor
cu caracter restricionat care sunt stocate n BD respectiv.
I.4 MODELAREA DATELOR
Modelarea datelor reprezint etapa de nceput a proiectrii unei baze de date. Operaia de
modelare include stabilirea entitilor i a atributelor acestora precum i a relaiilor dintre ele.
Modelul de date conceptual este creat independent de limbajul de programare n care se va

dezvolta aplicaia de baze de date.
Modelarea datelor ncepe cu analiza cerinelor beneficiarilor bazei de date, aa-numitele

reguli de afaceri (Business rules). Beneficiarii pot fi persoane cu preferine cunoscute, cum
ar fi angajaii unei companii, sau total necunoscute, ca de exemplu clienii unui magazin
online, ale cror preferine pot fi doar estimate prin sondaje fcute pe eantioane
reprezentative din rndul potenialilor utilizatori ai aplicaiei.
De exemplu, dac se dorete crearea unei baze de date pentru o facultate, beneficiarii acesteia
vor fi studenii, profesorii i personalul auxiliar. Studenii vor dori s extrag din baza de date
informaii referitoare la notele obinute, orar, planificarea examenelor, taxe achitate etc.
Profesorii vor dori de asemenea s i consulte online orarul, s scrie n baza de date notele
obinute de studeni sau s calculeze medii ale grupelor. Secretara va nscrie n baza de date
informaiile cu caracter personal ale studenilor, cuantumul burselor, taxele achitate de acetia
i va dori s extrag rapoarte privind situaia colar a fiecrui student, media notelor obinute
de acetia n sesiune, clasamente ale studenilor ordonate descresctor dup medie i numr
de credite acumulat, fr a putea scrie sau modifica notele studenilor.
De multe ori, persoanele care culeg aceste preferine de la beneficiari, prefer s le exprime
sub forma unor ntrebri.
Pentru exemplul BD a unei faculti, utilizatorii au adresat urmtoarele ntrebri:
STUDENII: Ce orar am? Ce not am obinut la un examen? Ce burs primesc?
14
PROFESORII: n care sal se ine cursul de la disciplina pe care o predau? Care este lista
studenilor dintr-o grup? Unde scriu notele obinute de studeni la examen n BD? Ce medie
are o grup la examen? Care sunt studenii restanieri?
SECRETARELE: Care este adresa de domiciliu a studentului X? La ce numr de telefon
poate fi gsit un student? Ce vrst are un student?
Observm din acest exemplu c sunt mai multe categorii de beneficiari sau utilizatori ai bazei
de date respective, cu cerine diverse i drepturi diferite.
Identificarea entitilor din BD i a atributelor lor se va face astfel nct BD s poat oferi
rspuns la toate ntrebrile utilizatorilor.
Se adopt o anumit strategie de definire a entitilor i atributelor acestora, precum i de
creare a tabelelor asociate lor, lund n considerare att vederile externe care vor fi create, ct
i cerinele de securitate ale aplicaiei.
n dezvoltarea aplicaiei respective se vor avea n vedere aspectele de securitate, nc din faza
modelrii datelor.
Cerinele informaionale ale organizaiei care solicit realizarea unei bazei de date trebuie s
fie corect i complet reflectate de modelul ER creat pentru acea aplicaie.
Figura I.3 prezint o parte din diagrama ER asociat modelului conceptual creat pentru baza
de date a unei faculti.
n acest caz, s-au avut n vedere cerinele personalului de la secretariatul facultii de a putea
citi din baza de date informaii specifice despre fiecare student, precum i de a cunoate
componena fiecrei grupe i mprirea lor pe specializri.
Figura I.3 Diagram ER parial - exemplu
15
Baze de date_________________________________________________________________
Este esenial analiza n detaliu a modelului creat, pentru eliminarea tuturor redundanelor i
a elementelor care pot crea ambiguiti i erori n prelucrarea sau acualizarea datelor.
Normalizarea este procesul de optimizare a modelului de date conceptual, prin care se

elimin deficienele modelului creat (atribute cu valori multiple, dependene funcionale
pariale .a.).
Primul model pentru baze de date a fost creat de E.F. Codd n anii 1970-1972, pentru bazele
de date relaionale.
O baz de date relaional depoziteaz datele n tabele, ntre care se stabilesc anumite
conexiuni.
n 1976, P. Chen propune un model avansat pentru baze de date i anume modelul entitate-
relaie (modelul ER Entity-Relation model), care separ nivelul fizic de cel logic, model
care va deveni ulterior referina n domeniul proiectrii bazelor de date.
I.5 MODELAREA FIZIC
Realizarea propriu-zis a BD (Database Design) const n crearea structurii acesteia, folosind

schema BD.
Structura BD este compus din tabele, cel puin unul pentru fiecare tip de entitate. Pentru
tabel se folosete termenul echivalent de relaie iar baza de date este numit relaional.
ns, nu este suficient ca structura BD s fie tabelar pentru ca BD s fie considerat
relaional. O BD relaional (BDR) trebuie s verifice regulile lui Codd, care vor fi
prezentate ntr-un paragraf ulterior.
Un tabel din BD se asociaz unui tip de entitate.
Este indicat ca numele tabelului s sugereze tipul de entitate i mai precis s corespund
formei de plural a denumirii entitii. De exemplu, se va crea tabelul cu denumirea studeni
pentru entitatea de tip STUDENT.
16
O coloan din tabel corespunde unui atribut al tipului de entitate.
Numele coloanelor dintr-un tabel pot s difere n structura intern a BD fa de ceea ce se

afieaz n vederile externe din BD. De obicei, n structura intern a BD se folosete o form
abreviat a denumirii atributului pentru a defini o coloan din tabel, respectnd restriciile
limbajului folosit. De exemplu, atributului numr matricol din diagrama ER i poate
corespunde coloana cu numele nrmatr din tabelul studeni.
Tabelul studeni poate fi descris prin lista atributelor entitii student:
studenti (nrmatr, nume, prenume, cnp, specializare)
n vederile externe nu se folosesc forme prescurtate ci denumiri detaliate ale atributelor
entitilor, pe nelesul utilizatorilor, numite i etichete (label). De exemplu, ntr-un formular
de introducere a datelor personale, poate s apar cmpul-text cu denumirea Telefon mobil,
care s corespund unei coloane din tabelul din BD cu denumirea mobil.
n orice tabel din BD, se introduce cte o linie pentru fiecare entitate nou nregistrat. O linie
din tabel se mai numete nregistrare sau un n-tuplu.
O linie din tabel reprezint un set de valori ale atributelor unei entiti.
La intersecia unei linii cu o coloan din tabel, se gsete un cmp sau o celul n care este
nscris valoarea atributului definit pe acea coloan, corespunztoare nregistrrii din linia
respectiv.
Valoarea unui atribut dintr-o celul poate s lipseasc, situaie n care spunem c atributul
poate fi NULL.
Prin NULL se nelege lipsa valorii unui atribut i nu valoarea zero.
n cazul n care nu se admite lipsa valorii unui atribut, trebuie s se specifice n linia de
comand opiunea NOT NULL pentru acea coloan.
De exemplu, admitem c pentru un student din anul I, cmpul specializare rmne
necompletat, n timp ce din cmpurile nume, prenume, nrmatr valorile nu pot s lipseasc.
De aceea, n formularele de introducere a datelor n BD, unele cmpuri sunt marcate ca fiind
obligatorii iar altele ca opionale. n plus, dac toate cmpurile obligatorii nu sunt completate,
atunci formularul nu poate fi trimis (submit) i apare un mesaj de eroare care l ntiineaz pe
utilizator ce mai trebuie scris. Dac aplicaia nu este corect realizat i utilizatorul trimite un
set de informaii incomplet, atunci n BD nu se poate face nregistrarea datelor dac lipsete
17
Baze de date_________________________________________________________________
valoarea unui atribut pentru care s-a menionat opiunea NOT NULL. Ca urmare, datele
nscrise n formular vor fi pierdute.
Dac nu este permis ca valorile unui atribut s se repete, atunci trebuie specificat opiunea
UNIQUE pentru a evita unele erori la introducerea datelor n BD. De exemplu, valorile
atributului cnp sunt unice.
Atributele care joac rolul de chei ale entitilor trebuie s aib valori unice.
n BD, datele sunt integrate mpreun cu o descriere a lor. Definirea coloanelor din tabelele
BD include i specificarea tipului de date folosit pe fiecare coloan. De exemplu, coloanele
nume i prenume vor conine date de tip caracter, n timp ce numrul matricol va fi exprimat
prin date de tip numeric. Dimensiunile cmpurilor sunt de asemenea specificate acolo unde
este cazul.
Trebuie menionat i calitatea de cheie primar a unui atribut sau set de atribute, precum i
eventualele referine care se fac ntre tabelele BD. Un atribut care este cheie ntr-un tabel dar
apare i n alt tabel, pentru a face legtura dintre cele dou tabele, se numete cheie strin
(FK - Foreign Key).
Este esenial s se lucreze cu o dublare minim a datelor, n scopul reducerii redundanei i al
meninerii coerenei lor. n principiu, orice informaie trebuie s apar ntr-un singur loc din
BD. De exemplu, nu nscriem n locuri diferite din BD gradul didactic al unei persoane,
pentru ca la o eventual promovare a acesteia, s nu fie necesar modificarea lui n mai multe
locuri. Dac totui l scriem de mai multe ori, exist riscul s se omit unele valori i avem n
acest caz de a face cu o eroare de actualizare cauzat de dublarea datelor i de redundana
BD, concretizat n pierderea coerenei BD.
Descrierea datelor, prin tipul i dimensiunea datelor, opiuni i alte specificaii, reprezint
metadatele, care sunt stocate n catalogul de sistem.
Limbajul de definire a datelor (DDL) este un limbaj descriptiv cu comenzi specifice,
utilizat pentru denumirea entitilor BD i a relaiilor logice dintre acestea, pentru
specificarea tipurilor i a structurilor de date, precum i a modurilor de vizualizare
personalizate. Prin compilarea instruciunilor DDL rezult setul de tabele al BD i astfel se
creeaz structura BD i catalogul de sistem.
Urmeaz ca aceast structur s fie populat cu date. Coninutul BD de la un anumit moment
constituie o instan a BD. Prin manipularea datelor, rezult noi instane ale acesteia.
18
I.6 ARHITECTURA BAZELOR DE DATE
Iniial grupul DBTG (Data Base Task Group) a propus o arhitectur a sistemelor de BD cu
dou nivele:
schema BD - reprezint nivelul inferior, de implementare i ntreinere
subschema BD este nivelul superior, folosit pentru realizarea vederilor
utilizatorilor.
Aceast arhitectur are dezavantajul c nu permite generarea vederilor externe independent
de schema intern a BD. Orice modificare a acesteia din urm conduce la schimbarea vederii
externe.
Personalizarea acestor vederi n sistemele multiutilizator este posibil prin introducerea unui
al treilea nivel, intermediar, care s separe detaliile de implementare de cele impuse la
vizualizare. De aceea, institutul ANSI (American National Standards Institute) i comitetul
SPARC (Standards Planning and Requirements Committee) au propus arhitectura cu trei
nivele ANSI/X3/SPARC sau ANSI-SPARC, care include:
nivelul intern
nivelul conceptual
nivelul extern.
n figura I.4 sunt reprezentate cele trei nivele ale arhitecturii ANSI-SPARC pentru BD, cu
toate elementele componente.
Figura I.4 Arhitectura ANSI-SPARC a unei BD
Nivelul extern este format din vederile utilizatorilor, fiecare incluznd anumite entiti,
relaii i atribute, eventual cu reprezentri diferite ale acelorai date, cu combinaii ale
acestora sau cu atribute derivate, pe baza unor scheme externe. Pe acest nivel, se lucreaz cu
19
Baze de date_________________________________________________________________
modele externe bazate pe nregistrri i generate n funcie de diferitele cerine ale

beneficiarilor bazei de date:
modelul de date relaional, bazat pe conceptul de relaii matematice, reprezint
datele din BD i relaiile dintre ele sub form de tabele;
modelul de date n reea reprezint datele ca o colecie de nregistrri (noduri) iar
relaiile dintre acestea prin direciile sau muchiile unui graf.
modelul de date ierarhic, similar modelului n reea, folosete conceptul de nod-
printe i permite unui nod din graf s posede numai un singur printe, realiznd o
structur arborescent.
Nivelul conceptual reprezint o vedere general a BD i descrie datele i relaiile care sunt
stocate n BD, ntr-o structur logic denumit i schem conceptual. Aceasta nu depinde
nici de modul de implementare a BD, nici de cerinele de vizualizare ale utilizatorilor.
Schema conceptual cuprinde toate entitile, atributele, relaiile i constrngerile datelor,
informaiile semantice despre date, normele de securitate i regulile de integritate. Pe acest
nivel se realizeaz modelul conceptual, bazat pe obiecte. Cele mai utilizate modele
conceptuale sunt:
modelul Entitate-Relaie (ER)
modelul orientat pe obiecte, care ia n considerare i comportamentul entitii, pe
lng atributele care descriu starea ei.
Procesul de modelare a datelor independent de modul de implementare, de SGBD int, de

programele de aplicaie, limbaje de programare sau aspecte fizice, reprezint modelarea
conceptual a BD.
Nivelul intern reprezint implementarea fizic a BD, pe baza unei scheme interne
cuprinznd structurile de date i de organizare a tabelelor i fiierelor asociate. Acest nivel
este responsabil de alocarea spaiului de stocare a datelor i a indexurilor, de descrierea i
plasarea nregistrrilor n spaiul alocat, de codarea i compresia datelor.
Pe nivelul intern se folosesc modele fizice ale BD care descriu modul de stocare a datelor n
memoria calculatorului, structurile, ordinea i cile de accesare ale nregistrrilor.
Nivelul intern interacioneaz direct cu nivelul inferior, cel fizic, gestionat de sistemul de
operare.
20
Schema intern este legat de cea conceptual printr-o interfa de transpunere

conceptual/intern care transform ca format cererea procesului-client i rspunsul procesului-
server ntre cele dou nivele.
Schemele externe sunt deduse din cea conceptual prin transpunerea extern/conceptual.
Imunitatea schemelor externe fa de modificrile efectuate n schema conceptual reprezint
independena logic de date a BD.
Imunitatea schemei conceptuale fa de schimbrile intervenite n schema intern este
denumit independen fizic de date a BD.
I.7 REZUMATUL CAPITOLULUI
Baza de date (BD) reprezint o resurs unic de informaii, computerizat, stocat pe un

server sau distribuit pe mai multe servere, partajat ntre mai muli utilizatori, accesibil
local sau de la distan.
Proiectarea unei BD ncepe cu procesul de modelare a datelor, pe baza regulilor de afaceri,
exprimate de beneficiari n mod descriptiv sau sub forma unor ntrebri.
Primul pas este acela de identificare a entitilor, atributelor i a relaiilor care descriu baza de
date. Urmeaz realizarea diagramei entitate-relaie ntr-o prim form. Printr-o analiz
complex i sistematic, se reorganizeaz modelul astfel nct s nu existe elemente
redundante, atribute cu valori multiple, derivate sau volatile, astfel nct BD s poat
rspunde la toate ntrebrile exprimate de utilizatori i s se poat securiza accesul la
informaiile cu caracter critic. Entitile se asociaz cu tabelele din BD, atributele cu
coloanele din tabele iar nregistrrile care se fac n BD devin linii ale tabelelor.
Arhitectura ANSI-SPARC cu trei nivele a BD permite realizarea independent a structurii
BD fa de vederile externe create pentru diferitele categorii de utilizatori.
I.8 TERMENI SPECIFICI
baz de date (BD)

date
informaii
catalog de sistem
21
Baze de date_________________________________________________________________
dicionar de sistem
sistem de gestiune a bazei de date (SGBD)
tip de entitate
entitate
atribut
relaie
diagrama Entitate-Relaie
cheie primar
cheie alternativ
cheie candidat
cheie strin
model de date
model conceptual
reguli de afaceri
normalizare
limbaj de manipulare a datelor
limbaj de definire a datelor
limbaj de interogare
schema bazei de date
subschema bazei de date
tabel
tranzacie
vedere extern
baze de date relaionale
NULL
NOT NULL
UNIQUE
I.9 APLICAIE PROPUS
Realizai modelul conceptual i diagrama entitate-relaie pentru o BD folosind scenariul

urmtor:
22
Se dorete o BD pentru evidena produselor, clienilor i a angajailor unui magazin de

electrocasnice, organizat n mai multe departamente: vnzri, achiziii, personal, financiar,
transport.
BD va fi folosit pentru gestiunea produselor (denumire, categorie, pre de achiziie, pre de
vnzare, form de prezentare), a achiziiilor (date, cantiti, valori) i a stocurilor.
Departamentul de achiziii dorete s cunoasc situaia stocurilor pentru a planifica din timp
achiziiile de la furnizori. Se dorete s se dispun de evidena clienilor (date personale:
nume, prenume, cnp, adres, localitate de domiciliu, telefon). Departamentul Personal
solicit ca BD s gestioneze informaiile despre angajai (cod_angajat, nume, prenume, cnp,
funcie, departament, salariu, telefon).
Departamentul de Transport dorete s dispun de evidena comenzilor de transport a
produselor, fcute de clieni la achiziionarea acestora, pentru planificarea lor pe zone.
Managerul magazinului dorete s cunoasc activitatea de vnzare a fiecrui vnztor
pentru a recompensa pe cei mai performani angajai. Managerul este interesat de situaia
ncasrilor i a profitului obinut n diverse perioade de timp (zi, lun, an).
I.10 TEST-GRIL
1. Cum se definete o baz de date?
Colecie de date
Colecie partajat de date
Colecie partajat de date, ntre care exist relaii logice
Colecie partajat de date, ntre care exist relaii logice, mpreun cu descrierea datelor
2. ntr-un tabel din BD, un atribut al unei entiti definete:

o coloan
un cmp
o linie
un tabel
3. Null-ul reprezint:
Caracterul SPACE
Valoarea ZERO
Un ir de caractere zero
Lipsa valorii dintr-un cmp
23
Baze de date_________________________________________________________________
4. Popularea BD cu date este realizat de ctre:

proiectani
programatori
administratorul bazei de date
administratorul de sistem
5. Controlul accesului la baza de date se face prin:
catalogul de sistem
dicionarul de date
sistemul de gestiune al BD
schema BD
6. Identificarea nregistrrilor dintr-un tabel din BD se face printr-un atribut:

cheie
derivat
opional
volatil
7. Manipularea datelor din BD se face prin:

autentificare
citire
scriere
tergere
8. O entitate a unei BD se asociaz cu:

un tabel
o coloan din tabel
o linie din tabel
o celul din tabel
9. Descrierea datelor se face prin:

atribute
nregistrri
specificarea tipului de date
metadate
10. Modelul ANSI-SPARC pentru BD are:

dou nivele
trei nivele
patru nivele
apte nivele
24
CAPITOLUL II
ELEMENTELE SPECIFICE BAZELOR DE DATE
DIN CUPRINS:
II.1 ENTITATE
II.2 ATRIBUT
II.3 RELAIE
II.4 DIAGRAMA ENTITATE - RELAIE
II.5 CARDINALITATEA UNEI RELAII
II.6 VEDERE
II.7 REGULILE LUI CODD
II.8 TRANZACIA
II.9 REZUMATUL CAPITOLULUI
II.10 TERMENI SPECIFICI
II.11 APLICAIE PROPUS
II.12 TEST-GRIL
Baze de date_________________________________________________________________
II.1 ENTITATE
O baz de date poate fi descris n termenii fundamentali de entitate, instan, atribut, valoare,
identificator, relaie i tranzacie.
Orice baz de date folosete entiti pentru a clasifica obiectele pe care le gestioneaz.
Prin definiie, entitatea este un obiect distinct inclus n BD, asociat unei persoane, firme,
unui loc, document sau concept etc.
Atunci cnd se dorete folosirea unei baze de date pentru organizarea unei activiti, trebuie
puse n eviden elementele eseniale ale acesteia i clasificate, folosind entiti. De exemplu,
pentru baza de date a unei faculti este nevoie s folosim entitile STUDENT, PROFESOR,
DISCIPLIN, SAL DE CURS i altele.
Putem asocia entitatea unui grup de elemente de acelai fel, care pot fi niruite ntr-o list.
Numele entitii este ntotdeauna un substantiv, care semnific persoane, obiecte, evenimente.
Entitile au instane, adic valori particulare, care sunt asociate cu o singur apariie a
entitii respective n activitatea curent.
Studentul POPESCU ION va fi nregistrat n aceast baz de date ca o instan a entitii
STUDENT.
Studenta IONESCU ANA va fi nregistrat ca fiind o alt instan a entitii STUDENT.
Dac se asociaz un tabel entitii STUDENT, atunci n acest tabel vor aprea dou linii
corespunztoare celor doi studeni amintii.
Exerciiu propus: Dai exemplu de o entitate i de cteva instane ale ei.
ATENIE! Unul i acelai substantiv poate desemna ntr-o baz de date o entitate, iar n alt
baz de date o instan a unei entiti.
De exemplu, n baza de date cu animale, n entitatea ANIMAL poate s apar instana pisic,
alturi de altele precum cine, cal, tigru. n alt baz de date care descrie rasele de animale,
fiecare dintre acestea va constitui o entitate aparte, cu un set de nregistrri cu rasele
specifice. De exemplu, n al doilea caz vom include entitatea PISIC, cu rasele siamez,
persan, albastru de Rusia etc.
26
Dependena existenei unei entiti de o alt entitate se numete constrngere de

participare.
n general, acest tip de constrngere este dictat de regulile de afaceri ale activitii descrise n
BD. De exemplu, dac divizm o entitate n mai multe entiti pentru a separa informaiile cu
caracter privat de cele cu caracter public, atunci la tergerea entitii-printe va disprea i
entitatea nou-creat din aceasta. Este un caz n care apare o constrngere de participare.
Entitile pot fi clasificate dup mai multe criterii.
Entitatea poate avea un caracter concret, precum o persoan, un animal, o main, caz n care
spunem c avem de a face cu o entitate tangibil, sau poate avea un caracter abstract, precum
nivelul de pregtire al unui student sau gradul de dificultate al unui test, situaie n care
considerm ca fiind entitatea intangibil.
n cadrul aceleiai baze de date, putem lucra cu entiti mai importante, specifice i, n acelai
timp, eseniale n activitatea pe care o descrie BD, precum studenii unei faculti, numite
entiti tari sau putem folosi i entiti cu caracter general, precum localitile de domiciliu
sau rile din care provin studenii, pe care le folosim ca s creem nite liste de cutare pentru
completarea uoar i fr erori a unor formulare de nscriere n BD i pe care le vom numi
entiti slabe.
Fiecare entitate este asociat cu un tabel din structura intern a BD, pe care l numim relaie
n cazul BD relaionale.
II.2 ATRIBUT
O entitate este caracterizat printr-un set de atribute care permite identificarea, clasificarea
sau cuantificarea instanelor sale.
Numrul de atribute ale unui tabel sau relaii reprezint gradul relaiei.
Un atribut are o singur valoare pentru fiecare instan, la un anumit moment de timp. O
valoare a unui atribut se poate schimba n timp, prin modificarea sau actualizarea datelor.
De exemplu, atributul anul naterii al studentului POPESCU ION are valoarea 1990, n
timp ce adresa de domiciliu a acestuia, exprimat ca ir de caractere Iai, bd. Independenei,
nr. 10, bl. T, et.3, ap.12, este considerat tot o valoare unic. n acest caz, putem selecta
27
Baze de date_________________________________________________________________
studenii nscrii n BD i nscui ntr-un anumit an, dar nu putem face selecia dup
localitatea de domiciliu, pentru c localitatea apare doar ca o poriune dintr-un ir i nu ca un
atribut independent. Este important s se stabileasc de la nceput la ce ntrebri trebuie s
rspund BD pentru a alege corect toate atributele necesare penrtu descrierea unei entiti.
Atributele pot fi de dou tipuri:
volatile, cu valori care se schimb automat n timp, precum vrsta studentului, sau n
timpul activitii, de exemplu stocul de produse al unui magazin.
nevolatile, cu valoare fix, cum este anul de natere al studentului.
Chiar i unele atribute care se schimb foarte rar i atunci numai prin modificare direct,
dictat de administrator, vor fi considerate nevolatile. Este cazul, de exemplu, al atributului
numr de telefon. Dac o persoan i schimb numrul de telefon, poate solicita
administratorului BD s actualizeze valoarea cmpului respectiv. Avem de a face cu un
atribut nevolatil, care se schimb n anumite condiii i nu n mod automat.
Recomandare: Folosii atribute nevolatile i evitai, dac este posibil, atributele volatile.
Atributele volatile pot fi deduse din cele nevolatile i, n general, sunt folosite la afiarea unor
informaii specifice, precum vrsta unei persoane.
Valoarea unui atribut poate fi un ir de caractere, un numr, o dat calendaristic, o valoare
de timp, o imagine, un fiier audio etc. Toate acestea reprezint tipul sau formatul datelor.
Fiecare atribut este descris prin tipul de date folosit pentru exprimarea valorilor lui.
Metadatele includ tipul datelor pentru fiecare atribut din catalogul de sistem.
Valoarea unui atribut poate fi:

obligatorie (opiunea NOT NULL, notat uneori cu prefixul asterisc *)
opional (opiunea NULL, notat cu un cercule o)
De exemplu, numele, prenumele i adresa unui client al unui magazin online sunt atribute cu
valori obligatorii pentru a putea expedia marfa comandat unui magazin online. ns,
numrul de telefon fix este un atribut cu valoare opional, deoarece clientul poate s indice
doar un numr de telefon mobil.
Valoarea unui atribut care nu este cunoscut la un anumit moment sau nu este aplicabil
reprezint un null.
28
O alt caracterizare extrem de important a atributelor este aceea dat de unicitatea valorii
acestuia. Acele atribute folosite pentru identificarea unic a nregistrrilor dintr-un tabel din
BD trebuie s aib o valoare unic (opiunea UNIQUE) i nu valori repetate. De exemplu,
codul numeric personal este unic dar anul naterii unei persoane poate avea aceeai valoare n
mai multe nregistrri.
Exerciiu propus: Alegei o entitate dintr-o BD i enumerai cteva atribute ale ei. Specificai
pentru fiecare atribut caracterul pe care l are: obligatoriu/opional, volatil/nevolatil,
unic/repetitiv. Facei cteva nregistrri n tabelul asociat, cu valori specifice.
Dac o persoan, furnizeaz administratorului BD mai multe numere de telefon, atunci am fi

tentai s le nscriem pe toate n acelai cmp, eventual separate prin virgule. Spunem c
avem un atribut cu valori multiple, care ngreuneaz procesul de cutare i de sortare a
datelor din BD. Nu este indicat s folosii atribute cu valori multiple!
Recomandare: Definii mai multe atribute similare atunci cnd estimai posibilitatea
apariiei de valori multiple.
nregistrrile dintr-un tabel din BD sunt difereniate printr-un identificator unic (UID
Unique IDentifier) care poate fi un atribut sau un grup de atribute ale entitii asociate
tabelului, numit cheie sau supercheie.
O supercheie pentru care nici un subset de atribute nu este o supercheie se numete cheie
candidat.
Se pot gsi mai multe chei candidat pentru aceeai relaie, dar una singur este aleas, la un
anumit moment, ca UID i aceea este numit cheie primar (PK Primary Key). Cheia
primar se scrie subliniat n lista atributelor entitii, realizat n limbaj descriptiv, sau
precedat de caracterul diez #. Celelalte chei se numesc chei alternative. n mod firesc,
setul tuturor atributelor unei entiti, constituie un UID i o cheie. O cheie format din mai
multe atribute se numete cheie compus.
Uzual, se aleg ns acele chei cu ct mai puine atribute componente, de preferat unul singur,
cu redundan nul. Se obinuiete chiar s se defineasc un atribut abstract de tip
identificator, cu autoincrementare la fiecare nou nregistrare, asemenea numerelor de ordine
29
Baze de date_________________________________________________________________
folosite n tabele, care s fie cheia primar a entitii descrise i s fie format dintr-un singur
atribut.
Exerciiu propus: Deducei din setul de atribute al entitii STUDENT cheile posibile i
alegei cheia primar.
Atributul este asociat cu o coloan a unui tabel, avnd o denumire proprie, distinct. Ordinea
atributelor sau a coloanelor din tabel nu este important.
Domeniul este mulimea valorilor pe care le poate lua un atribut. Cnd vorbim de valori, nu
trebuie s ne gndim numai la valori numerice. De exemplu, putem avea valori de tip ir de
caractere sau de tip dat-timp i s impunem anumite restricii asupra acestora. Dac
nscriem codul numeric personal al unei persoane, este util s restricionm lungimea irului
i tipul caracterelor, adic s fie introduse exact 13 caractere i toate de tip cifr, de la 0 la
9.
Faptul c oricrui atribut i se dau valori dintr-un anumit domeniu reprezint o constrngere
de domeniu.
Alte reguli impuse de utilizatorii sau de administratorii unei BD se numesc constrngeri de
ntreprindere.
De exemplu, dac regulile afacerii specific moneda n care se exprim preurile produselor
unui magazin spunem c lucrm cu o constrngere de ntreprindere.
II.3 RELAIE
ntre entitile folosite pentru modelarea unei baze de date, se stabilesc o serie de relaii.
De exemplu, profesorul pune note studenilor. Studenii de la o specializare frecventeaz
orele de curs de la anumite discipline. Un profesor este titular la una sau mai multe discipline.
Toate aceste relaii pe care le identificm n scenariul bazei de date a unei faculti, pot fi
descrise prin anumite atribute de legtur. De exemplu, relaia EXAMEN STUDENT va fi
descris de atributul nrmatr, n relaia EXAMEN - DISCIPLIN intervine atributul
cod_disciplin i aa mai departe.
Relaia dintre dou entiti, privit ntr-un sens, poate avea fie caracter sigur, fie opional. De
exemplu, la o disciplin sigur se d mcar un examen dar este opional studiul unei discipline
de ctre un student, aceasta depinznd de specializarea la care acesta este nscris. Prin
30
convenie, relaiile sigure sunt reprezentate grafic, cu o linie continu, n timp ce relaiile
opionale se reprezint cu o linie ntrerupt (Figura II.1).
Anumite atribute se vor repeta atunci cnd se implementeaz baza de date, de exemplu n
limbaj SQL, tocmai pentru a evidenia relaiile dintre entiti.
Dac atributul de legtur este cheie ntr-un tabel, atunci, n tabelul n care este folosit pentru
relaionare, el se numete cheie strin (FK Foreign Key). De exemplu, atributul care
exprim numrul grupei, nr_grupa, care este cheie primar a entitii GRUPA, apare ca i
cheie strin n setul de atribute al entitii STUDENT.
Setul de atribute care constituie o cheie candidat a altei relaii se numete cheie strin.
Avem de a face aici cu o dublare aparent a datelor dar prin referina care se face ntre tabele,
datele se introduc o singur dat, n tabelul principal, urmnd s fie nscrise i actualizate
automat n tabelul relaionat cu primul.
Nici un atribut dintr-o cheie primar a unei relaii de baz nu poate fi null (lips valoare),
aceasta reprezentnd regula sau constrngerea de integritate a entitilor.
Valoarea unei chei strine trebuie s fie egal cu valoarea unei chei candidat din relaia sa de
baz sau un null. Aceast condiie reprezint regula de integritate referenial.
Se observ c este greu de descris n cuvinte scenariul pe care se va construi baza de date i,
de aceea, se prefer s se reprezinte grafic entitile, atributele i relaiile dintre acestea, sub
forma unei diagrame Entitate Relaie.
Exerciiu propus: Exprimai n cuvinte relaiile dintre entitile folosite n baza de date a unui
magazin (cea propus n paragraful I.9) i identificai atributele de legtur.
II.4 DIAGRAMA ENTITATE - RELAIE
Diagrama Entitate-Relaie (ERD Entity - Relation Diagram) modeleaz grafic BD. n

aceast diagram sunt reprezentate entitile, relaiile i, eventual, atributele, sub forma unui
graf neorientat.
31
Baze de date_________________________________________________________________
De exemplu, n figura II.1 este reprezentat succint (fr atribute) diagrama ER a BD a unei
faculti.
Se observ c diagrama ER nu depinde de modul de implementare a BD ca aplicaie final

(implementation-free). Nu am spus nimic despre cum se va implementa BD pentru c, n faza
modelrii conceptuale, acest lucru nu conteaz i pe baza diagramei ER se poate face
implementarea BD n mai multe moduri. Nici tipul de BD nu conteaz n etapa modelrii
d
STUDENT
este inclus n
este dat EXAMEN
include
se d
pred TITULAR
GRUP are
este inclus n este studiat DISCIPLIN este predat
include
studiaz
SPECIALIZARE
Fig. II.1 Diagram-Entitate Relaie
conceptuale. Aceasta poate fi realizat pe principiul BD relaionale, sau a BD ierarhice sau de

tip reea, inclusiv n varianta necomputerizat, cu date nregistrate pe suport de hrtie i
ndosariate. Organizarea datelor se face indiferent de tipul BD, prin modelarea conceptual.
Diagrama ER trebuie reprezentat i analizat ct mai minuios i sistematic, pentru a fi siguri
c prin entitile, atributele i relaiile definite, diagrama rspunde la toate ntrebrile puse n
faza de descriere a BD prin regulile de afaceri, exprimate n documentaia BD.
De exemplu, diagrama din figura II.1 poate s rspund la diverse ntrebri: Care dintre
studeni particip la un examen? Cu ce profesor se d un examen? Ci studeni sunt ntr-o
anumit grup?
Sunt foarte importante i atributele fiecrei entiti pentru c lipsa unor atribute poate s fac
imposibil rspunsul la anumite ntrebri ale beneficiarilor BD. De exemplu, dac n exemplul
de mai sus, entitatea EXAMEN nu are un atribut sal i atribute de tip dat i timp, atunci din
interogarea BD nu vom putea ti n ce sal, n ce zi i la ce or este planificat un examen.
32
Exerciiu propus: Completai diagrama ER din figura II.1 cu atributele asociate entitilor i
eventual cu noi entiti, care sunt necesare pentru ca BD s rspund la anumite ntrebri.
Scriei pe fiecare linie linie de legtur dintre entitile relaionate, care este atributul prin
care se exprim acea relaie.
Diagrama ER este realizat cu scopul de a cuprinde ntr-o structur simpl i bine organizat
toate datele care sunt necesare organizaiei beneficiare.
Regul: Informaiile trebuie s apar ntr-un singur loc din BD, adic s nu se repete.
De exemplu, nu vom scrie n tabelul disciplinelor informaii specifice cadrului didactic,

precum gradul didactic, deoarece aceasta ar nsemna s repetm aceeai informaie pe mai
multe linii din tabel, dac acesta pred mai multe discipline. Cnd titularul este promovat,
informaiile despre gradul didactic ar trebui reactualizate pe toate liniile disciplinelor predate
de el i exist riscul de a nu face toate modificrile necesare (erori ale operatorului uman). De
aceea, am definit o entitate separat pentru titularii de discipline, cu atribute specifice, pe care
o relaionm cu entitatea DISCIPLIN doar prin identificatorul unic al titularului.
Informaiile care pot fi deduse sau derivate din altele, nu vor fi i ele incluse n modelul BD
prin alte atribute. De exemplu, dac pentru o entitate ANGAJAT se folosete atributul
data_angajrii, atunci vechimea angajatului poate fi dedus din data curent i data angajrii
i nu trebuie s apar ca un atribut separat. n cazul atributelor derivabile, se pstreaz acel
atribut care nu are caracter volatil.
II.5 CARDINALITATEA UNEI RELAII
Descrierea unei relaii dintre entiti, se face i prin numrul de participani la o relaie. De
exemplu, ntr-o relaie DISCIPLIN TITULAR, un singur titular pred ntr-un an o
disciplin, la o anumit specializare. Totui un titular poate s predea mai multe discipline n
acelai an universitar. Vorbim n acest caz de o relaie unul-la-muli, notat simplu 1:M.
Numrul de participani la o relaie, exprimat n ambele sensuri, reprezint raportul de
cardinalitate al relaiei.
Raportul de cardinalitate este impus prin regulile de afaceri ale activitii decrise n BD.
33
Baze de date_________________________________________________________________
De exemplu, este posibil ca relaia DISCIPLIN TITULAR s aib un alt raport de

cardinalitate, de tipul muli-la-muli (M:M), dac regulile facultii permit ca aceeai
disciplin s poat fi predat de mai muli titulari iar studenii s poat alege ntre acetia.
Exist ns i relaii restrictive, de tipul unul-la-unul (1:1), n care intervine cte un singur
participant din partea fiecrei entiti implicate ntr-o relaie.
Un astfel de raport 1:1 poate s apar n mod firesc sau s fie restricionat de regulile
activitii. De exemplu, dac se consider baza de date a unui cabinet medical, relaia
PACIENT FI MEDICAL are un raport de cardinalitate 1:1 pe care l interpretm astfel:
orice pacient are o singur fi medical la acel cabinet, iar o fi medical corespunde unui
singur pacient.
In diagrama ER, raportul de cardinalitate poate fi pur i simplu scris pe fiecare linie prin care
se reprezint o relaie dintre entiti sau poate fi reprezentat grafic printr-o linie simpl n
cazul unui participant sau printr-un mnunchi de trei linii, pentru mai muli.
n Figura II.2, este reprezentat doar o parte a diagramei ER pentru BD a unei faculti. Sunt
figurate dou relaii, una de tipul 1:M i cealalt de tipul M:M. Interpretarea lor este
urmtoarea: Un student este inclus ntr-o singur grup, dar o grup include mai muli
studeni i un student d mai multe examene iar un examen este dat de mai muli studeni.
1:M M:M
include
d
GRUP STUDENT EXAMEN
este dat
este inclus n
Figura II.2 Reprezentarea grafic a cardinalitii unor relaii
Restriciile impuse asupra raportului de cardinalitate al unei relaii se numesc constrngeri

de cardinalitate.
Exerciiu propus: Completai diagrama ER din figura II.1 cu valorile rapoartelor de

cardinalitate corespunztoare relaiilor dintre entiti.
Atributul care exprim o relaie 1:1 poate fi ales din setul de chei al oricrei din cele dou
entiti implicate n relaie.
34
n cazul relaiilor 1:M, atributul de legtur trebuie ales numai de la entitatea cu participare
singular la relaie. Dac s-ar alege pentru exprimarea relaiei un atribut cheie de la entitatea
cu participare multipl, atunci n tabelul celeilalte entiti vor aprea valori multiple pentru
acel atribut.
n relaiile M:M, indiferent din care parte a relaiei se alege atributul de relaionare, acesta va
avea valori multiple.
n general, nu se admit atribute cu valori multiple i de aceea nici relaiile M:M nu sunt
acceptate. Relaiile M:M trebuie eliminate din diagrama ER prin definirea de noi entiti.
II.6 VEDERE
O relaie (tabel) produs la cererea unui client pe baza relaiilor existente n BD se numete
vedere (view).
Putem considera vederea extern din BD ca fiind o relaie virtual, adic se genereaz un
tabel virtual, afiat n vederea extern, pe baza datelor existente n tabelele reale din BD. Acel
tabel din vederea extern nu exist de fapt n BD.
Pentru a diferenia tabelele din BD, n care stocm datele, de cele create n vederile externe,
vom folosi termenul de relaie de baz pentru tabelele interne.
O relaie cu o anumit denumire, corespunztoare unei entiti din schema conceptual a BD,
ale crei tupluri sunt stocate fizic n BD, se numete relaie de baz.
Trebuie s se fac distincie ntre datele stocate intern, n tabelele din BD, i informaiile care
sunt afiate n vederile externe.
Conform arhitecturii ANSI-SPARC, nivelul extern este complet separat de cel intern, i de
aceea structura intern a unei BD nu poate fi dedus din vederile externe. De aceea spunem
c vederile se genereaz n mod transparent. Informaiile care se afieaz pot fi toate citite sau
derivate din diferite date, stocate n unul sau mai multe tabele.
De exemplu, dac se dorete afiarea notelor obinute la examene de studenii unei grupe la
toate disciplinele dintr-un semestru, atunci se vor citi datele din relaiile de baz
corespunztoare entitilor STUDENT, GRUP, EXAMEN, DISCIPLIN, relaionate prin
atribute abstracte de tip nrmatr, nr_grup, cod_disciplin, urmnd ca afiarea listei s se
realizeze cu etichete sugestive de genul Numele i prenumele, Grupa, Denumirea disciplinei,
Not.
35
Baze de date_________________________________________________________________
Exerciiu propus: Reprezentai capul de tabel al unei vederi externe prin care s se afieze
lista disiciplinelor i a titularilor care predau la o specializare, generat pe baza diagramei
ER din figura II.1, cu denumiri de coloan ct mai sugestive. Din ce relaii de baz se culeg
datele pentru aceast vedere extern? Care sunt atributele folosite?
Se pot adopta diferite formate de afiare a rezultatelor interogrilor, n funcie de specificul

aplicaiei i de preferinele utilizatorilor bazei de date.
Prin utilizarea vederilor se asigur securitatea BD i se personalizeaz vederile fiecrui
utilizator.
Vederile sunt dinamice i orice modificare n relaiile de baz se reflect n vederile externe.
Succesiunea evenimentelor, n cazul realizrii unor modificri ale datelor, este dictat de
regulile de afaceri care descriu aplicaia.
De exemplu, se poate solicita modificarea instantanee a valorii afiate dac se reactualizeaz
datele din BD, sau se poate impune meninerea vechilor valori n vederile externe i doar la o
nou accesare a aplicaiei s se actualizeze i vederile externe.
De exemplu, la o burs de valori utilizatorii vor s tie imediat dac se schimb valorile
aciunilor, n timp ce pentru BD a unei biblioteci care primete volume noi, este posibil s nu
se doreasc afiarea instantanee a noilor titluri, pn nu se definitiveaz lista acestora.
De aceea spunem c nu toate vederile pot fi reactualizate.
Exist vederi externe prin intermediul crora se pot manipula datele din BD. De exemplu, o
vedere extern care conine un formular de nscriere n BD cu clienii unui magazin, permite
introducerea datelor n relaiile de baz ale BD. Dac vederea este reactualizat, de exemplu
clientul i schimb domiciliul sau numrul de telefon, atunci i relaia de baz prin care a
fost generat, trebuie reactualizat.
Observaii:
Nu sunt permise reactualizrile prin intermediul vederilor care implic relaii de baz
multiple sau operaii de acumulare sau de grupare a atributelor.
Este permis modificarea structurii datelor sau a modalitilor de stocare a lor fr a
afecta vederile externe (tabelele virtuale).
Eliminarea anumitor elemente (cmpuri, atribute etc) din schema BD poate deranja
vederile care le utilizeaz la momentul respectiv. Acest neajuns este evitat prin
tratarea corespunztoare a tranzaciilor n BD.
36
II.7 REGULILE LUI CODD
n prezent, cele mai utilizate sunt bazele de date relaionale (BDR). Accesul la acestea i
gestionarea lor se face cu un sistem de gestiune a bazelor de date relaionale (SGBDR, n
englez RDBMS Relational Database Management System).
Codd a enunat o regul fundamental i 12 reguli specifice pentru SGBDR:
Regula fundamental
Orice sistem care pretinde sau i se face reclam de a fi un SGBDR trebuie s fie capabil s
gestioneaze n ntregime bazele de date prin capacitile sale de relaionare.
Cnd vorbim de relaionare, ne referim la relaiile dintre atributele unei entiti, n cadrul unui
singur tabel, dar i la relaiile care se stabilesc ntre mai multe entiti, prin atributele de
legtur. Capacitatea de a relaiona informaiile se refer la o funcionare perfect, fr erori,
a SGBD. Dac datele sunt dublate n BD i pot s apar erori de acualizare, considerm c
acel SGBD nu gestioneaz corect datele. Dac nu exist anumite legturi ntre entiti, atunci
este posibil ca unele raportri s fie eronate, prin urmare avem de a face cu un SGBD
imperfect.
Cele dousprezece reguli enunate de Codd pentru BDR sunt urmtoarele:
1. Reprezentarea informaiilor
La nivelul logic, toate informaiile dintr-o BD relaional sunt reprezentate explicit ntr-un
singur mod prin valorile din tabele (relaii de baz).
2. Accesul garantat
Se garanteaz faptul c orice element (dat) dintr-o BDR este accesibil din punct de vedere
logic prin apelarea la o combinaie de nume de tabel, valoare a cheii primare i nume de
coloan.
3. Tratarea sistematic a valorilor null

Valorile null sunt acceptate pentru a reprezenta informaiile lips i pe cele care nu pot fi
aplicate n mod sistematic, indiferent de tipul de date.
37
Baze de date_________________________________________________________________
4. Catalog dinamic online, bazat pe modelul relaional

Descrierea BD este reprezentat la nivel logic n acelai mod ca i datele obinuite, astfel
nct utilizatorii autorizai pot folosi pentru interogarea acesteia acelai limbaj relaional
aplicat datelor curente.
5. Sublimbaje de date cuprinztoare

Un sistem relaional poate accepta mai multe limbaje i diverse moduri de utilizare a
terminalelor. Totui trebuie s existe cel puin un limbaj ale crui instruciuni s poat
exprima urmtoarele:
definirea datelor
definirea vederilor
manipularea datelor
constrngerile de integritate
autorizarea
limitele tranzaciilor (nceput, efectuare i rulare napoi).
6. Reactualizarea vederilor
Toate vederile care sunt teoretic reactualizabile, pot fi reactualizate de ctre sistem.
7. Operaii de inserare, reactualizare i tergere de nivel nalt

Capacitatea de tratare a unei relaii de baz sau a unei relaii derivate (vedere) ca pe un
singur operand se aplic nu numai regsirii datelor n BD, ci i inserrii, reactualizrii i
tergerii acestora.
8. Independena fizic de date

Programele de aplicaii i activitile de la terminale rmn logic intacte ori de cte ori sunt
fcute modificri, fie n metodele de stocare, fie n metodele de acces la date.
9. Independena logic de date
Programele de aplicaii i activitile de la terminale rmn logic intacte ori de cte ori sunt
fcute modificri n tabelele de baz cu pstrarea informaiilor sau deteriorarea acestora.
10. Independena de integritate

Constrngerile de integritate specifice unei anumite BDR trebuie s poat fi definite n
sublimbajul relaional de date i stocate n catalogul de sistem, nu n programele de aplicaii.
38
11. Independena de distribuie

Sublimbajul de manipulare a datelor dintr-un SGBDR trebuie s permit programelor de
aplicaiii interogrilor s rmn aceleai din punct de vedere logic dac i ori de cte ori
datele sunt centralizate sau distribuite fizic.
12. Regula de nonsubversiune

Dac un sistem relaional are un limbaj de nivel jos (cte-o-nregistrare-o-dat), atunci acel
nivel nu poate fi folosit pentru a submina sau a ocoli regulile de integritate i constrngerile
exprimate n limbajul relaional de nivel mai nalt (mai-multe-nregistrri-deodat).
De-a lungul timpului regulile lui Codd au fost strnit multe controverse, dar se pare c ele
sunt utile pentru analiza caracterului relaional al oricrui SGBD. Un SGBD care nu le
ndeplinete este cu siguran nerelaional.
II.8 TRANZACIA
Definiie: Tranzacia este definit ca o secven de operaii care se execut ca o singur

funcie logic, asupra unei BD partajate ntre mai muli utilizatori.
Operaiile realizate ntr-o tranzacie, ca un tot unitar, pot s fie de citire, scriere, tergere,
creare i se pot efectua asupra datelor dar i asupra structurii de date. Este important ca s se
efectueze integral i corect succesiunea de operaii propus, nu parial. n cazul n care o
tranzacie este incomplet, din diferite cauze (defeciune tehnic, eroare de program etc.), BD
trebuie s revin la starea iniial, pe care o avea nainte de iniierea tranzaciei (Figura II.3).
Spunem c BD trebuie s fie permanent ntr-o stare stabil, coerent sau consistent.
Tranzacia efectueaz transformri consistente asupra strii sistemului, meninnd consistena
acestuia.
39
Baze de date_________________________________________________________________
BD n stare
BD n stare intermediar BD n stare
instabil consistent
consistent
nceputul efectuarea sfritul

tranzaciei tranzaciei tranzaciei
Fig.II.3 Etapele unei tranzacii
Se definesc trei tipuri de tranzacii:

de regsire a datelor n BD, pentru afiarea lor sau crearea unui raport (de tip tabel,
diagram etc.)
de reactualizare a datelor, prin inserarea de noi date, tergerea sau modificarea celor
existente.
mixte, de regsire i reactualizare.
Tranzaciile se proiecteaz odat cu BD i trebuie specificat comportamentul SGBD n cazul
fiecreia, prin opiuni de derulare a tranzaciilor, exprimate apoi, n faza de implementare a
BD, n limbajul de programare adoptat (n particular SQL).
De exemplu, este important ordinea n care se vor efectua comenzile de mrire de salariu i
de acordare a unui premiu unui angajat. S presupunem c la un salariu de 3000 RON, se
acord, la aceeai dat, o majorare de salariu de 20 % i o prim de 10 %. Dac se face mai
nti calculul primei, atunci aceasta va fi de 300 RON. Dac mai nti se majoreaz salariul la
3600 RON i apoi se acord prima, valoarea ei va fi de 360 RON.
Ordinea n care se fac aceste operaii conteaz i ea este stabilit prin regulile de afaceri care
descriu activitatea firmei n cauz.
40
II.9 REZUMATUL CAPITOLULUI
Modelarea conceptual a unei BD se face n termenii specifici de entitate, instan, atribut,

valoare, identificator, relaie i tranzacie.
Modul de alegere a entitilor i atributelor, stabilirea cheilor i a relaiilor dintre entiti,
precum i constrngerile care se impun (de domeniu, de participare, de integritate, de
cardinalitate) depind de scenariul sau regulile de afaceri care descriu aplicaia bazei de date.
Tranzaciile trebuie i ele descrise n acest scenariu pentru ca proiectanii i programatorii s
poat modela i implementa corect BD.
Unei entiti i se asociaz un tabel, unei instane a entitii i corespunde o linie sau o
nregistrare din tabel iar atributele apar ca i coloane.
Fiecare atribut are pentru o instan o valoare unic. Aa-zisele valori multiple trebuie evitate,
deoarece nu permit sortarea corect a datelor.
Cardinalitatea relaiei, exprimat prin numrul participanilor la o relaie dintre dou entiti,
poate fi 1:1, 1:M sau M:M. Relaiile M:M trebuie eliminate din diagrama ER.
II.10 TERMENI SPECIFICI
Entitate
Instan
Entitate tare
Entitate slab
Entitate tangibil
Entitate intangibil
Atribut
Atribut volatil
Atribut nevolatil
Atribut derivat
Valoare
Valoare obligatorie
Valoare opional
Valoare unic
41
Baze de date_________________________________________________________________
Valori multiple
Tipul datelor
Identificator unic (UID)
Cheie primar (PK)
Cheie candidat
Cheie alternativ
Cheie compus
Cheie strin (FK)
Diagrama Entitate Relaie
Raportul de cardinalitate
1:1
1:M
M:M
Constrngere de domeniu
Constrngere de integritate
Constrngere de cardinalitate
Constrngere de participare
Regula de integritate referenial
Regulile lui Codd
Relaie de baz
Relaie virtual
Vedere
Tranzacii de regsire
Tranzacii de reactualizare
Tranzacii mixte
II.11 APLICAIE PROPUS
Considerm scenariul BD a unui magazin online cu un anumit specific. Stabilii ntrebrile la

care trebuie s rspund aceasta din diverse perspective de utilizare (client, agent de vnzri,
manager). Reprezentai diagrama ER, indicnd raportul de cardinalitate al fiecrei relaii i
42
atributele de legtur. Verificai dac modelul ER astfel conceput rspunde ntrebrilor

beneficiarilor. Formulai modul de desfurare a unor tranzacii i impunei constrngerile
necesare pentru funcionarea corect a SGBD.
II.12 TEST-GRIL
1. Ce elemente sunt reprezentate n diagrama ER?

atribute
entiti
tabele
tranzacii
2. O coloan dintr-un tabel din BD se asociaz cu:

un atribut
o entitate
o nregistrare
o relaie
3. Restriciile impuse valorilor pe care le poate lua un atribut, reprezint:

Constrngeri de cardinalitate
Constrngeri de domeniu
Constrngeri de integritate
Constrngeri de participare
4. n BD a unui cabinet medical, pentru entitatea PACIENT se folosesc atributele de mai

jos. Care dintre ele are caracter volatil?
nume
prenume
vrsta
ocupaia
5. Respectarea constrngerii de integritate se face prin opiunea:

DEFAULT
NULL
NOT NULL
UNIQUE
43
Baze de date_________________________________________________________________
6. Este adevrat c atributul de legtur dintre dou entiti:

este cheia primar a unei entiti
este cheie candidat a unei entiti
este cheie strin a unei entiti
poate avea valori multiple
7. O entitate are o cheie primar, dou atribute de tip NOT NULL i trei atribute opionale.
Care este gradul relaiei asociate entitii?
1
2
3
6
8. ntre dou entiti ale unui magazin, CUMPRTOR i PRODUS, ce fel de relaie se
stabilete?
1:1
1:M
M:M
9. Din setul de atribute al entitii PERSOAN (nume, prenume, data_naterii, adres,

localitate, jude, serie_carte_de_identitate, numr_carte_de_identitate, cnp), care sunt
cheile candidat care se pot defini?
......................................................................................................................................................
......................................................................................................................................................
......................................................................................................................................................
......................................................................................................................................................
10. Un set de operaii care trebuie efectuate ntr-o BD, toate n bloc, se numete:
cheie
instan
tranzacie
vedere
44
CAPITOLUL III
DIAGRAMA ENTITATE-RELAIE
DIN CUPRINS:
III.1 ALEGEREA SETULUI DE ENTITI I ATRIBUTE
III.2 CONCEPTELE MODELULUI ENTITATE-RELAIE
III.3 REPREZENTAREA GRAFIC A DIAGRAMEI ER
III.4 CAPCANE DE CONECTARE
III.5 INTERPRETAREA DIAGRAMEI ER
III.6 MATRICEA RELAIILOR
III.7 NORMALIZAREA
III.8 REZUMATUL CAPITOLULUI
III.9 TERMENI SPECIFICI
III.10 TEST-GRIL
Baze de date_________________________________________________________________
III.1 ALEGEREA SETULUI DE ENTITI I ATRIBUTE
Modelarea unei BD ncepe cu identificarea entitilor, atributelor i a relaiilor dintre entiti.

Reprezentarea lor grafic se face sub forma diagramei Entitate-Relaie (ER), respectnd
anumite convenii.
Modelul Entitate-Relaie (ER) reprezint principala tehnic de proiectare conceptual a BD.
Se mai folosete i modelul orientat pe obiecte, care extinde definiia entitii prin luarea n
considerare i a comportamentului acesteia, pe lng atributele care descriu starea ei.
Modelul ER sau schema conceptual a bazei de date se exprim n limbaj descriptiv printr-o
serie de relaii, specificate prin numele lor (numele entitii), urmat de atributele fiecreia
ntre paranteze, cheia primar fiind subliniat.
De exemplu, o baz de date a unui magazin cuprinde date despre clieni, angajai i produsele
oferite:
clieni (cod_client, nume, prenume, adres, telefon, cnp, adres_de_email)
angajai (id_angajat, nume, prenume, funcie, salariu, data de natere, cnp, adresa,
telefon)
produse (cod_produs, denumire, categorie, pre de vnzare, furnizor).
Alegerea identificatorului unic (UID) i a cheii primare ai unei entiti nu este o chestiune
foarte simpl. UID poate fi ceva foarte natural precum numele unei strzi sau ceva artificial,
creat special pentru a face diferena ntre mai multe instane (codul potal). Se poate folosi ca
UID un singur atribut sau un set de mai multe atribute. Clasificm astfel identificatorii unici
ai entitilor n simpli i compui. Dintre toi UID posibili ai unei entiti, trebuie ales cel mai
potrivit UID ca i cheie primar, pe care l numim UID primar. Ceilali UID se numesc
identificatori unici secundari sau chei candidat. De exemplu, pentru entitatea CLIENT
descris mai sus, se pot folosi mai muli UID: cod_client, cnp, adres_de_email care sunt
fiecare n parte identificatori simpli, sau se poate folosi un UID compus (nume, prenume,
adres). Alegerea cheii primare dintre toi aceti UID rmne la latitudinea proiectantului
care l va alege pe cel mai potrivit din perspectiva clientului precum i din a cea a aplicaiei.
Nu sunt deocamdat exprimate relaiile ntre entiti, dar formulnd eventuale interogri ale
BD vom putea stabili anumite legturi.
De exemplu, s presupunem c managerul magazinului dorete s interogheze BD pentru
aflarea ncasrilor dintr-o lun. Dac nu exist o entitate asociat vnzrilor, cu un atribut
46
referitor la preul de vnzare i la numrul de buci vndute, atunci efectuarea acelei

interogri este imposibil. Dac acelai manager vrea s afle profitul magazinului pe o lun
dar BD nu ofer informaii privind cheltuielile magazinului (salariale, administrative sau de
transport) i nici preul de achiziie al fiecrui produs, ci numai preul de vnzare, este din
nou imposibil ca BD s ofere informaia cerut.
Pe de alt parte dac acea interogare nu este dorit i BD servete numai la gestiunea
produselor, atunci este posibil s ncrcm excesiv modelul BD cu entiti i atribute care nu
servesc unor interogri fcute de utilizatori.
n acest sens, este necesar analiza setului de entiti definite, precum i a atributelor folosite,
pentru a fi siguri c BD rspunde la toate interogrile probabile.
Exerciiu propus: Pentru BD descris n modelul anterior, stabilii noi entiti i atribute
necesare realizrii interogrilor referitoare la vnzri i profit, descrise anterior. Transcriei
n limbaj descriptiv noul set entiti-atribute.
Relaionarea entitilor seamn cu un joc de puzzle. De obicei avem multe entiti, cu multe
atribute i chiar reprezentarea grafic a diagramei poate fi dificil i greu de urmrit.
Diagrama ER trebuie analizat cu atenie pentru a nu avea relaii lips. Optimizarea
diagramei implic i mai multe aspecte, de aplicare a unor reguli de normalizare, care permit
eliminarea riscurilor de apariie a unor erori sau omisiuni, la folosirea propriu-zis a bazei de
date. Acestea sunt de regul greu observabile n procesul de proiectare a BD i odat
implementat aplicaia cu BD, ele nu mai pot fi corectate.
De aceea este util s abordm sistematic procesul de reprezentare, analiz i de prelucrare a
diagramei ER.
III.2 CONCEPTELE MODELULUI ENTITATE-RELAIE
Modelul conceptual Entitate-Relaie (ER), dezvoltat iniial de Chen n 1976, descrie structura
BD i tranzaciile de regsire i reactualizare a datelor. Modelul ER se realizeaz independent
de SGBD i de platforma hardware pe care se va rula aplicaia BD.
S ne reaminitim c modelul ER include urmtoarele concepte:
47
Baze de date_________________________________________________________________
Tip de entitate obiect (fizic) sau concept (abstract) inclus n BD, cu existen
independent.
Entitate instan a unui tip de entitate, unic identificabil.
Tip de entitate slab tip de entitate a crei existen depinde de alte tipuri de entiti.
Tip de entitate tare tip de entitate a crei existen nu depinde de alte tipuri de entiti.
Tip de relaie asociere ntre tipuri de entiti.
Prin convenie, fiecrei entiti i corespunde n BD un tabel sau o aa-numit relaie, pe

care o denumim prin forma de plural a numelui entitii n cauz, uzual scris cu litere mici.
De exemplu, entitii STUDENT i va corespunde n BD tabelul studeni.
Relaie o instan a unui tip de relaie.

Gradul unei relaii numrul de entiti implicate n acea relaie (unar, binar, ternar etc)
Relaie recursiv relaie n care o entitate particip de mai multe ori, cu diferite roluri.
Raportul de cardinalitate descrie numrul de entiti implicate de fiecare parte a unei
relaii (1:1, unu-la-muli 1:M, muli-la-muli M:N).
Regul de afaceri regula pe baza creia se stabilete un raport de cardinalitate.
Atributul entitii proprietatea unui tip de entitate.
Atributul relaiei proprietate a unei relaii.
Atribut simplu atribut cu o singur component.
Atribut compus atribut cu mai multe componente, cu existene independente.
Domeniul atributului mulimea valorilor pe care le poate lua un atribut.
Atribut cu o singur valoare atribut care conine o singur valoare pentru o entitate.
Atribut cu valori multiple atribut care conine mai multe valori n acelai cmp.
Atribut derivat atribut dedus din valorile unui alt atribut sau set de atribute.
Cheie articol de date care permite identificarea n mod unic instana unui tip de entitate.
Cheie candidat atribut sau set de atribute care identific n mod unic instana unui tip de
entitate.
Cheie primar cheia candidat aleas pentru identificarea instanelor unei entiti.
Cheie alternativ cheie candidat neutilizat ca i cheie primar.
Cheie simpl cheie candidat format dintr-un singur atribut.
Cheie compus cheie candidat format din mai multe atribute.
48
Asupra entitilor i relaiilor din modelul ER se pot defini constrngeri:

de cardinalitate, exprimate prin raportul de cardinalitate i impuse de regulile de
afaceri ale firmei.
de participare, exprimnd dependena existenei unei entiti de o alt entitate.
de integritate, prin care se impune existena unei valori ntr-un anumit cmp
aparinnd cheii primare.
refereniale, impuse asupra relaiilor dintre entiti sau tabele, prin care cheia strin
ia aceleai valori ca i cheia primar din tabelul de referin sau este NULL.
Participarea unei entiti ntr-o relaie poate fi:
total sau obligatorie (participarea la acea relaie este garantat i se exprim prin
termenii trebuie s ... sau sigur ...);
parial sau opional (participarea la acea relaie este posibil, dar nu sigur, i poate
fi exprimat prin termenii poate s ... sau este posibil ca ...).
III.3 REPREZENTAREA GRAFIC A DIAGRAMEI ENTITATE-

RELAIE
Modelul ER poate fi reprezentat grafic sub forma unei diagrame ER n care se aplic regulile
urmtoare, ale aa-numitei convenii n stea (Figura III.1):
Fig. III.1 Reprezentarea grafic a elementelor modelului ER
49
Baze de date_________________________________________________________________
Entitile sunt reprezentate ca dreptunghiuri etichetate cu numele acestora, cu chenar

simplu pentru entitile tari i dublu pentru cele slabe.
Atributele sunt reprezentate schematic sub forma unor elipse etichetate cu numele
acestora i legate de entitatea pe care o descriu prin segmente de dreapt, sub forma
unor raze. Denumirea cheii primare se subliniaz. Conturul elipsei este continuu dac
reprezint atribute propriu-zise i discontinuu pentru atributele derivate. Conturul
elipsei este reprezentat printr-o linie dubl n cazul atributelor cu valori multiple.
Relaiile sunt reprezentate sub form de romburi, etichetate cu numele relaiei, cu
chenar simplu ntre entiti tari i cu chenar dublu cnd n relaie este implicat o
entitate slab.
Rapoartele de cardinalitate se reprezint ca etichete ale liniilor ce unesc entitile
implicate ntr-o relaie.
Liniile de legtur ntre simbolurile grafice ale entitilor i relaiilor sunt simple dac
participarea este parial i duble cnd participarea entitii la acea relaie este total.
Liniile de legtur pot fi etichetate i cu valorile minim i maxim ale numrului de
entiti implicate ntr-o relaie, scrise ntre paranteze.
Se observ din figura III.2 c, dac se folosete un numr mare de atribute, reprezentarea
grafic este greoaie i dificil de urmrit.
De aceea, se prefer convenia de reprezentare n dreptunghi, n care atributele unei entiti
sunt nscrise toate n dreptunghiul asociat acesteia i se au n vedere urmtoarele reguli:
O entitate se reprezint printr-un dreptunghi (softbox), n care se scrie numele entitii,
la singular, cu toate literele mari.
Aributele entitii se scriu unul sub cellalt n acelai dreptunghi, sub numele entitii,
cu litere mici.
Cheia primar se scrie prima n lista de atribute i se marcheaz cu un diez (#).
Un atribut obligatoriu se marcheaz cu un asterisc (*).
Un atribut cu valoare opional se marcheaz cu un cercule (o).
Relaia dintre dou entiti se reprezint printr-o linie, etichetat cu numele relaiei.
Linia de legtur dintre entiti este continu dac participarea entitii la relaie este
total sau obligatorie.
Linia de legtur dintre entiti este ntrerupt la captul la care participarea entitii
este opional.
50
Relaia se reprezint cu un capt ramificat, n trei (talpa gtei), dac o entitate are o
participare multipl la acea relaie.
Exerciiu propus: Redesenai diagrama din figura III.2, folosind convenia n dreptunghi.
Dac mai multe persoane folosesc acelai set de entiti i atribute pentru a desena diagrama
ER, este posibil s se obin diferite reprezentri, n funcie de amplasarea n plan a
dreptunghiurilor prin care reprezentm entitile. De aceea, s-a stabilit regula de orientare a
diagramei ER care impune sensul n care trebuie reprezentat i citit aceasta: de la stnga
la dreapta i de sus n jos. Putem interpreta aceast regul astfel: colul de pornire este cel
din stnga-sus, iar cel de finalizare a diagramei este cel din dreapta-jos (Figura III.3).
Figura III.2 Exemplu de diagram ER, reprezentat prin convenia n stea
Figura III.3 Sensul de reprezentare i de citire a diagramei ER

51
Baze de date_________________________________________________________________
Reprezentarea grafic a modelului ER ca diagram ER, respectnd anumite convenii

prestabilite, constituie un mod universal de comunicare, pe care nu ni-l ofer descrierea n
cuvinte a aplicaiei cu BD.
III.4 CAPCANE DE CONECTARE
n proiectarea modelului de date conceptual, pot s apar anumite ambiguiti de interpretare

a relaiilor care s conduc la imposibilitatea soluionrii unor interogri asupra BD. Aceste
probleme ale modelului ER se numesc capcane de conectare i sunt de dou tipuri:
Capcanele n evantai apar atunci cnd aceeai entitate este implicat n mai multe relaii
de tip 1:M i cile dintre entiti devin ambigue. De exemplu, din diagrama ER reprezentat
n figura III.4 nu putem deduce exact care proprieti sunt administrate de un anumit membru
de personal. Prin modificarea ordinii de reprezentare a entitilor implicate n aceste relaii se
obine o structur de tip arbore prin care se elimin ambiguitatea diagramei (Figura III.5).
Figura III.4 Model ER cu capcan n evantai
Capcanele de ntrerupere sunt cauzate de absena reprezentrii unor relaii n modelul ER.
De exemplu, n modelul din figura III.5 lipsete relaia direct dintre entitile Departament i
Proprieti, necesar identificrii departamentului care se ocup de o anumit proprietate.
Introducnd-o (Figura III.6), se creeaz o anumit redundan, preferabil n unele situaii.
52
Figura III.5 Model ER modificat pentru eliminarea capcanei n evantai
Figura III.6 Model ER modificat pentru eliminarea capcanei de ntrerupere
III.5 INTERPRETAREA DIAGRAMEI ENTITATE-RELAIE
Revenind diagrama ER, pentru a o urmri ca i continuitate, este util s exprimm n cuvinte,
cursiv, relaiile dintre entiti, pentra a fi siguri c sunt logice, asemntor modului n care se
exprim relaiile de rudenie, de colegialitate sau de prietenie dintre mai multe persoane. De
exemplu, eu sunt prietena Cristinei, sora lui Radu, colegul tu de grup.
53
Baze de date_________________________________________________________________
Este util s exprimm adecvat opionalitatea relaiei (sigur sau probabil) i cardinalitatea
ei (mai multe entiti sau doar una singur intr n relaie), la ambele capete ale unei
conexiuni.
Pentru fiecare relaie din diagrama ER, vom formula cte dou fraze de forma:
Fiecare ENTITATE de tip 1 sigur sau poate - se relaioneaz cu una sau mai multe
ENTITI de tip 2.
S nu uitm c relaia trebuie interpretat n ambele sensuri, prima or n sensul de la stnga
la dreapta sau de sus n jos.
S descompunem fraza de mai sus n elementele sale componente:
1. Fiecare
2. ENTITATE de tip 1
3. sigur sau poate (OPIONALITATEA)
4. se relaioneaz cu (NUMELE RELAIEI)
5. una sau mai multe (CARDINALITATEA)
6. ENTITI de tip 2.
Opionalitatea i cardinalitatea unei conexiuni dintre entiti pot s difere de la un capt la
altul.
S citim, de exemplu, diagrama din figura III.5.
Fiecare proprietate este sigur supervizat de un singur membru al personalului.
Fiecare membru din personal poate s supervizeze mai multe proprieti.
Fiecare membru al personalului sigur este alocat unui singur departament.
Fiecare departament sigur include mai muli membri.
n general, ceea ce citim din diagrama ER, regsim n descrirea sau scenariul aplicaiei,
adic n regulile de afaceri ale acesteia. De aceea, este util s se compare aceste reguli, cu
relaiile citite din diagrama ER, pentru a identifica eventualele relaii care lipsesc din
diagram sau pe cele care nu corespund regulilor afacerii. De asemenea, pot s existe
neclariti n interpretarea diagramei i n astfel de cazuri se pot cere lmuriri reprezentanilor
beneficiarului, pentru a formula regulile n cauz i a elimina ambiguitile.
Exerciiu propus: Interpretai diagrama ER din figura III.2, exprimnd de fiecare dat
opionalitatea i cardinalitatea relaiei.
54
Este posibil ca o relaie s se stabileasc n bucl, de la o entitate la ea nsi. Este cazul

care se refer la o asociere ntre membrii aceluiai tip de entitate. De exemplu, ne intereseaz
s ierarhizm angajaii dintr-un departament, pentru a ti fiecare angajat sau membru din
departament, cui i este subordonat. Pentru aceasta, se poate crea o bucl pe entitatea
PERSONAL, prin atributul ef.
Interpretarea diagramei ER face posibil verificarea modelului ER creat pentru o aplicaie de
BD. Se pot pune noi ntrebri beneficiarului, pentru a stabili att relaiile-lips, ct i
opionalitatea i cardinalitatea relaiilor, aa cum sunt ele vzute de beneficiar, de specialistul
n domeniul aplicaiei i nu de proiectanii BD. Proiectantul BD nu trebuie s impun el ci
participani sunt la o relaie i nici dac aceast participare este sigur sau opional. Regulile
de opionalitate i de cardinalitate sunt impuse de beneficiar.
Interpretarea diagramei ER pe care o face proiectantul BD urmeaz s fie citit de beneficiar,
pentru ca acesta s i exprime acordul sau dezacordul cu modul n care au fost nelese
aspectele activitii sale de ctre proiectant.
De exemplu, dac modelai datele pentru o BD dintr-o uzin chimic, fr a avea cunotine
de specialitate n acel domeniu, este util ca modelul sau modelele pe care le facei s fie de
fiecare dat verificate de un specialist, pentru a nu avea erori de interpretare.
III.6 MATRICEA RELAIILOR
O diagram ER n prima sa form, neprelucrat, conine o serie de relaii pe care proiectantul

le-a identificat pe baza ntrebrilor posibile ale utilizatorilor.
Este util s stabilim toate interogrile posibile ale BD nainte de a trece la optimizarea
diagramei entitate-relaie.
Este posibil s nu fie identificate toate entitile sau atributele necesare pentru realizarea unor
interogri.
Exerciiu propus: Pentru BD a unui cabinet medical, stabilii setul de entiti i atribute pe
care le considerai necesare a le folosi la cteva interogri specifice i facei asocierile
dintre entiti, atribute i interogri. Dup aceasta, formulai o nou interogare i vedei
dac modelul BD creat rspunde i la aceasta. Dac nu, identificai elementele lips.
55
Baze de date_________________________________________________________________
Odat stabilit setul de entiti i atribute, trecem la analiza relaiilor dintre entiti.
Care sunt informaiile pe care BD vrem s le furnizeze? Aceasta este ntrebarea de la care
plecm atunci cnd facem analiza relaiilor. Ce elemente lipsesc din modelul de date
construit? Acestea pot s treac uor neobservate dac nu exist o comunicare permanent
ntre proiectani i reprezentanii beneficiarilor BD.
Util este s reprezentm diagrama ER, fr atribute, cu relaiile identificate iniial, mai ales
dac numrul de entiti i atribute cu care lucrm este foarte mare. Analiza relaiilor dintre
entiti o putem face urmrind pas-cu-pas interogrile la care vrem s rspund BD, sau n
mod sistematic, folosind matricea relaiilor.
Matricea relaiilor permite identificarea n mod sistematic a tuturor relaiilor dintre entiti,
dac o citim pe linii i pe coloane, inclusiv a acelor relaii n bucl.
S urmrim ca exemplu modelul de date pentru un cabinet medical (Figura III.7).
Figura III.7 Matricea relaiilor pentru un model de date cu trei entiti
Matricea se citete pe orizontal.

De exemplu: Fiecare MEDIC (sigur) trateaz (mai muli) PACIENI.
Matricea relaiilor nu pune n eviden opionalitatea i cardinalitatea relaiilor. Dar putei
observa ct de uor se identific eventualele relaii care lipsesc din modelul de date, folosind
aceast matrice. Toate celulele trebuie analizate, linie cu linie. Nici o celul nu trebuie s
rmn necompletat. Nu este obligatoriu s existe relaii ntre oricare dou entiti, dar lipsa
unei astfel de relaii trebuie analizat i stabilit pe baza regulilor de afaceri care descriu
aplicaia.
Dup stabilirea tuturor relaiilor dintre entiti n matricea relaiilor, se redeseneaz diagrama
ER complet.
56
Exerciiu propus: Completai matricea relaiilor pentru BD a unei faculti, care cuprinde
entitile STUDENT, GRUP, AN DE STUDIU, PROFESOR, DISCIPLIN, SAL, OR,
EXAMEN, TIP DE ACTIVITATE.
III.7 NORMALIZAREA
Modelul de date creat pentru o aplicaie de BD trebuie optimizat pentru a elimina anumite
aspecte nedorite, precum redundana datelor sau unele dependene pariale dintre atribute,
astfel nct s nu mai apar erori n procesele de selecie sau de actualizare a datelor i, n
general, la utilizarea BD. Acest proces de optimizare a modelului BD poart numele de
normalizare.
Normalizarea este un procedeu de identificare a setului optim de relaii, bazat pe

dependenele funcionale dintre atribute, care are ca scop crearea unui model logic de date
valid, neredundant, care s elimine riscurile de apariie a anomaliilor de reactualizare a
datelor n baza de date.
Normalizarea precede etapa de implementare a BD deoarece aceasta implic unele modificri

de structur n modelul creat (schimbri de entiti, atribute sau relaii).
Forma nenormalizat (UNF Unnormalized Form) a unui tabel din BD include date
repetitive. Un astfel de tabel nu este considerat relaie n BD sau BD respectiv nu poate fi
considerat ca fiind relaional.
Un exemplu de dublare a datelor este acela n care stocai un numr de telefon n mai multe
agende (pe mai multe cartele SIM, eventual i n format scris, pe hrtie). Dac numrul
respectiv trebuie modificat, atunci trebuie s se aib n vedere toate locaiile unde apare acel
numr sau, la o dat ulterioar, nu vei mai ti care este numrul corect sau vei apela numrul
care nu mai este valabil. n acest caz este vorba de o eroare de actualizare i de o
inconsisten a informaiilor. Prin normalizarea BD, se elimin aceste probleme, scopul
normalizrii fiind acela de a ne asigura c datele sunt stocate fiecare numai ntr-un singur loc
i anume n cel mai bun loc din BD.
Erorile de actualizare se clasific n trei categorii:
57
Baze de date_________________________________________________________________
erori de inserare de noi date sau nregistrri cauzate de incoerena unor relaii din
schema relaional. De exemplu, dac se definete o relaie (tabel)
personal_departament, n care sunt inclui toi membrii de personal din agenie i
fiecare departament apare de mai multe ori n tabel, cu toate atributele sale, atunci pe
rndurile corespunztoare reprezentanilor si, se produce o dublare a datelor
referitoare la departamente (denumiri, adrese, numere de telefon). n cazul n care se
dorete nfiinarea unui nou departament care iniial nu are angajai, este necesar
introducerea de null-uri n cheia primar a relaiei ceea ce nu este admis. Dac se
angajeaz un nou membru de personal trebuie s introducem corect datele referitoare
la departamentul n care va fi repartizat, aa cum apar ele i n celelalte nregistrri ale
personalului aferent aceluiai departament. Reprezentarea distinct a tipurilor de
entiti n dou relaii personal i departament elimin aceast dublare a datelor i
anomaliile de inserare. Fiecare membru de personal este asociat numai cu numrul de
identificare al departamentului, atributele acestuia fiind incluse n alt tabel.
erori de modificare sunt cauzate de dublarea datelor n tabele. De exemplu,
modificarea unui atribut al unui departament, impune schimbarea valorii datelor din
mai multe rnduri. Dac nu se reactualizeaz toate nregistrrile corespunztoare, se
vor genera rapoarte incorecte, cu aa-numite date depreciate.
erori de tergere determin pierderea unor date din BD. De exemplu, dac n relaia
personal_departament se elimin singurul membru al unui departament, se terg i
datele referitoare la acest departament.
Pentru a evita erorile de actualizare este necesar descompunerea unor relaii n mai multe
relaii, cu seturi pariale din atributele iniiale, astfel nct s nu mai existe date dublate n nici
o relaie.
Normalizarea se realizeaz prin analiza i testarea relaiilor, pe baza cheilor primare i a celor
candidat, i aplicarea anumitor reguli de normalizare.
Procesul de normalizare se realizeaz n mai multe etape, numite forme de normalizare:
Prima form de normalizare (First Normalized Form 1NF) are ca scop eliminarea
atributelor cu valori multiple i se obine atunci cnd, la intersecia fiecrei linii cu
fiecare coloan din orice relaie a schemei BD, apare numai o singur valoare.
De exemplu, s presupunem c ntr-un tabel din BD se scriu disciplinele la care se in
ore ntr-o anumit sal. Firete c pentru un anumit amfiteatru sau un laborator
58
multidisciplinar, atributul disciplin va avea valori multiple. Entitatea nu este n prima

form de normalizare (figura III.8).
Trecerea unei entiti n 1NF se face prin definirea unei noi entiti corespunztoare
atributului cu valori multiple, eliminarea atributului respectiv i crearea unei relaii
1:M cu vechea entitate.
Exerciiu propus: Analizai entitile urmtoare:

GRUP (cod_grup, numr_grup, an_de_studiu, student)
MEDIC (id_medic, nume, prenume, cod_paraf, pacient)
PROPRIETATE (id proprietate, tip, suprafa, pre, vizitator)
Care dintre ele nu este n 1NF? Convertii-le la 1NF, dac este cazul.
Fig. III. 8 Trecerea n prima form de normalizare
A doua form normalizat (Second Normalized Form - 2NF) se aplic relaiilor

aflate n 1NF, care au chei compuse, i const n faptul c fiecare atribut care nu
aparine cheii primare este total dependent funcional de aceasta.
Dependena funcional dintre atribute semnific faptul c unul sau mai multe
atribute sunt determinate n mod unic de un alt atribut sau set de atribute, care
constituie determinantul.
De exemplu, toate atributele unei relaii sunt dependente funcional de cheia primar,
cu excepia atributelor care o formeaz.
Dependena funcional total apare atunci cnd atributul dependent nu depinde de
un subset de atribute al unei chei i eliminarea oricrei componente din determinant
59
Baze de date_________________________________________________________________
conduce la dispariia dependenei. n caz contrar, se consider c este o dependen

funcional parial.
Normalizarea n a doua form (2NF) se face prin identificarea i eliminarea tuturor

dependenelor funcionale pariale de cheia primar sau de cheile candidat.
O relaie cu cheie primar singular (cu un singur atribut) este automat n 2NF.
Pentru o relaie cu cheie primar compus, trecerea n 2NF se face prin eliminarea
dependenelor funcionale pariale. Pentru aceasta, fiecare atribut dependent
funcional parial este copiat ntr-un nou tabel, mpreun cu o copie a determinantului.
De exemplu, n BD a unei companii telefonice, sunt incluse entitile ABONAT i
JUDE. Pentru apelare, trebuie combinat numrul abonatului cu prefixul de jude,
pentru c acelai numr de telefon poate s apar la mai muli abonai, din judee
diferite. n figura III.9, este reprezentat barat relaia dintre cele dou entiti.
Figura III.9 Relaie barat ntre dou entiti
Dac s-ar folosi o singur entitate cu cheia primar compus (cod_abonat, cod_jude)
i atributele specifice judeului (denumire, prefix) ar fi nscrise toate n entitatea
ABONAT, atunci ar exista o dublare a datelor iar la schimbarea prefixelor de jude, ar
trebui fcute modificri identice pe foarte multe linii din tabel. ntr-o astfel de
reprezentare, atributele de jude depind parial de cheia primar prin atributul
cod_jude. Separarea entitilor i reprezentarea din figura de mai sus, rezolv aceast
problem i trece BD n forma a doua de mormalizare.
S considerm un alt exemplu. n modelul de date al unei agenii imobiliare, ntr-o
relaie clieni_proprieti care are ca UID, cheia primar compus (cod_client,
cod_proprietate), mai multe atribute (nume_client, telefon, adres) depind parial de
cheia primar deoarece depind numai de atributul cod_client, dar nu i de atributul
cod_proprietate. Dac un client, care ofer spre nchiriere mai multe proprieti, i
60
schimb numrul de telefon sau adresa de contact, atunci trebuie modificat valoarea
din mai multe nregistrri din tabel i este foarte posibil s se omit unele linii.
Deoarece n tabel apar valori repetitive, redundante, exist riscul apariiei unor erori
de actualizare. De aceea este necesar trecerea n forma a doua de normalizare care
asigur absena valorilor repetitive din tabelele bazei de date. n exemplul dat, pentru
normalizarea n 2NF, se definete o nou relaie clieni n care se includ toate
atributele clienilor mpreun cu determinantul cod_client ca i cheie primar, iar n
relaia iniial clieni_proprieti atributul cod_client rmne ca atribut simplu, cu rol
de cheie strin, care nu mai face parte din cheia primar a acestei relaii.
Exerciiu propus: Analizai i trecei n 2NF urmtoarea entitate, din BD a unui

magazin:
FURNIZORI_PRODUSE (cod_furnizor, cod_produs, denumire_furnizor, localitate,
jude, persoan_de_contact, telefon, denumire_produs, categorie, pre_de_achiziie)
Reprezentai grafic diagrama parial entitate relaie obinut.
A treia form normalizat (Third Normalized Form - 3NF) se obine prin eliminarea
aa-numitelor dependene tranzitive dintr-un model aflat n 1NF i 2NF. Dar mai nti,
ce semnific dependena tranzitiv?
Prin definiie, atunci cnd un atribut A determin atributul B, iar B determin

atributul C, apare dependena tranzitiv a atributului C de atributul determinant A,
prin intermediul atributului B (Figura III.10).
Figura III.10 Dependena tranzitiv a lui C de A
nclcarea formei a treia de normalizare apare atunci cnd un atribut din fara cheii
primare (atribut non-UID) depinde de un alt atribut non-UID.
De exemplu, dac BD a unui cabinet medical include n aceeai entitate i n acelai
tabel pacieni toate datele despre pacieni, inclusiv datele din fiele lor medicale, a
61
Baze de date_________________________________________________________________
celor despre consultaiile fcute i despre asistentele medicale care asist la consultaii
sau realizeaz tratamente, atunci exist sigur o dependen tranzitiv ntre atributul
cheie primar cod_pacient (A), cel de identificare a medicului cod_medic (B) unic
determinat de A i nume_medic (C), determinat de B. Dac se schimb numele unuia
dintre medici, atunci foarte multe nregistrri trebuie modificate n BD.
Dependenele funcionale tranzitive dintre atributele unei relaii pot cauza erori de
actualizare.
Exerciiu propus: Identificai alte posibile dependene tranzitive n acest model.
O relaie aflat n 1NF i 2NF se gsete i n 3NF dac nici un atribut din afara cheii
primare nu este dependent tranzitiv de cheia primar, prin intermediul altui atribut
care nu intr n componena cheii primare. Altfel spus, nici un atribut non-UID nu
poate avea propriile sale atribute deoarece el devine determinantul acestora i creeaz
dependene tranzitive n afara cheii primare.
Pentru obinerea formei a treia de normalizare (3NF), se identific eventualele

dependene tranzitive i orice atribut cu dependen tranzitiv se plaseaz ntr-o nou
relaie, adic un nou tabel, mpreun cu copia determinantului (determinanilor).
Exerciiu propus: Rezolvai dependenele tranzitive din exemplul anterior.
forma normal Boyce-Codd (BCNF) elimin dintr-o relaie dependenele

tranzitive fa de cheile candidat i se obine dup crearea formei 3NF, atunci cnd
toi determinanii sunt chei candidat diferite de cheia primar. Acesta este un aspect
mai complex i mai greu de observat.
Pentru o relaie cu o singur cheie candidat, care implicit este i cheie primar,
formele 3NF i BCNF sunt echivalente.
Dac o entitate are n afara cheii primare, una sau mai multe chei candidat, atunci,
pentru a obine forma Boyce-Codd, trebuie cutate i eliminate eventualele
dependene tranzitive fa de acestea.
De exemplu, ntr-o relaie VIZITARE_PROPRIETI sunt nregistrate vizitele pe care
le fac, la diferite proprieti, clienii unei agenii imobiliare, n vederea nchirierii. Ca
62
regul, agentul prezint proprietatea numai unui singur client la un anumit moment.
Cheia primar este compus (cod_proprietate, cod_client). n relaie, apar mai multe
dependene funcionale care sunt admise de 3NF, dac determinantul lor este cheie
candidat. Atributele data_vizitei, ora_vizitei, cod_agent, nr_nmatriculare,
marca_auto, nr_locuri, comentarii sunt determinate funcional total de cheia primar,
deci relaia respect regula 2NF. Dar atributele marca_auto, nr_locuri depind de
atributul nr_nmatriculare, dependent funcional de setul de atribute (data_vizitei,
ora_vizitei, cod_agent) care constituie o cheie candidat. Prin urmare, exist o
dependen tranzitiv de cheia candidat. Relaia este n 3NF, nu i n BCNF. Pentru a
trece la forma BCNF trebuie eliminat dependena tranzitiv de cheia candidat i, n
acest scop, este necesar crearea unei noi relaii AUTOVEHICULE, cu atributele
specifice (nr_nmatriculare, marca_auto, nr_locuri) i se elimin atributele
dependente tranzitiv de cheia candidat din tabelul iniial VIZITARE_PROPRIETI.
Pentru a sistematiza procesul de analiz a dependenelor tranzitive, este util s se
realizeze o matrice cu toate atributele entitii analizate, scrise att pe linii, ct i pe
coloane (asemenea matricii relaiilor) i s se marcheze dependenele dintre ele. Pe
aceasta, o vom numi matricea dependenelor. Aceast matrice este util i la
normalizarea n 2NF, precum i n 3NF i n BCNF.
Prin analiza tuturor dependenelor din relaie, se stabilete dac aceasta este sau nu n
forma de normalizare dorit.
Exerciiu propus: Identificai dependenele tranzitive din tabelul pacieni, din

exemplul BD a unui cabinet medical, folosind matricea dependenelor. Trecei tabelul
n forma BCNF.
A patra form normalizat (4NF) se obine din forma BCNF prin eliminarea
dependenelor funcionale multivalorice (MVD) netriviale (nu determin integral
tabelul), care apar n procesul de generare a primei forme de normalizare din cauza
relaiilor de tip 1:M independente dintre tipurile de entiti. De exemplu, exist astfel
de relaii 1:M ntre entitile DEPARTAMENT i PERSONAL respectiv ntre
DEPARTAMENT i PROPRIETI (Figura III.5). ntr-o relaie
DEPARTAMENT_PERSONAL_PROPRIETI exist o singur cheie candidat
(cod_departament, cod_agent, cod_proprietate) deci relaia este n forma BCNF.
63
Baze de date_________________________________________________________________
Pentru a evita apariia atributelor cu valori multiple, pentru acelai departament se

combin n mai multe rnduri numele agenilor cu atributele proprietilor pe care le
gestioneaz. Deci numele unui agent poate corespunde la mai multe proprieti iar
combinaia (cod_departament, cod_agent) apare redundant, de mai multe ori. Dac un
agent se mut de la un deparetament la altul, atunci trebuie fcute reactualizri n mai
multe linii de tabel. Pentru eliminarea acestei dependene multivalorice, se
descompune relaia iniial n dou relaii, de exemplu, DEPARTAMENT_PERSONAL
i DEPARTAMENT_ PROPRIETI.
A cincea form normalizat (5NF) se obine din 4NF prin descompunerea unei
relaii n dou sau mai multe relaii independente care elimin dependenele de tip
uniune fr pierderi i care garanteaz faptul c prin uniunea natural a mai multor
tabele rezultate din descompunerea altuia nu se genereaz date sau corespondene
false. De obicei, raportrile din BD se fac prin reunirea datelor din mai multe tabele.
ntre acestea trebuie stabilite clar relaiile i atributele de legtur (cheile strine),
astfel nct selecia valorilor s se realizeze corect.
De exemplu, dac BD a unei librrii, conine tabelele EDITURI, CRI, FURNIZORI,
fr a se face relaiile corecte dintre acestea, prin atributele cod_editur, cod_furnizor,
cu referine ntre cele trei tabele, atunci o interogare prin care se reunesc informaiile
din tabelele EDITURI, FURNIZORI prin care se caut lista furnizorilor unei edituri,
va genera toate combinaiile posibile dintre edituri i furnizori.
Observaie: De regul, se realizeaz normalizarea modelului BD pn la forma

BCNF, fiind relativ dificile regulile pentru 4NF i 5NF. Totui, dac la testarea
modelului apar erori, este bine s se aplice i aceste forme de normalizare.
III.8 REZUMATUL CAPITOLULUI

Alegerea entitilor, a atributelor i a relaiilor dintre entiti, pe care le lum considerare n
modelul de date ER al unei aplicaii de BD, necesit o bun documentare, o comunicare
permanent cu beneficiarii aplicaiei precum i mai multe etape de normalizare, pentru a
rspunde tuturor cerinelor de interogare ale clienilor precum i pentru a evita erorile de
actualizare care pot s apar n faza de utilizare a BD. Respectarea constrngerilor aplicaiei
(de opionalitate, cardinalitate, referenial i de participare) precum i a regulilor de
64
normalizare, uzual pn n forma Boyce-Codd, asigur performaele modelului bazei de date.

Reprezentarea grafic a modelului ER sub forma diagramei ER ofer posibilitatea analizei
rapide a modelului. Matricea relaiilor reprezint, de asemenea, un mod eficient de
reprezentare i identificare a relaiilor dintre entiti n vederea completrii modelului
conceptual al BD.
III.9 TERMENI SPECIFICI
Modelul Entitate-Relaie (ER)

Identificator unic (UID)
UID primar
UID secundar
UID simplu
UID compus
Diagrama ER
Reprezentare n stea
Reprezentare n dreptunghi
Regula de opionalitate
Regula de cardinalitate
Regula de orientare
Capcane de conectare
Matricea relaiilor
Normalizare
Forma nenormalizat (UNF)
Prima form de normalizare (1NF)
Valori multiple
A doua form de normalizare (2NF)
Dependen funcional
A treia form de normalizare (3NF)
Dependen tranzitiv
Forma de normalizare Boyce-Codd (BCNF)
A patra form de normalizare (4NF)
A cincea form de normalizare (5NF)
65
Baze de date_________________________________________________________________
III.10 TEST - GRIL
n BD a unei farmacii, se aleg entitile CLIENT, PRODUS, PRODUCTOR, FURNIZOR,

COMAND.
1. Care dintre urmtoarele relaii este de tip 1:M?

client - produs
comand - furnizor
produs furnizor
produs - productor
2. Care dintre atributele entitii PRODUS poate avea valori multiple?

cod_produs
denumire
pre de achiziie
productor
3. Care dintre atributele entitii PRODUS este artificial?

cod_produs
denumire
pre de achiziie
productor
4. Care dintre urmtoarele relaii este opional?

Un CLIENT cumpr unul sau mai multe PRODUSE.
Un FURNIZOR primete una sau mai multe COMENZI.
Un PRODUS este furnizat de unul sau mai muli FURNIZORI.
Un PRODUS este nscris pe una sau mai multe COMENZI.
5. n tabelul LISTA_PRODUSELOR se includ atributele cod_produs, denumire_produs,

cod_productor, cod_furnizor, pre_achiziie, pre_vnzare. n ce form de normalizare
este tabelul?
1NF
2NF
3NF
BCNF
66
CAPITOLUL IV
ASPECTE PARTICULARE ALE MODELRII
DATELOR
DIN CUPRINS:
IV.1 RELAII REDUNDANTE
IV.2 REZOLVAREA RELAIILOR M:M
IV.3 RELAII IERARHICE. RELAII RECURSIVE
IV.4 TRANSFERABILITATEA RELAIILOR
IV.5 SUBTIPURI I SUPERTIPURI
IV.6 MODELAREA ISTORICULUI UNUI ATRIBUT.
MODELAREA TIMPULUI
IV.7 MODELAREA GENERIC
IV.8 MODELAREA FIZIC
IV.9 REZUMATUL CAPITOLULUI
IV.10 TERMENI SPECIFICI
IV.11 APLICAIE PROPUS
IV.12 TEST-GRIL
Baze de date_________________________________________________________________
IV.1 RELAII REDUNDANTE
Modelul ER al unei BD include mai multe entiti, cu atributele proprii, i relaiile dintre
acestea.
Relaiile dintre entiti se analizeaz dup criteriile de opionalitate (sigur sau posibil) i de
cardinalitate (1:1, 1:M, M:M).
De exemplu, BD a unui magazin cuprinde date despre clieni, angajai i produse:
clieni (cod_client, nume, prenume, adres, telefon, cnp, adres_de_email)

angajai (id_angajat, nume, prenume, funcie, salariu, data de natere, cnp, adresa,
telefon)
produse (cod_produs, denumire, categorie, pre de vnzare, furnizor).
ntre aceste trei entiti, se stabilesc mai multe relaii pe care le putem descrie astfel:
1. Un client sigur este deservit de un angajat i un angajat poate s deserveasc unul

sau mai muli clieni.
2. Un angajat poate s vnd unul sau mai multe produse i un produs poate fi vndut
de unul sau mai muli angajai.
3. Un produs poate fi comandat de unul sau mai muli clieni i un client cumpr unul
sau mai multe produse.
4. Un angajat este sigur condus de un manager i un manager sigur are n subordine
unul sau mai muli angajai.
Relaia (1) este de tip 1:M ntre dou entiti distincte.

Relaia (4) este de tip 1:M, dar este o relaie n bucl, de la entitatea ANGAJAT la ea nsi.
Relaiile (2) i (3) sunt de tip M:M.
Exerciiu propus: Pentru BD descris n modelul de mai sus, reprezentai diagrama ER,
folosind convenia n dreptunghi i punnd n eviden opionalitatea i cardinalitatea
fiecrei relaii.
68
Se observ n diagrama ER crearea unui triunghi, prin relaionarea celor trei entiti. Putem
afirma n acest caz c avem relaii redundante, n sensul c una din cele trei relaii din
triunghi poate fi nlocuit cu celelalte dou. De exemplu, un angajat deservete unul sau mai
muli clieni (relaia 1) care cumpr unul sau mai multe produse (relaia 3), prin urmare din
aceste dou relaii tim care sunt produsele vndute de un angajat (relaia 2). Nu este nevoie
s folosim toate cele trei relaii dintre entiti, ci numai dou. Problema care apare se refer la
modul n care alegem cele dou relaii pe care le pstrm n diagram i pe care o eliminm.
n cazul n care analizm relaiile dintre entiti, lum n considerare urmtoarele reguli:
R1. Nu se admit relaii M:M deoarece cresc riscul erorilor de actualizare a datelor din BD.
R2. Nu se admit relaii 1:M care creeaz capcane n evantai.
R3. Se pstreaz cu prioritate, relaiile de tip 1:1.
R4. Se pot pstra unele relaii redundante dac prin aceasta se elimin riscul apariiei unei
capcane de ntrerupere.
n baza acestor reguli, n exemplul BD a unui magazin, una dintre relaiile (2) i (3) trebuie
eliminat iar cealalt care este tot de tip M:M tebuie rezolvat. De exemplu, eliminm n
prima faz relaia (2), dintre entitile ANGAJAT i PRODUS, care este redundant i de tip
M:M, deoarece ea poate fi nlocuit de celelalte dou relaii (1) i (3).
Rmne s rezolvm relaia M:M, n modul prezentat n paragraful urmtor.
Exerciiu propus: Pentru BD a unei faculti, n care se consider entitile STUDENT,

PROFESOR, DISCIPLIN, reprezentai diagrama ER, folosind convenia n dreptunghi,
cu toate relaiile posibile dintre entiti. Observai apariia unor relaii redundante? Dac
da, decidei care dintre relaii trebuie eliminate i care trebuie pstrate.
IV.2 REZOLVAREA RELAIILOR M:M
Relaiile muli-la-muli (M:M) sunt des ntlnite n primele etape ale modelrii datelor.
Practic, o astfel de relaie se traduce prin apariia aceleiai valori pe mai multe linii dintr-un
tabel, ceea ce ar crea probleme la reactualizarea datelor. De exemplu, un produs este
comandat de mai muli clieni, prin urmare n tabelul PRODUSE pe mai multe linii apare
acelai produs, cu cte un alt client cumprtor specificat pe fiecare linie (pentru a nu avea
69
Baze de date_________________________________________________________________
valori multiple n cmpul client), i n situaia modificrii codului produsului, este nevoie s
se fac actualizarea codului n toate liniile respective.
Este necesar s se nloicuiasc relaiile M:M cu relaii 1:1 sau 1:M. Modelul ER final nu
trebuie s conin relaii M:M.
Rezolvarea unei relaii M:M dintre dou entiti se face prin intersectarea mulimilor
atributelor lor i definirea unei noi entiti de intersecie, cu atributele rezultate din operaia
de intersecie.
n exemplul anterior, se intersecteaz entitatea CLIENT cu entitatea PRODUS i denumim
entitatea nou rezultat COMAND. Este evident faptul c un client lanseaz una sau mai
multe comenzi, dar o comand este asociat unui singur client, deci ntre cele dou entiti
apare o relaie 1:M. De asemenea, o comand include un singur produs, dar un produs apare
n una sau mai multe comenzi i din nou rezult o relaie 1:M (a nu se confunda comanda
unui produs, lansat prin butonul CUMPR asociat produsului, cu coul de
cumprturi al clientului, n care se nscriu toate comenzile fcute de client la o vizitare a
site-ului magazinului online). Entitatea COMAND va avea atributele rezultate din intersecia
entitilor (cod_client, cod_produs) precum i un atribut propriu cu rol de UID,
cod_comand. Se poate folosi i o cheie primar compus din cele dou coduri de client i de
produs, ceea ce ar crea aa-numitele relaii barate dintre entitatea de intersecie i entitile
iniiale. Pe lng acestea se vor folosi i alte atribute (numr_buci, data_lansrii_comenzii,
data_livrrii_produsului). Astfel, relaia M:M se nlocuiete cu dou relaii 1:M, fr a
aprea o capcan n evantai.
Exerciiu propus: Rezolvai relaia M:M dintre entitile STUDENT i DISCIPLIN, din BD
a unei faculti. Reprezentai diagrama ER modificat.
De obicei, entitatea de intersecie are un atribut opional de stare, care exprim o etap a unui
proces, identificabil n mod unic.
De exemplu, o agenie de turism organizeaz mai multe excursii, cu mai muli prestatori de
servicii (de cazare, de transport local, de transport internaional etc.) astfel nct relaia dintre
excursii i prestatorii de servicii este evident de tip M:M. Dar pentru o anumit destinaie i la
o anumit dat, participarea celor dou entiti la intersecie este singular, adic un singur
transportator internaional deservete grupul de excursioniti, cazarea unui turist, ntr-o
70
noapte se face la un singur hotel etc. Intersecia respectiv devine un eveniment clar,
identificat unic prin dat, timp, locaie.
De multe ori entitatea de intersecie are un caracter artificial, cum ar fi un contract de prestri
servicii, dar rolul ei este clar n rezolvarea unei relaii M:M tocmai prin participarea singular
a cel puin unei entiti n fiecare din relaiile nou-create. Relaia M:M este nlocuit cu relaii
1:1 sau cel mult 1:M.
IV.3 RELAII IERARHICE. RELAII RECURSIVE
De multe ori, avem de a face cu ierarhii de persoane sau de instituii, n funcie de

responsabilitile acestora sau de modul de subordonare dintre ele. Se pot stabili astfel ierarhii
de entiti, prin care se realizeaz o schem mai clar a BD.
Un bun exemplu, este acela al localizrii camerelor din cminele dintr-un campus studenesc,
prin numrul de cmin, prin etaj i numrul camerei. Aceasta este o ierarhie pe trei nivele
(figura IV.1).
Figura IV.1 Ierarhizarea entitilor
Se observ c identificarea unei camere din campus, nu se face doar prin numrul camerei, ci
prin toate cele trei chei primare: numr_cmin, numr_etaj, numr_camer, ceea ce se
reprezint prin relaii barate ntre entitile din ierarhie.
71
Baze de date_________________________________________________________________
Relaia este barat la captul corespunztor entitii determinate. De exemplu, fiecare camer
a unui hotel poate fi identificat doar dac se tie pe ce etaj se afl. Entitatea CAMER este
determinat de entitatea ETAJ. Relaia dintre ele este barat la captul dinspre entitatea
CAMER.
Bineneles c se poate defini o singur entitate cu toate atributele entitilor din ierarhie dar
este foarte posibil ca aceasta s nu respecte formele de normalizare a BD (apar de exemplu,
dependene funcionale pariale de cheia primar, care se rezolv tot prin definirea mai multor
entiti normaliznd entitatea respectiv).
Folosirea relaiilor ierarhice este recomandat n toate cazurile n care se modeleaz anumite
ierarhii ale instanelor unei entiti.
Exerciiu propus: Reprezentai ierarhic, ca diagram ER, pe ani de studiu, grupele de

studeni ale facultilor din cadrul unei universiti.
Recursivitatea relaiilor apare n multe cazuri n care entitile sunt modelate ierarhic,
ndeosebi atunci cnd entitile n cauz reprezint persoane.
De exemplu, n ierarhia militar, gradele militare se subordoneaz unele altora, pn la cel
mai nalt grad. Reprezentarea n BD a persoanelor din cadrul unei uniti militare poate fi
fcut fie cu mai multe entiti ierarhizate, fie printr-o singur entitate cu o relaie n bucl,
numit relaie recursiv.
Relaia recursiv apare ca relaie n bucl, de la o entitate la ea nsi, i reprezint o

subordonare a tuturor instanelor entitii fa de una dintre instanele ei.
De exemplu, dac printre atributele entitii CADRU_MILITAR apare atributul comandant,

atunci un membru al personalului unitii are aceast calitate de comandat i, n acelai timp,
este i cadru militar, prin urmare apare n lista respectiv ca instan a entitii, alturi de
subordonaii si (Figura IV.2).
Tabelul asociat entitii din figura IV.2, cu relaie recursiv, este mai greu de urmrit dect
dac s-ar folosi o reprezentare ierarhic. Adic, un soldat este subordonat comandantului de
pluton, acesta la rndul su este subordonat comandantului de detaament i aa mai departe.
Urmrirea ierarhiei, pe mai multe nivele, implic mai multe sortri ale datelor pn s se
stabileasc cel mai nalt grad din ierarhia respectiv.
72
De asemenea, dac se modific persoana cu rang de comandant dintr-o unitate, atunci este
necesar modificarea numelui su n mai multe nregistrri din tabel ceea ce poate s
conduc la erori de actualizare. De aceea, este preferat reprezentarea ierarhic, n care orice
dat este stocat ntr-o singur locaie din BD.
Figura IV.2 Reprezentarea unei relaii recursive
Reprezentarea ierarhic a entitilor corespunde unei structuri fixe, iar completarea ei se face
cu diferite persoane, care se pot schimba la un anumit moment, fr ca aceasta s afecteze
schema n sine (Figura IV.3).
Figura IV.3 Structur ierarhic, cu 4 nivele
Exerciiu propus: Reprezentai ierarhic, ca diagram ER, pe ani de studiu i pe grupe,

studenii facultilor din cadrul unei universiti.
73
Baze de date_________________________________________________________________
IV.4 TRANSFERABILITATEA RELAIILOR
Transferabilitatea este o noiune care exprim posibilitatea schimbrii unor asocieri dintre
instanele a dou entiti relaionate ntre ele.
De exemplu, n BD a unui cabinet medical, un pacient este asociat cu un anumit medic de
familie. ntrebarea care se pune este aceea dac pacientul poate s i schimbe medicul de
familie? Rspunsul poate fi i da, i nu, acesta depinznd numai de regulile de afaceri ale
cabinetului respectiv. Un rspuns afirmativ reflect transferabilitatea relaiei dintre medic i
pacient, permis de politica aplicat n acel cabinet.
Reinei c analiza unei relaii din modelul ER se face referitor nu numai la opionalitatea i
cardinalitatea relaiei, ci i la transferabilitatea acesteia.
n multe aplicaii este necesar s se impun netransferabilitatea unor relaii. De exemplu,

relaia dintre entitatea CAMER i entitatea CMIN din BD a unui campus universitar, este
netransferabil (Figura IV.4).
Relaiile netransferabile se marcheaz cu un romb n reprezentarea grafic.
Modelul de date creat pentru o aplicaie de BD conine de foarte multe ori atribute i relaii
care nu se pot schimba i pe care le numim netransferabile.
De exemplu, ziua, luna i anul naterii unei persoane sunt atribute cu caracter permanent,
imuabil.
Aceste aspecte particulare trebuie s fie clarificate prin regulile de afaceri, n documentaia
bazei de date, i s fie asigurat aplicarea lor n momentul implementrii BD n limbaj de
programare. Neaplicarea caracterului imuabil al unor atribute sau relaii poate s creeze
condiii favorabile fraudelor informatice, prin falsificarea unor informaii de identificare, n
procesul de accesare a BD.
Figura IV.4 Reprezentarea unei relaii netransferabile ntre dou entiti

74
Exerciiu propus: Analizai i reprezentai grafic relaiile dintre entitile ABSOLVENT,

FACULTATE, SPECIALIZARE, DIPLOM, din BD a unei universiti (punei n eviden
opionalitatea, cardinalitatea i transferabilitatea relaiilor care se pot stabili ntre entiti).
Exerciiu propus: Dai i alte exemple de relaii transferabile i de relaii netransferabile.
IV.5 SUBTIPURI I SUPERTIPURI
n multe modele de date se folosete un numr foarte mare de entiti, ceea ce face deosebit
de greu de reprezentat i de urmrit diagrama ER.
De exemplu, n BD a unui magazin de mbrcminte, se folosesc entitile BLUZ, FUST,
ROCHIE, CMA, PANTALON, PALTON, JACHET, COSTUM, pe lng celelalte
CLIENT, ANGAJAT, FURNIZOR, ACHIZIIE, VNZARE, PLAT. Primele opt entiti au
fost definite separat deoarece fiecare reprezint un articol de mbrcminte cu atribute
specifice. Totui acestea au n comun multe atribute (cod, mrime, material, productor,
culoare) i ar putea fi incluse toate ntr-un aa-numit supertip sau superentitate ARTICOL.
Astfel numrul de entiti este simitor redus. Pe lng atributele comune, se disting i
atribute care le difereniaz. De exemplu, o bluz poate avea mnecile scurte sau lungi, n
timp ce la o fust vom fi interesai de croiala acesteia iar la rochii ne vor interesa diferite
modele (de mireas, de sear, de plaj etc.) Spunem c entitile componente ale entitii
supertip sunt subtipuri ale acesteia. Un subtip se mai numete i subentitate.
n viaa de zi cu zi, avem de multe ori de a face cu subtipuri, pe care le denumim categorii, i
modelarea lor pentru o BD ne oblig s le identificm corect pe toate i s le difereniem prin
aspectele lor particulare.
Exerciiu propus: Dai trei exemple de entiti supertip i punei n eviden subtipurile
acestora.
Subtipurile sau subentitile sunt reprezentate grafic toate n acelai dreptunghi creat pentru
supertip (Figura IV.5).
75
Baze de date_________________________________________________________________
Figura IV.5 Reprezentarea subtipurilor i a supertipului n aceeai caset
Atributele comune subtipurilor se enumer unul sub cellalt, sub numele supertipului, n timp
ce atributele particulare, specifice fiecrui subtip se nscriu n caseta aferent acestuia.
Astfel un subtip are toate atributele supertipului i este implicat n toate relaiile acestuia cu
alte entiti. Un subtip poate s aib la rndul su alte subtipuri.
Exerciiu propus: Completai diagrama din figura IV.5 cu atribute comune i atribute
specifice subtipurilor identificate n modelul BD al unui parc auto.
Verificarea corectitudinii alegerii subtipurilor se face n baza urmtoarelor reguli:

Orice instan a entitii supertip se ncadreaz ntr-un subtip (regula de
exhaustivitate).
Orice instan a unui subtip nu este instan a altui subtip (regula de exclusivitate
mutual).
Altfel spus, orice instan a supertipului este instan a unui i numai a unui subtip.
Stabilirea subtipurilor se face pe baza regulilor afacerii. Este posibil, ca pe durata utilizrii
aplicaiei de BD, s apar noi subtipuri care trebuie introduse n structura acesteia, adic este
necesar dezvoltarea BD. Pentru a rezolva ct mai simplu aceast situaie, este util ca de la
nceput s se prevad unul sau mai multe subtipuri suplimentare, cu sau fr un nume
specific. Este foarte posibil ca politica firmei s prevad de la nceput aceste posibiliti de
dezvoltare care trebuie luate n consideraie la proiectarea BD sau s apar unele aspecte noi
care trebuie incluse n model sub forma unui subtip ALTELE sau DIVERSE.
De exemplu, un magazin poate s accepte la un anumit moment, ca modalitate de plat, doar
numerar i bonuri valorice. Dup o perioad de timp, pe msur ce afacerea se dezvolt i se
fac investiii, acelai magazin va accepta i plata cu carduri bancare. BD a magazinului nu
76
trebuie complet refcut, ci numai regndite subtipurile entitii PLAT. Este dificil de
introdus un nou subtip dar este mai simplu de adaptat numele i atributele subtipului generic
ALTELE pentru a nregistra plile cu card.
Exerciiu propus: Reprezentai diagrama ER, cu supertipuri i subtipuri, pentru BD a unui
magazin, n care includei toate entitile (BLUZ, FUST, ROCHIE, CMA,
PANTALON, PALTON, JACHET, COSTUM, CLIENT, ANGAJAT, FURNIZOR,
ACHIZIIE, VNZARE, PLAT), cu atribute comune i atribute specifice subtipurilor.
Constrngerea de exclusivitate mutual se aplic uneori i relaiilor dintre entiti, nu numai
subtipurilor unei superentiti, caz n care relaiile respective sunt marcate cu un arc.
De exemplu, s considerm BD pentru planificare activitilor din slile de sport ale unui
club, care pot gzdui fiecare meciuri de baschet, handbal, fotbal sau concursuri de
gimnastic. Bineneles c la un anumit moment, doar un singur tip de competiie se
desfoar ntr-o sal, ceea ce impune exprimarea constrngerii de exclusivitate mutual
(exclusive OR) asupra relaiilor dintre entitile SAL i MECI_DE_BASCHET,
MECI_DE_HANDBAL, MECI_DE_FOTBAL, CONCURS_DE_GIMNASTIC i
reprezentarea acestei constrngeri n diagrama ER se face cu un arc ce cuprinde toate relaiile
implicate (Figura IV.6).
Figura IV.6 Reprezentarea unei constrngeri de tip exclusive OR
77
Baze de date_________________________________________________________________
Trebuie fcut distincia ntre regula de exclusivitate mutual a subtipurilor unei entiti i
constrngerea de exclusivitate mutual aplicat unor entiti distincte, care nu pot fi
considerate de acelai tip.
Exerciiu propus: Dai un exemplu de o BD n care se aplic constrngerea de exclusivitate

mutual ntre mai multe entiti i reprezentai grafic diagrama ER a acesteia.
IV.6 MODELAREA ISTORICULUI UNUI ATRIBUT. MODELAREA

TIMPULUI
n multe aplicaii cu BD, valorile unor atribute se modific n timp i este nevoie s se
pstreze istoricul acestora, pentru a se observa evoluia lor, pentru a face anumite rapoarte i
comparaii, precum i pentru a lua anumite decizii.
De exemplu, managerul unui magazin dorete s analizeze evoluia pe o perioad de un an a
preului unui produs. Dac folosim entitatea PRODUS cu atributul pre_de_vnzare, atunci
nregistrarea din BD va reda la un anumit moment preul curent al produsului, nu i valorile
anterioare. Acestea sunt terse la fiecare actualizare a preului. Pentru a pstra toate valorile
preului produsului, este nevoie s se defineasc o nou entitate ISTORICUL PREULUI
care s nregistreze evoluia preului, data de la care se aplic un anumit pre i data de la care
acesta nu mai este valabil (Figura IV.7). Relaia dintre cele dou entiti este 1:M pentru c
aceluiai produs i corespund n timp mai multe valori ale preului. n plus, relaia dintre cele
dou entiti este barat pentru c identificatorul unic al preului se compune din id_produs i
data_aplicrii preului deoarece la aceeai dat, se stabilesc preurile la mai multe produse.
Figura IV.7 Modelarea istoricului unui atribut

78
Exerciiu propus: Realizai modelul ER pentru BD a unei companii care s nregistreze

evoluia n timp a salariului fiecrui angajat.
nregistrarea modificrilor suferite n timp de unele atribute ale unor entiti din model, se
poate face folosind atribute de tip dat timp sau entiti de timp separate.
n exemplul anterior n care se modela evoluia preului n timp, se folosesc atribute de timp.
De nenumrate ori dorim ca BD s pstreze i nregistrrile mai vechi, pentru a putea face o
comparaie ntre ele i valorile curente, pentru a observa anumite tendine i pentru a lua
decizii optime de eficientizare a proceselor (de producie, de vnzare, de tratament etc.)
Modelarea timpului ca entitate separata este util n multe aplicaii de planificare a
activitilor. De exemplu, pentru programarea orelor de curs i de laborator pe grupe de
studeni, se impun anumite constrngeri sau condiionri temporale. O nou activitate a
unei grupe (curs, laborator, seminar) nu poate s nceap nainte ca o alt activitate s nu se fi
ncheiat. Exprimm aceast constrngere prin impunerea ca ora de nceput a unei noi
activiti s fie programat dup ora de sfrit a altei activiti. Dac la orar apare pentru
fiecare activitate ora_de_nceput i ora_de_sfrit, atunci ntre aceste atribute apar anumite
condiionri. Realizarea orarului folosind o baz de date trebuie s se fac respectndu-se
unele constrngeri temporale. Chiar i o sal n care se desfoar anumite activiti didactice
trebuie reprezentat cu aceste condiionri temporale. Nu se pot planifica activiti simultane
de seminar, cu grupe disctincte, n aceeai sal. Adic ora de nceput a unui nou seminar
trebuie s fie egal sau dup ora de sfrit a oricrui alt seminar, programat n aceeai sal.
De asemenea, nu se pot face modificri n orar referitoare la o activitate, dup ora de ncepere
a acelei activiti. Este un alt tip de condiionare temporal a tranzaciilor din BD. Spunem c
ntre entitile SAL i GRUP apare o non-transferabilitate condiionat.
Transferabilitatea condiionat se refer la faptul c transferabilitatea ntre entiti este

posibil la orice moment nainte de momentul de nceput al unei activiti, dup care nu mai
este permis.
Reprezentarea entitilor cu unele atribute de timp poate s cauzeze nclcri ale regulilor de
normalizare a BD.
79
Baze de date_________________________________________________________________
De exemplu, ntr-o sal de festiviti, nu se pot programa simultan mai multe spectacole.
Adic ora de nceput a unui nou spectacol trebuie s fie dup ora de sfrit a altui spectacol.
Se descrie entitatea SPECTACOL prin atributele cod_spectacol (cheie primar), tip, titlu,
cod_echip, data, ora_de_nceput, ora_de_sfrit. Atributele de timp depind de atributul
data, sau altfel spus, atributul data are atribute proprii, dei nu este cheie primar. Nu putem
vorbi independent de ora 20, fr a specifica i ziua la care facem referire. De aceea spunem
c apare dependena de atributul data. Apare astfel o dependen tranzitiv care ncalc forma
a treia de normalizare (3NF). Este necesar separarea atributului care determin dependena
tranzitiv ntr-o entitate de sine stttoare DAT_TIMP, cu atributele id_dat_or, data,
ora_de_nceput, ora_de_sfrit, astfel nct s se rezolve condiionarea temporal impus de
regulile de afaceri. Entitatea iniial va apela numai la cheia primar a entitii de timp nou
create.
ntr-un alt exemplu, s considerm cazul modelrii unei BD a unei faculti, n care entitatea
ACTIVITATE are, printre altele, atributele cod_activitate, numr_grup, cod_profesor,
cod_sal, cod_disciplin, zi, ora_de_nceput, ora_de_sfrit. ntruct n aceeai sal nu se
pot programa simultan mai multe activiti, atributele de timp se condiioneaz n funcie de
codul slii, care la rndul su depinde de cheia primar, cod_activitate. De asemenea,
atributele de or nu sunt independente ci trebuie relaionate cu atributul zi pentru a exprima
corect intervalul n care se desfoar o activitate. Avem de a face aici cu o dependen
tranzitiv, care ncalc regula formei a treia de normalizare a BD (3NF).
ntrebare: Care sunt condiionrile de timp din exemplul de mai sus? Cum se procedeaz
pentru a trece entitatea n forma 3NF?
IV.7 MODELAREA GENERIC
n cazul n care regulile afacerii se schimb foarte des, este relativ dificil de anticipat i de
modelat entitile bazei de date. De exemplu, pentru BD a unui magazin de produse de
anticariat este dificil de tiut de la nceput toate tipurile de produse care se vor comercializa i
nici toate atributele specifice acestor categorii. n astfel de situaii, cu evoluii nepredictibile
ale afacerii, se poate folosi cu succes un model generic.
Modelarea generic a BD este avantajoas din mai multe motive:
80
Este flexibil, adic permite definirea de noi entiti i atribute, pe msur ce

specificul activitii descrise se schimb.
Folosete un numr considerabil redus de entiti, generice, cu atribute care pot fi
definite pe parcurs.
Se adapteaz uor i rapid unor noi condiii de lucru.
S considerm ca exemplu, BD a unui magazin de mbrcminte, n care sunt definite
entitile BLUZ, FUST, ROCHIE, CMA, PANTALON, PALTON, JACHET,
COSTUM, pe lng celelalte specifice oricrui tip de magazin, CLIENT, ANGAJAT,
FURNIZOR, ACHIZIIE, VNZARE, PLAT. ntr-un paragraf anterior, v artam c este util
s folosim subtipuri astfel nct reprezentarea diagramei ER s fie mai simpl. Dar ce se
ntmpl, dac n acelai magazin urmeaz s se aduc noi categorii de produse de
mbrcminte, de exemplu, articole sport, articole de nclminte i accesorii? Trebuie s
schimbm BD pentru a introduce noi subtipuri ale entitii PRODUS? Nu neaprat. Este
suficient s avem n vedere o posibil extindere a activitii i s modelm generic datele de
la nceput.
Modelarea generic definete o entitate generic, cu atribute generice, care urmeaz s ia

valori specifice pe msur ce activitatea descris n BD se diversific.
n exemplul considerat, n ipoteza c magazinul i pstreaz specificul de a comercializa

doar articole de mbrcminte, putem considera entitatea generic PRODUS, cu un set extins
de atribute, n care s includem toate atributele posibile de la toate tipurile de articole de
mbrcminte (id, denumire, mrime, lungime, culoare, material, gen, circumferin_talie,
bust, lungime_ mnec, dimensiune_gt, stil i altele), bineneles toate cu caracter opional,
astfel nct, pentru un anumit tip de produs, s completm doar cmpurile specifice, iar cele
care nu l caracterizeaz s admit lipsa valorii (NULL). Se pot defini i subtipuri ale entitii
generice, cu condiia s putem anticipa care sunt tipurile pe care le vizm pentru activitatea
descris, pe durata de viabilitate a BD. Observm c acest mod de abordare implic o cretere
nedorit a numrului de atribute i a dimensiunii tabelului asociat entitii (12 coloane).
Totui modelarea generic impune o i mai mare generalizare a noiunilor. Mai exact, nu vom
specifica denumirile atributelor, ci vom anticipa un numr maxim al acestora. n exemplul
bazei de date pentru magazinul de mbrcminte, putem folosim entitatea generic
TIP_PRODUS cu ase atribute generice pe care le notm atribut_1, atribut_2, atribut_3,
81
Baze de date_________________________________________________________________
atribut_4, atribut_5, atribut_6. n tabelul asociat se trec denumirile atributelor, urmnd ca

valorile lor s fie specificate n alt tabel, corespunztor unei entiti VALOARE_ATRIBUT
(Figura IV.8). Acest mod de descriere recicleaz atributele, reducnd numrul lor i
meninnd dimensiuni rezonabile ale tabelelor din BD. Conform diagramei din figur, un
articol va avea minimum patru atribute specificate i maximum ase, alese dintr-un set extins
de atribute. Tabelul cu tipurile de produse va avea apte coloane n loc de dousprezece (vezi,
de exemplu, tabelul IV.1). Valorile atributelor pentru diferite tipuri de produse, sunt
specificate n alt tabel, cu denumiri generice ale coloanelor (Tabelul IV.2).
Figura IV.8 Modelarea generic a entitii PRODUS
Tabelul IV.1 Definirea atributelor unor tipuri de produse

nume atribut_1 atribut_2 atribut_3 atribut_4 atribut_5 atribut_6
circumferin
FUST id mrime material lungime
_talie
lungime_ dimensiune_
CMA id stil material culoare
mnec gt
PANTALONI id mrime material culoare gen lungime
Tabelul IV.2 Valorile atributelor unor tipuri de produse

nume atribut_1 atribut_2 atribut_3 atribut_4 atribut_5 atribut_6
FUST 01 40 stof 50 70
CMA 02 sport elastan negru 62 41
PANTALONI 03 38 jeans gri de dam scuri
Modelarea generic permite folosirea aceleeai BD pe msur ce se extinde activitatea

magazinului, prin adugarea altor game de produse.
82
Exerciiu propus: Folosind modelul generic prezentat, adugai n BD a magazinului, alte

trei produse de mbrcminte i dou produse de tip accesoriu. Completai tabelele cu valori
specifice noilor categorii de produse.
Modelul generic prezentat stocheaz informaiile despre produse ntr-un singur tabel, cu
foarte multe nregistrri, greu de urmrit, i este necesar sortarea pe mai multe nivele a
datelor pentru separarea informaiilor despre un anumit tip de produs.
De aceea, n unele cazuri se recurge la folosirea unor relaii recursive care s permit stocarea
informaiilor despre diferite categorii de obiecte, n tabele diferite.
Pentru exemplul anterior, n care se modeleaz BD a unui magazin, n loc de dou entiti
generice (TIP_PRODUS, VALOARE_ATRIBUT), se pot considera mai multe entiti, cu
atribute i valori specifice:
TIP_PRODUS (# id_tip_produs, * nume)
PRODUS (# id_produs, * id_tip_produs, * nume)
ATRIBUT (# id_atribut, # id_tip_produs, * nume)
VALOARE_ATRIBUT(# id_produs, # id_atribut, # id_tip_produs, * valoare)
Relaiile dintre aceste entiti (PRODUS i VALOARE_ATRIBUT, TIP_PRODUS i
ATRIBUT, respectiv VALOARE_ATRIBUT i ATRIBUT) sunt barate, n sensul c fiecare
instan a entitii ATRIBUT se identific prin id_atribut i id_tip_produs iar valoarea
atributului va fi identificat n mod unic prin combinaia cheilor primare ale entitii
PRODUS i ATRIBUT (id_produs, id_atribut, id_tip_produs). Altfel spus, atributul cu
numrul 2, al tipului de produs FUST, este interpretat ca mrime iar valoarea sa difer de la
un produs la altul, n funcie de productor, model etc.
Exerciiu propus: Refacei modelul generic al magazinului, descris prin tabelele IV.1 i IV2
i reprezentai grafic diagrama cu noile entiti. Completai cele patru tabele asociate noului
model generic, cu valori specifice tuturor categoriilor de produse din exemplul anterior.
Acest model generic generalizat este deosebit de flexibil, n sensul c permite adaptarea
numrului de atribute la diferitele tipuri de produse sau de entiti, n general. Spre deosebire
de primul model generic care considera un numr maxim prestabilit de atribute, invariabil de
la un tip la altul, modelul generalizat poate include un numr variabil de atribute pentru
diversele tipuri considerate. Modelul poate fi uor modificat n timp, pe msur ce se extimde
83
Baze de date_________________________________________________________________
activitatea descris n BD. Numrul de coloane din tabelele asociate este fix, n timp ce
numrul de nregistrri (linii) din tabele va crete.
Prin realizarea unor modele de date generice, se prelungete durata de via a BD i se
simplific munca administratorilor de date. Totui complexitatea i costurile de implementare
a unei BD pe baza unui model generic sunt considerabil crescute.
IV.8 MODELAREA FIZIC
Transpunerea modelului conceptual ntr-un model care s descrie structurile bazei de date
reprezint faza de modelare fizic a datelor. Acest proces mai este denumit i mapare
(mapping).
Proiectarea logic consta n rafinarea modelului conceptual (prin normalizare) i
transpunerea acestuia ntr-un model de date logic, cunoscnd tipul de SGBD int (relaional,
ierarhic, n reea sau orientat-obiect). Ea viza obinerea unui model al BD complet, care s
permit definirea tuturor vederilor utilizatorilor i meninerea integritii BD. Prin integrarea
n modelul logic a schemelor externe pentru vederile utilizatorilor, respectiv a modelelor de
date logice locale, se obine modelul de date logic global. n aceast etap se elimin acele
probleme care apar atunci cnd se utilizeaz aceiai termeni pentru obiecte diferite sau
termeni diferii pentru aceleai obiecte.
A treia etap de proiectare, proiectarea fizic a BD, const n descrierea sub forma unui
model fizic, a modului de implementare a BD, a structurilor de stocare n capacitatea de
stocare secundar i a metodelor de acces la date.
n cazul bazelor de date relaionale, din modelul de date logic global se obin modelele
tabelelor relaionale, se deduc constrngerile impuse datelor i necesitile de securitate ale
sistemului.
Mai precis, fiecrei entiti i se asociaz un tabel, numit i relaie, pe care l descriem prin
capul de tabel. Denumirea tabelului este dat, n general, de forma de plural a numelui
entitii. De exemplu, entitatea STUDENT se asociaz cu tabelul studeni.
Fiecare tabel va avea tot attea coloane cte atribute are entitatea respectiv.
n modelul tabelului se nscriu pe lng denumirile atributelor, constrngerile de opionalitate
i caracterul de cheie al fiecrui atribut.
84
Este util ca n modelul fizic s se foloseasc denumiri prescurtate ale atributelor, astfel nct
transcrierea modelului fizic n limbaj de programare, s se fac mai simplu. n acest caz, n
modelul fizic este necesar s se includ i o descriere a fiecrei denumiri prescurtate.
De asemenea, n modelul fizic se mai pot include tipul datelor pentru fiecare atribut i
dimensiunea dorit, opiuni de tranzacionare, valori implicite (DEFAULT) i diferite
condiionri.
De exemplu, s considerm entitatea CMIN din figura IV.1. Aceasta are patru atribute care
definesc cele patru coloane ale tabelului cmine. Modelul fizic la tabelului este urmtorul:
Tabel IV. 1 Modelul tabelului cmine

Tip de Opionali- Denumirea Descriere Alte detalii
cheie tate coloanei
PK * nr_c numr_cmin UNIQUE, secven de 3
caractere (litere i cifre)
* adm id_administrator Secven de 4 cifre
FK * id_f id_facultate numr ntreg, pozitiv, unic
o denum denumirea ir de maximum 30 de
cminului caractere, UNIQUE
Relaiile dintre entiti, descrise n diagrama ER, se transform n atribute suplimentare, de

tip cheie, cu caracter obligatoriu sau opional, n funcie de natura relaiei.
Se aplic urmtoarele reguli de mapare:
Regula M1: O relaie simpl de tip 1:M dintre dou entiti determin includerea unui atribut
cheie-strin (FK Foreign Key)la entitatea cu participare multipl n relaie determinat de
cheia primar (PK Primary Key) sau o cheie candidat (UK Unique Key) a entitii cu
participare singular n relaie. De exemplu, n BD a unei faculti, relaia dintre entitatea
STUDENT i entitatea GRUP este de tip 1:M deoarece ntr-o grup sunt inclui mai muli
studeni. Relaia aceasta se transform (mapeaz) prin atributul id_grup care este cheie
primar a entitii GRUP i devine cheie strin a entitii STUDENT.
Regula M2: O relaie simpl de tip 1:1 dintre dou entiti determin includerea unui atribut
cheie-strin la una din cele dou entiti, n funcie de regulile de afaceri. Cheia strin este
determinat de cheia primar sau de o cheie unic a uneia dintre entitile implicate n relaie
care poate fi oricare din cele dou entiti. De exemplu, pentru un serviciu de transport, n
85
Baze de date_________________________________________________________________
care fiecare ofer are repartizat a anumit main, relaia dintre oferi i maini este 1:1 iar
cheia strin poate fi fie id_ofer inclus n setul de atribute al fiecrei maini, fie id_main
inclus n lista atributelor entitii OFER. De regul, cheia strin se pune n tabelul care va
avea mai puine nregistrri, pentru a salva spaiu de memorie.
Exerciiu propus: Realizai modelul fizic pentru diagrama ER corespunztoare BD a unui
magazin, cu relaiile descrise n paragraful IV.1.
Regula M3: O relaie barat dintre dou entiti determin apariia unui nou atribut n setul
de atribute al entitii determinate cu rol de cheie primar sau de component a acesteia,
respectiv de cheie secret, cu referire la tabelul entitii determinante. De exemplu, n BD a
unei universiti, relaia dintre facultate i catedre este una barat, n sensul c identificatorul
catedrei trebuie asociat cu identificatorul facultii, pentru a identifica unic o anumit catedr
din universitate. Prin urmare, atributul id_facultate este i cheie strin, i component a cheii
primare.
Exerciiu propus: Realizai modelul fizic pentru diagrama din figura IV.7.
Regula M4: Un supertip cu mai multe subtipuri este transformat ntr-un singur tabel dac are
mai multe atribute comune dect cele specifice fiecrui subtip. n acest caz, subtipurile sunt
difereniate n modelul fizic, printr-un singur atribut, cu caracter obligatoriu, care specific
subtipul. Relaiile supertipului se mapeaz conform regulilor anterioare. Relaiile subtipurilor
se mapeaz ca i chei strine opionale. Atributele subtipurilor devin opionale, urmnd ca la
completarea tabelului, s se nscrie date doar n coloanele corespunztoare atributelor unui
singur subtip. Apare aici o constrngere de tip XOR, care se exprim printr-o condiionare de
forma (de exemplu, considerm dou subtipuri, cu cte un atribut):
CHECK (atribut_1 is NOT NULL AND atribut_2 is NULL) OR (atribut_1 is NULL AND atribut_2
is NOT NULL)
Exerciiu propus: Realizai modelul fizic pentru modelul conceptual din figura IV.5
corespunztor parcului auto al unei societi de transport.
Regula M5: Dac un supertip are mai multe subtipuri care au mai multe atribute distincte
dect comune, atunci fiecare subtip este transformat ntr-un tabel, n care se includ i
atributele comune pe lng cele specifice subtipului. Cheia primar a supertipului devine
86
cheie primar n fiecare tabel de subtip. Cheile unice ale supertipului rmn chei unice n
toate tabelele subtipurilor. Orice relaie a supertipului se marcheaz printr-o cheie strin n
toate tabelele subtipurilor. O relaie a unui subtip se mapeaz doar n tabelul acestuia, cu
opionalitatea original. De exemplu, ntr-un supermarket se pot comercializa produse
alimentare, produse de mbrcminte i nclminte, cri, produse electrocasnice.
Subtipurile entitii PRODUS sunt foarte diferite i atunci este indicat s se realizeze tabele
distincte pentru subtipuri. n acest caz i reprezentarea grafic sugereaz folosirea mai multor
tabele, iar marcarea cu un arc a mai multor relaii trebuie s se traduc, n modelul fizic i n
programare, ntr-o constrngere de exclusivitate a subtipurilor (CHECK). Relaia dintre
supertip i o alt entitate devine relaie dintre fiecare subtip i acea entitate, deci relaia se
multiplic i se exprim printr-o cheie strin corespunztoare fiecrui subtip. Aceste chei
strine au caracter opional prin regula de exclusivitate a subtipurilor.
Exerciiu propus: Reprezentai modelul fizic pentru diagrama ER a BD prin care se planific
activitile dintr-o sal de sport (figura IV.6).
Regula M6: n cazul relaiilor cu caracter netransferabil (marcate n diagrama ER cu un

romb) trebuie s se precizeze n modelul fizic o constrngere referitoare la nemodificarea
valorilor nscrise n tabel pe coloana cheii strine. Aceasta se traduce prin nerealizarea de
actualizri sau tergeri ale datelor de pe acea coloan (ON UPDATE NO ACTION, ON
DELETE NO ACTION). Observm c este important s se menioneze n modelul fizic, toate
detaliile impuse de regulile de afaceri pentru ca programatorii s poat nscrie toate
constrngerile impuse de regulile de afaceri.
IV.9 REZUMATUL CAPITOLULUI
n acest capitol, sunt prezentate aspecte mai puin comune i mai dificile ale modelrii
datelor, precum:
identificarea i soluionarea relaiilor redundante sau de tip M:M din diagrama ER
posibilitile de reprezentare ierarhic sau recursiv a unor relaii i entiti
reprezentarea unor constrngeri referitoare la netransferabilitatea unor relaii
avantajele definirii unor subtipuri de entiti
modaliti de modelare a istoricului unor variabile i a timpului n modelul de date
87
Baze de date_________________________________________________________________
opiunile de modelare generic

regulile modelrii fizice a BD.
IV.10 TERMENI SPECIFICI
Relaii redundante
Relaii M:M
Intersecia entitilor
Relaii ierarhice
Relaii recursive
Relaii barate
Transferabilitate
Relaii netransferabile
Subtip/Subentitate
Supertip/Superentitate
Regula de exhaustivitate
Regula de exclusivitate mutual
Constrngere de exclusivitate mutual
Istoricul atributului
Modelarea generic
Modelarea fizic
Reguli de mapare
IV.11 APLICAIE PROPUS
Realizai diagrama ER i modelul fizic al BD a unui supermarket, prin care se gestioneaz

produsele, considernd cel puin patru subtipuri de produse. Se dorete s se cunoasc
amplasarea pe zone a produselor, precum i angajaii responsabili de plasarea lor pe rafturi.
88
IV.12 TEST-GRIL
1. ntre entitile STUDENT, DISCIPLIN, NOT i PROFESOR se pot stabili mai multe
relaii. Care dintre urmtoarele relaii considerai trebuie c este redundant i trebuie
eliminat?
DISCIPLIN - NOT
DISCIPLIN PROFESOR
NOT - PROFESOR
STUDENT - NOT
2. Pentru BD a unei faculti, care dintre relaiile urmtoare este de tip M:M?
DISCIPLIN PROFESOR
DISCIPLIN - SAL
NOT - PROFESOR
STUDENT - DISCIPLIN
3. Care dintre urmtoarele relaii sunt netransferabile?
client-chitan
student-grup
oper-autor
autovehicul-proprietar
4. Care dintre urmtoarele entiti admite subtipuri? Menionai-le acolo unde este cazul.
autovehicul: ...........................................................................................................................
construcie: ............................................................................................................................
program software: .................................................................................................................
carte: ......................................................................................................................................
5. Cum se mapeaz supertipul?

cu toate atributele specifice subtipurilor dar cu caracter opional
ntr-un singur tabel
n mai multe tabele asociate subtipurilor
printr-o cheie strin
6. Atributul de legtur dintr-o relaie n bucl devine n modelul fizic:

cheie primar
cheie strin
cheie unic
opional
89
Baze de date_________________________________________________________________
7. Pentru maparea unei relaii 1:M dintre dou entiti A i B, se poate folosete:
cheia primar a lui A ca i cheie primar a lui B
cheia primar a lui A ca i cheie strin a lui B
cheia primar a lui B ca i cheie primar a lui A
cheia primar a lui B ca i cheie strin a lui A
8. La maparea unei relaii barate, atributul de legtur devine:

component a cheii primare a entitii determinate
cheie strin a entitii determinate
component a cheii primare a entitii determinante
cheie strin a entitii determinante
9. La maparea unei relaii netransferabile, se impun condiiile:

ON DELETE NO ACTION
ON DELETE SET DEFAULT
ON UPDATE CASCADE
ON UPDATE NO ACTION
10. Se mapeaz n dou tabele, subtipurile entitii CLIENT, respectiv PERSOAN FIZIC
i PERSOAN JURIDIC. Entitatea CLIENT are o relaie cu entitatea COMAND.
Subentitatea PERSOAN JURIDIC are o relaie cu entitatea BANC. Care dintre
urmtoarele afirmaii este adevrat?
Atributele comune ale subtipurilor entitii client apar n fiecare tabel de subtip.
Atributele specifice ale fiecrui subtip sunt incluse ca opionale n tabelul CLIENI.
Relaia cu entitatea COMAND se mapeaz ca i cheie strin n ambele tabele ale
subtipurilor.
Relaia cu entitatea BANC se mapeaz ca i cheie strin n ambele tabele ale
subtipurilor.
90
CAPITOLUL V
FINALIZAREA PROIECTRII BAZEI DE DATE
DIN CUPRINS:
V.1 ANALIZA CRUD
V.2 SECVEN, INDEX, ROL
V.3 TRANZACII
V.4 ETAPELE CICLULUI DE VIA AL UNEI APLICAII
CU BD
V.5 REZUMATUL CAPITOLULUI
V.6 TERMENI SPECIFICI
V.7 TEST-GRIL
Baze de date_________________________________________________________________
V.1 ANALIZA CRUD
Aa-numita analiz CRUD (prescurtare a secvenei CREATE, RETRIEVE, UPDATE,

DELETE), face referire la posibilitatea de a crea structura bazei de date, de a regsi, a
modifica ori actualiza datele nregistrate sau de a le terge, atunci cnd i pierd valoarea sau
cnd devin perimate.
Proiectarea BD trebuie fcut astfel nct s fie posibile aceste patru operaiuni, pe serverul
de BD.
Prin analiza CRUD se urmrete dac modelele i implementarea BD permit efectuarea
tuturor operaiilor amintite, asupra tuturor datelor i n mod consistent, cu meninerea BD
ntr-o stare coerent.
Prin aceasta, analiza CRUD valideaz modelul ER creat pentru BD.
Se verific dac nu s-au omis din modelul BD, entiti, atribute sau relaii care sunt necesare
aplicaiei descrise de BD.
De exemplu, sunt multe relaii ntre tabele, exprimate prin atributele de tip cheie strin.
Omiterea unei constrngeri de tip cheie strin, conduce la rezultate eronate ale unei
interogri a BD, care vizeaz datele coninute n tabelele relaionate.
Se verific, de asemenea, dac modelul creat nu include unele aspecte a cror prezen nu se
justific, avnd n vedere cerinele clientului specificate n scenariul BD. Comunicarea
permanent dintre proiectant i client, este esenial pentru crearea unui model complet i
corect dimensionat al BD.
Dac transpunerea modelului conceptual al BD n modelul fizic i, ulterior, implementarea
BD nu sunt fcute riguros, exist riscul ca anumite prevederi din documentaia BD s nu fie
respectate sau ndeplinite i s se ajung chiar la nclcri ale unor reguli ale afacerii,
specifice activitii descrise n BD.
Analiza BD trebuie fcut cu personal specializat, n mod sistematic, urmrindu-se pas cu
pas, fiecare cerin din documentaie.
n specificaiile clientului trebuie urmrite anumite cuvinte-cheie care exprim cerinele
acestuia: introducere, nregistrare, ncrcare, importare, exportare, vizualizare, actualizare,
raport, listare, tiprire, citire, cutare, modificare, schimbare, tergere etc.
Toate acestea se traduc n operaii specifice BD, de tip CRUD, i trebuie s poat fi realizate
pe baza modelului creat.
92
Analiza CRUD a modelului urmrete ca asupra oricrei entiti din model s se poat
efectua cele patru operaii pentru a nu avea aspecte nemodelate ale aplicaiei.
Testarea cu un set complet de date de test, care s creeze toate situaiile reale tipice, din
perspectiva tuturor tipurilor de utilizatori ai BD i a tuturor regulilor de afaceri, precum i
corectarea aspectelor nedorite ale BD, va finaliza proiectarea acesteia.
V.2 SECVEN, INDEX, ROL
Secvena este un alt obiect al BD, cu caracter partajat, care permite mai multor utilizatori s
atribuie identificatori unici pentru unul i acelai obiect, asupra cruia se efectueaz operaii
de inserare de date de ctre mai multe persoane. Este extrem de util o secven de numere
unice, de exemplu, de nregistrare a candidailor din locaii diferite, la un concurs de admitere
la o universitate, care are sedii n mai multe orae. Pentru a nu se crea confuzii, fiecare
candidat trebuie s aib un numr unic de nregistrare, indiferent unde s-a nscris.
Pentru bazele de date distribuite n reea, generarea secvenelor unice de nregistrare este
esenial pentru corectitudinea procesului de gestiune a datelor prin intermediul bazelor de
date.
O secven este generat independent de tabelele din BD, cu valori minime i maxime, cu un
anumit pas de incrementare, cu posibilitatea memorrii unui set de valori iniial n memoria
cache i cu riscul pierderii acestora la o problem tehnic a sistemului precum i cu opiunea
de ciclare a secvenei, n sensul relurii procesului de generare a valorilor pornind de la
valoarea minim, dup ce s-a ajuns la valoarea maxim.
Exerciiu propus: Dai trei exemple, de situaii concrete n care este esenial crearea i
folosirea secvenelor n BD.
Indexul este un alt element specific BD, prin care se accelereaz procesul de cutare i de
extragere a informaiilor din tabelele BD. Crearea unui index implic ocuparea unui spaiu de
memorie suplimentar i, de aceea, este indicat s se creeze un index doar ntr-un caz bine
justificat. Indexul nu ia n considerare dect valorile nscrise ntr-o coloan, nu i null-urile.
93
Baze de date_________________________________________________________________
Securizarea BD impune acordarea de drepturi i revocarea lor pentru diferii utilizatori sau
pentru diferite grupuri de utilizatori. Utilizatorii din acelai grup sunt asociai cu un aa-numit
rol, un obiect creat distinct n structura BD (ROLE) pentru a specifica n mod unitar
drepturile de accesare a BD i de manipulare a datelor pentru utilizatorii cu acelai rang.
Administrarea conturilor utilizatorilor BD se face mai rapid i mai eficient prin definirea
acestor roluri, dect individual, pentru fiecare utilizator n parte.
V.3 TRANZACII
Tranzacia este o unitate logic de lucru care conine una sau mai multe comenzi SQL, care
se execut ca o singur funcie logic.
Iniierea tranzaciei poate fi fcut de ctre o persoan sau un program, printr-o comand de
iniiere de tip SELECT, INSERT, UPDATE.
Pn la completarea tranzaciei, efectele ei nu sunt vizibile.
Tranzacia las BD ntr-o stare coerent (Fig. V.1). Dac, dintr-un anumit motiv, una sau mai
multe operaii din cadrul unei tranzacii eueaz, atunci toate operaiile efectuate pn la acel
pas, n cadrul acelei tranzacii, sunt anulate i BD revine n starea coerent, n care se gsea
nainte de lansarea tranzaciei. De fapt, pe toat durata efecturii tranzaciei, excluznd pasul
de finalizare a acesteia, BD nu i modific starea.
Fig. V.3 Schema de principiu a unei tranzacii
Tranzacia include operaii de acces la BD i de manipulare a datelor:

BEGIN - nceperea efecturii tranzaciei; tranzacia intr n faza activ de derulare.
READ citirea datelor
WRITE scrierea datelor
94
END ncheierea operaiilor de manipulare a datelor, specificate n acea tranzacie

COMMIT aplicarea efectelor tranzaciei, dup verificarea execuiei corecte a
tuturor operaiilor tranzaciei, asupra ntregului set de date din BD. Modificrile din
BD sunt permanente i nu mai pot fi anulate sau pierdute, la o defectare ulterioar a
sistemului.
ABORT renunare la efectuarea tranzaciei; tranzacia este declarat ca abandonat
(aborted). Se execut procesul de revenire la datele iniiale (ROLLBACK), dac din
anumite motive, tranzacia nu poate fi complet i corect efectuat (tranzacie euat
failed).
UNDO anularea unei singure operaii din cadrul tranzaciei.
REDO reluarea unor comenzi din tranzacie, pentru a o putea finaliza.
Tranzaciile sunt descrise prin patru proprieti:
1. Atomicitate (all or nothing) - aciunile tranzaciei se execut toate sau nu se execut
deloc.
2. Consistena tranzactia menine BD ntr-o stare coerent, dup execuie.
3. Izolare - tranzactia este protejat de efectele executrii concurente a altor tranzacii.
4. Durabilitate efectele tranzaciei comise sunt permanente chiar i n cazul unei
cderi a SGBD (Database recovery).
SGBD menine ntr-o list (log) toate aciunile efectuate asupra datelor, astfel nct poate s
refac datele (undo) dup anularea unor operaii sau tranzacii.
Asigurarea atomicitii tranzaciei n prezena cderilor sistemului se numete recuperare la
cderi (crash recovery). Acest procesul de refacere va scana pn la cel mai recent punct
stabil, checkpoint, care conine lista tranzaciilor active i apoi pn la punctul de ncepere a
acestora.
O mare problem a bazelor de date i a proiectanilor de BD este aceea de gestionare a
conflictelor care apar n cazul tranzaciilor concurente (care se execut simultan asupra
acelorai structuri i date din BD).
Dou tranzacii de citire a acelorai date nu sunt conflictuale i ordinea lor nu conteaz. Dou
tranzacii, care citesc sau scriu obiecte din BD distincte, nu sunt conflictuale i de asemenea,
ordinea de execuie a lor nu conteaz. ns dac o tranzacie scrie un obiect de date i o alta
citete sau scrie acelai obiect, cele dou tranzacii intr n conflict iar ordinea execuiei lor
este esenial pentru obinerea rezultatului corect din punctul de vedere al aplicaiei.
n BD, apar urmtoarele tipuri de conflicte:
95
Baze de date_________________________________________________________________
Scriere - citire (WR): a doua tranzacie citete un obiect scris anterior de prima
tranzacie.
Citire - scriere (RW): a doua tranzacie scrie un obiect de date citit anterior de ctre
prima tranzacie.
Scriere scriere (WW): a doua tranzacie scrie un obiect de date scris anterior de
prima tranzacie.
Lipsa unui control asupra ordinii de execuie a operaiilor din tranzacii concurente poate s
genereze mari erori n coninutul BD.
De exemplu, s presupunem, c simultan un contabil efectueaz majorarea salariilor cu 20 %
iar alt contabil nscrie n BD bonusurile acordate salariailor pentru ultima lun. Pentru un
salariat, cu un salariu de 2000 RON, cruia i se acord un bonus de 500 RON, n ordinea
specificat a tranzaciilor, venitul ncasat va fi de 2900 RON. Dac ns se nregistreaz mai
nti bonusul i abia apoi se aplic majorarea de 20 %, salariatul va ncasa 3000 RON, pentru
c majorarea se va aplica i bonusului, ceea ce ncalc regulile aplicaiei.
Este foarte important s fie gestionate corect tranzaciile concurente i, pentru aceasta, se
folosesc aa-numitele lacte (LOCK), operaii de blocare a accesului, aplicate obiectelor
din BD care sunt folosite ntr-una din tranzacii, astfel nct nici o alt tranzacie s nu poat
s le citeasc sau s le modifice pn la finalizarea primei tranzacii. Lactele asigur acces
exclusiv la anumite obiecte din BD pentru o tranzacie, pentru o anumit perioad de timp.
Lactele pot fi de mai multe tipuri:
de blocare a accesului la obiect: interzice accesul altor tranzacii la acel obiect,
prevenind rezultatele incorecte.
de citire a obiectului (shared/read lock) obiectul poate fi citit, dar nu modificat.
de scriere a obiectului (exclusive/write lock) tranzacia care deine lactul, poate s
citeasc i s scrie obiectul pe care este aplicat acesta.
SGBD gestioneaz, prin componenta sa de management a lactelor, ordinea de acordare a
acestora pentru diferitele tranzacii.
De exemplu, s presupunem c tranzacia 1 (T1) este cea de majorare cu 20% a salariilor
nscrise n tabelul A iar tranzacia 2 (T2) este cea de acordare de bonusuri (tabelul B) i se
aplic pe acelai tabel din BD. S urmrim modul de rezolvare a conflitului dintre tranzacii,
prin folosirea lactelor:
T1 T2
1 Begin-transaction
96
2 Write-lock(A) Begin-transaction
3 Read(A) Write-lock(A)
4 A=A*1.20 Wait
5 Write(A) Wait
6 Unlock(A) A=A+B
Gestionarea tranzaciilor concurente revine ca sarcin a programatorului de BD. Tranzaciile

nu pot fi reprezentate n diagram ER dar ordinea de execuie i restriciile de execuie a lor
sunt descrise n documentaia BD, prin regulile de afaceri ale aplicaiei.
V.4 ETAPELE CICLULUI DE VIA AL UNEI APLICAII CU BD
Pentru a realiza o aplicaie de BD, este necesar urmrirea pailor urmtori:

Planificarea BD const n activiti administrative care vizeaz identificarea
planurilor de afaceri i a cerinelor sistemului informaional, evaluarea situaiei
curente i a oportunitilor IT, i se bazeaz pe modelul general de date care include
entitile i relaiile dintre ele, reprezentate ntr-o diagram ER, n care se specific i
legturile cu diferitele zone funcionale ale ntreprinderii.
Definirea sistemului const n stabilirea scopului i a limitelor aplicaiei BD,
inclusiv domeniile de utilizare i grupurile principale de utilizatori.
Colectarea i analiza cerinelor se face prin chestionarea persoanelor reprezentative
pentru toate domeniile de interes ale ntreprinderii, observarea funcionrii acesteia i
analiza documentelor utilizate pentru nregistrarea i redarea informaiilor,
observarea tranzaciilor efectuate etc. Instrumentele CASE (Computer-Aided
Software Engineering) sunt utile pentru specificarea complet i coerent a cerinelor
(caracteristicilor) ntreprinderii, .
Proiectarea BD ncepe cu realizarea unor modele de date care conin entiti i
relaii de nivel nalt (eseniale pentru reprezentarea funcionalitii ntreprinderii n
BD), dup care se trece la o analiz detaliat pentru a identifica i include n model
toate entitile, atributele i relaiile de nivel jos.
97
Baze de date_________________________________________________________________
Alegerea unui SGBD adecvat, care s accepte aplicaia de tip BD, se poate face ntre
fazele de proiectare logic i conceptual a BD. Se au n vedere costurile de achiziii
software i hardware, cele de instruire a personalului, precum i performanele
sistemului.
Proiectarea programelor de aplicaie pentru utilizatori, cu interfee prietenoase i
eficiente, cu posibiliti de accesare a datelor i efectuare a tranzaciilor n BD, se
face n paralel cu proiectarea propriu-zis a BD.
Realizarea unui prototip al BD este o etap opional dar avantajoas, ntruct pe
baza unui model de lucru simplificat, cu costuri reduse, se testeaz funcionalitatea
aplicaiei BD, se identific eventualele probleme dar i caracteristici noi care trebuie
implementate.
Implementarea BD i a aplicaiilor const n realizarea fizic a proiectelor acestora
folosind diverse limbaje. Implementarea BD se face pe baza unui limbaj de definire a
datelor (DDL). Instruciunile DDL sunt compilate pentru a crea schema BD. Vederile
utilizatorilor sunt definite n aceast etap. Programele-aplicaie sunt implementate
cu ajutorul altor limbaje, DML, sau de nivel nalt Java, C, C++, Delphi, cu meniuri,
formulare, rapoarte i cu reguli de securitate i de integritate.
Conversia i ncrcarea datelor const n transferul n BD a datelor existente, cu
eventuala conversie de format, folosind un utilitar de ncrcare n BD a fiierelor deja
existente.
Testarea aplicaiei BD const n executarea programelor de aplicaie cu scopul
depistrii erorilor de funcionare, pe baza unor strategii de testare. ntreinerea
operaional se face prin monitorizarea continu a aplicaiei, remedierea erorilor de
funcionare prin reorganizarea BD i eventual, implementarea unor cerine noi. Este
indicat folosirea noilor aplicaii de tip BD n paralel cu cele vechi, dac acestea
exist, pentru o anumit perioad de timp (de regul, ase luni) n care s se observe
i s se rezolve disfuncionalitile noului sistem.
98
V.5 REZUMATUL CAPITOLULUI
Proiectarea bazei de date se ncheie cu analiza CRUD (CREATE, RETRIEVE, UPDATE,

DELETE), care testeaz posibilitatea de a crea ntreaga structur a bazei de date, de a regsi,
a modifica ori a actualiza datele nregistrate sau de a le terge, atunci cnd nu mai au valoare.
n fapt, aceasta face parte din etapele ciclului de via al unei aplicaii cu BD.
Optimizarea BD n fazele de modelare dar i de implementare necesit crearea de noi obiecte
i elemente n BD, precum vederile externe pentru diferite categorii de utilizatori ai BD,
secvenele de numere unice i indexurile de accelerare a procesului de cutare n BD.
Gestionarea tranzaciilor i rezolvarea eventualelor conflicte reprezint un aspect-cheie al
aplicaiilor cu BD prin care se evit disfuncionalitile aplicaiei, erorile i inconsistena
datelor.
Ciclul de via al aplicaiei de BD ncepe cu activitile de planificare ce includ identificarea
planului de afaceri i a cerinelor sistemului informaional, evaluarea situaiei curente i a
oportunitilor IT, urmate de definirea sistemului, colectarea i analiza cerinelor.
Proiectarea propriu-zis a BD se continu cu alegerea unui SGBD adecvat i proiectarea
programelor de aplicaii pentru utilizatori. Realizarea unui prototip al BD permite
testarea modelelor folosite i a eventualelor probleme. Implementarea BD i a aplicaiilor
i testarea lor este realizat de programatorii BD. Administratorii de date se ocup apoi de
conversia i ncrcarea datelor.
Este esenial ntreinerea operaional a aplicaiei cu BD i este recomandat ca pentru un
anumit timp, noile aplicaii de BD s fie rulate n paralel cu cele vechi, astfel nct s se
observe i s se rezolve eventualele disfuncionaliti ale noului sistem.
V.6 TERMENI SPECIFICI
Analiza CRUD
Secven
Index
Rol
Tranzacie
Conflict
99
Baze de date_________________________________________________________________
Lact
Tipuri de lacte
Checkpoint
Crash recovery
Ciclu de via
V.7 TEST-GRIL
1. Care dintre urmtoarele operaii sunt vizate prin analiza CRUD?

MODIFY
SELECT
SET
TRUNCATE
2. Accelerarea procesului de cutare n BD se face prin crearea:

unei interfee grafice
unui index
unei secvene
unei vederi
3. Scopul unei secvene create n BD este acela de a:

accelera cutarea datelor
crea sinonime ale obiectelor deja definite
genera identificatori unici
trunchia tabelele din BD
4. Rezolvarea conflictelor dintre tranzaciile concurente care pot s apar n BD, se face prin
definirea unor:
indexuri
lacte
roluri
secvene
5. Administrarea drepturilor grupurilor de utilizatori ai BD se face prin intermediul:

indexurilor
lactelor
rolurilor
secvenelor
100
BIBLIOGRAFIE
[1] Thomas Connoly, Carolyn Begg, Anne Strachan, Baze de date Proiectare,
Implementare, Gestionare, Editura Teora, 2001
[2] Hugh Darwen, An Introduction to Relational Databases Theory, Hugh Darwen &
Ventus Publishing ApS, 2010
[3] Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database Systems, 5th
Edition, Addison-Wesley, 2007
[4] C. J. Date, An Introduction to Database Systems, 8th Edition, Addison-Wesley, 2003
101

BD1

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BD1

Încărcat de

Drepturi de autor:

Formate disponibile

__________________________________________________________________Luminia Scripcariu

CAPITOLUL I. INTRODUCERE N TEORIA BAZELOR DE DATE ............................. 5

CAPITOLUL II. ELEMENTELE SPECIFICE BAZELOR DE DATE ............................... 25

CAPITOLUL III. DIAGRAMA ENTITATE-RELAIE ..................................................... 45

III.3 Reprezentarea grafic a diagramei ER ............................................................ 49

CAPITOLUL IV. ASPECTE PARTICULARE ALE MODELRII DATELOR ............... 67

CAPITOLUL V. FINALIZAREA PROIECTRII BAZEI DE DATE ................................ 91

BIBLIOGRAFIE .................................................................................................................. 101

Bazele de date reprezint o aplicaie fundamental din domeniile programrii

Proiectarea bazei de date reprezint o etap esenial i critic pentru succesul

Aceast carte este dedicat proiectrii sistematice a bazelor de date relaionale

Cartea se adreseaz studenilor i tuturor celor interesai de proiectarea bazelor

Conf. dr.ing. Luminia SCRIPCARIU

Universitatea Tehnic Gheorghe Asachi din Iai

I.1 DEFINIII I APLICATIVITATE

Iniial a aprut necesitatea computerizrii sistemului de ndosariere. O prim soluie a acestei

Sistemul de gestiune a bazelor de date (SGBD, Database Management System - DBMS)

Aplicaiile cu baze de date faciliteaz accesul la informaii i reduc timpul de efectuare a

I.2 CATEGORII DE PERSONAL

Diferitele categorii de personal implicate n aplicaiile de BD necesit o anumit pregtire

Categoriile de persoane implicate n mediul BD sunt:

Proiectanii bazei de date se ocup de culegerea informaiilor care descriu cerinele i

Administratorul bazei de date (DBA Database Administrator) se ocup de popularea cu

I.3 NOIUNI SPECIFICE BAZELOR DE DATE

BD opereaz n termeni de entitate, atribut, relaie.

Fiecrei categorii de obiecte descrise n BD i se asociaz un tip de entitate cu un nume

O relaie reprezint o asociaie ntre mai multe entiti.

De exemplu, studenii de la o anumit specializare i dintr-un anumit an de studiu, studiaz

Figura I.1 Diagram Entitate - Relaie

Figura I.2 Exemplu de reprezentare grafic a unui tip de entitate,

Rezolvarea tranzaciilor concurente, n funcie de cerinele clientului, reprezint un alt aspect

Tranzacia reprezint o operaie de manipulare a datelor din BD .

Controlul tranzaciilor este avut n vedere n faza de programare, pe baza documentaiei BD

De exemplu, n timp ce un client lanseaz comanda de achiziie a unui produs de la un

Vederea extern reprezint forma de vizualizare a anumitor informaii incluse n BD care

De exemplu, departamentul tehnic al unei firme poate solicita ca aplicaia de BD s genereze

n prezent, se dezvolt SGBD multiutilizator pentru BD cu capaciti mari de stocare pentru

I.4 MODELAREA DATELOR

Modelul de date conceptual este creat independent de limbajul de programare n care se va

Modelarea datelor ncepe cu analiza cerinelor beneficiarilor bazei de date, aa-numitele

Figura I.3 Diagram ER parial - exemplu

Normalizarea este procesul de optimizare a modelului de date conceptual, prin care se

I.5 MODELAREA FIZIC

Realizarea propriu-zis a BD (Database Design) const n crearea structurii acesteia, folosind

Un tabel din BD se asociaz unui tip de entitate.

O coloan din tabel corespunde unui atribut al tipului de entitate.

Numele coloanelor dintr-un tabel pot s difere n structura intern a BD fa de ceea ce se

Prin NULL se nelege lipsa valorii unui atribut i nu valoarea zero.

I.6 ARHITECTURA BAZELOR DE DATE

Figura I.4 Arhitectura ANSI-SPARC a unei BD

modele externe bazate pe nregistrri i generate n funcie de diferitele cerine ale

Procesul de modelare a datelor independent de modul de implementare, de SGBD int, de

Schema intern este legat de cea conceptual printr-o interfa de transpunere

I.7 REZUMATUL CAPITOLULUI

Baza de date (BD) reprezint o resurs unic de informaii, computerizat, stocat pe un

I.8 TERMENI SPECIFICI

baz de date (BD)

I.9 APLICAIE PROPUS

Realizai modelul conceptual i diagrama entitate-relaie pentru o BD folosind scenariul

Se dorete o BD pentru evidena produselor, clienilor i a angajailor unui magazin de

2. ntr-un tabel din BD, un atribut al unei entiti definete:

4. Popularea BD cu date este realizat de ctre:

6. Identificarea nregistrrilor dintr-un tabel din BD se face printr-un atribut:

7. Manipularea datelor din BD se face prin: