Sunteți pe pagina 1din 28

2.

Proiectarea bazelor de date


2.1 PROIECTAREA BD SCHIMBAREA DE PARADIGM
Structura unei BD (entitile, atributele, relaiile) este determinat n timpul proiectrii
BD. Abordarea proiectrii unei BD este diferit de cea a sistemelor pe baz de fiiere, unde totul
era dictat de nevoile aplicative ale departamentelor individuale. n cazul BD trebuie de
considerat nti datele apoi aplicaiile. Aceast schimbare a modului de tratare se numete
schimbare de paradigm.
Cauza principal a eecurilor sistemelor informaionale este lipsa aplicrii unei
metodologii de proiectare a BD n mod structurat. Astfel rezult BD ineficiente pentru cerinele
aplicaiilor, documentaia este limitat, ntreinerea dificil.
2.1.1 Poziiile persoanelor din mediul BD
n 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;
- proiectanii de BD;
- programatorii de aplicaii;
- 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
ntreinerea strategiilor i procedurilor bazei de date
- responsabil cu proiectarea conceptual/logic a BD
- consultarea i ndrumarea managerilor superiori cu privire la direcia de
dezvoltare a BD, a. BD s sprijine obiectivele generale ale organizaiei.
Administratorul de baze de date (DBA data base administrator) este responsabil cu
realizarea fizic a BD, avnd urmtoarele sarcini:
- proiectarea i implementarea BD,
- securitatea i controlul integritii BD,
- ntreinerea sistemului operaional,
- asigurarea de performane satisfctoare pentru aplicaii i utilizatori;
Rolul DBA este mai tehnic i necesit cunoaterea n detaliu a SGBD i a mediului acestuia.
Proiectanii de BD
Exist proiectani de BD logice i proiectani de BD fizice.

Proiectanii de BD logice: ce anume?


- se ocup cu identificarea datelor (entiti i atribute) i relaiilor dintre acestea, i
de constrngerile asupra celor care vor fi stocate n BD;
- trebuie s cunoasc foarte bine datele organizaiei i a regulilor de operare ale
organizaiei;
- trebuie s implice toi 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 aplicaie, limbajele de programare etc.)
b) proiectarea logic a BD, care se bazeaz pe un anumit model, de ex. relaional, ierarhic,
n reea, orientat pe obiecte.
Proiectanii de BD fizice (Cum anume?) preia modelul logic i stabilete realizarea fizic:
- transpunerea modelului logic de date ntr-un set de tabele i constrngeri privind
integritatea;
- selectarea de structuri de stocare i metode de acces specifice, a.. s se obin
performane bune ale datelor in activitile legate de BD;
- msuri referitoare la securitatea datelor.
Proiectarea fizic a unei BD trebuie s in cont de SGBDul avut n vedere; proiectantul trebuie
s cunoasc funcionalitatea acestui SGBD i avantajele i dezavantajele fiecrei variante de
implementare a BD. Strategia de stocare aleas trebuie s in cont de modul de utilizare.
Programatorii de aplicaii
Odat realizat BD trebuie implementate programele de aplicaie ce confer
funcionalitatea cerut de utilizatorii finali. Aceasta este sarcina programatorilor de aplicaii.
Fiecare program conine instruciuni care i cere SGBD s efectueze o operaie oarecare n BD
(extragere, inserare, reactualizare, tergere de date). Programele pot fi scrise ntr-un limbaj de
generaia a treia sau a patra.
Utilizatorii finali
Sunt clienii pentru care a fost proiectat, implementat i este ntreinut BD, pentru a le
satisface necesitile informaionale.
Utilizatorii simpli nu sunt contieni de SGBD. Acceseaz BD prin programe de aplicaie
speciale, simplificatoare. Ei folosesc comenzi simple, opiuni din meniu. Utilizatorul simplu nu
tie nimic despre BD sau SGBD (de ex. vnztorul care citete codul de bare pentru a afla preul
unui produs. Exist totui un program care citete codul de bare, caut preul articolului respectiv
n BD, modific cmpul cu stocul de articole, afieaz preul la cas).
Utilizatorii sofisticai sunt familiarizai cu structura BD i facilitile SGBD. Pot utiliza un limbaj
de interogare de nivel nalt (SQL). Pot scrie programe de aplicaie pentru uz personal.

2.2. O METODOLOGIE CLASIC DE DEZVOLTARE A APLICAIILOR


Pn acum am punctat importana datelor n sistemul informaional al organizaiilor,
nivelurile la care se poate aborda structura i coninutul unei baze de date, precum i locul
"stratului" date n aplicaiile informatice actuale. n acest capitol vom ncerca s ncadrm
activitatea (activitile) de proiectare a bazei de date n demersul mai larg al dezvoltrii de
aplicaii.
De la bun nceput trebuie precizat c subiectul paragrafului de fa constituie obiect de
studiu pentru cel puin dou domenii ale informaiei aplicate n organizaii, sau, mai bine spus,
ale sistemelor informaionale n organizaii. Mai nti, este vorba de ceea ce n literatura anglosaxona se numete software engineering, n francez genie logiciel, iar la noi dezvoltare de
aplicaii software. Este un domeniu conturat nc din anii '60 i aflat de atunci, cel puin dup
spusele marilor specialiti, ntr-o permanent criz, ce nu d semne de epuizare.
Al doilea domeniu este mai larg i intete mult mai mult dect realizarea de aplicaii,
dei aceasta reprezint totui un obiectiv central. Este vorba de analiza i proiectarea sistemelor
informaionale. Analiza i proiectarea se ocup, printre altele, i cu investigarea tuturor
proceselor, operaiunilor i tranzaciilor dintr-o firm sau instituie, cerinelor utilizatorilor i
perspectivelor organizaionale, astfel nct toate aceste aspecte s fie luate n calcul n realizarea
unui sistem informaional coerent, aliniat misiunii, obiectivelor i politicilor firmei. Cu alte
cuvinte, analiza i proiectarea pornesc mai din amonte, de la utilizatori, procese, tranzacii
economice, ncercnd s formalizeze/modeleze realitatea sub forma unei largi game de diagrame,
scheme, specificaii pe care le vor nainta realizatorilor modulelor de interfa, prelucrri i date.
Una dintre cele mai cunoscute scheme de realizare (dezvoltare) a aplicaiilor de lucru cu
baze de date sau, altfel spus, schema de principiu a ciclului de via al aplicaiilor cu BD este cea
rezentat n figura 2.1.
Amploarea activitilor din ciclul de via a unei BD depinde de anvergura aplicaiei.
Cnd sistemul dezvoltat vizeaz un numar redus de utilizatori i se refer la un ansamblu
de funcii nu din cale-afar de complex, multe etape sunt srite sau parcurse sumar.
Planificarea bazei de date
Planificarea BD presupune ealonarea pai1or ciclului de viat pentru atingerea unui
maximum de eficacitate. Ca i n cazul planificrii software-ului, planificarea BD presupune
identificarea i evaluarea activitilor ce trebuie derulate (ntreprinse), resurselor necesare
derulrii activitilor, fondului de timp, specialitilor i banilor disponibili. Planificarea BD
trebuie integrat n strategia de ansamblu a firmei, unul dintre obiectivele eseniale fiind
catalizarea activitilor, politicilor i strategiei unitii.

