Laborator 4 - USIE

MODELAREA LOGICĂ A DATELOR

Proiectarea corectă a structurii unei baze de date relaţionale este o premisă

fundamentală în scrierea programelor de aplicaţie şi in functionarea lor fara
anomalile care pot apare in cazul unei structuri defectuoase. Acest capitol prezinta
un model de date folosit in proiectarea conceptuala de nivel inalt numit modelul
entitate asociere (EA) in varianta clasica (cu unele extensii). Intr-un alt capitol vor fi
prezentate regulile de transformare din modelul entitate-asociere in modelul
relational.

1. Etapele dezvoltarii unei aplicatii

Proiectarea structurii bazelor de date relationale este un domeniu in care cercetarile

au evoluat spre elaborarea unor metodologii teoretice şi a unor instrumente
software care asigura un grad ridicat de normalizare a schemelor de relatie,
pastrarea integritatii, evitarea anomaliilor datorate unei proiectari nesistematice şi
eliminarea subiectivismului proiectantului prin inlocuirea lui cu exactitatea metodei.

Pana la aparitia unor astfel de metodologii se pornea de la o colectie de tabele şi de

la dependentele functionale şi multivalorice asociate şi se ajungea, prin aplicarea
unor algoritmi sau metode de normalizare la schema dorita a bazei de date. Aceasta
abordare de tip bottom-up creaza insa dificultati in cazul bazelor de date complexe
in care numarul de tabele şi de dependente este mare. Probabilitatea ca unele
interdependente intre date sa nu fie sesizate in procesul de proiectare este in aceste
cazuri ridicat rezultand in exploatare anomalii care duc la reluari ale ciclului analiza
cerintelor → schema bazei de date → programe de aplicatie.

Cercetarile in domeniul proiectarii schemei conceptuale s-au concentrat pe gasirea

unor metodologii top-down pentru obtinerea unei structuri optime a BD. Ele au fost
influentate de rezultatele obtinute in domenii care folosesc bazele de date:
inteligenta artificiala, proiectarea asistata de calculator, abordarea orientata pe
obiecte.

1
Impactul conceptelor de abstractizare şi generalizare precum şi elaborarea unui
model de descriere informala a datelor, şi anume modelul entitate-asociere (EA), au
dus la gasirea unor cai algoritmizabile de proiectare optima a bazelor de date.
Modelul entitate-asociere este in acest moment cel mai popular model de
comunicare a structurii bazelor de date datorita intuitivitatii şi simplitatii
elementelor sale. Imbunatatiri sale ulterioare prin folosirea abstractizarilor şi
generalizarilor au dus la crearea de variante ale modelului, doua dintre acestea fiind
descrise in acest capitol.

Extensiile modelului EA au aparut şi pentru alte necesitati:

• modelarea cerintelor de secretizare a datelor,
• documentarea programelor de aplicatie şi usurarea comunicarii intre
proiectantul de sistem şi utilizatorul obisnuit,
• proiectarea bazelor de date complexe pe portiuni şi integrarea ulterioara
a acestora (asa numita integrare a vederilor).

Avantajul principal al modelului EA este acela al simplitatii sale şi al caracterului sau

intuitiv. Rezultatul proiectarii consta intr-o diagrama entitate-asociere care poate fi
apoi translatata in modelul de date folosit de sistemul de gestiune a bazelor de date
ales pentru dezvoltarea aplicatiei.

Figura 2.1. prezinta schematic etapele proiectarii unei noi aplicatii care gestioneaza
o baza de date, cu accentul pe partea de proiectare a structurii acesteia. Aceste etape
sunt detaliate in paragrafele urmatoare.

1.1. Analiza de sistem

In aceasta etapa se realizeaza analiza segmentului din lumea reala care va fi gestionat
de aplicatia respectiva. Rezulta o specificatie neformalizata a cerintelor constand din
doua componente:

1. Cerinte privind continutul bazei de date: categoriile de date care vor fi stocate
şi interdependentele dintre acestea.
2. Cerinte privind prelucrarile efectuate de aplicatie: prelucrarile efectuate
asupra datelor, arborele de meniuri al aplicatiei, machetele formatelor de
introducere şi prezentare a datelor şi ale rapoartelor tiparite de aceasta.

In general aceasta etapa nu poate fi asistata prin programe de tip CASE dar exista
reguli care ajuta proiectantul in realizarea sa. Activitatile desfasurate includ:
• Analiza activitatii desfasurate la momentul respectiv de beneficiarul aplicatiei sau
de o multime reprezentativa de beneficiari in cazul aplicatiilor de uz general.
• Analiza continutului de date şi a functionalitatii aplicatiilor software - daca exista
- care vor fi inlocuite de noua aplicatie incluzand meniuri, machete ecran şi
machete de rapoarte.

2
• Analiza formularelor tipizate şi a altor documente utilizate de beneficiar pentru
realizarea activitatii respective.
• Identificarea tuturor interdependentelor dintre datele care vor fi stocate in baza
de date şi a restrictiilor privind valorile pe care le pot lua anumite categorii de
date. • Identificarea - daca este cazul - a prelucrarilor care se declanseaza
automat atat in cazul modificarii bazei de date cat şi la momente prestabilite de
timp (de exemplu sfarsit de luna, de an, etc.)
• Identificarea operatiilor care sunt necesare beneficiarului in activitatea curenta
dar care in acest moment nu sunt realizate prin intermediul aplicatiilor software
folosite precum si a operatiilor care pot fi incluse in mod natural in noua aplicatie.

3
Fig. 1. Etapele proiectării unei aplicaţii

4
• Identificarea bazelor de date existente care pot fi folosite de noua aplicatie -
direct sau printr-un import initial de date - evitandu-se in acest fel reintroducerea
manuala a acestora.
• Identificarea modalitatilor de transfer de date intre noua aplicatie şi alte aplicatii
care ruleaza deja la beneficiar şi care vor fi folosite şi in viitor de catre acesta.
• Identificarea necesitatilor privind datele şi prelucrarile care pot fi in viitor
necesare beneficiarului, deci a posibilelor dezvoltari in timp ale aplicatiei.

Aceasta etapa este efectuata de personal calificat avand in vedere ca rezultatele sale
sunt baza de la care se pleaca in etapele urmatoare, eventualele erori putand fi
corectate ulterior cu costuri semnificative.

1.2. Proiectarea conceptuală a bazei de date

In aceasta etapa, pornind de la rezultatele analizei de sistem, se realizeaza modelarea

cerintelor privind datele folosind un model de nivel inalt. Cel mai popular model
folosit pentru aceasta este modelul entitate-asociere (EA). Actualmente exista pe
piata numeroase instrumente CASE care folosesc diverse variante ale modelului.
Motivele pentru care a fost ales sunt urmatoarele:
• Nu este legat direct de nici unul dintre modelele folosite de sistemele de
gestiune a bazelor de date (relational sau orientat obiect) dar exista algoritmi
bine pusi la punct de transformare din model EA in celelalte modele de date.
• Este intuitiv, rezultatul modelarii fiind o diagrama care defineste atat datele
stocate in baza de date cat şi interdependentele dintre acestea.
• Poate fi usor de inteles de nespecialisti. Aceasta caracteristica este foarte
importanta in momentul in care se face punerea de acord cu beneficiarul asupra
structurii bazei de date a aplicatiei, evitandu-se in acest fel o proiectare
neconforma cu realitatea sau cu cerintele exprimate de acesta.
• Proiectarea se poate face pe portiuni, diagramele partiale rezultate putand fi
apoi integrate pe baza unor algoritmi şi metode bine puse la punct.

1.3. Transformare în model relaţional

In aceasta etapa entitatile şi asocierile care formeaza diagrama EA se transforma pe

baza unor reguli clare in structura relationala a bazei de date. Rezulta schema
preliminara a acesteia formata din tabele (relatii in terminologia relationala),
coloanele acestora (atribute ale relatiilor) şi constrangerile de integritate care pot fi
deduse automat din diagrama incluzand unele interdependente intre date numite şi
dependente functionale. In cursul 3 este descrisa o metoda de transformare din
modelul EA clasic in modelul relational. In cazul variantei specifice uneltelor CASE
transformarea se face automat de catre acestea.

1.4. Normalizare

Exista o serie de reguli care descriu ce inseamna o structura corecta a unei tabele şi
care definesc asa numitele forme normale. Pe baza structurii bazei de date şi a

