Merged Document

UNIVERSITATEA DIN CRAIOVA
FACULTATEA DE MATEMATIC I TIINE ALE NATURII

SECIA INFORMATIC
LUCRARE DE LICEN
Coordonator tiinific:
Conf.univ.dr. Costin Boldea
Absolvent,
Surchicin Alexandru
IULIE 2014
UNIVERSITATEA DIN CRAIOVA

FACULTATEA DE MATEMATIC I TIINE ALE NATURII
SECIA INFORMATIC
LUCRARE DE LICEN
Modelarea bazelor de date folosind

diagrame E-R i aplicaii
IULIE 2014
Cuprins
Cuprins....................................................................................................... 2
Capitolul 1: Ce este o diagram ER (entitate-legatur)? ............................ 4
1.1 Definirea bazei de date - cteva definiii: entitate, legtura, atribut. .......................... 4
1.2 O metodologie de nceput................................................................................................. 6
1.3 Metodologia de proiectare ER ......................................................................................... 6
1.4 O prim diagram ER cu o singur entitate .................................................................. 7
1.5 Mai multe detalii despre atribute .................................................................................... 11
1.6 Atributul simplu su atomic............................................................................................. 11
1.7 Atributele compuse .......................................................................................................... 12
1.8 Atribute cu valori multiple ................................................................................................ 13
1.9 Atributele derivate ............................................................................................................ 15
1.10 Ce este o cheie? ............................................................................................................ 16
1.11 Modul de lucru ................................................................................................................ 19
1.12 Metodologia de proiectare ER ..................................................................................... 20
1.13 Maparea diagramei entite la o baz de date relaional ......................................... 25
1.14 Rezumatul primului capitol ........................................................................................... 29
Capitolul 2: Prima diagram a unei entiti ............................................... 30

2.1 O scurt introducere ........................................................................................................ 30
2.2 Definirea unei legturi pentru o entitate nou ........................................................... 32
2.3 Metodologia de proiectare a diagramelor ER .............................................................. 33
2.4 O gramatic preliminar pentru Diagramele ER ......................................................... 33
2.5 Ce este o legtur ? ........................................................................................................ 37
2.6 Atribut sau legtura ? ...................................................................................................... 37
2.7 Metodologia de obinere i proiectare a diagramelor ER este urmtoarea: ........... 38
2.8 Rezumatul capitolului ...................................................................................................... 38
Capitolul 3: Metodologia de proiectare ER i constrngeri asupra legturilor

................................................................................................................. 40
3.1 O scurt introducere ........................................................................................................ 40
3.2 Raportul de cardinalitate unei legturi .......................................................................... 40
3.3 Participare: Integral/Parial .............................................................................................. 45
3.4 Meodologia de proiectare ER......................................................................................... 47
3.5 Metodologia de proiectare ER ....................................................................................... 53
Surchicin Alexandru
3.6 Maparea legturilor la o baz de date relaionale ...................................................... 57
Capitolul 4: Descrierea aplicaiei .............................................................. 65

Bibliografie : ............................................................................................. 81
Capitolul 1: Ce este o diagram

ER (entitate-legatur)?
Surchicin Alexandru
Capitolul 1: Ce este o diagram ER (entitate-legatur)?

Diagrama ER este un mijloc semantic de modelare a datelor care este folosit
pentru a ndeplini cerinele descrierii abstracte. Datele descrise abstract se numesc
model conceptual. Modelul conceptual ne va conduce la o schem. O schem
implic o descriere permanenta, fix a structurii datelor. Deci, cnd credem c am
realizat o descrierea corect conform cu realitatea n interiorul modelului conceptual,
diagrama ER o vom putea numi schem.
Diagrama ER poate fi folosit deasemenea i pentru a documenta o baz de
date existent prin reverse-engineering; dar n introducerea acestui subiect scopul
principal este acela de a folosi diagrama ER pentru a modela o baz de date ce
urmeaz s fie creat.
1.1 Definirea bazei de date - cteva definiii: entitate, legtura,

atribut.
Aa cum specific i numele, o diagram ER modeleaz datele ca entitii i
legturi, i entittiile au atribute. O entitate este un lucru despre care stocm infornaii,
de exemplu, o persoan, un cont bancar, o cldire. n prezentarea iniial, Chen (1976)
descria o entitate ca un lucru care poate fi identificat distinct. Deci o entitate poate s
fie o persoan, un loc, obiect, eveniment, sau un concept despre care dorim s stocm
date.
Numele unei entiti trebuie ales astfel nct s reprezinte un tip sau o clas de
lucruri, nu doar o instan al acelui tip/clase. Numele unei entiti trebuie s fie destul de
generic, dar n acelai timp, numele entitii nu poate fi prea generic. De asemenea
numele ar trebui s fie capabil s se acomodeze schimbrilor n timp. De exemplu,
dac am modela o afacere i afacere ar consta n fabricarea medicamentelor, ne-am
putea gndi s crem o entitate numit Medicament. Dar ct timp va trece pn cnd
afacerea va evolua n producerea unor produse medicamentoase ? Dac se
anticipeaz c afacerea se va dezvolta i vor fi fcute i alte produse medicamentoase,
poate ar fi fost mai bine s crem o entitate numit LABORATOR MEDICAMENTE - ar
fi mai potrivit n timp.
Cteva exemple de entiti:

Surchicin Alexandru
Exemple pentru o etitate care refer o persoan ar fi AN GAJ AT, MEDIC sau
STUDENT.
Exemple pentru o entitate care refer un loc ar fi STAT sau AR
Exemple pentru o entitate care refer un obiect ar fi CLDIRE, AUTO, sau

PRODUS
Exemple pentru o entitate care refer un eveniment ar fi VNZRI,

RETURNRI, sau NREGISTRARE
Exemple pentru o entitate care refer un concept ar fi CONT sau

DEPARTAMENT.
n trecut, ne-am fi putut referei la o entitate ca la o nregistrare, dar termenul

nregistrare este prea fizic i prea limitat; nregistrare ne duce cu gndul la un lucru
fizic, iar atunci cnd lucrm la nivel conceptual, trebuie s evitm o astfel de gndire. n
contextul bazelor de date, este neobinuit s stocm informaii despre o entitate, i de
aceea ne gndim s stocm colecii de date despre entiti - astfel de colecii sunt
numite seturi de entiti. Seturile de entiti corespund conceptului de fiier, dar din
nou, un fiier de obicei nseamn o entitate fizic i deci abstractizm conceptul de
fiier(set de entiti) precum i conceptul de "nregistrare"(entitate). Ca exemplu, s
presupunem c avem o companie care are clieni. lmaginai-v ca aceast companie
are un set de entiti client.
O entitate ar putea fi foarte larg (de exemplu. o persoan), sau ar putea fi
limitat de aplicaia pentru care ne trebuie datele(cum ar fi student sau client). Entitile
largi care acoper o ntreag clas de obiecte, sunt uneori numite generalizri(ex.
persoan), iar entitile limitate sunt uneori numite specializri (ex. pacient). n
diagramele care vor urma vom revedea generalizrile i specializrile; dar deocamdat,
ne vom preocupa de un nivel de aplicabilitate la care nu se ntlnesc subgrupe
(specializri) sau subgrupe (generalizri) de entiti .
Cnd vorbim despre captarea datelor pentru o anumit entitate, ne referim la
aceasta ca la o instan. O entitate instan reprezint o singur apariie a unei entiti.
De exenplu dac crem, o entitate numit ELECTRONICE, i alegem s nregistrm
date despre o lantern, atunci nregistrarea" lantern este o instan a entitii
ELECTRONICE. Fiecare instan a unei entiti trebuie s fie unic identificabil deci
fiecare instan este independent i distinct identificabil de toate celelalte instane ale
5

Surchicin Alexandru
aceleiai entiti. ntr-un set de entiti client, va-i putea imagina c o companie ar
atribui un numr unic de client. Acest identificator unic este numit cheie.
O legtur reprezint o asociere, ntre entiti. Legturile sunt de obicei indicate
prin locuiuni verbale. Vom ncepe prin extinderea noiunii de entitate, i apoi ne vom
ntoarce la noiunea de legtur o dat ce am stabilit conceptul de entitate.
Un atribut este o proprietate sau caracteristic a unei entiti. De exemplu, o
entitate, PACIENT, ar putea avea atributele id_, cnp, nume, vrsta, adresa, etc.
1.2 O metodologie de nceput

Modelarea bazelor de date ncepe cu descrierea a ceea ce va fi stocat. O astfel
de descriere poate veni de la orcine; l vom numi pe cel care face descrierea utilizator.
De exemplu, Doamna Popescu de la Compania Acme Parts vine la tine, i ii cere s i
proiectezi o baz de date pentru compania ei. Doamna Popescu este utilizatorul. Tu eti
proiectantul bazei de date. Ceea ce ii spune doamna Popescu despre companie va
reprezenta descrierea bazei de date.
Ca punct de plecare n creearea bazei de date este identificarea unei entiti
centrale, primare - o categorie despre care vom stoca date. De exemplu, dac dorim
s crem o baz de date despre pacieni i mediul acestora, atunci o entitate ar fi
PACIENT (caracterizarea unei entiti va fi ntotdeauna fcut la singular). Avnd
aleas entitatea primar, PACIENT, vom cuta informaii care s fie nregistrate despre
aceast entitate. Aceast metodologie de selectare a unei entiti primare dintr-o
descriere reprezint primul pas n realizarea diagramei ER. Odat ce a fost aleas
entitatea primar, ne vom ntreba ce informaii vrem s nregistrm despre aceast
entitate. n exemplul nostru PACIENT, vom aduga cteva detalii despre PACIENT
orice detaliu care va caracteriza, identifica, clasifica, i exprima starea entitii (n acest
caz,entitatea PACIENT). Aceste detalii poart numele de atribute'. Cteva exemple de
atribute pentru PACIENT ar fi numele pacientului, numrul pacientului, anul, adresa,
etc. - informaii despre pacient.
1.3 Metodologia de proiectare ER

Pasul l: Selecteaz o entitate primar din descrierea bazei de date i
specific atributele care vor fi nregistrate pentru acea entitate.
6

Surchicin Alexandru
Definirea cerinelor este prima faz de inginerie software n care analistul

ncearc s descopere ce dorete utilizatorul. n cazul unei baze de date, un sistem
informaional-orientat, despre care utilizatorul va dori s stocheze informaii. Acum c
am ales entitatea primar i cteva atribute, sarcina noastr va fi s:
S desenm o diagram a unei entiti iniiale
S traducem n romn
S prezentm diagrama utilizatorului s vedem dac e bine i dac trecem mai

departe.
Al treilea pas poart numele de feedback n ingineria software. Procesul de

rafinare prin feedback este un process normal n fazele de cerere/specificare. nti vom
nva cum s desenm o entitate i apoi vom prezenta principiul de convertire a
diagramei n roman.
1.4 O prim diagram ER cu o singur entitate

Pentru a recapitula exemplul nostru, am ales un exemplu cu o entitate primar
dintr-o baz de date cu informai despre pacieni. Pacient reprezint entitatea despre
care vrem s stocm informaii. n continuare, nu ne vom preocupa de alte entiti.
S ne gndim la cteva atribute desprea entitatea PACIENT; care sunt.
atributele pe care le-ar putea avea un pacient? Un pacient are un cnp, nume, vrsta,
adresa. Am selectat trei atribute pentru entitatea PACIENT, i de asemenea am ales o
etichet generic pentru fiecare: cnp, nume, vrsta, adresa.
Vom ncepe prima noastr aventur n diagramele ER cu modelul Chen-like.
Chen(l976) a introdus ideea de diagrama ER. El i alii au mbuntit procesul ER de-a
lungul anilor; i deoarece nu exist nici un model ERD standard, modelul Chen-like i
alte variante ale acesteia sunt cele mai ntlnite. Dup modelul Chen-like, vom
introduce i alt modele. Mai trziu vom discuta pe scurt modelul Barker/Oraclelike.
Modelele Chen-like au avantajul c nu trebuie s tim dedesubtul logic al modelului
pentru a nelege proiectarea. Modelele Barker i alte cteva modele necesit o
nelegere complet al modelului relaional, iar diagramele sunt afectate de conceptele
relaionale.
Pentru a ncepe, n modelul Chen-like, vom proceda aa cum a procedat i Chen
iniial, adic vom trece entitiile n dreptunghiuri i vom trece atributele alturi. Un mod
de a descrie atributele este s le punem n cercuri sau ovale ataate dreptunghjurilor (la
7

Surchicin Alexandru
vrf i la mijloc). Figur de mai jos (partea inferioar) este un mod alternativ de
descriere a atributelor. Acest stil alternative prezentat n partea inferioar nu este la fel
de descriptiv, dar este mai compact i poate fi folosit dac diagramele Chen-like devin
dezordonate.
atribut
atribut
atribut
Entitate
nume
vrst
cnp
Pacient
sau
Forma compact a
diagramei ER
Cnp
Pacient
Nume
Vrst
Figura 1.1
Diagrama ER cu patru atribute

Surchicin Alexandru
Exist mai multe moduri de descriere a atributelor. Am ilustrat modelul atribute n

cercuri" (modelul Chen-like) deoarece este des ntlnit i folositor. n figur de mai jos
sunt prezentate cteva modele alternative pentru atribute.
Exist beneficii n altemarea formelor de reprezentare a atributelor. Forma standard a
modelului Chen-like cu cercuri i dreptunghiuri este bun pentru conceptualizare; este
uor de modificat i se observ foarte clar unde va fi poziionat fiecare atribut
Forma concis (partea de jos a figurii 1.1 i 1.2) este uor de obinut din forma standard
i este uneori mai folositoare pentru documentare atunci cnd spaiul reprezint o
constrngere.
cnp
nume
vrst
adres
specializare
Pacient
cnp
nume
vrst
adres
specializare
Pacient

Surchicin Alexandru
Pacient
cnp nume vrst adres specializare
Figura 1.2
Diagrama ER cu o entitate i 5 atribute,
Modele alterrnative (Batini,Ceri, Navathe)
Figura 1.1 (mijloc i jos) prezint o diagram ER cu o entitate, PACIENT, i trei

atribute : cnp, nume, vrst. Dac mai multe atribute sunt adugate la modelul
conceptual, cum ar fi adresa i specializare, vor fi adugate la entitate (aici,PACIENT
este singur entitate pe care o avem), aa cum se vede n figur 1.3
nume
cnp
vrst
Pacient
adres
specializare
Figura 1.3
O diagram ER cu o entitate si 5 atribute
10

Surchicin Alexandru
1.5 Mai multe detalii despre atribute

