Curs: Programarea și administrarea MySQL

Module: Introduction to MySQL

Unitate: Proiectarea bazei de date

În timpul implementării unei noi baze de date, este foarte uşor să

cădem în capcană încercând să terminăm lucrul repede, fără a dedica
suficient timp procesului de design, respectiv de proiectare. Importanţa
acestei faze o putem vedea cel mai bine după terminarea proiectului,
când, din cauza unei baze de date prost proiectate, trebuie să facem
reproiectări şi reimplementări scumpe. Proiectarea bazei de date este
similară cu proiectarea unei case. Este imposibilă începerea zidirii fără
a avea un plan detaliat, pregătit din timp. De asemenea, un proiect
bun vă asigură extinderea construcţiei originale, fără a fi necesară
demolarea construcției precedente. O situaţie identică este şi la
proiectare, respectiv la designul bazei de date. În cadrul acestei lecţii,
ne vom familiariza cu conceptele de bază ale unui proiect bun al bazei
de date.

Fazele proiectării bazei de date

Există trei faze principale când vine vorba de proiectarea bazei de

date. Acestea sunt:

Analiza cerinţelor;
Designul conceptual;
Designul logic.

Fiecare dintre aceste faze trebuie tratată cu mare atenție, fiindcă

fiecare fază este o precondiţie pentru următoarea fază, aşadar, dacă,
de exemplu, nu se realizează bine analiza cerinţelor, cu siguranţă
putem spune şi că designul conceptual, şi cel logic, nu se vor realiza
corect.

Analiza cerinţelor

Acesta este începutul lucrului nostru la proiect. Înainte de a analiza

ceea ce vom face, în primul rând trebuie să vedem de ce avem nevoie.
Ne vom da seama cel mai bine prin colectarea cât mai multor
informaţii şi prin analizarea lor.

De exemplu, sistemul pe care trebuie să-l realizăm este sistemul

informaţional al unei companii. Deja, din discuţia pe care am avut-o cu

© Copyright Link group 1/9

Curs: Programarea și administrarea MySQL
Module: Introduction to MySQL
Unitate: Proiectarea bazei de date

persoana care ne va prezenta ideea proiectului, putem ajunge la un

număr mare de informaţii. De exemplu:

Compania noastră se ocupă cu vânzarea diferitelor produse. Avem la

dispoziţie în jur de 500 de produse diferite. Noi angajăm în jur de 20 de
lucrători care vând produsele noastre la clienţii cu care încercăm să
construim o relaţie bazată pe încredere şi respect reciproc. O mare
atenţie o atribuim utilizatorului, respectiv cumpărătorului, aşadar avem
nevoie de informaţii despre fiecare client al nostru.

Aceste propoziţii conţin o mulţime de informaţii utile pentru viitorul

nostru sistem.

Vom analiza acum substantivele din propoziţie: client, companie,

produs, angajaţi. Aceste substantive pot deveni entităţi ale sistemului
pe care îl modelăm.

Observăm şi verbe în textul de mai sus: angajăm, vânzare.

Aceste verbe ne vor ajuta să determinăm relaţiile dintre entităţile

definite.

În final, numerele din aceste propoziţii ne indică dimensiunile necesare

pentru date.

Este foarte important să definiţi entităţile şi relaţiile şi, în final, să

adăugaţi dimensiunile. Entităţile şi relaţiile definite corect reduc spaţiul
pentru a face o greşeală fatală, ceea ce, cel mai des, diminuează
reputaţia dezvoltatorului şi costă clientul mult mai mult decât era
anticipat. Toate acestea se întâmplă din cauză că definirea entităţilor şi
a relaţiilor afectează în mod direct designul conceptual şi logic şi, din
nou, are un impact asupra aplicaţiei complete. De exemplu, dacă ştim
că trebuie să avem utilizatori pe sistem, ne este clar că aceşti
utilizatori vor avea anumite funcţii care vor trebui programate în alte
limbaje de programare din aplicaţia propriu-zisă. Dacă facem o
greşeală la început, eroarea se va reflecta până la sfârşit. De
asemenea, trebuie să se ţină cont de timp, deoarece trebuie ştiut că,
cu cât petrecem mai puţin timp lucrând - cu atât clientul va fi mai

© Copyright Link group 2/9

Curs: Programarea și administrarea MySQL
Module: Introduction to MySQL
Unitate: Proiectarea bazei de date

satisfăcut şi cu atât va începe mai repede să utilizeze sistemul şi să

câştige bani din asta.

Designul conceptual

După ce am colectat şi analizat cerinţele, acestea trebuie transformate

într-un tip de design formal, conceptual. În acest scop, în cele mai
frecvente cazuri se folosesc diferite diagrame pentru modelarea
entităţilor şi a relaţiilor dintre acestea.

Designul logic

În cele din urmă, prin designul logic se face maparea designului