5
dependentelor rezultate atat din transformarea in model relational cat şi a altor
dependente identificate de proiectant in analiza de sistem se poate face o operatie
numita normalizare modificand structura bazei de date astfel incat toate tabelele
din aceasta sa fie in forma normala dorita. Cursul 3 contine definitia formelor
normale uzuale şi descrierea unor algoritmi de normalizare care sunt folositi de
uneltele CASE pentru efectuarea automata a operatiei.

1.5. Implementarea specifică sistemului de gestiune folosit

In aceasta etapa se realizeaza crearea structurii bazei de date obtinuta in etapa

precedenta pe baza facilitatilor oferite de sistemul de gestiune a bazelor de date ales.
Rezultatul ei este programul de creare scris in limbajul de definitie a datelor acceptat
de SGBD-ul utilizat. Iata un exemplu:
Schema conceptala:
Student(CodStudent:Numeric, Nume:Şir, DataNasterii:Dată)
Program de creare (SQL):
Create table Student(
CodStudent Number(5) Primary Key,
Nume Varchar2(40),
DataNasterii Date);
Programul contine atat definirea tabelelor cat şi definirea celorlalte obiecte ale bazei
de date şi a interdependentelor dintre acestea (de exemplu constrangerile de
integritate intratabela şi inter-tabele).
De asemenea aici se fac şi toate operatiile privind proiectarea la nivel fizic a bazei de
date. In cazul folosirii de unor unelte CASE programul de creare poate fi generat şi
executat automat.

Prezentam in continuare elementele care definesc modelul entitate asociere in cele

doua variante: clasic şi specific instrumentelor CASE.

2. Modelul Entitate-Asociere clasic

Acest model a fost introdus de P. P. Chen in 1976 ([Ch 76]). El se constituie intr-o
abordare de tip grafic a proiectarii bazelor de date si a fost adoptat de comunitatea
stiintifica precum si de producatorii de software in domeniu datorita simplitatii si
expresivitatii sale.

2.1. Elementele modelului

Modelul entitate-asociere permite reprezentarea informatiilor despre structura

bazelor de date folosind trei elemente de constructie: entitati, atribute ale entitatilor
şi asocieri intre entitati. Definitia lor informala este urmatoarea:

Entitatile modeleaza clase de obiecte concrete sau abstracte despre care se

colecteaza informatii, au existenta independenta şi pot fi identificate in mod unic.

6
Exemple de entitati: Studenti, Orase, Angajati, etc. Ele definesc de obicei persoane,
amplasamente, obiecte sau evenimente cu importanta informationala. Membrii unei
clase care formeaza o astfel de entitate poarta numele de instante ale acelei entitati.
De remarcat ca intreaga literatura de specialitate defineste intii conceptul de
multime de entitati (sau tip de entitati) pentru ca apoi sa adopte pentru usurinta
exprimarii prescurtarea de entitate pentru acest concept. Deci entitatea este un
obiect generic care reprezinta multimea tuturor instantelor sale.
Entitatile sunt de doua categorii:
1. Entitati independente (sau tari) sunt cele care au existenta independenta de alte
entitati,
2. Entitati dependente (sau slabe) sunt formate din instante care isi justifica
incadrarea in clasa respectiva doar atita timp cit intr-o alta entitate (tata) exista
o anumita instanta de care sunt dependente. De exemplu in cazul unei baze de
date de personal, fiecare instanta a entitatii COPII ramine in clasa respectiva
(copiii angajatilor) atit timp cit in entitatea ANGAJATI exista instanta
reprezentand pe tatal/mama acelui copil.

Fig. 2. Conventia de reprezentare a elementelor modelului EA

7
Atributele modeleaza proprietati atomice distincte ale entitatilor. De exemplu
entitatea STUDENTI poate avea ca atribute Matricola, Nume, Prenume, Varsta, Anul,
Grupa, etc. In procesul de modelare vor fi luate in considerare doar acele proprietati
ale entitatilor care sunt semnificative pentru aplicatia respectiva. Din acest motiv, la
entitatea STUDENTI nu vom lua in considerare caracteristici ca Talia sau
Culoarea_parului acestea nefiind necesare pentru baza de date a universitatii (astfel
de atribute ar putea exista de exemplu intr-o baza de date privind personalul militar).

Atributele unei entitati sunt de doua feluri:

• atributele de identificare (formand impreuna identificatorul entitatii) reprezinta
acea multime de atribute care permit distinctia intre instantele aceleiasi entitati
• atributele de descriere (sau descriptori) sunt folositi pentru memorarea
caracteristicilor suplimentare ale instantelor.
In exemplul de mai sus Matricola este atribut de identificare (deoarece nu pot exista
doi studenti cu aceeasi matricola intr-o facultate) pe cand celelalte atribute sunt
descriptori.

Asocierile modeleaza interdependentele dintre clasele de obiecte reprezentate prin

entitati. De exemplu intre entitatile STUDENTI şi FACULTATI se poate figura o
asociere INSCRIS_LA care descrie impartirea studentilor pe facultati.
In crearea diagramei nu vor fi luate in consideratie decit interdependentele care sunt
necesare aplicatiei respective, in lumea reala putand exista intre entitatile diagramei
şi alte asocieri care nu sunt semnificative in contextul dat.

Figura 2. prezinta conventia de reprezentare grafica a celor trei tipuri de constructii

care participa la formarea unei diagrame EA. Se observa ca:

• Entitatile se reprezinta prin dreptunghiuri in care este inscris numele entitatii. In

cazul entitatilor dependente (slabe), conturul va fi cu linie dubla.
• Atributele se reprezinta prin cercuri (sau ovale) in interiorul carora apare numele
atributului. Ele sunt conectate cu un segment de dreapta la entitatea de care
apartin. Pentru a distinge atributele de identificare de cele de descriere, numele
primelor va fi subliniat.
• Asocierile se reprezinta prin romburi (daca conecteaza una sau doua entitati) sau
poligoane regulate (daca conecteaza mai mult de doua entitati) conectate prin
segmente de dreapta la entitatile asociate, avand inscris in interior (sau alaturi)
numele asocierii. Alte elemente grafice specificand caracteristici suplimentare ale
asocierilor vor fi introduse in paragrafele urmatoare.

2.2 Extensii ale modelului

Modelul entitate-asociere clasic are unele lipsuri in ceea ce priveste posibilitatea

modelarii caracteristicilor asociate unor subclase de obiecte modelate prin simple
entitati. Pentru aceasta, la modelul original au fost adaugate doua noi concepte:
ierarhia de generalizare şi ierarhia de incluziune. Prima defineste partitionarea
instantelor unei entitati in n subclase diferite iar a doua permite clasarea unora

8
dintre instantele unei entitati in m subclase care nu reprezinta o partitie in sens
matematic. Din punct de vedere formal, cele doua concepte se pot defini astfel:

Definitie (ierarhia de incluziune): O entitate E1 este o submultime a entitatii E (sau

este inclusa in entitatea E) daca fiecare instanta a lui E1 este de asemenea o instanta
a lui E.
Un exemplu de incluziune este definirea in cadrul entitatii ANGAJATI a unor subclase
modelate prin entitatile INGINERI, ECONOMISTI si COLABORATORI.
In cazul ierarhiei de incluziune entitatile fiu pot sa nu fie disjuncte doua cite doua:
pentru exemplul dat, exista angajati ingineri si care sunt incadrati cu contract de
colaborare. De asemenea reuniunea lor poate sa nu acopera in intregime entitatea
tata: exista angajati care nu sunt nici ingineri, nici economisti si nici colaboratori.

Definitie (ierarhia de generalizare): O entitate E este generalizarea entitatilor E1, E2,

..., En daca orice instanta a lui E este de asemenea instanta in una şi numai una din
entitatile E1, E2, ..., En.
Un exemplu de generalizare este clasarea instantelor entitatii ANGAJATI in subclasele
BARBATI şi FEMEI.
Caracteristica ierarhiei de generalizare este ca din punct de vedere matematic
entitatile fiu reprezinta o partitie a entitatii tata:
a. E1 ∪ E2 ∪ ... ∪ En = E şi
b. Ei ∩ Ej = ∅ pentru orice i ≠ j din intervalul 1..n

Ierarhiile de incluziune şi generalizare se folosesc doar in cazul in care pentru