Atributele sunt caracteristici ale entitilor care furnizeaz detalii descriptive
despre entiti. Exist mai multe tipuri de atribute: simple sau atomice, compuse, cu mai
multe valori, i derivate. Proprietile unui atribut sunt numele, descrierea, formatul i
lungimea. Unele atribute pot fi considerate unic identificabile pentru o entitate. Aceast
seciune introduce de asemenea i ideea de atribut cheie, unic identificator pentru o
entitate.
1.6 Atributul simplu su atomic

Atributele simple sau atomice nu pot fi sparte sau subdivizate, de aici i numele
de atomic. Se poat examina domeniul de valori al unui atribut pentru a deduce dac e
atribut simplu sau nu. Un exemplu de atribut simplu su atomic ar putea fi codul
numeric personal, caz n care unei persoane i este asociat un singur astfel de numr
nedevizat.
Alte teste pentru a afla dac un atribut e simplu vor depinde n ntregime de
circumstanele ntlnite de proiectantul bazei de date dorina utlizatorului pentru care
este fcut baza de date. De exemplu, am putea trata un atribut numr de telefon
numr de telefon ca fiind simplu ntr-o anumit baza de date, dar n condiii
s-ar putea s dorim s divizm numrul de telefon n dou pri distincte, adic n,
prefix local i numrul propiu-zis. Un alt exemplu n cazul cruia pe baza utilizrii
atributului n baza de date vom determina dac acesta este simplu su atomic este
atributul zi de natere. Dac am crea o baz de date pentru o clinic veterinar, ar avea
sens s mprim atributul n cmpuri zi de natere, luna, i an, deoarece tratamentul
este diferit pentru animalele mai mici de cinci zile comparative cu animalele cu vrsta
curpisa ntre cinci zile i cinci luni i cele cu o vrst de peste cinci ani. Deci, n acest
caz, zi de natere va fi un atribut compus. Totui pentru o baz de date de CURSE DE
CAI, nu ar fi necesar s mprim cmpul zi de natere n luna/zi/an, deoarece toi caii
sunt numerotai numai dup anul n care au fost nscui. n acest ultim caz, zi de
natere, alctuit numai din an, va fi atomic.
Dac un atribut este neatomic, trebuie s fie tratat ca atare ntr-o diagram ER.
Urmtoarele seciuni se ocup de astfel de atribute mai complicate, atribute neatomice atribute compuse i atribute cu valori multiple.
11

Surchicin Alexandru
1.7 Atributele compuse

Un atribut compus, uneori numit atribut grup, este un atribut format prin
combinarea sau
agregarea de atribute ntre care exist o legtur. Numele alese pentru atributele
compuse ar trebui s fie descriptive i generale. Conceptul de nume este adecvat
pentru o descriere general, dar este indicat s fie mai specific pentru anumite pari din
atribut. Cele mai multe aplicaii de procesare a datelor mpart numele n pari
componente. Apoi, numele, este numit atribut compus sau agregat deoarece este de
obicei compus din primul nume, ultimul nume i o iniial. Modul n care aceste atribute
compuse sunt prezentate n diagramele ER ntr-un model Chen-like este ilustrat n
figur 1.4. Sub-atributele, cum ar fi numele, iniiala, i prenumele sunt numite simple,
atomice, sau atribute elementare. Cuvntul agregat este folosit n diferite sensuri n
unele limbaje de interogare i pentru a evita confuzia nu vom numi atributele compuse
agregate; vom folosi cuvntul compuse.
numeeste un atribut compus- este compus
din nume de familie, iniiala tatluii
prenume
nume de
familie
Iniiala
tatlui
prenume
specializare
nume
cnp
Pacient
Figura 1.4:
Diagrama ER cu un atribut compus nume
12

Surchicin Alexandru
nc o dat. testul pentru a determina dac un atribut este compus sau nu,va
depinde n ntregime de circumstanele ntlnite de proiectantul bazei de date - dorina
utilizatorului pentru care se construiete baza de date. De exemplu, ntr-o baz de
date s-ar putea s nu fie important s tim exact din ce ora sau ar provine codul zip
al unei persoane, deci atributul adres din acea baz de date poate s nu fie divizat n
pari componente; poate fi numit doar adres. Pe cnd n alte baze de date, poate i
important s tim oraul i statul din care provine o persoan; deci n acest ultim caz va
trebui s spargem atributul adres n strad, ora, ara, i codul zip, atributul adres
devenind astfel unul compus.
1.8 Atribute cu valori multiple

Un alt tip de atribut neatomic pe care l vom descrie n continuare este atributul
cu valori multiple multiple. Atributul cu valori multiple, aa cum spune i numele, poate
avea mai multe valori pentru o entitate. De exemplu, atributul specializare ar putea avea
cu uurina mai multe valori dac o persoan frecventeaz (sau a frecventat, depinde
de contextul bazei de date) mai mult de o specialitatate. Atributul cu valori multiple
specializare este reprezentat n figur 1.5(model Chen-like) ca un oval dublu, care
ilustreaz situaia n care o baz de date va stoca date despre pacieni care ar putea
avea mai mult de o specialitate. Dei am ales s ilustrm coala ca atribut cu valori
multiple, asta nu nseamn c aa se va proceda n toate bazele de date pentru acest
atribut. De fapt, atributul specializare este tratat ca atribut simplu n multe baze de date.
Ideea de specializare poate nsemna specialitatea curent (sau chiar anterioar. Dac
subiecii despre care dorim s stocm date pot frecventa o singur dat la un moment
dat (i tocmai acest lucru vrem s l scoatem n evidenta), atunci atributul specializare
ar putea foarte bine s fie single-value.
13

Surchicin Alexandru
nume de
familie
Iniiala
tatlui
specializare este un atribut multivalue un atribut multi-value este

reprezentat folosind cercuri concetrice
i ovale
prenume
nume
specializare
Pacient
adres
Figura1.5: O diagram ER cu un atribut multi-value
nc o dat, testul de singularitate sau multipilcitate al unui atribut va depinde n

ntregime de circumstanele pe care le ntmpin proiectantul bazei de date - dorina
utilizatorului pentru care se construiete baza de date. Este recomandat ca dac
sensul bazei de date este ca atributul specializare s nsemne specializarea curent,
atunci atributul s poarte numele specializare curent" i reprezentat ca atribut singlevalued. n exemplul nostru, avem un atribut cu valori multiple (figura 1.5), deci sensul
diagramei este c mai mule specializri pot fi nregistrate pentru fiecare pacient.
14

Surchicin Alexandru
1.9 Atributele derivate

Atributele derivate reprezint acele atribute a cror valoare se calculeaz pe
baza altor atribute din date din baza de date. Un exemplu de atribut derivat este vrsta
care poate fi calculat o dat ce a fost introdus data de natere a pacientului. n
modelul Chen-like, un atribut derivat este reprezentat ntr-un oval punctat (aa cum se
arat n figur l.5A).
nume de
familie
Iniiala
tatlui
prenume
specializare
nume
Pacient
adres
vrst
cnp
Atribut
derivat
Figura 1.5A: O diagram ER cu un atribut derivat vrst
15

Surchicin Alexandru
1.10 Ce este o cheie?

Utilitatea unei baze de date este de a stoca date pentru a fi apoi regsite i
refolosite. Un atribut care poate fi folosit pentru a gsi o anumit apariie a unei entitii
este numit cheie. n timp ce modelm baza de date folosind modele ER, am putea
observa c unele atribute n mod natural par ar fi chei. Dac un atribut poate li
considerat c este un identificator unic pentru o entitate, atunci este numit cheie
candidat. Atunci cnd o cheie candidat este aleas s fie indetificatorul unic, aceasta
devine cheia primar a entitii.Ca un exemplu de chei, s presupunem c adaugam la
entitatea PACIENT din exemplu nostru un atribut numit numr pacient . Am putea
considera c numr pacient este un identificator unic pentru entitatea noastr - o cheie
candidat datorit unicitii. De obicei numele este unic, dar nu ntotdeauna. Adeseori
membrii unei clase au acelai nume de familie. Adresa poate s fie sau s nu fie un
identificator unic i deci nu este o cheie candidat potrivit. Fraii sau surorile care sunt n
aceeai clas pot avea aceai adres n realitate adeseori spitalele atribuie un numr
unic pentru fiecare pacient pentru a fi capabili s gseasc ntr-un mod rapid i simplu
informaii despre un anumit pacient - utilitatea cheii este s fumizeze un mod unic de a
gsi o instan a unei entiti (o anumit nregistrare).
Unele spitale aleg s nregistreze codul numeric personal c atribut. Un cod
numeric personal este de asemenea unic i deci reprezint o cheie candidat mpreuna
cu numrul pacientului . Dac att Codul numeric personal ct i numrul pacientului
sunt nregistrate, atunci proiectantul trebui s aleag care dintre acestea va fi cheia
primar. n cazul nostru, vom alege s nu codul numeric personal. Entitatea PACIENT
cu identificatoml numr unic pacient ales ca i cheie este prezentat n figur 1.6.
16

Surchicin Alexandru
numr pacient este un

identificator unic pentru
Pacient i de aceea este
subliniat
Nume
de
familie
Iniiala
tatlui
prenume
numr
pacient
nume
Pacient
specializare
adres
Figura 1.6: O diagram ER cu cheie primar
n modelul Chen-like, atributele care sunt identificator unici (chei candidat) sunt
de obicei subliniate (aa cum se arat n ligura 1.6). Un identificator unic poate fi un
atribut sau o combinaie de atribute. n acest moment nu este necesar s alegi care
cheie candidat va fi cheie primar. Cnd este doar o cheie candidat, de obicei o vom
numi cheie primar. n figur 1.6 am reprezentat att forma scurt a diagramei ER( n
partea interioar) cu atribute compuse i multi-value ct i cu chei primare. Atributele
compuse sunt listate mpreun cu prile componente, iar atributele cu valori multiple
sunt nchise n paranteze n forma abreviat.
n cele din urm, vom avea situaii n care diagrama ER(n model Chen-like) nu
are nici o cheie evident. Entitaiile pentru care se identifica cel puin o cheie se numesc
entiti tari.
n articolul iniial al lui Chen( l976), entitiile tari erau numite entiti obinuite. n
timpul procesului de analiz se va descoperi c unele entiti depind de altele (i deci i
17

Surchicin Alexandru
indentificarea lor). Chen a numit aceste entiti care depind de alte entiti, entiti
slabe.
De cele mai multe on' vom putea recunoate entitile slabe deoarece nu au chei
candidat, i totui actuala semnificaie a entitilor slabe este o entitate a crei
existen depinde de existent unei alte entiti. Vom urma notaia din modelul Chen-like
i vom numi astfel de enitati, entiti slabe - slabe deoarece vor depinde de alte entiti
pentru a furniza un identificator unic i pentru a da un motiv pentru ca entitatea s fie
nregistrat.
n modelul Chen-like vom reprezenta o entitate slab prin dou dreptunghiuri
(vezi Figura1.7). Momentan ne vom concentra aspura entitiilor care au chei, urmnd
ca mai trziu s lum n considerare i situaiile n care nici o cheie nu e evident.
id
medicament
productor
compoziie
Medicament
nume
pre
Entitate tare
productor
compoziie
Medicament
nume
pre
Entitate slab
Figura1.7: O entitate MEDICAMENT tare i o entitate MEDICAMENT slab
18

Surchicin Alexandru
O descriere n romn a entitiilor

Utilizatorii nu vor dori s studieze diagrama entitii, dar vor dori s aud ce a
neles analistul c
trebuie s realizeze. Pentru o descriere n romn, vom folosi
gramatica a limbii romne structurate" pentru a reprezenta informaia corespunztoare

diagramei.
1.11 Modul de lucru

Fie Entitate numele entitii i att(j) atributele. Ordinea atributelor nu este important,
deci J=1,2, este atribut arbitrat. S presupunem c sunt n atribute pan acum.
Echivalentul n limba diagramei noastre este:
Entitatea
Aceast baz de date nregistreaz informaii despre Entitate. Pentru fiecare
Entitate din baza de date nregistrm att( l), att(2),. . .,att(n).
Atributele
Pentru atributele atomice, a(j):
Pentru fiecare Entitate, ntotdeauna va fi unu i numai un att(j). Valoarea lui att(j)
nu va fi subdivizat.
Pentru atributele compuse, a(j):
Pentru fiecare Entitate vom nregistra att(j), care este compus din x,y,z. .. unde
(x,y,z) sunt pri componente ale lui att(j).
Pentru atribute cu valori multiple, a(j):
Pentru fiecare Entitate, vom nregistra att(j)-uri. Pot fi mai multe att(j) nregistrate
pentru fiecare Entitate.
Pentru atributele derivate, a(j):
Pentru fiecare Entitate, ar putea exista att(j)-uri, care vor fi derivate din baza de
date.
Cheile
Pentru chei:
a. Mai mult de o cheie candidat(entitate tare):
Pentru fiecare Entitate, vom avea urmtoarele chei candidat: att(j), att(k),...,[unde j,k
sunt atribute chei candidat]
19

Surchicin Alexandru
b. O cheie candidat (entitate tare):
Pentru fiecare Entitate, vom avea urmtoarea cheie primar: att(j)

c. Nici o cheie candidat(entitate slab):
Pentru fiecare Entitate 1 , nu vom presupune c nici un atribut este unic astfel nct s
poat identifica o anume entitate fr a referi o alt entitate Entitate2.
d. Nici o cheie candidat:
Pentru fiecare Entitate l intersectat, nu vom presupune c nici un atribut este unic s
poat identifica entitile individuale fr a referi Entitatea2.

n continuare vom revedea fiecare din _figurile de pn acum i vom nu romn
pentru fiecare dintre acestea. Mai nti, s lum n considerare figura 1.3. Aceast
figur nu conine atribute cu valori multiple sau atribute compuse. Entitate = PACIENT,
att(1)= nume, att(2)=cnp, etc. Traducerea n roman a diagramei entitii folosind
abloanele anterioare ar fi :
Entitate
Aceast baz de date stocheaz informaii despre PACIENI. Pentru fiecare PACIENT
din baza de date, nregistreaz nume, cnp, specializare, vrsta i o adres.
Atributele
ntotdeauna va fi unu i numai un singur nume pentru fiecare PACIENT.
Valoarea numelui nu va fi subdivizat.
ntotdeauna va fi unu i numai un singur cnp pentru fiecare PACIENT. Valoarea
cnp-ul nu va fi subdivizat.
ntotdeauna va fi una i numai o singur specializare pentru fiecare PACIENT.
Valoarea pentru specializare nu va fi subdivizat observai c n figur 1.3 nu am divizat
numele.
ntotdeauna va fi una i numai o singur vrsta pentru fiecare PACIENT.
Valoarea vrstei nu va fi subdivizat.
ntotdeauna va fi una i numai o singur adresa pentru fiecare PACIENT.
Valoarea adresei nu va fi subdivizat.
Cheile
20

Surchicin Alexandru
Pentru fiecare PACIENT, nu vom presupune c orice atribut va fi unic. (figura

1.3).
Exemple pe baza diagramei
n plus fa de descrierile de mai sus, unele exemple sunt foarte folositoare n
prezentarea care se va face utilizatorului, legat de modul n care s-a fcut proiectarea
bazei de date.
PACIENT
Nume
Cnp
Grigore 7925676528921
Specializare
Inginer
Vrsta
32 ani
Adresa
Vasile Alexandri, bl 2
tefan
7624554525828
Sculptor
19 ani
Brestei, nr. 40
Ioan
7953252258821
ofer
16 ani
Amaradia M14
Petru
7965482120032
Poliist
58 ani
Craiovita, bl T8
S considerm n continuare figura 1.4. Aceast figur are un atribut compus

nume. Traducerea n roman a diagramei entitii va fi urmtoarea:
Entitatea
Aceast baz de date stocheaz informaii despre PACIENI. Pentru fiecare
PACIENT din baza de date, vom nregistra un nume, o specializare i o adres.
Atributele
Pentru fiecare nume, ntotdeauna va fi unu i numai un singur nume pentru
fiecare PACIENT. Valoarea numelui va fi subdivizat n nume, prenume i iniiala
tatlui.
Pentru fiecare adres, ntotdeauna va fi una i numai o adres pentru fiecare
PACIENT. Valoarea pentru adresa nu va fi subdivizat.
PACIENT. Valoarea pentru adresa nu va fi subdivizat.
Cheile
Pentru fiecare PACIENT, nu vom presupune c orice atribut este unic astfel nct
s poat identifica entitile individual.
21

Surchicin Alexandru
PACIENT
Prenume
Nume
Iniial
Specializare
Adresa
Victor
Botan
Mecanic
Vasile Lupu, nr. 14
Mirela
Ungureanu
Contabil
Lpu Arge, bl 2
Feodor
Brankovici
ofer
tefan cel Mare, nr.8
Elena
Niculescu
Manager
Brestei, nr.42
Eduard
Constantin
Profesor
Craiovita, bl T7
S considerm n continuare figura 1.5. Figura are att un atribut compus ct i

unul cu valori multiple. Reprezentarea n limba romn a acestei diagrame va fi
urmtoarea:
Entitatea
Baza de date stocheaz informaii despre PACIENI. Pentru fiecare PACIENT
din baza de date, vom reine un nume, o specializare i o adres.
Atributele
Pentru fiecar nume, ntotdeauna va fi unu i numai un nume pentru fiecare
PACIENT. Valoarea pentru nume va fi subdivizat n nume, prenume i iniiala tatlui.
PACIENT. Valoarea adresei nu va fi subdivizat.
Pentru fiecare pacient poate fi nregistrat mai mult de o singur specializare.
Cheile
Pentru fiecare PACIENT, nu vom presupune c toate atributele vor fi unice
pentru a identifica entiti individuale.
PACIENT
Prenume
Nume
Iniial
Specializare
Adresa
Mihai
Ungureanu
ofer
Brestei, nr 40
Victor
Bacui
Inginer
Alin
Constantin
Contabil
Craiovita, bl T7
Emilia
Borozia
Medic
Vasile Lupu, nr.2
Maria
Niculescu
Poliist
Lpu Arge, bl 2
22

Surchicin Alexandru
S considerm n continuare figura 1.6. Figura are atribute compuse, atribute cu

valori
multiple i chei. Traducerea n limba romn a acestei diagrame va fi urmtoarea:
Entitatea
Baza de date stocheaz informaii despre PACIENI. Pentru fiecare PACIENT
din baz de date, vom nregistra un nume, o specializare, o adres i un numr de
pacieni.
Atributele
Pentru fiecar nume, ntotdeauna va fi unu i numai un nume pentru fiecare
PACIENT. Valoarea pentru nume va fi subdivizat n nume, prenume i iniiala tatlui.
PACIENT.
Valoarea adresei nu va fi subdivizat.
Pentru fiecare PACIENT, ntotdeauna vom nregistra mai multe specializri. Pot fi
nregistrate mai mult de o specializare pentru fiecare pacient.
Cheile
Pentru fiecare PACIENT, vom presupune c exist un atribut- numr studentcare va fi unic. n continuare s considerm partea de sus a figurii 1.7. Aceast entitate
prezint o entitate
tare. Traducerea n limba romn a acestei diagrame va fi urmtoarea:
Entitate
Aceast baz de date stocheaz informaii despre MEDICAMENTE. Pentru
fiecare
MEDICAMENT
din
baza
de
date,
vom
stoca
productorul,
numele
medicamentului, preul,compozitita i id-ul medicament.

Atributele
Fiecare MEDICAMENT va avea una i doar o marc, un nume, pre, compoziia,
i id. Nici unul din aceste atribute nu va fi subdivizat.
Cheia
Pentru fiecare MEDICAMENT, vom presupune c atributul id medicament este
unic astfel nct cu acesta se pot identifica entiti individuale.
Figura l.7(partea de jos) prezint o entitate slab. Singura diferen dintre o
descriere a unei entiti tari i cea a uneia slabe este c n descrierea entitii slabe
poate s fie cheia.
23

Surchicin Alexandru
Figura 1.8 prezint o legtur dintre dou entiti, un MEDICAMENT i un

PACIENT.
productor
id medicament
compoziie
Medicament
nume
pre
SA
Legtur
prenume
iniiala
prenume
numr pacient
nume
Pacient
adres
specializare
Figura 1.8: O diagram ER a bazei de date MEDICAMENT-PACIENT
Metodologia noastr a evoluat dup cum urmeaz:

Pasul l: Se selecteaz o entitate primar din descrierea bazei de date i specific
atributele care vor fi nregistrate pentru acea entitate.
Pasul2: Se folosete romna structurat pentru a descrie entiti, atribute i chei
i baza de date care a fost obinut.
24

Surchicin Alexandru
Pasul3: Se dau cteva exemple concrete
1.13 Maparea diagramei entite la o baz de date relaional

Avnd ilustrate ideile de entitate i atibut, ne vom ndrepta spre o realizare semifizic a acestor concepte. Spunem semi-fizic deoarece nu suntem preocupai de
fiierul care va fi stocat pe disc, ci de plasarea datelor n tabele relaionale pe care le
vom privi ca un mod de organizare fizic a datelor. Practic o baz de date relaional
reprezint o baz de date a unor tabele cu dou dimensiuni numite legturi. Aceste
tabele sunt alctuite din linii i coloane. Liniile sunt adeseori numite tupluri, iar
coloanele atribute. n bazele de date relaionale, toate atributele (coloanele tabelului)
trebuie s fie atomice i cheile trebuie s nu fie nule. n plus, n bazele de date
relaionale, actuala locaie fizic a datelor pe disc nu ne interseaz.
Procesul de convertire a unei diagrame ER ntr-o baz de date poart numele de
mapare. Ne vom preocupa doar de modelul relaional i vom prezenta regulile de
mapare a diagramelor ER n baze de date relaionale.
Vom ncepe cu o regul de mapare a entitiilor ri:
M1 - pentru entiti ri: se dezvolt un nou tabelaegatur), iar pentru fiecare
entitate tare
cheia indicat a entitii tari devine cheie primar a tabelului. Dac este indicat
mai mult de o singur cheie candiat pentru diagrama ER candidat, se alege una
dintre acestea care va deveni cheia primar.
n continuare, trebuie s mapm atributele din entitatea tare. Regulile de mapare
sunt diferite pentru atributele atomice, atributele compuse i pentru cele cu valori
multiple. Mai nti,vom prezenta regul de mapare a atributelor atomice:
M1a - maparea atributelor atomice dintr-o entitate - pentru entitiile cu atribute
atomice:
se mapeaz entitiile la un tabel formnd coloane pentru atibutele atomice.
O baz de date relaional realizat pe baza diagramei ER din figura 1.3 cu
cteva date va
arata astfel:
25

