Baze de Date - TEORIE

Universitatea Transilvania din Braşov
Facultatea de Inginerie tehnologică

Catedra de Inginerie economică şi sisteme de producţie
Şef lucr. dr. ing. Andrea DEACONESCU
PRELUCRAREA DATELOR
pentru anul II Inginerie economică (4 ani de studiu)
resp.
BAZE DE DATE
Pentru anul IV Inginerie economică (5 ani de studiu)
Braşov
2006
1
2
Cuprins
1. Baze de date. Proiectare. Implementare. Gestionare......................5

1.1 Introducere în BD. Tratarea datelor. Sisteme de gestionare a
bazelor de date. Sisteme bazate pe fişiere......................................5
1.1.1 Introducere..................................................................... 5
1.1.2 Tratarea datelor prin sisteme bazate pe fişiere.....................6
1.1.3 Tratarea datelor prin baze de date (BD)..............................9
1.1.4 Sistemul de gestionare a bazei de date (SGBD)....................9
1.1.5 Componentele mediului SGBD..........................................10
1.1.6 Proiectarea BD – schimbarea de paradigmă........................12
1.1.7 Poziţiile persoanelor din mediul BD....................................13
1.1.8 Avantajele şi dezavantajele SGBD.....................................15
1.1.8 Rezumatul capitolului 1.1................................................17
1.1.9 Întrebări la capitolul 1.1..................................................18
1.2. Modelul relaţional (SGBDR)..................................................19
1.2.1 Terminologie..................................................................19
1.2.2 Integritatea relaţională....................................................23
1.2.3 Vederi........................................................................... 24
1.3 Planificarea, proiectarea şi administrarea BD...........................26
1.3.1 Ciclul de viaţă al sistemelor informaţionale.........................26
1.3.2 Fazele proiectării BD.......................................................30
1.3.3 Proiectarea aplicaţiilor.....................................................32
1.3.4 Administrarea datelor şi a bazei de date............................33
1.4. Modelarea Entitate-Relaţie (ER)............................................35
1.4.1 Conceptele modelului ER.................................................36
1.4.2 Constrângeri structurale..................................................42
1.4.3 Problemele modelului ER.................................................48
1.5 Normalizarea...................................................................... 53
1.5.1 Scopul normalizării.........................................................53
1.5.2 Redundanţa datelor şi anomaliile de reactualizare...............54
1.5.3 Dependenţe funcţionale...................................................55
1.5.4 Procesul de normalizare..................................................57
1.5.5 Prima formă normală......................................................58
3
1.5.6 A doua formă normală (2NF)............................................61
1.5.7 A treia formă normală (3NF)............................................64
1.6 Metodologia de proiectare conceptuală a bazelor de date..........69
1.6.1 Pasul 1. Construirea modelului de date conceptual local pentru
fiecare vedere a utilizatorilor....................................................69
1.7 Metodologia de proiectare logică a bazelor de date pentru modelul
relaţional................................................................................. 75
1.7.1 Pasul 2. Construirea şi validarea modelului de date logic pentru
fiecare vedere a utilizatorilor....................................................75
1.7.2 Pasul 3. Construirea şi validarea modelului de date logic global
............................................................................................ 86
1.8 Metodologia de proiectare fizică a bazelor de date pentru bazele
de date relaţionale....................................................................92
1.8.1 Pasul 4. Transformarea modelului de date logic global pentru
un SGBD ţintă........................................................................92
1.8.2 Pasul 5. Proiectarea reprezentării fizice..............................98
1.8.3 Pasul 6. Proiectarea mecanismelor de securitate...............108
1.8.4 Pasul 7. Monitorizarea şi reglarea sistemului operaţional... .113
1.8.5 Rezumatul capitolului 1.8...............................................115
1.8.6. Întrebări la capitolul 1.8...............................................116
4
1. Baze de date. Proiectare. Implementare. Gestionare
Obiectivele acestui modul sunt:

- Cunoaşterea noţiunilor de bază privind sistemele informatice de
gestionare a bazelor de date relaţionale;
- Planificarea, proiectarea şi administrarea bazelor de date;
1.1 Introducere în BD. Tratarea datelor. Sisteme de gestionare a

bazelor de date. Sisteme bazate pe fişiere
1.1.1 Introducere
Cu siguranţă cei mai mulţi dintre Dvs. au o idee despre ce ar putea fi o

bază de date (BD). Bazele de date au apărut ca răspuns la nevoia
organizaţiilor (instituţii, întreprinderi, societăţi comerciale etc.) de a
eficientiza evidenţa activităţii lor, din toate punctele de vedere:
producţie, stocuri, aprovizionare, contabilitate, resurse umane, vânzări
etc.
Vedem BD în viaţa de zi cu zi – listele de ofertă ale diferiţilor furnizori
de cărţi, CD-uri, cartea de telefon, piesele în stoc de furnizat pentru un
anumit proiect, fişe sau înregistrări de prelucrat de un anumit program
etc.
Exprimându-ne mai precis, atunci când utilizăm termenul de bază de

date ne referim la o colecţie structurată de articole de date, între care
există legături logice. O astfel de colecţie, o BD, a fost construită pentru
a servi pentru o anume aplicaţie, reprezentând o lume în miniatură.
Articolele dintr-o BD se manipulează, pentru a extrage informaţiile utile.
Un sistem de gestionare de bază de date (SGBD), sau database

management system (DBMS) este softul care permite ca bazele de date
să fie definite/configurate, construite şi exploatate/manipulate. Obiectul
cursului nostru este SGBDR, sistemul de gestionare de baze de date
relaţionale, cu aplicaţii în MS-Access.
Modelul relaţional de BD
5
Există trei modele uzuale de implementare de BD: ierarhic, reţea sau
relaţional. Fiecare se bazează pe conceptul de date stocate ca set sau
mulţime de înregistrări. Imaginaţi-vă un set de fişe, de exemplu.
Modelele ierarhic şi reţea se bazează pe parcurgerea legăturilor dintre
date pentru a lucra cu baza de date; de regulă sunt utilizate pentru
sisteme-cadru generale, vaste şi nu fac obiectul cursului nostru.
Sistemele de gestionare a bazelor de date relaţionale (SGBDR) au
cunoscut o largă răspândire, datorită modelului simplu, relaţional de
date pe care-l utilizează:
 Datele se prezintă sub forma unei colecţii (unui set) de relaţii
 Fiecare relaţie are forma unui tabel (cea mai importantă
componentă a unei BD)
 Rândurile (înregistrările) tabelului reprezintă entităţi
 Coloanele (câmpurile) tabelului sunt atribute/proprietăţi ale
acestor entităţi
 Fiecare tabel are un set de atribute, care împreună reprezintă o
“cheie” care defineşte fiecare entitate în mod unic.
De exemplu, o societate poate avea în baza sa de date un tabel cu
angajaţii săi, cu un rând/înregistrare pentru fiecare angajat. Ce atribute
ar fi de interes? Depinde de sigur de scopul pentru care a fost creat
tabelul, şi atributele sunt stabilite la momentul configurării bazei de
date. Ca exemplu aplicaţia poate fi un ştat de plată, deci va fi nevoie, în
afară de nume, cod angajat şi de informaţii referitoare la adresă şi
salariu.
1.1.2 Tratarea datelor prin sisteme bazate pe fişiere
Superioritatea administrării datelor dintr-o organizaţie cu ajutorul unui

sistem de gestionare de baze de date (SGBD) rezultă dintr-o scurtă
comparaţie între sistemele tradiţionale de date, bazate pe fişiere şi
sistemele de gestionare a bazelor de date (SGBD)
Sistemul bazat pe fişiere este o colecţie de programe de aplicaţie

care efectuează servicii pentru utilizatorii finali, cum ar fi producerea de
rapoarte. Fiecare program defineşte şi gestionează propriile date.
Exemplu: o firmă care furnizează componente pentru diferite

proiecte/clienţi.
Compartimentul magazie (al firmei) va ţine fişiere cu:
6
- componentele în stoc, pe fişa fiecărei componente apărând
denumirea, seria, costul, nr. bucăţi etc.
Compartimentul contabilitate (al firmei) va ţine fişiere cu:
- componentele în stoc, documentele de achiziţie, intrare,
denumirea, seria, costul, nr. bucăţi etc.
- ieşirile de componente, cu caracteristicile şi cantităţile de
componente, documentaţie însoţitoare de ieşire (inclusiv numele
proiectelor/clienţilor către care se furnizează)
Compartimentul vânzări (al firmei) va ţine fişiere cu:
- numele proiectelor către care se livrează, inclusiv nume clienţi,
număr contract, tipuri de componente livrate
- cerinţele clienţilor, cu detalierea componentelor necesitate, inclusiv
descrierea componentelor, gradul de urgenţă şi prioritate etc.
Rezultă următoarele limitări ale sistemelor bazate pe fişiere:
- Separarea şi izolarea datelor. Atunci când datele sunt izolate în

fişiere separate, cele care ar trebui să fie disponibile sunt mai greu
de accesat. De exemplu dacă vrem să aflăm care componente
până la o anumită limită de preţ şi în ce cantitate se află în stoc
pentru un anumit proiect, va trebui sa extragem date din fişierul
cu proiecte şi apoi din cel cu stocuri (fişiere existând la
compartimente diferite), va trebui să creăm un fişier temporar care
să cuprindă toate aceste date. Extragerea corectă de date este
dificilă, necesitând sincronizarea prelucrării (în compartimente
diferite) a două sau mai multe fişiere.
- Dublarea datelor. Din cauza modului de abordare descentralizat,

specific fiecărui compartiment, tratarea datelor pe bază de fişiere a
dus la dublarea necontrolată a datelor. Observăm în exemplul
nostru, că mai multe compartimente au introdus aceleaşi date în
fişierele lor. Dublarea datelor este de nedorit din următoarele
cauze:
o Risipă: introducerea datelor de mai multe ori costă timp şi
bani, ocupă spaţiu suplimentar de stocare, deci alte costuri;
o Alterarea integrităţii datelor, prin dublare, deci datele nu mai
concordă. De exemplu, dacă intrarea unor componente cu
preţ nou nu este comunicată de către compartimentul
contabilitate celor de la magazie, aceleaşi componente vor
apărea în fişierele diferitelor compartimente cu preţ diferit.
7
- Dependenţa de date. Dacă este necesar de modificat structura
unui fişier (de ex. mărimea unui câmp), atunci trebuie de
identificat toate programele care lucrează cu acest fişier, pentru a
opera modificările respective în fiecare dintre ele. Această
caracteristică a sistemelor bazate pe fişiere se numeşte
dependenţă program-date.
- Incompatibilitatea fişierelor. Este posibil ca fiecare compartiment

să-şi genereze fişiere în alt limbaj de programare; structura
fişierelor va fi dependentă de limbajul în care este scris programul.
De exemplu, dacă compartimentul vânzări vrea să afle detaliile
legate de stocul existent pentru o anume componentă, va încerca
să acceseze fişierul corespunzător al compartimentului magazie,
plecând de la câmpul “denumire componente” existent în fişierele
ambelor compartimente; dacă fişierele sunt generate cu limbaje
diferite, va trebui să intervină un programator care să scrie un
program de transformare a fişierelor într-un format comun.
- Interogarea fixă sau proliferarea programelor de aplicaţie.

Tratarea datelor prin sisteme de fişiere a reprezentat un progres
semnificativ faţă de sistemele manuale. Au crescut cererile de
interogări noi sau modificate, care necesitau de fiecare dată
intervenţia programatorului, care trebuia să scrie interogările.
Astfel au apărut două situaţii. Pentru a limita volumul de lucru al
programatorilor, s-a ajuns la fixarea numărului de interogări
disponibile. Pentru a satisface numărul crescând de cereri de
interogări, a proliferat numărul de aplicaţii; au rezultat programe
ineficiente, scrise în grabă, cu documentaţie limitată şi dificil de
întreţinut. Accesul la fişiere este limitat la un singur utilizator o
dată, deci nu exista partajarea accesului pentru mai mulţi
utilizatori din acelaşi compartiment.
Limitările tratării datelor bazată pe fişiere au două cauze:

(1) definiţia datelor este încorporată în programele de aplicaţie, în
loc de a fi stocată independent;
(2) nu există control asupra accesului şi manipulării datelor
dincolo de cel impus de programele de aplicaţie.
8
Ca urmare a apărut o nouă tratare a datelor, prin baze de date (BD),
gestionate de sisteme de gestionare a bazelor de date (SGBD).
1.1.3 Tratarea datelor prin baze de date (BD)
Baza de date este o colecţie partajată de date între care există relaţii
logice (şi o descriere a acestor date), proiectată pentru a satisface
necesităţile informaţionale ale unei organizaţii.
Baza de date nu mai este deţinută de un singur compartiment al unei

organizaţii, ci este o resursă comună, partajată. Datele sunt integrate,
cu o dublare minimă. BD conţine datele operaţionale ale organizaţiei şi
descrierea acestora.
O bază de date este deci o colecţie autodescrisă de înregistrări
integrate. Această caracteristică BD este cunoscută şi ca independenţa
program - date.
O BD relaţională conţine entităţile, atributele şi relaţiile logice dintre

acestea, reprezentate printr-o diagramă entitate – relaţie (ER). Vom
reveni în detaliu asupra modelului ER de BD.
1.1.4 Sistemul de gestionare a bazei de date (SGBD)
SGBD este un sistem de programe care permite utilizatorului definirea,

crearea şi întreţinerea bazei de date şi accesul controlat la aceasta.
SGBD constă în elemente de software care interacţionează cu

programele de aplicaţie ale utilizatorului pe de o parte şi cu baza de
date pe cealaltă.
Un SGBD oferă o serie de facilităţi:

- permite definirea BD printr-un limbaj de definire a datelor (DDL)
- permite inserarea, reactualizarea, ştergerea şi extragerea de date
printr-un limbaj de manipulare a datelor (DML). BD fiind un depozit
unic şi central de date şi descrieri de date, DML poate oferi o
interogare generală a acestor date, numită limbaj de interogare.
Un astfel de limbaj de interogare este SQL, care elimină utilizarea
9
unui set fix de interogări disponibile, ca în cazul tratării datelor prin
sisteme de fişiere.
- Oferă accesul controlat la BD. Astfel SGBD poate furniza:
o Un sistem de securitate, pentru a împiedica accesul
utilizatorilor neautorizaţi
o Un sistem de integritate, care menţine concordanţa datelor
stocate;
o Un sistem de control al utilizării simultane, care permite
accesul partajat la BD;
o Un sistem de control al refacerii, care restaurează BD într-o
stare precedentă concordantă, ca urmare a unei defecţiuni
hard sau soft;
o Un catalog accesibil utilizatorilor, care conţine descrieri ale
datelor din BD
- Oferă generarea de vederi/views numite şi moduri de vizualizare a
BD prin mecanismul de vizualizare. Astfel se vor afişa numai
acele date din BD care sunt utile utilizatorului, eliminându-se
încărcarea rezultatului unei interogări cu date existente în BD, dar
care nu interesează utilizatorul. Modurile de vizualizare oferă şi
alte avantaje:
o Un anumit nivel de securitate; se exclud date care nu trebuie
văzute de anumiţi utilizatori;
o O personalizare a aspectului BD. De exemplu redenumirea
câmpurilor după preferinţele utilizatorului;
o O imagine coerentă, neschimbată a structurii BD, chiar dacă
BD însăşi este modificată; prin modul de vizualizare se va
afişa în continuare structura prestabilită a BD.
1.1.5 Componentele mediului SGBD
Mediul SGBD are cinci componente principale:
-- Date --
Hardware - Software -- -- Proceduri – Persoane
Maşină Punte Om
Hardware
10
Evident, pentru a funcţiona, SGBD au nevoie de elemente hardware,
care pot fi un singur PC până la o reţea. Un SGBD poate necesita un
anumit tip de elemente hardware sau de sistem de operare, sau poate
funcţiona pe o diversitate de elemente hardware şi platforme; Access
2000 este de ex. un SGBD relaţionale pe 32 biţi, pentru crearea de
aplicaţii clasice sau de tip client-server pentru BD, pentru sistemele de
operare Windows 9x şi Windows NT 4+; de asemenea, un SGBD
necesită un minimum de memorie (MS-a: size: 2,32 KB) şi spaţiu de
disc (MS-Access: size on disk: 4 KB).
O configuraţie / arhitectură
client-server este prezentată
în figura 1.1, pentru o
organizaţie cu patru filiale
legate într-o reţea de PCuri,
deservite de un server central.
Pe server se află programele
back-end, adică partea din
SGBD care administrează şi
controlează accesul la BD. Pe
calculatoarele din diversele
locaţii/PC clienţi se află
aplicaţiile front-end, adică
partea din SGBD care
constituie interfaţa cu
utilizatorul.
Fig. 1.1
Software
Componenta soft cuprinde programele SGBD şi programele de aplicaţie
împreună cu sistemele de operare, inclusiv software de reţea, dacă este
cazul. Programele aplicaţie sunt scrise într-un limbaj de programare din
generaţia a treia (C, Cobol, Fortran) sau de generaţia a patra – SQL,
incorporat într-un limbaj de generaţia a treia.
SGBD poate avea propriile instrumente de generaţia a patra, care
permit dezvoltarea rapidă de aplicaţii prin furnizarea unui limbaj de
interogare şi a unor generatoare de rapoarte, formulare, grafică etc.
11
Instrumentele de generaţia a patra îmbunătăţesc productivitatea şi
permit realizarea unor programe uşor de întreţinut.
Datele
Datele reprezintă cea mai importantă componentă a unui SGBD,
d.p.d.v. al utilizatorului; datele = punte între componentele maşină şi
cele umane. BD conţine:
- Date operaţionale
- Meta-date, adică date despre date.
Structura BD este numită schemă şi are mai multe tabele sau fişiere,
fiecare având mai multe atribute (câmpuri).
Procedurile
Procedurile se referă la instrucţiunile şi regulile care guvernează
proiectarea şi utilizarea BD. Procedurile sunt necesare atât
administratorilor, cât şi utilizatorilor de BD şi pot cuprinde instrucţiuni
referitoare la ;
- deschiderea unei sesiuni de lucru în SGBD;
- utilizarea unei anumite facilităţi a SGBD sau a unui program
aplicaţie;
- pornirea şi oprirea SGBD;
- efectuarea de copii de siguranţă a BD ;
- tratarea defecţiunilor hard sau soft;
- modificarea structurii unui tabel, reorganizarea BD pe mai multe
discuri, arhivarea datelor etc.
Persoanele
Sunt ultima componentă a unui mediu SGBD şi va fi discutată la
paragraful „Poziţiile persoanelor din mediul SGBD”.
1.1.6 Proiectarea BD – schimbarea de paradigmă
Structura unei BD (entităţile, atributele, relaţiile) este determinată în

timpul proiectării BD. Abordarea proiectării unei BD este diferită de cea
a sistemelor pe bază de fişiere, unde totul era dictat de nevoile
aplicative ale departamentelor individuale. În cazul BD trebuie de
considerat întâi datele apoi aplicaţiile. Această schimbare a modului de
tratare se numeşte schimbare de paradigmă.
12
Cauza principală a eşecurilor sistemelor informaţionale este lipsa
aplicării unei metodologii de proiectare a BD în mod structurat. Astfel
rezultă BD ineficiente pentru cerinţele aplicaţiilor, documentaţia este
limitată, întreţinerea dificilă.
1.1.7 Poziţiile persoanelor din mediul BD
In acest paragraf se examinează a 5-a componentă a mediului SGBD,

anume persoanele. Se pot identifica patru tipuri distincte de persoane
implicate în mediul SGBD:
- administratorii de date şi de BD;
- proiectanţii de BD;
- programatorii de aplicaţii;
- utilizatorii finali.
Administratorii de date şi de BD
BD şi SGBD sunt resurse comune care trebuie gestionate ca orice

resursă.
Sarcinile administratorului de date (DA = data administrator):
- responsabil cu gestionarea resurselor de date: planificarea,
elaborarea şi întreţinerea strategiilor şi procedurilor bazei de date
- responsabil cu proiectarea conceptuală/logică a BD
- consultarea şi îndrumarea managerilor superiori cu privire la
direcţia de dezvoltare a BD, a.î BD să sprijine obiectivele generale
ale organizaţiei.
Administratorul de baze de date (DBA – data base administrator) este
responsabil cu realizarea fizică a BD, având următoarele sarcini:
- proiectarea şi implementarea BD,
- securitatea şi controlul integrităţii BD,
- întreţinerea sistemului operaţional,
- asigurarea de performanţe satisfăcătoare pentru aplicaţii şi
utilizatori;
Rolul DBA este mai tehnic şi necesită cunoaşterea în detaliu a SGBD şi a
mediului acestuia.
Proiectanţii de BD
13
Există proiectanţi de BD logice şi proiectanţi de BD fizice.
Proiectanţii de BD logice: “ce anume?”

- se ocupă cu identificarea datelor (entităţi şi atribute) şi relaţiilor
dintre acestea, şi de constrângerile asupra celor care vor fi stocate
în BD;
- trebuie să cunoască foarte bine datele organizaţiei şi a regulilor de
operare ale organizaţiei;
- trebuie să implice toţi posibilii utilizatori ai BD în modelul creat.
Etape de proiectare a BD logice:

a) proiectarea conceptuală a BD, independent de detaliile de
implementare (de ex. SGBD utilizat, programele de aplicaţie,
limbajele de programare etc.)
b) proiectarea logică a BD, care se bazează pe un anumit model, de
ex. relaţional, ierarhic, în reţea, orientat pe obiecte.
Proiectanţii de BD fizice (“Cum anume?”) preia modelul logic şi

