Sunteți pe pagina 1din 27

CAPITOLUL 4.

BAZE DE DATE ŞI BAZE DE CUNOŞTINŢE: PROIECTARE,


ORGANIZARE, MANAGEMENT

4.1. Introducere în metodologia de proiectare a bazelor de date (BD)

Metodologia de proiectare, constă într-o abordare structurată, în care se


utilizează proceduri, tehnici, instrumente şi documentaţii, pentru a susţine şi
facilita procesul de proiectare.
O metodologie de proiectare constă în mai multe faze, conţinând etape
care îndruma proiectantul în alegerea tehnicilor adecvate fiecărei etape a
proiectului; de asemenea îl ajuta la: planificare, administrare, control şi
evaluarea proiectelor de dezvoltare a bazelor de date. În final are loc o abordare
structurată de analiză şi modelare a unui set de cerinţe privind BD, într-o
manieră standardizată şi organizată.
Metodologia de proiectare a BD, consta din trei faze principale:
4.1.1. Proiectarea conceptuală a BD
Această fază F1, reprezintă procesul de constituire a unui model al
informaţiilor utilizate în cadrul unei întreprinderi, independent de toate
consideraţiile de ordin fizic.
4.1.2. Proiectarea logică a BD
Această fază F2, constă în procesul de construire a unui model al
informaţiilor utilizate în cadrul unei întreprinderi, baza pe un anumit model de
date, dar independent de un anumit SGBD şi de alte considerente de ordin fizic.
4.1.3. Proiectarea fizică a BD
Această fază F3 reprezintă procesul de realizare a unei descrieri a
implementării bazei de date într-o capacitate de memorare secundară; descrie
structuri de memorare şi metode de acces utilizate pentru realizarea unui acces
eficient la date.

4.2. Proiectarea fizică a BD


Următoarele aspecte s-ar putea dovedi de importanţă pentru succesul
proiectării BD:
■ lucrul interactiv cu utilizatorii cât de mulţi trebuie;
■ urmărirea unei metodologii structurate de-a lungul procesului de
modelare a datelor;
■ utilizarea unei abordări coordonată prin date;

■ încorporarea consideraţiilor structurale şi de integritate în modelul


de date;
■ combinarea tehnicilor de conceptualizare, normalizare şi validare a
tranzacţiilor în metodologia de modelare a datelor;

46
■ utilizarea diagramelor, pentru a reprezenta cât mai mult din
modelul de date;
■ utilizarea unui limbaj de proiectare a BD Data Base Design
Language (BDDL) pentru a reprezenta semantica suplimentară a
datelor;
■ construirea unui dicţionar care să suplimenteze diagramele
modelului de date;
■ disponibilitatea de a repeta anumite etape.
Metodologia de proiectare a BD constă dintr-o serie de etape:

4.3. Proiectarea conceptuală a BD (etape)


E1. Constituirea modelului de date conceptual local, pentru fiecare vedere a
utilizatorului.
E1.1. Identificarea tipurilor de entităţi
E1.2. Identificarea tipurilor de relaţii
E1.3. Identificarea şi asocierea atributelor cu tipurile de entităţi sau
relaţii
E1.4. Determinarea domeniilor atributelor
E1.5. Determinarea atributelor cheie candidat şi primare
E1.6. Specializarea/generalizarea tipurilor de identităţi
E1.7. Desenarea diagramei Entitate-Relaţie
E1.8. Revizuirea modelului de date conceptual local, împreună cu
utilizatorul
Faza de proiectare conceptuală a bazelor de date începe cu crearea unui
model de date conceptual al întreprinderii, care este total independent de
detaliile privind implementarea, cum ar fi elementele de software ale sistemului
SG-BD ţintă, programele aplicaţie, limbajele de programare, platforma
hardware sau orice consideraţie de ordin fizic.
În continuare se vor prezenta etapă cu etapă realizarea unui proiect
conceptual al unui BD.
Proiectarea conceptuală şi logică a BD este împărţită în trei etape
principale.
Obiectivul este de a descompune proiectarea în activităţi mai uşor
manevrabile, prin examinarea diverselor perspective ale utilizatorilor asupra
întreprinderii sau vederilor utilizatorilor.
O Vedere este rezultatul dinamic al uneia sau a mai multor operaţii relaţionale,
care acţionează asupra relaţiilor de bază pentru a realiza o altă
relaţie. O vedere este o relaţie virtuală care, în realitate nu există în BD,
ci este produsă în momentul respectiv la cererea unui anumit utilizator.
În cadrul acestei etape se transpun modelele de date logice locale pentru
modelul relaţional. În această etapă se elimină caracteristicile indezirabile care
ar fi dificil de implementat într-un sistem SGBD relaţional – din modelele de
date. Modelele logice sunt apoi validate prin utilizarea tehnicii de normalizare.

47
Normalizarea este o tehnică de realizare a unui set de relaţii cu proprietăţi
dezirabile, date fiind cerinţele unei întreprinderi. Procesul de normalizare a fost
realizat prima dată de către E.F Codd (1972).
Normalizarea, adese ori, constă dintr-o serie de teste asupra unei relaţii,
pentru a se constata dacă aceasta satisface sau violează cerinţele unei anumite
forme normale. Iniţial au fost introduse trei forme normale denumite astfel:
prima (1NF), a doua (2NF), a treia (3NF) formă normală. Toate aceste forme
normale se bazează pe dependenţele funcţionale dintre atributele unei relaţii.
Mai târziu, au fost introduse forme normale superioare, cum ar fi cea de-a patra
(4NF) şi cea de-a cincea (5NF) formă normală.
Normalizarea constituie un mijloc eficient de garantare a faptului că
modelele sunt coerente şi logice din punct de vedere structural şi au o
redundanţă minimă. Modele de date sunt validate şi pentru tranzacţiile pe care
este necesar să le accepte.
Validarea reprezintă procesul de garantare a faptului că se realizează un
model „corect”.
După etapa E2, modelele de date logice ar putea fi utilizate, dacă este
necesar, pentru a realiza implementarea de prototipuri ale BD pentru vederile
utilizatorilor.
Implică îmbinarea modelelor de date logice locale (care reprezintă vederi
diferite ale utilizatorilor), pentru a obţine un model de date logice global unic al
întreprinderii (care reprezintă vederile tuturor utilizatorilor).
Pe parcursul întregii metodologii, utilizatorii joacă un rol foarte important
în revizuirea şi validarea continuă a modelului de date şi a documentaţiei de
susţinere a acestuia. Proiectarea BD este un proces interactiv, care are un punct
de plecare şi o procesiune numeroasă de îmbunătăţiri. Este posibil ca deciziile
luate în cadrul unei etape să conducă la modificarea deciziilor luate în decursul
unei etape anterioare.
Metodologia trebuie să acţioneze ca un ghid în mod eficient în activitatea
de proiectare a BD.
Constă în continuarea modelului de date conceptual local pentru fiecare
vedere a utilizatorilor specificată.
Prima etapă în proiectarea BD constă în realizarea unor modele de date
conceptuale, pentru fiecare vedere a utilizatorilor asupra întreprinderii. O vedere
a utilizatorului reprezintă datele cerute de către un anumit utilizator pentru a lua
o decizie corectă sau a efectua o anumită activitate. De obicei, vederea unui
utilizator constituie o zonă funcţională a întreprinderii, cum ar fi: producţia,
marketing, vânzările, personalul, contabilitatea sau controlul aprovizionării. Un
utilizator poate fi o persoană reală sau un grup de persoane care utilizează în
mod direct sistemul. Utilizatorul se poate referi la un raport produs de către
sistem sau poate solicita rezultatele unei tranzacţii care trebuie acceptată de
către acestea. Vederile utilizatorilor pot fi identificate utilizând diverse metode:
pot fi examinate diagramele de flux de date care au fost realizate mai înainte, în
scopul de a identifica zonele funcţionale şi posibil funcţiile individuale, ar putea
48
fi chestionaţi utilizatorii se pot examina procedurile, rapoartele şi formulările
şi/sau observa întreprinderea în funcţiune.
Se realizează o referire la modul de date conceptual, corespunzător
fiecărei vederi a utilizatorilor pe care urmează să modeleze, cu termenul de
model de date conceptual local corespunzător vederii respective. Fiecare model
de date conceptual local cuprinde: tipuri de entităţi, tipuri de relaţii, atributele,
domeniile atributelor, cheile candidat, cheile primare.

