2 MODELAREA CONCEPTUALĂ A DATELOR 2.1 Modelul Entitate-Asociere (EA) Pentru definirea modelului conceptual al datelor se apelează la modele intermediare care sunt folosite ca suport al unei metodologii de proiectare. Un model conceptual este un ansamblu de concepte şi reguli de combinare a acestor concepte permiţând reprezentarea realităţii circumscrise domeniului supus informatizării. Modelele utilizate se numesc modele semantice şi au drept obiectiv ca prin conceptele oferite să permită reprezentarea lumii reale. Modelele semantice utilizează abstracţii reprezentând lumea reală ca pe o colecţie de entităţi şi de legături, stabilite între acestea. Majoritatea modelelor permit definirea de restricţii descriind aspectele statice, dinamice sau chiar temporale ale entităţilor. Modelul entitate-asociere (EA) pe care îl vom utiliza în continuare pentru definirea modelului conceptual al datelor este şi el un model semantic. Sistem informaţional Proceduri Informaţii
Documentare şi analiză
Informaţii şi legături dintre informaţii
Proceduri şi reguli de gestiune
Modelare
Modelul conceptual al datelor - date - tipuri de entităţi - asocieri între entităţi
Modelul conceptual al prelucrărilor (MCP)
Figura 2.1 Procesul de modelare a datelor şi prelucrărilor Modelul EA urmăreşte obţinerea unei reprezentări fidele, utilizând concepte specifice, a realităţii (problemei de rezolvat ce urmează a fi informatizată). Această reprezentare a lumii reale se va realiza făcându-se abstracţie de orice restricţie fie ea informatică sau organizatorică. Pornind de la semantica obiectelor lumii reale şi a legăturilor stabilite între acestea modelul EA serveşte în egală măsură ca un mijloc de comunicare între modelator (informatician) şi viitorul utilizator al sistemului (beneficiarul sistemului informatic), care descrie realitatea supusă modelării în conformitate cu propria lui percepţie.
Concepte de bază ale modelului Entitate Asociere ENTITATEA reprezintă un obiect al realităţii modelate caracterizat printr-o existenţă proprie, cu o identitate proprie (care-l face identificabil în raport cu celelalte obiecte de acelaşi tip) şi o mulţime de caracteristici care exprimă proprietăţile acestuia. Pentru exemplificare vă propunem ca domeniu de studiu gestiunea poliţelor încheiate de o societate de asigurări. Entităţile pe care le putem defini sunt: o poliţă de asigurare, instrumente de plată, etc. Entitatea poliţă de asigurare nr. 25 se defineşte prin următoarele realizări ale caracteristicilor: 15/03/2002 (data încheierii), Ionescu Costel (numele agentului de asigurare), Popescu Marius (titularul poliţei de asigurare), 22/03/2002 (data inceperii perioadei asigurate), etc. Entitatea poliţă de asigurare nr. 25 are propria identitate, distingându-se clar de celelalte entităţi de acelaşi tip (celelalte poliţe încheiate) prin numărul său şi are o existenţă de sine stătătoare (Figura 2.2). 25 15/03/2002 Ionescu Costel Popescu Marius 22/03/2002
27 10/03/2002 Ionescu Costel Popescu Ion 17/03/2002
117 11/03/2002 Ion Dan Manea Marian 18/03/2002
Figura 2.2 Entităţi aparţinând tipului de entitate poliţă de asigurare În activitatea de modelare interesul se focalizează pe definirea tipurilor de entităţi aparţinând problemei de rezolvat şi nu pe entităţi care reprezintă realizările tipurilor de entităţi. În locul noţiunii de tip de entitate, unii autori folosesc conceptul de clasă de entităţi. Modelul abstract pe care ni-l oferă modelul EA se bazează tocmai pe aceste tipuri generice de entităţi şi a legăturilor stabilite între acestea. TIP DE ENTITATE reprezintă un concept generic desemnând mulţimea tuturor entităţilor prezentând aceleaşi caracteristici constructive. Exemple : produs, comandă, angajat, student, contract, poliţă de asigurare, depozit bancar, ordin de tranzacţionare la bursă etc. De această dată tipul de entitate produs desemnează ansamblul produselor aflate în catalogul firmei, produse descrise plecând de la aceleaşi caracteristici comune: codul produsului, denumirea, unitatea de măsură, data omologării, procent TVA. Tipul de entitate student desemnează ansamblul studenţilor caracterizaţi prin aceleaşi trăsături comune: număr matricol, nume, data-naşterii, localitatea, facultatea, specializarea etc. POLIŢĂ DE ASIGURARE
TIP DE ENTITATE
Număr Data încheierii Agentul Beneficiarul Data începerii
ATRIBUTE
Realizări ale atributelor
ENTITĂŢI 25 15/03/2002 Ionescu Costel Popescu Marius 22/03/2002
27 10/03/2002 Ionescu Costel Popescu Ion 17/03/2002
117 11/03/2002 Ion Dan Manea Marian 18/03/2002
Figura 2.3 Entităţi aparţinând aceluiaşi tip
Atenţionăm asupra faptului că o entitate poate aparţine mai multor tipuri de entităţi diferite. De exemplu, entitatea cititorului Ionescu poate aparţine şi tipului de entitate profesor şi tipului de entitate doctoranzi (desemnând ansamblul persoanelor care urmează forma de pregătire doctorală). Fiecare tip de entitate se defineşte prin mulţimea caracteristicilor comune entităţilor aparţinând tipului. ATRIBUTUL defineşte o proprietate distinctă a unei entităţi. Fiecare atribut prezintă un domeniu, adică o mulţime de valori admise. Într-o entitate se regăsesc realizări corespunzătoare caracteristicilor definitorii pentru tipul de entitate. Atributele pot fi clasificate în funcţie de mai multe criterii: a) După complexitate atributele sunt: • elementare (simple) ale căror realizări nu pot fi descompuse (exemplu: unitate monetară, preţ unitar, număr matricol al studentului, marca angajatului, etc). • decompozabile (complexe) ale căror realizări sunt decompozabile (ex: data calendaristică – se poate descompune în zi, lună, an; adresa - se poate descompune în stradă, număr, codul de clasificare al unui mijloc fix, etc). b) După realizările pe care le pot prezenta atributele pot fi: 1) • obligatorii (trebuie să prezinte obligatoriu o realizare, ceea ce corespunde sintagmei NOT NULL – orice realizare). • opţionale ( sunt atribute care pot să nu prezinte nici o valoare (realizare) în cadrul unei entităţi (de exemplu atributele: telefon, fax, e-mail - nu toate persoanele au telefon, fax, adresă e-mail). 2) • monovaloare: atribute care prezintă o singură valoare în cadrul unei entităţi (exemplu: nume student, nr. matricol, data naşterii, codul numeric personal etc). • multivaloare: atribute care prezintă mai multe realizări în cadrul aceleiaşi entităţi (de exemplu, în tipul de entitate ANGAJAT, entitatea Popescu Marius poate prezenta pentru atributul STUDII mai multe valori: Facultatea de Mecanică, Facultatea de Finanţe Asigurări Bănci şi Burse de Valori). CONT BANCAR Nr. Cont Tip Cont Data Deschiderii Limită credit Moneda Figura 2.4. Tipul de entitate Cont Bancar Problema de modelat este adesea deosebit de complexă în cadrul ei putându-se identifica obiecte simple, compozite şi/ sau complexe. În modelul EA obiectelor lumii reale le corespund entităţi, iar entităţile definite prin aceleaşi caracteristici formează un tip de entitate. Aceasta înseamnă că obiectelor simple le va corespunde în modelul conceptual al datelor câte un tip de entitate. Exemplu: pentru conturile deschise de o bancă se poate defini în cadrul modelului conceptual al datelor tipul de entitate cont bancar (Figura 2.4). Clienţilor (persoane fizice) ai unei bănci, deoarece sunt definiţi prin aceleaşi caracteristici (nume client, cod numeric personal, cod de identificare în cadrul băncii, adresa etc), le va corespunde în modelul EA un singur tip de entitate, numărul de realizări ale acestuia (de entităţi) fiind egal cu numărul clienţilor. Obiectele compozite se caracterizează prin faptul că ele conţin una sau mai multe caracteristici multivaloare (cărora în modelul EA le vor corespunde atribute multivaloare). Aceasta va determina ca în modelul conceptual optimizat al datelor acestui obiect compozit să-i corespundă mai multe tipuri de entităţi (atributele multivaloare se vor regăsi într-un tip de entitate distinct).
Exemplu: Documentelor bonuri de consum le va corespunde tipul de entitate bon de consum definit prin atributele monovaloare: număr bon, data bon, secţia, gestiunea dar şi atributele multivaloare: cod material, cantitate eliberată, preţ unitar. Aceasta face ca tipul de entitate bon de consum, definit iniţial prin mulţimea tuturor atributelor mai sus menţionate, să conducă în final la definirea a două tipuri de entităţi: Bon de consum (documentul în sine) definit prin atributele: număr bon, data bon, secţia, gestiunea şi tipul de entitate Material eliberat definit prin atributele: cod material, cantitate eliberată, preţ unitar (Figura 2.5). Într-un mod asemănător putem reprezenta în modelul EA facturile, comenzile emise de clienţi pentru livrarea produselor etc. Obiectele compuse sunt decompozabile ele regrupând în structura lor obiecte simple între care există o anumită legătură. Chiar dacă în modelul EA iniţial pentru un obiect compus s-a definit un singur tip de entitate, ulterior acesta se va descompune în tipuri de entităţi de sine stătătoare corespunzătoare obiectelor elementare care intră în structura obiectului compus (Figura 2.6). BON DE CONSUM Obiect compozit Nr. bon Data bon Secţia Gestiunea
Caracteristici multivaloare (un bon de consum serveşte la eliberarea din magazie a mai multor materii prime)
Cod material Cantitate eliberată Preţ unitar Tip de entitate Bon de consum Nr bon Data bon Secţia Gestiunea
Material eliberat Cod material Cantitate eliberată Preţ unitar
Figura 2.5 Reprezentarea obiectelor compozite sub formă de tipuri de entităţi Obiect compus
CONTRACT DE CREDIT NR CONTRACT DATA CONTRACT TITULAR VALOARE CONTRACT UNITATE MONETARA GARANTII
TITULAR COD IDENTIFICARE NUME CNP ADRESA DATA NASTERII
Tipuri de entităţi
GARANTIE NR DOCUMENT DATA EMITERII BANCA EMITENTA SUMA
Figura 2.6 Reprezentarea obiectelor compuse sub formă de tipuri de entităţi
Tipul de entitate contract de credit - definit prin atributele: număr contract, data contract, titular, valoare contract, unitate monetară, garanţii – corespunde unui obiect compus al realităţii de modelat. Titularul şi garanţia sunt două obiecte distincte ale problemei de modelat, fiecăruia trebuind să-i corespundă în MCD un tip de entitate distinct. Ca urmare, se vor include în MCD tipurile de entităţi: TITULAR definit prin: Cod identificare, nume, cod numeric personal, adresă, data naşterii. GARANŢIE care poate fi reprezentată, de exemplu, de o scrisoare de garanţie bancară definită prin atributele: număr document, data emiterii, banca emitentă, termen de valabilitate, sumă. CONTRACT DE CREDIT definit prin: Nr. Contract, Data contract, Valoare contract, Moneda. Fiecare tip de entitate prezintă un IDENTIFICATOR reprezentat de un atribut sau un grup minimal de atribute al cărui rol este de a permite identificarea în mod unic, fără echivoc, a entităţilor. De multe ori identificatorul este reprezentat de un atribut de tip “număr de ordine” (incrementat cu 1 pentru fiecare nouă valoare atribuită) sau de un cod (construcţie artificială având o anumită semnificaţie). Exemple: pentru tipul de entitate STUDENT identificatorul va fi Nr Matricol, în cazul entităţii BON CONSUM identificatorul va fi atributul Nr. Bon (atribut de tip număr de ordine), etc. În reprezentarea grafică a tipului de entitate identificatorul este marcat distinct prin subliniere (Figura 2.7). STUDENT Nr matricol Nume student Data naşterii Adresa
Figura 2.7 Tipul de entitate Student
ASOCIEREA dintre entităţi exprimă legătura stabilită dintre acestea şi rolul pe care îl joacă fiecare entitate participantă la legătură. Exprimând o legătură dintre entităţi ea nu are o existenţă de sine stătătoare. O asociere poate prezenta unul sau mai multe atribute proprii cu rol de a caracteriza, explicita, legătura stabilită între entităţile participante la asociere. Atributele Data debut şi Data sfârşit caracterizează asocierea Ocupă şi aceasta deoarece ele nu sunt proprietăţi ale entităţii Camere, aceiaşi cameră cu nr. 10 poate fi ocupată la date diferite şi de către clienţi diferiţi. Fiecare entitate participantă la asociere joacă un anumit rol. În exemplul prezentat în figura 2.8 entitatea Client joacă rolul Ocupant (clientul x ocupă în data y camera z) iar entitatea Camera prezintă rolul este ocupată (camera z este ocupată în data y de clientul x).
TIPUL DE ASOCIERE se defineşte ca ansamblul legăturilor, prezentănd aceeaşi semnificaţie, dintre entităţile aparţinând la două sau mai multe tipuri de entităţi. Exemplu: tipul de asociere Ocupă din figura 2.8. Cardinalităţi 1,n
CLIENŢI Cod client Nume Adresa CNP
Ocupă Data debut Data sfarsit
Ocupant
CAMERE
1,n
Nr cameră Tip Tarif cameră
Este ocupată
Roluri
Figura 2.8 Tipul de asociere Ocupă CARDINALITATEA cuplului entitate-asociere reprezintă cuplul de valori întregi (x,y) astfel încât: • x (cardinalitate minimală) exprimă numărul minim de realizări ale legăturii (asocierii) existând pentru o entitate. • y (cardinalitate maximală) reprezintă numărul maxim de apariţii ale corespondenţei putând exista pentru o entitate. • Cardinalitatea minimală 0 indică faptul că pot exista entităţi care să nu participe la nici o asociere: Există clienţi potenţiali ai unei firme cărora încă nu li s-au încheiat poliţe de asigurare – cardinalitate minimală 0, dar sunt clienţi cărora li s-au încheiat mai multe poliţe – cardinalitate maximală n. CLIENT
0,n
POLIŢA
1,1
Cod client Nume Adresa CNP
Nr. poliţă Data poliţă Valoare asigurată
incheie
Figura 2.9 Cardinalitatea minimală 0
Cardinalitatea minimală 1 indică faptul că toate realizările tipului de entitate trebuie să participe la o realizare a tipului de asociere. De exemplu, orice contribuabil aflat în evidenţa administraţiei financiare are deschis un rol şi numai unul singur (în acest caz şi cardinalitatea maximală este tot 1).
CONTRIBUABIL Cod-identificare Nume Adresa
ROL
1,1
1,1 ARE
Nr rol Data deschiderii
Figura 2.10 Cardinalitatea minimală 1
Cardinalitatea maximală 1 indică faptul că numărul de roluri deschise unui contribuabil la administraţia financiară nu poate fi mai mare de 1. Săgeata din figura 2.10 indică caracterul imuabil al asocierii (rolul fiscal nu-şi modifică titularul). Cardinalitatea maximală n indică faptul că mai multe entităţi de un anumit tip participă la o asociere. Un client emite unul sau mai multe documente de plată (Figura 2.11). POLIŢA
1,4
Nr. Poliţă Data încheierii Data început Data sfârşit Valoare asigurată
PRIME DE PLATĂ
1,1
Data scadenţei Suma de plată
prevede
Figura 2.11 Cardinalitatea maximală n Dar uneori valoarea lui N poate fi specificată clar printr-o constantă. De exemplu, pentru o poliţă de asigurare (încheiată pe un an) sunt calculate maxim 4 prime de asigurare - câte una pe trimestru (figura 2.12). Valorile uzuale pentru exprimarea cardinalităţii sunt : 0,1; 1,1; 0,n;1,n. CLIENT
1,n emite
Cod client Nume Adresa CNP
DOCUMENT
1,1
Nr doc Data doc Tip doc Sumă
Figura 2.12 Cardinalitatea maximală 4 Între realizările a două tipuri de entităţi se pot stabili mai multe asocieri prezentând semantică diferită şi prin urmare cardinalităţi diferite. Exemplu: un profesor lucrează la o disciplină cu un grup de studenţi, unora dintre aceştia (maxim 10) conducându-le şi proiectul de semestru la disciplina respectivă (figura 2.13).
PROFESOR
1,n
Cod ID Nume Grad didactic Titlu ştiinţific
lucrează
STUDENT Nr. Matricol Nume student
conduce 1,1
1,10
Figura 2.13
După numărul de tipuri de entităţi participante asocierea poate fi: • unară (refexivă) • binară • complexă Asocierea reflexivă (ciclică, unară) se caracterizează prin faptul că exprimă legăturile stabilite între entităţi aparţinând aceluiaşi tip (figura 2.14).
0,N
MATERIAL
0,N
COD DENUMIRE UNIT. DE MĂSURĂ
Substituie
Este substituit
Substituie Cantsubstit
Figura 2.14 Asocire reflexivă Spre exemplu, o materie primă necesară pentru fabricarea unui produs poate fi substituită (dacă nu există cantitatea necesară în stoc) printr-o altă materie primă (având aceleaşi caracteristici dar spre exemplu o altă concentraţie) într-o anumită cantitate. Asocierile binare reprezintă legături (corespondenţe) stabilite între realizările aparţinând la două tipuri de entităţi diferite. Exemplu: asocierea Prevede stabilită între tipul de entitate POLIŢĂ şi tipul de entitate PRIMA DE PLATĂ (figura 2.12) sau asocierile Lucrează şi Conduce din figura 2.13. Asocierile complexe exprimă legături stabilite între realizările mai multor tipuri de entităţi. Spre exemplu, o entitate ternară se poate stabili între tipurile de entităţi: CONTRIBUABIL, TAXA, DOCUMENT DE PLATĂ (DOC PLATA). 1,N
1,1
Plăteşte
Contribuabil
Doc. plată
Plătitor 0,N
Plătită
Emis
Taxă
Figura 2.15 Asociere ternară Se recomandă însă reducerea acestor asocieri complexe la asocieri binare. Astfel asocierea ternară prezentată în figura 2.15 se descompune conform figurii 2.16 în asocieri binare. În continuare prezentarea se va referi doar la asocierile binare.
0,N Achită
Contribuabil
Datorează Suma
1,1 Doc plată
1,N 1,N
1,N 0,N
Taxe
Privesc
Figura 2.16 Descompunerea unei asocieri ternare în asocieri binare
2.2. Restricţii de integritate Restricţiile de integritate definesc cerinţele pe care datele trebuie să le respecte pentru a fi corecte şi coerente în raport cu realitatea pe care o reflectă. Restricţiile de integritate reprezintă o modalitate de integrare a semanticii datelor în mod indirect în modelul entitate asociere pe care astfel îl îmbogăţesc. Restricţiile de integritate privesc: • valorile pe care le pot lua atributele entităţilor şi asocierilor; • valorile identificatorilor entităţilor; • rolurile jucate de entităţi în asocierile la care participă; • asocierile stabilite între entităţi. Pentru modelul EA prezentat în Figura 2.17 pot fi definite următoarele restricţii de integritate privitoare la realizările atributelor: data documentului (comenzii) să fie anterioară datei curente sau egală cu aceasta, cota de TVA poate fi 0 %, sau 19%, produsul cel mai vechi din nomenclatorul de fabricaţie a fost omologat în 12.12.99, iar numărul gestiunii poate lua valori în mulţimea M={1,2,3}, tipul depozitului poate fi frigorific/nefrigorific, unităţile de măsură sunt KG şi BUC. Restricţiile de integritate pot fi statice (se verifică permanent) sau dinamice (privesc evoluţia în timp a datelor). De exemplu, restricţiile referitoare la numărul gestiunii, tipul depozitului şi unităţile de măsură sunt statice. Restricţia privind cota de TVA este dinamică ea putându-se modifica în timp în conformitate cu prevederile fiscale în vigoare.
0,N
1,N
Comanda
Cod produs Denumire Preţ catalog TVA Data omologării Unit măsură
Cuprinde Nr doc Data-doc
Produs
Cantitate
Gestiune Număr gestiune Nume gestionar Tip depozit
1,n
1,n Depozitat Stoc Data stoc
Figura 2.17. Model EA
2.2.1. Restricţii de domeniu Domeniul, ca mulţime de valori pe care le poate lua un atribut, poate fi definit printr-o proprietate (o condiţie privind un atribut sau un grup de atribute), prin precizarea unui interval de valori sau prin enumerarea mulţimii de valori admise. Restricţiile de domeniu reprezintă condiţii (reguli) care privesc ansamblul de valori admise pentru un atribut în cadrul tipului sau domeniului său. Restricţiile pot viza realizările unui/unor atribute aparţinând unei aceleiaşi entităţi sau asocieri, caz în care se numesc restricţii intraentitate, sau a unui/unor atribute aparţinând unor entităţi şi/sau asocieri diferite, caz în care se numesc restricţii interentităţi. Restricţiile pe domeniu se pot exprima cu privire la: 1. Conţinutul unui singur atribut al unei entităţi sau asocieri: Exemplu: Unit. Măsură={ “KG”,”Buc”} TVA = { 0, 19} Preţ > 10000 şi preţ <10000000 Cantitate > 10 (cantitatea este un atribut definit pentru asocierea CUPRINDE din Figura 2.17). 2. Corelaţiile ce trebuie să se respecte între valorile mai multor atribute sau asocieri aparţinând aceleiaşi entităţi sau asocieri: Exemple: Număr gestiune=1 atunci nume gestionar = “Ion Toma” Cod produs=12 atunci Unit Măsură=”BUC” 3. Corelaţiile care trebuie să existe între atributele aparţinând mai multor entităţi sau asocieri diferite: Exemplu: În gestiunea 1 se stochează doar produsele având codurile în mulţimea {1000, 1001, 1014}. Data-stoc > data omologării Cod produs=112 atunci număr gestiune=1 4. Corelaţii realizate pe baza unor valori obţinute prin operaţii de sintetizare (însumare, calculul mediei, valorii minime /maxime etc.) a unui ansamblu de entităţi: Exemplu: Suma cantităţilor comandate pentru un produs nu poate depăşi stocul din data respectivă. Preţul mediu al produselor >200000
2.2.2. Restricţii structurale Identificarea entităţilor Fiecare entitate va trebui să poată fi identificată fără echivoc. Acest lucru impune ca identificatorul entităţii să ia valori unice diferite de NULL (NULL înseamnă că nu s-a atribuit nici o valoare, deci valoarea NULL este diferită de zero sau spaţiu). În definirea modelului EA putem întâlni cazuri mai speciale legate de identificarea entităţilor: 1. Nu putem defini un identificator sub forma unui atribut/grup de atribute pentru un anumit tip de entitate (Figura 2.18). Exemplu: Pentru fiecare angajat al firmei se consemnează lunar prezenţa prin reţinerea orelor efectiv lucrate, orelor absentate, orelor de concediu medical. Identificarea entităţilor Prezenţa se face prin rolul Realizează pe care entitatea Angajat îl joacă în asocierea Înregistrează Identificarea prin rol a entităţilor se poate realiza doar dacă asocierea în cauză nu este ciclică (unară) iar cardinalitatea cuplului entitate identificată-asociere este 1,1 şi cardinalitatea cuplului entitate identificator - asociere este 1,1 sau 0,1. 1,1 ANGAJAT Marca Nume Funcţie Salariu
1,1 Înregistrează
Ore efective Ore absenţe Ore concediu Ore medical
Luna
Realizeză
PREZENŢA
Aparţine
Figura 2.18 2. Identificarea unei entităţi se poate realiza prin unul sau mai multe atribute proprii împreună cu rolul jucat de alt tip de entitate (figura 2.19) în cadrul asocierii. ASIGURARE
1,n
Nr. polită Data Val. asigurare
1,1 Prevede
Cuprinde
PRIME ASIGURARE Data scadenţă Sumă de plată
Priveşte
Figura 2.19 O poliţă de asigurare de viaţă presupune pe lângă specificarea numărului, datei încheierii poliţei, valorii asigurate şi precizarea primelor de plată cu înscrierea datei limită a plăţii precum şi a sumei de plată ( considerăm că sumele sunt diferite de la o scadenţă la alta). Fiecare poliţă se identifică prin număr, atribuit în mod unic. Pentru tipul de entitate Scadenţa, atributul Data scadenţei nu poate fi identificator deoarece, la aceeaşi dată mai multe poliţe au acelaşi termen limită de plată. Identificarea entităţilor Prime asigurare se va realiza prin valorile atributului propriu Data scadenţei şi rolul Cuprinde jucat de entitatea Asigurare în asocierea Prevede.
2.2.3. Restricţii de integritate de roluri În definirea asocierii am subliniat faptul că aceasta exprimă legătura stabilită între entităţi diferite, fiecare dintre acestea jucând un anumit rol. Plecând de la rolurile jucate de entităţi în cadrul asocierilor putem defini o serie de restricţii de integritate şi anume de : egalitate, incluziune şi excluziune de roluri. Restricţia de incluziune de roluri Restricţia de incluziune de roluri statuează faptul că, dacă o entitate E1 care joacă rolul r1 în asocierea A1 va trebui să joace şi rolul r2 în asocierea A2. Rezultă că rolul r1 include (implică prin incluziune) rolul r2 . Pentru reprezentarea restricţiei de incluziune de roluri se va utiliza următoarea reprezentare grafică: I
r1
r2
Figura 2.20 Incluziune de roluri Un exemplu îl constituie secvenţa de MCD elaborat pentru o firmă de asigurări. (Figura 2.21). Clienţii încheie poliţe de asigurare şi primesc despăgubiri la producerea riscului asigurat dacă au la zi plata primelor de asigurare. Între rolul despăgubită şi rolul achitată se manifestă o restricţie de incluziune pe rol. De asemenea este o restricţie de integritate pe rolurile despăgubită şi încheiată pe care le joacă entitatea poliţă. I
CLIENT
Cod client Nume client Adresa
încheiată 1,1
1,n încheie
POLIŢA
Nr poliţa Data poliţa Data inceput Data sfârşit Nume agent
achitată
despăgubită 1,1 1,1 calculează
1,n
achită 1,1 PLATA PRIME Nr chitanţă Data chitanţă Suma plătită
Figura 2.21. Incluziune de roluri
calculată
I
DESPAGUBIRE Nr. Document Data document Sumă despăgubită
Restricţia de egalitate de roluri Egalitatea de roluri presupune ca restricţia de incluziune între roluri să fie reciprocă. Grafic restricţia de egalitate de roluri se reprezintă conform figurii 2.22. r1
r2
=
Figura 2.22. Egalitatea de roluri Persoanele care au un rol (fişă) deschis la administraţia financiară, deci joacă rol de posesor în asocierea Are, înseamnă că au obligaţii fiscale, deci joacă rol de contribuabil în asocierea Datorează, reciproca fiind valabilă: orice persoană care are obligaţii fiscale trebuie să aibă deschis un rol. Dar nu Posesor toate persoanele sunt contribuabili, deci există entităţi ale tipului Persoana care nu joacă rolul de Posesor în asocierea Are. Grafic, egalitatea de roluri se reprezintă conform figurii 2.23. Rol
Persoana
1,1
0,1
CNP Nume Adresa
Are
Contribuabil 0,n
= 1,n
Nr. rol Data deschid.
Impozit Cod impozit Denumire
Datorează
Figura 2.23. Egalitate de roluri Restricţia de excluziune de roluri Excluziunea de roluri specifică faptul că un rol r1 jucat de o entitate E1 în asocierea A1 exclude existenţa rolului r2 jucat în asocierea A2. r1
#
r2
Figura 2.24. Reprezentarea excluziunii de roluri
Figura 2.25. Excluziunea de roluri
Din exemplele prezentate rezultă că restricţiile de integritate de roluri vizează rolurile pe care o entitate le poate juca în cadrul unor asocieri diferite. Incluziunea de roluri specifică faptul că un rol r2 jucat de entitatea E1 în asocierea A2 este urmarea rolului r1 jucat de aceeaşi entitate în asocierea A1. Restricţia de egalitate de roluri evidenţiază că rolul r1 jucat de entitatea E1 în asocierea A1 determină rolul r2 jucat de aceeaşi entitate în asocierea A2, iar rolul r2 determină în acelaşi timp rolul r1. Resticţia de excluziune de roluri precizează că, dacă o entitate E1 joacă rolul r1 în asocierea A1 nu poate juca rolul r2 într-o altă asociere numită A2. Dar aceste restricţii legate de participarea entităţilor la asocieri nu pot fi judecate doar la nivel de roluri ci este necesară uneori precizarea unor restricţii de integritate la nivelul tipului de asociere, deci a ansamblului de asocieri prezentând aceeaşi semantică.
2.2.4. Restricţii de integritate de asocieri Restricţiile analizate în acest subcapitol vizează asocierea însăşi împreună cu entităţile participante. Altfel spus restricţiile se referă la mulţimea tuturor rolurilor aparţinând asocierii. Restricţia de incluziune de asocieri Restricţia de incluziune exprimă faptul că asocierea A1 stabilită între două entităţi va determina existenţa unei alte asocieri A2 în cadrul modelului EA. Exemplu: Un broker primeşte ordine de la clientul său şi execută tranzacţii.
BROKER
ORDINE 1,n
primeşte
ID Broker Nume broker SVM
1,1
ID ordin Data ordin Cod acţiune
1,n Execută
1,1
I
emite
1,1
1,n
TRANZACŢII Cod tranzactie Valoare
CLIENTUL Cod client Nume client Adresa
Figura 2.26. Incluziunea de asocieri Tipul de asociere execută este determinat de existenţa tipului de asociere primeşte (brokerul nu poate efectua tranzacţia dacă nu a primit ordinul corespunzător). Restricţia de excluziune de asocieri Restricţia de excluziune de asocieri exprimă faptul că asocierile aparţinând tipului de asociere A1 exclud asocierile aparţinând tipului A2. Exemplu: Studenţii din universităţile de stat care achită taxa de şcolarizare nu pot fi bursieri ai acestor instituţii. Rezultă că între Achită (taxe) şi Încasează (bursă) este o excluziune de asocieri.
Primitor
STUDENT
F
0,n
Cod-stud Nume Adresa
BURSE
1,1
Cod bursă Suma
Încasează
# 1,n TAXE SCOLARE
Achită Plătitor
1,1
Cod TAXĂ Denumire Suma taxă
Figura 2.27. Excluziune de asocieri Restricţia de egalitate de asocieri Restricţia de egalitate de asocieri exprimă faptul că asocierile aparţinând tipului A1 determină existenţa asocierilor aparţinând tipului A2 şi invers. Exemplu: Fie tipurile de entităţi Cărţi şi Legitimaţii între care se stabilesc tipurile de asocieri Posedă şi Împrumută. Între aceste asocieri se stabileşte o restricţie de egalitate de asocieri deoarece orice împrumut de carte implică posesia legitimaţiei de acces la bibliotecă iar posesia legitimaţiei implică posibilitatea împrumutului de carte (Figura 2.28). Toate rolurile Cititor implică toate rolurile Posesor şi entităţile participante la asociere. STUDENT
LEGITIMATIE 1,1
Nr. Matricol Nume
cititor
Posedă
posesor
1,1
Nr. Legitimatie Data emiterii
0,n
Împrumută
=
0,n CARŢI Cota Titlu Editura
Figura 2.28. Restricţie de egalitate de asocieri
2.3. Dependenţe funcţionale 2.3.1. Tipuri de dependenţe funcţionale Conceptul de dependenţă funcţională (DF) este fundamental în analiza structurii datelor. Studiul dependenţelor funcţionale stabilite între atribute ne permite obţinerea unei reprezentări formalizate a structurii de date. Dependenţele funcţionale evidenţiază raporturile de determinare stabilite între atributele unei entităţi. O dependenţă funcţională pune în relaţie două atribute: determinantul şi determinatul. Determinant
Determinat
Figura 2.29 Dependenţă funcţională Exemplu: Nr. rol Cod fiscal
Nume contribuabil Agent economic
Această df subliniază faptul că unei realizări a atributului Nr. rol îi va corespunde întotdeauna aceeaşi realizare a atributului Nume contribuabil, iar aceeaşi realizare a atributului Cod fiscal va fi asociată aceluiaşi Agent economic. Rezultă că determinantul reprezintă atributul/grupul de atribute din stânga df care prin valoarea sa determină valoarea luată de atributul cu rol de determinat. Fie tipul de entitate R, A,B,C… atribute aparţinând lui R, iar X, Y, Z ansambluri de atribute de R. Spunem că în tipul de entitate R se verifică df X → Y dacă în două realizări ale lui R având aceleaşi valori pentru X există aceleaşi valori pentru Y. Rezultă deci că df este o relaţie de determinare stabilită între atributele aparţinând aceluiaşi tip de entitate. Dacă valorile atributelor cuprinse în Y sunt cunoscute, atunci ele sunt în funcţie de valorile atributelor aparţinând lui X pentru că ele sunt determinate în mod unic de acestea din urmă. Dependenţa funcţională poate implica atribute sau grupuri de atribute. Dacă: A → (B,C) atunci există dependenţele funcţionale: A→B A→C Exemplu: Nr. Poliţă → Data poliţă, nume agent Ceea ce ne conduce la identificarea dependenţelor funcţionale: Nr. Poliţă → Data poliţă Nr. Poliţă → Nume agent Dar dacă există df (A,B) → C nu înseamnă că se verifică dependenţele funcţionale: A→B şi A→C
Exemplu: Cod secţie
Marca
Dacă există dependenţa funcţională: Cod-material, cod-furnizor Æ preţ-aprovizionare rezultă că preţul nu depinde numai de codul materialului ci şi de furnizor, acelaşi material putând fi aprovizionat la preţuri diferite de la furnizori diferiţi. Df XÆY este o dependenţă funcţională completă dacă Y este dependent funcţional de X fără să fie dependent funcţional de nici una din componentele lui X (preţul de aprovizionare este determinat atât de furnizor cât şi de materialul aprovizionat). Dependenţa funcţională XÆY se numeşte df parţială dacă Y este dependent funcţional atât de X cât şi de o parte a lui X. Fie tipul de entitate E definit prin atributele: cod operaţie, cod reper, timp-prelucrare, categorieoperaţie. Între atributele aparţinând lui E există următoarele df: Cod operaţie, cod reper Æ timp de prelucrare (df.completă) Cod operaţie, cod reper Æ categorie-operaţie (df.parţială) Dependenţa funcţională X Æ Y se numeşte df trivială dacă Y ⊆ X. În procesul de analiză a datelor pot fi identificate df tranzitive. XÆ A este o df tranzitivă dacă A este un atribut unic neinclus în X astfel încât există Y ⊄ X, XÆY şi YÆA şi Y nu determină X. Să analizăm dependenţele funcţionale care se stabilesc între atributele: CNP (cod numeric personal), Nume persoană, Localitatea de domiciliu, Cod localitate aparţinând tipului de entitate Persoana. CNP fiind ales drept identificator al entităţii înseamnă că există dependenţele funcţionale: CNP Æ Nume persoană CNP Æ Localitatea de domiciliu CNP Æ Cod localitate Dar există: df Localitate de domiciliu Æ Cod localitate ceea ne conduce la concluzia că df CNP Æ Cod localitate este o df tranzitivă. Dependenţa multivaloare se manifestă atunci când valorii unui atribut/grup de atribute îi corepund mai multe valori ale unui alt atribut. Df tranzitivă se reprezintă astfel: X Y O dependenţă multivaloare poate să se manifeste în cazul unei entităţi prezentând cel puţin trei atribute (A,B,C) astfel încât: A determină mai multe valori pentru B, A determină mai multe valori pentru C; B şi C sunt independente unul de celălalt. Exemplu: Să presupunem că dorim să reţinem informaţia referitoare la numărul de inventar al mijloacelor fixe aflate într-o secţie şi mărcile (codul de identificare) salariaţilor care lucrează în secţia respectivă întrun tip de entitate numit SECŢII al cărui identificator este atributul cod secţie. Se identifică între aceste atribute dependenţele funcţionale multivaloare:
Cod secţie
Nr inventar
2.3.2. Proprietăţile dependenţelor funcţionale Proprietăţile dependenţelor funcţionale, numite şi regulile lui Amstrong sunt: Reflexivitatea: Dacă Y⊂ X atunci se verifică df XÆY unde X şi Y sunt atribute/grupuri de atribute aparţinând tipului de entitate R. Dezvoltarea: Pentru orice Z ⊂ R dacă se verifică XÆ Y atunci se verifică şi df XZÆ YZ. Tranzitivitatea: Dacă se verifică df XÆ Y şi df YÆZ atunci este adevărată şi df XÆZ. Aditivitatea: Dacă XÆ Y şi XÆ Z atunci există df XÆ YZ. Pseudotranzitivitatea: Dacă există dependenţele funcţionale XÆY şi WYÆZ atunci se verifică df XWÆZ. Descompunerea: Dacă se verifică df XÆY atunci se verifică şi df XÆZ dacă Z⊂Y. Studiul dependenţelor funcţionale se poate realiza utilizând mai multe instrumente. În cele ce urmează ne propunem să prezentăm două dintre acestea: matricea dependenţelor funcţionale şi diagrama dependenţelor funcţionale care s-au dovedit complementare.
2.3.3. Matricea dependenţelor funcţionale Matricea dependenţelor funcţionale poate fi realizată în două variante: matricea simplificată matricea completă Matricea simplificată reprezintă un tablou în care coloanele cuprind determinanţii dependenţelor funcţionale iar fiecare linie un atribut aparţinând mulţimii atributelor supuse modelării. Matricea completă reprezintă un tablou asemănător matricii simplificate cu singura deosebire că numărul de coloane este egal cu numărul liniilor, cu alte cuvinte antet de coloană va fi orice atribut (regăsit şi ca antet de linie) şi nu doar atributele (grupurile de atribute) cu rol de determinant într-o dependenţă funcţională. Să elaborăm matricea simplificată a dependenţelor funcţionale pentru atributele necesare elaborării MCD privind consumul normat de materii prime stabilit pentru produsele din nomenclatorul de fabricaţie al firmei. Mulţimea atributelor corespunzătoare problemei studiate este formată din: cod produs, denumire produs, cod um, preţ livrare, cod reper, denumire reper, cantitate reper (în realizarea unui produs finit intră mai multe repere de acelaşi fel sau diferite), cod material, denumire material, cantitate normată pe reper, denumire um. Pe baza mulţimii atributelor enunţate se identifică dependenţele funcţionale stabilite între acestea care apoi sunt marcate în matricea simplificată a dependenţelor funcţionale. DETERMINANTI ATRIBUTE 1 3 5 8 5+8 1+5 1. Cod produs 1 2. Denumire produs 1 3. Cod um 1 1 1 4. Preţ produs 1 5. Cod reper 1 1 6. Denumire reper 1 7. Cantitate reper 1 8. Cod material 1 1 1 9. Denumire material 1 10. Cantitate normată pe reper 1 11. Denumire unitate de 1 măsură Figura 2.30 Matricea simplificată a DF
Analizând Figura 2.30 constatăm că fiecare coloană din matrice a fost rezervată unui determinant (se poate stabili anterior o listă a DF). Valoarea 1 marchează la intersecţia unei coloane cu o linie existenţa unei DF între atributul cu rol de determinant precizat în coloană şi atributul determinant înscris la nivelul liniei. Una din regulile modelului EA specifică unicitatea atributelor adică obligativitatea ca un atribut să aparţină unei singure entităţi sau asocieri. Plasarea unui atribut într-o entitate sau alta este determinată de DF la care participă în legătură cu identificatorul tipului de entitate. Aceasta înseamnă că la nivelul matricei dependenţelor funcţionale la nivelul fiecărei linii va trebui să fie înscrisă o singură valoare 1. În mod distinct, prin subliniere, în cadrul matricei au fost marcate câteva valori 1. Ele exprimă proprietatea de reflexivitate a DF şi sunt marcate la intersecţia coloanei cu linia corespunzătoare aceloraşi atribute (în cazul nostru determinanţii). O problemă apare în linii de 3 şi 8 unde cod um şi cod material prezintă mai mulţi determinanţi. Această situaţie atenţionează asupra necesităţii unei analize şi impune alegerea corectă a determinantului dependenţelor funcţionale puse în evidenţă. Existenţa mai multor valori 1 pe o linie poate fi şi consecinţa unor DF tranzitive care pun în evidenţă asocieri ierarhice (numite şi restricţii de integritate funcţională) între entităţile ale căror identificatori sunt în dependenţă funcţională. Matricea completă a dependenţelor funcţionale În cazul matricei complete numărul de coloane corespunde cu numărul liniilor. DETERMINANTI 5 6 7 8 9 10
ATRIBUTE 1 2 3 4 1 1. Cod produs 1 1 2. Den. produs 1 1 3. Cod um 1 1 4. Preţ produs 1 1 5. Cod reper 1 1 6. Den. reper 7. Cantitate reper 1 1 8. Cod material 9. Den. material 10. Cant. normată 1 11. Den. um Figura 2.31 Matricea completă a DF
11
5+8
1+5
1
1
1 1 1
1 1
1 1
Din analiza matricei complete a DF constatăm: • diagonala de valori 1 rezultată (aşa cum am precizat şi în cadrul matricei simplificate) este consecinţa proprietăţii de reflexivitate a df; • existenţa dependenţelor elementare (prezentând un determinant elementar, format dintr-un atribut); • existenţa dependenţelor neelementare al căror determinant este format dintr-un grup de atribute în cazul nostru (Cod produs, cod reper) şi (cod reper, cod material). • existenţa unor dependenţe tranzitive (cod produs→cod material) şi multivaloare între atributele cod produs şi cod reper, respectiv între cod reper şi cod material care conduc la apariţia mai multor valori 1 în cadrul liniilor matricei. Analiza informaţiei din matrice (completă sau simplificată) ne va conduce la definirea unor tipuri de entităţi optimizate în cadrul cărora să fie eliminate DF complexe. Diagrama dependenţelor funcţionale Diagrama dependenţelor funcţionale reprezintă un graf constituit pe baza DF identificate pornind de la care vom putea defini tipurile de entităţi ale modelului EA astfel încât în cadrul acestora să nu se mai manifeste DF complexe. Notaţiile pe care le vom utiliza în cadrul diagramei sunt: DF Cvasi DF
Cvasi dependenţele funcţionale sunt cele pentru care cunoaşterea unei valori pentru determinant nu antrenează sistematic cunoaşterea unei valori a determinatului. De exemplu: Cod reper
Cod produs
De multe ori aceste cvasi dependenţe funcţionale sunt reciproce. Un produs este format din mai multe repere dar un anumit reper participă la realizarea mai multor produse. Un graf al DF pune în evidenţă DF tranzitive: Atribut 1 Df 1 Df 3
Atribut 2 Df 2 Atribut 3 Figura 2.32 Graf al DF
Dependenţa tranzitivă DF3 va trebui eliminată din diagrama dependenţelor funcţionale. În cazul problemei pe care o avem de rezolvat cvasidependenţe funcţionale reciproce sunt: Dar dependenţa funcţională dintre atributul cod produs şi atributul cod material este tranzitivă şi va trebui eliminată din diagrama DF. Pornind de la mulţimea atributelor ce definesc problema de rezolvat (enumerate în paragraful anterior) putem identifica dependenţele funcţionale pe care le vom grupa în cadrul diagramei în funcţie de determinanţii pe care îi prezintă. În aceste condiţii diagrama DF va arăta astfel: Cod produs Cod reper Cod produs
Cod reper Cod material Cod material
Trecerea de la diagrama dependenţelor funcţionale la modelul EA se realizează pe baza următoarelor reguli:
Figura 2.33 Diagrama DF 1. Pentru fiecare DF în care determinantul este elementar se creează un tip de entitate în care determinantul DF joacă rolul de identificator.
În cazul problemei de rezolvat se vor defini patru tipuri de entităţi şi anume: Produs, Reper, Material şi Unităţi măsură prezentând drept identificatori atributele: Cod produs, Cod reper, Cod material şi respectiv Cod um (Figura 2.34). PRODUS
REPER
MATERIAL
UNITATI MASURA
Cod produs
Cod reper
Cod material
Cod um
Fig 2.34 Tipuri de entităţi definite. 2. Toate atributele participând la dependenţe funcţionale ce prezintă acelaşi determinant se vor grupa în cadrul aceluiaşi tip de entitate prezentând drept identificator atributul cu rol de determinant în cadrul dependenţelor funcţionale. În urma aplicării acestei reguli obţinem: PRODUS
REPER
MATERIAL
UNITATI MASURA
Cod produs Den produs Pret livrare
Cod reper Den reper
Cod material Den material
Cod um Den um
Figura 2.35 Gruparea atributelor pe tipuri de entităţi 3. Fiecărei dependenţe funcţionale între identificatorii tipurilor de entităţi îi va corespunde în modelul EA un tip de asociere. Această asociere este ierarhică (restricţie de integritate funcţională) când cardinalitatea maximală pentru cuplul E1A este 1 iar pentru cuplul E2A este n. Aplicând această regulă obţinem:
Figura 2.36 Definirea tipurilor de asocieri 4. Pentru fiecare DF neelementară (cu determinantul format dintr-un grup de atribute, identificatorii în cadrul tipurilor de entităţi definite) se creează un tip de asociere neierarhic (restricţie de integritate multiplă), definită prin atributul cu rol de determinant în DF. Aplicând regula obţinem:
Figura 2.37 Model EA Realizând matricea simplificată a df vom constata respectarea cerinţelor de validare a modelului EA:
Figura 2.38 Matricea simplificată a DF Matricea s-a realizat pe baza DF manifestate în cadrul tipurilor de entităţi definite. Se observă că prin eliminarea elementelor de reflexivitate pe fiecare linie a matricei rămâne, aşa cum este corect, o singură valoare semnificând că un atribut prezintă un singur determinant.
2.4. Reguli de verificare şi normalizare a MCD 2.4.1. Reguli de verificare a MCD •
•
Realizarea MCD impune respectarea următoarelor reguli: Regula de unicitate a numelor se aplică tuturor elementelor care participă la definirea MCD: tipuri de entităţi, tipuri de asocieri, atribute, roluri. Această regulă impune eliminarea din model a omonimelor şi sinonimelor. Aceasta înseamnă că nu vom putea da, în cadrul aceluiaşi MCD, şi unui atribut şi unui tip de entitate acelaşi nume, de exemplu Student. Vom numi tipul de entitate Student iar atributul va primi denumirea Nume Student. Regula unicităţii atributelor (neredundanţei) impune ca un atribut să definească un singur tip de entitate sau un singur tip de asociere.
• • • •
• •
Regula de unicitate a asocierilor, aplicabilă în cazul asocierilor neierarhice, specifică faptul că pentru fiecare realizare a asocierii nu poate să existe decât o singură realizare a fiecărei entităţi participante la asociere. Regula proprietăţilor şi determinantului unei entităţi precizează că un atribut care este determinat de mai mulţi determinanţi, aceştia fiind identificatori ai unor tipuri de entităţi diferite, trebuie să definească tipul de asociere creat între respectivele tipuri de entităţi. Regula atributelor derivabile recomandă evitarea includerii în MCD a atributelor rezultate din calcule. Prezenţa unor astfel de atribute în MCD se justifică numai dacă ele sunt purtătoare ale unei informaţii cu o anumită relevanţă şi frecvenţă de utilizare. Regula atributelor decompozabile precizează că pot fi menţinute în cadrul MCD atribute complexe în măsura în care prelucrările nu impun descompunerea lor pe componente elementare. Un exemplu este reprezentat de atributul adresa care se poate descompune pe următoarele componente: cod poştal, localitate, stradă, număr, nr. apartament. Într-un SI realizat pentru activitatea unei administraţii financiare se impune descompunerea atributului adresa pe componentele sale elementare deoarece contribuabilii sunt adesea selectaţi după criteriul străzii de domiciliu sau numărului. În cazul unui SI destinat evidenţei angajaţilor unei firme atributul adresa se va reţine ca atare, nefiind necesară descompunerea sa pe elemente. Regula minimizării identificatorilor specifică necesitatea stabilirii cu atenţie a identificatorilor entităţilor reţinând în grupul de atribute un număr cât mai mic de elemente (atribute). Regula valorii NULL. Deoarece există definite în cadrul tipurilor de entităţi atribute care nu prezintă realizări obligatorii la nivelul fiecărei entităţi, rezultă că MCD poate fi rafinat prin definirea unor subtipuri de entităţi care să cuprindă doar atributele specifice acelei submulţimi de entităţi. Atributele cu rol de identificator vor trebui să primească obligatoriu realizări.
2.4.2. Reguli de normalizare a MCD Normalizarea este considerată o parte importantă a procesului de proiectare a datelor. Modelul EA este rezultatul unui proces iterativ care a permis identificarea tipurilor de entităţi, atributelor definite în cadrul acestora, a identificatorilor şi a asocierilor. Normalizarea vizează atributele entităţilor pe care le analizează cu scopul eliminării anomaliilor asigurându-se astfel definirea unor tipuri de entităţi “libere” de dependenţe funcţionale tranzitive şi multivaloare. Procesul normalizării se poate desfăşura urmând una din următoarele abordări: • Varianta “top down” caracterizată prin urmărirea respectării formelor normale la nivelul entităţilor; • Varianta “bottom up” caracterizată prin definirea unui tip de entitate unic înglobând toate atributele modelului EA la nivelul căruia să se identifice mulţimea dependenţelor funcţionale existente între ele. Regulile de normalizare a MCD sunt: Regula nr. 1 (FN1): Fiecare entitate trebuie să prezinte un identificator prezentând realizări unice, nenule. Această regulă este consecinţa directă a definirii tipului de entitate în cadrul MCD. O regulă suplimentară celei enunţate deja este cea referitoare la caracterul elementar al atributelor. Regula nr. 2 (FN2): Toate atributele entităţii, altele decât identificatorul, trebuie să fie în dependenţă funcţională completă şi directă cu identificatorul entităţii. Altfel spus, în toate realizările tipului de entitate, fiecare atribut trebuie să fie determinat de identificator şi trebuie să ia o singură valoare şi numai una (nu se admit valori multiple deci dependenţe funcţionale multivaloare). Sintagma de dependenţă completă exprimă necesitatea ca atributele să fie determinate de identificator în ansamblul lui, şi nu doar de o parte a lui (nu se admit dependenţe parţiale). Din cele menţionate rezultă faptul că o entitate care prezintă identificatorul format dintr-un singur atribut respectă automat această regulă. Regula nr. 3 (FN3): Toate atributele unei asocieri trebuie să depindă complet de identificatorul asocierii (identificatorii entităţilor participante la asociere) iar fiecare atribut trebuie să depindă de întregul identificator şi nu de o parte a acestuia.
2.5. Dezvoltări ale modelului entitate asociere Generalizarea şi specializarea Un subtip (o subclasă) de entităţi reprezintă un grup de entităţi aparţinând unui tip, reprezentate distinct în cadrul modelului, ele prezentând anumite trăsături caracteristice ce le detaşează, individualizează, de celelalte entităţi. Definirea subtipurilor de entităţi se poate face pe două căi: - plecând de la valoarea unui atribut (valorile unor atribute); - utilizând criterii precizate de utilizator. Prin această grupare a entităţilor aparţinând unui tip se ajunge la definirea unor supertipuri de entităţi dominante în raport cu subtipurile (subclasele) acestora. Subclasele sunt rezultanta unei specializări la nivelul entităţilor, ele conservând însă capacitatea de a moşteni de la supertipul lor elementele comune definitorii. Pentru a clarifica importanţa definirii în modelul EA a tipurilor şi subtipurilor de entităţi vă propunem următorul exemplu: O bancă lucrează atât cu clienţi persoane fizice cât şi cu clienţi persoane juridice. Fiecare client al băncii primeşte un număr unic de identificare (cod ID), are un nume. Dacă este persoană fizică se reţine codul numeric personal (CNP) şi data naşterii (DataN), dacă este persoană juridică se reţine codul fiscal (CodF) şi codul din registrul comerţului (CodC). CLIENŢI
Tip (Supertip)
Cod ID Nume
0,1
Este o
0,1
Este o 1,1
1,1 PERS FIZICĂ
PERS JURIDICĂ
CNP DataN
CodF CodC
Subtipuri de entităţi
Figura 2.39 Subtipuri de entităţi Cele două subtipuri - PERS FIZICĂ şi PERS JURIDICĂ - moştenesc toate caracteristicile definite pentru supertip (CLIENŢI) şi anume Cod ID şi Nume. Generalizarea Generalizarea reprezintă un proces de modelare a cărui finalitate este reprezentată de definirea unui supertip regrupând toate atributele comune şi a mai multor subtipuri regrupând atributele specifice unui subansamblu de realizări ale unui tip generic de entităţi.
DOCUMENT
0,1
Este un
NUMĂR DATA DOC EMITENT BENEFICIAR
1,1
Este un
1,1 Sgaranţie Nr zile Suma
1,1 OrdinPlată Cont Plătitor Cont Benef Banca Pl. Banca Benef.
Figura 2.40 Generalizarea în modelul EA Conceptul de generalizare provine de la reprezentarea cunoştinţelor sub formă de reţele semantice şi se materializează printr-un predicat de forma “este un” (mai este numită şi relaţie IS-A după forma engleză a predicatului). Să luăm un exemplu: orice document se identifică prin număr, data emiterii, emitent, destinatar dar fiecare tip de document consemnează un eveniment cu o anumită natură şi conţinut. Astfel o scrisoare de garanţie bancară indică perioada de valabilitate pentru care se garantează plata pentru o sumă precizată. Un ordin de plată va aduce ca informaţie specifică: numărul contului plătitor, banca plătitoare, contul beneficiar, banca acestuia, suma plătită. Se pot reprezenta astfel în mod distinct proprietăţile comune ale tuturor documentelor (elementelor de identificare) de cele specifice (Figura 2.40). Generalizarea permite în cadrul modelului EA tocmai definirea acestor caracteristici comune în cadrul unui supertip de entitate urmând ca elementele specifice să rămână a fi descrise la nivelul subtipurilor de entităţi. Pentru că orice scrisoare de garanţie bancară sau ordin de plată se definesc prin număr, data, emitent, beneficiar rezultă că subtipurile de entităţi Sgaranţie şi OrdinPlată vor moşteni atributele susmenţionate de la supertipul DOCUMENT. Generalizarea prezintă o serie de proprietăţi, parţial comentate deja: • Moştenirea atributelor semnificând faptul că orice entitate E1 (Sgaranţie/OrdinPlată) având cu o altă entitate E (DOCUMENT) o relaţie de generalizare, de forma E1 este un E, moşteneşte atributele lui E; • Atributele supertipului nu aparţin subtipului; • Nu există moştenire colaterală (între Sgaranţie şi OrdinPlată) Figura 2.40. cuprinde şi precizarea restricţiei de integritate de excluziune (o scrisoare de garanţie nu poate fi un ordin de plată). Specializarea Specializarea reprezintă operaţia opusă generalizării permiţând realizarea unei decupări a unui tip de entitate E (care va deveni SUPERTIP) în subtipuri de entităţi diferenţiate prin atribute proprii sau prin anumite realizări aparţinând unui atribut. Specializarea şi generalizarea sunt două abordări diferite ale aceluiaşi proces de modelare. În măsura în care dorim să cuprindem în modelul EA informaţia existentă în documentele Scrisoare de garanţie bancară şi ordin de plată (emis de agentul economic) putem crea iniţial un tip de
entitate document definit prin mulţimea atributelor corespunzătoare problemei analizate (mulţimea tuturor atributelor celor două tipuri de documente). Tipul de entitate DOCUMENT (Figura 2.41) este un concept generic, el cuprinzând elementele caracteristice celor două documente aparţinând lumii reale, Scrisoarea de garanţie şi Ordinul de plată. Chiar dacă pot exista atribute cu realizări opţionale în cadrul unui tip de entitate, atât timp cât privesc caracteristici particulare ale unor entităţi este necesară “gruparea” acestora în subtipuri (de entităţi). La nivelul tipului de entitate (Document) vor rămâne doar atributele comune subtipurilor definite. Obţinem astfel subtipurile de entităţi Sgaranţie şi OrdinPlată ajungând astfel la modelul EA prezentat în figura 2.40. Operaţia de specializare poate fi: totală sau parţială. Document Număr Data Emitent Beneficiar Nr. zile Suma Cont benef. Banca benef. Cont plătitor Banca plătit.
Figura 2.41 •
Specializarea totală corespunde situaţiei în care orice entitate a supertipului face parte dintr-un subtip. Grafic se marchează printr-o linie dublă. • Specializarea parţială corespunde situaţiei în care pot exista realizări ale supertipului care nu aparţin nici unui subtip (spre exemplu o realizare a tipului document este un document de tip bon de consum căruia nu-i corespunde nici un subtip din cele definite – în exemplul nostru Sgaranţie şi OrdinPlată). Grafic se reprezintă printr-o linie simplă. Să presupunem că secretariatul unei facultăţi doreşte să evidenţieze cele trei categorii de studenţi pe care îi gestionează: studenţii de la forma de învăţământ zi, studenţii cursurilor postuniversitare şi studenţii doctoranzi. Toţi aceşti studenţi se definesc printr-o serie de atribute comune: număr matricol, nume, adresă, data naşterii care se reţin la nivelul tipului de entitate STUDENT. Atributele specifice fiecărui grup de studenţi aparţinând unei anumite forme de pregătire se vor reţine în subtipurile specifice. Astfel, studenţii de la cursurile de zi se definesc prin: an (de studii), grupa, categorie (student înscris pe loc bugetat sau cu taxă), tip bursă. Studenţii cursurilor doctorale se caracterizează prin: cursul urmat, tema aleasă pentru dizertaţie iar studenţii doctoranzi se definesc prin: specializare, conducător ştiinţific, tema tezei, anul înscrierii.
Student Nr. matricol Nume Adresă Data naşterii 0,1
0,1 0,1 #
Este un
# Este un
1,1
Este un
1,1
1,1 Postuniv.
Zi
Doctoranzi
Cursul Tema dizertaţiei
An Grupă Categorie Tip bursă
Specializare Conducător Anul înscrierii Tema
Figura 2.42. Specializare totală Figura 2.42 evidenţiază faptul că orice entitate aparţinând tipului student îşi găseşte corespondent într-o realizare a unui subtip. S-a marcat distinct şi de această dată restricţia de integritate de excluziune dintre subtipurile de entităţi (dacă este un student la zi nu poate fi student la un curs postuniversitar sau doctorand). Există situaţii în care între cele două subtipuri de entităţi având acelaşi supertip pot apărea şi restricţii de incluziune, deci realizările cele două subtipuri nu sunt disjuncte (figura 2.43). Şeful unui compartiment din structura organizatorică a firmei poate fi economist deci apare relaţia de incluziune între cele două subtipuri definite – ŞEF şi ECONOMIST. Angajat Cod id Nume Funcţie Salariu
0,1
0,1 # Este un
Este un
1,1
1,1 Şef Indemnizaţie
Economist Specializarea
Figura 2.43 Restricţie de integritate de excluziune
STUDIU DE CAZ Se doreşte realizarea modelului conceptual al datelor pentru sistemul informatic al unei societăţi de valori mobiliare ştiind că: - Ordinele de tranzacţionare se primesc de la clienţi, fiecare client fiind definit printr-un cod unic de identificare, nume, adresa, banca, cont. - Ordinele de tranzacţionare vizează societăţile cotate pe piaţă, societăţi pentru care se reţine codul, denumirea, capitalul social, cotaţia maximă şi respectiv cotaţia minimă înregistrată. - Ordinele clienţilor privesc o anume societate tranzacţionată şi pot fi de vânzare, (caz în care acesta poate specifica preţul minim pe care îl acceptă) sau de cumpărare, pentru care poate preciza un preţ maxim. Ordinele primesc un număr unic la nivelul SVM-ului şi cuprind: data şi ora emiterii, numărul de acţiuni, societatea vizată. - Ordinele sunt executate de un broker, clienţii lucrând fiecare cu un anume broker din societate, pentru care se reţin următoarele caracteristici: cod şi nume. - Tranzacţiile realizate pe baza ordinelor primite prezintă: un număr, data tranzacţiei, numărul acţiunilor care au făcut obiectul tranzacţiei, preţul la care s-a realizat tranzacţionarea. - Un ordin poate fi acoperit prin mai multe tranzacţii realizate pe piaţă. În MCD s-au definit următoarele tipuri de entităţi: Client definit prin atributele: Cod-client (identificator), nume-client, adresa, cont, banca. Societăţi definit prin: Cod soc (identificator), denumire, capital, cotaţia maximă, cotaţia minimă (aceste două ultime atribute au rol informativ iar prin cerinţele problemei nu s-a cerut şi reţinerea datelor la care s-au înregistrat aceste valori). Ordin definit prin: Nr-ordin (identificator), data ordin, ora, nr-acţiuni. Se remarcă în cadrul MCD specializarea totală (cu specificarea restricţiei de excluziune între entităţile subtipurilor) prin definirea subtipurilor Vânzare şi Cumpărare necesare reţinerii preţului minim de vânzare respectiv preţului maxim de cumpărare. Tranzacţii: Nr-tranz (identificator), data tranz, nr. acţiuni, preţ tranz. Broker: Cod-broker (identificator), nume broker.
Figura 2.44
2.6 Reprezentarea timpului Modulul EA nu oferă formalisme specializate pentru reprezentarea timpului. Dar elementul timp trebuie de cele mai multe ori să se regăsească în cadrul modelului conceptual definit. Aşa se explică faptul că modelul EA permite atât reprezentări sincronice (care aduc o viziune atemporală) sau diacronice (care surprind elementul timp în MCD). Să presupunem că dorim să realizăm un MCD care să permită reprezentarea consumului specific de materii prime necesare fabricării fiecărui subansamblu din componenţa unui produs finit (Figura 2.45). Modelul conceptual din figura 2.45 este o reprezentare sincronică. Realitatea modelată nu a impus integrarea în MCD a elementului timp. Sunt însă situaţii în care în cadrul MCD este necesar să integrăm şi elementul timp. Să presupunem că dorim să reprezentăm cursele realizate de fiecare aeronavă a unei companii de transporturi aeriene. Ne interesează să cunoaştem ce aeronavă a asigurat fiecare din cursele programate. Vor fi utilizate în cadrul modelului două tipuri de entităţi AVION şi CURSA între cele două stabilindu-se tipul de asociere REALIZEAZĂ. Produs
0,n
1,n
Componentă
Compus
Cod produs Denumire Preţ catalog
Cod Den. compon.
Nr. compon.
1,n
Necesită Cantitate MaterPrimă
1,n
Codmat Den mat
Figura 2.45 Reprezentare sincronică Aeronavă Nr-id Marca Tip Km parcurşi Data reparaţiei
1,n
1,n Realizează
Cursă Nr cursă Destinaţie Ora-plecării Ora-sosirii
Figura 2.46 Reprezentarea sincronică din figura 2.46 evidenţiază ce curse au fost realizate de fiecare aeronavă din dotare dar nu şi când. Cursa cu numărul 123 având destinaţia Paris se efectuează în fiecare zi de joi a săptămânii şi deci nu putem identifica cu ce aeronavă s-a realizat într-o numită zi. Dacă însă dorim să avem o evidenţă clară a curselor realizate de o anumită aeronavă această reprezentare se dovedeşte neacoperitoare. Realizările tipului de asociere se identifică după Nr-ID şi Nr cursă. Cum acelaşi avion poate realiza aceeaşi cursă, de mai multe ori identificarea realizărilor tipului de asociere nu se mai poate realiza. Acest lucru impune introducerea în cadrul modelului a unui tip de entitate temporală.
Caracteristic pentru entităţile temporale este faptul că ele sunt definite adesea printr-un singur atribut (data calendaristică). În cazul în care prezintă mai multe atribute, fiecare dintre acestea reprezintă o unitate de măsură a timpului (zi, oră, minut) iar ansamblul acestor atribute formează identificatorul tipului de entitate. Observăm că introducerea timpului de entitate temporală a condus la transformarea tipului de asociere binară existent iniţial între AVION şi CURSA într-o asociere ternară. Data cursei Data
1,n
Aeronavă Nr-id Marca Tip Km parcurşi Data reparaţiei
Cursă Nr cursă Destinaţie Ora-plecării Ora-sosirii
Realizează
1,n
1,n
Figura 2.47 Reprezentare diacronică O altă modalitate de a introduce elementul timp în cadrul modelului EA este reprezentată de introducerea evenimentelor datate. Din activitatea practică cunoaştem faptul că fiecare eveniment produs (o aprovizionare, încheierea unui contract, etc.) se concretizează într-un document care pe lângă număr şi prezentarea conţinutului prezintă şi o dată. Să luăm cazul unei societăţi de asigurări şi să ne limităm la gestiunea doar a poliţelor de asigurare a bunurilor. În cadrul MCD trebuie să cuprindem atât clienţii societăţii, bunurile pe care aceştia le asigură şi riscurile pentru care se face asigurarea. Evenimentul asigurare bun care are loc se consemnează într-un document numit poliţă de asigurare. Acest eveniment se va regăsi în cadrul MCD sub forma unui tip de entitate (Poliţă). Client
1,1
1,n
Poliţă
Cod client Nume Tip Adresă
Încheie
Nr poliţă Data poliţă
1,n 1,n Asigură
Precizează 1,n
1,1 Riscuri Bun asigurat Denumire Adresa Val bun Val asigurată
Cod risc Denrisc
Figura 2.48 Introducerea evenimentelor datate în modelul EA
2.7 Validarea modelelor externe Validarea MCD nu se realizează doar prin regulile de validare şi normalizare (prezentate într-un capitol anterior) vizând elemente de “construcţie” ale modelului ci şi prin controlul completitudinii modelului. Trecerea la etapa modelării logice nu se poate face fără verificarea completitudinii modelului conceptual. MCD este definit prin prisma unei singure prelucrări a datelor, ori în realitate diverşii utilizatori prelucrează datele în conformitate cu propriile lor nevoi având o percepţie diferită (modele externe) asupra datelor. Realitate
Model Extern 1
Model Extern 2
Model Extern n
Model Conceptual
Figura 2.49. Modele externe ale datelor Fiecărei prelucrări (consultare sau actualizare) realizate de un utilizator îi corespunde un model extern al datelor (MED) care reflectă viziunea particulară a utilizatorului asupra realităţii. Acest model extern propriu unei anumite prelucrări implică un bloc logic de date constituit pe baza formalismului EA. Dacă în urma definirii modelelor externe constatăm că fiecare dintre acestea este deductibil din MCD definit înseamnă că modelul conceptual al datelor răspunde criteriului de completitudine. În construirea modelelor externe se recomandă utilizarea următoarelor reguli: - se defineşte un model extern pentru fiecare consultare sau actualizare impusă de o prelucrare; - modelul extern se construieşte utilizând formalismul EA. În construirea modelului EA corespunzător ME se ţine seama de faptul că : - entităţile ME pot să nu prezinte identificatori; - atributele, entităţile şi asocierile ME pot să nu-şi găsească un corespondent în MCD; - atributele ME corespunzătoare celor aparţinând MCD vor trebui să prezinte acelaşi nume cu acestea. În cazul unei actualizări ME construit va reda spre exemplu, fluxul de date implicat în cadrul prelucrării. În cazul operaţiei de actualizare privind facturile emise clienţilor ME se prezintă astfel:
Factura NR FACTURĂ Data factură Client Val-factură
1,n CUPRINDE 1,1 COD PROD DEN PROD UM CANT FACT PREŢ VAL-PRODUS TVA-PRODUS TOTAL-PRODUS
Figura 2.50 ME al operaţiei de actualizare Din analiza ME prezentat în figura 2.50 constatăm că unele atribute îşi găsesc corespondent direct în MCD, altele sunt atribute calculate (VAL-PRODUS, TVA-PRODUS, TOTAL-PRODUS) iar unele atribute, deşi definesc aceleaşi caracteristici, sunt definite cu nume diferite de cele utilizate în MCD (Client în loc de DEN CLIENT de exemplu), deci prin echivalenţă îşi găsesc un corespondent în MCD.
Figura 2.51 Verificarea completitudinii MCD Atributele calculate aparţinând ME vor fi descompuse în conformitate cu algoritmii de calcul utilizaţi în vederea identificării operanzilor. Se verifică apoi măsura în care atributele se regăsesc direct sau prin echivalenţă în MCD. În măsura în care ME cuprinde şi atribute care nu se regăsesc în MCD este necesară completarea acestuia cu atributele omise.
Reguli de validare a modelelor externe CONSULTARE 1. Atributele externe trebuie să fie atribute conceptuale 2. Se verifică existenţa în MCD a atributelor necesare identificării datelor în procesul consultării. 3. Cardinalităţile asocierilor externe trebuie să fie incluse în cardinalităţile asocierilor aparţinând MCD corespunzătoare semantic. ACTUALIZARE 1. Orice atribut extern serveşte fie la identificarea unui element conceptual de actualizare (atribut, entitate) fie la obţinerea valorii de actualizare a unui element conceptual. Această regulă permite identificarea atributelor omise ce vor completa MCD precum şi la identificarea atributelor ME care vor fi şterse deoarece nu servesc niciunuia din scopurile amintite. 2. Cardinalităţile asocierilor externe trebuie să se includă în cardinalităţile asocierilor conceptuale corespunzătoare semantic. 3. Orice element conceptual trebuie să poată fi actualizat (inserat, modificat, şters) prin cel puţin un model extern. Se vor defini modele externe omise care realizează actualizarea elementelor conceptuale. 2.8 Probleme recapitulative Probleme rezolvate Problema 1 În cadrul subsistemului informatic privind calculaţia costurilor se urmăreşte evidenţierea consumului de materii prime aferent comenzilor de produse lansate în fabricaţie. Ştiind că : • În comandă se precizează secţia producătoare şi cantitatea de fabricat din produsul respectiv; • Eliberarea materiilor prime din gestiune pentru consum se face pe baza bonului de consum în care se specifică: numărul şi data bonului, gestiunea care eliberează materialele, comanda de producţie pentru care se eliberează materialele, cantităţile şi preţurile materiilor prime date în consum; • Orice produs din nomenclatorul de fabricaţie se defineşte prin: cod, denumire, preţ de livrare; • Materiile prime se definesc prin: codul materiei prime, denumire, unitate de măsură, gestiunea în care se depozitează; • Intrările de materii prime în gestiuni se realizează pe baza documentului Notă de recepţie şi constatare de diferenţe (NRCD) în care se consemnează: numărul şi data documentului, furnizorul, gestiunea primitoare, materia primă recepţionată, cantitatea şi preţul de aprovizionare. Restricţii: • O comandă de producţie se referă la un singur produs; • O materie primă poate fi stocată în mai multe depozite; • Preţul fiecărei materii prime diferă de la un furnizor la altul; • Un depozit are un singur gestionar. Se cere: 1. Identificaţi mulţimea atributelor aparţinând problemei de rezolvat; 2. Realizaţi diagrama dependenţelor funcţionale; 3. Realizaţi modelul EA pe baza dependenţelor funcţionale identificate. REZOLVARE: 1. Atributele care definesc realitatea modelată sunt: Cod produs Den prod Preţ livrare Nr. comandă Data lansării cdă Secţia de producţie Cantitate produs Nr. bon consum Data bon Gestiune Cod material Den material Cantitate eliberată Nr NRCD Cantitate intrată Preţ intrare Furnizor Gestionar
2. Diagrama dependenţelor funcţionale este:
Cod produs Den produs Cantitate comandă Preţ livrare
Nr. comandă
Nr bon consum Data bon
Data lansării
Secţia Cantit. eliberată Cod material Furnizor
Den material Unit. măsură
NRCD
Gestiune Gestionar
Cantit. Intrată, Pret Intrare
Modelul EA este: PRODUS Cod produs Den prod Preţ livrare
0,N
1,1 Cuprinde
COMANDĂ Nr cda Data lansare Secţia
Cant cdă
1,N
NRCD Nr NRCD Data NRCD Furnizor
Necesită 1,1
1,N
BON CONSUM
Cuprinde Cant elib.
Intrate
1,N
Cant intr Preţ intr
Nr bon Data bon
0,N 1,N
0,N 1,N
MATERIALE Cod material Den material
1,N Stochează Stoc iniţial
1,N GESTIUNE Nr Gestiune Gestionar
Problema 2 Să se elaboreze MCD pentru evidenţa poliţelor de asigurare încheiate de o societate specializată în asigurări de bunuri ştiind că: • Un client poate încheia una sau mai multe poliţe de asigurare de bunuri. Fiecare client primeşte un cod unic şi este definit prin nume, adresă, cod numeric personal; • O poliţă de asigurare se întocmeşte pentru unul sau mai multe bunuri de către un agent de asigurări şi cuprinde numărul, data întocmirii, perioada asigurării bunului; • Pentru fiecare bun asigurat se specifică: numele bunului, adresa unde se află, valoarea bunului, valoarea pentru care se asigură, riscul/riscurile pentru care se asigură (furt, incendiu, inundaţie etc); • Pentru fiecare poliţă încheiată se stabileşte: valoarea primelor de asigurare pe care clientul urmează să le achite şi data limită a plăţii, data de la care operează asigurarea, data de sfârşit a perioadei de asigurare; • Plata primelor de asigurare se face pe bază de documente (chitanţă, ordin de plată, filă cec etc identificate prin număr şi dată).
REZOLVARE:
Notă: Entităţile Bun şi PRIMĂ nu prezintă indentificator propriu. Ele se vor identifica prin valoarea atributului Numele bunului şi rolul pe care entitatea POLIŢĂ îl joacă în asocierea Priveşte şi respectiv valoarea atributului Nr primă şi rolul pe care îl joacă entitatea POLIŢĂ în asocierea Prevede. Problema 3 O societate de turism doreşte să implementeze un sistem informatic privind gestiunea hotelieră. Să se elaboreze MCD ştiind că se doreşte realizarea evidenţei spaţiului de cazare (camerele sunt de tipuri diferite – simplă, dublă, apartament – iar tariful diferă de la cameră la cameră chiar dacă sunt de acelaşi tip), a serviciilor suplimentare oferite în unele camere (televizor, fax, frigider etc) care se tarifează separat. Nota de plată se întocmeşte clientului în funcţie de camera ocupată, numărul zilelor de cazare, serviciilor suplimentare solicitate. Rezervările se fac pe camere şi nu pe locurile din cameră. Verificaţi modelul EA elaborat pe baza matricei simplificate a dependenţelor funcţionale.
REZOLVARE: CLIENT CAMERĂ Nr cameră Tip Tarif cameră
1,n
0,n
Cod numeric Nume Adresă Act identitate
1,n Ocupă data debut data sfârşit
0,n
Are Primeşte SERVICII 1,n 0,n
1,1
Tip serviciu Tarif/zi
NOTĂ PLATĂ 1,n
Nr notă Data
Priveşte
Matricea simplificată a dependenţelor funcţionale este: 1. Nr cameră 2.Tip cameră 3. Tarif cameră 4. Dată debut sejur 5. Dată sfârşit sejur 6. Cod numeric personal 7. Nume client 8. Adresă 9. Act identitate 10. Nr. notă plată 11. Data notă plată 12. Tip serviciu 13. Tarif serviciu/zi
1 1 1 1
6
10
12
1+6
1 1 1 1 1 1 1 1 1 1
Problema 4 Un spital doreşte să implementeze un sistem informatic de gestiune prin care va putea avea o evidenţă clară a: pacienţilor (date personale, diagnostic), medicilor şi responsabilităţile lor pe saloane, medicaţiei şi procedurilor de tratament prescrise pacienţilor, repartizării medicilor şi saloanelor pe secţii. Reguli de gestiune: • Un pacient, în decursul unei internări, este sub supravegherea aceluiaşi medic şi rămâne în acelaşi salon; • Pacienţii din acelaşi salon sunt sub îngrijirea aceluiaşi medic; • Un medic are o singură specialitate şi lucrează în cadrul unei singure secţii; • O procedură se poate efectua într-un singur cabinet, în ziua şi ora fixată. Realizaţi diagrama dependenţelor funcţionale şi apoi modelul EA. REZOLVARE: Modelul EA elaborat pe baza diagramei dependenţelor funcţionale este:
Cod medic
Cod pacient
Cod diagnostic
Nume Nume medic Den diagnostic
Adresă
Cod Secţie
Cod medicament
Data naşterii
Nume secţie
Denumire Doză
Nr salon
Preţ
Act identit.
Cod procedură Capacitate Nume procedură Pacient Cod-id Nume Adresă Data naşterii Act identit.
Data, ora
data internării data externării 0,n
Sala Proceduri
0,n
Cod procedură Nume procedură Cabinet
Face Data,ora
1,n
0,n Internat
Medic Data int, Data extern
Cod-medic Nume Specialitate
0,n
Primeşte Dozaj
Secţie
1,1
Cod secţie Nume secţie
0,n
Lucreză
Medicament 1,n Cod medicament Den medicament Preţ
1,n 1,n
Are 1,1
1,1 Răspunde Salon Nr salon Capacitate
Probleme propuse 1. Ştiind că S.C. Agroprod este organizată pe mai multe ferme, fiecare fermă lucrând cu angajaţi permanenţi să se elaboreze MCD privind evidenţa personalului şi calculul salariilor aferente timpului lucrat. Un angajat ocupă un post pentru care s-a stabilit funcţia şi salariul. Fiecare post are un număr unic în cadrul fermei, iar fiecare fermă are un şef. Unor angajaţi li se fac reţineri reprezentând chirii, popriri, rate pe baza documentelor emise de creditori pentru care se reţine: nr.doc, data doc, tip reţinere, emitent, suma datorată. Pentru fiecare angajat se reţine codul unic de identificare, numele, o dată a angajării în firmă, data naşterii. În fiecare lună se consemnează în documentul Foaie colectivă de prezenţă pentru fiecare angajat numărul orelor lucrate, numărul orelor absentate, numărul orelor de concediu de odihnă, numărul orelor de concediu medical. 2. Să se elaboreze MCD pentru sistemul informatic privind gestiunea mărfurilor într-o firmă. Modelul va trebui să evidenţieze informaţiile privitoare la: cantităţile şi preţurile de aprovizionare ale mărfurilor de la furnizori, livrările de mărfuri către clienţi (preţul de livrare al mărfurilor este diferit de cel de achiziţionare). Mărfurile se stochează în depozite. Fiecare depozit are un singur gestionar. Pentru fiecare marfă se cunoaşte stocul iniţial la începutul perioadei şi depozitul în care se află. O anumită marfă este stocată în unul sau mai multe depozite. Fiecare client este înscris într-un nomenclator cu numele, adresa, telefonul, contul, banca şi codul de identificare. 3. Pentru un magazin de muzică se doreşte crearea unei baze de date cuprinzând oferta acestuia. Realizaţi MCD necesar ştiind că baza de date va stoca următoarele informaţii: numele fiecărui album, casa producătoare, anul înregistrării, preţul (care diferă în funcţie de suport: CD sau casetă), genul în care se încadrează albumul (rap, dance, rock etc), melodiile cuprinse, durata fiecărei melodii, interpretul, compozitorul. Menţionăm că o melodie poate avea mai mulţi autori şi poate fi interpretată de mai mulţi cântăreţi. 3. Fie următorul MCD: CONTRACTE PRODUSE Cod produs Den produs Unit. măsură Preţ TVA
Nr contract Data contract Cantitate contractată Cod produs Data livrării
PRIVESC
LIVRARE ÎNCHEIE
FACTURA Nr factură Data factura Cantitate livrată
CLIENŢI Cod client Den client Adresă
Ştiind că: • Obiectul unui contract este reprezentat de unul sau mai multe produse pentru care se specifică cantitatea contractată; • Data livrării se referă la întregul contract;
•
Livrarea produselor se face pe bază de factură care cuprinde cantitatea facturată şi preţul de facturare pentru produsele livrate (într-o factură pot fi înscrise unul sau mai multe produse).
Se cere: - Stabiliţi cardinalităţile. - Elaboraţi matricea simplificată a dependenţelor funcţionale şi pe baza informaţiilor astfel obţinute stabiliţi dacă MCD este corect elaborat. În caz contrar oferţi soluţia corectă pentru MCD. Precizaţi restricţiile de integritate corespunzătoare. - Dezvoltaţi MCD ştiind că obiectul de activitate este reprezentat de fabricarea de produse şi prestarea de servicii; contractele încheiate precizând produsele sau serviciile solicitate de clienţi. Realizaţi specializările implicate de această precizare. 4. Elaboraţi MCD pentru sistemul informatic privind gestiunea depozitelor bancare constituite de clienţii unei bănci comerciale. Depozitele se pot constitui în lei sau valută (dolari USA sau Euro). Soldul minim pentru un depozit în lei este de 1000000 iar în valută 1000. Depozitele se constituie pe termen de 30, 60, 90, 180, 360 de zile, fără capitalizare, dobânda fiind de 30% pe an pentru termene sub 90 de zile şi 33% pentru restul termenelor. Un client poate avea oricâte depozite. Sistemul va reţine numărul şi data documentelor de plată a dobânzii aferente depozitelor. Stabiliţi restricţiile impuse de problema de rezolvat. Dobânzile neridicate la scadenţă se înregistrează într-un cont la vedere deschis pe numele titularului depozitului bancar. Fiecare cont astfel deschis are un număr unic.