stabileşte realizarea fizică:
- transpunerea modelului logic de date într-un set de tabele şi
constrângeri privind integritatea;
- selectarea de structuri de stocare şi metode de acces specifice, a.î.
să se obţină performanţe bune ale datelor in activităţile legate de
BD;
- măsuri referitoare la securitatea datelor.
Proiectarea fizică a unei BD trebuie să ţină cont de SGBDul avut în
vedere; proiectantul trebuie să cunoască funcţionalitatea acestui SGBD
şi avantajele şi dezavantajele fiecărei variante de implementare a BD.
Strategia de stocare aleasă trebuie să ţină cont de modul de utilizare.
Programatorii de aplicaţii
Odată realizată BD trebuie implementate programele de aplicaţie ce

conferă funcţionalitatea cerută de utilizatorii finali. Aceasta este sarcina
programatorilor de aplicaţii. Fiecare program conţine instrucţiuni care îi
cere SGBD să efectueze o operaţie oarecare în BD (extragere, inserare,
reactualizare, ştergere de date). Programele pot fi scrise într-un limbaj
de generaţia a treia sau a patra.
14
Utilizatorii finali
Sunt clienţii pentru care a fost proiectată, implementată şi este

întreţinută BD, pentru a le satisface necesităţile informaţionale.
Utilizatorii simpli nu sunt conştienţi de SGBD. Accesează BD prin

programe de aplicaţie speciale, simplificatoare. Ei folosesc comenzi
simple, opţiuni din meniu. Utilizatorul simplu nu ştie nimic despre BD
sau SGBD (de ex. vânzătorul care citeşte codul de bare pentru a afla
preţul unui produs. Există totuşi un program care citeşte codul de bare,
caută preţul articolului respectiv în BD, modifică câmpul cu stocul de
articole, afişează preţul la casă).
Utilizatorii sofisticaţi sunt familiarizaţi cu structura BD şi facilităţile

SGBD. Pot utiliza un limbaj de interogare de nivel înalt (SQL). Pot scrie
programe de aplicaţie pentru uz personal.
1.1.8 Avantajele şi dezavantajele SGBD
Avantaje
- Controlul redundanţei datelor; nu se elimină în întregime
redundanţa, ci se controlează volumul inerent al acesteia în BD.
- Coerenţa datelor; datorită eliminării redundanţei, orice
reactualizare a unui articol (stocat o singură dată) se face o
singură dată, eliminându-se incoerenţa. Dacă articolul este stocat
de mai multe ori, SGBD garantează coerenţa tuturor exemplarelor
din articolul respectiv.
- Mai multe informaţii obţinute de la aceeaşi cantitate de date; ca
urmare a integrării datelor operaţionale, două sau mai multe fişiere
pot fi integrate, extrăgându-se mai multe informaţii.
- Partajarea datelor; fişierele sunt deţinute de compartimentele
organizaţiei care le utilizează, dar fiind parte din BD, ele sunt la
dispoziţia tuturor utilizatorilor interesaţi.
- Integritatea crescută a datelor; se referă la validitatea şi coerenţa
datelor stocate. Integritatea este exprimată prin constrângeri, care
reprezintă reguli de coerenţă pe care BD nu are voie să le încalce.
- Securitatea crescută; se referă la protecţia BD faţă de utilizatorii
neautorizaţi. Fără sisteme de securitate, integrarea ar face datele
15
foarte vulnerabile. Securitatea se realizează prin nume de
utilizatori plus parole. Se poate limita tipul de operaţie efectuată.
- Aplicarea standardelor; prin integrare se pot aplica standarde
organizaţionale, naţionale sau internaţionale, ca de ex. formatul
datelor, convenţii referitoare la denumire, pt. a facilita schimburi
între sisteme.
- Economia de scală; în loc de bugete pentru fiecare compartiment
pentru crearea unui sistem propriu de BD bazat pe fişiere, există
un buget unic combinat, care permite alocarea fondurilor
economisite pentru îmbunătăţirea sistemului.
- Echilibrul între cerinţele aflate în conflict; cerinţele posibil în
conflict ale diferitelor compartimente referitoare la utilizarea BD
sunt gestionate la nivel de DBA, care va lua deciziile ce se impun şi
va acorda prioritate aplicaţiilor majore.
- Îmbunătăţirea accesibilităţii datelor şi capacităţii de răspuns;
limbajele de interogare şi generatoare de rapoarte asociate SGBD
oferă utilizatorilor posibilitatea unor interogări ad-hoc, fără a apela
la programator.
- Productivitatea crescută; SGBD furnizează standardele necesare
aplicaţiei, economisind timpul programatorului.
- Capacitatea de întreţinere îmbunătăţită, prin independenţa de
date; într-un SGBD descrierile datelor sunt separate de aplicaţii,
aplicaţiile fiind imune la modificarea descrierii datelor; este
caracteristica de independenţă program-date, care uşurează
întreţinerea aplicaţiilor din BD.
- Concurenţa/simultaneitatea îmbunătăţită; se garantează alterarea
datelor în situaţia când acelaşi fişier este utilizat simultan de mai
mulţi utilizatori.
- Îmbunătăţirea serviciilor de salvare de siguranţă şi refacere. Se
minimizează pierderile apărute ca urmare a unor defecţiuni. Nu
este necesară realizarea zilnică de copii de siguranţă.
Dezavantaje
- Complexitatea; pt. ca un SGBD să fie funcţional, acesta va evolua
într-un sistem soft extrem de complex. Funcţionalitatea trebuie
cunoscută de către toţi cei implicaţi în BD, de la DA la utilizatorul
final, pentru a o putea exploata. Dacă SGBD este greşit înţeles, BD
proiectată poate fi greşită, cu toate consecinţele acestei situaţii.
16
- Dimensiunea; Fiind un element soft foarte complicat, SGBD ocupă
mult spaţiu pe disc şi necesită multă memorie pentru a funcţiona
eficient.
- Costul SGBD; variază în funcţie de mediu şi funcţionalitate. De la
150 USD pt. un PC cu un utilizator, la 750.000 USD pt. un sistem
mainframe cu sute de utilizatori. Se adaugă cheltuieli periodice
anuale de întreţinere.
- Costurile adiţionale pentru elemente hardware; pentru a sigura
performanţele SGBD poate fi nevoie de achiziţionarea unui
calculator mai mare, chiar dedicat rulării SGBD, cu disc şi memorie
mai mari.
- Costul conversiei; la implementarea unui nou sistem SGBD şi/sau
a unei noi configuraţii hard, conversia poate costa semnificativ mai
mult decât noile elemente hard. Se include costul instruirii
personalului, angajarea de personal specializat. Apare termenul de
sistem moştenit, adică un sistem mai vechi, inferior, de care
organizaţia se cramponează din motive de costuri de conversie.
- Performanţa; SGBD (spre deosebire de cel bazat pe fişiere) este
general, creat pentru a permite diverse aplicaţii; astfel unele pot
funcţiona mai puţin rapid decât în cazul sistemului bazat pe fişiere,
creat pentru o anume aplicaţie.
- Impactul crescut al unei defecţiuni. Centralizarea (partajarea)
resurselor creşte vulnerabilitatea SGBD. Eşecul oricărei
componente poate duce la sistarea tuturor operaţiilor.
1.1.8 Rezumatul capitolului 1.1
Sistemul de gestionare a bazelor de date (SGBD) reprezintă cadrul

de bază pentru sistemele informaţionale şi a avut un impact
fundamental asupra modului de operare al organizaţiilor.
Predecesorul SGBD a fost sistemul bazat pe fişiere. Acesta reprezintă

o serie de programe de aplicaţie ce efectuează servicii (de regulă
generarea de rapoarte) pentru utilizatorii finali. Fiecare program îşi
defineşte şi îşi gestionează propriile date. Acest sistem reprezintă un
mare progres faţă de sistemele manuale de fişare şi îndosariere, dar are
şi probleme semnificative cum ar fi redundanţa datelor şi dependenţa
program – date.
17
Tratarea datelor prin baze de date rezolvă dificultăţile abordării pe bază
de fişiere. O bază de date reprezintă un set partajat de date şi
descrierea acestora între care există relaţii logice. BD este proiectată
pentru a satisface necesităţile informaţionale ale unei organizaţii.
Un SGBD este un sistem de elemente software, care permite

utilizatorilor definirea, crearea şi întreţinerea bazei de date şi acre
permite accesul controlat la aceasta. SGBD oferă un limbaj de definire
a datelor (DDL), care permite utilizatorilor definirea BD, şi un limbaj
de manipulare a datelor (DML), care permite utilizatorilor inserarea,
reactualizarea, ştergerea şi extragerea datelor din BD.
Mediul SGBD constă din elemente hardware (calculatorul), de software

(sistemul SGBD, sistemul de operare şi programele de aplicaţie), date,
proceduri şi persoane. Persoanele includ administratorii de date şi de
baze de date, proiectanţii de baze de date, programatorii de aplicaţii şi
utilizatorii finali.
Avantajele tratării datelor prin BD includ: controlul redundanţei

datelor, coerenţa şi partajarea datelor, îmbunătăţirea securităţii şi
integrităţii datelor. Dezavantajele includ: complexitate, preţ, impact
scăzut al defecţiunilor.
1.1.9 Întrebări la capitolul 1.1

 Daţi patru exemple de sisteme de baze de date (situaţii în care
activitatea unei organizaţii ar avea beneficia de pe urma unei baze
de date)
 Analizaţi termenii: date; bază de date; sistem de gestionare a
bazelor de date; vederi.
 Analizaţi avantajele tratării datelor prin sisteme bazate pe fişiere.
 Descrieţi principalele diferenţe între tratarea datelor prin baze de
date faţă de tratarea bazată pe fişiere.
 Descrieţi cele cinci componente ale mediului SGBD şi analizaţi
relaţiile dintre acestea.
 Analizaţi rolurile următoarelor categorii de personal în mediul
SGBD: administrator de date; administrator de baze de date;
proiectant de baze de date logice; proiectant de baze de date
fizice; programator de aplicaţii; utilizatori finali.
18
1.2. Modelul relaţional (SGBDR)
În cadrul modelului relaţional (ML) toate datele sunt structurate logic în

cadrul unor relaţii (tabele). Fiecare relaţie are o anumită denumire (titlu
tabel) şi este formată din anumite atribute (coloane) ale datelor. Fiecare
tuplu (line) conţine câte o valoare per atribut.
1.2.1 Terminologie
1.2.1.1 Structura relaţională a datelor
Relaţie: o relaţie este un tabel cu coloane şi rânduri.

Atribut: Un atribut este o coloană a unei relaţii, cu o anumită
denumire.
Domeniu: Un domeniu este mulţimea de valori permise pentru unul
sau mai multe atribute. Pentru fiecare atribut se defineşte în mod
central denumirea domeniului, sensul acestuia şi domeniul de definiţie.
Ca urmare sistemul va evita operaţiile incorecte semantic. (De ex.
compararea unui număr de telefon cu nr. de casă, deşi ambele sunt
şiruri de caractere; însă: nr. luni este legal de înmulţit cu salariile, deşi
primele sunt caractere text, iar celelalte sunt valori monetare).
Exemplu:
Atribut Denumirea Sensul Domeniul de

(cap de domeniului definiţie
coloană)
Localitatea Localitatea Mulţimea tuturor Caracter:
denumirilor de dimensiune 20
localităţi din
România
Nr tel Numere Mulţimea tuturor Caracter:
telefon numerelor de telefon dimensiune 14
din România
Tuplu: Un tuplu este un rând dintr-o relaţie.

Intensitatea unei relaţii: structura tabelului, specificarea domeniilor
şi a altor restricţii referitoare la valorile posibile. Intensitatea este de
regulă fixă/fixată.
19
Extensia (starea) unei relaţii: tuplurile, care se modifică în timp.
Grad: Gradul unei relaţii reprezintă numărul de atribute pe care îl
conţine. O relaţie cu două atribute, de exemplu, se numeşte binară.
Cardinalitate: cardinalitatea unei relaţii este numărul de tupluri
conţinute de aceasta.
Baza de date relaţională: Un set de relaţii normalizate. O BDR constă
din relaţii structurate adecvat.
Termeni formali Alternativa 1 Alternativa 2

Relaţie Tabel Fişier
Tuplu Rând Înregistrare (Record)
Atribut Coloană Câmp (Field)
1.2.1.2 Relaţii matematice
Pentru a înţelege sensul termenului de relaţie revedem unele concepte

matematice.
Produsul cartezian:
D1 x D2;
D1 = {2, 4}; D2 = { 1, 3, 5};
D1 x D2 = {(2,1); (2,3); (2,5); (4,1); (4,3); (4,5)}
Orice submulţime a produsului cartezian este o relaţie:

de ex. R = {(2,1); (4,1)}, adică: R = {(x,y)| x  D1, y  D2 şi y = 1}
sau:
S = {(x,y)| x  D1, y  D2 şi x = 2y}, adică S ={(2,1)}
n
X Di
În general scriem produsul cartezian a n mulţimi ca fiind: i 1
Fiecare element al produsului cartezian va fi un n-tuplu, adică este
format din n elemente, câte unul din fiecare mulţime de la 1 la n. Orice
submulţime a acestui produs cartezian, adică orice mulţime de n-tupluri
reprezintă o relaţie a celor n mulţimi (care formează produsul
cartezian).
1.2.1.3 Relaţii în bazele de date
Schema de relaţie: O denumire a relaţiei, urmată de un set (mulţime)

de perechi formate din atribute şi denumiri de domenii.
20
Fie o relaţie R cu atributele Ai cu domeniile corespunzătoare Di, i=1,n.
Relaţia R va fi definită de schema de relaţie S= {A 1:D1, A2:D2, ...,
An:Dn}.
Fiecare înregistrare (tuplu) din acest tabel (relaţie) va fi descrisă prin n
coloane (atribute), va fi deci un n-tuplu, fiecare atribut (A i , i=1,n)
luând o valoare (di , i=1,n) din domeniul corespunzător (D i , i=1,n).
Deci di  Di.
Un n-tuplu al relaţiei (o înregistrare din tabel) va avea deci forma:
(A1:d1, A2:d2, …, An:dn).
Fiecare element din acest n-tuplu este format dintr-un atribut şi
valoarea lui.
Relaţia va fi deci o mulţime (un set) de astfel de n-tupluri.
Când relaţia R se scrie sub formă de tabel, atributele (A i) vor fi capetele
de coloane, iar tuplurile (n-tuplurile) vor fi rândurile, de forma d 1, d2, …,
dn.
Astfel, o relaţie din modelul relaţional este o submulţime al produsului

cartezian al domeniilor atributelor. Tabelul este o reprezentare fizică a
unei astfel de relaţii.
1.2.1.4 Proprietăţile relaţiilor

- fiecare relaţie are o denumire, diferită de toate celelalte denumiri
de relaţii;
- fiecare celulă a relaţiei conţine exact o valoare atomică (singulară);
este ilegală trecerea de mai multe valori într-o celulă;
- fiecare atribut are o denumire distinctă;
- toate valorile unui atribut aparţin aceluiaşi domeniu;
- ordinea atributelor nu are nici o importanţă;
- fiecare tuplu este distinct; nu există dubluri ale tuplurilor;
- teoretic, ordinea tuplurilor nu are nici o importanţă (în practică
poate afecta eficienţa accesării tuplurilor).
Aceste proprietăţi rezultă din proprietăţile relaţiilor matematice:
- din moment ce relaţia este o mulţime, ordinea elementelor nu are
importanţă; deci ordinea tuplurilor nu are importanţă;
- într-o mulţime nu se repetă nici un element; deci nu există tupluri
duble.
1.2.1.5 Chei relaţionale
21
Trebuie să existe posibilitatea de identificare unică a unui tuplu dintr-o
relaţie, prin valorile atributelor sale.
Supercheia: Este un atribut sau un set de atribute care identifică în

mod unic un tuplu din interiorul unei relaţii.
O supercheie poate conţine şi atribute care nu sunt necesare identificării
unice a tuplului.
Cheia candidat: este o supercheie minimă, pentru care nici o

submulţime nu este supercheie în cadrul relaţiei respective.
O cheie poate include mai multe atribute, caz în care se numeşte cheie
combinată.
O cheie candidat este unică (în fiecare tuplu al relaţiei R, valorile cheii
identifică acel tuplu în mod unic) şi ireductibilă (nici o submulţime a
cheii candidat nu este unică).
Cheia primară: este cheia candidat care este selectată [din toate
cheile candidat identificate] pentru a identifica în mod unic tuplurile din
cadrul unei relaţii.
Cheile candidat neselectate se numesc chei alternative.
Cheie străină: Un atribut sau o mulţime de atribute din cadrul unei

relaţii, care se potrivesc cu o cheie candidate din altă relaţie.
De exemplu o cheie străină dintr-o relaţie poate (spunem că ţinteşte)
coincide cu cheia primară din altă relaţie. (Spunem că ţinteşte cheia
primară din altă relaţie).
Atributele comune joacă un rol important în manipularea datelor.
1.2.1.6 Reprezentarea schemelor (de relaţii) din BD relaţionale
Schema unei relaţii dintr-o BD are forma:

Denumire relaţie [titlu tabel] (Atribute, începând cu cheia primară,
subliniată)
Clienţi (Nr. crt., firmă, localitate, adresă facturare, judeţ,
cod poştal,
nr. telefon, cont trezorerie, dată contact).
Modelul conceptual (schema conceptuală) al unei BD este

mulţimea tuturor schemelor de relaţie pentru BD respectivă.
22
1.2.2 Integritatea relaţională
Un model de date relaţional cuprinde:

- o parte structurală, discutată în paragraful precedent;
- un set de reguli de integritate care asigură corectitudinea datelor;
- o parte de manipulare, care defineşte tipurile de operaţii permise
asupra datelor.
Fiecare atribut are un domeniu, deci asupra valorilor permise pentru

fiecare atribut există anumite constrângeri de domeniu.
Mai există două reguli de integritate importante care sunt

constrângeri ce se aplică întregii baze de date, anume:
- integritatea entităţilor
- integritatea referenţială
1.2.2.1 Null-uri
Null reprezintă valoarea unui atribut care este curent necunoscută sau
nu este aplicabilă tuplului respectiv.
Valoare logică “necunoscut”.
Un Null nu este acelaşi lucru cu o valoare numerică = 0 sau cu un şir de
text “spaţii” (zero string); acestea sunt valori, un Null însemnând însă
absenţa unei valori.
1.2.2.2 Integritatea entităţilor
Se aplică cheilor primare ale relaţiilor de bază. O relaţie de bază (tabel

de bază) corespunde unei entităţi în schema conceptuală a BD.
Integritatea entităţilor: într-o relaţie de bază nici un atribut al unei
chei primare nu poate fi Null.
1.2.2.3 Integritatea referenţială
Se aplică cheilor străine.

Integritatea referenţială: Dacă într-o relaţie există o cheie străină,
valoarea acesteia trebuie ori să coincidă cu valoarea unei chei candidat
a unui tuplu în relaţia sa de bază, ori să fie în întregime Null.
23
1.2.2.4 Constrângerile de întreprindere
Constrângerile de întreprindere: sunt reguli adiţionale, specificate
de către utilizatorii sau administratorul bazei de date (DBA).
1.2.3 Vederi
Vederea externă este structura BD aşa cum apare ea unui anumit

utilizator.
În modelul relaţional o vedere este o relaţie virtuală, o relaţie care nu

este de fapt de sine stătătoare, ci este derivată în mod dinamic din una
sau mai multe relaţii de bază.
1.2.3.1 Terminologie
Relaţie de bază: O relaţie cu o anumită denumire, corespunzătoare

unei entităţi din schema conceptuală, ale cărei tupluri sunt stocate fizic
în BD.
Vedere: Rezultatul dinamic al uneia sau mai multor operaţii relaţionale

care acţionează asupra relaţiilor de bază, pentru a obţine o altă relaţie.
O vedere este o relaţie virtuală, care în realitate nu există în BD, ci este
produsă în momentul respectiv, la cererea unui utilizator.
Conţinutul unei vederi este definit ca o interogare asupra unei sau mai
multor relaţii de bază. Vederile sunt dinamice, adică modificările în
relaţiile de bază sunt reflectate imediat în vederi. Şi invers, modificările
permise operate asupra vederii se transmit relaţiilor de bază.
1.2.3.2 Scopul vederilor
Mecanismul de vedere este util pentru că:

- furnizează un mecanism de securitate puternic;
- permite utilizatorilor accesarea datelor în mod personalizat;
aceleaşi date pot fi vizualizate simultan, în moduri diferite, de către
diverşi utilizatori;
- poate simplifica operaţiile complexe asupra relaţiilor de bază.
24
1.2.3.3. Reactualizarea vederilor
Există restricţii referitor la modificările care pot fi efectuate prin

intermediul vederilor.
Condiţiile de care depinde reactualizarea datelor prin intermediul
vederilor sunt:
- sunt permise reactualizările prin intermediul unor vederi definite
prin utilizarea unei interogări simple a unei singure relaţii de bază,
şi care interogare conţine fie cheia primară, fie cheia candidat a
acesteia;
- nu sunt permise reactualizările prin vederi care implică relaţii de
bază multiple;
- nu sunt permise reactualizările prin vederi care implică operaţia de
acumulare sau de grupare.
Relaţiile sunt reprezentate fizic sub formă de tabele, cu rândurile

