5.

METODOLOGIA DE PROIECTARE CONCEPTUALĂ A

BAZELOR DE DATE
Proiectarea unei baze de date cuprinde următoarele etape:
-proiectarea conceptuală
- proiectarea logică
- proiectarea fizică.

5.1. Proiectarea conceptuală a bazei de date

Proiectarea conceptuală a bazei de date este procesul de construire a unui model al
informaţiilor utilizate în întreprindere, independent de consideraţiile de ordin fizic (SGBDul
utilizat).

5.1.1. Construirea modelului de date conceptual local pentru fiecare vedere a

utilizatorilor
De regulă vederea unui utilizator este o zonă funcţională a întreprinderii (de exemplu
producţia, marketingul, vânzările, resursele umane, contabilitatea, aprovizionarea etc.).
utilizatorul este o persoană reală individuală sau un grup de persoane. identificarea vederilor
utilizatorilor se realizează prin examinarea diagramelor de flux şi prin chestionarea
utilizatorilor.
Modelul de date conceptual corespunzător vederii unui utilizator se numeşte model de
date conceptual local corespunzător vederii respective. Fiecare model de date conceptual
local cuprinde elementele enumerate în tabelul de mai jos, din care se desprind sarcinile de
proiectare conceptuală.

Elemente ale modelului de Sarcini pentru construirea modelului conceptual local

date conceptual local (Paşi)
Tipuri de entităţi 1.1. Identificarea tipurilor de entităţi (t.e.)
Tipuri de relaţii 1.2. Identificarea tipurilor de relaţii (t.r.)
Atribute 1.3. identificarea şi asocierea atributelor cu t.e. şi t.r.
Domeniile atributelor 1.4. Determinarea domeniilor atributelor
Cheile candidat 1.5. Determinarea atributelor chei candidat şi chei primare
Cheile primare
1.6. Specializarea/generalizarea t.e. (opţional)
1.7. Desenarea diagramei ER
1.8. Revizuirea modelului conceptual local cu utilizatorii

5.1.2. Identificarea tipurilor de entităţi (t.e.)

Modalităţi de identificare:
- studierea specificaţiei cerinţelor utilizatorului referitor la funcţia utilizatorului în
întreprindere; se caută substantivele în specificaţia cerinţelor utilizatorului (de
exemplu Nr_Personal; NumeP; Nr_Proprietate; AdresaP; Chirie etc.)
- se caută obiectele principale de interes, excluzându-se calităţile; se grupează (de
exemplu Nr_Personal şi NumeP vor aparţine aceluiaşi tip de entitate Personal)
- se identifică obiectele care există pe cont propriu (de exemplu Personal există
indiferent de Nr_Personal, NumeP, etc.)
- discuţii cu utilizatorii (de exemplu pentru eliminarea sinonimelor: Angajat =
Personal)

1
 Documentarea t.e.: după identificarea t.e. li se atribuie denumiri evidente, care se trec
într-un dicţionar de date.

5.1.3. Identificarea tipurilor de relaţii (t.r.)

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

5.1.5. Identificarea şi asocierea atributelor cu t.e. sau t.r.

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

5.1.6. Determinarea domeniilor atributelor

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

5.1.7. Determinarea atributelor chei candidat şi chei primare

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

2
 - Documentarea cheilor primare şi alternative prin înregistrare în dicţionarul de date.

5.1.8. Specializarea/generalizarea tipurilor de entităţi (opţional)

Acest pas este dictat de reprezentarea cât mai clară a entităţilor importante şi a
relaţiilor dintre ele. Diagrama ER finală trebuie să fie cât mai lizibilă.
Modelul ER din figura 5.1 a conţine entităţile Proprietate_de_Inchiriat şi
Proprietate_de_Vanzare. Se generalizează prin crearea entităţii Proprietate (fig. 5.1 b.)

Nr.
Nr. Chiriaş Chirie Preţ Cumpărător
Tip Tip

