COLEGIUL NAȚIONAL ONISIFOR GHIBU ORADEA

Proiect baze de date

Nume:

Oradea, 2020
Cuprins

Descrierea scenariului ……………………………………………………………………………………….. 2

Stabilirea entităților ………………………………………………………………………………………….. 2
Stabilirea atributelor …………………………………………………………………………………………. 2
Identificatorii unici ……………………………………………………………………………..……………. 2
Stabilirea relațiilor între entități ……………………………………………………………………………... 3
Rezolvarea relațiilor many to many ………………………………………………………………………..... 4
Normalizarea …………………………………………………………………….…………………………... 5
ERD final …………………………………..………………………………………………………………... 6
1. Descrierea scenariului

Într-o companie care comercializează flori sunt necesare următoarele informații referitoare la clienții săi
(persoane fizice) si la tipurile de flori pe care le comercializează:
- date ale clienților care au cumpărat un anumit tip de flori: prenume, nume, adresă, telefon, numărul de flori
de acest tip cumpărate la fiecare comandă;
- numărul clienților care au cumpărat cel puțin două tipuri de flori;
- date specifice pentru un anumit tip de flori: denumire științifică, preț unitar, anotimp specific;
- tipurile de flori care nu au fost cumpărate de niciun client pe parcursul ultimului an;
- date ale clienților care nu au cumpărat nicio floare pe parcursul ultimilor doi ani.

2. Stabilirea entităților

Entități - O entitate este un lucru, obiect, persoană sau eveniment care are CLIENT FLOARE
semnificaţie pentru afacerea modelată, despre care trebuie să colectăm şi să
memorăm date.

CLIENT – reține date despre clienti

FLOARE – reține date despre flori

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.

4. Identificatori unici (UID)

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
*nume * preț
identificator unic (nu cred că există două flori cu aceeași denumire
*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

5. Stabilirea relațiilor între entități

O relaţie este o asociere, legătură, sau conexiune existentă între entităţi şi care are o semnificaţie pentru
afacerea modelată. Orice relaţie este bidirecţională, legând două entităţi sau o entitate cu ea însăşi.

Orice relaţie este caracterizată de următoarele elemente: nume, opționalitate, grad.

a) numele relaţiei – este un verb. În cazul de față clientul cumpără flori, iar florile sunt cumpărate de
clienți. Numele relațiilor vor fi cumpără și sunt cumpărate.
b) opţionalitatea relaţiei – o relație poate fi obligatorie (mandatory) sau opțională. Pentru a stabili
opţionalitatea relaţiei trebuie să răspundem la următoarea întrebare: Un client trebuie să cumpere
flori? Se poate ca un client să nu cumpere nicio floare (au ajuns în baza de date a firmei nu datorită
faptului că au cumpărat ci au completat un chestionar, spre exemplu)? În cazul de față putem
presupune că relația este obligatorie (clienții au fost înregistrați atunci când au cumpărat) deci vom
spune: Un CLIENT trebuie să cumpere o FLOARE.
c) gradul (cardinalitatea) relaţiei - este dată de numărul de instanţe ale entităţii care pot intra în relaţie
cu o instanţă a celelaltei entităţi. Adică va trebui să răspundem la întrebări de genul: Câte flori poate
cumpăra un CLIENT? Răspunsurile posibile sunt unul şi numai unul, sau unul sau mai mulţi. Cea
mai realistă varinată a relaţiei este aşadar: Un CLIENT trebuie să cumpere una sau mai multe
FLOARE. Cum relațiile sunt bidirecționale vom avea și relația O FLOARE poate fi cumpărată de
unul sau mai mulți CLIENT. Relația este opțională deoarece pot fi flori reținute în baza de date, care
nu au fost cumpărate de niciun client (încă).

În cadrul ERD, o relaţie va fi reprezentată printr-o linie ce uneşte cele două entităţi. Deoarece o relaţie
este bidirecţională, linia ce uneşte cele două entităţi este compusă din două segmente distincte, câte una
pentru fiecare entitate. Tipul segmentului ce pleacă de la o entitate ne va indica opţionalitatea relaţiei
dintre această entitate şi entitatea aflată în cealaltă parte a relaţiei. Dacă acest segment este continuu este
vorba de o relaţie obligatorie, o linie întreruptă indică o relaţie opţională.

Dacă o instanță este legată prin relație de o singură instanță corespondentă linia se termină simple, iar
dacă o relație este legată de mai multe instanțe linia se termină cu trei linii (crow feet).

FLOARE
CLIENT #id
#id cumpără *denumire
*prenume * preț
*nume *anotimp
*adresă
o telefon este cumpărată
o tip_flori_cump
o numar_flori
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
încheie #id
*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

8. ERD final LOCALITATE

#id
*denumire
*judet

FLOARE
CLIENT #id
#id *denumire
*prenume * preț
*nume *anotimp
o telefon locuiește

are

TRANZACTIE include
încheie #id
*data este inclusă

este încheiată

PRODUS
* tip_flori_cump
* numar_flori
conține

este conținută