corespunzând tuplurilor individuale, iar coloanele corespunzând
atributelor.
Structura relaţiei, împreună cu specificarea domeniilor şi altor
constrângeri fac parte din intensitatea bazei de date, iar relaţia,
împreună cu toate tuplurile sale reprezintă o extensie a bazei de date.
Proprietăţile relaţiilor din bazele de date sunt: fiecare celulă conţine
exact o valoare, denumirile atributelor sunt diferite, valorile acestora
provin din acelaşi domeniu, ordinea atributelor nu are importanţă, nici
ordinea tuplurilor, nu există tupluri duble.
Gradul unei relaţii reprezintă numărul de atribute, în timp de
cardinalitatea reprezintă numărul de tupluri. O relaţie unară are un
singure atribut, una binară are două, una ternară are trei, iar o relaţie
n-ară are n atribute.
O supercheie este un set de atribute care identifică în mod unic
tuplurile dintr-o relaţie, în timp ce o cheie candidat este o supercheie
minimă. O cheie primară este o cheie candidat selectată pentru a
identifica tuplurile. O relaţie trebuie să aibă întotdeauna o cheie
primară. O cheie străină este un atribut sau set de atribute dintr-o
relaţie care constituie o cheie candidat pentru altă relaţie.
25
Un Null reprezintă o valoare pentru un atribut care este necunoscut în
momentul respectiv sau nu este definit pentru acel tuplu.
Integritatea entităţilor este o constrângere care stabileşte că, într-o
relaţie de bază nici un atribut al unei chei primare nu poate avea
valoarea Null. Integritatea referenţială stabileşte că valorile cheii
străine trebuie să corespundă valorilor unei chei candidat a unui tuplu
oarecare din relaţia de bază sau să aibă în întregime valoarea Null.
În modelul relaţional o vedere este o relaţie virtuală. Vederea oferă
securitate şi permite proiectantului să personalizeze modelul unui
utilizator. Vederile sunt create dinamic pentru utilizatori. Nu toate
vederile pot fi reactualizate.
 Analizaţi fiecare dintre următoarele concepte în contextul

modelului de date relaţional: relaţie, atribut, domeniu, tuplu,
intensitate şi extensie, gard şi cardinalitate.
 Analizaţi diferenţele dintre cheile candidat şi cheia primară a unei
relaţii. Ce este o cheie străină? Care este legătura dintre cheile
străine şi cele candidat ale unei relaţii? Daţi exemple.
 Definiţi cele două reguli de integritate principale din modelul
relaţional. Analizaţi de ce sunt necesare aceste reguli.
 Ce este o vedere? Analizaţi diferenţa dintre o vedere şi o relaţie de
bază. Ce se întâmplă când un utilizator accesează o bază de date
prin intermediul unei vederi?
1.3 Planificarea, proiectarea şi administrarea BD
1.3.1 Ciclul de viaţă al sistemelor informaţionale
Un sistem informaţional (SI) include resursele care permit colectarea,

administrarea, controlul şi propagarea informaţiilor în întreaga
organizaţie.
SI al unei organizaţii cuprinde;

- baza de date (BD)
- elementele software ale BD
26
- software de aplicaţie
- elementele hardware
- personalul care utilizează şi dezvoltă sistemul.
În cadrul SI, ciclul de viaţă al aplicaţiei de tip BD cuprinde următoarele

etape (fig. 1.2):
- Planificarea BD: activităţile administrative care permit parcurgerea

etapelor aplicaţiei de tip BD cât mai eficient posibil.
- Definirea sistemului: specificarea scopului şi limitelor aplicaţiei de

tip BD, a utilizatorilor săi şi a domeniilor de aplicaţie.
- Colectarea şi analiza cerinţelor: colectarea şi analizarea de

informaţii despre partea de organizaţie ce urmează să fie deservită
de aplicaţia de tip BD şi utilizarea acestor informaţii pentru
identificarea cerinţelor utilizatorilor;
Cerinţă: o caracteristică ce trebuie inclusă în noul sistem;
Informaţiile şi cererile colectate, exprimate de cele mai multe

ori neformal trebuie transformate într-o formulare structurată;
pentru aceasta se utilizează tehnici de specificare a
cerinţelor, anume: tehnici de analiză şi proiectare structurată
(Structured Analysis Design), diagrame de flux de date (Data
Flow Diagrams) şi diagrame de tip intrare-prelucrare-ieşire
ierarhică (Hierarchic Input Process Output).
- Proiectarea bazelor de date: procesul de realizare a unui proiect

pentru o BD, care va aborda toate operaţiile şi obiectivele
întreprinderii.
Scopurile proiectării BD sunt:
o Reprezentarea datelor şi a relaţiilor dintre ele, necesare

tuturor aplicaţiilor şi utilizatorilor;
o Furnizarea unui model de date care să accepte efectuarea
oricărei tranzacţii necesare asupra datelor;
o Specificarea unui proiect minimal, structurat adecvat pentru
realizarea cerinţelor stabilite referitor la performanţele
sistemului, de exemplu timpul de răspuns.
27
Cele două abordări în proiectarea unui sistem de BD sunt:
o de jos în sus; se stabilesc atributele la un nivel fundamental

(adică proprietăţile entităţilor), care apoi sunt grupate în
relaţii, după dependenţele funcţionale ale acestora; această
abordare se mai numeşte şi normalizare şi este indicată la
proiectarea unor BD mai simple, cu un număr relativ mic de
atribute;
o de sus în jos; pentru BD mai complexe; se începe cu
realizarea unor modele de date care conţin câteva entităţi şi
relaţii de nivel înalt, urmând apoi rafinări succesive de sus în
jos, pentru a identifica entităţile, relaţiile şi atributele asociate
de nivel jos. Această abordare este ilustrată de modelul ER .
Se începe cu identificarea entităţilor şi relaţiilor care prezintă
interes pentru organizaţie, urmată apoi de finalizarea
atributelor. Exemplu: entităţi: clienţi, produse; se identifică
relaţia dintre aceste entităţi: clientul cumpără produse, apoi
se identifică atributele: Clienţi (nr. client, adresă etc.) şi
Produse (nr. produs, factură intrare, stoc etc.).
- Alegerea sistemului SGBD; se alege un sistem adecvat care să

accepte o aplicaţie de tip BD;
- Proiectarea aplicaţiei: Proiectarea interfeţei cu utilizatorul şi a

programelor de aplicaţie care utilizează, respectiv prelucrează BD.
Proiectarea BD şi a aplicaţiilor sunt activităţi paralele în ciclul de
viaţă al aplicaţiei de tip BD.
- Realizarea prototipului: Construirea unui model de lucru al unei

aplicaţii de tip BD.
- Implementarea: realizarea fizică a proiectelor pentru BD şi

aplicaţii; se realizează printr-un DDL corespunzător SGBD ales. În
această etapă sunt realizate şi vederile specificate de utilizatori. O
parte din programele de aplicaţie sunt tranzacţiile bazei de date
implementate cu un DML corespunzător SGBD, care poate fi
incorporat într-un limbaj de programare gazdă (ex. Visual Basic,
Delphi etc.).
28
- Conversia şi încărcarea datelor: transferul în noua BD a oricăror
date deja existente şi conversia oricăror aplicaţii existente, a.î. să
poată funcţiona în cadrul acesteia.
- Testarea: procesul de executare a programelor de aplicaţie, cu

intenţia de a găsi erori; ca şi la proiectare, şi la testare trebuie de
implicat utilizatorii.
Strategii de testare:
o Testarea de sus în jos;
o Testarea de jos în sus;
o Testarea pe fir;
o Testarea la suprasolicitare.
- Întreţinerea operaţională: procesul de monitorizare şi întreţinere a

sistemului, care se efectuează după instalarea acestuia.
o Monitorizarea performanţelor sistemului;
o Întreţinerea şi modernizarea, prin încorporarea de noi cerinţe,
parcurgând etapele precedente.
29
Fig. 1.2 Ciclul de viaţă al aplicaţiilor tip bază de date
1.3.2 Fazele proiectării BD
Proiectarea conceptuală a BD: procesul de construire a unui model al

informaţiilor utilizate în cadrul fiecărei organizaţii, independent de toate
consideraţiile fizice.
Proiectarea logică a BD: procesul de construire a unui model al
informaţiilor utilizate în cadrul unei organizaţii bazat pe un anumit
30
model de date (de exemplu entitate-relaţie - ER), al SGBD, dar
independent de alte consideraţii fizice legate de SGBD.
Tehnica de normalizare este utilizată pentru a testa corectitudinea unui

model de date logic. Normalizarea garantează că relaţiile derivate din
modelul de date nu prezintă redundanţă a datelor, care poate fi cauza
anomaliilor după implementare.
Proiectarea logică şi conceptuală a BD presupune

considerarea/îmbinarea tuturor vederilor utilizatorilor.
Un model logic cu multiple vederi ale utilizatorilor asupra organizaţiei se
numeşte model de date logic global.
În proiectarea unui model de date logic global există două moduri
principale de abordare:
- tratarea centralizată
- tratarea prin integrarea vederilor.
Tratarea centralizată: Îmbină cerinţele separate ale utilizatorilor,

care reprezintă vederi distincte ale acestora într-un set unic de cerinţe,
după care se construieşte modelul de date logic global. Sistemul de BD
nu trebuie să fie prea mare sau complex.
Tratarea prin integrarea vederilor: Îmbină modelele de date logice

separate, care reprezintă vederi distincte ale utilizatorilor, într-un singur
model de date logic global. Vederile distincte ale utilizatorilor se numesc
modele de date logice locale.
Proiectarea fizică a BD: procesul de realizare a descrierii

implementării bazei de date într-o capacitate de stocare; descrie
structurile de stocare şi metodele de acces utilizate.
Principalul scop al proiectării fizice pentru modelul relaţional presupune:
- deducerea unui set de tabele relaţional şi de constrângeri asupra
acestora, din informaţiile provenite din modelul de date logic
global;
- identificarea structurilor de stocare specifice şi a metodelor de
acces la date, pentru a asigura performanţele optime ale
sistemului de BD.
- Proiectarea unei protecţii de securitate pentru sistem;
31
1.3.3 Proiectarea aplicaţiilor
1.3.3.1 Proiectarea tranzacţiilor
Tranzacţie: O acţiune sau serie de acţiuni efectuate de către un singur

utilizator sau program de aplicaţie, care accesează şi pot modifica
conţinutul bazei de date.
O tranzacţie poate fi formată din mai multe operaţii şi este un

eveniment din lumea reală.
SGBD garantează coerenţa BD, deci în urma unei tranzacţii o BD trece

dintr-o stare coerentă într-altă stare coerentă.
SGBD garantează coerenţa BD şi în cazul unei defecţiuni. Odată
tranzacţia încheiată, modificările efectuate sunt stocate permanent în
BD şi nu pot fi pierdute sau anulate (doar printr-o nouă tranzacţie).
Tipuri de tranzacţii:
- de regăsire;
- de reactualizare;
- mixte (regăsire plus reactualizare).
Tranzacţiile se proiectează plecând de la informaţiile din cerinţele

utilizatorului.
Exemplu: utilizatorul va dori să înregistreze toţi noii clienţi în BD, deci
se proiectează o tranzacţie care să facă posibilă această acţiune,
însoţită de o interfaţă prietenoasă cu utilizatorul.
1.3.3.2 Proiectarea interfeţei cu utilizatorul
Utilizatorul va lucra de regulă nu direct în tabele, ci în formulare, fiecare

formular reprezentând un tuplu dintr-un tabel.
Înainte de implementare se proiectează macheta unui formular sau
raport.
Indicaţii utile pentru proiectarea unui formular/raport

- titlu semnificativ
- instrucţiuni inteligibile
- grupare logică a câmpurilor
- aspect atrăgător al machetei
32
- etichete familiare ale câmpurilor
- terminologie şi prescurtări coerente
- utilizare coerentă a culorilor
- spaţii şi limite vizibile ale câmpurilor de introducere a datelor
- mişcare convenabilă a cursorului
- corectare de erori pentru caractere individuale sau câmpuri întregi
- mesaje de eroare pentru valori inacceptabile
- marcare clară a câmpurilor opţionale
- mesaje explicative pentru câmpuri
- semnal de terminare
1.3.4 Administrarea datelor şi a bazei de date
Etapele ciclului de viaţă al aplicaţiilor de tip bază de date şi rolurile

(principal sau secundar) ale personalului administrator de date (DA) şi
administrator de bază de date (DBA) rezultă din tabelul de mai jos:
Etapa Rol principal Rol secundar

Planificarea BD DA DBA
Definirea sistemului DA DBA
Colectarea şi analiza cerinţelor DA DBA
Proiectarea conceptuală a bazei de DA DBA
date
Alegerea sistemului SGBD DBA DA
Proiectarea logică a bazei de date DA DBA
Proiectarea aplicaţiilor DBA DA
Proiectarea fizică a bazei de date DBA DA
Realizarea prototipului DBA DA
Implementarea DBA DA
Conversia şi încărcarea datelor DBA DA
Testarea DBA DA
Întreţinerea operaţională DBA DA
Administrarea datelor (DA): Gestionarea resurselor de date, care

include planificarea BD, realizarea şi întreţinerea standardelor, politicilor
şi procedurilor şi proiectarea conceptuală şi logică a bazei de date.
33
Administrarea bazei de date (DBA): Administrarea realizării fizice a
unei aplicaţii de tip BD, inclusiv proiectarea şi implementarea fizică a
BD, stabilirea controlului de securitate, integritate, monitorizarea
performanţelor sistemului şi reorganizarea BD după necesităţi.
Principalele diferenţe dintre sarcinile din DA şi DBA rezultă din tabelul

de mai jos:
Administrarea datelor (DA) Administrarea bazei de date

(DBA)
Implicat în planificarea IT Evaluează noile SGBD
strategică
Stabileşte scopurile pe termen Execută planurile de atingere a
lung scopurilor
Întăreşte standardele, politicile Întăreşte standardele, politicile
şi procedurile şi procedurile
Stabileşte cerinţele privind Implementează cerinţele
datele privind datele
Realizează proiectarea Realizează proiectarea logică şi
conceptuală şi logică a bazei fizică a bazei de date
de date
Dezvoltă şi întreţine modelul Implementează proiectul fizic
general de date al bazei de date
Coordonează dezvoltarea Monitorizează şi controlează
sistemului baza de date
Are o orientare managerială Are o orientare tehnică
Este independent de SGBD Depinde de SGBD
Un sistem informaţional (SI) constă în resursele care permit

colectarea, gestionarea, controlul şi difuzarea informaţiilor în cadrul
întregii organizaţii.
Principalele etape ale ciclului de viaţă al aplicaţiei tip bază de date
sunt: planificarea BD, definirea sistemului, colectarea şi analiza
cerinţelor, proiectarea BD, alegerea SGBD (opţional), proiectarea
aplicaţiilor, realizarea prototipului (opţional), implementarea, conversia
şi încărcarea datelor, testarea şi întreţinerea operaţională.
34
Proiectarea conceptuală a BD este procesul de construire a unui
model al informaţiilor utilizate în întreprindere, independent de toate
consideraţiile fizice.
Proiectarea logică a BD este procesul de construire a unui model al
informaţiilor utilizate în întreprindere, bazat pe un anumit model de
date, dar independent de un anumit SGBD şi de alte consideraţii fizice.
Un model logic care reprezintă vederile mai multor utilizatori asupra
unei organizaţii se numeşte model de date logic global. În
proiectarea acestuia abordările pot fi: tratarea centralizată şi tratarea
prin integrarea vederilor.
Proiectarea fizică a bazei de date este procesul de implementare într-
o capacitate de stocare; se descriu structurile de stocare şi metodele de
acces la date.
Proiectarea aplicaţiei de tip BD presupune: proiectarea tranzacţiilor
şi proiectarea interfeţei cu utilizatorul. O tranzacţie a bazei de date este
o operaţie care implică acces la baza de date şi reprezintă un eveniment
din lumea reală.
Administrarea datelor constă în gestionarea resurselor de date,
inclusiv planificarea BD, proiectarea conceptuală şi logică a acesteia,
dezvoltarea şi întreţinerea standardelor, politicilor şi procedurilor.
Administrarea datelor acţionează mai ales la începutul ciclului de viaţă
al aplicaţiei tip BD, înainte de implementare.
Administrarea bazei de date constă în gestionarea realizării fizice a
BD, inclusiv proiectarea fizică şi implementarea BD, controlul de
securitate şi integritate, monitorizarea performanţelor şi reorganizarea
BD după caz. Administrarea BD intervine mai ales în etapele târzii ale
ciclului de viaţă al aplicaţiei de tip BD.

 Descrieţi scopul fiecărei etape din ciclul de viaţă al aplicaţiilor de
tip BD.
 Descrieţi principalele scopuri ale fazelor de proiectare conceptuală
şi logică a BD.
 Definiţi diferenţele dintre scopurile şi sarcinile DA şi DBA.
1.4. Modelarea Entitate-Relaţie (ER)
35
Modelul ER este un model conceptual de nivel înalt, dezvoltat de Chen
(1976) pentru a facilita proiectarea BD. Un model de date conceptual se
compune din:
- un set de concepte care descriu structura bazei de date (entităţi,
relaţii, atribute) şi
- tranzacţiile de regăsire şi actualizare asociate.
Scopul realizării unui model de date de nivel înalt este:
- perceperea datelor de către utilizator,
- ascunderea aspectelor tehnice asociate proiectării BD.
Un model de date conceptual este independent de tipul de SGBD utilizat
şi de platforma hardware asociată.
1.4.1 Conceptele modelului ER

Conceptele de bază ale modelului ER includ:
- tipurile de entităţi
- tipurile de relaţii
- atributele
1.4.1.1 Tipuri de entităţi
Tip de entitate: Un obiect sau concept identificat de organizaţie ca

având o existenţă independentă. Un tip de entitate conţine un set de
obiecte sau concepte cu aceleaşi proprietăţi.
Exemple de tipuri de entităţi:
Clienţi, Produse, Personal, Rudă_apropiată (obiecte, entităţi cu
existenţă fizică)
Vânzare (concepte, entităţi cu existenţă conceptuală)
Entitate: o instanţă unic identificabilă a unui tip de entitate.
Exemplu: Georgescu, Popescu sunt entităţi ale tipului de entitate
“Clienţi”
Entitate tare (entitate părinte, proprietar, dominantă): Un tip de
entitate a cărei existenţă nu depinde de alte tipuri de entităţi.
Exemplu: clienţi, produse, personal, vânzare.
Entitate slabă (entitate copil, dependentă, subordonată): Un tip de
entitate a cărei existenţă depinde de existenţa uneia sau mai multor
alte tipuri de entităţi.
Exemplu: Ruda_apropiată.
36
Reprezentare în modelul ER: entitatea tare se trece într-un dreptunghi
cu chenar simplu, entitatea slabă într-un dreptunghi cu chenar dublu
(fig. 1.3).
Personal Ruda_apropiata
Fig. 1.3 Entitate tare şi entitate slabă
1.4.1.2 Atribute
Atribut: o proprietate a unui tip de entitate sau relaţie.

Domeniul atributului: Mulţimea în care ia valori atributul.
Atribut simplu: are o singură componentă, cu existenţă independentă.
Exemplu: Atribute în tipul de entitate Personal: sex, salariu
Atribut compus: are mai multe componente, fiecare independentă
Exemplu: Adresa (Str. Zorilor 13): atributul strada + atributul
numărul
Atribut cu o singură valoare: Conţine o singură valoare pentru o
anumită entitate.
Atribut cu valori multiple: Conţine mai multe valori pentru o singură
entitate.
Exemplu: un client poate avea mai multe numere de telefon.
Atribut derivat: are o valoare derivabilă din valoarea unui atribut sau
set de atribute de care este legat şi care nu sunt în mod necesar în
aceeaşi entitate.
Exemplu: atributul vârsta se derivă din data naşterii.
Reprezentarea atributelor: elipse; contur punctat pentru atribute

derivate, contur dublu pentru atribute cu valori multiple. Atributele
compuse “radiază” atributele componente. Denumirea atributelor cheie
primară se subliniază. Figura 1.4 se referă la modelul ER al unei agenţii
imobiliare.
37
Fig.1.4. Reprezentarea schematică a tipurilor de entităţi “Personal”,
“Filiala” şi “Ruda apropiată” şi a atributelor acestora.
38
1.4.1.3 Tipuri de relaţii
Tip de relaţie : O asociere semnificativă între tipuri de entităţi.

Exemplu: Între tipul de entitate “Filiala” şi tipul de entitate
“Personal” există tipul de relaţie “este alocat”.
Între fiecare entitate din tipurile de entităţi de mai sus există o prezenţă
unic identificabilă a tipului de relaţie dintre ele, numită: relaţie.
Relaţie : o instanţă unic identificabilă a unui tip de relaţie.

Exemplu: între fiecare entitate din tipul de entitate “Personal” şi
fiecare entitate din tipul de entitate “Filială” există o instanţă a relaţiei
“este alocat”, adică fiecare angajat este alocat unei filiale.
În figura 1.5 sunt prezentate apariţiile individuale ale relaţiei „este

alocat” , utilizând o diagramă numită reţea semantică. Aceasta este o
diagramă la nivel de obiecte, unde simbolul  reprezintă entităţile, iar
simbolul  reprezintă relaţiile. Pentru simplificare în fig. 1.5. sunt
prezentate numai unele atribute.
Fig. 1.5. Model semantic în reţea, cu apariţiile individuale ale relaţiei