M N Proprietate Proprietate M 1
Chiriaş Închiriază de închiriat de vânzare Cumpără Cumpărător

Nr.
Nr. M
Proprietate
M Proprietate
Deţine
Adresa Adresa
1
Proprietar

Nr.
a) Proprietar

Nr.
Nr. Chiriaş Chirie Preţ Cumpărător

M N Proprietate Proprietate M 1
Chiriaş Cumpără Cumpărător
Închiriază de închiriat de vânzare

d
Tipul
M 1
Proprietate Deţine Proprietar

Adresa
Nr.
Proprietate Nr.
Proprietate
b)

Fig. 5.1. Exemplu de generalizare a tipului de entitate

Entităţile Proprietate_de_Inchiriat şi Proprietate_de_Vanzare devin subclase ale entităţii

Proprietate în baza atributelor comune (Tipul, Adresa, cheia primară) şi în baza relaţiilor
comune asociate fiecăreia (Proprietar_deţine_Proprietate).

3
Entităţile subclasă au şi atribute diferite (Chirie respectiv Preţ) şi relaţii diferite (Inchiriaza
respectiv Cumpara).

5.1.9. Desenarea diagramei ER

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

5.1.10. Revizuirea modelului de date conceptual local împreună cu utilizatorii

Acest pas este necesar pentru a garanta că modelul este o reprezentare „adevărată” a
întreprinderii d.p.d.v. al utilizatorului.

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

5.2. Proiectarea logică

Proiectarea logică este procesul de construire a unui model al informaţiilor utilizate în
întreprindere pe baza unui anumit model de date, dar independent de SGBD şi de alte
consideraţii de ordin fizic.

5.2.1 Construirea şi validarea modelului de date logic pentru fiecare vedere a

utilizatorilor
Acest pas este bazat pe modelul de date conceptual al vederii utilizatorului asupra
întreprinderii. Se efectuează modificarea structurii modelului conceptual conform cerinţelor
modelului de date relaţional (conform cerinţelor caracteristice unui sistem de gestionare
relaţional).

5.2.1.1 Transpunerea modelului de date conceptual local într-un model de date logic
local
Se rafinează modelul de date conceptual local prin eliminarea caracteristicilor
nedorite.

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

Nr.
Nume ziar Proprietate

M N
Ziar Face reclama Proprietate

a)
Nr.
Nume ziar Proprietate

1 N M 1
Ziar Listeaza Reclama Reclama In Proprietate

b)

Fig. 5.2. Relaţia de cardinalitate M:N se descompune în 2 relaţii de cardinalitate 1:M

Apar două tipuri de relaţii noi: Listeaza şi respectiv ReclamaIn care leagă entitatea
slabă de cele 2 entităţi tari.

5.2.1.1.2 Eliminarea relaţiilor complexe

O relaţie complexă include cel puţin trei tipuri de entităţi. Ea trebuie descompusă
pentru a identifica o relaţie intermediară. Relaţia complexă se înlocuieşte cu un număr
corespunzător de relaţii binare de cardinalitate 1:M.
În exemplul din figura 5.3. relaţia complexă Inchiriaza s-a descompus în trei relaţii
1:M, anume Organizeaza, AsociatCu şi Ţine; s-a identificat o entitate slabă:
Acord_de_Inchiriere care este legată de entităţile tari (iniţiale) prin cele trei relaţii binare de
cardinalitate 1:M identificate. Analizaţi constrângerile de participare din fig. 5.3. a şi 5.3. b!

5
 Nr.
Nr. Personal Proprietate

M M
Personal Inchiriaza Proprietate

Chirias

Nr. Chirias

a)

Nr.
Nr. Personal Proprietate

1 M M 1
Personal Organizeaza Proprietate Asociat cu Proprietate

Ţine

Chirias

Nr. Chirias

b)

Fig. 5.3. Relaţie complexă M:N descompusă în trei relaţii binare 1:M.

5.2.1.1.3 Eliminarea relaţiilor recursive

