You are on page 1of 33

5.

Proiectarea bazelor de date


relaionale
Modelul Entitate - Relaie
Proiectarea bazei de date este o munc de colectiv care armonizeaz cerinele i posibilitile
beneficiarului pe de o parte i proiectantului de sistem pe de alt parte. Baza de date este prima
treapt spre o viziune sistemic, de ansamblu, unificatoare i generatoare de rezultate specifice
corecte n acelai timp.
Vechiul sistem de proiectare a fost bazat pe fiiere. Limitele acestei concepii constau n
separarea datelor, duplicarea datelor, dependena programului de concepia fiierului i
incompatibilitatea formatelor de fiiere folosite n diverse limbaje. Aceste limitri implic pierdere
de timp i spaiu i posibilitatea de inconsisten a datelor.
Sistemul de baz de date - n opoziie cu vechiul sistem - d posibilitatea de a definii datele
n afara programului i asigur controlul asupra manipulrii datelor.
Definiie: Baz de date: Este o colecie partajat de date legate logic, proiectat pentru a
satisface necesitile unui sistem informatic.
Deci datele sunt strnse ntr-o colecie unic i sunt folosite simultan de mai muli
utilizatori. Redundana datelor este controlat prin normalizare, ceea ce implic o redundan
minim.
O astfel de baz de date are nevoie de un sistem de gestiune a bazei de date. Acesta este un
sistem de programe care fac posibil definirea, ntreinerea i accesul controlat la baza de date. Un
astfel de sistem trebuie s conin limbajul de definire i limbajul de manipulare a datelor. Putem
aminti urmtoarele limbaje: SQL sau QBE (limbaje generale), respectiv DBASE, FOX PRO,
PROGRESS, PARADOX .a.m.d. (limbaje specifice).
Cum se stabilete structura bazei de date? Tocmai prin proiectarea de care ne ocupm. n
opoziie cu proiectarea bazei de date bazate pe fiiere, care pornea de la una sau mai multe aplicaii
ale beneficiarului, proiectarea bazei de date se rezolv naintea elaborrii aplicaiei. De aceea
aceast aciune devine esenial pentru tot sistemul.
Proiectantul bazei de date trebuie s identifice datele relaionale, relaiile dintre ele i
restriciile asupra lor. Proiectarea const din dou faze: unul logic i unul fizic. n timpul proiectrii
logice este important implicarea viitorilor utilizatori n procesul de proiectare. n proiectarea fizic
se decide cum va fi realizat practic modelul logic.
Avantajele i dezavantajele sistemului de baze de date:
Avantajele ar fi urmtoarele:

controlul redundanei

consistena datelor

economia de spaiu pentru aceleai date

controlul integritii datelor

utilizarea standardelor

d posibilitatea rspunsului la cereri variate i cu exprimri parial necunoscute la momentul


proiectrii.

productivitate crescut

concuren crescut

posibiliti crescute de recuperare n caz de eroare


Dezavantaje:
1

complexitate crescut
costul SGBD
cost crescut rezultat din cerine de hard
costul trecerii de la un sistem la altul
o eventual defeciune are un impact crescut, global

1. Modelarea ER (Entity-Relationship)
n acest capitol vom descrie urmtoarele obiective:
Folosirea modelului conceptual de nivel nalt pentru proiectarea de baze de date.

Conceptele modelului ER, model de nivel nalt.


O tehnic grafic de reprezentare a modelului ER.
Modul de identificare a problemelor ce pot aprea la crearea unui model ER.
Limitele modelului ER primar i conceptele necesare pentru modelarea aplicailor complexe.
Conceptele modelului EER (Enhanced Entity-Relationship), numite i specializare/generalizare.
O tehnic grafic de reprezentare a specializri/generalizri n modelul EER.

Utilizarea produsului ERwin produs de Logic Works, pentru proiectarea bazelor de date, ceea ce
include i modelul ER.
Modelul ER (Entity-Relationship) este un model conceptual de nivel nalt dezvoltat de Chen
n 1976, care faciliteaz crearea de baze de date relaionale. n acest capitol, vom descrie conceptele
primare ale modelului ER, dup care vom identifica problemele care pot aprea la un model ER
(Howe, 1989). Vom discuta deasemenea, problemele reprezentrii unor aplicaii, folosind modelul
ER (Schmidt i Swenson, 1975). Avnd n vedere c modelul ER are anumite limite n modelarea
aplicaiilor, vom introduce un model mai complex, modelul EER, numit i specializare/generalizare.
1.1. Conceptele modelului Entity-Relationship
Conceptele primare ale modelului ER includ: tip de entitate, tip de relaie, atribute.
1.1.1. Tipuri de entiti
Definiie: Tip de entitate: Este un obiect sau un concept, identificat de o ntreprindere,
avnd o existen independent.
Tipurile de entiti reprezint obiecte reale, din viaa de zi cu zi, avnd proprietile lor, sau obiecte
conceptuale, abstracte.
Definiie: Entitate: Un obiect sau un concept ce se poate identifica unic.
Un tip de entitate conine mai multe entiti.
Un tip de entitate se identific prin nume i list de atribute. O baz de date conine n
general mai multe tipuri de entiti. Fiecare tip de entitate are propriile lui atribute. Putem clasifica
aceste tipuri n tipuri slabe i tipuri tari.
Definiie: Tip slab de entitate: Este un tip de entitate, a crui existen este dependent de
un alt tip de entitate.
Definiie: Tip tare de entitate: Este un tip de entitate, a crui existen nu depinde de nici
un alt tip de entitate.
Entitile slabe se mai numesc dependente sau subordonate iar cele tari printe sau dominante.
Reprezentarea grafic a entitilor: Entitile tari se reprezint printr-un dreptunghi,
etichetate cu numele entitii iar cele slabe se reprezint printr-un dreptunghi desenat cu linie dubl,
etichetate de asemenea cu numele lor.
2

Exemplu:

nume entitate tare

nume entitate slab

1.1.2. Atribute
Definiie: Atribute: Proprietile unui tip de entitate sau de relaie.
Definiie: Domeniul atributului: Un set de valori ce se pot da acelui atribut.
Domeniul unui atribut nu se poate definii totdeauna foarte exact. De exemplu, atributul nume de
familie poate lua orice nume de familie existent. Evident, acest atribut trebuie s fie un ir de
caractere, dar oare ce caractere poate s conin? Unele domenii se pot descompune n mai multe
subdomenii. De exemplu data naterii se poate descompune in subdomeniile: an, lun, zi.
Atributele se pot clasifica n simple sau compuse; cu o singur valoare sau cu mai multe
valori; respectiv derivate.
Definiie: Atribut simplu: Atribut care are doar o singur component i o existen
independent.
Aceste atribute nu se pot diviza mai trziu n mai multe atribute distincte.
Definiie: Atribut compus: Atribut care are mai multe componente i o existen
independent.
Aceste atribute se pot diviza n mai multe atribute simple. De exemplu atributul adres se poate
descompune n atributele: strada, numr, ora, cod potal i jude. Decizia ca un atribut compus s
se descompun n mai multe atribute simple este dependent de modul n care se va utiliza acel
atribut: separat pe componente, sau ntregul atribut.
Definiie: Atribut cu o singur valoare: Atribut care poate lua o singur valoare pentru
fiecare entitate.
Majoritatea atributelor sunt atribute cu o singur valoare, ceea ce este indicat n proiectarea bazelor
de date.
Definiie: Atribut cu mai multe valori: Atribut care poate lua mai multe valori pentru
fiecare entitate.
Atributele cu mai multe valori, trebuie s aib totdeauna o limit inferioar i una superioar.
Definiie: Atribut derivat: Atribut a crei valoare se poate calcula din unul, sau mai multe
alte atribute, care nu sunt neaprat atributele entitii n cauz.
De exemplu atributul vrsta este derivat din atributul data naterii i data zilei n care se utilizeaz
acest atribut. Alt exemplu ar fi atributul numrul total de entiti, ceea ce se poate calcula,
numrnd entitile nregistrate.
Chei:
Intuitiv, o cheie este un atribut, care determin unic o entitate dintr-un tip de entitate. n
continuare, dm o definiie riguroas a cheii.
Definiie: Cheie candidat: Un atribut, sau un set de atribute, care identific unic o entitate
dintr-un tip de entitate.
Definiie: Cheie primar: O entitate poate s aib una sau mai multe chei candidat, din care
doar una selectat este i primar.
Decizia referitoare la care din cheile candidate s fie cheie primar este dependent de lungimea
cheii. Cheia primar este de obicei cea mai scurt dintre cheile candidat.
Definiie: Cheie compus: O cheie candidat care conine cel puin dou atribute.
Reprezentarea grafic a atributelor:
Un atribut se reprezint printr-o elips, legat de entitatea de care aparine cu o linie i
etichetat cu numele atributului. Elipsa este punctat, dac atributul este un atribut derivat; respectiv
dublat, daca poate lua mai multe valori.
3

Dac un atribut este compus, atunci componentele atributului se reprezint n elipse legate
printr-o linie de atributul compus.
Atributele care intr n componena cheii primare, se noteaz prin sublinierea numelui
atributului.
Numr
bloc

Exemplu:

Scara
Adresa

Nume
Locatari
Numr
matricol

Etaj
Apartament

n acest exemplu, entitatea Locatari, fiind o entitate tare, are urmtoarele atribute: Numr
matricol, Nume i Adresa. Dintre aceste atribute, atributul Numr matricol este cheie primar;
atributul Adresa este atribut compus, care se descompune n Numr bloc, Scara, Etaj i Apartament.
1.1.3. Tipuri de relaii
Definiie: Tip de relaie: Asociere ntre tipuri de entiti.
Definiie: Relaie: Asociere ntre entiti, cnd asocierea include un tip de entitate dintre
toate tipurile participante.
Reprezentarea grafic a relaiilor: Relaiile se reprezint printr-un romb etichetat cu numele
relaiei. Rombul se deseneaz cu linie dubl, dac relaia leag o entitate slab de entitatea tare de
care aparine.
Definiie: Gradul relaiei: Numrul entitilor participante n relaie.
Entitile dintr-o relaie se numesc participani. Numrul lor d gradul relaiei. Dac intr-o relaie
sunt doi participani, atunci relaia se numete binar.
Definiie: Relaie recursiv: Relaie n care aceleai entiti particip n roluri diferite.
n cazul relaiilor recursive cele dou arce de la entitate la relaie i napoi, primesc diferite
etichete, care sunt importante n nelegerea corect a relaiei.
1.1.4. Atributele relaiilor
Atributele descrise mai sus, se pot asocia i relaiilor. Aceste atribute se reprezint grafic, ca
i atributele entitilor, cu deosebirea c legtura nu este cu o entitate, ci cu o relaie. Adic linia
leag elipsa de rombul ce semnific relaia.
1.2. Structuralitatea
S analizm acum restriciile ce pot aprea la includerea unei entiti participante ntr-o
relaie. Avem dou tipuri mari de restricii: cardinalitatea i participarea.
1.2.1. Cardinalitatea
Definiie: Cardinalul este numrul relaiilor posibile pentru o entitate participant.
Majoritatea relaiilor au gradul doi, care pot fi: unu-la-unu (1:1), unu-la-multe (1:M), sau
multe-la-multe (M:N).
Relaiile unu-la-unu:
4

