3.

MODELAREA DATELOR în EA și UML

I. OBIECTIVE

1. Modelarea datelor prin entități și asocierile dintre acestea

2. Reprezentarea datelor în modelele EA, EAE și UML
3. Transformarea modelelor EA/EAE/UML în model relațional

II. FUNDAMENTARE TEORETICA

Un model de date este un instrument teoretic care permite interpretarea şi structurarea corectă
a datelor, astfel acesta ne permite să identificăm semnificaţia și conţinutul de informaţie pentru o
colecţie de date. În această perspectivă se poate defini o bază de date ca fiind o colecţie de date
persistente, organizate conform unui anumit model de date.

Modelarea conceptuală este procesul în care se elaborează o descriere semantică a unui sistem
(de exemplu, o organizaţie, o întreprindere, etc.), care trebuie reflectat de (modelat în) structura
generală (designul acestuia) şi de implementarea unei aplicaţii cu baze de date. Modelarea
conceptuală este independentă faţă de baza de date, ea implică analiza cerinţelor aplicaţiei şi
elaborarea unei structuri semantice generale ,de nivel înalt a bazei de date .

2.1.MODELUL ENTITATE-ASOCIERE (EA)

Modelul entitate-asociere (EA), introdus de Peter Chen în 1976, este una din cele mai
cunoscute abordări privind proiectarea structurii conceptuale a unei baze de date. Modelul EA descrie
entităţile asociate și restricţiile asupra acestora într-o manieră independentă de baza de date propriu-
zisă. Acest model este folosit ca bază pentru crearea unui model de tip relaţional sau orientat pe
obiecte corespunzător unui anumit sistem de gestiune a datelor.

Elementele esenţiale ale modelelor de date folosite în proiectarea bazelor de date sunt entităţile
(engl.entities) cu atributele lor şi asocierile (engl.relationships) dintre acestea.O entitate reprezintă
orice poate fi identificat în mod distinctiv, ea se referă la un aspect al realităţii obiective şi poate
reprezenta un obiect fizic, o activitate, un concept, etc. Orice entitate este descrisă prin atributele sale
care se aleg pe baza criteriului relevanţei relativ la domeniul de interes pentru care se defineşte modelul
respectiv, astfel încât să asigure diferenţierea precisă a entităţii respective faţă de alte entități.

Modelarea conceptuală a bazei de date este o etapă importantă în proiectarea unei aplicaţii de
baze de date. O aplicaţie cu baze de date reprezintă, de exemplu, o bază de date care contine informaţii
şi un program asociat care implementează comenzile necesare pentru introducere, ştergere, actualizare
a datelor, precum şi interogarile prin care un utilizator obţine informaţiile dorite.
De exemplu, entitatea Angajat al unei instituţii reprezintă o persoană angajată, care are o
anumită funcţie, lucrează într-o anumită secţie şi primeşte un anumit salariu. Această entitate poate fi
descrisă prin mai multe atribute, dintre care o parte sunt atribute de identificare a persoanei (cum sunt:
Nume, Prenume, DataNasterii, Adresa), iar alte atribute sunt atribute legate de activitatea acesteia în
instituţia respectivă (cum sunt: Funcţia, Salariul).
În bazele de date, entităţile similare care pot fi descrise prin aceleaşi atribute, se grupează în
mulţimi, fiecare entitate având valori particulare ale atributelor respective. Toate entităţile similare, care
pot fi descrise prin aceleaşi atribute, aparţin unui acelaşi tip de entitate. Colecţia tuturor entităţilor de
acelaşi tip dintr-o bază de date constitue o mulţime numită set de entităţi. O mulţime de entităţi se
descrie prin aceleaşi atribute prin care este descrisă fiecare entitate componentă.

1
 În proiectarea bazelor de date se folosesc asocieri între mulţimile de entităţi componente,
pentru a modela realitatea pe care baza de date o reprezintă. Asocierile pot fi binare (între două mulţimi
de entităţi) ,recursive ( la nivelul aceleiași entități) sau n-are (între n mulţimi de entităţi, n>2).
Asocierile binare sunt la rândul lor, de trei categorii, după numărul elementelor asociate din
fiecare dintre cele două mulţimi. Fiind date două mulţimi de entităţi, E1 şi E2, se definesc următoarele
asocieri binare (vezi Figura 3.1.) :

• asocierea “unu-la-unu” (one-to-one) este asocierea în care unei entităţi din mulţimea E1 îi
coreaspunde o singură entitate din mulţimea E2, şi reciproc; se notează cu 1:1.
• asocierea “unu-la-mulți” (one-to-many) este asocierea în care unei entităţi din mulţimea E1 îi
corespund una sau mai multe entităţi în mulţimea E2, dar unei entităţi din E2 îi corespunde o
singură entitate în mulţimea E1; se notează cu 1:N.
• asocierea “mulți-la-mulți” (many-to-many) este asocierea în care unei entităţi din mulţimea E1
îi corespund una sau mai multe entităţi în mulţimea E2 şi de asemenea, unei entităţi din E2 îi
corespund una sau mai multe entităţi în mulţimea E1; se notează cu M:N.

Figura 3.1. Tipuri de asocieri între două mulţimi (seturi) de entităţi.

(a) Asociere 1:1; (b) Asociere 1:N; (c) Asociere M:N

În crearea unui astfel de model, sunt utilizate două categorii de entităţi: entităţi puternice și
entităţi slabe. Entităţile puternice au o existenţă proprie în cadrul modelului, în timp ce entităţile slabe
nu pot exista decât dacă există o entitate puternică cu care sunt asociate. De exemplu, entitatea
Dependent poate să reprezinte o persoană care depinde de un angajat al unei instituţii (adică se află în
întreţinerea acestuia). Entitatea Angajat este o entitate puternică, deoarece ea există în mod mod normal
în modelul activităţii instituţiei, în timp ce o entitate Dependent este o entitate slabă: nu se va înregistra
o astfel de persoană decât dacă părintele acesteia este angajat în acea instituţie.

Modelul EA se reprezintă printr-o diagramă care conţine mulţimile de entităţi şi asocierile

dintre acestea. Una dintre cele mai folosite notaţii pentru redarea diagramei EA reprezintă o entitate
printr-un dreptunghi, iar atributele tipului de entitate prin elipse conectate printr-o linie continuă cu
acesta. Pentru entităţile puternice se utilizează un dreptunghi încadrat cu o linie simplă, iar pentru
entităţile slabe se utilizează un dreptunghi încadrat cu linie dublă sau întreruptă, pentru distinctivitate.

O asociere dintre două sau mai multe mulţimi de entităţi se reprezintă printr-un romb conectat prin linii
continue la tipurile de entităţi asociate. O asociere poate să aibă sau nu un nume; dacă are un nume,
acesta poate fi înscris în rombul respectiv. Tipul unei asocieri este stabilit astfel încât să reflecte cât mai
corect modul de organizare al activităţii modelate.Tipul asocierii se notează prin înscrierea
cardinalității (câte entități din set sunt parte în asociere) și participării( dacă aceasta este obligatorie
– notat cu 1 sau opțională- notat cu 0) pe fiecare legătură care conduce la un tip de entitate.
Este posibil ca o asociere să prezinte ea însăşi atribute şi aceste atribute se reprezintă prin elipse
conectate la asocierea respectivă.

2
 Asocieri în funcţie de cardinalitatea legăturii

1. Asocieri de tip „unu la unu” sunt asocieri în care maximele cardinalităţii au

valoarea 1.

2. Asocieri de tip „unu la mai mulţi” sunt asocieri în care maxima cardinalităţii
unei entităţi este unu, iar a celeilalte entităţi are valoarea „mulţi”.