Surchicin Alexandru
PACIENT
Nume
Sergiu
Cnp
7925676528921
Specializare
Vrsta
Adresa
Salvamar
32 ani
tefan cel Mare, nr. 2
Gabriel
7624554525828
Sculptor
24 ani
Brestei, nr. 40
Ioan
7953252258821
ofer
16 ani
Vasile Lupu M14
Petru
7965482120032
Doctor
60 ani
Craiovita, bl T8
Numele legturii (tabelului) va fi numele entitii, PACIENT.
Atributele din
diagram devin capete de tabela. Tabelul actual cu datele pe care acesta le conine,
reprezint un exemplu de tip de date la care ne-am putea atepta n cazul unei astfel de
legturi. Ordinea coloanelor este irelevant pentru o baz de date relaional, cu
condititaca o dat aceasta aleas s fie respectat pn la sfar-sit.
Dar de ce se ntmpl pentru atributele compuse i pentru cele cu mai multe
valori? Aa cum am menionat mai sus, exista o axiom a bazelor de date relaionale
care spun c toate coloanele trebuie s fie atomice. Dac n diagrama exista un atribut
non-atomic, acesta trebuie fcut atomic pentru a l mapa la baza de date relaionala.
Pentru atributele compuse, obinem atomicitatea reinnd numai prile component ale
atributului.
Urmtoarea regul de mapare privete atributele compuse:
M1b pentru entitile cu atribute compuse: se mapeaz entitile la un table
formnd coloane din prile elementare (atomice) ale atributelor compuse.
Fcnd referire la figura 1.4, o baz de date relaionala care corespunde
diagramei din figura 1.4 va arat astfel:
PACIENT
Prenume
Nume
Iniial
Specializare
Adresa
Mihai
Ungureanu
ofer
Brestei, nr 40
Victor
Bacui
Inginer
Alin
Constantin
Contabil
Craiovita, bl T7
26

Surchicin Alexandru
Emilia
Borozia
Medic
Vasile Lupu, nr.2
Maria
Niculescu
Poliist
Lpu Arge, bl 2
Atributele cu mai multe valori au fost prezentate n figur 1.5. n aceast

diagram entitate, entitatea noastr PACIENT avea un atribut compus, nume i un
atribut cu valori multiple, specializare. Asta nseamn c un pacient ar putea avea
stocat mai mult de o singur specializare pe o linie. Datele care ar putea fi
reprezentate cu aceasta diagram ar putea arta astfel: (pentru a ilustra atributele cu
valori multiple, vom arta doar numele, adresa i specializarea):
PACIENT
Nume
Specializare
Adresa
Mihai
ofer
Brestei, nr 40
Victor
Inginer
Alin
Contabil
Craiovita, bl T7
Emilia
Medic
Vasile Lupu, nr.2
Maria
Poliist
Lpu Arge, bl 2
Dup cum se observ acesta nu este un tabel relaional deoarece coal nu este
atomic.
O regul de mapare pentru atributele cu valori multiple ar fi urmtoarea:
Mlc - pentru atribute cu valori multiple: se formeaz un tabel separat pentru
atributul cu valori multiple. Se adaug o nou linie pentru fiecare valoare a
acestui atribut, mpreuna cucheia din tabelul iniial. Cheia noului tabel va fi
rezulta prin concatenarea dintre atributul valori multiple i cheia din tabelul iniial.
Se terge atributul cu valori multiple din table iniial.
Acum s presupunem c exemplul de mai sus are drept cheie atributul nume.
Acesta va fi mapat n dou legturi: o legtur cu un atribut cu valori multiple i o
legtur rezultat n urma ndeprtri atributului cu valori multiple.
Legtura cu atributul cu valori multiple, este urmtoarea:
Nume-Specialitate
27

Surchicin Alexandru
Nume
Specializare
Mihai
ofer
Victor
Inginer
Alin
Contabil
Emilia
Medic
Maria
Poliist
Alin
Contabil
Roberto
Manager
Elena
Barman
Victor
Buctar
Legtura rezultat n urma ndeprtrii atributului cu valori multiple va fi urmtoarea:
Pacient
Nume
Adresa
Mihai
Brestei, nr 40
Victor
Emilia
Vasile Lupu, nr.2
Maria
Lpu Arge, bl 2
Fr nici o cheie, regul de mapare rmne aceai numai c, n loc s spunem
mpreuna cu cheia ... vom spune mpreuna cu atributele atomice .... n bazele de
date relaionale, fiecare linie al tabelului conine atribute atomice. De asemenea, fiecare
linie este unic.
Dac atributele nume sau adres nu ar fi fost considerate unice, atunci ar fi
rezultat urmtoarea legtur:
Pacient
Nume
Mihai
Specializare
ofer
Adresa
Brestei, nr 40
28
Surchicin Alexandru
Victor
Inginer
Alin
Contabil
Craiovita, bl T7
Emilia
Medic
Vasile Lupu, nr.2
Maria
Poliist
Eminescu, bl 2
Alin
Contabil
Craiovita, bl T7
Emilia
Medic
Ion Creanga, nr.7
1.14 Rezumatul primului capitol

Principalul obiectiv al acestei primei pri a fost de a dezvolta conceptul de
entitate i descriere a diagramelor cu o entitate(folosind modelul Chen-like). Conceptul
de atlibut, a fost de asemenea discutat, iar n ultima seciune a acestei prime pri s-a
prezentat modul n care o cu o singur entiate ar putea fi mapat la o baz de date
relaional. De asemenea s-a prezentat i gramatica unei diagrame cu o entitate i mai
multe atribute. Gramatica va fi dezvoltat i n continuarea acestei lucrri.
29
Capitolul 2: Prima diagram a

unei entiti
Surchicin Alexandru
Capitolul 2: Prima diagram a unei entiti

2.1 O scurt introducere
Am conceput o metod pentru desenarea, interpretarea i rafinarea entitii
iniiale, trebuie s trecem la baza de date mai complexe. Pentru a progresa, vom
continua cu entitatatea iniial i vom cuta alte informaii care sunt associate cu
entitatea iniial i vom cuta alte informaii care sunt associate cu entitatea.
Mai nti verificm entitatea iniial pentru a vedea dac atributele nu ar trebui
s fie i ele la rndul lor entiti.Dup acest prim pas vom analiza alte informaii din
descriere, i le adugm(1) la o entitate existent i analizam diagrama ER existent su
(2) crem direct o nou entitate. Dup crearea noii entiti, observm ce tipuri de
legturi exist ntre cele dou entiti. Acest capitol dezvolta paii 3,4, i 5 ai
metotdologiei de proiectare ER prezentat n aceast lucrare. Pasul 3 examineaz
atributele entitatiii iniiale, pasul 4 discuta despre ce trebuie s facem dac este nevoie
de o nou entitate, i pasul 5 trateaz dezvoltarea legturii dintre 2 entiti.
Conceptul de legtur este introdus n acest capitol, nu vom invlude nici o nou
regul
de
mapare/transformare
acest
capitol;
deoarece
regulile
de
mapare/transformare pot fi mai bine nelese dup dezvoltarea noiunilor de

