Post on 12-Sep-2019
Curs nr. 5 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 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.
1. 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.
1.1 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.
1
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.
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.
Convenţii folosite în diagramele de reprezentare a fluxurilor de date DFD:
2
− 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.
1.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:
3
Fig. 1. Diagrama contextuală pentru aplicaţia Decontări
Fig. 2. Diagrama fluxului de date de nivel 1 pentru aplicaţia Decontări
Fig. 3. Diagrama fluxului de date de nivel 2 pentru aplicaţia Decontări
4
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;
− 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ă.
2. 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
5
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.
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.
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);
6
− î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.
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.
Tabel 1 Aplicaţia Decontări
7
Sursa Destinaţia Nume flux Continutul fluxului
1.1. Înregistrare facturi desfacere
D2 FACTURI DESFACERE desfaceri
CODCLIENT, DENCLIENT, ADRESAC, CONTC, BANCA_C, DATAFACTD, NRFACTD, TOTALFACTD
D2 FACTURI DESFACERE
1.3. Analiza situaţie client desfaceri
CODCLIENT, DENCLIENT, ADRESAC, CONTC, BANCA_C, NRFACTD, TOTALFACTD
Figura 4. Diagrama fluxului de date
2.1 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 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.
8
Î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.
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;
9
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;
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;
}
10
else if (vb1=1) vb=1
READ (ÎNCASĂRI)
}
MOVE FIRST LINE ÎNCASĂRI
READ (FACTURI_DESF)
}
CLOSE (FACTURI_DESF, ÎNCASĂRI, CLIENTI)
3. 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.
− 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.
11
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 entitate-
relaţ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.
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
12
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.1. 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.
13
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.
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.
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
14
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.
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. Operaţiunea se face, în
schimb, în repository, depozitul de informaţii despre proiect. Aici orice atribut se descrie
separat, ca orice obiect distinct.
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
15
tipului de entitate Ei este determinată univoc de instanţe ale tipurilor de entităţi E1,…,Ei-
1,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 5.
16
Reprezentare tip entitate cu numele <nume tip entitate>
Reprezentare atribut cheie cu numele <nume atribut>
<nume tip entitate>
<nume atribut> Reprezentare atribut cu numele <nume atribut>
<nume atribut>
<nume tip relaţie> Reprezentare tip de relaţie cu numele <nume tip relaţie>
Relaţia R funcţională faţă de tipul
Relaţia R nefuncţională faţă de tipul
E R
E R
Superclasa
Subclasa
Apartenenţa subclasei la
<nume tip entitate>
<nume atribut>
Apartenenţa atributului <nume atribut> la tipul de entitate <nume tip entitate>
<nume atribut> Reprezentare atribut derivat cu numele <nume atribut>
Reprezentare atribut compus <nume atribut> format din componentele <atribut1>, <atribut2>
<nume atribut>
<atribut1> <atribut2>
Figura 5. Simboluri utilizate în reprezentarea unei diagrame EER
17
Un exemplu de reprezentare a unui tip de entitate prin diagramă este ilustrat în figura
6.
CLIENT
DenClient
AdresaClient CodClient
Figura 6. 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 7.
PRODUSE FURNIZORI
Figura 7. Reprezentare relaţie Oferte între entităţile FURNIZORI, PRODUSE
Oferte
18