3. Asocieri de tipul „mulţi la mulţi” sunt asocieri în care maximele cardinalităţii au

valoarea „mulţi”.

Observaţie:Asocierea de tip „mulţi la mulţi” se transformă în două asocieri de tipul „unul la

mulţi” fiind, de regulă, mai uşor de implementat şi de utilizat şi anume:

Asocieri parțiale și totale

Printr-o asociere parţială se înţelege o asociere în care nu există obligativitatea participării
la această asociere a tuturor entităţilor vizate, ci numai a unora dintre ele sau a nici uneia. Asocierea
parţială se caracterizează prin faptul că minima cardinalităţii ataşată unei entităţi este zero.
Observaţii
 dacă minima cardinalităţii este zero, are drept rezultat lipsa obligativităţii participări
partenerului la această asociere;
 dacă minima cardinalităţii este mai mare decât zero, are drept rezultat obligativitatea
participării.

3
 O asociere este totală dacă toate entităţile au obligativitatea să participe la asociere,
adică minima cardinalităţii este mai mare decât zero.

Un atribut de identificare (numit cheie primară), reprezintă un atribut care se

caracterizează prin unicitatea valorii sale pentru fiecare instanţă a entităţii.
În cadrul diagramei entitate-asociere, un atribut de identificare se marchează prin
subliniere sau prin marcarea cu simbolul # plasat la sfârşitul numelui acestuia.

De reținut:

a) În modelul EA tipul de entitate (şi mulţimea de entităţi corespunzătoare) semnifică un

substantiv, în timp ce o asociere semnifică un verb, deoarece de obicei o asociere reprezintă o
interacţiune între tipurile de entităţi
b) Modul de stabilire a entităţilor şi a asocierilor dintre acestea nu este unic, aceeaşi funcţionalitate
se poate obţine printr-o varietate de diagrame EA, depinzând de felul în care proiectantul
dezvoltă modelul conceptual şi mai departe realizează baza de date, deasemenea identificarea
corectă pentru entităţi ,atribute ,asocieri nu este, întotdeauna una simplă.
c) Modelul EA nu precizează modul cum sunt realizate asocierile între mulţimile de entităţi.
Acest aspect depinde de modelul de date utilizat în implementare.. De exemplu, în modelele
ierarhic şi reţea, asocierile sunt realizate explicit, prin link-uri (arce) de la o entitate la entităţile
asociate, în timp ce în modelul relaţional asocierea se realizează prin valorile unor atribute
comune ale mulţimilor de entităţi (prin chei primare și străine).

Un tutorial ce prezintă modelul EA poate fi consultat la adresa

https://www.tutorialspoint.com/dbms/er_model_basic_concepts.htm

Exemplul 1. Pentru baza de date a unei facultăţi se definesc tipurile de entităţi și cțteva atribute pentru
acestea:
FACULTATE (Nume, Adresa, ..)
PROFESOR (Nume, Prenume, Funcţia, …)
STUDENT (Nume, Prenume, AnStudii, …)

Între aceste tipuri de entităţi se pot defini asocierile: FACULTATE-PROFESOR, de tipul 1:N
şi asocierea PROFESOR-STUDENT, de tipul M:N.Asocierea PROFESOR-STUDENT reprezintă
examinarea studenţilor de către profesori, cu atributele acesteia: DataExaminării, Disciplina, Nota.
Dar, la fel de bine, este posibil ca NOTA să fie definită ca un tip de entitate, aflată în asociere
1:N cu fiecare din tipurile de entităţi PROFESOR şi STUDENT. Se definește asocierea de tip M:N între

4
tipurile PROFESOR şi STUDENT, se defineşte tipul de entităţi NOTA, asociat 1:N cu fiecare din
tipurile PROFESOR şi STUDENT.

Figure 3.3. Diagrama EA pentru Facultate

Exemplul 2. Pentru o bază de date din domeniul imobiliar , se pot pune în evidenţă
următoarele entităţi:
 DATE_PERSOANĂ – entitate care stochează date personale ale ofertantului
(vânzătorului) sau ale clientului (cumpărătorului);
 CERERI_ OFERTE – conţine ofertele sau cererile imobiliare propuse de vânzători,
respectiv cumpărători;
 DESCRIERE_IMOBIL – stochează informaţiile referitoare la imobile;
 JUDEŢE – entitate ce conţine judeţele în care sunt amplasate imobilele;
 LOCALITĂŢI - entitate ce conţine localităţile în care sunt amplasate imobilele;
 STRĂZI - entitate ce precizează străzile în care sunt amplasate imobilele;
 FACTURI – formularul necesar unei tranzacţii de cumpărare-vânzare.

Figura 3.4..Diagrama EA pentru domeniul imobiliar

2.2.MODELUL ENTITATE-ASOCIERE-EXTINS (EAE)

Modelul EA prezentat este suficient pentru modelarea aplicaţiilor de baze de date "tradiţionale",
adică bazele de date utilizate pentru activităţi financiare şi industriale. În ultimele două decade,
domeniile în care se folosesc baze de date au devenit tot mai numeroase, ca de exmplu,
telecomunicaţiile, proiectarea tehnologică, sistemele de informaţii geografice, seviciul WWW, etc.
Tipurile de entităţi definite în astfel de baze de date sunt mult mai complexe şi pentru reprezentarea lor

5
cît mai intuitivă şi mai compactă au fost propuse numeroase concepte noi, iar modelul a fost extins,
pentru a îngloba aceste noi concepte și anume subtipuri, respectiv specializare/generalizare cu scopul
unei mai bune structurări prin realizarea unor modele d edate care să includă ierarhii de entități.

Tipuri-subtipuri. În modelul EA extins se pot defini subtipuri de entităţi, care reprezintă

specializări ale unor tipuri de entităţi şi se pot defini de asemenea ierarhii pe mai multe nivele de tipuri
şi subtipuri de entităţi. Astfel se pot folosi două modalităţi de definire a ierarhiilor de tipuri:
specializarea şi generalizarea.

Specializarea este un proces de abstractizare a datelor prin care, pornind de la un tip de entitate
dat, se definesc unul sau mai multe subtipuri, diferenţiate între ele în funcţie de rolul pe care îl au în
modelul de date. Asocierea dintre o mulţime de entităţi de un tip dat şi mulţimea de entităţi de un subtip
al acestuia este o asociere 1:1, semnificând faptul că o entitate care aparţine unei mulţimi de un subtip
este asociată cu o singură entitate din mulţimea de entităţi de bază şi reciproc .

Generalizarea este procesul de abstractizare invers specializării, prin care se crează un supertip
de entitate pornind de la mai multe tipuri de entităţi. Pentru aceasta se identifică atributele comune ale
mai multor tipuri de entităţi şi aceste atribute vor caracteriza un supertip de entitate, iar atributele care
diferă de acestea rămân atribute specifice ale fiecărui tip. Rezultatul obţinut prin generalizare este, ca
şi în cazul specializării, o ierarhie de tipuri şi subtipuri de entităţi, iar asociearea dintre mulţimile
corespunzătoare este tot o asociere 1:1. Ceea ce diferă în generalizare faţă de specializare, este doar
modul în care se definesc nivelele ierarhiei.

2.3.MODEL DE DATE ÎN REPREZENTARE UML

Pentru reprezentarea diagramei EA au fost propuse numeroase variante de notaţii, pentru