Acesta este un tip particular de relaţie care trebuie descompusă pentru a identifica o
relaţie intermediară. În exemplul din figura 5.4. relaţia recursivă Supravegheaza este
eliminată prin identificarea unei relaţii adiţionale denumită SupravegheatDe şi a unei entităţi
slabe: Personal_Alocat.

6
 Supervizează

1 M

Personal

Nr_Personal

a)

Personal_Alocat
1 M

SupravegheatDe Supervizează

1 1

Personal

Nr_Personal

b)
Fig. 5.4. Eliminarea unei relaţii recursive

5.2.1.1.4 Eliminarea relaţiilor cu atribute

Atunci când o relaţie are asociat un atribut, acest lucru sugerează existenţa unui tip de
entitate neidentificat. Exemplul din figura 5.5 se referă la determinarea numărului de ore
lucrate de angajaţii temporari atribuiţi fiecărei filiale. Relaţia LucreazaLa are atributul Ore-
Lucrate şi este de cardinalitate M:N. Se descompune în două relaţii binare de cardinalitate
1:M. Acum atributul Ore_Lucrate aparţine noii entităţi slabe identificate: Alocaţie_Filiala.
Analizaţi constrângerile de participare din fig. 5.5 a şi 5.5. b!

7
 Ore_Lucrate Nr. Filială
Nr. Personal

M N
Personal Lucrează La Filiala

a)

Ore_Lucrate Nr. Filială

Nr. Personal

N M N
Personal
1
Atribuit La Alocaţie_ Necesită Filiala
Filiala

b)

Fig. 5.5. Eliminarea unei relaţii cu atribut

5.2.1.1.5 Eliminarea atributelor cu valori multiple

Este vorba de atribute cu mai multe valori pentru o singură entitate. Acest atribut
trebuie descompus pentru a identifica o nouă entitate. Exemplul din figura 5.6. se referă la
evidenţa filialelor, unde o filială poate avea mai multe numere de telefon. Se identifică o nouă
entitate: Telefon, legată de entitatea Filiala prin relaţia Are.

Nr. Telefon Nr. Filială

Adresă

Filiala

Nr. Filială
Nr. Telefon

M 1
Telefon Are Adresa
Filiala

Fig. 5.6. Eliminarea atributelor cu valori multiple

5.2.1.5 Reexaminarea relaţiilor 1:1

Asemenea relaţii pot indica existenţa a două relaţii care să reprezinte acelaşi obiect în
cadrul întreprinderii. De exemplu entităţile Filiala şi departament pot fi sinonime. În astfel de

8
situaţii cele două entităţi se îmbină, selectând una din cheile primare, dacă acestea nu coincid.
Cealaltă cheie primară devine alternativă.

5.2.1.1.7 Eliminarea relaţiilor redundante

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

1 1
Bărbat CăsătoritCu Femeie

1 1

Tatăl lui Mama lui

1
M
M
Copil

Fig. 5.7. Relaţie neredundantă!

În exemplul din figura 5.7. relaţia este neredundantă, deşi există 2 căi intre entitatea
Copil şi Barbat. Tatăl ar putea avea copii dintr-o căsătorie precedentă, sau ar putea să nu fie
căsătorit cu mama copilului, iar în figură se modelează numai căsătoria curentă a tatălui.

5.2.1.2 Extragerea relaţiilor (tipurilor de entităţi) din modelul de date logic local
În urma 5.2.1.1 s-a obţinut modelul de date logic local, ca urmare a rafinării modelului
de date conceptual.
La 5.2.1.2. se extrag relaţiile pentru a reprezenta entităţile care le compun.
Componenţa fiecărei relaţii va fi descrisă utilizând un limbaj de definire a bazelor de date
(DBDL). Într-un DBDL apare denumirea relaţiei, apoi între paranteze atributele simple. Se
identifică cheia primară, cheile alternative şi/sau cheile străine ale relaţiei. Se trece relaţia
care conţine cheia străină ca şi cheie primară.

