Documente Academic
Documente Profesional
Documente Cultură
Model Proiect
Model Proiect
1. Detalii despre spectacolele susținute (titlu, autor, data și ora la care are loc acesta)
2. Detalii personale ale clienților (numele și prenumele, adresa, telefon, card de credit)
3. Detalii despre rezervările făcute de clienți (data și ora, locul rezervat)
4. Detalii despre biletele emise (serie, preț, loc)
2. Stabilirea entităților
Astfel, vom avea următoarele entități:
3. Stabilirea atributelor
Un atribut este orice detaliu care serveşte la identificarea, clasificarea, cuantificarea, sau exprimarea
stării unei instanţe a unei entităţi. Atributele sunt informaţii specifice ce trebuie cunoscute şi memorate
Un atribut poate fi obligatoriu sau opţional. Dacă un atribut este obligatoriu, pentru fiecare instanţă a entităţii
respective trebuie să avem o valoare pentru acel atribut, de exemplu
este obligatoriu să cunoaştem numele clientilor. Pentru un atribut CLIENT FLOARE
*prenume *denumire
opţional putem avea instanţe pentru care nu cunoaştem valoarea *nume * preț
*adresă *anotimp
atributului respectiv. De exemplu atributul telefon al entităţii CLIENT
o telefon
poate fi opţional. Un atribut obligatoriu este precedat în ERD de un o tip_flori_cump
o numar_flori
asterisc *, iar un atribut opţional va fi precedat de un cerculeţ o.
Astfel, pentru fiecare CLIENT trebuie să reținem prenume, nume, adresă, telefon, tipul de flori cumparate,
numarul de flori cumparate.
Astfel, pentru fiecare FLOARE trebuie să reținem denumire științifică, preț unitar, anotimp specific.
Atributele care definesc în mod unic instanţele unei entităţi se numesc identificator unic (UID). Atributele
care fac parte din identificatorul unic al unei entităţi vor fi precedate de semnul diez #. În exemplul de față
niciun atribut nu permite identificarea în mod unic a clienților. Vom adăuga un atribut id care va avea
valoare unică pentru fiecare client.
CLIENT FLOARE
#id #id
Pentru entitatea FLOARE atributul denumire științifiică ar putea fi *prenume *denumire
identificator unic (nu cred că există două flori cu aceeași denumire *nume * preț
*adresă *anotimp
științifică), dar se preferă ca UID să fie de tip numeric, așa că vom adăuga o telefon
o tip_flori_cump
un atribut unic id pentru entitatea FLOARE. o numar_flori
FLOARE
CLIENT
#id
#id cumpără *denumire
*prenume
* preț
*nume
*anotimp
*adresă
o telefon este cumpărată
o
t
i
p
_
f
l
o
r
i
_
c
u
m
p
o
6. Rezolvarea relațiilor many-to-many (mai-mulți-la-mai-mulți)
Relaţiile many-to-many pot apărea într-o primă fază a proiectării bazei de date însă ele nu au voie să apară
în schema finală. Relațiile many to many se vor desface în două relații unu la mai mulți, folosind o entitate
intersecție (intermediară). Etapele vor fi următoarele:
a) se găseşte entitatea de intersecţie, pentru exemplul nostru vom introduce entitate TRANZACTIE.
b) crearea noilor relaţii
- opţionalitatea: relaţiile care pleacă din entitatea de intersecţie sunt întotdeauna obligatorii în această
parte. În partea dinspre entităţile originale, relaţiile vor păstra opţionalitatea relaţiilor iniţiale.
- cardinalitatea: ambele relaţii sunt de tip one-to-many, iar partea cu many va fi întotdeauna înspre
entitatea de intersecţie.
- se stabilesc numele noilor relaţii
c) adăugarea de atribute în cadrul entităţii de intersecţie, dacă acestea există. Vom adăuga atributul
data, având în vedere că la un moment-dat trebuie să obținem informații despre clienții care nu au
cumpărat flori în ultimii 2 ani. Atributele tip_flori_cumpărate și număr flori sunt specifice
tranzacției, așa că le vom trece în entitatea tranzacție.
d) stabilirea identificatorului unic pentru entitatea de intersecţie: dacă entitatea de intersecţie nu are un
identificator unic propriu, atunci acesta se poate forma din identificatorii unici ai entităţilor iniţiale la
care putem adăuga atribute ale entităţii de intersecţie. În exemplul nostru, vom adăuga un
identificator unic id pentru entitatea tranzacție (deși e posibil ca identificatorii unici ai clientului, ai
florii și data să fie suficiente).
FLOARE
CLIENT
#id
#id *denumire
*prenume * preț
*nume *anotimp
*adresă
o telefon
TRANZACTIE include
#id
încheie
*data este inclusă
* tip_flori_cump
* numar_flori
este încheiată
Faptul că identificatorul unic al unei entităţi preia identificatorul unic din altă entitate cu care este legată este
reprezentat grafic prin bararea relaţiei respective, înspre entitatea care preia UID-ul celeilalte entităţi.
7. Normalizarea relațiilor
Normalizarea este o tehnică de proiectare a bazelor de date prin care se elimină (sau se evită) anumite
anomalii şi inconsistenţe a datelor. O baza de date bine proiectată nu permite astfel ca datele să fie
redundante, adică aceeaşi informaţie să se găsească în locuri diferite, sau să memorezi în baza de date,
informaţii care se pot deduce pe baza altor informaţii memorate în aceeaşi bază de date.
Prima formă normală - O entitate se găseşte în prima formă normală dacă şi numai dacă:
- nu există atribute cu valori multiple;
- nu există atribute sau grupuri de atribute care se repetă.
Cu alte cuvinte toate atributele trebuie să fie atomice, adică să conţină o singură informaţie.
În cerința noastră atributul tip_flori_cump poate avea mai multe valori (la o tranzacție pot fi achiziționate
mai multe flori). Dacă un atribut are valori multiple, sau un grup de atribute se repetă, atunci trebuie creată o
entitate suplimentară pe care să se lege de entitatea originală printr-o relaţie de 1:m. În noua entitate vor fi
introduse atributele sau grupurile de atribute care se repetă.
Un caz special apare în cazul atributului adresa din entitatea CLIENT. În mod normal adresa va conține mai
multe date: localitate, strada, nr samd. La prima vederea și acasta este o încălcare a primei forme normale.
Dacă la un momendat ni se cere o listă cu clienții dintr-o anumită localitate va trebui să aducem entitatea la
prima formă normal. Dacă adresa este doar un element care se imprimă pe contract sau e necesară doar
pentru a transporta marfa la domiciliu, toți clienții fiind din aceași localitate aducerea la prima formă
normală poate fi ignorată. În exemplul nostrum putem ignora, dar într-un exemplu real, nu.
TRANZACTIE
#id
*data
PRODUS
* tip_flori_cump
* numar_flori
conține
este conținută
A doua formă normală – o entitate se găseşte în a doua formă normală dacă şi numai dacă se găseşte în
prima formă normală şi în plus orice atribut care nu face parte din UID (unique identifier) va depinde de
întregul UID nu doar de o parte a acestuia. Această situaţie se rezolvă prin crearea unei noi entităţi, care va fi
legată de entitatea inițială cu o relație 1:m. Nu avem încălcări ale celei de a doua fome normale.
A treia formă normală - o entitate se găseşte în a treia formă normală dacă şi numai dacă se găseşte în a
doua formă normală şi în plus nici un atribut care nu este parte a UID-ului nu depinde de un alt
atribut non-UID. Cu alte cuvinte nu se acceptă dependenţe tranzitive, adică un atribut să depindă de UID în
mod indirect. În exemplul nostru am putea avea o încălcare pentru a treia formă normală. Aceasta ar putea
interveni dacă pentru un client ar trebui să stocăm codul poștal al localității de domiciliu și denumirea
localității. E evident, că denumirea localității va depinde de codul poștal și nu de id-ul clientului. Această
situaţie se rezolvă prin crearea unei noi entităţi LOCALITATE, pe care o legăm de entitatea CLIENT printr-
o relaţie 1:m. Entitatea LOCALITATE va conține atributele cod_postal și denumire.
LOCALITATE
#id
*denumire
*judet
CLIENT
#id
*prenume
*nume
o telefon
FLOARE
CLIENT
#id
#id
*denumire
*prenume * preț
*nume *anotimp
o telefon locuiește
are
TRANZACTIE include
#id
încheie
*data este inclusă
este încheiată
PRODUS
* tip_flori_cump
* numar_flori
conține
este conținută