aceasta se poate utiliza și limbajul UML (Unified Modeling Language), dezvoltat în special pentru
modelarea aplicaţiilor software în modelul obiectual. Diagrama claselor definită în limbajul UML este
similară diagramei EA, deşi terminologia diferă în câteva aspecte. Corespondenţa dintre modelul EA
şi modelul obiect este destul de evidentă, astfel un tip de entitate din modelul EA corespunde unei
clase în modelul obiect, o entitate corespunde unui obiect, iar mulţimea de entităţi de un tip dat
corespunde tuturor instanţierilor de obiecte din clasa respectivă.
În UML o clasă se reprezintă printr-un deptunghi cu trei compartimente: în primul
compartiment este înscris numele clasei; în compartimentul următor sunt înscrise atributele clasei,
care sunt atributele pe care le prezintă orice obiect instanţă a clasei, iar în ultimul compartiment sunt
înscrise metodele clasei, ce reprezintă operaţiile ce pot fi aplicate obiectelor.
În reprezentarea UML a unei diagrame EA, un tip de entitate se reprezintă prin
compartimentul de nume şi compartimentul de atribute, iar metodele nu sunt specifice diagramelor
EA. Asocierile între tipurile de entităţi din diagramele EA sunt numite tot asocieri în UML şi se
reprezintă prin legături între clase
O asociere binară de tipul 1:N sau M:N între două tipuri de entităţi din modelul EA
corespunde unei asocieri binare de acelaşi tip în modelul obiect, reprezentată printr-o legătură între
cele două tipuri de entităţi. Legătura este marcată (opţional) cu numele asocierii şi prin multiplicitatea
fiecărui tip de entitate în cadrul asocierii, marcată la capătul corespunzător al legăturii, cu o singură
valoare (de exemplu 1) sau în forma (min…max); un asterix (*) înseamnă nici o limită superioară a
participării în asociere. ( vezi Tabelul 3.1. pentru notații acceptate).

6
 De exemplu, de la tipul de entitate ANGAJAT se definesc subtipurile SECRETARA,
TEHNICIAN, INGINER. Acestea “moştenesc” toate atributele tipului iniţial şi fiecare dintre ele are
în plus atribute suplimentare, specifice rolului lor.În Figura 3.4. este reprezentată diagrama UML care
defineşte tipul de entitate ANGAJAT şi subtipurile acestuia (SECRETARA, TEHNICIAN,
INGINER), iar ierarhia tipurilor şi a subtipurilor este reprezentată prin asocierile dintre
acestea.Subtipul SECRETARA are ca atribut specific atributul "VitezaRedactare", care este o măsură
a calificării; subtipul TEHNICIAN are ca atribut specific atributul "GradCalificare", iar subtipul
INGINER are ca atribut specific atributul "Specialitatea"; acest din urmă atribut poate lua diferite
valori, ca de exemplu: Electronist, Programator, Mecanica, etc.

Figura 3.5. Reprezentarea UML a schemei conceptuale a unei baze de date

În UML, o asociere în care o entitate este pusă în corespondenţă cu entităţi care sunt părţi
constituente ale acesteia se numeşte agregare , deci agregarea este corespondenţa între "întreg" şi părţile
acestuia. O agregare se reprezintă printr-o legătură de asociere marcată cu un indicator de agregare, un
romb plasat la capătul legăturii din vecinătatea tipului de entitate care reprezintă "întregul". În modelul
obiectul şi în limbajul UML agregările sunt intens utilizate, dar în diagramele EA agregarea se utilizează
numai pentru asocierea unui tip de entitate slabă cu tipul de entitate puternică de care depinde. Ierarhiile
de tipuri din diagrama EA, reprezentate prin asocieri de tipul 1:1, corespund ierarhiilor de clase
(moştenirilor) din modelul obiect, care se reprezintă în UML printr-o legătură cu o săgeată direcţionată
către superclasă.
Restricţiile de mai sus se referă la modul şi gradul de participare şi de apartenenţă a
subclaselor în ierarhia de clase. În timp ce mandatory este o restricţie definită de utilizator, toate
celălalte restricţii sunt definite de UML. Restricţia disjunct indică faptul că intersecţia unei mulţimi
de subclase este mulţimea vidă. Adică, o instanţă a superclasei poate fi o instanţă numai a uneia din
subclase. Overlapping indică faptul că o instanţă a superclasei poate fi o instanţă a mai multe subclase.
Mandatory indică faptul că fiecare instanţă a superclasei trebuie să fie o instanţă a cel puţin uneia din
subclasele sale.

Notația Min/Max și semnificații

Notaţie min ... max 0 ... * Se referă la zero sau mai multe obiecte
(se referă la cel puţin min
0 ... 1 Se referă la niciun obiect sau la cel mult un obiect
obiecte şi la cel mult max
obiecte) 1 ... * Se referă la cel puţin un obiect
1 ... 1 Se referă la exact un obiect
3 ... 5 Se referă la cel puţin trei obiecte şi la cel mult cinci obiecte
Notaţie prescurtată 1 La fel ca 1 ... 1
* La fel ca 0 ... *
Tabelul 3.1. Notația Min/Max
7
 Multiplicităţile în UML sunt similare cu perechile (min, max) din modelul EEA. În UML,
atunci când descriem cu câte obiecte din clasa B poate fi asociat un obiect din clasa A, pereche min
... max este amplasată, pe linia asocierii, lângă clasa B. Acest aranjament este diferit faţă de cel al
perechii (min, max) în cazul modelului EEA; în acest ultim caz, perechea (min, max) este asociată cu
linia care uneşte clasa cu rombul legăturii, indicând de câte ori – minimum şi maximum – un obiect
al clasei participă la legătură (“relationship”). Valorile min şi max au însă aceeaşi semnificaţie cu
privire la restricţiile de cardinalitate şi de participare din modelul EEA. De exemplu, un min pentru
zero indică întotdeauna o participare parţială în asociere, pe când un min cu o valoare mai mare sau
egală cu unu indică o participare totală.

2.4.TRANSFORMĂRI ALE MODELULUI EA/EAE ÎN MODEL RELAȚIONAL

In procesul de transformare vom pleca de la o diagramă EA și vom obține trei tipuri de scheme
de relație:
a. Relații provenite din entități. Ele conțin aceleași informații ca și entitățile din care au rezultat.
b. Relații provenite din entități și care conțin chei străine. Ele conțin pe lângă informațiile provenite
din entitățile din care au rezultat și atribute care în alte entități sunt identificatori. Este cazul acelor
entități care au asocieri M :1 și parțial din cele care au asocieri 1 :1 cu alte entități.
c. Relații provenite din asocieri. Este cazul celor care apar din transformarea asocierilor binare mulți-
mulți și a asocierilor de grad mai mare ca doi. Ele conțin ca atribute reuniunea identificatorilor
entităților asociate plus atributele proprii ale asocierilor.

Procesul de transformare are la bază un algoritm și este din această cauză etapa care se pretează
cel mai bine pentru crearea de instrumente software care să-l asiste.(diverse IDE-SGBD oferă
automatizarea acestui proces).

Transformarea entităților

Fiecare entitate a diagramei se transformă într-o schemă de relație având:

Numele relației =Numele entității
Atributele relțtiei =Atributele entității
Cheia relației =Identificatorul entitțtii

Transformarea asocierilor unare și binare 1:1 și 1:N.

Fiecare asociere din această categorie va avea ca rezultat completarea mulțimii de atribute
descriptive ale uneia dintre cele două scheme rezultate din entitățile asociate, cu cheia celeilalte
scheme. Aceste atribute care se adaugă sunt denumite cheie straină deoarece ele sunt cheie, dar în alta
schemă de relație.
a. In cazul asocierilor multi-unu, se adaugă identificatorul entității unu în schema rezultată din
entitatea multi
b. In cazul asocierilor unu-unu, se adaugă identificatorul unei entități în schema rezultată din
transformarea celeilalte.
Alegerea schemei în care se face adăugarea se poate face după două criterii:
• fie în acea schemă care definește relația cu cele mai puține tupluri din cele două,
• fie păstrându-se, dacă există, filiația naturală între cele două entităti: identificatorul
părinte se adaugă la fiu.