constrngeri structural pe legturi, care vor fi discutate n continuare acestei lucrri.
S considerm figura 2.1. n aceast figur, avem o farmacie cu urmtoarele
atribute: nume, adresa, numrul farmacie(un atribut i cheie), pacieni(un atribut cu
valori multiple). S presupunem c prima ntlnire cu utilizatorul, i artm diagram i
i cteva exemple de date, i acesta spune: Vreau s nregistrez toi pacienii la care
farmacie au fost nscrii i vreau s nregistrez nu doar numele pacienilor, dar de
asemenea i numele(intiala,nume de familie i prenume)..
30

unei entiti
Surchicin Alexandru
nume
id farmacie
Farmacie
pacient
adres
Figura 2.1: Entitate Farmacie cu un atribut cu mai multe valori

Ceea ce tocmai ne-a spus utilizatorul este c atributul, pacieni, ar trebui s fie
entitate.
Amintii-v de definiia entitii, reprezint un lucru(obiect) despre care vrem s stocm
informaii.Ideea intitala a fost s nregistrm colile urmate, dar acum ne-a fost spus c
trebuie s nregistrm i informaii despre pacieni. Primul indiciu ca un atribut trebuie
s fie considerat entitate este trebuie s stocm informaii despre acel atribut. Ceea ce
vom face n continuare, este s trecem de la 2.1 la figura 2.2. n figur 2.2, PACIENT
este acum ea nsi o entitate, astfel n acest caz avem dou entiti separate:
FARMACIE i PACIENT. Urmtorul pas este s definim o legtur ntre dou entiti.
Presupunem c numele pacienilor s fie cheie pentru entitatea FARMACIE.
prenume
Iniiala
tatlui
Nume de
familie
id pacient
nume
Pacient
31

unei entiti
Surchicin Alexandru
nume
pacient
id farmacie
Farmacie
adres
Figura 2.2: 2 Diagrame ER: una pentru PACIENT i una pentru FARMACIE
2.2 Definirea unei legturi pentru o entitate nou

Bazele de date sunt create pentru a stoca informaii nrudite. De exemplu, nu ar
avea nici un sens s nregistrm date despre student i valut sau despre liniile aeriene
i angajaii unei fabric de mingi de tenis n aceeai baz de date. Aceste concept nu
sunt nrudite. ntr-o baz de date trebuie s stocm colecii de date nrudite. Urmnd
aceast metod, n mod evident avem o situaie n care un atribut face parte dintr-o
entitate (pacient a fost considerat parte din farmacie), dar acum pacient a devenit o
entitate. Ce trebuie s facem n continuare este s stabilim legtura dintre entitile
PACIENT i FARMACIE.
Putem spune n mod informal: PACIENII frecventeaz FARMACIE sau
FARMACIILE sunt frecventate de PACIENI.
Gradul unei legturi se refer la numrul de entiti care se afla n legtur. n
figur 2.3, dou entiti fac parte dintr-o legtur, deci aceasta se numete legtura
binar.
Acum avem un tool ce ne poate permite s desenm descrierea unei baze de
date sub forma unei diagrame ER (entitate relaie).Semnificaia diagramelor noastre
este s stocheze informaii despre x i y (x i y sunt entiti) i s ne indice ce tip de
legtur este ntre x i y.
Metodologia noastr pe care vom aplica ar fi urmtoarea:
32

unei entiti
Surchicin Alexandru
2.3 Metodologia de proiectare a diagramelor ER

Pasul 1: Se selecteaz entitatea principal din baza de date care necesit o descriere
i se indic atributele care vor fi nregistrate pentru acest entitate.
Pasul 2: Se folosete romana structurata pentru entiti, atribute i cuvinte cheie pentru
a descrie baza de date care a fost obinut.
Pasul 3: Se examineaz atributele din entitatea principal (eventual cu asistenta
utilizatorului) pentru a gsi informaii despre una din entitile care vor fi stocate n baza
de date.
Pasul 3a: Dac pentru un atribut este nevoie i de alte informai, atunci atributul
respective devine entitate.
Pasul 3b: Se definete legtur cu entitatea intiala.
Pasul 4: Se dau exemple de date
2.4 O gramatic preliminar pentru Diagramele ER

Capitolul 1 am schiat o gramatic pentru a descrie o entitate. Acum c am
adugat o legtur la diagrama noastr, trebuie s facem c descrierea bazei de date
s arate mai bine. De asemenea dorim s i prezentm utilizatorului cteva exemple
de date pentru a l ajuta s neleag ct mai bine proiectul pe care vrem s-l realizm.
Pentru fiecare legtur, adugm urmtoarele comentarii (n roman):
O/Un Entitate 1 Legtura Entitate2 (diateza activ) i o/un Entitate2 Legtura Entitate1
(diateza pasiv).
Legtura
Pacienii frecventeaz FARMACIILE i FARMACIILE sunt frecventate de PACIENI.
Uneori o descriere la forma singular va acoperi problema mai bine i de aceea se
poate de asemenea folosi:UN PACIENT frecventeaz FARMACIILE i FARMACIA este
frecventat de PACIENI. Utilizatorul va fi cel care decide care exprimare este mai
indicate s o folosim.
Definirea celei de-a dou entiti
Avnd examinat entitatea iniial de atribute care la rndul lor ar fi putut
reprezenta entiti, acum se poate ncepe adugarea mai multor date. S privim diferitele
informaii oferite de ctre utilizator. S presupunem c n acest moment avem
urmtoarea descriere, vrem s stocm informaii despre pacienti- numele i numrul
pacienilor. n plus fa de informatiille despre pacieni, vrem s stocm i informaii
33

unei entiti
Surchicin Alexandru
despre medicamentele acestora. Vom dori s stocm numrul de identificare a

medicamentului, compoziie i pre .
n continuare s presupunem c am decis s alegem pacient c entitate iniial i
vrem s adugm informaii despre medicamente.
n figur 2.2, avem dou etitati dar acestea apar ca i cum ar fi independente.
Pentru a face entitatea FARMACIE i entitatea PACIENT trebuie s fie cele dou
entiti printr-o legtur.
O legtur ntr-o diagram ER este o conexiune ntre dou sau mai multe entiti
sau ntre o entitate i ea nsi. Cel de-al doilea tip de legtur, ntre o entitate i ea
nsi, este cunoscut c legtura recursiv. Un nume de legtur, ntre o entitate i ea
nsi, este cunoscut ca conexiunea
dintre entiti. Odat ce vom nelege cum
legtura este indicat, vom avea un tool care ne poate permite s realizm descrierea
bazei de date sub forma unei diagrame ER.
n modul Chen-like, o legtur este descris printr-un romb poziionat pe linia
care unete cele dou entiti, aa cum se arat n figur 2.3.
prenume
Iniiala
tatlui
Nume de
familie
id pacient
cnp
nume
Pacient
Legatur
Frecventez
id farmacie
nume
Farmacie
Figura 2.3: Entiatea FARMACIE i legatura acesteia cu entitatea PACIENT
34
adres