„Este Alocat”
Reprezentarea schematică a relaţiilor
Modele semantice sunt dificil de înţeles datorită detaliilor.

Reprezentarea de nivel înalt a relaţiei “este alocat”, utilizând conceptele
39
modelului ER se prezintă în figura 1.6. Pentru simplificare s-au
reprezentat numai atributele chei primare.
Relaţiile se reprezintă prin romburi; rombul are linii duble dacă face
legătura dintre o entitate slabă şi una tare, de care depinde.
În exemplul din fig. 1.6 se observă că entitatea slabă Ruda_Apropiată
nu are cheie primară.
Fig. 1.6. Reprezentare schematică a entităţilor, relaţiilor şi atributelor

cheie primară Filiala, Personal şi Ruda_Apropiată
Gradul unei relaţii: numărul de entităţi participante într-o relaţie.
Fig. 1.7. Relaţie binară, cu 2 participanţi (2 entităţi participante), relaţie

numită “deţine”
Fig. 1.8. Relaţie ternară, numită “Fixează”
40
Fig. 1.9. Relaţie cvadruplă, numită “Reglementează”
Relaţie recursivă: O relaţie în care aceeaşi entitate participă mai mult

decât o dată în diferite roluri.
Fig. 1.10. Relaţie recursivă numită “supervizează”, cu numele de roluri

supervizat şi supervizor. Relaţiei i s-au atribuit nume de roluri pentru a
indica scopul pe care-l are fiecare entitate participantă în cadrul relaţiei.
Nume de roluri pot fi utilizate şi când două entităţi sunt asociate prin
mai mult decât o relaţie (fig. 1.11).
41
Fig. 1.11 Entităţi asociate prin două relaţii distincte numite
“Administrează” şi “Este alocat”, împreună cu numele de roluri
corespunzătoare.
1.4.1.4 Atributele relaţiilor
Se pot asocia atribute şi relaţiilor (exemplul din fig. 1.12).
Fig. 1.12. Exemplu de relaţie numită “Vizitează“ cu atributele

(Data_vizitare şi Comentarii).
Prezenţa unor atribute asociate relaţiilor poate indica existenţa unei

entităţi neidentificate (în exemplul dat, entitatea “Vizitare”).
1.4.2 Constrângeri structurale

Entităţilor participante într-o relaţie li se impun anumite constrângeri,
aşa cum sunt percepute în lumea reală.
Exemple: o proprietate de închiriat trebuie să aibă un proprietar, filiala
trebuie să aibă personal.
Există două mari tipuri de constrângeri structurale: de cardinalitate şi
de participare.
1.4.2.1 Constrângeri de cardinalitate
Raport de cardinalitate al unei relaţii: Descrie numărul de relaţii

posibile pentru fiecare entitate participantă.
Pentru relaţii binare raportul de cardinalitate poate fi:

 1:1 unu la unu;
 1: M unu la mai mulţi;
42
 M:N mai mulţi la mai mulţi.
Regulile care stabilesc cardinalitatea sunt reguli de afaceri ale
organizaţiei (în modelarea unei organizaţii trebuie reprezentate cât mai
multe reguli de afaceri).
Relaţii unu la unu (1:1)
Se consideră relaţia binară Administreaza, anume Personal

Administreaza Filiala. Modelul semantic corespunzător este prezentat în
figura 1.13.
Fig.1.13 Model tip reţea semantică al relaţiei 1:1 (Personal

Administreaza Filiala)
Relaţia este de cardinalitate 1:1 deoarece o singură entitate din

Personal este asociată cu o singură entitate din Filiala. Acesta este
confirmată prin regula de afaceri pe care o reprezintă relaţia: o filială
are un singur administrator, iar un angajat poate administra doar o
singură filială. Pot exista angajaţi (de. ex. Ann Beech) care nu
administrează nici o filială. În schimb nu pot exista filiale fără
administrator.
Diagrama ER a acestei relaţii este

prezentată în figura 1.14.
43
Liniile sunt etichetate cu raportul de cardinalitate, care în fig. 1.14 este
1: 1.
Fig. 1.14 Diagrama ER a relaţiei 1:1 Personal Administreaza Filiala
Relaţii unu la mai mulţi (1:M)
Considerăm relaţia binară Personal Supravegheaza

Proprietate_de_Inchiriat, al cărei model tip reţea semantică este
prezentat în figura 1.15.
Fig. 1.15 Diagrama tip reţea semantică a relaţiei 1:M

Din diagramă reiese gradul de cardinalitate al relaţiei ca fiind de 1: M,
deoarece un membru al personalului poate supraveghea mai multe
proprietăţi (de ex. p2 supraveghează pr1 şi pr2), ceea ce corespunde
regulilor de funcţionare ale organizaţiei. În schimb o proprietate poate fi
supravegheată numai de un singur membru al personalului.
Relaţia este deci de cardinalitate 1: M citită de la stânga la dreapta, şi
de cardinalitate 1:1 citită de la dreapta la stânga, din punctul de vedere
al proprietăţii de închiriat. Pentru stabilirea gradului de cardinalitate al
relaţiei se va lua în considerare gradul mai înalt, deci în cazul
exemplului 1:M.
44
Diagrama ER corespunzătoare
acestei relaţii este reprezentată în
figura 1.16.
Fig. 1.16. Diagrama ER a relaţiei
1:M
45
Relaţii mai mulţi la mai mulţi (M:N)
Considerăm relaţia Ziar Face Reclama Proprietate_de_Inchiriat cu

reţeaua semantică din figura 1.17.
Fig. 1.17. Diagramă tip reţea semantică a relaţiei M:N
Din diagramă reiese gradul de cardinalitate al relaţiei de M:N atât

d.p.d.v. al entităţii Ziar, cât şi din cel al entităţii
Proprietate_de_Inchiriat. Corespunzător regulilor de afaceri, într-un ziar
se poate face reclamă mai multor proprietăţi, şi unei proprietăţi i se
poate face reclamă în mai multe ziare.
Diagrama ER corespunzătoare
este prezentată în figura 1.18.
Fig. 1.18.
Diagrama ER a relaţiei M:N
1.4.2.2 Constrângeri de participare
46
Constrângerile de participare determină dacă existenţa unei entităţi
depinde de legătura sa de altă entitate prin intermediul unei relaţii.
Există două tipuri de constrângeri de participare (a unei entităţi într-o

relaţie):
- participare totală sau obligatorie (reprezentată printr-o linie dublă)
- participare parţială sau opţională (reprezentată printr-o linie
simplă).
Participarea unei entităţi într-o relaţie este totală, dacă existenţa unei
entităţi necesită (este condiţionată de) existenţa altei entităţi prin
intermediul unei anumite relaţii. Altfel participarea este parţială.
Exemplu. În relaţia binară Filiala Este Alocat Personal (fig. 1.19) o
filială poate exista, evident, numai dacă are alocat personal. Deci
existenţa entităţii Filiala este condiţionată de existenţa entităţii
Personal. Ca urmare entitatea Filiala va participa total (obligatoriu) în
relaţia Este Alocat, şi se va reprezenta cu linie dublă.
Conform regulilor de afaceri ale

organizaţiei, pot însă exista
membri de personal care nu sunt
alocaţi unei anumite filiale.
Entitatea Personal va avea deci
participare parţială (opţională) în
relaţia Este Alocat, şi se va
reprezenta cu linie simplă
Fig. 1.19. Constrângeri de participare
O reprezentare alternativă a constrângerilor de participare rezultă din

fig. 1.20, unde pe liniile
de legătură sunt trecute valorile
minimă şi maximă cu care pot
participa entităţile în relaţie.
În cazul exemplului, o filială poate
avea minim 5 şi maxim nedefinit
(N) angajaţi. Un angajat poate să
nu fie alocat unei filiale (valoare
47
minimă 0) sau să fie alocat unei filiale, şi numai uneia (valoare maximă
1).
Fig. 1.20 Constrângeri de participare, notaţie alternativă
1.4.3 Problemele modelului ER
În proiectarea unui model de date conceptual pot apărea aşa-numite

capcane de conectare, datorită interpretării eronate a sensului unei
relaţii.
1.4.3.1 Capcane în evantai
Capcanele în evantai sunt acele capcane de conectare care într-un

model ER reprezintă o relaţie dintre tipuri de entităţi, dar căile dintre
anumite apariţii ale entităţilor sunt ambigue.
Capcanele în evantai apar când

două sau mai multe relaţii 1:M
provin din aceeaşi entitate (fig.
1.21).
Din model nu rezultă la ce filială
este alocat un anumit membru al
personalului dintr-o secţie, ştiind
că o secţie coordonează mai
multe filiale.
Examinăm modelul la nivel de apariţii individuale prin intermediul reţelei
semantice (fig. 1.22).
Fig. 1.21 Capcană în evantai
Se poate observa capcana în

evantai: Angajatul SG37 este
alocat secţiei S1, dar secţia S1
coordonând filialele B3 şi B7,
nu se ştie la care dintre aceste
două filiale este alocat SG 37.
48
Fig. 1.22. Reţeaua semantică a modelului ER din fig. 1.21
Capcana se rezolvă prin

restructurarea modelului ER, a.î.
acesta să reprezinte corect
asocierile dintre entităţi (fig.
1.23).
Se observă care secţie
coordonează care filiale, şi ce
personal este alocat fiecărei
filiale.
Fig. 1.23. Model ER restructurat
Reţeaua semantică a
modelului restructurat
(corect) este cea din fig.
1.24.
Angajatul SG37 este alocat
filialei B3, coordonată de
secţia S1.
Fig. 1.24. Reţeaua semantică a modelului ER din fig. 1.23.
1.4.3.2 Capcane de întrerupere
Capcanele de întrerupere sunt acele capcane de conectare în care un

model sugerează existenţa unei relaţii între tipurile de entităţi, dar nu
există căi între anumite apariţii ale acestor entităţi.
Capcanele de întrerupere apar când în calea prin care sunt legate
entităţile intervine o entitate cu participare parţială.
Exemplu. Din modelul din fig. 1.25 se observă următoarele:

Pe ramura din stânga:
49
- unei singure filiale îi sunt alocaţi mai mulţi angajaţi (relaţie 1:M)
- filiale există numai dacă are personal, fiecare membru al
personalului este obligatoriu alocat unei filiale (participări totale –
linii duble de legătură).
Pe ramura din dreapta:
- Un angajat (membru al personalului) poate superviza mai multe
proprietăţi, o proprietate poate fi supravegheată de un membru al
personalului (relaţie 1: M)
- Nu fiecare membru al personalului supraveghează obligatoriu
proprietăţi şi nu toate proprietăţile sunt supravegheate obligatoriu
de un membru al personalului (participări parţiale – linii simple de
legătură).
Din modelul din fig. 1.25 nu se

poate deduce ce proprietăţi sunt
disponibile la care filiale.
Modelul ER sugerează existenţa

unei relaţii între entităţile Filiala şi
Proprietate_de_Inchiriat, dar, aşa
cum rezultă din reţeaua
semantică asociată (fig. 1.26) nu există căi între anumite apariţii ale
entităţilor.
Fig. 1.25 Capcană de întrerupere
Lipsa căilor între anumite

apariţii ale entităţilor Filiala
şi Proprietate_de_Inchiriat
se observă clar din reţeaua
semantică din figura 1.26.
Nu se poate deduce la ce
filială este disponibilă
proprietatea PA14.
Fig. 1.26. Reţeaua semantică a modelului ER din fig. 1.25.

50
Participarea parţială a entităţilor Personal şi Proprietate_de_Inchiriat în
relaţia Supravegheaza are ca efect faptul că unele proprietăţi nu pot fi
asociate cu o filială prin intermediul unui membru al personalului.
Pentru rezolvarea acestei capcane

de întrerupere trebuie identificată
relaţia care lipseşte. Aceasta este
relaţia Are dintre entităţile Filiala şi
Proprietate_de_Inchiriat.
Se restructurează modelul ER,
introducând relaţia nou identificată
Are între entităţile între care
lipseau căile (fig. 1.27).
Fig. 1.27. Model ER restructurat pentru eliminarea capcanei de
întrerupere.
Acum la nivelul apariţiilor
individuale, adică din reţeaua
semantică, se poate stabili că
proprietatea PA14 este
disponibilă la filiala B7 (fig.
1.28).
Fig. 1.28. Reţeaua semantică

a modelului ER restructurat
din fig. 1.27.
Un tip de entitate este un obiect sau un concept care este identificat

de organizaţie ca având o existenţă independentă. O entitate este o
instanţă unic identificabilă a unui tip de entitate.
Un tip de entitate slabă este o entitate a cărei existenţă depinde de
existenţa altor entităţi. O entitate tare este o entitate a cărei existenţă
nu este dependentă de existenţa altor entităţi.
Un atribut este o proprietate a uni tip de entitate sau relaţie.
51
Domeniul atributului reprezintă mulţimea de valori care pot fi
atribuite acestuia.
Un atribut simplu este compus dintr-o singură componentă, cu
existenţă independentă.
Un atribut compus este format din mai multe componente, fiecare cu
existenţă independentă.
Un atribut cu o singură valoare conţine o singură valoare pentru o
singură entitate.
Un atribut cu valori multiple deţine mai multe valori pentru o singură
entitate.
Un atribut derivat are o valoare derivabilă dn valoarea altui atribut
sau mulţimi de atribute, care nu sunt neapărat ale aceleiaşi entităţi.
O cheie candidat este un atribut sau set de atribute care identifică în
mod unic apariţiile individuale ale unui tip de entitate.
O cheie primară este o cheie candidate aleasă pentru o entitate.
O cheie compusă este o cheie candidat care constă din două sau mai
multe atribute.
Un tip de relaţie este un set de asociaţii, toate cu un acelaşi sens,
între tipuri de entităţi.
O relaţie este o asociere între entităţi, această relaţie cuprinzând o
entitate din fiecare tip de entitate ce participă în relaţie.
Gradul unui tip de relaţie este numărul de entităţi participante în
aceasta.
O relaţie recursivă conţine o aceeaşi entitate care participă de mai
multe ori în relaţie, cu roluri diferite. Numele de roluri sunt utilizate
pentru determinarea funcţiilor fiecărei entităţi participante într-o relaţie.
Raportul de cardinalitate descrie numărul de relaţii posibile pentru
fiecare entitate participantă.
Constrângerile de participare determină dacă existenţa unei entităţi
depinde de legătura sa cu o altă entitate, prin intermediul unei relaţii.
O capcană în evantai există acolo unde un model reprezintă o relaţie
între tipuri de entităţi, dar calea dintre anumite apariţii ale acestora este
ambiguă.
O capcană de întrerupere există acolo unde modelul sugerează
existenţa unei relaţii între tipuri de entităţi, dar nu există o cale între
anumite apariţii ale entităţilor.
52
 Descrieţi conceptele de bază ale modelului ER, şi reprezentarea
schematică a acestora.
 Descrieţi constrângerile ce pot fi impuse entităţilor participante
într-o relaţie.
 Descrieţi problemele ce pot apărea în crearea unui model ER.
1.5 Normalizarea
Atunci când proiectăm o BD pentru un SGBD relaţional, principalul

obiectiv la crearea unui model de date logic este reprezentarea corectă
a datelor, relaţiilor şi constrângerilor. Pentru acesta trebuie de
identificat un set de relaţii adecvat, ceea ce se realizează cu ajutorul
tehnicii de normalizare. Normalizarea este tratarea de jos în sus a
proiectării BD, care începe cu examinarea relaţiilor dintre atribute.
1.5.1 Scopul normalizării
Normalizarea este o tehnică de realizare a unui set de relaţii (a unei

mulţimi de tabele) cu proprietăţi (atribute) dezirabile, având în vedere
cerinţele organizaţiei.
Normalizarea este frecvent efectuată ca o serie e teste asupra unei

relaţii, pentru a stabili dacă aceasta satisface sau violează cerinţele unei
anumite forme normale. Se deosebesc: prima formă normală (1NF),
a doua formă normală (2NF), a treia formă normală (3NF), forma
normală Bryce-Codd (BCNF), a 4-a şi a 5-a formă normală (4NF, 5NF).
Toate formele normale se bazează pe dependenţele funcţionale dintre
atributele unei relaţii. Prin aplicarea testelor de normalizare, adică prin
normalizarea schemei relaţionale (vezi pct. 1.2.1.3) se previne apariţia
anomaliilor de reactualizare.
1.5.2 Redundanţa datelor şi anomaliile de reactualizare
Atributele trebuie grupate în relaţii (tabele) astfel încât să se

minimizeze redundanţa datelor şi să se reducă spaţiul de stocare
necesar relaţiilor de bază implementate.
53
Pentru stocarea în BD a informaţiilor referitoare la angajaţi şi filiale
comparăm două posibilităţi:
a) Crearea a două tabele, unul cu angajaţi (relaţia Personal) şi unul cu

filialele (relaţia Filiala):
Personal (Nr_Personal, NumeP, AdresaP, Functie, Salariu, Nr_Filiala)

Filiala (Nr_Filiala, AdresaF, Nr_Tel)
b) stocarea tuturor informaţiilor într-un tabel unic (Personal_Filiala):
Personal_Filiala (Nr_Personal, NumeP, AdresaP, Functie, Salariu,

Nr_Filiala, AdresaF, Nr_Tel).
În relaţia Personal_Filiala valorile atributelor referitoare la filială se

repetă pentru fiecare membru al personalului alocat unei anumite filiale.
Apar astfel date redundante, care pot crea probleme numite anomalii
de reactualizare, care sunt împărţite în:
- anomalii de inserare
- anomalii de ştergere
- anomalii de modificare.
Anomaliile de inserare
Există două tipuri de anomalii de inserare. Pentru a le ilustra

considerăm relaţia Personal_Filiala (cu date redundante).
- La inserarea unui nou membru al personalului, trebuie inserate
corect şi toate datele referitoare la filiala la care este alocat, date
aflate deja în alte rânduri din acelaşi tabel.
- La inserarea de date referitoare la o filială care nu are alocat încă
nici un membru de personal, trebuie de trecut Null-uri în celulele
pentru atributele personalului. Dar Nr_Personal fiind cheie primară,
încercarea de a introduce valoarea Null ar viola integritatea
entităţilor şi nu va fi permisă. Ca urmare nu poate fi inserată o
filială nouă fără personal alocat.
Aceste probleme se evită proiectând şi utilizând două relaţii distincte,
anume: Personal şi Filiala.
Anomaliile de ştergere
54
Dacă în relaţia Personal_Filiala o anumită filială apare o singură dată
(filiala are un singur membru de personal), atunci ştergerea acestui
membru de personal va duce la ştergerea şi a informaţiilor referitoare la
filiala respectivă.
Anomalii de modificare
Dacă reactualizăm de exemplu un număr de telefon al unei filiale din

tabelul Personal_Filiala, atunci acest număr va trebui de reactualizat în
acest tabel în toate rândurile în care apare filiala respectivă (rânduri
corespunzătoare diferiţilor membri ai personalului alocaţi filialei
respective).
Proprietăţile de uniune fără pierderi şi conservare a dependenţei
Relaţia Personal_Filiala este expusă anomaliilor de reactualizare şi

trebuie descompusă în două relaţii (tabele) distincte: Personal şi Filiala.
Descompunerea are două proprietăţi importante:

- Uniune fără pierderi: permite regăsirea oricărei instanţe din
relaţia iniţială în instanţele corespunzătoare ale relaţiilor mai mici.
- Conservarea dependenţei: permite impunerea unei constrângeri
asupra relaţiei iniţiale, prin impunerea unei constrângeri asupra
fiecăreia dintre relaţiile mai mici. Adică nu este necesară
efectuarea uniunii relaţiilor mai mici pentru a verifica dacă este
violată o constrângere asupra relaţiei iniţiale.
1.5.3 Dependenţe funcţionale
Conceptul de dependenţă funcţională este elementul central în procesul

de normalizare.
Dependenţă funcţională: descrie legăturile dintre atributele unei
relaţii. De exemplu, dacă A şi B sunt atribute ale relaţiei R, atributul B
este dependent funcţional de A (se notează A  B) dacă fiecărei valori a
atributului A îi este asociată exact o valoare atributului B (A şi B pot fi
formate din mai multe atribute fiecare).
55
Atunci când există o dependenţă funcţională, ea este specificată ca o
constrângere între atribute.
A  B: pentru o valoare dată a lui A (în toate rândurile din tabel unde
apare această valoare) se va găsi o singură valoare a lui B
Exemplu: A = atributul „localitate”; B = atributul „judeţ”. Deoarece A 

B (adică B este dependent funcţional de A), în fiecare rând din tabel
unde A are valoarea Codlea, B va avea valoarea Braşov.
Dependenţa dintre atributele A şi B poate fi reprezentată şi sub formă

de diagramă (fig. 1.29).
Determinantul unei dependenţe

funcţionale se referă la atributul din
partea stângă a săgeţii. Aici A este determinantul lui B.
Fig. 1.29. Diagramă de dependenţă funcţională
În relaţia Personal_Filiala există 13 dependenţe funcţionale cu următorii

determinanţi, înscrişi în stânga săgeţii:
Nr_Personal  NumeP;
Nr_Personal  AdresaP;
Nr_Personal  Functie;
Nr_Personal  Salariu;
Nr_Personal  Nr_Filiala;
Nr_Personal  AdresaF;
Nr_Personal  Nr_Tel;
Nr_Filiala  AdresaF;
Nr_Filiala  Nr_Tel;
AdresaF  Nr_Filiala;
AdresaF  Nr_Tel;
Nr_Tel  Nr_Filiala;
Nr_Tel  AdresaF;
Identificarea cheii primare a unei relaţii cu ajutorul dependenţei