PlanificareaBD

Definireasistemului

Colectareaianalizacerinelor

ProiectareaBD
Proiectareaconceptual
Selectarea
SGBD

Proiectarealogic

Proiectarea
aplicaiei

Proiectareafizic

Prototipizare

Implementare
ncrcareai
conversiadatelor
Testare
ntreinereoperaional

Fig. 2.1 Ciclul de via a aplicaiilor ce utilizeaz baze de date

Definirea sistemului
Definirea sistemului presupune specificarea domeniului i granielor aplicaiei ce
lucreaz cu baza de date, utilizatorilor, aplicabilitii sale, precum i a celorlalte componente ale
sistemului informaional la care se va conecta noul subsistem.

Colectarea i analiza cerinelor


Aceasta etap implic adunarea i analiza cerinelor aplicaiilor din partea utilizatorilor.
Cerina reprezint o opiune, un element ce trebuie inclus, tratat n noul sistem. Proiectarea BD
se bazeaz pe informaii despre organizaii, informaii ce trebuie preluate i gestionate de baz.
Acestea pot fi culese n diferite moduri :
intervievarea personalului din ntreprindere, cu precdere a celor mai apropiai, prin
specificul activitii lor, de profilul aplicaiei, avndu-se n vedere acordarea unei atenii
mrite experilor din compartimentele funcionale considerate;
observarea modului de derulare a operaiilor n cadrul firmei ;
examinarea documentelor, n principal a celor purttoare de informaii (primare,
rapoarte) ;
folosirea chestionarelor pentru preluarea informaiilor de la un mare numr de
utilizatori;
utilizarea experienei acumulate la proiectarea unor sisteme similare.
Informaia culeas trebuie s includ: principalele domenii (zone) i grupuri de
utilizatori; documentaia utilizat sau generat de i despre aceste domenii/grupuri de utilizatori;
detaliile tranzaciilor reclamate de fiecare domeniu/grup; o list de cerine, pe prioriti a fiecrui
domeniu/grup.
Rezultatul acestei activiti l reprezint specificaiile cerinelor organizaionale,
prezentate, de obicei, sub forma unui set de documente n care sunt descrise, din diferite
unghiuri, operaiile ntreprinderii. De obicei, cerinele specificate se prezint ntr-o form puin
structurat i necesit transformarea utiliznd tehnici consacrate, cum ar fi cele de tip SAD Structured Analisys and Design (analiz i proiectare structurat), DFD - Data Flow Diagrams
(diagrame ale fluxurilor de date), diagrame HIPO - Hierarchical Input Process Output (ierarhice intrri-prelucrri-ieiri) etc.
Proiectarea bazei de date
Aceasta include proiectarea logic i fizic a BD. n urma acestei etape va fi elaborat
modelul BD care va constitui suportul obiectivelor i operaiunilor organizaiei. Principalele
obiective ale proiectrii BD sunt:
reprezentarea datelor i a relaiilor dintre date, formulare pe diferitele zone ale aplicaiei
i ale grupurilor de utilizatori ;
furnizarea unui model al datelor care s permit orice tranzacie autorizat asupra
acestora ;

construirea unui proiect care va atinge cerinele de performan ale sistemului, cum ar
fi: securitatea, timpul de rspuns etc.
Deseori ns, realizarea unui obiectiv se face n detrimentul altuia. Spre exemplu, un nivel
ridicat de securitate atrage dup sine scderea vitezei de rspuns.
Exist dou abordri majore ale proiectrii BD. Abordarea bottom-up pornete de la
nivelul elementar, cel al atributelor, care sunt grupate n clase de entitati i asociaii.
Normalizarea este un exemplu tipic de demers bottom-up, care d rezultate bune atunci cnd
numrul atributelor nu este prea mare.
Cnd numrul de atribute este ridicat, mai nimerit este abordarea top-down, care
dezvolt mai nti un model sintetic, simplificat al datelor. Cele cteva entiti sunt descompuse
ulterior n mai multe etape, pn la identificarea atributelor i entitilor elementare. Modelarea
folosind diagrame E-R are la baz abordarea top-down.
Exist i alte abordri ale proiectrii BD; spre exemplu, inside-out (de la interior ctre
exterior) seamn cu bottom-up, dar difer prin faptul c mai nti se stabilete un set de
concepte majore i apoi analiza se lrgete prin includerea n model i a altor concepte care se
afla n relatie cu cele majore. Strategia mixt utilizeaz deopotriv, pentru diferitele pri ale
modelului, i bottom-up, i top-down, combinnd rezultatele.
Dup cea mai mare parte a autorilor, proiectarea bazelor de date este de dou tipuri,
logic i fizic, n timp ce dup alii exist trei tipuri: conceptual, logic, fizic.

Selectarea sistemului de gestiune a bazei de date