Transformarea asocierilor unare ,binare de tipul M :N și a celor de grad > 2

Fiecare asociere M :N și fiecare asociere cu grad mai mare ca doi se transformă într-o schemă
de relație astfel:

8
Nume relație = Nume asociere
Atribute relație = Reuniunea identificatorilor entităților asociate la care se adaugă atributele
proprii asocierii
Cheia relaței = Conform Tabelului 3.2.( Sinteza posibilelor abordări pentru
transformarea modelului EA în relațional)

Grad Asocieri Cheia relatiei rezultate

Unare multi (E) - multi (E) Cheie(E) + Cheie(E)
Binare multi (E1) - multi (E2) Cheie(E1) + Cheie(E2)
Ternare unu (E1) - unu (E2) - unu (E3) Cheie(E1)+Cheie(E2) sau
Cheie(E1)+Cheie(E3) sau
Cheie(E2)+Cheie(E3) sau
unu (E1) - unu (E2) - multi (E3) Cheie(E1)+Cheie(E3) sau
Cheie(E2)+Cheie(E3) sau
unu (E1) - multi (E2) - multi Cheie(E2)+Cheie(E3)
(E3)
multi (E1) - multi (E2) - multi Cheie(E2)+Cheie(E3)+Cheie(E1)
(E3)
Cheile schemelor de relaţie rezultate din asocieri Legenda:
X + Y: Mulțimea de atribute X împreună cu mulțimea de atribute Y

Tabelul 3.2. Reguli de transformare și chei rezultate

Proiectul conceptual de nivel înalt al unei baze de date (diagrama EA, EAE, UML) poate fi
dezvoltat independent de un anumit SGBD (MySQl, SQLServer,Postgresql), utilizând diverse
instrumente software de proiectare vizuală (case tools de ex. Astah, Visual paradigm, etc.). De obicei
însă, SGBD-urile (în special cele relaţionale cum ar fi SQL Server ,MysqlWorkbench, Navicat) pun la
dispoziţie instrumente de proiectare a bazelor de date, în care se poate defini grafic modelul conceptual.
Deasemenea este necesar de remarcat faptul că în modelul relațional , cheia străină va fi plasată
în relația ce reprezintă partea mulți a asocierii.

Exemple de modele relationale : http://www.databaseanswers.org/data_models/

III. PROBLEME REZOLVATE

3.1.Descrierea sistemului informatic “Asociaţia de locatari” și modelul conceptual

(1) O asociaţie de locatari se compune din una sau mai multe scări, aflate în una sau mai multe blocuri
indentificate prin număr bloc şi număr scară. Pe fiecare scară locuiesc locatari dintre care se alege
un şef de scară. Fiecare dintre scări se compune din apartamente, având informaţii prin care se
poate face relaţia la scări, precum şi alte informaţii constând din: număr apartament, suprafaţa,
numărul cutiilor poştale, a prizelor tv., a legăturilor la coşul de fum şi altele.
(2) Locatarii sunt identificaţi printr-un număr matricol unic în toată asociaţia de locatari. Informaţiile
despre ei sunt memorate în număr bloc, scara, etaj, apartament - reprezentând adresa - şi nume.
Unii dintre locatari pot fii şefi de scară si/sau capi de familii, ceea ce implică alte informaţii în
plus pentru aceste persoane. Aceste informaţii sunt: pentru şef de scară, data intrării în funcţie iar
pentru capul de familie, numărul de persoane, numărul de persoane prezente, numărul de chei,
valoarea fondului de rulment, a fondului de reparaţii, a altor fonduri, precum şi plata curentă şi
restanţa.

9
(3) În fiecare lună se primesc facturi de la diferiţi furnizori, reprezentând cheltuielile asociaţiei de
locatari. Aceste cheltuieli sunt identificaţi unic de un număr de cheltuială şi au în componenţa
informaţiilor o informaţie prin care se face legătura cu un furnizor, tipul de cheltuială, numărul,
data şi valoarea facturii şi scadenţa. Aceste scheltuieli pot fii pe una sau mai multe scări sau pe
una sau mai multe familii.
(4) Cheltuielile se vor plăti de asociaţia de locatari prin virament, ori prin casă.
(5) Locatarii îşi plătesc datoriile la asociaţia de locatari cu bani gheaţă, primind ca dovadă a plăţii,
chitanţe. Despre plăţi se memorează o legătură la capul de familie care a efectuat plata, numărul,
data şi valoarea chitanţei.
(6) Furnizorii de la care vin facturile la asociaţia de locatari, se identifică unic printr-un cod local,
sau după codul fiscal. Pe lângă aceste informaţii mai memorăm informaţii despre denumire,
contul, banca şi adresa sediului.
(7) Calculul plăţiilor pentru locatari se va face la începutul fiecărei luni, pentru luna anterioară,
memorând data efectuării calculului, numărul matricol al capului familiei pentru relaţie, valoarea
şi restanţa pentru luna aceea. După listarea plăţilor nu se mai admit modificări.
(8) Fiecare scară este întreţinută de un personal identificat de un număr matricol (alta decât la
locatari) şi având informaţiile: legătura la scara unde lucrează, numele, data naşterii şi a angajării
şi meseria.
(9) În asociaţia de locatari pot fi mijloace fixe şi obiecte de inventar, identificate prin numărul de
inventar şi având între informaţii legătura la scara unde sunt amplasate. Se mai poate memora
despre ei denumirea, valoarea şi valoarea amortizată.

Vom crea modelul EAE pentru “Asociaţia de locatari”, folosind descrierea de mai sus.
Inițial ,identificăm tipurile de entităţi din specificaţiile de mai sus:

Scari Cheltuieli
Apartamente Achitări
Locatari Patrimoniu
Şef de scară Personal
Familii Obiecte de inventar
Plăţi Furnizori
Chitanţe

Vom identifica tipurile principale de asocieri ce sunt reprezentate de verbele din tabela de mai jos.

Entitate 1 Tip de asociere Entitate 2

Scări sunt locuite de Locatari
se compun din Apartamente
sunt întreţinute de Personal
se foloseşte Patrimoniu
Familiile trebuie să plătească Plăţi
Primesc Chitanţe
Furnizorii Provoacă Cheltuieli
Cheltuielile se calculează pentru Scări
se calculează pentru Familii
se achită prin Achitări

Determinarea cardinalităţii şi a participării în tipurile de relaţii: Considerăm asocierea

Scările sunt locuite de Locatari. O singură scară este locuită de mai mulţi locatari. Deci până acum
cardinalitatea este de 1:M, însă trebuie să verificăm şi relaţia inversă - Locatarii locuiesc pe Scări - unde

10
se observă că un locatar locuieşte pe o singură scară. Deci în final, cardinalitatea relaţiei este 1:M. În
continuare fie relaţia Cheltuielile se calculează pentru Scări.
Observăm că putem avea mai multe scări la care să se refere o cheltuială, precum şi mai multe
cheltuieli pentru o scară. Deci cardinalul relaţiei este de N:M. Să analizăm acum participarea la relaţie
a membrilor tipurilor de entităţi: Fie asocierea Scăile sunt locuite de Locatari. Putem avea cazul în care
o scară să nu fie locuită deloc de locatari. În cazul asocierii inverse nu putem avea cazul în care un
locatar să nu locuiască pe nici o scară. Deci asocierea directă este parţială, iar cea inversă este totală.

Cardinalitatea şi participarea sunt ilustrate în următorul tabel:

Participarea
Tip de entitate Tip de relaţie Tip de entitate Card.
parţială totală
Scări sunt locuite de Locatari 1:M
1:M totală totală
se compun din Apartamente
Personal 1:M partială totală
sunt întreţinute de parţială totală
Patrimoniu 1:M
se folosesc parţială parţială
Familiile Plăţi 1:M
trebuie să plătească primesc 1:M parţială parţială
Chitanţe
Furnizorii provoacă Cheltuieli 1:M parţială totală
se calculează pentru M:N totală parţială
Cheltuielile Scări
se calculează pentru M:N totală totală parţială
Familii
Cheltuielile se achită prin 1:M totală
Achitări

Se poate observa că asocierea Cheltuilile este de tipul Tip cheltuială are cardinalitatea M:1. De accea
având în vedere convenţia că asocierile se denumesc în direcţia 1:M , vom schimba numele asocierii
în Tip cheltuială este tipul unei Cheltuieli.
Vom identifica atributele entităţiilor, atribute ce descriu caracteristicile entităţilor. Aceste
atribute sunt trecute în următorul tabel:

Tip entitate Atribute Tip entitate Atribute

Scări Nr_bloc Şef de scară Nr_mat
Scara Nr_Bloc
Lift Scara
Apartamente Apartament Etaj
Nr_bloc Apartament
Scara Nume
Suprafaţa Data_intrare_func
Cutii_poştale Familii Nr_Mat
Nr_prize_tv Nr_Bloc
Locatari Nr_mat Scara
Nr_Bloc Etaj
Scara Apartament
Etaj Nume
Apartament Nr_pers
Nume Nr_pers_prezente
Plăţi Data Nr_chei

11
 Nr_mat Fond_rulment
Valoare Fond_reparaţii
Restanţă Alte_fonduri
Furnizori Cod_Furnizor Chitanţe Nr_Chit
Denumire Nr_Mat
Cod_fiscal Valoare
Cont Data
Banca Cheltuieli Nr_Crt
Strada Cod_Cheltuială
Nr Cod_Furnizor
Bl Nr_factură
Sc Data_factură
Ap Valoare_factură
Localitate Achitări Nr_crt
Judeţ Nr_Doc
Personal Nr_matricol Tip_Op
Nr_bloc Valoare_Achit
Scara Data
Nume Patrimoniu Nr_inventar
Data_naşterii Nr_bloc
Meseria Scara
Data_angajării Denumire
Inv_Fix
Valoare

Vom analiza cheile candidat al fiecărei tip de entitate şi vom alege una din ele să fie cheie
primară. De exemplu în tipul de entitate Locatari aven o cheie candidat, numit Nr_mat. Deci această
cheie va fi cheia primară. În general cheia cea mai simplă este aleasă în funcţia de cheie primară.
În tabela următoare specificăm cheile primare si alternative ale fiecărei tip de entitate:

Tip entitate Cheie primare Chei candidate

Scări Nr_bloc, Scara
Apartamente Nr_bloc, Scara
Locatari Nr_Mat
Şef de scară Nr_Mat
Familii Nr_Mat
Plăţi Data, Nr_Mat
Chitanţe Nr_Chit
Cheltuieli Nr_Crt
Furnizori Cod_Furnizor Cod_fiscal
Achitări Nr_Doc, Tip_Op
Personal Nr_matricol
Patrimoniu Nr_inventar

12
 În final putem lua decizia de a folosi specializarea/generalizarea . Dacă avem tipuri de entităţi
care au aceleaşi atribute, atunci putem generaliza aceste tipuri de entităţi. De exemplu din tabelul în
care apar atributele tipurilor de entităţi, putem observa că tipurile de entităţi Locatari, Şef de scară şi
Familii au multe atribute comune. Deci putem generaliza tipurile de entităţi Şef de scară şi Familii la
tipul de entitate Locatari.

IV. PROBLEME PROPUSE

4.1.Să se realizeze diagrama conceptuală a unui sistem de baze de date pentru o universitate.

 Baza de date trebuie să țină evidența fiecărui profesor cu id, nume și adresă.
 Fiecare profesor lucrează pentru un departament, iar fiecare departament are cel puțin un
profesor. Departamentele au un id unic și un nume.
 Cursurile sunt oferite de un singur department și au un număr unic pentru fiecare departament.
Stocați numele cursului, creditele și descrierea.
 Fiecare curs are cel puțin o secţiune. O secţiune este identificată utilizând numărul cursului
asociat, numărul secţiunii, anul și semestrul. Stocați de asemenea dimensiunea secţiunii.
 Studenţii au id-uri şi nume.
 Fiecare student are un singur instructor ca îndrumător. Studenţii se înscriu într-una sau mai
multe secțiuni. O secțiune trebuie să aibă minim cinci studenți sau să fie anulată. O secțiune
este predată de cel puțin un profesor.

4.2.Să se realizeze diagrama conceptuală a unui sistem de baze de date care stochează
următoarele informații despre depozite de produse.

 Pentru un depozit se stochează numele, care este unic, orașul în care se află și starea depozitului.
 Produsele au un număr unic, nume și preț. Stocați cantitatea (inventar) pentru fiecare produs
din fiecare depozit. Nu toate produsele sunt stocate în fiecare depozit și depozitul nu poate stoca
toate produsele.
 Un transport este identificat printr-un număr unic de expediere, având un nume de expeditor și
un contact. Un transport este completat dintr-un singur depozit.
 Fiecare expediere conține cel puțin un produs.
 Fiecare produs expediat are o cantitate. Un transport merge la un singur client în cazul în care
fiecare client este identificat prin număr, nume și adresă.

4.3.Să se realizeze diagrama conceptuală a unei baze de date necesară pentru administrarea
bănci.
 Conturile din bancă pot fi conturi private sau conturi de afaceri. Un cont privat este utilizat de
una sau mai multe persoane. O persoană poate avea mai multe conturi. Un cont de afaceri este
utilizat de o companie. Persoanele și companiile au adrese.
 Compania bancară are sucursale și bancomate. Sucursalele și bancomatele au adrese. Un ATM
este operat de o sucursală.
 Compania bancară are angajați. Angajații sunt persoane și lucrează într-o anumită sucursală.
 Tranzacțiile pot fi transferuri de bani, depozite în numerar sau retrageri de numerar.
 Transferurile de bani pot fi realizate prin Internet sau în formă scrisă la o sucursală a băncii. Se
pot face retrageri de numerar la un ATM sau de la o sucursală a băncii. Dacă sunt făcute la o
sucursală, un angajat este responsabil pentru acestea. Depunerile în numerar pot fi efectuate
numai la o sucursală, iar un angajat este responsabil pentru această tranzacție.

13
4.4.Să se realizeze diagrama conceptuală a unui sistem de baze de date pentru rezervările de
călătorii cu autocare.

 Baza de date conţine informații despre legăturile dintre autobuze. Stațiile de autobuz au nume
și sunt situate într-o țară și legate de un oraș. O legătură de autobuz conectează două stații de
autobuz.
 Distingem între legăturile directe și legăturile indirecte cu opririle intermediare la alte stații de
autobuz.
 Călătoria cu autocarul este descrisă cu o oră de plecare și sosire, tipul de autocar (inclusiv
numele și numărul maxim de pasageri) și relația cu o conexiune de autobuz.
 Fiecare călătorie cu autocarul poate fi rezervată de cel mult 25 de pasageri și fiecare pasager
poate rezerva oricâte călătorii cu autocarul.
 Ora și data rezervării și starea sa actuală (de exemplu, rezervate, plătite etc), precum și
 numele angajatului care a efectuat rezervarea trebuie să fie înregistrate.
 Pentru fiecare pasager, numele, data și locul nașterii și adresa lui compusă din codul poştal,
numărul, numele străzii și orașul trebuie înregistrate. Un pasager poate fi identificat de către
numele și data și locul nașterii sale.
 Societatea de autocare dorește să își îmbunătățească relația cu clienții și, prin urmare, îi place
