Modelarea conceptuala a datelor (diagramele entitate – relatie, DER)

Modelarea conceptuala a datelor (diagramele entitate – relatie, DER)

In cadrul modelarii conceptuale a datelor se va renunta la abordarea proceselor si se va trece la abordarea sistemelor prin prisma datelor. La fel ca si in cazul modelarii proceselor si modelarii logicii proceselor elementele esentiale vor fi diagramele.

James Martin si Carma McClure, atunci cand reliefeaza importanta tehnicilor structurate prin obiectivele ce si le propun, considera ca o parte a acestora au legatura si cu datele, si anume  [1]:

Sa se realizeze o administrare riguroasa a datelor. Administrarea datelor se refera la structurarea corecta a datelor, la uniformitatea modalitatilor de definire si proiectare a datelor la nivel de intreprindere si nu a sistemului. Corect efectuate, acestea accelereaza procesele de analiza si proiectare si permit sa se utilizeze in comun componentele esentiale ale sistemelor: resursele.

Sa se efectueze o analiza sanatoasa a datelor. Analizele datelor clarifica problemele de structurare a lor si conduc la structuri stabile ale acestora, concretizate prin costuri reduse ale realizarii sistemelor. Daca baza de date a unitatii este deosebit de importanta, atunci pe analiza datelor trebuie sa se puna un accent aparte, ea fiind intotdeauna realizata inaintea proiectarii programelor. Firesc, daca stim care sunt cerintele unui sistem (iesirile), imediat ne vom pune intrebarea din ce se obtin acestea (intrarile) si apoi vom urmari cum se pot obtine iesirile (procesele).

Obiectivul principal al ingineriei informatiei este crearea unui set de metodologii care sa poata fi folosite in cele mai diverse medii de lucru, astfel incat sa se construiasca modele ale datelor la nivele de intreprindere, iar sistemele proiectate izolat sa se integreze in aceste modele.

Datele trebuie sa fie unice. Asupra lor, la nivel de intreprindere, pot fi vazute doua categorii mari de operatiuni:

asigurarea datelor (creare, actualizare);

utilizarea datelor (obtinere de documente, de diverse rapoarte, analize „What-If”, sprijin decizional, diferite cautari de informatii, control si auditare intreprindere).

Modelul conceptual al datelor inseamna o modalitate de reprezentare a datelor organizatiei. Rolul sau este de a scoate in relief toate regulile privind identitatea si legaturile existente intre date  [1].

Cea mai cunoscuta forma utilizata pentru modelarea datelor este diagrama entitate-relatie (DER). O modalitate aproape identica este folosita si in analiza si proiectarea orietata-obiect.

Modelarea datelor prin DER prezinta caracteristicile si structura datelor independent de modul in care acestea sunt memorate in calculator. Modelul se creeaza iterativ. De cele mai multe ori, operatiunea are loc la nivel de intreprindere, prin apelarea la o categorie foarte larga de date neglijandu-se detaliile exagerate. Doar in etapele urmatoare, in speta cand se trece la definirea proiectului, are loc construirea unui model anume entitate-relatie prin care sa fie scoasa in evidenta aria de intindere a proiectului. In timpul structurarii cerintelor, un model entiatate-relatie reprezinta cerintele conceptuale de date pentru sistemul luat in discutie. Dupa ce sunt descrise complet intrarile si iesirile sistemului in cadrul proiectarii logice, modelul conceptual al datelor, redat sub forma entitate-relatie, este rafinat inainte de a fi trecut intr-un format logic (de regula, un model relational al datelor) din care se definesc bazele de date si are loc proiectarea fizica a acestora  [1].

DER joaca un rol deosebit de important in formarea profesionala a veritabililor analisti.

Se considera ca, in timpul modelarii conceptuale a datelor, se produc si se analizeaza cel putin patru diagrame entitate-relatie  [1]:

1.     DER care sa acopere datele necesare aplicatiei proiectului. Ea va permite stabilirea necesarului de date ale aplicatiei proiectului, fara sa se tina seama de constrangerile sau confuziile generate de detaliile care nu sunt inca necesare.

2.     DER pentru aplicatia ce va fi inlocuita. Diferentele dintre aceste diagrame arata ce schimbari trebuie intreprinse pentru convertirea bazei de date in noua aplicatie. Nu se aplica in cazul sistemelor complet noi.

3.     DER care sa scoata in relief intreaga baza de date din care noua aplicatie isi va extrage datele. Cat timp mai multe aplicatii pot folosi aceeasi baza de date, aceasta diagrama si prima evidentiaza modul in care noua aplicatie apeleaza la continutul unor baze de date mult mai extinse.