Relaţia pe care o entitate o are cu altă entitate este exprimată prin mecanismul cheie
primară – cheie străină. Adică cheia primară din entitatea părinte devine cheie străină în
entitatea copil.
În continuare se prezintă cum relaţiile care reprezintă entităţile şi relaţiile acestora
sunt extrase din structurile de date posibile, prezentate în modelul de date logic (fig. 5.8.).

9
 Strada Oraşul
Prenume
Nume
Nume_ CodPoştal
Adresa
Prenume

Nr_Filială
Adresa
Funcţie Administrează
1
1
Salariu Personal Filiala
M Nr. Fax
Are 1
Sex 1
Nr_Personal Nr. Tel.

ÎnruditCu

Rudenie M
Rudă
Apropiată
NumeR
Nr. Tel.
Adresa

Fig. 5.8. Model de date logic

Din acest model de date logic se extrag:

a. Tipuri de entităţi tari:

Pentru fiecare entitate tare (obişnuită) se creează o relaţie care să cuprindă toate
atributele sale simple.
Exemplu: entitatea tare Personal
Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu)
Cheie primară Nr_Personal

b. Tipuri de entităţi slabe: Ruda_Apropiata.

Pentru fiecare entitate slabă se creează o relaţie care să cuprindă toate atributele sale simple.
În plus se include cheia primară a entităţii părinte (sau proprietar) ca şi cheie străină.

Compoziţia acestei relaţii va fi:

Ruda_Apropiata (Nr_Personal, NumeR, Adresa, Nr_Tel, Rudenie)
Cheie primară Nr_Personal împreună cu NumeR
Cheie străină Nr_Personal se referă la Personal (Nr_Personal)

10
c. Tipuri de relaţii binare unu la unu (1:1)
În relaţia de cardinalitate 1:1 Personal Administreaza Filiala entitatea părinte este
Personal, deoarece are participare parţială. Ca urmare se plasează o copie a cheii primare din
Personal în Filiala, unde devine cheie străină sub denumirea Nr_Personal_Manager.

Compoziţia acestor relaţii va fi:

Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu)
Cheie primară Nr_Personal
Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)
Cheie primară Nr_Filiala
Cheie alternativă Nr_Tel sau Nr_Fax
Cheie străină Nr_Personal_Manager, care se referă la Personal (Nr_Personal)

d. Tipuri de relaţii binare unu-la-mai-mulţi (1:M)

Pentru fiecare relaţie binară 1:M între entităţile E1 şi E2 se plasează o copie a cheii
primare din E1 în E2, unde devine cheie străină. Entitatea aflată în partea notată cu „1” este
entitatea părinte, iar cea din partea cu „M” este entitatea copil. Întotdeauna cheia primară din
entitatea părinte devine cheie străină în entitatea copil.

Exemplu: Filiala Are Personal, unde Filiala este părinte iar personal este copil.

Compoziţia acestor relaţii va fi:

Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu, Nr_Filiala)
Cheie primară Nr_Personal
Cheie străină Nr_Filiala se referă la Filiala (Nr_Filiala)
Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)
Cheie primară Nr_Filiala
Cheie alternativă Nr_Tel sau Nr_Fax
Cheie străină Nr_Personal_Manager, care se referă la Personal (Nr_Personal)

5.2.1.2. se încheie cu documentarea relaţiilor şi atributelor chei străine.

Compoziţia relaţiilor extrase din modelul de date logic se documentează utilizând DBDL.
Sintaxa poate fi extinsă pentru a exprima constrângerile de integritate asupra cheilor străine
(vezi 5.2.1.6). Şi dicţionarul de date trebuie reactualizat cu noile atribute cheie identificate la
5.2.1.2

5.2.1.3 Validarea modelului prin utilizarea normalizării

Normalizarea este o procedură de stabilire a atributelor care aparţin împreună unui tip
de entitate. Prin normalizare datele sunt organizate conform dependenţelor lor funcţionale şi
se elimină riscul anomaliilor de reactualizare. În prima formă normală se elimină grupurile
repetitive.