unei entiti
Surchicin Alexandru
n figur 2.3, este descris acesta legtura. Sensul legturii este a unui verb
care leag dou substantive (entiti). Toate legturile sunt cu dou sensuri. Aa cum
vom vedea, este necesar s afirmm c legturile sunt n ambele direcii.
Medicamentul este n mod evident o entitate deoarece dorim s reinem
informaii despre acesta. Dac adugam medicamentul n baza de date, am putea s l
includem c la pasul 1 al metodologiei noastre adugnd un atribut numit medicament,
numai c mai trziu la pasul 3 al metodologiei l-am trece la statutul de entitate.
Descrierea medicamentului ca atribut al entitii pacient este prezentat n figur 2.4 (n
modelul Chen-like). [Deocamdat ignorm entitatea FARMACIE.
prenume
Iniiala
tatlui
Nume de
familie
id pacient
cnp
nume
Pacient
medicament
Figura 2.4: Entitatea PACIENT cu un atribut numit MEDICAMENT
Dac adugm atributul, medicament, la entitatea, PACIENT, iar dup aceea

observm
c medicamentul ar fi trebuit s fie entitate, putem s crem entitatea
MEDICAMENT i apoi s adugam legtura la model. (Observai c figura 2.4 ar fi

suficient dac utilizatorul nu ar dori s mai stocheze informaii despre medicamente).
Evident, am fi putut observa c atributul medicament, nc de la nceput i s l trecem
n diagram noastr ca entitate de prima dat. Recunoscnd MEDICAMENT ca entitate,
am fi desenat cele dou entiti, PACIENT i MEDICAMENT, iar apoi am cuta legtura
dintre cele dou. Oricum am fi procedat am fi ajuns la figura 2.5, avnd dou entiti,
PACIENT i MEDICAMENT i cteva legturi ntre cele dou.
35

unei entiti
Surchicin Alexandru
compoziie
id medicamet
pre
nume
Medicament
cumpr
Iniiala
tatlui
prenume
Nume de
familie
id pacient
cnp
nume
Pacient
Figura 2.5: O Diagrama ER a unei baze de date PACIENT-MEDICAMENT

Folosind modelul Chen-like, trebuie s alegem cteva verbe care s descrie
legtura dintre cele dou entiti (PACIENT i MEDICAMENT) n acest caz, alegem a
cumpra (indicat n romb). Ulterior utilizatorul ar putea identifica legtura printr-un alt
verb; dar fr alte informaii, presupunem c utilizatorul a vrut s fac referire la
pacienii ce cumpra medicamente. Alte posibiliti pentru legtur dintre entitile
PACIENT i MEDICAMENT ar putea fi altele. Aceast legtur dintre cele dou entiti
este cunoscut c legtura binar.
36
Surchicin Alexandru

unei entiti
2.5 Ce este o legtur ?

Exist unele situaii cnd o legtur poate fi confuz. De exemplu, s
considerm urmtoarea descriere a unei baze de date. Creaz o baz de date pentru
CLIENI i FURNIZORI. CLIENI vor avea un nume, adres, numr de telefon i
numrul clientului. FURNIZOR va avea un numr de furnizor, un nume i o adres.
n aceast baz de date, avem n mod evident dou entai- CLIENT
FURNIZOR. Dorim s stocm informaii despre client (numele, adresa, etc.) i furnizor
(numrul furnizorului, nume, etc). Dar care este legtura ditre ele ?
Ce avem aici este o descriere incomplete, vag din care trebuie s proiectm
baza de date. Ceea ce se tie despre compania care vrea baza de date este c are att
client ct i furnizori; totui ceea ce nu realizeaz compania este ca leagatura dintre
CLIENT i FURNIZOR se face prin intermediul unei COMPANII sau a unui VNZTOR
i nu e o legtur direct. Aa c, ceea ce pn acum n aceast descriere sunt defapt
dou pri distincte a bazei de date a companiei, una pentru client i alta pentru
furnizori. Dac mai trziu o s avem alte entiti cum ar fi inventar sau vnztor care
fac legtura ntre client i furnizori, atunci am putea indentific entiti de legtura i
legturi. Pentru acum cu doar aceste dou idei irelevante client i furnizor nu exist
nicio legtur evidenta, deci singurul lucru pe care l-am putea face ar fi s nu stabilim
nici o legtur n diagrama pn cnd nu vom obine mai multe informaii de la utilizator.
Exist i posibilitatea ca s fie nevoie de crearea a dou baze de date ntre care nu
exist nicio legtur.
2.6 Atribut sau legtura ?

n unele cazuri poate fi neclar dac un anumit lucru(obiect) este atribut sau
legtura. Att atributele ct i legturile exprim ceva despre o entitate. Atributele unei
entiti exprima caliti sub forma unor proprieti sau caracteristici. Legturile exprim
asocieri intre entiti.
S presupunem c avem de construit o baz de date pentru o bibliotec. Mai
departe presupunem c am creat o alt entitate principal, CARTE care are ca atribut,
persoana care a mprumutat cartea. n unele cazuri, un atribut este nepotrivit pentru a
exprima o asociere care s descrie legtura dintre cele dou entiti. C problem
37

unei entiti
Surchicin Alexandru
secundar, persoana care a mprumutat cartea ar necesita folosirea unei valori nule
pentru acele entiti CARTE care nu au fost mprumutate. n realitate, numai o anumit
parte din crile unei biblioteci pot fi mprumutate la un moment dat. Deci, atributul
mprumutat va fi nul pentru majoritatea entitilor CARTE. Acesta repetare a valorii nul
indic faptul c atributul nume_datornic ar putea fi o entitate. Dac a fost create o
entitate DATORNIC i asocierea dintre entitile CARTE i DATORNIC a fost n
mod clar stabilit c legtura, atunci proiectantului bazei de date i-ar fi mai uor s pun
atributele i entitile n locurile corecte. Este important s nelegem deosebirea dintre
tipurile de informaii care pot fi exprimate ca atribute i acelea care trebuie tratate ca
leagaturi sau entiti.
2.7 Metodologia de obinere i proiectare a diagramelor ER este

urmtoarea:
Pasul 1: Se selecteaz entitate principal din baza de date care necesit o descriere i
de indica atributele care trebuie nregistrate pentru aceasta entitate. Se eticheteaz
cuvintele cheiele i se dau cteva exemple de date.
Pasul 2: Se folosete romana structurata pentru entiti, atribute
i chei pentru a
descrie baza de date obinut.

Pasul 3: Se examineaz atributele din entitatea principal (eventual cu asistenta
utilizatorului) pentru a gsi informaii despre atributele ce vor fi stocate n baza de date.
Pasul 3a: Dac pentru un atribut avem nevoie de alte informaii, atunci respectivul
atribut devine entitate.
Pasul 3b: Se definete legtura cu entitatea intiala.
Pasul 4: Dac o alt entitate este necesar, se deseneaz cea de-a doua entitate
mpreun cu atributele acesteia. Se repeta pasul 2 pentru a vedea dac aceasta
entitate ar trebui mprit n mai multe entiti.
Pasul 5: Se traseaz legturile dintre entiti, dac acestea exist.
Pasul 6: Se dau cteva exemple.
2.8 Rezumatul capitolului

Definirea entitilor, atributelor i legturilor s-a fcut n primul capitol. Adeseori
proiectarea unei baze de date poate fi dificil, tocmai datorit faptului c nu este foarte
de uor de identificat dac avem de a face cu un atribut, o entitate sau o legtur. n
38

unei entiti
Surchicin Alexandru
acest capitol s-a discutat despre cteva tehnici pentru a determina dac avem de a face
cu o entiate, un atribut sau o legtur.
n acest capitol a fost deasemenea introdus conceptual: de legtur binar. Majoritatea
bazelor de date pe care le vei folosi vor avea mai multe entiti, iar n acest capitol s-a
realizat o diagram cu dou entiti pornind de la o diagram cu o singur entiate i s-a
prezentat un mod de reprezentare a legturilor binare ntre dou entiti folosind
modelul Chen-like.
39
Surchicin Alexandru
Capitolul 3: Metodologia de
proiectare ER i constrngeri asupra legturilor
Capitolul 3: Metodologia de proiectare ER i constrngeri

asupra legturilor
3.1 O scurt introducere
n capitolul anterior, am prezentat cteva component ale diagramelor ER, printer
care entiti, atribute i legturi. Dar ntr-o diagram ER este insufficient s definim
legturi fr a define i ceea ce se numesc constrngeri structural. Constrngerile
structural sunt informaii despre modul n care sunt legate dou (sau mai multe) entiti.
Exist dou tipuri de constrngeri structurale: cardinalitatea i participare.
n acest capitol, pe lng constrngerile structurale ale legturilor, dorim s
prezentm i o gramatic care s descrie diagramele realizate. Aceasta gramatic ne
va ajuta n procesul de obinere a diagramelor, deoarece va specific un tipar pentru
limba romana care poate fi folosit n diagrama, fcndu-ne s exprimm exact ce
realizeaz acesta. Acest capitol dezvolta paii 6 i 7 din metodologia de proiectare a
diagramelor ER. Pasul 6 exprima clar natura legturii, iar la pasul 7 se prezint baza de
date (proiectat pn acum) utilizatorului.
Regulile de mapare pentru legturi sunt de asemenea dezvoltate i discutate,
folosind exemple.
3.2 Raportul de cardinalitate unei legturi

Cardinalitatea reprezint un mod de a reprezenta numrul de entiti (una sau
mai multe) care vor fi legate la o alt entitate (sau entiti). De exemplu, exist 4 moduri
prin care entitatiile MEDICAMENT i PACIENT pot fi implicate numeric ntr-o legtur:
una-la-una(1:1), mai multe-la-una(M:1), una-la-mai-multe(1:M) i multe-la-maimulte(M:N).
Legtura unu-la-unu(1:1)
n acest tip de legtur, o entitate este asociat cu alt entitate i viceversa. S
lum de exemplu, legtura a cumpra (prezentat n figur 3.1); am stabilit ca un
medicament eeste cumprat de un pacient i un pacient cumpra un medicament, deci
legtura medicament/pacient va fi unu-la-unu, n mod symbolic reprezentat:
PACIENT:MEDICAMENT.
40
Surchicin Alexandru
compoziie
id medicamet
pre
nume
Medicament
cumpar
prenume
Iniiala
tatlui
id pacient
Nume de
familie
cnp
nume
Pacient
Figura 3.1: O diagram ER PACIENT-MEDICAMENT cu legtura cumpar, i

raportul de cardinalitate 1:1
41
Surchicin Alexandru
O diagram poate fi reprezentat sub forma unei legturi 1:1 ca n figura 3A (Batani,
Ceri, i Navathe, 1992).
PACIENT
MEDICAMENT
Figura 3A: O legatur 1:1, PACIENT:MEDICAMENT::1:1

Legtur mai multe-la-una (M:1)
Dac legtura SA (PACIENT:MEDICAMENT) prezentat n figur 2.6 ar fi fost de
tipul mai multe-la-una, am fi fost spus c mai muli pacieni sunt asociai cu acelai
medicament i un medicament este asociat mai multor pacieni, asta nseamn:
PACIENT-MEDICAMENT::M:1.
Am folosit intenionat locuiunea verbal a fi asociat n locul verbului a cumpra
deoarece afirmaia mai muli pacieni cumpra un medicament poate avea mai multe
nelesuri. De asemenea, folosirea unui verb pentru a exprima o legtur nu este
ntotdeauna cea mai bun alegere cnd desenm prima dat diagram, numai dac
suntem absolut siguri c verbul ales descrie n mod corect intenia utilizatorului. De
asemenea am fi putut folosi locuiunea verbal este legat de n locul locuiunii a fi
asociat cu pentru a fi siguri c nu greim.
Vom limita limbajul folisit pentru a descrie legtura prezentat; dar ce implic o
legtur PACIENT:MEDICAMENT::M:1 ?
Printr-o diagram legtura M:1 s-ar reprezenta c n figur 3B(Baani,Ceri, i
Navathe, 1992).
42
Surchicin Alexandru
PACIENT
MEDICAMENT
Figura 3B: Legatura mai multe-la-una PACIENT:MEDICAMENT::M:1

Legtura una-la-mai multe (1:M)
Sensul legturii una-la-mai multe S(PACIENT:MEDICAMENT) (prezentat n
Figur 3.6) ar fi ca unui pacient i sunt associate mai multe medicamente i un
medicament este asociat unui pacient. Evident, dac definim o legtur 1:M (sau M:1),
atunci trebuie s fim foarte clari care entitate este 1 i are este M. n cazul de fa este :
PACIENT MEDICAMENT::1:M.
n mod grafic legtura 1:M poate fi reprezentat ca n figur 3C (Baani, Ceri, i
Navathe, 1992).
PACIENT
MEDICAMENT
Figura 3C: Legtura una-la-mai multe PACIENT:MEDICAMENT::1:M

Legtur mai multe-la-mai multe (M:N)
n legturile mai multe-la-mai multe, mai multor apariii ale unei entiti i sunt
asociate mai multe apariii ale celeilalte entiti. O legtur de tipul mai multe-la-mai
43
Surchicin Alexandru
multe este notate M:N. n documentaia mai veche astfel de legturi erau notate M:M,
dar n crile de actualitate se noteaz M:N indicnd c cele dou numere de entiti nu
este de neaprat egal (de obicei valorile lui M i N sunt diferite).
Dac legtura noastr iniial S ar fi fost de tipul mai multe-la-mai multe, un
student ar fi asociat cu mai multe medicamente i un medicament cu mai muli pacieni,
adic:
PACIENT:MEDICAMENT::M:N
n acest caz (dac presupunem S=condus, aa cum este prezentat n figur
2.6), mai muli pacieni pot cumpra mai multe medicamente (nu toate n acelai timp) i
mai multe medicamente pot fi cumprate de mai muli pacieni.
n mod grafic legtura M:N poate fi reprezentat ca n figur 3D (Baani, Ceri, i
Navathe, 1992).
PACIENT
MEDICAMENT
Figura 3D: Legtura mai multe-la-mai multe PACIENT:MEDICAMENT::M:N

n exprimarea cardinaliti acest raport x:x, unde x=1 sau M(N), este numit raport
cardinal.
Care este modul de a descrie descrie situaia rel a studeniilor i automobilelor
noastre?
Aceasta este o ntrebare foarte interesant. Rspunsul este c trebuie s modelm
realitatea dup cum ne este prezentat aceasta de utilizator. Ascultm utilizatorul,
facem cteva presupuneri i desenm modelul. Redm modelul realizat utilizatorului
prin intermediul unor afirmaii pentru ca acesta s l aprobe sau s l corecteze.
Un lucru ce nu poate fi realizat folosind diagrama ER este s modelm fiecare
situaie pentru fiecare posibilitate. Punctul de pornire n creare a unei baze de date l
44
Surchicin Alexandru
reprezint o situaie care va fi determinat prin procesul de analizare al sistemului. n

analiza clasic a sistemelor, analistul primete informaii de la utilizator, creaz o
descriere detaliat i apoi prezint rezultatul utilizatorului. Apoi, analistul (analistul de
baze de date/proiectantul) va modela realitatea descris de utilizator. Dac utilizatorul
nu este de acord, atunci analistul poate cu uurina modifica modelul conceptual, pentru
a-l aduce la forma dorit de utilizator.
n exemplul nostru PACIENT:MEDICAMENT, alegerea pe care o vom face va fi
c unui pacient i este asociat (cumpr) un medicament. Chiar dac pot exista excepii
de la acest caz, vom adopta acest model i scopul acestui model este acela c va
trebui s alegem cum vom identifica legturile dintre entiti dar i informaiile pe care
dorim s le asociem entitiilor. Trebuie s inem cont de faptul c avem de a face cu un
model conceptual care se poate modifica, n funcie de realitate; totui, trebuie s
alegem un model cu care s ncepem, i cel pe care l alegem este acela de legtur
unu-la-unu ntre pacieni i medicamente.
n modelul Chen-like, vom descrie legtura unu-la-un, adugnd numerele de
cardinalitate pe liniile din diagram ER care conecteaz legturile i entitiile (vezi
figura 3.1).
n Figur 3.1 punem un 1 pe linia dintre dreptunghiul entitii PACIENT i
rombul legturii i mai punem un 1 pe linia dintre rombul n care este trecut legtura
i dreptunghiul ncare es-te trecut entitatea MEDICAMENT. Aceste cifre de unu
nseamn c un
pacient se afl n legtur cu un medicament i un medicament se
afl n legtur cu un pacient. Trebuie s fim ateni atunci cnd spunem exact ce
nseamn aceast legtur. n modelul nostru nseamn c n incinta farmaciei un
pacient va cumpra cel mult un medicament. n plus, vom spune c un medicament va
fi cumprat de un pacient. Deoarece clarificm (rafinm) baza de date, ncercm s
potrivirn numele legturii pentru a se potrivi cu conceptul pe care l modelm- condusulde acea vom numi legtura conduce.
3.3 Participare: Integral/Parial

Este probabil c ntr-o farmacie nu toi pacienii cumpra un mecicament. Pentru
modelul nostru, am putea presupune c toate medicamenetele din incinta farmaciei
sunt associate unui pacient. Pentru a arta c fiecare medicament este cumprat de
un pacient, dar nu ca fiecare pacient cumpra un medicament, vom lrgi modelul nostru
Chen-like al diagramei ER punnd o linie dublntre rombul n care este trecut legtura
45
Surchicin Alexandru
i entitatea MEDICAMENT pentru a indica faptul c fiecare medicament este cumprat

de ctre un pacient. Altfel spus, fiecare medicament din baza de date se afl ntr-o
legtur. ntre entitatea PACIENT i rombul n care este trecut legtura vom pstra o
singur linie pentru a indica faptul c nu fiecare pacient cumpra un medicament. Unii
pacieni nu vor participa la legtura de a cumpra pentru c nu cumpra
niciun
medicament n incinta farmaciei. Liniile simple/duble sunt numite constrngeri de

participare (cunoscute i sub numele de constrngeri opionale) i sunt prezentate n
figur 3.2 .
id
medicament
compoziie
pre
nume
Medicament
1
Participare
integrala
cumpr
Participare
partiala
prenume
Initiala
tatalui
Nume de
familie
numr pacient
cnp
nume
Pacient
adres
specializare
Figura 3.2: O diagram ER a bazei de date PACIENT-MEDICAMENT cu legtura

cumpr
Linia dubl indic participarea integral. Unii proiectani prefer s o numeasc
participare mandatorie. Atunci cnd o parte a unei legturi este mandatories au
46
Surchicin Alexandru
complet, nu se poate c o valoare-sa s fie nul (sau s lipseasc) pentru atributul din
acele legturi. n cazul nostru, dac un medicament este n baza de date, trebuie s se
afle n legtur cu un pacient.
Linia simpl, participarea parial este numit i opional. Sensul participrii
opionale sau pariale este c ar putea fi pacieni care nu au legtur cu nici un
medicament.
3.4 Meodologia de proiectare ER

Pasul 1: Se selecteaz entitatea principal din descrierea bazei de date i se noteaz
atributele care trebuie reinute pentru aceasta entitate. Se eticheaza cuvintele cheie i
se dau cteva exemple de date.
Pasul 2: Se folosete romna structurat pentru entiti, atribute i chei pentru a descrie
baza de date obinut.
Pasul 3: Se examineaz atributele din entitatea principal (eventual cu asistenaa
utilizatorului) pentru a gsi infonnaii despre fiecare dintre atributele ce vor fi stocate
pentru entiate.
Pasul 3a: Dac pentru un atribut avem nevoie de alte informaii, atLmci atributul
respectiv devine entitate.
Pasul 3b: Se redefinete legtura cu entitatea iniial
Pasul 4: Dac o alt entitate este necesar, se deseneaz entitatea mpreun cu
atributele acesteia. Se repeta pasul 2 pentru a vedea dac entitatea ar trebui mprit
n mai multe entiti.
Pasul 5: Se leag entitiile prin legturi, dac exist legturi.
Pasul 6: Stabilete exact natura legturilor. De exemplu, dac exist o legtur
A:B::1:M, atunci exist o legtur de la A(l) la B(M) i de la B(M) napoi la A(l).
Pasul 7: Se prezint utilizatorului baza de date proiectat, completat cu entiti,
atribute, chei i legturi. Se reface diagram n funcie de solicitrile acestuia.
Pasul 8: Se dau cteva exemple de date.
Un exemplu de lagtur una-la-multe (1:M)

Legturile care sunt 1:M sau M:1 sunt moduri de a privi asemntor aceiai
problem. Cnd specificam 1:M sau M:1, trebuie s fim foarte ateni s spunem care
entitate este 1 i care este M. Ca exemplu de legtura 1:M, s considerm problema
studeniilor i a camerelor. ntr-o camer pot s locuiasc mai muli student, iar mai
47
Surchicin Alexandru
muli student pot s locuiasc ntr-o camer. Deci, legtura dintre camera comun i
student ar fi de una-la-multi (1:M: CAMERA:STUDENT) i va fi prezentat n figur 3.3
(fr atribute).
Camera
ocup
Camerele pot fi
ocupate de mai muli
studeni .
Mai multi studeni pot

ocupa o camer
Student
Figura 3.3: O diagram ER (fr atribute) a unei legturi 1:M
Dup cum se observ nu toate camerele sunt locuite de studeni, i de aceea
participarea camerelor n legtur este parial. n mod normal am spune:
Camerele pot fi ocupate de mai muli studeni.
Mai mult, s-ar putea c nu toi studenii s locuiasc n camere de cmin: deci, legtura
dintre STUDENT i CAMER este de asemenea parial:
Studenii pot s ocupe o camer.
Acum s refacem legturile folosind att propoziii scurte ct i lungi. Pentru prima
propoziie: Camerele pot fi ocupate de muli studeni- aceasta se potrivete cu
ablonul 4- x:y::l (parial):M
ablonul 4-1:M de la partea 1, cu participare parial:
Unele x-i sunt legai de mai muli y-eci.
Deci, propoziia mai corect este: X-ii, dar nu de neaprat toi x-i, (care sunt stocai n
baza de date) poate fi legai de mai muli (zero sau mai muli) y-eci .Unii x-i nu sunt
legai de nici un y.
Sau camerele, dar nu de neaprat toate camerele, (care sunt nregistrate n baza de
date) pot fi ocupate de mai muli (zero sau mai muli) studeni.
48
Surchicin Alexandru
Pentru legtura invers: Studenii pot ocupa o camer - aceasta se potrivete la

ablonul 2
M(parial): l.
ablonul 2-M(parial):1, de la captul cu M cu participare opional:
Unii x-i sunt legai de un y.Deci, traducerea lung a propoziiei este:
X, dar nu de neaprat toi x-ii, (care sunt nregistrai n baza de date) pot fi legai de
unul i numai un y. Unii x-ii pot s nu fie legai de nici un y. [Nici un x nu este legat de
mai mult de un y [] indic participarea opional.
nlocuind X cu studenii i y cu camere obinem: Studenii, dar nu neaprat toii studenii
(care sunt nregistrai n baza de date) pot s ocupe una i numai o camer. Mai muli
studeni pot s nu ocupe nici o camer. Nici un student nu ocup mai mult de o camer.
Un exemplu de legtur multe-la-una (M:1)
S presupunem c coal sau facultatea pentru care crem baza de date are
locuri de parcare pentru student, i n continuare s presupunem c fiecrui student i
este asociat un anume loc de parcare. Va trebui s avem o enitate numita SUPRAFA
DE PARCARE, care va avea locaii de parcare descrise cu ajutorul unor notaii
descriptive cum ar fi Zona de Est #7, Zona de Nord #28, etc. n acest caz, mai multe
automobile sunt atribuite unei suprafee de parcare i o suprafa de parcare conine
mai multe automobile, deci legtura este multe-la-una,
M:1::AUTOMOBIL::SUPRAFAA DE PARCARE. Aceast diagram este prezentat n
Figur 3.4(din nou, fr atribute).
49
Surchicin Alexandru
Student
M
Studentii trebuie sa se
inscrie la mai multe cursuri
a parca
La un curs se pot inscribe
mai multi studenti
Curs
Figura 3.5: O diagram ER (fr tribute) a unei legturi M:N

Am descris legtura de participare dintre automobil i suprafaa de parcare ca
fiind complet n ambele sensuri- ceea ce nseamn c toate automobilele au un loc de
parcare i toate locurile de parcare sunt atribuite studenilor.
Expresiile gramaticale ale acestei legturi sunt:
ablon 1- M:1, de la captul M, participare complet
x-i care sunt nregistrai n baza de date trebuie legai de unu i numai un y. Nici un x
nu e legat de mai muli y-eci.
x=automobil, y=loc de parcare, legtur=a parc
Automobilele, care sunt n baza de date, trebuie s fie parcate n unul i numai un
singur loc de parcare. Nici un automobil nu poate fi parcat n mai mult de un loc de
parcare.
i invers:
ablonul 3 -1:M, de la captul l, participare complet
x-i, care sunt nregistrai n baza de date, trebuie s fie legai la mai muli (unu sau mai
muli) y-ci.
50
Surchicin Alexandru
[Nici un x nu este legat cu un non y (sau) Non x-i nu sunt legai de un y. (Forma
negativ va depinde de sensul propoziiei.)]
n locurile de parcare, care sunt stocate n baza de date, trebuie s parcheze mai multe
(unul sau mai multe) automobile. Nici un loc de parcare nu conine automobile care s
nu aparin studenilor. Asta nseamn c pe locurile de parcare care sunt reinute n
baza de date nu sunt parcate automobile care s nu fie ale studenilor.
Un exemplu de legtur mai multe- la-mai multe (M:N)
Exemplul clasic pe care l vom trata aici este acela cu studenii care participa la
cursuri. Pentru nceput tim c studenii participa (sunt nscrii) la mai multe cursuri, i
fiecare curs este frecventat de mai muli studeni. Diagrama de baz pentru legtur
student-curs este acea din figura 3.5.
Student
Studenii
trebuie s se
inscrie la mai
multe cursuri
inscrie
La un curs se
pot nscrie mai
muli studeni
N
Curs
Figura 3.5 O diagram ER (fr atribute) a unei legturi M:N
51
Surchicin Alexandru
Am ales cuvntul nscrie pentru a descrie legtura. Participarea studenilor la

legtura de nscriere este complet(mandatorie); iar cea a cursurilor este parial.
Alegerea a fost arbitrar, amndou putatnd fi complete sau pariale, depinznd de
nevoile i dorinele utilizatorului. Privii cu atenie expresiile gramaticale i obsevai
impactul alegerii fcute, participare complet ntr-un caz i pariala n cealalt caz.
Expresile gramaticale ale legturii sunt:
ablonul 3-M:N, de la captul M, participare complet
x-i, care sunt nregistrai n baza de date, trebuie s fie legai cu muli (unu sau mai
muli) y-ci.[Nici un x este legat cu un non y (sau) Non X-i nu sunt legai cu un y (sau)
Nici un x nu este legat de un y. (Forma negativ va depinde de sensul propoziiei)].
x=studeni, y=cursuri, legtura=nscrie
Studenii, care sunt nregistrai n baza de date, trebuie s fie nscrii la multe (unul sau
mai multe) cursuri.
i forma invers:
ablonul 4-M:N, de la captul M, participare parial.
x-i, dar nu de neaprat toi (care sunt reinui de baza de date) pot s fie legai cu muli
(unu sau mai muli) y-ci. Unii x-i pot s nu fie legai de y.
X=curs. y=student. legtur=nscris
Cursurile. dar nu de neaprat toate cursurile. (care sunt stocate n baza de date)
pot s aib nscrii muli (unu sau mai muli) studeni. Unele cursuri pot s nu aib
nscrii studeni. De asemenea, aceast baz de date ne spune c n timp ce putem s
avem cursuri fr studeni, trebuie s stocm informaii doar despre studeni activi, care
participa la cursuri. Evident am putea s considerm legtura cu studenii parial, i
astfel am putea stoca toi studenii-inclusiv pe cei inactivi. Vom alege tipul de
constrngere de participare al legturii n funcie de realitatea descris-realitatea
furnizat de utilizator.
Un ultim exemplu
Ca ultim exemplu pentru a ncheia acest capitol, vom prezenta nc 0 problem
i o metodologie. S considerm un model simplificat pentru un aeroport. care reine
PASAGERI i AVIOANE. S presupunem c atributele entitii PASAGER sunt numele,
52
Surchicin Alexandru
articolele din bagaj, i numrul pasagerului. S presupunem c atributele entitii

AVION sunt numrul avionului, destinaia, ora decolni i ora de sosire.
Observaie: Vom omite mai multe lucruri (atribute) pe care le-am fi putut lua n calcul
pentru un aeroport; dar de dragul exemplului, vom presupune c acestea sunt singurele
informaii pe care le vom nregistra n baza de date.

Pasul 1 : Se selecteaz o entitatea principal din descrierea bazei de date i se
noteaz atributele are trebuie reinute pentru aceasta entiate. Se eticbeteaz
cuvintele cheiele i se dau cteva exemple de date.
S presupunem c am ales PASAGER ca entitate principal. PASAGER are
urmtoarele atribute: numrul pasagerului#, nume(numele de familie, iniiala tatlui i
prenume), bagajele. Vom desena aceasta diagram, alegnd numrul pasagerului# ca
i cheie i nume ca atribut compus.
Nume
de
familie
bagaje
Intiala
tatlui
prenume
nume
Pasager
Figura 3.6: Diagrama entitii pasager
Numr
pasager#
Pasul 2: Se realizeaz o descriere n limba romn a entitilor, atributelor, i

cheilor.
Entitatea
Aceast baz de date stocheaz date despre PASAGERI. Pentru fiecare
pasager, reinem urmtoarele: numrul pasageruluii#, nume (nume, iniiala tatlui i
prenume), bagaje.
Atributele
Pentru atributele atomice, att(j):
53
Surchicin Alexandru
Pentru fiecare PASAGER, ntotdeauna va fi un singur numr de pasager #. Numrul de

