1

Crearea unui proiect de baze de date

Procesul maprii
Transformarea modelului conceptual, a modelului ERD n model fizic, adic n baza de date propriu
zis, se numete mapare.

Model conceptual Model fizic Termen Oracle
Entitate Tabel Table
Atribut

Cmp ( coloan) Field
Instan nregistrare
(articol,linie)
Record
UID Cheie primar Primary key
Indentificator unic
secundar
Cheie unic
Relaie Cheie strin i
constrngere
Foreign key
Foreign key Constraint
Regulile afacerii Restricii
(constrngeri)
Constraints

Maparea relaiilor

Tip de relaie Reguli de mapare

E1

E1

E1
One-to-one



E2

E2

E2
1. Se introduce n entitatea E1 cheia primar a entitii
E2, ca i cheie strin .Aceast cheie strin va fi i
cheie unic
2. Cheia strin se introduce n entitatea E1 sau n entitatea
E2, dar se scrie cod adiional
3. Cheia strin se introduce n entitatea cu mai puine
instane
One-to-many Introducem n tabela corespunztoare entitii de pe partea
many a relaiei cheia primar a entitii de pe partea one
a relaiei. Cheia strin va avea opionalitatea relaiei
- dac relaia pe partea many este opional atunci i
coloanele cheii strine vor fi opionale.
- dac relaia este obligatorie pe partea many atunci cheia
strin va fi opional
Non-transferabil Cheia strin nu poate fi actualizat
Barat Cheia strin apare n partea many a relaiei i n plus, face
parte din cheia primar
Arc Se introduc n entitatea cu arc dou chei strine, cte una
pentru fiecare arc i acestea sunt ntotdeauna opionale
-se scrie cod adiional pentru a verfica exclusivitatea
2
Supertipuri,
subtipuri
1. O singura tabela in care coloane vor fi toate atributele
supertipului si subtipurilor.
Atributele subtipurilor se transform n chei straine
optionale.
Se introduce o consterangere de validare pentra a verfica
daca coloanele obligatorii ale subtipurilor nu sunt nule.
2. Dou tabele (cnd cele 2 subtipuri au foarte putine
atribute n comun). Atributele supertipului devin coloane n
cele 2 tabele. Relaiile supertipului devin chei strine ale
subtipului.


Maparea relaiilor

1. Maparea relaiilor one-to-one
Lund n considerare entitile FACTURA i COMANDA legate printr-o relaie one-to-one, este evident
c putem include cheia primar id din FACTURA n cadrul tabelei COMANDA, dar putem proceda la fel de
bine i invers, incluznd cheia primar a tabelei COMANDA n cadrul tabelei FACTURA, deoarece fiecrei
instane a entitii FACTURA i corespunde cel mult o instan a entitii COMANDA, dar i invers, oricrei
instane a entitii COMANDA i corespunde cel mult o instan a entitii FACTURA.
Figura 1. 1 Maparea relaiilor one-to-one



Se observ faptul c n tabela FACTURI cheia strin nr_comanda este o coloan obligatorie,
corespunznd tipului de relaie din care deriv maparea, cea de relaie obligatorie.

2. Maparea relaiilor one-to-many

n gereral, la maparea unei relaii de tip one-to-many, vom introduce n tabela corespunztoare entitii
de pe partea many a relaiei cheia primar a entitii de pe partea one a relaiei. Cmpurile astfel ntroduse se
vor numi cheie strin (foreign keys).
Aadar:
- cheia strin a unei tabele este cheia primar din tabela referit
3
- cheia strin este ntotdeauna introdus n tabela corespunztoare entitii din partea many a relaiei.
- dac relaia pe partea many este opional atunci i coloanele cheii strine vor fi opionale.
- dac relaia este obligatorie pe partea many atunci coloanele ce fac parte din cheia strin vor fi
opionale
n exemplul de mai jos este ilustrat att maparea relaiei one-to-many ct i a relaiei barate:
Figura 1. 2 Maparea relaiei one-to-many


4


3. Maparea relaiilor recursive

Dac vom privi o relaie recursiv ca pe o relaie de tipul one-to-many ntre o entitate i ea nsi, atunci
acest caz se reduce la regulile de mapare date anterior.


Figura 1. 3 Maparea relaiilor recursive


5
4. Maparea relaiilor barate