n relaiile unu-la-unu, o entitate este legat de cel mult o entitate din partea cealalt a
relaiei. Aceast relaie se reprezint grafic prin etichetarea arcului dintre relaie i entitate cu
cardinalul relaiei, adic cu 1.
Relaiile unu-la-multe:
Relaia de tip unu-la-multe are cardinalul 1 n stnga i N n dereapta. Deci o entitate
participant este legat n relaia respectiv de 0, 1, sau mai multe entiti. Exemplificm acest tip
de relaie prin relaia Sunt locuite dintre tipurile de entiti Scri, respectiv Locatari.

Atribute

Scri

Nr_bloc
Scara

Sc.A

Nr_bloc
Scara
Nr_bloc
Scara

Sc.B
Sc.C

Sunt locuite de
R1
R2
R3

Locatari
Fam.1
Fam.2
Fam.3

Atribute
Nr_mat
Numele
Nr_mat
Numele
Nr_mat
Numele

Figura 1.1. Exemplu de relaie 1:M


n reprezentarea grafic a relaiilor, relaia unu-la-multe se noteaz cu etichetarea arcului cu
1 n partea stng i cu N n partea dreapt. Din exemplul de mai sus observm c dac relaia
direct este de unu-la-multe, atunci relaia invers este de unu-la-unu.
Relaiile multe-la-multe:
Acest tip de relaie se deosebete de relaia unu-la-multe prin faptul c relaia invers nu este
de unu-la-unu, ci de unu-la-multe. Deci, dac i relaia direct i relaia invers este de tipul unu-lamulte, atunci relaia este de tipul multe-la-multe i se noteaz cu (N:M).
1.2.2. Participarea
Definiie: Participarea determin dac existena unei entiti depinde sau nu de relaia cu o
alt entitate.
Participarea poate fi de mai multe tipuri: total i parial. n cazul participrii totale, toate
entitile particip n relaia dat. n caz contrar participarea se numete parial. n diagrama ER
aceste tipuri de relaii se reprezint prin arc cu linie dubl pentru participarea total, respectiv cu
linie simpl pentru participarea parial. Pentru participarea parial, exist un mod de notaie prin
care se eticheteaz arcele relaiei cu perechea de numere ce reprezint minimul, respectiv maximul
entitilor participante la relaie.
1.3. Problemele modelului ER
n acest capitol vom examina numeroasele probleme ce pot aprea la modelarea unei baze
de date. Aceste probleme se refer la capcanele care pot aprea la definirea relaiilor ntre tipuri de
entiti. Amintim dou tipuri mari de capcane: de tip labirint (fan trap), respectiv de tip prpastie
(chasm trap).
Definiie: Fan trap (capcan de tip labirint): Acest tip de capcan reprezint cazul n care
modelul reprezint o relaie ntre dou tipuri de entiti, dar calea dintre cele dou membrii este
ambigu.

Cu alte cuvinte, pornind de la o entitate, nu se tie ca dup parcurgerea cii relaiilor, la ce


entitate se ajunge n partea cealalt. Aceast capcan se poate elimina prin rearanjarea ordinii
relaiilor dintre cele dou tipuri de entiti.
Cellalt tip de capcan este:
Definiie: Chasm trap (capcan de tip prpastie): Acest tip de capcan se descrie prin faptul
c modelul sugereaz existena relaiei ntre cele dou tipuri de entitate, dar calea dintre tipurile de
entiti nu exist.
Aceast problem provine din participarea parial a unor entiti la una dintre relaii.
Problema se poate rezolva prin introducerea unei relaii directe.
1.4. Modelul Enhanced Entity-Relationship (EER)
Modelul ER, discutat n capitolele de mai sus, este adecvat pentru descrierea multor scheme
de baze de date. Din 1980 s-au dezvoltat foarte mult aplicaiile care folosesc baze de date. Modelul
ER nu mai era suficient pentru reprezentarea complexelor scheme de baze de date. De aceea s-au
introdus alte concepte n modelul ER, dezvoltnd modelul EER.
Modelul EER include toate conceptele modelului ER, plus alte completri devenite
necesare. Aceste concepte sunt nou introduse sunt: specializarea/generalizarea, categorisirea i
ncapsularea. n acest capitol vom descrie conceptele de baz a modelului EER i anume,
specializare/generalizare.
Specializarea/generalizarea este n strns legtur cu modul de descriere a tipurilor de
entiti n superclase i subclase, precum i de motenirea atributelor. De aceea vom descrie aceste
concepte.
1.4.1. Superclasele i subclasele tipurilor de entiti
Vom descrie aceste concepte, avnd ca exemplu tipul de entitate Locatari.
Definiie: Superclas: Superclasa este un tip de entitate care include subclase distincte
reprezentate ntr-un model de date.
Definiie: Subclas : Subclasa este un tip de entitate care are un rol distinct i este membru
al unei superclase.
De exemplu superclasa Locatari se divizeaz n dou subclase i anume: ef de scar i
Familii. Relaia dintre o superclas i o subclas se numete relaie superclas/subclas. Aceast
relaie este de tip unu-la-unu. Relaia Locatari/Familii de exemplu, este o astfel de relaie.
Fiecare membru al unei subclase este membru i n superclas, dar are un rol diferit. Exist
subclase case se suprapun, adic exist membrii ntr-o subclas care apar i n cealalt subclas.
Putem observa c exemplul de mai sus este exact de acest tip, pentru c eful de scar poate s fie i
cap de familie.
De ce se folosete clasificarea n subclase? Rspunsul este simplu de observat direct din
exemplul dat. Dac nu am clasifica entitile din tipul de entitate Locatari, atunci ar trebui s
memorm informaiile specifice efului de scar i capului de familie pentru fiecare locatar.
Deoarece majoritatea locatarilor nu aparine nici unei categorii, pentru acestea ar fi informaii
nefolositoare, dar care ns ar ocupa mult spaiu pe suportul magnetic.
1.4.2. Motenirea atributelor
Fiecare subclas are ca atribute comune, atributele superclasei n care aparine. Deci fiecare
membru al unei subclase se caracterizeaz prin atributele superclasei i alte atribute specifice
subclasei. De exemplu subclasa Familii se caracterizeaz prin toate atributele superclasei Locatari
(Numr matricol, Numr bloc, Scara, Etaj, Apartament i Nume), pe lng care mai are i alte
atribute specifice (Numr persoane, Numr persoane prezente, etc.)
Fiecare subclas poate s aib subclase, crendu-se un arbore de clase, care se numete
ierarhie de tipuri. Aceast ierarhie de tipuri include alte denumiri de ierarhii i anume: ierarhia de
6

specializri (de exemplu, tipul de entitate Familii este o specializare a tipului de entitate Locatari)
i ierarhia de generalizri (de exemplu, Locatari este o generalizare a tipului de entitate Familii).
1.4.3. Specializarea
Definiie: Specializare este un proces de maximizare a diferenelor unor membrii ale unei
entiti, identificnd caracteristicile distincte.
Specializarea este o aproximare top-down a definirii unor superclase, mpreun cu
subclasele lor. Relaia superclas/subclas se reprezint grafic printr-un arc de la superclas la un
cerc, care la rndul lui este legat cu un arc de subclas. Pe arcele de la subclase se deseneaz un
semn de incluziune de la subclas la superclas. Aceste semn de incluziune indic direcia relaiei
superclas/subclas.
Atributele specifice doar subclasei sunt ataate direct la dreptunghiul care reprezint
subclasa.
Toate aceste notaii se exemplific n figura de mai jos:
Numr
matricol
Numr
bloc

Locatari

Familii
ef de scar

Adresa

Numr
persoane

Data
intrrii n
funcie
n exemplul de mai sus tipul superclasa Locatari se compune din mai multe subclase: ef de
scar i Familii. Superclasa Locatari va avea ca membrii pe toi locatarii unei scri. ntre aceti
locatari, unii sunt capi de familii iar alii efi de scar. Aceti membrii ai tipului de entitate Locatari
vor aprea ca membrii i n subclasele ef de scar, respectiv Familii.
Definiie: Subclas partajat se numete subclasa care are mai multe superclase.
Membrii din subclasa partajat sunt membrii n fiecare dintre superclase. De aceea ei
motenesc atributele fiecrei superclase o astfel de motenire se numete motenire multipl.
n cazul relaiilor, dac o subclas este n relaie cu un alt tip de entitate, aceast relaie se
refer doar la subclasa respectiv, nu i la superclasa lui.
1.4.4. Generalizarea
Definiie: Generalizare se numete procesul de minimizare a diferenelor dintre entiti,
pentru identificarea caracteristicilor comune.
Procesul de generalizare este o aproximare bottom-up a superclaselor, din subclasele
originale. Deci generalizarea este inversa specializrii. De exemplu dac privim tipurile de entiti
Familii i ef de scar, vom observa c unele atribute ale lor caracterizeaz ambele tipuri. De aici
rezult necesitatea crerii unei superclase care s conin toate atributele comune celor dou tipuri.
1.4.5. Regulile specializrii i generalizrii
n acest capitol vom discuta despre regulile ce trebuie aplicate n cazul specializrii sau al
generalizrii.
Prima regul se numete regula disjunciei. Aceast regul specific dac subclasele unei
clase sunt disjuncte, adic un membru al superclasei aparine cel mult uneia dintre subclase. O
specializare disjunct se reprezint cu un d nscris n cercul care leag subclasele de superclase.
7

Dac subclasele nu sunt disjuncte, adic un membru al superclasei poate s aparin la mai
multe subclase, atunci subclasele respective se numesc non disjuncte i se noteaz cu o n cercul
care leag subclasele de superclase. n exemplul nostru subclasele Sef de scar i Familii - care sunt
subclasele clasei Locatari - sunt non disjuncte.
A doua regul a specializrii este regula participrii, care poate fi total sau parial.
Participarea este total dac toi membrii superclasei sunt i membrii subclaselor. Pentru
reprezentarea participrii totale, arcul de la superclas la cercul dintre superclas i subclas se
dubleaz.
n cazul participrii pariale nu toi membrii superclasei iau parte ntr-o subclas. Acest tip
de participare se reprezint cu linie simpl ntre superclas i cerc. n exemplul nostru avem o
participare parial n cazul superclasei Locatari, cu subclasele ef de scar i Familii.
Cele dou reguli se aplic distinct la procesele de specializare, sau generalizare. De aceea
putem avea patru tipuri de specializri: disjunct total, disjunct parial, non disjunct total, sau
non disjunct parial.

2. Normalizarea bazei de date


n acest capitol vom discuta despre:
Necesitatea normalizrii
Problemele asociate cu informaiile redundante n rnduri.
Identificarea tipurilor variate de anomalii ce pot aprea la actualizare: inserare, tergere i
modificare.
Procesul de normalizare.
Conceptul de dependen funcional, modalitatea de a grupa atributele n relaii
Cum utilizm dependenele funcionale, pentru a grupa atributele n relaii care sunt n
forme normale cunoscute?
Cum definesc relaiile, formele normale?
Cum derulm procesul de normalizare?
Cum identificm prima (1NF), a doua (2NF) i a treia (3NF) form normal, respectiv
forma normal Boyce-Codd (BCNF)?
2.1. Necesitatea normalizrii
Cnd proiectm o baz de date, dorina noastr este de a reprezenta ct mai corecte
informaiile i s diminum ct mai mult posibilitatea de a ajunge la informaii eronate (dac nu
putem elimina de tot acest neajuns). Pentru a ajunge la aceast performan, trebuie s folosim
normalizarea.
Definiie: Normalizare: O tehnic de generare a unor relaii cu proprietile dorite, n scopul
memorrii corecte a datelor unei ntreprinderi.
Procesul de normalizare prima dat a fost introdus de E. F. Codd (1972). Iniial s-au propus
trei forme normale, numerotate de al unu la trei. Mai trziu s-a inclus nc o form normal, numit
Boyce-Codd, dup numele celor care l-au introdus: R. Boyce i E. F. Codd.
Formele normale cele mai folosite sunt: forma normal 3 i forma normal Boyce-Codd.
Exist i forme normale mai tari - forma normal 4 (4NF) i forma normal 5 (5NF) - dar aceste se
folosesc foarte rar.
Procesul de normalizare este o metod formal de identificare a relaiilor bazate pe chei
primare (sau chei candidat n cazul BCNF) i dependenele funcionale cu atributele asociate.
Normalizarea d posibilitatea proiectantului bazei de date, pentru a efectua o seria de teste pe baza
8