Considerat un pas opional, selectarea SGBD presupune alegerea celui mai adecvat
SGBD pentru realizarea i exploatarea aplicaiei. Nu toate SGBD-urile satisfac cerinele
aplicaiei, iar, pe de alt parte, cele mai performante sunt i cele mai scumpe. Cerinele de
funcionalitate trebuie coroborate cu resursele disponibile, n vederea identificrii celui mai
adecvat SGBD comercial pentru realizarea i exploatarea aplicaiei.
Proiectarea aplicaiei
Proiectarea aplicaiei se refer la conceperea secvenelor de cod (instruciuni n limbaje
de programare) ce vor lucra cu baza. Din figura 2.1 se observ c proiectarea BD i proiectarea
aplicaiei sunt activiti distincte, paralele ale ciclului de via al aplicaiilor cu BD. n cea mai
mare parte a cazurilor, proiectarea aplicaiei nu poate fi finalizat nainte de proiectarea bazei. Pe
de alt parte, informaiile proiectrii vor fi transmise proiectrii BD.
n aceast etap trebuie verificat dac toate funciile specificate n cerinele utilizatorului
se regsesc n proiectul aplicaiei. Proiectarea aplicaiei include i activitatea de proiectare a

tranzaciilor. De asemenea, tot acum se elaboreaz i modelul interfeei cu utilizatorul a


aplicaiei.
Prototipizarea
Dei opional, prototipizarea se poate dovedi deosebit de util prin construirea unui
model de lucru iniial simplificat, model ce permite dezvoltatorilor i utilizatorilor s testeze i s
amelioreze incremental noua aplicaie. Un mare avantaj al prototipizarii este gradul mult mai
mare de acceptare a noului sistem la final, acesta fiind dezvoltat mpreun cu utilizatorii ce pot
s-i exprime pe parcurs doleanele. Etapele prototipizarii sunt descrise n figura 2.2.
Repetarede
cteorieste
necesar

Dezvoltarea
modeluluidelucru

Construirea
prototipului

Abandonarea
aplicaiei

Implementarea
aplicaiei
Decizie

Testareaiutilizarea
prototipului

Redezvoltarea
aplicaiei

Revizuirea
prototipului

Dezvoltareaunuinou
prototip

Fig. 2.2 Schema de principiu a prototipizrii


Implementarea
Implementarea presupune crearea definiiilor BD la nivelurile conceptual, extern, intern,
precum i punerea n lucru a programelor (aplicaiei), fiind realizat utiliznd limbajul de
definire a datelor (DDL) pus la dispozitie de SGBD-ul selectat. Implementarea aplicaiei se
realizeaz ntr-un mediu de programare utilizand un limbaj de tip 3GL sau 4GL.
Conversia i ncrcarea datelor
Acest pas este necesar atunci cnd sistemul (aplicaia) dezvoltat nlocuiete un altul.
Datele trebuie transferate din vechea aplicaie n cea nou, operaie ce implic de multe ori
schimbarea structurii fiierelor, a formatului, logic i fizic, al datelor, n concordan cu cerinele
7

noii aplicaii, dar i ale noului SGBD. Uneori sunt necesare (i posibile) i conversii ale unor
programe din vechiul n noul sistem. Majoritatea SGBD-urilor actuale au module de importexport din/n alte SGBD-uri. Conversia aplicaiilor este, n general, mult mai complex atunci
cnd se schimb limbajul/mediul de programare.
Testarea
Testarea este operaiunea sistematic de verificare a funcionalitii sistemului, a gradului
de adecvare la cerinele utilizatorilor. Prin testare, aplicaia este lansat n execuie, urmrindu-se
depistarea eventualelor erori i ameliorarea unor parametri precum viteza, securitatea etc.
Urmnd o metodologie riguroas, msurtorile din cadrul testrii dau posibilitatea evalurii
calitii i fiabilitii software-ului.
Este de preferat ca utilizatorii aplicaiei s fie pe deplin implicai n procesul testrii, iar
aplicaia testat s fie instalat pe un alt sistem dect cel pe care a fost conceput; n orice caz,
trebuie avut n vedere i un mecanism de recuperare a datelor corupte n caz de avarie.
Exist mai multe strategii de testare a corectitudinii i funcionalitii unei ap1icaii de
lucru cu BD ce pot fi aplicate individual sau combinate n cadrul aceluiai sistem:
top-down;
bottom-up;
fire de execuie ;
test de stres.
Testarea top-down ncepe de la nivelul superior al funciilor majore ale aplicaiei. Este
util n verificarea arhitecturii sistemului, reproiectrile majore fiind semnalate din primele
momente ale testrii.
Testarea bottom-up ncepe cu modulele elementare i continu pe vertical cu modulele
compozite pn la nivelul general al aplicaiei.
Testarea firelor de execuie este foarte important n sistemele de prelucrare n timp real,
n care sunt rulate simultan o serie de procese ce coopereaz. Acest tip de testare este mult mai
complex, fiind legat de detaliile tehnice ale sistemului de operare. Fiecarui proces i se aloc un
fir de execuie (thread) care este urmrit de la declanarea sa, acordndu-se o mare importan
punctelor de ntlnire cu celelalte fire executate pe sistem.
Testul de stres presupune suprasolicitarea bazei i aplicaiilor. Astfel, BD se ncarc
automat cu un numr extrem de mare de nregistrri, iar la aplicaie se conecteaz ct mai muli
utilizatori. Astfel se depisteaz pn la ce limite rezist aplicaia.