subclasele unor clase modelate prin entitati este nevoie de stocarea unor informatii
suplimentare specifice.
In cazul unei baze de date de personal este nevoie de exemplu sa fie memorat
numarul de copii ai fiecarui angajat. Acest fapt se poate modela in doua feluri: fie
prin adaugarea la entitatea ANGAJATI a unui atribut suplimentar NumarCopii (care
va avea valoarea 0 pentru angajatii fara copii) fie prin aparitia unei entitati
suplimentare CU_COPII aflata intr-o relatie de incluziune cu entitatea ANGAJATI şi
care va avea ca atribute de identificare pe cele ale tatalui iar ca atribut descriptiv
numarul de copii, acesta fiind atributul specific subclasei.

9
 Element Reprezentare Exemplu
Ierarhie de
incluziune

Economisti

Ierarhie de
generalizare

Fig. 3. Conventia grafica de reprezentare grafica a ierarhiilor

Vom alege a doua varianta in cazul in care numarul angajatilor cu copii este mult mai
mic decit numarul total al angajatilor, fapt care va duce la economie de spatiu pe
disc: in acest caz o noua entitate - din care va rezulta o tabela a bazei de date – va
ocupa mai putin spatiu decat un atribut suplimentar - din care rezulta o coloana
suplimentara a tabelei SALARIATI.
Conventia grafica de reprezentare a celor doua tipuri de ierarhii se gaseste in fig. 3.

2.3. Caracteristici ale elementelor modelului

Asa cum entitatile au atribute care specifica diversele proprietati ale clasei de obiecte
modelate, şi asocierile au caracteristici care aduc informatii suplimentare. Acestea
sunt urmatoarele:

Gradul asocierii

Este o valoare numerica intreaga si este dat de numarul de entitati care participa la
acea asociere. Asocierile de grad 1, 2 şi 3 se mai numesc si asocieri unare, binare si
respectiv
ternare.

10
Pentru exemplificare vom considera o baza de date continand informatii despre
studenti, proiectele realizate de acestia, calculatoarele pe care au alocate ore de
lucru si facultatile la care sunt inscrisi. De asemenea vom considera ca unii dintre
studenti au un tutor care ii indruma, acesta fiind un student dintr-un an mai mare.
Diagrama EA a bazei de date este prezentata in figura 4. Pentru simplificarea figurii,
nu s-au reprezentat decit entitatile şi asocierile dintre ele nu şi atributele fiecarei
entitati in parte.

Fig. 4. Exemple de asocieri de grad 1, 2 si 3

Asocierea TUTOR este o asociere unara deoarece la ea participa doar entitatea

STUDENT. Aceasta asociere arata cine este tutorul fiecarui student (daca exista).
Asocierea INSCRIS_LA este o asociere binara intre entitatile STUDENT şi
FACULTATE si arata la ce facultate/facultati este inscris fiecare student.
Asocierea ALOCARE este o asociere ternara intre entitatile STUDENT, PROIECT şi
CALCULATOR. Ea modeleaza pe ce calculatoare are alocate ore de lucru fiecare
student pentru fiecare proiect.

Un exemplu de asociere de grad mai mare ca trei este orarul unui an de studiu al unei
facultati. Acesta este o asociere intre urmatoarele entitati:
• GRUPE. Fiecare grupa are un cod unic.
• SALI. Salile sunt etichetate printr-un indicativ alfanumeric.
• INTERVALE ORARE. Un interval orar este un triplet (Zi, De la ora, La ora) •
ACTIVITATE. Este o activitate prezenta in orar (curs, laborator, seminar, proiect).
• PROFESOR. Este cadrul didactic titular pentru o activitate

Modelarea acestor clase de obiecte ca entitati presupune faptul ca in baza de date

sunt stocate si alte informatii despre ele. Diagrama EA este prezentata in figura 5. Ea
modeleaza programarea activitatilor didactice efectuate de profesori pe intervale
orare, sali si grupe.

11
 Fig. 5. Asociere de grad 5

Conectivitatea asocierii

Este specifica fiecarei ramuri a unei asocieri şi poate avea una din urmatoarele doua
valori: unu sau multi. Determinarea ei pentru ramura spre o entitate E se face astfel:
fixand arbitrar cite o instanta pentru celelalte entitati care participa la asociere se
pune intrebarea: cite instante ale lui E pot fi conectate cu acestea? Daca poate fi cel
mult una, conectivitatea ramurii este unu, altfel conectivitatea este multi.

Pentru exemplul din figura 4.:

• Asocierea TUTOR este unu-unu sau multi-uni dupa cum un student poate fi tutor
pentru un singur alt student sau pentru mai multi studenti de an inferior.
• Asocierea INSCRIS_LA este multi-unu (multi spre STUDENT) sau multi-multi dupa
cum un student poate fi inscris la una sau mai multe facultati.
• Asocierea ternara ALOCARE (aplicam definitia):
• ramura spre STUDENT: fiind dat un proiect si un calculator, citi studenti au ore
alocate pe acel calculator pentru respectivul proiect? Presupunand ca mai multi
studenti lucreaza pentru acelasi proiect pe acelasi calculator ramura va fi multi.
• ramura spre PROIECT: fiind dat un student şi un calculator, la cite proiecte are
acesta alocate ore pe acel calculator? Presupunand ca pentru fiecare proiect
exista un calculator dedicat, ramura va fi unu.
• ramura spre CALCULATOR: fiind dat un student şi un proiect, pe cate calculatoare
are alocate acesta ore pentru realizarea proiectului? Presupunand ca la un
proiect se lucreaza pe un singur calculator, ramura va fi unu.
Deci asocierea ALOCARE este multi-unu-unu.
Observam ca raspunsul la fiecare din cele trei intrebari se da in functie de realitatea
modelata. Aceeasi asociere poate avea conectivitati diferite in cazuri diferite: daca
exista chiar si un singur proiect la care un student are ore alocate pe mai mult de un
calculator, ramura spre CALCULATOR va fi multi iar asocierea va fi multi-unu-multi.

Conventia de reprezentare grafica a conectivitatii folosita in aceasta prezentare este

urmatoarea: ramurile 'unu' vor fi reprezentate sub forma de sageata. In figura 6. sunt

12
prezentate cele trei asocieri avand figurata şi conectivitatea. S-a presupus ca
asocierile TUTOR si INSCRIS_LA sunt unu-unu respectiv multi-unu.

Fig. 6. Reprezentarea conectivitatii

Obligativitatea asocierii

Ca şi conectivitatea, aceasta se determina pentru fiecare ramura şi poate avea doar

una din urmatoarele valori: obligatorie sau optionala. Determinarea ei pentru
ramura spre o entitate E se face astfel: fixand arbitrar cite o instanta pentru celelalte
entitati care participa la asociere se pune intrebarea: este obligatoriu sa existe o
instanta a lui E asociata cu acestea? Daca raspunsul este 'Da' ramura este obligatorie
altfel este optionala.

In exemplul anterior ramurile asocierilor TUTOR si ALOCARE sunt optionale iar cele
ale asocierii INSCRIS_LA sunt obligatorii deoarece:
• Pentru asocierea TUTOR: exista studenti care nici nu au un tutor nici nu sunt
tutori pentru alti studenti
• Pentru asocierea ALOCARE:
- Un student la un proiect poate sa nu aiba alocate ore pe nici calculator (de
exemplu in cazul unui proiect la o materie umanista)
- Un student si un calculator respectiv un calculator si un proiect pot sa nu fie
asociati prin alocare de ore de lucru (de exemplu pentru calculatoarele din
birourile cadrelor didactice)
• Pentru asocierea INSCRIS_LA: nu exista studenti care nu sunt inscrisi la nici o
facultate si nici facultati fara studenti inscrisi.

Conventia de reprezentare grafica a clasei de apartenenta folosita in continuare este

urmatoarea: ramurile obligatorii vor fi reprezentate prin linie continua iar cele
optionale prin linie intrerupta. In figura 7 este prezentata diagrama anterioara avand
figurata si obligativitatea.
Daca gradul şi conectivitatea unei asocieri sunt folosite in proiectarea conceptuala a
schemei bazei de date, obligativitatea se modeleaza pentru definirea unui criteriu de
integritate specificand posibilitatea de aparitie a valorilor nule: la transformarea
diagramei EA in model relational atributele tabelelor care modeleaza informatia

13
reprezentata de asocieri pot avea sau nu valori nule dupa cum ramurile acestora sunt
optionale sau obligatorii.

Atributele asocierilor

In unele cazuri o anumita informatie descriptiva nu este asociata cu o clasa de obiecte

ci cu un ansamblu de clase diferite modelate fiecare prin entitati. In acest caz aceasta
va fi modelata ca un atribut al asocierii dintre entitatile respective. Sa luam de
exemplu cazul unei asocieri multi-multi A_ABSOLVIT intre entitatile STUDENT şi
FACULTATE care contine informatii privind facultatile absolvite anterior de unii
studenti.