5.2.1.4 Validarea modelului conform tranzacţiilor utilizatorului

Modelul trebuie să accepte tranzacţiile cerute de către vederile utilizatorului.
Tranzacţiile se determină din specificaţiile cerinţelor utilizatorilor. Prin folosirea diagramei
ER, a dicţionarului de date şi a legăturilor cheie primară/cheie străină prezentate în relaţii se
încearcă efectuarea manuală a tranzacţiilor.

11
5.2.1.5 Desenarea diagramei ER
Se desenează varianta finală a diagramei ER, validată prin normalizare şi conform cu
tranzacţiile pe care trebuie să le accepte.

5.2.1.6 Definirea constrângerilor de integritate

Prin impunerea de constrângeri se protejează baza de date faţă de riscul de incoerenţă.
Se consideră 5 tipuri de integritate, anume referitoare la:
a. datele cerute
b. domeniile atributelor
c. integritatea entităţilor
d. integritatea referenţială
e. constrângerile întreprinderii

a. Datele cerute
Unele atribute nu admit Null-uri. În aceste situaţii se selectează proprietatea de câmp
required, care cere date pentru câmpul respectiv. Se verifică dacă aceste constrângeri au fost
identificate şi documentate în dreptul atributelor în dicţionarul de date (vezi 5.1.2)

b. Constrângerile privind domeniile atributelor

Se verifică dacă s-au identificat şi documentat la 5.1.4

c. Integritatea entităţilor
Cheia primară a unei entităţi nu poate conţine Null-uri. Se verifică 5.1.5

d. Integritatea referenţială
Se referă la relaţia entitate părinte – entitate copil. Se ştie că cheia primară din părinte
se copiază în copil unde devine cheie străină.

Integritatea referenţială înseamnă ca o valoare nenulă a cheii străine din entitatea copil
trebuie să se refere la (să coincidă cu) o valoare existentă în entitatea părinte.
Dacă entitatea copil are participare totală în relaţie, nu sunt permise Null-uri în câmpul cheie
străină. Se admit atunci când entitatea copil are participare parţială.

Asigurarea integrităţii referenţiale se realizează prin constrângeri de existenţă. Acestea

definesc condiţiile în care poate fi inserată, reactualizată (modificată) sau ştearsă o cheie
candidat sau o cheie străină.

Se ia ca exemplu relaţia Personal Administrează Proprietate, de cardinalitate 1:M.

Entitate părinte (Ep): Personal, cheie primară: Nr_Personal
Entitate copil (Ec): Proprietate, cheie străină: Nr_Personal, copie a cheii primare din
Personal.

Cazul 1. Inserarea unei apariţii în relaţia (entitatea) copil

Pentru a asigura integritatea referenţială se verifică dacă atributul Nr_Personal din apariţia
nou inserată în Ec este stabilit ca Null sau are o valoare existentă în Ep.

Cazul 2. Ştergerea unei apariţii din relaţia (entitatea) copil

Se poate efectua fără probleme, nu afectează integritatea referenţială.

12
Cazul 3. Reactualizarea cheii străine în relaţia (entitatea) copil
Similar cazului 1.

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

Se poate efectua fără probleme. Ep are participare parţială, deci poate exista un membru al
personalului care nu administrează o proprietate.

Cazul 5. Ştergerea unei apariţii din relaţia (entitatea) părinte.

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

NO ACTION Blocarea ştergerii apariţiei din Ep, dacă are corespondent(i) în Ec

CASCADE Dacă o apariţie în Ec se şterge, se şterg automat corespondenţii din Ec.

Dacă Ec acţionează ca Ep în altă relaţie, ştergerea se propagă în
cascadă.

SET NULL Când se şterge o apariţie din Ep, valorile cheii străine în Ec sunt setate
la Null. Are loc o reactualizare prin setare la Null a valorilor atributelor
selectate din cheia străină a Ec. Această strategie se poate aplica numai
dacă atributele cheie străină acceptă Null-uri.