funcţionale
56
Pentru a identifica cheia primară a relaţiei (tabelului) Personal_Filiala se
identifică întâi toate cheile candidat, adică acele atribute care identifică
în mod unic fiecare rând din relaţie.
Toate atributele care nu fac parte din cheia primară trebuie să fie
dependente funcţional de aceasta.
Ca urmare cheia primară va fi acel atribut (sau set de atribute) care
determină funcţional toate celelalte atribute ale relaţiei.
Cu alte cuvinte cheia primară va fi acel atribut (sau set de atribute) de
care sunt dependente funcţional toate celelalte atribute ale relaţiei.
În relaţia Personal_Filiala această cerinţă o îndeplineşte numai atributul
Nr_Pers.
1.5.4 Procesul de normalizare
Normalizarea este o tehnică formală de analizare a relaţiilor (tabelelor)

bazată pe cheile primare ale acestora şi pe dependenţele funcţionale.
Tehnica presupune o serie de reguli care pot fi utilizate pentru testarea
relaţiilor individuale, rezultând normalizarea bazei de date. Atunci când
o cerinţă nu este îndeplinită, relaţia care o violează trebuie descompusă
în relaţii care satisfac individual cerinţele normalizării.
Normalizarea se execută ca o serie de paşi corespunzători unei anumite

forme normale. Pentru modelul relaţional numai prima formă normală
(1NF) este de importanţă critică în crearea de relaţii adecvate. Toate
formele normale următoare sunt opţionale, dar pentru a evita
anomaliile de reactualizare se recomandă efectuarea normalizării până
la cel puţin forma normală 3NF.
Procesul de normalizare este ilustrat în figura de mai jos, unde se

demonstrează legătura dintre diversele forme normale. Unele relaţii în
1NF sunt şi în 2NF, unele relaţii în 2 NF sunt şi în 3NF ş.a.m.d.
57
Schema legăturilor dintre formele normale
1.5.5 Prima formă normală
Forma nenormalizată (UNF) este un tabel care conţine unul sau mai
multe grupuri repetitive.
Prima formă normală (1NF) este o relaţie în care intersecţia fiecărui
rând cu fiecare coloană conţine o singură valoare şi numai una.
Se presupune că datele sunt introduse prin intermediul unui formular.

Aceste date se transferă şi se stochează într-un tabel de formă
nenormalizată. Se identifică şi se elimină grupurile repetitive pentru a
aduce tabelul în prima formă normală (1NF).
Un grup repetitiv este un atribut sau grup de atribute dintr-un tabel

care are valori multiple pentru o singură apariţie a atributului
(atributelor) cheie primară al acelui tabel.
Există două tratări uzuale pentru eliminarea grupurilor repetitive din

tabele.
Prima tratare: se elimină grupurile repetitive prin introducerea datelor

adecvate în coloanele goale ale rândurilor care conţin date repetitive.
Exemplu: Se consideră un formular (fig. 1.30) pentru introducere în

baza de date a agenţiei imobiliare de „Detalii client-închiriere”. Pentru
simplificare se presupune că un client închiriază o anumită proprietate o
singură dată şi nu poate închiria mai mult de o proprietate în acelaşi
timp.
58
Fig. 1.30. Formularul „Detalii client-închiriere” al agenţiei imobiliare
Pentru cei doi clienţi datele transformate într-un tabel nenormalizat se

prezintă ca în fig. 1.31.
Fig. 1.31 Tabelul nenormalizat (UNF) Client_Inchiriere
Ca urmare există valori multiple la intersecţia dintre anumite rânduri şi

coloane. De exemplu pentru clientul John Kay există două proprietăţi:
PG4 şi PG 16.
Pentru a transforma tabelul în prima formă normală se elimină grupul
repetitiv, a.î. să existe o singură valoarea în fiacre celulă.
Conform primei tratări grupul repetitiv se elimină prin introducerea
datelor adecvate în fiecare rând. Tabelul (relaţia) va fi acum în 1NF (fig.
1.32).
59
Fig. 1.32. Relaţia Client_Inchiriere în prima formă normală (1NF)
În continuare se identifică cheile candidat, care pentru acest tabel vor fi

chei compuse:
(Nr_Client, Nr_Proprietate); (Nr_Client, InceputInchir) şi
(Nr_Proprietate, InceputInchir). Se selectează drept chei primară al
acestei relaţii setul de atribute: (Nr_Client, Nr_Proprietate); în fig. 1.32
ele au fost mutate a.î. să fie primele două coloane.
Acum relaţia Client_Inchiriere în 1NF este definită astfel:
Client_Inchiriere (Nr_Client, Nr_Proprietate, NumeC, AdresaP,

InceputInchir, SfarsitInchir, Chirie, Nr_Proprietar,
NumeP)
Relaţia este în 1NF, adică la intersecţia unui rând cu o coloană există o

singură valoare, dar are în acelaşi timp date redundante. Va trebui
trecută în 2NF, ceea ce nu este însă obiectul prezentului curs.
A doua tratare: se elimină grupul repetitiv prin plasarea într-o relaţie

separată a datelor repetitive, împreună cu o copie atributului cheie
iniţial (Nr_Client), aşa cum arată figura 1.33. Apoi se identifică o cheie
primară pentru noua relaţie.
60
Fig. 1.33 Relaţiile Client şi Prop_Inchir_Proprietar în 1NF
Formele celor 2 relaţii în 1NF rezultante sunt:
Client (Nr_Client, NumeC)

Prop_Inchir_Proprietar (Nr_Client, Nr_Proprietate, AdresaP,
InceputInchir, SfarsitInchir, Chirie, Nr_Proprietar,
NumeP)
Cum rezultă din fig. 1.33, ambele relaţii sunt în 1NF, deoarece la
intersecţia dintre fiecare rând şi fiecare coloană există o singură
valoare.
A doua relaţie prezintă o oarecare redundanţă a datelor şi poate suferi

anomalii de reactualizare. Se impune trecerea în 2NF.
1.5.6 A doua formă normală (2NF)
A doua formă normală se bazează pe conceptul de dependenţă

funcţională totală.
Dacă A şi B sunt atributele unei relaţii, atunci B este total dependent

funcţional de A, dacă B este dependent funcţional de A, dar nu de
orice submulţime adecvată a lui A.
O dependenţă funcţională A → B este totală, dacă prin eliminarea

oricărui atribut din componenţa lui A, dependenţa nu mai are loc.
61
O dependenţă funcţională A → B este parţială, dacă există un atribut
din componenţa lui A, care dacă este eliminat din A, dependenţa
funcţională se păstrează.
Exemplu de dependenţa funcţională parţială:
Determinantul A se compune din 2 atribute: Nr_Personal, NumeP.

Atributul determinat, dependent funcţional de A este B: Nr_Filiala.
A → B, deci: Nr_Personal, NumeP → Nr_Filiala.
Şi după eliminarea atributului NumeP din componenţa lui A,

dependenţa funcţională se păstrează:
NumeP → Nr_Filiala, deci dependenţa iniţială A → B este una parţială.
A doua formă normală (2NF) se aplică relaţiilor cu chei compuse (din

mai multe atribute).
Al doilea tabel din fig. 1.33 se află în 1NF şi are cheia primară compusă
din 2 atribute: Nr_Client, Nr_Proprietate. Tabelul este expus anomaliilor
de reactualizare. Dacă de exemplu trebuie de modifica valoarea chiriei
pentru proprietatea PG4 şi reactualizarea nu se face în fiecare rând în
care apare PG4, se pierde coerenţa bazei de date. Se observă că
atributul „Chirie” depinde funcţional numai de atributul „Nr_Proprietate”
şi nu de întreaga cheie primară compusă. (Adică, dacă se elimină
atributul Nr_Client din cheia primară, dependenţa funcţională
Nr_Proprietate → Chirie se păstrează).
Pentru a evita anomaliile de reactualizare tabelul trebuie de adus în

2NF.
A doua formă normală, 2NF (definiţie): O relaţie (tabel) în 1NF în

care fiecare atribut care nu este cheie primară este total dependent
funcţional de cheia primară (compusă) se află în 2 NF.
Trecerea din 1 NF în 2NF se face prin eliminarea dependenţelor parţiale.

Atributele identificate ca fiind parţial dependente de cheia primară se
plasează într-o nouă relaţie (tabel), împreună cu determinantul lor.
62
Se consideră tabelul Client_Inchiriere (fig. 1.32), având o cu cheie
primară compusă.

InceputInchir, SfarsitInchir, Chirie, Nr_Proprietar, NumeP)
În acest tabel există următoarele dependenţe funcţionale:
fd1 Nr_Client, Nr_Proprietate → Dependenţe totale de

InceputInchir, SfarsitInchir cheia primară
Nr_Client,
Nr_Proprietate
fd2 Nr_Client → NumeC Dependenţă parţială
de (unul din atributele
din) cheia primară
fd3 Nr_Proprietate → AdresaP, Chirie, Dependenţă parţială
Nr_Proprietar, NumeP de (unul din atributele
din) cheia primară
fd4 Nr_Proprietar → NumeP Dependenţă tranzitivă
fd5 Nr_Client, InceputInchir → Dependenţe totale
Nr_Proprietate, AdresaP, SfarsitInchir, de cheia candidat
Chirie, Nr_Proprietar, NumeP Nr_Client,
InceputInchir
fd6 Nr_Proprietate, InceputInchir → Dependenţe totale
Nr_Client, NumeC, SfarsitInchir de cheia candidat
Nr_Proprietate,
InceputInchir
Tabelul Client_Inchiriere nu se află în 2NF, deoarece s-au depistat

dependenţe parţiale ale unor atribute de (unul din atributele din) cheia
primară.
Observaţie: Dependenţa tranzitivă nu violează 2NF, deşi poate cauza

anomalii de reactualizare . Astfel de dependenţe sunt eliminate la
trecerea în 3NF.
Pentru a aduce tabelul în 2NF:
- atributele dependente parţial se mută într-un nou tabel, împreună cu

atributul lor determinant fd2, fd3):
63
Proprietar_Proprietate (Nr_Proprietate, AdresaP, Chirie,

Nr_Proprietar, NumeP)
- tabelul iniţial – sub alt nume - îşi păstrează cheia primară iniţială,
compusă, şi acele atribute care au dependenţă funcţională totală de
cheia primară (fd1).
Inchiriere (Nr_Client, Nr_Proprietate, InceputInchir, SfarsitInchir).
Relaţiile (tabelele) în 2NF derivate din relaţia (tabelul) Client_Inchiriere
1.5.7 A treia formă normală (3NF)
În tabelul Proprietate-Proprietar s-a identificat dependenţa tranzitivă

Nr_Proprietar → NumeP. Reactualizarea numelui unui proprietar (de ex.
Tony Shaw) trebuie făcută în fiecare rând în care acesta apare. În caz
contrar BD va deveni incoerentă. Ca urmare existenţa dependenţei
tranzitive poate cauza anomalii de reactualizare.
Aducerea unei relaţii (unui tabel) în 3 NF se referă la eliminarea

dependenţelor tranzitive.
Dependenţă tranzitivă (definiţie): Dacă A, B şi C sunt atributele

unei relaţii (unui tabel) şi A → B şi B → C, atunci C este dependent
64
tranzitiv de A prin intermediul lui B (cu condiţia ca A să nu fie
dependent funcţional de B sau C).
Se consideră de exemplu relaţia Personal_Filiala

Personal_Filiala (Nr_Personal, NumeP, AdresaP, Functie, Salariu,
Nr_Filiala, AdresaF, Nr_Tel).
Există (printre altele) următoarele dependenţe funcţionale:

Nr_Personal → Nr_Filiala şi Nr_Filiala → AdresaF
Deci dependenţa Nr_Personal → AdresaF are loc prin intermediul
atributului Nr_Filiala.
Această dependenţă este adevărată pentru că atributul Nr_Personal nu

este dependent funcţional de atributul Nr_Filiala sau de atributul
AdresaF.
A treia formă normală, 3NF (definiţie):

O relaţie (un tabel) în 1NF şi 2NF în care nici un atribut care nu este
cheie primară nu este dependent tranzitiv de cheia primară se află în
3NF
Ca exemplu consideră dependenţele funcţionale din relaţiile (tabelele)

de mai sus:

Nr_Client → NumeC
Inchiriere (Nr_Client, Nr_Proprietate, InceputInchir, SfarsitInchir)

Nr_Client, Nr_Proprietate → InceputInchir, SfarsitInchir
Nr_Client, InceputInchir → Nr_Proprietate, SfarsitInchir
Nr_Proprietate, InceputInchir → Nr_Client, SfarsitInchir
Proprietar_Proprietate (Nr_Proprietate, AdresaP, Chirie, Nr_Proprietar,

NumeP)
Nr_Proprietate → AdresaP, Chirie, Nr_Proprietar, NumeP
Nr_Proprietar → NumeP
Singura dependenţă tranzitivă identificată se află în relaţia (tabelul)

Proprietar_Proprietate:
Nr_Proprietar → NumeP,
65
sau mai exact: Nr_Proprietate → Nr_Proprietar → NumeP.
Celelalte 2 relaţii (tabelele „Inchiriere” şi „Client”) nu conţin dependenţe

tranzitive şi se află în 2NF, deci sunt considerate automat ca fiind în
3NF.
Tabelul „Proprietar_Proprietate” se aduce în 3NF prin eliminarea

dependenţei tranzitive:
- atributul determinat, dependent funcţional tranzitiv se mută în altă

relaţie (tabel), împreună cu determinantul său:
Proprietar (Nr_Proprietar, NumeP)
- tabelul iniţial – sub alt nume - îşi păstrează cheia primară iniţială, şi
acele atribute care au nu au dependenţă funcţională tranzitivă de cheia
primară:
Proprietate_de_Inchiriat (Nr_Proprietate, AdresaP, Chirie,
Nr_Proprietar)
Relaţiile (tabelele) 3NF derivate din relaţia (tabelul)

Proprietate_Proprietar
Cele 2 noi tabele se află în 3NF, deoarece nu conţin dependenţe

tranzitive ale unor atribute de cheia primară.
Relaţia „Client_Inchiriere” (fig. 1.32) aflată în 1NF:

InceputInchir, SfarsitInchir, Chirie, Nr_Proprietar, NumeP)
a fost supusă procesului de normalizare şi descompusă în 4 relaţii

(tabele) 3NF:
Inchiriere (Nr_Client, Nr_Proprietate, InceputInchir, SfarsitInchir)
66
Proprietate_de_Inchiriat (Nr_Proprietate, AdresaP, Chirie,
Nr_Proprietar)
Proprietar (Nr_Proprietar, NumeP)
Procesul de normalizare este ilustrat în figura de mai jos:
Descompunerea relaţiei (tabelului) 1NF: Client_Inchiriere în relaţii

(tabele) 3NF
Relaţia iniţială Client_Inchiriere poate fi recreată prin uniunea relaţiilor

(tabelelor) 3 NF rezultate în urma normalizării. Aceasta se realizează
prin mecanismul cheie primară – cheie străină.
De exemplu atributul Nr_Proprietar este cheie primară în relaţia

(tabelul) „Proprietar” şi cheie străină în relaţia (Tabelul)
„Proprietate_de-închiriat”.
Relaţiile (tabelele) sunt prezentate în figura de mai jos:
Relaţiile (tabelele) 3NF derivate din relaţia (tabelul) Client-Inchiriere

67
Normalizarea este o tehnică de realizare a unui set de relaţii cu
proprietăţi adecvate, avându-se în vedere cerinţele unei întreprinderi
privind datele. Normalizarea este o metodă formală, ce poate fi utilizată
pentru identificarea relaţiilor, bazându-se pe cheile şi dependenţele
funcţionale dintre atributele acestora.
Relaţiile cu redundanţă de date pot suferi din cauza anomaliilor de
reactualizare, care se clasifică în anomalii de inserare, ştergere şi
modificare.
Normalizarea este legată de conceptul de dependenţă funcţională,
care descrie legăturile dintre atributele unei relaţii. Dacă A şi B sunt
atribute ale relaţiei R, atributul B este dependent funcţional de A (A 
B) dacă fiecărei valori a atributului A îi este asociată exact o valoare
atributului B (A şi B pot fi formate din mai multe atribute fiecare).
Un determinant este orice atribut de care un alt atribut este total
dependent funcţional. Determinantul unei dependenţe funcţionale se
referă la atributul (grupul de atribute) din partea stângă a săgeţii.
Procesul de normalizare face ca relaţia să treacă prin diverse forme
normale. În fiecare etapă a normalizării se elimină caracteristici
indezirabile din relaţie, care o fac sensibilă la anomalii de reactualizare.
Forma nenormalizată (UNF) este un tabel cu unul sau mai multe
grupuri repetitive.
Prima formă normală (1NF) este o relaţie în care la intersecţia dintre
fiecare rând cu fiecare coloană apare o singură valoare.
A doua formă normală (2NF) este o relaţie (tabel) care se află în 1NF
şi în care fiecare atribut care nu este cheie primară este total dependent
de cheia primară. Dependenţa funcţională totală arată că dacă A şi
B sunt atribute ale unei relaţii (tabel), B este total dependent funcţional
de A dacă B este dependent funcţional de A, dar nu şi de orice
submulţime adecvată a lui A.
A treia formă normală (3NF) este o relaţie (tabel) care se află în 1NF
şi 2NF, în care nici un atribut care nu este cheie primară nu este
dependent tranzitiv de cheia primară. Dependenţa tranzitivă este
situaţia în care între trei atribute A, B şi C ale unei relaţii (tabel) există
dependenţele funcţionale: A → B şi B → C, adică C este dependent
tranzitiv de A prin intermediul lui B (cu condiţia ca A să nu fie
dependent funcţional de B sau C).
68
 Descrieţi scopul normalizării datelor.

 Descrieţi problemele ce decurg din redundanţa datelor.
 Descrieţi conceptul de dependenţă funcţională.
 Cum este legat conceptul de dependenţă funcţională de procesul
de normalizare?
 Definiţi prima, a doua şi a treia formă normală.
1.6 Metodologia de proiectare conceptuală a bazelor de date
Proiectarea unei baze de date cuprinde următorii paşi:

Pasul 1: proiectarea conceptuală
Paşii 2 şi 3: proiectarea logică
Paşii 4, 5, 6, şi 7: proiectarea fizică.
Proiectarea conceptuală a bazei de date este procesul de construire

a unui model al informaţiilor utilizate în întreprindere, independent de
consideraţiile de ordin fizic (SGBDul utilizat).
1.6.1 Pasul 1. Construirea modelului de date conceptual local

pentru fiecare vedere a utilizatorilor
De regulă vederea unui utilizator este o zonă funcţională a întreprinderii

(de exemplu producţia, marketingul, vânzările, resursele umane,
contabilitatea, aprovizionarea etc.). utilizatorul este o persoană reală
individuală sau un grup de persoane. identificarea vederilor utilizatorilor
se realizează prin examinarea diagramelor de flux şi prin chestionarea
utilizatorilor.
Modelul de date conceptual corespunzător vederii unui utilizator se

numeşte model de date conceptual local corespunzător vederii
respective. Fiecare model de date conceptual local cuprinde elementele
enumerate în tabelul de mai jos, din care se desprind sarcinile de
proiectare conceptuală.
Elemente ale Sarcini pentru construirea modelului

69
modelului de date conceptual local
conceptual local (Paşi)
Tipuri de entităţi 1.1. Identificarea tipurilor de entităţi (t.e.)
Tipuri de relaţii 1.2. Identificarea tipurilor de relaţii (t.r.)
Atribute 1.3. identificarea şi asocierea atributelor cu
t.e. şi t.r.
Domeniile atributelor 1.4. Determinarea domeniilor atributelor
Cheile candidat 1.5. Determinarea atributelor chei candidat şi
Cheile primare chei primare
1.6. Specializarea/generalizarea t.e. (opţional)
1.7. Desenarea diagramei ER
1.8. Revizuirea modelului conceptual local cu
utilizatorii
Pasul 1.1 Identificarea tipurilor de entităţi (t.e.)
Modalităţi de identificare:
- studierea specificaţiei cerinţelor utilizatorului referitor la funcţia
utilizatorului în întreprindere; se caută substantivele în specificaţia
cerinţelor utilizatorului (de exemplu Nr_Personal; NumeP;
Nr_Proprietate; AdresaP; Chirie etc.)
- se caută obiectele principale de interes, excluzându-se calităţile; se
grupează (de exemplu Nr_Personal şi NumeP vor aparţine aceluiaşi
tip de entitate Personal)
- se identifică obiectele care există pe cont propriu (de exemplu
Personal există indiferent de Nr_Personal, NumeP, etc.)
- discuţii cu utilizatorii (de exemplu pentru eliminarea sinonimelor:
Angajat = Personal)
Documentarea t.e.: după identificarea t.e. li se atribuie denumiri
evidente, care se trec într-un dicţionar de date.
Pasul 1.2 Identificarea tipurilor de relaţii (t.r.)

- Identificarea relaţiilor: de regulă relaţiile sunt indicate de expresii
verbale în specificaţia utilizatorului. De exemplu: filiale are
personal; personal administrează proprietate; chiriaş vizitează
proprietate etc. Interesează numai relaţiile dintre entităţi cerute.
Majoritatea relaţiilor sunt binare. Este bine de verificat fiecare
pereche de tipuri de entităţi, pentru a găsi o posibilă relaţie între
ele.
70
- Determinarea cardinalităţii (1:1; 1:M; M:N) şi constrângerilor de
participare (totală, parţială); eventual se specifică şi valorile limită
ale cardinalităţii.
- Documentarea tipurilor de relaţii. Pe măsură ce sunt identificate, li
se atribuie denumiri evidente; acestea, precum şi constrângerile se
trec în dicţionarul de date.
- Vizualizarea pe parcurs a t.e. şi t.r. identificate prin modelarea ER.
Pasul 1.3 Identificarea şi asocierea atributelor cu t.e. sau t.r.