conceptual cu tabelele şi la relaţiile specifice ale sistemului de baze de
date selectat. Cu designul logic ne vom ocupa pe parcursul întregului
curs.

Având în vedere faptul că designul logic va fi studiat în timpul

întregului curs, care are ca precondiţie modul adecvat de colectare a
cerinţelor de utilizator, respectiv are ca precondiţie faptul că ştim ce
bază de date ne este necesară şi în ce scenarii se va folosi aceasta, ne
putem concentra atenția pe designul conceptual. În continuarea
acestei lecţii vom vedea cum se creează un design conceptual calitativ
pentru sistemul bazei de date.

Designul conceptual

După cum am spus deja, crearea modelului conceptual implică

definirea entităţilor şi a relaţiilor dintre ele. Pentru aceasta, avem
nevoie de o bună cunoaştere a noţiunilor, aşadar ne vom reaminti ce
este modelul relaţional.

Am menţionat anterior modelul relaţional, aşadar ne este cunoscută

definiţia acestei noţiuni. Modelul se mai numeşte şi modelul entităţii şi
a relaţiei, adică Entity Relationship Model, în care putem observa
foarte uşor două noţiuni-cheie ale acestui model: entităţi şi relaţii. Am
menţionat deja aceste noţiuni, iar acum este timpul să ne ocupăm
puţin cu definiţia lor, fiindcă acestea alcătuiesc baza creării modelului

© Copyright Link group 3/9

Curs: Programarea și administrarea MySQL
Module: Introduction to MySQL
Unitate: Proiectarea bazei de date

conceptual, precum şi baza de date, în general.

Dacă observăm aceasta, simplificat, putem spune că baza de date

salvează informaţii despre anumite obiecte, care se mai numesc şi
entităţi, şi relaţiile dintre aceste obiecte. De exemplu, baza de date a
unei universităţi poate salva informaţii despre studenţi şi cursuri,
precum şi informaţii despre înscrierile studenţilor la anumite cursuri.
Studenţii şi cursurile ar fi entităţi, în timp ce înscrierile ar fi relaţia
dintre cursuri şi studenţi. Similar acestui lucru, dacă observăm
cerinţele menţionate la începutul acestei lecţii, o bază de date de
vânzări ar putea conţine informaţii despre produse, clienţi şi vânzări.
Produsele şi clienţii ar fi entităţi, în timp ce vânzarea ar fi relaţia dintre
clienţi şi produse.

O abordare populară a designului conceptual este şi folosirea modelării

relaţiilor, respectiv crearea aşa-numitului model ER.

Modelarea entităţilor

Pentru a vizualiza proiectarea în timpul modelării relaţiilor şi entităţilor,

adesea se foloseşte desenarea diagramei de entităţi şi relaţii (Entity
Relationship Diagram).

În diagrama ER, entităţile sunt reprezentate printr-un dreptunghi, în

cadrul căruia este scrisă denumirea entităţii. Entităţile bazei de vânzări
menţionate ar arăta astfel:

Imaginea 3.1. Entităţile bazei de date de vânzări

© Copyright Link group 4/9

Curs: Programarea și administrarea MySQL
Module: Introduction to MySQL
Unitate: Proiectarea bazei de date

De obicei, baza de date se foloseşte pentru reprezentarea anumitor

caracteristici, respectiv atribute ale entităţilor deja menţionate. În
baza de date a vânzării, pentru fiecare client se vor salva informaţiile,
precum prenumele, numele, adresa de e-mail și data naşterii. Desigur,
este posibil să fie mai multe informaţii de acest tip. Pe scurt, putem
spune că atributele descriu entităţile din care fac parte.

Atributele se mai folosesc şi pentru deosebirea mai multor entităţi de

acelaşi tip. Pentru deosebirea clienţilor, puteţi folosi prenumele lor,
însă imaginaţi-vă un scenariu în care în baza de date apar doi clienţi cu
acelaşi prenume. Fiindcă mai multe persoane, în cazul nostru mai mulţi
clienţi, pot avea acelaşi prenume, ajungem la concluzia că atributul
prenume nu se poate folosi ca identificator al entităţilor.

Vom observa acum ce atribute ne sunt disponibile pentru identificarea

entităţilor. Vom analiza adresa de e-mail. Adresa de e-mail este,
desigur, unică, așa că la prima vedere este un candidat bun pentru
identificarea entităţilor. Problema utilizării adresei de e-mail pentru
identificarea entităţilor este aceea că, în acest caz, fiecare client ar fi
trebuit să aibă o adresă de e-mail, deoarece în caz contrar nu ar fi
posibilă salvarea informaţiilor în bază despre acest client. De
asemenea, problema ar apărea şi la utilizatorii care posedă mai multe
adrese de e-mail, aşadar informaţiile de acest tip nu ar putea să se
salveze în baza de date.

Soluţia acestei probleme, respectiv a lipsei de atribut adecvat de

identificare, se găseşte în introducerea atributului a cărui menire
specială este tocmai identificarea entităţilor.