ntreinerea operaional
Aceast activitate se deruleaz pe toat durata de utilizare a aplicaiei. n afar de
monitorizarea BD, a programelor, de "curarea" periodica i repararea eventualelor erori
hard/soft, tot n aceast activitate sunt ncorporate operaiunile de actualizare a datelor i
programelor (ca urmare a unor noi oportuniti tehnologice), modificarea unor parametri
(procente TVA, impozite etc.). Monitorizarea performanei sistemului se realizeaz prin
raportarea la un nivel prestabilit de acceptare. Dac este cazul, o situare a performanei generale
sub acest punct critic poate antrena reorganizarea BD. Altminteri, chiar i n cazul funcionrii n
parametri normali, BD trebuie optimizat, avnd n vedere i facilitile oferite de SGBD.
ntreinerea i actualizarea aplicaiei sunt necesare n mai mare sau mai mic msur.
Spre exemplu, ntr-un mediu economic i legislativ dinamic, cum este cel din ara noastr,
deseori este necesar modificarea unor pri importante ale aplicaiei. Uneori, modificarea
presupune reluarea unora sau tuturor pailor din ciclul de via al aplicaiei de lucru cu BD.
2.2 PRIVIRE DE ANSAMBLU ASUPRA PROIECTRII BAZELOR DE DATE
Dei au fost publicate destule cri dedicate proiectrii bazelor de date, subiectul continu
s fie departe de epuizare. Chiar dac unii autori s-au strduit s aduc rigurozitate, uneori cu
preul unei anume rigiditi, proiectarea bazelor de date rmne preponderent o art i mai puin
o tiin. Problema proiectarii unei baze de date ine de elaborarea unei structuri logice i a alteia
fizice n vederea ntmpinrii nevoilor informaionale ale utilizatorilor ntr-o organizaie, pentru
un set definit de aplicaii.
Exist mai multe curente de idei n ceea ce privete proiectarea bazelor de date. Unul
dintre acestea mparte procesul de proiectare n dou direcii: modelarea logic a datelor i
proiectarea bazelor de date relaionale, definind modelarea logic a datelor ca procedur pentru
reprezentarea cerinelor informaionale ntr-un format corect, consistent i stabil, iar proiectarea
BD relaionale drept procedur de transformare a modelului logic al datelor ntr-o schem
relaional stabil. Aici apare o inadverten, considerndu-se c o schem relaional alctuit
din tabele i restriciile la care sunt supuse datele din tabele nu ar corespunde nivelului logic al
bazei de date, ci nivelului fizic. n aceast abordare, metodologia de modelare logica a datelor
(MLD) se deruleaza n 12 pai:
1. identificarea entitilor majore ;
2. determinarea relaiilor dintre entiti;
3. determinarea cheilor primare i alternative;
4. determinarea cheilor strine;
5. determinarea celor mai importante reguli organizaionale (key business rules) ;
6. adugarea celorlalte atribute (atributele non-cheie) ;
7. validarea perspectivelor utilizatorului folosind normalizarea ;
8. determinarea domeniilor (restriciilor asupra valorilor autorizate ale atributelor) ;
9

9. determinarea operaiunilor declanatoare (regulile care guverneaz efectele


modificrilor asupra atributelor i entitilor) ;
10. combinarea perspectivelor utilizatorului;
11. integrarea cu modelele de date existente ;
12. analiza stabilitii i dezvoltrilor ulterioare.
Este evident c, dei se separ artificial proiectarea logic a bazei de date de proiectarea
bazei de date relaionale, o parte dintre paii modelrii logice sunt raportai explicit la modelul
relaional. Perspectiva poate fi explicat prin faptul c, la nivelul anilor 80, modelul suveran n
materie de gestiune a bazelor de date era cel relaional (suveranitate manifestat din plin i
astzi), iar SGBD-urile ce puteau exploata baze de date obiectuale erau ca i inexistente.
Cea de a doua direcie, proiectare a bazei de date relaionale (PBDR), care continu
operaiunile derulate n MLD, presupune urmtorii pai:
1. identificarea tabelelor ;
2. identificarea atributelor;
3. adaptarea structurii datelor la specificul SGBD-ului folosit ;
4. inventarierea regulilor organizaionale privind entitile;
5. inventarierea regulilor organizaionale privind relaiile (asociaiile) dintre entiti ;
6. inventarierea regulilor adiionale despre atribute ;
7. optimizarea structurii n vederea unui mecanism de acces ct mai eficient ;
8. definirea secvenelor de "nmnunchiere" (clustering);
9. definirea cheilor pentru calcularea adreselor logice ale nregistrrilor n tabele (hash
keys) ;
10. adugarea indexurilor;
11. adugarea de date redundante;
12. redefinirea coloanelor;
13. redefinirea tabelelor.
Literatura de specialitate i practica se raporteaz ns preponderent la doar dou
componente majore ale proiectarii bazelor de date: proiectarea logica i proiectarea fizic. Din
acest punct de vedere, cele 12 etape din MLD i primele 6 din aa-numita PBDR ar corespunde,
n linii mari, proiectrii logice a bazei, n timp ce etapele urmtoare (7-13) din PBDR proiectrii fizice.
O alt abordare, structureaz ciclul de via al bazelor de date pe urmtoarele etape:
1. analiza cerinelor;
2. proiectarea logic, ce se materializeaz n schema global ce conine datele i relaiile
dintre ele, fiind derulat astfel :
a) modelarea E-R;
10

b) integrarea perspectivelor utilizator;


c) conversia diagramelor E-R n tabele;
d) normalizarea tabelelor ;
3. proiectarea fizic: selectarea indexurilor, metodelor de acces, cluster-elor de date; tot
aici, se include i denormalizarea;
4. distribuirea datelor, materializat n schema de fragmentare i schema de alocare a
datelor ;
5. implementarea, monitorizarea i modificarea ulterioar a bazei de date. i aici apar
dubii legate de modul de derulare a normalizrii (2.d), o dat ce prin conversia
diagramelor E-R se obin deja tabelele relaionale (2.c).
Ambele abordri sunt legate ndeosebi de paradigma relaional folosind n primele etape
modelul E-R, mai apropiat de lumea real.
Mai nou, proiectarea bazelor de date este privit pornind de la cele trei modele n vog
astzi: relaional, obiectual i relaional-obiectual. Din aceast perspectiv, procesul proiectrii
bazelor de date este prin excelen unul iterativ, incremental, ntr-o msura cu att mai mare cu
ct ne apropiem de obiectual. Fiecare iteraie se materializeaz ntr-o form a schemei bazei,
pornindu-se de la modelare, apoi trecndu-se de la proiectare la construcie (implementare). Cu
toate acestea, activitile principale ale ciclului de via al bazei de date nu difer prea mult, cel
puin la nivel general:
analiza cerinelor informaionale;
modelarea datelor ;
proiectarea i optimizarea bazei de date (proiectare logic i fizic) ;
testarea i revizuirea bazei ;
certificarea bazei de date;
ntreinerea i ameliorarea bazei.
Specific acestei dezvoltri este activitatea de certificare a bazei care se constituie ca un
fel de atestat de bun funcionare acordat bazei, atestat menit a ntri ncrederea beneficiarilor
bazei.
n alt idee recent se definesc trei componente ale proiectrii bazelor de date:
proiectarea conceptual, ce ine de construirea unui model informaional independent de orice
considerent privind aspectul fizic al datelor; proiectarea logic, ce const n construirea unui
model informaional pe calapodul unui model de date consacrat (E-R, relaional, OO, OR), dar
independent de tipul SGBD-ului ales i de celelalte aspecte fizice ale modelului; proiectarea
fizic, ce se materializeaz n implementarea efectiv a bazei pe suportul de stocare, inclusiv
aspecte ce in de asigurarea unui acces eficient i a securitii.
n acest curs, alegnd varianta mai simpl, cu cele dou tipuri de proiectare, logic i
fizic, vom discuta aproape exclusiv despre proiectarea logic.
11