- Identificare: Se caută substantive sau expresii substantivale în
specificaţia cerinţelor utilizatorilor care să caracterizeze t.e. şi t.r.
găsite. Atributele sunt proprietăţi, calităţi, caracteristici
identificatoare ale unei entităţi sau relaţii. Se deosebeşte între
atribute simple, compuse, derivate. Atributele derivate trebuie
reprezentate în modelul conceptual pentru a nu pierde informaţii.
- Documentarea atributelor: pe măsură ce sunt identificate li se
atribuit denumiri evidente şi semnificative pentru utilizatori. Pentru
fiecare atribut se trec în dicţionarul de date: denumirea, sinonime
sau aliasuri, tipul de date şi lungimea, eventuale valori prestabilite
(default value), dacă se acceptă Null-uri (required), dacă e compus
sau derivat, formula de calcul, dacă are valori multiple.
Pasul 1.4 Determinarea domeniilor atributelor

- Determinarea: Domeniul este un recipient de valori din care unul
sau mai multe atribute îşi iau valorile. De exemplu domeniul
numerelor de filială valabile este compus din 3 caractere, literă-
cifră-literă. Domeniul va include şi mulţimea valorilor permise,
dimensiunea şi formatul câmpului.
- Documentarea domeniului atributelor: se înregistrează denumirea
şi caracteristicile domeniilor atributelor în dicţionarul de date.
Pasul 1.5 Determinarea atributelor chei candidat şi chei primare

- identificare: pentru fiecare entitate se identifică toate cheile
candidat şi se secţionează dintre ele cheia primară. O cheie
candidat este o submulţime minimă de atribute ale unei entităţi,
care identifică în mod unic fiecare apariţie a acesteia. Cheia
primară aleasă va îndeplini următoarele criterii:
o va cuprinde un set minim de atribute
o va fi cheia candidat cu cea mai mică probabilitate de
modificare a valorilor
71
o va fi cheia candidat cu cea mai mică probabilitate de a-şi
pierde caracterul de unicitate
o va fi cheia candidat cu cele mai puţine caractere
o va fi cheia candidat cel mai uşor de utilizat d.p.d.v. al
utilizatorilor
Unei entităţi tari i se poate identifica o cheie primară, nu şi unei
entităţi slabe. Unei entităţi slabe i se poate identifica o cheie primară
numai prin plasarea în ea a unei chei străine, în cadrul relaţiei sale cu
entitatea tare.
Cheile candidat care nu sunt selectate cheie primară devin chei
alternative.
- Documentarea cheilor primare şi alternative prin înregistrare în
dicţionarul de date.
Pasul 1.6 Specializarea/generalizarea tipurilor de entităţi

(opţional)
Acest pas este dictat de reprezentarea cât mai clară a entităţilor

importante şi a relaţiilor dintre ele. Diagrama ER finală trebuie să fie cât
mai lizibilă.
Modelul ER din figura 1.34 a conţine entităţile Proprietate_de_Inchiriat
şi Proprietate_de_Vanzare. Se generalizează prin crearea entităţii
Proprietate (fig. 1.34 b.)
72
Fig. 1.34. Exemplu de generalizare a tipului de entitate
Entităţile Proprietate_de_Inchiriat şi Proprietate_de_Vanzare devin

subclase ale entităţii Proprietate în baza atributelor comune (Tipul,
Adresa, cheia primară) şi în baza relaţiilor comune asociate fiecăreia
(Proprietar_deţine_Proprietate).
Entităţile subclasă au şi atribute diferite (Chirie respectiv Preţ) şi relaţii
diferite (Inchiriaza respectiv Cumpara).
Pasul 1.7 Desenarea diagramei ER

Diagrama ER care se desenează va fi reprezentarea conceptuală a
vederii unui utilizator asupra întregii întreprinderi. Diagrama ER va
73
reprezenta modelul de date conceptual local bazat pe o anumită vedere
a utilizatorului asupra întreprinderii.
Pasul 1.8 Revizuirea modelului de date conceptual local

împreună cu utilizatorii
Acest pas este necesar pentru a garanta că modelul este o reprezentare
„adevărată” a întreprinderii d.p.d.v. al utilizatorului.
Proiectarea conceptuală a bazei de date este procesul de construire

a unui model al informaţiilor utilizate în întreprindere, independent de
consideraţiile de ordin fizic.
Proiectarea conceptuală începe prin crearea unui model de date
conceptual al întreprinderii, complet independent de detaliile de
implementare. Pentru fiecare vedere a utilizatorilor asupra întreprinderii
este creat un model de date conceptual local.
O vedere a utilizatorului constă în datele cerute de către un anumit
utilizator pentru a lua o decizie sau a efectua o anumită sarcină. De
regulă vederea unui utilizator este o zonă funcţională a întreprinderii.
Un utilizator poate fi o persoană sau un grup de persoane care
utilizează în mod direct sistemul.
Vederile utilizatorilor se pot identifica utilizând diagrame de flux de date
– care definesc zonele funcţionale şi eventual funcţiile individuale –
sau/şi prin chestionarea utilizatorilor, examinarea procedurilor,
rapoartelor şi observarea întreprinderii.
Fiecare model de date conceptual local cuprinde tipurile de entităţi,
tipurile de relaţii, atributele, domeniile atributelor, cheile candidat şi
primare.
Fiecare model de date conceptual local este susţinut de către o
documentaţie, cum ar fi dicţionarul de date, care este realizat pe
parcursul dezvoltării modelului.
- Descrieţi principalele faze implicate în proiectarea BD.

- Analizaţi rolul important al utilizatorilor în procesul de proiectare al
bazelor de date.
74
- Descrieţi principalul obiectiv al proiectării conceptuale a bazelor de
date.
- Descrieţi ce reprezintă o vedere a utilizatorului şi cum pot fi
identificate diferitele vederi.
- Identificaţi principalele sarcini asociate proiectării conceptuale a
bazelor de date.
- Identificaţi şi descrieţi scopul documentaţiei generate pe parcursul
proiectării conceptuale a bazelor de date.
1.7 Metodologia de proiectare logică a bazelor de date pentru

modelul relaţional
Proiectarea logică este procesul de construire a unui model al

informaţiilor utilizate în întreprindere pe baza unui anumit model de
date, dar independent de SGBD şi de alte consideraţii de ordin fizic.
1.7.1 Pasul 2. Construirea şi validarea modelului de date logic

pentru fiecare vedere a utilizatorilor
Acest pas este bazat pe modelul de date conceptual al vederii

utilizatorului asupra întreprinderii (realizat la pasul 1). Se efectuează
modificarea structurii modelului conceptual conform cerinţelor modelului
de date relaţional (conform cerinţelor caracteristice unui sistem de
gestionare relaţional).
Pasul 2.1 Transpunerea modelului de date conceptual local într-

un model de date logic local
Se rafinează modelul de date conceptual local prin eliminarea

caracteristicilor nedorite.
Pasul 2.1.1 Eliminarea relaţiilor de tip M:N
O relaţie M:N (de mai mulţi la mai mulţi) se descompune pentru a

identifica o relaţie intermediară. Relaţia M:N se înlocuieşte cu două
relaţii 1:M.
75
Exemplu: Relaţia Ziar Face Reclama Proprietate (fig. 1.35 a) este de
cardinalitate M:N, deoarece un ziar poate face reclamă mai multor
proprietăţi, iar unei proprietăţi i se poate face reclamă in mai multe
ziare.
Relaţia se descompune conform figurii 1.35 b, unde Reclama este o
entitate slabă a cărei existenţă depinde de existenţa celorlalte două
entităţi tari.
Fig. 1.35 Relaţia de cardinalitate M:N se descompune în 2 relaţii de

cardinalitate 1:M
Apar două tipuri de relaţii noi: Listeaza şi respectiv ReclamaIn care

leagă entitatea slabă de cele 2 entităţi tari. Analizaţi constrângerile de
participare din fig. 1.35 a şi 1.35. b!
Pasul 2.1.2 Eliminarea relaţiilor complexe
O relaţie complexă include cel puţin trei tipuri de entităţi. Ea trebuie

descompusă pentru a identifica o relaţie intermediară. Relaţia complexă
se înlocuieşte cu un număr corespunzător de relaţii binare de
cardinalitate 1:M.
În exemplul din figura 1.36 relaţia complexă Inchiriaza s-a descompus
în trei relaţii 1:M, anume Organizeaza, AsociatCu şi Ţine; s-a identificat
o entitate slabă: Acord_de_Inchiriere care este legată de entităţile tari
(iniţiale) prin cele trei relaţii binare de cardinalitate 1:M identificate.
Analizaţi constrângerile de participare din fig. 1.36 a şi 1.36. b!
76
Fig. 1.36. Relaţie complexă M:N descompusă în trei relaţii binare 1:M.
Pasul 2.1.3 Eliminarea relaţiilor recursive
Acesta este un tip particular de relaţie care trebuie descompusă pentru

a identifica o relaţie intermediară. În exemplul din figura 1.37 relaţia
recursivă Supravegheaza este eliminată prin identificarea unei relaţii
adiţionale denumită SupravegheatDe şi a unei entităţi slabe:
Personal_Alocat.
Analizaţi constrângerile de participare din fig. 1.37 a şi 1.37. b!
77
Fig. 1.37. Eliminarea unei relaţii recursive
Pasul 2.1.4 Eliminarea relaţiilor cu atribute
Atunci când o relaţie are asociat un atribut, acest lucru sugerează

existenţa unui tip de entitate neidentificat. Exemplul din figura 1.38 se
referă la determinarea numărului de ore lucrate de angajaţii temporari
atribuiţi fiecărei filiale. Relaţia LucreazaLa are atributul Ore-Lucrate şi
este de cardinalitate M:N. Se descompune în două relaţii binare de
cardinalitate 1:M. Acum atributul Ore_Lucrate aparţine noii entităţi
slabe identificate: Alocaţie_Filiala. Analizaţi constrângerile de participare
din fig. 1.38 a şi 1.38. b!
78
Fig. 1.38. Eliminarea unei relaţii cu atribut
Pasul 2.1.5 Eliminarea atributelor cu valori multiple
Este vorba de atribute cu mai multe valori pentru o singură entitate.

Acest atribut trebuie descompus pentru a identifica o nouă entitate.
Exemplul din figura 1.39 se referă la evidenţa filialelor, unde o filială
poate avea mai multe numere de telefon. Se identifică o nouă entitate:
Telefon, legată de entitatea Filiala prin relaţia Are.
Discutaţi posibilitatea
declarării entităţii
Telefon ca entitate
slabă şi a
constrângerii de
participare a entităţii
Filiala ca parţială.
Fig. 1.39. Eliminarea

atributelor cu valori
multiple
Pasul 2.1.6 Reexaminarea relaţiilor 1:1
Asemenea relaţii pot indica existenţa a două relaţii care să reprezinte

acelaşi obiect în cadrul întreprinderii. De exemplu entităţile Filiala şi
departament pot fi sinonime. În astfel de situaţii cele două entităţi se
79
îmbină, selectând una din cheile primare, dacă acestea nu coincid.
Cealaltă cheie primară devine alternativă.
Pasul 2.1.7 Eliminarea relaţiilor redundante
O relaţie este redundantă atunci când aceeaşi informaţie se poate

obţine şi prin alte relaţii. Trebuie deci de aflat dacă există mai mult
decât o singură cale între două entităţi. Dacă se identifică 2 căi, nu
înseamnă neapărat că una din relaţii este redundantă. Trebuie de ţinut
cont şi de semnificaţia temporală a relaţiilor.
În exemplul din figura 1.40

relaţia este neredundantă, deşi
există 2 căi intre entitatea
Copil şi Barbat. Tatăl ar putea
avea copii dintr-o căsătorie
precedentă, sau ar putea să nu
fie căsătorit cu mama copilului,
iar în figură se modelează
numai căsătoria curentă a
tatălui.
Fig. 1.40. Relaţie neredundantă!
Pasul 2.2 Extragerea relaţiilor (tipurilor de entităţi) din modelul

de date logic local
În urma pasului 2.1 s-a obţinut modelul de date logic local, ca urmare a
rafinării modelului de date conceptual.
La pasul 2.2. se extrag relaţiile pentru a reprezenta entităţile care le

compun. Componenţa fiecărei relaţii va fi descrisă utilizând un limbaj de
definire a bazelor de date (DBDL). Într-un DBDL apare denumirea
relaţiei, apoi între paranteze atributele simple. Se identifică cheia
primară, cheile alternative şi/sau cheile străine ale relaţiei. Se trece
relaţia care conţine cheia străină ca şi cheie primară.
80
Relaţia pe care o entitate o are cu altă entitate este exprimată prin
mecanismul cheie primară – cheie străină. Adică cheia primară din
entitatea părinte devine cheie străină în entitatea copil.
În continuare se prezintă cum relaţiile care reprezintă entităţile şi

relaţiile acestora sunt extrase din structurile de date posibile,
prezentate în modelul de date logic (fig. 1.41).
Fig. 1.41. Model de date logic
Din acest model de date logic se extrag:
a. Tipuri de entităţi tari:

Pentru fiecare entitate tare (obişnuită) se creează o relaţie care să
cuprindă toate atributele sale simple.
Exemplu: entitatea tare Personal
Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia,
Sex, Salariu)
Cheie primară Nr_Personal
b. Tipuri de entităţi slabe: Ruda_Apropiata.
81
Pentru fiecare entitate slabă se creează o relaţie care să cuprindă toate
atributele sale simple. În plus se include cheia primară a entităţii părinte
(sau proprietar) ca şi cheie străină.
Compoziţia acestei relaţii va fi:

Ruda_Apropiata (Nr_Personal, NumeR, Adresa, Nr_Tel, Rudenie)
Cheie primară Nr_Personal împreună cu NumeR
Cheie străină Nr_Personal se referă la Personal (Nr_Personal)
c. Tipuri de relaţii binare unu la unu (1:1)
În relaţia de cardinalitate 1:1 Personal Administreaza Filiala entitatea

părinte este Personal, deoarece are participare parţială. Ca urmare se
plasează o copie a cheii primare din Personal în Filiala, unde devine
cheie străină sub denumirea Nr_Personal_Manager.
Compoziţia acestor relaţii va fi:

Sex, Salariu)
Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)
Cheie primară Nr_Filiala
Cheie alternativă Nr_Tel sau Nr_Fax
Cheie străină Nr_Personal_Manager, care se referă la Personal
(Nr_Personal)
d. Tipuri de relaţii binare unu-la-mai-mulţi (1:M)
Pentru fiecare relaţie binară 1:M între entităţile E1 şi E2 se plasează o

copie a cheii primare din E1 în E2, unde devine cheie străină. Entitatea
aflată în partea notată cu „1” este entitatea părinte, iar cea din partea
cu „M” este entitatea copil. Întotdeauna cheia primară din entitatea
părinte devine cheie străină în entitatea copil.
Exemplu: Filiala Are Personal, unde Filiala este părinte iar personal
este copil.
Compoziţia acestor relaţii va fi:
82
Sex, Salariu, Nr_Filiala)
Cheie străină Nr_Filiala se referă la Filiala (Nr_Filiala)
Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)
Cheie primară Nr_Filiala
Cheie alternativă Nr_Tel sau Nr_Fax
Cheie străină Nr_Personal_Manager, care se referă la Personal
(Nr_Personal)
Pasul 2.2. se încheie cu documentarea relaţiilor şi atributelor chei

străine.
Compoziţia relaţiilor extrase din modelul de date logic se documentează
utilizând DBDL. Sintaxa poate fi extinsă pentru a exprima constrângerile
de integritate asupra cheilor străine (vezi pasul 2.6). Şi dicţionarul de
date trebuie reactualizat cu noile atribute cheie identificate la pasul 2.2
Pasul 2.3 Validarea modelului prin utilizarea normalizării
Normalizarea este o procedură de stabilire a atributelor care aparţin

împreună unui tip de entitate. Prin normalizare datele sunt organizate
conform dependenţelor lor funcţionale şi se elimină riscul anomaliilor de
reactualizare. În prima formă normală se elimină grupurile repetitive.
Pasul 2.4 validarea modelului conform tranzacţiilor utilizatorului
Modelul trebuie să accepte tranzacţiile cerute de către vederile

utilizatorului. Tranzacţiile se determină din specificaţiile cerinţelor
utilizatorilor. Prin folosirea diagramei ER, a dicţionarului de date şi a
legăturilor cheie primară/cheie străină prezentate în relaţii se încearcă
efectuarea manuală a tranzacţiilor.
Pasul 2.5 Desenarea diagramei ER
Se desenează varianta finală a diagramei ER, validată prin normalizare

şi conform cu tranzacţiile pe care trebuie să le accepte.
Pasul 2.6 Definirea constrângerilor de integritate
83
Prin impunerea de constrângeri se protejează baza de date faţă de
riscul de incoerenţă.
Se consideră 5 tipuri de integritate, anume referitoare la:
a. datele cerute
b. domeniile atributelor
c. integritatea entităţilor
d. integritatea referenţială
e. constrângerile întreprinderii
a. Datele cerute
Unele atribute nu admit Null-uri. În aceste situaţii se selectează
proprietatea de câmp required, care cere date pentru câmpul respectiv.
Se verifică dacă aceste constrângeri au fost identificate şi documentate
în dreptul atributelor în dicţionarul de date (vezi pasul 1.2)
b. Constrângerile privind domeniile atributelor

Se verifică dacă s-au identificat şi documentat la pasul 1.4
c. Integritatea entităţilor
Cheia primară a unei entităţi nu poate conţine Null-uri. Se verifică pasul
1.5
d. Integritatea referenţială
Se referă la relaţia entitate părinte – entitate copil. Se ştie că cheia

primară din părinte se copiază în copil unde devine cheie străină.
Integritatea referenţială înseamnă ca o valoare nenulă a cheii

străine din entitatea copil trebuie să se refere la (să coincidă cu)
o valoare existentă în entitatea părinte.
Dacă entitatea copil are participare totală în relaţie, nu sunt permise

Null-uri în câmpul cheie străină. Se admit atunci când entitatea copil are
participare parţială.
Asigurarea integrităţii referenţiale se realizează prin constrângeri de

existenţă. Acestea definesc condiţiile în care poate fi inserată,
reactualizată (modificată) sau ştearsă o cheie candidat sau o cheie
străină.
84
Se ia ca exemplu relaţia Personal Administrează Proprietate, de
cardinalitate 1:M.
Entitate părinte (Ep): Personal, cheie primară: Nr_Personal
Entitate copil (Ec): Proprietate, cheie străină: Nr_Personal, copie a cheii
primare din Personal.
Cazul 1. Inserarea unei apariţii în relaţia (entitatea) copil

Pentru a asigura integritatea referenţială se verifică dacă atributul
Nr_Personal din apariţia nou inserată în Ec este stabilit ca Null sau are o
valoare existentă în Ep.
Cazul 2. Ştergerea unei apariţii din relaţia (entitatea) copil

Se poate efectua fără probleme, nu afectează integritatea referenţială.
Cazul 3. Reactualizarea cheii străine în relaţia (entitatea) copil

Similar cazului 1.
Cazul 4. Inserarea unei apariţii în relaţia (entitatea) părinte

Se poate efectua fără probleme. Ep are participare parţială, deci poate
exista un membru al personalului care nu administrează o proprietate.
Cazul 5. Ştergerea unei apariţii din relaţia (entitatea) părinte.

Dacă apariţie care urmează a fi ştearsă din Ep îi corespunde o apariţie
(sau mai multe) din Ec, atunci integritatea referenţială se pierde prin
ştergere.
Posibile strategii de luat în considerare:
NO ACTION Blocarea ştergerii apariţiei din Ep, dacă are

corespondent(i) în Ec
CASCADE Dacă o apariţie în Ec se şterge, se şterg automat

corespondenţii din Ec. Dacă Ec acţionează ca Ep în altă
relaţie, ştergerea se propagă în cascadă.
SET NULL Când se şterge o apariţie din Ep, valorile cheii străine în
Ec sunt setate la Null. Are loc o reactualizare prin
setare la Null a valorilor atributelor selectate din cheia
străină a Ec. Această strategie se poate aplica numai
dacă atributele cheie străină acceptă Null-uri.
85
SET DEFAULT Când se şterge o apariţie din Ep, valorile cheii străine
corespunzătoare din Ec sunt setate la valori prestabilite
(default).
Exemplu: se şterge un membru al personalului în Ep
(Personal) şi automat proprietăţile pe care acestea le-a
administrat trecute în Ec (Proprietăţi) se setează la
atributul Nr_Pers la valoarea corespunzătoare
managerului.
NO CHECK Nu are loc nici o verificare de integritate. Când se

şterge o apariţie din Ep nu este garantată menţinerea
integrităţii referenţiale.
Cazul 6. Reactualizarea cheii primare în relaţia (entitatea) părinte

