SUPORT PENTRU ACTIVITATI DE CURS

Prof. univ. dr. Alexandru Manole

amanole@artifex.org.ro
 Evaluare
1 punct oficiu.
2 subiecte teorie a 1,5 puncte.
1 subiect aplicativ, șase puncte. Cerințele pentru acest
subiect au în vedere reprezentarea datelor în cadrul
modelelor conceptual și logic.
Bonus pentru activitatea individuală: conform fișei
disciplinei, maximum 50% din nota finală, în funcție de
rezultatul obținut de fiecare student la:
Testarea continuă pe parcursul semestrului: maximum
20%;
Participarea activă la seminar şi realizarea de activităţi
gen teme / referate: maximum 30%.
 REFERAT
Studenții vor prezenta un referat, care va trata problema reprezentării datelor
conform unor cerințe (tema este la alegere) și va avea următoarea structură:
Descrierea cerințelor.
Modelul conceptual al datelor de tip Entitate-Atribut-Corespondență.
Modelul logic al datelor de tip relațional.
Tema referatului și descrierea cerințelor sunt la alegerea studentului. Se poate
aborda orice instituție/firmă/organizație al cărei exemplu îl considerați potrivit. Nu
trebuie să precizați denumirea acelei instituții, este suficient să includeți în cerințe
tipul activității pentru care reprezentați datele, de asemenea nu este obligatoriu ca
referatul dumneavoastră să acopere întreaga activitate a organizației selectate.
Cerința minimă este să abordați un exemplu care să includă date despre persoane
fizice/juridice, documente și bunuri care intervin în acea activitate. Pornind de aici,
schema externă - descrierea cerințelor pe care o propuneți prin referat poate fi oricât
de complexă.
Ca exemplu pentru referat: aplicațiile rezolvate din suportul de curs.
 REFERAT
Modelul conceptual: pe lângă modelul propriu-zis, reprezentat grafic conform
regulilor descrise în suportul de curs (cerința minimală), vor fi apreciate scurte
explicații pentru deciziile pe care le-ați luat vis-a-vis de entități, asocieri, atribute și
cardinalități, dar nu este necesar să reiterați observațiile din suportul de curs,
eventual puteți descrie interpretarea observațiilor în diverse situații prezentate în
cerințe.
Modelul logic. Cerința minimală: prezentarea modelului utilizând notația din
materialul de curs.
Referatul se transmite pe adresa de email amanole@artifex.org.ro
Termen: ziua anterioară examenului, ora 24.00.
 Precizări
Sistemul de gestiune a bazelor de date suport utilizat pentru aplicațiile prezentate la
curs și laborator este MicrosoftTM Access® versiunea 2019.
MicrosoftTM Windows®, MicrosoftTM Access® și Microsoft TM SQL Server ®
sunt mărci înregistrate ale Microsoft Corporation.
IBM® și DB2® sunt mărci înregistrate ale International Business Machines
Corporation.
Oracle® și MySQL® sunt mărci înregistrate ale Oracle.
Capturile de ecran sunt preluate cu permisiunea Microsoft TM.
Aplicațiile propuse sunt construite în scop didactic.
 Structura cursului
Conceptul de bază de date. Noţiuni fundamentale
privind bazele de date.

Sisteme de gestiune a bazelor de date. Obiectivele

fundamentale ale unei baze de date.

Modelarea/reprezentarea datelor. Nivelul extern.

Nivelul conceptual. Modelul Entitate-Atribut-

Corespondență.

Nivelul logic (modelul relaţional).

Cereri de interogare.
 TEMA 1.
Conceptul de bază de date. Noţiuni
fundamentale privind bazele de date

1.1. Date, informații, cunoștințe.

1.2. Baze de date, fișiere de date.
1.3. Funcțiuni ale bazei de date.
Noţiuni fundamentale privind bazele de date
1.1. Date, informații, cunoștințe (Năstase și colectiv, 2000;
Muntean, Danaiata și Margea, 2001)
Datele constituie forma cea mai simplă de reprezentare a realității și nu au o
semnificație aparte. Ele se reprezintă sub formă de identificatori (ce anume
descriu datele respective), atribute (caracteristici ale datelor) și valori
(realizări concrete ale datelor pentru aspecte concrete ale realității).
Informațiile rezultă din prelucrarea datelor, au caracter de noutate și o
semnificație specifică pentru beneficiari. Distincția dintre date și informații
se bazează pe noutatea și utilitatea lor.
Cunoștințele sunt informații complexe cu caracter fundamental despre un
anumit domeniu de activitate. Cunoștințele permit individului să înțeleagă
informațiile și să le utilizeze în mod corespunzător.
Năstase, P., Mihai, Fl., Cosăcescu, L., Covrig, L., Stanciu, A. (2000). Tehnologia
bazelor de date. Access 2000. Editura Economică, București.
Muntean, M., Danaiata, D., Margea, C. (2001). Managementul cunostintelor în
societatea bazata pe cunoastere. Revista Informatica Economica, nr. 2 (18)/2001, pp.
13 – 22. http://revistaie.ase.ro/content/18/danaiata.pdf
Noţiuni fundamentale privind bazele de date
Exemplu de date, informații, cunoștințe: determinarea și
interpretarea profitului.
Venituri – Cheltuieli = Profit
25.000 – 15.000 = 10.000
Profitul este pozitiv, ceea ce indică o poziție favorabilă a entității
economice respective.
Date: Numărul 25.000
Informații: 25.000 reprezintă venitul.
Cunoștințe: ce reprezintă venitul? Este un indicator „bun”?
Noţiuni fundamentale privind bazele de date
1.2. Baze de date, fișiere de date

O bază de date reprezintă o colecție de date structurată

conform unui anumit principiu (model), dedicată stocării
datelor referitoare la o anumită activitate și accesibilă de către
utilizatori.
Oancea și Crețan (2013) definesc baza de date astfel: „O
colecție de date aflate în interdependență care reflectă un
anumit aspect al realității și este destinată unui anumit grup de
utilizatori împreună cu descrierea structurii lor și relațiilor
dintre ele, formează o bază de date.”

Oancea, B., Crețan, A. (2013). Baze de date. Editura Pro Universitaria, București,
p. 15.
Noţiuni fundamentale privind bazele de date
Caracteristici ale bazei de date:
O colecție de date interdependente;
Este utilizată pentru reprezentarea informatizată a unui anumit
aspect al realității (o activitate economică, socială etc., desfășurată
de un agent, indiferent de gradul de complexitate al acestuia, de
forma de proprietate sau de alte caracteristici similare, de la
individ, care poate utiliza o bază de date pentru necesități
personale, până la o organizație multinațională, care poate
întreține și exploata o bază de date pentru întreaga sa activitate,
chiar pe parcursul mai multor perioade de timp);
Destinată unui grup de utilizatori: baza de date fără utilizatori nu
are nici o finalitate practică. În plus, o bază de date ale cărei
funcționalități nu sunt acceptate/agreate de utilizatorii săi nu poate
fi caracterizată ca un succes.
Noţiuni fundamentale privind bazele de date
Istoric, ca forme de reprezentare a datelor, bazele de date au
fost precedate de fișiere de date și fișiere de date cu legături
între ele (Năstase și colectiv, 2000): agregări de date cu o
anumită structură, destinate unor prelucrări simple asupra
datelor.
Unitatea de prelucrare a datelor este înregistrarea: include
datele unui anume obiect din mulțimea de obiecte reprezentate
în fișierul de date.
Exemplu: reprezentarea datelor despre facturi. Un fișier de date
poate conține date despre un număr virtual nelimitat de facturi,
dar o înregistrare include datele unei singure facturi.
În cadrul fișierelor de date, componentele structurii de date
sunt delimitate între ele prin separatori (atribute și înregistrări).
Noţiuni fundamentale privind bazele de date
În conformitate cu Hogan (2018), o bază de date își regăsește
aplicabilitatea „pe măsură ce crește complexitatea,
dimensiunea și importanța datelor”:
Trecerea de la gestionarea datelor prin fișiere/fișiere cu legături la
gestionarea prin baze de date se impune atunci când cei trei
parametri ajung la un anumit nivel, la care menținerea fișierelor
de date poate conduce la consecințe negative pentru proprietarul
datelor, consecințe din rândul cărora subliniem erori în ceea ce
privește corectitudinea datelor față de realitatea la care se referă și
probleme la nivel de redundanță, aspecte care sunt valabile și
pentru fișierele gestionate prin aplicații de calcul tabelar, deși
aceste aplicații includ o serie de instrumente dedicate integrității
datelor.
Hogan, R. (2018). A Practical Guide to Database Design (Second edition). CRC
Press, Taylor & Francis Group.
Noţiuni fundamentale privind bazele de date
1.3. Funcțiunile bazei de date
La nivelul unei organizații, o bază de date poate îndeplini una
sau mai multe dintre următoarele funcțiuni (Conger, 2012):
Procesarea online a tranzacțiilor – OLTP. Această funcțiune necesită
viteză de procesare a datelor, eficiență și asigurarea funcționării în
permanență, mai ales dacă avem în vedere dezvoltarea comerțului
electronic și răspândirea rețelei Internet.
Sistem Informatic pentru Management (MIS): acest tip de aplicație este
dedicat furnizării de informații de sinteză pentru managerii organizației.
Această funcțiune este orientată spre interogarea datelor în vederea
procesării și analizei.
Business intelligence și data mining: utilizează tehnici avansate de
analiză a datelor pentru identificarea de trenduri și șabloane. În acest
caz, vorbim deja de un depozit de date, o bază de date cu caracteristici
speciale, destinată acestei funcțiuni.
Conger, S. (2012). Hands-on Database. An Introduction to Database Design and
Development. Prentice Hall.
Noţiuni fundamentale privind bazele de date
Pachet pedagogic – tema 1
Cuvinte - cheie
Date.
Informații.
Cunoștințe.
Bază de date.
Fișier.
Înregistrare.
Procesarea online a tranzacțiilor – OLTP.
Sistem Informatic pentru Management (MIS).
Business intelligence și data mining.
Noţiuni fundamentale privind bazele de date
Întrebări
Ce sunt datele?
Cum deosebim informațiile de date?
Ce sunt cunoștințele?
Definiți baza de date.
Evidențiați caracteristicile bazei de date.
Explicați cauzele care determină trecerea de la fișier de date la baza de
date.
Care sunt funcțiunile bazei de date?
 TEMA 2.