2.3 CONSTRUIREA DE DIAGRAME ENTITATE-RELAIE


Prima etap pentru realizarea unei baze de date const n analiza sistemului. Se cunosc
mai multe tehnici de analiz, dar cea mai des ntlnit este tehnica entitate-relaie.
Prin tehnica entiate-relaie (denumit i entitate-asociere) se construiete o diagram
entiate-relaie (notat E-R) prin parcurgerea urmtorilor pai:
a) identificarea entitilor (componentelor) din sistemul proiectului;
b) identificarea asocierilor (relaiilor) dintre entiti i calificarea lor;
c) identificarea atributelor corespunztoare entitilor;
d) stabilirea atributelor de identificare a entitilor.
a) Identificarea entitilor
Prin entitate se nelege un obiect concret sau abstract reprezentat prin proprietile sale.
Prin convenie, entitile sunt substantive, se scriu cu litere mari i se reprezint prin
dreptunghiuri. ntr-o diagram nu pot exista dou entiti cu acelai nume, sau o aceeai entitate
cu nume diferite.
Pentru o baz de date din domeniul imobiliar, se pot pune n eviden urmtoarele
entiti:
DATE_PERSOAN entitate care stocheaz date personale ale ofertantului
(vnztorului) sau ale clientului (cumprtorului);
CERERI_ OFERTE conine ofertele sau cererile imobiliare propuse de vnztori,
respectiv cumprtori;
DESCRIERE_IMOBIL stocheaz informaiile referitoare la imobile;
JUDEE entitate ce conine judeele n care sunt amplasate imobilele;
LOCALITI - entitate ce conine localitile n care sunt amplasate imobilele;
STRZI - entitate ce precizeaz strzile n care sunt amplasate imobilele;
FACTURI formularul necesar unei tranzacii de cumprare-vnzare.
Figura urmtoare prezint o prim form a diagramei entitate-asociere (E-R).
DATE_
PERSOANA

FACTURI
LOCALITATI

CERERI_OFERTE
JUDETE
DESCRIERE_IMO
BIL

STRAZI

Fig. 2.3. Diagrama E-R pentru domeniul imobiliar (prima form)

12

b) Identificarea asocierilor dintre entiti i calificarea lor


ntre majoritatea componentelor (adic a entitilor) unui sistem economic se stabilesc
legturi (asocieri).
Exemplu: Exist o asociere ntre entitile CERERI_OFERTE i FACTURI deoarece facturile
reprezint finalizarea unei cereri/oferte. Aceast asociere se reprezint ca n figura de mai jos.
(1,1)

(0,1)

suntfinalizate

CERERI_OFERTE

FACTURI

prin

Fig. 2.4. Prezentarea asocierii dintre entitile CERERI_OFERTE i FACTURI


Sunt necesare precizarea ctorva notaii i noiuni utilizate n exemplul de mai sus:
legturile (asocierile) se reprezint prin arce neorientate ntre entiti;
fiecrei legturi i se acord un nume plasat la mijlocul arcului i simbolizat printr-un
romb (semnificaia legturii);
numerele simbolizate deasupra arcelor se numesc cardinaliti i reprezint tipul
legturii;
cardinalitatea asocierilor exprim numrul minim i maxim de realizri a unei entiti
cu cealalt entitate asociat.
Exemplu: Cardinalitatea (1,1) ataat entitii CERERI_OFERTA nseamn c o factur poate fi
rezultatul tranzacionrii a minim unei cereri/oferte i a unui numr maxim de tot o cerere/ofert.
Cardinalitatea (0,1) ataat entitii FACTURI nseamn c o cerere se poate finaliza prin maxim
o factur sau prin nici una (0 facturi) . Aceast cardinalitate reiese din analiz:
CERERI_OFERTE

FACTURI

1
2
3

F1
F2

Fig. 2.5. Determinarea cardinalitii asocierii dintre entitile CERERI_OFERTE i


FACTURI
Maximele unei cardinaliti sunt cunoscute i sub denumirea de grad de asociere, iar
minimele unei cardinaliti, obligativitatea participrii entitilor la asociere.
Tipuri de asocieri (legturi) ntre entiti
Asocierile pot fi de mai multe feluri, iar odat cu asocierea, se impune stabilirea
calificrii acesteia. Asocierea dintre entiti se face n funcie de
13

i)
cardinalitatea asocierii;
ii)
numrul de entiti distincte care particip la asociere.
i. Dup cardinalitatea asocierii
n funcie de maxima cardinalitii (gradul de asociere), se cunosc trei tipuri de asocieri,
care, la rndul lor, sunt de dou tipuri, n funcie de minima cardinalitii (gradul de obligativitate
al participrii la asociere):
asocieri de tip unu la unu;
o asocieri pariale de tip unu la unu
o asocieri totale de tip unu la unu
asocieri de tip unu la mai muli
o asocieri pariale de tip unu la muli
o asocieri totale de tip unu la muli
asocieri de tip muli la muli
o asocieri pariale de tip muli la muli
o asocieri totale de tip muli la muli.
ii. Dup numrul de entiti distincte care particip la asociere:
asocieri binare (ntre dou entiti distincte);
asocieri recursive (asocieri ale entitilor cu ele nsele);
asocieri complexe (ntre mai mult de dou entiti distincte).
n continuare se descriu asocierile grupate dup cardinalitatea ei.

Asocieri n funcie de cardinalitatea legturii


1.
Asocieri de tip unu la unu sunt asocieri n care maximele cardinalitii au
valoarea 1.

(...,1)

E1

(...,1)

E2

Fig. 2.6. Asociere de tip unu la unu