A_Absolvit

AnAbsolvire Medie Specializare

In acest caz informatii ca anul absolvirii, media, specializarea nu pot fi conectate nici
la STUDENT (pentru ca un student poate fi absolventul mai multor facultati in ani
diferiti, cu medii diferite, etc.) si din motive similare nici la FACULTATE. Ele descriu
asocierea unui student cu o facultate si de aceea vor fi atasate asocierii A_ABSOLVIT.
Toate atributele unei asocieri sunt atribute descriptive, neexistand in acest caz un
identificator al asocierii.

Rolul

In cazul in care de la o asociere pornesc mai multe ramuri catre aceeasi entitate,
fiecareia dintre acestea i se poate asocia un rol. Acesta arata semnificatiile diferite
pe care le are aceeasi entitate in cadrul asocierii respective.

Fig. 7. Reprezentarea obligativitatii. Roluri

14
In cazul asocierii TUTOR cele doua ramuri pot fi etichetate de exemplu cu tutor si
discipol aratand ca instante diferite ale aceleiasi entitati au rolurile respective (fig.
7.).

2.4. Criterii de modelare

a. Clasificarea in entitati şi atribute

Desi definitia notiunilor de entitate, atribut, asociere este destul de simpla, in

practica modelarii apar dificultati in clasificarea diverselor informatii intr-una din
aceste categorii. De exemplu in cazul sediilor unei banci localizate in diverse orase:
obiectul ORAS este entitate distincta sau atribut descriptiv al entitatii SEDIU?

Pentru a putea clasifica corect informatiile, exista citeva reguli care trebuie
respectate şi pe care le prezentam in continuare. Prima regula da un criteriu general
de impartire in entitati şi atribute, urmatoarele doua semnaleaza exceptii iar ultimele
doua reguli au un caracter mai putin normativ ci mai degraba orientativ.

Regula 1. Entitatile au informatii descriptive, pe cand atributele nu poseda astfel de

informatii.
Daca exista informatii descriptive despre o anumita clasa de obiecte, aceasta va fi
modelata ca o entitate. In cazul in care pentru pentru acea clasa de obiecte nu este
nevoie decit de un identificator (codul, denumirea, etc), ea va fi modelata ca un
atribut. De exemplu daca despre un ORAS este necesara stocarea in baza de date
unor informatii ca JUDET, POPULATIE, etc. atunci ORAS va fi o entitate. Daca singura
informatie necesara este numele sau atunci NUME_ORAS va fi un atribut al altei
entitati.

Regula 2. Atributele multivalorice vor fi reclasificate ca entitati.

Daca la o valoare a unui identificator corespund mai multe valori ale unui descriptor,
acesta va fi clasat ca entitate. De exemplu, in cazul unei baze de date privind
localizarea in teritoriu a unor banci, daca se memoreaza informatii doar despre banci
care au un singur sediu, LOCALITATE este atribut al entitatii BANCA.

Localitate
Bucuresti, Cluj, Iasi

BANCA

Daca insa se memoreaza informatii despre banci care au sucursale şi filiale in diverse
localitati, deci pentru o singura banca (o valoare a identificatorului entitatii BANCA)
avem mai multe localitati in care aceasta are sedii (mai multe valori ale descriptorului
LOCALITATE), atunci LOCALITATE va fi entitate distincta desi nu are decat un singur
atribut. Pentru a modela localizarea sediilor in diverse localitati intre cele doua
entitati va exista o asociere binara unu-multi (unu spre BANCI) numita de exemplu
ARE_SEDIU_IN.

15
 Nume

Regula 3. Atributele unei entitati care au o asociere multi-unu cu o alta entitate vor
fi reclasificate ca entitati.
Asa cum am vazut asocierile pot lega doar entitati. Daca un descriptor al unei entitati
este intr-o relatie multi-unu cu o alta entitate acel descriptor va fi trecut in categoria
entitatilor. De exemplu, daca avem entitatile BANCA avand ca atribut descriptiv
monovaloric LOCALITATE şi JUDET, daca se doreste modelarea apartenentei la judete
a localitatilor va exista o asociere multi-unu intre atributul LOCALITATE şi entitatea
JUDET.

Localitate

In acest caz LOCALITATE va fi reclasificata ca entitate desi nu sunt necesare alte

informatii in afara numelui localitatii.

Nume

Regula 4. Atributele vor fi atasate la entitatile pe care le descriu in mod nemijlocit.

De exemplu, UNIVERSITATE va fi atasat ca atribut al entitatii FACULTATE şi nu al
entitatilor STUDENT sau PROFESOR.

Regula 5. Folosirea identificatorilor compusi va fi evitata. Identificatorul unei entitati

este acea submultime de atribute ale acesteia care identifica in mod unic fiecare
instanta a sa. In model relational pentru atributele de acest fel se construiesc de
regula structuri de cautare rapida (indecsi) care functioneaza cu atat mai lent cu cat
complexitatea indecsului creste. Aplicarea acestei reguli se poate face in diverse
moduri:
1. Daca identificatorul unei entitati este compus din mai multe atribute care sunt
toate identificatori in alte entitati, acea entitate se elimina. Informatia continuta
de aceasta va fi modelata sub forma unei asocieri intre acele entitati.

16
2. Daca identificatorul unei entitati este compus din mai multe atribute care nu sunt
toate identificatori in alte entitati, exista doua solutii:
• Entitatea respectiva se elimina şi este inlocuita prin alte entitati si asocieri astfel
incit pe ansamblu informatia modelata in varianta originara sa fie pastrata. •
Entitatea respectiva ramine in forma originara, cu dezavantaje insa in privinta
vitezei operatiilor.

Se vede ca procedura clasificarii obiectelor in entitati şi atribute este iterativa:

• se face o prima impartire conform primei reguli
• parte din atributele astfel obtinute se reclasifica in entitati conform regulilor 2 si
3
• se face o rafinare finala conform regulilor 4 si 5.

b. Identificarea ierarhiilor de generalizare şi incluziune.

In cazul in care despre anumite subclase ale unei clase de obiecte exista informatii
specifice, clasa şi subclasele (care la pasul anterior au fost catalogate ca entitati) sunt
interconectate intr-o ierarhie de incluziune sau generalizare, dupa cum este cazul. La
acest pas se face şi o reatasare a atributelor pentru evitarea redundantei, astfel:
• La entitatea tata vor fi atasate atributele care formeaza identificatorul şi
descriptorii care modeleaza informatii specifice intregii clase.
• La entitatile fiu vor fi atasate atributele de identificare (aceleasi ca ale tatalui) şi
atributele care modeleaza informatii specifice doar acelei subclase de obiecte.

Sa consideram o ierarhie care imparte studentii dupa in caministi si necaministi (fig.

7.). In acest caz atributul NUME trebuie eliminat de la entitatea NECAMINIST
deoarece el este prezent deja la tata.

17
 Matricola Nume

Matricola Camera Matricola Adresa

Camin

Fig. 8. Atributele entitatilor unei ierarhii

Rezulta urmatoarele reguli:

1. Tatal şi fii unei ierarhii au acelasi identificator.
2. Descriptorii care apar şi la tata şi la fii se elimina de la fii.
3. Descriptorii care apar la toti fii unei ierarhii de generalizare şi nu apar la tata
se muta la tata.

c. Identificarea asocierilor

In aceasta etapa se trateaza informatiile care nu au fost clasificate ca entitati sau

atribute ci reprezinta interdependente intre clase de obiecte. Ele sunt modelate ca
asocieri intre entitati. Pentru fiecare asociere se specifica gradul, conectivitatea,
obligativitatea si daca este cazul si atributele asocierii precum si rolurile ramurilor
sale.

Ca şi in cazul clasificarii in entitati şi atribute, existe citeva reguli de urmat in operatia

de definire a asocierilor:

Eliminarea asocierilor redundante. In cazul in care o asociere poate fi dedusa din alte
asocieri deja catalogate, aceasta se elimina. De retinut ca intre doua entitati pot sa
existe oricite asocieri şi ele nu sunt considerate redundante atit timp cit au
semnificatie diferita.
Un caz des intilnit de redundanta este cel al compunerii (tranzititatii) asocierilor.
Prezentam un exemplu:

18
 Urmeaza_profilul

Are_profilul
Fig. 9. Asocieri redundante

In acest exemplu, asocierea INSCRIS_LA modeleaza apartenenta fiecarui student la o