SET DEFAULT Când se şterge o apariţie din Ep, valorile cheii străine corespunzătoare
din Ec sunt setate la valori prestabilite (default).
Exemplu: se şterge un membru al personalului în Ep (Personal) şi
automat proprietăţile pe care acestea le-a administrat trecute în Ec
(Proprietăţi) se setează la atributul Nr_Pers la valoarea corespunzătoare
managerului.

NO CHECK Nu are loc nici o verificare de integritate. Când se şterge o apariţie din
Ep nu este garantată menţinerea integrităţii referenţiale.

Cazul 6. Reactualizarea cheii primare în relaţia (entitatea) părinte

Dacă valorii reactualizate a cheii primare în Ep îi corespundeau una (mai multe) valori ale
cheii străine în Ec, integritatea referenţială este pierdută. Se va aplica una din strategiile de la
cazul 5.

e. Constrângerile întreprinderii
Sunt de fapt regulile de afaceri care pot uneori genera reactualizări ele entităţilor. De
exemplu agenţia imobiliară poate stabili ca un membru al personalului să administreze
maxim 10 proprietăţi.
5.2.1.6. se încheie cu documentarea tuturor constrângerilor de integritate. Aceasta
se face în dicţionarul de date, pentru a fi luate în considerare la implementarea fizică.

5.2.1.7 Revizuirea modelului de date logic local împreună cu utilizatorii

Se verifică dacă modelul de date logic local este o reprezentare „adevărată” a vederii
utilizatorului. Modelul de date logic local trebuie să fie complet şi in întregime documentat.
Modelul şi documentaţia se revăd împreună cu utilizatorul.

13
5.2.2. Construirea şi validarea modelului de date logic global

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

5.2.2.1. Îmbinarea modelelor de date logice locale individuale într-un singur model de
date logic global al întreprinderii

(1) Revizuirea denumirilor entităţilor şi cheilor primare din modelele locale.

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

(Vederea 1)
Personal (Nr_Personal, Nume_Prenume, Funcţie, Sex, Salariu, Nr_Filială)
Cheie primară Nr_Personal
Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

(Vederea 2)
Personal (Nr_Personal, Prenume, Nume, Adresa, Nr_Filială)
Cheie primară Nr_Personal
Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

(Vedere Globală)
Personal (Nr_Personal, Prenume, Nume, Adresa, Funcţie, Sex, Salariu, Nr_Filială)
Cheie primară Nr_Personal
Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

Fig. 5.9. Îmbinarea entităţilor cu aceeaşi denumire şi aceeaşi cheie primară

În versiunea globală obţinută prin îmbinare s-a utilizat versiunea descompusă a atributului
Nume_Prenume (în urma consultării cu utilizatorii).

Îmbinarea entităţilor cu aceeaşi denumire şi chei primare diferite (fig. 5.10)

Astfel de entităţi nu au aceeaşi cheie primară, dar au chei candidat similare. Rezultă
aceeaşi vedere globală ca în fig. 5.9.

14
 (Vederea 1)
Personal (Nr_Personal, Nume_Prenume, Funcţie, Sex, Salariu, Nr_Filială)
Cheie primară Nume_Prenume
Cheie alternativă Nr_Personal
Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

(Vederea 2)
Personal (Nr_Personal, Prenume, Nume, Adresa, Nr_Filială)
Cheie primară Nr_Personal
Cheie alternativă Prenume, Nume
Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

Fig. 5.10. Îmbinarea entităţilor cu aceeaşi denumire şi chei primare diferite

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

Astfel de entităţi se pot identifica atunci când: denumirile sunt diferite, dar indică
acelaşi scop, după cheia primară, după participarea în anumite relaţii.
Exemplu: Entităţile Personal şi Angajaţi.

(4) Includerea (fără îmbinare) a entităţilor unice din fiecare vedere locală
Toate entităţile care nu au echivalent se includ nemodificate în modelul global.