4.     DER pentru intreaga baza de date din care aplicatia curenta isi extrage datele necesare. Ea este discutata doar pentru sistemele care exista si pentru care se urmareste imbunatatirea. Din nou, diferentele dintre diagrama precedenta si cea de fata vor indica modificarile majore de efectuat pentru a se putea influenta noua aplicatie.

Metodele de determinare a cerintelor trebuie sa fie orientate, prin intrebarile puse, prin anchetele efectuate, si asupra datelor, nu numai asupra proceselor si logicii lor. La inceput, chiar fara utilizarea unei terminologii de specialitate, analistul va fi preocupat de modul in care va afla cat mai multe informatii despre datele necesare viitorului sistem pentru a functiona la parametrii proiectati. Intrebarile vor fi astfel formulate incat sa se realizeze o buna intelegere a regulilor dupa care vor fi folosite datele in noul sistem, ce politici vor fi utilizate. Nu trebuie, inca, sa se intre in detalii de genul: cand si cum sunt prelucrate sau folosite datele, pentru a se realiza modelarea datelor [1].

Modelarea datelor se realizeaza printr-o combinatie a punctelor de vedere.

Un prim punct de vedere, formulat in literatura sub numele de metoda top-down, va scoate in evidenta regulile derularii activitatii firmei, printr-o intelegere foarte clara a naturii afacerii, si nu se va opri asupra detaliilor privind modul in care ecranele, rapoartele sau documentele sunt folosite in organizatie  [1].

In afara metodei top-down, informatiile necesare construirii modelului datelor se pot obtine si prin urmarirea documentatiei firmei, ecrane, rapoarte, formulare, din interiorul sistemului. Acest proces este cunoscut in literatura de specialitate sub numele de metoda bottom-up [1].

Elementele rezultate vor figura in diagramele fluxurilor de date prin care vor fi evidentiate datele prelucrate in sistem si de aici va rezulta necesarul de date mentinute in baza de date a sistemului.

Definirea conceptului de entitate

Entitatile sunt obiecte sau evenimente (fenomene sau procese economice, in cazul nostru). Obiectele se caracterizeaza printr-o existenta de-a lungul timpului, iar evenimentele isi fac simtita prezenta la un moment dat [1].

La randul lor, obiectelor li se pot asocia cel putin doua evenimente: aparitia si disparitia lor. Exemple: incheierea si incetarea contractului de munca; predarea produselor la sectia expeditie si desfacerea lor la beneficiari s.a.

La fel putem spune si despre evenimente. Ele reprezinta asocieri intre doua sau mai multe obiecte. Exemplu: CLIENT COMANDA PRODUS.

Entitatile contin in structura lor atributele prin care ele sunt descrise.

O entitate este o persoana, un loc, un obiect, eveniment sau concept din domeniul de activitate a utilizatorului despre care organizatia doreste sa pastreze anumite date. Se cuvine precizata diferenta dintre tipurile entitatilor (entity types) si cazurile/instantele entitatii (entity instances) [1].

Tipul entitatii, cunoscut si sub numele de clasa entitatii, este o colectie de entitati care au proprietati sau caracteristici comune. Fiecarui tip de entitate i se atribuie un nume. Cat timp numele reprezinta o clasa sau un set de cazuri, el este singular. Si inca o conventie. Cum referirea generala la elementele ce pot fi catalogate ca entitati se poate face prin notiunea de obiect (desi sensul lui poate fi altul in contextul analizei si proiectarii orientate obiect), referirea la acesta se va realiza printr-un substantiv la singular. Se vor folosi litere majuscule, plasate in interiorul dreptunghiului corespunzator entitatii.

O instantiere a entitatii sau instanta, denumita de noi in continuare, caz al entitatii sau caz, este o manifestare singulara a unui tip de entitate. Un tip de entitate se descrie o singura data prin modelul datelor, in timp ce mai multe cazuri ale acelui tip de entitate pot fi reprezentate prin datele stocate in bazele de date. De exemplu, exista o singura entitate CLIENT, dar ea poate sa aiba sute sau mii de cazuri/instante ale acestei entitati stocate in baza de date.

Atribute

Fiecare tip de entitate are un set de atribute asociate lui.

Un atribut este o proprietate sau o caracteristica a unei entitati care prezinta interes pentru organizatie. La randul lor, si relatiile pot avea propriile lor atribute.