4.3.1. Identificarea tipurilor de entităţi


În această etapă obiectivul este identificarea principalelor tipuri de entităţi
din vederea utilizatorului asupra întreprinderii. Modelul de date conceptual local
constă în definirea principalelor obiective care pot prezenta interes pentru
utilizator. O metodă de identificare a entităţilor constă în examinarea
specificaţiei cerinţelor corespunzătoare unei anumite funcţii a utilizatorului în
cadrul întreprinderii.
Din această specificaţie se identifică substantivele sau expresiile
substantivale menţionate. De asemenea, se caută obiectivele principale, cum ar
fi: personale, locurile sau conceptele de interes, excluzându-se substantivele
care reprezintă doar calităţi ale altor obiecte.
O modalitate alternativă de identificare a entităţilor este de a căuta
obiectele care există pe cont propriu.
Uneori, entităţile sunt greu de identificat, datorită modului în care sunt
prezentate în cadrul specificaţiei cerinţelor utilizatorului, uneori utilizatorii se
exprimă prin exemple sau analogii. Nu este întotdeauna evident dacă un anumit
obiect este o entitate, o relaţie sau un atribut.
Proiectanţii de baze de date trebuie să aibă o vedere selectivă asupra lumii
şi să clasifice lucrurile legate de întreprinderea pe care le observă.
Există situaţii să nu existe un set unic de tipuri de entităţi care pot fi
deduse dintr-o anumită specificaţie a cerinţelor, dar intervale succesive ale
procesorului de analiză, trebuie să se ajungă la alegerea entităţilor care sunt cel
puţin adecvate pentru sistemul cerut.
Pe măsură ce se identifică entităţile, li se atribuie denumiri care să aibă
semnificaţie şi să fie evidente pentru utilizatori. Denumirea şi descrierile
entităţilor sunt reunite într-un dicţionar de date. Atunci când este posibil se
documentează numărul estimat de apariţii ale fiecărei entităţi. O entitate
cunoscută sub denumiri diferite, acestea se numesc aliasuri sau sinonime şi sunt
înregistrate în dicţionarul de date.

4.3.2. Identificarea tipurilor de relaţii


În această etapă obiectivul este identificarea relaţiilor importante care
există între entităţile identificate. De îndată ce entităţile sunt identificate,
următoarea etapă constă în identificarea relaţiilor care există între acestea.
Atunci când se identifică entităţile, o metodă este de a căuta substantivele în

49
specificaţia cerinţelor utilizatorului, de regulă, relaţiile sunt indicate prin
expresii verbale.
În majoritatea cazurilor relaţiile sunt binare (există între doar două
entităţi), totuşi trebuie să se determine şi relaţiile complexe, care ar putea
include mai mult de două tipuri de entităţi, precum şi relaţii recursive, care
implică un singur tip de entitate.
O atenţie deosebită trebuie pentru a detecta toate relaţiile care sunt:
explicite, implicite în specificaţiile utilizatorului. Totuşi relaţiile lipsă trebuie să
iasă la iveală când se validează modelul conform tranzacţiilor pe care trebuie să
le accepte.
■ Determinarea cardinalităţii şi constrângerilor de
participare a tipurilor de relaţii.
După identificarea relaţiilor care trebuie modelate, urmează determinarea
cardinalităţii fiecăreia, care poate fi: unu-la-unu (1:1), unu-la-multi (1:M) sau
multi-la-multi (M:M). În plus se va determina constrângerile de participare al
fiecărei entităţi din cadrul unei relaţii ca fiind fie totale, fie parţiale. Un model
care include cardinalitatea şi constrângerile de participare reprezintă mai
explicit semantica relaţiei respective. Cardinalitatea şi participarea sunt forme
de constrângeri care sunt folosite pentru a verifica şi menţine calitatea datelor.
■ Determinarea tipurilor de relaţii
Pe măsură ce se identifică tipurile de relaţii, li se atribuie denumiri care
au semnificaţie şi sunt existente pentru utilizator. De asemenea, se înregistrează
în dicţionarul de date descrierile relaţiilor şi constrângerilor de cardinalitate şi
de participare.
■ Utilizarea modelării Entitate – Relaţie (ER)
Uneori este mai uşor vizualizarea unui sistem complex decât descifrarea
unor descrieri textuale lungi, din specificaţia cerinţelor utilizatorilor.
Diagramele Entitate – Relaţie (ER) se utilizează pentru a reprezenta mai uşor
entităţile şi modelul în care sunt legate acestea unele de altele.
În cadrul fazei de proiectare a BD se recomandă modelul E-R oriunde
este necesar, pentru a servi la construirea unei imagini a sectorului de
întreprindere care urmează să fie modelat.

4.3.3.Identificarea şi asocierea atributelor cu tipurile


de entităţi sau relaţii
Obiectivul acestei etape constă în asocierea atributelor cu tipurile de
entităţi sau relaţii adecvate. Această etapă din cadrul metodologiei constă în
identificarea tipurilor de fapt privind entităţile şi relaţiilor care trebuie
reprezentate în BD.
Atributele pot fi identificate acolo unde substantivul sau expresia
substantivală exprimă o proprietate, calitate, identificator sau caracteristică a
uneia din acela entităţi sau relaţii.

50
■ Atribute simple/compuse
Este foarte important de a determina dacă un atribut este simplu sau
compus. Atributele compuse sunt formate din atribute simple. De exemplu,
atributul Adresă poate fi simplu conţinând toate detaliile adresei ca o singură
valoare. Dar atributul poate fi şi compus, fiind format din atribute simple care
conţin detaliile adresei ca valori separate în atribute. Stradă, zonă, oraş şi cod P.
opţiunea de a reprezenta detaliile adresei ca un atribut simplu sau compus este
determinată de cerinţele utilizatorului.
În cadrul acestei etape, este important de identificat toate atributele
simple care vor fi reprezentate în modelul de date conceptual-inclusiv acela care
formează atributele compuse.
■ Atributele derivate
Atributele ale căror valori pot fi deduse din valorile altor atribute se
numesc derivate sau calculate. Exemple de atribute derivate sunt:
• numărul de membri ai personalului care lucrează în cadrul unei
anumite filiale;
• vârsta unui membru al personalului;
• salariile lunare totale ale tuturor membrilor personalului din cadrul
unei anumite filiale;
• numărul de proprietăţi pe care le administrează un membru al
personalului.
Uneori, aceste atribute nu sunt prezentate în modelul de date conceptuale.
Atributele derivate trebuie să fie prezente în modelul de date pentru a evita
pierderea potenţială de informaţii. Reprezentarea atributelor derivate va fi luată
în considerare în decursul proiectării fizice a bazei de date. În funcţie de modul
de utilizare a atributului, pot fi calculate noi valori ale atributului derivat de
fiecare dată când acesta este accesat sau când valoarea din care derivă se
modifică.
Există situaţii în care atributele par să fie asociate mai multor tipuri de
entităţi, deoarece aceasta poate indica următoarele:
• au fost identificate o serie de entităţi cum ar fi Manager, Supervizor
şi Secretar, care pot fi identificate ca o singură entitate, denumită
Personal;
• a fost identificată o relaţie între tipuri de entităţi, în acest caz,
trebuie asociat atributului o singură entitate – şi anume cea părinte.
■ Documentarea atributelor
De îndată ce se identifică atributele, li se atribuie denumiri care sunt
semnificative şi evidente pentru utilizatori.
Pentru fiecare atribut se înregistrează următoarele informaţii:
• denumirea şi descrierea atributului;
• orice aliasuri sau sinonime cunoscute ale atributului;
• tipul de date şi lungimea lor;
• valorile prestabilite ale atributelor (dacă sunt specificate);
• faptul dacă atributul trebuie specificat;
51
• dacă atributul este compus şi în acest caz, care sunt atributele simple
din care este format;
• dacă atributul este derivat şi în acest caz cum trebuie calculat;
• dacă atributul are valori multiple.