Uneori, este chiar posibil să luăm în considerare mai multe atribute,

adică un set de atribute de identificare. De exemplu, unirea
prenumelui cu adresa va determina, cu siguranţă, entitatea. Totuşi, cel
mai bun mod îl reprezintă introducerea unui atribut special proiectat
pentru această menire şi pe acesta îl vom folosi aproape întotdeauna
în cadrul cursului nostru.

Introducerea unui nou atribut va fi, de asemenea, foarte utilă atunci

când folosim date din baza de date din aplicaţie (de exemplu, putem

© Copyright Link group 5/9

Curs: Programarea și administrarea MySQL
Module: Introduction to MySQL
Unitate: Proiectarea bazei de date

marca foarte uşor, printr-un cod de program, care comentariu aparţine

utilizatorului şi să oferim posibilitatea ca pe baza unui identificator
unic, utilizatorul să-şi poată şterge sau modifica cu uşurinţă
comentariul).

În general, atributul de identificare (sau atributele) se mai numeşte şi

cheie primară, însă despre aceasta vom discuta în următorul modul.

În diagrama ER, atributele se reprezintă în forme ovale cu denumirea

acestora şi sunt unite cu entitatea care le deține. Atributele care
reprezintă cheia primară sunt reprezentate cu o denumire subliniată.
Toate acestea se pot vedea în imaginea 3.2.

Imaginea 3.2. Entitatea Customer cu atributele pe care le deține

Acum ne vom ocupa puţin de entitatea Product. Conform cerinţei

© Copyright Link group 6/9

Curs: Programarea și administrarea MySQL
Module: Introduction to MySQL
Unitate: Proiectarea bazei de date

primite de la utilizator, baza de date pe care o modelăm trebuie să

salveze informaţiile despre denumirea şi preţul produsului. De aceea,
entitatea Product va poseda atributele Name, Price şi Product ID ca
atribut necesar pentru identificarea entităţii. Acesta este prezentat şi în
imaginea 3.3.

Imaginea 3.3. Entitatea Product cu atributele pe care le deține

Modelarea relaţiilor

Am menţionat deja că entităţile relaționează cu alte entităţii. Aceasta

înseamnă că entităţile din sistemul nostru posedă, cel mai probabil,
anumite relaţii, puncte comune. De exemplu, un client poate cumpăra
un produs sau un student poate frecventa un anumit curs, un muzician
poate înregistra un album, un scriitor poate să scrie o carte. Acestea
sunt exemple de relaţii între entităţi.

În cazul nostru, ca relaţie dintre client şi produs definim vânzarea,

având în vedere că un client poate cumpăra un produs. La fel ca
entităţile, şi relaţiile pot poseda atribute. Astfel, relaţia vânzării poate
poseda atribute, precum timpul vânzării şi numărul vânzării.

În imaginea de mai jos puteţi vedea cum arată aceasta când este

© Copyright Link group 7/9

Curs: Programarea și administrarea MySQL
Module: Introduction to MySQL
Unitate: Proiectarea bazei de date

reprezentată prin diagrama ER.

Imaginea 3.4. Diagrama ER a bazei de date de vânzări

Relaţiile dintre entităţi se reprezintă cu ajutorul unui romb. În diagrama

reprezentată mai sus apare ceva necunoscut, este vorba de
caracterele M şi N în faţa rombului, care reprezintă relaţia. Aceste
caractere definesc aşa-numita cardinalitate a relaţiei.

Haideţi să vedem ce este aceasta, de fapt. Diferite entităţi pot apărea

în diferite părţi ale relaţiei. De exemplu, fiecare client poate cumpăra
oricâte produse vrea şi fiecare produs poate fi cumpărat de orice
client. Aceasta este aşa-numită relaţia many-to-many (mai-mulți-la-mai-
mulți).

În afară de acest tip de relaţie, mai există şi alte tipuri de relaţii, de

exemplu one-to-many (unu-la-mai-mulți) sau one-to-one (unu-la-unu).
O singură persoană poate avea mai multe carduri de credit, însă
fiecare dintre aceste carduri de credit aparţin unei singure persoane.
Acesta este un exemplu clasic de relaţie one-to-many (unu-la-mai-
mulți).

© Copyright Link group 8/9

 Curs: Programarea și administrarea MySQL
Module: Introduction to MySQL
Unitate: Proiectarea bazei de date

La sfârşit, numărul de serie al motorului unei maşini este un exemplu

tipic al relaţiei one-to-one (unu-la-unu). Motorul maşinii poate avea un
singur număr de serie şi numărul de serie al maşinii poate să aparţină
unui singur motor.

Pentru a marca aceste tipuri diferite de relaţii, folosim prescurtări,

precum:

1:1 (one-to-one);
1:N (one-to-many);
M:N (many-to-many).

© Copyright Link group 9/9

Powered by TCPDF (www.tcpdf.org)