Exemplu: Asocierea din figura 2.5 este asociere de tip 1 la 1.
2.
Asocieri de tip unu la mai muli sunt asocieri n care maxima cardinalitii
unei entiti este unu, iar a celeilalte entiti are valoarea muli.

E1

(...,1)

(...,n)

E2

E1

(...,n)

(...,1)

Fig. 2.7. Asociere de tipul unu la mai muli


14

E2

Exemplu:
A

B
CERERI_OFERTE

LOCALITATI

L1
L2
L3

(1,1)

LOCALITATI

i
corespunde

1
2
3

(0,n)

CERERI_OFERTE

Fig. 2.8. Asociere de unu la mai muli ntre entitile LOCALITI i CERERI_OFERTE
3.
Asocieri de tipul muli la muli sunt asocieri n care maximele cardinalitii au
valoarea muli.

(...,n)

E1

(...,n)

E2

Fig. 2.9. Asociere de tipul muli la muli


Exemplu:
DEPOZIT

PRODUS

D1
D2
D3

(0,n)

P1
P2
P3

(0,n)
nmagazie

PRODUS

DEPOZIT

Fig. 2.10. Asociere de tipul muli la muli ntre entitile DEPOZIT


i PRODUS

15

Observaie: Uneori (n cazul utilizrii unor SGBD), asocierea de tip muli la muli se
transform n dou asocieri de tipul unul la muli fiind, de regul, mai uor de implementat i
de utilizat i anume:
(...,n)

Din

E1

(...,n)

(...,1)

E2

E1

(...,n)

A1

(...,n)

a)

(...,1)

A2

E2

b)

Fig. 2.11. Transformarea unei asocieri de tipul muli la muli (a)


n asocieri de tipul unu la muli (b)
Exemplu: n cazul exemplului de mai sus (vezi figura 2.10), transformarea asocierii muli la
muli n asocieri de tipul unu la muli se poate realiza prin construirea unei noi entiti
DEPOZIT_PRODUS astfel:
DEPOZIT_
DEPOZIT

PRODUS

PRODUS
(0,1)

asociaz

D1
D2
D3

(0,n)

(0,n)

D1P1
D1P3
D2P1
D3P4

asociaz

(0,1)

P1
P2
P3

Fig. 2.12. Transformarea asocierii de tipul muli la muli n asocieri de tipul unu la muli
Asocieri pariale i totale
Printr-o asociere parial se nelege o asociere n care nu exist obligativitatea
participrii la aceast asociere a tuturor entitilor vizate, ci numai a unora dintre ele sau a nici
uneia. Asocierea parial se caracterizeaz prin faptul c minima cardinalitii ataat unei
entiti este zero.
Observaii (asupra minimei cardinalitii)
minima cardinalitii este zero, are drept rezultat lipsa obligativitii participrii
partenerului la aceast asociere;
minima cardinalitii este mai mare dect zero, are drept rezultat obligativitatea
participrii.
(0,)

E1

(,)

(,)

E2

E1

a)

(0,)

E2
b)

Fig. 2.13 Asocieri pariale ntre entitile E1 i E2


16

Exemplu: Asocierea dintre entitile CERERI_OFERTE i FACTURI din fig. 2.5 reprezint o
asociere parial, deoarece participarea entitii FACTURI nu este obligatorie, minima
caracteristicii corespunztoare entitii CERERI_OFERTE fiind 0.
O asociere este total dac toate entitile au obligativitatea s participe la asociere, adic
minima cardinalitii este mai mare dect zero.
(1,)

(1,)

E1

E2

a)
(1,)

(n,)

E1

(n,)

E2

b)
(n,)

E1

(1,)

E1

c)
(n,)

E2

d)

Fig. 2.14 Asocieri totale ntre entitile E1 i E2


n continuare se dau cteva exemple de asocieri totale, respectiv pariale.
Exemplu: Asocieri pariale de tip unu la unu
CERERI_OFERTE

FACTURI

1
2
3

F1
F2

Exemplu: Asocieri totale de tip unu la unu


CERERI_OFERTE

DESCRIERE_IMOBIL

1
2
3

17

I1
I2
I3

E2

Exemplu: Asocieri pariale de tip unu la muli

CERERI_OFERTE

LOCALITATI

L1
L2
L3

1
2
3

Exemplu: Asocieri totale de tip unu la muli

ELEVI

CLASE

C1
C2
C3

E1
E2
E3
E4

Exemplu: Asocieri pariale de tip muli la muli


DEPOZIT

PRODUS

D1
D2
D3
D4

P1
P2
P3

Exemplu: Asocieri totale de tip muli la muli

STUDENTI
CURSURI

C1
C2
C3

S1
S2
S3
S4

Fig. 2.13 Asocieri dup gradul i obiectivitatea lor


18

n exemplul bazei de date AGENTIE_IMOBILIARA, tipurile de asocieri dintre entiti


stabilite n funcie de modul n care se desfoar activitatea modelat sunt:
JUDETE-LOCALITATI 1:n deoarece unui jude i corespund mai multe
localiti;
LOCALITATI-STRAZI 1:n - deoarece unei localiti i corespund mai multe
strzi;
STRAZI-CERERI_OFERTE 1:n deoarece unei strzi i pot corespunde mai
multe oferte/cereri;
FACTURI-CERERI_OFERTE 1:1 deoarece fiecare factur conine doar cte o
ofert/cerere;
CERERI_OFERTE-DECRIERE_IMOBIL 1:1 fiecrei cereri i se face o singur
descriere de imobil;
FACTURI- DATE_PERSOANA 1:1 o factur este ncheiat de o singur
persoan;
DATE_PERSOANA -CERERI 1:n o persoan poate lansa mai multe cereri sau
oferte de imobil.
c) Identificarea atributelor entitilor i a asocierilor dintre entiti
Atributele unei entiti reprezint proprieti ale acestora. Atributele sunt substantive, iar
pentru fiecare atribut i se va preciza tipul fizic (integer, float, char, string etc.)
Exemplu: Entitatea LOCALITI are urmtoarele atribute: codul localitii, notat cod_loc,
simbolul de identificare al judeului simbol_jude i denumirea localitii nume_loc.
d) Stabilirea atributelor de identificare a entitilor
Un atribut de identificare (numit cheie primar), reprezint un atribut care se
caracterizeaz prin unicitatea valorii sale pentru fiecare instan a entitii.
n cadrul diagramei entitate-asociere, un atribut de identificare se marcheaz prin
subliniere sau prin marcarea cu simbolul # plasat la sfritul numelui acestuia.