4.3.4. Determinarea domeniilor atributelor


În această etapă obiectivul este, determinarea domeniilor atributelor din
modelul de date conceptual local.
Un domeniu este un recipient de valori din care unul sau mai multe
atribute îşi iau valorile. De exemplu, s-ar putea defini:
• domeniul atributelor ce reprezintă numerele de filială valabile, ca
fiind un şir de trei caractere, de lungime variabilă, în care primul
caracter este o literă, iar următorul sau următoarele două sunt cifre
de la 1 la 99;
• domeniul atributelor corespunzătoare numerelor de telefon şi de
fax valabile, ca fiind un şir de cifre;
• valorile posibile ale atributelor Sex din entitatea Personal, ca fiind
ori „B” ori „F”. domeniul acestui atribut este un şir format dintr-un
singur caracter care constă în valorile „B” sau „F”.
Într-un model de date complete se specifică domeniul corespunzător
fiecăruia dintre atributele acestuia care include:
• setul de valori impuse pentru un atribut;
• dimensiunea şi formatele câmpurilor atributelor.
Se pot specifica şi alte informaţii referitoare la domeniu, cum ar fi
operaţiile permise asupra unui atribut. Documentarea domeniului atributelor se
realizează pe măsura ce se identifică domeniile atributelor, se înregistrează
caracteristicile acestora în dicţionarul de date.
Intrările de atribute din dicţionarele de date se reactualizează, pentru a
înregistra domeniile acestora.

4.3.5. Determinarea atributelor cheie candidate şi primare


În această etapă obiectivul constă în identificarea cheii (cheilor) candidate
pentru fiecare entitate şi dacă există mai mult decât o cheie candidat –
selecţionarea celei care va fi cheia primară.
O cheie candidat este un atribut sau un set minimal de atribute ale unei
entităţi, care identifică în mod unic fiecare apariţie a acesteia. Se poate
identifica mai mult decât o singură cheie candidat, dar în acest caz trebuie să
alegem una dintre ele drept cheie primară, celelalte chei candidat se numesc
chei alternative.
La alegerea unei chei primară din cele candidate trebuie să se ţină seama
de următoarele, care ajută la efectuarea selectării:
• se alege cheia candidat cu setul minim de atribuţi;
• se alege cheia candidat căreia probabilitatea de modificare a valorii
este mai mică;
52
• se alege cheia candidat care are probabilitatea mai mică să-şi piardă
caracterul de unitate în viitor;
• se alege cheia candidat cu cel mai mic număr de caractere;
• se alege cheia candidat cea mai prietenoasă din punct de vedere al
utilizatorului.
În procesul de identificare al cheilor primare se constată dacă o entitate
este tare sau slabă.
O entitate se numeşte tare dacă i se poate asocia o cheie primară şi este o
entitate slabă dacă nu i se poate asocia o cheie primară.
Cheia primară a unei entităţi slabe poate fi identificată numai atunci când
relaţia slabă se transformă într-o entitate şi legăturile ei cu entitatea de care
aparţine prin plasarea unei chei străine în cadrul acelei relaţii.
Procesul de transformare în relaţii a entităţilor şi a legăturilor lor este
foarte important, prin urmare, identificarea cheilor primare pentru entităţi slabe
nu poate avea loc înainte de a ajunge la acea etapă.
Este indicat să se înregistreze identificarea cheilor primare şi alternative
(atunci când există), în dicţionarul de date.

4.3.6. Specializarea/generalizarea tipurilor de entităţi


Obiectivul este identificarea tipurilor de entităţi superclasă şi subclasă,
atunci când este adecvat.
În cadrul acestei etape există opţiunea de a dezvolta modelul ER prin
utilizarea proceselor de specializare sau de generalizare a entităţilor identificate
pe parcursul etapei E 1:1.
Dacă se alege tratarea prin specializare se evidenţiază diferenţele prin
definirea uneia sau a mai multor subclase ale unei entităţi, denumită superclasă
de specializare.
În cazul când se alege tratarea prin generalizare, se încearcă o identificare
a caracteristicilor comune ale entităţilor,pentru a defini o entitate generalizată
denumită superclasă de generalizare. În general, se optează pentru
generalizarea entităţilor, bazându-se pe existenţa atributelor comune şi a
relaţiilor asociate fiecăruia.
De obicei, nu există indicaţii stricte privind situaţiile în care este
recomandabilă realizarea modelului ER prin specializare sau generalizare,
deoarece aceasta alegere este, adeseori, subiectivă şi depinde de caracteristicile
particulare a situaţiei de modelat.
Ca o indicaţie utilă în alegerea specializării sau generalizării, este
recomandabilă realizarea modelului ER, trebuie să se încerce reprezentarea
entităţilor importante şi relaţiilor cât mai riguros posibil. Gradul de
specializare/generalizare afişat într-o diagramă E-R, trebuie să fie dictat de
lizibilitatea diagramei şi de claritatea cu care aceasta modelează tipurile
importante de entităţi şi relaţii. Conceptul de specializare/generalizare este
asociat modelării extinse.

53
Datorită faptului că această etapă este opţională se vor utiliza doar
termenii de „diagramă ER” sau „model ER”, atunci când se fac referiri la
reprezentarea schematică a modelelor de date.
4.3.7. Desenarea diagramei Entitate – Relaţie (E-R)
Obiectivul acestei etape constă în desenarea unei diagrame Entitate-
Relaţie (ER) care să fie o reprezentare conceptuală a vederii unui utilizator
asupra întreprinderii.

4.3.8. Revizuirea modelului de date conceptual local,


împreună cu utilizatorul
Aceasta se face pentru a garanta că modelul este o reprezentare „reală” al
punctului de vedere al utilizatorului asupra întreprinderii înainte de terminarea
etapei E1, este necesar ca împreună cu utilizatorul să se treacă în revistă modelul
de date conceptual local, care include diagrama ER şi documentaţia de susţinere
care-l descrie.
În cazul în care există anomalii în modelul de date, trebuie efectuate
modificările necesare, care ar putea necesita reluarea unor etape elementare
anterioare. Se va repeta acest proces, până când utilizatorul este gata de a
„parafa” modelul drept o reprezentare „corectă” a sectorului de întreprindere
care trebuie modelat.
În rezumat o metodologie de proiectare reprezintă o structură în care se
utilizează: proceduri, tehnici, instrumente şi documentaţii care susţin şi
facilitează procesul de proiectare. Există o serie de factori critici pentru succesul
etapei de proiectare a bazelor de date care includ, de exemplu, lucrul introductiv
cu utilizatorul şi disponibilitatea de a repeta o serie de etape elementare,
intermediare.
Obiectivul principal al etapei E1 din metodologia prezentată este de a
construi un model de date conceptual local al unei întreprinderi, corespunzător
unei anumite vederi a utilizatorului:
■ Vederile utilizatorilor se pot identifica utilizând diagrame de
flux de date, care definesc zonele funcţionale şi posibil funcţiile
individuale, şi/sau observarea întreprinderii în funcţiune;
■ Fiecare model de date conceptual local cuprinde: tipurile de
entităţi, tipurile de relaţii, atributele, domeniile atributelor, cheile
candidate şi cheile primare;
■ Fiecare model de date conceptual local este susţinut de către o
documentaţie, cum ar fi: dicţionarul de date, care este realizat în decursul
dezvoltării modelului.