Sistemul de gestiune a bazelor de date

2.1. Definiție.
2.2. Caracteristici.
2.3. Funcțiile SGBD.
2.4. Obiectivele fundamentale ale unei baze de date.
 Sistemul de Gestiune a Bazelor de Date
2.1. Definiție
Baza de date se regăsește, la nivelul memoriei externe, sub forma
unui fișier sau ca o colecție de fișiere.
O bază de date MicrosoftTM Access®, în memoria externă, se
prezintă sub forma unui singur fișier, care include atât baza de
date propriu-zisă, precum și interfețele grafice pentru actualizarea
și consultarea datelor, dar și alte instrumente.
Utilizatorul interacționează cu baza de date prin intermediul unei
aplicații speciale, denumită Sistem de Gestiune a Bazelor de Date
– SGBD, care este instalat și rulează sub controlul sistemului de
operare instalat pe calculatorul utilizatorului. Hogan (2018)
definește astfel SGBD-ul: „un pachet software special care este
proiectat pentru a defini și gestiona datele în cadrul uneia sau
mai multor baze de date”.
Exemple de SGBD: MicrosoftTM Access®, MicrosoftTM SQL Server®,
Oracle®, IBM DB2®, MySQL® etc.
 Sistemul de Gestiune a Bazelor de Date
2.2. Caracteristici
Utilizatorul accesează baza de date prin intermediul unui
program (o interfață / colecție de interfețe) și transmite o
cerere. Programul poate fi construit cu instrumentele proprii
SGBD (cazul Microsoft TM Access®, de exemplu) sau cu
ajutorul unor alte instrumente/medii de dezvoltare.
Programul transmite cererea utilizatorului către SGBD.
SGBD recepționează cererea, o „traduce” în formatul său
propriu și generează mai departe cereri, către sistemul de
operare, pentru regăsirea datelor din fișierul (fișierele) bazei de
date aflate pe suport de memorie externă.
Datele extrase se întorc la utilizator parcurgând traseul invers.
Pentru scrierea datelor, se aplică același algoritm, cu precizarea
că solicitarea utilizatorului vizează salvarea unor date.
 Sistemul de Gestiune a Bazelor de Date

• Diagrama descrie mediul de lucru al utilizatorilor care exploatează

baza de date.
• Pentru diferiți utilizatori pot exista programe distincte (componenta
client), dar baza de date, SGBD și sistemul de operare care le
gestionează (componenta server) sunt unice, commune, „partajate” de
utilizatori prin programele de aplicații individuale.
Sistemul de Gestiune a Bazelor de Date

Program 1
(CLIENT)

Program 2 Sistem de Baza de date

SGBD
(CLIENT) operare (SERVER)
(SERVER)
(SERVER)

Program n
(CLIENT)

Exemplu Arhitectură client-server

 Sistemul de Gestiune a Bazelor de Date
2.3. Funcțiile SGBD.
Funcțiile principale ale unui Sistem de Gestiune a Bazelor de
Date sunt:
Asigurarea efectuării operațiunilor de citire și scriere solicitate
de utilizatori, respectiv de consultare a bazei de date (citire) și
actualizare a datelor (scriere);
Descrierea datelor – definirea datelor și a legăturilor între
acestea (finalitate, schema bazei de date);
Asigurarea instrumentelor pentru implementarea cerințelor
stabilite de obiectivele fundamentale ale bazei de date,
prezentate în continuare.
Obiectivele fundamentale ale BD
2.4. Obiectivele fundamentale ale unei baze de date.
Obiectivele unei baze de date derivă din utilitatea și performanța
așteptată a bazei de date (Năstase și colectiv, 2000).
Independența datelor și față de programele prin care utilizatorii
accesează datele. Modificările operate asupra datelor nu
afectează aceste aplicații;
Realizarea de legături între structurile de date componente ale
bazei de date. Indiferent de modelul de date adoptat, este
necesar a se stabili legături coerente între aceste structuri,
pentru a reflecta corelațiile dintre obiectele reale ale căror date
le reprezintă;
Integritatea datelor. Acest obiectiv reprezintă încrederea
utilizatorilor în faptul că datele corespund întru totul realității
pentru care a fost construită baza de date.
Obiectivele fundamentale ale BD
Întrucât integritatea absolută nu poate fi realizată (indiferent de
criteriile de validare a datelor, erori, de tastare de exemplu, sunt
posibile, rezultând valori ale datelor care respectă criteriile de
validare, dar nu sunt corecte, evidențiem cazul adăugării sau
eliminării involuntare a unei cifre, sau inversarea a două litere
introduse „în grabă” în cadrul unui cuvânt, mai ales dacă eroarea
nu este evidentă – ambele cuvinte sunt corecte în limba
utilizatorului), baza de date trebuie să dispună de mecanisme
precum:
Tip de date, care permite introducerea numai a valorilor
corespunzătoare tipului respectiv. Există tipuri de date pentru:
șiruri de caractere;
valori numerice;
date calendaristice;
valori logice;
sume monetare;
obiecte de mari dimensiuni (ca spațiu de memorie ocupat), hyperlink etc.
Obiectivele fundamentale ale BD
Un tip de date mai permite și prelucrarea unitară a valorilor unui
atribut asociat cu el prin intermediul unor proceduri de calcul
specifice. Totuși, tipul de date nu asigură o „protecție absolută”
față de erori. Spre exemplu, tipurile de date „șir de caractere”
acceptă valori numerice, în timp ce tipurile „numerice” nu permit
salvarea unor valori care includ alte caractere, cum ar fi literele.
Validarea datelor față de o listă de valori predefinită. Atunci
când valorile posibile sunt limitate la o listă cunoscută,
implementarea acestei validări contribuie la asigurarea
integrității datelor.
Un exemplu de aplicabilitate a validării față de listă. O
organizație are parteneri din toate județele României.
O eroare de tastare în acest caz, de tipul București vs. Bucuerști, conduce
la omiterea înregistrărilor referitoare la acel partener atunci când se
consultă datele partenerilor din București.
Obiectivele fundamentale ale BD
Restricțiile tip interval interzic încărcarea unor date ale
căror valori sunt eronate, în afara intervalului acceptat.
Respectarea restricțiilor de integritate a datelor previne
erorile asociate datelor de intrare, care se vor regăsi, într-o
formă sau alta, în structura datelor de ieșire.
Restricțiile de integritate referențiale au în vedere
corelarea corectă a datelor între care există anumite
legături logice.
De exemplu, asocierea documentelor cu persoanele care
interacționează cu acele documente. Este obligatorie
precizarea corectă a datelor care permit asocierea.
Obiectivele fundamentale ale BD
Securitatea datelor presupune protejarea datelor față de
evenimente care afectează echipamentele (hard) sau
aplicațiile (soft). Ex.: defectarea mediilor de stocare,
întreruperea funcționării rețelei într-o aplicație distribuită,
un modul software care rezolvă o problemă, dar cu
„pierderi colaterale” etc.
Instrumentele dedicate asigurării acestui obiectiv se referă
la:
Copie de siguranță: o copie simplă a bazei de date, într-o
stare funcțională, neafectată de erori;
Jurnal de tranzacții: fișier de date care memorează
operațiunile efectuate începând de la crearea unei copii
asociate.
Se pot valorifica și instrumente nespecifice SGBD: RAID.
Obiectivele fundamentale ale BD
RAID: Redundant Array of Inexpensive Disks. Se poate
implementa fie la nivel logic, fie la nivel fizic (controller-e
dedicate).
Permite crearea, așa cum îi spune și numele, a unei matrici
(combinații) de hard-disk-uri și aplicarea unuia dintre
standardele RAID, dedicat prevenirii pierderii de date
cauzate de defecțiuni asociate unui hard-disk.
RAID 1: „mirroring”, asigură scrierea datelor, simultan, pe
mai multe hard-disk-uri sau mai multe partiții ale unui disc.
Astfel, conținutul bazei de date este multiplicat pe toate
dispozitivele HDD din matricea RAID.
RAID 10: „mirroring” + RAID 0 (striping: datele sunt
„împărțite” pe mai multe discuri, dar nu oferă protecție în
caz de defecțiune, fiind orientat spre performanță). RAID 10
combină avantajele RAID 0 și RAID 1.
Obiectivele fundamentale ale BD
RAID 0