Exemplu de entitate pentru aplicatia DECONTARI si unele dintre atributele posibile:

CLIENT : CodClient, DenClient, AdresaC

Ca si numele tipurilor entitatilor, numele atributelor sunt substantive scrise cu majuscule, plasate in interiorul elipselor, legate de entitatea careia i se asociaza. De multe ori insa, chiar si in cazul folosirii produselor CASE, pentru a nu se incarca o diagrama entitate-relatie, se evita prezentarea atributelor. Operatiunea se face, in schimb, in repository, depozitul de informatii despre proiect. Aici orice atribut se descrie separat, ca orice obiect distinct.

Unul dintre exemplele anterioare poate fi reprezentat in diagrama conform fig. 3.5.

Figura 3.5. Model de reprezentare a atributelor DER

Eseu: Imobilizarile corporale - definiții, concepte, principii și clasificari privind imobilizarile corporale Eseu: Concluzii si propuneri cu privire la interfata subsistemului cu utilizatorul

Cheie candidat si cheie primara

Fiecare tip de entitate trebuie sa aiba un atribut sau un set de atribute prin care sa se efectueze diferentierea unui caz de acelasi tip.

O cheie candidat aste un atribut sau o combinatie de atribute prin care se poate identifica in mod unic un caz (o instanta) al tipului entitatii respective.

Sunt entitati care pot avea doua sau mai multe chei-candidat. In exemplul nostru, pot fi chei-candidat CodClient, NumeClient, AdresaC (presupunand ca ele identifica in mod unic un angajat). Atunci cand sunt mai multe chei-candidat, proiectantul trebuie sa decida care din ele va fi folosita drept cheie-primara.

O cheie-primara este o cheie-candidat care a fost selectata pentru a servi ca identificator de cazuri in cadrul unui tip de entitate [1]

In reprezentarile din DER, in elipsa sau elipsele aferente atributului sau atributelor ce formeaza cheia primara, numele respective se subliniaza (vezi CodClient din entitatea CLIENT ).

Relatiile entitatilor

Relatiile reprezinta legaturile intre componentele unei diagrame entitate-relatie. O relatie este o asociere intre cazurile/instantele uneia sau mai multor tipuri de entitati care prezinta interes pentru organizatie. Ele se pot simboliza printr-un romb. De regula, relatiile sunt redate prin verbe.

Cardinalitatea relatiilor

Presupunem ca exista doua tipuri de entitati, A si B, intre care exista o linie de legatura pentru a marca relatia. Cardinalitatea unei relatii este data de un numar al cazurilor/instantelor entitatii B care pot sau care ar putea sa fie asociate cu fiecare caz al entitatii A. Cardinalitatea este sugerata prin 0 (zero), 1, M (“multe”), cu mentiunea ca ele pot avea prezenta obligatorie sau optionala. Trimiterea la cardinalitate se face in moduri destul de diferite, in functie de notatia folosita. Recomandam citirea cu atentie a diagramelor si descifrarea elementelor strict necesare intelegerii, indeosebi pentru reflectarea cardinalitatii. De exemplu, ea poate fi notata cu semne (0, 1, M, N) sau prin simboluri (linie cu varf simplu de sageata pentru 1, linie cu varf dublu de sageata pentru M. Alteori, 1 se reprezinta prin linie simpla si M prin varf de sageata). In multe materiale, inclusiv produse CASE, se foloseste notatia model-date, cunoscuta mai mult sub numele laba-gastei, conform carei cardinalitatea se reprezinta prin urmatoarele simboluri [1]:

Entitati compuse sau asociative (gerundive)

Atributele pot fi asociate cu o relatie multe-la-multe sau cu o entitate. Un exemplu, din lumea cursurilor-credit, transferabile in cadrul unei perioade. Un student poate lua mai multe cursuri dintr-o lista, dar finalizarea cu nota se poate efectua in momente (la date) diferite. Prezentam, mai jos, cateva dintre datele concrete [1]

Din analiza cazurilor rezulta ca atributul DATA_PROMOVARII nu este o proprietate a entitatii STUDENT, cat timp examenele pot fi date la momente diferite. Dar nu este nici o proprietate a entitatii CURS, cat timp acelasi curs poate fi sustinut la date diferite. In schimb, DATA_PROMOVARII este o proprietate a relatiei dintre STUDENT si CURS. Atributul se asociaza relatiei si se prezinta sub forma de diagrama, ca in fig. 3.7.

Figura 3.7. Asocierea unui atribut la o relatie [1]