4.4. Tehnici privind organizarea logică a bazelor de date


pentru modelul relaţional
În decursul acestui capitol se va prezenta etapă cu etapă, o tehnologie de
proiectare logică a BD pentru modelul relaţional. Această tehnologie, începe
prin a rafina modelele de baze, conceptuale locale, transpunându-le în modele
54
de date logice locale, după care se utilizează acestea la extragerea unui set de
relaţii.
Proiectarea logică a bazelor de date reprezintă procesul de construire a
unui model al informaţiilor utilizate în cadrul unei întreprinderi, bazat pe un
anumit model de date, dar independent de un anumit SGBD şi de alte construcţii
de ordin fizic.
Etapele metodologiei de organizare logică a bazelor de date pentru
modelul relaţional sunt următoarele:
Construirea şi validarea modelului de date logice pentru fiecare
vedere a utilizatorilor.
Construirea şi validarea modelului de date logic global.
Etapa E2 are ca obiectiv realizarea unui model de date logic – bazat pe
modelul de date conceptual al vederii utilizatorului asupra întreprinderii – urmat
de validarea acestuia prin utilizarea tehnicii de normalizare şi conform
tranzacţiilor cerute.
Operaţiile efectuate în cadrul acestei etape (E2) sunt:
E2.1. Transpunerea modelului de date conceptual local în modelul de date logic
local.
E2.2. Extragerea relaţiilor din modelul de date logic local.
E2.3. Validarea modelului prin utilizarea normalizării.
E2.4. Validarea modelului conform tranzacţiilor utilizatorului.
E2.5. Desenarea diagramei Entitate – Relaţie (ER).
E2..6. Definirea constrângerilor de integritate.
E2.7. Revizuirea modelului de date logic loca, împreună cu utilizatorii.
La încheierea acestei etape, (E2) trebuie să se obţină un model al vederilor
utilizatorului care să fie: riguros, cuprinzător şi fără echivoc. Dacă sunt
respectate aceste cerinţe, se va dispune în acest stadiu de un fundament solid
pentru a putea trece la etapa următoare (E3) care constă în combinarea
modelelor de date logice locale individuale, pentru a realiza un model de date
logic global al întreprinderii.

4.4.1. Transpunerea modelului de date conceptual local


în model de date logic local
După etapa E1 se dispune de un model de date conceptual local
corespunzător vederii utilizatorului asupra întreprinderii. Dar trebuie menţionat
faptul că modelul de date poate conţine unele structuri de date care ne pot fi
modelate cu uşurinţă de către sistemele de gestiune a BD convenţionale. În
cadrul acestei etape se transformă aceste rânduri de date într-o formă care este
manipulată cu mai multă uşurinţă de aceste sisteme de gestiune convenţionale.
Acest proces determină utilizatorul să se gândească mai profund la
semnificaţia datelor şi în final are ca efect o reprezentare mai reală a
întreprinderii.
Obiectivele acestei etape (E2.1.) sunt:

55
■ Eliminarea relaţiilor de tip M:N
În cazul când o relaţie de tip M:N este reprezentată în modelul de date
conceptual, atunci trebuie să se descompună pentru a identifica o relaţie
intermediară.
Relaţia de tip M:N este înlocuită cu două relaţii de tip 1:M,
corespunzătoare entităţii nou identificate.
■ Eliminarea relaţiilor complexe
O relaţie complexă este cea formată din trei sau mai multe entităţi. În
cazul când în modelul conceptual este identificată o reprezentare complexă, ea
trebuie descompusă pentru a identifica o entitate intermediară. Relaţia complexă
este înlocuită cu numărul necesar de relaţii de tip 1:M (binare), corespunzătoare
noii entităţi identificate.
■ Eliminarea relaţiilor recursive
O relaţie recursivă este un tip particular de relaţie, în care un tip de
entitate are o relaţie cu ea însăşi. În cazul când în modelul conceptual este
reprezentată o relaţie recursivă, trebuie să o descompunem pentru a identifica o
entitate intermediară.
De exemplu, pentru a reprezenta situaţia în care un membru al
personalului supraveghează alţi membrii, se poate defini o relaţie recursivă de
tip unu-la-mulţi (1:M). Personal Supraveghează Personal, aşa cum se arată în
fig.4.1.(a).
Natura recursivă a acestei relaţii necesită o tratare specială, pentru a
permite reprezentarea sa atât în proiectarea logică a bazei de date, cât şi în
implementarea fizică a acesteia. Pentru a simplifica această relaţie slabă
denumită Personal – Alocat şi o relaţie adiţională de tip 1:1, denumită
Supravegheat De, aşa cum se arată în fig.4.2. (b).
Relaţia recursivă de tip M:N se descompune în acelaşi mod ca şi relaţia
binară de tip M:N descrisă anterior.

Nume -
Publicaţie Nr. Articol

Realizează
Reclamă
Publicaţie Articol

M N

Fig.4.1. (a) Relaţie de tip M:N Publicaţie Face Reclamă la anumite


articole de bun casnic

56
Nr. Articol
Nume -
Publicaţie

Listează M Reclamă 1
Publicaţie În Articol

Fig.4.2.(b) Descompunerea relaţiei de tip M:N Face Reclamă în două


relaţii de tip 1:M (Enumerare şi Reclamă În) şi entitate Reclamă.

■ Eliminarea relaţiilor cu atribute


În cazul în care în modelul de date conceptuale este reprezentată o relaţie
cu atribute, ea trebuie să fie descompusă pentru a identifica o entitate.
De exemplu, se consideră situaţia în care se doreşte să se înregistreze
numărul de ore lucrate de către personalul angajat temporar la fiecare filială aşa
cum arată fig.4.3. Relaţia Personal Lucrează La Filiala are un atribut
Ore_Lucrate Descompunerea relaţiei Lucrează La într-o entitate slabă, denumită
Alocaţie – filială, căreia îi este alocat atributul Ore_Lucrate şi se creează două
relaţii noi de tip 1:M aşa cum se arată în fig.4.4.

Nr. Ore_ Nr. Filială


Personal Lucrate

Personal Lucrează Filiala


M N
La

Fig.4.3. Relaţia Lucrează_La, cu atribute Ore_Lucrate

57
Nr. Ore _ Nr. Filială
Personal Lucrate

1 Atribut M M 1
Personal Atribut La Necesita Filială
La

Fig.4.4. Descompunerea relaţie Lucrează La, pentru a realiza entitate


Alocaţie_Filială şi două relaţii de tip 1:M (Atribut La şi Necesită)

■ Eliminarea atributelor cu valori multiple