facultate a unui institut de invatamint superior. Fiecare facultate are un profil unic
descris de asocierea ARE_PROFILUL. Ambele asocieri sunt multi-unu in sensul
STUDENT FACULTATE PROFIL. Deoarece asocierile multi-unu (ca şi cele unu-
unu) sunt din punct de vedere matematic functii, din compunerea lor putem afla
profilul la care este inscris fiecare student. Rezulta ca asocierea URMEAZA_PROFILUL
care are chiar aceasta semnificatie este redundanta şi trebuie eliminata.

Asocieri de grad mai mare ca 2. Asocierile ternare (sau de grad mai mare ca trei) se
folosesc doar atunci cand sunt strict necesare. Este de multe ori posibil ca o aceeasi
informatie sa fie modelata ca o asociere ternara sau ca un ansamblu de asocieri
binare si unare. In cazul acesta, este de preferat ca sa se opteze pentru a doua
varianta. Doar cand asocierile binare nu pot modela intreaga semnificatie dorita se
va opta pentru asocieri de grad mai mare ca doi. Aceasta cerinta deriva din faptul ca
la trecerea in modelul relational asocierile de grad superior devin scheme de relatii
de sine statatoare, marind numarul de tabele din baza de date pe cand cele de grad
unu şi doi (cu exceptia celor multi-multi) nu au acest efect.

d. Integrarea vederilor.

In cazul proiectarii bazelor de date complexe, activitatea se desfasoara uneori de

catre mai multe colective simultan, fiecare modeland o portiune distincta a bazei de
date. Deoarece in final trebuie sa se obtina o singura diagrama a bazei de date, dupa
terminatea modelarii pe portiuni diagramele rezultate sunt integrate eliminandu-se
redundantele si inconsistentele.

3.Structurarea cerinţelor sistemului - modelarea logică a datelor şi prelucrărilor

Indiferent de metodologiile folosite în realizarea unui sistem/aplicaţie, toate

apelează la operaţiunea de modelare logică a datelor şi prelucrărilor sub formă de
diagrame, diferenţele constând doar în folosirea mai pronunţată a diagramelor

19
pentru descrierea sistemului, încadrându-le în diagrame de context, diagrame ale
fluxurilor de date fizice şi diagrame ale fluxului de date logice. Altele apelează la
combinaţii de diagrame, tabele şi forme descriptive.
Diagrama de context scoate în evidenţă aria de întindere a sistemului analizat, prin
specificarea elementelor din interiorul organizaţiei şi a celor externe, sub denumirea
de entităţi externe sistemului analizat.

Diagramele fluxurilor de date (DFD)

Diagrama fluxului de date ale nivelului logic curent, independentă de tehnologie,

reliefează funcţiile de prelucrare a datelor executate de către sistemul informaţional
curent. Diagrama de flux de date ale sistemului logic nou va prezenta circuitul
datelor, structura lor şi cerinţele funcţionale ale noului sistem.
Descrieri ale obiectelor DFD se regăsesc în aşa-zisele dicţionare ale proiectelor sau
depozitele CASE (repository).
Diagramele fluxului de date DFD au ca obiectiv urmărirea modului de transfer al
datelor între procesele de prelucrare a lor, astfel de diagrame se mai numesc şi
modele ale proceselor de prelucrare, iar operaţiunea se numeşte modelarea
proceselor.
DFD reprezintă doar una din tehnicile de analiză structurată.
Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor fluxurilor
de date a căpătat noi accepţiuni prin încorporarea ei în instrumentele de analiză şi
proiectare cu ajutorul calculatorului, adică în instrumente CASE.

Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru

construirea DFD
În analiza sistemelor se folosesc frecvent reprezentările grafice, de exemplu
diagramele. În continuare vom folosi tehnica reprezentării grafice a fluxului
informaţional.
Proiectarea fluxului informaţional reprezintă circulaţia informaţiei în sistem,
transformările suferite, stocarea informaţiei precum şi scurgerile de informaţie în
afara sistemului. Scopul diagramelor de date DFD pentru o anumită componentă
organizatorică sau funcţională la care se referă (secţie, birou, compartiment, întreaga
unitate, o anumită activitate – vânzări, cumpărări, încasări, plăţi, ş.a) este de a scoate
în relief, într-o manieră cât mai sugestivă, următoarele aspecte :
- sursa datelor de prelucrare;
- operaţiunile de prelucrare prin care trec datele;
- destinaţia datelor prelucrate;
- legătura existentă între prelucrări şi activitatea de stocare a datelor.
Întocmirea diagramelor de flux de date (DFD)
DFD este o reprezentare grafică a transformării datelor de intrare în date de ieşire
folosind un set de simboluri de reprezentare şi un set de reguli de completare şi
validare.

20
Simboluri folosite în diagramele realizate cu SSADM

proces (transformare): Procesele sunt etichetate cu

text ce sugerează modul de transformare a datelor şi
sunt identificate printr-un număr(descriere a funcţiei
procesului de prelucrare, începând cu un verb, urmat
de o descriere a obiectului funcţiei de prelucrare). În
DFD fizică pentru sistemul existent, se va preciza
şi locaţia (compartiment / persoană) procesului.

flux de date: este constituit din datele transmise între două procese. Fluxul
de date este etichetat printr-un substantiv ce sugerează informaţia sau
pachetul de informaţii transmise.

entitate externă (terminator): sursă / receptor de date. Poate

fi un alt sistem (organizaţie, compartiment).

stoc de date: un depozit temporar sau permanent de date.

Poate fi:
- manual: registre, dosare, arhivă de documente - pe suport magnetic:
fişiere.

3.1. Convenţii folosite în diagramele de reprezentare a fluxurilor de date DFD:

− procesele şi stocurile de date sunt numerotate secvenţial, pentru a putea fi
identificate. Numerele asociate proceselor nu semnifică ordinea de execuţie a
acestora;
− pentru a evita fluxurile de date întretăiate şi aspectul de “păienjeniş” al diagramei,
entităţile externe şi stocurile de date pot fi duplicate. O entitate externă duplicată se
reprezintă prin trasarea unei linii oblice, iar un stoc duplicat printr-o linie
suplimentară verticală în partea stângă a cutiei;
− pentru a face diagramele mai lizibile, entităţile externe sunt plasate, pe cât posibil,
în jurul diagramei iar stocurile de date, în partea centrală a diagramei;
− fluxurile de date de la - către stocurile de date sunt unidirecţionale (fie de adăugare,
fie de consultare) şi nu sunt etichetate.

21
3.2. Descompunerea funcţională şi rafinarea DFD

Dacă sistemul pe care-l descriem cu ajutorul DFD este complex, va fi dificil să realizăm
de la început o DFD detaliată. Pentru a putea descrie în detaliu sistemele complexe,
metodele structurate propun o abordare TOP-DOWN, respectiv o descompunere
funcţională a sistemului, care este realizată prin rafinarea succesivă a proceselor.
Primul nivel (nivelul 0) îl constituie DIAGRAMA CONTEXTUALĂ, care defineşte
graniţele între sistemul analizat si mediu.
Nivelele următoare se obţin prin rafinarea proceselor complexe într-o diagramă de
nivel inferior.
Pentru aplicaţia DECONTĂRI au rezultat următoarele diagrame:

Fig. 10. Diagrama contextuală pentru aplicaţia Decontări

Fig. 11. Diagrama fluxului de date de nivel 1 pentru aplicaţia Decontări

22
Fig. 12. Diagrama fluxului de date de nivel 2 pentru aplicaţia Decontări

3.3. Definirea direcţiilor de perfecţionare a actualului sistem

Pe baza activităţilor de evaluare şi analiză critică se identifică neajunsurile actualului
sistem şi se propun soluţii de înlăturare a acestora se formulează variante de soluţii,
iar în cadrul acestora se definesc cerinţele şi restricţiile de realizare a sistemului
informatic.
Definirea direcţiilor de perfecţionare presupune:
1. specificarea obiectivelor şi a performantelor sistemului informatic;
2. stabilirea domeniilor de probleme şi a principalelor funcţiuni ale sistemului
informatic;
3. definirea cerinţelor si restricţiilor informaţionale pe domenii de probleme şi
funcţiuni care constă în:
− definirea principalelor intrări/ ieşiri;
− definirea soluţiei de organizare a datelor;
− definirea variantelor tehnologice de prelucrare;
− definirea restricţiilor informaţionale şi de control.
4. formularea condiţiilor pentru realizarea sistemului informatic, care constă în:
− specificarea termenelor şi duratelor solicitate;
− precizarea priorităţilor în realizarea obiectivelor sistemului informatic;

