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 .