pasager nu va fi divizat.
Pentru fiecare PASAGER, ntotdeauna va fi una i numai o nregistrare pentru articolele
din bagaje.Valoarea pentru acestea nu va fi divizat.
Pentru atributele compuse, att(j):
Pentru fiecare PASAGER, vom nregistra numele, care este format din nume de familie,
iniiala tatlui i prenume. Numele de familie, iniiala tatlui i prenumele sunt pari ale
atributului nume.
Cheile
Pentru fiecare PASAGER, vom avea urmtoarea cheie primarznumrul pasagerului#.
Pasul 3: Se examineaz atributele din entitatea principal (eventual cu asistenaa
utilizatorului) pentru a gsi informaii despre fiecare din atribute.
Pasul 4: Dac o alt entitate este necesar, se deseneaz entitatea mpreun cu
atributele acesteia. Se repet pasul 2 pentru a vedea dac se mai poate obine
alte entiti.
Cealalt entitate este AVION care are urmtoarele atribute: numrul avionului#,
destinaia, ora decolrii, ora sosirii.
Entitatea
Baza de date stocheaz date despre avioane. Pentru fiecare AVION, vom nregistra:
numrul avionului#, destinaia, ora de plecare, i ora de sosire. Atributele
Pentru atributele atomice, att(j):
Pentru fiecare AVION, ntotdeauna va exista unul i numai un singur numr de avion#.
Valoare pentru numr avion# nu va fi subdivizat.
Pentru fiecare AVION, ntodeauna va exista una i numai o singur nregistrare a
destinaie. Valoarea destinaiei nu va fi subdivizat.
Pentru fiecare AVION, ntodeauna va exista una i numai o nregistrare a orei de
plecare. Valoarea orei de plecare nu va fi subdivizat.
Pentru fiecare AVION, ntodeauna va exista una i numai o nregistrare a orei de sosire.
Valoarea orei de sosire nu va fi subdivizat.
Cheile
Pentru fiecare AVION, vom avea urmtoarea cheie principal: numrul avionului#.
Pasul 5: Se leag entitile prin intermediul legturilor, dac acestea exist.
Ce legtur este ntre avioane i pasageri?
54
Surchicin Alexandru
Toi vor cltori cu avioane. Toate avioanele vor avea mai muli pasageri.
Diagrama pentru aceast problem este ilustrata n figur 3.7 i figura 3.8. Observai c
din nou avem de luat o a a gtur dintre pasager i avion. n decriere nu se specific
dac ar trebui s alegem 1 sau M, aa c vom alege 1. De asemenea vom alege
participarea complet la ambele pri. Ar fi ceva straniu s stocm date despre
pasagerii care nu au cltorit cu avioanele aeroportului sau despre zboruri care nu au
avut pasageri. n figur 3.7 sunt afiate doar entitile i atributele bazei de date. n
figur 3.8 atributele sunt descrise, i deasemenea include i civa din paii prezentai
anterior i cteva exemple de date. Iniial se poate folosi figura 3.7, dar ulterior locul
acesteia va fi luat de figura 3.8 pentru o documentare mai concis .
Nume de
familie
Initiala
tatlui
prenume
Numr pasager #
bagaje
nume
Pasager
Pasagerii zboar
cu un avion
zboar
Numar
avion#
Avioanele
zboar cu mai
muli pasageri
Ora
sosirii
destinaie
Avion
Ora
decolrii
Figura 3.7: O diagram a bazei de date PASAGERI- AVIOANE cu legtura zboar