23
− specificarea cerinţelor speciale privind flexibilitatea, compatibilitatea cu alte
sisteme, gradul de generalizare al sistemului.
Pentru fiecare variantă de soluţie informatică se procedează la:
− evaluarea resurselor necesare (costurile de sistem);
− evaluarea efectelor economice directe si indirecte;
− calculul indicatorilor de eficientă economică.

3.4. Modelarea sistemului curent

Indiferent de tipul sistemului analizat, manual sau informatizat, acesta va fi înlocuit

de un nou sistem. Oricât de ineficient, vechiul sistem trebuie să transfere celui nou o
serie de elemente, cum sunt datele folosite, procedurile existente. Deci sistemul fizic
actual efectuează în parte sau în întregime ceea ce-şi propune să facă noul sistem
fizic, dar la alt nivel de performanţă. Necesitatea trecerii de la vechiul la noul sistem
ne obligă să decidem asupra celor două elemente specificate anterior, date şi
proceduri, ceea ce conduce la obligativitatea constituirii unui model logic al
sistemului propus, care să conţină una sau mai multe DFD, un model de date şi logica
procesului de prelucrare. O modalitate de abordare constă în prezentarea detaliată a
sistemului fizic curent, după care să se realizeze construirea modelului logic curent,
prin abstractizarea celui fizic existent. Se va continua cu scoaterea în relief a ceea ce
trebuie neapărat schimbat din sistemul curent şi ceea ce trebuie să se realizeze în cel
nou. Pornind de la modelul fizic, se derivă modelul logic în cadrul căruia se realizează:
− pune în evidenţă ce face sistemul, eliminând detaliile referitoare la modul cum
funcţionează sistemul în implementarea actuală;
− pune în evidenţă funcţiunile de bază ale sistemului;
− permite identificarea şi eliminarea problemelor legate de redundanţa datelor şi
duplicarea proceselor de prelucrare;
− permite stabilirea cu o mai mare precizie a graniţelor sistemului prin eliminarea
proceselor manuale care nu pot fi automatizate complet.

3.5. Derivarea modelului logic al sistemului existent

Construirea modelului logic presupune transformarea diagramei de flux a datelor
fizice în diagrama de flux a datelor logice.
Procesul de derivare a diagramei logice va începe de la ultimul nivel de
descompunere alcătuit de la procesele “frunză” şi va continua prin agregarea
proceselor către nivelurile superioare. Se parcurg următorii paşi :
1. Identificarea stocurilor logice de date - se face pe modelul logic al datelor prin
gruparea într-un stoc logic de date a entităţilor înrudite sau utilizate frecvent.
După identificarea stocurilor logice de date se construiesc:
− diagrama de corespondenţă între stocuri logice şi entităţile din modelul logic; −
diagrama de corespondenţă între stocuri fizice şi stocuri logice de date.

24
 2. Înlăturarea dependenţelor fizice şi temporale din denumirea proceselor şi a
fluxurilor de date: din DFD la nivel fizic (se observă că nu există referinţe fizice şi
temporale în aplicaţia decontări).
3. Derivarea proceselor logice:
− scoaterea în afara graniţelor sistemului a proceselor manuale care nu pot fi
automatizate (deciziile);
− înlocuirea proceselor care nu realizează nici o transformare asupra fluxurilor de
date cu fluxurile propriu-zise;
− combinarea proceselor care realizează prelucrări asemănătoare sau multiple care
se execută împreună sau în secvenţă;
− înlăturarea proceselor care ţin de implementarea actuală şi a proceselor
redundante.
În cazul aplicaţiei prezente:
− se combină procesele “Înregistrare încasări în numerar” şi “Înregistrare încasări prin
virament” deoarece realizează prelucrări asemănătoare;
− se înlătură procesele redundante “Înregistrare încasări în jurnal” si “Înregistrare
plăti în jurnal”.
4. Derivarea fluxurilor logice care presupune înlocuirea numelui de document
numai cu fluxul de informaţii utilizate efectiv de proces.
5. Gruparea proceselor elementare şi transformarea diagramei fizice în
diagramă logică, aplicând cei 5 paşi.

3.6. Relaţia existentă între DFD şi modelul datelor

După cum reiese din prezentările anterioare, fiecare săgeată din DFD reprezintă un
flux al datelor, în sensul unui traseu pe care structurile datelor elementare sau
grupate se vor deplasa în sistem. De exemplu, Facturi desfacere este o dată grupată.
Când numele ei se plasează pe un flux de prelucrare trebuie să vedem şi
obligativitatea ca acel flux să fie descris prin prisma structurii datelor respective, deci,
trebuie prezentate rubricile documentului. Similar va fi abordat şi simbolul pentru
stocare. La prima vedere, el reprezintă locul unde se realizează operaţiunea, dar
foarte important este să prezentăm structura datelor păstrate. Firesc, şi în cazul
fluxului de date, şi în cel al stocării lor nu trebuie uitată descrierea semnificaţiei
economice. Structura datelor trebuie să fie redusă la a treia formă normalizată, iar
conţinutul locurilor de stocare a datelor să fie prezentat prin reduceri la unul sau mai
multe tabele relaţionale în forma a treia normalizată.
În cazul aplicaţiei DECONTĂRI, se obţine nivelul elementar al DFD a sistemului logic
pentru Decontări cu beneficiarii reprezentată în figura 4. Nivelele superioare ale DFD
a sistemului logic sunt identice.

25
Tabel 1 Aplicaţia Decontări
Sursa Destinaţia Nume flux Continutul fluxului
CODCLIENT, DENCLIENT,
1.1. Înregistrare D2 FACTURI ADRESAC, CONTC,
desfaceri
facturi desfacere DESFACERE BANCA_C, DATAFACTD,
NRFACTD, TOTALFACTD
CODCLIENT, DENCLIENT,
D2 FACTURI 1.3. Analiza
desfaceri ADRESAC, CONTC, BANCA_C,
DESFACERE situaţie client
NRFACTD, TOTALFACTD

Figura 13. Diagrama fluxului de date

3.7. Modelarea logicii proceselor

După ce au fost descrise procesele de conversie a datelor în informaţii, prin

intermediul diagramelor fluxurilor de date DFD, deoarece ele nu reliefează şi logica

26
internă a proceselor, oricât ar fi de detaliate, chiar şi la nivelul proceselor primare, se
impune apelarea la alte tehnici pentru descrierea logicii proceselor. Procesele trebuie
astfel descrise încât să poată fi convertite în programe prin intermediul limbajelor de
programare.
În faza de analiză, modelarea logicii proceselor se va derula cât mai detaliat şi
complet posibil, dar operaţiunea nu va respecta structura sau sintaxa unui anumit
limbaj de programare: aceasta se va realiza într-o etapă ulterioară şi anume
proiectarea. Modelarea logicii proceselor ca şi diagramele fluxurilor de date fac parte
din etapa de analiză a sistemului.
În analiza structurată, rezultatele obţinute în urma modelării proceselor sunt
descrieri şi diagrame structurate care vor prezenta logica fiecărui proces, precum şi
diagrame care vor evidenţia dimensiunea temporală a sistemelor, când apar
procesele sau evenimentele şi modul în care aceste evenimente schimbă starea
sistemului.
Pe scurt se poate spune că modelarea logică a proceselor se va concretiza în
următoarele elemente ale documentaţiei :
− reprezentarea în engleza structurată;
− reprezentarea logicii proceselor prin tabele de decizie; − reprezentarea logicii
proceselor prin arbori de decizie;
− tabelul sau diagrama stărilor de tranziţie.

3.8 Reprezentarea logicii proceselor prin engleza structurată

Engleza structurată este o formă mult simplificată şi modificată a limbii engleze,
folosită pentru descrierea conţinutului casetelor care marchează procesele
(prelucrările) din diagrama fluxului de date. Cuvintele folosite sunt în strânsă legătură
cu logica folosită în conceperea procedurilor componente ale sistemelor informatice
. Se folosesc verbe pentru cuvintele cheie şi substantive pentru descrierea structurii
datelor.
Nu există o formă standard de engleză structurată, fiecare analist ar putea apela la o
formă proprie, dar scopul este de a înlesni accesul mai multor persoane la rezultatele
analizei înglobate în documentaţie. Utilizarea englezei structurate pentru procesul
“Analiza situaţie client” din decontări cu beneficiarii este reprezentată mai jos.

Analiza situaţie client