de date, toate aceste teste ducnd la prevenirea posibilitii de a aprea anomalii la actualizarea
bazei de date.
Pentru a ilustra procesul de normalizare, vom folosi exemple din sistemul informatic
Asociaie de locatari.
2.2. Redundana n informaii i anomalii la actualizare
Partea cea mai important a proiectrii bazei de date este de a grupa atributele n relaii cu
scopul de a minimiza redundana n informaii i spaiul ocupat de fiiere pe suportul magnetic.
Fie relaia Furnizori_Cheltuieli exemplificat mai jos. La exemple vom simplifica atributele
asociate entitilor.
Cod
Denumire
Cod
Nr.
Furn.
fiscal
Crt.
F100
Romgaz
R1234567
1
F100
Romgaz
R1234567
2
F110
Renel
R7654321
3
F110
Renel
R7654321
4
Figura 2.1 Relaia Furnizori_Cheltuieli

Cod
Chelt.
C15
C16
C10
C11

Denumire
Cheltuial
Chelt pt. nclzire
Chelt pt. buctrii
Chelt cu iluminatul
Chelt pt. func. liftului

Valoare
1500000
500000
3000000
200000

Dependenele funcionale pentru relaia Furnizori_Cheltuieli de mai sus sunt urmtoarele:


Furnizori
(Cod.Furn., Denumire, Cod fiscal)
Cheltuieli
(Nr.Crt., Cod chelt., Cod.furn., Valoare)
Tip_cheltuiala
(Cod.Chelt., Denumire chelt.)
Furnizori_Cheltuieli (Nr.Crt., Cod chelt., Cod furn., Denumire chelt., Denumire, Cod
fiscal, Valoare)
n acest exemplu, informaia despre furnizor devine redundant. Detaliile despre furnizor se
repet la fiecare introducere a unei cheltuieli noi. n dependenele funcionale specificate pentru
entitatea Cheltuieli, apare doar codul furnizorului. Analog, denumirea cheltuielii, apare i ea n plus
fa de entitatea Cheltuieli.
O alt problem serioas datorat redundanei bazei de date, sunt problemele de actualizare
a informaiei stocate. Aceste probleme se pot clasifica n anomalii de inserare, modificare, sau
tergere.
2.2.1. Anomalii de inserare
Anomaliile de inserare se pot clasifica n dou tipuri mari:
Pentru a adaug detaliile despre o cheltuial ctre un furnizor, n relaia Furnizori_Cheltuieli
trebuie obligatoriu adugate i detaliile despre furnizorul n cauz, chiar dac el exist deja n baza
de date. Aceast anomalie poate duce la apariia aceluiai furnizor, avnd introduse detalii diferite n
nregistrri diferite.

Pentru a aduga detaliile unui furnizor nou n relaia Furnizori_Cheltuieli, trebuie neaprat
adugat i o cheltuial pentru asociaia de locatari ctre acel furnizor. n cazul n care nc nu a
sosit factura de la furnizor, nu pot nregistra nici o cheltuial i deci trebuie introduse date vide n
locul cheltuieli. Cum Nr.Crt. este cheia primar n relaia Furnizori_Cheltuieli, introducerea de date
vide n acest cmp va strica integritatea entitii.

2.2.2. Anomalii de tergere


n cazul tergerii ultimei cheltuieli a asociaiei de locatari ctre un furnizor, se va terge i
furnizorul. Deci toate detaliile introduse despre acel furnizor vor fi pierdute, ceea ce duce la
obligativitatea reintroducerii datelor la o nou folosire al acelui furnizor. n cazul entitii separate
pentru cheltuieli i furnizori, dac se terge i ultima cheltuial ctre un furnizor, datele despre
furnizor rmn totui n entitatea Furnizori.
2.2.3. Anomalii de modificare
Dac n relaia Furnizori_Cheltuieli dorim s schimbm valoarea unui atribut al unui
furnizor, va trebui s schimbm datele la fiecare apariie a acelui furnizor. De exemplu dac dorim
s schimbm codul fiscal al furnizorului cu codul F100, va trebui s achimbm acest atribut n dou
locuri. Dac n timpul modificrilor, care poate dura destul de mult, intervine i un incident n uema
cruia vor rmne nregistrri nemodificate, atunci baza de date devine inconsistent. Aceast
anomalie se poate evita prin folosirea a dou entiti distincte precum Cheltuieli i Furnizori. n
acest caz dac trebuie s modific un atribut al unui furnizor, va trebui s-o modific doar ntr-un
singur loc: n entitatea Furnizori.
2.3. Dependene funcionale
Unul din cele mai importante concepte asociate normalizrii este dependena funcional.
Dependena funcional descrie relaia dintre atribute. n acest capitol vom descrie conceptul de
dependen funcional, urmnd ca n capitolele urmtoare s descriem procesul de nlormalizare a
bazei de date.
2.3.1. Definiia dependenei funcionale
Definiie: Dependen funcional: Descrie relaia dintre atribute. De exemplu dac
atributul A este n relaia R cu atributul B, atunci atributul B este dependent funcional de atributul
A (notat: A B), dac orice valoarea al lui A este asociat prin relaia R cu exact o valoare a
atributul B.
Dependena funcional este o proprietate a semanticii atributelor n relaii. Semantica indic
atributele care sunt n relaie i specific dependenele funcionale dintre atribute.
Considerm o relaie ntre dou atribute A i B, unde atributul B este dependent funcional
de atributul A (atributele A i B pot fi compuse din mai multe atribute). Cu alte cuvinte, dac tim
valorile cmpului A, atunci analiznd valorile lui B n relaia cu A, vom considera c pentru valori
diferite al lui A - care fiind cheie, trebuie s aib valori diferite - avem valori diferite i pentru
cmpul B. Dependena funcional dintre dou cmpuri se reprezint grafic n urmtorul mod:

Figura 2.2 Diagrama dependenei funcionale


Definiie: Determinant: Numim determinantul unei relaii funcionale, atributul, sau
mulimea atributelor din partea stng a sgeii.

10

n acest capitol vom ignora dependenele funcionale triviale, adic acele relaii de tipul
AB, n care B este dependent de un subset de atribute al lui A. Pentru a exemplifica dependenele
funcionale, considerm urmtorul exemplu:
Exemplu: Considerm atributele Cod furnizor i Denumire. Pentru un anumit cod de
furnizor, putem determina denumire acelui furnizor. Adic denumirea este dependent funcional de
cod furnizor. Dependena invers nu este adevrat pentru c pot exista aceleai denumiri cu coduri
diferite.
Relaia dintre cod furnizor i denumire este de 1:1, iar relaia invers este de 1:M.
S identificm dependenele funcionale din relaia Furnizori_Cheltuieli descris mai sus:
Nr. Crt., Cod Furn., Cod Chelt.
Denumire
Nr. Crt., Cod Furn., Cod Chelt.
Cod fiscal
Nr. Crt., Cod Furn., Cod Chelt.
Denumire cheltuial
Nr. Crt., Cod Furn., Cod Chelt.
Valoare
Cod Furnizor
Denumire
Cod Furnizor
Cod fiscal
Cod fiscal
Denumire
Cod fiscal
Cod Furnizor
Cod Chelt.
Denumire cheltuial
n aceast relaie avem 9 dependene funcionale, care au determinantele
(Nr. Crt., Cod
Furn., Cod Chelt.), Cod fiscal, Cod Furn. i Cod Chelt. Putem evidenia aceste dependene i ntr-un
alt format:
Nr.Crt., Cod Furn., Cod Chelt.
Cod Furn.
Cod fiscal
Cod Chelt.

Denumire,Cod fiscal, Denumire cheltuial, Valoare


Denumire, Cod fiscal
Denumire, Cod Furn.
Denumire cheltuial

Pentru a identifica cheile candidate, trebuie s identificm atributul, sau grupul de atribute
care determin unic fiecare nregistrare al acestei relaii. Dac avem mai mult de o cheie candidat,
atunci va trebui s identificm i o cheie primar. Toate atributele care nu aparin cheii primare,
depind funcional de cheia primar. n aceast ipostaz este grupul de atribute (Nr. Crt., Cod Furn.,
Cod Chelt.). Atributele Cod Furn., Cod fiscal i Cod Chelt. Sunt determinani, dar nu sunt chei
candidat.
Conceptul de dependen funcional este conceptul central al normalizrii, ceea ce vom
descrie n capitolele urmtoare.
2.4. Procesul de normalizare
Normalizarea este un proces formal de analiz a relaiilor bazate pe chei primare (sau pe
baza cheilor candidat n cazul BCNF). Normalizarea presupune urmarea unor reguli prin care baza
de date se poate normaliza pn la un anumit grad. Dac o cerin nu este satisfcut, relaia trebuie
descompus n mai multe relaii, care individual satisfac cerinele formei normale.
Normalizarea se execut trecnd prin toate formele normale, pn la forma normal cerut.
La proiectarea unei baze de date trebuie s ajungem cel puin la forma normal unu, dar ca s
evitm toate anomaliile descrise mai nainte, este recomandat aducerea bazei de date la BCNF.
11

n figura urmtoare evideniem relaia dintre diversele forme normale. Observm c unele
din relaiile n 1NF este i n 2NF, dintre care unele n 3NF i aa mai departe.

1NF
2NF
3NF
BCNF
4NF
5NF
NF
Figura 2.3. Ilustrarea grafic a relaiei dintre formele normale.
2.5. Forma Normal Unu (1NF)
nainte s discutm despre forma normal unu, vom da definiia stadiului dinainte de aceast
form normal.
Definiie: Form Nenormalizat (UNF): O tabel care conine una sau mai multe grupuri
repetitive.
Definiie: Forma Normal Unu (1NF): Relaie n care la intersecia oricrei linii cu oricare
coloan gsim un cmp care conine exact o valoare.
n acest capitol ncepem procesul de normalizare. Pentru nceput transferm datele de la
surs ntr-o tabel, care va fi o tabel nenormalizat. Pentru a transforma aceast tabel n forma
normal unu, identificm i tergem grupurile repetitive din tabel. Grupurile repetitive sunt
atribute, sau grup de atribute, pentru care avem diferite valori pentru aceeai valoare a cheii, ceea ce
este n contradicie cu definiia cheii. Eliminarea acestor grupuri repetitive se poate realiza n dou
moduri:
Conform primei modaliti, eliminm grupurile repetitive, prin crearea altor nregistrri, n
care s fie introduse valorile din aceste grupuri, mpreun cu celelalte valori ai atributelor din
nregistrarea la care se lucreaz. Tabele astfel rezultat va fi n form normal unu.
n a doua modalitate, fiecare valoare a grupurilor repetitive le copiem ntr-o nou relaie
mpreun cu cheia primar din tabela iniial. Putem avea mai multe grupuri repetitive. n acest caz
crem mai multe relaii noi. Aceste relaii noi, precum i tabela normalizat vor fi n form normal
unu.
De exemplu s lum relaia Furnizori_Cheltuieli:
Cod
Furn.
F100

