Baze de date

Curs
2
Etapele de proiectare a unei baze
de date

08.10.2021
 Proiectarea bazei de date relaţionale
Pentru a construi baza de date la nivelul logic trebuie proiectată structura bazei de
date. Structura bazei de date este definită de:
• structura de câmpuri a fiecărui tabel
• legăturile care se stabilesc între tabele.
Operaţia de proiectare a bazei de date înseamnă transformarea cerinţei de informaţii
într-o colecţie de tabele şi de relaţii dintre ele. Pentru a fi eficientă în exploatare, o
bază de date trebuie să fie bine proiectată. Metoda de proiectare aleasă depinde de
dimensiunile bazei de date.
După ce s-au proiectat tabelele, câmpurile şi relaţiile dintre tabele, urmează studierea
proiectului pentru a-i descoperi deficienţele. Este mult mai simplu să se modifice
proiectul în această fază – şi nu după ce au fost încărcate toate datele în baza de date.
Construirea bazei de date la nivel fizic
Etape:
1. Construirea tabelelor care compun baza de date. Aceasta înseamnă că pentru
fiecare tabel din baza de date trebuie definită structura, adică ansamblul de
câmpuri împreună cu proprietăţile lor.
2. Stabilirea relaţiilor între tabele.
3. Popularea bazei de date. Se încarcă date în fiecare tabel. La nivelul tabelului
unitatea de prelucrare este înregistrarea: se pot adăuga înregistrări, se pot şterge
înregistrări, se pot modifica înregistrări. Se poate modifica structura unui tabel
chiar după ce a fost încărcat cu date. Sistemul de gestiune a bazelor de date nu
operează modificarea de structură direct în tabel, ci execută următoarele
operaţii: creează noua structură de tabel (rezultată în urma modificărilor cerute),
încarcă în noul tabel datele din vechiul tabel şi şterge vechiul tabel. Toate aceste
operaţii sunt executate automat de către sistem, fără intervenţia utilizatorului şi
fără a fi vizibile pentru utilizator.
1.1. Proiectarea bazelor de date mici
O bază de date mică este destinată în general pentru informatizarea unui singur domeniu de
activitate al organizaţiei. Pentru proiectarea ei se pot folosi două metode:
Metoda 1
Se porneşte de la o entitate care defineşte informaţia compusă pe care trebuie să o conţină baza
de date. Se construieşte tabelul pentru această entitate şi se divizează acest tabel în tabele mai
mici, prin procesul de normalizare a datelor. În cadrul acestui proces sunt identificate informaţiile
care trebuie separate în tabele mai mici şi modul în care va fi asigurată legătura între ele. Prin
această operaţie se simplifică o înregistrare de mari dimensiuni în mai multe tabele legate între
ele. Nu trebuie alocate câmpuri pentru datele derivate sau calculate (cum este, de exemplu,
vârsta unei persoane, dacă există deja un câmp în care este înregistrată data naşterii).
Pe de altă parte, dacă o bază de date relaţională conţine foarte multe tabele, exploatarea sa va
necesita un timp mai mare de prelucrare, deoarece o cerere de informaţii din baza de date va avea
ca efect parcurgerea mai multor tabele. De aceea, procesul de divizare a tabelului iniţial în mai
multe tabele trebuie să se oprească la un moment dat.
TEMA de grup
Consideraţi anul o organizaţie pentru care se construieşte un minisistem
informatic, iar sursa informaţională va fi o bază de date relaţională. Analiza
trebuie să pornească de la entitatea Student. Veţi identifica toate datele
caracteristice unui student, atât din punct de vedere al datelor personale
(număr matricol, nume şi prenume, iniţiala tatălui, datele despre părinţi,
adresa, numărul de telefon), cât şi din punct de vedere al situaţiei şcolare
(anul de studiu, facultatea, sectia, profesorul indrumator, profesorul pe
care îl are la fiecare disciplină, disciplinele pe care le studiază în acest an
şcolar, notele şi absenţele la fiecare disciplină, pe fiecare semestru, media
la fiecare disciplină obţinută semestrial, media anuală la fiecare disciplină,
media semestrială şi media anuală a studentului). Construiţi cu aceste date
primul tabel. Construiţi baza de date prin normalizarea tabelului iniţial.
Metoda 2
Pentru proiectarea bazei de date se porneşte de la informaţiile pe care
trebuie să le furnizeze baza de date. Pentru aceasta, trebuie să se
parcurgă, în ordine, următorii paşi:
• Determinarea scopului bazei de date.
• Determinarea tabelelor necesare în baza de date.
• Determinarea câmpurilor necesare în tabele.
• Identificarea câmpurilor care pot fi cheie unică.
• Determinarea relaţiilor dintre tabele.
Determinarea scopului bazei de date
Primul pas în proiectarea unei baze de date este determinarea scopului
şi a modului în care poate fi folosită baza de date. Mai întâi trebuie
identificate informaţiile pe care trebuie să le furnizeze baza de date şi
apoi se împart aceste informaţii pe categorii de informaţii (care vor
corespunde tabelelor), iar categoriile de informaţii se împart în
informaţii elementare (care vor corespunde câmpurilor din tabele).
Pentru realizarea acestor obiective se întreprind următoarele acţiuni:

• Se discută cu persoanele care vor folosi baza de date pentru a obţine informaţiile necesare
pentru proiectarea ei.
• Se adună formularele care vor fi folosite în mod curent pentru introducerea datelor şi
documentele tipizate care se folosesc pentru a obţine informaţii despre datele care se
exploatează în mod curent în cadrul compartimentelor.
• Pe baza acestor documente se întocmeşte o listă cu informaţiile pe care trebuie să le conţină
baza de date şi se identifică tipul şi domeniul lor de valori.
• Se identifică perioada de stocare a datelor (o lună, un an, mai mulţi ani etc.).
• Se identifică informaţiile pe care trebuie să le furnizeze baza de date.
• Se adună rapoartele care se întocmesc de obicei în cadrul compartimentelor şi, pe baza lor, se
schiţează rapoartele care vor fi tipărite folosind informaţiile din baza de date. Se identifică
ritmul de tipărire a rapoartelor (zilnic, săptămânal, lunar etc.).
• Se examinează o bază de date existentă, bine proiectată, similară proiectului care se realizează.
Determinarea tabelelor necesare în baza de
date
Acest pas este foarte important deoarece de el depind
rezultatele care se vor putea obţine atunci când se
exploatează în mod curent baza de date (rapoartele care vor fi
tipărite, formularele folosite pentru introducerea, modificarea
şi vizualizarea datelor şi întrebările la care se pot obţine
răspunsuri folosind interogările).
Tabelele se determină împărţind informaţia pe categorii de
informaţii.
Pentru a determina ce tabele va conţine baza de
date, trebuie respectate următoarele principii:
• Fiecare tabel şi colecţia de tabele nu trebuie să conţină informaţie redundantă. Fiecare
informaţie elementară trebuie să fie memorată într-un singur tabel, într-un singur câmp
– pentru a fi actualizate într-un singur loc. În acest mod, operaţia de actualizare este mult
mai eficientă şi se elimină posibilitatea ca aceeaşi dată, memorată în mai multe locuri, să
aibă valori diferite. De exemplu, adresa şi numărul de telefon ale unui client nu se vor
memora pentru fiecare comandă, ci într-un singur loc, într-un tabel cu informaţii
generale despre clienţi (în tabelul Clienti, şi nu în tabelul Comenzi).
• Fiecare tabel trebuie să conţină o singură categorie de informaţii. Dacă fiecare tabel
conţine numai o singură categorie de informaţii, se va putea întreţine acea categorie de
informaţii independent de restul informaţiilor memorate în baza de date. De exemplu,
adresa clientului se va memora în tabelul Clienti şi nu în tabelul Comenzi deoarece,
atunci când se şterge o comandă, adresa clientului se va putea păstra în continuare, fiind
memorată în alt tabel.
Determinarea câmpurilor necesare în
tabele
Fiecare tabel conţine date referitoare la aceeaşi categorie de informaţii şi fiecare câmp din tabel conţine date
despre o informaţie elementară din acea categorie de informaţii. De exemplu, tabelul Clienti poate conţine
câmpuri pentru numele companiei, adresa, localitatea, judeţul, numele, prenumele, funcţia şi numărul de
telefon al persoanei de contact. Când se stabilesc câmpurile în care va fi divizată informaţia din tabel, trebuie
avute în vedere următoarele considerente:
• Câmpurile trebuie să fie legate direct de categoria de informaţii memorată în tabel.
• În câmpurile din tabel trebuie să fie inclusă toată categoria de informaţii pentru care se
construieşte tabelul.
• În tabel nu se vor folosi câmpuri derivate (câmpuri care conţin date ce derivă din alte câmpuri)
sau câmpuri calculate (câmpuri care conţin valori obţinute în urma evaluării unei expresii).
• Informaţia memorată în tabel se divizează în cele mai mici informaţii logice . De
exemplu, în tabelul Angajati, pentru a memora numele unui angajat se folosesc două câmpuri, unul pentru
nume şi unul pentru prenume, şi nu un singur câmp, iar în tabelele Angajati, Clienti şi Furnizori, pentru
memorarea adresei se vor folosi mai multe câmpuri: unul pentru stradă şi număr, altul pentru localitate,
altul pentru judeţ şi altul pentru codul poştal. În acest mod, folosind interogările, se poate găsi un angajat
numai după nume sau numai după prenume sau se poate obţine o listă cu clienţii sau furnizorii dintr-un
anumit oraş sau dintr-o anumită localitate.
Stabilirea câmpurilor care pot fi chei de
identificare
Pentru a lega date memorate în tabele separate din baza de date (de exemplu, pentru a lega
un client de toate comenzile făcute de el), fiecare tabel din baza de date trebuie să aibă un
câmp sau un set de câmpuri care să permită identificarea fiecărei înregistrări, adică un set de
câmpuri care să formeze cheia de identificare.
Există două tipuri de chei de identificare:
• Cheia de identificare cu un singur câmp. Atunci când există în tabel un câmp cu valoare
unică (cum este, de exemplu, în tabelul Clienti, codul companiei), el poate fi folosit pentru
cheia primară. În cazul în care nu se poate identifica în structura tabelului combinaţia de
câmpuri care să poată fi folosită pentru cheia primară, se va adăuga la structura tabelului un
câmp care va fi folosit pentru identificarea unică a înregistrărilor. Astfel, în tabelul Angajati
nu se pot folosi cele două câmpuri Nume şi Prenume pentru a identifica un angajat,
deoarece este posibil să existe doi angajaţi cu acelaşi nume şi prenume. În acest caz se
adaugă la tabel un câmp denumit Marca (identificatorul angajatului).
Tipuri de chei de identificare
• Cheia de identificare cu mai multe câmpuri. Atunci când nu se găseşte în tabel un câmp
cu valori unice, se vor folosi două sau mai multe câmpuri pentru a construi cheia primară.
Acest caz apare cel mai des în tabelele obţinute prin transformarea relaţiilor de tipul mai–
multe–la–mai–multe. Un astfel de exemplu este tabelul DetaliiComenzi care a rezultat din
transformarea relaţiei de tipul mai–multe–la–mai–multe dintre tabelele Comenzi şi
Produse. În tabelul DetaliiComenzi există mai multe înregistrări care au aceeaşi valoare
pentru câmpul număr comandă (printr-o comandă pot fi cerute mai multe produse) şi mai
multe înregistrări care au aceeaşi valoare pentru câmpul cod produs (acelaşi produs poate
fi solicitat prin mai multe comenzi). În schimb, într-o comandă, un produs nu poate să
apară decât o singură dată, astfel încât o înregistrare poate fi unic identificată folosind
pentru cheia primară cele două câmpuri: numărul comenzii şi codul produsului.
Atunci când se alege cheia primară a tabelului, trebuie să se ţină cont de faptul că în tabel
cheia primară nu poate avea valoarea Null sau valori duplicate.
Determinarea relaţiilor dintre tabele
După ce s-a împărţit informaţia în tabele şi câmpuri şi s-a identificat cheia
primară în fiecare tabel, trebuie definite relaţiile dintre tabele. De exemplu,
dacă se introduc datele corespunzătoare unui formular BonComanda, care
conţine toate informaţiile referitoare la comanda unui client, acest formular
conţine informaţii care sunt memorate în cinci tabele: Angajati (identificatorul
angajatului care a preluat comanda), Clienti (informaţiile despre client: nume,
adresa etc.), Produse (informaţii despre fiecare produs comandat: denumire,
unitate de ambalare, preţ), Comenzi (informaţii generale despre comandă:
număr, data comenzii etc.) şi DetaliiComenzi (cantitatea pentru fiecare produs
comandat). Introducerea şi prelucrarea acestor date este posibilă numai dacă
s-au definit relaţii între cele cinci tabele.
Scop: proiectarea unei baze de date mici
Proiectarea bazei de date a unei magazii de materiale
1. Determinarea scopului bazei de date
Scopul bazei de date este gestionarea mişcărilor de materiale dintr-o magazie.
Cerinţele bazei de date sunt:
Fiecare articol din magazie este identificat printr-un cod. Articolul mai are următoarele atribute:
denumire, unitate de măsură, preţ, stoc de siguranţă (stocul minim necesar desfăşurării procesului de
producţie). În funcţie de tipul articolelor, se mai pot adăuga şi alte atribute (model, culoare, mărime
etc.).
În magazie are loc o continuă mişcare de articole: unele articole intră în magazie, altele ies din magazie.
Fiecare mişcare este caracterizată de data mişcării, cantitate şi valoare. În urma unei mişcări, stocul de
articole se modifică şi poate să ajungă sub stocul de siguranţă.
Trebuie să se cunoască în orice moment situaţia stocurilor din magazie şi graficul mişcărilor de articole.
Documentele pe baza cărora are loc mişcarea de materiale sunt:
pentru intrări: factura – factura este emisă de un furnizor;
pentru ieşiri: bonul de consum – bonul de consum este emis de o
persoană responsabilă cu această activitate într-un compartiment
funcţional al companiei.