Relaiile barate sunt mapate ca i cheie strin n tabela aflat n partea many a relaiei, la fel ca la
maparea oricrei relaii one-to-many. Bara de pe relaie exprim faptul c acele coloane ce fac parte din cheia
strin vor deveni parte a cheii primare a tabelei din partea many a relaiei barate. Un exemplu este cel din
figura 1.19.

5. Maparea tipurilor i subtipurilor

Nici un sistem de gestiune a bazelor de date nu suport n mod direct supertipurile i subtipurile. Exist
mai multe soluii ale acestei probleme.

Varianta 1. Se creeaz o tabel pentru supertip i cte o tabel pentru fiecare subtip. Diagramele de
tabel n acest caz vor fi:
Figura 1. 4 Maparea tipurilor i subtipurilor


Cheia primar a supertipului va fi inclus n toate tabelele corespunztoare subtipurilor i va deveni
cheia primar a acelei tabele. Atributele i cheile strine provenite din relaiile de la nivelul supertipului vor fi
memorate n tabela corespunztoare supertipului. Atributele i relaiile de la nivel de subtip, se vor memora doar
n tabela corespunztoare subtipului respectiv. Acest model este cel mai natural dar poate crea multe probleme
privind eficiena ntruct sunt necesare multe operaii de interogare din tabele multiple, pentru a obine
informaii suplimentare despre toi clienii.

Varianta 2: Se creeaz cte o tabel pentru fiecare subtip. Atributele i cheile strine provenite din
relaiile de la nivelul supertipului vor fi introduse n fiecare tabel astfel obinut, acestea fiind motenite de
ctre fiecare subtip.

6
Figura 1. 5 Maparea tipurilor i subtipurilor



Varianta 3. Se creeaz o singur tabel pentru supertip. Aceast tabel va conine toate coloanele
corespunztoare atributelor de la nivelul supertipului, dar i toate coloanele corespunztoare tuturor atributelor
din toate subtipurile. Atributele de la nivelul supertipului i vor pstra opionalitatea, ns atributele de la
nivelul subtipurilor, vor fi toate introduse n tabel, dar vor fi toate opionale. Relaiile de la nivelul supertipului
se transform normal. Relaiile de la nivelul subtipurilor se vor implementa cu ajutorul cheilor strine opionale.
Figura 1. 6 Maparea tipurilor i subtipurilor


Am introdus un atribut suplimentar Tip_client, cu ajutorul cruia vom codifica dac un client este
persoan fizic sau companie.Deoarece atributele de la nivelul subtipurilor sunt obligatorii pentru subtipul
respectiv, va trebui stabilit o regul de integritate la nivel de nregistrare, care s verifice c pentru o
nregistrare de un tip anume sunt completate cmpurile corespunztoare. De exemplu, la adugarea unei noi
companii n tabela CLIENTI, trebuie verificat cmpul cod_fiscal dac este completat. Se observ c vor fi multe
cmpuri cu valoarea null, ceea ce conduce la un spaiu de memorie vast ocupat de tabel.

7
Maparea arcelor
Pentru a mapa un arc se creeaz un numr de chei strine egal cu numrul de relaii existente n arcul
respectiv.



Figura 1. 7 Maparea arcelor



Dei relaiile din arc sunt obligatorii, cheile strine corespunztoare au fost setate ca fiind opionale,
deoarece pentru fiecare nregistrare trebuie s avem completat una din cele dou chei strine, iar cealalt cheie
strin trebuie s rmn necompletat (principiul exclusivitii). n etapa de proiectare fizic se va implementa
o condiie de integritate care s verifice aceast condiie.

8
6. Maparea relaiilor nontransferabile
O relaie nontransferabil din modelul conceptual presupune definirea n modelul fizic a urmtoarei
restricii: cheia strin definit pentru relaia nontransferabil nu poate fi actualizat. Restriciile care se
implementeaz n modelul fizic pentru chei strine nu prevd aceast interdicie, astfel nct se impune ca prin
programare s fie create module de program pentru verificarea acestei reguli. Nontransferabilitatea dedus din
regulile afacerii trebuie bine documentat pentru ca ulterior programatorii s elaboreze codurile de program
corespunztoare.





Figura 1. 8 Maparea relaiilor nontransferabile




n anexa 2 a lucrrii este prezentat un exemplu complet de mapare bazat pe diagrama ERD elaborat
pentru afacerea aleas ca studiu de caz .