să ține evidența unui grup special de călători care utilizează frecvent o rută de autobuz dedicată.
Această legătură și numărul de utilizări în medie pe săptămâna trebuie înregistrate.
 Un alt grup de călători care trebuie tratat separat sunt angajații companiei, care ar putea obține
bilete mai ieftine. Pentru ei ar trebui înregistrat numărul de cont bancar.

4.5.Să se realizeze diagrama conceptuală a unei baze de date pentru un sistem de rezervare al
unei companiei hoteliere:

 Există mai multe hoteluri în lanț. Fiecare hotel are un nume, o adresă (numă, stradă, oraș, stat,
cod poștal), o adresă web (URL) și un număr de telefon principal.
 Fiecare hotel este format dintr-un set de camere amenajate pe diferite etaje. Fiecare cameră are
un identificator unic în cadrul acelui hotel. (nume sau numar)
 Etajele sunt numerotate și fiecare cameră este pe un singur etaj.
 Pentru fiecare camera este necesar numărul de paturi, precum și să se cunoască dacă fumatul
este permis în cameră.
 Oaspeţii pot face rezervări de camere. Fiecare rezervare indică informații despre oaspeți, data
dorită de sosire și plecare, precum și preferințele acestoa (camera de fumatori/nefumatori,
numarul de paturi si situarea la un etaj inferior/superior). Aceste preferințe de cameră sunt
opționale și nu sunt incluse în fiecare rezervare. De asemenea, sunt necesare informații despre
un card de credit utilizat pentru a asigura rezervarea; cardurile de credit sunt indicate printr-un
număr de card de credit (o secvență de până la 16 cifre) și o dată de expirare (luna, an).
 În orice moment, oaspeții pot avea mai multe rezervări; Informațiile despre șederea unui
oaspete sunt stocate în istoric. Baza de date urmărește informații istorice despre șederea fiecărui
oaspete în orice cameră din orice hotel. Astfel, este necesar să știm când a început şi când s-a
încheiat șederea, în ce cameră a fost, din ce hotel a fost și cine a fost oaspetele. Pentru fiecare
oaspete care a rezervat sau a rămas într-o cameră, baza de date trebuie să stocheze numele
persoanei, adresa, adresa de e-mail și cele trei numere de telefon (acasă, serviciu, mobil).
Adresele de e-mail și numerele de telefon sunt opționale, în timp ce celelalte informații sunt
necesare.
 O factură este generată în timpul șederii oaspeților la hotel, în care se detaliază costurile
accumulate. Acestea includ tariful regulat al camerei dar și alte taxe (la restaurante, baruri,
spațiile comerciale etc)

4.6.Să se realizeze diagrama conceptuală a unei baze de date aplicabilă unui lanţ de farmacii.

 Pacienții sunt identificati prin CNP, nume , adresa și vârsta .

14
  Doctorii sunt identificați prin :CNP, nume , specialitate, vechime .
 Compania farmaceutică este identificata prin : nume , adresa, număr de telefon .
 Medicamentele sunt caracterizate de nume și cod.Fiecare medicament este comercializat de o
anumită companie, iar numele acestuia identifică în mod unic produsul în procesul de producție
al respectivei companii.
 Farmacia este caracterizată de : nume, adresa, număr de telefon
 Fiecare pacient apelează la un farmacist principal. Farmaciile comercializează medicamente.
Același medicament poate fi comercializat la diferite farmacii cu prețuri diferite.
 Fiecare medic are cel putin un pacient. Un medic poate prescrie mai multe medicamente pentru
diverși pacienti, respectiv un pacient poate obține rețete medicale de la diverși medici.Fiecare
rețetă are o dată și cantitatea din medicamentele prescrise.
 Companiile farmaceutice au contracte cu farmaciile, astfel o companie poate avea contracte cu
mai multe farmacii, respectiv o farmacie poate avea contracte cu mai multe companii
farmaceutice.Pentru fiecare astfel de contract se va retine data de început și sfârșit și textul
contractului.Dacă o companie nu mai posedă contract cu farmacia, produsele sale nu vor mai fi
comercializate.
 Farmaciile desemnează un supervizor pentru fiecare contract, ce poate fi modificat pe durata
contractului.

4.7.Să se realizeze diagrama conceptuală a unui sistem de baze de date pentru proiectele de
cercetare dintr-o universitate.
 Cadrele didactice și studenții dintr-o universitate sunt integrați în diverse proiecte de cercetare,
caracterizate de un număr de identificare, un finanțator , data de începere și de sfârșit și un
buget de cheltuieli.
 Fiecare departament este caracterizat de un număr, nume, locație și are un profesor - șef de
catedră
 Pentru cadrele didactice se va menține în baza de date codul numeric personal, numele, funcția
si specialitatea didactica.
 Studentii-absolventi sunt identificati bazat pe codul numeric personal, deasemenea li se retine
numele, varsta si programul de studii (Master sau Doctorat)
 Fiecare proiect este gestionat de un profesor (investigator principal), însa la acelasi proiect pot
coopera mai mulți profesori. Profesorii oricarui departament pot coordona/lucra la mai multe
astfel de proiecte de cercetare.
 Fiecare proiect este realizat de unul sau mai mulți studenți- absolventi ce pot lucra la mai multe
proiecte. Pentru fiecare din proiectele la care lucrează, studenții-absolvenți vor fi supravegheati
de câte un profesor .
 Profesorii pot lucra in mai multe departmente, inclusiv pentru activitatea de cercetare in cadrul
unor proiecte.
 Studenții-absolvenți lucrează într-un singur departament pentru finlizarea programului de
studii. Fiecare student –absolvent are un student-senior care îi supervizează activitatea.

4.8.Să se realizeze diagrama conceptuală a unei baze de date pentru o companie care vinde PC-
uri.
 Compania de PC-uri vinde produse ce au un ID unic, o descriere și un pret. De asemenea,
cantitatea pentru fiecare produs va trebui stocată.
 Un produs este oferit de exact un producator ce are un nume unic si posibil mai multe telefoane
de contact. Producatorul poate produce mai multe produse.
 Compania doreste sa isi utilizeze sistemul informational pentru a gestiona si informatia legata
de clienti.Un client este identificat printr-un ID are un nume si o adresa (strada, oras).
 Orice client poate achiziționa oricate produse, deasemenea același produs poate fi vândut mai
multor clienți. Pentru fiecare vânzare se va reține data și cantitatea.
 Compania doreste să facă distincție intre vânzările de sisteme de tip desktop/notebook și
componente. Deasemenea dorește să poată vinde ulterior și alte tipuri de produse.
 Pentru sistemele desktop este important factorul de disipare a căldurii (răcirea sistemului de
calcul), iar pentru notebook, greutatea.

15
  Componentele trebuie să aparțina unei categorii .
 Sistemul de baze de date va trebui sa stocheze configuratia desktopului (componentele
acestuia). Aceeasi componentă poate fi utilizabilă în mai mult de un sistem de tip desktop.
 Compania dorește să facă distincție între laptopuri pentru jocuri și laptopuri pentru bussines.
Anumite notebookuri pot fi catalogate în ambele clase, și nu există o alta categorie de laptopuri.
 Pentru laptopurile utilizate la jocuri este important de cunoscut ca parametru de calitate valoarea
3Dmax benchmark, iar pentru cele utilizate la bussines, compania doreste să stocheze numele
stațiilor docking.

4.9.Să se realizeze diagrama conceptuală a unui sistem de baze de date pentru gestiunea
clienţilor si a contractelor unei companii de telefonie mobilă.
 Orice client este identificat printr-un ID, el are un nume și posibil mai multe adrese de email.
