Dorin ZAHARIE Victoria STANCIU — Niculae DAVIDESCU * Liana Elena ANICA-POPA 4 Nea ea sistemelor ose | Cea ett ts2 Ciclul de dezvoltare al sistemelor informatice de gestiune 2.1 Ciclul de viata al sistemului Introducerea unui SIG nu se rezumi 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. Adescori, 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 in obtinerea lor. Din perspectiva organizatiei utilizatoare, un sistem informatic de gestiune parcurge, in existenta sa, patru stadii (figura 2.1): ¢ definirea necesitatii sau oportunit&tii sistemului; © obfinerea sistemului; © introducerea in exploatare; © — exploatarea curenta si mentinerea fn 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 si le rezolve si, in functie de ceea ce exista in materie de organizare, resurse, echipamente si aplicatii in functiune, identifica obiectivele urmiarite, principalii utilizatori si informatiile de care trebuie si dispund acestia, limitarile, restrictiile sau cerintele tehnice, stabilind, in final, modul de realizare: printr-un sistem informatic nou sau prin modificarea sistemelor existente. in 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.34 Necesitate oportunitate Obtinere Dezvoltarea sistemelor informatice de gestiune pre ie Dezvoltare Software aplicativ Introducere in exploatare Exploatare curenta si mentinere in functiune matice de gestiune cuprinde urmdtoarele obfinerea, introducerea in exploatare, exploatarea curenté: $i mentinerea in functiune. Automatizarea este cea mai veche si comuna forma de interventie a SIG in activitatea socioeconomica 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, valorificand facilitatile 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 38 decat in variantele enumerate anterior, dar pot antrena si riscuri mai mari. Alaturi de BPR, care se concentreazA asupra unuia sau a doua procese de business, considerate a fi de importanta strategicd si pentru care se adopt modificari radicale, organizatiile pot practica si un sistem de management al proceselor de afaceri, care aduce ameliorari si adaptari de mai mic amploare. Modificarea modelului de business vizeazA schimbiri care afecteazi 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. Obfinerea sistemului Din perspectiva organizatiei, un sistem nou se poate obtine prin achizitie sau prin dezvoltare. Achizitia este posibili-dacd 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 oricdror afaceri sau specifice unei anumite industri, cum sunt calculul salariilor, urmarirea stocurilor, contabilitatea financiara s.a.m. Ceea ce are de facut organizatia, in aceasta situatie, este si obtina o list cat mai completa a ofertelor de pe piatd si si aleag& acel produs gi acel furnizor de software care raspund cel mai bine cerintelor sale in materie de lucrari si operatii tratate, conditii si limite de functionare, pret, costuri de instalare si exploatare $.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, antreneaza si alinierea sistemului informational al organizatiei la viziunea gi regulile dupa care acesta oper: oricarei decizii de achiziti ceea ce trebuie analizat cu atentie inaintea36 Dezvoltarea sistemelor informatice de gestiune Dezvoltarea conduce la obtinerea unui sistem "personalizat", conceput si construit conform nevoilor si conditiilor specifice organizatiei. Are avantajul de a fi adaptat din start acestora, dar costurile si durata de obtinere vor fi mai mari. Daci se urmareste modificarea unui sistem existent, aceasta poate fi facuta numai prin dezvoltare. Introducerea in exploatare Introducerea in exploatare, numit si introducere in productie, asigur’ amplasarea echipamentelor si a retelelor de comunicatie (dac& este cazul), instalarea software-ului de aplicatie in structurile adecvate, crearea si incarcarea initialA a bazei de date, instruirea utilizatorilor, testarea sistemului in conditiile reale de utilizare etc. Exploatarea curenta $i mentinerea in functiune Exploatarea curenta cuprinde perioada in care sistemul este folosit in cadrul organizatiei pentru efectuarea prelucrarilor si obtinerea rezultatelor urmarite prin introducerea sa. Detine, in ansamblul existentei sistemului, durata cea mai mare si ia sfargit odata cu scoaterea definitiva din functiune si inlocuirea cu un alt sistem. in cursul exploatarii curente apar situatii care solicita interventii de mentinere in functiune (sau intretinere) a sistemului. Acestea sunt determinate de doua cauze principale: © crori nesesizate in procesul dezvolt i, care trebuie eliminate; e schimbari survenite in timp, la care sistemul trebuie sA se adapteze, cum sunt cele produse de modificiri in legislatie, de evolugia tehnologiilor folosite (echipamente si programe) etc. 2.2 Dezvoltarea externa, dezvoltarea interna, dezvoltarea personala Dezvoltarea desemneaz crearea unui software de aplicatie nou. Aceasta poate fi facuta anterior (in cazul produselor de uz general), la cerere (in cazul produselor personalizate) sau intr-o varianté combinaté (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 fat de organizatie, se disting: e dezvoltarea externa (outsourcing): dezvoltatorul este o societate comerciala specializata; © Se mai foloseste in acest caz gi sintagma "sistem pe masura". loses!Ciclul de dezvoltare al sistemelor informatice de gestiune 37 e dezvoltarea interna (insourcing): dezvoltatorul este compus din . angajati ai departamentului de informatica al organizatiei; © dezvoltarea personalé (selfsourcing): dezvoltatorul este chiar utilizatorul sistemului. Dezvoltarea externa este recomandabila atunci cand este vorba despre functii de afaceri comune sau specifice industriei in cauzi, cand competenta si experienta prealabile acumulate in directia respectiva sunt atuuri importante. De asemenea, este prioritara daci depasirea costurilor ; sau a termenelor este inacceptabila. Ramane, evident, singura alternativa } atunci cand nicio alta modalitate de dezvoltare nu este posibila. in TI (engl. IT) ai organizatiei, este posibila cu conditia ca acestia si posede competenta tehnicd necesara si sa existe resurse suficiente, in timp, oameni si echipamente. fn caz afirmativ, este maniera de preferat in situatiile in care controlul organizatiei asupra sistemului este critic sau cAnd sistemul se dezvolti pentru o competent’ esentiali, specificd respectivei organizatii. Toate celelalte cazuri pot fi luate in considerare atunci cand, din analiza intreprins de organizatie, rezulti cd aceasti abordare este cea mai avantajoasa. Dezvoltarea personalé, in continu extindere, prezintaé avantajul esential de a avea aceleasi persoane atat in calitatea de dezvoltator, cat si in aceea de utilizator. Dezvoltarea personala este cea mai buna, dacd nu singura solutie, pentru lucrari noi sau urgente, cand apelarea la o structuri ; specializaté 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 poati verifica singur si s& le retina si aprofundeze pe cele care i se par cele mai pertinente. O serie de instrumente informatice moderne avantajeazi acest tip de dezvoltare, cu atét mai mult cu ct, pentru unele dintre ele, definirea problemei este direct executabila, asa cum este cazul procesoarelor de tabele. Administratorul sistemului reprezinté persoanele sau structurile care asigura conditiile de functionare curenta a sistemului si gestioneazi masurile de protectie si securitate ale acestuia. in aceast’ postur se pot afla: © utilizatorul; © angajati din departamentul de TI al organizatiei; ® osocietate comerciala specializata.38 Dezvoltarea sistemelor informatice de gestiune Utilizatorul administreaza, in mod normal, sistemele dezvoltate de catre el (dac& existi). Deoarece acestea trebuie sa interactioneze si si se integreze cu celelalte SIG din organizatie at&t sub aspectul preluarii de date, cat si sub cel al furnizArii 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. Administrarea sistemului de catre 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 conecteaza 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 citre 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 dezvoltirii — intema, extemd sau personali, caracteristicile concrete ale tehnologiilor informationale folosite pentru realizare si functionare ale viitorul sistem sunt factori care diferentiazi puternic modul in care are loc dezvoltarea sistemului. | Definirea Construirea Testarea cerintelor Proiectarea Lenn Conceperea Figura 2.2 Procesele de bazét 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 si le satisfacd sistemul, proiectarea, constructia si testarea (figura 2.2). Definirea cerintelor Cerintele descriu comportamentul dorit al viitorului sistem prin specificarea serviciilor pe care acesta urmeazi si le asigure si al conditiilor si restrictiilor de fanctionare. Definirea cerinfelor este procesul in care beneficiarii sistemului si echipa de dezvoltare stabilesc impreuna si convin asupra produsului care urmeazii a fi realizat. Din perspectiva beneficiarilor, se pot distinge doua categorii de cerinte: de business gi de utilizare, Cerintele de business precizeazi scopul sistemului, aria sa de cuprindere, beneficiile sau avantajele pe care acesta ar trebui si le asigure pentru organizatie si care justified efortul de realizare a lui. Cerintele de utilizare identifica 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 fn care sunt integrate. Din perspectiva dezvoltatorilor sistemului, se disting, de asemenea, doud categorii de cerinte: functionale si nefunctionale. Cerinfele functionale precizeazi comportamentul observabil din exterior — cu alte cuvinte, functiile asigurate utilizatorilor umani si de celelalte sisteme cu care interactioneazi — pe care viitorul sistem trebuie sa-l asigure pentru a raspunde cerintelor de business gi de utilizare. Cerintele nefunctionale au caracter tehnic si, spre deosebire de cele functionale, care trateaza distinct fiecare functionalitate, sunt globale. Se pot distinge trei grupuri de cerinfe 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. Cerintele astfel obtinute sunt sistematizate, verificate din punct de vedere al coerentei si completitudinii si reprezentate intr-o forma suficient de detaliata si lipsité 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 clarificdri, completiri, corectii. Specificatia, la randul su, face obiectul validdrii impreuna cu beneficiarii, inainte de a se trece la procesul de proiectare. Teoretic, proiectarea, constructia si testarea ar trebui sd respecte in totalitate specificatia definiti si aprobati impreund cu beneficiarul, pentru a obtine software-ul si sistemul dorit. Practica a demonstrat insd cA asertiunea, conform40 Dezvoltarea sistemelor informatice de gestiune c&reia specificatia este complet si rimAne valabild pand la obtinerea si livrarea sistemului, este nerealisté. Existé mai multe motive ale acestei stari de fapt: © cererile se modifica in timp ce are loc proiectarea, constructia si testarea sistemului, din cauza schimbarilor survenite in mediul socioeconomic in care opereazi organizatia, in obiectivele managementului, in legislatia in vigoare .a.m.d.; © cererile formulate initial sunt incomplete sau nu reflect nevoile reale ale utilizatorilor, deoarece acestia nu intrevad, decdt dupa ce iau contact cu viitorul sistem sau cu o parte a acestuia, noile conditii de fanctionare, posibilitatile si oportunitatile oferite; © cererile nu sunt corect interpretate si infelese 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 si scape celeilalte, din cauza formirii si experientei lor profesionale diferite. Constituind fundamentul viitorului sistem si confruntandu-se cu dificultatile obiective mentionate, definirea cerintelor este consideraté un proces critic pentru dezvoltarea sistemelor informatice. Gestionarea sistematicd, coordonata si controlaté a dinamicii cerintelor si a ajustarii software-ului in curs de realizare contureaza un domeniu distinct de preocupare — managementul cerinjelor. Proiectarea Proiectarea are ca scop definirea unei solutii informatice corespunzitoare specificatiei sistemului. Aceasta inseamnd transpunerea cerintelor intr-un ansamblu de date si unitati de program executabile pe tipul de platforma si in configuratia dorita. in 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, constituita sub forma de baze de date, fie din exteriorul acestuia. Preluarea din exterior se realizeaz& 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 s.a.m.d., pot fi memorate in bazele de date implicate sau pot fi comunicate direct altor unititi de program sau sisteme. Pentru fiecare unitate de program, orice combinare a acestor variante este posibila. Formularea fiecrei lucrari de informatizat sub forma de unitati de programare si seturi de date constituie una dintre sarcinile fundamentale ale proiectarii Definirea detaliilor de continut, reprezentare si structurare a bazei de date, capabile s& 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 proiectarii.Ciclul de dezvoltare al sistemelor informatice de gestiune 41 Stabilirea structurii si aspectului interfefelor cu utilizatorii, ca si a regulilor, restrictiilor si procedurilor de inserare, respectiv extragere si afisare a datelor, apartin, de asemenea, sarcinilor proiectarii. La cele mentionate, derivate nemijlocit din rolul de infrastructura a sistemului informational al organizatiei, se adauga inca dou dimensiuni ce fac, de asemenea, obiectul proiectarii. Prima este determinata de nevoia de a controla complexitatea sistemului si de 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 cuprinzdtoare decat Iucrarile si unitatile de program aferente acestora, parti ce pot fi construite gi testate (relativ) separat, succesiv sau in paralel. A doua dimensiune vizeaza nevoia, tipicd 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 raport cu posturile de lucru pe care urmeaza a fi utilizat si cu functionalitatile pe care trebuie si le asigure fiecdruia dintre acestea, in corelatie cu particularitatile configuratiei fizice si a platformei folosite; © proiectarea bazei de date; © proiectarea unititilor de program— unititile 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 cerintelor descrie viitorul sistem informatic sau software-ul de aplicatie sub aspectul comportamentului pe care ar trebui s&-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 gi descrie care sunt elementele de natura informaticd, aflate deci in interiorul sistemului, necesare pentru a obtine acest comportament. Prin urmare, definirea cerintelor si proiectarea realizeaza, impreund, 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 la unitafile de programare definite in cursul proiectiri.42 Dezvoltarea sistemelor informatice de gestiune Pasii urmati uzual sunt: scrierea programelor intr-un limbaj sursa, aducerea acestuia in forma executabila prin compilare sau interpretare si testarea functionarii sale. Scrierea programelor este departe de a fi o munca mecanica. fnaintea formularii in structurile sintactice cerute de limbajul de programare folosit, orice situatie, orice actiune, orice functionalitate trebuie gandit’, rafinata in cele mai mici detalii. Ceea ce la nivelul proiectarii face obiectul unei fraze sau asertiuni, poate genera, la nivelul scrierii programului, mai multe module, avand fiecare zeci sau sute de linii de cod. Acest efort de detaliere, de rafinare, de definire este, de asemenea, din sfera proiectarii, dar pe un alt nivel si la o alta scara. Trecerea in forma executabila a textului de program sursa este automatizata, find efectuata de programe de calculator specializate si, in functie de mediul informatic utilizat, trebuie ceruta explicit sau se poate realiza implicit, in totala transparenta pentru cel care lucreaza. Disfunctionaltatile gi erorile constatate la testare sunt inliturate prin modificarea adecvata a programelor sursa, dupa care noile programe sunt aduse din nou in forma executabila si verificate; acest ciclu se repeta 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 strict’ corelatie cu modul in care s-a proiectat functionarea sistemului, de la nivelul cel mai general pani la cel mai detaliat. Ordinea urmata la testare este ins inversi, parcurgand urmitoarele trei nivele: © unitara; ede integrare; © de sistem. 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 functionarii ansamblului, in calitatea de software aplicativ coerent si unitar. Identificarea sursei erorilor si disfunctionalit3tilor si inlaturarea lor presupune revenirea la oricare dintre nivelele de proiectare, inclusiv la programele sursi si implica un efort creator, care conduce la ajustarea, la amelioarea proiectului. Dupa ce programele sursa au fost redactate, tastate si corectate, se genereaza, prin compilare si editare de legaturi, formatul executabil final, ce se livreaza alaturi de documentatia de utilizare si de exploatare a sistemului,in forma in care sunt colectate, cerinfele fac referire la prelucrari si date in tiune; modelarea conceptuala opereazi insi sub imperativul separdrii si lierii lor independente. Principala ratiune a acestui demers const in obtinerea grad cat mai ridicat de flexibilitate. Cum in practicd s-a constatat ci rarile sunt mult mai frecvent expuse modificarilor decat datele, este firesc ca acestora din urma sa fac, in cea mai mare masura posibila, abstractie de elucrarile la care vor participa. Pentru a nu afecta, pe de alt& parte, capacitatea de a raspunde nevoilor de prelucrare in posibilé schimbare, articularea lor sa corespunda setului de concepte, obiecte, persoane, structuri si fapte care in domeniul respectiv de business. Dar fiecare domeniu foloseste, alaturi in cadru comun, propriii sai termeni, concepte si sintagme profesionale si igureaza o ,.realitate” specifica, in care exista si interactioneaza categorii de jiecte”” particulare. Pentru o banca, spre exemplu, realitatea profesionala este npusa din clienti, conturi, credite, dobanzi, comisioane, care vor apare si in mularea cerintelor sale. intr-o universitate, in schimb, intervin studenti, cadre lactice, discipline, examene etc., iar cerintele vor fi exprimate in raport cu estea. Exist, prin urmare, o diversitate fireasca si obiectiva, la care modelarea Una dintre cele mai larg utilizate tehnici folosite in acest scop, numita ate-relafie sau entitate-asociere (denumire preferata in acest material), recurge 0 abstractizare bazaté pe trei concepte: entitatea, atributul si asocierea. mentele specifice fiecdrui domeniu de activitate sunt astfel figurate sub forma entitati, atribute si asocieri, iar modelul, ca atare, indica datele folosite pentru irezentarea lor in software-ul de aplicatie. Pe de alti parte, nici entitatile si nici cierile nu fac trimitere la vreuna dintre modalitatile tehnice de memorare a elor, dar formeaza un cadru suficient de riguros si coerent pentru a permite rivarea de solutii informatice corecte. Concepte de baza in modelarea entitate-asociere Asa cum s-a mentionat, reprezentarea realititii se face recurgand la trei cepte de bazi: atributul, entitatea si asocierea. Entitatea este expresia unui element, concret sau abstract, existent in domeniul blemei sau activitatii studiate. Spre exemplu, studentul ,Jonescu Vladimir”,88 Dezyoltarea sistemelor informatice de gestiune disciplina ,,Baze de date”, sala ,,2/03” sunt entitati participante 1a activitatea didacticd dintr-o universitate. Caracteristicile sau proprietatile relevante, retinute pentru reprezentarea unei entitati, formeaza atributele acesteia. Rezulta de aici ca entitatea este expresia existentei unui anumit ,,obiect” caracterizat printr-un set de atribute care, din totalitatea caracteristilor sau proprietatilor sale, sunt considerate semnificative pentru domeniul problemei respective. Astfel, pentru persoana mentionata, vor fi retinute ca atribute: numele, prenumele, data nasterii, sexul, liceul absolvit, adresa de domiciliu, adresa in Bucuresti, necesare pentru evidentierea sa ca student, dar vor fi ignorate altele, cum ar fi: inaltimea, greutatea, bolile din copilarie etc. nerelevante aici, dar in mod cert necesare pentru urmarirea sa, spre exemplu, ca pacient al unui medic de familie. Asadar, nu este vizaté o reprezentare exhaustiva a realitatii, ci acea (minima) reflectare care raspunde cerintelor problemei sau activitatii reale avute in vedere. Notatia cu ghilimele, folosita pentru numele gsi prenumele studentului, denumirea disciplinei si numérul salii nu este intamplatoare: ea semnaleaza nevoia identificarii acelui student, acelei discipline si respectiv, a acelei sli, din multimea studentilor universitatii, a disciplinelor predate gi a salilor de activitati didactice. Identificatorii folositi trebuie sa fie atribute ale entitatilor respective (altfel, 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 entitatile de acelasi tip (altfel, din nou, identificarea n-ar mai fi posibila). Printr-o numerotare ingrijita, se poate asigura ca fiecare sala din universitate sa aibé un numéar unic, ceea ce face ca acesta sa fie un identificator valabil. Dar numele si prenumele, luate impreuna, nu pot constitui un identificator valid pentru oricare dintre studentii universitatii, deoarece exista riscul de a regasi doua sau mai multe persoane avand nume si prenume identice. in consecinta, trebuie recurs la un alt atribut sau combinatie de atribute care sd permitd identificarea sigura si, in principiu, pe o durata ,.oricat” de mare, a fiecarui student. Solutia generala aplicata in asemenea cazuri 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, addugandu-se, in consecinta, la atributele retinute pentru acesta. Numarul 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, cat si durata preconizata de utilizare (fiind nevoie, in cazul exemphului nostru, ca identificatorul si opereze nu numai pe perioada studentiei, ci si, pentru un numéar suficient de ani, dupa absolvirea studiilor). Legiturile 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 ca nu. Sunt atribute ale asocierii dintre acestea.larea conceptualii a datelor 89 -Asadar, asocierea nu numai cA reprezinta existenta unei legdturi intre entitati, dar poate avea, in plus, atribute proprii, diferite de ale entitatilor pe care le leaga. Tipuri $i realizari Prezentarea anterioara s-a facut in termeni de elemente individuale: un anumit student, o anumita disciplina, o anumita sala. Modelarea trebuie sa cuprinda si sa dea o reprezentare valabila pentru ansamblul elementelor, respectiv pentru totalitatea studentilor din universitate, pentru totalitatea disciplinelor studiate, pentru totalitatea sdlilor. Se ajunge astfel la conceptele de entitate tip, asociere tip si atribut tip. Realitatea Realizari Entitatea ale entitatii STUDENT Bucuresti 672214338" Popescu Nume rari Prenume Locatitate Nr. telefon Marines Ton Ploiestt 6721325 Figura 5.1 Reprezentarea realit prin entitati si realizari de entitati Entitatea tip reprezinté 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 unci entitati tip este descrisa prin acelasi set de proprietati, acestea find, la nivelul ansamblului, atribute tip. In mod similar, la nivel general, legaturile sunt reprezentate prin asocieri tip. Pentru simplitate, in acest material s-a optat pentru o formulare mai concis, in care referirea la tipuri se face doar prin termenii entitate, atribut si asociere.0 Dezvoltarea sistemelor informatice de gestiune Exprimand conceptualizri de tipuri identificate in spatiul problemei sau activitatii studiate, se recomanda ca denumirile entitatilor, asocierilor si atributelor sa fie formulate la singular. Pentru referirea la un anumit element din aceste ansambluri se utilizeaza termenul de realizare. Continutul particular al atributului aferent unei anumite realizari de entitate sau asociere constituie o valoare a acestuia, iar ansamblul tuturor valorilor acceptabile formeazi domeniul atributului respectiv. Modelul conceptual al datelor se reprezinté grafic. in acest scop, au fost Propuse mai multe conventii de notare, intre care figureazi si cea folosita in materialul de fata’, Atributul Atributul constituie reprezentarea unei proprietiti sau _caracteristici elementare, semnificativa pentru realitatea modelata. Atributul nu poate avea o existenté independenta in model; prezenta sa este intotdeauna legata de o entitate sau asociere, a carei proprietate o exprima. in mod uzual, un atribut trebuie si reprezinte o informatie elementari, nedecompozabila. Aceasta inseamna, spre exemplu, c& un atribut adresd nu este acceptabil si ar trebui sa fie inlocuit cu setul de atribute elementare care o compun. Totusi, din considerente de simplitate a modelului, in situatiile in care nu exist’ cerinte de tratare distincté a partilor componente, atributele compuse pot fi acceptate. Alaturi de atributele elementare, modelul conceptual al datelor poate include si atribute ale cAror valori se obfin prin calcule sau alte tipuri de prelucrari. Acestea sunt denumite atribute derivate si constituie, in esenta, redondante. Varsta, spre exemplu, este un atribut derivat, calculat pe baza datei nasterii si a datei curente. Atributele derivate sunt marcate grafic prin incadrarea intre paranteze drepte. Prezenta lor in model este justificati de considerente de lizibilitate sau coerenta si este, in consecinta, urmarea optiunilor echipei de proiectare. Unicitatea Pentru atribute exist o regula a unicitatii, conform careia un atribut poate apirea o singuri dati in model, indiferent daca este atasat unei entitati sau unei asocieri. O alta regula prevede cA un atribut poate si aiba, in orice moment, o singurd valoare posibila intr-o realizare a entitatii sau asocierii; cu alte cuvinte, in situatiile in care apar atribute multivaloare, cum ar fi, spre exemplu, limbile strdine cunoscute, trebuie aleasi o reprezentare alternativa, in care regula mentionata sa fie respectata. '° Specificd metodei Merise, folosita, printre altele, in lucrarile: (Akoka, J.; Comyn-Wattiau, |., 2001), (Diving, M., 1989) (Diving, M., 1989), (Nanci, D.; Espinasse, B. avec la collaboration de B. Cohen, J.C. Asselbom et H. Heckenroth, 2001), (Bodart, F.; Hainaut, J. L.; Pigneur, Y., 1983).conceptual a datelor 1 ititatea reprezinté un ansamblu de elemente (obiecte) de aceeasi natura, fe sau abstracte, ce pot fi distinse in spatiul problemei sau activitatii studiate. iitate este descrisa printr-un set de atribute. Dintre acestea, un atribut sau un de atribute indeplineste functia de identificator. fitii SOLICITANTI ft ttt pe titi ris ttt tet moueree igura 5.2 Doud moduri diferite de definire a entitatilor pentru aceeasi realitate Orice realizarea a unci entitati trebuie sa fie distinctibila si identificabila in rt cu toate celelalte. Aceasta inseamna ca atributul sau grupul de atribute ce ite drept identificator trebuie si ia valori unice pentru fiecare realizare. STUDENT Nume entitate Identificator, ————+] Numérmatrico! = Nume Prenume : Data nasteri Abribute Sex Adresa Dvarsta] Abribut deritat Ga Figura 5.3 Reprezentarea grafica a unei entitati * Definirea entitatilor este, prin excelent, o problema de proiectare. in primul rand, este necesar si fie alese drept entitati acele ,,obiecte” a cdror perceptie int interes din perspectiva realit&tii studiate. in al doilea rand, aceeasi realitate poate fi modelata in viziuni diferite, care depind de intelegerea, preferintele si erienta proiectantului si care recurg la entitati diferite. Spre exemplu, in cazul unei societati de valori imobiliare, clientii pot fi reprezentati fie printr-o singura92 Dezvoltarea sistemelor informatice de gestiune entitate, fie prin dowd — proprietari si solicitanti — fiecare varianta fiind corecté (figura 5.2). Reprezentarea grafica Grafic, entitatea se reprezinta printr-un dreptunghi, in care sunt notate, in zone distincte, numele entitatii si atributele acesteia. Atributul sau atributele care servesc drept identificator sunt subliniate. Figura 5.3 ilustreaz& aceasta reprezentare. Asocierea Asocierea modeleazi ansamblul legaturilor dintre realizdrile uneia sau mai multor entitati. Numarul de entitati participante la o asociere defineste dimensiunea sau gradul acesteia. Cele mai frecvent intalnite sunt asocierile de grad 2 (binare). Pot exista insa gi asocieri cu gradul unu sau mai mare decat doi, fara nicio limitare. Lista entitatilor participante la o asociere constituie colectia acesteia. Realizarea unei asocieri poate exista numai in prezenfa cate unei realizari ale fiecareia dintre entitatile din colectia sa. Reciproca nu este adevarat&: pot exista realizari de entitati care si nu participe la nicio realizare a asocierii din a c&rei colectie fac parte. Nrfacture Hume Data facturii Prenume Scadenta AATESA: ‘Suma de plata Cardinait anita fatea minimaid, rest 1, Sentra ABON AT Cardinaiitatea minimala, maxinala, tentra FACTURA Figura 5.4 Reprezentarea graficd a unei asocieri Cardinalitati minimale si maximale Modul de participare a entitatilor la asociere este definit prin cardinalitate. Pentru o anumita entitate, cardinalitatea precizeaz4, prin doua valori, numaruljodelarea conceptual a datelor 93 im, respectiv maxim de realizari ale asocierii la care poate participa o realizare ‘entitatii respective. Valorile uzuale sunt 0 sau / pentru cardinalitatile minimale, pectiv J sau n ("n" reprezentand orice valoare mai mare decat unu) pentru inalitatile maximale. Cardinalitatea minimala cu valoare zero pentru o anumita entitate indica faptul pot exista realizari ale acesteia care nu participa la asociere; cu alte cuvinte, articiparea este opfionald. Valoarea unu a cardinalitatii minimale inseamna cd orice realizare a entitatii spective trebuie sa participe la cel putin o realizare a asocierii; participarea este, acest caz, obligatorie. Reprezentarea grafica Asocierea se reprezinté grafic printr-un oval, atasat prin linii continue la titétile a caror legaturi o exprima. in interiorul acestuia sunt mentionate lumirea asocierii si eventualele atribute proprii. Participarea fiecdrei entitati din lectie este adnotata cu valorile aferente celor doua cardinalitati ale sale. Figura 5.4 prezinta, pentru exemplificare, asocierea dintre facturile emise de o ‘ocietate 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 mai multe facturi (0,n); — factura (realizare a entitatii FACTURA) este adresata intotdeauna unui singur abonat (1,1). Mai multe asocieri, o singura colecti in modelarea conceptuala, asocierea exprima existenta unei legaturi cu o semnificatie anume in spatiul problemei sau activitatii reflectate. Consecinta imediata este aceea ca intre aceleasi entitati pot exista mai multe asocieri, avand fiecare propriile semnificatii, cardinalitati si, daca este cazul, atribute.Dezvoltaren sistemelor informatice de gestiune Figura 5.5 Interpretarea cardinalit SBONAT Cod client Hefacturs Nome Data facturii Frenume Scadenta Adresa Suma de plata tilor in reprezentarea asocierii anterioare Spre exemplu, angajatii unei firme Jucreazd fiecare intr-un anumit departament, iar unii dintre acestia conduc departementele in care lucreaza. intre aceleasi entitat (figura 5.6): i — ANGAJAT si DEPARTAMENT - exist deci doua asocieri LUCREAZA — un angajat lucreazi inu-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,1); un departament este condus de un angajat (cardinalitate /, 1).a datelor DEPARTAMENT Cod departament Denumire departament Amplasare —s Contabilitate | Ta —— SSS=4 Marketing > congue Figura 5.6 Doud asocieri diferite intre aceleasi entitdti Asocieri cu atribute O asociere poate avea propriile atribute, diferite de cele ale entitatilor pe care le leagi. Figura 5.7 prezinté un exemplu de acest gen, bazat pe structura unei acturi. Factura si produsul constituie entitati. O factura include mai multe produse: ‘in consecintd, se stabilesc legaturi intre facturd si fiecare dintre produsele pe care le iprinde, iar cantitatea facturaté este atributul acestei legaturi. Semnificatia ardinalitatilor este urmatoarea: o factura contine unul sau mai multe produse (/,n); “un produs poate s& nu figureze in nicio factura, dupa cum poate aparea in oricat de multe facturi (0,7).96 Dezvoltarea sistemelor informatice de gestiune Un alt exemplu este prezentat in figura 5.8. Fiecare dintre marfurile detinute de o firma poate fi stocata in mai multe depozite diferite i in fiecare depozit se pot pastra mai multe marfuri (cardinalitati 0,7 pentru ambele entitati). Cantitatea aflata intr-un anumit depozit (stocul curent) este un atribut al asocierii STOCARE (si nu al mrfii sau al depozitului). Stocul total al marfii este un atribut derivat, calculat prin insumarea stocurilor curente din toate depozitele in care se gaseste acesta. Asocieri n-are in toate exemplele anterioare, la asocieri au participat doua enti tip diferite. Aceasta nu este ins o limitare. O asociere poate cuprinde oricat de multe entitati atunci cand reprezentarea domeniului problemei impune asa ceva. Interpretarea cardinalitatilor minimale poate ridica, in unele situatii, dificultati, daca se ignora precizarea facuta anterior, conform careia acestea servesc pentru a indica optionalitatea sau obligativitatea participarii realizarilor entit? respectiva. departamentului in asocierea lucrea: la asocierea in consecint&, in exemplul de mai sus, cardinalitatea zero atribuita nu trebuie interpretaté in sensul unui departament fara angajati, ci in acela al acceptarii (de realizdri) de departamente pentru care inc& nu sunt precizati angajafii. Datorité acestei particularitati, unii autori recomanda, in situatii asemanatoare, notarea cardinalitatii minimale cu caracterul ,,?”. in cazurile in care, din cerinte, rezulta obligativitatea participarii, ca in exemplul privitor la facturi, cardinalitatea minimala trebuie sa primeasca valoarea 1lodelarea conceptuala a datelor 97 Documentul de hértie... Factura nr, 120004 din 12.98.2014 Denumire UM Pret Cantitate Valoare produs unitar facturaté produs FACTURS Nrfactura Den produs Cantitate facturata Data facturé uM [Naloare! [Total factura] Pretunitar .. gi continutul documentului reprezentat sub forma de realizari de entitati si asocieri Hrfact: 142560 Cod produs: 3135 Nr fact: 120004 gq 7 . Nrfact: 18221 A | Godprodus: 186? Pe 2 ‘Cod produs: 1729 Lf cantiaces / Data: 11.8,2014 / = od produs: 2214 9 Cod produs: 2105 Den produs: Brénzi vaci Cantfact: 1,5 UM: kg Pretunitar: 14,50 a neo Figura 5.7 O facturd si reprezentarea sa entitate-asociere98 Dezvoltarea sistemelor informatice de gestiune DEPOZIT Cod marta e ‘God deposit Denumire Denumire depocit Unitate masura Adresa depot IStoc total] Figura 5.8 O asociere cu airibute proprii Sa consideram, pentru exemplificare, cazul unui service auto. Pentru fiecare vehicul aflat in reparatii sau revizie, se deschide un ordin de reparatie. in cadrul 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 caruia se executd (figura 5.9). AUTOVEHICUL Heinmat hrs Marc: Hodel Km parcursi i ORDIM REPARATIE Hrerdin Data deschideri Data inchideni Defectiunireciamate ‘Cod operatic Deseriere operatic Durata medie ANGAJAT Hrintern, Hume Prenume Figura 5.9 Asocierea ternardé LUCRARE reprezinté operatiile inscrise in ordinul de reparatie de céitre mecanicii care le-au efectuat. Interpretarea cardinalitatilor se face prin prisma participarii realizarilor de entitati la asociere: pentru un ordin de reparatii se pot executa mai multe operatii delarea conceptuala a datelor 99, acelasi angajat; acelasi angajat poate executa aceeasi operatie pentru mai Ite ordine de reparatii diferite; aceeasi operatie (dintre cele prevazute in lator) poate fi executata de catre mai multi angajati pentru acelasi ordin de tii. Aceasta denota cardinalitate maximala n pentru toate cele trei entitati: un ordin de reparatie contine cel putin o operatic executaté de un angajat, inalitatea sa minimala este /. Schema contine si legatura dintre ordinul de reparatie si vehicul. inalitatea J-n atagaté entitatii AUTOVEHICUL indica faptul ca service-ul istreazi numai acele vehicule la care s-au facut reparatii sau intervent iciparea find obligatorie, orice vehicul trebuie s& fie legat de cel putin un lin de reparatii. Asocieri reflexive Alaturi de asocierile binare, ternare, ... n-are, exist si asocieri de gradul 1, leaga intre ele realizari ale aceleiasi entitati, denumite asocieri reflexive. Spre lu, asocierea care reprezinta casatoria leaga intre ele doua realizari diferite entititii PERSOANA (figura 5.10). frrtit =3- =- =™- = =. == Cod numericpersonal Hume Prenume Data nasteri Sex Dimensiane = 1 wrest = PERSCANA PERSCANA Figura 5.10 Reprezentarea ciisdtoriei printr-o asociere reflexive100 Dezyoltarea sistemelor informatice de gestiune Pentru a putea interpreta o asociere reflexiva, este necesara specificarea rolului jucat de catre fiecare realizare, deoarece acestea apartin aceleiasi entitati. in exemplul referitor la casatorie, cele doua roluri sunt sof si sofie. Reprezentarea configuratiei formatiilor de studiu (serie, grupa) in care sunt incadrati studentii poate fi realizaté, de asemenea, printr-o asociere reflexiva, asa cum se vede in figura urmatoare. cuprinsain compusa din STRUCTURSRE Figura 5.11 Formatiile de studiu reprezentate printr-o asociere reflexiva Seriile si grupele sunt realizari ale entitatii FORMATIE_STUDIU. Rolurile jucate in asociere, a caror specificare este si aici indispensabila pentru interpretarea schemei, introduc gi diferentieri privitoare la tipul formatiilor: in limita enumerarii 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 valor generice cu marimile concrete acceptate: o formatie de studiu este compusa din minim 2 si maxim 5 alte formatii (grupe) si este, pe de alt parte, cuprinsa in minim zero (daca este o serie) si maxim o formatie (daca este o grupa in serie). in aceste conditii, componenta fiecarei grupe se reprezint& 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area conceptualii a datelor 101 disciplinele de limbi straine), cardinalitatea studentului in asocierea -ARTIZARE devine I,n. STUDENT Hematricol Nume Prenume Data nasterii Sex tn REPARTIZARE cuprinsain compusa din STRUCTURSRE Figura 5.12 Gruparea studengilor in formariile de studi Identificarea asocierilor Realizarile oricarei asocieri trebuie sa fi identificabile. Cum 0 asociere nu are identificator propriu, regula precedenta se traduce in felul urmator: intre aceleasi realizari ale entitétilor din colectia unei asocieri, nu poate exista decdt o singura realizare a asocierii. Figura 5.13 prezint, 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 discipli inlaturarea acestei deficiente se poate face fie prin transformarea asocierii EXAMEN in entitate, fie prin introducerea unei entititi 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 aparut asocieri suplimentare, necesare conectarii noii entitati cu celelalte doud existente. Entitatea EXAMEN are un identificator102 Dezvoltarea sistemelor informatice de gestiune propriu si pastreaz4 doar atributul Data examen, iar Nota devine atribut al asocierii PARTICIPARE. matricol DISCIPLINE, Homi Prenume n Data nasterii Tip disciplina Sex Hr puncte credit - Figura 5.13 Reprezentarea participarii studentilor la examene Tematrico! DISCIPLINA Hume Prenume Den discipling Data nasterii Tip discipling Sex Nrpuncte credit EXAMEN PROGRAMARI Id examen fata examen Figura 5.14 Modelarea corectét a participarii studentilor la examene in virtutea aceleiasi reguli de identificabilitate, 0 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 snaturala”), 5.2 Reprezentarea regulilor de gestiune prin restrictii de integritate O buna parte a cerintelor functionale const din reguli de gestiune. Asa cum indicé numele lor, acestea sunt reguli specifice activitatii de business reflectate, fixate prin legislatie sau definite de cdtre conducerea organizatiei. Unele suntProiectarea bazei de date Scopul proiectarii const& in definirea bazei de date si ansamblului de Programe, executabile pe platforma si in configuratia convenite, necesare atisfacerii cerinelor cuprinse in specificatia sistemului. Din perspectiva rationamentelor efectuate, definirea are loc progresiv, in stadiile de proiectare general, cAnd se formuleaza o solutie sintetica, de ansamblu de proiectare tehnica, in care se fac detalierile si ajustarile corespunzatoare platformei avute in vedere. Proiectarea bazei de date, care face obiectul prezentului capitol, urmeazai acest mers progresiv, prin elaborarea unei structuri de baze de date care si corespunda eat mai fidel modelului conceptual al datelor, urmati de o ajustare a acesteia la acteristicile prelucrarilor presupuse de executia lucrarilor asumate de software- il de aplicatie. Structura obtinut este detaliati si adaptata apoi la caracteristicile latformei, care aici vizeazi esentialmente SGBD-ul folosit si suportul pe care-I propune acesta. 1.1 Modelarea logica a datelor Modelarea logica a datelor urmareste si dea o solutie de reprezentare nformatica a modelului conceptual al datelor. in scopul mentinerii unui grad cat ridicat de flexibilitate, se vizeazé un tip de solutie, ce este detaliati si itivataé apoi, pe nivelul fizic, in configurarea adecvati mediului concret de stionare al datelor adoptat. Din perspectiva tipurilor de solutii, exist practic doua alternative principale: siere sau baze de date. Pentru acestea din urmi, este luat in considerare modelul ional, avnd in vedere dominatia sa pe piata. In conformitate cu aceste optiuni, ate afirma ca modelarea logica a datelor are drept scop definirea bazei de date ationale aferente modelului conceptual al datelor. cepte de baza ale modelulul relational _ Modelul relational recurge la o structura de reprezentare plata, in care datele at stocate in relatii sau tabele distincte. Orice tabel sau relatie reuneste un blu de tupluri sau inregistrari, compuse fiecare din setul de valori ale unui bine definit si invariabil pentru tabelul respectiv, de atribute sau campuri, ce stituie structura acestuia. Valorile luate de fiecare atribut apartin unui anumit domeniu. Spre exemplu, nasterii este un atribut ce poate primi, drept valori, doar date calendaristice. in si situatie se afla si data cdsdtoriei. in consecinta, un atribut este o162 Dezvoltarea sistemelor informatice de gestiune submultime a unui domeniu caruia i s-a atribuit un nume. Acest nume exprima, in mod normal, rolul sau semnificatia atribuite elementelor domeniului respectiv, Pentru orice tuplu, fiecare atribut poate primi numai acele valori care sunt considerate valide in conformitate cu restricfiile de integritate care-| vizeaza. Structura, definita cel putin prin numele atributelor si domeniul fiecdruia, ramane, in mod normal, invariabila. Modificarea sa, prin adaugare, eliminare, inlocuire de atribute sau schimbare a domeniului, constituie ceea ce se numeste 0 restructurare si implica rememorarea tuplurilor existente, cu adaptarea la noile reguli de structura. Cum aceasta poate impune prelucrari complicate, uneori cu imposibilitatea recuperdrii tuturor datelor din vechea structura, este de dorit si se efectueze cat mai rar cu putinta, ceea ce depinde de o buna proiectare. Cod numeric personal Data casatoriei 1120212411 | Ionescu 18-6/1984 2670310485711] Popescu Valentina 15/10/1987 1820417251744 Georgescu. a 1/4/1982 Tuplu sauinregistrare Figura 7.1 llustrarea cdtorva concepte ale modelului relational Modificarea tuplurilor este, prin contrast, cat se poate de fireasc si are loc prin actualizare, adica prin adaugare sau stergere de tupluri sau prin modificarea continutului acestora. Termenii de tabel, cdmp si inregistrare, asociati relatici, atributului si respectiv tuplului, sunt cei folositi in implementari si vor fi preferati in continuare. Cheia primaré este un camp sau grup de cdmpuri din structura tabelului, ales pentru a identifica fiecare inregistrare. Cheia primara suport o restrictie specific relationala: ea trebuie s4 aib& intotdeauna valori unice si nenule pentru fiecare inregistrare. in exemplul mentionat anterior, cémpul "cod numeric personal" indeplineste toate conditiile pentru a fi definit drept cheie primara. in unele situatii, structura tabelului poate confine mai multe cémpuri sau grupuri de cAmpuri care ar putea indeplini aceasté functie. Acestea sunt denumite chei candidat, posibile alternative la cheia primar aleasa. Atunci cand este necesara stabilirea de legaturi intre inregistrari aflate in acelasi tabel sau in tabele diferite, modelul relational preconizeaz4 introducerea unui cémp sau grup de cdmpuri care s& contina, in fiecare inregistrare, valoarea prin care se poate identifica inregistrarea cu care se face legatura. Aceasta este 0roiectarea bazei de date 163 legitura bazat pe continut (legatura logica). Valoarea plasaté intr-un asemenea camp, daca nu este nula, trebuie sa aiba un corespondent valid printre inregistrarile care se face legatura; cu alte cuvinte, valorii sale sA i se poata atasa intotdeauna 0 inregistrare existenta in tabelul vizat. Aceasta conditie generala poarta numele d. restrictie de integritate referentiala. Atunci cand pentru identificarea inregist cu care se face legatura se foloseste cheia primara, cémpul sau grupul de cAmpuri din tabelul legat folosite in acest scop formeaza o cheie externd. Cheia extema este deci un camp sau grup de cémpuri dintr-un tabel, care joaca rolul de cheie primara intr-un alt tabel. Cheia externa este supusi restrictici de integritate referentiala. Reprezentarea relationala a entitatilor si asocierilor Elaborarea modelului logic const, in prima faz, in reprezentarea entitatilor si asocierilor care compun modelul conceptual in termenii specifici modelului relational, adica table, campuri, chei primare si chei externe. Notatia folosit aici se bazeaz pe urmiatoarele conventii: ¢ tabelul este indicat prin nume, urmat de lista de cmpuri incadrata de paranteze rotunde; ¢ cheile primare sunt subliniate cu linie continua, iar cheile externe, cu linie punctata. +--— entitatea. Cod client Nume : Prenume gischema tabelului corespunzator Adresa ABONATI (Cod ckent, Nume, Prenume, Adresa} Figura 7.2 Reprezentarea unei entitati in modelul logic 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 cémpurile tabelului; ¢ identificatorul entitatii devine cheia primara a tabelului.164 Dezvoltarea sistemelor informatice de gestiun Reprezentarea asocierilor Reprezentarea asocierilor se face diferentiat, in functie de grad si cardinalitati. a. Asocieri binare cu toate cardinalitatile maximale "n" in acest caz, asocierea se reprezinta printr-un tabel distinct, in care: © identificatorii entititilor participante formeaza, impreuna, cheia primard a tabelului; . © identificatorul fiec4rei entitati participante devine cheie externa; * — eventualele atribute ale asocierii devin cdmpuri ale tabelului. Figura 7.3. prezinta un exemplu de acest tip, in care asocierea PRODUS_FACTURAT este reprezentati printr-un tabel distinct, avand cheia primara compusa din campurile CodProdus si NrFactura. in acelasi timp, CodProdus si NrFactura sunt, fiecare, cheie externa in raport cu tabelul in care indeplinese functia de cheie primara. Dupa cum se observa, atributele derivate nu fac parte din tabele (nu se memoreaza). Cod prods _ Den produs uM Pret unitar FACTURA Urfacturd Dats factura Total factura] FRODUS_FACTURS Cantitate facturata — . [Valoare] Cy _ PRODUSE_FACTURATE/‘Cod odus, Ni: ‘a, Cantitate facturata} PRODUSE:Cod produs, Den produs, UM, Pret unitar} FACTURINt factura, Data factura) Figura 7.3 Reprezentarea unei asocieri binare cu cardinalitati maximale "n" Regula mentionata aici este aplicabila in toate situatiile. Este de notat insa ca, in cazurile particulare prezentate in continuare, exista solutii de reprezentare mai economice, in care nu mai sunt necesare tabele distincte pentru fiecare asociere.‘Proiectarea bazei de date 165 b. Asocieri binare cu una dintre cardinalitatile maximale "1" in acest caz, asocierea se reprezinta in tabelul corespunzator entitatii cu cardinalitatea maximala "/", in felul urmator: © identificatorul celeilalte entitati participante devine cheie externa in tabelul respectiv; * eventualele atribute ale asocierii se adaugi la cimpurile deja existente ale tabelului”, FACTURA Cod client . Nefactura Hume: Data facturii Prenume Scadenta Adress Suma de plata ABONATI (Cod client, Nume, Prenume, Adresa’ Figura 7.4 Reprezentarea unei asocieri binare cu o cardinalitate maximald "1" Pentru exemplificare, in figura 7.4 este ilustrat un asemenea caz. Asocierea dintre factura gi abonatul cruia fi este adresata, in care cardinalitatea maximala corespunzatoare entitatii Factura are valoarea "1", poate fi reprezentaté prin includerea codului clientului drept cheie externa in tabelul FACTURI. O alta solutie, bazata pe aplicarea regulii anterioare, consta in reprezentarea asocierii printr-un tabel distinct in care identificatorii celor dou entitati compun cheia primara si constituie, fiecare, cheie externa in raport cu tabelul la care se refera (figura 7.5). Aceasta variant are ins’ dezavantajul de a adduga un tabel suplimentar si, inc mai important, pe acela de a mari numirul de compuneri (join) necesare intre tabele. Ea se poate dovedi avantajoasi doar atunci cand cardinalitatea minimald este zero si frecventa aparitiei sale in ansamblul inregistrarilor este mare. " Asa cum s-a mentionat deja, o asemenea asociere nu ar trebui sa aiba atribute proprii.166 Dezvoltarea sistemelor informatice de gestiune FACTURA Codclient — | Nefactura Nume Data facturii Prenume Scadenta sdresa Suma de plata FACTURI ‘Nx factura, Data factur:, Scadenta, Suma de plata} ABONATI ‘Cod cient, Nume, Prenume, Adresa} Figura 7.5 O alta reprezentare relationald a schemei conceptuale anterioare . Asocieri binare cu toate cardinalitatile maximale in acest caz, pot fi avute in vedere trei tipuri de solutii, dintre care doua similare celor prezentate anterior. Prima modalitatea de reprezentare consta in inserarea identificatorului uneia dintre entitati in tabelul aferent celeilalte, in calitate de cheie externa. Cum situatia este aici simetrica, alegerea tabelului in care va fi inserata cheia externa depinde, in plan general, de valoarea cardinalitatilor minimale si de frecventa aparitiei acestora. Astfel, dacd doar una dintre entitati are cardinalitatea minimala 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, abonatul achité suma mentionata in aceasta, eventual cu penalizari. Exista deci o asociere intre factura gi incasarea sa, in care cardinalitatile maximale sunt ambele de valoare "/", cea minimala fiind ins "zero" pentru factura (deoarece pe o perioada mai mare sau mai mica, plata pentru factura emis inca nu a aparut). in consecinta, solutia relational preferabila este aceea de a insera cheia externa, respectiv numdrul facturii, in tabelul INCASARI (figura 7.6). Aceeasi rezolvare se poate da si atunci cand ambele cardinalitati minimale sunt "zero", dar frecventa aparitiei uneia dintre ele este mult mai mare decat a celeilalte: prin asimilare cu cazul precedent, identificatorul entitatii aferente acesteia este cel ce va aparea drept cheie externa. A doua modalitate consta in reprezentarea asocierii printr-un tabel distinct. in termeni generali, 0 asemenea rezolvare este adecvata cazurilor in care ambele cardinalitéti minimale au valoarea "zero" si aceasta valoare apare frecvent in ansamblul inregistrarilor. in felul acesta, se vor reprezenta, in tabelul respectiv,roiectarea bazei de date 167 i cheile inregistrarilor aflate efectiv in legatura, evitand plasarea unui camp ie externa in unul sau altul dintre tabelele asociate, camp ce va fi, pentru cele i multe dintre inregistrari, neutilizat. FACTURA, INCASARE hirfacturs = = Igincasare Data facturi: Scadenta Date platir Mod plats Unitate Sums platits Suma de plata [Penalizere! INCASARI Idincasare, Data plat, Mod plat, Unitate, Suma plitt’, Nx FACTUREX: factura, Data facta, Scadenta, Suma de plati Figura 7.6 Reprezentarea relationald a unei asocieri binare cu ambele cardinalitati maximale de valoare "1" LIVRARE Hrdoc exp. Data livearit Costtransport 2-2 On | Hreatalog ---4 Denumire 1 UM + Pretunitar | Cond are, ’ & COMENZI ‘Xr comandi, Data comenzii, Nx doc exp, Data kitriti, Cost trasport} MARFURI.. MF_COMANDATE... Figura 7.7 Reprezentarea unei asocieri binare avand si cardinalitatile minimale cu valoarea "1"168 Dezvoltarea sistemelor informatice de gestiune Cea de-a treia modalitate consta in comasarea celor doua entitati intr-un singur tabel. In termeni generali, aplicarea sa este recomandabili atunci cand cardinalitatile minimale au, de ambele parti, valoarea "/". Spre exemplu, intr-o aplicatie de comert electronic de tipul B to C (adresat consumatorului individual), o comanda va fi acceptati numai daca poate fi imediat onorata (sau mai precis, oferta instantanee va cuprinde numai marfuri sau servicii imediat si nemijlocit livrabile). Prin urmare, intre comanda primita si livrarea corespunzatoare va exista 0 asociere avand atat cardinalitatile minimale, cat si cele maximale de valoare "/". Traducerea sa in relational se poate face printr-un singur tabel, ceea ce va mentine nealterata reprezentarea corecta a realitatii, eliminand, in acelasi timp, operatia costisitoare de compunere (figura 7.7). d. Asocieri reflexive Reprezentarea relational a asocierilor reflexive se face prin aplicarea regulilor referitoare la asocierile binare, in varianta corespunzatoare combinatici de cardinalitati intalnite. ae IP solie = = — iume Prenume Data nasterii Sex ~ e CASATORII‘CNP sot, CNP sotie, Data cisdtore!} PERSOANE‘CNP, Nume, Prenume, Data nastexii, Sex: Figura 7.8 Reprezentarea unei asocieri reflexive cu toate cardinalitatile maximale "1" Figura 7.8 prezinté un exemplu de asociere reflexiva in care cardinalitatile sunt "0,1" de ambele parti. Schema referindu-se la angajatii unei societati, cazurile in care atat sotul, cat si sotia se numara printre acestia sunt destul de rare. Frecventa de aparitie a cardinalitatii minimale zero fiind deci mare, cea mai bunaroiectarea bazei de date 169 entare relationalé a asocierii este printr-un tabel distinct. Aceasta preia identificatorii celor doua entitati participante (al cAror nume a fost modificat prin ompletare cu rolul jucat, atat pentru a evita repetarea cat si, cel putin la fel de important, pentru a conferi lizibilitate structurii) si atributul propriu asocierii, respectiv data cdsdtoriei. Un alt exemplu, de aceasta dati de reprezentare a unei asocieri reflexive in care doar una dintre cardinalitatile maximale are valoarea "/", apare in figura 7.9. Situatia redata vizeazi gruparea marfurilor (articolelor) dintr-un magazin, intr-o structura de clasificare ierarhizati pe mai multe nivele, de genul: alimente Proaspete - fructe, legume, carne - peste, pasdre, pore $.a.m.d. Solutia adoptata este cea care recurge la inserarea, in tabelul corespunzator entitatii cu cardinalitatea maximala "/”, a identificatorului celeilalte entitati in calitate de cheie externa. Cum aici este vorba de o singura entitate, in tabelul GRUPE, identificatorul Cod grupad ar trebui s apara de doud ori, atat drept cheie primara, cat si drept cheie externa. Cum prezenta a dou& campuri cu acelasi nume nu este permisa, denumirea caémpului cheie externa, care oricum trebuia modificaté, a fost completata cu numele de rol jucat in asociere, devenind cod grupd superioard, ceea ce are avantajul de a o face mai lizibila si, nu mai putin, de a indica legatura cu modelul conceptual. enumiré artical Unitate masura GRUPE ‘Cod grupa, Denumire grapi, Cod. ARTICOLE ‘Cod base, Denumize articol, Unitate vanzare, Pret vanzare, Stoc, Cod; Figura 7.9 Reprezentarea unei asocieri reflexive cu una din cardinalitatile maximale de valoare "I"170 Dezvoltarea sistemelor informatice de gestiune Figura 7.10 ilustreaz4 un alt caz, bazat pe modelarea structurii de fabricatie a produselor unei unitati industriale. Entitatea ARTICOL are aici caracter generic, desemnand orice element material care participa, se consum sau rezulté din procesele de fabricatie. Prin urmare, un articol se obsine din zero (daca este un bun achizitionat) sau mai multe articole (daca este semifabricat sau produs final). in acelasi timp, orice articol poate fi intrebuingat la fabricatia altor articole sau, dacd este un produs final sau secundar, a niciunuia. FABRICATIE Norma consum ARTICOL obtinut intrebuintat f Denumire artical Pret standard y uM ' t ARTICOLE (Cod articol, Denumire articol, UM, Pret standard) Figura 7.10 Reprezentarea unei asocieri binare cu ambele cardinalitati maximale de valoare "n"" Asocierea reflexivd care exprima aceste legaturi, avand ambele cardinalitati maximale cu valoarea "n", nu poate fi reprezentata 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 — gi atributul asocierii, respectiv norma de consum prevazuta in documentatia de fabricatie. e. Asocierin-are Asocierile la care participa trei sau mai multe entita{i se reprezinta printr-un tabel distinct, in care: ¢ identificatorii entitatilor participante cu cardinalitatea maximala "n" formeaza, impreuni, cheia primard a tabelului; e identificatorul fiecarei entitati participante devine cheie externa; ¢ eventualele atribute ale asocierii devin atribute ale tabelului.Proiectarea bazei de date 171 Figura 7.11 reia exemplul de asociere ternara inclus in capitolul cinei $i prezinta structura tabelului LUCRARI, care-i da expresie relafionala. AUTOVEHICUL inmatriculare Nrseriegasiv Marcé Model Km parcursi OPERATIE Hrordin — — c beordin : Cod operatic Data deschidert, Descriere operatic Data inchideni Duratamedie © Defectiunireciambte Hruntern Meme Prenume LUCRARI (Nr ordin, Nr intem, Cod operatie, Data executiel) ANGAJATI (Nrintem, Nume, Prenume) OPERATI (Cod operatie, Descriere operatic, Durata medie) AUTOVEHICULE (Xt inmatriculare, Nr serie sasiu, Marca, Model, Km parcursi) Figura 7.11 Reprezentarea unei asocieri n-are Reprezentarea subtipurilor de entitati Reprezentarea relationala a subtipurilor de entitati trebuie sa asigure: © exprimarea legaturilor existente intre subtipuri si tip, in sensul in care fiecare realizare a subtipurilor trebuie sa fie, simultan, si 0 realizare a tipului;172 Dezvoltarea sistemelor informatice de gestiune © simularea mecanismului mostenirii, pentru care modelul relational nu ofera o solutie dedicata. Solutionarea primului aspect se face considerand ca intre tip si subtipuri exist’ asocieri binare cu cardinalitati 0,1 — 1,1 si aplicand regula de reprezentare specifica acestui caz, Pentru al doilea aspect, exista mai multe solutii posibile, diferentiate in functie de modul de constituire a subtipurilor, prin specializare sau prin generalizare. PERSOANA CHP Nume Prenume Sex Data nasteri Tip Nrmatrico! An studi Nrpcte credit 1 STUDENTI CNP, Nr maticol, An stud, Ne pcte credit) y CADRE_DIDACTICE’€NP, Grad didactic, Vechime invati: PERSOANE CNP, Nume, Prenume, Sex, Data nastet!, Tip) Figura 7.12 Reprezentarea tipului si subtipurilor prin tabele distincte Specializarea O prima solutie consta in utilizarea de tabele distincte pentru reprezentarea tipului si a subtipurilor. Identificatorul tipului migreaza in toate tabelele si devine cheie primara atat pentru tip, cat si pentru subtipuri (figura 7.12). Urmatoarele doua solutii se bazeaza pe aplatizarea relatiei, fie "in sus", fie "in jos". in primul dintre cazuri, se ajunge la un tabel in care sunt memorate atat atributele tipului, cat si cele ale tuturor subtipurilor. Avantajul acestei variante consta in existenta unui singur tabel; spatiul de memorare este insa irosit partial,Proiectarea bazei de date 173 prin faptul ca, in functie de subtipul caruia ii apartine o inregistrare sau alta, anumite cémpuri vor fi inevitabil neutilizate. De asemenea este indispensabila introducerea unor restrictii de integritate care s4 verifice completarea si, respectiv, necompletarea campurilor in functie de subtipul concret reprezentat. Specializarea ca atare este exprimata prin introducerea unui atribut suplimentar care s& indice subtipul c&ruia ii apartine fiecare inregistrare, la care, de altfel, va face referinta si restrictia de integritate mentionata Schema relationala aferenta acestui gen de solutie, pentru modelul conceptual descris in figura 7.12, este urmatoarea: PERSOANE (CNP. Nume, Prenume, Sex, Data nasterii, Tip. ‘Nr matricol, An studii, Nr pete credit. Grad didactic, Vechime invatam) Prin aplatizarea "in jos", se creeaz tabele distincte pentru fiecare subtip, iar atributele tipului "coboara" si se adauga in fiecare dintre acestea. fn aceasta modalitate de reprezentare, schema relationala pentru acelasi model conceptual este urmatoarea: STUDENTI (CNP. Nume, Prenume, Sex. Data nasterii. Nr matricol, An studii, Nr pcte credit) CADRE_DIDACTICE (CNP, Nume, Prenume, Sex, Data nasterii, Grad didactic, Vechime invatam) 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 fiecarui subtip. Figura 7.13 prezinté un exemplu de acest gen, in care Nr tert, cheia primara a tipului, apare in postura de cheie externa in tabelele aferente subtipurilor. Reprezentarea evolutiei in timp Expresia relationala a situatiilor de acest gen urmeaza regulile generale, cu exceptia faptului ca entitatile prin care se reprezinti timpul (date, perioade) nu apar ca tabele distincte. in consecint&, atributele entit tilor de acest gen participa la formarea cheilor primare, dar nu pot constitui chei externe.Dezvoltarea sistemelor informatice de gestiune Exemplul din figura 7.14 ilustreazA acest caz: modelul logic este compus doar din doud tabele, corespunzitoare entitatii VALUTA gi asocierii COTATIE; entitatea ZI. COTATIE nu are © reprezentare explicita; e cheia primara a tabelului COTATI este compusa din identificatorii celor doua entitati participante — Cod valutd si Data; ¢ in absenta unui tabel distinct pentru timp, numai codul valutei poate fi cheie externa. Nrtert Denumire Adresa CLIENT Condit vancare 72 CLIENTI-Xr client, Categorie client, Conditi vanzare, > FURNIZORUEN: furnizor, Durata livrare, Nr te: TERT Xr text, Denumire, Adresa} Figura 7.13 Reprezentarea tipului i subtipurilor obtinute prin generalizare Denumire valuta VALUTE ‘CodValuti, DenumireValuti Figura 7.14 Reprezentarea relationald a cotatiilor valutare zilnicejectarea bazei de date 175 Pentru entitatile ce exprima perioade, in compunerea cheii primare pot fi tinute fie ambele momente care o delimiteaza, fie, in situatiile in care apar itervale in curs (inca neincheiate), numai momentul de inceput, pentru a permite cel final sé ramana nul. Cod anaajat Nume Prenume Adresa Studi COMPARTIMENT Cod compartiment Denumire compartment PERIOADA Functia Salariu! Data inceperii (la! Data terminariittay an ; : N v INCADRARI ‘Cod angajat,Data inceperi, ,Data termina: LOCURI_LMUNCA Cod a Data terminar} ANGAJATI‘Cod angajat, Nume, Prenume, Adresa, Studi? COMPARTIMENTE Cod compastiment, Denuméze compartment) , Functia, Salarul: Figura 7.15 Reprezentarea locurilor de muncé, functiilor si salariilor anagajatilor, trecute si prezente Reprezentarea evolutiei in timp a locurilor de munca, functiilor si salariilor angajatilor (figura 7.15) se incadreaza in acest caz: pentru cele din trecut se cunose atat datele de inceput, cat si cele de sfarsit, in timp ce pentru cele prezente, doar data de incepere. In consecinta, cheile primare ale tabelelor care le memoreaza — LOCURI_MUNCA gi INCADRARI ~ includ numai momentul de inceput, care este cunoscut in toate cazurile. Data termindrii este de asemenea prezenta in cele doua tabele, dar nu mai face parte din cheia primara.176 Dezvoltarea sistemelor informatice de gestiune Identificatorii relativi Identificatorii relativi constituie unul dintre tipurile de restrictie de integritate structurala si desemneaza situatiile in care pentru identificarea unei entitati trebuie sA se recurga, alaturi de atribute proprii, la rolul jucat de o alta entitate intr-o asociere la care participa impreuna. Relational, reprezentarea se face incorporand in cheia primara a tabelului corespunzator enti restrictionate, identificatorul celeilalte entitati, prin care, in mod normal, se exprima asocierea: conform regulii generale, acesta devine si cheie externa. ATELIER i: PROIECT, Neproiect Termen PROIECTE ‘Neatelier, Nr project, Texmen} ATELIERE ‘Xr atelier, Adresa} Figura 7.16 Reprezentarea relationalé a cazurilor de identificatori relativi Figura 7.16 ilustreazi aceasté rezolvare: tabelul PROJECTE are o cheie primara compusa, format din campurile Nr proiect si Nr atelier. Acesta din urma 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. Tabelele CAMERE, TIPURI_CAMERE, CLIENTI, REZERVARI, CAZARI, NOTE_CHELTUIELI, FACTURI, INCASARI si PERIOADE-TARIFARE corespund entitatilor din modelul conceptual (reluat, pentru a facilita urmarirea procesului, in figura 7.17). CLASIF! 1CARI_CAMERE, CAMERE _LIBERE, CAMERE_REZERVATE, CAMERE_OCUPATE si TARIFE sunt tabelele care dau expresie asocierilor in care toate cardinalitatile maximale ale entitatilor participante au valoarea "n". Toate celelalte asocieri sunt reprezentate prin inserarea de chei externe in tabelele aferente entitatilor pentru care cardinalitétile maximale au valoarea "I" (spre exemplu, Nr cazare in NOTE_CHELTUIELI pentru asocierea INCLUDE, Cod client in REZERVARI pentru asocierea SOLICITA etc.).Proiectarea bazei de date 177 Asocierea cu cardinalitati maximale "/” dintre entitatile Cazare si Facturd a fost reprezentata prin inserarea numdrului cazdrii drept cheie externa in tabelul FACTURI, datorita faptului ca pentru aceasta, cardinalitatea minimala are valoarea "1" (conform recomandarii mentionate la pagina 166). CAMERE (Nr camera, Etaj, Descriere) TIPURI_CAMERE (Cod tip, Nrlocuri, Confort) CLASIFICARI_CAMERE (Nr camera, Cod tip, Incadrare dela, Incadrare pana la) PERIOADE_TARIFARE (Nr perioada, Data inceput, Data terminare) TARIFE (Nrperioada, Codtip, CAMERE_LIBERE (Nr camera, Libera dela, Libera pana la) CLIENTI (Cod client, Nume, Prenume, Adres, Nrtelefon, Adresa email) REZERVARI (Nerezervare, Datarezervirii, Rezervat dela, Rezervatpaua la, Stare, Avans, Cod client) CAMERE_REZERVATE (Nrrezervare , Nr camera , Nr persoane) CAZARI (Nr cazare, Data venirii, Data plecarii fc) Tarif camera, Tarif persoana) 7.2 Optimizarea bazei de date Schema relationala derivaté din modelul conceptual al datelor este solutia corecté pentru viitorul sistem, in cadru general. O bazi de date creata in conformitate cu ea va asigura fondul de informatii necesar prelucrarilor presupuse de cerintele functionale. Existé insé o puternicd interactiune cu prelucrarile executate, in sensul in care structura de memorare a datelor le poate creste sau, dimpotrivé, diminua gradul de complexitate, cu consecinte directe asupra performantelor. Prin urmare, schema initiala a bazei de date ar trebui revazuta si modificata, nu pentru a corespunde mai bine problemei ce face obiectul sistemului sau regulilor de normalizare relationala, ci pentru a fi optimizatd in raport cu prelucrarile specifice, particulare la care urmeaza sa participe. Optimizarea presupune, pe de o parte, o ajustare a implementarii, bazata pe exploatarea la maxim a tuturor caracteristicilor si posibilitatilor tehnice specifice