55
Surchicin Alexandru
Pasager
M
Pasagerii zboar
cu un avion
Avioanele
zboar cu mai
muli pasageri
zboar
Avion
Exemplu:
Pasager(nume, NRP, bagaje)
Avion(numr avion#, destinaie,oradecolrii, ora sosirii)

numar avion# destinaie
ora decolrii ora sosirii
12316 2
104
Torino
09:17
11:10
43536 5
219
Paris
17:05
18:35
nume
NRP
Steve, I.I
John, S.S
bagaje
Pasul 6: Se stabilete cu exacitate natura legturilor la ambele capete. De

exemplu, dac exist o legtur A:B::1:M, atunci exist o legtur de la A(1) la
B(M) i de la B(M) napoi la A(1).
ablonul 1-M:1, de la captul M, cu participare complet
x-i, care sunt stocai n baza de date, trebuie s fie legai cu unu i numai un y.Nici un
x nu este legat cu mai mult de un y.
56
Surchicin Alexandru
x=pasager, y=avion, legtura=zbor

Pasagerii, care sunt nregistrai n baza de date, trebuie s zboare cu unu i numai un
singur avion . Nici un pasager nu cu mai mult de un avion.
ablonul 3-1:M, de la captul 1, cu participare complet
x-i care sunt nregistrai n baza de date, trebuie legai cu mai muli (unu sau mai muli)
y-ci.
x=avion, y=pasager,legtura=zbor
Avioanele, care sunt nregistrate n baza de date, trebuie s zboare cu muli(unu sau
mai muli) pasageri.
Pasul 7: Se prezint utilizatorului baza de date proiectat, cu descrieri pentru
entiti, atribute, chei i legturi. Se reface diagrama dac este necesar.
Pasul 8: Se dau cteva exemple pe baza diagramei realizate.
3.6 Maparea legturilor la o baz de date relaionale

n aceast seciune vom continua cu prezentarea regulilor de mapare nceput la
sfritul primului capitol. n primul capitol a fost prezentat modul n care se mapeaz
entitiile, entitiile cu atribute compuse, i entitiile cu atribute cu valori multiple. n
acest capitol, avnd cunoscut noiunea de constrngere, vom prezenta modul n care
se mapez aceste legturi.
I. Identificm entitiile: Pasager, Avion
2. Adaugm atribute la entiti, i identificm cheile principale:
Pasager (nume[nume, prenume, iniial], frecvena zborurilor#, bagaje)
Avion(zborul#, destinaia, ora de plecare, ora de sosire)
3. Ce legtur este ntre pasageri i avioane?
Pasagerii zboar cu avioane.
Prima noastr regul de mapare a legturilor mapeaz legturi binare M:N.
M321- Pentru legturi binare M:N: Pentru fiecare legtur M:N, crem un nou tabel
(legtur) cu cheile principale ale celor dou entiti care sunt legate prin legtura
M:N. Cheia noului tabel va fi rezultatul concatenrii cheilor entiti. n acest tabel
vom include toate atributele pe care le are legtur M:N.
57
Surchicin Alexandru
De exemplu, s ne referim la figura 3.6. Dac tabele STUDENT i CURS au

urmtoarele date:
Student
nume.de.familie
iniiala.tatlui
prenume
Stefania
Mangiru
Ionut
Ciunescu
Laura
COSOI
Andrei
Frunza
Petrescu
numr_student
adres
465
Brestei, nr.8
389
Stefan cel Mare,nr.2
128
Vasile Lupu, ap.65
364
Dimitre Cantemir,
745
Ismail, nr.5
bl.M12
Bogdan
Curs
numecurs
numar_curs
credite
Programare procedural
CDG4581
Algoritmi i structuri de date
SER1589
Baze de date
GHT4587
nainte de a folosi regulile de mapare trebuie s ne asigurm c au fost deja stabilite

cheile principale pentru cele dou entiti. Dac numr_student i numr_curs sunt
cheile principale pentru STUDENT i repesctiv CURS, atunci pentru a mapa legtura
M:N, vom crea un tabel numit LEGTURA:
LEGTURA
numr_curs
numr_student
CDG4581
587
SER1589
587
GHT4587
347
STR1258
266
FDG5842
266
SRT2587
157
Att numr_student ct i numr_curs sunt mpreun chei principale n tabelul

LEGTURA. Urmtorul set de reguli de mapare mapeaz legturile binare 1:1.
M3b Pentru legturi 1:1: Cheia principal a Entitii A v fi inclus n Entitatea B
drept cheie strin (foreign key).
58
Surchicin Alexandru
ntrebarea este: Care este entitatea A i care este Entitatea B? Rspunsul acestei
ntrebri este dat n urmtoarele 3 reguli de mapare: M3b_1, M3b_2, i M3b_3.
M3b_1- Pentru legturile binare 1:1, dac una din cele 2 pri are participare
complet n legtur, i cealalt participare parial, atunci vom insera cheia
principal a prii cu constrngerea de participare parial n tabelul celei cu
constrngere de participare complet. Vom include orice atribut al legturii n
tabelul entitii cu participare complete (cheia principal a primei entitii devine
cheie strin (secundar) n noul tabel).
De exemplu, referindu-ne la Figura 3.2, vom spune:

Un medicament, nregistrat n baza de date, trebuie s fie cumprat de unu i numai un
pacient. i un pacient poate cumpra unu i numai un medicament. Aici, participarea
complet este pe parte entitii MEDICAMENT deoarece Un medicament trebuie s
fie cumprat de ctre un pacient.
Deci lum cheia principal de pe partea cu participarea parial, adic PACIENT, i o
includem n tabelul MEDICAMENT. Cheia pricipala a entitii PACIENT este acum
id_pacient, deci aceasta va fi stocat n tabelul MEDICAMENT ca i cheie secundar. O
baz de date care implementeaz diagram ER din figura 3.2 la care se mai adaug i
cteva date, arata astfel:
Medicament
Nume
id_medicament
compoziie
pre
Aspirina
A42321
(acid acetilsalicilic)
23,46 lei
Floraderm
B74568
Urtica dioica (urzica)
45,12 lei
Floritene
E22578
Colagen
12,99 lei
Duvadilan
F14545
(isoxuprina hidrocl.20 mg)
126 lei
Pacient
Nume_de_familie prenume
iniial
numr_pacient
adres
Stefania
Mangiru
124
Stefan cel Mare,nr.8
Laura
Cosoi
235
Vasile Lupu, nr.2
Bogdan
Petrescu
147
Dimitre Cantemir,
862
Brestei, nr.8
bl.M12
Ionut
Ciunescu
L
59
Surchicin Alexandru
Bogdan
Petrescu
954
Lapus Arges, bl 2
Deoarece PACIENT are un atribut cu mai multe valori, specializare, avem nevoie de
tabelul de mai jos care s mapeze atributul cu mai multe valori.
Nume-specializare
Numr_pacient
Specializare
124
Bucatar
124
Medic
124
Frezer
235
Dentist
235
Sofer
147
Ospatar
147
Profesor
862
Sofer
954
Contabil
954
Bucatar
M3b_2 Pentru legturile 1:1, dac ambele pri au constrngere de participare

parial,
atunci
exist
posibiliti
de
implimentare
bazei
de
date
corespunztoare.
M3b_2a Prima alternativ: se poate alege o legtur petru a stoca cheia
celeilate.
M3b_2b A doua posibilitate: n funcie de situaie, se poate s creeze un nou
tabel care s conin cheia celor dou entiti (ca la M3a).
Din nou, referindune la figura 3.1, vom presupune c aici constrngerea de
participare este parial la ambele capete, i presupunem c nu exist nici un atribut
specializare. n acest caz va fi citit:
Un medicament poate fi cumprat de unu i numai un pacient.
i un pacient poate cumpra unu i numai un medicament.
Considerm id_medicament (cheia principal pentru MEDICAMENT) i o reinem n
PACIENT, c n exemplul de mai jos:
60
Surchicin Alexandru
Medicamente
nume
compoziie
A42321
Aspirina
23,46 lei
B74568
Floraderm
45,12 le
E22578
Floritene
Colagen
12,99 lei
F14545
Duvadilan
126 lei
id_medicament
pre
Pacient
Nume_de_familie prenume
iniiala
numr_pacient
adres
id_medicament
Stefania
Mangiru
124
Stefan cel Mare, nr.8
A42321
Laura
Cosoi
235
Vasile Lupu, nr.2
B74568
Bogdan
Petrescu
147
Dimitre Cantemir, bl.M 12E22578
Ionut
Ciunescu
862
Brestei, nr.8
F14545
Bogdan
Petrescu
954
Lapus Arges, bl 2
G14258
n tabelul PACIENT, id_vehicul este cheia strin.

M3b_2c - A treia alternativ de implementare a legturii binare 1:1 cu participare
parial n ambele pri, ar fi s crem un tabel nou care s conin doar cheile
celor dou tabele PACIENT i MEDICAMENT. n acest caz vom mapa legturile
aa cum am procedat n cazul legturilor binare M:N; i dac exist valori nule,
nu vor fi trecute n noul tabel, aa cum se arata mai jos:
PACIENT- MEDICAMENT
numr_pacient
Id_medicament
A42321
124
B74568
235
E22578
147
F14545
862
n acest caz cele dou legturi PACIENT i MEDICAMENT vor rmne:
Pacient
Nume_de_familie
prenume
iniial
numr_pacient
Stefania
Mangiru
124
Laura
Cosoi
235
Vasile Lupu, nr.2
61
adres
Surchicin Alexandru
Bogdan
Petrescu
147
Dimitre
Cantemir,
862
Brestei, nr.8
954
Lapus Arges, bl 2
bl.M12
Ionut
Ciunescu
Bogdan
Petrescu
Medicament
Nume
id_medicament
compoziie
pre
Aspirina
A42321
23,46 lei
Floraderm
B74568
45,12 lei
Floritene
E22578
Colagen
12,99 lei
Duvadilan
F14545
126 lei
M3b_3 Pentru legturile binare 1:1, dac ambele pri au constrngere de

participare complet, n funcie de semantic legturii se poate alege care dintre
legturi va conine cheia celeilate. Ar fi nepotrivit s includem chei strine n
ambele tabele deoarece am suprancrca baza de date.Vom include toate
atributele legtura, n tabelul care primete cheia strin.
Acum presupunnd participarea complete la ambele pri c n figur 3.1, cele dou
tabele PACIENT i MEDICAMENT ar putea arta astfel:
Pacient
Nume_de_familie
prenume
iniial
numr_pacient
adres
Stefania
Mangiru
124
Laura
Cosoi
235
Vasile Lupu, nr.2
Bogdan
Petrescu
147
Dimitre
862
Brestei, nr.8
954
Lapus Arges, bl 2
Cantemir,
bl.M12
Ionut
Ciunescu
Bogdan
Petrescu
62
Surchicin Alexandru
Medicament
compoziie
pre
numr_pacient
Nume
id_medicament
Aspirina
A42321
23,46 lei
124
Floraderm
B74568
45,12 lei
235
Floritene
E22578
Colagen
12,99 lei
147
Duvadilan
F14545
(isoxuprina hidrocl.20 mg) 126 lei
862
n cazul precedent, numr_pacient a fost inclus n MEDICAMENT, fcnd din

numr_pacient cheie strin n MEDICAMENT. De asemenea am fi putut lua cheia
primar de la MEDICAMENT, id_medicament, i a o includem n tabelul PACIENT.
n acest caz, dac legtura are atribute, atunci acestea ar fi stocate n MEDICAMENT,
mpreun cu numr_pacient.
Urmtorul set de legturi de mapare mapeaz legturile binare 1:N:
M3c Pentru legturile binare 1:N, s verificm ce fel de constrngeri de
participare are parte N a legturii:
M3c_1 Pentru legturi binare 1:N, dac partea N are participare complet ,
atunci includem cheia entitii din partea 1, n tabelul prii N, ca i cheie strin.
De exemplu, n figur 3.3 presupunnd participarea complete pe parte de student, vom
obine: n camer pot s locuiasc zero sau mai muli studeni i stundetii trebuie s
locuiasc n una i numai o singur camer.
STUDENT
Nume_de_familie
prenume
iniial
numr_student
camer
Stefania
Mangiru
124
Laura
Cosoi
235
Bogdan
Petrescu
147
Ionut
Ciunescu
862
Bogdan
Petrescu
954
63
Surchicin Alexandru
CAMER
numecamer
supervisor
Saunders
Popa
Eisenhover
Ghiorghiu
Aici, avem de a face cu participarea complete la captul N, ceea ce nseamn, la partea

cu entitatea STUDENT. Aadar, vom lua cheia pentru CAMER, numecamera, i vom
include n tabelul STUDENT. n acest caz, dac legtura are un atribut, va fi inclus n
STUDENT, n partea N.
M3c_2 Pentru legturile binare 1:N, dac partea N are participare parial, atunci
legtura 1:N este tratat la fel ca o legtur binar M:N cu un tabel separate
pentru legtur. Cheia noii legturi se obine prin concatenarea cheilor
entitiilor.
64
Capitolul 4: Descrierea aplicaiei
Surchicin Alexandru

Aplicaia realizat reprezint un Shopping Cart (aplicaie folosit pentru
cumprturi online).
Aplicaia este realizat n PHP, HTML i CSS. . Toate datele despre produsele
postate pe site se pstreaz ntr-o baz de date. La proiectarea bazei de date s-a folosit
MySQL.
Site-ul farmacie online a fost creat din urmtoarele fiiere :
index.php
ajutor.php
cart.php
categorycontent.php
config.php
contact.php
footer.php
createaccount.php
db_nfs.php
despre.php
header.php
login.php
index.php
logout.php
more.php
css.css
search.php
Este folosit fiierul farmacie.sql n care se pstreaz toat baza de date siteului, adic produsele i utilizatorii nregistrai pe site.
Shopping Cart-ul folosete urmtoarele tabele:
users
ID
int(11)
NUME
varchar(50)
65
Surchicin Alexandru
PRENUME
varchar(50)
NIK
varchar(50)
PAROLA
varchar(200)
EMAIL
varchar(200)
ADRESA
varchar(200)
STARE
tinyint(1)
INTREBARE
varchar(200)
RASPUNS
varchar(200)
medicamente
ID
int(11)
NUME
varchar(50)
IMG
varchar(100)
PRET
decimal(5,2)
PRODUCATOR
varchar(100)
CATEGORY
int(11)
DESCRIERE
varchar(5000)
categories
ID
int(11)
TITLE
varchar(50)
comanda
ID
int(11)
NUME
varchar(100)
PRENUME
varchar(100)
EMAIL
varchar(100)
ADRESA
varchar(100)
TITLU
varchar(100)
PRET
decimal(5,2)
Aplicaia permite unui utilizator s i creeze un cont, solicitnd n funcie de

profilul acesteia datele personale corespunztoare. Pentru crearea unui cont de
66
Surchicin Alexandru
utilizator apsam pe acest link i mergem pe pagin Web createaccount.php. Nu te

poi loga pe ai pn cnd nu ai fost nregistrat.
Figura 4.1: Sign up

Ea va arta n felul urmtor:
67
Surchicin Alexandru
Figura 4.2: Create account

n formularul de mai sus noul utilizator va trebui s introduc numele su,
prenumele, un nume de utilizator, emailul, parola i apoi s confirme parola.n caz c ai
uitat parola sunt dou ntrebri personale care i ajut la recuperarea parolei. Pentru
ndeplinirea acestor cmpuri vor fi puse anumite restricii. Spre exemplu:
numele i prenumele utilizatorului trebuie s fie introdus, astfel apare

mesajul Introducei primul i al doilea nume! .
if(empty($_POST['nume']) || empty($_POST['prenume']))
echo "<p id='failed'> Introduceti primul si al doilea nume!
</p>";
numele de utilizator nu trebuie s fie mai scurt de 4 caractere:
else if(empty($_POST['username']))
echo "<p id='failed'> Introduceti un nume de utilizator ! </p>";
else if (strlen($name) <= 4 )
echo "<p id='failed'> Numele de utilizator trebuie sa fie mai
scurt de patru caractere! </p> ";
parola nu trebuie s fie mai scurt de 6 caractere:

else if(empty($_POST['parola'])
echo "<p id='failed'> Introduceti va rog parola ! </p> ";
else if(strlen($password) <= 6 )
echo "<p id='failed'> Parola trebuie sa aiba cel putin 6
caracatere! </p>";
emailul va trebui s fie introdus corect:

else if(empty($_POST['email']))
68
Surchicin Alexandru
echo "<p id='failed'> Introduceti va rog emailul! </p>";

else if(!empty($_POST['email'])){
$email=$_POST['email'];
$condition='/^(?!(?>"?(?>\\\[ -~]|[^"])"?){255,})
(?!"?(?>\\\[-~]|[^"]){65,}"?@)(?>([!#-\'*+\/-9=?^-~
]+)(?>\.(?1))*|"(?>[!#-\[\]-~]|\\\[
~])*")@(?!.*[^.]{64,})(?>([a-z\d](?>[a-z\d-]*[az\d])?)(?>\.(?2)){0,126}|\[(?:(?>IPv6:(?>([af\d]{1,4})(?>:(?3)){7}|(?!(?:.*[af\d][:\]]){8,})((?3)(?>:(?3)){0,6})?::(?4)?))|(?>(?>IPv6:(?>(?3)
(?>:(?3)){5}:|(?!(?:.*[af\d]:){6,})(?5)?::(?>((?3)(?>:(?3)){0,4}):)?))?(25[0-5]|2[04]\d|1\d{2}|[1-9]?\d)(?>\.(?6)){3}))\])$/iD';
Nu se poate nregistra cineva cu acelai nume de utilizator sau cu acelai email de
dou ori. Dac vom ncerca s ne nregistrm, atunci ne va aprea mesajul Numele de
utilizator/Email deja exist nregistrate. Alegei alt nume utilizator/email!.
if(!empty($result))
echo "<p id='failed'> Numele de utilizator/Email deja
exista inregistrate! </p>";
Pentru recuperarea parolei sunt dou linii din formular care trebuiesc ndeplinite i sunt
prezentatea n figur urmtoare.
Figura 4.3
69
Surchicin Alexandru
if(empty($question))
echo "<p id='failed'> It's important to type a question! </p>";