Denumire
Romgaz

F110

Renel

Cod
fiscal
R1234567

Nr.
Cod
Denumire
Crt.
Chelt.
Cheltuial
1 C15
Chelt pt. nclzire
2 C16
Chelt pt. Buctrii
R7654321
3 C10
Chelt cu iluminatul
4 C11
Chelt pt. Func. liftului
Figura 2.4. Tabela nenormalizat Furnizori_Cheltuieli.

12

Valoare
1500000
500000
3000000
200000

n aceast tabel observm c pentru furnizorul Romgaz avem dou tipuri de cheltuieli.
Pentru a transforma aceast tabel n 1NF, trebuie s avem o singur valoare la fiecare intersecie
linie coloan.
n cazul primei modaliti, scriem repetiiile pe diferite rnduri iar coloanele care nu conin
repetiii, vor fii copiate pe fiecare rnd. Dup desprirea repetiiilor pe mai multe rnduri,
identificm o nou cheie.
Cod
Denumire
Cod
Nr.
Cod
Denumire
Valoare
Furn.
fiscal
Crt.
Chelt.
Cheltuial
F100
Romgaz
R1234567
1 C15
Chelt pt. nclzire
1500000
F100
Romgaz
R1234567
2 C16
Chelt pt. Buctrii
500000
F110
Renel
R7654321
3 C10
Chelt cu iluminatul
3000000
F110
Renel
R7654321
4 C11
Chelt pt. Func. liftului
200000
Figura 2.5. Tabela Furnizori_Cheltuieli n 1NF, creat prin prima modalitate de transformare.
n tabela normalizat, noua cheie va fii (Cod Furn., Nr. Crt., Cod Chelt.).
Normaliznd tabela iniial dup a doua modalitate, vom crea o a doua tabel cu informaiile
care nu se repet, mpreun cu cheia primar din tabela iniial. Deci cele dou tabele vor fi
urmtoarele:
Furnizori (Cod Furn., Denumire, Cod fiscal)
Cheltuieli (Cod Furn., Cod Chelt., Nr. Crt., Denumire cheltuial, Valoare)
Cele dou tabele astfel create sunt n 1NF:
Cod
Furn.
F100
F100
F110
F110

Nr.
Crt.
1
2
3
4

Cod
Chelt.
C15
C16
C10
C11

Denumire
Cheltuial
Chelt pt. nclzire
Chelt pt. Buctrii
Chelt cu iluminatul
Chelt pt. func. Liftului

Valoare
1500000
500000
3000000
200000

Cod
Denumire
Cod
Furn.
fiscal
F100
Romgaz
R1234567
F100
Romgaz
R1234567
F110
Renel
R7654321
F110
Renel
R7654321
Figura 2.6. Relaia Cheltuial i Furnizor, create prin metoda a doua de normalizare.
Pentru a demonstra trecerea la forma normal doi i mai mari, vom folosii relaia
Furnizori_Cheltuieli, evideniat n figura 2.5.
2.6. Forma Normal Doi (2NF)
Forma normal doi se bazeaz pe conceptul de dependen funcional total, ceea ce vom
descrie n continuare.
13

2.6.1. Dependena funcional total


Definiie: Dependena funcional total: Dac A i B sunt atributele unei relaii, atunci B
este total dependent funcional de atributul A, dac B este dependent funcional de A, dar nu este
dependent funcional de nici un subset al lui A.
De exemplu s lum urmtoarea dependen funcional:
Nr. Crt., Cod Chelt. Denumire cheltuial
Dependena funcional este corect, pentru c fiecare valoare al lui
(Nr. Crt., Cod
Chelt.) determin unic denumirea cheltuielii, ns dependena nu este total, pentru c Denumire
cheltuial depinde funcional i de un subset al lui
(Nr. Crt., Cod Chelt.) i anume atributul Cod
Chelt.
2.6.2. Definiia Formei Normale Doi
Forma normal doi trebuie verificat doar la relaiile care au cheie compus pe poziie de
cheie primar. Relaiile la care cheia primar se compune dintr-un singur atribut, este n 2NF.
Relaiile care nu sunt n forma normal doi, pot suferii de anomaliile prezentate in capitolul 2.2. De
exemplu dac n cazul relaiei Furnizori_Cheltuieli vream s actualizm datele despre furnizorul
F100, trebuie s actualizm dou nregistrri.
Definiie: Forma Normal Doi (2NF): O relaie este n forma normal doi, dac este n
forma normal unu i fiecare atribut care nu aparine cheii primare, este total dependent funcional
de cheia primar.
Vom demonstra aducerea la forma normal doi, folosind relaia Furnizori_Cheltuieli
evideniat n figura 2.5. Putem trece la forma normal doi prin tergerea atributelor care nu depind
total de cheia primar i trecerea lor ntr-o alt tabel mpreun cu determinantul lor. Dup
efectuarea acestor transformri, vom avea urmtoarele relaii:
Relatia Cheltuieli
Cod
Nr.
Cod
Valoare
Furn. Crt.
Chelt.
F100
1 C15
1500000
F100
2 C16
500000
F110
3 C10
3000000
F110
4 C11
200000
Relaia Furnizori
Cod
Denumire
Furn.
F100
Romgaz
F100
Romgaz
F110
Renel
F110
Renel

Relaia Tip Cheltuial


Cod
Denumire
Chelt.
Cheltuial
C15
Chelt pt. nclzire
C16
Chelt pt. buctrii
C10
Chelt cu iluminatul
C11
Chelt pt. func. liftului

Cod
fiscal
R1234567
R1234567
R7654321
R7654321

Figura 2.7. Relaiile rezultate dup trecerea la 2NF a relaiei Furnizori_Cheltuieli.


Relaiile rezultate au urmtoarea form:
Furnizori
(Cod Furn., Denumire, Cod fiscal)
Tip cheltuial
(Cod Chelt., Denumire cheltuial)
Cheltuieli
(Nr. Crt., Cod Furn., Cod Chelt., Valoare)
14

2.7. Forma Normal Trei (3NF)


Forma normal doi chiar dac nu conine atta redundan ca forma normal unu, totui
exist cazuri n care pot aprea anomalii la actualizare. Aceste anomalii apar din cauza redundanei
generate de dependena tranzitiv.
2.7.1. Dependena tranzitiv
Definiie: Dependen tranzitiv: Dac atributele A, B, C sunt n relaiile AB i BC,
atunci spunem c atributul C este dependent tranzitiv de atributul A, via B.
2.7.2. Definiia Formei Normale Trei
Definiie: Forma Normal Trei (3NF): O relaie care este n form normal doi i nu exist
nici un atribut care s nu aparin cheii principale i care s fie tranzitiv dependent de cheia
principal.
n cazul existenei dependenei tranzitive, tergem coloanele care sunt tranzitiv dependente
de cheia primar i crem o relaie nou cu aceste coloane, mpreun cu determinantul lor, adic
cheia primar.
Examinnd relaiile n forma normal de mai sus, observm c nu exist dependene
tranzitive. Deci relaiile sunt n form normal trei.
2.8. Forma Normal Boyce-Codd (BCNF)
Baza de date trebuie proiectat astfel nct s nu conin dependene pariale sau tranzitive,
pentru c altfel ne putem confrunta cu anomaliile descrise n cap. 2.2.
2.8.1. Definiia Formei Normale Boyce-Codd
Forma normal Boyce-Codd este bazat pe cheile candidat din relaie. O relaie cu o singur
cheie candidat n form normal trei este i n form normal Boyce-Codd.
Definiie: Forma normal Boyce-Codd (BCNF): O relaie este n forma normal BoyceCodd dac i numai dac orice determinant din relaie este cheie candidat.
S cutm determinanii din exemplul de mai sus:
Cod Furn.
Cod Chelt.
Nr. Crt., Cod Furn., Cod Chelt.

Denumire, Cod fiscal


Denumire cheltuial
Valoare

Toi cei trei determinani sunt i chei candidat. Deci exemplul de mai sus este n form
normal Boyce-Codd. Relaiile n form normal trei sunt n general i n form normal BoyceCodd. n cazul n care relaia nu este n form normal Boyce-Codd, trecerea la BCNF se realizeaz
prin tergerea din relaia iniial a atributelor care sunt asociate unui determinant care nu este cheie
candidat i crearea unei noi relaii cu aceste atribute i determinantul lor.
Exist situaii cnd este foarte greu de descompus atributele, ca s ajungem la BCNF. n
aceste situaii este indicat rmnerea la forma normal trei.

15

2.9. S recapitulm procesul de normalizare (de la 1NF la BCNF)


Forma Normal Unu (1NF)
Trebuie s cutm toate interseciile de linii i coloane, unde exist repetiii. Aceste repetiii
se pot elimina prin dou modaliti:

Crearea a noi nregistrri pentru fiecare valoare a repetiiei, dup care se caut o nou cheie
primar.

tergerea atributelor care conin repetiii i crearea a unor noi relaii care vor conine
atributele terse, precum i cheia principal din relaia iniial.
Forma Normal Doi (2NF)
Se caut dependenele pariale de cheia principal, adic toate atributele care depind
funcional de un subset de atribute a cheii primare. Dac cheia primar este compus dintr-un singur
atribut, atunci relaia este n forma normal doi. Dac exist dependene pariale, vom terge
atributele care depind parial de cheia principal i crem o relaie nou care s se compun din
atributele terse mpreun cu determinantul lor.
Forma Normal Trei (3NF)
Pentru a trece la forma normal trei, trebuie s eliminm dependenele tranzitive. Eliminarea
se realizeaz prin tergerea cmpurilor dependente tranzitiv de cheia primar din relaia iniial i
crearea unei noi relaii cu aceste atribute i determinantul lor.
Forma Normal Boyce-Codd (BCNF)
Cerina la forma normal Boyce-Codd este ca fiecare determinant din relaie s fie cheie
candidat. n cazul n care nu este ndeplinit aceast cerin, vom terge atributele dependente
funcional de determinantul care nu este cheie candidat i crem o nou relaie n care s avem
atributele terse i determinantul lor. n unele cazuri trecerea la forma normal Boyce-Codd
complic foarte mult baza de date, caz n care este de preferat rmnerea la forma normal trei.

Form nenormalizat (UNF)


tergem grupurile
care se repet
Forma normal unu (1NF)
tergem
dependenele pariale
Forma normal doi (2NF)
tergem dependenele
tranzitive
Forma normal trei (3NF)

16

Metodologie - Proiectarea bazei de date


n acest capitol vom nva despre:

Scopul metodologiei de proiectarea a bazelor de date.

Proiectarea bazelor de date are dou faze mari: proiectarea logic i proiectarea fizic.

Utilizatorii sistemului informatic au un rol important n proiectarea bazelor de date.

Cum documentm procesul de proiectare a bazelor de date?

Cum descompunem scopul proiectrii n vederi (view-uri) specifice utilizatorilor


ntreprinderii?

Cum utilizm modelarea Entity-Relationship (ER), pentru a crea un model conceptual local,
bazat pe informaiile adunate despre view-urile utilizatorilor?

Cum proiectm un model local conceptual ntr-un model local logic de date?

Cum crem relaiile pentru un model conceptual local?

Cum validm modelul logic de date, utiliznd tehnica normalizrii?

Cum compunem modelele logice locale de date, bazate pe view-urile specifice utilizatorilor,
ntr-un model logic global de date al ntreprinderii?