Un client poate recomanda arbitrar mai multi clienți, însă un client poate fi recomandat de cel
mult un alt client. Data recomandării este importantă și va trebui stocată.
 Un client poate conduce mai multe contracte cu diverse companii, fiind de interes acei clienti
ce posedă cel puțin un contract. Orice contract este identificat de un ID.
 Orice contract este specific unui anumit model de telefon mobil. Un astfel de model este
identificat de ID-ul de model.
 Pentru a putea gestiona diversitatea modelelor de telefoane mobile este necesară stocarea de
informație suplimentară, astfel pentru telefoane multimedia dimensiunea ecranului, pentru
telefoane Bluetooth, furnizorul implementării stivei de protocoale Bluetooth și pentru
telefoanele mobile cu suport Windows mobile este importantă versiunea software. Astfel un
telefon mobil poate să nu posede nici una din aceste caracteristici sau poate avea mai multe
astfel de caracteristici.
 Compania este identificată de nume și un numar fiscal .
 Companiile colaboreaza cu magazinele ce sunt idenficate printr-un ID si localizate la o adresa
ce contine strada, cod postal si oras.
 Sistemul informațional trebuie să distingă între magazinele proprii ale companiei pentru care
este disponibil venitul anual și dealer în regim de discount special pentru care este necesară
stocarea zonei de vânzare. Acești dealeri pot fi utilizați ca și parteneri de vânzare pentru mai
multe companii. Pentru orice alte magazine nu este necesară stocarea de informație specială.

4.10.Să se realizeze diagrama conceptuală a unui sistem de baze de date pentru o compania de
închirieri de imobile.
 Compania oferă clădiri de diferite tipuri pentru închiriere firmelor, dar și persoanelor private.
 Clădirea este unic identificată de adresa sa (cod postal, oraș, strada), fiind stocată și suprafața
totală.
 Clădirile pot fi locuinte familiale grupate (vile multi-apartament), cladiri de birouri sau mixt.
Pot exista deasemenea alternative ce nu vor necesita a fi tratate distinct.
 In fiecare clădire de locuințe familiale pot exista maxim 20 apartamente , fiecare apartament
poate fi identificat printr-un ID. Pentru fiecare apartament se va stoca numărul de camere.
 Un apartament este închiriat de exact o persoană ce posedă un nume și posibil mai multe
telefoane de contact. Se presupune că o persoană privată va închiria un singur apartament.
 Este important pentru companie sa retina numarul de locuri de parcare pentru fiecare cladire de
birouri.
 Clădirea de birouri poate conține pana la max 50 birouri , fiecare cu propriul ID și conexiune
la Internet.
 Birourile sunt închiriate de firme, identificate printr-un nume și un număr fiscal. Birourile pot
fi închiriate de mai mult de o companie și deasemenea o companie poate închiria mai mult de
un birou.
 Firmele și persoanele private sunt singurii potențiali închiriatori, ce sunt identificabili printr-un
ID. Complementar, este reținută data de când închiriatorul a devenit client al companiei.
 Pentru fiecare firmă, chiria trebuie platită per birou si stocată în consecință în mod individual.
Aceeasi metodă este practicată si pentru persoanele private, însă per apartament.

16
4.11.Să se realizeze diagrama EER a unui sistem de baze de date pentru un hotel, in
administrarea propriilor camere.
 Hotelul are mai multe camere. Orice cameră are un număr de identificare un număr maxim de
oaspeți și un pret fix pe zi.
 Orice cameră este identificabila printr-un număr propriu de identificare.
 Pentru fiecare cameră se pot face rezervări. Fiecare rezervare are o dată de început și o dată de
sfârsit și specifică numărul de persone pentru care este rezervată camera.
 Două rezervări pentru aceeași cameră nu pot avea suprapunere de perioadă., astfel pentru o
anumită cameră și o dată de început poate exista o singură rezervare.
 Pentru fiecare rezervare se va alege un anumit serviciu.
 Fiecare serviciu este de un anumit tip (cu sau fără mic dejun, demipensiune sau complet).
Fiecare seviciu are un preț per persoana.
 Clienții au un ID un nume și o adresa.
 Fiecare rezervare este efectuată de un oaspete utilizând numărul cărții de credit a celui ce va
ocupa camera.

4.12.Să se realizeze diagrama EER a unui sistem de baze de date care stochează următoarele
informații despre o asociaţie de locatari:

 Aceasta se compune din una sau mai multe scări, aflate în una sau mai multe blocuri identificate
prin număr bloc şi număr scară.
 Pe fiecare scară locuiesc locatari dintre care se alege un şef de scară. Fiecare dintre scări se
compune din apartamente, având informaţii prin care se poate face relaţia la scări, precum şi
alte informaţii constând din: număr apartament, suprafaţa, numărul cutiilor poştale, a prizelor
tv., a legăturilor la coşul de fum şi altele.
 Locatarii sunt identificaţi printr-un număr matricol unic în toată asociaţia de locatari.
Informaţiile despre ei sunt memorate în număr bloc, scara, etaj, apartament - reprezentând
adresa - şi nume. Unii dintre locatari pot fi şefi de scară si/sau capi de familii, ceea ce implică
alte informaţii în plus pentru aceste persoane. Aceste informaţii sunt: pentru şef de scară, data
intrării în funcţie iar pentru capul de familie, numărul de persoane, numărul de persoane
prezente, numărul de chei, valoarea fondului de rulment, a fondului de reparaţii, a altor fonduri,
precum şi plata curentă şi restanţa.
 În fiecare lună se primesc facturi de la diferiţi furnizori, reprezentând cheltuielile asociaţiei de
locatari. Aceste cheltuieli sunt identificaţi unic de un număr de cheltuială şi au în componenţa
informaţiilor o informaţie prin care se face legătura cu un furnizor, tipul de cheltuială, numărul,
data şi valoarea facturii şi scadenţa. Aceste cheltuieli pot fi pe una sau mai multe scări sau pe
una sau mai multe familii.
 Cheltuielile se vor plăti de asociaţia de locatari ori prin virament, ori prin casă.
 Locatarii îşi plătesc datoriile la asociaţia de locatari cu bani gheaţă, primind ca dovadă a plăţii,
chitanţe. Despre plăţi se memorează o legătură la capul de familie care a efectuat plata,
numărul, data şi valoarea chitanţei.
Furnizorii de la care vin facturile la asociaţia de locatari, se identifică unic printr-un cod
local, sau după codul fiscal. Pe lângă aceste informaţii mai memorăm informaţii despre
denumire, contul, banca şi adresa sediului.
 Fiecare scară este întreţinută de un personal identificat de un număr matricol (alta decât la
locatari) şi având informaţiile: legătura la scara unde lucrează, numele, data naşterii şi a
angajării şi meseria.
 În asociaţia de locatari pot fi mijloace fixe şi obiecte de inventar, identificate prin numărulde
inventar şi având între informaţii legătura la scara unde sunt amplasate. Se mai poate memora
despre ei denumirea, valoarea şi valoarea amortizată

17
4.13.Să se realizeze diagrama EER a unui sistem de baze de date pentru rezervările de călătorii
cu autocare.
Baza de date conţine informații despre legăturile dintre autobuze. Stațiile de autobuz au nume
și sunt situate într-o țară și legate de un oraș. O legătură de autobuz conectează două stații de
autobuz.
 Distingem între legăturile directe și legăturile indirecte cu opririle intermediare la alte stații de
autobuz.
 Călătoria cu autocarul este descrisă cu o oră de plecare și sosire, tipul de autocar (inclusiv
numele și numărul maxim de pasageri) și relația cu o conexiune de autobuz.
 Fiecare călătorie cu autocarul poate fi rezervată de cel mult 25 de pasageri și fiecare pasager