Categoriile de informaţii sunt:

Între categoriile de informaţii se stabilesc următoarele relaţii:
• un furnizor poate emite de la una până la mai multe facturi;
• factura nu poate fi emisă decât de un singur furnizor;
• într-o factură pot fi de la unul până la mai multe materiale;
• un material poate să apară în mai multe facturi;
• un compartiment poate emite de la unul până la mai multe bonuri de consum;
• bonul de consum nu poate fi emis decât de un singur compartiment;
• într-un bon de consum pot fi cerute unul sau mai multe materiale;
• un material poate să apară în mai multe bonuri de consum.
• Relaţiile dintre categoriile de informaţii sunt de tip 1-n (unu la mai multe) sau n-n (mai
multe la mai multe):
2. Determinarea tabelelor necesare în baza
de date
Pentru a putea răspunde la toate aceste cerinţe, baza de date va fi formată din următoarele tabele:
• Furnizori: conţine informaţii despre furnizorii de materiale;
• Facturi: conţine informaţii generale despre facturi;
• DetaliiFacturi: conţine informaţii detaliate despre materialele intrate în magazie prin factură (se
creează pentru a transforma relaţia de tip n–n, dintre Facturi şi Materiale, în două relaţii de tip 1–
n);
• Materiale: conţine informaţii generale despre materialele din magazie;
• Bonuri: conţine informaţii generale despre bonurile de consum;
• DetaliiBonuri: conţine informaţii detaliate despre materialele ieşite prin bonurile de consum (se
creează pentru a transforma relaţia de tip n–n, dintre Bonuri şi Materiale, în două relaţii de tip 1–
n);
• Compartimente: conţine informaţii despre compartimentele funcţionale ale companiei
3. Determinarea câmpurilor necesare în
tabele
Tabelele vor conţine următoarele câmpuri:
• Furnizori: cod furnizor (I1), denumire furnizor (C,30), adresă (M), localitate (C,20), judeţ
(C,15), cod poştal (I), cod fiscal (I), bancă (C,20), cont (I), telefon (C,10);
• Facturi: număr factură (I), dată factură (DT), cod furnizor (I);
• Detalii facturi: număr rând factură (I), număr factură (I), cod material (I), cantitate intrată
(R); preţ (R);
• Materiale: cod material (I), denumire material (C,30), unitate de măsură (C,4), stoc
siguranţă (R);
• Bonuri de consum: număr bon (I), dată bon (DT), cod compartiment (I);
• Detalii bonuri: număr rând bon (I), număr bon (I), cod material (I), cantitate ieşită (R);
• Compartimente: cod compartiment (I), denumire compartiment (C,20), nume (C,15) şi
prenume (C,15) pentru persoana responsabilă, funcţie (C,15), telefon (C,10).
4. Identificarea câmpurilor care pot fi chei
unice
Pentru a lega datele memorate în tabele separate din baza de date, fiecare tabel
are un câmp sau un set de câmpuri care să permită identificarea fiecărei
înregistrări, adică un set de câmpuri care să formeze cheia de identificare, astfel:
• Furnizori: cod furnizor;
• Facturi: număr factură;
• Detalii facturi: număr rând factură sau număr factură + cod material;
• Materiale: cod material;
• Bonuri de consum: număr bon;
• Detalii bonuri de consum: număr rând bon sau număr bon + cod material;
• Compartimente: cod compartiment.
5. Determinarea relaţiilor dintre tabele
După ce a fost împărţită informaţia în tabele şi câmpuri şi au fost
identificate cheile primare în fiecare tabel, se definesc relaţiile dintre
tabele:
 ACTIVITATE IN ECHIPA
