Sunteți pe pagina 1din 19

Facultatea de Automatica si Calculatoare Iasi

LECIA 3

Relaiile n detaliu ................................................................................ 2


Stabilirea unei relaii .....................................................................................................................................2
Tipuri de relaii..............................................................................................................................................5
Rezolvarea relaiilor Relaii si entiti de intersecie ...............................................................................11
Normalizarea datelor in timpul modelarii ..................................................................................................13
Rezumat ......................................................................................................................................................15
Practica........................................................................................................................................................15

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

1|

Facultatea de Automatica si Calculatoare Iasi

Relaiile n detaliu
Obiective
In aceast lecie discutm n detaliu modul de stabilire a unei relaii ntre dou entiti.
Se vor trece in revista tipurile de relaii i exemplele aferente lor precum si exemple pentru tipuri de relaii
mai puin frecvente. Se va discuta si despre relaiile netransferabile i despre diferenele i asemnrile
dintre relaii i atribute. Se va analiza cazul si se vor discuta soluii pentru situaiile n care o relaie pare a
avea un atribut. n cele din urm sunt discutate regulile de normalizare n contextul modelarii conceptuale.
Aadar se vor analiza:

Relaii

Tipuri de relaii diferite

Nontransferabilitatea

Relaiile care par s aib atribute

Regulile de normalizare

La sfritul acestei lecii, ar trebui s fii capabili s facei urmtoarele:

Creai o relaie bine definite ntre entiti

Identificai tipurile de relaii care sunt comune i care nu

Dai exemple reale de tipuri de relaii mai puin frecvente

Alegei ntre folosirea unui atribut sau a unei relaii pentru a modela datele Dvs.

Modelarea unei relaii de tip m: m folosind o entitate de intersecie i dou relaii 1:m

Modelarea altor tipuri de relaii, cnd si cum sa facei acest lucru

Regulile de normalizare

Stabilirea unei relaii


Pentru stabilirea unei relaii se procedeaz astfel:
a) Se determina existena unei relaii
b) Se alege un nume pentru relaie, avnd in vedere ambele capete ale acesteia
c) Se determina opionalitatea sau obligativitatea relaiei
d) Se determina gradul relaiei
e) Se determina nontransferabilitatea relaiei

a) Determinarea existenei unei relaii


Verificai pentru fiecare dintre entiti, dac este cumva legat de una sau mai multe dintre entitile
existente n modelul dumneavoastr, i dac da, trasai o relaie folosind linia punctat.

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

2|

Facultatea de Automatica si Calculatoare Iasi


De obicei toate entitile unui model sunt legate de cel puin o alt entitate. Excepiile sunt rare dar
exist.
Dou entiti pot fi legate de mai multe ori, nu doar o singura dat. In exemplul cu sistemul de pota
electronic, ntre entitile MESAJ i USER exist dou relaii, una referitoare la userul care trimite mesajul
si cealalt referitoare la userul care l primete.
O entitate poate fi relaionata (legata) cu ea nsi. Aceasta se numete relaie recursiv. De exemplu
un mesaj poate fi un rspuns la un alt mesaj. Vedei diagrama de mai jos pentru mai multe detalii cu
privire la aceasta.
MESAJ

USER

trimitere
primire

rspunde (reply)

b) Alegerea unui nume pentru relaie


Uneori, numele relaiei este asemntor pentru ambele capete, din punct de vedere al citirii lui,
folosindu-se acelai verb la moduri diferite. Alteori se folosesc cuvinte distincte pentru cele doua capete,
cum ar fi printe pentru / copil al sau compuse din / parte a ...
Dac nu reuii sa gsii un nume, ncercai sa folosii numele exemplificate mai jos :
- Este alctuit din / este parte a
- Este clasificat ca / este clasificare pentru
- Este atribuit / este atribuirea pentru
- Se refer la / refer pe
- Responsabil pentru / responsabilitatea lui
Cteodat se pot folosi nume foarte scurte, de exemplu cu, n, de, pentru, la.
MESAJ

USER
Trimis de

Trimitator al

Trimis ctre

Primitor al

Rspuns pentru
Rspuns la
Se pune problema daca formulrile trimis ctre si primitor al sunt intr-adevr opuse. Dac este aa, se
presupune c n cazul n care un Mesaj este trimis la un utilizator, mesajul ajunge cu sigurana. Poate c ar
fi mai bine sa se foloseasc pentru numirea relaiei formularea primit de / primitor al.

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

3|