Un atribut cu valori multiple conţine mai multe valori pentru o singură
entitate.
În cazul când modelul de date conceptual este reprezentat un atribut cu
valori multiple, el trebuie descompus pentru a identifica o entitate.
De exemplu, pentru a reprezenta situaţia în care o singură filială are mai
multe numere de telefon, se va defini atributul Nr_Tel. al entităţii Filială ca
atribut cu valori multiple, aşa cum arată în fig.4.5.
Se elimină acest atribut cu valori multiple, aşa cum rezultă din fig.4.6. şi
se identifică o nouă entitate denumită Telefon cu Nr._Tel. reprezentat acum ca
atribut simplu – şi o nouă relaţie de tip 1:M denumită Are.

Nr. Filială Adresă

Filială Nr._Tel.

Fig.4.5. Entitatea Filială cu un atribut cu valori multiple denumit Nr_Tel

Nr._Filială Nr_Tel

1 M
Adresă Filială Are Telefon

58
Fig.4.6. Descompunerea atributului cu valori multiple Nr_tel într-o relaţie
de tip 1:M, denumită Are şi o entitate denumită telefon, cu un atribut simplu,
denumit Nr_Tel

■ Relaxarea relaţiilor de tip 1:1


În cazul când se identifică entităţile s-ar putea întâmpla să se găsească
două care să reprezinte aceleaşi obiecte din cadrul întreprinderii. Un exemplu
poate fi următorul, se identifică entităţile Filială şi Departament, care, de fapt,
reprezintă acelaşi lucru, deoarece Filiala este un sinonim pentru Departament. În
acest caz din cele două entităţi trebuie să alegem una dintre ele, cealaltă
rămânând cheie alternativă.
Eliminarea Relaţiilor Redundante
O relaţie este redundantă dacă aceeaşi informaţie poate fi obţinută prin
intermediul altor relaţii. Obiectivul este de a realiza un model de date minimal,
deci relaţiile redundante nu sunt necesare, acestea trebuie eliminate. Se poate
determina cu uşurinţă dacă există mai mult decât o cale între două entităţi.
Totuşi, aceasta nu înseamnă că una dintre relaţii este redundantă, deoarece ele
pot reprezenta diferite asociaţii din cadrul întreprinderii. Estimarea redundanţei
este determinată de dimensiunea temporală a relaţiilor.
Se consideră că exemplu modelarea relaţiei dintre entităţile Copil,
Femeie, Bărbat aşa cum este reprezentată în fig.5.7.

1 1
Bărbat Femeie
Căsătorit
Cu
1 1

Tatăl Lui Mama


Lui
M M
Copil

Fig.4.7. Relaţie neredundantă

Din figură se observă că există două căi între entităţile Bărbat şi Copil:
una directă prin intermediul relaţiei Tatălui, iar cealaltă prin intermediul
relaţiilor Căsătorit Cu şi Mama lui. Aparent se poate crede că relaţia Tatăl Lui
nu este necesară.
Această presupunere este incorectă din două motive:
• tatăl ar putea avea copii dintr-o căsătorie anterioară, iar atunci se
modelează numai căsătoria curentă a tatălui printr-o relaţie de tip 1:1;
59
• este posibil ca tata şi mama să nu fie căsătoriţi, sau tatăl ar putea fi
căsătorit cu altcineva decât mama copilului (sau mama este căsătorită cu
cineva care nu este tatăl copilului), astfel încât, din nou relaţia cerută nu
poate fi modelată fără o relaţie de tip Tatăl Lui.
Rezultă faptul că atunci când se estimează redundanţa, este foarte
importantă să se analizeze semnificaţia fiecărei relaţii dintre entităţi.
Această etapă a prezentat metodele prin care poate fi simplificat modelul
de date conceptual local, prin eliminarea structurilor de date care sunt dificil de
implementat în bazele de date relaţionale.
Această etapă corectă se referă la modelul de date conceptual rafinat cu
denumirea de model de date logic local.

4.4.2. Extragerea relaţiilor din modelul de date logic local


În această etapă se extrag relaţiile din modelul de date logic local pentru a
reprezenta entităţile şi relaţiile descrise în vederea utilizatorului asupra
întreprinderii.
Va fi descrisă componenţa fiecărei relaţii utilizând un limbaj de Definirea
Bazelor de Date din punct de vedere Logic (DBDL) pentru bazele de date
relaţional (BDR).
La utilizarea limbajului DBDL se specifică următoarele:
• denumirea relaţiei urmată de o listă a dimensiunii atributelor sale simple,
cuprinsă între paranteze;
• se identifică cheia primară şi cheile alternative şi/sau străine ale relaţiei
respective. După identificarea unei chei străine este afişată, de asemenea,
relaţia care o conţine drept cheie primară. Se va evidenţia faptul că
relaţiile care reprezintă entităţile şi relaţiile acestora sunt extrase din
structurile de date posibile, prezente în modelul de date logic fig.4.8.
Relaţia pe care o are o entitate cu altă entitate este reprezentată prin
mecanismul cheie primară/cheie străină.
Atunci când se decide unde se va expedia sau plasa atributul (atributele)
cheii străine, trebuie să se identifice entităţile „părinte” şi „copil” implicate în
relaţie.
Entitatea părinte se referă la entitatea care plasează o copie a cheii sale
primare în relaţia care reprezintă entitatea copil, unde va acţiona ca o cheie
străină.

60
Stradă
Oraşul
Pronume Nr_Filială
Adresă
CodP
Nume_Pronume Adresă
Nume
Admini
1 strează
1
Filială
Funcţie Personal M
1
1 Are
Salariu Nr_personal Nr_Fax
Nr_Tel
Înrudit
Sex Cu

M
Rudenie Rudă Apropiată
Nr_Tel

NumeR

Adresa
Fig.4.8. Un exemplu de model de date logic