poate rezerva oricâte călătorii cu autocarul.
 Ora și data rezervării și starea sa actuală (de exemplu, rezervate, plătite etc), precum și
numele angajatului care a efectuat rezervarea trebuie să fie înregistrate.
 Pentru fiecare pasager, numele, data și locul nașterii și adresa lui compusă din codul poştal,
numărul, numele străzii și orașul trebuie înregistrate. Un pasager poate fi identificat de către
numele și data și locul nașterii sale.
 Societatea de autocare dorește să își îmbunătățească relația cu clienții și, prin urmare, îi place
să ține evidența unui grup special de călători care utilizează frecvent o rută de autobuz dedicată.
Această legătură și numărul de utilizări în medie pe săptămâna trebuie înregistrate.
 Un alt grup de călători care trebuie tratat separat sunt angajații companiei, care ar putea obține
bilete mai ieftine. Pentru ei ar trebui înregistrat numărul de cont bancar.

4.14.Firma VideoShop ofera spre imprumut clientilor casete VHS si DVD, conform cerințelor:
• Fiecare suport de stocare media este identificat unic printr-un cod , o categorie de pret si locatia
sa in magazin, clasele media sunt VHS si DVD si pentru casete video este importanta calitatea
, iar pentru DVD codul de regiune.
• Pentru a oferi informatii clientilor, fiecare media are asociata informatie minima despre film.Pe
un astfel de suport de stocare este inregistrat un singur film , insa acesta poate exista atat pe
caseta cat si pe DVD.
• Un film este definit unic de un identificator , are un titlu si se vor stoca numele actorilor
principali.Un astfel de suport media poate fi imprumutat de catre un client , pentru fiecare
imprumut se va stoca data de inceput si sfarsit.
• Clientul este identificat de un ID, numele si adresa sa (oras, strada, cod postal), iar pentru a
putea realiza rezervari prin Internet se va utiliza cardul de credit
• Un client poate realiza mai multe imprumuturi, fara a fi necesara inregistrarea unui istoric al
imprumuturilor .
Modificati proiectul anterior astfel încât să fie posibilă verificarea în baza de date a unui istoric al
împrumuturilor, cât și înregistrarea împrumuturilor utilizand un contract caracterizat de data de
început, data de sfârșit , respectiv cod de identificare.

4.15.Realizați modelul relațional pentru schemele conceptuale EA1 și EA2 de mai jos,în care
denumirile entităților și atributelor sunt abstractizate.Argumentați soluția propusă în ceea ce
privește alegerea cheilor primare și definirea cheilor străine și creați câte un script SQL (DML)
echivalent modelului propus.

Exemple de diverse modele de baze de date și echivalentul logic în script SQL pot fi consultate la adresa :
http://www.ntu.edu.sg/home/ehchua/programming/sql/SampleDatabases.html

18
Figura 3.7. Diagrama EA2

Figura 3.6. Diagrama EA1

19
Figura 3.7. Diagrama EA2

20
Cod SQL
CREATE DATABASE dbImo;
USE dbImo;

CREATE TABLE Manager (

staffNo int PRIMARY KEY);

CREATE TABLE Branch (

branchNo int PRIMARY KEY,
mgrStaffNo int UNIQUE NOT NULL);

CREATE TABLE Staff (

staffNo int PRIMARY KEY,
supervisorStaffNo int,
branchNo int NOT NULL,
CONSTRAINT FK_supervisorStaffNo_staff FOREIGN KEY (supervisorStaffNo) REFERENCES Staff (staffNo));

ALTER TABLE Manager ADD CONSTRAINT FK_staffNo_manager FOREIGN KEY (staffNo) REFERENCES Staff (staffNo);
ALTER TABLE Branch ADD CONSTRAINT FK_mgrStaffNo_branch FOREIGN KEY (mgrStaffNo) REFERENCES Manager (staffNo);
ALTER TABLE Staff ADD CONSTRAINT FK_branchNo_staff FOREIGN KEY (branchNo) REFERENCES Branch (branchNo);

CREATE TABLE PrivateOwner (

ownerNo int PRIMARY KEY);

CREATE TABLE BusinessOwner (

ownerNo int PRIMARY KEY);

CREATE TABLE PropertyForRent (

propertyNo int PRIMARY KEY,
ownerNo int NOT NULL,
staffNo int,
branchNo int NOT NULL,
CONSTRAINT FK_staffNo_PropertyForRent FOREIGN KEY (staffNo) REFERENCES Staff (staffNo),
CONSTRAINT FK_branchNo_PropertyForRent FOREIGN KEY (branchNo) REFERENCES Branch (branchNo),
CONSTRAINT FK_privateOwner_PropertyForRent FOREIGN KEY (ownerNo) REFERENCES PrivateOwner (ownerNo),
CONSTRAINT FK_businessOwner_PropertyForRent FOREIGN KEY (ownerNo) REFERENCES BusinessOwner (ownerNo));

CREATE TABLE Newspaper (

newspaperName varchar(255) PRIMARY KEY);

CREATE TABLE Advert (

propertyNo int,
newspaperName varchar(255),
dateAdvert date,
PRIMARY KEY (propertyNo, newspaperName, dateAdvert),
CONSTRAINT FK_newspaperName_advert FOREIGN KEY (newspaperName) REFERENCES Newspaper (newspaperName),
CONSTRAINT FK_propertyNo_advert FOREIGN KEY (propertyNo) REFERENCES PropertyForRent (propertyNo));

CREATE TABLE Clientul (

clientNo int PRIMARY KEY);

CREATE TABLE Lease (

leaseNo int PRIMARY KEY,
clientNo int,
propertyNo int,
CONSTRAINT FK_clientNo_lease FOREIGN KEY (clientNo) REFERENCES Clientul (clientNo),
CONSTRAINT FK_propertyNo_lease FOREIGN KEY (propertyNo) REFERENCES PropertyForRent (propertyNo));
CREATE TABLE Viewing (
clientNo int,
propertyNo int,
PRIMARY KEY (clientNo, propertyNo),
CONSTRAINT FK_clientNo_viewing FOREIGN KEY (clientNo) REFERENCES Clientul (clientNo),
CONSTRAINT FK_propertyNo_viewing FOREIGN KEY (propertyNo) REFERENCES PropertyForRent (propertyNo));

CREATE TABLE Registration (

clientNo int PRIMARY KEY,
branchNo int NOT NULL,
staffNo int,
CONSTRAINT FK_clientNo_registration FOREIGN KEY (clientNo) REFERENCES Clientul (clientNo),
CONSTRAINT FK_branchNo_Registration FOREIGN KEY (branchNo) REFERENCES Branch (branchNo),
CONSTRAINT FK_staffNo_Registration FOREIGN KEY (staffNo) REFERENCES Staff (staffNo));

CREATE TABLE Telephone (

telNo varchar(11) PRIMARY KEY,
branchNo int NOT NULL,
CONSTRAINT FK_branchNo_Telephone FOREIGN KEY (branchNo) REFERENCES Branch (branchNo));
Ovsees
name address relation name address phone number
phone number
ID insurance number
CONTACT REGISTRANT

N
d

CONTACT OF certification date

number of players
1
name
1 N
N TEAM COACHES COACH
M
MEMBER OF
2
age PLAYER
N
PLAYS IN
PLAYS
M
N N 1
REFEREES

MATCH SPORT
MASCOT

name locations
number location datetime number of referees
nickname
REGISTRANT
ID name phone number address insurance number

PLAYER
ID age is mascot mascot nickname

SPORT
name number of referees

TEAM
name sport

MATCH
number location date time

CONTACT
player ID name relation phone number address

COACH
ID team name certification date

REFEREES
player ID match number

MEMBER OF
player ID team name

PLAYS IN
team name match number

LOCATION
sport sport location