Facultatea de Automatica si Calculatoare Iasi


c) Determinarea Opionalitii la cele dou capete ale Relaiei
Pentru a determina tipul relaiei la ambele capete luam in discuie exemplul ElectronicMail si rspundem
la ntrebrile :
- Fiecare MESAJ trebuie sa fie trimis de un UTILIZATOR ?
- Fiecare UTILIZATOR trebuie sa fie expeditorul unui MESAJ ?
- Fiecare MESAJ trebuie sa fie trimis la un UTILIZATOR ?
- Fiecare UTILIZATOR trebuie sa fie destinatarul unui mesaj ?
Atunci cnd rspunsul la ntrebare este DA relaia este obligatorie, n caz contrar este opional.
In acest moment trebuie sa fii ateni pentru ca de multe ori un capt al relaiei pare s fie obligatoriu,
dar de fapt nu este.
n exemplul ElectronicMail se pare c fiecare MESAJ trebuie s fie trimis de ctre un UTILIZATOR. Dar un
MESAJ care a fost trimis de ctre un utilizator extern la un utilizator intern nu are nici o relaie cu un USER,
cu excepia cazului n care sistem au fost setat sa menin si utilizatorii externi.
Uneori, o relaie care pare n cele din urm obligatorie, dar iniial nu a fost considerata aa, trebuie
modelata ca opionala.

d) Determinarea Gradului la cele dou capete ale relaiei


Pentru a determina gradul relaiei la cele doua capete consideram exemplul cu ElectronicEmail si
rspundem la ntrebrile :
- Poate un MESAJ sa fie scris de mai mult de un singur UTILIZATOR ?
- Poate un UTILIZATOR s fie autorul a mai mult de un MESAJ ?
n cazul n care rspunsul este NU gradul este numit " unu " sau 1.
n cazul n care rspunsul este DA gradul este numit " mai muli " sau "m".
Gradul sau cardinalitatea relaiei trebuie s fie determinata pentru toate capetele relaiei.
De reinut ca un capt al relaiei de tip "mult " care este obligatoriu de la A la B nu nseamn c este
obligatoriu pentru ca A s fie mprit n mai mult de un B. Un singur B este suficient. Citii-astfel: fiecare A
trebuie s aibe corespondent cel puin un B.
A

B
Divizat in

Parte a

O relaie opionala de tipul " muli " nseamn ca la un capt exista zero, unul sau mai multe elemente. n
exemplul cu ElectronicEmail un USER poate fi autorul a 0,1 sau mai multe MESAJE.
Uneori, gradul este o valoare fix alteori se specifica doar o valoare maxima. Presupunem ca un MESAJ
poate conine unul sau mai multe ATASAMENTE, dar din motive legate de afacere, numrul de

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

4|

Facultatea de Automatica si Calculatoare Iasi


ATASAMENTE pentru un MESAJ nu poate depi 4. In acest caz gradul relaiei este < 5. Diagrama arat un
crowsfoot (picior de cioara).

USER

MESAJ
Scris de

Autor al

Primit de

Destinatar al

Rspunsul lui
Coninnd

Rspuns scris de

mai puin de 5
ATASAMENT

e) Determinarea gradului de transferabilitate a unei relaii al ambele capete


Atunci cind este creat un mesaj, UTILIZATORUL, creatorul mesajului, este o valoare bine cunoscuta,
certa. Ar fi ciudat dac un sistem de e-mail ar permite schimbarea autorului dup finalizarea unui MESAJ.
Deseori relaiile prezint caracteristica de a nu se putea schimba valorile pe care acestea le leag, odat
ce relaia este stabilita. Aceasta proprietate se numete nontransferabilitate.
Nontransferabilitatea

duce

la

imposibilitatea

schimbrii

valorilor

pentru

cheile

strine.

Nontransferabilitatea se reprezint grafic n diagrama prin plasarea unui mic simbol n form de diamant
pe linia de relaie, la captul ei.
Nu toate relaiile sunt netransferabile. S presupunem ca sistemul de e-mail permite unui utilizator s
depun un MESAJ ntr-un folder..

coninnd

FOLDER

cmp al
MESAJ

scris de
primit de

autor al

USER

destinatar al

Tipuri de relaii
Exist trei tipuri principale de relaii numite dup gradul lor:
Unu la mai muli ( 1 : m )
Muli la muli ( m : m )
Unu la unu ( 1:1)

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

5|

Facultatea de Automatica si Calculatoare Iasi


