Ae : Zed = ~ Dorin ZAHARIE c) Mose RV LY erly Niculae DAVIDESCU \. Liana Elena ANICA-POPA ES FV yA iely | ie as informatice de gestiune2 Ciclul de dezvoltare al sistemelor informatice de gestiune 2.1 Ciclul de viata al sistemului Introducerea unui SIG nu se rezuma la procurarea de noi programe aplicative si, eventual, de noi echipamente. Aparitia sa antreneaza inevitabil modificari in procesele de business, in gama, profilul si sarcinile alocate posturilor de lucru, in organizarea activitatii si, nu de putine ori, in comportamentul fata de clienti si de ceilalti parteneri. Adeseori, organizatia are nevoie, de asemenea, modificari pentru a se adapta la provocarile si oportunitatile aparute in mediul socioeconomic si recurge la sisteme informatice noi sau la modificarea celor existente ca suport tn obtinerea lor. Din perspectiva organizatiei utilizatoare, un sistem informatic de gestiune parcurge, in existenta sa, patru stadii (figura 2.1): e definirea necesitatii sau oportunitatii sistemului; © — obtinerea sistemului; e _ introducerea in exploatare; © exploatarea curenta si mentinerea in functiune. Definirea necesitatii sau oportunitatii sistemului Definirea necesitatii sau oportunitatii noului sistem formeaza obiectul unei activitati prin excelent multidisciplinara. Aceasta porneste de la problemele pe care organizatia doreste sd le rezolve si, in functie de ceea ce exist in materie de organizare, resurse; echipamente si aplicatii in functiune, identifica obiectivele urmirite, principalii utilizatori si informatiile de care trebuie sa dispuna acestia, limitarile, restrictiile sau cerintele tehnice, stabilind, in final, modul de realizare: printr-un sistem informatic nou sau prin modificarea sistemelor existente. termeni generali, contributia sistemelor informatice de gestiune in sustinerea schimbirilor din organizatie poate consta in automatizare, rationalizare, imbunatatirea proceselor de afaceri (BPR — Business Process Reengineering) si modificarea modelului de business.Dezvoltarea sistemelor informatice de Restlun, le M — Necesitate Inter oportunitate s << Obfinere acizte — Dezvoltane Software B aplicativ Introducere in exploatare Exploatare curenta si mentinere in functiune Figura 2.1 Ciclul de viata al sistemelor informatice de gestiune cuprinde urmatoarele stadii: definirea necesitatii/oportunitatii, obfinerea, introducerea in exploatare, exploatarea curenta si mentinerea in funcfiune. Automatizarea este cea mai veche si comuna forma de interventie a SIG in activitatea socioeconomicd a organizatiilor. In acest caz, contributia sistemului informatic se rezuma la preluarea unor prelucrari efectuate anterior manual sau cu mijloace mai putin performante, mentinand neschimbate procedurile din domeniul respectiv. Rationalizarea intervine pe o scara mai mare, actionand nu numai asupra efectuarii propriu-zise a prelucrarilor, ci si prin imbunatatirea organizarii si derularii unor procese, valorificind facilititile de centralizare, memorare, regasire a datelor si de comunicare pe scara larga, oferite de tehnologie. Business Process Reengineering are in vedere o reconsiderare radical a modului in care se deruleazi anumite procese de business. Aceste efort de schimbare este frecvent acompaniat de introducerea de sisteme informatice adecvate noii viziuni, care o fac posibila si o sustin. Avantajele economice obtinute sunt, in acest caz, mult mai importante| | Ciclul de dezvoltare al sistemelor informatice de gestiune 35 decat in variantele enumerate anterior, dar pot antrena $i riscuri mai mari. Alaturi de BPR, care se concentreaz4 asupra unuia sau a doud procese de business, considerate a fi de important strategicd si pentru care se adopta modificari radicale, organizatiile pot practica si un sistem de management al proceselor de afaceri, care aduce ameliorari $i adaptari de mai mica amploare. Modificarea modelulul de business vizeaza schimbari care afecteaza nu numai anumite procese sau parti din organizatie, ci intregul mod de functionare al acesteia sau orientarea spre activitati comerciale de alta natura. Similar celorlalte cazuri, sistemele informatice de gestiune constituie un suport in asemenea evolutii. Nu este mai putin adevarat faptul ca, in unele cazuri, sesizarea oportunitatilor antrenate de evolutia tehnologiilor informatiei poate fi inspiratoare sau declansatoare de schimbare. Bancomatele si internet bankingul sunt exemple de acest tip, in care evolutia tehnologiei informatiei a indus noi servicii si procese generatoare de venituri. Obtinerea sistemului Din perspectiva organizatiei, un sistem nou se poate obtine prin achizitie sau prin dezvoltare. Achizitia este posibila-daca existé o oferta de software aplicativ cu functionalitatile dorite pe piata. Acesta este un pachet de programe deja disponibil, destinat de la bun inceput cumpararii si utilizarii de catre (cat) mai multi clienti. Asemenea produse se adreseazi domeniilor comune oricaror afaceri sau specifice unei anumite industrii, cum sunt calculul salariilor, urmarirea stocurilor, contabilitatea financiara $.a.m.d, Ceea ce are de facut organizatia, in aceasta situatie, este 4 obtina o lista cat mai completa a ofertelor de pe Piata si si aleaga acel produs si acel furnizor de software care rispund cel mai bine cerintelor sale in materie de lucréri si operatii tratate, conditii si limite de functionare, pret, costuri de instalare si exploatare s.a.m.d. Furnizorul poate fi chiar dezvoltatorul software-ului Sau un tert agreat. Recurgerea la un produs program de uz general impune, inaintea inceperii exploatarii propriu-zise, un proces de Parametrizare si adaptare la organizatie, dar, in acelasi timp, antreneazi si alinierea sistemului informational al organizatiei la viziunea si regulile dupa care acesta opereaza, ceea ce trebuie analizat cu atentie inaintea oricarei decizii de achizitie. :* Dezvoltarea sistemelor informatice de gestiune Dezvoltarea conduce la obtinerea unui sistem "personalizat™, conceput si construit conform nevoilor si conditiilor specifice organizaticl. Are avantajul de a fi adaptat din start acestora, dar costurile si durata de obtinere vor fi mai mari, Dacd se urmareste modificarea unui sistem existent, aceasta poate fi facut numai prin dezvoltare. Introducerea in exploatare Introducerea in exploatare, numita si introducere in productie, asigura amplasarea echipamentelor si a retelelor de comunicatie (dacd este cazul), instalarea software-ului de aplicatie in structurile adecvate, crearea $1 incarcarea initiald a bazei de date, instruirea utilizatorilor, testarea sistemului in conditiile reale de utilizare etc. Exploatarea curenta si mentinerea in functiune le perioada in care sistemul este folosit in cadrul Jucrarilor si obtinerea rezultatelor urmérite prin durata cea mai mare si Exploatarea curentd cuprind organizatiei pentru efectuarea pre introducerea sa. Detine, in ansamblul existentei sistemului, ia sfarsit odata cu scoaterea definitiva din functiune si inlocuirea cu un alt sistem. i | exploatarii curente apar situatii care solicita interventii de mentinere In cursul in functiune (sau fntretinere) a sistemului. Acestea sunt determinate de doua cauze principale: © erori nesesizate in procesul dezvoltarii, care trebuie eliminate; schimbiri survenite in timp, la care sistemul trebuic si se adapteze, cum sunt cele produse de modificdri in legislatie, de evolutia tehnologiilor folosite (echipamente si programe) etc. 2.2 Dezvoltarea externa, dezvoltarea interna, dezvoltarea personala . Dezvoltarea desemneaza crearea unui software de aplicatie nou. Aceasta poate fi facut& anterior (in cazul produselor de uz general), la cerere (in cazul produselor personalizate) sau intr-o varianté combinata (un sistem prealabil modificat, completat si ajustat conform solicitarii beneficiarului). Creatorul software-ului aplicativ va fi desemnat, in continuare, prin termenul generic de dezvoltator. In functie de pozitia acestuia fata de organizatie, se disting: © dezvoltarea externa (outsourcing): dezvoltatorul este o societate comerciala specializata; sistem pe masura". © Se mai foloseste in acest caz $i sintagmatare al sistemelor informatice de gestiune 37 dezvoltarea intern (insourcing): dezvoltatorul este compus din angajati ai departamentului de informatica al organizatiei; dezvoltarea personal (selfsourcing): dezvoltatorul utilizatorul sistemului. Ciclul de dezvol . este chiar Dezvoltarea externa este recomandabila atunci cand este vorba despre functii de afaceri comune sau specifice industriei in cauza, cand competenta si experienta prealabile acumulate in directia respectiva sunt atuuri importante. De asemenea, este prioritara dacd depasirea costurilor sau a termenelor este inacceptabila. Ramane, evident, singura alternativa atunci cand nicio alt modalitate de dezvoltare nu este posibila. Dezvoltarea interna, de catre specialistii in TI (engl. IT) ai organizatiei, este posibild cu conditia ca acestia s4 posede competenta tehnicd necesara si s& existe resurse suficiente, in timp, oameni si echipamente. In caz afirmativ, este maniera de preferat in situatiile in care controlul organizatiei asupra sistemului este critic sau cand sistemul se dezvolta pentru o competent esentiala, specifica respectivei organizatii. Toate celelalte cazuri pot fi luate in considerare atunci cand, din analiza intreprinsd de organizatie, rezulta ca aceasta abordare este cea mai avantajoasa. Dezvoltarea personala, in continua extindere, prezinta avantajul esential de a avea aceleasi persoane atat in calitatea de dezvoltator, cat si in aceea de utilizator. Dezvoltarea personal este cea mai bund, daca nu singura solutie, pentru lucrari noi sau urgente, cnd apelarea la o structura specializat4 nu se justificd sau termenele ar fi de nerespectat. Sunt, de asemenea, situatii, mai ales in efectuarea de analize si adoptarea de decizii, cand utilizatorul formuleaza ipoteze ad-hoc, pe care trebuie sa le poata verifica singur si sA le retina si aprofundeze pe cele care i se par cele mai pertinente. O serie de instrumente informatice moderne avantajeaza acest tip de dezvoltare, cu atét mai mult cu cat, pentru unele dintre ele, definirea probes este direct executabild, asa cum este cazul procesoarelor de tabele. Administratorul sistemului reprezinta persoanele sau structurile care asigura conditiile de functionare curenta a sistemului si gestioneaza masurile de protectie si securitate ale acestuia. In aceasta postura se pot afla: e — utilizatorul; © angajati din departamentul de TI al organizatici; © osocietate comerciala specializata.* Decvoltarea sistemelor informatice de gestiune Utili os in mod normal, sistemele dezvoltate de catre el (daca en ees trebuie si interactioneze si s& se integreze cu Celelalte SIG din organizatie atat sub aspectul preluérii de date, ct si sub cel al i rezultatelor obtinute prin prelucrare, administrarea poate fi Partajat cu Persoane din compartimentul TI, care posed’ cunoasterea de ansamblu a sistemelor Si au capacitatea de a asigura securitatea si coerenta de functionare necesare. Administrarea de catre personalul TI al organizatiei este cazul cel mai frecvent intalnit oN ie sistemului de ctre o societate specializata apare in situatiile in care serviciile de prelucrare sunt externalizate: cu alte cuvinte, atét echipamentele, Ct si software-ul se afla la respectiva societate. In asemenea situatii, fie organizatia se conecteaz la sistemul aflat la tert si foloseste resursele de echipament si software ale acestuia, fiind taxat proportional cu gradul de utilizare, fie transfera, pur si simplu, informatiile cdtre acesta si primeste rezultatele prelucrarilor, platind, in acest caz, serviciul de care beneficiaz4. Contabilitatea este unul dintre exemplele frecvent intalnite de externalizare a sistemelor informatice de gestiune. 2.3 Procese de baza in dezvoltare Diversitatea conditiilor in care are loc dezvoltarea unui sistem informatic de gestiune are consecinte directe asupra activitatilor necesare pentru realizarea sa. Natura aportului sistemului in functionarea organizatiei - automatizare, rationalizare, reingineria proceselor sau reorientarea activitatii, aria de cuprindere a acestuia in organizatie, tipul dezvoltarii - intea, extema sau personald, caracteristicile concrete ale tehnologiilor informationale folosite pentru realizare si functionare ale viitorul sistem sunt factori care diferentiaz4 puternic modul in care are loc dezvoltarea sistemului. Definirea cerintelor Conceperea Figura 2.2 Procesele de bazd in dezvoltarea sistemelor informatice de gestiune Pentru oricare dintre situatiile amintite, exist un set comun de procese de bazd, corespunzatoare logicii de realizare a sistemului ca produs uman: definireaCiclul de dezvoltare al sistemelor informatice de gestiune 39 cerinfelor pe care trebuie sa le satisfack sistemul, proiectarea, constructia si testarea (figura 2.2). Definirea cerintelor Cerinfele descriu comportamentul dorit al viitorului sistem prin specificarea serviciilor pe care acesta urmeaza sa le asigure si al conditiilor si restrictiilor de functionare. Definirea cerintelor este procesul in care beneficiarii sistemului si echipa de dezvoltare stabilesc impreuna si convin asupra produsului care urmeazd a fi realizat. Din perspectiva beneficiarilor, se pot distinge doud categorii de cerinte: de business si de utilizare. Cerintele de business precizeazi scopul sistemului, aria sa de cuprindere, beneficiile sau avantajele pe care acesta ar trebui sa le asigure pentru organizatie si care justific efortul de realizare a lui. Cerintele de utilizare identificd lucrarile ce urmeaza a fi preluate sau asistate de software-ul de aplicatie, modul in care se vor executa aceste lucrari, regulile de gestiune aplicate, posturile de lucru afectate, incadrarea si interactionarea cu restul lucrarilor si activitatilor din procesele de business in care sunt integrate. Din perspectiva dezvoltatorilor sistemului, se disting, de asemenea, doud categorii de cerinte: functionale si nefunctionale. Cerintele functionale precizeazi comportamentul observabil din exterior — cu alte cuvinte, functiile asigurate utilizatorilor umani si de celelalte sisteme cu care interactioneazd — pe care viitorul sistem trebuie si-l asigure pentru a raspunde cerintelor de business si de utilizare. Cerinfele nefunctionale au caracter tehnic si, spre deosebire de cele functionale, care trateaz distinct fiecare functionalitate, sunt globale. Se pot distinge trei grupuri de cerinte nefunctionale: de calitate (performanta, disponibilitate, fiabilitate etc.), de platforma (configuratii de calcul si comunicatie, sisteme de operare, sisteme de gestiune a datelor etc.) si de proces (demers sau metodologie utilizate, termene etc.). Cerintele de business si de utilizare se obtin de la persoanele din organizatie implicate, vizate sau decidente, prin dialog direct sau prin alte tehnici de informare, in cadrul unui subproces de colectare a cerinfelor. Cerinjele astfel obtinute sunt sistematizate, verificate din punct de vedere al coerentei si completitudinii si Teprezentate intr-o forma suficient de detaliata si lipsita de ambiguitate, pentru a sta la baza proiectarii, ce constituie Specificatia viitorului sistem. Elaborarea Specificatiei poate impune reveniri la activitati de colectare a cerintelor, pentru clarificari, completari, corectii. Specificatia, la randul sau, face obiectul validdrii impreund cu beneficiarii, inainte de a se trece la procesul de proiectare. Teoretic, proiectarea, constructia si testarea ar trebui s respecte in totalitate specificatia definiti si aprobaté impreuni cu beneficiarul, pentru a obtine software-ul si sistemul dorit. Practica a demonstrat ins& cd asertiunea, conformmelor informatice de gestiune 7 Dezvoltarea siste i ificati: ; riméne valabilé pand la obfinerea si livrarea eaten cia teat te motive ale acestei stari de fapt: i i, \erealii ist mai mult | sistemului, este nerealist4. Exista mal ne proiectarea, constructia 9 © cererile se modifica in timp ce are | mH cons ; testarea sistemului, din cauza schimbarilor survenite in mediu] socioeconomic in care opereazi organizatia, in obiectivele i, in legislatia in vigoare s.a.m.d.; | ; . reals inifal sunt incomplete sau m reflecta nevoile reale ale utilizatorilor, deoarece acestia nu intrevad, decat dupa ce iau contact cu viitorul sistem sau cu o parte a acestuia, noile conditii de functionare, posibilitatile gi oportunitatile oferite; ; cererile nu sunt corect interpretate $1 injelese din cauza dificultatilor de comunicare dintre utilizatori si echipa de dezvoltare: semnificatia precisa a termenilor si conceptelor de specialitate folositi de fiecare dintre parti poate sé scape celeilalte, din cauza formarii si experiente} lor profesionale diferite. ; Constituind fundamentul viitorului sistem si confruntandu-se cu dificultatile obiective mentionate, definirea cerintelor este considerata un proces critic pentru dezvoltarea sistemelor informatice. Gestionarea sistematic’, coordonata sj controlaté a dinamicii cerintelor si a ajust&rii software-ului in curs de realizare contureazi un domeniu distinct de preocupare — managementul cerinfelor. Proiectarea Proiectarea are ca scop definirea unei solutii informatice corespunzatoare specificafiei sistemului. Aceasta inseamna transpunerea cerintelor intr-un ansamblu de date si unit’ti de program executabile pe tipul de platforma si in configuratia dorita. fn termeni esentiali, 0 unitate de program efectueazi anumite prelucrari, determinate sau derivate din lucrarile informatizate cuprinse in cerintele de utilizare. Datele necesare acestor prelucrari provin fie din memoria pe termen lung a sistemului, constituité sub forma de baze de date, fie din exteriorul acestuia. Preluarea din exterior se realizeaza cu ajutorul echipamentelor dedicate — tastatura, cititoare de diverse tipuri - sau prin comunicare nemijlocité cu alte unitati de Program ori sisteme aflate in functiune. Rezultatele prelucrarilor efectuate pot fi transmise in exterior, prin afisare pe ecran, prin imprimare, prin inscriptionare optica 5.a.m.d., pot fi memorate in bazele de date implicate sau pot fi comunicate direct altor unitati de program sau sisteme. Pentru fiecare unitate de program, orice combinare a acestor variante este posibila. Formularea fiecdrei lucriri de informatizat sub forma de unitati de programare si seturi de date constituie una dintre sarcinile fundamentale ale proiectirii. Definirea detaliilor de continut, reprezentare si structurare a bazei de date, capabile s4 raspunda, in termeni ct mai buni, nevoilor unitatilor de program, in concordant’ cu caracteristicile platformei informatice pe care va functiona, formeaza o alta sarcind fundamentala a proiectirii.Ciclul de dezvoltare al sistemelor informatice de gestiune 4 Stabilirea structurii si aspectului interfetelor cu utilizatorii, ca si a regulilor, restrictiilor $i procedurilor de inserare, respectiv extragere si afisare a datelor, apartin, de asemenea, sarcinilor proiectarii. La cele mentionate, derivate nemijlocit din rolul de infrastructur& a sistemului informational al organizatiei, se adauga incd doud dimensiuni ce fac, de asemenea, obiectul proiectarii. Prima este determinata de nevoia de a controla complexitatea sistemului side a administra realizarea sa. Se cautd, astfel, reutilizarea unor componente si dezvoltarea de structuri aditionale, superioare sau transversale unitatilor de program din software-ul de aplicatie final. Este, spre exemplu, uzuali descompunerea in subsisteme, prin care sunt delimitate parti mai mici si mai putin complexe ale sistemului, dar mai cuprinzatoare decat lucrarile si unitatile de program aferente acestora, parti ce pot fi construite si testate (relativ) separat, succesiv sau in paralel. A doua dimensiune vizeaza nevoia, tipica sistemelor informatice, de protejare fata de tentativele si riscurile de compromitere a securitatii de functionare si a datelor memorate sau manipulate. Proiectarea include, asadar, urmatoarele sarcini: © proiectarea arhitecturii (structurarii) viitorului sistem in Taport cu posturile de lucru pe care urmeazé a fi utilizat si cu functionalititile pe care trebuie sA le asigure fiecdruia dintre acestea, in corelatie cu particularitatile configuratiei fizice si a platformei folosite; © proiectarea bazei de date; © proiectarea unitatilor de program— unitatile sau grupurile de unitati care asigura executia fiecdrei lucrari de informatizat, inclusiv sub aspectul asigurarii protectiei si securitatii ; © proiectarea interfetelor cu utilizatorii. Sarcinile de rezolvat in cursul proiectarii sunt interdependente si nu se deruleaza liniar, formand, la randul lor, un proces. Definirea cerinfelor descrie viitorul sistem informatic sau software-ul de aplicatie sub aspectul comportamentului pe care ar trebui si-l aiba fata de utilizatori si fata de orice alte sisteme, de diverse tipuri, pe care le va utiliza sau cu care va interactiona. in continuarea sa, proiectarea determina si descrie care sunt elementele de natura informaticd, aflate deci in interiorul sistemului, necesare pentru a obfine acest comportament. Prin urmare, definirea cerintelor si proiectarea realizeaza, impreuna, conceperea sistemului (figura 2.2). Construirea Construirea are scopul de a produce unitatile software de instalare necesare livrarii si punerii in functiune a sistemului, pornind de Ja unitatile de programare definite in cursul proiectarii.a Dezvoltarea sistemelor informatice de gestiune acernat mst Uuzual sunt: scrierea programelor intr-un limbaj sursi, aducerea ae rma executabild prin compilare sau interpretare si testarea functionarij fone Programelor este departe de a fi o munca mecanica. {naintea Ormulani in structurile sintactice cerute de limbajul de programare folosit, orice Situatie, orice actiune, orice functionalitate trebuie ganditd, rafinata in cele mai mici detalii. Ceea ce la nivelul proiectirii face obiectul unei fraze sau asertiuni, poate Senera, la nivelul scrierii programului, mai multe module, avand fiecare zeci say Sute de linii de cod. Acest efort de detaliere, de rafinare, de definire este, de asemenea, din sfera proiectarii, dar pe un alt nivel sila o alta scara. Trecerea in forma executabil a textului de program surs4 este automatizati, fiind efectuaté de programe de calculator specializate si, in functie de mediul informatic utilizat, trebuie cerut explicit sau se poate realiza implicit, in total transparent pentru cel care lucreaza. Disfunctionaltatile si erorile constatate la testare sunt inlaturate prin modificarea adecvata a programelor sursa, dupa care noile programe sunt aduse din nou in forma executabila si verificate; acest ciclu se repeti pana cand se ajunge la functionarea dorita. Testarea Testarea este cea care valideaza proiectarea si se afla, in consecinta, in aceeasi situatie: pentru a fi realizata, trebuie conceputa in prealabil, si aceasta in stricta corelatie cu modul in care s-a proiectat functionarea sistemului, de la nivelul cel mai general pani la cel mai detaliat. Ordinea urmatd la testare este ins inversd, parcurgand urmiatoarele trei nivele: © unitara; e de integrare; ¢ desistem. Testarea unitara verificd functionarea separata a fiecarei unitati de program. Ea este incorporata, in mod normal, constructiei. Testarea de integrare vizeazi functionarea unitatilor de program in interactiune. Testarea de sistem se concentreazi asupra functiondrii ansamblului, in calitatea de software aplicativ coerent si unitar. Identificarea sursei erorilor si disfunctionalitatilor si inlaturarea lor presupune revenirea la oricare dintre nivelele de proiectare, inclusiv la programele surs4 si implica un efort creator, care conduce la ajustarea, la amelioarea proiectului. Dupi ce programele sursa au fost redactate, tastate si corectate, se genereaza, prin compilare $i editare de legaturi, formatul executabil final, ce se livreaza alituri de documentatia de utilizare si de exploatare a sistemului.5 Modelarea conceptuala a datelor In forma in care sunt colectate, cerintele fac referire la prelucrari si date in interactiune; modelarea conceptuala opereazi ins sub imperativul separdrii si studierii lor independente. Principala ratiune a acestui demers consta in obfinerea unui grad cat. mai_ridicat_de.flexibilitate. Cum in practicd s-a constatat ca prelucrarile sunt mult mai frecvent expuse modificarilor decat datele, este firesc ca studiul acestora din urma sa fac, in cea mai mare masura posibila, abstractie de prelucrarile la care vor participa. Pentru a nu afecta, pe de alta parte, capacitatea datelor de a raspunde nevoilor de prelucrare in posibila schimbare, articularea lor trebuie s4 corespunda setului de concepte, obiecte, persoane, structuri si fapte care intervin in domeniul respectiv de business. Dar fiecare domeniu foloseste, alaturi de un cadru comun, propriii sai termeni, concepte si sintagme profesionale si prefigureaza o ,fealitate” specifica, in care exista si interactioneaza categorii de obiecte” particulare. Pentru o banca, spre exemplu, realitatea profesionala este compusa din clienti, conturi, credite, dobanzi, comisioane, care vor apare si in formularea cerintelor sale. Intr-o universitate, in schimb, intervin studenti, cadre didactice, discipline, examene etc., iar cerintele vor fi exprimate in raport cu acestea. Exista, prin urmare, o diversitate fireasca si obiectiva, la care modelarea conceptual a datelor trebuie sa dea un raspuns unitar. Una dintre cele mai larg utilizate tehnici folosite in acest scop, numita entitate-relatie sau entitate-asociere (denumire preferata in acest material), recurge la o abstractizare bazata pe trei concepte: entitatea, atributul si asocierea. Elementele specifice fiecdrui domeniu de activitate sunt astfel figurate sub forma de entitati, atribute si asocieri, iar modelul, ca atare, indica datele folosite pentru Teprezentarea lor in software-ul de aplicatie. Pe de alta parte, nici entitatile si nici asocierile nu fac trimitere la vreuna dintre modalitatile tehnice de memorare a datelor, dar formeazi un cadru suficient de riguros si coerent pentru a permite derivarea de solutii informatice corecte. 5.1 Concepte de baza in modelarea entitate-asociere Asa cum s-a mentionat, reprezentarea realitatii se face recurgand la trei Concepte de baza: atributul, entitatea si asocierea. : : Entitatea este expresia unui element, concret sau abstract, existent in domeniul Probleme’ sau activitatii studiate. Spre exemplu, studentul onescu Viadimir”,Ci —<—<——— = _~ 88 Dezvoltares sistemelor informatice de gestiyne disciplina Baze de date”, sala 2/03" sunt entitati participante la activitate, didactica dintr-o universitat Caracteristicile sau proprietatile relevante, Tetinute Pentru reprezentarea unei entitati formeazi atributele acestela. Rezulta de aici a Entitatea este expresia existenfei unui anumit object” caracterizat printr-un set de atribute care, din totalitatea caracteristilor sau proprietatilor sale, sunt considerate semnificative pentru domeniul problemei respective. Astfel, pentru persoang mentionata, vor fi retinute ca atribute: numele, prenumele, data nasterii, sexy] liceul absolvit, adresa de domiciliu, adresa in Bucuresti, necesare pentny evidentierea sa ca student, dar vor fi ignorate altele, cum ar fi: indltimea, greutatea, bolile din copilarie etc. nerelevante aici, dar in mod cert necesare pentru urmarirea | unui medic de familie. Asadar, nu este vizata 9 sa, spre exemplu, ca pacient al nili Teprezentare exhaustiva a realitatii, ci acea (minima) reflectare care raspunde cerintelor problemei sau activitatii reale avute in vedere. Notatia cu ghilimele, folosita pentru numele si prenumele studentuluj, denumirea disciplinei $i numarul sali nu este intamplatoare: ea semnaleaza nevoig identificarii acelui student, acelei discipline si respectiv, a acelei sali, din multimea studentilor universitatii, 4 disciplinelor predate si a salilor de activitati didactice, fie atribute ale entitatilor respective (altfel, Identificatorii folositi trebuie sa atilor entitatile, reprezentate numai prin atributele lor, n-ar fi identificabile). Mai mult decat atat, atributul sau atributele identificatoare trebuie sa aiba valori unice pentru fiecare dintre entitétile de acelasi tip (altfel, din nou, identificarea n-ar mai fi posibila). Printr-o numerotare ingrijita, se poate asigura ca fiecare sald din ba un numér unic, ceea ce face ca acesta sa fie un identificator valabil. Dar numele si prenumele, luate impreund, nu pot constitui un identificator valid pentru oricare dintre studentii universitatii, deoarece exist riscul de a regasi doud sau mai multe persoane avand nume si prenume identice. In consecint trebuie recurs la un alt atribut sau combinatie de atribute care sa permita identificarea sigurd si, in principiu, pe o durata oricat” de mare, a fiecdrui student. Solutia generala aplicata in asemenea cazurl consta in introducerea unui atribut artificial, constituit chiar in acest scop, denumit generic cod”. Probabil unul dintre cele mai cunoscute exemple in aceasta privinta este codul numeric personal, care ar putea fi adoptat si pentru identificarea studentilor, adéugdndu-se, in consecinta, la atributele retinute pentru acesta. Numéarul matricol ar fi un alt atribut utilizabil in acest scop. La stabilirea identificatorului trebuie avute asadar in vedere atat ,,aria, intinderea” pe care acesta urmeaza a fi folosit, ct $i durata preconizata de utilizare (find nevoie, in cazul exemplului nostru, ca identificatorul s4 opereze nu numai pe perioada studentiei, ci si, pentru un numar suficient de ani, dupa absolvirea studiilor). Legaturile dintre entitati, existente in realitatea reflectaté, sunt modelate sub forma de asocieri. Propozitia .Studentul Ionescu Vladimir are joia, intre orele 8 si 10, curs la disciplina Baze de date in sala 2013”, exprima o asemenea legatura, reprezentata in model printr-o asociere intre cele trei entitati mentionate. »Curs, joi, intre orele 8 si 10” sunt atribute. Sunt oare acestea atributele studentului, ale disciplinei sau ale sAlii ? Desigur ci nu. Sunt atribute ale asocierii dintre acestea. universitate saitual modelare® concer 89 asocierea NU numai ca Teprezinta existenta unei legaturi intre entitati, dar sada, in plus, aribute propri diferite de ale entitatilor pe care le leags. ate . ripuri 9 realizari zentarea anterioara s-a facut in termeni de elemente individuale: un anumit re anumité disciplina, o anumita sala. Modelarea trebuie sA cuprinda si si students rezentare valabila pentru ansamblul elementelor, respectiv pentru studentilor din universitate, pentru totalitatea disciplinelor studiate, dea totalitatea Jlilor. Se ajunge astfel la conceptele de entitate tip, asociere tip tru totalitatea S gi aribut P- Realitatea Realizari Entitatea ale entitatii STUDENT e t Bucuresti \ 6722443. : e Popesu Nume Maria Preaume Localitate Nr. telefon e Marinescu Ton Ploiesti G7 21325311 Figura 5.1 Reprezentarea realitatii prin entitati si realizdri de entitayi Entitatea tip reprezintA ansamblul elementelor de aceeasi natura. Student este, in aceste conditii, entitate tip, iar Ionescu Vladimir, un caz particular, denumit realizare a entitatii tip. Fiecare realizare a unei entitati tip este descrisd prin acelasi set de proprietati, acestea find, la nivelul ansamblului, atribute tip. In mod similar, lanivel general, legaturile sunt reprezentate prin asocieri tip. Pentru simplitate, in acest material s-a optat pentru o formulare mai concisd, in care referirea la tipuri se face doar prin termenii entitate, atribut si asociere.90 Dezvoltarea sistemelor informatice a / 7 Resting, active Primand conceptualizari de tipuri identificate in Spatiul Probleme; aii Studiate, se recomanda ca denumirile entitatilor, asocierilor Siar et Sau | fie formulate la Singular. Pentru referirea la un sri ansambluri se utilizeaza Uteloy. anumit element qj termenul de realizare. "9 aceste Continutul Particular al atributului aferent Sau_asociere constituie acceptabile formeaza do Modelul conce Propuse mai multe Materialul de fata'’, unei anumite Tealizari de enti © valoare a acestuia, j a ri ‘ar ansamblul tuturor meniul atributului Tespectiv, val ptual al datelor Se reprezinta grafic, in acest sco, a Conventii de notare, intre care figureazé si cea folosita q in ate Atributul | Atributul — constituie Teprezentarea_ unei Proprietati sau Caracteri sti: clementare, semnificativa pentru Tealitatea modelati, Stici Atributul nu poate avea o existenta independenta » Prezenta sa ¢, intotdeauna legata de o entitate Sau asociere, a cArei i ima, ~ In mod uzual, un atribut trebuie si Teprezinte o informatie elementary | nedecompozabila, Aceasta inseamna, Spre exemplu, ca un atribut adresé nu este | acceptabil si ar trebui sa fie inlocuit cu setul de atribute elementare care 0 compun, Totusi, din considerente de simplitate a modelului, in Situatiile in care ny existg, cerinte de tratare distincté a Partilor componente, atributele compuse pot 4; acceptate. Alaturi de atributele elementare, si atribute ale caror valori se obtin prin sunt denumite airibute derivate si cor ‘a, spre exemply, este un atribut derivat, calculat pe baza datei nasterii sia datei curente. Atributele derivate sunt marcate grafic prin incadrarea i Prezenta lor in model este justificaté de considerente de lizi este, in consecinta, urmarea optiunilor echipei de Proiectare. modelul conceptual al datelor Poate include calcule sau alte tipuri de Prelucrari. Acesteg nstituie, in esenta, redondante. Varsy Unicitatea lizare a entitatii sau asocierii; cu alte cuvinte, multivaloare, cum ar fi, spre exemplu, limbile isi 0 reprezentare alternativa, in care regula in situatiile in care apar atribute Strdine cunoscute, trebuie alea: mentionata sa fie respectata. ee "* Specificd metodei Merise, folosité, printre altele, in lucrarile: (Diving, M., 1989) (Diving, M., 1989), (Nanci, J.C. Asselborn et H. Heckenroth, 2001), (Akoka, J.; Comyn-Wattiau, I., 2001), D.; Espinasse, B. avec la collaboration de B. Cohen, (Bodart, F.; Hainaut, J. L.; Pigneur, Y., 1983), oe pdatelor nceptuald & ” elarea © mod! —gatitate? ‘atea reprezinta un ansamblu de elemente (obiecte) de aceeasi natura, Entital abstracte, Ce pot fi distinse in spatiul problemei sau activitatii studiate. escrisd printr-un set de atribute. Dintre acestea, un atribut sau un e si net d Se ae Z je este jeplineste functia de identificator. de atribute ind SOLICITANTI PROPRIETARI Figura 5. 2 Doud moduri diferite de definire a entitatilor pentru aceeasi realitate jgura 5. Orice realizarea a unei entitati trebuie sa fie distinctibila si identificabila in yt cu toate celelalte. Aceasta inseamna ca atributul sau grupul de atribute ce oe drept identificator trebuie sa ia valori unice pentru fiecare realizare. si Numér matricol Nume Prenume Dats nasteri Sex Adresa [varsta] Abribute Alrisut derivat Gaiuiat, Figura 5.3 Reprezentarea grafica a unei entitati * Definirea entitatilor este, prin excelent, o problemi de proiectare. in primul tand, este necesar s& fie alese drept entitati acele ,obiecte” a cdror perceptie prezinta interes din perspectiva realitatii studiate. fn al doilea rnd, aceeasi realitate Poate fi modelata in viziuni diferite, care depind de intelegerea, preferintele si experienta proiectantului si care recurg la entitati diferite. Spre exemplu, in cazul nei societati de valori imobiliare, clientii pot fi reprezentafi fie printr-o singura+ 2 Dezvoltarea sistemelor informaticg de ' Cstiy, . ‘ Ne entitate, fie prin doud - proprietari si solicitant! — fiecare variant fing co (figura 5.2). Reprezentarea grafica Grafic, entitatea se reprezinta printr-un dreptunghi, in care sunt notat, ay distincte, numele entitatii $i atributele acesteia. Atributul sau atributele Care is ne drept identificator sunt subliniate. Figura 5.3 ilustreazd aceasta reprezentare V*% Asocierea Asocierea modeleaz ansamblul legaturilor dintre realizarile uneja Sa multor entitéti. Numarul de entitati pagticipante ja © asociere define dimensiunea sau gradul acesteia. Cele mai frecvent intalnite sunt asocieriy este grad 2 (binare). Pot exista insa si asocieri cu gradul unu sau mai mare decat 4st fara nicio limitare. . | . , Lista entitatilor participante la o asociere constituie colectia acesteia, Realizarea unei asocieri poate exista numai in prezenta cate unej Tealiza, itatile din colectia sa. Reciproca nu este adevarata: Pot i ri ale fiecareia dintre entit we at ; se exist realizari de entitati care sd nu participe la nicio realizare a asocierii din a cle colectie fac parte. Cod client Nefactura Nume Data facturii Prenume Scadenta Adresa Suma de plata Cardinatitatea minimaia, vesbetit maximaia, centru ABONAT Cardinaiitatea minimala, rexpectit maximaié, tenia FACTURA Figura 5.4 Reprezentarea graficd a unei asocieri Cardinalitati minimale si maximale | Modul de Participare a entitatilor la asociere este definit prin cardinalitat | Pentru o anumita entitate, cardinalitatea precizeaza, prin doua valori, numit- tuald a datelor 93 Mi qaelare® concep! «im, 15 ectiv max: ; respective jndtii TSP Hal gentilt 7 san ("A Vv . iatile maximale. oe litatea minimal cu valoare zero pentru o anumita entitate indica faptul exista realiziri ale acesteia care nu participa la asociere; cu alte cuvinte, t anil 3 a area este optional. == en ort . et I Joarea unu a cardinalitatii minimale inseamna ca orice realizare a entitatit : ebuie s4 participe la cel putin o realizare a asocierii; participarea este, respect tr spective i p jn acest 082 obligatorie. i im de realizari ale asocierii la care poate participa o realizare Valorile uzuale sunt 0 sau / pentru cardinalitatile minimale, reprezentand orice valoare mai mare decat unu) pentru Reprezentarea grafica * Asocierea SC reprezinta grafic printr-un oval, atasat prin linii continue la ile a cAror legatura 0 exprima. in interiorul acestuia sunt_mentionate .q asocierii $i eventualele atribute proprii. Participarea fiecdrei entitati din tie este adnotata cu valorile aferente celor doua cardinalitati ale sale. ora 5.4 prezinta, pentru exemplificare, asocierea dintre facturile emise de 0 societate de telefonie si abonatii sai. Interpretarea cardinalitatilor este urmatoarea: — unui abonat (realizare a entitatii ABONAT) i se pot adresa zero (client nou, pentru care n-a fost emisa inca nicio factura), una sau mal multe facturi (0,n); - © factura (realizare a entitatii FACTURA) este adresata intotdeauna unui singur abonat (1,1). entitati denumire Mai multe asocieri, o singura colectie ta unei legdturi cu o reflectate. Consecinta multe asocieri, avand in modelarea conceptual, asocierea exprima existen semnificatie anume in spatiul problemei sau activitatii imediata este aceea cA intre aceleasi entitati pot exista mai fiecare propriile semnificatii, cardinalitati si, daca este cazul, atribute.4 ~~ Dezvoltarea sistemelor informati ce de Be eStiy Cod chent Nome Prenume Adresa Ur factura Cata facturi: Scadenta Suma de plata Figura 5.5 Interpretarea cardinalitdtilor in reprezentarea asocierii. anterioare Spre exemplu, angajatii unei firme fucreazd fiecare ~ LUCREAZA — un angajat lucreazé intr-un singur departament (cardinalitate /,/); intr-un departament pot lucra mai multi angajati (cardinalitate 0,7); CONDUCE ~— un angajat Poate conduce un singur departament (cardinalitate 0,/); un departament este condus de un angajat (cardinalitate /,/), lucreaza. intre ~ exista deci doua asocieri ne intr-un anumit departament, iar unii dintre acestia conduc departementele in care aceleasi entitati - ANGAJAT si DEPARTAMENT (figura 5.6):a conceptual a datelor c oaelar OEPARTAMENT Cod departament Denumire departament Amplasare Figura 5.6 Doud asocieri diferite intre aceleasi entitati Asocieri cu atribute O asociere poate avea propriile atribute, diferite de cele ale entitatilor pe care le leaga. Figura 5.7 prezinté un exemplu de acest gen, bazat pe structura unei facturi. Factura si produsul constituie entitati. O factura include mai multe produse: in consecinta, se stabilesc legaturi intre factura si fiecare dintre produsele pe care le cuprinde, iar cantitatea facturaté este atributul acestei legdturi. Semnificatia cardinalitatilor este urmatoarea: o factura contine unul sau mai multe produse (/,); un produs poate sa nu figureze in nicio factura, dupa cum poate apdrea in oricat de multe facturi (0,1).96 Dezvoltarea sistemelor informatice de Bestiune entat in figura 5.8. Fiecare dintre marfurile detiny de o firma poate fi stocatd in mai multe depozite diferte si in fiecare deporit se te pistra mai multe marfuri (cardinalitati 0. pentrs ambele entitati). Cantitatea aja, intr-un anumit depozit (stocul curent) este un atribut al asocierii STOCARE Gin al marfii sau al depozitului). Stocul fotal al marfii este un atribut derivat, calcul prin insumarea stocurilor curente din toate depozitele in care se Baseste acesta, Un alt exemplu este prez Asocieri n-are in toate exemplele anterioare, la asocieri au participat doua entitati tip diferite Aceasta nu este insd o limitare. O asociere poate cuprinde oricat de multe entitay atunci cand reprezentarea domeniului problemei impune asa ceva. Interpretarea cardinalitatilor minimale poate ridica, in unele situatii, dificultay daca se ignora precizarea facut anterior, conform careia acestea servesc Pentru, indica optionalitatea sau obligativitatea participarii realizdrilor entitatii la asociere, respectiva. in consecinta, in exemplul de mai sus, cardinalitatea zero atribuig, departamentului in asocierea Iucreazd nu trebuie interpretaté in sensul unyj departament fara angajati, ci in acela al acceptarii (de realiziri) de departamente pentru care ined nu sunt precizati angajatii. Datorité acestei particularitati, unjj tii asemanatoare. notarea cardinalitatii minimale cy autori recomanda, in situa caracterul in camurile in care, din cerinte, rezulta obligativitatea participarii, ca in exemplul privitor la facturi, cardinalitatea minimala trebuie sd primeasca valoarea 1. B> oe datelor nceptuald a area 60) ode! Documentul de hértie... — Facturanr 129904 din 12.26 2016 Denumire UM Pret Cantitate Valoare produs unitar facturati produs Nefactura Data factura Total tactura: cod prods Den proces uM Pretunitar Cantitate facturaté aloare! a $i continutul documentului reprezentat sub forma de realizdri de entitati si asocieri dj produs: 31. cod rodus: 3128. Cantfact 2 Data: 12.38.2014 Urfact 142583 Ne fact: 120004 ‘od produs: 1887 Mrfact 18221 0 Cod produs: 1729 Lf Cant fact: 4 jf | Data 116.2014 4 4 cod produs: 2214 | 4 Cod produs: 2105 Den produs: Branza vac Cantfact 1,5 LUM: kg Pretunitar: 14,50 q Figura 5.7 O facturé si reprezentarea sa entitate-asociere> 98 Dervoltareasistemelor informatie de yyy, Nine Cod marta, Deni ere marae Sma Unitate masuré Port [Stoctotar, Figura 5.8 O asociere cu atribute proprii Sa consideram, pentru exemplificare, cazul unui service auto. Pentru ficcare vehicul aflat in reparatii sau revizie, se deschide un ordin de reparatie. fn cadny, acestuia, mecanicii inscriu lucrarile pe care le-au efectuat, raportandu-se la un nomenclator in care figureaza toate operatiile de manopera si durata lor Medie Lucrarea este, asadar, 0 asociere intre trei entitati (ternara): angajatul (mecanic operatia executata si ordinul de reparatie pe baza ciruia se executd (figura 5.9). SUTOVEHICUL Hrinmatriculare Hrserie sasiv Mar Model Km parcursi ORCIN REPL. Urordin Cod operatic Cata descrideri Cescriere operat Catainchiden Durata medi Defectunireclamate Hrintern Nume Prenume Figura 5.9 Asocierea ternard LUCRARE reprezinta operatiile inscrise in ordinul de reparatie de catre mecanicii care le-au efectuat. Interpretarea cardinalititilor se face prin prisma participarii realizdrilor de entitati la asociere: pentru un ordin de reparatii se pot executa mai multe operatii deptuali a datelor ce spoaelare® eon ” acelasi angajat: acelasi angajat Poate executa aceeasi operatie pentru mai ai oedine de reparatii diferite; aceeasi Operatie (dintre cele prevazute in mul Stor) poate fi executata de catre mai multi angajati pentru acelasi ordin de mn eh aceasta conta ea maximala n pentru toate cele trei entitati le reparal ine cel putin o i a jat, roe a i else Putin o operatie executaté de un angajat, card ema contine si legatura dintre ordinul de reparatie si vehicul tatea /- atasata entitatii AUTOVEHICUL indica faptul ca service-ul oe gistteaZa numai acele vehicule la care s-au facut reparatii sau interventii ine ares find obligatorie, orice vehicul trebuie sa fie legat de cel putin tn Je reparalil C! edinall rain de asocieri reflexive Alaturi de asocierile binare, ternare, ... n-are, exista si asocieri de gradul 1 core 18 jntre ele realizar ale aceleiasi entitati, denumite asocieri reflexive Spre asocierea care reprezinté casatoria leaga intre ele doud realizari fer mpl, # ‘aga intre ele doud realizari diferite exe i PERSOANA (igure $10), fente al i Cod numencpersonal ume Prenume Data nastern Sex Simensiane = 7 Colecte = PERSCANS PERSCANd Figura 5. eprezentarea casatoriei pri igura 5.10 Reprezentarea casatoriei printr-o asociere reflexivitpezvoltares sistemelor informatice de gestiy,, 100 , este necesara specificarea Tolulyj jere reflexiva, “ Pree soci apartin aceleiasi entititj, in deoarece acestea doua roluri sunt sof si sofie. , r de studiu (serie, grupa) in care sum menea, printr-o asociere reflexiya, asa Pentru a putea interpreta 0% realizare, jucat de catre fiecare rea 7a exemplul referitor la casator'e, © it Reprezentarea configuratiel formate incadrati studentii poate fi realizata, cum se vede in figura urmal joare. compusa din cupninsain STRUCTURARE Figura 5.11 Formatiile de studiu reprezentate printr-o asociere reflexive grupele sunt realizari ale entitatii FORMATIE_STUDIU. Rolurile e si aici indispensabila pentru interpretarea : in limita enumeririi Seriile si jucate in asociere, a caror specificare est schemei, introduc si diferentieri privitoare la tipul formatiilo anterioare, o realizare cu rolul ,,compusd din” nu poate fi decat o serie, in timp ce realizarile aferente grupelor nu pot avea decat rolul ,,cuprinsd in”. Figura 5.11 ilustreaza, in plus, si o notatie diferit a cardinalitatilor, care inlocuieste valorile generice cu marimile concrete acceptate: 0 formatie de studiu este compusa din minim 2 si maxim 5 alte formatii (grupe) si este, pe de alta parte, cuprinsa in minim zero (daca este o serie) si maxim o formatie (daca este o grupa in serie). in aceste conditii, componenta fiecdrei grupe se reprezinta printr-o asociere cu studentii respectivi (REPARTIZARE, in figura 5.12), iar apartenenta acestora la seriile de studiu se regaseste prin intermediul asocierii STRUCTURARE. Cum acelasi student poate face parte din mai multe grupe diferite (situatie ce apare, spre exemplu, ca urmare a repartizarii diferentiate pentru disciplinele optionale sauI ' conceptuali a datelor 101 oaelare® | disciplinele de limbi straine), cardinalitatea studentului in asocierea ARTIZARE devine /,n. RE STUDENT Urmatricol Nume Prenume Data nasterit Sex FORMATIE STUDI compusa din cupnnsain STRUCTURSRE Figura 5.12 Gruparea studentilor in formatiile de studiu Identificarea asocierilor Realizarile oricArei asocieri trebuie sa fi identificabile. Cum o asociere nu are jdentificator propriu, regula precedenta se traduce in felul urmAator: intre aceleasi realizari ale entitafilor din colectia unei asocieri, nu poate exista decat o singuré realizare a asocierii. Figura 5.13 prezinta, pentru exemplificare, modelarea sustinerii examenelor la diverse discipline de catre studenti. Schema incalcd regula mentionata, deoarece acelasi student poate sustine de mai multe ori examen la aceeasi disciplina. inlaturarea acestei deficiente se poate face fie prin transformarea asocierii EXAMEN in entitate, fie prin introducerea unei entitati suplimentare pentru reprezentarea timpului, ambele solutii alterand ,,naturaletea” modelului. Asa cum se poate observa in figura 5.14, in care este figurat modelul obtinut prin aplicarea primei solutii, au ap&rut asocieri suplimentare, necesare conectarii noii entitati cu celelalte doua existente. Entitatea EXAMEN are un identificatoroN 102 . Dezvoltarea sistemelor informatice g * Bestiy Propriu gi pastreazd doar atributul Dara examen, iar Nota devine atribut al aso ARE, ‘eri PARTICIP, RE Nematricol VANEN — fume EXAMEN Tad discipins Den discipiing Cae Data examen Tip diseging canes Hota Nrpuneté credt- Figura 5.13 Reprezentarea participarii studentilor la examene STUDENT atticol Hume Cod disciping Prenume Den discipliné Data nasteri: Tip disciplind Sex Nepunete credt Id examen Data examen Figura 5.14 Modelarea corecté a participarii studentilor la examene in virtutea aceleiasi reguli de identificabilitate, o asociere binard care are cel putin una dintre perechile de cardinalitati de valoare 1,1 nu poate poseda atribute proprii (chiar daca, la o prima vedere, aceasta pare a fi mai aproape de perceptia naturala”). 5,2 Reprezentarea regulilor de gestiune prin restrictii de integritate O buna parte a cerintelor functionale consta din reguli de gestiune. Asa cum indica numele lor, acestea sunt reguli specifice activitatii de business reflectate, fixate prin legislatie sau definite de cétre conducerea organizatiei. Unele sunt1 proiectarea bazei de date roiectarii consta in definirea bazei de date si ansamblului de i Rea . : sop creeutabile pe platforma gsi in configuratia convenite. necesare progtal Si cerintelor cuprinse in specificatia sistemului. gatisface™ ectiva rationamentelor efectuate, definirea are loc progresiv, in ersp' 4 je sinteti P roiectare generala, cand se formuleaza o solutie sintetica, de ansamblu tare tehnica, in care se fac detalierile si ajustarile corespunzatoare formei avute in vedere. : : : ; oe jectarea bazei de date, care face obiectul prezentului capitol, urmeaza acest at rogresiV, prin elaborarea unei structuri de baze de date care si corespunda _ i rdel modelului conceptual al datelor, urmata de o ajustare a acesteia la eristicile prelucrarilor presupuse de executia lucrarilor asumate de software- oie aplicatie. Structura obtinuta este detaliata $i adaptata apoi la caracteristicile platformei, care aici vizeazd esentialmente SGBD-ul folosit si suportul pe care-1 propune acesta. atadiile 4° PI aj de proiec’ 7.1 Modelarea logica a datelor Modelarea logicé a datelor urmareste sa dea o solutie de reprezentare informatica a modelului conceptual al datelor. In scopul mentinerii unui grad cat mai ridicat de flexibilitate, se vizeazi un tip de solutie, ce este detaliata si definitivaté apoi, pe nivelul fizic, in configurarea adecvati mediului concret de gestionare al datelor adoptat. Din perspectiva tipurilor de solutii, exista practic doua alternative principale: fisiere sau baze de date. Pentru acestea din urmi, este luat in considerare modelul relational, avand in vedere dominatia sa pe piata. in conformitate cu aceste optiuni, se poate afirma ci modelarea logica a datelor are drept scop definirea bazei de date relationale aferente modelului conceptual al datelor. Concepte de bazaiale modelulul relational sunt ete relational recurge la o structura de reprezentare plata, in care datele ansamblu de i oe sau tabele distincte. Orice tabel sau relatie reuneste un Sup, bine Mctint uri sau inregistrari, compuse fiecare din setul de valori ale unui Conse tet invariabil penta tabelul respectiv, de atribute sau cémpuri ce alone ts acestuia. data nas Mate de fiecare atribut apartin unui anumit domeniu. Spre exemplu. ribut ce poate primi, drept valori, doar date calendaristice. In ceeasi rt este un at i situati ee is : Ne se afla si data cdsdtoriei. in consecinté, un atribut este 0 ae, 162 Dezvoltarea sistemelor informatice de gestiune submultime a unui domeniu cdruia i s-a atribuit un nume. Acest nume exprima, in mod normal, rolul sau semnificatia atribuite elementelor domeniului Tespectiy, Pentru orice tuplu, fiecare atribut poate primi numai acele valori care sunt considerate valide in conformitate cu restrictiile de integritate care-] vizeaza. Structura, definita cel putin prin numele atributelor si domeniul fiecaruja, ramane, in mod normal, invariabila. Modificarea sa, prin adaugare, eliminare, inlocuire de atribute sau schimbare a domeniului, constituie ceea ce se numeste g restructurare si implica rememorarea tuplurilor existente, cu adaptarea la noile Teguli de structura. Cum aceasta poate impune prelucrari complicate, uneori cu imposibilitatea recuperarii tuturor datelor din vechea structurd, este de dorit s& s¢ efectueze cat mai rar cu putinta, ceea ce depinde de o buna proiectare. | =! Atribut Cod numeric personal Nume | Prenume Data Data nasterii casatoriei 1120712411| Ionescu Dan 20.11, 1952] 18 6.1984 2670310485711 | Popescu Valentina | 10/5/1967 | 15/10/1987 1820317251744] Georgesea 17/4/1982 Tuplu sav inregistrare ] Figura 7.1 Iustrarea cétorva concepte ale modelului relational Modificarea tuplurilor este, prin contrast, cat se poate de fireasci si are loc prin actualizare, adic& prin adaugare sau stergere de tupluri sau prin modificarea continutului acestora. Termenii de ‘abel, camp si inregistrare, asociati relatiei, atributului si respectiv tuplului, sunt cei folositi in implementari si vor fi preferati in continuare. Cheia primard este un camp sau grup de cdmpuri din structura tabelului, ales pentru a identifica fiecare inregistrare. Cheia primara suporta 0 restrictie specific relationala: ea trebuie si aiba intotdeauna walori unice si nenule pentru fiecare inregistrare. in exemplul mentionat anterior, campul "cod numeric personal” indeplineste toate conditiile pentru a fi definit drept cheie primara. in unele situatii, structura tabelului poate contine mai multe cAmpuri sau grupuri de campuri care ar putea indeplini aceasta functie. Acestea sunt denumite chei candidat, posibile alternative la cheia primara aleasa. Atunci cand este necesara stabilirea de legaturi intre inregistrari aflate in acelasi tabel sau in tabele diferite, modelul relational preconizeaza introducerea unui cimp sau grup de cémpuri care si contin, in fiecare inregistrare, valoarea prin care se poate identifica inregistrarea cu care se face legatura. Aceasta este 0Pe proiectare® bazei de date 1683 urd bazatd pe continut (legatura logicd). Valoarea plasata intr-un asemenea daca nu este nula, trebuie si aiba un corespondent valid printre inregistrarile c a se face legatura; cu alte cuvinte, valorii sale si i se poata atasa intotdeauna oe jstrare existenta in tabelul vizat. Aceasta conditie generala poarté numele de vstricfi de integritate referentiald. Atunci cand pentru identificarea inregistrarii oo care se face legatura se foloseste cheia primara, cmpul sau grupul de cdmpuri fin tabelul legat folosite in acest scop formeaza o cheie externd. Cheia externa este geci un camp sau grup de campuri dintr-un tabel, care joacd rolul de cheie primara trun alt tabel. C’ heia externa este supusd restrictiei de integritate referential’. eg int Reprezentarea relationala a entitatilor si asocierilor Elaborarea modelului logic constd, in prima faza, in reprezentarea entitatilor i asocierilor care compun modelul conceptual in termenii specific’ modelului relational, adic table, cmpuri, chei primare gi chei externe. Notatia folosita aici se bazeazi pe urmatoarele conventii: tabelul este indicat prin nume, urmat de lista de campuri incadrata de paranteze rotunde; ¢ cheile primare sunt subliniate cu linie continua, iar cheile externe, cu linie punctata. + ~~ entaea Cod client ume 7 Prenume .gischema tabelului corespunzator Adresa ABONATI ‘Cod client, Nume, Prenume, Adresa} Figura 7.2 Reprezentarea unei entitati in modelul logie relational Reprezentarea entitatilor « Pentru entitati, trecerea la modelul logic se face in felul urmator (figura 7.2): © entitatea se reprezinta printr-un tabel distinct; © atributele entitatii devin campurile tabelului; * identificatorul entitatii devine cheia primard a tabelului.164 Dezvoltarea sistemelor informatice de Este Reprezentarea asocierilor Reprezentarea asocierilor se face diferentiat, in functie de eal 7 cardinalitati. a. Asocieri binare cu toate cardinalitatile maximale "n" asocierea se reprezinta printr-un tabel distinct, in care: in acest caz, : tr t, in tilor participante formeaza, impreuna, e identificatorii ent! primara a tabelului; © jdentificatorul fiecarei entitati participante devine cheie externa; e eventualele atribute ale asocierii devin campuri ale tabelului. Cheig Figura 7.3 prezintaé un exemplu de acest tip, in care asociereg PRODUS_FACTURAT este reprezentata printr-un tabel distinct, avand cheia primara compusi din campurile CodProdus si NrFactura. In acelasi timp, CodProdus si NrFactura sunt, fiecare, cheie externa in raport cu tabelul in on indeplinesc functia de cheie primara. Dupa cum se observa, atributele derivate nu fac parte din tabele (nu se memoreaza). Codprodus _ Den produs UM Pretunitar Nrfacturé Data factura Total factura] a y PRODUSE_FACTURATE(Cod produs, factura, Cantitate facturata} PRODUSE ‘Cod produs, Den produs, UM, Pret unitar; FACTURIN« facturi, Data factura} Figura 7.3 Reprezentarea unei asocieri binare cu cardinalitati maximale "n" a Regula mentionata aici este aplicabild in toate situafiile. Este de notat ins cd, in cazurile particulare prezentate in continuare, exista solutii de reprezentare : © Par t . ie ee m care nu mai sunt necesare tabele distincte pentru fiecat 7i . a bazei de date proiestare b asocieri binare cu una dintre Cardinalitatile maximale "1" jn acest az, asocierea Se reprezintd rdinalitatea maximala "/", in felul urmiator: cme identificatorul celeilalte entitati tabelul respectiv; « eventualele atribute ale asocierii se adauga la cimpurile deja existente ale tabelului”, in tabelul corespunzator entitatii cu Participante devine cheie externa in Nefactura Data facturii Scadenta Suma de plata FACTURI Xx faczara, Data factur:, Scadenta, Suma de pl ABONATI ‘Cod client, Name, Prenume, Adres; Figura 7.4 Reprezentarea unei asocieri binare cu o cardinalitate maximala "1" Pentru exemplificare, in figura 7.4 este ilustrat un asemenea caz. Asocierea dintre factura si abonatul caruia ji este adresata, in care cardinalitatea maximal corespunzatoare entitatii Factura are valoarea "1", poate fi reprezentata prin includerea codului clientului drept cheie externa in tabelul FACTURI. O alta solutie, bazata pe aplicarea regulii anterioare, const in Teprezentarea asocierii printr-un tabel distinct in care identificatorii celor douad entitati compun cheia primara si constituie, fiecare, cheie externa in raport cu tabelul la care se tefera (figura 7.5). AceastA varianta are insi dezavantajul de a adauga un tabel Suplimentar si, inc mai important, pe acela de a mari numarul de compuneri (join) Necesare intre tabele. Ea se poate dovedi avantajoasi doar atunci cand cardinalitatea minimali este zero gi frecventa aparitici sale in ansamblul Inregistrarilor este mare. eee " : Asa cum sa ‘mentionat deja, o asemenea asociere nu ar trebui sd aiba atribute proprii.>, Dezvoltarea sistemelor informatice de Rest, 166 le Codclient — _| | FscTuR Nefaeturg Nume Data facturii Prenume Scadenta Adresa Suma de plata FACTURI ‘Xr factura, Data factur:, ABONATI ‘Cod cent, Name, Prenume, Adresa’ Scadenta, Suma de plata Figura 7.5 O alté reprezentare relationala a schemei conceptuale anterioare ¢. Asocieri binare cu toate cardinalitatile maximale Bl fn acest caz, pot fi avute i similare celor prezentate anterior, Prima modalitatea de Teprezentare const in inserarea identificatorului uneia dintre entitati in tabelul aferent celeilalte, in calitate de cheie externa. Cum situatia este aici simetricd, alegerea tabelului in care va fi inserata cheia extema depinde, in plan general, de valoarea cardinalitatilor minimale Si de frecventa aparitiel acestora. Astfel, dacd doar una dintre entitati are cardinalitatea minimal zero, alegerea cea mai indicata este aceea de a insera identificatorul acesteia drept cheie externa in celalalt tabel. Spre exemplu, ca raspuns la factura primita, in aceasta, eventual cu penalizari. Exista deci o sa, in care cardinalitatile maximale sunt ambele insa "zero" in vedere trei tipuri de solutii, dintre care doua abonatul achita suma mentionata asociere intre factura si incasarea de valoare "/", cea minimala fiind parut). In consecinta, solutia telationala preferabilé este aceea de a insera cheia extema, respectiv mumdrul facturii, in tabelul INCASARI (figura 7.6), Aceeasi rezolvare se Poate da si atunci cand ambele cardinalitati minimale sunt "zero", dar freeventa aparitiei uneia dintre ele este mult mai mare decat celeilalte: prin asimilare cu cazul precedent, identificatorul entitatii aferente acesteia este cel ce va aparea drept cheie externa, A doua modalitate consta in reprezentarea asocieri printr-un tabel distinct. in termeni generali, 0 asemenea Tezolvare este adecvata cazurilor in care ambele Cardinalitati minimale au valoarea "zero" si aceasta valoare apare frecvent in ansamblul inregistrarilor. in felul acesta, se vor reprezenta, in tabelul respecti¥,proiectarea bazei de date . umai cheile inregistrarilor aflate efectiy in legiturd, eviténd plasarea unui cmp ml heie extema in unul sau altul dintre tabelele asociate, camp ce va fi, pentru cele i multe dintre inregistrari, neutilizat, mal INCAS4RE Idincasare Data plati Mod pst Unitate Suma platits lurfectura = = Data facturi Scadenta Suma de plats [Penalizare’ ‘ate, Suma p}; iNCASARI Idiacasaze, Data plit Mod plata, Uz Scadenta, Suma de FACTURI Xs factura, Data factar, Figura 7.6 Reprezentarea relationala a unei asocieri binare cu ambele cardinalitati maximale de valoare "|" COMMANDS Urdoc exp Data tivrarit Costtransport --74 Denumire : ' UM ' - ! Pretuniter | He i Cost trasport: MARFURT. MF_COMANDATE Figura 7.7 Reprezentarea unei asocieri binare avand si cardinalitatile minimale cu valoarea "1"168 Dezvoltarea sistemelor informatice de ges, ne Cea de-a treia modalitate consta in comasarea celor doua entitati intr-un gj tabel. in termeni generali, aplicarea sa este recomandabild atungj Mgur cardinalitatile minimale au, de ambele parti, valoarea "/”. Spre exemplu, and aplicatie de comert electronic de tipul B to C (adresat consumatorului individuany° comanda va fi acceptata numai daca poate fi imediat onorata (sau mai precis, oe ; marfuri sau servicii imediat si nemijlocit livrabitey instantanee va cuprinde numai Prin urmare, intre comanda primita si livrarea corespunzatoare va exista 0 asogj avand atat cardinalitatile minimale, cat si cele maximale de valoare "/", Traduceres Tea tr-un singur tabel, ceea ce va mentine Nealteratg : a sa in relational se poate face print reprezentarea corecta a realita! i, eliminand, in acelasi timp, operatia costisitoare q, . le compunere (figura 7.7). d. Asocieri reflexive Reprezentarea relationala a asocierilor reflexive se face prin aplicarea reguliloy referitoare la asocierile binare, in varianta corespunzatoare combinatiei de cardinalitati intalnite. PERSOSNS cue sotie — — Nume Prenume Cata nasterii Sex Data casatoriei ~> “4077 PERSOANE‘CNP, Nume, Prenume, Data nasterii, Sex} Figura 7.8 Reprezentarea unei asocieri reflexive cu toate cardinalitatile maximale "! va in care cardinalitatile tii unei societati, cazurile : | de rare. i bund Figura 7.8 prezinta un exemplu de asociere reflexi sunt "0,/" de ambele parti. Schema referindu-se la angajal in care atét sotul, cat si sotia se numéara printre acestia sunt destul Frecventa de aparitie a cardinalitatii minimale zero fiind deci mare, cea ma ~ aproiectares bazei de date rezentare relationala a asocierii este re ;demtificatori celor dou’ entitati Participante (al cdror nume a fost modificat prin completare CU rolul jucat, atat pentru a i lizibilitae co epetarea at si, cel putin la fel de impotent, pentru a confer lizibilitate structuri) gi atributul propriu asocieri, respectiV data cdsdtoriei, Un alt exemplu, de aceasta dati de care doar una dintre cardinalitatile maxi situatia redata vizeaza gruparea marfu 169 Printr-un tabel distinct. Aceasta preia Teprezentare a unei asocieri reflexive in male are valoarea "/", apare in figura 7.9. z nt : rilor (articolelor) dintr-un magazin, intr-o sructura de clasificare ierarhizata Pe mai multe nivele, de genul: alimente proaspete - fructe, legume, carne - peste, Pasare, porc $.a.m.d. Solutia adoptata este cea care recurge la inserarea, in tabelul Corespunzator entitatii cu cardinalitatea maximala "/", a identificatorului celei e 7 Cu acelasi nume nu este permisa, denumirea campului cheie externa, care oricum trebuia modificaté, a fost completata cu numele de rol jucat in asociere, devenind cod grupi superioara, ceea ce are avantajul de a o face mai lizibila si, nu mai putin, de a indica legatura cu modelu: conceptual. : [ Cod arupa -- Cenumite grups GRUPE (Cod gnupi, Denumize grupi, Coder ARTICOLE:Cod base, Denumize articol, Unitate misuri, Unitate vanzase, Pret vanzare, Stoc, G Figura 7.9 Reprecentarea unei asocieri reflexive cu una din cardinalitdjile maximale de valoare "I"Dervoltarea sistemetor intormatice g \c Figura 7.10 ilustreaza un alt caz, bazat pe modelarea structurii q Stone produselor unei unitati industriale. Entitatea ARTICOL are aicy nye bricatig desemnand orice element material care participa, se consumy a" gener procesele de fabricatie. Prin urmare, un articol se obyine din zero (avy C28 dit achizitionat) sau mai multe articole (daca este semifabricat ema no EE un bun acelasi timp, orice articol poate fi intrebuingat la fabricatia alter ero’ final) este un produs final sau secundar, a niciunuia. attlcole sau, daca Fasicen ARTICOL obtinut Cod attica! Denumire articol Unt Pret standard ‘Norma consum) ARTICOLE (Cod articol, Denumire articol, UM, Pret standard) Figura 7.10 Reprezentarea unei asocieri binare cu ambele cardinalitati maximale de valoare "n" Asocierea reflexiva care exprima aceste legaturi, avand ambele cardinalitati maximale cu valoarea "n", nu poate fi reprezentat relational decat printr-un tabel distinct, in care apar identificatorii entitatilor participante — aici, una singura, motiv pentru care numele a fost completat cu rolurile jucate in asociere — si atributul asocierii, respectiv norma de consum prevazuta in documentatia de fabricatie. e. Asocierin-are Hi itati inta print-un Asocierile la care participa trei sau mai multe entitati se reprezinta p' tabel distinct, in care: ob ¢ identificatorii entitatilor participant ae formeaza, impreuna, cheia primara a Canaan cheie exter e identificatorul fiecarei entitati participante Cvs ierii i i tabelului. © eventualele atribute ale asocierii devin atribute ale peo ala "1" e cu cardinalitatea maximal aegis> prietare bazl de date att Figura 7.11 reia exemplul de asoci 7 ie lere temara inclus in capitolul cinci si predit structura tabelului LUCRARI, cari E ei da expresie relationala. th Uclomatricutare Ursetiesasic Marca * Wodel Km parcursi Sod operatic Descriere operate Ourata medie Heintern Nome Prenume ' \ ! 1 1 Voy v y ORDINE_REPARATIE Nr ordin. Data deschiderii, Data inchiderii, Defectiuni reclamate, Nr inmatriculare) ANGAJATI (Nr intem, Nume, Prenume) OPERATII (Cod operatie. Descriere operatic, Durata medie) AUTOVEHICULE (Nr inmatriculare, Nr serie sasiu, Marcd, Model, Km parcursi) Figura 7.11 Reprezentarea unei asocieri n-are Reprezentarea subtipurilor de entitati Reprezentarea relational a subtipurilor de entitati trebuie si asigure: * exprimarea legaturilor existente intre subtipuri si tip, in sensul in care fiecare realizare a subtipurilor trebuie sd fie, simultan, si o realizare a tipului;YY Dezvoltarea sistemelor informati 172 ice de Bestinne e — simularea mecanismului mostenirii, pentru care modelul relation, ofera o solutie dedicata. oo : “onal ny Solutionarea primului aspect se face considerand ca Intre tip si subtipur} ex: asocieri binare cu cardinalitati 0,/ - /,/ si aplicand regula de reprezentare specif : fica acestui caz. a Pentru al doilea aspect, existé mai multe solutii posibile, diferentiate in func de modul de constituire a subtipurilor, prin specializare sau prin generalizare. tie Hume I 1 Prenume ' 1 Sex J 1 Data nasterii ' 1 Tip ' ' 1 i 1 ' 1 ' 1 ' 1 1 t i> i<- 4 Hr matricol Grad didactic = An studi hime i “FT lr pete credit 1 ' ee : ' STUDENTI-CNP, Nz matccol, An stud=, Nx pcte credits w CADRE_DIDACTICE‘CNP, Grad didactic, Vechime invatim) PERSOANE’CNP, Nume, Prenume, Sex, Data nasteri, Tip: Figura 7.12 Reprezentarea tipului si subtipurilor prin tabele distincte Specializarea O primé solutie consta in utilizarea de tabele distincte pentru reprezentare tipului si a subtipurilor. Identificatorul tipului migreaz in toate tabelele si devine cheie primara atat pentru tip, cat si pentru subtipuri (figura 7.12). . Unmatoarele doua solutii se bazeaza pe aplatizarea relatiei, fie "in sus", fie "0 jos". In primul dintre cazuri, se ajunge la un tabel in care sunt memorate atributele tipului, ct si cele ale tuturor subtipurilor. Avantajul acestei variant? const in existenta unui singur tabel; spatiul de memorare este ins irosit part! atatbazei de date jectarea proiee! 173 faptul 4, in functie de subtipul cat in ymite campun vor fi inevitabil neutil agueere unor restrictii de integritate mi Tuia fi apartine o inregistrare sau alta, izate. De asemenea este indispensabila Dee Care sa verifice completarea sl, Tespectiv, ecompletarea cémpurilor in functie de subtipul concret Teprezentat. Specializarea cq atare este exprimata prin Introducerea Unui atribut suplimentar care si indice subtipul céruia il apartine fiecare Inregistrare, la care, de altfel, va face referinta si restrictia de integritate mentionat / Schema relationala aferenta acestui gen de Solute, pentra modelul conceptual eseris in figura 7.12, este urmatoarea: PERSOANE (CNP. Nume. Prenume, Sex, Dat matricol, An stu Grad didactic, Vechime ‘anasterii, Tip, Ir pete credit, invayam) Prin aplatizarea "in jos", se creeaza tabele distincte pentru fiecare subtip, iar atributele tipului "coboara” si se adauga in fiecare dintre acestea. in aceasta modalitate de reprezentare, schema relationala Pentru acelasi model conceptual este urmatoarea: STUDENTI (CNP. Nume. Prenume, Sex, Data nasterii, Nr matricol, An studii, Nr pete credit) ume, Prenume, Sex, Datanast Grad didactic, Vechime invayam) CADRE_DIDACTICE (CNP, Ni Generalizarea in cazul generalizarii, subtipurile au Propriii identificatori. Prin urmare, Singura solutie este aceea de a crea tabele distincte Pentru fiecare structura si de a le lega prin inserarea identificatorului tipului in calitate de cheie externa in tabelele aferente fiecdrui subtip. Figura 7.13 prezinta un exemplu de acest gen, in care Nr ‘er cheia primara a tipului, apare in postura de cheie extend in tabelele aferente subtipurilor, Reprezentarea evolutiei in timp _ Expresia Telationald a situatiilor de acest gen urmeazi regulile generale, cu “Aceptia faptului ca entitatile prin care se reprezinta timpul (date, perioade) nu apar A labele distincte, fn consecintd, atributele entititilor de acest gen participa la Smmateacheilor primare, dar nu pot constitui chei externe. a»ae Decvoltarea sistemelor informa zvoltal i tice di ¢ de gesti june Exemplul din fi i " ip in figura 7.14 ilustreaza acest caz: 174 modelul logic este coi spss s mpus doar din doua ont e pus loua tabs ot itatii VALUTA si asocierii COTATIE: entitat oe SOR patzato reprezentare explicita; 7 9 4. COTATIE ny an cheia primara a tabelului . mara a t lui COTATII este co a din j celor doua entitati participante — Cod valuta Dae "dentificato in absenta unui tabel distinct p. imp, nur ibsent listinct pentru t i " , numai codul valutej Poate heie extemi, ate fi Mrtert SSacee Denumire Y Adresa 1 ‘ ‘ 1 \ CLIENT 1 Urchient Nefurnizor ‘ Categorie client Duraté livrare Condit vancare { < : = \ & Vv CLIENTI-Xz cent, Categore client, Conditi vanzaze, Nr text: FURNIZORI Xz fum:zor, Durata livrare, Nx test) TERTIXr text, Denunrse, Adresa} Figura 7.13 Reprezentarea tipului si subtipurilor obtinute ‘prin generalizare Cod valuta Denumire valuta 1 z g oy coTATIL ‘CodValuta, Data CursOficial} x TE ‘CodValu 4 iceValuta} VALUTE ‘CodWaluta, Denuam wr valutare zilnice Figura 7.14 Reprezentarea relationald a cotatiilo> 5 ctarea bazei de date 1 Prot 7 i ° Pentru entitatile ce exprins Perioade, in compunerea cheii primare pot fi ainute fie ambele momente care delimiteaza, fie, in situatile in care apar veal in curs (inca Neincheiate , numai in 4 rimind nul Mal momentul de inceput, pentru a permite ina -a cel final sa ramai . cacel od anasiat fume Prenume Cod compsriment ares Denumire compartment Studi Functia Salariul Data INceperii ila Data terminariisia; Data Cod ang ANGAJATI‘Cod gaiat, Nume, Prenume, Adtesa, Stu i COMPARTIMENTE,¢, d compartment Denumite Compartment, Figura 7.15 Reprezentarea locurilor de mun Ei anagajatilor, trecute St prezente le 0 Consecinta, cheile pri UR_MUNCA si INCADRARE — inc\ inceput, care este M toate cazurile, Data termingrii Prezenta in cele doua “6 darnu mai face parte din cheia primara.os” 176 Dezvoltarea sistemelor informatice q © Besti lune Identificatorii relativi Identificatoni relativi itui i i constituie unul dintre tipuril sk fecaness le de restricti structurala si desemneaza situatiile in care pentru idéatificarse ane sa aturi se recurga, alaturi de atribute proprii, la rolul jucat de vite asociere la care participa impreuna. o alta Relational, reprezentar i t . ea se face incorporand in i ii _ cpre: , ¢ cheia pri: oo eee entitatii restrictionate, identificatorul celeilalte entitat normal, se exprima asocierea: conform ii =e mene regulii generale, acesta di de int a eBTita ntitati treb = entitate intr. “0 a tabeluty; TiN care, j VINE Si Cheje TELIER y N v PROIECTE “Xratelier, Nr proiect, Tenmen’ ATELIERE ‘Xrateler, Adresa} ’ Figura 7.16 Reprezentarea relationala a cazurilor de identificatori relativi Figura 7.16 ilustreazi aceasta rezolvare: tabelul PROIECTE are o cheie din campurile Nr proiect si Nr atelier, Acesta din urmi primara compusa, formata da expresie rolului jucat de entitatea ATELIER in asocierea EXECUTA participanta la identificare si este, in consecinta, si cheie externa. Pentru o ilustrare mai completa, in continuare este prezentat modelul logic relational aferent gazduirii clientilor in hotel. E, TIPURI_,CAMERE, CLIENTI, REZERVARI, CAZARI, Tabelele CAMER. iB i} NOTE_CHELTUIELI, FAC’ TURI, INCASARI $i PERIOADE-TARIFARE corespund entitatilor din modelul conceptual (reluat, pentru a facilita urmarirea procesului, in figura 7.17). CLASIFICARI_CAMERE, CAMERE_LIBERE, CAMERE_REZERVATE, iT. ierilor in care CAMERE_OCUPATE $i TARIFE sunt tabelele care dau expresie asoc’ toate cardinalitatile maximale ale entitatilor participante au valoarea "n", Toate celelalte asocieri sunt reprezentate prin inserarea de chei externe in tohele® aferente entitatilor pentru care cardinalitatile maximale au valoarea "/" (SP! f Cod exemplu, Nr cazare in NOTE_CHELTUIELI pentru asocierea INCLUDE, ©% client in REZER VARI pentru asocierea SOLICITA etc.). _ ae- -a bazei de date proicctare 177 Asocierea cu cardinalitati maximale "/"" dintre entitatile Cazare si Facturd a fost reprezentat’ ape ‘nserarea numdrului cazarii drept cheie extema in tabelul FACTURI, datorité faptului cd pentru aceasta, cardinalitatea minimal are valoarea nj" (conform recomandarii mentionate la pagina 166). CAMERE (Nr camer’ Ftaj, Descriere) TIPURI_CAMERE (Cod tip, CLASIFICART_CAMERE Nrlocuti, Conforty d era dela. Libera panila) CLIENT] (Cod client, Nume, Prenume, Adresi, ‘ervarii, Rezervat dela, REZERVARI (Nr Tezervare, d client) CAMERE_REZERV ATE (Nrrezervare, Nrcamera CAZARI (Nr cazare, Data venitii, Data plecari :Nere CAMERE_OCUPATE. + Rezervatpana la, : Nrpersoane) 7.2 Opti Schema relationala derivata din modelul conceptual al datelor este solutia Corecté pentru viitorul sistem, in cadru general. O bazi de date creaté in Conformitate cu ca va asigura fondul de informatii necesar prelucrarilor presupuse de cerintele functionale. Existé insé o puternica interactiune cu_prelucrarile €xecutate, in sensul in care st ructura de memorare a datelor le poate creste sau, dimpotriva, diminua gradul de complexitate, cu consecinte directe asupra Performantelor. Prin urmare, schema initiala a bazei de date ar trebui Tevazuta si Modificata, nu Pentru a corespunde mai bine problemei ce face obiectul sistemului Sau tegulilor de normalizar e relationala, ci pentru a fi optimizatd in raport cu Prelucrarile specifice, Particulare la care urmeazA si participe. Ptimizarea presupune, pe de o parte, o ajustare a implementa, fee &xploatarea la maxim a tuturor caracteristicilor si posibilitatilor tehnice spec