Cum ne asigurm c modelul global este o reprezentare adevrat i total a prii


ntreprinderii pe care vrem s o modelm?
Metodologia proiectrii bazei de date se compune din dou etape mari: proiectarea logic, n
care proiectantul decide asupra structurii logice a bazei de date, i proiectarea fizic, n care
proiectantul decide cum se va implementa structura logic n sistemul de gestiune a bazelor de date
(SGBD).
n acest capitol vom prezenta pas cu pas, crearea unei baze de date. Vom utiliza modelarea
ER descris n capitolul 1, pentru proiectarea bazei de date; vom valida acest model prin
normalizare, prezentat n capitolul 2; iar n final vom compune diferitele view-uri ntr-un model
global al ntreprinderii.
n acest capitol vom utiliza cuvintele entitate i relaie n locul expresiilor tip de
entitate i tip de relaie. Unde aceast utilizare ar putea crea confuzii, vom specifica tip de
entitate, respectiv tip de relaie.
3.1. Metodologia proiectrii bazelor de date
3.1.1. Ce este o metodologie de proiectare?
Definiie: Metodologie de proiectare: O aproximare structurat, care utilizeaz proceduri,
tehnici, instrumente i documentaii pentru a facilita procesul de proiectare.
Metodologia de proiectare se compune din etape, care la rndul lor se compun din pai, care
orienteaz proiectantul la fiecare nivel al crerii bazei de date.
3.1.2. Proiectarea logic i fizic a bazei de date
Definiie: Proiectare logic: Procesul de construcie a unui model de informaii folosite
ntr-o ntreprindere, bazat pe modelul de date, dar independent de particularizrile sistemului de
gestiune a bazei de date i a altor considerente fizice.
Proiectarea logic ncepe cu crearea modelului conceptual al bazei de date, care este
independent de implementarea ntr-un SGBD. Modelul conceptual este apoi proiectat pe un model
logic, care va influena mai trziu modelul de date n care se va implementa.
17

Definiie: Proiectare fizic: Este procesul de descriere a implementrii bazei de date ntr-un
SGBD.
n aceast etap a proiectrii este creat baza de date ntr-un SGBD, mpreun cu procedurile
de actualizare. n aceast etap exist un feedback ntre proiectarea fizic i cea logic, pentru c
deciziile luate la implementarea fizic pot afecta baza de date logice.
3.2. Prezentarea metodologiei
n acest capitol vom prezenta o descriere a metodologiei de proiectare a bazelor de date.
Prima dat s vedem care sunt paii de urmat n proiectare:

Pasul 1. Proiectarea logic a bazei de date relaionale: Crearea unui model conceptual local,

Pasul

Pasul

Pasul

Pasul

pentru vederile utilizatorilor.


Pasul 1.1. Identificarea tipurilor de entiti.
Pasul 1.2. Identificarea tipurilor de relaii.
Pasul 1.3. Identificarea i atribuirea de atribute la tipurile de entiti i tipurile de relaii.
Pasul 1.4. Determinarea domeniilor de definiie a atributelor.
Pasul 1.5. Determinarea atributelor care compun cheile candidate i primare.
Pasul 1.6. Specializare/generalizare (pas opional).
Pasul 1.7. Desenarea diagramei entity-relationship.
Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.
2. Crearea i validarea modelului logic local.
Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.
Pasul 2.2. Crearea relaiilor pentru modelul logic local.
Pasul 2.3. Validarea modelului, utiliznd normalizarea.
Pasul 2.4. Validarea modelului din nou, utiliznd tranzaciile.
Pasul 2.5. Desenarea diagramei ER.
Pasul 2.6. Definirea regulilor de integritate a bazei de date.
Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.
3. Crearea i validarea modelului logic global de date.
Pasul 3.1. Compunerea modelelor logice locale ntr-un model logic global.
Pasul 3.2. Validarea modelului logic global.
Pasul 3.3. Verificarea posibilitii de a completa baza de date n viitor.
Pasul 3.4. Desenarea diagramei ER finale.
Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.
4. Proiectarea fizic i implementarea bazei de date relaionale: Translatarea modelului
logic global n SGBD.
Pasul 4.1. Proiectarea relaiilor de baz n SGBD.
Pasul 4.2. Crearea regulilor de integritate n SGBD.
5. Proiectarea i implementarea reprezentrii fizice.
Pasul 5.1. Analizarea tranzaciilor.
Pasul 5.2. Alegerea organizrii fiierelor.
Pasul 5.3. Alegerea indecilor secundari.
Pasul 5.4. Introducerea unei redundane controlate.
Pasul 5.5. Estimarea spaiului pe disc.
18

Pasul 6. Proiectarea i implementarea unui mecanism de securitate.


Pasul 6.1. Crearea view-urilor pentru utilizatori.
Pasul 6.2. Proiectarea regulilor de acces la baza de date.
Pasul 7. Verificarea sistemului operaional.
Proiectarea logic a bazei de date se divide n trei pai mari. Primul pas are ca obiectiv,
descompunerea proiectrii sistemului informatic n vederi, care se pot discuta cu utilizatorii
sistemului. Modelul de date astfel creat, se valideaz prin normalizare i prin tranzacii n pasul doi.
n final, se genereaz modelul global al ntreprinderii, care este la rndul lui validat i verificat cu
ajutorul utilizatorului sistemului.
Factori critici pentru succesul proiectrii logice:
Lucrul interactiv cu utilizatorul sistemului.
Folosirea unei metodologii structurate pentru procesul de proiectare a bazei de date.
ncorporarea regulilor de integritate n modelul logic de date.
Combinarea validrii conceptuale, prin normalizare i prin tranzactii, la proiectarea
modelului logic de baze de date.

Utilizarea diagramelor pentru a reprezenta ct mai multe modele logice posibile.

Crearea dicionarului de date, ca supliment al modelului de date.

3.3. Metodologia de proiectare a bazei de date logice


n acest capitol vom prezenta pas cu pas, proiectarea unei baze de date.
Pasul 1. Crearea modelului conceptual local, pentru utilizatori.
Obiectivul: Crearea unui model conceptual local, pentru view-urile utilizatorilor.
Primul pas n proiectarea bazei de date este de a colecta datele necesare pentru realizarea
sistemului, ceea ce putem culege, discutnd cu viitorii utilizatori ai bazei de date. Aceast discuie
presupune o desprire n vederi, a bazei de date, vederi care pot lucra separat.
Desprirea n vederi se poate realiza n mai multe moduri. O modalitate ar fi analiza datelor
globale i gsirea de pri relativ independente. O alt modalitate ar fii analiza rapoartelor,
procedurilor cerute i/sau observarea sistemului existent n lucru.
Modelele conceptuale locale trebuie s conin:

tipuri de entiti,

tipuri de relaii,

atribute,

domeniile atributelor,

cheile candidat,

chei primare
Paii din prima etap a proiectrii logice sunt:
Pasul 1.1. Identificarea tipurilor de entiti.

Pasul 1.2. Identificarea tipurilor de relaii.


Pasul 1.3. Identificarea i atribuirea de atribute la tipurile de entiti i tipurile de relaii.
Pasul 1.4. Determinarea domeniilor de definiie a atributelor.
Pasul 1.5. Determinarea atributelor care compun cheile candidate i primare.
19

Pasul 1.6. Specializare/generalizare (pas opional).


Pasul 1.7. Desenarea diagramei entity-relationship.
Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.

Pasul 1.1. Identificarea tipurilor de entiti


Obiectivul: Identificarea tipurilor de entiti principale n vederile utilizatorilor.
Primul pas n proiectarea bazei de date este identificarea entitilor din datele furnizate de
utilizatori. De exemplu, dac avem informaiile Nr_Mat, Nr_Bloc, Scara, Etaj, Apartament i
Nume, putem identifica entitatea Locatari. n general putem identifica entitile n mai multe
moduri. De exemplu n locul entitii Locatari, am putea crea o entitate Locatari cu atributele
Nr_Mat i Nume, iar celelalte informaii n entitatea ProprietateLocatari.
Exist cazuri cnd entitile sunt greu de identificat, pentru c modul de prezentare a
viitorilor utilizatori necesit explicaii. Utilizatorii descriu aceste entiti, folosind sinonime i
omonime, ceea ce ngreuneaz identificarea entitilor. Sinonimele prin care se descrie aceeai
entitate, se pot considera sinonime i la crearea modelului logic, evideniind aceste sinonime ca
diverse aliasuri ai entitilor.
Documentarea tipurilor de entiti
Dup identificarea entitilor, le dm cte un nume, iar aceste nume le vom evidenia n
dicionarul de date, mpreun cu explicaiile despre entiti, precum i posibilele aliasuri.
Pasul 1.2. Identificarea tipurilor de relaii
Obiectivul: Identificarea relaiilor importante dintre entiti.
Dup identificarea entitilor, va trebui s identificm i relaiile importante dintre aceste
entiti. Relaiile se descriu printr-un verb al relaiei. De exemplu:
Scrile sunt Locuite de Locatari

Furnizorii Provoac Cheltuieli

La identificarea relaiilor vom lua n considerare doar relaiile care ne intereseaz. Degeaba
exist i alte relaii care s se poat identificate, dac nu prezint importan pentru problema
noastr, atunci nu le lum n consideraie.
n cele mai multe din cazuri, relaiile sunt binare, adic se realizeaz ntrea exact dou
entiti. Exist i relaii mai complexe, care se realizeaz ntre mai multe entiti, sau relaii
recursive, care pune n relaie o singur entitate cu ea nsi.
Determinarea cardinalitii i a participrii la tipurile de relaii
Dup identificarea tipurilor de relaii, trebuie s determinm cardinalitatea lor, alegnd
dintre posibilitile: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Dac se
cunosc valori specifice ale cardinalitilor, aceste valori se scriu la documentarea relaiilor. n
continuare determinm i participarea la relaie, care poate fii total, sau parial.
Documentarea tipurilor de relaii
Dup identificarea tipurilor de relaii, le denumim i le introducem n dicionarul de date,
mpreun cu cardinalitatea i participarea lor.
Utilizarea modelrii ER
Pentru vizualizarea sistemelor complicate, utilizm diagrama ER, pentru c este mult mai
uor de a cuprinde toate informaiile. V propunem ca s utilizai ntotdeauna diagrama ER, pentru
o mai bun vizualizare a datelor.
Pasul 1.3. Identificarea i asocierea de atribute la tipurile de entiti i tipurile de relaii
20

Obiectivul: Asocierea de atribute la tipurile de entiti i la tipurile de relaii.