Relaiile - 1 : m
Tipurile de relaii 1:m sunt cel mai frecvent ntlnite ntr-un model ER. S-au discutat anterior cteva
exemple. Trebuie subliniat faptul ca aceste relaii se pot ntlni sub formele descrise mai jos si anume:

a.

Relaie 1: m obligatorie la ambele capete. Acest tip de relaie modeleaz de obicei entiti care nu
pot exista una fr cealalt. De multe ori existena unor detalii obligatorii pentru tabela printe este
mai decisiva dect o regul strict de afaceri. De multe ori relaia exprim faptul c o entitate este
ntotdeauna mprit n detalii. Vzuta din alt punct de vedere se exprim de multe ori ca o entitate
care se clasific, care are atribute.
Evitarea tipului de relaie 1: m obligatorie la ambele capete
De obicei ncercai sa evitai relaii de tipul (a) n favoarea celor de tip (b) privind subiectul dintr-o alta
perspectiv. De exemplu s presupunem c o comanda este definita ca avnd cel puin un element
(un produs comandat). Cu alte cuvinte o comanda este privit ca fiind un concept compus. Putei
evita modelare COMENZII prin a decide modelarea folosind un concept uor diferit cum ar fi entitatea
COMANDA_PRINCIPALA. Apoi definii un element din COMANDA_PRINCIPALA ca avnd zero, unul
sau mai multe ELEMENTE. Aadar o COMANDA ar fi atunci un lucru compus din dou entiti: orice
COMANDA_PRINCIPALA cu unul sau mai multe COMANDA_ELEMENTE. Daca apar linii goale in
COMANDA_PRINCIPALA acestea nu sunt considerate a fi o comand.
De ce sa evitam aceste relaii ?
Implementarea unei relaii de tip 1 : m care este obligatorie la ambele capete cauzeaz probleme
tehnice. n special, este dificil s se asigure c exista ntotdeauna detalii pentru o nregistrare noucreata. n cele mai multe medii de baze de date relaionale, este chiar imposibil.

Relaie de tip 1 opional : m obligatoriu. Acesta este un tip foarte comun de relaii, la fel ca si (d). n
mod normal cel puin 90 % toate relaiile sunt de tip (b) i (d). Relaiile exprim faptul c entitatea de
la captul 1 poate exista singura, n timp ce entitatea la captul m poate exista doar n contextul in
care exista si cealalt.

Relaie de tip 1 obligatoriu : m opional. Aceasta relaie nu este uzuala, o vei ntlni numai atunci
cnd relaia exprim faptul c o instan a unei entiti exist numai atunci cnd acesta nu este un set
gol n care elementele setului pot exista independent. Spre exemplu un produs poate fi parte dintr-o,
categorie dar o categorie nu prezint importanta daca nu are produse.

Relaie opional la ambele capete. A se vedea observaiile de (b).

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

6|

Facultatea de Automatica si Calculatoare Iasi


e

Relaia m:m obligatorie la ambele pri este foarte neobinuita n condiii normale. Aceasta relaie
pare s nsemne c o instan a entitii poate fi creata numai dac este imediat atribuita unei
instane ale altei entiti, precum i invers. Dar cum se poate produce acest lucru, atunci cnd nu
avem un exemplu al oricrei entiti ? Aplicarea regulii obligatoriu la zero duce la un conflict. Relaia
poate, totui, s fie parte a unui model cu caracter teoretic, ca cel matematic: o linie const
ntotdeauna din multe puncte si un punct este ntotdeauna parte din mai multe linii. Se poate descrie,
de asemenea, o situaie existent: DEPARTAMENTUL are ntotdeauna ANGAJATI i un ANGAJAT este
ntotdeauna atibuit unui DEPARTAMENT. Aici se pune ntrebarea dac este garantat c situaia va
rmne mereu n acest fel.
O relaie m : m care este obligatorie la ambele pri poate aprea atunci cnd relaia este parte a unui
arc. A se vedea lecia despre Constrngeri pentru mai multe detalii.

Relaia- m : m obligatorie la un capat nu este neobisnuita in versiunile initiale ale unui model cu
toate ca de obicei acestea dispar in etapele urmatoare

Relaia - m : m optionala la ambele capete este des intilnita in versiunile initiale ale unui model. Si
acestea dispar in etapele urmatoare.

Relaii-1:1

De

obicei

exista

doar

cteva

tipuri

diferite

de

relaii

1:1

fiecare

Model ER .