De aici rezulta un caz aparte de entitate, numita gerundiva sau compusa sau asociativa care, de fapt, este o relatie folosita de analist in model ca un tip de entitate. In astfel de cazuri, se foloseste un simbol special: dreptunghi cu romb in interior, in care se scrie numele entitatii (fig. 3.8) [1].

Figura 3.8. Redarea unei entitati gerundive (asociative)  [1]

Nu trebuie confundata aceasta situatie cu relatiile transformate in entitati nepurtatoare de informatii, descrise anterior.

Scopul diagramelor entitate-relatie este de a surprinde cele mai complete sensuri posibile ale datelor necesare sistemului informational din organizatie.

Tipuri de relatii

Din cele prezentate mai sus, rezulta ca intre entitatile descrise, luate doua cate doua, se pot identifica trei tipuri de relatii: unu-la-unu, unu-la-multe, multe-la-multe. In diagrame, descrierea relatiilor se face de-a lungul liniilor care leaga cele doua entitati. Simbolul varf-de-sageata este cunoscut ca indicator al cardinalitatii (cardinality indicator).

In cele ce urmeaza sunt prezentate exemple de tipuri de relatii [1]

1.     Relatia unu-la-unu (1:1)

Figura 3.9. Descrierea relatiei 1:1

„Fiecare BIROU este condus de un, si numai un, MANAGER”

„Fiecare MANAGER conduce un, si numai un, BIROU”.

2.     Relatia unu-la-multe (1:M)

Figura 3.10. Descrierea relatiei 1:M

Fiecare VANZARE implica unul sau mai multe ATRICOL(e)_VANDUT(e) “

„Fiecare ATRICOL_VANDUT face parte din numai o VANZARE”

3.Relatia multe-la-multe

Figura 3.11. Descrierea relatiei M:N

“Fiecare FURNIZOR livreaza unul sau mai multe PRODUS(e)”

“Fiecare PRODUS este livrat de unul sau mai multi FURNIZOR(i)”

In anumite cazuri, intre doua entitati pot exista mai multe relatii.

De exemplu, s-ar putea spune ca “FURNIZOR ofera PRODUS”, dar si “PRODUS este cumparat de la FURNIZOR”, ceea ce s-ar putea reprezenta ca in fig. 3.12.

Figura 3. 12. Descrierea relatiilor multiple intre doua entitati

4.Relatii optionale si obligatorii

Alteori, relatiile dintre entitati nu-si fac simtita prezenta in toate situatiile. Chiar cazul cu studiile la care lucreaza diverse persoane este destul de elocvent; o persoana poate sa lucreze la un singur studiu sau la cateva, sau la niciunul si, invers, un studiu poate fi efectuat de o persoana, de mai multe sau de nici una. In astfel de situatii, se apeleaza la urmatoarea forma de reprezentare. (fig. 3.13)

Figura 3.13. Exemplu de relatie optionala

Cercul suprapus pe latura entitatii indica, de fapt, pozitia 0 (valoarea minima poate fi si zero), conferind relatiei caracterul optional.

Un alt aspect se refera la caracterul obligatoriu al relatiilor. Cu alte cuvinte, o entitate poate exista fara cealalta?

Sa luam exemplul vanzarilor. In relatia 1:M, dintre VANZARE si ARTICOL_VANDUT. Ar fi total eronat ca o entitate sa existe fara cealalta: nu poate fi o vanzare fara cel putin un articol vandut si, invers, un articol nu poate fi vandut fara o vanzare (operatiunea nu ar avea sens). Simbolul folosit pt a marca relatiile obligatorii este acelasi cerc, cu deosebirea ca este hasurat.

Figura 3.14. Exemplu de relatie obligatorie

5.Relatia unei entitati cu ea insasi

In practica, apar si situatii in care o entitate este pusa in relatie cu ea insasi.

Ne oprim la exemplul entitatii ANGAJAT. Unii dintre ei dobandesc statutul de coordonatori ai activitatii celorlalti, situatii in care se poate apela la o diagrama de genul celei din fig.3.15.

Figura 3.15. Redarea relatiei unei entitati cu ea insasi

Reprezentarea anterioara se citeste astfel:

“Un angajat poate fi coordonatorul unuia sau mai multor angajati”

“Oricare angajat intotdeauna raporteaza altui angajat”

6.Relatii alternative (sau/sau)