Urmtorul pas n metodologie este identificarea atributelor. Aceste atribute se identific n
aceeai mod ca i entitile. Pentru o mai uoar identificare, trebuie s lum entitile i relaiile la
rnd i s ne punem urmtoarea ntrebare: Ce informaii deinem despre aceast ? Rspunsul la
aceast ntrebare ne va da atributele cutate.
Atribute simple sau compuse
Este important s notm dac un atribut este simplu sau compus. Conform acestei informaii
va trebui s lum decizii referitoare la acel atribut. Dac un atribut este compus, atunci putem opta
pentru descompunerea sa, dac este necesar prelucrarea separat a datelor compuse, sau putem s-l
lsm compus n caz contrar.
De exemplu, atributul Adres conine informaiile (Nr_Bloc, Scara, Etaj, Apartament). Noi
va trebui s prelucrm aceste informaii separat, deci vom descompune acest atribut n cele patru
atribute simple.
Putem avea cazuri n care atributele simple s le compunem. De exemplu n cazul atributelor
Nume_Familie i Prenume, neavnd nevoie de aceste informaii separat, le vom compune n
atributul Nume.
Atribute derivate (calculate)
Sunt acele atribute, care se pot calcula din alte atribute existente n baza de date. De
exemplu numrul locatarilor de pe o scar se poate numra n tipul de entitate Locatari. Deci acest
atribut este atribut derivat.
n general aceste atribute nu trebuie incluse n modelul de date, pentru c n cazul n care se
modific atributul din care se calculeaz atributul derivat, trebuie s se modifice i acesta. n cazul
n care nu se modific, baza de date devine inconsistent. De aceea este important de a meniona
dac un atribut este sau nu derivat.
Dac identificm un atribut care s nu-l putem asocia nici unei entiti sau relaii, ne
ntoarcem la paii anteriori, identificnd noua relaie sau entitate la care s asociem atributul
respectiv.
n cazul n care putem asocia acelai atribut la mai multe entiti, atunci va trebui s
decidem dac generalizm sau nu aceste entiti, proces care este descris la pasul 1.6.
Documentarea atributelor
Dup identificarea atributelor, le asociem un nume, i le nregistrm n dicionarul de date,
mpreun cu urmtoarele informaii:
numele i descrierea atributului,

toate aliasurile i sinonimele prin care este cunoscut atributul,


tipul de date i lungimea,
valorile iniiale ale atributelor (dac exist),
dac atributul accept sau nu valoarea nul,
dac atributul este sau nu compus, i dac este atunci atributele simple care le compun,
dac atributul este sau nu derivat i atributul din care se deriv,
dac atributul accept sau nu mai multe valori.

Pasul 1.4. Determinarea domeniului atributelor


Obiectivul: Determinarea domeniului atributelor n modelul conceptual local.
Domeniul atributului este o mulime de valori pe care o poate lua. Pentru a controla n
totalitate domeniul atributelor, se poate evidenia urmtoarele:
setul de valori admisibile pentru un atribut,

operaiile admisibile asupra unui atribut,


21

ce atribute se pot compara cu atributul respectiv, n combinaiile cu alte atribute,


mrimea i formatul cmpului atributului.
Documentarea domeniilor atributelor
Actualizm dicionarul de date cu domeniul de definiie a fiecrui atribut.
Pasul 1.5. Determinarea atributelor care compun cheile candidat i primare
Obiectivul: Identificarea cheilor candidat pentru fiecare entitate i alegerea cheilor primare
n cazul n care sunt mai multe chei candidat.
Identificarea cheilor i selectarea cheilor primare
O cheie candidat este un atribut, sau un grup de atribute care identific unic fiecare
nregistrare din tipul de entitate. Putem identifica una, sau mai multe chei candidat. n acest caz
trebuie s alegem dintre ele o cheie primar. Cheile candidat care nu sunt primare, se vor numii chei
alternante. Pentru alegerea unei chei ca fiind cheie primar, vom ine cont de urmtoarele:
cheia candidat, care are un numr minimal de atribute,

cheia candidat, care i va schimba cel mai rar valoarea,


cheia candidat, care este cel mai puin probabil s sufere modificri n viitor,
cheia candidat, care este compus din cele mai puine caractere (n cazul atributelor de tip
caracter),
cheia candidat, care este cel mai uor de folosit din punctul de vedere al utilizatorului.
Prin procesul de identificare a cheilor primare, deducem i dac o entitate este entitate
tare, sau entitate slab. Dac reuim s identificm o cheie primar, atunci entitatea este tare,
altfel este slab. O entitate slab nu poate exista fr o entitate tare, care s-i fie printe. Cheia
primar a entitii slabe este derivat parial sau total din cheia primar a entitii tari.
Documentarea cheilor primare i alternante
nscriem cheile primare i pe cele alternante n dicionarul de date.
Pasul 1.6. Specializarea/generalizarea tipurile de entiti (pas opional)
Obiectivul: Identificarea entitilor subclas respectiv superclas, ntre entitile apropiate.
n acest pas putem opta pentru a continua modelarea ER, folosind procesul de generalizare
sau specializare. Dac alegem procesul de specializare, vom ncerca s definim unul, sau mai multe
subclase ai entitii respective. Dac ns alegem procesul de generalizare, vom cuta superclase
pentru acea entitate.
Un exemplu pentru procesul de generalizare ar fii entitile ef_de_scar i Familii. Ambele
entiti au atribuite urmtoarele atribute: Nr_mat, Nr_bloc, Scara, Etaj, Apartament i Nume. Pe
lng aceste atribute, entitatea ef_de_scar mai are asociate atributul Data_intrare_func; iar
entitatea Familii, atributele Nr_pers, Nr_pers_prezente i Nr_chei. Deci, cele dou entiti avnd
atribute n comun, le putem generaliza n entitatea Locatari, care va conine atributele comune, i
entitile ef_de_scar i Familii, coninnd doar atributele diferite - particularizrile fa de
superclas.
Pasul 1.7. Desenarea diagramei ER.
Obiectivul: Desenarea unei diagrame ER. care va fi reprezentarea conceptual a vederilor
utilizatorilor despre ntreprindere.
n momentul acesta suntem n msur s prezentm o diagram complet a modelului bazat
pe vederile utilizatorilor despre ntreprindere.
22

Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului


Obiectivul: Verificarea modelului conceptual local cu ajutorul utilizatorului, pentru a vedea
dac modelul este o reprezentare adevrat a vederii utilizatorului despre ntreprindere.
nainte de a termina pasul 1, trebuie verificat modelul conceptual elaborat. Acest model
include diagrama ER i documentaia anexat. n cazul n care apare orice fel de anomalie, repetm
procesul de mai nainte i remediem problema.
Pasul 2. Crearea i validarea modelului logic local
Obiectivul: Crearea unui model logic local bazat pe modelul conceptual al utilizatorilor
asupra ntreprinderii i validarea ei prin procesul de normalizare i prin tehnica tranzaciilor cerute.
n acest pas verificm modelul conceptual creat n pasul anterior i eliminm din el
structurile care sunt dificil de realizat ntr-un SGBD. Dac la sfritul acestui proces modelul
alterat, vom corecta aceste probleme i ne vom referii n continuare la modelul rezultat, ca fiind
modelul logic local. Vom valida modelul logic prin procesul de normalizare i a tranzaciilor.
Activitile din acest pas sunt:
Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.

Pasul 2.2. Crearea relaiilor pentru modelul logic local.


Pasul 2.3. Validarea modelului, utiliznd normalizarea.
Pasul 2.4. Validarea modelului din nou, utiliznd tranzaciile.
Pasul 2.5. Desenarea diagramei ER.
Pasul 2.6. Definirea regulilor de integritate a bazei de date.
Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.
Pasul 2.1. Proiectarea modelului conceptual local pe modelul logic local

Obiectivul: Verificarea modelului conceptual local pentru eliminarea structurilor care se pot
implementa greu ntr-un SGBD i proiectarea modelului rezultat la modelul logic local.
n pasul nti am pregtit un model conceptual bazat pe informaiile date de utilizator. Acest
model trebuie prelucrat, pentru a putea fi uor de prelucrat de sistemul de gestiune a bazelor de date.
Obiectivele acestui pas sunt:
(1) Eliminarea relaiilor M:N.
(2) Eliminarea relaiilor complexe.
(3) Eliminarea relaiilor recursive.
(4) Eliminarea relaiilor cu atribute.
(5) Reexaminarea relaiilor 1:1.
(6) Eliminarea relaiilor redundante.
(1) Eliminarea relaiilor multe-la-multe
Dac n modelul de date apar relaii de tipul multe-la-multe (M:N), trebuie descompuse n
dou relaii unu-la-multe (1:M) prin adugarea unei noi entiti suplimentare.
De exemplu, pot exista mai multe cheltuieli pentru o scar, dar i o cheltuial (factur) poate
s se refere la mai multe scri. Deci relaia dintre entitatea Scri i entitatea Cheltuieli este de M:N,
ceea de este evideniat n figura 3.1.(a).

23

Scari
Nr_Bloc
Scara
Lift

Cheltuieli
Nr_Crt
Cod_Cheltuiala (FK)
Cod_Furnizor (FK)
Nr_factura
Data_factura
Valoare_factura

Cheltuieli

Scari
Nr_Bloc
Scara
Lift

Sunt platite de

Nr_Crt

Pe scari
Scara (FK)
Nr_Crt (FK)
Nr_Bloc (FK)

Au cheltuieli

Cod_Furnizor (FK)
Cod_cheltuiala
Nr_factura
Data_factura
Valoare_factura

Se calculeaza

Figura 3.1. (a). Relaie de tipul N:M. (b). Relaie transformat n dou relaii 1:M.
Aceast relaie se poate elimina, prin crearea unui tip de entitate suplimentar, care s fac
legtura dintre scri i cheltuieli. Diagrama acestor relaii se vede n figura 3.1.(b).
Notm, c tipul de entitate nou creat - Pe_scri - este tip de entitate slab, pentru c depinde
att de tipul de entitate Scri, ct i de tipul de entitate Cheltuieli.
(2) Eliminarea relaiilor complexe
O relaie complex este o relaie ntre mai mult de dou tipuri de entiti. Dac n modelul
conceptual apar relaii complexe, acestea trebuie eliminate. Se pot elimina prin crearea unui nou tip
de entitate, care s fie n relaie de tipul 1:M cu fiecare tip de entitate din relaia iniial, partea cu M
a relaiei fiind spre tipul de entitate nou creat.
(3) Eliminarea relaiilor recursive
Relaiile recursive sunt nite relaii particulare, prin care un tip de entitate este n relaie cu
el nsi. Dac apare o astfel de relaie n modelul conceptual, ea trebuie eliminat. Eliminarea se
poate rezolva prin crearea unei noi entiti unde s se evidenieze fiecare entitate care este legat de
entitatea din tipul de entitate iniial. n acest caz vom avea o relaie de tipul 1:M ntre tipul de
entitate iniial i tipul de entitate nou creat i o relaie de tipul 1:1 ntre tipul de entitate nou creat i
tipul de entitate iniial.
(4) Eliminarea relaiilor cu atribute
Dac n modelul conceptual avem relaii cu atribute, putem descompune aceast relaie,
identificnd un nou tip de entitate n care s nregistrm atributele necesare.
(5) Reexaminarea relaiilor de tipul 1:1
n modelul conceptual putem avea entiti ntre care s avem relaie de
tipul 1:1. Se
poate ntmpla ca aceste entiti s fie de fapt aceeai entitate cu nume diferite. Dac suntem n
acest caz, unim cele dou entiti, cheia primar devenind cheia primar al uneia dintre entiti.
(6) Eliminarea relaiilor redundante
O relaie este redundant dac se poate ajunge de la un tip de entitate la alt tip de entitate pe
mai multe drumuri. V amintim c noi vrem s ajungem la un model minimal i deci relaiile
redundante nu sunt necesare. Decizia ca o relaie este redundant trebuie s fie precedat de o
analiz amnunit a relaiilor care compun cele dou drumuri dintre cele dou entiti, pentru c
pot aprea situaii, cnd o relaie este aparent redundant, dar n realitate este nevoie de ea.
n finalul acestui pas putem spune c am eliminat din modelul conceptual acele structuri
care sunt dificil de implementat i deci este mai corect ca n continuare s ne referim la acest model
ca fiind un model logic local de date.
Pasul 2.2. Crearea de relaii peste modelul logic local
Obiectivul: Crearea de relaii peste modelul logic.
24