P1 P2

P3 P4

P5 P6

P7 P8

P9 P10

RAID 0: performanță ridicată, risc ridicat de pierdere a datelor.

Obiectivele fundamentale ale BD
RAID 1

P1 P1

P2 P2

P3 P3

P4 P4

P5 P5

RAID 1: - performanță mai redusă;

- spațiu de stocare diminuat la jumătate;
- risc minim de pierdere a datelor.
Obiectivele fundamentale ale BD
RAID 10

P1 P2 P1 P2
P3 P4 P3 P4
P5 P6 P5 P6
P7 P8 P7 P8

P9 P10 P9 P10

RAID 10: - performanță ridicată;

- minimum patru discuri;
- risc minim de pierdere a datelor.
 Obiectivele fundamentale ale BD
RAID 5

P11 P12 P13

P21 P22 P23

P31 P32 P33

S2 S3 S1
P9
RAID 5: - segmentele S au rol de backup;
- performanță ridicată;
- minimum trei discuri;
- risc minim de pierdere a datelor pentru un HDD defect.
Obiectivele fundamentale ale BD
Tehnologiile de tip Failover / cluster asigură menținerea
în funcțiune a sistemului informatic atunci când unul
dintre serverele incluse în cluster devine indisponibil, din
multiple cauze.
Distribuirea geografică a componentelor cluster-ului va
ține cont de:
analiza riscurilor de eveniment fizic și logic asociate fiecărei
locații considerate;
timpul admis de întrerupere a funcționării sistemului
informatic;
calitatea/performanțele resurselor de comunicație între
componentele cluster-ului.
Obiectivele fundamentale ale BD
Confidențialitatea datelor presupune protejarea bazei de
date față de evenimente generate de accesarea neautorizată
și potențial răuvoitoare a datelor.
Instrumentele dedicate confidențialității:
Contul de utilizator: permite identificarea utilizatorului în
sistem;
Parola de acces: împreună cu numele de cont, asigură
autentificarea utilizatorului identificat prin cont;
Drepturile de acces: permit unui utilizator să efectueze o
anumită operație asupra unui obiect din baza de date.
Mulțimea seturilor user-drept-obiect constituie drepturile de
acces ale user-ilor la baza de date.
Obiectivele fundamentale ale BD
Conturile de utilizator sunt definite în sistem și formează o
listă de verificare – nu se pot acorda drepturi unui cont
inexistent.
Segmentele din baza de date pentru care se pot acorda
drepturi sunt recunoscute automat de S.G.B.D., fiind
create și gestionate sub controlul său – verificare de tip
listă.
Drepturile de acces sunt specifice S.G.B.D. și formează o
listă predefinită. Exemple:
Drept de citire: utilizatorul poate consulta date;
Drept de inserare: utilizatorul poate adăuga date;
Drept de modificare;
Drept de ștergere etc.
Obiectivele fundamentale ale BD
Utilizarea unei baze de date, funcțiunea MIS

Actualizare
date (1) Consultare
(1)

Actualizare BAZA
date (2) DE DATE Prelucrare (1)

Actualizare Prelucrare (1)

date (n)

Date de intrare Date de ieșire

 Sistemul de Gestiune a Bazelor de Date
Pachet pedagogic – tema 2
Cuvinte - cheie
Sistem de gestiune a bazelor de date.
Integritate.
Confidențialitate.
Securitate.
Program.
Tip de date.
Validare.
Drept de acces.
Jurnal de tranzacții.
Copie de siguranță.
Legături.
 Sistemul de Gestiune a Bazelor de Date
Întrebări

Care sunt funcțiile unui S.G.B.D.?

Ce instrumente se pot aplica pentru asigurarea securității datelor?
Definiți obiectivul de confidențialitate a datelor.
Ce presupune independența dintre date și prelucrări?
Descrieți modul de utilizare al celor trei instrumente propuse pentru
asigurarea confidențialității datelor.
Explicați cele trei instrumente care contribuie la integritatea datelor.
 TEMA 3.
Metodologia construirii unei baze de date
– modelarea/reprezentarea datelor.
Nivelul conceptual. Modelul Entitate-
Atribut-Corespondență
3.1. Reprezentarea datelor în baza de date.
3.2. Nivelul extern – colectarea informațiilor.
3.3. Nivelul conceptual-definiție. Modelul EAC.
Instrumentele modelului EAC.
3.4. Elaborarea modelului EAC. Aplicații.
 Reprezentarea datelor
3.1. Reprezentarea datelor în baza de date
Reprezentarea datelor implică trei niveluri (Năstase și colectiv,
2000):
Nivelul extern. Datele sunt prezentate la nivelul utilizatorului
final, simbolul 1 în slide-ul 45: descrieri, documente utilizate în
activitatea sa, proceduri etc. Acest nivel evidențiază cerințele
formulate pentru baza de date.
Nivelul conceptual (administratorul bazei de date, simbolul 2 în
slide-ul 45) presupune reprezentarea structurii bazei de date
conform unui model conceptual, acceptat de actorii implicați
(informaticieni și beneficiari). Modelul conceptual este apoi
transformat într-un model logic, care poate fi implementat într-un
SGBD (modelul logic va fi compatibil cu SGBD ales).
Nivelul fizic – utilizatorii avansați (simbolul 3 în slide-ul 45).
Unul sau mai multe fișiere rezultate din implementarea modelului
logic în SGBD.
 Reprezentarea datelor
3.2. Nivelul extern – colectarea informațiilor.
La nivelul extern, se acordă atenție următoarelor aspecte
(Conger, 2012):
Interviuri cu utilizatorii bazei de date, atât utilizatorii care
lucrează cu date de intrare, dar și beneficiarii rezultatelor
prelucrării datelor de intrare;
Analiza documentelor beneficiarului, pentru a identifica datele de
intrare, datele de ieșire și procedurile de transformare a datelor
inițiale în rezultate (astfel de documente por fi formulare tipizate
prin care se colectează date, rapoarte, manuale, proceduri, alte
reglementări interne, documente utilizate în corespondența de
afaceri etc). Analiza va viza și structura documentelor respective,
fiind de dorit ca baza de date să „producă” rapoarte/situații finale
cât mai aproape de documentele deja existente în sistemul
informațional al beneficiarului;
Aplicarea de chestionare și observarea modului în care utilizatorii
lucrează cu datele.
 Reprezentarea datelor
Reprezentarea datelor la nivelul extern va reflecta de fapt
cerințele utilizatorilor finali. Un model de structurare este
prezentat de Conger (2012):
Conținutul bazei de date (datele de intrare);
Conținutul și structura situațiilor finale (care prezintă datele
de ieșire). Se verifică existența datelor de intrare care permit
determinarea datelor de ieșire: concordanța intrări-ieșiri.
Funcționalități ale bazei de date: interfețe, mecanisme
dedicate obiectivelor bazei de date, modul de operare cu
aplicația etc.
O decizie importantă care poate surveni în această etapă
vizează S.G.B.D. care va fi utilizat. O atare decizie
implică o serie de costuri, directe (licență) și indirecte
(licență S.O., hardware conform cerințelor S.G.B.D./S.O.)
 Reprezentarea datelor
Cerințele hardware ale S.G.B.D. pot viza:
Spațiu de stocare minim necesar (liber) pe hard-disk. În
funcție de componentele S.G.B.D. instalate, acest spațiu
poate fi mai extins sau mai restrâns.
Unitate de disc optic, dacă instalarea se realizează de pe un
suport optic (ex. DVD).
Monitor cu o anume rezoluție minimă.
Conexiune la Internet.
Capacitate de memorie RAM (minimă și recomandată).
Procesor (cu viteză minimă și recomandată).
Tipul procesorului: generația minimă, ținând cont de
standardizarea performanțelor după tipul procesorului.
 Reprezentarea datelor