O relaie 1:1 obligatorie la ambele capete, conecteaz strns dou entiti: cnd creai o instan a
unei entiti trebuie s existe exact o instanta dedicata in entitatea cellalta n acelai timp. De
exemplu entitatea PERSOANA si entitatea NATERE. Acest lucru duce la ntrebarea: de ce dorii s
facei o distincie ntre cele dou entiti? Singurul rspuns acceptabil este: numai dac exist o
nevoie funcionala. Dac avei aceast relaie n modelul dvs., este de multe ori posibil sa fie o parte
a unui arc.

Relatia 1:1 obligatorie la un capt apare adesea ntr-un model n care rolurile sunt modelate, de
exemplu n acest model de spital.

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

7|

Facultatea de Automatica si Calculatoare Iasi


Att pentru PACIENT cat i pentru ANGAJAT rolurile sunt jucate de ctre o PERSOANA.Atributul
BLOOD_tip este, n conformitate cu acest model, de interes, doar atunci cnd persoana este un
pacient. Reinei c pacientului si angajatul nu pot fi modelati ca subtipuri ale PERSOANA, pentru ca o
persoan poate juca ambele roluri. Vom studia conceptul de roluri ntr-o lecie viitoare.

Relatia 1:1 optionala la ambele capete este mai puin frecvent. Cu toate acestea, ea poate s apar,
de exemplu, atunci cnd exist o relaie ntre dou entiti care sunt conceptual identice dar exist n
diferite sisteme. Un exemplu n acest sens este entitatea ANGAJAT ntr-un singur sistem i entitatea
PERSOANA, o ter parte ntr-un sistem diferit.
Multe relaii 1:1 apar atunci cnd unele dintre entiti reprezint diferite etape ale unui proces, cum
ar fi n exemplul urmtor..

Redundana
Ca si atributele, relatii pote fi redundante.
n exemplul din stnga putei deriva relaia de la PERSON la
COUNTRY din celelalte dou relaii pe care apoi s le eliminai
din model. Aceasta este o problem semantica i nu poate fi
rezolvata numai din

structura, cum se arata in exemplul

dreapta.

Relaii si Atribute
Atributele pot ascunde o relaie. De fapt, orice atribut poate ascunde o relaie.
n exemplu, atributul TYPE al entitatii ATTACHAMENT_TYPE poate fi nlocuit cu o entitate ATTACHAMENT_
TYPE si o relaie de la ATTACHAMENT la ATTACHAMENT_TYPE.
Nu averi alta optiune decat s modelati in acest fel, atita timp ct avei nevoie de a pstra atributele
suplimentare ale ATTACHAMENT TYPE. Dac nu exist
atribute importante ale ATTACHAMENT TYPE ce trebuie
pstrate, altele dect numele tipului, ai putea lua n
considerare eliminarea entitii i s considerati Type ca
un atribut al ATTACHAMENT.

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

8|

Facultatea de Automatica si Calculatoare Iasi


Relaii de tip m : m
Intr- o prim faza a unui model ER apar ntotdeauna multe si diferite tipuri de relaii m : m, acesta fiind un
lucru obinuit. De obicei aceste relaii sunt temporare, n etapele ulterioare ale modelarii, dup ce
adugai mai multe detalii la model, multe dintre relaiile de tip m: m dispar deoarece nu modeleaz cu
exactitate businessul analizat.
Un exemplu tipic este relaia dintre CLIENT si PRODUS.
cum
CLIENT
Id
Nume

cumprtor a

PRODUS
Cod
Nume
cumprat de

S presupunem c realizm un model pentru o companie de retail care vinde PRODUSE. Un CLIENT
cumpr PRODUSE. S presupunem c viitorii cumprtori sunt primii de asemenea n sistem. Acest lucru
ar nsemna c:
Un CLIENT poate cumpra unul sau mai multe PRODUSE
Un PRODUS poate fi achiziionat de unul sau mai muli CLIENI
Un eveniment tipic pentru aceast companie ar fi de exemplu atunci cnd un cumprtor POPESCU VASILE
achiziioneaz de exemplu dou CMI. "POPESCU VASILE" este un nume de CLIENT, "CMA" este un
nume de PRODUS. Se nate ntrebarea unde plasm acest "doi", informaia fiind legat de cantitate.
CLIENT
Id
Nume
Cantitate

CLIENT
Id
Nume

cumprtor a
cumprat de

cumprtor a
cumprat de

PRODUS
Cod
Nume