Relaia pe care un tip de entitate o are cu alt tip de entitate este reprezentat prin mecanismul
cheie primar/cheie strin. Cheia strin pentru o entitate este reproducerea cheii primare altei
entiti. Pentru a decide entitile unde vom include copia cheii primare a altei entiti, trebuie
nainte s identificm entitile printe i fiu. Entitile printe se refer la acele entiti ale
cror chei primare se vor copia n entitile fiu.
Pentru descrierea relaiilor vom folosii un limbaj de definire a bazei de date (Database
Definition Language - DBDL). n acest limbaj, specificm prima dat numele entitii, urmat de
atributele asociate ntre paranteze. Dup aceea identificm cheia primar i toate cheile alternante,
precum i/sau cheile strine.
Tipuri de entitate tari
Pentru tipurile de entiti tari n modelul logic crearea unei relaii include toate atributele
entitii. Pentru atributele compuse al unei entiti, vom include numai atributele simple din
compunerea atributului compus n descrierea entitii.
De exemplu tipul de entitate Familii, prezentat n figura 3.2. se descrie n urmtorul mod.
Familii (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers,
Nr_pers_prezente, Nr_chei)
Cheie primar: Nr_mat
Familii
Nr_Mat
Nr_pers
Nr_pers_prezente
Nr_chei
Nr_Bloc
Scara
Etaj
Apartament
Fond_rulment
Fond_reparatii
Alte_fonduri

Plati
Data
Nr_Mat (FK)
Valoare
Restanta

Trebuie sa plateasca
Figura 3.2. Exemplu de model logic.
Tipurile de entiti slabe
Descrierea tipurilor de entiti slabe se face la fel ca i tipurile de entiti tari, cu o
completare i anume, evidenierea cheii strine. De exemplu descrierea tipului de entitate de mai sus
se descrie astfel:
Pli (Data, Nr_mat, Valoare, Restan)
Cheie primar: Data, Nr_mat
Cheie strin: Nr_mat se refer la Familii(Nr_mat)
Menionm c n cazul acesta cheia strin este i n compunerea chei primare. Deci nainte
de introducerea cheii strine, cheia primar nu identifica unic o entitate. La terminarea acestui pas,
putem identifica cheile primare pentru toate tipurile de entiti din modelul logic.
Tipurile de relaii binare de tipul unu-la-unu (1:1)
25

Pentru fiecare tip de relaie binar de tipul 1:1 ntre dou tipuri de entitate E1 i E2 gsim o
copie a cheii primare a tipului de entitate E1 n compunerea tipului de entitate E2, sub denumirea de
cheie strin. Identificarea tipului de entitate printe i a tipului de entitate fiu depinde de
participarea entitilor la relaie. Tipul de entitate care particip parial la relaie este desemnat ca
fiind printe iar cel cu participare total fiu. Dac ambele tipuri de entitate particip parial sau
total la relaie, atunci tipurile de entiti se pot evidenia ca fiind printe sau fiu arbitrar. n
cazul n care participarea este total, putem ncerca s combinm cele dou tipuri de entiti ntr-una
singur. Aceast compunere poate s fie posibil n cazul n care nici unul dintre cele dou tipuri de
entiti nu mai ia parte la alt relaie.
Tipurile de relaii binare de tipul unu-la-multe 1:M
Pentru toate relaiile 1:M ntre dou entiti E1 i E2 n modelul logic de date, vom avea
copia cheii primare a entitii E1 n compunerea entitii E2. Totdeauna entitatea de partea unu a
relaiei este considerat entitate printe, iar cealalt entitate fiu.
Atributele cu mai multe valori
Pentru fiecare atribut A care permite mai multe valori din entitatea E1 n modelul logic de
date, crem o nou relaie care va conine atributul A mpreun cu cheia primar a entitii E1 pe
post de cheie strin. Cheia primar a noii relaii va fi atributul A, sau dac este necesar,
compunerea ei cu cheia primar al lui E1.
Relaiile superclas/subclas
Pentru fiecare relaie superclas/subclas vom identifica superclasa ca fiind entitatea
printe, iar subclasa entitatea fiu. Exist multe moduri de a reprezenta relaia aceasta. De
exemplu s lum relaia prezentat n figura 3.3.
(Opiunea 1)
Locatari (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume,
Data_intrare_func, Nr_pers, Nr_pers_prez, Nr_chei)
Cheie primar: Nr_mat
(Opiunea 2)
Familii (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume,
Nr_pers, Nr_pers_prez, Nr_chei)
Cheie primar: Nr_mat
ef_de_scar (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume,
Data_intrare_func)
Cheie primar: Nr_mat
(Opiunea 3)
Locatari (Nr_mat, Nr_bloc, Scara, Apartament, Nume)
Cheie primar: Nr_mat
ef_de_scar (Nr_mat, Data_intrare_func)
Cheie primar: Nr_mat
Cheie strin : Nr_mat referire la Locatari(Nr_mat)
Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)
Cheie primar: Nr_mat
Cheie strin : Nr_mat referire la Locatari(Nr_mat)

26

Locatari
Nr_Mat
Nr_Bloc (FK)
Scara (FK)
Etaj
Apartament
Nume

Cap familie

Sef de scara

Nr_Mat (FK)

Nr_Mat (FK)
Data_intrare_fun
c

Nr_pers
Nr_pers_prezent
e
Nr_chei
Fond_rulmen
tFond_reparati
iAlte_fonduri

Figura 3.3. Exemplu de relaie superclas/subclas


Documentarea relaiilor i a atributelor din cheile strine
Actualizm dicionarul de date, introducnd fiecare atribut nou introdus n compunerea unei
chei la acest pas.
Pasul 2.3. Validarea, utiliznd normalizarea
Obiectivul: Validarea modelului logic, utiliznd tehnica normalizrii.
Examinm procesul de normalizare dup cum am descris n capitolul 2. Prin normalizare
trebuie s demonstrm c modelul creat este consistent, conine redundan minimal i are
stabilitate maxim.
Normalizarea este procesul prin care se decide dac atributele pot sau nu s rmn
mpreun. Conceptul de baz a teoriei relaiilor este c atributele sunt grupate mpreun pentru c
exist o relaie logic ntre ele. Cteodat baza de date nu este cea mai eficient. Acesta se
argumenteaz prin urmtoarele:
Proiectarea normalizat organizeaz datele n funcie de dependenele funcionale. Deci acest
proces este situat undeva ntre proiectarea conceptual i cea fizic.
Proiectul logic nu este un proiect final. El ajut proiectantul s neleag natura datelor n
ntreprindere. Proiectul fizic poate fi diferit. Exist posibilitatea ca unele tipuri de entiti s se
denormalizeze. Totui normalizarea nu este un timp pierdut.
Proiectul normalizat este robust i independent de anomaliile de actualizare prezentate n
capitolul 2.
Calculatoarele moderne au mult mai mult putere de calcul, ca cele de acum civa ani. Din
aceast cauz, cteodat este mai convenabil implementarea unei baze de date cu puin
redundan, dect suportarea cheltuielilor pentru procedurile adiionale.
Normalizarea produce o baz de date care va fi uor extensibil n viitor.
Procesul de normalizare include urmtoarele etape mari:
Forma Normal Unu (1NF), eliminarea grupurilor repetitive;
27

Forma Normal Doi (2NF), eliminarea dependenelor pariale de cheia primar;


Forma Normal Trei (3NF), eliminarea dependenelor tranzitive de cheia primar;
Forma Normal Boyce-Codd (BCNF), eliminarea anomaliilor care au mai rmas.
Pasul 2.4. Validarea modelului prin tranzacii
Obiectivul: Verificarea ca modelul de date suporte toate tranzaciile cerute de utilizator.
n acest pas se valideaz baza de date prin verificarea tranzaciilor ce se cer de utilizator.
Lund n considerare tipurile de entiti, relaiile, cheile primare i strine, ncercm s rezolvm
manual cerinele utilizatorilor. Dac reuim s rezolvm fiecare tranzacie cerut, atunci nseamn
c modelul creat este valid. Dac nu putem rezolva o tranzacie, atunci este foarte posibil s fi omis
un atribut, o relaie, sau o entitate din modelul de date.
Trebuie s examinm n dou posibiliti, dac baza de date suport tranzaciile cerute. Una
dintre ele ar fi prin rezolvarea de tranzacii. De exemplu s lum relaia dintre Furnizori i
Cheltuieli exemplificat n figura 3.4.
Furnizori

Cheltuieli
Nr_Crt

Cod_Furnizor

Cod_Furnizor (FK)
Cod_cheltuiala
Nr_factura
Data_factura
Valoare_factura

Denumire
Cod_fiscal (AK1)
Cont
Banca
Strada
Nr
Bl
Sc
Ap
Localitate
Judet

Provoaca

Figura 3.4. Exemplu de relaie pentru validarea prin tranzacii.


Inserarea de detalii despre un nou furnizor.
Cheia primar al acestei entiti este Nr_furnizor. Deci prima dat verific dac numrul
introdus nu exist deja; dup care n caz c nu exist acest cod, inserez detaliile despre furnizor.
Dac exist deja codul, nu admit inserarea. Pot verifica i existena codului fiscal, care pentru
aceast entitate este cheie alternant.
tergerea detaliilor despre un furnizor
Se caut codul furnizorului de ters. Dac exist se terge furnizorul, actualizndu-se i
cheia strin n entitatea Cheltuieli. Dac nu exist codul cerut, atunci apare un mesaj de eroare i
nu este ters nici un furnizor.
A doua modalitate de verificare trebuie folosit n cazul n care avem entiti care nu iau
parte direct la nici o tranzacie. Pentru verificarea acestor entiti, vom verifica nite interogri
pregtite special.
Pasul 2.5. Desenarea diagramei ER.
Obiectivul: Desenarea diagramei Entity-Relationship, care este reprezentarea logic a
vederilor utilizatorilor aspra ntreprinderii.
28

Pasul 2.6. Identificarea regulilor de integritate.


Obiectivul: Identificarea regulilor de integritate pentru vederile utilizatorilor asupra
ntreprinderii.
Regulile de integritate sunt importante pentru a proteja baza de date mpotriva posibilelor
inconsistene. Dac este necesar, putem produce un proiect fizic de baz de date, pentru a putea
vedea mai uor ce reguli sunt necesare.
Vom considera cinci tipuri de reguli de integritate:
necesitatea datelor,

reguli asupra domeniului atributelor,


integritatea entitilor,
integritatea referinelor,
regulile ntreprinderii.