WRITE CLIENTI,FACTURI_DESF, ÎNCASĂRI READ (FACTURI_DESF) cod =
FACTURI_DESF.codclient; den = FACTURI_DESF.denclient;
adr = FACTURI_DESF.adresac; cont = FACTURI_DESF.contc; banca =
FACTURI_DESF.bancac; while (not eof (FACTURI_DESF))
{
if (cod!=FACTURI_DESF.codclient)
{ CLIENTI.codclient = cod;
CLIENTI.denclient = den;
CLIENTI.adresac = adr;

27
 CLIENTI.contc = cont;
CLIENTI.banca_c = banca;
CLIENTI.sold = sold;
cod = FACTURI_DESF.codclient;
den = FACTURI_DESF.denclient;
adr = FACTURI_DESF.adresac;
cont = FACTURI_DESF.contc;
banca = FACTURI_DESF.bancac;
} else
{
READ(ÎNCASĂRI);
vb=0; vb1=0;
while (not eof (ÎNCASĂRI) AND vb=0)
{
if (cod=ÎNCASĂRI.client AND FACTURI_DESF.nrfactd=ÎNCASĂRI.nrfactd
AND
FACTURI_DESF.datafactd =ÎNCASĂRI.datafactd)
{ if (FACTURI_DESF.totalfactd !=ÎNCASĂRI.sumaincasata)
{ sold = sold+ FACTURI_DESF.totalfactd - ÎNCASĂRI.sumaincasata}
vb1=1;
}
else if (vb1=1) vb=1
READ (ÎNCASĂRI)
}
MOVE FIRST LINE ÎNCASĂRI
READ (FACTURI_DESF)
}
CLOSE (FACTURI_DESF, ÎNCASĂRI, CLIENTI)

3.9. Modelarea conceptuală a datelor (diagramele entitate – relaţie, DER)

În cadrul modelării conceptuale a datelor se va renunţa la abordarea proceselor şi se

va trece la abordarea sistemelor prin prisma datelor. La fel ca şi în cazul modelării
proceselor şi modelării logicii proceselor elementele esenţiale vor fi diagramele.
James Martin şi Carma McClure, atunci când reliefează importanţa tehnicilor
structurate prin obiectivele ce şi le propun, consideră că o parte a acestora au
legătură şi cu datele, şi anume :
− Să se realizeze o administrare riguroasă a datelor. Administrarea datelor se referă
la structurarea corectă a datelor, la uniformitatea modalităţilor de definire şi
proiectare a datelor la nivel de întreprindere şi nu a sistemului. Corect efectuate,
acestea accelerează procesele de analiză şi proiectare şi permit să se utilizeze în
comun componentele esenţiale ale sistemelor: resursele.

28
− Să se efectueze o analiză sănătoasă a datelor. Analizele datelor clarifică problemele
de structurare a lor şi conduc la structuri stabile ale acestora, concretizate prin costuri
reduse ale realizării sistemelor. Dacă baza de date a unităţii este deosebit de
importantă, atunci pe analiza datelor trebuie să se pună un accent aparte, ea fiind
întotdeauna realizată înaintea proiectării programelor. Firesc, dacă ştim care sunt
cerinţele unui sistem (ieşirile), imediat ne vom pune întrebarea din ce se obţin
acestea (intrările) şi apoi vom urmări cum se pot obţine ieşirile (procesele).
Obiectivul principal al ingineriei informaţiei este crearea unui set de metodologii care
să poată fi folosite în cele mai diverse medii de lucru, astfel încât să se construiască
modele ale datelor la nivel de întreprindere, iar sistemele proiectate izolat să se
integreze în aceste modele.
Datele trebuie să fie unice. Asupra lor, la nivel de întreprindere, pot fi văzute două
categorii mari de operaţiuni:
− asigurarea datelor (creare, actualizare);
− utilizarea datelor (obţinere de documente, de diverse rapoarte, analize „What-If”,
sprijin decizional, diferite căutări de informaţii, control şi auditare întreprindere).
Modelul conceptual al datelor înseamnă o modalitate de reprezentare a datelor
organizaţiei. Rolul său este de a scoate în relief toate regulile privind identitatea şi
legăturile existente între date.
Cea mai cunoscută formă utilizată pentru modelarea datelor este diagrama
entitaterelaţie (DER). O modalitate aproape identică este folosită şi în analiza şi
proiectarea orietată-obiect.
Modelarea datelor prin DER prezintă caracteristicile şi structura datelor independent
de modul în care acestea sunt memorate în calculator. Modelul se creează iterativ.
De cele mai multe ori, operaţiunea are loc la nivel de întreprindere, prin apelarea la
o categorie foarte largă de date neglijându-se detaliile exagerate. Doar în etapele
următoare, în speţă când se trece la definirea proiectului, are loc construirea unui
model anume entitate-relaţie prin care să fie scoasă în evidenţă aria de întindere a
proiectului. În timpul structurării cerinţelor, un model entiatate-relaţie reprezintă
cerinţele conceptuale de date pentru sistemul luat în discuţie. După ce sunt descrise
complet intrările şi ieşirile sistemului în cadrul proiectării logice, modelul conceptual
al datelor, redat sub forma entitate-relaţie, este rafinat înainte de a fi trecut într-un
format logic (de regulă, un model relaţional al datelor) din care se definesc bazele de
date şi are loc proiectarea fizică a acestora.
Se consideră că, în timpul modelării conceptuale a datelor, se produc şi se analizează
cel puţin patru diagrame entitate-relaţie:
1. DER care să acopere datele necesare aplicaţiei proiectului. Ea va permite
stabilirea necesarului de date ale aplicaţiei proiectului, fără să se ţină seama de
constrângerile sau confuziile generate de detaliile care nu sunt încă necesare.
2. DER pentru aplicaţia ce va fi înlocuită. Diferenţele dintre aceste diagrame
arată ce schimbări trebuie întreprinse pentru convertirea bazei de date în noua
aplicaţie. Nu se aplică în cazul sistemelor complet noi.

29
 3. DER care să scoată în relief întreaga bază de date din care noua aplicaţie îşi
va extrage datele. Cât timp mai multe aplicaţii pot folosi aceeaşi bază de date,
această diagramă şi prima evidenţiază modul în care noua aplicaţie apelează la
conţinutul unor baze de date mult mai extinse.
4. DER pentru întreaga bază de date din care aplicaţia curentă îşi extrage
datele necesare. Ea este discutată doar pentru sistemele care există şi pentru
care se urmăreşte îmbunătăţirea.
Metodele de determinare a cerinţelor trebuie să fie orientate, prin întrebările puse,
prin anchetele efectuate, şi asupra datelor, nu numai asupra proceselor şi logicii lor.
La început, chiar fără utilizarea unei terminologii de specialitate, analistul va fi
preocupat de modul în care va afla cât mai multe informaţii despre datele necesare
viitorului sistem pentru a funcţiona la parametrii proiectaţi. Întrebările vor fi astfel
formulate încât să se realizeze o bună înţelegere a regulilor după care vor fi folosite
datele în noul sistem, ce politici vor fi utilizate. Nu trebuie, încă, să se intre în detalii
de genul: când şi cum sunt prelucrate sau folosite datele, pentru a se realiza
modelarea datelor.
Modelarea datelor se realizează printr-o combinaţie a punctelor de vedere .
Un prim punct de vedere, formulat în literatură sub numele de metoda top-down,
va scoate în evidenţă regulile derulării activităţii firmei, printr-o înţelegere foarte
clară a naturii afacerii, şi nu se va opri asupra detaliilor privind modul în care
ecranele, rapoartele sau documentele sunt folosite în organizaţie.
În afara metodei top-down, informaţiile necesare construirii modelului datelor se
pot obţine şi prin urmărirea documentaţiei firmei, ecrane, rapoarte, formulare, din
interiorul sistemului. Acest proces este cunoscut în literatura de specialitate sub
numele de metoda bottom-up.
Elementele rezultate vor figura în diagramele fluxurilor de date prin care vor fi
evidenţiate datele prelucrate în sistem şi de aici va rezulta necesarul de date
menţinute în baza de date a sistemului.

3.10. Modelul Entitate/Relaţie (E/R)

Cercetările efectuate pentru definirea unui model de date care să permită

reprezentarea cât mai fidelă a realităţii au condus la definirea conceptului de model
semantic încă din 1976 când Chen a prezentat modelul Entitate-Relatie (E/R), care
constituie astăzi o tehnică larg acceptată pentru proiectarea bazelor de date.
Modelul E/R permite proiectantului bazei de date să elaboreze un model conceptual
de nivel înalt, fără a ţine seama de anumite constrângeri impuse de utilizarea unui
anumit SGBD, de o anumită platformă hardware, sau de anumite considerente de
eficienţă privind exploatarea bazei de date, ceea ce permite o reprezentare mai fidelă
a realităţii avute în vedere, constituind astfel o etapă intermediară în proiectarea unei
baze de date, fiind din acest punct de vedere asemănător pseudocodului utilizat în
activitatea de programare.

30
 Modelul Entitate/Relaţie (E/R) permite reprezentarea schematică a realităţii avute
în vedere cu ajutorul unei diagrame E/R definită plecând de la conceptele de bază:
tip de entitate, tip de relaţie (legătură, corelaţie), atribut.

3.11. Tipuri de entităţi, entităţi

Tipul de entitate reprezintă o clasă de obiecte sau un concept cu o existenţă de sine
stătătoare, este identificat printr-un nume şi este definit de un set de proprietăţi
numite atribute. O entitate este un obiect particular al clasei de obiecte, reprezintă o
instanţă a tipului de entitate şi este definit de valori corespunzătoare ale atributelor
ce definesc tipul de entitate. Entităţile sunt obiecte sau evenimente (fenomene sau
procese economice, în cazul nostru). Obiectele se caracterizează printr-o existenţă
de-a lungul timpului, iar evenimentele îşi fac simţită prezenţa la un moment dat. La
rândul lor, obiectelor li se pot asocia cel puţin două evenimente: apariţia şi dispariţia
lor. Exemple: încheierea şi încetarea contractului de muncă; predarea produselor la
secţia expediţie şi desfacerea lor la beneficiari ş.a. Evenimentelor le corespund
asocieri între două sau mai multe obiecte. Exemplu: CLIENT COMANDĂ PRODUS.
Raportat la o anumită organizaţie, o entitate este o persoană, un loc, un obiect,
eveniment sau concept din domeniul de activitate a utilizatorului despre care
organizaţia doreşte să păstreze anumite date. Se cuvine precizată diferenţa dintre
tipurile entităţilor (entity types) şi cazurile/instanţele entităţii (entity instances) .
Tipul entităţii, cunoscut şi sub numele de clasa entităţii, este o colecţie de entităţi
care au proprietăţi sau caracteristici comune. Referirea generală la elementele ce pot
fi catalogate ca entităţi se va realiza printr-un substantiv denumit cu litere majuscule,
plasate în interiorul dreptunghiului corespunzător entităţii.
O instanţiere a entităţii sau instanţă, denumită în continuare, caz al entităţii sau caz,
este o manifestare singulară a unui tip de entitate. Un tip de entitate se descrie o
singură dată prin modelul datelor, în timp ce mai multe cazuri ale acelui tip de
entitate pot fi reprezentate prin datele stocate în bazele de date. De exemplu, există
o singură entitate CLIENT, dar ea poate să aibă sute sau mii de cazuri/instanţe ale
acestei entităţi stocate în baza de date.

3.11.1.Atribute
Fiecare tip de entitate are un set de atribute asociate lui. Un atribut este o
proprietate sau o caracteristică a unei entităţi care prezintă interes pentru
organizaţie. La rândul lor, şi relaţiile pot avea propriile lor atribute.
Exemplu de entitate pentru aplicaţia DECONTĂRI şi unele dintre atributele
posibile:
CLIENT : CodClient, DenClient, AdresaClient
Ca şi numele tipurilor entităţilor, numele atributelor sunt substantive scrise cu
majuscule (eventual + minuscule), plasate în interiorul elipselor, legate de entitatea
căreia i se asociază. De multe ori însă, chiar şi în cazul folosirii produselor CASE, pentru
a nu se încărca o diagramă entitate-relaţie, se evită prezentarea atributelor.

31
Operaţiunea se face, în schimb, în repository, depozitul de informaţii despre proiect.
Aici orice atribut se descrie separat, ca orice obiect distinct.

3.11.2. Cheie candidat şi cheie primară

Fiecare tip de entitate trebuie să aibă un atribut sau un set de atribute prin care să
se efectueze diferenţierea fiecărui caz de acelaşi tip.
Un set de atribute ale căror valori identifică în mod unic instanţele unui tip de
entitate, constituie o cheie candidat pentru acel tip de entitate. Având în vedere
faptul că pentru un tip de entitate pot exista mai multe chei candidat, una dintre chei
se va desemna drept cheie primară.
O cheie-primară este o cheie-candidat care a fost selectată pentru a servi ca
identificator de cazuri în cadrul unui tip de entitate .
În reprezentările din DER, în elipsa sau elipsele aferente atributului sau atributelor
ce formează cheia primară, numele respective se subliniază (vezi CodClient din
entitatea CLIENT ).
Un tip de relaţie reprezintă o asociere între două sau mai multe tipuri de entităţi şi
defineşte legătura care există între tipurile respective de entităţi. Fiecare tip de
relaţie este identificat printr-un nume care descrie funcţia sa şi poate conţine
atribute. O relaţie sau o instanţă a unui tip de relaţie este o legătură între instanţe ale
tipurilor de entităţi asociate în cadrul tipului de relaţie corespunzător. Dacă R este un
tip de relaţie definit pe tipurile de entităţi E1, E2,…,En, atunci R este funcţional faţă de
Ei (1 ≤ i ≤ n) dacă orice instanţă a tipului de entitate Ei este determinată univoc de
instanţe ale tipurilor de entităţi E1,…,Ei1,Ei+1,…,En prin relaţia R. Un tip de relaţie R
definit pe tipurile de entităţi E1, E2,…,En, poate fi funcţional sau nu faţă de fiecare din
tipurile de entităţi Ei (1 ≤ i ≤ n).
Un atribut defineşte o proprietate a unui tip de entitate sau a unui tip de relaţie şi
poate fi: atribut simplu sau elementar, atribut compus (format din mai multe
componente, fiecare având o existenţă independentă), atribut derivat (valorile sale
se obţin plecând de la valorile altor atribute).
Pentru reprezentarea unor probleme complexe de tip bază de date, apărute
începând din anii 80, modelul de date semantic a fost extins cu noi concepte
semantice, rezultând astfel modelul entitate relaţie extins EER. În acest sens la
conceptele de bază au fost adăugate conceptele suplimentare de superclasă,
subclasă şi moştenire.
O superclasă reprezintă un tip de entitate care conţine subclase distincte care
trebuie să fie reprezentate în cadrul modelului, iar o subclasă este un membru al unei
superclase. O subclasă, fiind un tip de entitate distinct, poate avea la rândul său
subclase, astfel încât se pot construi ierarhii de clase. O subclasă moşteneşte toate
atributele superclasei, putând avea în plus şi alte atribute. În diagrama EER, pentru
subclase se vor reprezenta numai atributele specifice subclasei.
Pentru elaborarea unei diagrame EER, se utilizează o serie de simboluri reprezentate
în figura 10.

32
 <nume tip
entitate> Reprezentare tip entitate cu numele <nume tip entitate>

<nume atribut> Reprezentare atribut cu numele <nume atribut>

<nume atribut>
Reprezentare atribut cheie cu numele <nume atribut>

<nume atribut> Reprezentare atribut derivat cu numele <nume atribut>

Reprezentare atribut compus <nume atribut>

<atribut1> <atribut2>
format din componentele <atribut1>, <atribut2>

<nume atribut>

<nume tip
entitate> <nume atribut>
Apartenenţa atributului
<nume atribut>
la tipul de entitate <nume tip
entitate> <nume tip relaţi e>

Reprezentare tip de relaţie cu numele <nume

tip relaţie>
E R

Relaţia R funcţională faţă de tipul

Relaţia R nefuncţională faţă de tipul
Apartenenţa subclasei E R la

Superclasa

Subclasa

Figura 10. Simboluri utilizate în reprezentarea unei diagrame EER

33
Un exemplu de reprezentare a unui tip de entitate prin diagramă este ilustrat în
figura 11.

DenClient

CodClient CLIENT AdresaClient

Figura 11. Model de reprezentare a atributelor prin DER

Relaţiile entităţilor
O relaţie este o asociere între cazurile/instanţele uneia sau mai multor tipuri de
entităţi care prezintă interes pentru organizaţie. Ele se reprezintă printr-un romb ca
în exemplul din figura 12.

FURNIZORI Oferte PRODUSE

Figura 12. Reprezentare relaţie Oferte între entităţile FURNIZORI, PRODUSE

34