PRODUS
Cod
Nume
Cantitate

Este clar c CANTITATE nu este o proprietate a CLIENT, nici a PRODUS Cantitatea pare a fi un atribut al
relaiei dintre CLIENT i PRODUS.

CLIENT
Id
Nume

cumprtor a
cumprat de

PRODUS
Cod
Nume

Cantitate

Relatiile nu au si nu pot avea atribute. In exemplul nostru (si n general) lipseste o entitate pentru care

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

9|

Facultatea de Automatica si Calculatoare Iasi


CANTITATE este atribut. Din acest motiv trebuie s schimbm modelul prin adugarea entittii COMANDA
Ne punem din nou ntrebarea: unde sa plasam atributul cantitate ?
Acum cantitatea nu mai poate fi un atribut al unei COMENZI deoarece atributul trebuie s fie o valoare
singular, aadar nu poate conine trei valori 1, 2 i 1 n acelai timp.
Cantitate a devenit o proprietate a relaiei dintre PRODUS si COMANDA de tip m : m
CLIENT
* Id-ul
* Nume

Cu

al

Cu

pentru

PRODUS
* Cod
* Nume

COMANDA
* Id-ul
* Data

Cantitate

Aceasta conduce la apariia unei noi entiti COMANDA_DETALII. Observai ca relaia de tip m:m opionala
la ambele capete se transforma in doua relaii de tip 1 : m care sunt obligatorii la unul dintre capete. Setul
de tabele pentru acest model ar putea fi :
CLIENT
* Id-ul
* Nume

COMANDA
* Id-ul
* Data

PRODUS
* Cod
* Nume

COMANDA_DETALII
* Cantitate_vinduta

Tabelele ar putea arata astfel:


CLIENT

COMANDA

ID

Nume

Id_comanda

Data_comanda

Id_client

Popescu

28/02/2014

Vasilescu

01/03/2014

...

...

...

...

...

PRODUSE

COMANDA_DETALII

Cod_produs

Nume

Id_comanda

Cod_produs

Cantitate

Camasa

Pantalon

...

...

...

....

...

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

10 |

Facultatea de Automatica si Calculatoare Iasi

Rezolvarea relaiilor Relaii si entiti de intersecie


Mai devreme n aceast lecie ai vzut un exemplu tipic de relaie care pare a avea atribute. Relaiile din
exemplu erau de tip mai muli la mai-muli.
Pentru a face fa situaiei s-a creat o noua entitate, o entitate de intersecie, care nlocuiete relaia i
poate deine atribute. Acest lucru conduce la urmtoarele ntrebri :
Care sunt paii de rezolvare a unei relaii, n general ?
Trebuie ca fiecare relaie m : m s fie rezolvata ?
Pot fi rezolvate si alt tip de relaii dect cele m : m ?
Rezolvarea unei relaii
S presupunem c dorim rezolvarea unei relaii de tip m : m ntre entitile A i B.

1) Primul pas este crearea unei noi entiti de intersecie. Vei vedea c uneori nu gsii niciun cuvnt
adecvat pentru conceptul pe care l modeleaz. Noua entitate poate s fie ntotdeauna numita folosind
o combinaie intre numele A / B sau un nume care este oarecum derivat din numele original al relaiei.
2) Urmtorul pas este crearea a dou noi relaii de tip 1:m pornind de la entitatea A / B COMBINAIE, una
ctre entitatea A i cealalt ctre entitatea B. Stabilii tipul relaiilor opionale sau obligatorii funcie de
tipul relaiei iniiale.
3) Numii relaiile. Avei posibilitatea s denumii adesea ambele relaii folosind " in / din ".
4) Urmtorul pas este eliminarea relaiei iniiale de tip m : m
5) n cele din urm, revizuii relaiile nou- trasate. Acestea pot fi opionale in partea entitii A sau B sau
ctre entitatea A/B combinaie. De asemenea, exista posibilitatea ca aceste noi relaii sa fie de tip m : m
i sa necesite o noua rezolvare.
Pot fi rezolvate toate relaiile de tip m:m ?
Rspunsul depinde de o serie de factori dup cum urmeaz:
 Avnd n vedere un scenariu obinuit, atunci cnd vei ncepe crearea unui model ER, vei
descoperi c multe dintre relaii sunt de tip m : m. Cele mai multe dintre acestea par a ascunde
entiti de care avei nevoie ntr-o etap ulterioar pentru a plasa atributele specifice. n cele din
urm, vei avea doar cteva relaii autentice de tip "m:m"

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