(5) Îmbinarea relaţiilor din vederile locale

Se examinează toate relaţiile (denumire, scop, constrângeri structurale) din toate
vederile locale şi se elimină conflictele, prin:
- Îmbinarea relaţiilor cu aceeaşi denumire şi acelaşi scop, apoi
- Îmbinarea relaţiilor cu denumiri diferite dar acelaşi scop

(6) Includerea (fără îmbinare) a relaţiilor unice din fiecare vedere locală
Relaţiile pentru care nu s-au găsit relaţii identice în alte vederi se includ nemodificate
în modelul global.

(7) Căutarea entităţilor şi relaţiilor lipsă

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

(8) Verificarea cheilor străine

Se verifică dacă cheile străine din entităţile copil mai sunt corecte şi se efectuează
modificările necesare.

15
 (9) Verificarea constrângerilor de integritate
Se verifică dacă constrângerile de integritate ale modelului global nu intră în conflict
cu constrângerile de integritate din vederile utilizatorilor. Conflictele se rezolvă prin
consultarea cu utilizatorii.

(10) Desenarea modelului de date logic global

Se desenează diagrama ER a modelului de date logic global, care reprezintă îmbinarea
tuturor modelelor de date logica locale.

(11) Reactualizarea documentaţiei

Documentaţia trebuie reactualizată în urma modificărilor intervenite la realizarea
modelului global. Documentaţia trebuie să reflecte întotdeauna modelul de date curent.

5.2.2.2 Validarea modelului de date logic global

Se realizează prin utilizarea normalizării şi conform tranzacţiilor cerute, dacă este
necesar. Este un pas echivalent cu 5.2.1.3 respectiv 5.2.1.4, anume se fac aceleaşi validări
dar acum pentru modelul de date logic global.

5.2.2.3 Verificarea în vederea dezvoltării locale

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

5.2.2.4 Desenarea diagramei ER finale

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

5.2.2.5 Revizuirea modelului de date logic global împreună cu utilizatorii

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

5.2.3. Rezumatul capitolului 5.2.

Proiectarea logică a bazelor de date este procesul de construire a unui model al

informaţiilor utilizate în cadrul unei întreprinderi, bazat pe un anumit model de date, dar
independent de un anumit SGBD şi de alte consideraţii de ordin fizic.
Principalele etape cuprind: construirea şi validarea unui model de date logic local
corespunzător fiecărei vederi a utilizatorilor (5.2.) şi construirea şi validarea unui model de
date logic global (5.2.2).
Rafinarea unui model de date conceptual pentru a obţine un model de date logic
include: eliminarea relaţiilor de tip M:N, a relaţiilor complexe, recursive, cu atribute, a

16
atributelor cu valori multiple, reexaminarea relaţiilor de tip 1:1 şi eliminarea relaţiilor
neredundante.
Modelul de date logic se validează prin normalizare, prin care se garantează că
modelul reprezintă fidel întreprinderea, este coerent, cu redundanţă minimă şi stabilitate
maximă.
Constrângerile de integritate se impun pentru a proteja BD faţă de a deveni
incoerentă. Există 5 tipuri de constrângeri de integritate: asupra datelor necesare, ale
domeniilor atributelor, de integritate a entităţilor, de integritate referenţială şi ale
întreprinderii.
Integritatea referenţială se asigură prin constrângeri de existenţă, care definesc în
ce condiţii poate fi o cheie candidata sau străină inserată, reactualizată sau ştearsă.
Există mai multe strategii care pot fi aplicate atunci când o apariţie a entităţii părinte pe care
vrem să o ştergem are corespondent în entitatea copil: NO ACTION, CASCADE, SET
NULL, SET DEFAULT şi NO CHECK.
Constrângerile întreprinderii se numesc uneori şi reguli de afaceri.
Modelul de date logic este susţinut de către documentaţie, cum ar fi dicţionarul de
date sau schema relaţională, care sunt realizate pe parcursul construirii modelului.

17