a#

(a)

E
(b)

Fig. 2.16. Notaii uzuale pentru atributele de identificare


Exemplu: Ca atribut de identificare putem considera codul numeric personal cnp pentru
entitatea DATE_PERSOAN.
Pentru ca un atribut s fie atribut de identificare, acesta trebuie s satisfac unele cerine:
ofer o identificare unic n cadrul entitii;
19

este uor de utilizat:


este scurt (de cele mai multe ori, atributul de identificare apare i n alte entiti, drept
cheie extern).
Pentru o entitate pot exista mai multe atribute de identificare, numite atribute (chei)
candidate. Dac exist mai muli candidai cheie se va selecta unul, preferndu-se unul cu valori
mai scurte i mai puin volatile.
-

Exemplu: n urma analizrii celor 4 etape necesare construirii diagramei entitate-asociere:


identificarea entitilor domeniului sau a sistemului economic;
identificarea asocierilor dintre entiti;
identificarea atributelor aferente entitilor i asocierilor dintre acestea;
stabilirea atributelor de identificare a entitilor,
se poate prezenta forma complet a diagramei asociate domeniului ales n exemplu.
(0,n)

STRAZI

areasociat

(1,1)

(0,n)

LOCALITATI

areasociat

(1,1)

JUDETE

(1,1)
seregsete
(1,n)

CERERI_
OFERTE
(1,1)

(1,n) conin

(1,1)

DATE_PERSOANA
(1,1)
incheie
(0,1)

(1,1)
finisate

(0,1)

FACTURI

conin
(1,1)

DESCRIERE
_IMOBIL

Fig. 2.17. Diagrama E-R pentru domeniul imobiliar (a doua form)


n cazul n care se dorete o diagram care s conin i atributele fiecrei entiti nsoite
de precizarea atributelor de identificare (adic a cheilor primare), pentru a nu ncrca imaginea,
diagrama proiectului se poate fragmenta pe mici domenii, dup cum este cazul entitii
OFERTE, prezentat n figura 2.18. (S-au considerat un numr relativ mic de atribute).

20

id_co#
tipul
cnp
data_inreg
cod_loc

CERERI_OFERTE

id_strada
nr_imobil
pret_min
pret_max
tip_solutionare

Fig. 2.18. Reprezentarea atributelor aferente entitii CERERI_OFERTE (detaliu dintr-o


diagram E-R)
n reprezentarea atributelor aferente entitii CERERI_OFERTE semnificaia atributelor
este urmtoarea: cheia primar a entitii id_co reprezint numrul de ordine al cererii sau
ofertei de imobil lansat de o anumit pesoan, atributul tipul specific dac este vorba de o
cerere sau de o ofert, prin cnp se precizeaz codul numeric personal al clientului,
data_inreg reprezint data la care s-a nregistrat oferta/cererea, apoi uremaz cteva date legate
de imobil: codul strzii id_strada, numrul imobilului nr_imobil, preul minim, respectiv
preul maxim al imobilului pret_min, pret_max. Ultimul atribut, tip_solutionare precizeaz
dac cererea/oferta respectiv a fost soluionat; pentru o cerere/oferta nou introdus, acest
atribut se va completa cu explicaia de nesoluionat.
Astfel, diagrama bazei de date AGENIE IMOBILIAR conine 7 entiti a cror
asociere a fost prezentat n figura 2.19.

21

DATE_PERSOANA

STRZI

LOCALITATI

JUDETE

cnp#

id_strada#

cod_loc#

simbol_judet#

numele

cod_loc#

simbol_judet

nume_judet

adresa

nume_str

nume_loc

nr_telefon
email
banca_client

CERERI-OFERTE

DESCRIERE_IMOB IL

nr_cont_client

id_co #

id_co#

tip

tip_imobil

cnp

etaj

data_inreg

nr_camere

tip_solutionare

suprafata

cod_loc

garaj

id_strada

centrala_termica

nr_imobil

termopane

FACTURI
nr_factura#
id_oferta
data_factura
cnp
pret
TVA
total

pret_min
pret_max

Fig. 2.19. Baza de date AGENIE IMOBILIAR- entiti i atribute

2.3.1 Reprezentarea constrngerilor de participare n diagramele E-R


Constrngerile de participare determin dac existena unei entiti depinde de legtura
sa de alt entitate prin intermediul unei relaii.

22

Exist dou tipuri de constrngeri de participare (a unei entiti ntr-o relaie):


participare total sau obligatorie (reprezentat printr-o linie dubl)
participare parial sau opional (reprezentat printr-o linie simpl).
Participarea unei entiti ntr-o relaie este total, dac existena unei entiti necesit
(este condiionat de) existena altei entiti prin intermediul unei anumite relaii. Altfel
participarea este parial.
Exemplu. n relaia binar FILIALA Este Alocat PERSONAL (fig. 2.20) o filial poate
exista, evident, numai dac are alocat personal. Deci existena entitii FILIALA este
condiionat de existena entitii PERSONAL. Ca urmare entitatea FILIALA va participa total
(obligatoriu) n relaia Este Alocat, i se va reprezenta cu linie dubl.

Nr.Filiala

FILIALA

Nr.Personal

EsteAlocat

PERSONAL

Conform regulilor de afaceri


ale organizaiei, pot ns
exista membri de personal
care nu sunt alocai unei
anumite filiale. Entitatea
PERSONAL va avea deci
participare
parial
(opional) n relaia Este
Alocat, i se va reprezenta cu
linie simpl.

Fig. 2.20. Constrngeri de participare

Nr.Filiala

FILIALA

Nr.Personal

(5,N)

EsteAlocat

(0,1)

PERSONAL

O reprezentare alternativ a
constrngerilor
de
participare rezult din fig.
2.21, unde pe liniile de
legtur
sunt
trecute
valorile minim i maxim
cu care pot participa
entitile n relaie.

Fig. 2.21 Constrngeri de participare, notaie alternativ