Uneori se ivesc situatii cand relatiile posibile se redau alternativ: fie o varianta este de urmat, fie cealalta. De exemplu, o marfa destinata vanzarii poate fi realizata de unitatea care o vinde sau poate fi procurata din afara. In ambele cazuri, obiectul comercializat, MARFA, care este o entitate, va fi pusa in legatura cu cele doua surse posibile, PRODUCTIA_ALTORA si PRODUCTIA_PROPRIE, printr-un punct comun, dar nu cu linii de relatii distincte, asa cum este prezentat in figura 3.16.

Figura 3.16. Exemplu de diagrama pentru relatiile alternative

Citirea diagramei este:

“O marfa se poate asocia sau cu un producator din afara, sau cu productia unitatii”

“Un producator din afara poate livra mai multe marfuri”

“O linie proprie de productie poate livra mai multe marfuri”

Desi diagramele entitate-relatie se cunosc de catre multi specialisti din lumea bazelor de date, ele constituie unul din conceptele esentiale ale analizei si proiectarii structurate si, ca atare, provin din acest domeniu  [1].

Dupa cum reiese si din citirea cu atentie a numelui diagramei, scopul ei este de a evidentia entitatile de date (obiectele despre care se solicita pastrarea datelor) si relatiile ce exista intre ele.

De remarcat diferenta dintre diagrama fluxului de date si diagrama entitate-relatie. In timp ce diagrama fluxurilor de date indica atat procesele de prelucrare, cat si entitatile de date (redate fie sub forma fluxurilor de date, fie a locurilor de stocare), DER trateaza doar entitatile de date. Din aceasta cauza, DER poate fi considerata si ca diagrama modelului datelor sau diagrama conceptuala a datelor [1].

In sistemul analizat pentru descrierea DER se apeleaza la simbolul dreptunghi, pentru fiecare entitate. Se recomanda ca numele entitatii sa fie redat printr-un substantiv la singular (CLIENT, PRODUS, SALARIAT, FACTURA_DESFACERE, INCASARI).

Dupa ce se identifica entitatile se continua cu imperecherea lor, fiecare cu fiecare, pentru a descrie relatiile dintre ele.

Figura 3.17. DER pentru aplicatia Decontari

1. Modelul Entitate/Relatie (E/R)

Cercetarile efectuate pentru definirea unui model de date care sa permita reprezentarea cat mai fidela a realitatii au condus la definirea conceptului de model semantic inca din 1976 cand Chen a prezentat modelul Entitate-Relatie (E/R), care constituie astazi o tehnica larg acceptata pentru proiectarea bazelor de date.

Modelul E/R permite proiectantului bazei de date sa elaboreze un model conceptual de nivel inalt, fara a tine seama de anumite constrangeri impuse de utilizarea unui anumit SGBD, de o anumita platforma hardware, sau de anumite considerente de eficienta privind exploatarea bazei de date, ceea ce permite o reprezentare mai fidela a realitatii avute in vedere, constituind astfel o etapa intermediara in proiectarea unei baze de date, fiind din acest punct de vedere asemanator pseudocodului utilizat in activitatea de programare.

Modelul Entitate/Relatie (E/R) permite reprezentarea schematica a realitatii avute in vedere cu ajutorul unei diagrame E/R definita plecand de la conceptele de baza: tip de entitate, tip de relatie (legatura, corelatie), atribut.

Pentru reprezentarea unor probleme complexe de tip baza de date, aparute incepand din anii 80, modelul de date semantic a fost extins cu noi concepte semantice, rezultand astfel modelul entitate relatie extins EER. In acest sens la conceptele de baza au fost adaugate conceptele suplimentare de superclasa, subclasa si mostenire.

O superclasa reprezinta un tip de entitate care contine subclase distincte care trebuie sa fie reprezentate in cadrul modelului, iar o subclasa este un membru al unei superclase. O subclasa, fiind un tip de entitate distinct, poate avea la randul sau subclase, astfel incat se pot construi ierarhii de clase. O subclasa mosteneste toate atributele superclasei, putand avea in plus si alte atribute. In diagrama EER, pentru subclase se vor reprezenta numai atributele specifice subclasei.

Pentru elaborarea unei diagrame EER, se utilizeaza [11], [13] o serie de simboluri reprezentate in figura 3.18.

Problema rezolvata

Folosind modelul entitate - relatie sa se reprezinte diagrama E/R pentru un sistem informatic simplificat al unei firme care desfasoara activitate de comert fiind avute in vedere subsistemele;

aprovizionare (evidenta furnizorilor);

desfacere (situatia vanzarilor);

urmarirea stocurilor.