Necesitatea datelor
Exist atribute care nu pot conine valoarea nul, ci trebuie s aib totdeauna o valoare. De
exemplu fiecare cheltuial nregistrat trebuie s aib asociat un furnizor al serviciilor sau al
obiectelor ce se pltesc prin acea cheltuial.
Aceste reguli deja le-am identificat, cnd am documentat atributele n pasul 1.3.
Reguli asupra domeniului atributelor.
Unele atribute au un domeniu de definiie bine definit. Aceste domenii trebuie respectate.
Domeniile de definiie au fost deja identificate cnd am documentat domeniile atributelor n pasul
1.4.
Integritatea entitilor.
Cheia primar a entitilor nu poate lua valori nule. De exemplu fiacare furnizor trebuie s
aib un cod diferit de zero.
Aceste reguli au fost deja identificate, cnd am documentat cheile primare n pasul 1.5.
Integritatea referinelor
Cheia strin din tipul de entitate fiu face legtura cu o entitate din tipul de entitate
printe. Deci, dac cheia strin conine o valoare, ea trebuie neaprat s se regseasc i n tipul
de entitate printe. De exemplu tipul de entitate Cheltuieli conine cheia strin Cod_furnizor,
care se refer la Furnizori(Cod_furnizor). Dac aceast cheie nu este nul, atunci trebuie s gsim
un furnizor care s aib acel cod.
Prima ntrebare pe care trebuie s ne-o punem este: Poate fii cheia strin nul? n cazul
exemplului nostru asta ar nsemna c exist cheltuieli care nu se pltesc nimnui. Aceste cazuri nu
sunt admise de lege, deci nu putem avea valoare nul n cheia strin din tipul de entitate Cheltuieli.
n general dac participarea tipului de entitate fiu este total, atunci nu putem avea valoare
nul n cheia strin. n caz contrar putem avea valoare nul.
Pentru a demonstra diferitele cazuri la definirea acestor reguli, folosim relaia de mai sus
dintre Furnizori i Cheltuieli, care este de tipul 1:M. Considerm urmtoarele cazuri:
Cazul 1: Inserarea unei entiti n tipul de entitate fiu (Cheltuieli): Pentru a verifica
integritatea referinei, verificm dac atributele din componena cheii strine (Cod_furnizor) sunt
vide, sau s existe entitate n tipul de entitate printe care s aib valoare cheii primare egal cu
valoare cheii strine.
Cazul 2: tergerea unei entiti din tipul de entitate fiu (Cheltuieli): tergerea unei
entiti din tipul de entitate fiu nu cauzeaz probleme cu privin la integritatea referinelor.
29

Cazul 3: Actualizarea cheii strine n tipul de entitate fiu (Cheltuieli): Acest caz este
similar cazului 1.
Cazul 4: tergerea unei entiti din tipul de entitate printe (Furnizori): Dac se terge o
entitate din tipul de entitate printe, integritatea referinelor se stric n cazul n care exist entiti
n tipul de entitate fiu, care se refer la entitatea tears. Exist strategii severe de a rezolva
integritatea referinelor:
FR ACIUNE Neacceptarea tergerii unei entiti din tipul de entitate printe, dac acesta
este referit de o entitate din tipul de entitate fiu. n cazul nostru, nu se accept tergerea
furnizorului, dac el are o factur de ncasat.
CASCAD
Dac o entitate din tipul de entitate printe este tears, se terg automat toate
entitile din tipurile de entiti fiu. Dac tipurile de entiti fiu au i ei la rndul lor alte tipuri de
entiti fiu, se va efectua tergerea n cascad n toate tipurile de entiti fiu, pn la ultimul nivel.
Cu alte cuvinte, dac se terge un furnizor, atunci automat se terge fiecare factur pe care o are
de ncasat acest furnizor.
SETARE LA NUL Dac o entitate din tipul de entitate printe se terge, atunci se vor seta la
valoare nul toate cheile strine ai tipurilor de entiti fiu n cascad pn la ultimul nivel. n
exemplul nostru, dac se terge un furnizor, atunci se vor seta la valoare nul toate referinele la
acest furnizor n tipul de entitate Cheltuieli. Acesta nseamn c nu vom tii ca anumite cheltuieli
la ce furnizor trebuie pltite.
SETARE IMPLICIT
Este analog cazului de setare la nul, cu diferena c aici se seteaz
cheia strin la o valoare implicit n loc de valoare nul. n exemplul nostru putem seta cheia
strin din Cheltuieli la o valoare a cheii primare din Furnizori, care s conin un furnizor
predefinit - de exemplu cu numele de Furnizor ters.
FR MODIFICARE n cazul tergerii unei entiti din tipul de entitate printe, nu se
actualizeaz deloc cheile strine din tipurile de entiti fiu.
Cazul 6: Modificarea cheii primare n tipul de entitate printe (Furnizori): Dac se
modific cheia primar din tipul de entitate printe, integritatea referinelor se stric. Pentru
meninerea integritii, se pot folosii toate cazurile descrise mai sus, dar cel mai indicat este
folosirea cazului CASCAD.
Regulile ntreprinderii.
n final evideniem acele reguli care sunt date de realitatea ce se va modela n baza de date.
Documentarea tuturor regulilor de integritate.
Trecem toate regulile de integritate n dicionarul de date.
Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.
Obiectivul: Convingerea c modelul creat reprezint n totalitate realitatea care trebuie
modelat n baza de date.
La acest pas modelul local logic este complet i este bine documentat. nainte de a trece la
pasul 3, trebuie verificat modelul, s fie conform cu realitatea. n cazul n care se gsesc diferene,
ne vom rentoarce la paii anteriori i modificm cele necesare.
Pasul 3. Crearea i validarea modelului global logic de date.
Obiectivul: Combinarea modelelor locale logice ntr-un model logic global care s
reprezinte ntreprinderea care este modelat.
30

A treia activitate major n proiectarea bazei de date logice este crearea modelului logic
global, prin compunerea tuturor modelelor locale. Dup combinarea modelelor locale, trebuie
validat modelul global prin tehnica de normalizare, dup care prin tehnica tranzaciilor. Acest
proces utilizeaz aceleai tehnici pe care le-am descris la paii 2.3. i 2.4.
Acest proces este foarte important n proiectarea bazei de date, pentru c el demonstreaz c
reprezentarea ntreprinderii este independent de orice utilizator, funcie sau aplicaie. Activitile
din acest pas sunt:
Pasul 3.1. Compunerea modelelor logice locale ntr-un model logic global.

Pasul 3.2. Validarea modelului logic global.


Pasul 3.3. Verificarea posibilitii de a completa baza de date n viitor.
Pasul 3.4. Desenarea diagramei ER finale.
Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.
Pasul 3.1. Compunerea modelelor logice locale ntr-un model logic global.

Obiectivul: Compunerea tuturor modelelor logice locale ntr-un model logic global al
ntreprinderii.
n cazul unui sistem mic, cu puine vederi ai utilizatorilor, este relativ uor de a compune
modelele logice locale. n cazul unui sistem mai mare ns, trebuie s urmm un proces sistematic
de realizare a modelului global. Paii acestui proces sunt urmtoarele:
(1) Verificarea numelor entitilor i a cheilor lor primare.
(2) Verificarea numelor relaiilor.
(3) Compunerea entitilor de pe view-urile locale.
(4) Includerea (fr compunere) a entitilor care apar pe doar una dintre view-uri.
(5) Compunerea relaiilor de pe view-urile locale.
(6) Includerea (fr compunere) a relaiilor care apar pe doar una dintre view-uri.
(7) Cutarea entitilor i a relaiilor care lipsesc (dac exist).
(8) Cutarea cheilor strine.
(9) Cutarea regulilor de integritate.
(10) Desenarea modelului logic global.
(11) Actualizarea documentaiei.
Cel mai uor de compus mai multe modele locale este compunerea succesiv a dou cte
dou dintre modele.
(1) Verificarea numelor entitilor i a cheilor lor primare.
Aceast verificare se face folosind i dicionarul creat n decursul pailor de dinainte.
Probleme apar doar atunci cnd:
Dou entiti au acelai nume, dar sunt de fapt diferii.

Dou entiti sunt aceleai, dar nu au aceleai nume.

Probabil va fi necesar analizarea atributelor entitilor, pentru a rezolva aceast problem.


n particular, putem utiliza cheia primar i numele entitii, pentru a identifica entitile
echivalente.
(2) Verificarea numelor relaiilor.
Aceast activitate este asemntoare celui descris la entiti.
(3) Compunerea entitilor de pe view-urile locale.
31

Examinm numele i atributele entitilor ca vor fi compuse. Activitile care se includ n


acest pas sunt:
Compunerea entitilor care au aceleai nume i aceleai chei primare.

Compunerea entitilor care au aceleai nume, dar cu chei primare diferite.


Compunerea entitilor care au nume diferite, cu chei primare egale sau diferite.
Compunerea entitilor care au aceleai nume i aceleai chei primare. n general entitile
cu aceleai chei primare reprezint lumea real, i deci pot fi compuse. Atributele care apar n
entitile de pe ambele view-uri, vor fi trecute doar o singur dat. Dac ntr-un view apare un
atribut compus, iar ntr-un alt view acelai atribut dar descompus n atribute simple, atunci vom
ntreba, dac se poate, utilizatorii pentru a decide asupra formei de utilizare a atributului.
Compunerea entitilor care au aceleai nume, dar au chei primare diferite. n astfel de
situaii, cutm dou entiti care au aceleai nume i nu au aceleai chei primare, dar au aceleai
chei candidat. Cele dou entiti pot fi compuse, urmnd ca dup compunere s alegem o cheie
primar, restul rmnnd chei alternante.
Compunerea entitilor care nu au nume comune i nu au aceleai chei primare. Aceste
entiti se pot depista prin analiza atributelor celor dou entiti.
(4) Includerea (fr compunere) a entitilor care apar doar ntr-un view.
Pasul anterior identific toate entitile comune. Celelalte entiti, se vor include n modelul
logic global exact aa cum apar n view-ul respectiv.
(5) Compunerea relaiilor de pe modelele locale.
n acest pas analizm similitudinile dintre relaii de pe diferite modele locale. n timpul
compunerii relaiilor trebuie rezolvate i conflictele dintre relaii, ca i regulile de cardinalitate i
participare. Putem compune relaii care au aceleai nume i acelai scop, sau acelai scop, dar nume
diferite.
(6) Includerea (fr compunere) a relaiilor care apar doar pe un view.
Relaiile care au rmas neincluse n modelul global dup pasul anterior, se includ n modelul
global fr modificare.
(7) Cutarea entitilor i relaiilor care lipsesc.
Este unul din cei mai grei pai din crearea modelului global. Trebuie cutate acele entiti i
relaii, care s-au omis la paii anteriori i n-au ajuns n modelul global.
(8) Cutarea cheilor strine.
n decursul pailor anterioare, s-au modificat entiti, chei primare i chei strine. n acest
pas verificm dac cheile strine sunt corecte n fiecare entitate fiu i efectum toate modificrile
necesare.
(9) Cutarea regulilor de integritate
Verificm dac regulile de integritate a modelului global nu sunt n conflict cu regulile
definite la modelele locale. Fiecare problem de acest gen se rezolv cu ajutorul utilizatorului
sistemului.
(10) Desenarea diagramei ER.
Acum desenm diagrama ER pentru modelul global de date.
(11) Actualizarea documentaiei.
Actualizm documentaia, ca s reflecte toate modificrile aduse n acest pas modelului.
Pasul 3.2. Validarea modelului logic global.
Obiectivul: Validarea modelului global logic de date, folosind normalizarea, dup care
folosind tranzaciile cerute.
Acest pas este echivalent cu paii 2.3. i 2.4., unde am validat modelul local de date.
32

Pasul 3.3. Verificarea posibilitilor de extindere a bazei de date n viitor.


Obiectivul: Determinarea ca dac modelul se acomodeaz uor la modificri orict de mari
ce pot intervenii n viitor.
Este important ca modelul creat s fie expansibil n viitor. Dac modelul nu are aceast
calitate, viaa lui poate fi scurt i pentru o mai mare modificare va trebui refcut de la nceput.
Pasul 3.4. Desenarea diagramei Entity-Relationship finale.
Obiectivul: Desenarea unei diagrame ER, care s reprezinte modelul global de date al
ntreprinderii.
Pasul 3.5. Verificarea modelului global cu ajutorul utilizatorului.
Obiectivul: Verificarea c modelul global reprezint n totalitate realitatea.
n acest moment modelul global este complet i documentat. mpreun cu utilizatorul
sistemului se verific acest model i se aduc eventualele corecturi prin ntoarcerea la paii n cauz.

33