n cazul exemplului, o filial poate avea minim 5 i maxim nedefinit (N) angajai. Un
angajat poate s nu fie alocat unei filiale (valoare minim 0) sau s fie alocat unei filiale, i
numai uneia (valoare maxim 1).
23

2.3.2 Problemele modelului ER


n proiectarea unui model de date conceptual pot aprea aa-numite capcane de
conectare, datorit interpretrii eronate a sensului unei relaii.
2.3.2.1 Capcane n evantai
Capcanele n evantai sunt acele capcane de conectare care ntr-un model ER reprezint
o relaie dintre tipuri de entiti, dar cile dintre anumite apariii ale entitilor sunt ambigue.
SECIE
1

Estealocat

Capcanele n evantai apar cnd dou sau mai multe


relaii 1:M provin din aceeai entitate (fig. 2.22).

Coordoneaz

Din model nu rezult la ce filial este alocat un


anumit membru al personalului dintr-o secie,
tiind c o secie coordoneaz mai multe filiale.

PERSONAL

FILIALA

Fig. 2.22 Capcan n evantai


Examinm modelul la nivel de apariii individuale prin intermediul reelei semantice (fig.
2.23).
Entitile
PERSONAL
SA1
SA2
SA3

Relaia
Estealocat

Entitile
SECIE

r1
S1
r2
r3

S2

Relaia
Coordoneaz

Entitile
FILIALA

r4

F1

r5

F2

r6

F3

Fig. 2.23. Reeaua semantic a modelului ER din fig. 2.22


Se poate observa capcana n evantai: Angajatul SA1 este alocat seciei S1, dar secia S1
coordonnd filialele F1 i F3, nu se tie la care dintre aceste dou filiale este alocat SA1.
24

FILIALA
M

Capcana se rezolv prin restructurarea modelului


ER, a.. acesta s reprezinte corect asocierile dintre
entiti (fig. 2.24).

Coordoneaz

Estealocat

Se observ care secie coordoneaz care filiale, i ce


personal este alocat fiecrei filiale.

1
SECIE

PERSONAL

Fig. 2.24. Model ER restructurat


Reeaua semantic a modelului restructurat (corect) este cea din fig. 2.25.
Entitile
SECIE
S1

Relaia
Coordoneaz
r4
r5

S2

r6

Entitile
FILIALA
F1
F2
F3

Relaia
Estealocat
r1
r2
r3

Entitile
PERSONAL
SA1
SA2
SA3

Fig. 2.25. Reeaua semantic a modelului ER din fig. 2.24.


Angajatul SA1 este alocat filialei F1, coordonat de secia S1.
2.3.2.2 Capcane de ntrerupere
Capcanele de ntrerupere sunt acele capcane de conectare n care un model sugereaz
existena unei relaii ntre tipurile de entiti, dar nu exist ci ntre anumite apariii ale acestor
entiti.

25

Capcanele de ntrerupere apar cnd n calea prin care sunt legate entitile intervine o
entitate cu participare parial.
Exemplu. Din modelul din fig. 2.26 se observ urmtoarele:
Pe ramura din stnga:
unei singure filiale i sunt alocai mai muli angajai (relaie 1:M)
filiale exist numai dac are personal, fiecare membru al personalului este obligatoriu
alocat unei filiale (participri totale linii duble de legtur).
Pe ramura din dreapta:
-

Un angajat (membru al personalului) poate superviza mai multe proprieti, o proprietate


poate fi supravegheat de un membru al personalului (relaie 1: M)
Nu fiecare membru al personalului supravegheaz obligatoriu proprieti i nu toate
proprietile sunt supravegheate obligatoriu de un membru al personalului (participri
pariale linii simple de legtur).
PERSONAL

Estealocat

Din modelul din fig. 2.26 nu se poate deduce


ce proprieti sunt disponibile la care filiale.

Supervizeaz

1
FILIALA

Proprietate
denchiriat

Fig. 2.26 Capcan de ntrerupere

Modelul ER sugereaz existena unei relaii ntre entitile FILIALA i


PROPRIETATE_DE_NCHIRIAT, dar, aa cum rezult din reeaua semantic asociat (fig.
2.27) nu exist ci ntre anumite apariii ale entitilor.

26

Entitile
FILIALA

Relaia
Estealocat

Entitile
PERSONAL

r4

r1

F1
F2

r2

F3

r3

Relaia
Supervizeaz

Entitile
PROPRIETATE_
DE_NCHIRIAT

SA1

P1

SA2

P2
r5

SA3

P3

Fig. 2.27. Reeaua semantic a modelului ER din fig. 2.26.


Lipsa cilor ntre anumite apariii ale entitilor FILIALA i Proprietate_de_Inchiriat se
observ clar din reeaua semantic din figura 2.27.
Nu se poate deduce la ce filial este disponibil proprietatea P2.
Participarea parial a entitilor PERSONAL i PROPRIETATE_DE_NCHIRIAT n
relaia Supravegheaza are ca efect faptul c unele proprieti nu pot fi asociate cu o filial prin
intermediul unui membru al personalului.
Pentru
rezolvarea
acestei
capcane de ntrerupere trebuie
identificat relaia care lipsete.
Aceasta este relaia Are dintre
entitile FILIALA i

PERSONAL

Estealocat

Supervizeaz

1
FILIALA

Are

PROPRIETATE_
DE_NCHIRIAT

PROPRIETATE_DE_NCHIRI
AT.
Se restructureaz modelul ER,
introducnd
relaia
nou
identificat Are ntre entitile
ntre care lipseau cile (fig.
2.28).

Fig. 2.28. Model ER restructurat pentru eliminarea capcanei de ntrerupere.

27

Entitile
FILIALA
F1

Relaia
Estealocat
r1

F2

r2

F3

r3

Entitile
PERSONAL
SA1

Relaia
Supervizeaz

Entitile
PROPRIETATE_
DE_NCHIRIAT

r4

P2

SA2
SA3

P1

r5

P3

Relaia Are

r1
r2
r3

Fig. 2.29. Reeaua semantic a modelului ER restructurat din fig. 2.28.


Acum la nivelul apariiilor individuale, adic din reeaua semantic, se poate stabili c
proprietatea P2 este disponibil la filiala F2 (fig. 2.29).

28