11 |

Facultatea de Automatica si Calculatoare Iasi


Rspundem cu NU la ntrebarea Pot fi rezolvate toate relaiile de tip m:m ?
Doar din punct de vedere pur conceptual al modelarii datelor, nu este necesara rezolvarea relaiilor
autentice de tip m : m. Modelul este destul de bogat pentru a sta la baza fazei de proiectare. O relaie de
tip m:m se va transforma ntr-un tabel binar, un tabel care este format din coloanele chei externe. Acesta
este exact acelai tabel ca si cel ce ar rezulta din entitatea de intersecie atunci cnd am rezolva relaia de
tip m : m.
O relaie de tip m: m ntr- o diagram conceptuala de date are nevoie de mai puin spaiu dect o entitate
separata plus dou relaii. Din acest motiv, o diagram coninnd o relaie de tip m : m nerezolvat este
mult mai transparenta i mai uor de citit.
Rspundem cu DA la ntrebarea Pot fi rezolvate toate relaiile de tip m:m ?
Da, din punct de vedere al funciei de modelare, rspunsul este diferit. Dac modelul Dvs. conine o relaie
adevrat m:m aparent, exista o nevoie a afacerii de a pstra informaii privind combinaiile dintre s
zicem, entitatea A i B.
Cu alte cuvinte, sistemul ar trebuie s conin cel puin o funcie de afaceri care creeaz relaia. Aceasta
"creare a relaiei" nu poate fi exprimat ca o utilizare a atributelor entitii , dei acest lucru este ceea ce
de obicei, instrumente de proiectare necesit pentru modelul funcional. Oracle Designer nu face excepie.
Acest lucru nseamn c atunci cnd creai un model ER n Oracle Designer acesta rezolva ntotdeauna
relaia m :m n scopul de a crea un model funcional definit complet cu toate datele funcionale incluse.

Rezolvarea altor relaii


Pot relaiile de alt tip dect m:m sa fie rezolvate?
Da. Fiecare relaie, chiar una de tip 1:1. poate s fie rezolvata ntr-o entitate intersecie i dou relaii , la
fel ca si in cazul relaiilor de tip m: m.
Cnd trebuie sa facei acest lucru ? Situaiile de acest gen sunt destul de rare.
O situaie tipic n care ar fi necesara rezolvarea unei relaii de tip non m:m apare atunci cnd o entitate
reprezint ceva care este n afara sistemului dumneavoastr.
S presupunem c avei nevoie de a crea pentru sistemul Dvs o relaie de tip m : 1 de la entitatea externa
PERSOANA ctre CLIENT_TIP care este una dintre entiti interne (ca n diagrama de mai jos ).

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

12 |

Facultatea de Automatica si Calculatoare Iasi


Acest lucru ar duce mai trziu la o schimbare a structurii tabelului extern PERSOANE, lucru ce nu este de
dorit (de multe ori pentru tabele externe sunt contracte semnate, nu se pot nclca regulile stabilite deja)
i, uneori, este chiar imposibil, dac nu avei drepturi asupra tabelului.

Modelul de mai sus pstreaz tabela PERSOANA ca entitate extern fara sa ii aduc modificri si realizeaz
referenierea din interior. Relaia m : 1 se transforma in entitatea CLASIFICARE i dou cele relaii intre
CLIENT_TIP si CLASIFICARE respectiv CLASIFICARE si PERSOANA.

Normalizarea datelor in timpul modelarii


Normalizarea este un concept ntlnit in bazele de date relaionale. Dealtfel, n cazul n care ai creat un
modelul entitate relaie corect, tabelele create n faza de proiectare se vor conforma cu regulile de
normalizare. Orice regul de normalizare folosita in proiectarea bazelor de date relaionale are o
interpretare in modelul de date corespunztor. Regulile care pot fi utilizate pentru a valida modul de
amplasare al atributelor ntr-un model ER sunt dup cum urmeaz.
Regula de normalizare

Descriere

Prima Forma Normala

Toate atributele au o singura valoare

A doua form normal ( 2NF )

Un atribut trebuie s depind de ntregul identificator unic (UID) al


entitii.

A treia forma normala ( 3NF )

Un atribut non UID poate fi dependent de un alt atribut non-UID

"Un model entitate-relaie normalizat se transpune automat ntr-un model normalizat de baz de date
relaional
"A treia form normal este obiectivul general acceptat pentru o baz de date in care s-a eliminat
redundana "