Cerințele S.G.B.D. legate de software se pot referi la:
Sistem de operare: producător, versiune. Aici menționăm
faptul că sistemul de operare însuși poate avea propriile
cerințe hardware.
Anumite update-uri ale sistemului de operare.
Compatibilitate cu alte aplicații server.
Anumite caracteristici necesare îndeplinirii funcțiilor
corespunzătoare obiectivelor bazei de date care necesită
resurse din afara S.G.B.D. (conexiunea cu conturile de
utilizator ale sistemului de operare, acces la resurse de
memorie externă pentru back-up-uri etc.).
 Reprezentarea datelor
Descrierea Descrierea Descrierea
datelor de intrare datelor de ieșire funcționalităților

Modelul conceptual al datelor

Modelul logic al datelor

2

Fișierele bazei
de date

3
 Modelul conceptual al datelor
3.3. Nivelul conceptual – definiție. Modelul EAC.
Instrumentele modelului EAC.
Nivelul conceptual asigură o interfață între cerințele formulate
la nivelul extern și modelul fizic specific S.G.B.D. La acest
nivel se stabilesc datele (de intrare) care vor fi reprezentate în
baza de date.
Modelul Entitate-Atribut-Corespondență este unul dintre
modelele utilizate pentru reprezentarea datelor la nivel
conceptual.
Instrumentele și regulile privind reprezentarea acestora sunt
specifice metodei MERISE.
O lucrare de referință despre MERISE este Nanci D., B. Espinasse avec la
collaboration de B. Cohen, J.C. Asselborn et H. Heckenroth (2001), «
Ingénierie des systèmes d'information : Merise deuxième génération »,
Vuibert éditions, Paris. ISBN : 2-7117-8674-9 (416 pages).
Modelul conceptual al datelor
Obiectele din activitatea reală și caracteristicile acestora sunt
reprezentate sub formă de entități. Entitatea se caracterizează
prin denumire, care indică ce obiecte descrie entitatea și
atribute, care corespund caracteristicilor obiectelor.
Un atribut reprezintă un descriptor de date și se caracterizează
prin denumire și domeniu: mulțimea valorilor posibile.
Un atribut poate aparține numai unei entități sau unei asocieri
și poate exista o singură dată în cadrul modelului EAC.
Atributele pot fi atomice (nedecompozabile), cum ar fi numărul
curent, numărul facturii, prețul sau compuse, de exemplu CNP,
cod IBAN, data calendaristică, numele complet. Un atribut de
acest tip poate fi reprezentat în oricare dintre cele două
variante, cu precizarea că este interzisă reprezentarea unui
atribut a cărui valoare se poate determina pe baza valorilor
altui/altor atribute din același model.
Modelul conceptual al datelor
O entitate poate avea mai multe atribute, iar reprezentarea
entității pentru un anume obiect se numește realizare. De
exemplu, o entitate care descrie clienții firmei va avea, pentru
fiecare client individualizat, o realizare.
Pentru o realizare, fiecare atribut are cel mult o valoare. Un
atribut care nu respectă regula nu aparține acelei entități.
Cel puțin un atribut al entității joacă rolul de identificator
pentru realizările acesteia și evidențiază, prin valori/combinații
de valori unice, fiecare realizare.
În principal, entitățile se referă la persoane fizice/juridice
(clienți, furnizori, salariați etc.), documente (facturi,
chitanțeetc.), bunuri (mijloace fixe – autoturisme, terenuri etc.,
active circulante – produse, mărfuri, materii prime etc.).
Aceste trei categorii de „actori” ai activității organizației
constituie un punct de plecare în reprezentarea entităților.
Modelul conceptual al datelor
Restricții referitoare la identificator:
Valori/combinații de valori unice;
Nu se acceptă valori care nu sunt disponibile (NULL);
Dimensiune cât mai restrânsă: nu se poate accepta un
identificator compus dacă o parte a sa respectă restricția de
unicitate.
Exemplu: identificatorul compus Serie document_Număr
document_Data document nu poate fi acceptat atunci când orice
combinație de valori pentru Serie document_Număr document este
unică.
Nu se admit etichete duplicate pentru denumirile
entităților, asocierilor și atributelor, chiar dacă există
similitudini (de exemplu, două atribute care descriu
aceeași proprietate pentru obiecte din categorii distincte,
reprezentate în entități distincte).
Modelul conceptual al datelor
Unirea
Este o operațiune care permite încadrarea mai multor
tipuri de entități (și de realizări de entități) în sfera unei
singure entități.
Se realizează preluarea tuturor atributelor specifice
fiecărui tip de entitate.
Este necesar să existe posibilitatea de identificare, în
mod implicit sau explicit a tipului de entitate căruia îi
aparține o anumită realizare.
Implicit: identificatorul asigură evidențierea, fără
echivoc, a tipului de entitate corespunzător fiecărei realizări.
De exemplu, CNP față de CUI permite diferențierea între
realizările de tip persoane fizice față de cele de tip persoane
juridice, prin dimensiunea valorilor atributului (numărul de
caractere).
Modelul conceptual al datelor
Explicit: se definește un atribut care are rolul specific de
a evidenția, fără echivoc, a tipului de entitate corespunzător
fiecărei realizări.
De exemplu, un atribut Tip client permite diferențierea între
realizările de tip persoane fizice față de cele de tip persoane
juridice, prin valorile sale – o valoare anume pentru fiecare tip de
realizare.
Spre deosebire de identificator, valorile atributului care
implementează modul explicit nu sunt unice, dar sunt distincte
pentru diferite tipuri de realizări, iar realizărilor de același tip le
va corespunde o valoare identică a acestui atribut.
Pentru atributele care nu sunt comune, dar sunt incluse
în entitatea rezultată prin unire, se admit valori nule acolo
unde realizarea aparține unui tip de entitate căruia nu îi sunt
specifice acele atribute.
Modelul conceptual al datelor
Partiționarea
Este o operațiune care permite reprezentarea separată a
unor tipuri de entități care au atât proprietăți comune, dar și
proprietăți distincte.
Se definesc astfel mai multe entități, care includ
atributele specifice, plus o entitate care include atributele
comune.
Nu mai este necesară diferențierea între realizările
diferitelor tipuri de entități.
Este necesară reprezentarea corespunzătoare a
asocierilor.
Unirea este preferabilă partiționării dacă se consideră că
asocierile ating un anumit nivel de complexitate, conform
aprecierii utilizatorilor.
Modelul conceptual al datelor
Asocierea descrie o corelație existentă, în realitate, între
obiectele reprezentate prin entități.
Asocierea are un nume definit și poate avea și atribute
proprii.
Pentru a denumi asocierile se pot utiliza verbe din
limbajul natural, ca expresie a faptului că reprezintă
acțiuni prin care două sau mai multe realizări de entități
sunt corelate.
Pentru o realizare a asocierii, un atribut propriu nu poate
avea decât o valoare.
Asocierea nu are identificator. Realizarea asocierii se
identifică prin identificatorii realizărilor entităților
participante.
 Modelul conceptual al datelor
Entitățile, atributele, identificatorii și asocierile se reprezintă astfel:

NUME_ENTITATE 1 NUME_ENTITATE 2

Identificator 1 Identificator 1
Identificator 2 Atribut 2
Atribut 3 Atribut 3
Atribut 4 Atribut 4
. .
Atribut n Atribut n

ASOCIERE 1