Dacă valorii reactualizate a cheii primare în Ep îi corespundeau una (mai
multe) valori ale cheii străine în Ec, integritatea referenţială este
pierdută. Se va aplica una din strategiile de la cazul 5.
e. Constrângerile întreprinderii
Sunt de fapt regulile de afaceri care pot uneori genera reactualizări ele
entităţilor. De exemplu agenţia imobiliară poate stabili ca un membru al
personalului să administreze maxim 10 proprietăţi.
Pasul 2.6. se încheie cu documentarea tuturor constrângerilor de
integritate. Aceasta se face în dicţionarul de date, pentru a fi luate în
considerare la implementarea fizică.
Pasul 2.7 Revizuirea modelului de date logic local împreună cu
utilizatorii
Se verifică dacă modelul de date logic local este o reprezentare
„adevărată” a vederii utilizatorului. Modelul de date logic local trebuie să
fie complet şi in întregime documentat. Modelul şi documentaţia se
revăd împreună cu utilizatorul.
1.7.2 Pasul 3. Construirea şi validarea modelului de date logic

global
86
În această etapă se construieşte un model de date logic global prin
îmbinarea modelelor de date logice locale individuale, care au fost
realizate pentru a reprezenta fiecare vedere a utilizatorilor.
După îmbinare trebuie rezolvate conflictele dintre vederi, ca şi orice
suprapuneri existente. Va rezulta o reprezentare a întregii întreprinderi
independentă de orice utilizator sau aplicaţie.
Pasul 3.1 Îmbinarea modelelor de date logice locale individuale

într-un singur model de date logic global al întreprinderii
(1) Revizuirea denumirilor entităţilor şi cheilor primare din

modelele locale.
Pot exista două sau mai multe entităţi care au aceeaşi denumire dar
sunt de fapt diferite, respective acre au denumiri diferite, dar sunt
aceleaşi. Se compară conţinutul de date al fiecărui tip de entitate.
Se utilizează cheile primare pentru a identifica tipurile de entităţi
echivalente, dar cu denumiri diferite.
(2) Revizuirea denumirilor relaţiilor. Se procedează ca la (1).
(3) Îmbinarea entităţilor din vederile locale
Îmbinarea entităţilor cu aceeaşi denumire şi aceeaşi cheie primară
(fig. 1.42)
Astfel de entităţi reprezintă de regulă acelaşi obiect în lumea reală.
La fuziune se includ atributele entităţilor iniţiale, eliminându-se
dublurile.
Fig. 1.42. Îmbinarea entităţilor cu aceeaşi denumire şi aceeaşi cheie

primară
87
În versiunea globală obţinută prin îmbinare s-a utilizat versiunea
descompusă a atributului Nume_Prenume (în urma consultării cu
utilizatorii).
Îmbinarea entităţilor cu aceeaşi denumire şi chei primare diferite

(fig. 1.43)
Astfel de entităţi nu au aceeaşi cheie primară, dar au chei candidat
similare. Rezultă aceeaşi vedere globală ca în fig. 1.42.
Fig. 1.43. Îmbinarea entităţilor cu aceeaşi denumire şi chei primare

diferite
Îmbinarea entităţilor cu denumiri diferite, cu chei primare similare

sau diferite
Astfel de entităţi se pot identifica atunci când: denumirile sunt
diferite, dar indică acelaşi scop, după cheia primară, după participarea
în anumite relaţii.
Exemplu: Entităţile Personal şi Angajaţi.
(4) Includerea (fără îmbinare) a entităţilor unice din fiecare

vedere locală
Toate entităţile care nu au echivalent se includ nemodificate în
modelul global.
(5) Îmbinarea relaţiilor din vederile locale

Se examinează toate relaţiile (denumire, scop, constrângeri
structurale) din toate vederile locale şi se elimină conflictele, prin:
- Îmbinarea relaţiilor cu aceeaşi denumire şi acelaşi scop, apoi
- Îmbinarea relaţiilor cu denumiri diferite dar acelaşi scop
88
(6) Includerea (fără îmbinare) a relaţiilor unice din fiecare vedere
locală
Relaţiile pentru care nu s-au găsit relaţii identice în alte vederi se
includ nemodificate în modelul global.
(7) Căutarea entităţilor şi relaţiilor lipsă

Identificarea entităţilor şi relaţiilor lipsă dintre diversele vederi ale
utilizatorilor şi care nu apar în nici una dintre vederi este o operaţiune
dificilă:
Acestea pot rezulta din modelul de date general, dacă există.
Când se consultă utilizatorii asupra unei anumite vederi, ei trebuie
rugaţi să examineze şi entităţile şi relaţiile din alte vederi.
Se examinează atributele fiecărui tip de entitate şi se compară cu
atributele entităţilor din alte vederi. Poate exista un atribut al unei
entităţi dintr-o vedere care corespunde unui atribut cheie primară,
cheie alternativă sau unui atribut simplu al unei entităţi din altă
vedere. Dintr-o astfel de corespondenţă rezultă existenţa unei relaţii
neidentificate, construibilă prin mecanismul cheie primară/cheie
străină.
(8) Verificarea cheilor străine

Se verifică dacă cheile străine din entităţile copil mai sunt corecte
şi se efectuează modificările necesare.
(9) Verificarea constrângerilor de integritate

Se verifică dacă constrângerile de integritate ale modelului global
nu intră în conflict cu constrângerile de integritate din vederile
utilizatorilor. Conflictele se rezolvă prin consultarea cu utilizatorii.
(10) Desenarea modelului de date logic global

Se desenează diagrama ER a modelului de date logic global, care
reprezintă îmbinarea tuturor modelelor de date logica locale.
(11) Reactualizarea documentaţiei

Documentaţia trebuie reactualizată în urma modificărilor
intervenite la realizarea modelului global. Documentaţia trebuie să
reflecte întotdeauna modelul de date curent.
Pasul 3.2 Validarea modelului de date logic global
89
Se realizează prin utilizarea normalizării şi conform tranzacţiilor
cerute, dacă este necesar. Este un pas echivalent cu 2.3 respectiv 2.4,
anume se fac aceleaşi validări dar acum pentru modelul de date logic
global.
Pasul 3.3 Verificarea în vederea dezvoltării locale

Se determină dacă este probabil ca în viitorul previzibil să apară
modificări şi se evaluează capacitatea modelului de date logic global
de a cuprinde aceste modificări. Modelul de date logic global trebuie să
poată fi extins cu uşurinţă. Modelul creat trebuie să fie extensibil, să
poată evolua în condiţiile afectării minime a utilizatorului. Se
incorporează modificări numai dacă utilizatorul o cere.
Pasul 3.4 Desenarea diagramei ER finale

Diagrama ER finală reprezintă modelul de date logic global al
întreprinderii. Se desenează după ce modelul de date logic global a
fost validat. Documentaţia (schema relaţională şi dicţionarul de date)
trebuie reactualizată şi completată.
Pasul 3.5 Revizuirea modelului de date logic global împreună

cu utilizatorii
Revizuirea va garanta faptul că modelul de date logic global este o
reprezentare „adevărată” a întreprinderii. Modelul împreună cu
documentaţia se revizuiesc în colaborare cu utilizatorii, pentru a
confirma că sunt corecte şi complete.
Proiectarea logică a bazelor de date este procesul de construire a

unui model al informaţiilor utilizate în cadrul unei întreprinderi, bazat pe
un anumit model de date, dar independent de un anumit SGBD şi de
alte consideraţii de ordin fizic.
Principalele etape cuprind: construirea şi validarea unui model de date
logic local corespunzător fiecărei vederi a utilizatorilor (pasul 2) şi
construirea şi validarea unui model de date logic global (pasul 3).
Rafinarea unui model de date conceptual pentru a obţine un model de
date logic include: eliminarea relaţiilor de tip M:N, a relaţiilor complexe,
90
recursive, cu atribute, a atributelor cu valori multiple, reexaminarea
relaţiilor de tip 1:1 şi eliminarea relaţiilor neredundante.
Modelul de date logic se validează prin normalizare, prin care se
garantează că modelul reprezintă fidel întreprinderea, este coerent, cu
redundanţă minimă şi stabilitate maximă.
Constrângerile de integritate se impun pentru a proteja BD faţă de a
deveni incoerentă. Există 5 tipuri de constrângeri de integritate: asupra
datelor necesare, ale domeniilor atributelor, de integritate a entităţilor,
de integritate referenţială şi ale întreprinderii.
Integritatea referenţială se asigură prin constrângeri de
existenţă, care definesc în ce condiţii poate fi o cheie candidata sau
străină inserată, reactualizată sau ştearsă.
Există mai multe strategii care pot fi aplicate atunci când o apariţie a
entităţii părinte pe care vrem să o ştergem are corespondent în
entitatea copil: NO ACTION, CASCADE, SET NULL, SET DEFAULT şi NO
CHECK.
Constrângerile întreprinderii se numesc uneori şi reguli de afaceri.
Modelul de date logic este susţinut de către documentaţie, cum ar fi
dicţionarul de date sau schema relaţională, care sunt realizate pe
parcursul construirii modelului.
 Analizaţi scopul proiectării logice a bazelor de date.

 Descrieţi etapele rafinării modelului de date conceptual pentru a se
obţine modelul de date logic
 Descrieţi regulile de extragere a relaţiilor care reprezintă tipuri de
entităţi tari şi slabe, tipuri de relaţii binare 1:1, 1:m.
 Analizaţi modul in care tehnica de normalizare poate fi utilizată
pentru a valida modelul de date logic.
 Descrieţi scopul constrângerilor de integritate şi arătaţi care sunt
cele 5 tipuri principale de constrângeri.
 Descrieţi strategiile alternative aplicabile atunci când există o
apariţie a Ec care se referă la o apariţie a Ep pe care vrem s-a
ştergem.
 Identificaţi sarcinile asociate cu îmbinarea modelelor de date logice
locale, pentru obţinerea modelului de date logic global.
91
1.8 Metodologia de proiectare fizică a bazelor de date pentru
bazele de date relaţionale
Proiectarea fizică a bazelor de date este procesul de descriere a

implementării bazei de date într-o capacitate de stocare secundară; se
descriu structurile de stocare şi metodele de acces utilizate pentru
asigurarea unui acces eficient la date.
1.8.1 Pasul 4. Transformarea modelului de date logic global

pentru un SGBD ţintă
Acest pas presupune transformarea relaţiilor extrase din modelul de

date logic global într-o formă care să poată fi implementată in SGBD
ţintă.
Este necesară cunoaşterea funcţionalităţii SGBD ţintă, de exemplu:
- dacă sistemul acceptă definirea cheilor primare, străine şi
alternative;
- dacă sistemul acceptă definirea datelor necesare (adică a unor
atribute ca fiind NOT NULL)
- dacă sistemul acceptă definirea domeniilor
- dacă sistemul acceptă definirea constrângerilor întreprinderii
- cum se creează relaţiile de bază.
Pasul 4.1 Proiectarea relaţiilor de bază pentru SGBD ţintă
Trebuie confruntate şi asimilate informaţiile referitoare la relaţii (tabele)

obţinute prin modelarea logică a datelor.
Aceste informaţii sunt obţinute din definiţia relaţiilor (în DBDL) şi din
dicţionarul de date.
Pentru fiecare relaţie identificată în modelul de date logic global vom

avea o definiţie formată din:
- denumirea relaţiei
- listă de atribute simple (între paranteze)
- cheia primară (PK), şi după caz, cheile alternative (AK) şi cheile
străine (FK)
- constrângerile de integritate corespunzătoare oricărei chei străine
(FK) identificate
92
Din dicţionarul de date, pentru fiecare atribut există şi:
- domeniul atributului, care constă din tipul de date, lungimea
acestora şi constrângeri asupra domeniului
- opţional, o valoare prestabilită a atributului
- dacă atributul poate conţine NULLuri
- dacă atributul este derivat, şi în acest caz cum trebuie calculat.
De exemplu în cazul BD a agenţiei imobiliare discutată, proiectul pentru

relaţia de bază (tabelul) Proprietate_de_Închiriat, în DBDL, pentru
implementarea cu ajutorului SGBD MS-Access este redat în figura de
mai jos.
93
Proiectul logic iniţial a fost adaptat funcţionalităţii SGBD ţintă (MS-
Access). În continuare sunt prezentate câteva exemple ale acestui
proces de adaptare (rafinare):
94
Atributul Proiectul logic Proiectul fizic pt. Explicaţii
MS-Access
Nr_Proprietate Şir variabil de Tip de date Text,
Access nu
(PK) caractere, max. 5 lungimea 5 deosebeşte
între şiruri de
caractere cu
lungime fixă
şi variabilă
Nr_ProprietarP Nr_Proprietar Nr_ProprietarP (FK) Access nu
(FK) → Nr_Proprietar din → Nr_Proprietar din acceptă ca o
Nr_ProprietarA „Proprietar_Privat” „Proprietar_Privat” aceeaşi FK
(FK) şi în totodată iar dintr-un tabel
Nr_Proprietar Nr_ProprietarA (FK) copil să bată
Admit NULLuri → Nr_Proprietar din → Nr_Proprietar din în 2 tabele
„Proprietar_Afacere” „Proprietar_Afacere” părinte
diferite
(integrit.
ref.)
Nr_Filiala (FK) Regula de Regula de MS Access
reactualizare: reactualizare: oferă doar:
CASCADE CASCADE Regula de
Regula de ştergere: Regula de ştergere: reactualizare:
SET DEFAULT NO ACTION CASCADE
Regula de
ştergere:
NO ACTION
MS Access nu
acceptă:
SET NULL şi
SET DEFAULT
Se trece la crearea bazei de date în MS_Access, pornind de la Blank

Database. Modul de creare a tabelelor (relaţiilor) în MS_Access este
detaliat în partea a doua a cursului. Mai jos este prezentată vizualizarea
de proiectare (Design View) a tabelului corespunzător relaţiei
Proprietate_de_Închiriat.
95
În cadrul tabelelor:
- se specifică cheia primară
- se setează proprietăţile câmpurilor: field size, format, input mask,
caption, default value, validation rule/text, required.
- Se creează liste de tip „lookup”, ca cea pentru tipul de proprietate:
O dată create toate tabelele proiectate, se realizează relaţiile dintre

acestea şi se impune integritatea referenţială.
96
Cascade Update Related Fields: modificarea unei valori din cheia
primară din tabelul părinte declanşează automat reactualizarea valorilor
corespunzătoare din toate înregistrările legate.
Cascade Delete Related Records: ştergerea unei înregistrări din tabelul

părinte duce la ştergerea tuturor înregistrărilor legate din tabelul copil.
Pasul 4.1 se încheie cu documentarea proiectului fizic prin DBDL .
97
Pasul 4.2. Proiectarea constrângerilor întreprinderii pentru
SGBD ţintă
Constrângerile întreprinderii, provenite din lumea reală, pot influenţa

reactualizările relaţiilor.
Exemplu: Un angajat nu poate administra mai mult de 10 proprietăţi.
Constrângerile trebuie reproiectate în funcţie de SGBD ales, respectiv
invers, SGBD se alege astfel încât să permită implementarea acestei
constrângeri.
Pentru Access implementarea constrângerilor de întreprindere se
realizează de exemplu cu limbajul Visual Basic, care lucrează cu baze de
date în Access.
1.8.2 Pasul 5. Proiectarea reprezentării fizice
Se determină organizarea fişierelor şi metodelor de acces utilizate

pentru stocarea relaţiilor de bază. Stocarea eficientă a datelor se
evaluează prin:
- transferul de tranzacţii: număr de tranzacţii prelucrabile în timp
- timpul de răspuns: timpul scurs până la încheierea unei singure
tranzacţii (de minimizat)
- capacitatea de stocare pe disc: spaţiul pe disc necesar stocării
fişierelor bazei de date (de minimizat).
Proiectantul trebuie să cunoască cele 4 componente hardware care
interacţionează şi afectează performanţele sistemului: memoria
principală, unitatea CPU, discul I/O, reţeaua.
Distribuirea datelor pe unităţile de disc se observă în figura 1.44.
Fig. 1.44. Configuraţia tipică a discului
Pasul 5.1 Analizarea tranzacţiilor

Pentru fiecare tranzacţie se determină:
- frecvenţa estimată cu care vor fi rulate tranzacţiile
98
- relaţiile şi atributele accesate de tranzacţie şi tipul de acces
(interogare, inserare, reactualizare, ştergere)
- constrângerile de timp impuse tranzacţiilor
În cazul BD a unei agenţii imobiliare se consideră – cu titlu de exemplu

– următoarele tranzacţii:
A: realizarea unui raport în care sunt enumerate proprietăţile de

închiriat din cadrul fiecărei filiale
B: crearea şi întreţinerea înregistrărilor referitoare la clienţii din cadrul
fiecărei filiale
C: enumerarea vizitelor efectuate de clienţi, cunoscând adresele
proprietăţilor vizitate
Hărţile de utilizare a tranzacţiilor
a) Harta cu modelul ER simplificat cu numerele estimate de

apariţii ale fiecărei entităţi
În colţul din stânga sus al fiecărei entităţi este trecut estimarea

numărului total de apariţii ale acesteia (numărul de înregistrări din
tabel). Se indică de asemenea valorile medii şi maxime ale apariţiilor
dintr-o entitate copil, asociate unei apariţii din entitatea părinte.
Astfel:
- În tabelul „Filiala” sunt înregistrate 50 de filiale.
o Unei filiale îi sunt alocate în medie 240 şi maxim 300
proprietăţi de închiriat.
99
o La o filială sunt înregistraţi în medie 400 şi maxim 500 de
chiriaşi.
- În tabelul „Proprietate_de_Închiriat” sunt înregistrate estimativ
12000 proprietăţi (50 filiale x 240 proprietăţi, în medie/filială).
o O proprietate de închiriat este vizitată (apare în „Vizitare”) în
medie de 20 şi maxim de 40 de ori.
- În tabelul „Chiriaş” sunt înregistraţi estimativ 20000 de chiriaşi (50
filiale x 400 chiriaşi în medie/filială)
o Un chiriaş efectuează în medie 10 şi maxim 20 de vizitări.
- În tabelul „Vizitare” sunt înregistrate estimativ 360000 vizitări
(12000 proprietăţi de închiriat x 30 vizitări /proprietate)
b) Harta căilor şi operaţiilor tranzacţiilor A, B şi C
În harta b) sunt afişate operaţiile de inserare (I), citire (C),

reactualizare (R) sau ştergere (Ş) împreună cu calea corespunzătoare
tranzacţiilor A, B şi C.
A: realizarea unui raport în care sunt enumerate proprietăţile de

închiriat din cadrul fiecărei filiale
Tranzacţia A deci necesită accesarea tabelului „Filiala” şi citirea (C) a
datelor din acest tabel. Prin intermediul atributului Nr_Filială (cheie
primară în Filiala şi cheie străină în Proprietate_de_Închiriat) se citesc
(C) proprietăţile de închiriat oferite de fiecare filială.
100
B: crearea şi întreţinerea înregistrărilor referitoare la clienţii din
cadrul fiecărei filiale
Tranzacţia B necesită inserarea (I) a clienţilor (chiriaşilor) înregistraţi în
tabelul „Chiriaş” şi în acelaşi timp la o anume filială, reactualizarea (R)
şi ştergerea (Ş) datelor referitoare la chiriaşi.
Pentru executarea tranzacţiei B se va accesa tabelul „Filiala”, iar prin
atributul Nr_Filială (cheie primară în „Filiala” şi cheie străină în
„Chiriaş”) se vor insera, citi, reactualiza sau şterge chiriaşii înregistraţi
la fiecare filială.
C: enumerarea vizitelor efectuate de clienţi, cunoscând adresele

proprietăţilor vizitate
Tranzacţia C necesită accesarea tabelului „Proprietate_de_Închiriat”,
punct de acces fiind atributul adresa proprietăţii, cunoscut. Prin atributul
Nr_Proprietate (cheie primară în „Proprietate_de_Închiriat” şi cheie
străină în „Vizitare”) se citesc (C) vizitelor efectuate la acea proprietate.
De asemenea se pot înregistra şi ziua şi ora estimată la care va fi rulată

fiecare tranzacţie, inclusiv momentul sau intervalul de încărcare
maximă. Pentru tranzacţiile care accesează frecvent baza de date,
modelul lor de execuţie se documentează ca în cazul exemplului de mai
jos, referitor la tranzacţia D:
D: căutarea proprietăţilor de închiriat oferite de o anumită

filială, care satisfac un anumit tip de proprietate cerut de un
potenţial chiriaş.
101
Singurele operaţii necesare pentru tranzacţia D sunt de citire (C),
documentate în figura de mai sus. Atributele utilizate ca puncte de
acces, de intrare sunt notate cu (P).
În cadrul tranzacţiei D se accesează tabelul „Filiala”, punctul de acces
fiind atributul cheie primară Nr_Filială, care se citeşte (C). Din tabelul
„Filiala”, prin mecanismul cheie primară-cheia străină (Nr_Filiala) se
citesc (C) în tabelul „Proprietate_de_Închiriat” datele referitoare le toate
proprietăţile oferite de o anumită filială. Atributul „Tipul” se utilizează ca
punct de intrare pentru interogare (clientul caută un anumit tip de
proprietate).
La accesarea unui număr de filială din „Filiala” se accesează tabelul
„Proprietate_de_Inchiriat” de 48 – 300 ori (există minim 48 de
proprietăţi din fiecare tip disponibile la o filială, şi o filială oferă maxim
300 de proprietăţi).
Analizând toate tranzacţiile (nu numai A, B, C, şi D exemplificate)

asupra întregii baze de date a agenţiei imobiliare se constată că foarte
multe tranzacţii necesită accesarea tabelului „Proprietate_de_Închiriat”.
Pasul 5.2 Alegerea organizării fişierelor