Prima form normal n modelarea datelor


Toate atributele trebuie s aib doar o singur valoare.
Trebuie sa verificai faptul c fiecare atribut are o singur valoare pentru fiecare apariie a entitii. Niciun
atribut nu trebuie sa aib valori repetitive.

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

13 |

Facultatea de Automatica si Calculatoare Iasi


Se pot observa adesea atributele ce nu sunt bine plasate prin faptul c numele entitii si numele
atributului sunt aceleai, cum ar fi subiectul MESAJului si textul MESAJului. n cazul n care atributul are
mai multe valori, creai o noua entitate pe care o relaionai cu cea originala printr-o relaie de tip m : 1.

A doua form normal n modelarea datelor


Un atribut trebuie s depind de ntregul identificator unic al entitii.

Verificai c fiecare atribut este dependent de ntregul identificator unic al entitii. Fiecare instana
specifica a UID trebuie s determine o singura instana a unui atribut.
Verificai daca un atribut nu depinde doar o parte a UID. Dac se ntmpl aa atunci este o greeala ce
trebuie ndreptata.
A treia form normal n modelarea datelor
Un atribut non-UID poate fi dependent de un alt atribut non-UID.

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

14 |

Facultatea de Automatica si Calculatoare Iasi

Rezumat
Relaiile exprima modul n care entitile sunt conectate.
Iniial majoritatea relaiilor par a fi de tip m:m, la final majoritatea relaiilor devin de tip m:1
Relaiile pot fi rezolvate prin
Doua noi relaii
O entitate de intersecie
In general normalizarea se oprete la cea de a treia forma normala
Exist trei tipuri generice de relaii: 1:m, 1:1, m:m.
Relaia de tip 1:m opional la partea 1 este, de departe, cel mai comun tip de relaie folosit n modele
ER. Aceasta este foarte uor aplicabila ntr- o baz de date relaional.
Relaiile nu pot avea atribute. n cazul n care acest lucru apare trebuie sa transformai relaia ntr-o
entitate de intersecie plus dou relaii.
Relaiile de tip 1:1 si m:m sunt mai puin frecvente, unele exprima mai mult o situaie de dorit, mai
degrab dect realitatea (de exemplu relaia 1:m care este obligatorie la ambele capete)

Practica
Practica 3-1: Gsii un context
Scopul acestei practici este de a folosi abilitile dumneavoastr de modelare.
Tema Dvs.
Avnd n vedere urmtoarele diagrame ER, gsi un context care se potrivete modelului.

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

15 |

Facultatea de Automatica si Calculatoare Iasi


Practica 3-2: Numele entitii de intersecie
Scopul acestei teme este de a gsi un nume adecvat pentru entitatea de intersecie dup rezolvarea
relaiei m: m.
Tema Dvs.
1 Rezolvai urmtoarele relaii m:m. Gsi un nume acceptabil pentru entitate de intersecie.
2 Gsii cel puin un atribut pentru fiecare entitate de intersecie care ar putea avea sens n contextul unei
afaceri. Dai un nume clar.

Practica 3-3: Chitana


Scopul acestei teme este de a utiliza un model simplu din viaa real ca baz pentru un model de date
conceptual.
Scenariu - Lucrai ca antreprenor pentru Moonlight Coffees. Sarcina Dvs este de a crea un model
conceptual de date pentru afacere. Ai colectat toate tipurile de documente cu privire la Moonlight. Mai
jos putei vedea un exemplu de chitana folosit la unul dintre magazine.
Tema Dvs.
Utilizai informaiile de pe chitana i ntocmii o list de entiti i atribute.

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

16 |

Facultatea de Automatica si Calculatoare Iasi