[Atribute proprii]
Modelul conceptual al datelor
Un exemplu de alocare a atributelor pentru asociere.
De exemplu, pentru reprezentarea acţiunii de facturare a
mărfurilor, atributele care reflectă cantităţile şi preţurile unitate
înscrise pe factură se vor încadra în asocierea care descrie
această acţiune (aceste atribute se realizează concomitent cu
asocierea:
Modelul conceptual al datelor
Dacă asocierea nu se realizează (dacă nu există o vânzare
de marfă), cele două atribute nu primesc valori – nu se
realizează.
Mai mult, amplasarea celor două atribute în cadrul oricăreia
dintre entităţi conduce la următoarele probleme:
- Dacă se alege entitatea FACTURI ca loc al celor două
atribute, pe fiecare factură se va înscrie o singură marfă,
datorită unicităţii identificatorului (altfel spus, nu se pot
factura mai multe mărfuri pe acelaşi document – factura).
- Dacă atributele sunt încadrate în entitatea MARFURI, nu se
poate asigura păstrarea în timp a valorilor istorice ale
cantităţii şi preţului – de fiecare dată când se facturează o
anumită marfă, identificată prin cod, valorile anterioare ale
cantităţii şi preţului ar trebui înlocuite cu noile valori.
Modelul conceptual al datelor
Se pot reprezenta asocieri distincte între aceleași entități,
care evidențiază corelații distincte, cu realizări distincte.
Pentru explicitarea modului în care o entitate participă la o
asociere, se pot utiliza nume convenţionale, denumite roluri,
care permit de asemenea identificarea asocierilor prin
identificatorii entităţilor la care se referă.
Precizarea rolurilor este obligatorie pentru asocierile
reflexive: asocieri între realizări diferite ale aceleiaşi entităţi.
Exemplu. Pentru evidenţierea rezultatelor unei competiții
de fotbal:
- Echipele pot fi asimilate persoanelor juridice, iar datele lor
reprezentate prin entitatea ECHIPE;
- Dacă scorul se reprezintă în forma Punctaj Echipa A – Punctaj
Echipa B, reținem că echipa A este echipa gazdă, iar B echipa
oaspete .
Modelul conceptual al datelor
Modelul conceptual al datelor
NUME_ENTITATE 1

Identificator 1
Identificator 2
Atribut 3
Atribut 4
. Rol 1
Atribut n

Asociere reflexiva

Rol 2 [Atribute proprii]

Modelul conceptual al datelor
Majoritatea asocierilor se reprezintă ca asocieri binare –
între două entități.
Asocierile pot fi și reflexive, așa cum s-a arătat, dar pot
exista și asocieri care implică mai mult de două entități.
Entități PROFESORI, DISCIPLINA, SALA între care se
poate reprezenta o asociere ORAR:
SALA PROFESORI DISCIPLINA

CodSala NrLegitimatie CodDisciplina

Denumire_Sala Nume_profesor Denumire_disciplina

ORAR

Ziua
Ora
C/S
Modelul conceptual al datelor
Identificarea prin rol
Este un caz particular de identificare, atunci când o entitate nu poate
avea ca identificator numai un atribut sau grup de atribute.
Entitatea aflată într-o astfel de situație (entitatea identificată) se
identifică prin atributul/atributele proprii desemnate ca atare și rolul său
într-o anumită asociere, în care are cardinalitatea 1,1 față de cealaltă
entitate (entitatea identificatoare).
La nivelul logic, în identificare va fi implicat nu rolul, ci
identificatorul entității care identifică.
Identificarea relativă se poate marca prin simbolul (R) în pe linia
dintre entitatea identificată și asociere.
Exemplu: eșalonarea ratelor unui credit
CREDITE RATE
PLATA NrRata
NrContract DataScadentă
DataContract Suma

Eșalonare Se referă la
Modelul conceptual al datelor
Nici unul dintre atributele entității RATE nu poate îndeplini
(independent) funcția de identificator.
Numărul ratei participă la identificare, dar este unic doar pentru un
credit, dar pot exista numere de rată identice care descriu eșalonarea
unor credite diferite.
Prin urmare, identificarea se realizează prin numărul ratei și rolul
entității (ceea ce implică la MLD numărul creditului).
Alternativ, se poate recurge la o reprezentare de genul:
CREDITE RATE
PLATA
NrContract NrRata
DataContract DataScadentă
Suma
Entitatea RATE va avea ca realizări (mono-atribut, deci mono-
valoare) numerele de ordine ale ratelor, de la 1 la numărul maxim de rate
acceptat.
Identificarea prin rol nu mai este necesară.
O astfel de soluție nu are un impact negativ asupra modelului logic
de date.
Modelul conceptual al datelor
Reprezentarea timpului
Reperele de timp (Datele calendaristice, indiferent de
unitatea de măsură-precizia asociată) se reprezintă ca
atribute obișnuite.
Reperul de timp asociat unui document se reprezintă în
entitatea documentului respectiv.
Pentru reprezentarea valorilor istorice ale unui atribut:
Se poate defini o entitate în acest sens, dacă se poate asocia cu o
altă entitate.
Atributul de timp (valori de tip data calendaristică sau alt tip de
valori, cu o precizie diferită) însoțește atributul pentru care se
reprezintă valorile istorice.
Atributul de timp poate fi considerat identificator numai dacă
valorile sale sunt unice.
În caz contrar se aplică identificarea prin rol.
 Modelul conceptual al datelor
Se referă la
INDICATOR E-F VALORI
ISTORIC
Cod_IEF Data_val
Denumire Valoare_IEF
Definiție
Descriere
Alternativ, se poate construi o entitate auxiliară care reține lista de
valori a atributului de timp, iar atributul cu rol de valoare se
înscrie în asocierea dintre cele două entități:

INDICATOR E-F TIMP

ISTORIC
Cod_IEF Data_val
Denumire Valoare_IEF
Definiție
Descriere
În acest caz, orice combinație de valori a identificatorilor celor
două entități asigură identificarea asocierii și trebuie să fie unică.
Modelul conceptual al datelor
Cardinalitățile reprezintă perechi de valori care descriu
modul de participare a entităților și realizărilor lor la
asocieri, exprimat prin numărul de realizări al unei entități
care corespunde unei singure realizări a celeilalte entități.
Cardinalități minime: 0 sau 1;
Cardinalități maxime: 1 sau n, unde:
0 (nici unul/nici una);
1 (unul singur/una singură);
n (mai mulți/mai multe).
Cardinalitatea minimă și maximă a unei entități A care
participă la o asociere cu entitatea B este dată de numărul
minim și maxim de realizări ale entității B corespunzător
unei realizări a entității A.
 Modelul conceptual al datelor
Exemple
FACTURI MĂRFURI

NumărFactură CodMarfa
SerieFactură DenMarfa
DataFactură UnitMasura
DataScadentă Caracteristici

1,n 0,n
FACTURARE
Cantitate
PrețUnitar

• În baza unei facturi pot fi comercializate minim una și maxim n (mai multe) mărfuri:
1,n.
• O marfă poate fi comercializată de minim 0 ori (dacă nu există cerere), respectiv
maxim în baza mai multor facturi: 0,n.
• În acest caz, Cantitate și PrețUnitar sunt atribute multivaloare pentru ambele entități.
 Modelul conceptual al datelor
Exemple
SALA PROFESORI DISCIPLINA

CodSala NrLegitimatie CodDisciplina

Denumire_Sala Nume_profesor Denumire_disciplina

0,n
1,n ORAR 1,n

Ziua
Ora
C/S
• O sală poate găzdui minim o activitate (curs sau seminar) și maxim n (mai multe)
activități: 1,n.
• Un profesor poate susține minim zero activități (dacă nu are activități în semestrul
respectiv), respectiv mai multe activități: 0,n.
• O disciplină poate avea minim o activitate programată și maxim n (mai multe)
activități: 1,n.
 Modelul conceptual al datelor
CREDITE RATE
NrRata
NrContract DataScadentă
DataContract Suma

1,n 1,1
Eșalonare PLATA
Se referă la

Un credit poate avea minimum o rată, maximum mai multe rate: 1,n.
O rată se referă la un singur credit: 1,1.
CREDITE RATE
1,n 1,n
PLATA
NrContract NrRata
DataContract DataScadentă
Suma
Un credit poate avea minimum o rată, maximum mai multe rate: 1,n.
Un număr (de ordine) de rată se poate regăsi în eșalonarea a minim unui credit
(ex. rata 1) și maximum a mai multor credite: 1,n
 Modelul conceptual al datelor
Se referă la
INDICATOR E-F VALORI
• 1,n 1,1
ISTORIC
Cod_IEF Data_val
Denumire Valoare_IEF
Definiție
Descriere

INDICATOR E-F TIMP

1,n ISTORIC 1,n
Cod_IEF Data_val
Denumire Valoare_IEF
Definiție
Descriere
Aplicație 1. Reprezentarea datelor
Cerințele prezentate cu caractere bold constituie schema externă –
reprezentarea datelor la nivel extern.
SC XYZ SA comercializează produse de panificație. Produsele sunt identificate prin: cod,
denumire, gramaj, ingrediente, tipul produsului, alergeni. Ingredientele sunt caracterizate
prin cod, denumire, cantitate în rețeta unui produs, caracterul alergen.
Vânzarea se realizează pe bază de factură: serie factură, număr factură, data emiterii, data
scadentă, datele furnizorului și beneficiarului, produsele vândute, cantități comercializate,
prețuri unitare, cota TVA (diferă în funcție de codul produsului), valori fără TVA pe linie
factură, valori TVA pe linie factură, valori inclusiv TVA pe linie factură, discount pe linie
factură, valoare totală fără TVA, total TVA, valoare totală inclusiv TVA, număr aviz de însoțire
a mărfii, data aviz de însoțire a mărfii, număr înmatriculare auto, nume delegat. Orice factură
poate fi anulată. Orice factură poate fi stornată, prin emiterea unei facturi de stornare, cu
aceleași categorii de date. Cota TVA poate diferi în funcție de produs.
Datele beneficiarilor sunt următoarele: nume/denumire, nr. de înregistrare la Registrul
Comerțului, CUI, cod client (nu se poate utiliza CNP al persoanelor fizice), adresa, banca, cont
bancar (cod IBAN), email, număr telefon, capital social.
Plata se poate efectua prin numerar, card bancar, ordin de plată, virament bancar, bilet la
ordin. Se acceptă plata în tranșe, iar un document de plată poate deconta sume referitoare la
mai multe facturi.
Datele relevante pentru plată sunt: ID_plată, număr document, tip document, data document,
suma plătită, referința (factura care se plătește), cod IBAN plătitor, cod IBAN beneficiar plată,
numele plătitorului, numele beneficiarului plății.
Aplicație 1. Reprezentarea datelor
Pentru elaborarea modelului conceptual, propunem următorul algoritm:
Etapa I. Reprezentarea entităţilor
Entităţile se utilizează pentru abstractizarea:
- persoanelor fizice/juridice;
- documentelor;
- bunurilor.
Drept urmare, entităţile modelului nostru sunt:
PRODUSE
INGREDIENTE
FACTURI
BENEFICIARI
TVA
AVIZ_DE_INSOTIRE_A_MARFII (AVIZ_IM)
AUTOVEHICULE
DELEGAȚI
PLATĂ
Aplicație 1. Reprezentarea datelor
Observaţie 1: nu se va reprezenta o entitate pentru persoana fizică sau juridică
a cărei activitate face obiectul modelului (în cazul nostru compania) și nici
pentru marca proprie). Aceste date sunt mai degrabă constante și nu intră în
categoria atribute. De asemenea, crearea unei atare entități va provoca
dificultăți atât în etapa a treia (asocieri), dar și la construirea modelului logic
de date, ceea ce conduce la denaturarea structurii bazei de date.