O organizaţie păstrează evidenţa vânzărilor unor produse. Fiecare produs este
identificat printr-un cod. Produsul mai are următoarele atribute: denumire,
unitate de măsură, preţ. Stocul fiecărui produs creşte prin aprovizionarea cu noi
produse, documentul folosit fiind factura sosită de la furnizor. Stocul fiecărui
produs se micşorează în urma vânzării, documentul folosit fiind factura emisă
către client. Fiecare factură emisă unui client corespunde unei vânzări realizate de
un agent de vânzări. Fiecare agent de vânzări este identificat unic printr-un cod.
Agentul de vânzări mai are următoarele atribute: nume şi prenume. Realizaţi o
bază de date care să păstreze aceste informaţii şi care să furnizeze informaţii
despre: cantităţile vândute din fiecare produs, stocul de produse disponibile
pentru a fi vândute şi cantităţile de produse vândute de fiecare agent de vânzări.
Angajaţii unui departament trebuie să se deplaseze în diferite localităţi din ţară,
pentru rezolvarea unor probleme de serviciu. Trebuie să se ţină evidenţa
cheltuielilor de deplasare. Fiecare angajat este identificat unic printr-un cod. El
mai are atributele nume şi prenume. Fiecare operaţie de deplasare se identifică
printr
1.2 Proiectarea bazelor de date medii şi
mari
O bază de date medie este sursa informaţională a unui subsistem
informatic, iar o bază de date mare este sursa informaţională a unui
sistem informatic. Ele conţin informaţii foarte complexe şi trebuie să
furnizeze la rândul lor informaţii foarte complexe.
Pentru proiectarea acestor baze de date se porneşte de la modelul
conceptual al aplicaţiei de gestiune care va fi transformat în tabele şi
relaţii dintre tabele.
Pentru această transformare se aplică următoarele reguli:
1) O entitate devine un tabel. Identificatorul entităţii devine cheie primară, iar
atributele entităţii devin câmpuri în tabel.
2) O asociere ierarhică devine o relaţie, astfel:
a) Entitatea care în asociere are conectivitatea maximă 1 va fi tabelul condus, iar cealaltă
entitate va fi tabelul conducător.
b) Cheia primară a tabelului conducător va fi cheie secundară în tabelul condus.
c) Dacă asocierea are atribute proprii, acestea vor deveni câmpuri în tabelul conducător.
3) O asociere non-ierarhică devine un tabel, astfel:
a) Atributele proprii ale asocierii vor fi câmpuri în acest tabel. La aceste câmpuri se
adaugă identificatorii entităţilor care participă la asociere. Cei doi identificatori vor
forma cheia de identificare pentru acest tabel.
b) Cele două entităţi care participă la asociere vor fi tabele conducătoare, iar tabelul
provenit din asociere va fi tabel condus. Cheia primară a fiecărui tabel conducător va
fi cheie secundară în tabelul condus.
Scop: proiectarea unei baze de date medii
Proiectarea bazei de date
folosind modelul
conceptual al aplicaţiei de
gestiune
1. Transformarea entităţilor în tabele:
2. Transformarea asocierilor ierarhice în
relaţii:
Se adaugă la tabelele conduse cheile secundare, care vor fi subliniate cu
o linie, spre deosebire de cheile primare care sunt scrise îngroşat.
2. Transformarea asocierilor ierarhice în
relaţii:
Se stabilesc relaţiile între tabele:
1. Transformarea asocierilor non-ierarhice în
tabele şi relaţii:
Se obţin tabelele:

şi relaţiile:
ACTIVITATE DE ECHIPA
Realizaţi bazele de date la nivel logic pornind de la modelele
conceptuale realizate pentru subsistemele informatice pentru
compania care asigură consultanţă, pentru an, pentru biblioteca
universitatii, pentru secretariatul facultatii, pentru examenul de licenta
şi pentru magazia cu materiale sportive a universitatii.
Intrebari!
 APLICATIA DE GESTIUNE

Aplicaţia de gestiune creează un sistem informatic pentru un

subsistem al organizaţiei sau pentru întreaga organizaţie.

Primul pas în realizarea aplicaţiei de gestiune este crearea modelului

conceptual
Pentru realizarea modelului conceptual se parcurg următorii paşi:

1. Se analizează fluxul operaţional şi fluxul informaţional şi se identifică

caracteristicile procesului informaţional.
2. Pe baza caracteristicilor identificate se stabilesc regulile de
gestiune.
3. Pe baza regulilor de gestiune se stabilesc entităţile cu lista de
atribute şi identificatorii, asocierile cu colecţia de entităţi şi
proprietăţi, rolul entităţilor în asociere şi conecti- vităţile asocierilor.
4. Pe baza entităţilor şi asocierilor definite se stabilesc restricţiile de
integritate.
5. Se realizează schema modelului conceptual
Restricţiile de integritate sunt reguli pe care trebuie să le respecte în
permanenţă instanţele entităţilor şi ale asocierilor.
• Reguli:
• Valorile identificatorului entităţii trebuie să fie unice în mulţimea de instanţe ale entităţii. De exemplu, nu
trebuie să existe două instanţe ale entităţii Angajat cu aceeaşi valoare a atributului identificator Marcă.
• Identificatorul unei instanţe a entităţii trebuie să nu fie nul (trebuie obligatoriu să aibă o valoare). De
exemplu, pentru o instanţă a entităţii Angajat este posibil ca atributul Telefon să nu aibă o valoare
(atributul este nul deoarece angajatul nu are telefon), dar este obligatoriu ca atributul Marcă folosit ca
identificator să aibă o valoare.
• O instanţă a unei asocieri nu poate exista dacă nu există instanţe ale entităţilor care participă la asociere.
• Trebuie respectate restricţiile de domeniu de valori ale atributelor (de exemplu, data facturii nu trebuie
să fie anterioară datei curente sau cantitatea facturată trebuie să fie strict pozitivă sau nota unui elev nu
poate lua decât valori întregi între 1 şi 10).
• Trebuie respectate corelaţiile dintre valorile atributelor entităţilor şi atributele asocierilor (de exemplu,
valoarea atributului CantitateFacturată a asocierii Se facturează pentru o instanţă a entităţii
ArticolÎmbrăcăminte nu trebuie să fie mai mare decât a valorii atri- butului CantitateStoc a entităţii Stoc
pentru aceeaşi instanţă a entităţii ArticolÎmbrăcă- minte sau valoarea atributului Reţineri nu trebuie să fie
mai mare decât un procent din valoarea atributului TotalSalariu a aceleiaşi instanţe a entităţii Angajat).
• Atunci când o entitate participă la mai multe asocieri trebuie respectate restricţiile impuse de relaţiile
dintre rolurile entităţii
Asocierile pot fi:
• Asocieri ierarhice – sunt asocieri în care există o conectivitate maximă
egală cu 1. De obicei nu au atribute proprii. Ele implică restricţii de
integritate funcţională.
• Asocieri non-ierarhice – sunt asocieri în care ambele conectivităţi
maxime au valoarea n. De obicei au atribute proprii. Ele implică
restricţii de integritate multiplă.
Relaţiile dintre rolurile unei entităţi
Dacă o entitate participă la două asocieri, va avea două roluri: unul faţă de prima
asociere (Rol1) şi unul faţă de cea de a doua asociere (Rol2). Între cele două roluri se
poate stabili una dintre relaţiile:
• €Relaţia de incluziune – rolul Rol1 al entităţii într-o asociere impune rolul Rol2 al
entităţii într-o altă asociere (o instanţă a entităţii nu poate avea rolul Rol2 în cea de
a doua asociere, dacă nu a avut rolul Rol1 în prima asociere Se notează: Rol1 | Rol2
• Relaţia de excluziune – cele două roluri ale entităţii Rol1 şi Rol2 se exclud reciproc
(nu pot să existe amândouă pentru aceeaşi instanţă a entităţii). Se notează: Rol1 #
Rol2.
• Relaţia de egalitate – între cele două roluri ale entităţii Rol1 şi Rol2 nu există
restricţie de incluziune (o instanţă a entităţii poate avea rolul Rol1, independent de
existenţa rolului Rol2, şi invers). Se notează: Rol1 = Rol2.
Exemple:
Relaţia de incluziune. Un client al fabricii trimite un bon de comandă
pentru un grup de articole de îmbrăcăminte şi aceste articole îi sunt
livrate în baza unui bon de livrare. În această activitate intervin trei
entităţi: Client, BonComandă şi BonLivrare şi două asocieri: Trimite între
entitatea Client şi entitatea BonComandă şi Determină între
BonComandă şi BonLivrare. Entitatea BonComandă participă la ambele
asocieri: la prima cu rolul Este trimis şi la a doua cu rolul Determină.
Cele două roluri sunt în relaţia de incluziune deoarece entitatea
BonComandă nu poate avea rolul Determină dacă nu a avut rolul Este
trimis
Relaţia de excluziune. Firma care vinde şi închiriază autoturisme încasează de la client
contravaloarea autoturismului sau a serviciului de închiriere în baza unui document de încasare. În
această activitate intervin două entităţi Autoturism şi DocumentÎncasare şi două asocieri între cele
două entităţi: Conţine1, cu atributele NumărAutoturismeÎnchiriate şi TarifÎnchiriere, şi asocierea
Conţine2, cu atributele NumărAutoturismeVândute şi PreţVânzare. Rolul entităţii Autoturism în
asocierea Conţine1 este Se închiriază, iar în asocierea Conţine2 este Se vinde. Cele două roluri
sunt în relaţia de excluziune deoarece entitatea Autoturism nu poate avea în acelaşi timp şi rolul Se
vinde şi rolul Se închiriază (un autoturism nu poate fi şi vândut şi închiriat).
Relaţia de egalitate. Firma care vinde articole de îmbrăcăminte livrează
articole unui client pe baza unui bon de livrare. Preţul de livrare al
fiecărui articol este păstrat într-un catalog în care este înregistrată şi
data limită pentru acele preţuri. În această activitate intervin trei
entităţi, Catalog, Articol şi BonLivrare şi două asocieri, Se vinde (cu
atributul PreţVânz), între entitatea Catalog şi entitatea Articol, şi
Conţine, între entităţile Articol şi BonLivrare. Entitatea Articol participă
la ambele asocieri: la prima cu rolul Este vândut şi la a doua cu rolul
Este livrat. Cele două roluri sunt în relaţia de egalitate deoarece
entitatea Articol se vinde cu preţul din catalog până la date limită,
indiferent dacă este livrat sau nu unui cllient, şi este livrat unui client
indiferent de preţul cu care se vinde.
Scop: Realizarea modelului conceptual al unei aplicaţii de gestiune.
Enunţul problemei: Se realizează subsistemul de facturare al compartimentului Distri- buţie al unei fabrici care
produce articole de îmbrăcăminte.
Pasul 1. Analizând fluxurile operaţionale şi informaţionale s-au constatat următoarele:
• Fabrica produce articole de îmbrăcăminte care se împart în două categorii: articole de îmbrăcăminte pentru femei
şi articole de îmbrăcăminte pentru bărbaţi.
• Fabrica are 1500 de clienţi fideli. Există trei categorii de clienţi: magazine, depozite en-gros şi firme de export.
• Fabrica are un catalog de produse în care sunt înregistrate aproximativ 3000de modele. Preţurile din catalog sunt
valabile 3 luni. Catalogul de produse se reactua- lizează trimestrial.
• Compartimentul Distribuţie are 5 posturi de lucru. Fiecare post de lucru are propriul său stoc de articole de
îmbrăcăminte şi primeşte comenzile de la clienţii proprii.
• Facturile de la cele cinci puncte de lucru sunt centralizate la sediul fabricii, la compartimentul Distribuţie.
• Pentru fiecare bon de comandă al unui client pot fi emise mai multe bonuri de livrare (în funcţie de articolele care
există în stoc).
• Pentru fiecare bon de livrare se emite o factură. Preţul de facturare este cel de la data la care a fost emis bonul de
comandă.
• La nivelul organizaţiei există subsisteme informatizate printre care şi subsistemul Contabi- litate. Aceste subsisteme
folosesc o reţea de calculatoare instalate la sediul fabricii.
• Fiecare post de lucru va fi dotat cu un microcalculator care va fi conectat la
reţeaua de calculatoare.
• Sistemul conducător doreşte ca, pentru reducerea costurilor, prin sistemul
informatic facturarea clienţilor să se facă lunar (se emite o singură factură
pentru un client pentru toate bonurile de livrare dintr-o lună).
• Sistemul conducător are nevoie de următoarele informaţii:
• situaţii statistice lunare (pe ultimele 12 luni) pe posturi de lucru, pe clienţi (cu
• evidenţiere pe fiecare categorie de clienţi) şi pe articole de îmbrăcăminte (cu
• evidenţiere pe fiecare categorie de articole);
• situaţii statistice anuale (pe ultimii 5 ani) pe posturi de lucru, pe clienţi (cu
• evidenţiere pe fiecare categorie de clienţi) şi pe articole de îmbrăcăminte (cu
evidenţiere pe fiecare categorie de articole);
Pasul 2. Pe baza analizei făcute se stabilesc următoarele reguli de
gestiune:
• Un client aparţine unei singure categorii.
• Un client lucrează numai cu unul dintre posturile de lucru.
• Un client poate să emită unul sau mai multe bonuri de comandă.
• Un bon de comandă este emis de un singur client.
• Un bon de comandă poate determina mai multe bonuri de livrare.
• Un bon de livrare este emis în baza unui singur bon de comandă.
• Un articol de îmbrăcăminte aparţine unei singure categorii.
• Catalogul cu articole de îmbrăcăminte este actualizat trimestrial.
• Un bon de comandă poate conţine unul sau mai multe articole de
îmbrăcăminte.
• Un articol de îmbrăcăminte poate să apară într-un bon de comandă, sau nu.
• Un bon de livrare poate conţine unul sau mai multe articole de îmbrăcăminte.
• Un articol de îmbrăcăminte poate să apară într-un bon de livrare, sau nu.
• Un bon de livrare generează o singură factură.
• O factură poate corespunde la mai multe bonuri de livrare.
• Tarifele de facturare corespund datei la care a fost emis bonul de comandă în baza căruia s-
a emis bonul de livrare.
• Fiecărui articol de îmbrăcăminte îi corespunde un singur procent pentru TVA.
• Situaţiile statistice lunare cerute de sistemul conducător se realizează lunar şi se arhivează
pe o perioadă de 12 luni.
• Situaţiile statistice anuale cerute de sistemul conducător se realizează anual şi se arhivează
pe o perioadă de 5 ani.
• Se obţine lunar jurnalul de vânzări care este necesar subsistemului Contabilitate.
• O factură se emite o singură dată pe lună pentru un client care a trimis cel puţin o
comandă.
• Este posibil ca facturarea să se facă după livrare.
şi se stabilesc următoarele restricţii:
• Fiecare client trebuie să aparţină unei categorii de clienţi şi unui post
de lucru.
• Fiecare bon de livrare trebuie să fie generat de un bon de comandă şi,
la rândul său, trebuie să corespundă unei facturi.
• Fiecare factură trebuie să fie emisă unui client.
• Mărimea unui articol de îmbrăcăminte trebuie să aparţină domeniului
[34,56]
Pasul 3.
Pe baza reguli de gestiune se stabilesc entităţile cu lista de atribute şi
identi- ficatorii, asocierile cu colecţia de entităţi şi proprietăţile şi
conectivităţile. Numele de entităţi şi atribute trebuie să fie unice.

Pentru entităţi s-au folosit nume sugestive: Post (post de lucru), CategClient (categoria clientului),
Articol (articol de îmbrăcăminte), CategArticol (categoria articolului de îmbră- căminte). Pentru
atributele proprietăţilor s-au folosit nume sugestive: IdPost (identificator post), IdCatClient (identificator
categorie client), DenCatClient (denumire categorie client), IdCatArt (identificator categorie articol
îmbrăcăminte) şi DenCatArt (denumire categorie articol îmbrăcăminte).
Asociere:

Pentru atributele asocierilor s-au folosit nume sugestive: CantCom (cantitate comandată),
CantLivr (cantitate livrată) şi PretVânz (preţ de vânzare).
Asocierea Aparţine1

• Fiecare client aparţine obligatoriu unei categorii de clienţi (1), dar numai unei singure categorii
de client (1).
• Unei categorii de client îi corespunde cel puţin un client (1) sau mai mulţi clienţi (n).
Asocierea Aparţine2
• Fiecare articol de îmbrăcăminte aparţine obligatoriu unei categorii de articole (1), dar numai
unei singure categorii de articole (1).
• Unei categorii de articol îi corespunde cel puţin un articol (1) sau mai multe aticole (n).
Asocierea Se înregistrează
• La un post de lucru poate să nu fie înregistrat niciun client (0) sau mai mulţi clienţi (n).
• Fiecare client aparţine obligatoriu unui post de lucru (1), dar numai unui singur post de lucru (1).
• Asocierea Trimite
• Un client poate să nu trimită niciun bon de comandă (0), sau să trimită mai multe bonuri de
comandă (1).
• Un bon de comandă este emis obligatoriu de un client (1) şi numai unul (1).
Asocierea Conţine1

• Un bon de comandă poate să conţină un singur articol de

îmbrăcăminte (1) sau mai multe (n).
• Este posibil ca într-o perioadă de timp un articol de îmbrăcăminte să
nu fie solicitat de niciun client – nu apare în niciun bon de comandă
(0) – sau să fie solicitat de mai multe bonuri de comandă (n).
Asocierea Determină
• Un bon de comandă poate să nu fie onorat – nu se emite un bon de
livrare (0) – sau poate fi onorat în mai multe etape – se emit mai
multe bonuri de livrare (n).
• Un bon de livrare este emis obligatoriu pentru a onora un bon de
comandă (1) şi numai unul (1).
Asocierea Conţine2
• Un bon de livrare poate să conţină un singur articol de îmbrăcăminte (1) sau
mai multe (n).
• Este posibil ca într-o perioadă de timp un articol de îmbrăcăminte să nu fie
livrat – nu apare în niciun bon de livrare (0) – sau să fie livrat prin mai multe
bonuri de livrare (n).
Asocierea Corespunde
• Un bon de livrare poate să nu fie încă facturat – nu corespunde niciunei facturi
(0) – sau să fi fost facturat – este facturat într-o singură factură (1).
• O factură a fost emisă pentru cel puţin un bon de livrare (1) sau mai multe (n).
Asocierea Se vinde
• Data limită din catalog indică un singur preţ de vânzare (1) sau mai multe (n).
• Un articol a fost vândut cu un singur preţ (1) sau cu mai multe (n).
Asocierea Se trimite
• Pentru un client nu se emite nicio factură – nu a făcut o comandă sau nu i-a fost livrată nicio
comandă (0) – sau au fost emise mai multe facturi (n).
• O factură se emite obligatoriu pentru un client (1) şi numai unul (1).
Asocierea Se emite
• Un post de lucru poate să nu fi emis nicio factură – nu a făcut o nicio livrare (0) – sau a emis
mai multe facturi (n).
• O factură este emisă obligatoriu de un post de lucru (1) şi numai de unul (1).
Asocierea Aparţine4
• Într-o lună a anului curent nu a fost emisă nicio factură (0) sau au fost emise mai multe (n).
• O factură nu a fost emisă într-o lună a anului curent (0) sau a fost emisă într-o lună a anului
curent (1).
Asocierea Aparţine5
• Într-un an al perioadei nu a fost emisă nicio factură (0) sau au fost emise mai multe (n).
• O factură nu a fost emisă într-un an al peroadei (0) sau a fost emisă într-un an al perioadei (1).
Pasul 4.
Se stabilesc restricţiile de integritate. De exemplu, un bon de comandă
nu poate determina un bon de livrare dacă bonul de comandă nu a fost
emis de un client.
Pasul 5.
Se realizează schema modelului conceptual.