• Tipuri de entităţi
Pentru fiecare entitate tare (obişnuită) din modelul de date logic, se
creează o relaţie care cuprinde toate atributele simple ale acelei entităţi. Pentru
atributele compuse, cum ar fi adresa, se introduc în relaţie numai atributele
constituante simple şi anume: Stradă, Oraşul şi Cod poştal. De exemplu,
compoziţia relaţiei Personal din fig.4.8. este: personal (Nr_Personal, Pronume,
Nume, Stradă, Oraş, CodP, Funcţie, Sex, Salariu). Cheie primară Nr_Personal.
• Tipuri de entităţi slabe
Pentru fiecare entitate din modelul de date logic se creează o relaţie care
să cuprindă toate atributele simple ale acelei entităţi. În plus, se include cheia
primară a entităţii proprietar ca o cheie străină. Cheia primară a unei entităţi
slabe este parţial sau total derivată din entitatea proprietar.
Din fig.8 se observă că entitatea Personal este proprietatea entităţii slabe
Rudă_Apropriată.
Compozitic relaţiei Rudă_Apropriată este: Rudă_Apropiată (Nr_Personal,
NumeR, Adresă, Nr_Tel, Rudenie) cheia primară Nr_Personal, NumeR; cheie
străină Nr_Personal se referă la Personal (Nr_Personal).
Se observă că atributul cheie străină al relaţiei Rudă_Apropiată formează
o parte a cheii primare corespunzătoare acestei entităţi. În această situaţie, cheia
61
primară a relaţiei Rudă_Apropiată nu poate fi identificată decât după ce cheia
străină a fost expediată din relaţia Personal în relaţia Rudă_Apropiată. În finalul
acestei etape trebuie să se identifice orice cheie primară sau cheie candidat care
au fost formate în procesul de extragere a relaţiilor din modelul de date logice.
■ Tipuri de relaţii binare unu-la-unu (1:1)
În cazul fiecărei relaţii binare de tipul 1:1 dintre entităţile E1 şi E2 din
modelul de date logic, se expediază o copie a atributului (atributelor) cheie
primară al entităţii E1 în relaţia care reprezintă entitatea E2. identificarea
entităţilor părinte şi copil depinde de constrângerile de participare ale entităţilor
E1 şi E2 din cadrul relaţiei. Entitatea care participă parţial în relaţie este
desemnată drept entitate părinte, iar cea care participă total este desemnată drept
entitate copil. O copie a cheii primare a entităţii părinte este plasată în relaţia
care reprezintă entitatea copil.
În cazul în care ambele tipuri de entităţi participă total sau parţial într-o
relaţie de tip 1:1, desemnarea entităţilor părinte, respectiv copil, este arbitrară.
Mai mult, atunci când ambele entităţi participă total într-o relaţie, există
opţiunea de a reprezenta această relaţie utilizând legătura cheie primară/cheie
străină ca mai sus, sau de a îmbina atributele asociate ambelor entităţi într-o
singură relaţie.
În general, există tendinţe de a îmbina cele două tipuri de entităţi atunci
când ele nu sunt implicate în alte relaţii. Un exemplu care ilustrează modul în
care se poate reprezenta o relaţie de tip 1:1 în relaţiile extrase dintr-un model de
date logic.
Relaţia Personal Administrează Filiala – reprezentată în fig.4.8. este de
tip 1:1, deoarece un singur membru al personalului administrează o singură
filială.
Entitatea personal participă la relaţia Administrează în timp ce entitatea
Filiala participă total. Entitatea care participă parţial în relaţia (Personal) este
desemnată drept entitatea părinte, iar cea care participă total în relaţie (Filială)
este desemnată drept entitate copil. Prin urmare, o copie a cheii primare a
entităţii Personal (părinte) şi anume Nr_Personal_este plasată în relaţia Filială
(copil).
Compoziţia relaţiilor Personal şi Filială este:
Personal (Nr_Personal, Pronume, Nume, Stradă, Oraşul, CodP, Funcţia, Sex,
Salariu).
Cheie primară Nr_Personal
Filială (Nr_Filială, adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager
Cheie primară Nr_Filială
Cheie alternativă Nr_Tel sau Nr_Fax
Cheie străină Nr_Personal_Manager se referă la Personal (Nr_Personal)
De observat că atributul Nr_Personal, care reprezintă managementul unei
filiale a fost redenumit Nr_Personal_Manager, pentru a indica mai clar scopul
cheii străine în relaţia Filială.

62
■ Tipuri de relaţii binare unu-la-mulţi (1:M)
În cazul fiecărei relaţii binare de tipul 1:M dintre entităţile E1 şi E2 din
modelul de date logic, se expediază o copie a atributului (atributelor) cheie
primară al entităţii E1 în relaţia E2 pentru a acţiona ca o cheie străină. Entitatea
aflată în „partea singulară” a relaţiei este desemnată drept entitate părinte, iar
cea din „partea multiplă” drept entitate copil.
Ca şi anterior, pentru a reprezenta această relaţie, o copie a cheii primare
a entităţii părinte este plasată drept cheie străină în relaţia reprezentând entitatea
copil.
În exemplul următor se ilustrează modul în care se poate reprezenta o
relaţie de tip 1:M prin relaţii derivate dintr-un model de date logic.
Relaţia Filiala Are Personal, prezentată în fig.4.8., este de tip 1:M,
deoarece o singură filială are mai mulţi membrii de personal. În fig.4.8. se
observă că entitatea Filială se află în partea singulară şi reprezintă entitatea
părinte, iar entitatea personal se află în „partea multiplă” şi reprezintă entitatea
copil. Relaţia dintre aceste entităţi este stabilit prin plasarea unei copii a cheii
primare a entităţii Filiala (părinte) – şi anume Nr_Filială în relaţia Personal
(copil).
Compoziţia relaţiilor Filială şi Personal este:
Personal (Nr_Personal, Prenume, Nume, Strada, Oraşul, CodP, Funcţie, Sex,
Salariu, Nr_Filial).
Cheie primară Nr_Personal
Cheie străină Nr_Filială se referă la Filiala (Nr_Filială)
Filiala (Nr_Filială, Adresă, Nr_Tel, Nr_Fax, Nr_Personal_Manager)
Cheie primară Nr_Filială
Cheie alternativă Nr_Tel sau Nr_Fax
Cheie străină Nr_Personal_Manager se referă la personal (Nr_Personal)

■ Relaţii de tip superclasă/subclasă


În modelul de date logic fiecare relaţie de tip supraclasă/subclasă se
identifică entitatea de tip superclasă drept entitate de părinte, iar cea de tip
subclasă drept entitate copil.
Există o serie de opţiuni privind modul în care se poate reprezenta o astfel
de relaţie, sub formă de una sau mai multe relaţii. Alegerea celei mai adecvate
opţiuni depinde de constrângerile de disjuncţie şi de participare ale relaţiei de
tip superclasă/subclasă.
De exemplu, se consideră entităţile Proprietate_de_Închiriat şi
Proprietate_de_Vânzare, având la bază existenţa atributelor comune şi relaţiile
asociate fiecăreia.
Prin urmare, se vor prezenta entităţile Proprietate_de_Închiriat şi
Proprietate_de_Vânzare drept subclase definite ale superclasei Proprietate aşa
cum rezultă din fig.4.9.

63
Nr_Chiriaş Chirie Preţ

M N Proprietate- Proprietate- M 1 Cumpărător


Închiri Cumpărător
Chiriaş de-Închiriat de-Vânzare

Tipul
M 1
Proprietate Proprietar
Deţine

Adresa
Nr_Proprietar
Nr_Proprietate

Fig.4.9. Superclasa Proprietate cu subclasele Proprietate:de:Închiriat şi


Proprietate_de_Vânzare (Atributul adresă nu este descompus)

Există diverse modalităţi de reprezentare a acestei relaţii, după cum se


prezintă în continuare:
(Opţiunea 1)
Toată_Proprietatea (Nr_proprietate, Adresa, Tipul, Cheie, Preţ)
Cheia Primară Nr_Proprietate

(Opţiunea 2)
Proprietatea_de_Închiriat (Nr_Proprietate, Adresa, Tipul, Chirie)
Cheie primară Nr_Proprietate
Proprietate_de_Vânzare (Nr_Proprietate, Adresa, Tipul; Preţ)
Cheie primară Nr_Proprietate

(Opţiunea 3)
Proprietate (Nr_Proprietate, Adresa, Tipul)
Cheie primară Nr_Proprietate
Proprietate_de_Închiriat (Nr_Proprietate, Chirie)
Cheie primară Nr_Proprietate
Cheie străină Nr_Proprietate se referă la Proprietate (Nr_Proprietate).

Opţiunea variază de la plasarea tuturor atributelor proprietăţii într-o


singură relaţie (opţiunea 1), până la împărţirea acestora în trei relaţii (Opţiunea
64
3). Cea mai adecvată reprezentare a relaţiei de tip superclasă/subclasă este
determinată de constrângerile impuse acesteia.
Relaţia pe care o are superclasa Proprietate cu subclasele sale este total
disjunctă, întrucât fiecare membru al superclasei Proprietate trebuie să fie
membru al uneia dintre subclase (Proprietatea_de_Închiriat sau
Proprietate_de_Vânzare), dar nu poate aparţine ambelor. Altfel spus, pentru o
relaţie de tip superclasă/subclasă care este total disjunctă, se creează către o
relaţie separată care să reprezinte fiecare subclasă şi se include câte o copie a
atributului (atributelor) cheie primară al superclasei în fiecare dintre acestea.
Prin urmare, se va alege Opţiunea 2 drept cea mai bună reprezentare a acestei
relaţii.
Totuşi, mai există şi alţii factori care pot influenţa alegerea finală, cum ar
fi dacă subclasele sunt implicate în relaţii diferite.

■ Documentarea relaţiilor şi atributelor chei străine


Compoziţia relaţiilor extrase din modulul de date logic se documentează
utilizând limbajul DBDL. Se constată că sintaxa limbajului DBDL poate fi
extinsă pentru a reprezenta constrângerile de integritate asupra cheilor străine.
De asemenea, Dicţionarul de date trebuie reactualizat pentru a reflecta orice
atribute chei noi care au fost identificate în decursul acestei etape.

4.4.3 Validarea modelului de date logic prin utilizarea normalizării

Normalizarea este utilizată pentru a îmbunătăţii modelul, astfel încât


acesta să satisfacă diverse constrângeri care evită dublarea inutilă a datelor.
Normalizarea garantează că modelul este mai apropiat de întreprindere, este
coerent are o redundanţă minimă şi o stabilitate maximă. Normalizarea are rolul
de stabilire a atributelor care aparţin unui tip de entitate. Conceptul fundamental
al teoriei relaţionale este acela că atributele sunt grupate, împreună într-o relaţie
deoarece între ele există o legătură logică. Uneori se argumentează că un proiect
normalizat al unei baze de date nu prezintă o eficienţă de prelucrare maximă. În
general în favoarea normalizării pledează următoarele argumente:
9 Proiectul normalizat organizează datele conform dependenţelor lor
funcţionale, astfel spus procesul se află situat undeva între
proiectarea conceptuală şi fizică
9 Proiectarea logică poate să nu conducă la proiectul final, că trebuie
să reprezinte cea mai mare concepţie, a proiectului, privind natura
şi semnificaţie datelor din cadrul întreprinderii.
65
În momentul când există criterii specifice privind performanţele
proiectarea fizică poate fi diferită.
9 Un proiect normalizat este robust şi fără anomali de reactualizare
9 Calculatoarele prezente sunt mult mai performante faşă de cele din
anii anteriori, fapt care face ca implementarea unui proiect care excelează
prin facilităţi flexibile de utilizare, pe baza unui tip de prelucrare
suplimentar.
9 Normalizarea implică înţelegerea în totalitate a fiecărui atribut
care trebuie să fie reprezentat în baza de date, acesta reprezintă cel mai
important beneficiu.
9 Normalizarea realizează un proiect al bazei de date flexibil, care
poate fi extins cu uşurinţă
În etapa E.2.2 au fost extrase relaţiile din modelul de date logic local, iar
în această etapă E.2.3 se va examina grupările atributelor din fiecare din aceste
relaţii.
Astfel spus se va valida compoziţia fiecărei relaţii, utilizând regulile de
normalizare.
Procesul de normalizare conţine următoarele etape principale:
9 Prima formă normală (1NF), care elimină grupările repetitive;
9 A doua formă normală (2NF), care elimină dependenţele parţiale
de cheia primară;
9 A treia formă normală (3NF), care elimină dependenţele tranzitive
de cheia primară
9 Forma normală Boyce-Cold (BCNF), care elimină anomaliile
rămase din dependenţele funcţionale.
Obiectivul etapei E.2.3 este de a garanta că fiecare relaţie extrasă din
modelul de date logic se află cel puţin în forma normală Boyce-Cold (BCFN).
În cazul când se identifică relaţii care nu se găsesc în BCNF, acest lucru
ar putea indica faptul că o parte din modelul de date logic este greşită sau că a
fost introdusă o eroare la extragerea relaţiei din model. În acest caz, dacă este
necesar trebuie restructurat modelul de date, pentru a garanta faptul că aceasta
este o reprezentare „adevărată” a sectorului de întreprindere care este modelat.

4.4.4. Validarea modelului conform tranzacţiilor utilizatorului

Această etapă constă în garantarea faptului că modelul de date logic local


acceptă tranzacţiile cerute de către vederile utilizatorilor. Tranzacţiile cerute de
către fiecare vedere a utilizatorilor pot fi determinate din specificaţia cerinţelor
acestora. Prin folosirea diagramei ER, a dicţionarului de date şi a legăturilor
cheie primară/cheie străină prezentate în relaţii, se încearcă efectuarea manuală
a operaţiilor. În cazul când toate tranzacţiile pot fi rezolvate în acest mod, se
realizează o validare a modelului de date logic conform tranzacţiilor.

66
Dacă o tranzacţie nu poate fi efectuată manual, înseamnă că există o
problemă în cadrul modelului de date, care este necesar să fie rezolvată.
În acest caz, este posibil să se fi omis o entitate o relaţie sau un atribut din
componenţa modelului de date.
Pentru a garanta faptul că modelul de date logic local acceptă tranzacţiile
cerute se vor analiza două abordări posibile:
9 Necesită verificarea faptului că modelul furnizează informaţiile
(entităţi, relaţii în atributele acestora) cerute de către fiecare
tranzacţie, prin documentarea unei descrieri a cerinţelor acestora.
Ca exemple putem lua, tranzacţiile corespunzătoare entităţii Manager din
cadrul unei filiale ar putea cuprinde următoarele operaţii:
9 Inserarea detaliilor referitoare la un nou membru al personalului.
Cheia primară a relaţiei Personal este atributul Nr-personal şi mai
întâi se verifică dacă nu cumva noul număr de personal există deja,
dacă există, se interzice inserarea şi se abandonează procesul. În
cazul contrar, se inserează detaliile referitoare la noul membru al
personalului. Se controlează ca fiecare detaliu să fie reprezentat de
către un atribut din relaţia Personal.
9 Ştergerea detaliilor referitoare la un membru al personalului,
cunoscându-se numărul de personal. În acest caz se caută numărul
de personal respectiv în coloana corespunzătoare a relaţiei
Personal.
Dacă nu există a apărut o eroare a utilizatorului şi detaliile nu pot fi
şterse; în caz contrar se şterge treptat din relaţia Proprietate, corespunzătoare
proprietăţii alocate acelui membru al personalului pentru a fi administrată.
A doua abordare în validarea modelului de date conform tranzacţiilor
cerute presupune reprezentarea schematică a căii urmate de fiecare tranzacţie,
direct în diagrama ER.
În figura 4.10 se prezintă o astfel de abordare, în care se utilizează
tranzacţiile (a) respectiv (b).

Nr. personal Nr. proprietate

1 M
Administrează
Personal Proprietate

(a) (b)
Fig. 4.10
O reprezentare schematică a tranzacţiilor (a) şi (b)

67
Această abordare permite vizualizarea zonelor din model care nu sunt
cerute de către tranzacţii, precum şi a acelor zone care sunt de importanţă critică
pentru acestea.
Prin urmare este necesar a se revedea direct suportul oferit de către
modelul de date pentru tranzacţiile cerute.
În cazul când există zone ale modelului care nu par să fie utilizate de vreo
tranzacţie, se poate pune în discuţie costul reprezentării acestor informaţii în
modelul de date. Pe de altă parte, dacă există zone ale modelului care nu sunt
adecvate pentru furnizarea căii corecte a unei tranzacţii, s-ar putea să fie
necesară analizarea posibilităţii ca anumite tipuri de entităţi sau de relaţii de
importanţă critică să fi fost omise.

4.4.5 Desemnarea diagramei Entitate-Relaţie (E.R)

Obiectivul acestei etape constă în desemnarea unei diagrame Entitate-


Relaţie (ER) finale, care să constituie o reprezentare logică locală a datelor
dintr-o vedere a utilizatorului asupra întreprinderii. Această diagramă a fost
validată prin utilizarea procesului de normalizare şi conform tranzacţiilor pe
care trebuie să le accepte.

4.4.6. Definirea constrângerilor de integritate

Constrângerile de integritate din cadrul unui vederi a utilizatorului asupra


întreprinderii nu sunt acele care trebuie impuse pentru a proteja baza de date
faţă de situaţia de a deveni incoerentă.
În aceasta se va specifica numai că constrângeri de integritate sunt
necesare, fără a stabili modul în care se va realiza aceasta. Se consideră cinci
tipuri de constrângeri de integritate privind:
9 Datele necesare. Se identifică atributele care trebuie să conţină o
valoare valabilă, adică atributele care nu au voie să conţină informaţii
lipsă sau null-uri. De exemplu cum ar fi atributele Nr-Persoană şi Nume-
Prenume din entitatea personal, trebuie să conţină întotdeauna o valoare
şi nu pot conţine null-uri. Totuşi, atributul Nr-Tel din entitatea Personal
nu este necesar să conţină întotdeauna o valoare şi prin urmare poate
conţine null-uri care pot reprezenta informaţii lipsă, necunoscute sau
inaplicabile.
Detaliile despre atributele din modelul de date corespunzător vederii
supervizorului au fost descrise în E1.3.
9 Domeniile atributelor. Domeniul corespunzător unui atribut identifică
mulţimea de valori permise pe care le poate conţine acesta. De exemplu,
mulţimea de valori corespunzătoare atributului Nr-client din entitatea

68
Client este formată din variabile de tip şir de cinci caractere care conţin
valorile cuprinse între CR1 şi CR999.
Un număr de exemple de domenii ale atributelor din modelul de date
logic local al supervizorului au fost descrise în E1.4.
9 Integritatea Entităţilor. Cheia primară a unei entităţi nu trebuie să
admită null-uri. De exemplu, fiecare apariţie a entităţii Filială, trebuie să
conţină o valoare a atributului cheie primară, Nr-Filială. Atributele care
constituie cheia primară a fiecărei entităţi au fost identificate în etapele
E1.5 şi E2.2.
9 Integritatea referenţială. În general relaţiile dintre entităţi sunt
reprezentate prin luarea unei copii a cheii primare a entităţii părinte în
relaţia copil. Integritatea referenţială semnifică faptul că, dacă cheia
străină a unei relaţii copil conţine o valoare, acea valoare trebuie să se
refere la o apariţie existentă şi valabilă din relaţia părinte. Cum ar fi dacă
atributul Nr-Filială (Cheie străină) din relaţia (copil) Personal conţine
valoarea B3 această valoare trebuie să fie conţinută în atributul Nr-Filială
(cheie primară) din relaţia (părinte) Filială.
Se va asigura integritatea referenţială prin specificarea unor constrângeri
de existenţă asupra cheilor primare şi străine. Aceste constrângeri definesc
condiţiile în care sunt reactualizate sau şterse apariţiile unei chei primare,
respectiv inserate sau reactualizate apariţiile unei chei străine.
Inserarea unei noi apariţii a unei chei primare sau ştergerea unei apariţii a
unui chei străine nu constituie cauza unor probleme privind integritatea
referenţială.
Pentru fiecare cheie străină unei relaţii, trebuie definite condiţiile de
reactualizare sau ştergerea cheii primare corespunzătoare. În definirea acestor
condiţii se poate alege dintr-o serie de strategii. Şi anume NO ACTION;
CASACADE, SET NULL SET DEFAULT şi NO CHECK.
Constrângerile de existenţa asupra cheilor străine ale relaţiei
Proprietate_de_închiriat vor fi descrise utilizând limbajul de definire al bazelor
de date (DBDL):
9 Proprietate_ de_ închiriat (Nr_Proprietate, Strada, Zonă, Oraşul, Cod P,
Tipul, Camere, chirie, Nr_Proprietar, Nr_Personal, Nr_Filială).
9 Cheie primară Nr_Proprietate
9 Cheie străină Nr_Proprietar se referă la Proprietar_Privat,
(Nr_Proprietar) şi Proprietar _Afacere (Nr_Proprietar) la ştergere NO
ACTION la reactualizare CASCADE
9 Cheie străină Nr_Personal se referă la Personal (Nr_Personal) la ştergere
SET Null la reactualizare CASCADE.
9 Cheie străină Nr_Filială se referă la Filială (Nr_Filială) la ştergere NO
ACTION la reactualizarea CASCADE.
Constrângerile întreprinderii, sunt definite de către regulile întreprinderii,
care controlează tranzacţiile din „lumea reală”.

69
De exemplu o agenţie specifică faptul că un supervizor poate supraveghea
minim 5 şi maxim 10 membri de personal în acelaşi timp Regulile întreprinderii
din specificaţia cerinţelor utilizatorului sunt enumerate anterior.
Documentarea constrângerilor de integritate – în modelul de date logic
corespunzător vederii supervizorului se documentează detaliile referitoare la
toate constrângerile de integritate.

Revizuirea modelului de date logic împreună cu utilizatorul

În cadrul acestei etape se validează modelul de date logic local,


corespunzător vederii supervizorului, prin revizuirea acesteia împreună cu
utilizatarul (utilizatarii). Este foarte important ca modelul, să constituie o
reprezentare „adevărată” a „lumii reale” aşa cum este percepută de către
supervizori. Diagrama ER acţionează ca un mijloc de comunicare între
realizatorul (realizatorii) modelui şi utilizator (utilizatori).
Este foarte important ca utilizatorii să analizeze documentaţia care susţine
modelul. În cazul când utilizatorii constată un punct slab în model sau
documentaţie, trebuie repetate etapele necesare. Modelul de date logic local,
corespunzător vederii supervizorului din studiu evolutiv, cuprinde un model ER
ca cel prezentat în figura 4.11 şi documentaţie care descrie componentele
acesteia.
Fig. 4.11. un exemplu de model de date logic local, corespunzător
vederii supervizorului din studiul evolutiv ca versiune finală.

70
susţine

1 M

3 M
supervizează
supervizor Personal_
Alocat

1 M 1 reuneşte
Filială Are
1 Personal
3 1
1 îndeplineşte
înregistreaza oferă
M
administrează
M Acord de
inchiriere
Proprietar Proprietar
tine M _privat afacere
M Asociat
Proprietate
1 cu 1 de închiriat
1 M d
1
la deţine
client 1 Proprietar
Descrisă

1 M
M
M 1
Efectuează vizitare Reclam listează ziar

Fig.4.11.Construirea şi validarea modelului de date logic global

În cadrul acestui paragraf se va îmbina modelul de date logic local,


corespunzător vederii supervizorului cu cel corespunzător vederii
managementului pentru a realiza modelul de date logic global. În această etapă
se va prezenta o posibilă abordare a procesului de îmbinare a modelelor de date
logice locale pentru a construi un singur model de date logic global. Modelele
de date logice locale care vor fi îmbinate în această etapă sunt prezentate în
figura 4.11 (vederea supervizorului) şi în fig. 4.12 (vederea managerului).

71
Supervizeaz
1 1 administreaz
Supervizor Manager

d Nr_Personal
1 Repartizat 1 1
Personal alocat
M
Personal Nr_Filial
1 Este

Ruda apropiata L Legate de


1
Nume
refera
Nr_proprietat supervizeaz
ziar
M are 1 1
1 M Filial
Proprietate de
Afiseaza
1 La M vizitare
M M
Reclama
M
Plasatin
M Înrudit cu
Detine

M cere
Acord de
Proprietar Afacere închiriere 1 M
privat proprietar M
M Ţine 1 chirias
d
Nr_proprietar Nr.închiriere Nr_ chirias

Proprietar

Fig. 4.12 Un exemplu de model Entitate –Relaţie extins, vederea managerului


asupra studiului.

72