Observaţie 1’: deși putem vorbi de două tipuri de documente de plată, acestea
pot fi agregate într-o singură entitate, PLATĂ, prin unire. Pentru a marca
aplicarea unirii, este obligatoriu cel puțin un atribut care să diferențieze între
realizările de diferite tipuri (OP vs. Chitanțe etc.). Un astfel de atribut se poate
denumi Tip document și asigură identificarea explicită între diferite tipuri de
realizări.

Similar, observația se aplică pentru BENEFICIARI. Fie se introduce

(identificare explicită) un atribut tip client, fie presupunem că diferențierea se
face prin valorile existente (persoane juridice), respectiv nule (persoane fizice)
ale atributului CUI (identificarea implicită).
Aplicație 1. Reprezentarea datelor
Etapa II. Reprezentarea atributelor şi identificatorilor

Observaţie 2: nu se reprezintă, într-o entitate, atribute referitoare la altă

entitate din acelaşi model. În schimb, se vor reprezenta asocieri între entităţile
aflate în această situaţie.

Observaţie 2’: nu se vor reprezenta, în model, atribute ale căror valori pot fi
calculate pe baza valorilor altor atribute din același model.

Observaţie 2’’: în entitățile de tip document, se va acorda o atenție deosebită

oportunității de a înscrie alte atribute decât cele referitoare la numărul și data
documentului. Nu se vor defini într-o astfel de entitate atribute referitoare la
persoane implicate în circulația documentului, nici atribute care descriu
bunurile tranzacționate pe baza documentului.
Aplicație 1. Reprezentarea datelor
Atributele și identificatorii entităţilor sunt următoarele:
PRODUSE: Codp, Denumirep, Gramaj, Tipp
INGREDIENTE: Codin, Denumirein, Car
FACTURI: Serief, Nrf, Dataem, Datasc, Anulat
BENEFICIARI: Codclient, Numed, NrRC, CUI, Adresa, Banca, IBAN, Email, Telc,
Capsoc
TVA: Dataref (+rolul din asocierea cu PRODUSE), CotaTVA
AVIZ_IM: NrAIM, DataAIM
AUTOVEHICULE: Nrauto
DELEGAȚI: Nrleg, Numed
PLATĂ: IDplata, Nrdoc, Tipdoc, Datadoc
Atributele subliniate reprezintă identificatorii.

Notă: Soluția prezentată urmărește rezolvarea de la curs. Alte cazuri particulare care
au fost discutate la dezbateri vor fi prezentate separat.
Aplicație 1. Reprezentarea datelor
Etapa III. Reprezentarea asocierilor
În primul rând se vor trata situaţiile corespunzătoare observaţiei nr. 2.
• PRODUSE – INGREDIENTE : RETETA
• FACTURI – BENEFICIARI: VANZARE
• FACTURI – PRODUSE: PFACT (PRODUSE_FACTURATE)
• PRODUSE – TVA: TAXARE, cu rolurile Produs taxat, respectiv Se referă la
• FACTURI – AIM: INSOTIRE
• AIM – AUTO: TRANSPORT
• AIM – DELEGATI: DELEGARE
• FACTURI – FACTURI: STORNARE (asociere reflexivă cu rolurile
Factura de stornare , respectiv Factura stornata.
• FACTURI – PRODUSE: PSTORNO (PRODUSE_STORNATE)
• FACTURI – PLATA: DECONT

Observaţie 3: nu se reprezintă asocieri între entităţi ce descriu persoane

implicate în tranzacții cu bunuri și entitățile care se referă la bunurile
respective. Ambele entităţi în schimb vor fi conectate prin asocieri cu
documentul justificativ al operaţiunii economice. Astfel, nu se poate asocia
BENEFICIARI cu PRODUSE, ambele se vor asocia cu FACTURI.
Aplicație 1. Reprezentarea datelor
Observaţie 3’: Atributele a căror realizare coincide cu realizarea unei asocieri,
vor fi înscrise în asocierea respectivă, nu în entități care participă la acea
asociere.

Observaţie 3’’: atributele atomice cu semnificație cantitativ-valorică care se

referă la o tranzacție se înscriu în asocierea care descrie acea tranzacție,
stabilită între documentul justificativ al tranzacției și bunul tranzacționat.
Ca excepție, atributele care nu au o variabilitate suficient de ridicată în timp
(nu se modifică frecvent), cum ar fi, de exemplu, prețul care rămâne valabil
pentru un interval de timp extins. Pentru aceste cazuri, a se vedea observația 4.

Observaţie 4: Atributele ale căror valori pot fi considerate destul de persistente

în timp/spațiu, cum ar fi cele cu semnificație de cotă de taxare/impozit/termen
de plată etc. aplicabile unei tranzacții, se pot procesa, la nivelul reprezentării
datelor, în mai multe variante (trebuie să se țină cont de faptul că valorile
acestor cote pot varia în timp și/sau spațiu - dacă se aplică valori diferite pentru
diverse segmente ale activității pentru care se reprezintă date, de exemplu cote
de TVA diferite în funcție de mărfurile comercializate):
Aplicație 1. Reprezentarea datelor
1. Atributul variază doar în timp:
a. La nivelul conceptual și logic, acest atribut poate fi omis (chiar dacă se
încadrează într-o entitate, acea entitate nu va participa la asocieri)
b. La nivelul fizic, se conturează două soluții:
a. Se definește un tabel auxiliar cu două atribute:
a. Data de referință
b. Valoarea atributului
Pentru preluarea unei valori a atributului, se încadrează data
tranzacției între două valori Data de referință și se preia valoarea
atributului valabilă la data tranzacției.
a. Se definește o procedură în programul client (prin utilizarea unui
limbaj de programare:
a. printr-o structură de tip alternativ, se definesc intervalele între
care este valabilă o anumită valoare, precum și valoarea
respectivă.
b. Preluarea valorii valabile la un moment dat se realizează prin
implementarea aceluiași principiu ca în cazul soluției anterioare.
2. Atributul variază atât în timp, cât și în spațiu:
Modelul EAC: Se aplică soluția din slide-ul 63-64, implementată și în aplicația 1,
pentru TVA.
Modelul logic: se obține un tabel TVA (Codp, Dataref, CotaTVA).
Aplicație 1. Reprezentarea datelor
Într-un astfel de tabel se vor înregistra noile valori ale atributului
CotaTVA, ori de câte ori suferă modificări în timp/spațiu (coordonata de
timp vizează atributul data de la care intră în vigoare cota, iar cea de
spațiu atributul Codp).
Datele dintr-un astfel de tabel se pot valorifica, în orice moment, prin
încadrarea documentului, prin valoarea atributului care marchează data
sa calendaristică, în intervalul de valabilitate al unei anumite cote
(interval definit de două valori succesive cronologic ale atributului
Dataref, a doua valoare marchează încheierea unui interval), precum și
asocierea între produsul comercializat (prin codul său) și cota TVA
aplicabilă, în funcție de cod.

Notă: Dacă se decide totuși reprezentarea acestor atribute aflate în

situația descrisă de cazul 1 în modelul conceptual/logic și preluarea din
modelul logic în baza de date, atributul se înscrie în entitatea
corespunzătoare documentului justificativ aferent tranzacției.
Aplicație 1. Reprezentarea datelor
Soluția 2 a fost considerată în cadrul aplicației 1, pentru exemplificare.

Observaţie 5: reprezentarea operațiunii de plată comportă mai multe variante,

în funcție de regulile comerciale stabilite între parteneri. Distingem
următoarele cazuri:
a. cazul aplicației 1. se acceptă plata în tranșe, iar un document poate deconta sume
în contul mai multor facturi:
* atributul Suma se înscrie în asocierea FACTURI - PLATĂ
b. se acceptă doar plata integrală, un document de plată se referă la o singură
factură:
* atributul Suma se înscrie în entitatea DOCUMENTE
c. se acceptă plata în tranșe, un document de plată se referă la o singură factură:
* atributul Suma se înscrie în entitatea DOCUMENTE
d. se acceptă doar plata integrală, un document de plată se referă la mai multe
facturi:
* atributul Suma se înscrie în asocierea FACTURI – PLATĂ.
Aceste posibile cazuri influențează și cardinalitățile. Cazul a este inclus în
rezolvarea aplicației. Cazurile b-d și vor fi prezentate distinct.

Notă. Dacă în aplicațiile didactice nu se precizează nimic în acest sens, recomandăm

utilizarea soluției din această aplicație, respectiv cea mai acoperitoare.
Aplicație 1. Reprezentarea datelor
Înainte de a se trece la etapa IV, se verifică trei chei de control:
a) fiecare entitate participă la cel puţin o asociere.
Soluția minimală, în cazul în care pentru o entitate A nu se verifică acest criteriu,
identificarea celei mai relevante entități cu care A să fie conectată printr-o asociere.
b) modelul nu este segmentat în mai multe submodele care să fie ne-conectate;
Un astfel de exemplu (simplificat) este redat în figura de mai jos:

A B C

D E

Considerând A, B, C, D și E entități, iar liniile dintre ele asocieri, se observă că, deși
fiecare entitate participă la o asociere (sau două, în cazul entității B), modelul este
segmentat în două submodele: unul include entitățile A, B și C; celălalt entitățile D
și E.
Soluția minimală: reprezentarea unei asocieri între una din entitățile A, B și C și una
din entitățile din submodelul D – E.
c) toate atributele și acţiunile (corelaţiile) din enunţ sunt reflectate în model.
Aplicație 1. Reprezentarea datelor
Reprezentarea cardinalităților
Pentru reprezentarea cardinalităţilor, în fiecare asociere se analizează situaţia
fiecărei entităţi, determinând numărul realizărilor celeilalte entităţi şi stabilind
cardinalităţile corespunzătoare.
Asocierea PRODUSE – INGREDIENTE : RETETA
un PRODUS poate include mai multe INGREDIENTE (cardinalitate 1,n).
un INGREDIENT se poate regăsi în mai multe PRODUSE (cardinalitate 1,n).
Asocierea FACTURI – BENEFICIARI: VANZARE
o FACTURĂ corespunde unui singur BENEFICIAR (cardinalitate 1,1).
un BENEFICIAR poate primi mai multe FACTURI (cardinalitate 1,n).
Asocierea FACTURI – PRODUSE: PRODUSE_FACTURATE
pe o FACTURĂ se pot regăsi mai multe PRODUSE vândute (cardinalitate
1,n).
un PRODUS se poate regăsi pe mai multe FACTURI (cardinalitate 0,n).
PRODUSE – TVA: TAXARE, cu rolurile Produs taxat, respectiv Se referă la :
O Dată de referință și o anumită Cotă TVA se referă la un singur PRODUS
(cardinalitate 1,1).
Pentru un PRODUS se pot înregistra mai multe cote de TVA – istoricul
cotelor de TVA (cardinalitate 1,n).
Aplicație 1. Reprezentarea datelor
Asocierea FACTURI – AIM: INSOTIRE
Pentru o FACTURĂ se pot înregistra mai multe AIM (cardinalitate 1,n).
Un AIM se referă la o singură FACTURĂ (cardinalitate 1,1).
Asocierea AVIZE – AUTO: TRANSPORT
Pentru un AVIZ se consideră un singur AUTO (cardinalitate 1,1).
Un AUTO poate fi utilizat la mai multe AVIZE (cardinalitate 1,n).
Asocierea AIM – DELEGATI: DELEGARE
Pentru un AIM există un singur DELEGAT (cardinalitate 1,1).
Un DELEGAT poate corespunde mai multor AIM (cardinalitate 1,n).
Asocierea FACTURI – FACTURI: STORNARE (asociere reflexivă cu rolurile
Factura care storneaza, respectiv Factura stornata.
O FACTURA DE STORNARE poate storna mai multe FACTURA STORNATA
(cardinalitate 1,n).
O FACTURA STORNATA poate fi stornată de o singură FACTURA CARE
STORNEAZA (cardinalitate 0,1).
Asocierea FACTURI – PRODUSE: PRODUSE_STORNATE
pe o FACTURĂ se pot regăsi mai multe PRODUSE (cardinalitate 1,n).
un PRODUS se poate regăsi pe mai multe FACTURI (cardinalitate 0,n).
Asocierea FACTURI – PLATA: DECONT
o FACTURĂ poate deconta prin mai multe PLATI - transe (cardinalitate 1,n).
o PLATA se poate referi la mai multe FACTURI (cardinalitate 1,n).
Aplicație 1. Reprezentarea datelor
Aplicație 1. Reprezentarea datelor
Reprezentarea celorlalte opțiuni privind plata.
b. se acceptă doar plata integrală, un document de plată se referă la o singură
factură:
* atributul Suma se înscrie în entitatea DOCUMENTE

c. se acceptă plata în tranșe, un document de plată se referă la o singură factură:

Aplicație 1. Reprezentarea datelor
* atributul Suma se înscrie în entitatea DOCUMENTE

d. se acceptă doar plata integrală, un document de plată se referă la mai multe

facturi:
* atributul Suma se înscrie în asocierea FACTURI – PLATĂ.
 Reprezentarea datelor
Pachet pedagogic – tema 3
Cuvinte - cheie
Nivel extern.
Nivel conceptual
Entitate.
Atribut.
Realizare.
Asociere.
Cardinalitate.
Rol.
Identificator.
 Reprezentarea datelor
Întrebări

Care sunt cele trei categorii de cerințe care rezultă în urma colectării
informațiilor la nivelul extern?
Care sunt cele trei tipuri de obiecte care pot fi reprezentate prin entități?
Ce rol are identificatorul entității?
Care este corelația dintre noțiunile entitate și realizare a entității?
Ce este asocierea reflexivă?
Cum se reprezintă corect entitățile și asocierile între entitățile descrise
mai jos:
Un tip de document în baza căruia se realizează tranzacții cu un anumit tip de
bunuri;
Bunurile tranzacționate cu acest document;
Partenerii implicați în tranzacție (persoane fizice/juridice).
 TEMA 4.
Nivelul logic
4.1. Definiție. Modelul logic de tip relațional.
4.2. Instrumentele modelului relațional.
4.3. Regulile de trecere la modelul relațional.
4.4. Aplicații.
 Modelul logic al datelor
4.1. Definiție. Modelul logic de tip relațional
Modelul logic al datelor presupune reprezentarea datelor utilizând
instrumente compatibile cu SGBD în care va fi implementată
baza de date (de la logiciel în limba franceză = program). Pentru
SGBD relaționale, se va utiliza modelul relațional.
4.2. Instrumentele modelului relațional
- Relația: o structură de date bidimensională, similară unui tabel
(tabel este denumirea instrumentului utilizat la nivel fizic pentru
reprezentarea relației în accepțiunea unor SGBD relaționale).
Termenul de relație, în acest context nu trebuie confundat cu cel
de asociere sau corespondență;
- Orice relație poartă un nume (întrucât relația provine dintr-o
entitate sau asociere a modelului conceptual, este de așteptat să
preia numele obiectului sursă);
- Fiecare coloană a relației corespunde unui anumit atribut, care
are propriul nume, care permite diferențierea atributelor între ele
(ca și în cazul relației, numele poate fi păstrat de la MCD).
 Modelul logic al datelor
- Denumirile relațiilor și atributelor trebuie să fie unice, pentru a
nu genera confuzii;
- Fiecărui atribut îi corespunde un domeniu de valori (mulțimea
valorilor acceptate pentru atribut). La trecerea la nivelul fizic,
domeniul atributului se va regăsi în tipul de date și celelalte
restricții definite pentru valorile atributului;
- O relație reprezintă date despre mai multe obiecte, iar pentru
fiecare obiect individual există în cadrul relației un tuplu. Altfel
spus, un tuplu se formează dintr-un grup de valori, cel mult o
valoare pentru fiecare atribut (pot exista valori necompletate,
dacă acestea nu încalcă regulile privind integritatea datelor).
- Inclusiv datele care descriu structura bazei de date (metadatele)
este necesar a fi stocate conform aceluiași principiu.
 Modelul logic al datelor
- Cheia primară: „un atribut sau grup de atribute care
identifică, prin valori distincte sau combinaţii de valori
distincte”, fiecare tuplu dintr-o relație. Pentru cheile
primare nu se acceptă valori nule;
- Cheia externă: un atribut dintr-o relație care este cheie
primară în altă relație. Între cele două atribute se stabilește
restricția de integritate referențială.
Orice relație are cel puţin o cheie: primară sau externă.
În baza corespondenței din definiția cheii externe, se
definesc, la nivelul fizic, legăturile dintre tabele.
Conger (2012) are în vedere următoarele avantaje
ale modelului relațional:
- Minimizarea redundanței;
- Corelarea datelor din diferite segmente ale bazei de date.
 Modelul logic al datelor
Datele despre fiecare persoană sau bun sunt reprezentate o
singură dată, ca tuplu în relația respectivă, iar dacă o persoană,
sau un bun, sunt implicate într-o acțiune descrisă printr-o altă
relație, se preia doar valoarea corespunzătoare persoanei sau
bunului, în înregistrarea referitoare la acțiunea respectivă, ca
valoare a cheii externe care referă persoana sau bunul.
Simplitatea și aplicabilitatea modelului permit utilizarea
acestuia ca instrument de lucru inclusiv în scop didactic.

Modelul logic poate fi reprezentat prin utilizarea notației:

NUME_TABEL (Cheieprimară, Atribut2, …, Atributn,
Cheieexternă), conform Năstase și colectiv (2000).
Dacă sunt mai multe tabele, acestea pot fi reprezentate unul sub
altul.
 Modelul logic al datelor
4.3. Regulile de trecere la modelul relațional.
Modelul relaţional se obţine din modelul EAC, prin aplicarea
regulilor de trecere:
„R1. Toate entităţile se transformă în tabele. Atributele entităţilor devin
atribute ale tabelelor. Identificatorii entităţilor devin chei primare ale
tabelelor.
R2. Asocierile în care ambele cardinalităţi maxime sunt n se transformă în
tabele. Atributele asocierii, dacă există, devin atribute ale tabelelor
corespunzătoare. Identificatorii entităţilor participante la asociere devin
chei externe ale noului tabel.
R3. Asocierile în care una din cardinalităţile maxime este 1 şi cealaltă n
dispar. Tabelul provenit din entitatea cu cardinalitatea maximă 1 preia
identificatorul celeilalte entităţi, cu rol de cheie externă, precum și (dacă
există) atributele asocierii.
R4. Asocierile în care ambele cardinalităţi maxime sunt 1 dispar. Tabelul
provenit din una dintre entităţi preia identificatorul celeilalte entităţi, cu
rol de cheie externă”.
 Modelul logic al datelor
Regula nr. 1 (R1) se aplică prima. Este singura regulă care se
aplică pentru entități.
După reprezentarea tabelelor, atributelor și cheilor primare
conform cu regula R1, se analizează fiecare asociere, evaluându-se
combinația de cardinalități maxime.
Dacă ambele cardinalități maxime sunt n se aplică regula nr. 2
(R2). Se recomandă, la modelul fizic, definirea combinației de chei
externe a tabelelor rezultate prin R2, drept cheie primară compusă.
Dacă numai una din cardinalitățile maxime este n, se aplică R3.
Dacă ambele cardinalități maxime sunt 1, se aplică R4.
Alternativ, atributele celor două entități se pot comasa în același
tabel.
Pentru entitățile identificate relativ se aplică regulile 3 sau 4. Se
recomandă, la nivel fizic, construirea unei chei primare compuse, din
identificatorul preluat drept cheie externă și cheia primară
transformată.
 Modelul logic al datelor
Pachet pedagogic – tema 4
Cuvinte - cheie
Nivel logic.
Model relațional.
Tabel – relație.
Atribut.
Înregistrare - tuplu.
Cheie primară.
Cheie externă.
Trecere de la MCD la MLD.
 Modelul logic al datelor
Întrebări

Care este rolul cheilor primare?

Cum se formează cheile externe?
Pentru ce obiecte din modelul conceptual de tip EAC se aplică regula de
trecere R1?
Când se aplică regula de trecere R2?
Cum se aplică regula de trecere R4?
Ce convenții se utilizează pentru reprezentarea cheilor primare? Dar a
celor externe?
Ce instrument permite definirea, la nivel fizic, a legăturilor între tabele?
Aplicație 1. Reprezentarea datelor
Reprezentarea modelului logic al datelor
Etapa I. Se aplică mai întâi regula R1, se reprezintă tabelele, atributele şi cheile
primare.
Etapa II. Se analizează fiecare asociere, şi se aplică regula R2, R3 sau R4.
Asocierea FACTURI-PRODUSE (PFACT)
Cardinalităţile maxime sunt n şi n.
Asocierea se transformă în tabel (tabelul PFACT).
În noul tabel se înscriu cele trei atribute ale asocierii: Cantf, Pretf, Discount.
Tabelul preia și identificatorii entităților participante la asociere, respectiv
Serief, Nrf de la FACTURI și Codp de la PRODUSE, cu rol de chei externe.
Asocierea FACTURI-BENEFICIARI (VANZARE)
Cardinalităţile maxime sunt 1 şi n. Asocierea NU se transformă în tabel.
Tabelul provenit din entitatea FACTURI preia identificatorul de la
BENEFICIARI, Codclient, cu rol de cheie externă.
Asocierea reflexivă STORNARE
Cardinalităţile maxime sunt 1 şi n.
În tabelul FACTURI se înscrie identificatorul corespunzător rolului Factura
de stornare, respectiv Seriefs, Nrfs, cu rol de cheie externă.
Aplicație 1. Reprezentarea datelor
Asocierea TVA-PRODUSE (TAXARE)
Cardinalităţile maxime sunt 1 şi n.
Asocierea NU se transformă în tabel.
Tabelul provenit din entitatea TVA preia și identificatorul entității
PRODUSE, respectiv Codp, cu rol de cheie externă. Identificarea prin rol VA
impune definirea unei chei primare compuse din Dataref și Codp.
Asocierea INGREDIENTE-PRODUSE (RETETA)
Cardinalităţile maxime sunt n şi n.
Asocierea se transformă în tabel (tabelul RETETA).
Noul tabel preia atributul asocierii: Cantin.
Tabelul preia și identificatorii entităților participante la asociere, respectiv
Codin de la INGREDIENTE și Codp de la PRODUSE, cu rol de chei
externe.
Asocierea DELEGATI-AVIZ_IM (DELEGARE)
Cardinalităţile maxime sunt 1 şi n.
În tabelul AVIZ_IM se înscrie identificatorul entității DELEGATI, respectiv
NrLeg, cu rol de cheie externă.
Aplicație 1. Reprezentarea datelor
Asocierea FACTURI-PRODUSE (PSTORNO)
Cardinalităţile maxime sunt n şi n.
Asocierea se transformă în tabel (tabelul PSTORNO).
Noul tabel preia atributele asocierii: Cants, Prets.
Tabelul preia și identificatorii entităților participante la asociere, respectiv
Serief, Nrf de la FACTURI și Codp de la PRODUSE, cu rol de chei externe.
Asocierea FACTURI-AVIZ_IM (INSOTIRE)
Cardinalităţile maxime sunt 1 şi n.
În tabelul AVIZ_IM se înscrie identificatorul entității FACTURI, respectiv
Serief, Nrf, cu rol de cheie externă.
Asocierea AUTO-AVIZ_IM (TRANSPORT)
Cardinalităţile maxime sunt 1 şi n.
În tabelul AVIZ_IM se înscrie identificatorul entității AUTO, respectiv
NrAUTO, cu rol de cheie externă.
Aplicație 1. Reprezentarea datelor
Asocierea FACTURI-PLATA (DECONT)
Cardinalităţile maxime sunt n şi n.
Asocierea se transformă în tabel (tabelul DECONT).
Noul tabel preia atributul asocierii: Suma.
Tabelul preia și identificatorii entităților participante la asociere, respectiv
Serief, Nrf de la FACTURI și IDPlata de la PLATA, cu rol de chei externe.
Aplicație 1. Reprezentarea datelor
Rezultatul aplicării regulilor de trecere este prezentat în continuare (elementele cu
italic corespund regulii nr. 2, cele cu bold regulii nr. 3):

TVA (Dataref, CotaTVA, Codp)

INGREDIENTE (Codin, Denumirein, Car)
PRODUSE (Codp, Denumirep, Gramaj, Tipp)
FACTURI (Serief, Nrf, Dataem, Datasc, Anulat, Codclient, Seriefs, Nrfs)
BENEFICIARI (Codclient, Numecl, NrRC, CUI, Adresa, Banca, IBAN, Email,
Telc, Capsoc)
AVIZ_IM (NrAIM, DataAIM, Serief, Nrf, NrAUTO, Nrleg)
AUTO (NrAUTO)
DELEGATI (Nrleg, NumeD)
PLATA (IDPlata, Nrdoc, Datadoc, Tipdoc)
PFACT (Serief, Nrf, Codp, Cantf, Pretf, Discount)
PSTORNO (Serief, Nrf, Codp, Cants, Prets)
DECONT (Suma, Serief, Nrf, Codp, IDPlata)
RETETA (Codin, Codp, Cantin)