Se alege tipul adecvat de fişier, care poate fi: heap; hash; ISAM –
Indexed Sequential Access Method; arbore B+.
102
În majoritatea cazurilor SGBDurile bazate pe PCuri (de ex. MS-Access)
nu permit utilizatorului alegerea sau modificarea organizării fişierelor
din tabelele de bază.
Pasul 5.3 Alegerea indexurilor secundare

Trebuie de determinat dacă adăugarea de indexuri secundare
îmbunătăţeşte performanţele sistemului. Indexurile secundare oferă un
mecanism de specificare a unei chei adiţionale, pentru regăsirea mai
eficientă a datelor.
Exemplu: pentru entitatea Proprietate_de_Inchiriat se va indexa
cheia primară Nr_Proprietate (index primar) şi se poate constitui un
index secundar pentru atributul Chirie, ca fiind de interes.
Indicaţii referitoare la indexare:

- se indexează cheia primară
- nu se indexează relaţii mici
- se indexează cheia străină dacă e frecvent utilizată
- nu se indexează atribute frecvent reactualizate
- nu se indexează atribute cu şiruri lungi de caractere.
MS-Access indexează automat cheile primare şi cheile străine din

tabele.
În cazul interogării a mai multe tabele simultan (interogare de tabele

multiple) viteza de interogare poate fi mărită prin indexarea câmpurilor
din ambele părţi ale firului relaţiei (din ambele părţi ale uniunii) şi prin
indexarea câmpurilor pentru care se utilizează criterii de interogare. De
103
exemplu în tabelul „Proprietate_de_Închiriat” se vor indexa câmpurile
frecvent interogate „tipul” şi „zona”.
Este indicat să se creeze numai indexuri care se presupune că vor

îmbunătăţi performanţele sistemului, deoarece întreţinerea indexurilor
încarcă suplimentar resursele, ceea ce ar putea avea ca rezultat final
scăderea vitezei sistemului.
Crearea indexurilor secundare se documentează, împreună cu motivaţia

pentru care au fost considerate necesare.
Pasul 5.4 Considerarea introducerii unei redundanţe controlate

Trebuie de determinat dacă introducerea de redundanţă controlată prin
relaxarea normalizării (denormalizare) duce la îmbunătăţirea
performanţelor sistemului. Datorită denormalizării implementarea BD
este mai dificilă, scade flexibilitatea BD, se pot accelera regăsirile dar se
încetinesc reactualizările.
Pasul 5.4.1 Considerarea datelor derivate

Valorile atributelor derivate pot fi calculate din valorile altor atribute.
Stocarea unui atribut derivat în BD duce la:
- costuri suplimentare de stocare şi menţinere a concordanţei
datelor derivate cu datele operaţionale din care au fost derivate;
- costuri de calculare a datelor derivate de fiecare dată când este
necesar.
Exemplu: Entitatea Personal poate conţine un nou atribut derivat

(Nr_Proprietati) care arată câte proprietăţi administrează fiecare
membru al personalului. Valoarea acestui atribut se derivă din entitatea
Proprietate_de_Inchiriat, după atributul NrPer (fig. 1.45).
104
Fig. 1.45. Relaţia Personal simplificată cu atributul derivat Nr_Proprietăţi
Dacă BD este interogată frecvent asupra numărului de proprietăţi

administrate de fiecare membru al personalului poate fi util de stocat
acest atribut derivat în relaţia (entitatea) Personal.
Exemplu:
Tranzacţia E: Enumerarea numărului proprietăţii, oraşului, tipului, chiriei
şi avansului pentru închiriere (conform regulilor de afaceri: avansul = 2
x chiria).
Interogarea trebuie să cuprindă toate câmpurile cerute plus un câmp

calculat (derivat) pentru „avans”. Pentru a evita rularea repetată a
interogării, se preferă adăugarea unui câmp suplimentar în tabelul de
bază, „Proprietate_de_Închiriat”, câmp numit „Avans”, unde se trece
avansul pentru fiecare proprietate, calculat de operatorul uman la
înregistrarea sau actualizarea proprietăţii respective.
Deci la executarea tranzacţiei E nu mai trebuie calculat (prin rularea
interogării) avansul pentru fiecare proprietate.
105
Pasul 5.4.2 Considerarea dublării atributelor sau grupării
(uniunii) relaţiilor
Există situaţii în care se dublează anumite atribute sau se grupează

relaţii pentru a reduce numărul de uniuni necesare pentru efectuarea
unei interogări.
Pentru evitarea redundanţei, prin normalizare relaţia

Filiala (Nr-Fil, Strada, Zona, Orasul, CodP, Nr_Tel, Nr_Fax)
se descompune în două relaţii:
Filiala (Nr_Fil, Strada, CodP, Nr_Tel, Nr_Fax)

106
Cod_Postal_Filiala (Nr_Fil, CodP, Zona, Orasul)
Astfel la introducerea unei filiale noi nu trebuie de repetat toate

informaţiile legate de oraş.
Totuşi se întâmplă rar să dorim să accesăm adresa filialei fără atributele
corespunzătoare zonei şi oraşului. Păstrând atributele oraşului într-o
relaţie separată înseamnă că, ori de câte ori dorim adresa completă a
filialei, trebuie de efectuat uniunea celor 2 relaţii.
Ca urmare se optează pentru o denormalizare şi se păstrează prima
variantă a relaţiei, deşi conţine date redundante.
Exemplu: Tranzacţia F: a se enumera pentru fiecare proprietate

numărul proprietăţii, strada, oraşul, împreună cu numărul de personal şi
numele angajatului responsabil pentru administrarea proprietăţii
respective.
Se realizează o interogare pe tabele multiple, adică o grupare/uniune de

tabele (vezi figura de mai jos), pentru a include numele angajatului (din
tabelul „Personal”) în rezultatul interogării.
107
Pentru a evita rularea interogării de fiecare dată (necesitatea realizării
uniunii între cele 2 tabele), în tabelul „Proprietate_de_Închiriat” se
introduce o redundanţă controlată, anume câmpul „Nume” (care există
şi în tabelul „Personal”).
Pentru a garanta coerenţa în continuare a BD, se proiectează şi se

implementează un program de aplicaţie prin care orice modificare în
câmpul „Nume” în tabelul părinte „Personal” să se transmită în câmpul
„Nume” din tabelul copil „Proprietate_de_Închiriat”.
Pasul 5.4.3 Documentarea introducerii redundanţei
Orice redundanţă introdusă ulterior se documentează şi se motivează.

Modelul de date logic trebuie reactualizat, astfel încât să reflecte orice
modificări apărute prin denormalizare.
Pasul 5.5 Estimarea necesarului de spaţiu pe disc
Este obligatorie pentru stabilirea performanţelor hardware cerute pentru

implementarea bazei de date. Se determină astfel dacă pe moment sau
în viitor este necesare achiziţionarea de hardware mai performant.
1.8.3 Pasul 6. Proiectarea mecanismelor de securitate
Măsurile de securitate pentru baza de date trebuie să corespundă

cerinţelor utilizatorilor.
Pasul 6.1 Proiectarea vederilor utilizatorilor
108
În baza modelelor de date logice local se proiectează vederile
utilizatorilor. Vederile se creează în MS-Access prin interogări QBE, care
se bazează pe limbajul de interogare structurată SQL (Structured Query
Language).
Exemplu: Se doresc detalii referitoare la personalul agenţiei imobiliare,
vizibile pentru supervizorul organizaţiei, dar fără informaţii referitoare la
salarii.
In timp ce managerul organizaţiei vede relaţia de bază, completă:
Personal (Nr_Personal, Prenume, Nume, Adresa, Telefon, Sex, Functia,
Salariu, Nr_Filiala)
Cheie primară: Nr_Personal
Cheie străină: Nr_Filiala, se referă la relaţia, tabelul „Filiala” (cu cheia
primară Nr_Filiala).
În urma interogării selective QBE (implicit cu SQL) se generează

vederea:
Personal_VedereSupervizor (Nr_Personal, Prenume, Nume, Adresa,
Telefon, Sex, Functia, Nr_Filiala)
Cheie primară: Nr_Personal
Cheie străină: Nr_Filiala, se referă la relaţia, tabelul „Filiala” (cu cheia
primară Nr_Filiala).
Aceasta este o vedere pentru un utilizator cu permisiune de acces la
date limitată.
Vederea supervizorului, adică răspunsul la interogarea selectivă, se

poate edita (reactualiza). MS-Access va scrie reactualizările în tabelul
sau tabelele de bază care au fost interogate. Deci supervizorul are
dreptul la reactualizări asupra tabelului de bază Personal, cu excepţia
câmpului „Salariu”, utilizând interogarea selectivă QBE, respectiv
formular corespunzător interogării.
Figurile de mai jos arată vizualizarea de proiectare (Design View) a

interogării selective QBE (Query By Example) şi formularul realizat în
baza interogării, formular cu care lucrează supervizorul.
109
Pasul 6.2 Proiectarea regulilor de acces
De regulă utilizatorii nu au acces la relaţiile de bază, ci numai la vederile
create pentru ei. Administratorul de BD atribuie fiecărui utilizator un
identificator de autorizaţie care are asociată o parolă.
Fiecare instrucţiune SQL executată de către SGBD este efectuată în
numele unui anumit utilizator. Identificatorul de autorizaţie determină la
ce obiecte din BD se poate referi utilizatorul şi ce operaţii poate efectua
asupra acestor obiecte. Fiecare obiect creat în SQL are un proprietar
identificat prin identificatorul de autorizaţie. Proprietarul este singurul
care cunoaşte existenţa obiectului respectiv şi deci poate efectua
operaţii asupra lui.
110
Privilegiile sunt acţiunile pe care un utilizator are voie să le efectueze
asupra unei relaţii de bază sau vederi.
Instrucţiuni pentru acordarea privilegiilor:

SELECT: privilegiul de a regăsi date dintr-o relaţie
Când utilizatorul creează o relaţie folosind instrucţiunea Create Table din
limbajul SQL, utilizatorul de vine automat proprietarul noii relaţii cu
privilegii complete
GRANT: se acordă privilegii altor utilizatori asupra relaţiei nou create
REVOKE: revocă privilegii
CREATE VIEW: utilizatorul care creează vederea devine automat
proprietarul acesteia, dar nu neapărat cu privilegii complete, (ca la
SELECT)
Exemplu: pentru ca utilizatorul manager să regăsească rânduri din

relaţia Personal şi să insereze, să reactualizeze şi să şteargă date din
aceasta, să transmită privilegii utilizatori, se utilizează următoarea
instrucţiune SQL:
GRANT ALL PRIVILEGES
ON personal
TO manager WITH GRANT OPTION.
Exemplu: Utilizatorului cu identificatorul de autorizaţie ADMIN i se

acordă privilegiul SELECT pentru relaţia Personal, cu următoarea
instrucţiune SQL:
GRANT SELECT
ON personal
TO admin
MS-Access oferă două metode tradiţionale de securizare a BD:

- stabilirea unei parole a BD (pentru deschiderea BD)
- securitatea la nivel de utilizator (se limitează segmentele din BD
care pot fi citite sau reactualizate la nivel de utilizator)..
Stabilirea unei parole

Figura de mai jos arată caseta de dialog care solicită introducerea
parolei pentru deschiderea bazei de date.
111
O dată deschisă BD, toate obiectele (tabele, interogări, formulare etc.)
sunt puse la dispoziţia utilizatorului.
Securitatea la nivel de utilizator
Securitatea la nivel de utilizator este similară metodelor utilizate în

majoritatea sistemelor (softurilor) de reţele. Utilizatorului i se cere să se
identifice şi să scrie o parolă atunci când porneşte MS-Access. În cadrul
fişierului de informaţii al grupului de lucru (Workgroup Administrator)
utilizatorii sunt identificaţi ca membri ai unui grup. Access defineşte
automat grupurile Admin şi Users, dar pot fi definite şi alte grupuri.
Figura de mai jos ilustrează caseta de dialog pentru definirea grupurilor

şi conturilor de utilizator.
112
Figura de mai jos ilustrează caseta de dialog pentru acordarea
permisiunilor de utilizator şi de grup. Se reglementează modul în care se
lucrează cu fiecare obiect din BD.
Un control mai fin se realizează prin definirea de grupuri (conturi de
grup) noi, cărora li se acordă anumite permisiuni (de grup). Apoi se
adaugă utilizatorii care fac parte din acest grup, care au implicit toate
drepturile grupului din care fac parte, dar ale căror drepturi pot fi
modificate individual, astfel încât să fie mai multe sau mai puţine faţă de
grup.
Pasul 6.3 Documentarea proiectului măsurilor de securitate şi

vederilor utilizatorilor
Proiectarea vederilor individuale şi mecanismele de securitate trebuie

complet documentate. Dacă proiectul fizic afectează modelele de date
logice individuale, atunci şi aceste diagrame trebuie reactualizate.
1.8.4 Pasul 7. Monitorizarea şi reglarea sistemului operaţional
113
Obiectiv: Monitorizarea sistemului operaţional şi îmbunătăţirea
performanţelor acestuia, pentru a corecta deciziile inadecvate de
proiectare sau pentru a reflecta cerinţele în schimbare.
Reglarea din mers a bazei de date de către administratorul BD prezintă

anumite avantaje:
- se evită necesitatea procurării de hardware adiţional
- se poate micşora configuraţia hard
- timpul de răspuns scade, transferul devine mai eficient
- ca urmare cresc productivitatea întreprinderii, moralul angajaţilor
şi satisfacţia clienţilor.
Orice modificare de reglare poate în acelaşi timp îmbunătăţi o aplicaţie şi

strica alta. Este de dorit să se verifice/testeze întâi modificarea pe o
bază de date de încercare, sau atunci când sistemul nu este complet
utilizat (în afara orelor de lucru).
Presupunem că după câteva luni de utilizare a BD complet operaţionale

a agenţiei imobiliare au apărut din partea mai multor utilizatori ai
sistemului două noi cerinţe:
(1) Capacitatea de a păstra fotografii ale proprietăţilor de închiriat,

împreună cu comentariile care descriu principalele caracteristici ale
acesteia.
În MS-Access se introduc câmpuri cu tip de date (data type): OLE

(Object Linking and Embedded = legarea şi înglobarea de obiecte).
Acestea permit stocarea de date cum ar fi documente MS-Word sau MS-
Excel, figuri, sunete sau alte tipuri de date binare create în alte
programe. Obiectele OLE pot fi legate de sau înglobate într-un câmp
dintr-un tabel sau formular în Access şi pot fi afişate.
Tabelul Proprietate_de_Închiriat se va restructura astfel încât să

cuprindă un câmp numit „Vedere” cu tip de date OLE, şi un câmp numit
„Comentarii”, cu tip de date Memo, capabil de a cuprinde un text mai
lung.
Figura de mai jos ilustrează un formular care cuprinde cele două

câmpuri noi, formular bazat pe tabelul Proprietate_de_Închiriat.
114
Calea către imaginea/imaginile stocate pe hard disk se specifică în
design view al formularului (sau raportului sau paginii de acces) creat
după tabel.
(2) Capacitatea de a publica un raport care să disponibilizeze în

Internet proprietăţile de închiriat disponibile.
Această cerinţă se satisface prin crearea întâi a unui raport adecvat,

care să conţină câmpurile dorite pentru a fi vizualizate în Internet, după
care în baza acestui raport se realizează Pagina de acces la date. Pentru
ca pagina de acces la date creată să fie activată, este necesară legătura
la Internet şi un browser adecvat.
1.8.5 Rezumatul capitolului 1.8.
Proiectarea fizică a bazei de date reprezintă procesul de realizare a

descrierii implementării acesteia în capacitatea de stocare secundară.
Etapa iniţială (pasul 4) constă în transpunerea modelului de date
logic global într-o formă care să poată fi implementată în SGBD
relaţional ţintă.
115
Următoarea etapă (pasul 5): proiectarea organizării fişierelor şi
metodelor de acces care vor fi utilizate pentru stocarea relaţiilor de
bază. Aceasta presupune analizarea tranzacţiilor, alegerea organizării
adecvate a fişierelor, adăugarea de indexuri secundare, introducerea de
redundanţă controlată şi estimarea spaţiului necesar pe disc.
Indexurile secundare furnizează un mecanism de specificare a unei
chei suplimentare pentru o relaţie de bază, pentru regăsirea mai
eficientă a datelor.
Denormalizarea este o opţiune atunci când performanţele sistemului
nu sunt satisfăcătoare şi o relaţie are o rată de reactualizare scăzută şi o
rată de interogare foarte ridicată.
Baza de date trebuie prevăzută cu un mecanism de securitate (pasul
6). Măsurile de securitate necesare se identifică pe parcursul proiectării
logice. Ele se realizează prin crearea de vederi pentru utilizatori şi
utilizarea de mecanisme de control al accesului, scrise în limbajul SQL.
Etapa finală (pasul 7) din proiectarea fizică a BD constă în
monitorizarea şi reglarea neîntrerupte ale sistemului operaţional
pentru maximizarea performanţelor.
1.8.6. Întrebări la capitolul 1.8
 Explicaţie diferenţa dintre proiectarea conceptuală, logică şi fizică a

bazelor de date.
 Descrieţi scopul principalelor etape din metodologia de proiectare
fizică a bazelor de date.
 În ce condiţii se justifică denormalizarea unui model de date logic?
Utilizaţi exemple.
116

Baze de Date - TEORIE

Încărcat de

Informații document

Titlu original

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

Baze de Date - TEORIE

Încărcat de

Drepturi de autor:

Formate disponibile

Universitatea Transilvania din Braşov

Facultatea de Inginerie tehnologică

Şef lucr. dr. ing. Andrea DEACONESCU

1. Baze de date. Proiectare. Implementare. Gestionare......................5

Obiectivele acestui modul sunt:

1.1 Introducere în BD. Tratarea datelor. Sisteme de gestionare a

Cu siguranţă cei mai mulţi dintre Dvs. au o idee despre ce ar putea fi o

Exprimându-ne mai precis, atunci când utilizăm termenul de bază de

Un sistem de gestionare de bază de date (SGBD), sau database

1.1.2 Tratarea datelor prin sisteme bazate pe fişiere

Superioritatea administrării datelor dintr-o organizaţie cu ajutorul unui

Sistemul bazat pe fişiere este o colecţie de programe de aplicaţie

Exemplu: o firmă care furnizează componente pentru diferite

Rezultă următoarele limitări ale sistemelor bazate pe fişiere:

- Separarea şi izolarea datelor. Atunci când datele sunt izolate în

- Dublarea datelor. Din cauza modului de abordare descentralizat,

- Incompatibilitatea fişierelor. Este posibil ca fiecare compartiment

- Interogarea fixă sau proliferarea programelor de aplicaţie.

Limitările tratării datelor bazată pe fişiere au două cauze:

1.1.3 Tratarea datelor prin baze de date (BD)

Baza de date nu mai este deţinută de un singur compartiment al unei

O BD relaţională conţine entităţile, atributele şi relaţiile logice dintre

1.1.4 Sistemul de gestionare a bazei de date (SGBD)

SGBD este un sistem de programe care permite utilizatorului definirea,

SGBD constă în elemente de software care interacţionează cu

Un SGBD oferă o serie de facilităţi:

1.1.5 Componentele mediului SGBD

Mediul SGBD are cinci componente principale:

1.1.6 Proiectarea BD – schimbarea de paradigmă

Structura unei BD (entităţile, atributele, relaţiile) este determinată în

1.1.7 Poziţiile persoanelor din mediul BD

In acest paragraf se examinează a 5-a componentă a mediului SGBD,

BD şi SGBD sunt resurse comune care trebuie gestionate ca orice

Proiectanţii de BD logice: “ce anume?”

Etape de proiectare a BD logice:

Proiectanţii de BD fizice (“Cum anume?”) preia modelul logic şi

Odată realizată BD trebuie implementate programele de aplicaţie ce

Sunt clienţii pentru care a fost proiectată, implementată şi este

Utilizatorii simpli nu sunt conştienţi de SGBD. Accesează BD prin

Utilizatorii sofisticaţi sunt familiarizaţi cu structura BD şi facilităţile

1.1.8 Avantajele şi dezavantajele SGBD

1.1.8 Rezumatul capitolului 1.1

Sistemul de gestionare a bazelor de date (SGBD) reprezintă cadrul

Predecesorul SGBD a fost sistemul bazat pe fişiere. Acesta reprezintă

Un SGBD este un sistem de elemente software, care permite

Mediul SGBD constă din elemente hardware (calculatorul), de software

Avantajele tratării datelor prin BD includ: controlul redundanţei

1.1.9 Întrebări la capitolul 1.1

În cadrul modelului relaţional (ML) toate datele sunt structurate logic în

1.2.1.1 Structura relaţională a datelor

Relaţie: o relaţie este un tabel cu coloane şi rânduri.

Atribut Denumirea Sensul Domeniul de

Tuplu: Un tuplu este un rând dintr-o relaţie.

Termeni formali Alternativa 1 Alternativa 2

1.2.1.2 Relaţii matematice

Pentru a înţelege sensul termenului de relaţie revedem unele concepte

Orice submulţime a produsului cartezian este o relaţie:

1.2.1.3 Relaţii în bazele de date

Schema de relaţie: O denumire a relaţiei, urmată de un set (mulţime)

Astfel, o relaţie din modelul relaţional este o submulţime al produsului

1.2.1.4 Proprietăţile relaţiilor

1.2.1.5 Chei relaţionale

Supercheia: Este un atribut sau un set de atribute care identifică în