Practica 3-4: Moonlight P & O
Scopul acestei teme este de a crea un model de ER iterativ, bazat pe piese noi de informaii i cerine.
Scenariu - Inca lucrai ca antreprenor pentru Moonlight Coffees, aparent va descurcai foarte bine!
Tema Dvs.
1. Creai un model entitate relaie pe baza urmtoarelor Informaii despre personal si organizaie:
Toi angajaii Moonlight Caffe lucreaz pentru un departament, cum ar fi "Pre Global" sau "HQ",
sau pentru un magazin. Toi angajaii sunt nscrii in baza de date pentru salarizare in una dintre
organizaiile noastre, localizate in diferite ri. Jill, de exemplu, lucreaz ca manager de magazin n
Londra, Werner este administrator financiar- contabil i este situat n Germania.
2. Extinderea sau modificarea diagramei pe baza acestor informaii:
Toate magazinele aparin unei organizaii dintr-o ar. Exist doar o singur organizaie pentru
fiecare ar. Toate rile i departamentele raporteaz ctre HQ (headquarters), cu excepia HQ.
3. i din nou:
Angajaii pot lucra part-time. De exemplu Lynn a avut un 80% din timp alocat dezvoltrii de produse
de la 01 septembrie. nainte lucra full-time.
4. Schimbai modelul dac este necesar i dac este posibil pentru a permite introducerea urmtoarelor
noi informaii:
a) Jan lucreaz in ture n dou magazine diferite din Praga .
b) Anul trecut Tess a demisionat n Brazilia din poziia de manager de magazin i s-a mutat la
Toronto. Recent ea a nceput sa lucreze la magazinul de la Toronto Airport.
c) Pentru a reduce numrul de rapoarte directe, departamentele i organizaii de ara pot s
raporteze deasemenea si ctre un alt departament nu doar ctre HQ.
d) Magazinele din Luxemburg raporteaz ctre Belgia.
e) Pentru a preveni responsabiliti contradictorii, angajaii nu au voie s lucreze pentru un
departament i pentru un magazin n acelai timp.
5. Este modelul Dvs. n msur s rspund la urmtoarele ntrebri ?
f) Cine lucreaz n prezent in departamentul Operaiuni ?
g) Cine este lucreaz n prezent pentru Moonlight La Lune in Mont Martre, Frana ?
h) Exist n prezent angajai care lucreaz pentru Marketing n Frana ?
i) Care este cea mai mare ar n ceea ce privete numrul de angajai? In ceea ce privete
managerii ? n ceea ce privete part-time ?
j) Cnd poate Lynn sa srbtoreasca al cincilea an petrecut in companie ? Cnd va putea face
la fel si Tess " ( al cincilea an cu Moonlight )?
k) Ce ar are cel mai mic numr de demisii ?

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

17 |

Facultatea de Automatica si Calculatoare Iasi


Practica 3-5: Lista de preuri
Scopul acestei teme este de a utiliza un model din viaa real ca baz de date pentru un model de date
conceptual.
Scenariu - Lucrezi ca antreprenor pentru Moonlight Coffees.
Tema Dvs. Elaborai un model ER bazat pe lista de preuri al unui magazin Moonlight Coffe.

Practica 3-6: E-mail


Scopul acestei teme este de a extinde un model de date conceptual existent.

Tema Dvs.
Considerai modelul dat ca punct de
plecare. Adugai, tergei sau modificai
orice entiti, atribute i relaii astfel nct
s

putei

facilita

urmtoarele

funcionaliti:

1) Un utilizator trebuie s fie capabil de a crea pseudonime (alias) pentru ali utilizatori.
2) Un folder poate conine alte foldere.
3) Un utilizator trebuie s fie capabil sa forwardeze un mesaj (o compoziie). Un mesaj forward este
un nou mesaj, care este trimis n mod automat mpreun cu mesajul forwardat.

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

18 |

Facultatea de Automatica si Calculatoare Iasi


4) Toate folderele i listele sunt ale unui utilizator.
Provocare suplimentara:
5) O list de e-mail poate conine att utilizatori ct i alte liste.
6) O list de e-mail poate conine adrese externe, cum ar fi "giovanni_papini@yahoo.com".
7) Un pseudonim poate fi un alias pentru o adres extern.

Practica 3-7: Cas de vacan


Scopul acestei teme este de controla calitativ un model conceptual de date.
Scenariu - Eu si Paul am fcut o excursie n Statele Unite ale Americii. Eu si Eric am facut o excursie n
Frana i anul trecut n Statele Unite ale Americii am nchiriat o main ".
Tema Dvs. - Comentai modelul de mai jos care sta la baza textului scenariului.

Practica 3-8: Normalizarea unui model ER


Scopul acestei teme este de a transforma un model ER aflat in forma normala zero in cea de a treia form
normal.
Tema Dvs.
1) Pentru urmtoarele modele ER evaluai
fiecare

entitate

conform

regulilor de

normalizare, identificai atributele ce

nu

sunt corect amplasate i explicai ce regul


de normalizare este nclcata si de ce,
pentru fiecare atribut.
2) Opional, redesenai diagrama ER n a treia
form normal.

Proiectarea Sistemelor de Baze de Date Relaionale - Proiect

19 |