if(empty($answer))
echo "<p id='failed'> Your answer is based on your password
recover! </p>";
Dup ce completm toate cmpurile corect i apsm butonul Sign up se va nregistra
un utilizator nou n baza de date. Utilizatorul dat va putea trece pe pagina de
autentificare login.php la care se va loga pe site.
Figura 4.4: Logare

Se vor face dou inputuri n care va trebui s scriem numele de utilizator i
parola. Dac va rmne o csu liber i vom apsa pe butonul Log n, atunci n
browser ne va aprea urmtorul mesaj de eroare Introducei numele de utilizator! sau
Introducei parola! i dac vor fi introduse datele incorecte n unul din cmpuri, atunci
ne va afia Numele de utilizator sau parola este incorect! ncercai din nou!. Codul
PHP care st n spatele acestor mesaje este urmtorul:
if(empty($name))
echo "<p id='failed'>Introduceti un nume de utilizator!</p>";
else if (empty($password))
echo "<p id='failed'>Introduceti parola!</p>";
else if (empty($result))
echo
"<p
id='failed'>
Numele
de
utilizator
sau
incorecta! <br/ >Va rog incercati din nou! </p>";
70
parola
este
Surchicin Alexandru
Dac ai introdus date corecte referitor la login i parola, atunci se vor extrage din baza
de date aceste informaii i utilizatorul va fi autentificat pe site. Dup ce ne-am logat,
trecem automat pe pagina de start - index.php. Pentru o securitate mai mare parola va
fi criptat n md5.
Dup procesul de logare butonul Sign up din bara meniului principal i va
schimba numele n log out.
Figura 4.5: Autentificare
Figura 4.6: Ieire

Apsnd pe acest buton se va petrece procesul de log out (ieire din cont). Coninutul
fiierului logout.php este urmtorul:
<?php
session_start();
session_destroy();
header('Location: index.php');
?>
Se va distruge sesiunea i se va trece pe pagina principal.
Site-ul proiectat are ca obiectiv promovarea i vnzarea on-line de produse
farmaceutice. Fiecare vnzare va fi precedat de o comand, care va trebui confirmat
pentru ca livrarea s aib loc. Confirmarea se va face prin e-mail, astfel c serverul pe
care magazinul va fi instalat va trebui s fie capabil s trimit i s recepioneze e-mailuri. Pagina index.php este pagina de start al site-ului. Pagina principal va arta n felul
urmtor:
71
Surchicin Alexandru
Figura 4.7: Home Page

Pe aceast pagin se vor afia ultimele 4 produse adugate pe site .
Figura 4.8: Meniul principal

<?php
if(isset($_GET['category'])){
72
Surchicin Alexandru
$query = mysql_query("SELECT * FROM medicamente WHERE

category='".mysql_real_escape_string($_GET['category'])."'
ORDER
BY NUME ASC ");

}
else{
$query = mysql_query("SELECT * FROM medicamente ORDER BY ID DESC
");
}
$itemperpage=4; /*produse pe pagina*/
$totalmed=mysql_num_rows($query);/*total produse*/
$Pagini=ceil($totalmed/$itemperpage);/*pagini*/
if(!isset($_GET['ID_MED'])){/*conditie daca e setata categoria*/
?>
Dac totalul de produse e mai mic dect produsele pe o pagin atunci se execut
urmtorul cod altfel se mparte n pagini.
<table id="categorytable"
> <?php
if($itemperpage>=$totalmed){
$result=array();
$rows=0;
while($result[$rows++] = mysql_fetch_assoc($query));
for($i=0;$i<$totalmed;$i++)}
?>
n interiorul catalogului, fiecare categorie va conine mai multe produse, n funcie de
stocul curent aflat n baza de date .
Fiecare produs selectat are denumire, pre, productor i arata astfel n figur
urmtoare :
73
Surchicin Alexandru
Figura 4.9: Informaii despre produs

Pentru a putea s comande, utilizatorul trebuie fie s se logheze, fie s se
nregistreze.
n continuare, utilizatorul are acces la partea de comenzi, unde poate naviga i
comanda prin acest link i mergem pe pagin Web more.php. Cnd accesam butonul
add to cart apare mesajul Adugat n co ! i dm click pe ok .
Figura 4.10: Mesaj pentru comand

<?php if(isset($_GET['ID_MED'])){ ?>
<table id="categorytable_summ" width="90%">
74
Surchicin Alexandru
<?php$query
get_query("SELECT
FROM
medicamente
WHERE
ID='".mysql_real_escape_string($_GET['ID_MED'])."'");
foreach($query as $result):
?><tr>
<td rowspan="4" width= 35%><img src="<?=$result['IMG']?>" alt="
Adauga
imagine
"
width="210"
height="290"
border=""
></img></td>
<td
><font
size="+2"
color="#993300"><?=$result['NUME']?></font></td>
</tr><tr>
<td><font
size="+1"><b>Producator:</b><?=$result['PRODUCATOR']?></font></t
d>
</tr><tr>
<td><font
size="+1"><b>Pret</b>
<i><?=$result['PRET']?></i>
<b>Lei</b></font> </td>
</tr><tr>
<td align="right"><a
href="more.php?action=add_med&id=<?=$_GET['ID_MED']?>"><img src
="img/cart1.jpg" onclick="alert('Adaugat in cos !')" width="130"
height="40" ></a></td>
</tr><tr>
<td colspan="2"><p><font
color="#993300"><b>Informatii:</b></font><br><?=$result['DESCRIE
RE']?></p></td>
</tr>
<?php endforeach;?>
</table>
<?php } ?>
Dup alegerea tuturor produselor, utilizatorul va hotr dac realizeaz comanda, o
modific sau o anuleaz. Vom alege link-ul: Trimite comanda.
75
Surchicin Alexandru
Figura 4.11: Coul de cumprturi

Aici se poate aduga un anumit produs sau se poate elimina un produs din coul
de cumprturi. Dup verificare, se poate trece la validarea comenzii, primul pas fiind
acela al apsrii butonului Plaseaz comanda. n acest moment, dac suntei logat
va aprea mesajul Comanda a fost plasat cu success !, n caz contrar va trebui s v
logai.
Cutarea se face dup denumirea medicamentului i productor.
Figura 4.12: Cutare

n fiierul header.php este un <form> care transmite toate datele n search.php
<form action="search.php" name="searchform" id="searchform"
method="post">
<input type="text" value="Cautare" id="search" name="search"
onblur="if(this.value=='') this.value=this.defaultValue"
onfocus="if(this.value==this.defaultValue) this.value=''"/>
<input type="submit" name="apply" value="submit"
style="position: absolute; height: 0px; width: 0px; border:
none; padding: 0px;" hidefocus="true" tabindex="-1"/>
<?php
if(isset($_POST['apply']))
$cautare=mysql_real_escape_string($_POST['search']);
else
$cautare= '';
76
Surchicin Alexandru
?>
</form>
n fiierul footer.php este un div n care este doar footerul site-ului.

<div id="footer-top">
<div id="footer">
<br />
<p id="footitle"> © 2014 Farmacia Plus+. Registered company
number: 4379591. </p>
<br>
</div>
</div>
Figura 4.13: Footer

n fiierul config.php se face conexiunea cu baza de date.
<?php
$db_host="localhost";
$db_user="root";
$db_pass="";
$db_name="farmacie";
$conn=@mysql_connect($db_host,$db_user,$db_pass);
mysql_select_db($db_name,$conn);
?>
Baza de date se va afla pe localhost, unde va trebui s ne conectm cu numele

de utilizator root la baza de date cu numele farmacie.
Baza de date al site-ului se numete farmacie.sql. Ea este proiectat n MySQL.
comanda
categories
ID
TITLE
ID
NUME
PRENUME
EMAIL
ADRESA
TITLU
PRET
medicamente
ID
NUME
IMG
PRET
PRODUCATOR
CATEGORY
DESCRIERE
Figura 4.14: Normalizarea bazei de date

77
users
ID
NUME
PRENUME
NIK
PAROLA
EMAIL
ADRESA
STARE
INTREBARE
RASPUNS
Surchicin Alexandru
ALTER TABLE `medicamente` ADD CONSTRAINT `fk1` FOREIGN KEY (`category`)

REFERENCES `farmacie`.`categories` (ìd`)
ALTER TABLE `medicamente` ADD CONSTRAINT `fk2` FOREIGN KEY (`nume`)
REFERENCES `farmacie`.`comanda` (`titlu`)
ALTER TABLE `medicamente` ADD CONSTRAINT `fk3` FOREIGN KEY (`pret`)
REFERENCES `farmacie`.`comanda` (`pret`)
ALTER TABLE `comanda` ADD CONSTRAINT `fk4` FOREIGN KEY (`nume`)
REFERENCES `farmacie`.ùsers` (`nume`)
ALTER TABLE `comanda` ADD CONSTRAINT `fk5` FOREIGN KEY (`prenume`)
REFERENCES `farmacie`.ùsers` (`prenume`)
ALTER TABLE `comanda` ADD CONSTRAINT `fk6` FOREIGN KEY (èmail`)
REFERENCES `farmacie`.ùsers` (èmail`)
ALTER TABLE `comanda` ADD CONSTRAINT `fk7` FOREIGN KEY (àdresa`)
REFERENCES `farmacie`.ùsers` (àdresa`)
Baza de date este compuse din trei tabele unde n tabelul medicamente putem
aduga alte noi produse pe site.
.
Figura 4.15: Baza de date

Fiierul css.css conine toate stilurile folosite pentru designul site-ului.
S-au folosit urmtoarele stiluri CSS pentru aceast pagin numit content.
78
Surchicin Alexandru
Figura 4.16: Produs

#content{
background-color:#e5e5e5;
border-radius: 0px 7px 7px 0px;
float: right;
width: 670px;
display: table-cell;
margin-top: 30px;
padding-top:10px;
border-style: solid;
border-width: 1px;
border-color:#a5a5a5;
}
#title a{
text-decoration: none;
color:
#993300;
}
79
Surchicin Alexandru
#title a:hover{
text-shadow:5px 5px 10px #993300;
}
n concluzie, putem spune c internet-ul a devenit un spaiu util tuturor oamenilor att
prin a-i petrece o parte din timpul liber, la serviciu, sau oriunde n alt parte.Odat cu
evoluia informaiilor i firmele au nceput s creasc, un mare avantaj constituindu-l
internet-ul care pe msur ce i-a dezvoltat tehnologiile, volumul de informaii a
nceput s fie din ce n ce mai mare. Ceea ce este un lucru bun pentru societate !
80
Surchicin Alexandru
Bibliografie :
Bibliografie :
1. Sikha Bagui, Richard Earp
Database Design Using Entity- Relationship Diagrams. Auerbach
Publication 2003
2.
3.
4.
5.
http://www.aw-bc.com/info/riccardi/database/Riccardi_ch4.PDF
http://www.cse.cuhk.edu.hk/~taoyf/course/bmeg3120/notes/er.pdf
www.seap.usv.ro/~valeriul/lupu/Curs_8_rom.doc
http://www.rgata.ru/sites/mpoevs/uploads/materials/bd/Kratkiy%20kur
s%20po%20BD.174.pdf
81

Merged Document

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Merged Document

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA DIN CRAIOVA

FACULTATEA DE MATEMATIC I TIINE ALE NATURII

UNIVERSITATEA DIN CRAIOVA

Modelarea bazelor de date folosind

Capitolul 2: Prima diagram a unei entiti ............................................... 30

Capitolul 3: Metodologia de proiectare ER i constrngeri asupra legturilor

Capitolul 4: Descrierea aplicaiei .............................................................. 65

Capitolul 1: Ce este o diagram

Capitolul 1: Ce este o diagram ER (entitate-legatur)?

1.1 Definirea bazei de date - cteva definiii: entitate, legtura,

Capitolul 1: Ce este o diagram

Exemple pentru o entitate care refer un loc ar fi STAT sau AR

Exemple pentru o entitate care refer un obiect ar fi CLDIRE, AUTO, sau

Exemple pentru o entitate care refer un eveniment ar fi VNZRI,

Exemple pentru o entitate care refer un concept ar fi CONT sau

n trecut, ne-am fi putut referei la o entitate ca la o nregistrare, dar termenul

Capitolul 1: Ce este o diagram

1.2 O metodologie de nceput

1.3 Metodologia de proiectare ER

Capitolul 1: Ce este o diagram

Definirea cerinelor este prima faz de inginerie software n care analistul

S desenm o diagram a unei entiti iniiale

S prezentm diagrama utilizatorului s vedem dac e bine i dac trecem mai

Al treilea pas poart numele de feedback n ingineria software. Procesul de

1.4 O prim diagram ER cu o singur entitate

Capitolul 1: Ce este o diagram

Capitolul 1: Ce este o diagram

Exist mai multe moduri de descriere a atributelor. Am ilustrat modelul atribute n

Capitolul 1: Ce este o diagram

Figura 1.1 (mijloc i jos) prezint o diagram ER cu o entitate, PACIENT, i trei

Capitolul 1: Ce este o diagram

1.5 Mai multe detalii despre atribute

1.6 Atributul simplu su atomic

Capitolul 1: Ce este o diagram

1.7 Atributele compuse

Capitolul 1: Ce este o diagram

1.8 Atribute cu valori multiple

Capitolul 1: Ce este o diagram

specializare este un atribut multivalue un atribut multi-value este

Figura1.5: O diagram ER cu un atribut multi-value

nc o dat, testul de singularitate sau multipilcitate al unui atribut va depinde n

Capitolul 1: Ce este o diagram

1.9 Atributele derivate

Capitolul 1: Ce este o diagram

1.10 Ce este o cheie?

Capitolul 1: Ce este o diagram

numr pacient este un

Figura 1.6: O diagram ER cu cheie primar

Capitolul 1: Ce este o diagram

Figura1.7: O entitate MEDICAMENT tare i o entitate MEDICAMENT slab

Capitolul 1: Ce este o diagram

O descriere n romn a entitiilor

trebuie s realizeze. Pentru o descriere n romn, vom folosi

gramatica a limbii romne structurate" pentru a reprezenta informaia corespunztoare

1.11 Modul de lucru

Capitolul 1: Ce este o diagram

Pentru fiecare Entitate, vom avea urmtoarea cheie primar: att(j)

1.12 Metodologia de proiectare ER

Capitolul 1: Ce este o diagram

Pentru fiecare PACIENT, nu vom presupune c orice atribut va fi unic. (figura

S considerm n continuare figura 1.4. Aceast figur are un atribut compus

Capitolul 1: Ce este o diagram

Vasile Lupu, nr. 14

tefan cel Mare, nr.8