Cuprins
1 Introducere ......................................................................................................................... 3 1.1 Sistem informaţional şi Sistem Informatic (SI).......................................................... 3 1.1.1 Particularităţi ale introducerii unui Sistem Informatic ....................................... 3 1.1.2 Schema bloc a Sistemului Informatic................................................................. 5 1.2 Tipuri de Sisteme Informatice .................................................................................... 6 1.2.1 Sisteme de prelucrare a tranzacţiilor .................................................................. 6 1.2.2 Sisteme de conducere ......................................................................................... 6 1.2.3 Sisteme de asistare a deciziilor........................................................................... 7 1.2.4 Sisteme bazate pe cunoştinţe .............................................................................. 7 1.2.5 De la MPR la ERP şi BPR ................................................................................. 7 1.3 Funcţiile unui Sistem Informatic ................................................................................ 8

2

Abordări în Sisteme Informatice cu Baze de Date ............................................................. 9 2.1 Cadrul general şi specific al sistemelor cu Baze de Date ........................................... 9 2.1.1 Principii generale la realizarea unui Sistem Informatic ..................................... 9 2.1.2 Principii de realizare şi utilizare a Bazelor de Date ......................................... 10 2.1.3 Costurile erorilor nedepistate în faza de analiză şi proiectare .......................... 13 2.2 Etape în ciclul de viaţă ale Sistemului Informatic.................................................... 13 2.3 Modele de realizare a Sistemelor Informatice.......................................................... 15 2.3.1 Modelul cascadă ............................................................................................... 15 2.3.2 Modelul în “V” ................................................................................................. 16 2.3.3 Modelul incremental ........................................................................................ 17 2.3.4 Modelul spirală ................................................................................................. 17 2.3.5 Modelul tridimensional .................................................................................... 18 2.3.6 Standardul ISO/ IEC......................................................................................... 18

3

Analiza de sistem ............................................................................................................. 19 3.1.1 Strategii de analiză ale Sistemului Informatic.................................................. 19 3.1.2 Elemente analizate în sistemul ţintă ................................................................. 20 3.1.3 Etape în analiza de sistem ................................................................................ 21 3.2 Tehnici de reprezentare grafică a Sistemelor Informatice ....................................... 24 3.2.1 Scheme logice .................................................................................................. 24 3.2.2 Diagrame globale (scheme bloc) ...................................................................... 24 3.2.3 Flux pe orizontală ............................................................................................. 25 3.3 Modelul Conceptual al Datelor ................................................................................ 26 3.3.1 Entitate, atribut, relaţie şi restricţii ................................................................... 26 3.3.2 Diagrama Entitate-Relaţie (DER) .................................................................... 28 3.4 Realizarea MCD ....................................................................................................... 32 3.4.1 Dependenţe funcţionale ţi tranzitive ................................................................ 32 3.4.2 Reguli de structurare a MCD ........................................................................... 33 3.4.3 Paşi de urmat pentru realizarea MCD .............................................................. 35 3.5 Limbajul Unificat de Modelare (UML) ................................................................... 37 3.5.1 Noţiuni şi notaţii pentru entităţi ....................................................................... 37 3.5.2 Noţiuni şi notaţii pentru relaţii ......................................................................... 38 3.5.3 Exemplu de diagramă de clase ......................................................................... 39

4

Proiectarea Bazei de Date relaţionale............................................................................... 39 4.1 Reguli de Gestiune ................................................................................................... 40 4.1.1 Tipuri de reguli de gestiune .............................................................................. 40 4.1.2 Definirea şi stabilirea regulilor de gestiune...................................................... 41 4.1.3 Exemple de Reguli de Gestiune ....................................................................... 42 4.2 Niveluri de integritate ale bazei de date ................................................................... 42 4.2.1 Integritatea entităţii .......................................................................................... 43 4.2.2 Integritatea domeniului .................................................................................... 43 4.2.3 Integritatea referenţială .................................................................................... 44 4.2.4 Integritatea definită de utilizator ...................................................................... 45 4.3 Normalizarea Bazei de Date ..................................................................................... 45 4.3.1 Forma Normală 1 (FN1) ................................................................................... 47 4.3.2 Forma Normală 2 (FN2) ................................................................................... 48 4.3.3 Forma Normală 3 (FN3) ................................................................................... 49 4.3.4 Paşi în normalizarea bazei de date şi normalizare avansată ............................. 49 4.4 Proiectarea de detaliu ............................................................................................... 50 4.5 Management de proiect ............................................................................................ 52 4.5.1 Scopuri şi metode în managementul de proiect ............................................... 52 4.5.2 Estimarea realizării priectului .......................................................................... 54 4.5.3 Fazele managementului de proiect ................................................................... 54 4.5.4 Costurile managementului de proiect ............................................................... 55

Bibliografie............................................................................................................................... 56

2

1 Introducere
Un sistem este un ansamblu de părţi componente cu legături reciproce, care se referă la o zonă a lumii reale şi descrie o structură de modelare a acesteia. Un model este o imagine conceptuală a unor obiecte din realitate, care ilustrează proprietăţile şi comportarea lor, precum şi interacţiunile dintre ele, în scopul cunoaşterii sau controlului realităţii vizate. Modelul poate fi abstract (de exemplu un model matematic sau o schemă grafică) sau poate fi material (de exemplu o machetă la scară). În general, orice model care se va implementarea pe un sistem de calcul trebuie să aibă o reprezentare matematică distinctă şi se bazează pe o simulare pe calculator a sistemului ţintă (real). Abordarea oricărui sistem (ca model) începe cu identificarea părţilor sale (dacă acestea sunt evidente) sau cu divizarea artificială a părţilor, după care se identifică legăturile dintre ele. Discriminarea părţilor componente se face prin analiză – pentru fiecare component rezultând o serie de caracteristici şi moduri de comportare, adică fiecare component este modelat separat. Pentru ca sistemul realizat să ilustreze cât mai fidel realitatea, se recompun părţile prin sinteză adică se refac legăturile dintre componente, spre a obţine comportarea de ansamblu ce se doreşte modelată. Atât analiza cât şi sinteza sistemului se realizează urmărind o metodologie specifică domeniului ştiinţific vizat, a zonei ţintă şi contextul în de lucru, precum şi a scopului modelării (cunoaştere, control, simulare, etc.). Pentru verificarea concordanţei modelului cu realitatea vizată, se elaborează sau se folosesc metode de evaluare a comportării întregului, atât pentru verificarea performanţele dorite în scop cât şi pentru utilizarea eficientă a modelului în scopul propus. Cel mai adesea, un sistem se bazează pe un formalism, adică pe o exprimare simbolică a obiectelor (ca proprietăţi) şi a relaţiilor între ele (ca interacţiuni), cum este de exemplu exprimarea prin formule matematice a fenomenelor fizice sau economice.

1.1 Sistem informaţional şi Sistem Informatic (SI)
Un sistem informaţional este ansamblul mărimilor cantitative şi a raporturilor calitative între obiecte dintr-o zonă a lumii reale. În general, un sistem informaţional priveşte documentele (şi informaţiile conţinute de acestea) care se vehiculează în activitatea umană din zona reală de interes. Un sistem informatic (prescurtat în continuare SI) este format din totalitatea resurse fizice (echipamente de calcul, de stocare, de prezentare şi de transfer date) împreună cu resurse logice (programe şi date propriu-zise) care aplicate peste un sistem informaţional cresc eficienţa manipulării informaţiilor şi a funcţionării acestuia. 1.1.1 Particularităţi ale introducerii unui Sistem Informatic

SI poate fi privit ca o automatizare a sistemului informaţional al organizaţiei, suprapunându-se peste acesta din urmă şi nu înlocuindu-l în totalitate. Sunt rare cazurile în care SI asigură şi comunicaţiile prin voce şi imagine (de exemplu prin video-teleconferinţă) practicate în organizaţii. Cum datele sunt informaţii într-o reprezentare adecvată prelucrării şi stocării lor prin mijloace informatice, este evident că SI se bazează pe conversia tuturor informaţiilor de interes în date, cu structurarea, stocarea şi prelucrarea acestora pentru o utilitate anume a omului. Programele care asigură manipularea datelor vor viza acţiuni de prelucrare, de transfer şi de prezentare a rezultatelor spre acea utilitate. Ca idee generală, scopul unui SI este creşterea eficienţei în prelucrarea şi comunicarea informaţiilor. Astfel, omul este degrevat de acţiuni de rutină (în care omul poate greşi) dar în plus se obţin prelucrarea rapidă, prezentarea intuitivă şi completă a rezultatelor, transferul rapid şi sigur al informaţiilor. Trebuie remarcat că sistemele informatice actuale permit prelucrarea datelor pe un nivel calitativ superior, prin asistarea utilizatorului uman în luarea
3

deciziilor, prin în prognoze şi chiar prin expertiza asupra unor probleme complexe (similar activităţilor unor experţi umani). Eficienţa unui SI este reflectată în reducerea costurilor, în creşterea preciziei şi a vitezei de răspuns în rezolvarea diverselor probleme. SI contribuie însă şi la creşterea productivităţii prin reducerea resurselor implicate în diverse procese, prin conducerea efectivă, cu precizie şi promptitudine a proceselor, precum şi la asistarea omului pentru luarea unor decizii dificile. În timp ce până nu demult calculatorul era considerat un instrument de plus valoare, astăzi acesta este utilizat pentru administrarea şi chiar generarea de cunoştinţe. Un SI adecvat şi folosit corespunzător este atât de eficient încât el poate contribui indirect la îmbunătăţirea organizării muncii, a calităţii informaţiilor şi produselor, la decizii optime şi la comunicaţie fără restricţii. Un SI aduce însă şi probleme organizaţiei şi persoanelor care îl utilizează: Aceste probleme pot fi legate de: • Calitate – atunci când soluţia informatică la problemele organizaţiei este de calitate slabă, ducând la pierderi şi nu la câştiguri prin utilizarea sa. Acelaşi rezultat se obţine şi la folosirea incorectă a unui SI (calitatea slabă a pregătirii utilizatorilor) prin lipsa de competenţă a utilizatorilor, prin furnizarea de date incorecte sau perimate, prin neglijarea sau utilizarea ne-corespunzătoare a rezultatelor. • Productivitate – atunci când costurile sau durata de realizare a SI sunt prea mari. Trebuie ţinut cont de faptul că pe lângă costurile vizibile sunt şi costuri ascunse – legate de refacerea soluţiei pe durata realizării sistemului, de pregătirea personalului sau de dotări auxiliare necesare funcţionării sistemului. • Întreţinere – atunci când sistemul realizat nu este actualizat la condiţiile curente (ca date şi prelucrări) sau când echipamentele nu sunt verificate periodic şi aduse în parametrii de bună funcţionare. Întreţinerea implică la rândul ei costuri permanente care trebuie luate în considerare corespunzător dimensiunilor sistemului. • Fiabilitatea – ca siguranţă în funcţionare a sistemului, referitor la rata mică de defectare a echipamentelor şi programelor, la toleranţa la defecte (capacitatea de revenire în funcţionare după un defect, cu pierderi de date şi timp de prelucrare convenabile), la siguranţa datelor şi programelor (ca modalitate şi loc de păstrare a suporturilor cu date şi programe pentru a fi ferite de distrugere – prin neglijenţă, rea voinţă sau calamităţi). Asigurarea fiabilităţii sistemului implică costuri pentru: echipamente şi programe de calitate, suporturi de memorare dublate, spaţii de depozitare speciale pentru suporturile de date. • Securitate – ca mijloace de prevenire şi împiedicare a accesului neautorizat la sistem şi date, a fraudei informatice sau acţiunilor rău-voitoare asupra sistemului. Costurile privesc sisteme performante antivirus, antifraudă, şi antiefracţie, care trebuie în plus actualizate permanent. • Factor uman – ca impact psihologic şi mod de acceptare a SI de către utilizatorii umani. Prin introducerea unui sisteme informatic personalul uman se poate simţi urmărit şi verificat în acţiunile sale, poate fi frustrat de inutilitatea cunoştinţelor şi aportului său faţă de cel al mijloacelor de informatizare, astfel că de aici pot apare incidente de muncă sau utilizarea necorespunzătoare a sistemului. Asemenea situaţii duc la compromiterea SI – chiar dacă acesta este realizat corect. O a treia situaţie de compromitere a sistemului informatic apare atunci când el este realizat după cerinţele beneficiarului, dar acesta din urmă ori nu cunoaşte bine domeniul ţintă, ori nu are soluţii adecvate la problemele sale, ori de-a dreptul nu ştie ce vrea. Aspectele prezentate mai sus nu sunt argumente împotriva introducerii unui SI ci reprezintă situaţii ce trebuie rezolvate atât de proiectant cât şi de organizaţia beneficiară, pentru a asigura un SI de calitate, care să atingă scopurile vizate. Neglijarea aspectelor de mai sus duce la lucrări de calitate proastă, cheltuieli suplimentare şi chiar compromiterea sistemului informatic; poate apare astfel falsa părere că

4

SI este inutil, ceea ce va bloca progresul şi va provoca chiar eliminarea din competiţia globală a organizaţiei respective. Pe de altă parte, este la fel de falsă părerea că o problemă oarecare a unei organizaţii se poate rezolva prin introducerea unui SI fără a se cunoaşte în prealabil soluţia şi a se adapta această soluţie la specificul organizaţiei. Dacă nu se cunoaşte bine problema şi nu se dispune de o soluţie adecvată (elaborată local sau în exterior de specialişti avizaţi) problema nu va putea fi rezolvată şi din nou, pe nedrept, se ajunge la compromiterea sistemului informatic. În asemenea situaţii se consideră că a fost aplicată „metoda” denumită pe scurt GIGO (garbage in garbage out – adică, în traducere liberă, gunoi se prelucrează gunoi se obţine) – evident o exprimare în glumă a unei situaţii defectuoase, exprimare ce exploatează acronimele atât de des folosite în mediul informatic. 1.1.2 Schema bloc a Sistemului Informatic

Structura de principiu a unui SI este cea din Figura 1-1., în care: Ieşiri sunt de fapt rezultatele vizate. Intrări sunt toate informaţiile preluate din mediu necesare obţinerii ieşirilor. Prelucrările sunt operaţiunile prin care intrările devin ieşiri. Controlul sistemului asigură funcţionarea coerentă a sistemului prin comenzi adecvate. Contur

Anticipare Retroacţiune

Control

Comandă Comandă Intrări Prelucrare

Comandă Ieşiri

Figura 1-1 Structura bloc de principiu a unui SI. Facilităţile de retroacţiune şi de anticipare sunt adăugate unui SI modern pentru a depista abaterile ieşirilor de la performanţele vizate (prin retroacţiune) şi a prezice intrări utile la paşi ulteriori (prin anticipare). Retroacţiunea (denumită uzual şi reacţie iar în engleză feedback) dă caracterul cibernetic al sistemului informatic, mai precis caracterul de adaptabilitate (specific fiinţelor vii), care este foarte necesar pentru flexibilitatea în funcţionare a sistemului într-un context dinamic (adică un context ce se modifică în timp). Anticiparea (în engleză feed-forward), este o facilitate care permite asistarea deciziilor complexe în conducerea sistemului real (pe baza sistemului informatic care, eventual, îl simulează pe cel real). Astfel, sistemele informatice moderne nu sunt numai un ajutor pasiv (de evidenţă a unor fapte trecute) ci şi un sprijin activ în conducerea eficientă a sistemului ţintă – peste care s-a aplicat SI. Evident, aceste facilităţi nu se întâlnesc la sistemul informaţional - care este în sine pasiv, doar omul fiind cel care-l animă, omul fiind factorul activ. Cunoştinţele „active” ale omului sunt înglobate sistemului informatic, astfel că aceste din urmă se poate „comporta” ca un expert în domeniul ţintă, spre a creşte eficienţa de manipulare a informaţiilor pentru utilizatorul uman. Conceptul de sistem este o abstracţie legată de o zonă din lumea reală; graniţa dintre sistemul propriu-zis şi mediul înconjurător este stabilită arbitrar, dar este foarte importantă pentru analiza şi realizarea sistemului informatic. Această graniţă – denumită Contur (v. §3.1.2) se stabileşte de la primele faze de analiză ale sistemului vizat.

5

1.2 Tipuri de Sisteme Informatice
S-a arătat mai sus că SI are ca rol creşterea eficienţei manipulării informaţiilor – dintrun sistem informaţional. Fiindcă, în general, sistemul informaţional este deja existent (şi trebuie doar eficientizat prin informatizare) Sistemele Informatice se mai numesc şi Sisteme de Informatizare, subliniind prin această titulatură aportul activ de adaptare a vechiului sistem la cel nou - folosind mijloace de calcul electronic. Informatizarea este aşadar, acţiunea de adaptare şi transpunere a Sistemului Informaţional în SI. O operaţiune elementară prin care se face acces la date în scopul modificării lor se numeşte tranzacţie. Există două categorii de tranzacţii: • Tranzacţii externe - ce privesc proceselor economice şi operaţiuni efectuate cu exteriorul firmei (aprovizionare, încasări, plăţi). Intrările pot fi preluate de pe documentele scrise, local sau prin Internet (de la distanţă – prin EDI - Electronical Data Interchange). • Tranzacţii interne - unde datele sunt preluate în SI pornind de la rezultate parţiale obţinute în interiorul sistemului Există mai multe categorii de Sisteme Informatice, după o clasificare ce ţine cont de locul şi modul de utilizare a Sistemului Informatic, aşa cum se prezintă în continuare. 1.2.1 Sisteme de prelucrare a tranzacţiilor

Sistemele de prelucrare a tranzacţiilor (TPS Tranzaction Processing Systems) - execută operaţii de rutină zilnice asupra înregistrărilor unei baze de date şi nu duc neapărat la prelucrări într-un scop de eficientizare a utilizării datelor. TPS se utilizează mai ales în gestiunea (evidenţa) resurselor unei organizaţii (fie aceste resurse, materiale, produse, persoane, sau activităţi). Toate organizaţiile prezintă cinci categorii de TPS utilizate manual sau cu ajutorul unor mijloace automatizate: 1) Sisteme de marketing – au ca funcţii de bază controlul şi evidenţa cererii şi ofertei, prospectarea pieţei, stabilirea şi alocarea preţurilor, gestiunea de mărfuri produse. Aplicaţii uzuale: sunt sisteme de informare şi vânzare, sisteme de prospectare a pieţei şi sisteme de preţuri. 2) Sisteme de conducere a producţiei – au ca funcţii de bază planificarea, aprovizionarea şi desfacerea, transportul şi recepţia de marfă, controlul proceselor (în domeniul ingineresc) operaţiuni de întreţinere a echipamentelor. Aplicaţii uzuale sunt: sisteme de planificare a resurselor materiale, sisteme de control a achiziţiei şi desfacerii de produse, sisteme de conducere a proceselor şi sisteme de control a calităţii. 3) Sisteme financiare – au ca funcţii de bază controlul bugetului, al taxelor (schimb de bani), al contabilităţii costurilor şi controlul financiar. Aplicaţii uzuale sunt: sisteme contabile, sisteme de planificare şi bilanţ al bugetului şi sisteme de gestiune financiară. 4) Sisteme de personal – au ca funcţii de bază evidenţa salariilor, evidenţa şi formarea profesională. Aplicaţii uzuale sunt: calculul salariilor, evidenţa şi urmărirea personalului, sisteme de urmărire a beneficiilor, sisteme de urmărire a carierei, sisteme de calificare a personalului şi educaţie asistată de calculator (local şi la distanţă). 5) Sisteme de evidenţă în educaţie şi cultură – au ca funcţii de bază controlul examenelor de admitere, evidenţa notelor şi a situaţiilor şcolare, evidenţa lucrărilor de administrare în cercetare, evidenţa şi prezentarea cursurilor şi urmărirea materialelor bibliografice. Au ca aplicaţii de bază sisteme de informare în biblioteci, evidenţa situaţiei şcolare, evidenţa activităţii de cercetare, sisteme de educaţie asincronă (pe calculator). 1.2.2 Sisteme de conducere

Sistemele informatice de conducere (MIS - Management Information Systems) sunt utile activităţilor de conducere ale firmei şi au următoarele funcţii: • Asistă conducerea în luarea deciziilor pe baza evaluării sintetice a informaţiilor multiple preluate din sistemul real.
6

• •

Asigură implementarea unor mecanisme şi metode pentru organizarea muncii. Asigură planificarea producţiei şi resurselor ţinând cont de restricţiile exterioare şi interioare. Caracteristici: - sunt orientate spre raportare şi mai rar către control; - asigură controlul operaţiilor zilnice; - se bazează pe fluxul de informaţii din întreaga întreprindere (atât fluxuri materiale cât şi financiare); - au reale capacităţi analitice; - privesc spre trecut şi spre prezent, nu spre viitor; - sunt relaţii inflexibile fiind specifice firmei respective; - au o orientare spre interesul firmei şi nu spre exterior; - informaţiile trebuie să sosească în mod ordonat şi stabil; - necesită perioade lungi de analiză şi proiectare. Sisteme de asistare a deciziilor

1.2.3

Sistemele de asistare a deciziilor (DSS – Decision Support Systems) completează MIS cu mijloace de predicţie şi sugerare a măsurilor de luat în viitor şi sunt prevăzute cu modele de predicţie şi modele de conducere pentru a furniza sugestii conducătorilor. Cerinţe şi moduri de utilizare: - trebuie să fie flexibile (adaptate uşor) şi cu timp mic de răspuns; - lucrează sub iniţiativa şi controlul omului; - trebuie să necesite pregătire profesională de specialitate; - trebuie să asiste probleme şi decizii nestructurate (fără un model cunoscut anterior); - trebuie să permită decizii pentru conducerea de nivel înalt. DSS se bazează pe MIS, sistemul este interactiv şi conţine cunoştinţe generale de conducere dar şi speciale. 1.2.4 Sisteme bazate pe cunoştinţe

Sistemele sunt bazate pe cunoştinţe (KBS Knowledge Based Systems) sau sisteme expert sunt sisteme ce au înglobate tehnici de inteligenţă artificială. Sunt utile pentru asistarea deciziilor, pentru predicţii sau pentru conducere empirică a unei activităţi economice. Expertul într-un domeniu este o persoană ultracalificată prin educaţie şi experienţă care nu poate formula pe loc o explicaţie a deciziei sale. Totuşi, cunoştinţele sale pot fi înglobate întrun KBS şi apoi utilizate de oricine în domeniul dat. KBS poate fi de două tipuri: sisteme simbolice - care emulează sistemele umane de raţionament (emit judecăţi) şi sisteme subsimbolice – care emulează recunoaşterea şi raţionamentul aproximativ, folosind reţele neuronale artificiale, logică Fuzzy şi algoritmi genetici. 1.2.5 • • • • • De la MPR la ERP şi BPR În evoluţia lor istorică, SI aplicate în economie au parcurs mai multe etape: în anii 1960 funcţionau sisteme de evidenţă de inventar; în anii 1970 au apărut sisteme de planificare a necesarului de materiale MRP (Manufacturing Requirement Planning) care extrag din planul de producţie necesarul de componente şi subansamble ce trebuie aprovizionalte; în anii 1980 au apărut sisteme MRP II (Manufacturing Resource Planning) care adăugaul a sisteme MRP facilităţi de planificare şi management distribuit al a producţiei; în anii 1990 sistemele MRP II au fost extinse în evidenţe financiare, de resurse umane şi conducere a proiectelor (project management); în anii 2000 au apărut sisteme integrate de rezolvare corelată a problemelor întreprinderii, denumite ERP (Enterprise Resource Planning).
7

Sistemele ERP constau dintr-un set de aplicaţii care rezolvă atât probleme financiare, probleme de planificare a producţiei, probleme de resurse umane şi plăţi. Tendinţa de dezvoltare a sistemelor de gestiune şi control al resurselor se îndreaptă către sisteme IPR (Intelligent Resource Planning) al firmei BAAN, şi spre sisteme de tip BPR (Business Process Reengineering) – care oferă soluţii de restructurare a resurselor umane şi de reorganizare a producţiei pentru maximizarea profitului. Sistemele de control al activităţilor economice sunt completate cu sisteme de comunicaţie şi transfer financiar electronice, cunoscute drept EDI (Electronic Data Interchange), care fac legătura firmei cu banca, transportatori, autorităţi vânzători.

1.3 Funcţiile unui Sistem Informatic
În general un Sistem Informatic trebuie să îndeplinească o serie de funcţii standard, după cum urmează: 1) Colectarea datelor – constă în preluarea datelor necesare funcţionării Sistemului Informatic; datele sunt: • Colectate de pe documente scrise (prin intermediul operatorilor umani); • Achiziţionate din mediu prin senzori . În această etapă datele sunt denumite date primare şi ele trebuie validate (verificate dacă sunt conform realităţii şi formatului specific de intrare). După culegere şi validare, datele sunt stocate pe suport extern. Urmează selectarea datelor pentru prelucrări. Dacă este necesar, se face codificarea datelor (ca prelucrare preliminară utilizării lor în continuare). 2) Codificarea datelor – reprezintă ataşarea unei valori numerice (un cod) către o un nume de produs pentru a fi identificat. În realizarea sa un cod prezintă o serie simboluri (de obicei cifre) împărţite pe ranguri şi grupuri de ranguri, fiecare indicând clase utilizate într-o codificare arborescentă a obiectelor din mulţimea de referinţă. 3) Conversia datelor – constă în transformarea datelor dintr-un tip de date în altul mai adecvat prelucrării sau interpretării lor. 4) Transmiterea datelor. Uneori, este necesară transmiterea la distanţă a datelor prin reţele de calculatoare. Transmiterea trebuie sa se facă: exact, rapid şi confidenţial; între doi parteneri ocazionali trebuie sa aibă loc autentificarea fiecăruia (adică fiecare de partea sa să aibă confirmarea ca celalalt nu este cel care pretinde că este şi nu un impostor). 5) Funcţia de arhivare. Pentru volume mari de date, care trebuie păstrate mai mult timp (pentru utilizare ulterioară sau pentru recuperarea datelor corecte în caz că apar erori la cele curente) este necesară stocarea datelor într-un format special – comprimat şi organizat pentru păstrarea şi recuperarea rapidă). Acţiunea de selecţie a datelor recent modificate, cu comprimarea şi structurarea lor pentru păstrare îndelungată se numeşte arhivare; ea trebuie să se realizeze periodic, pentru a deţine o arhivă actualizată şi utilă în refacerea eventuală a datelor pierdute accidental. Arhivarea se numeşte şi “salvare” (Back Up) iar refacerea datelor prin extragerea lor din arhivă cu reîncărcarea lor pentru utilizare se numeşte “restaurare” (Restore). 6) Funcţia de control-verificare - este funcţia de depistare a unor eventuale situaţii eronate rezultate din analiza datelor. 7) Funcţia de prelucrare – asigură transferul datelor dar şi operaţiuni precum: sortarea, regăsirea, clasificarea datelor. 8) Funcţia de raportare şi prezentare - constă în afişarea unor rezultate pe hârtie (rapoarte) sau pe ecran. Prezentarea este un aspect foarte important în utilizarea şi interpretarea datelor, în plus permiţând utilizarea comodă a aplicaţiei. Modalitatea de prezentare uzuală este Interfaţa Utilizator Grafica (GUI – Graphical User Interface) folosind elemente precum casete, butoane grafice, liste, etc.

8

2 Abordări în Sisteme Informatice cu Baze de Date
Pentru rezolvarea corectă şi completă a problemelor vizate de un SI este necesară respectarea unor principii şi adoptarea unor modele care permit parcurgerea sistematică a activităţilor implicate în realizarea respectivului sistem. Chiar dacă modelele diferă (mai mult sau mai puţin) de la o abordare la alta, toate îşi propun o cale optimă de urmat în soluţionarea problemelor. Pe de altă parte, specificul sistemelor cu Baze de Date induce o serie de restricţii şi aduce totodată metode de lucru de care trebuie să se ţină cont în proiectarea şi realizarea sistemului.

2.1 Cadrul general şi specific al sistemelor cu Baze de Date
Principiile prezentate în continuare se referă la cadrul general al Sistemelor Informatice şi la cadrul particular al sistemelor cu Baze de Date. Cele două categorii de principii trebui respectate simultan pentru obţinerea rapidă a unui SI de calitate şi care să poată fi refăcut cu uşurinţă în viitor. 2.1.1 Principii generale la realizarea unui Sistem Informatic

Prin însăşi menirea sa, SI manipulează informaţii dintr-un domeniu anume (informaţii care există indiferent că sunt sau nu prelucrate automat) în ajutorul omului ca utilizator final al informaţiilor, serviciilor sau produselor pentru care se foloseşte sistemul. Cerinţele generale impuse utilizării unui SI privesc trei aspecte de bază: • Eficienţa – adică obţinerea unor avantaje (materiale, de timp sau de organizare) legate de domeniul automatizat; • Utilizarea facilă – adică interacţiunea comodă dintre om şi SI (privitor la modul de înţelegere a modului de lucru şi la operarea la sistem); • Scalabilitatea – adică posibilitatea de a creşte sau micşora dimensiunea sistemului fără modificări majore ale acestuia. Legat de activităţile de proiectare şi implementare, trebuie remarcat că o latură a eficienţei Sistemului Informatic se referă la modul cum se asigura re-utilizarea părţilor deja realizate la alte sisteme similare sau la dezvoltarea aceluiaşi sistem. Principiile comun acceptate în realizarea unui SI sunt: a) Abordarea globală a problemelor de rezolvat, pentru a se obţine o privire de ansamblu atât a sistemului ţintă cât şi a sistemelor cu care el interacţionează. Se pot extrage astfel chestiunile prioritare care trebuie rezolvate prin SI şi se poate face o eşalonare a dezvoltării de viitor a acestuia. b) Utilizarea unei metodologii unitare, prin care se tratează toate problemele ce pot apare la proiectarea dar şi la implementarea sistemului informatic, spre a elimina erori şi neconcordanţe de concepţie şi execuţie. Metodologiile clasice utilizate structurează informaţiile în abordarea diagramă entitate-relaţie (spre exemplu metoda MERISE) sau în abordare obiectuală (de exemplu OMT - Object Modelling Technique). Metodologia modernă, folosită astăzi pe scară largă, este UML (Unified Modelling Language), care integrează cele două abordări şi oferă un formalism şi o sistematizare eficientă a informaţiilor, a prelucrărilor lor şi a planificării etapelor de proiectare, pentru realizarea unui SI de orice tip şi de orice dimensiune. c) Structurarea sistemului informatic cât mai independent de structura organizatorică a firmei asigură funcţionarea sistemului informatic şi în cazul modificărilor organizatorice în cadrul firmei. d) Participarea nemijlocită a viitorului beneficiar la activitatea de analiză, proiectare şi implementare a sistemului informatic ajută la depistarea tuturor problemelor beneficiarului şi la rezolvarea acestora.
9

e) Respectarea cadrului legislativ este o cerinţă majoră. SI de gestiune trebuie să respecte reglementările în vigoare pentru prelucrări, tipărire de documente şi formate ale rapoartelor finale. f) Realizarea sistemului informatic trebuie sa se facă în concordanţă cu resursele disponibile la utilizator. g) Reutilizarea unor părţi ale sistemului (vechi) existent sau ale unor componente realizate deja pentru sistemul existent sau pentru alte sisteme asemănătoare. h) Schimbarea (în sensul dezvoltării) sistemului trebuie să se facă cu prevederea acestei situaţii încă din etapa de proiectare. Compromisurile (inerente schimbării) trebuie explicitate şi documentate. Respectând aceste principii, se poate trece la analiza şi proiectarea Sistemului Informatic – din care rezultă un plan de acţiuni şi resurse necesare, după care se trece la implementarea sistemului – adică la punerea în operă a planului. Un model este o structură de cunoştinţe care priveşte o secţiune a realităţii, adică o reprezentare coerentă cu scopul sau utilitatea propuse. Scopul poate fi un produs fizic iar utilitatea poate fi un serviciu. În cazul Sistemelor Informatice, totdeauna se urmăreşte realizarea unui serviciu, chiar dacă acesta poate fi pus în slujba realizării unui produs, deoarece SI priveşte culegerea, prelucrarea şi transmiterea informaţiilor – care nu sunt obiecte fizice ci valori, concepte, cunoştinţe sau comenzi. O metodologie este o cale optimă de urmat către obţinerea unui scop, şi cuprinde acţiunile desfăşurate în paşi (în succesiune, cu ramificaţii şi repetiţii); calea „optimă” este calea cea mai eficientă din punctul de vedere al consumul de resurse (materiale, financiare, umane, timp) şi se obţine după acumularea de experienţă şi chiar de expertiză în domeniul dat. Trebuie remarcat că există diverse căi prin care se poate realiza ceva, dar este calea optimă este cea de cost minim; de aceea, în competiţia continuă din lumea modernă nu va reuşi decât cel care adoptă şi respectă metodologiile cele mai noi, verificate. În contextul Sistemelor Informatice, metodologiile sunt specifice domeniului în care se doreşte automatizarea prelucrării informaţiilor, dar deja se conturează o abordare uniformă şi chiar o standardizare a fazelor de analiză şi proiectare, privind modul în care acestea sunt modelate şi conduse. 2.1.2 Principii de realizare şi utilizare a Bazelor de Date

Aceste principii sunt cunoscute şi ca „Regulile lui Codd” privitoare la Teoria Relaţională a Bazelor de Date, care au fost elaborate de E.F. Codd, după cercetările sale în domeniul bazelor de date. Aceste principii pornesc de la ideea că bază de date relaţională este nu doar o colecţie de tabele cu legături între ele, ci se conformează algebrei relaţionale din domeniul matematicii. Produsul software cu care se realizează sistemul de baze de date (cunoscute şi sub numele de SGBD – Sistem de Gestiune a Bazelor de Date) trebuie să asigure respectarea acestor principii, adică să se conformeze lor şi chiar să asiste omul în realizarea corectă a Bazei de Date. Cele 12 reguli sunt prezentate scurt mai jos. I.
-

Datele sunt structurate în tabele Un tabel (denumit şi relaţie sau entitate) este o grupare logică de date prezentată în forma tabelară - pe linii şi coloane. Ex.: tabelul Student ce (cu studenţii unei facultăţi) se referă la entitatea „student” folosită la urmărirea situaţiei şcolare a studenţilor, când se doreşte automatizarea evidenţei la secretariatul facultăţii. - O linie (denumită şi articol sau înregistrare) descrie un obiect (persoană, loc sau lucru); fiecare linie conţine informaţii asupra unui singur subiect din tabel. Ex.: linia care descrie un anume student (fie acesta Popescu M. Ion, cu numărul de legitimaţie 732).

10

-

-

-

-

O coloană (denumită şi câmp) descrie o singură caracteristică privitoare la un obiect, adică descrie o proprietate generică a entităţii pe care o reprezintă tabelul. Ex.: coloana Nume care conţine numele de familie a studentului. Fiecare valoare este apare la intersecţia dintre linie şi coloană. Ex.: valoarea Popescu în coloana Nume, sau valoarea 732 în coloana Numar_Legitimatie, pe aceeaşi linie. Data este atomică, adică nu există mai mult de o valoare asociată cu intersecţia dintre o linie şi o coloană. Ex.: în coloana Nume a tabelului Student apare doar valoarea Popescu (nu şi prenumele sau iniţiala tatălui). Nu există ordine între tabele – în sensul de succesiune sau ierarhie fixă, şi un tabel ce stochează date nu va conţine pe un altul. Relaţia între tabele este logică, adică nu există o relaţie fizică (fixă) înscrisă în program.

II.

Datele sunt accesibile din punct de vedere logic în Baza de Date relaţională - informaţia nu este referită (adresată) prin locaţia fizică (de pe suportul de memorare). Ex.: un anume student nu se poate indica prin “al 3-lea rând” în tabelul Student. - Orice informaţie trebuie să fie accesibilă logic indicând 1) un tabel 2) o cheie unică de identificare (cheie primară) 3) o coloană. Ex.: un „obiect” student se poate accesa prin indicarea tabelului Student, a cheii Numar_Legitimatie a şi coloanei din care se doreşte informaţia – de exemplu Nume.

III. Valorile lipsă (vide) sunt tratate uniform ca „necunoscute” - Valoare lipsă (denumită şi NULL) este interpretate întotdeauna valoare necunoscută; aceasta fie nu a fost introdusă fie nu este într-adevăr cunoscută. - Şirul vid la şiruri de caractere (indicat prin “” – adică „nici o literă”) şi 0 (zero) la numere nu înseamnă valoare “necunoscută” ci pot fi doar valori de iniţializare. Ex.: dacă un student nu are trecută în tabel nota de la bacalureat nu înseamnă că acesta nu la absolvit (altfel nu ar fi admis) ci înseamnă, că pentru moment, nota nu a fost introdusă. - Dacă nu sunt manipulate corect, valorile vide pot provoca anomalii în baza da date. Ex. valoare vidă la Numar_Legitimatie pentru un student anume va face imposibilă găsirea sa în tabelul Fisa_Student – unde are toate datele situaţiei şcolare. IV. O bază de date este auto-descriptivă - Baza de date relaţională conţine atât informaţii utilizator – date despre obiecte din lumea reală aflate în tabele) dar şi informaţii despre ea însăşi – date ce descriu structura obiectelor din baza de date (de exemplu capul de tabel, structura unei machete, etc.). - Datele ce descriu obiectele din baza de date sunt denumite meta-date şi sunt stocate în „tabele sistem” care sunt este accesate în acelaşi mod ca şi tabelele utilizator. - Colecţia de tabele sistem este denumită şi catalog sistem sau dicţionar de date V.
-

Comunicarea cu SGBD se face într-un limbaj unic pentru date şi meta-date Limbajul general acceptat actualmente este SQL (pronunţat „sicuăl” din engleză „sequel”) - Limba trebuie să suporte operaţii relaţionale legate de: actualizarea/modificarea datelor (de ex. operaţiile SELECT, INSERT, UPDATE, DELETE), definirea datelor (de ex. CREATE, ALTER, DROP) şi administrare (de ex. GRANT, REVOKE, BACKUP, RESTORE).

VI. O bază de date oferă alternative în consultarea informaţiilor - Datele din baza de date pot fi consultate direct în tabelele sursă – aşa cum sunt ele stocate pe suport extern, sau pot fi vizualizate în „tabele virtuale” (denumite „views” în engleză şi denumite vizualizări în continuare) – care de exemplu rezultă în urma unor interogări.
11

O vizualizare permite consultarea datelor din unul sau mai multe tabele (sau din alte tabele virtuale) printr-o combinare după dorinţă a liniilor şi coloanelor în tabelul virtual rezultat. - O vizualizare este definită de utilizator (indicând sursele de date şi structura de linii şi coloane dorite) dar tabelul rezultat nu dublează informaţia din tabelele sursă ci este doar o afişare a lor în forma dorită; tabelul rezultat poate fi utilizat apoi ca sursă de date. - O vizualizare poate conţine şi date agregate care nu se regăsesc în tabelele sursă ci au rezultat prin prelucrări asupra datelor sursă. Ex. din notele individuale ale studenţilor (date în tabele sursă) vizualizarea afişează media notelor obţinute la o disciplină (date noi).
-

VII. Baza de date permite operaţii relaţionale - Liniile sunt considerate elementele iar tabelul mulţimea care le conţine. - Asupra liniilor se pot aplica operaţii relaţionale (SELECT, INSERT, UPDATE, DELETE) şi operaţii pe mulţimi (reuniune, intersecţie, diviziune, diferenţă) - Operaţiile relaţionale şi pe mulţimi operează pe relaţii (tabele) producând alte relaţii. - O bază de date care permite doar operaţii pe fiecare linie (prin „navigare” în tabele) nu este considerată o bază de date “relaţională”. VIII. Independenţa fizică a datelor - Aplicaţiile care accesează informaţii într-o bază de date relaţională nu trebuie să fie afectate de schimbări în modul de stocare fizică a informaţiilor (de ex. schimbarea poziţiilor coloanelor în tabel sau a adreselor datelor pe disc). - Aplicaţia care accesează informaţia într-o bază de date relaţională „ştie” doar caracteristicile generale ale informaţiei (tipul de dată şi lungimea) dar nu trebuie să ştie cum este informaţia accesată sau stocată fizic. IX. Independenţa logică a datelor - Interdependenţa logică înseamnă că relaţiile dintre tabele se pot schimba fără să afecteze funcţionarea aplicaţiilor şi a interogărilor. - Structura de obiecte de lucru (adică tabele, interogări, machete, etc.) din baza de date sau structura tabelelor şi relaţiilor (logice) între ele se poate modifica fără să fie necesară refacerea bazei de date sau a aplicaţiei care o foloseşte. X.
-

Integritatea datelor este o funcţie a DBMS Pentru a fi considerată relaţională, integritatea datelor trebuie asigurată de însăşi baza de date (de fapt de SGBD) şi nu de programul de aplicaţie. - Integritatea datelor constă în menţinerea consistenţei şi preciziei informaţiei în baza de date. Există trei tipuri de integritate a datelor: integritatea entităţii, de domeniu şi referenţială (v.§4.2.3) - În baza de date, asigurarea integrităţii se poate face procedural – prin mici programe (proceduri) care forţează condiţiile de integritate, sau se poate face declarativ – prin declararea explicită a condiţiilor de integritate la crearea liniilor şi coloanelor.

XI. Baza de date permite distribuirea operaţiilor - Datele dintr-o bază de date relaţională trebuie să poate fi stocate centralizat (pe un singur calculator) sau distribuit (pe mai multe calculatoare interconectate – în reţea). - Utilizatorii pot combina date provenite din tabele din acelaşi tip de bază de date aflate pe diferite calculatoare (servere) sau din alte tipuri de baze de date relaţionale. - Integritatea datelor trebuie asigurată indiferent de numărul de copii ale datelor şi indiferent unde acestea sunt stocate. XII. Accesul direct la date să nu poată afecta integritatea datelor - Accesul la date se poate prin căile oferite de baza de date dar şi prin căi „directe” – de ex. prin intermediul unui program scris în limbajul C şi care „citeşte” informaţia din tabele.
12

-

Accesul direct trebuie să nu afecteze integritatea datelor amintită mai sus, mai precis SGBD trebuie să împiedice ca intervenţia prin limbajul maşinii să afecteze integritatea datelor. Costurile erorilor nedepistate în faza de analiză şi proiectare

2.1.3

Analiza şi proiectarea sistemului informatic sunt etape foarte importante în realizarea unui SI, iar folosirea unei metodologii adecvate este esenţială în reuşita acesteia. Sunt dese cazurile în care realizarea Sistemului Informatic se lasă pe seama unor persoane care au experienţă în domeniul hardware sau chiar software dar care nu cunosc sau nu aplică o metodologie adecvată în acest demers; rezultatul muncii lor – făcute după impresii şi judecăţi ad-hoc, va fi ori un sistem prost sau inutilizabil ori va duce la costuri foarte ridicate datorită multelor erori care vor fi depistate la implementare sau chiar la utilizarea sistemului. Costuri x100 x10
1

Proiectare Implementare Exploatare Etape Figura 2-1 Costuri implicate de rezolvarea unei probleme în cele trei etape principale în realizarea unui sistem informatic. Costurile de rezolvare ale unei probleme legate de funcţionarea sau utilizarea sistemului cresc cu câte un ordin de mărime (de 10 ori) de la etapa de proiectare la cea de implementare şi apoi la cea de exploatare a sistemului (v. Figura 2-1). Cu cât se rezolvă mai multor probleme la etapa de (analiză) şi proiectare, cu atât mai puţine situaţii neaşteptate apar şi vor trebui rezolvate la implementarea sau la exploatarea sistemului, când este deja târziu şi costisitor a se renunţa la echipamente, bani şi muncă investite dar nefolositoare. Succesul soluţiei adoptate şi a investiţiei este asigurat doar de folosirea corectă (adică respectarea) unei metodologii adecvate problemei de rezolvat. De aceea, astăzi, se cheltuiesc mulţi bani pentru achiziţionarea unui sistem de proiectare asistată de calculator (CAD) sau un sistem pentru analiza şi proiectarea software asistată (CASE) care permit dezvoltarea corectă şi în timp scurt, cu investiţie, erori şi eforturi minime în rezolvarea cu succes a problemelor ce apar la realizarea unui SI. Dacă nu se cunoaşte sau nu se caută o metodologie corectă, este mai bine a se apela la firme specializate, care pot dovedi că au avut succes în realizarea sistemelor informatice la alţi beneficiari. Un SI în sine nu este o soluţie şi nu rezolvă problemele de gestiune, de organizare sau de conducere ale unui organizaţii decât dacă soluţiile (dar mai ales metodele de soluţionare) sunt corect analizate, elaborate şi testate. Problemele sunt efectiv rezolvate ca principiu de om (de expert sau de beneficiar) în faza de analiză competentă a domeniului, după care implementarea vine doar să pună în operă soluţiile adoptate. Durata prea mare de dezvoltare (de creare sau de refacere) a unui SI precum şi adaptarea la noi situaţii pe o durată prea îndelungată duc la cheltuieli mari şi la rezultate slabe.

2.2 Etape în ciclul de viaţă ale Sistemului Informatic
Pe parcursul realizării şi utilizării Sistemului Informatic, apar diferite etape ca durata şi rol, care trebuie abordate în mod specific şi cu personal specializat, care se finalizează cu documente specifice, cu produse software şi hardware pentru rezolvarea problemei date. Se vorbeşte de „ciclul de viaţă” al Sistemului Informatic, pentru că succesiunea de etape se
13

repetă într-un ciclu prin care se obţine şi apoi se rafinează soluţia problemei. Etapele ciclului de viaţă sunt: 1) Definirea cerinţelor utilizatorului – priveşte extragerea prin interviu sau expertiză la faţa locului a problemelor de rezolvat cu viitorul SI. Documentul întocmit este „Studiul de necesitate” şi este elaborat de o echipă care, eventual, va fi şi beneficiara sistemului informatic. Echipa de lucru este condusă de o persoana care, în mod normal, face parte din conducerea firmei beneficiare, pentru a avea responsabilitate şi putere de decizie în diversele chestiuni ce pot apare. 2) Analiza de sistem detaliază scopurile vizate, datele şi prelucrările necesare precum şi resursele necesare: programe, echipamente, resurse umane, finanţe. Persoanele implicate în această etapă trebuie să cunoască bine problemele dar şi soluţiile lor, fiind specialişti în domeniul ţintă dar având şi cunoştinţe de proiectare, de informatică şi cunoştinţe de management al proiectelor. În această etapă se elaborează „Specificaţiile de proiectare”, care prevăd estimativ resursele hardware, software şi auxiliare necesare. Conform acestor cerinţe, se elaborează o structură a sistemului care poate să realizeze funcţiile dorite şi se indică modalităţile de testare care pot atesta atingerea scopurilor. urmărind o metodă anume. Pentru a realiza cu succes şi eficienţă această etapă este necesară adoptarea şi respectarea unei o metodologii - adică a unei abordări ştiinţifice şi sistematice verificate. Astăzi, pentru această etapă se pot folosi instrumente CASE (Computer Aided Software Engineering) care asistă analistul de sistem în definirea structurilor şi funcţiilor pe module, în proiectarea lor, iar apoi poate genera aplicaţia (codul programului) şi chiar întocmi în linii mari documentaţia de proiectare. 3) Proiectarea logică – priveşte etapa de concepţie a structurilor şi a elementelor ce compun SI, care vor constitui ulterior baza pentru realizarea sistemului. Sunt implicaţi analişti programatori şi specialişti care stabilesc cadrul în care se va realiza şi va funcţiona SI: resurse fizice existente, aplicaţii existente şi necesare, modul de realizare a aplicaţiilor şi structurii de echipamente; în această etapă se stabileşte şi modul general de desfăşurare a acţiunile de implementare. Documentul elaborat este „Proiectul de ansamblu”. 4) Proiectarea fizică - în cadrul căreia se detaliază toate datele şi procedurile implicate în rezolvarea problemei date, precum şi modalitatea de realizare şi instalare a structurii de echipament. Pe partea de programe se realizează structura modulară şi funcţiunile modulelor, pe partea de echipament se realizează schema de amplasare a echipamentelor cu instrucţiuni de instalare, iar pe partea de lucrări se face planificarea în detaliu a operaţiunilor de execuţie. Documentul elaborat este „Proiectul de detaliu” şi „Specificaţii de programare”. 5) Implementarea Sistemului Informatic - cuprinde multitudinea de operaţiuni de programare (codificare), precum şi instalarea echipamentelor şi programelor necesare funcţionării sistemului. Documentele realizate în această etapă sunt „Programe sursă documentate” şi „Documentaţia de funcţionare”. 6) Testarea individuală a modulelor – constă în verificarea funcţionării modulelor şi a interacţiunii lor cu module vecine. Este posibil ca anumite module să nu execute funcţiile dorite, şi atunci se reiau pentru acestea (sau chiar pentru întreg ansamblul) etapele 4, 5, 6, până la obţinerea rezultatului dorit. Documentele întocmite sunt „Foi de test” – prin care se constată conformitatea (sau nu) a funcţionării modulelor cu specificaţiile de programare şi se indică tipul şi locul erorii. 7) Integrarea componentelor şi testarea finală a Sistemului Informatic – constă în asamblarea tuturor componentelor fizice (echipamente) şi logice (date şi programe), care vor funcţiona împreună pentru realizarea scopului propus, după care se face testarea ansamblului spre a se verifica atingerea acestui scop. Testarea finala «de punere în funcţiune» durează cel puţin 3 zile; testarea sa de către personalul de exploatare indică
14

dacă sistemul este realizat în conformitate cu cerinţele beneficiarului, dacă este sigur şi dacă este uşor utilizabil (dacă sunt probleme de operare). Uneori există şi o etapă de testare a comunicaţiei pentru cazul în care beneficiarul este distant. Documentul întocmit la finalul etapei este „Procesul verbal de dare în exploatare”, semnat de către realizatori şi de către beneficiar. 8) Exploatarea şi întreţinerea Sistemului Informatic. Exploatarea implică utilizarea de personal pregătit special, deci presupune şcolarizarea personalului utilizator. Întreţinerea constă în rezolvarea incidentelor de proastă funcţionare sau de nefuncţionare ale SI, pentru care soluţionarea constă în menţinerea copiilor de rezervă pentru date şi programe, configurare sau chiar reinstalare periodică a aplicaţiilor, precum şi controlul şi menţinerea în stare bună de funcţionare a echipamentelor fizice. 9) Dezvoltarea Sistemului Informatic – constă în adăugarea sau modificarea unor module pentru a satisface mai bine cerinţele impuse sau pentru a rezolva noi cerinţe. În scopul dezvoltării facile atât a modulelor software cât şi hardware, este necesară realizarea unei documentaţii amănunţite privind structura şi funcţionarea SI; această documentaţie trebuie realizată cel târziu în faza de testare finală, înainte de darea în exploatare şi trebuie sa conţină funcţiile şi modul de realizare a modulelor, manualul de utilizare şi ajutor pe loc (help). De obicei, dezvoltarea se realizează de o alta echipa decât cea care a creat SI, de aceea documentaţia trebuie să fie atât de amănunţită încât să nu pună probleme de înţelegere sau de modificare a programelor. Astăzi, mediile de proiectare (CASE Computer Aided Software Engineering) şi cele de programare oferă şi facilitatea documentării automate, venind în ajutorul proiectantului şi programatorului. Realizarea unui sistem cu baze de date respectă (în general) o metodologie care este specifică tipului de SGBD utilizat la implementarea sistemului. Se deosebesc două familii mari de abordări care s-au impus actual în lume: abordarea relaţională şi abordarea obiectuală. Astfel, de la etapa de analiză şi până la etapa de model fizic se vor folosi terminologii şi simboluri specifice uneia din abordări, orientate spre diagrama Entitate-Relaţie sau pe descrierea obiectuală a domeniului. În cele ce urmează se va prezenta doar prima abordare, în care simbolistica de reprezentare a diagramei Entitate-Relaţie va fi cea clasică (v. Figura 3– 15) sau UML (v. Figura 3–19)

2.3 Modele de realizare a Sistemelor Informatice
În evoluţia lor, metodele de analiză şi proiectare a Sistemelor Informatice au cunoscut trei generaţii: • Modele ierarhice - care se bazează pe descompunerea ierarhică a acţiunilor mari în subacţiuni. • Modele sistemice – care vizează module cu acţiuni specifice ce rezultă de obicei dintro metodă sau printr-un instrument care asistă proiectantul. • Modele obiectuale – care discriminează în lumea reală obiecte generice ca sunt implementate apoi ca obiecte software. În continuare se face o succintă trecere în revistă a modelelor cunoscute în proiectarea şi realizarea Sistemelor Informatice, la unele dintre acestea indicând etapele din ciclul de viaţă cu numerele de ordine care apar la §2.1.1., chiar dacă apar diferenţe faţă de structura generală indicată la acel paragraf. 2.3.1 Modelul cascadă Prezintă o curgere logică a etapelor din ciclul de viaţă a (indicată prin săgeata revenire în cazul invalidării unor chestiuni specifice etapei, care trebuie revăzute (săgeata ) cu ).

15

Analiz. sist. inf. 1-2 Planif. lucrărilor 3 Proiectarea generală 3 Proiectare de detaliu Programare 5, 6 Integrare, testare 7 Exploatare, dezv. 8 ,9

Figura 2-2 Modelul cascadă de realizare a Sistemului Informatic.

2.3.2

Modelul în “V”

Acest model este o variantă a modelului cascadă în care locul central este ocupat de programare (codificare). Acest model este folosit uzual la sisteme orientate obiect.

1

9

2

8

3

7

4

8

5

Codificare şi Testare componente

Figura 2-3 Modelul în „V” de realizare a Sistemului Informatic.

16

2.3.3

Modelul incremental

Este un model în care o componentă sau un grup de componente este realizat independent de celelalte adăugându-se sistemului unul câte unul până la obţinerea ansamblului. Acesta este un mod de lucru eficient, abordat în echipă şi coordonat de un conducător de echipă de proiect. Se aplică începând de la etapa 5 până la etapa 8. Componentele pot fi reutilizate în alte proiecte.
Analiză de sistem Proiectarea Arhitecturi i Realizare Componen t Proiectare

Testare

Predare

Planificare

Integrare

Implementar

Figura 2-4 Modelul incremental în realizarea Sistemului Informatic. 2.3.4 Modelul spirală

Acţiunile se succed una după alta, iar spirala indică curgerea timpului şi totodată etapele conceptuale (spre centru) şi cele de implementare (spre periferie).

Dare în exploatare

Analiză sistem

Integrare Integrare

Analiză sistem Proiectar e

Proiectar e

Startare Proiect

Testare

Plan activităţi
Implementare

Testare

Plan activităţi

Implementare

Figura 2-5 Modelul în spirală de realizare a Sistemului Informatic.
17

Diferitele etape au corespondenţă şi schimb de informaţii între ele (atunci când se află în acelaşi cadran). Modelul cuprinde o strategie de management de proiect bazată pe natura iterativă a procesului de realizare a Sistemului Informatic. 2.3.5 Modelul tridimensional

Acest model este utilizat în metoda MERISE şi indică trei direcţii implicate în dezvoltarea Sistemului Informatic: Abstractizarea – dimensiunea de conceptualizare, Decizia – dimensiune de acţiune umană, Ciclul de viaţă – dimensiune de dezvoltare. Prescurtările ce apar în Figura 2-6 se referă la: • Nivelul conceptual - priveşte abordarea abstractă a datelor şi prelucrărilor adică modelul conceptual al datelor (MCD) şi al prelucrărilor (MCP) • Nivelul logic - priveşte abordarea din punct de vedere relaţional, uşor de implementat ca date şi prelucrări prin modelul logic al datelor MLD şi modelul logic al prelucrărilor MLP • Nivelul fizic - priveşte realizarea efectivă a fişierelor cu date şi cu prelucrări – MFD modelul fizic al datelor şi MFP – modelul fizic al prelucrărilor. • Deciziile pot fi: - generale – se referă la modul de lucru pe ansamblu - tehnice – vizează suportul hardware de prelucrare şi comunicaţie - organizaţionale - legate de modul cum se pune în operă sistemul. • Ciclul de viaţă - priveşte etapele 1 la 11 din §2.1.1. Abstractizare MFD+MFP MLD+MLP MFD+MFP
Nivel fizic

Nivel logic
Nivel conceptual Decizii organizatorice Decizii generale

Decizii tehnice

Ciclu de viaţă

Decizie

Figura 2-6 Modelul tridimensional în realizarea Sistemului Informatic. 2.3.6 Standardul ISO/ IEC

Institutul mondial de standarde ISO – International Standards Organization, şi IEC – International Electrotehnical Comision au elaborat şi promovează prin standardul ISO / IEC – 12207 o modalitate unitară de abordare a sistemelor informatice. Astfel, standardul stabileşte un cadru comun pt. procesele ciclului de viaţă fără a impune un model anume. Cadrul se referă la 5 procese primare, 8 procese ajutătoare şi 4 procese organizatorice. Fiecare proces prezintă un set de activităţi şi activităţile ei conţin seturi de task-uri (sarcini). A. Procese primare 1. procesul de achiziţie – cuprinde activităţi derulate de furnizorul sistemului informatic în pentru analiza şi soluţionarea problemei de rezolvat; 2. procesul de furnizare – cuprinde activităţi de predare parţială şi finală a produselor informatice;
18

3. procesul de dezvoltare – activităţi derulate pentru crearea şi adăugarea de facilităţi de prelucrare şi prezentare a informaţiei (adică noi interogări, module program, etc.); 4. procesul de exploatare – cuprinde activităţi realizate de organizatorul desemnat să folosească sistemele informatice (utilizatorul / beneficiarul prelucrează informaţiile de interes); 5. Procesul de întreţinere – cuprinde activităţi realizate de organizatorul desemnat să întreţină în funcţie sistemelor informatice; Procesele primare vizează acţiuni în realizarea sistemelor informatice prin prisma actorilor. În cazul în care beneficiarul sistemului este şi cel care îl exploatează şi îl întreţine actorul de o parte se reduce la beneficiar şi actorul de furnizare este cealaltă parte. B. Procese ajutătoare – care sprijină alte procese, contribuind la calitatea software. 1. procesul de documentare – activităţi de înregistrare a informaţiei şi prelucrărilor; 2. procesul de gestiune a configuraţiei cuprinde derularea activităţilor de conducere şi se adresează procedurilor administrative şi tehnice pe parcursul proiectului software (se stabilesc proceduri de control pentru stocarea, manipularea şi livrarea componentelor software, stabilind modificările şi versiunile succesive); 3. procesul de asigurare a calităţii se referă la modul de abordare a informaţiei; activitate ce asigură îndeplinirea condiţiilor de calitate şi care se bazează în general şi pe următoarele procese ajutătoare; 4. procesul de testare cuprinde activitatea realizată de beneficiar şi furnizor pt. verificarea produselor pornind de la cerinţe stabilite anterior; 5. procesul de validare – acţiuni realizate de beneficiari pt. verificarea şi confirmarea respectării cerinţelor pt. utilizarea sistemului; 6. procesul de analiză comună – activităţi de evaluare a stării sistemului informatic atât de către furnizor cât şi de beneficiar; 7. procesul de auditare – activităţi desfăşurate pt. determinarea gradului de îndeplinire a cerinţelor, procedurilor contractuale, fazelor de realizare a sistemului informatic; 8. procesul de depanare – remediere a defecţiunilor. C. Procese organizatorice 1. procese de management – ca activitate de bază pentru conducerea proiectului; 2. proiectul de infrastructură – activitate pentru stabilirea, realizarea şi întreţinerea infrastructurii, adică a necesarului de hardware, software, tehnici, metode, standarde şi facilităţi de dezvoltare; 3. îmbunătăţirea procesului – pentru a măsura, controla şi îmbunătăţi un proces oarecare; 4. formarea personalului ca activitate de pregătire profesională.

3 Analiza de sistem
Activitatea de analiză de sistem are ca scop cunoaşterea completă şi corectă a problemelor de rezolvat în domeniul vizat şi elaborarea unei soluţii de principiu corecte şi fezabile (adică realistă şi realizabilă în limita resurselor disponibile). Activitatea de analiză constă în discriminarea elementelor ce apar în lumea reală şi legăturilor dintre ele aşa cum apar în domeniul ales, precum şi stabilirea ansamblului de activităţi care trebuie desfăşurate în scopul realizării sistemului propus. 3.1.1 Strategii de analiză ale Sistemului Informatic

În analiza sistemului ţintă se deosebesc trei strategii de principiu: strategia descendentă (TOP-DOWN), strategia ascendentă (BOTTOM-UP) şi strategia mixtă (cele două mixate). Strategia descendentă priveşte proiectarea şi realizarea sistemului informatic pornind de la general spre particular. Se analizează la început ansamblul şi apoi se trece la detalii, prin divizarea logică a ansamblului. Metoda are avantajul scalabilităţii, adică proprietatea de a
19

putea extinde sau dezvolta sistemul sau de a-l reduce şi diviza fără modificări esenţiale (de concepţie sau de implementare). În cazul unui sistem de gestiune se face analiza de ansamblu a întregii activităţi a firmei şi se delimitează domeniile de acţiuni specifice, după care se trece la detalierea acţiunilor din fiecare domeniu. Strategia TOP-DOWN se foloseşte pentru sisteme informatice complexe cu arie largă de cuprindere sau care vizează soluţii globale. Pe măsura dezvoltării componentelor din arhitectura generală a sistemului se testează acestea individual cât şi în legătură cu celelalte componente. Metoda este utilă în faza de analiză chiar dacă există un singur domeniu ţintă. Dezavantajul metodei provine din faptul că pentru o nouă problemă de rezolvat, analiza şi implementarea trebuie refăcute - fiind specifice, iar blocurile obţinute prin detaliere trebuie realizate din nou. Strategia ascendentă priveşte elaborarea soluţiei pornind de la particular spre general. Se analizează de la început, în detaliu, acţiuni şi resurse necesare, după care se realizează “componente” (adică module de prelucrare) specifice. Se pot obţine soluţii noi cu aplicabilitate generală din soluţii cunoscute dar aplicabile la cazuri particulare. În SI de gestiune se abordează domeniile specifice de gestiune fără a exista o soluţie cadru generală dar care se poate obţine ulterior prin punerea în acord a acestora. Un mare avantaj al acestei strategii este adus de reutilizarea componentelor (în diverse alte sisteme – similare sau diferite), unde acestea se asamblează după problema de rezolvat. Dezavantajul major este adus de dificultatea analizei unei noi probleme şi abordarea rezolvării pornind exclusive de la componentele (existente sau nou create). Strategia mixtă reprezintă o combinaţie între primele două strategii, în general abordându-se analiza şi proiectarea sistemului prin metoda TOP-DOWN, iar realizarea acestuia prin metoda BOTTOM-UP. Pe parcursul realizării şi utilizării sistemului informatic, diferite etape ca durată în timp prezintă caracteristici ce trebuiesc evaluate şi abordate specific de către echipa de implementare şi/sau conducere. 3.1.2 Elemente analizate în sistemul ţintă

O primă fază în analiza sistemului ţintă constă în stabilirea conturului domeniului ce urmează a fi informatizat. Contur

Producţie

Departament Aprovizionare

Conducere Transport Figura 3-1 Separarea zonei de interes de celelalte zone, prin contur. În exemplul din Figura 3-1 se indică separarea Departamentului Aprovizionare de restul firmei, cu care acesta are legături dar de care se deosebeşte prin funcţiunile specifice şi prin prelucrările care se doresc automatizate.
20

După cum s-a arătat la §1.1.2 şi în Figura 1-1, blocurile de principiu ale viitorului SI sunt Intrări, Ieşiri, Prelucrări şi Control. Dacă blocul de Control nu apare explicit în structura sistemului, el trebuie realizat de către personalul utilizator. Prin control se urmăreşte ritmicitatea şi precizia prelucrărilor sau se intervine în situaţii în care ieşirile nu sunt conform specificaţiilor de la proiectarea sistemului. Intrările reprezintă ansamblul datelor încărcate manual sau automat în sistem. Acestea intervin prin tranzacţii externe şi tranzacţii interne. Tranzacţiile externe redau dinamica aplicaţiilor şi proceselor economice şi financiare din cadrul firmei. Ele provin din exteriorul sistemului informatic şi reprezintă date privind aprovizionarea cu materii prime, date de încasări şi plăţi, etc. Pot fi date consemnate pe documente (facturi), date din mediul economic-financiar (legate de prevederi legale de genul ordin de plată şi cotă TVA), date din sistemele informaţionale (altele decât domeniul vizat al sistemului informatic al firmei), cât şi date din sisteme informatice exterioare firmei. Intrările pot fi preluate fizic de la periferice utilizate de către om (tastatură) şi de la dispozitive pentru cartele magnetice. Datele pot fi introduse şi de la distanţă prin Internet cu ajutorul formularelor WEB sau EDI (Electronic Data Interchange). Cu ajutorul tranzacţiilor interne datele sunt preluate din SI ca rezultate ale altor prelucrări. Exemple pot fi valoarea totală a produselor sau valoarea produselor cu TVA. Prelucrările privesc operaţii de calcul dar şi operaţii de tipul căutare, sortare, extragere a unor informaţii, filtrare după criterii stabilite, comasare de informaţii şi operaţii logice. În general prelucrările vizează crearea iniţială şi actualizarea bazei de date, exploatarea, reorganizarea, salvarea şi restaurarea bazei de date (BACK-UP, RESTORE). Salvarea înseamnă înscrierea periodică pe suportul magnetic a informaţiilor din baza de date la momentul curent. Restaurarea se face prin reîncărcarea în baza de date după un eveniment sau se face ca o operaţie periodică în cazul sistemelor distribuite. Ieşirile privesc rezultatele prelucrărilor şi pot fi ieşiri în urma operaţiilor de transfer a datelor care nu şi-au modificat valoarea (numărul şi data facturii, denumirea produsului) şi ieşiri obţinute în urma unor operaţii conform unor algoritmi. Pentru cele două categorii testarea rezultatelor este specifică, în al doilea caz fiind necesare intrări şi rezultate de test cunoscute pentru a putea depista corectitudinea prelucrărilor. Ieşirile pot fi indicatori sintetici reprezentând valori unice (scalare) şi indicatori analitici ce apar sub forma unor tabele. Rapoartele conţin indicatori sintetici şi analitici prezentaţi într-un document unitar şi o formă impusă de lege (stat de plată, balanţă sintetică), conţinând date de stare ale domeniului informatizat (starea patrimoniului, starea vânzărilor, etc.). Rapoartele statistice conţin indicatori sintetici utili luării deciziilor de către conducerea firmei. Rapoartele previzionale oferă sugestii pentru decizii viitoare pe baza prelucrării suplimentare a datelor din trecut. După destinaţie rapoartele pot fi de uz intern sau de uz general, iar după frecvenţă rapoartele pot fi zilnice, lunare sau trimestriale. Ele pot conţine grafice pentru evaluarea calitativă a unor evoluţii utile în luarea deciziilor. 3.1.3 Etape în analiza de sistem

Realizarea unui SI poate avea loc în două situaţii de fapt: 1) ca adăugire pentru un sistem informatic deja existent şi 2) ca sistem nou. În primul caz, analiza de sistem se bazează pe elemente arhitecturale (de structură a sistemului), pe date şi programe existente la care trebuie adăugate noi date şi programe compatibile cu cele vechi, pe când în al doilea caz analiza de sistem porneşte de la zero şi se bazează pe documente (hârtii scrise) care se întocmesc şi se prelucrează manual de către lucrătorii din domeniul analizat. În acest ultim caz este necesară cunoaşterea structurii organizaţiei, a rolului fiecărui element în activităţile vizate şi a restricţiilor de lucru specifice. Acţiunea de cunoaştere a situaţiei concrete are loc prin interviuri cu personale beneficiare (manageri şi lucrători) şi apoi prin reunirea cunoştinţelor într-un model care permite o reprezentare precisă (pe ansamblu şi apoi în detaliu) a operaţiunilor şi informaţiilor culese.
21

În cadrul analizei intervin în principal două categorii de persoane: analişti şi beneficiari; analistul conduce interviurile făcute beneficiarilor şi extrage cunoştinţele care apoi vor fi codificate (adică primesc notaţii precise) şi formalizate (adică relaţiile între ele sunt exprimate prin formule sau proceduri precise), pentru a fi apoi înglobate în SI. Analiştii sunt persoane care de obicei sunt experţi în domeniul vizat şi în plus au cunoştinţe în informatică şi în teoria sistemelor; ei sunt cei care doresc să cunoască în amănunt problemele de rezolvat şi de aceea intervievează viitorii beneficiari ai Sistemului Informatic. Beneficiarii sunt lucrători în locul şi în domeniul vizate, dar şi conducători ale organizaţiei la diferite niveluri. Desfăşurarea cu succes a analizei este în responsabilitatea analistului; acesta este uneori chiar o persoană care lucrează în domeniul şi locul vizate (economist, contabil, inginer, etc.). Există diverse abordări privind desfăşurarea analizei de sistem; mai jos se prezintă o abordare procedurală sistematică propusă în [3]. 3.1.3.1 Înţelegerea cerinţelor beneficiarului Se inventariază chestiunile de rezolvat şi „aşteptările” pe care beneficiarul le are de la SI viitor. În demersul de înţelegere a cerinţelor trebuie implicat şi beneficiarul nu numai analistul, fiindcă deseori beneficiarul nu formulează complet şi corect cerinţele – datorită faptului că unele detalii le omite considerându-le subînţelese, nu le dă atenţie sau nu le ştie. În [4] se fac următoarele recomandări pentru o analiză de succes: • Formulaţi clar obiectivele urmărite. • Stabiliţi unde trebuie să faceţi compromisuri la obiective în conflict. • Stabiliţi priorităţi şi schimbaţi priorităţi atunci când se impun. • Realizaţi un model al sistemului (grafic şi procedural), indicând efecte colaterale şi schimbări pe termen lung. • Stabiliţi de ce date aveţi nevoie şi care este volumul lor. • Nu abstractizaţi excesiv şi nu reduceţi totul la o idee, un caz sau fapt. • Ţineţi cont de părerea celor care vă atrag atenţia asupra unor „greşeli”. • Aplicaţi metode cunoscute când vă sunt folositoare dar evitaţi-le când vă încurcă. • Studiaţi istoricul desfăşurării analizei şi „lecţiile” căpătate. • Gândiţi termeni de sistem (prin elemente şi legături) nu doar în termeni de cerinţe. 3.1.3.2 Clasificarea cerinţelor Este fundamental să se realizeze o clasificare a cerinţelor prin prisma specificului lor, pentru a fi caracterizate şi detaliate uşor. În general, categoriile după care se face clasificarea sunt: • Obiecte şi proprietăţi – se deosebesc diverse obiecte lumea reală, se împart în categorii şi se exprimă caracteristici generice pentru fiecare categorie de obiecte (adică proprietăţile ale acestora). Categoria de obiecte va deveni un tabel, un obiect anume devine o linie din tabel, o proprietate devine o coloană în tabel, o anume proprietate a unui obiect devine o valoare. • Obiective operaţionale – exprimă scopurile urmărite prin introducerea SI precum şi modurile în care se pot atinge. Ele se referă la „ce se doreşte” şi „cum se poate obţine”. • Reguli de lucru (denumite şi „reguli de gestiune”) – sunt condiţii şi restricţii impuse proprietăţilor (privind limitele valorilor, cazuri speciale ale lor în relaţiile între obiecte), sau impuse prelucrărilor (ordinea lor, evenimente care le declanşează). O regulă se exprimă prin cuvinte ca „... trebuie ...”, „... se va face... ”, „... respectă strict...”. • Preferinţe – sunt condiţii recomandate proprietăţilor obiectelor sau acţiunilor, care se exprimă prin cuvinte ca „... se recomandă ...”, „... pe cât posibil... ”, „... este indicat ca...”.

22

3.1.3.3 Corelarea cerinţelor Cerinţele formulate nu sunt nici sentinţe nici cugetări disparate. Înţelegerea corectă a cerinţelor impune combinarea lor în contextul comun al obiectivelor SI; din această combinare rezultă noi legături (relaţii) între obiecte şi acţiuni dar pot rezulta chiar schimbări de principiu în realizarea SI. 3.1.3.4 Stabilirea de priorităţi între cerinţe Unele cerinţe sunt vitale funcţionării SI sau siguranţei mediului şi personalului, altele sunt minore. Priorităţile stabilite între cerinţe se poate face pe o scară de valori după care să fie tratate; în cazul în care unele cerinţe minore complică sistemul, se renunţă la ele sau se prevăd pentru dezvoltări viitoare. Alegerea priorităţilor trebuie să ţină cont şi de găsirea soluţiei optime, deci cerinţele care duc la un optim de funcţionare sau utilizare a SI nu sunt minore. 3.1.3.5 Reprezentarea şi formalizarea obiectelor şi interacţiunilor După ce s-au stabilit cu precizie obiective, cerinţe, obiecte şi interacţiuni este utilă o reprezentare grafică a ansamblului acestora. O imagine este adesea intuitivă şi mult mai explicită ca o descriere text a unui fapt sau unei situaţii. În analiza sistemului informaţional ţintă se vor discrimina: • fluxuri (de materiale, de energii, de informaţii), cum sunt: produse în stoc, facturi, bonuri de livrare, etc.; • entităţi ale lumii exterioare: clienţi, furnizori; • structuri organizatorice; • legi, reglementări: contracte, reguli contabile; Reprezentarea grafică a părţilor şi întregului sistem ţintă ajută la înţelegerea şi la corectarea modului de abordare a SI, dar operaţiunile care le va executa acesta pot fi transpuse în programe numai dacă se cunosc cu precizie şi sunt formalizate Datele cu care lucrează sistemul informaţional se constituie într-un model al datelor ce formalizează structura şi legăturile dintre date (adică produce o structură conceptuală exprimată prin simboluri). Formalizarea prelucrărilor produce un model al prelucrărilor (o schemă de acţiune). Activitatea de formalizare face parte din analiza sistemului informaţional: Exemple: date formalizabile - informaţii asupra unor clienţi; date neformalizabile - date meteorologice, date imprecise sau incerte. Prelucrări formalizabile - editarea unei facturi, calcule matematice; prelucrări neformalizabile - soluţii cu calcule în volum foarte mare sau necunoscut. 3.1.3.6 Stabilirea metodologiei urmărite la realizarea SI Analiza de sistem necesită o metodă generală de abordare pentru că apar probleme din caracteristicile foarte variate ale informaţiilor (unele modele sunt adecvate, altele nu). Fiindcă apar dificultăţi şi datorită persoanelor implicate în proiect (proiectanţi, analişti) trebuiesc abordate şi din punct de vedere organizaţional conducerea şi implementarea proiectului cu o metodă anume. Exemple de situaţii care au apărut ca urmare a lipsei de metodă: - programele nu realizează ce s-a dorit; - programele nu pot fi modificate (dezvoltate) pentru noi cerinţe; - studiile sunt corecte şi logice pe hârtie şi nu pot fi aplicate în practică; - programele dau rezultate corecte dar în timp prea lung; - informatizarea perturbă activitatea umană; Întrebări la care se răspunde pentru a găsi o metodă: 1. cum se poate realiza un caiet de sarcini (specificaţii) care să descrie exact scopul informatizării, ce metodă de analiză este adecvată? 2. Cum se poate realiza un sistem de programe conform caietului de sarcini? – ce metodă de implementare se va folosi?

23

De obicei, metoda după care se realizează analiza de sistem face parte din metodologia generală adoptată pentru realizarea SI. De aceea, chiar în faza de analiză se fac mai multe treceri prin etapele indicate mai sus, spre a rafina cunoştinţele şi a găsi cea mai bună cale de a realiza cu succes Sistemul Informatic vizat.

3.2 Tehnici de reprezentare grafică a Sistemelor Informatice
După realizarea analizei sistemului ţintă este necesară o reprezentare grafică, intuitivă, care are următoarele scopuri: - o inventariere preliminară a acţiunilor şi datelor; - o reprezentare a legăturilor dintre ele într-un mod vizibil şi inventiv; - obţinerea unei viziuni de ansamblu asupra sistemului. 3.2.1 Scheme logice

Prelucrările din sistem se pot ilustra comod prin scheme logice, cu simboluri grafice în Figura 3-2 Operaţiunile ce trebuie descrise, apar ca succesiuni de blocuri de prelucrare
Stop procedură

Start

Start procedură

Stop

A=B+C

Bloc de atribuire

Bloc de intrare/ieşire

Citeşt e B,C

Exemplu bloc de intrare date

Bloc de decizie binară

DA X>B

NU

Sortare Apel la un subprogram Sortare

Figura 3-2 Simboluri în reprezentarea schemelor logice. Pe exemplul de gestiune a stocurilor de mai sus, se poate realiza o schemă logică pentru cazul în care se doreşte afişarea datelor despre un reper (material) solicitat: 1. Se lansează aplicaţia de gestiune a stocurilor. 2. Se deschide fişierul stoc. 3. Se introduce codul materialului căutat. 4. Dacă nu s-a găsit - afişează eroare şi sari la 6; altfel (s-a găsit) continuă cu 5. 5. Se afişează date despre material (cantitate, calitate, loc de depozitare. 6. Se doresc late informaţii? Dacă da sari la 3; altfel continuă cu 7. 7. Se închide fişier. 8. Se închide aplicaţia. 3.2.2 Diagrame globale (scheme bloc)

Schema bloc se bazează pe setul de simboluri din Figura 3-3, şi indică la nivel conceptual, în mod simplificat, succesiunea de operaţiuni şi obiectele asupra cărora se acţionează.
24

Fişier

Document

Bloc de prelucrare

Succesiune

Figura 3-3 Simboluri grafice pentru ilustrarea Sistemului Informatic ca schemă bloc. În exemplul din Figura 3-4 se prezintă o aplicaţie de gestiune a stocurilor pentru o magazie, pe baza Notelor de Intrare Recepţie (NIR), a Bunurilor de Consum (BC) şi a Contractelor de Aprovizionare (CTA).

NIR

Gestoc

Stocuri

BC

Situaţia Stocurilor

Comandă

Procesare Comenzi CTA

Furnizori

Fişiere Furnizori

Figura 3-4 Modelul unui Sistemului Informatic de gestiune a stocurilor 3.2.3 Flux pe orizontală

Este o formă de prezentare în care se folosesc următoarele convenţii de reprezentare: - fiecare document se găseşte pe o linie de nivel orizontală; - fiecărui document i se trec cronologic toate operaţiile suportate din momentul intrării în SI până în momentul arhivării sau distrugerii; - se reprezintă schematic operaţiile şi influenţele unor documente asupra altora fiind acordată atenţie eliminării unor documente şi eventual schimbării traseelor informaţiilor în momentul utilizării SI. Diagrama este de fapt un tabel ce conţine drept coloane: Nr. curent, Nume document, Periodicitate de completare, Forma, Observaţii (lămuritoare la scopul şi utilitatea documentului). În cadrul tabelului se trec documentele şi operaţiunile şi diagrama însoţitoare dă imaginea de ansamblu a acestora. Simbolurile utilizate sunt ilustrate în Figura 3-5. Diagramele întocmite ilustrează structurile de prelucrare specifice sistemului informatic şi sunt utile în proiectarea bazelor de date şi a modulelor program (sau a interogărilor) ce reprezintă de fapt prelucrările dorite.
25

Factura

Document de intrare

Afişare (pe ecran sau hârtie)

Punere în aşteptare

Manipulare

Punere în circulaţie

Arhivare

Verificare

Figura 3-5 Simboluri în reprezentarea de fluxuri pe orizontală.

3.3 Modelul Conceptual al Datelor
Modelul conceptual al datelor (MCD) se referă la identificarea entităţilor tip şi atributelor generice ale acestora ca şi concepte prin care se poate modela o zonă a realităţii umane. Urmare a acestui model, se poate constitui modelul logic al datelor (MLD) – util în faza de proiectare a aplicaţiei apoi modelul fizic al datelor (MFD) – care reprezintă tabelele cu structuraşi datele specifice aplicaţiei ce utilizează mediul SGBD. Procesul de realizare a MCD se bazează pe strategia descendentă (top-down) şi are drept scop descrierea conceptuală a datelor folosite în cadrul organizaţiei – fără a da atenţie detaliilor de implementare, apoi descrierea conceptuală a prelucrărilor – în termeni generici de tipul „achiziţie”, „plată”. Aceste descrieri conceptuale se vor detalia ca obiecte sau tabele, respectiv ca funcţii cu restricţii şi cerinţe specifice de prelucrare. În principal, modelul conceptual al datelor priveşte identificarea de: • Entităţi (persoane, locuri, lucruri) cu care are de a face organizaţia; • Atribute – ca informaţii specifice care caracterizează sau descriu entităţile; • Relaţii – ca legături ce există între entităţi în realitate, şi care trebuie luate în considerare în contextul scopului urmărit. Spre exemplu, la o firmă vânzătoare de automobile, entităţi vor fi maşinile – cu proprietăţi ca marcă, tip, culoare, facilităţi, apoi clienţii – cu caracteristici ca nume, prenume, adresă, preferinţe; legătura dintre cele două entităţi o reprezintă chiar comanda/achiziţia de către client a unui (sau mai multor) automobil(e). 3.3.1 Entitate, atribut, relaţie şi restricţii

3.3.1.1 Entitate Entitatea este un obiect concret sau un concept abstract din zona realităţii care se doreşte modelată şi gestionată prin SI. Orice entitate este asociată unui tabel. În principiu o entitate reprezintă o categorie de obiecte sau de documente din realitate, însă în realizarea Sistemului Informatic, o entitate poate fi şi o interacţiune între două obiecte concrete din realitate. Astfel, o firmă comercială operează cu entităţi cum sunt PRODUS şi FIRMA – ca obiecte concrete din realitate dar şi cu entitatea FACTURA – care reprezintă de
26

fapt interacţiuni cu firme furnizor şi client, adică relaţia firmei în cauză cu aceste două categorii de firme. După cum se constată din acest exemplu, entitatea reprezintă obiectul generic şi de aceea se recomandă ca numele entităţii să indice numele obiectului la singular. O entitate poate fi: • independentă sau tare – dacă nu se bazează pe o altă entitate pentru a fi identificată (referită); • dependentă – în caz contrar. O instanţiere a unei entităţi este un obiect concret din categoria pe care o reprezintă entitatea, adică este o linie din tabelul asociat entităţii. Aşa cum s-a arătat mai sus, există mai multe tipuri de entităţi: • entităţi tip – care sunt utilizate să reprezinte efectiv categorii de obiecte din lumea reală, cum sunt PRODUS, COMERCIANT; • entităţi subtip – care provin din ierarhii de generalizare, cum sunt FURNIZOR şi CLIENT, ca entităţi fii ale entităţii părinte COMERCIANT; • entităţi asociative – care sunt utilizate la asocierea altor două sau mai multe entităţi, cum este entitatea FACTURA; 3.3.1.2 Atribut Un atribut indică o proprietate a unei entităţi (adică a categoriei de obiecte), ce indică o caracteristică prin care obiectele din acea categorie se deosebesc unele de altele. De exemplu, pentru entitatea produs atributul DENUMIRE indică produsul, atributul PRET indică costul unitar, al unui anume produs, etc. Fiecare atribut ia o valoare anume, într-un domeniu de valori bine specificat: DENUMIRE este un şir de caractere, PRET este un număr. Atributele pot fi clasificate în două categorii: • Atribut identificator (de referire), denumite şi cheie – prin care se identifică un obiect din tabel; asemenea atribute sunt numele obiectelor, sau codurile de identificare: numărul de legitimaţie pentru persoane, codul de produs, etc. • Atribut descriptiv (de informaţie) – prin care se indică o proprietate a obiectului, proprietate care se poate regăsi şi la alte obiecte din tabel. Atributul cheie care identifică unic un obiect din tabel – cum este de exemplu un cod de identificare produs, se numeşte cheie primară. Atunci când într-un tabel apare un atribut cheie primară din alt tabel, ele este denumit cheie externă sau cheie străină. O cheie compusă este aceea formată din două sau mai multe atribute cheie – necesară în cazul când celelalte atribute nu depind doar de una din chei. De exemplu, identificarea unei facturi se poate face unic prin codul de COMERCIANT şi DATA emiterii facturii (deci prin două atribute). 3.3.1.3 Relaţie Sensul general al relaţiei, în contextul bazelor de date relaţionale, este acela de legătură între obiecte: • de acelaşi tip – care formează împreună o colecţie (ca tabel) şi indică o entitate, • tipuri diferite – care interacţionează în contextul real ce se doreşte informatizat (ca asociere). În continuare, se va considera conceptul de relaţie în a doua accepţie, adică relaţia este asocierea între entităţi. Concret, relaţia între două entităţi se realizează pe baza unui câmp comun (un atribut ce apare în ambele tabele), de obicei un câmp cheie al unui tabel apare drept cheie externă în celălalt tabel. De exemplu, în tabelul FACTURI apare codul de COMERCIANT spre a indica sursa sau destinaţia facturii; acest cod împreună cu data facturii vor reprezenta cheia unei facturi instanţiate (concrete). Relaţia se exprimă printr-un verb care exprimă interacţiunea dintre cele două entităţi în realitate. Relaţiile se clasifică după criterii de grad, conectivitate, cardinalitate, tip şi existenţă: • Gradul unei relaţii este numărul de entităţi asociate în relaţie. O relaţie n-ară este o relaţie generală de grad n; cazuri particulare sunt relaţii binare (2-are), ternare (327

are), etc. Gradul cel mai uzual în relaţie este 2, relaţiile ternare sau n-are fiind descompuse în relaţii binare succesive între entităţi. Există însă şi relaţii unare, adică relaţii recursive aplicate doar unei singure entităţi; de exemplu, relaţia „este şef al” peste entitatea ANGAJAT este aplicată unor angajaţi subordonaţi unui angajat – şeful acestora. • Conectivitatea unei relaţii caracterizează numărul de obiecte efective ale unei entităţi care intră în relaţie cu un singur obiect al unei alte entităţi - luate ca referinţă. Conectivitatea nu se caracterizează numeric ci calitativ, prin valori „unu” şi „mulţi”. • Cardinalitatea unei relaţii este de fapt conectivitatea minimă şi maximă a unei relaţii, adică numărul minim de obiecte şi numărul maxim de obiecte ce se intră în relaţie cu un obiect ale entităţii referinţă. O relaţie unu-la-unu (1:1) este aceea în care un obiect ale entităţii de referinţă este în relaţie cu cel mult un obiect ale celeilalte entităţi. De exemplu, un ANGAJAT al unei firme face parte dintr-un (singur) anume DEPARTAMENT. O relaţie unu-la-mulţi (1:N) este aceea în care un obiect ale entităţii de referinţă este în relaţie mai multe obiecte ale celeilalte entităţi. De exemplu, un DEPARTAMENT al unei firme are ca salariat mai mult de un ANGAJAT. O relaţie mulţi-la-mulţi (M:N) este o relaţie nespecifică, adică aceea în care un obiect ale entităţii de referinţă este în relaţie nici unul, unul sau mai multe obiecte ale celeilalte entităţi. De exemplu relaţia ANGAJAT „lucrează la” PROIECT: există angajaţi care nu sunt implicaţi în proiecte (de exemplu portarul) iar un angajat poate lucra la unul sau mai multe proiecte. Pentru indicarea specifică a relaţiei se foloseşte exprimarea generală: (Numar_minim : Numar_maxim) de obiecte aflate în relaţie cu un obiect din entitatea referinţă, adică primul număr indică minimul de obiecte iar al doilea maximul de obiecte din a doua entitate ce intră în acea relaţie. În acest caz, relaţia (M:N) se va apare ca (0:N). În situaţia în care relaţia încă este de forma (M:N), atunci tabelele trebuie despicate spre a obţine relaţii unu-la-mulţi (1:N). • Direcţia relaţiei indică cine este sursa şi cine este destinaţia relaţiei, atunci când verbul indică o entitate părinte şi o entitate fiu. Direcţia este determinată de conectivitatea relaţiei: în relaţii unu-la-unu direcţia este dinspre entitatea independentă către cea dependentă; dacă cele două entităţi sunt independente direcţia este arbitrară. În relaţia unu-la-mulţi entitatea care intervine cu 1 este părinte; în relaţia mulţi-la-mulţi direcţia este arbitrară. • Tipul relaţiei: relaţie identificatoare – cea care indică o entitate fiu (dependentă), iar non-identificatoare – cea între entităţi independente. Restricţia de existenţă a relaţiei – indică dacă pentru un obiect din entitatea referinţă există cel puţin un obiect din entitatea aflată în relaţie cu ea, mai precis indică dacă relaţia este obligatori pentru toate obiectele celor două entităţi sau nu. Cardinalitatea minimă indică „existenţa” prin valoare diferită de 0 ca obligativitate, iar prin 0 ca relaţie opţională (vezi exemplul cu ANGAJAT şi PROIECT de mai sus). 3.3.2 Diagrama Entitate-Relaţie (DER)

Un rol esenţial în modelarea conceptuală a bazei de date îl are reprezentarea grafică a situaţiilor ce trebuie rezolvate pe parcursul creării noului sistem. Ca şi în construcţii, şi la realizarea Sistemului Informatic este necesară ilustrarea grafică a schemei de lucru. Imaginea grafică permite o abordare calitativă de principiu a problemei şi facilitează descoperirea erorilor sau neconcordanţelor între starea curentă a proiectului şi obiectivul vizat. Diagrama Entitate-Relaţie (DER) este un instrument foarte eficient în proiectarea aplicaţiilor cu baze de date relaţionale, astfel că este de importanţă majoră realizarea sa în mod corect şi complet. Caracteristicile DER ca model sunt:

28

• • •

Corespondenţă perfectă cu modelul relaţional – după construirea DER aceasta se poate transpune aproape direct în tabele relaţionate. Simplă şi uşor de înţeles fără cunoştinţe prea sofisticate. Modelul poate fi folosit de către proiectantul de baze date dar şi de utilizatorul obişnuit. SGBD relaţionale actuale sunt construite şi adaptate utilizării schemei de proiectare cu DER.

3.3.2.1 Simboluri grafice utilizate în DER „clasică” DER surprinde obiectele şi atributele lor precum şi relaţiile între ele în zona din lumea reală pentru care se doreşte realizarea sistemului de informatizare. Noţiunile prezentate în paragraful precedent se reprezintă prin simboluri grafice aşa ca în Figura 3-6.

Angajat

Entitate (Obiect) Entitate slabă (adică un obiect căruia nu i se poate găsi nici un atribut cheie) [student] Atribut “urmează” [disciplina] Atribut cu mai multe valori Relaţie

Nume

Strada

Atribut derivat

Marca

Atribut cheie Figura 3-6 Simboluri grafice utilizate în DER.

Restricţiile de participare specifice unei relaţii sunt indicate grafic în Figura 3-7 şi ele pot fi determinate considerând o entitate drept referinţă (în relaţia analizată) şi evaluând apoi numărul de obiecte ale celeilalte entităţi ce intră în relaţie cu un obiect a entităţii de referinţă. 1. Restricţia de participare indică la obligativitatea relaţiei: dacă un obiect al entităţii de referinţă este în relaţie cu cel puţin un obiect al celeilalte entităţi atunci participarea este totală (linie dublă) şi cardinalitatea minimă diferită de 0. Altfel participarea este parţială - linie simplă. 2. Cardinalitatea relaţiei indică numărul de obiecte instanţiate aflate în relaţia între cele două entităţi: cardinalitatea minimă şi maximă corespunzătoare (v. §3.2.3) - arată în ce măsură o entitate (ca mulţime) este legată de cealaltă entitate. totală 1:N
Urmează curs cu

parţială 1:n

Student

Profesor

Figura 3-7 Reprezentarea restricţiei de participare în DER.

29

Determinarea cardinalităţilor este utilă spre a evalua câte linii se vor afişa la o interogare ce conţine relaţii între două tabele – relativ la liniile cu valori de atribute care se repetă..

Figura 3-8 Simbolul relaţiei care nu implică un câmp cheie al uneia dintre entităţi. O relaţie care nu se realizează pe baza unui câmp cheie se reprezintă grafic ca în Figura 3-8, iar o relaţie recursivă este prezentată grafic în Figura 3-9. Student

Şef de grupă

Figura 3-9 Relaţie recursivă (aceeaşi entitate intervine în relaţie cu ea însăşi). 3.3.2.2 Un exemplu DER În Figura 3−10 este ilustrată DER pentru gestiunea informatizată a activităţii unui institut de proiectare, în care s-au discriminat entităţile ANGAJAT, DEPARTAMENT, PROIECT. Rămâne ca temă cititorului să determine care sunt structurile tabelelor, care sunt câmpurile cheie, direcţia relaţiilor şi sensul numerelor asociate cardinalităţilor relaţiilor din figură. În această diagramă se pot remarca atribute compuse (de exemplu Strada sau Nume – compus din Prenume, Nume familie şi Iniţiala tatălui) precum şi relaţii recursive (relaţia Supervizor pentru entitatea Angajat). De exemplu, pentru situaţia şcolară a studenţilor se va obţine un tabel care repetă numele studenţilor pentru fiecare cod (sau nume) de disciplină, afişând notele obţinute DER din Figura 3−10 este doar o primă formă, care nu poate fi utilizată direct în proiectarea bazei de date relaţionale, (mai precis a tabelelor şi relaţiilor dintre ele). Astfel, trebuie re-gândite atribute precum Nume şi Adresa (fiecare cu părţile sale), pentru că un tabel în baza de date relaţională nu permite coloane compuse (cu subcoloane) – acestea denumite şi „câmpuri care repetă”. Pe lângă aceste modificări necesare în date (şi în DER) sunt apoi condiţii de optimalitate ale bazei de date care vor trebui atinse şi se obţin prin normalizarea bazei de date (v. § proiectare §4.3 ).

30

Prenume

Nume familie

Strada

Localitate

Bloc

Nume Iniţiala tatălui

Adresa Nume Lucrează în

Cod Sediu

Angajat

1:1 0:1

1:N 1:1 Şef la

Departament

Vârsta 0:N Marca 0:N 0:N
Supervizor

0:N Sediu

Contractează

Lucrează pentru 1:N Întreţine pe

1:N Nume Proiect

Nume 1:1 Beneficiar Loc Cod

Întreţinut Situaţia socială Grad de rudenie Data naşterii

Figura 3-10 DER „clasică” pentru evidenţa activităţii unui institut de proiectare. 3.3.2.3 Al doilea exemplu DER Pe parcursul de până acum al prezentării s-a folosit des exemplul de evidenţă a situaţiei şcolare a studenţilor într-o facultate. Pentru acest caz, DER este prezentată în Figura 3-11. Lăsăm chiar studentului cititor analiza (şi înţelegerea) acestei diagrame.

31

Prenume

Nume

StradaNr

Nume

MarcaProf

Nume

Adresa N:M

Localitate

Cod N:M Disciplina 0:N

NrOreCurs

Student NrLeg

urmează

predă

1:N Profesor

Marca

Nume

Titlu

Prenume

Figura 3-11 DER „clasică” pentru evidenţa situaţiei şcolare a studenţilor.

3.4 Realizarea MCD
Modelul conceptual al datelor (MCD) se referă la identificarea conceptuală a entităţilor tip şi atributelor generice ale acestora prin care se poate modela o zonă a realităţii umane. Acest model (uzual fiind entitate - relaţie) este necesar la constituirea modelului logic al datelor (MLD) şi modelului fizic al datelor (MFD) adică la constituirea tabelelor şi ulterior la încărcarea şi utilizarea lor printr-un mediu SGBD relaţional. 3.4.1 Dependenţe funcţionale ţi tranzitive

O dependenţă funcţională se referă la faptul atributele entităţilor depind unele de altele, astfel cum depind în fapt în situaţia reală pe care o reprezintă baza de date. Trebuie reamintit, din nou, că „relaţie” înseamnă atât tabel cât şi legătură între tabele – conform abordării relaţionale a bazelor de date, tocmai pentru că acestea se pot generaliza prin termenul de relaţie. Rezultă deci că într-o relaţie câmpurile sunt într-o dependenţă în care un câmp (atribut) este determinant şi altul determinat v. Figura 3-12. De exemplu, câmpul Nume în tabelul Student este dependent de câmpul NrLeg pentru că de fapt numărul de legitimaţie identifică un student în registrele de evidenţă ale organizaţiei şi prin acesta se poate apoi obţine numele studentului; acesta este un exemplu de dependenţă funcţională în cadrul aceluiaşi tabel. Un exemplu de dependenţă funcţională între câmpuri ale două tabele diferite este următorul: Nota, obţinută de un student la o disciplină
32

anume, înscrisă în tabelul FişaStudent este dependentă de acea disciplină, deci de codul ei înscris în tabelul Disciplina. R B. Atribut (câmp) Determinat (dependent)

A. Atribut (câmp) Determinant (cheie)

Figura 3-12 Câmpuri în dependenţă funcţională. Dependenţa funcţională poate fi definită în general astfel: atributul B în relaţia R este dependent funcţional de atributul A al relaţiei R dacă pentru orice situaţie concretă (instanţă) în care atributele A şi B apar în tabelele din baza de date valoarea lui A indică una şi numai valoare a lui B (v. şi Figura 3-12). Cheia primară se poate defini în termeni de dependenţă funcţională: o cheie primară este unul (sau mai multe) atribut(e) cu proprietăţile 1) toate atributele care nu sunt parte a cheii sunt dependente funcţional de atributul cheie, 2) dacă cheia primară este compusă din mai multe atribute nici un subset al acesteia nu are proprietate 1). Prin conceptul de dependenţa funcţională se pot caracteriza asocieri sau relaţii între atribute, aşa cum se prezintă în Figura 3-13. Relaţiile între entităţi pot fi acum înţelese mai bine prin prisma dependenţelor funcţionale: de fapt două entităţi sunt în relaţie pentru că atributul cheie al unei entităţi este în relaţie cu atribute (eventual cheie) ale celeilalte entităţi.

A

1:1

B

Asocierea 1:1 indică o dependenţă funcţională în care doar o instanţă B depinde de una A Asocierea 1:N indică o dependenţă funcţională în care mai multe instanţe B depind de una A Asocierea 0:1 indică o dependenţă funcţională în care există instanţe B care nu depind de A

A

1:N

B

A

0:1

B

Figura 3-13 Asocieri de atribute exprimate ca dependenţe funcţionale. Dependenţele funcţionale se identifică iniţial între atribute şi stabilesc modul în care aceste atribute se vor structura pe entităţi. Există un set de reguli prin care plasarea atributelor la entităţi să permită realizarea unei baze de date consistente (fără confuzii şi fără eventuale asocieri eronate). Între atribute ale relaţiilor pot apare însă şi aşa-numite dependenţe tranzitive, care trebuie cunoscute şi specificate ca atare. O dependenţă tranzitivă apare atunci când un atribut non-cheie este dependent de un al atribut non-cheie, ultimul fiind însă dependent de cheia primară. De exemplu, în DER din Figura 3-10 la entitatea Proiect atributul Loc este dependent de atributul Beneficiar (la rândul său dependent de Cod proiect – care este câmpul cheie). 3.4.2 Reguli de structurare a MCD În realizarea MCD se respectă următoarele reguli:
33

Regula de unicitate a numelor aplicabilă oricărei categorii de obiecte (entitate tip, atribut, relaţie) – prin care un nume o dată folosit nu se mai repetă. - Regula unicităţii atributelor (neredundanţei) – un atribut nu trebuie să se găsească în 2 entităţi. Această regulă se va respecta aplicând matricea dependenţelor funcţionale . - Regula de unicitate a relaţiilor – pentru fiecare asociere nu poate să existe decât o singură realizare a fiecărei entităţi în acea relaţie. Ca urmare, se elimină relaţiile M:N şi, de obicei, se înlocuiesc cu relaţii 1:N. - Regula proprietăţilor şi determinantului unei proprietăţi: dacă un atribut depinde de mai mulţi determinanţi (aceştia reprezentând identificatori ai mai multor entităţi) atunci el ar trebui să definească tipul de relaţie între aceste entităţi. - Atribute derivabile sunt acele atribute obţinute prin calcul din alte atribute (existente în entităţi, tabel) şi ca atare atributul nu trebuie să constituie un câmp din structura tabelului ci un câmp adăugat, calculat (rezultat al unei interogări cu agregare pe orizontală). - Atribute decompozabile - anumite atribute (ex. Nume = Nume & Prenume & Iniţiala tatălui sau Adresa = Strada & Bloc & Localitate) nu trebuie păstrate în forma lor uzuală ci trebuie divizate în mai multe atribute independente. Urmare a aplicării acestor reguli se obţine pentru exemplul evidenţei situaţiei studenţilor o DER ca în Figura 3-15. Se observă că nu mai există câmpuri compuse (de ex. Nume) şi că sa introdus o nouă entitate FişaStudent, cu relaţii între aceasta şi entităţile Student şi Disciplina. Noua entitate a fost necesară pentru a se elimina relaţia directă „urmează” cu cardinalităţi N:M dintre entităţile Student şi Disciplina. Această relaţie încă figurează în DER prezentată, doar pentru a se observa cum şi din ce motiv s-a transformat DER prin introducerea noii entităţi.

-

Nume Nume StradaNr Cod N:M

MarcaProf

Prenume Student NrLeg 1:N ·· 1:1 N:M

Localitate urmează

NrOreCurs

Disciplina 1:N 0:N

interacţiune

·· predă

FişaStudent

1:1

NrLeg

NotaEx

1:N Profesor

Cod

NotaLab Marca Nume

Titlu

Prenume

Figura 3-14 DER pentru evidenţa situaţiei şcolare a studenţilor – modificată.
34

Se poate emite o regulă generală de „spargere” a relaţiilor N:M făcând observaţia că asemenea relaţii „produc date”, deci reprezintă de fapt interacţiuni cu anume rezultate între entităţile relaţionate. Astfel, interacţiunea Student-Disciplina produce notele obţinute de student la disciplinele urmate, note care trebuie „salvate” într-un tabel pentru că nu sunt câmpuri calculate (atribute derivate) ci sunt date primare. Relaţia „urmează” s-a transformat în entitatea FişaStudent şi în două relaţii noi (care nu sunt denumite ci indicate prin ...); se observă că această nouă entitate are un câmp cheie compus, format din cheile externe NrLeg (cheie în tabel Student) şi Cod (cheie în tabel Disciplina). Entităţile vor fi reprezentate în baza de date relaţionale ca tabele, însă aceste tabele au o structură „plată” (flat tables), în sensul că toate atributele se înşiruie drept coloane independente (fără subcoloane) şi în ordine aleatoare (ordinea nu trebuie să fie importantă). Refacerea DER spre a satisface regulile indicate duce la această structură de tabel. În Figura 3-15 se prezintă DER pentru cazul de evidenţă a activităţii unui institut de proiectare, la care – în plus faţă de DER obţinută în Figura 3-14, se foloseşte o reprezentare care scoate în evidenţă structura „plată” de tabel indicată.

Angajat Marca Nume Prenume Localitate StradaNr Vârsta 1:N întreţine 1:1 Întreţinut Nume Prenume GradRudenie DataNaşterii SitSocială

1:1 încadrat la 1:N ·· 1:1 FişaAngajat CodDept Marca Norma Stadiu 1:N

1:N

Departament CodDept Nume Sediu Şef

Proiect CodProiect ·· Nume Beneficiar 1:N Loc Buget

Figura 3-15 DER pentru evidenţa activităţii unui institut de proiectare. Această reprezentare a DER este evident mai simplu de desenat şi de aceea este cea recomandată. Este, de asemenea, recomandat ca fiecare relaţie să aibă un nume, dar rămâne în sarcina cititorului să dea nume relaţiilor pe care entitatea FişaAngajat le are cu entităţile Angajat şi Proiect şi care sunt indicate în Figura 3-15 doar prin ... 3.4.3 Paşi de urmat pentru realizarea MCD

Modelul conceptual presupune faptul că datele sunt reprezentate ca „relaţii” (în accepţia relaţională şi a algebrei relaţionale); ca atare nu trebuie specificat cum anume se vor implementa la nivel fizic. Această inovaţie (care a apărut prin anii ‘70) permite adăugarea de câmpuri calculate în tabele care de fapt sunt doar vizualizate şi aceste câmpuri nu sunt efectiv stocate în tabelele fizice (în fişiere pe disc); în plus, se obţine o independenţă de lucru privind
35

tabele stocate şi tabele care se obţin doar în urma unei prelucrări (de exemplu de sortare a unor linii ce satisfac o condiţie dată). Tabelele sunt astfel de două categorii: tabele de bază (stocate fizic pe disc) şi tabele rezultat (vizualizat ca urmare a unei prelucrări) dar faptul că ele sunt privite toate ca „relaţii” permite ca un tabel obţinut după o operaţie să fie folosit ca intrare în altă operaţie; altfel spus sursa de date poate fi nu doar tabelul fizic stocat pe disc (de bază) ci şi tabelul rezultat (de vizualizare). Pentru a concluziona, se inventariază mai jos paşii care trebuie urmaţi pentru obţinerea modelului conceptual – ca rezultat al etapei de analiză. Pasul 1. Se inventariază entităţi şi atribute, preluându-le din diverse documente sau prin interviu cu persoane implicate în domeniul de informatizat. Documentele de unde se pot prelua informaţii sunt nomenclatoare (de exemplu de materiale), liste (de furnizori, de clienţi), centralizatoare (de facturi, chitanţe). Pasul 2. Se întocmeşte dicţionarul de date – adică atributele obţinute la pasul 1 se înscriu într-o listă în care se explică rolul fiecărui atribut, având grijă ca un atribut să apară o singură dată şi eliminând atribute sinonime. Respectând această regulă se evită confuzii de câmp – cum ar fi atributul Cod la entităţile Departament şi Proiect, incorecte în DER din Figura 3-10 dar înscriu corect drept CodDept şi CodProiect în DER din Figura 3-15. În dicţionarul de date nu se înscriu câmpuri calculate – adică acele câmpuri ale căror valori rezultă printr-o prelucrare oarecare; un asemenea caz este câmpul Vârsta angajatului (v. Figura 3-15), care se poate calcula folosind data naşterii (ce ar trebui inclusă între atribute) şi data curentă (preluată de la ceasul sistemului) însă a fost admisă în exemplele de mai sus pentru a figura şi date numerice între majoritatea celorlalte care sunt de tip text. Pasul 3. Se stabilesc dependenţele între atribute. Dependenţele se înscriu într-un graf de dependenţe funcţionale – reprezentate prin săgeţi cu linie continuă iar dependenţele tranzitive prin săgeţi cu linie punctată (v. pentru DER din Figura 3-15). Nume CodProiect Beneficiar

Buget

Loc

Figura 3-16 Graful dependenţelor. Pasul 4. Pentru toate atributele ne-dependente (izolate) se caută atribute sau grupuri de atribute ce pot fi determinanţi ai acestora. Pasul 5. Atributele sau grupurile de atribute determinanţi pentru alte atribute sunt „chei candidat”; se stabilesc dependenţe funcţionale reciproce între cheile aceluiaşi atribut. Pasul 6. Se stabilesc cheile primare – atributele care pot identifica unic instanţe ale entităţilor (adică ce corespund unor obiecte anume din viaţa reală şi care vor apare în tabele) şi se stabilesc atributele care vor fi dependente de cheia primară pentru fiecare entitate. La acest pas se stabilesc de fapt ce câmpuri (coloane) ar putea avea fiecare tabel (capul de tabel). Pasul 7. Se stabilesc cheile externe, adică acele atribute care apar la o entitate dar sunt chei primare la alta. Pasul 8. Se stabilesc relaţiile între entităţi, pe baza dependenţelor între atribute. Pasul 9. Se realizează Diagrama Entitate-Relaţie (DER) – de preferat în forma cu entităţi şi atribute prezentate ca în Figura 3-15.

36

3.5 Limbajul Unificat de Modelare (UML)
Până în anii 1990, se considera că activitatea de analiză şi proiectare este specifică tipului de aplicaţie vizat – de exemplu aplicaţie de rezolvare a unei probleme economice (realizată cu baze de date) sau aplicaţie de rezolvare a unei probleme de automatizare (realizate cu programe în limbaj de nivel mediu sau jos). După apariţia programării orientate obiect (OOP) s-au dezvoltate metode de analiză specifice acestei abordări, cum sunt - OMT (Object Modeling Technique) – iniţiată de James Rumbaugh, - OOD (Object Oriented Design) – iniţiată de Greedy Booch, - OOSE (Object-Oriented Software Engineering) – iniţiată de Ivar Jacobson. În deceniul 1990, s-a constatat că metodele de analiză şi proiectare orientate obiect au un grad de generalitate foarte mare şi pot fi folosite în diverse domenii şi în abordări care nu erau orientate obiect. Mai mult cele trei metode amintite aveau diferenţe de nuanţă sau se completau în multe privinţe, dar lumea era divizată între cele trei metode de abordare. Această situaţie de conflict a fost rezolvată după 1997, când se înfiinţează Limbajul UML constă din setul de concepte şi notaţii privind structura şi funcţionarea unui sistem din lumea reală, spre a fi modelat şi reprezentat grafic în mod intuitiv şi lucrativ – adică uşor de înţeles şi de transpus într-un sistem informatic. Descrierea sistemului din lumea reală se face printr-o serie de diagrame care se referă la: - activităţi, - cazuri de utilizare, - clase, - colaborare, - componente, - exploatare, - obiecte, - secvenţă, - stări. Aceste diagrame pot fi împărţite în 3 categorii: diagrame statice – care descriu structura şi responsabilităţile sistemului informatic (diagramele de cazuri de utilizare, clase, obiecte), diagrame dinamice – care descriu comportamentul şi interacţiunile care au loc între diverse entităţi în cadrul sistemului informatic (diagrame de activităţi, colaborare, secvenţă, stări, cazuri de utilizare) şi diagrame arhitecturale – care descriu componentele executabile ale sistemului şi determină locaţiile fizice de execuţie şi nodurile de stocare a datelor (diagrame de componente, de exploatare). 3.5.1 Noţiuni şi notaţii pentru entităţi

Vocabularul UML conţine noţiuni care referă obiecte şi relaţii între acestea, pe care le reprezintă grafic şi le combină în diagrame corespunzătoare structurilor sau acţiunilor vizate. Cele trei noţiuni importante, în contextul realizării aplicaţiilor cu baze de date, sunt (termeni sunt daţi întâi în engleză pentru a fi recunoscuţi uşor în literatura în domeniu): a. Things – entităţi sau repere b. Relationships – relaţii c. Diagrams – diagrame Entităţile sunt, evident, noţiunile cele mai importante în abordarea noastră, şi de aceea se vor prezenta scurt câteva categorii şi apoi reprezentarea grafică în Figura 3-17: i) Structurale (structural things) ii) Comportamentale (behavioral things) iii) De grupare (grouping things) iv) De adnotare (annotational things).

37

Entităţi structurale sunt cele care pot asimilate cu obiecte din lumea reală şi corespund entităţilor din abordarea „clasică” a DER. Totuşi, o diferenţă esenţială este aceea că entitatea în accepţia UML este o clasă – aşa cum este ea înţeleasă în abordarea obiectuală. Astfel, entitatea / clasa va fi descrisă nu doar prin structurile de date (valori) proprii – denumite atribute, ci şi prin acţiunile pe care ea le poate efectua (prelucrări) – denumite metode.

Clasă (class) Ispelling Nume clasă (Ex: Fereastra) Atribute (Ex: origin size) Operaţii sau Metode (Ex: open() close() move() display()
Interfaţă (interface) – reprezintă descrierea completă a comportării vizibile extern a unei clase sau component (ataşată de acea clasă sau de component) Figura 3-17 Reprezentarea UML a clasei (entitate structurală). În Figura 3-1 se prezintă succint noţiunile şi reprezentarea UML a clasei, pe un exemplu foarte la îndemână oricărei persoane ce lucrează cu calculatorul: fereastra (window) uzuală afişată pe ecran, în care se prezintă informaţii specifice unei aplicaţii actuale. 3.5.2 Noţiuni şi notaţii pentru relaţii

Notaţiile pentru relaţii între entităţi sunt specifice categoriei relaţiei, aşa cum se prezintă în continuare şi se reprezintă grafic în Figura 3−18: • • • • Dependenţă (dependency) – unul depinde de altul semantic; Asociere (association) – conexiune între obiecte: agregare (romb simplu - open), compoziţie (romb umplut), cu multiplicitate (câte obiecte de un fel – cel apropiat, pot fi legate de unul de felul celălalt); Generalizare / specializare sau moştenire (tată - fiu) – săgeată deschisă Realizare – relaţii între clasificatori: când un clasificator specifică un contract către altul care garantează acesta.

38

Dependenţă 0..1 Agregare *

0..1 Asociere simplă * Compoziţie Realizare

Generalizare

Figura 3-18 Reprezentarea UML a relaţiilor între entităţi. Cardinalităţile de participare în relaţie a entităţilor (în UML denumite multiplicităţi) se reprezintă oarecum similar cu cele din DER, cu următoarele deosebirile (vezi Figura 3-18): separatorul dintre cardinalitatea minimă şi maximă este ‘..’ şi nu ‘:’, iar multiplul N („mulţi”) este reprezentat prin ‘*’. Se face observaţia că relaţia „mulţi la mulţi” (N:M în DER) se reprezintă simplu ca un singur asterics ‘*’. * * * 1..1 FisaStudent Cod NrLeg NotaEx NotaLab 1..1 «referă» Disciplina * Cod Nume Marca NrOreCurs 0..* «sef de grupa» «se informează de la» «predă» * Angajat 1..1 Marca 1..1 «este un» Functia Adresa Vechime 1..1 «este un» Profesor 1..1 Marca Nume Prenume Titlu

Student NrLeg Nume Prenume Localitate *

«deţine»

* PersTESA Marca Meseria Postul LocMunca

Figura 3-19 Diagrama de clase UML pentru evidenţa activităţii într-o universitate. 3.5.3 Exemplu de diagramă de clase

În Figura 3-19 se prezintă o diagramă de clase UML adecvată exemplului de evidenţă a situaţiei şcolare a studenţilor, care a fost completată cu elemente ce ţin şi de structurile interne de personal ale universităţii. Analiza şi înţelegerea diagramei este un exerciţiu util şi uşor.

4 Proiectarea Bazei de Date relaţionale
Obiectivele unui proiectări de calitate a bazei de date relaţionale se referă la corectitudinea sa şi la construirea eficientă (cu consum minim de timp şi resurse). Aceste obiective sunt:

39

• Baza de date să ofere informaţii conform cerinţelor deja definite ale beneficiarului dar şi informaţii ad-hoc (care sunt cerute pe loc chiar după darea în exploatare a aplicaţiei). • Tabelele să fie construite corect şi eficient, fiecare reprezentând o singură categorie de obiecte, să fie compuse fiecare din câmpuri distincte (ne-repetate) iar datele în tabele să nu fie redundante (acelaşi coloane să u se repete în două sau mai multe tabele); fiecare obiect dintr-un tabel să fie identificat unic prin intermediul unei valori dintrunul sau mai multe câmpuri (cheie primară). • Baza de date să asigure integritatea datelor la nivel de câmp, tabel şi relaţie. Aceste nivele de integritate garantează că structurile de date şi valorile lor vor fi corecte şi precise în oricare din situaţiile de utilizare a bazei de date şi a aplicaţiei. • Baza de date să satisfacă regulile de gestiune relevante ale organizaţiei. Regulile de gestiune sunt de fapt restricţii uzuale asupra datelor şi asupra utilizării lor, impuse de însuşi domeniul în care se aplică baza de date sau de uzanţe ale organizaţiei. • Baza de date să permită dezvoltarea ulterioară, adică să permită creşterea volumului de informaţie şi de prelucrare pe măsură ce activitatea organizaţiei se extinde. Beneficiile unei proiectări de calitate sunt: • Structura bazei de date se poate modifica şi întreţine uşor; modificări asupra unui câmp nu necesită (nu provoacă) modificări asupra altor câmpuri sau tabele. • Datele se modifică uşor, iar valorile noi nu produc efecte nedorite în baza de date. Modificarea unui valori se face o singură dată, şi nu în mai multe locuri (tabele). • Informaţia se regăseşte uşor iar interogarea bazei de date se face uşor pentru că tabelele sunt construite bine şi relaţiile între tabele sunt corecte. • Aplicaţiile pentru utilizator se construiesc uşor, pentru că apar puţine probleme de manipulare a datelor atunci când ele sunt bine structurate în tabele cu relaţii între ele. Proiectarea bazei de date urmărind o metodologie corectă conduce la dezvoltarea aplicaţiilor de baze de date cu costuri reduse şi permite o utilizare comodă şi eficientă a bazei de date.

4.1 Reguli de Gestiune
Producere, transferul şi manipularea datelor în cadrul unei organizaţii sunt supuse anumitor reguli, cerinţe şi restricţii care trebuie respectare şi în cadrul modelului conceptual al datelor. Proiectarea bazei de date va fi condiţionată de aceste reguli privind tipurile şi domeniile de valori admise pentru atribute, privind gradul de participare a entităţilor în relaţii, dar şi privind integritatea datelor în baza de date (v. §4.2). De exemplu, în cazul evidenţei situaţiei studenţilor, într-un an de studii se poate face înscrierea unui student la mai multe discipline facultative dar numai la o singură disciplină opţională. O altă regulă poate fi aceea că un student absolvă anul de studii doar dacă examenele susţinute şi absolvite însumează numărul de credite impus. O regulă de gestiune (business rule) este o propoziţie ce exprimă o restricţie impusă bazei de date, impunând condiţii în specificarea atributelor şi relaţiilor entităţilor. Regula de gestiune provine din modul cum sunt privite informaţiile de către organizaţie, prin prisma aspectelor legale, a aspectelor de fezabilitate (adică de conformitate cu realitatea) şi de eficienţă a prelucrărilor. Orice activitate prezintă reguli specifice atât asupra naturii şi condiţiilor impuse informaţiilor, datorate precedenţelor de timp (de exemplu data emiterii unei facturi trebuie să fie ulterioară celei a comenzii), datorate legilor în vigoare sau uzanţelor din domeniu, datorate unor utilizării aceloraşi informaţii în mai multe domenii sau mai multe aplicaţii. 4.1.1 Tipuri de reguli de gestiune O primă clasificare a regulilor de gestiune se face după elementul afectat:
40

reguli specifice atributelor – care impun restricţii asupra tipului de date şi formatului în care se vor înscrie valorile în câmpul din tabel; de exemplu, data calendaristică se scrie cu specificarea în clar a lunii (10 Aprilie 2005), sau numele de familie a clientului se înscrie cu majuscule. • Reguli specifice relaţiilor – care impun restricţii asupra legăturilor între entităţi; de exemplu, în legătura dintre entitatea Student şi entitatea Grupa apare regula: ”O grupă are cel puţin 25 de studenţi dar nu mai mult de 30”. O altă clasificare a regulilor de gestiune se poate face prin prisma orientării în SI: • reguli orientate spre baza de date – care afectează proiectarea logică a SI prin constrângeri legate de modificarea caracteristicilor sau relaţiilor entităţilor; de exemplu, se admit clienţi cumpărători de automobile doar persoane cu cetăţenie română şi cu domiciliul în România (ca urmare se limitează valorile posibile la „proprietăţile” cetăţenie şi adresă). • reguli orientate spre aplicaţie – care afectează proiectarea fizică a aplicaţiei; de exemplu, pentru clienţi „fideli” se face automat o reducere de 10%, care afectează valoarea produsului cumpărat dar noua valoare nu poate fi inclusă în proiectarea logică pentru că ea se obţine în urma unui calcul. 4.1.2 Definirea şi stabilirea regulilor de gestiune

•

Pentru a obţine un set coerent şi complet de reguli de gestiune trebuie să se cunoască atât modul de lucru comun cu datele al utilizatorilor din domeniu cât şi viziunea managerului asupra acestor date. Multe din regulile de gestiune provin din experienţa de lucru a persoanelor amintite dar pot să provină şi din experienţa analistului de sistem sau chiar a analistului-programator implicata în acel domeniu. Definirea regulii de gestiune constă în exprimarea concisă şi clară a condiţiei care trebuie respectată în proiectarea sau utilizarea bazei de date, iar stabilirea regulii se face printr-un proces de intervievare a utilizatorilor şi managerilor, pentru a indica în ce context şi la ce moment se aplică o regulă sau alta, ce avantaje şi ce dezavantaje prezintă. Se recomandă ca întâi să se definească şi stabilească reguli de gestiune pentru câmpuri apoi pentru relaţii, pentru a nu se face salturi şi reveniri înainte şi înapoi la diferite tipuri de reguli de gestiune în procesul de stabilire a lor şi a nu provoca confuzii. O cale sistematică de definire şi stabilire a regulilor de gestiune este prezentată mai jos, ca paşi de urmat de către analistul de sistem în faza de proiectare a bazei de date. 1. Se selectează un tabel. Fiecare tabel trebuie analizat în parte (nu contează ordinea în care se parcurg), la fiecare analizând subiectul tabelului prin următoarele întrebări: (a) Cum foloseşte organizaţia informaţia legată de subiect? (b) Ce relaţii există între tabelul curent şi celelalte tabele? Aceste întrebări ajută la clarificarea imaginii asupra subiectului tabelului şi la pregătirea pentru paşii următori. 2. Se revizuieşte fiecare câmp şi se determină dacă necesită restricţii. Pentru fiecare câmp se specifică tipul de dată, domeniul de valori, constrângerile ce decurg din întrebările (a) şi (b) de la pasul 1 pentru acest câmp, la culegerea, reprezentarea stocarea şi verificarea datelor. 3. Se definesc regulile de gestiune necesare pentru câmpul curent. Se formulează scurt şi complet fiecare regulă de gestiune care corespunde unei anume restricţii impuse câmpului ca proprietate a entităţii sau valori pe care le poate lua. 4. Se stabilesc ce alte elemente se modifică prin regula definită. Fiindcă o restricţiile impuse unui câmp pot condiţiona şi alte câmpuri (din acelaşi tabel sau din alte tabele) se identifică elementele afectate şi cum; uzual, se afectează valorile elementelor, spre exemplu:„nu permit lipsă valoare (vid sau Null, de ex. pentru Nr. Legitimaţie student)”, „nu permit modificare” (decât cu autorizare), „valoarea se regăseşte identic în alt tabel” (de ex. Nr. Legitimaţie din tabelul FişaStudent se regăseşte în tabelul Student). 5. Se determină acţiunile prin care regula poate fi încălcată. Restricţia impusă de regulă se testează pentru fiecare din acţiunile: inserare a unei noi linii (articol) sau unui nou câmp,
41

ştergerea unui articol sau a unei valori de câmp, modificarea o valoare de câmp. După ce s-a determinat care din acţiuni va încălca regula se va nota situaţia spre a se folosi în pasul următor. 6. Se înscrie regula în Lista de Reguli de Gestiune. Înscrierea regulilor de gestiune se face indicând: (i) Propoziţia - ca text scurt şi complet, (ii) restricţia – ca explicaţie scurtă a modului cum se aplică constrângerea la tabel(e) şi câmp(uri) locale şi vecine, (iii) Tipul – indică orientarea restricţiei spre baza de date sau spre aplicaţie, (iv) Categoria – se referă la câmp sau relaţie, (v) Test – indică ce acţiuni (inserare, ştergere, modificare) vor testa restricţia impusă, (vi) Structuri afectate – numele tabelelor sau relaţiilor afectate, (vii) Elemente de câmp afectate în propriul tabel sau alte tabele, (viii) Caracteristici ale relaţiilor afectate, (ix) Măsuri luate – ca modificări ale câmpurilor sau relaţiilor în DER efectuate pentru a asigura respectarea regulii (de exemplu „enforce referential integrity” în SGBD – Access). Documentarea corectă şi completă a regulilor de gestiune este esenţială pentru proiectarea eficientă a bazei e date, asigurând o metodă standard de înregistrare a lor, de revizuire (depanare) şi de aplicare la proiectarea bazei de date. Este indicat să se revadă Lista cu Reguli de Gestiune după crearea acesteia, pentru că fiecare regulă contribuie la integritatea datelor şi impun constrângeri specifice organizaţiei; dacă este necesar se adaugă noi reguli de gestiune sau altele se înlătură –fiindcă nu aduc rezultatele scontate sau chiar încurcă aplicaţia (caz analizat foarte atent). 4.1.3 Exemple de Reguli de Gestiune

Mai jos se dau două exemple de reguli de gestiune pentru cazul evidenţei situaţiei şcolare a studenţilor - prezentate de multe ori până aici (v. DER din Figura 3-14 sau diagrama UML din Figura 3-19): 1. O disciplină poate fi urmată de studenţi doar dacă există numărul (minim) de studenţi ce poate alcătui o grupă (adică 25 studenţi). Regula se aplică explicit la cursuri facultative (adică acestea nu se pot organiza fără un număr de minim de 25 studenţi în audienţă), dar se aplică implicit la cursurile obligatorii (adică este evident că disciplina se predă la cel puţin o grupă). În virtutea acestei reguli, în relaţia între tabelele Student şi Disciplina apar cardinalităţile: N:M care indică faptul că „un student urmează cel puţin N discipline (cele obligatorii) şi maxim M discipline (M>N, adică în plus şi cele facultative)”, respectiv N:M „o disciplină este urmată de cel puţin N studenţi (o grupă – cel puţin 25)” şi de maxim M studenţi (din multe alte grupe)”. 2. Unele discipline facultative sunt predate de profesori invitaţi. Această regulă indică faptul că un profesor este titular al uneia sau mai multor discipline, dar există discipline care să nu fie alocate unui anume profesor (de ex. unele discipline facultative); pentru acestea se aduc profesori invitaţi din afara universităţii – din alte universităţi sau din mediul de afaceri. În virtutea acestei reguli, în relaţia între tabelele Disciplina şi Profesor apar cardinalităţile: 0:N care indică faptul că: „o disciplină poate să nu fie predată de nici un profesor (dacă este facultativă şi titularul nu este din universitate) şi poate fi predată de maxim N profesori (la diferite secţii)”, respectiv 1:N „un profesor predă cel puţin o disciplină dar poate preda şi mai multe”.

4.2 Niveluri de integritate ale bazei de date
Integritatea datelor în baza de date este un termen generic care se referă la consistenţa, precizia şi corectitudinea informaţiilor stocate în baza de date. Integritatea datelor nu se referă la siguranţa fizică, la toleranţa la erori sau la salvarea corectă informaţiei (backups) ci priveşte modul cum sunt stocate şi manipulate datele în tabele aşa încât să nu apară situaţii anormale (de exemplu lipsa de corespondenţă a liniilor din două tabele aflate în relaţie). Există patru tipuri de integritate a informaţiei: 1. Integritate a entităţii – aplicată la nivel de articol (linie) în tabel;
42

2. Integritate a domeniului – aplicată la nivel de câmp (coloană) în tabel; 3. Integritate referenţială – aplicată la nivel de tabele aflate în relaţie; 4. Integritate definită de utilizator – aplicată la nivel reguli de gestiune asupra datelor din tabele; Integritatea informaţiei presupune o proiectare corectă şi apoi mecanisme de verificare a (respectării) integrităţii ce pot fi implementate în chiar SGBD (ca produs de baze de date relaţionale) în server-ul de baze de date, sau în aplicaţia de baze de date externă acesteia (ca de exemplu în cazul accesului prin Internet la o bază de date unde integritatea este implementată prin programe de acces la formularul transmis la utilizator). În cazul unui Server SQL, acesta permite ca regulile de integritate a informaţiilor să fie definite central în baza de date, deci independente de aplicaţiile care folosesc această bază de date Când integritatea informaţiilor este implementată direct în SGBD sau în serverul de baze de date, proiectantul aplicaţiei nu trebuie să se mai preocupe de asigurarea integrităţii ci cel mult va trebui să activeze mecanismele care verifică şi forţează respectarea integrităţii informaţiilor. Probleme care pot apare atunci când se încearcă implementarea integrităţii informaţiilor în aplicaţie (deci codarea lor în program) sunt: 1) efort de programare suplimentar, 2) inconsistenţa programului şi potenţiale erori în acesta, 3) dificultăţi la modificarea programului, 4) o securitate mai slabă a aplicaţiei – fiindcă mecanismele de verificare a integrităţii ar putea fie ocolite. 4.2.1 Integritatea entităţii

Integritatea entităţii asigură ca fiecare obiect instanţiat din tabel să fie identificat unic, adică un obiect din lumea reală să apară pe o singură linie deci să nu apară în duplicat. De exemplu, doi studenţi în tabelul Student să poată fi unic indentificaţi prin intermediul numărului de legitimaţie (NrLeg). Atât SGBD cât şi un Server SQL nu permit duplicarea obiectelor (liniilor) dacă este activată (forţată) integritatea entităţii. În acest fel nu este importantă ordinea în care sunt memorate datele în tabel – deci ordinea liniilor, de fapt a obiectelor înscrise, poate fi oricare. Este evident că aceasta oferă un mare avantaj la utilizarea unui tabel în baza de date fiindcă culegerea datelor despre obiectele din tabel se poate face la întâmplare (de exemplu studenţii pot fi înscrişi în tabel în orice ordine – aşa cum s-au prezentat ei la secretariatul facultăţii, nu în ordine alfabetică). Independenţa de modul fizic de stocare a datelor este obţinută prin aceea că fiecare obiect (linie) în tabel poate fi adresat (referit) printr-o valoare unică denumită “cheie” (cheie primară), care nu permite două valori identice în tabel (de exemplu doi studenţi cu acelaşi număr de legitimaţie, chiar dacă sunt fraţi gemeni şi se numesc la fel ...) şi nici lipsa valorii (valoare vidă). Un tabel poate conţine doar o singură cheie primară, chiar dacă aceasta este un singur câmp (de exemplu numărul de legitimaţie în tabel Student) sau este formată din două câmpuri (de exemplu numărul de legitimaţie şi codul disciplinei la care a susţinut examen în tabel FişaStudent); în acest ultim caz, numărul de legitimaţie şi codul disciplinei reprezintă chei primare în tabelele de unde provin (Student, respectiv Disciplina) sar e numesc chei externe (sau străine) în tabelul FişaStudent. 4.2.2 Integritatea domeniului

Integritatea domeniului cere valorile unui câmp (unei coloane) din tabel să aibă doar un set de valori anume pentru a fi valid. Cu alte cuvinte, integritatea domeniului, defineşte ce valori sunt permise a fi introduse într-o coloană dată, restricţionând tipul de dată, formatul sau domeniul posibil de valori. Integritatea domeniului mai este cunoscută şi ca integritate a atributului, iar verificare sa este „forţată” prin intermediul SGBD sau serverului de baze de date.
43

De exemplu, integritatea domeniului pentru coloana Vârsta studentului în tabel Student permite doar valori în domeniul 16-120 ani (pentru tineri supradotaţi, respectiv pentru pensionari longevivi); un Matusalem nu s-ar putea înscrie chiar dacă la vârsta de 600 ani este capabil a învăţa. Verificare integrităţii domeniului poate fi forţată prin constrângere de valoare implicită (DEFAULT) – prin se care automat pune o valoare în coloană (de ex. 19 în coloana Vârsta – considerând şcoala începută la 6 ani şi urmată 12 clase), sau poate fi forţată prin constrângeri de cheie străină (FOREIGN KEY) sau de verificare (CHECK) – prin care se folosesc domenii de valori din alte tabele, de unde provin de fapt mărimile. 4.2.3 Integritatea referenţială

Integritatea referenţială asigură sincronizarea tabelelor aflate în relaţie. Forţarea integrităţii referenţiale asigură menţinerea aceloraşi valori în coloanele comune a două tabele aflate în relaţie. De exemplu, SGBD nu va permite să se înscrie în tabelul FişaStudent un număr de legitimaţie care nu se va regăsi şi în Student (fiindcă are fi o eroare – nu este un student real). Dacă nu a fi asigurată integritatea referenţială nu s-ar putea obţine răspunsuri consistente (cu înţeles) atunci când se va dori, de exemplu, afişarea situaţiei notelor obţinute de studenţi cu numele şi prenumele lor. 4.2.3.1 Tabel „părinte” şi tabel „fiu” După cum se constată şi din exemplul de mai sus, integritatea referenţială se referă la cazuri când apare o combinaţie de chei străine sau cheie primară şi o cheie străină. Se consideră că o cheie străină este o coloană sau combinaţie de coloane într-un tabel derivat (denumit “fiu”) care ia valorile dintr-o cheie primară a unui alt tabel (denumit “părinte”). Înregistrările care din tabelul „fiu” (de exemplu FişaStudent) care nu au corespondent în tabelul „părinte” (de exemplu Student) se numesc „orfane”; deci integritatea referenţială împiedică apariţia de înregistrări orfane la interogări care folosesc cele două tabele în relaţie. Pentru ca integritatea referenţială să fie menţinută, cheia străină din tabelul “fiu” poate accepta doar valori care există în cheia primară a tabelului “părinte” Există trei moduri de abordare pentru a implementa integritatea referenţială: 1) restricţionare – a dreptului de modificare a informaţiei în tabele fiu sau părinte; 2) cascadare – extindere a activităţii de modificare a informaţiei la tabelul „înrudit” (părinte sau fiu); 3) anulare – punerea pe valoare vidă (NULL) a valorilor cheii străine în tabelul fiu. 4.2.3.2 Cazuri de încălcare a integrităţii referenţiale Actualizarea (UPDATE) valorilor în câmpuri cheie poate produce “orfani”, adică atunci când se modifică fie cheia primară a tabelului părinte fie cheia străină a tabelului fiu (vezi exemplul de mai sus cu tabele Student şi FişaStudent). Pentru a menţine integritatea referenţială, actualizarea ce poate cauza erori este blocată (nu este permisă) de către SGBD. Această situaţie apare atunci când o cheie străină face referire la o cheie primară. Ca alternativă, actualizarea poate fi cascadată de la “părinte” la “fiu” (adică modificarea este continuată automat la tabelul fiu dacă s-a modificat cheia primară la părinte). Ştergerea (DELETE) de linii din tabele aflate în relaţie părinte-fiu poate ataca integritatea referenţială. Dacă se şterge un „student” (linia sa) în tabel Student, atunci în tabelul FişaStudent vor rămâne linii orfane. Menţinerea integrităţii referenţiale se face prin blocarea ştergerii sau prin cascadare. Inserarea (INSERT) de noi valori de în câmpul cheie poate, de asemenea, ataca integritatea referenţială. De exemplu articole (linii) noi inserate în tabelul părinte produce articole (linii) orfane în tabelul fiu. Menţinerea integrităţii referenţiale se face prin blocarea inserării când în tabelul fiu se introduce o nouă linie (aceasta nu este permisă); se remarcă faptul că la inserare nu se poate menţine integritatea referenţială prin cascadare (aşa ca la actualizare sau ştergere).

44

4.2.4

Integritatea definită de utilizator

Integritatea definită de utilizator se referă la regulile de gestiune specifice domeniului rezolvat, care nu sunt acoperite de alte categorii de integritate amintite. Implementarea acestui tip de integritate se face uzual prin activarea unor proceduri predefinite, create specific regulii de gestiune care se doreşte rezolvată. În acest context se amintesc modalităţi de implementare a asigurării integrităţii informaţiei, care se aplică şi celorlalte categorii de integritate: • Integritatea Declarativă – se obţine prin declararea unei constrângeri asupra unei anumite coloane dintr-un tabel; constrângerea constă într-o restricţia asupra valorilor din acea coloană şi/sau din mai multe coloane cu date înrudinte (vezi exemple mai sus). Acest tip de asigurare a integrităţii intră în funcţie automat la cele trei: entitate, domeniu şi referinţială, la care provoacă de fapt o blocare a acţiunii care încalcă integritatea datelor. • Integritatea Procedurală – forţează controlul integrităţii prin proceduri de vizualizare sau activare şi se aplică doar la integrităţi: de domeniului şi referenţială. Acest tip de asigurare a integrităţii este mai complexă, şi necesită efort de programare pentru că presupune o intervenţie cu consultarea eventuală a utilizatorului.

4.3 Normalizarea Bazei de Date
O bază de date este compusă din relaţii (tabele) ce reprezintă colecţii de obiecte din lumea reală. Fiecare obiect instanţiat (concret) se numeşte articol. Obiectele au proprietăţi generice (atribute) reprezentate prin coloanele din tabel, pentru fiecare articol o proprietate luând o valoare specifică. În bazele de date relaţionale tabelele sunt bidimensionale – adică coloanele nu pot avea subcoloane şi nu se pot repeta ca semnificaţii. În acest sens, tabelele, articolele şi atributele trebuie să respectă regulile: 1. Fiecare articol (linie din tabel) reprezintă un singur obiect din realitate – obiectul nu se repetă pe mai multe linii. 2. Tabelul este omogen privind coloane sale, adică pe o coloana toate valorile sunt de acelaşi tip (numeric, text, etc.). 3. Fiecare articol (linie) este identificat unic printr-o cheie dedicată. 4. Fiecare coloana are un nume şi semnificaţie distincte. Nu există două coloane care să aibă aceeaşi semnificaţie într-un tabel. 5. Datele pe liniile şi coloane se pot succeda în ordine arbitrară (adică ordinea obiectelor sau a rubricilor în tabel nu afectează semnificaţia datelor din tabel). Nerespectarea regulilor de mai sus duc la anomalii (situaţii anormale), care pot fi eliminate prin procesul de normalizare a bazei de date. Aceste anomalii sunt: 1. Anomalie de actualizare (Update) – datorată redundanţei datelor, adică apariţiei unei valori de mai multe ori pe aceeaşi coloană. Aceasta poate duce la ineficienţa bazei de date. 2. Anomalie de inserare – datorată lipsei de date, adică trebuie completate toate datele obligatorii pentru un obiect anume pentru a nu avea valori vide (necompletate) la vreun câmp cheie. Acest fel de anomalie poate sa afecteze în mod serios baza de date. 3. Anomalie de ştergere – conduce la pierderea unor informaţii prin ştergerea unor articole (obiecte) care deţin anumite proprietăţi ce nu se regăsesc la alte articole. Aceasta poate duce la pierderea de date vitale. 4. Anomalie de inconsistenţă – care apare atunci când la aceleaşi atribute avem domenii diferite. La proiectarea bazei de date se stabileşte structura de date care va fi utilizată; fiindcă această structură trebuie să satisfacă regulile amintite (ce provin din regulile lui Codd) şi cu siguranţă la prima vedere structura de date nu va fi în forma perfectă, sunt necesari mai mulşi paşi de proiectare prin care să se aducă structura de date la forma normală. Chiar astfel sunt
45

denumite stările succesive prin care structura de date poate fi adaptată spre a elimina anomaliile prezentate mai sus. În exemplele ce urmează, se consideră ca problemă de rezolvat gestionarea situaţiei şcolare a studenţilor dintr-o facultate de Ştiinţe Economice. Tabelul cu date care se va realiza la primul pas arată ca cel din Figura 4-1, care se presupune că va fi folosit pentru a urmări situaţia şcolară a studenţilor (de aceea denumit SituatiaStudent). Fiecare student este indicat prin Număr Legitimaţie (câmp NRLEG) cu nume (NUMESTUD) şi specializarea (cîmp SPECIALIZARE), apoi Cod disciplina (COD), numele disciplinei( NUMEDISC), numele profesorului titular NUMEPROF, cu titlul didactic (TITLU) şi cu nota obţinută la examen (NOTA). Tabelul din Figura 4-1 reprezintă date nenormalizate; astfel, el conţine grupuri de date care se repetă: COD, NUMEDISC, NUMEPROF, TITLU, NOTA. Dacă s-ar imagina lucrul uzual la secretariat cu „fişele” studenţilor, acestea vor conţine fiecare aceste repetiţii – pentru fiecare student se înscriu în fişă (din cataloage) datele pentru fiecare disciplină. Pentru o bază de date relaţională, acest lucru duce la mari deficienţe în utilizarea ei – pentru că structura de tabel relaţional nu permite subcoloane - este un tabel plat, bidimensional; datele despre studenţi din Figura 4-1 pot fi văzute ca un set de coloane specifice studentului, care au subcoloane indicând datele despre disciplinele pe care le urmează (nume disciplină, cine o predă, nota, etc.) – deci un tabel tridimensional (datele despre discipline apar pe adâncime). SituatieStudent
NRLEG NUMESTUD SPECIALIZARE COD NUMEDISC NUMEPROF TITLU NOTA

1833

Sandu F.

Finante Banci

2844 3245

Bran B. Costin D.

ECTS Finante Banci

1935

Gaiu G.

Finante Banci

100 200 300 100 400 450 300 325 400 450 300 200

Baze Info. Algebra LMP Baze Info. PSI Mat. Econ. LMP Microecon. PSI Mat. Econ. LMP Algebra

Mircea D. Stan C. Mircea D. Mircea D. Mircea D. Stan C. Mircea D. Ivan R. Mircea D. Stan C. Mircea D. Stan C.

Conf. Conf. Conf. Conf. Conf. Conf. Conf. Prof. Conf. Conf. Conf. Conf.

8 7 7 9 5 6 8 6 7 7 5 7

Figura 4-1. Baza de date cu situaţia şcolară a studenţilor. Structura tabelului se poate descrie (în modul uzual din limbajul SQL) astfel: SituatieStudent(NRLEG, NUMESTUD, SPECIALIZARE, {COD, NUMEDISC, NUMEPROF, TITLU, NOTA}) unde grupul repetat este indicat între acolade. Dacă se stabileşte drept cheie primară câmpul NRLEG, atunci tabelul permite şi încărcarea datelor pentru studenţi cu nume identice – şi în acest caz fiind posibilă identificarea lor unică (fără confuzii). Câmpul NRLEG este de fapt un câmp de codificare a articolelor din tabel, codificare care are chiar rolul de identifica unic un obiect, chiar daca el are proprietăţi similare cu un altul (în cazul nostru numele). Anomaliile care apar sunt următoarele: • Nu se ştie câte discipline urmează un student, deci nu se ştie de câte ori se vor repeta linii pentru el, fiindcă la secţii diferite se predau numere diferite de discipline. Se observă din Figura 4-1 ca studentul 3245 are trei subiecte in timp ce 1935 are patru. • Structura de date pe coloane nu este omogenă – de ex. pe coloana NUMESTUD există linii cu date şi alte linii fără date (vide).
46

Liniile nu pot fi citite în orice ordine – că este pericolul să nu ştim la care din studenţi se referă datele despre o disciplină. • Există atribute non-cheie (de exemplu numele Disciplinei sau numele Profesorului) care nu sunt dependente complet de câmpul cheie (numărul legitimaţiei studentului NRLEG). • Unele atribute non-cheie depind direct de alte atribute non-cheie – de exemplu nume Disciplină depinde complet de cod disciplină COD. • Anomalie de inserare: dacă se introduce o nouă disciplină (de exemplu opţională) este obligatoriu să fie şi un student amator să o urmeze pentru a fi posibil să apară în tabel; în lipsa unui student amator nu avem cum să ştim că ea există şi este oferită de programă. • Anomalie de ştergere: dacă studentul 3245 se retrage, dispare şi NUMEDISC 325 din tabel şi se pierde urma acesteia (ca şi cum nu ar mai fi în programă). • Anomalii de inconsistenţă: câmpuri cheie (adică în coloana NRLEG) există valori vide (lipsă numere de legitimaţie) şi nu se ştie cărui student aparţine de fapt linia respectivă. Primul pas în eliminarea situaţiilor anomale este sa aducem tabelul (datele) în Forma Normală 1 (FN1 – iar în engleză 1NF, 1st Normal Form). 4.3.1 Forma Normală 1 (FN1)

•

Pentru a aduce structura de date la FN1, trebuie eliminate grupurile care se repetă, astfel că obţinem tabelul din Figura 4-2 SituatieStudent
NRLEG NUMESTUD SPECIALIZARE COD NUMEDISC NUMEPROF TITLU NOTA

1833 1833 2844 3245 2844 3245 3245 1833 1935 1935 1935 1935

Sandu F. Sandu F. Bran B. Costin D. Bran B. Costin D. Costin D. Sandu F. Gaiu G. Gaiu G. Gaiu G. Gaiu G.

Finante Banci Finante Banci ECTS Finante Banci ECTS Finante Banci Finante Banci Finante Banci Finante Banci Finante Banci Finante Banci Finante Banci

100 200 100 325 400 450 300 300 400 450 300 200

Baze Info. Algebra Baze Info. Microecon. PSI Mat. Econ. LMP LMP PSI Mat. Econ. LMP Algebra

Mircea D. Stan C. Mircea D. Ivan R. Mircea D. Stan C. Mircea D. Mircea D. Mircea D. Stan C. Mircea D. Stan C.

Conf. Conf. Conf. Prof. Conf. Conf. Conf. Conf. Conf. Conf. Conf. Conf.

8 7 9 6 5 6 8 7 7 7 5 7

Figura 4-2 Baza de date în forma normală 1 (FN1). De data aceasta liniile pot fi scrise în orice ordine, dar există date redundante (adică ce apar de mai multe ori) şi se consumă ineficient memorie de stocare a lor. În plus, dacă se face o modificare la numele unui student (de exemplu o studentă căsătorită), trebuie actualizate (modificate) mai multe linii, care trebuie căutate prin tot tabelul, pentru că liniile nu mai apar grupate pentru fiecare student. Din cele 4 articole acum avem 12 articole, transformând tabelul dintr-o structură tridimensională în una bidimensională. Pentru a fi siguri ca orice articol este identificat unic (pentru a se conforma regulii 3) trebuie să modificăm cheia, prin adăugarea la cheia originală NRLEG a câmpului COD – împreună reuşind să identifice unic o linie. Astfel, tabelul poate fi descris ca: SituatieStudent(NRLEG, COD, NUMESTUD, SPECIALIZARE, NUMEDISC, NUMEPROF, TITLU, NOTA)
47

Astfel, nu mai apar grupuri repetate de coloane. Totuşi, s-au menţinut anomaliile: • Anomalie de actualizare: daca se modifică titlul disciplinei 100 (în Informatică I) atunci toate liniile care conţin această disciplină trebuie căutate şi modificate. Pot fi peste 1000 de astfel de linii într-un tabel real. • Anomalie de Inserare: cheia primară este NRLEG, COD, deci nu putem adaugă o nouă disciplină fără să fie şi un student care să o urmeze. • Anomalie de Ştergere: dacă studentul 3245 se retrage, NUMEDISC 325 dispare cu desăvârşire şi se pierde orice informaţie despre această disciplină (cine o predă). Aceste anomalii sunt datorate situaţiei de dependenţă parţială care s-a menţinut pentru atributele non-cheie ce nu sunt dependente in totalitate de cheia primară: NUMESTUD şi SPECIALIZARE depind de NRLEG, NUMEDISC, NUMEPROF şi TITLU depind de COD şi doar NOTA depinde complet de ambele (deci de cheia primară stabilită). În exemplul nostru relaţia este în FN1 şi deţine dependentele parţiale, aşa că normalizarea continuă cu a doua forma normala (FN2). 4.3.2 Forma Normală 2 (FN2)

Transformarea la FN2 implică obţinerea câte unei noi relaţii pentru fiecare dependenţă parţială, adică pentru fiecare dependenţă se realizează un tabel separat. Vom avea o relaţie SituatieStudent cu cheia originală şi atributul NOTA, o relaţie Student pentru atributele NUMESTUD şi SPECIALIZARE cu o cheie primară NRLEG, şi o relaţie Curs pentru detalii ale cursului: COD, NUMEDISC, NUMEPROF si TITLU. Descrierile relaţiilor sunt aşadar: SituatieStudent(NRLEG,COD,NOTA) Student(NRLEG,NUMESTUD,SPECIALIZARE) Disciplina(COD,NUMEDISC,NUMEPROF,TITLU) În această nouă situaţie: NRLEG şi COD formează încă cheia primară pentru relaţia SituatieStudent şi atributul NOTA este dependent în de întreaga cheie. • NUMESTUD şi SPECIALIZARE în FN1 sunt dependente de complet de cheia NRLEG, deci se poate forma noua relaţie Student. • NUMEDISC şi NUMEPROF de asemenea FN1 sunt dependente de cheia COD şi formează o nouă relaţie Curs. Se observă că SituatieStudent conţine acum chei externe (sau străine) adică chei ale obiectelor din alte tabele. Aceste chei au rolul de a asocia relaţiile (adică tabelele). Acum se poate înţelege de ce se foloseşte cuvântul relaţie şi pentru tabel şi pentru legătura între tabele: tabelul SituatieStudent este de fapt o relaţie între tabelele Student şi Disciplina, având drept cheie primară perechea de chei din cele două tabele (fiecare specifică tabelului din care provine). Anomalia de inserare a fost rezolvată şi putem adăuga discipline noi fără probleme (indiferent dacă sunt sau nu între studenţii existenţi amatori să le urmeze). Anomalia de ştergere a fost şi ea rezolvată, astfel că putem să ştergem în sfârşit un student (care, de exemplu, se retrage) fără să pierdem informaţii de care avem nevoie. Anomalia de actualizare fost de asemenea rezolvată în câteva cazuri, astfel dacă vrem să schimbăm titlul unei Discipline se face o singură modificare în tabelul Disciplina. Mai există şi alte anomalii? Dacă se examinează relaţia Disciplina se va constata că TITLU depinde de NUMEPROF: Mircea D. are încă gradul de Conf. dar va deveni Prof. şi aceasta înseamnă că atributul TITLU din Disciplina nu este dependent direct de cheia primară COD (al Disciplinei). Mai sunt alte câteva probleme cu relaţia Disciplina:
•

48

Nu putem adăuga un nou NUMEPROF decât doar dacă acel profesor are ataşată o disciplină - anomalie de inserare. • Dacă un profesor schimbă TITLU trebuie să găsim fiecare instanţă (apariţie) a acelui NUMEPROF în Disciplina şi să facem modificarea - anomalie de actualizare. • Dacă ştergem gradul se va pierde informaţia asupra celui care predă (un asistent nu predă Disciplina) - anomalie de ştergere. Aceste anomalii există din cauză că gradul profesorului nu este dependent direct de disciplina predată ci indirect sau tranzitiv prin intermediul câmpului NUMEPROF. A treia formă normală elimină aceste dependenţe tranzitive şi indirecte. 4.3.3 Forma Normală 3 (FN3)

•

La transformarea datelor pentru a satisface FN3 se extrage într-o relaţie separată, orice atribut care prezintă dependenţe tranzitive. Aceasta înseamnă obţinerea unei noi relaţii (derivate), în cazul nostru relaţia Profesor, cu atributele NUMEPROF şi TITLU. SituatieStudent
NRLEG COD NOTA

Student
NRLEG NUMESTUD SPECIALIZARE

1833 1833 2844 3245 2844 3245 3245 1833 1935 1935 1935 1935

100 200 100 325 400 450 300 300 400 450 300 200

8 7 9 6 5 6 8 7 7 7 5 7

1833 2844 3245 1935

Sandu F. Bran B. Costin D. Gaiu G. Profesor

Finante Banci ECTS Finante Banci Finante Banci

NUMEPROF TITLU

Mircea D. Stan C. Ivan R. Disciplina
COD

Conf. Conf. Prof.

DISCIPLINA

NUMEPROF

100 200 325 400 450 300

Baze Info. Algebra Microecon. PSI Mat. Econ. LMP

Mircea D. Stan C. Ivan R. Mircea D. Stan C. Mircea D.

Figura 4-3 Baza de date normalizată Descrierea relaţiilor va fi aşadar: SituatieStudent(NRLEG,COD,NOTA) Student(NRLEG,NUMESTUD,SPECIALIZARE) Disciplina(COD,NUMEDISC,NUMEPROF) Profesor(NUMEPROF,TITLU) 4.3.4 Paşi în normalizarea bazei de date şi normalizare avansată

Pe scurt, procesul de normalizare constă în eliminarea datelor redundante din tabele prin operaţia de proiecţie relaţională (PROJECTION). Date redundante sunt cele care se repetă sau nu reflectă au specificul entităţii vizate, iar operaţia de proiecţie relaţională constă
49

în descompunerea („despicarea”) unui tabel cu mai multe coloane în alte două (sau mai multe) tabele, în fiecare din acestea transferându-se un anumit număr de coloane din tabelul original. Scopul principal al normalizării este de a obţine un (singur) câmp de identificare (cheie primară) – plasată în prima coloană, iar restul de câmpuri (coloane spre stânga) să fie funcţional dependente de prima. Pentru a fi corectă, descompunerea tabelului original trebuie să se facă fără pierderi de date (câmpuri), adică să se poată obţine tabelul original prin operaţia relaţională de reunire (JOIN) Paşii normalizării, începând cu baza de date ne-normalizată, sunt: 1. Eliminarea grupurilor de câmpuri care se repetă - FN1 a. Identificarea câmpurilor care se repetă. b. Obţinerea de câmpuri atomice (singulare semantic). c. Stabilirea câmpurilor cu rol de cheie compusă (la această fază sigur mai multe câmpuri împreună vor juca rolul de cheie primară). 2. Rezolvarea dependenţelor parţiale - FN2. a. Identificarea tuturor determinanţilor alţii decât cheia compusă şi a câmpurilor dependente. b. Crearea şi denumirea unui nou tabel pentru fiecare determinant, care devine câmp cheie primară. c. Includerea câmpurilor dependente din tabelul original în tabelul creat la pct. b. d. Ştergerea tuturor câmpurilor de la pct.c. din tabelul original, cu excepţia câmpului determinant care devine cheie externă. e. Re-denumirea tabelului original pentru a fi corect semantic. 3. Rezolvarea dependenţelor indirecte - FN3, practic prin repetarea punctelor a-e de la FN2, cu excepţia faptului că acum cheia primară va fi un singur câmp (nu mai multe). Formele normale conţin obligatoriu pe cele precedente, adică FN2 conţine pe FN1 iar FN3 pe FN1 şi FN2. În practică, se consideră că este suficientă normalizarea după primele trei forme FN1, FN2 şi FN3. Formele normale se pot obţine rapid şi comod folosind DER realizată în faza de modelare conceptuală (v.§3.4), unde se identifică corect entităţile (categoriile de obiectele) şi relaţiile între acestea. Apoi se stabileşte pe rând care relaţie reprezintă de fapt „interacţiune” cu producere de date (v. cazul reprezentat în Figura 3-14, privind interacţiunea StudentDisciplină) care se devine un nou tabel ce are câmpul cheie primară compus din chei externe provenite din tabelele în interacţiune. Formele normale se obţin prin modificarea („despicarea”) tabelelor bazei de date folosind DER şi obţinând după fiecare pas de normalizare o nouă DER.

4.4 Proiectarea de detaliu
După realizarea diagramei Sistemului Informatic – într-una din variantele prezentate mai sus, există premizele pentru proiectarea funcţională, adică descrierea în amănunt a structurilor de date şi a prelucrărilor vizate. În continuare se desfăşoară următoarele activităţi: 1. se revăd cerinţele de funcţionare formulate la nivelul fiecărei componente (se reajustează structura şi concepţia sistemului); 2. se proiectează ieşirile (conţinut, format, periodicitatea, termene, volum, destinaţie); 3. se specifică algoritmic prelucrările pentru fiecare procedură în parte; 4. se proiectează intrările (corespunzător ieşirilor impuse); 5. se proiectează structura fişierelor sau a bazei de date; 6. se proiectează sistemul de codificare (codificarea fiind necesară pentru ataşarea unei chei unice fiecărui reper şi pentru utilizarea în a cheilor comun la mai multe fişiere); 7. se proiectează circuitul informaţional;

50

8. se proiectează procedurile de interfaţă cu utilizatorul (mod manual de lucru sau automat, interfaţă grafică sau text); 9. se elaborează grafice de realizare a fiecărei componente precizând cerinţele şi condiţiile tehnice ale acesteia; Documentaţia realizată în această fază se numeşte „Proiect Tehnic” sau „Specificaţie de Programare”. O metodă de proiectare (conceptuală, logică şi fizică) des utilizată în România este metoda MERISE - de provienţă franceză, dar care respectă principalii paşi din l Etapele de principiu care trebuie parcurse pentru realizarea Sistemului Informatic sunt (conform metodei MERISE): • Modele Conceptuale ale Datelor şi Prelucrărilor (MCD şi MCP) – care descriu pentru fiecare din acestea ideile de principiu pentru organizarea lor; • Modele Logice ale Datelor şi Prelucrărilor (MLD şi MLP) – care descriu structura de amănunt şi legăturile între aceste structuri şi privesc proiectarea software (şi hardware implicat); • Modele Fizice ale Datelor şi Prelucrărilor (MFD şi programe) – care sunt efectiv implementări ale structurilor de date (fişiere) şi prelucrărilor (module program sau interogări formulate prin intermediul grilelor de proiectare interogări) şi privesc punerea în operă concretă şi materială a Sistemului Informatic. Aceste modele coboară în ordine de la nivelul conceptual la cel de implementare (de la cel mai abstract la cel mai concret). Pentru realizarea efectivă a Sistemului Informatic este necesar să se analizeze cerinţele şi de aici să se extragă Modelul Conceptual al Comunicaţiilor MCC (din care va rezulta de fapt distribuirea spaţială a datelor) şi Modelul Organizaţional al Prelucrărilor (MOP) care descrie restricţiile induse de mediu (organizatoric, spaţial şi temporal). Stocarea structurilor de date se face, actual, în două moduri: în fişiere şi în baze de date. Modul de organizare specifică a datelor în cele două moduri, cu avantaje şi dezavantaje sunt prezentate mai jos: • Organizare ca fişier în aplicaţii: datele sunt memorate în fişiere cu structuri specificate chiar în aplicaţii, astfel că orice operaţie efectuată asupra datelor necesită proceduri speciale, dedicate. Avantaje: atât aplicaţia cât şi fişierul de date pot fi optimizate. Dezavantaje: orice modificare în structura datelor implică modificarea aplicaţiei. • Organizare în baze de date. În acest caz, structurile de date sunt definite generic (de obicei în tabele) astfel că aplicaţiile apelează datele prin intermediul unor programe specializate. Aplicaţiile sunt realizate ca prelucrări executate: - pe lot (batch) - în care întreaga înşiruire de comenzi formează un lot şi este preluată şi executată în bloc; - prin interpretoare - în care fiecare comandă este executată separat şi apoi se trece la următoarea. Sistemele de gestiune a bazelor de date (SGBD) prezintă ambele moduri de lucru utile în următoarele situaţii: - în cazul lot se pot executa programe de sine stătătoare pe care le vor utiliza nespecialişti; - în cazul interpretor prelucrările sunt lansate de personal specializat sau în momentele de depanare şi testare, astfel că se poate interveni la orice moment în modificarea comenzilor. Folosirea SGBD prezintă avantaje şi dezavantaje: Avantaje: independenţa datelor de programe, structura datelor se poate modifica oricând (se adaugă o nouă coloană în tabel) fără a modifica interogările (Query), se asigură portabilitatea datelor şi programelor (datele se pot duce pe alt sistem fără a modifica nimic din modul de lucru), prelucrările se pot executa şi memora pt. a fi reutilizate ori de câte ori este nevoie. Dezavantaje: spaţiu mare de memorie ocupat (pe disc şi în memorie); necesitatea utilizării în fundal a unui SGBD ca schelet obligatoriu de lucru, adică (în general) nu se poate obţine un
51

program executabil care să fie preluat şi memorat pe alt sistem independent de SGBD – de aici rezultă costuri mai mari implicate de cumpărarea încă unei licenţe SGBD. Pentru că în lucrarea de faţă se utilizează mediul de baze de date MS Access în scopul experimentării şi verificării acţiunilor de proiectare şi pentru că prelucrările vizate sunt în principal interogări relativ simple (ce nu necesită flux de operaţiuni şi nici modele complexe de prelucrare), se vor discuta în continuare în special probleme legate de proiectarea structurilor de date – care de fapt sunt şi problemele esenţiale la proiectarea sistemelor de gestiune, atunci când se utilizează mediile moderne de baze de date.

4.5 Management de proiect
Se consideră că termenul de proiect poate fi folosit în cazul unei serii de activităţi care vizează un obiectiv complex ce iese din rutina obişnuită – adică nu se repetă des şi are un pronunţat caracter specific, indus de problema de rezolvat. Realizarea unui SI presupune coordonarea mai multor echipe de oameni şi planificarea multor resurse – materiale, financiare şi umane, în vederea atingerii unui scop individualizat ce vizează o problemă specifică a organizaţiei beneficiare. Această problemă priveşte informaţii şi cunoştinţe necesare organizaţiei care vor fi prelucrate cu sisteme electronice de calcul, care o dată instalate vor fi doar exploatate, adică nu mai apar probleme de natura proiectării şi implementării; prin aceste caracteristici, realizarea unui SI constituie un proiect al organizaţiei beneficiare. Managementul de proiect reprezintă planificarea, organizarea şi administrarea (managementul) sarcinilor şi resurselor pentru a îndeplini un obiectiv definit, de obicei cu constrângeri de timp, cost şi calitate. Managerii oricărei activităţi pot folosi conceptele şi uneltele managementul de proiect pentru a gestiona propria muncă. Dacă un proiect implică mai mult decât câteva sarcini sau dacă câteva resurse trebuie să fie urmărite, practicile managementului de proiect pot fi folositoare.

4.5.1 Scopuri şi metode în managementul de proiect
Scopul managementului de proiect este de a atinge un obiectiv specific în timp şi buget dat şi asigurând totodată o calitate ridicată. Un obiectiv poate fi simplu – precum planificarea proiectării şi producţiei unei oferte de vânzări pentru o firmă, sau poate fi complex – de exemplu proiectarea şi realizarea sistemului integrat de informatizare a unui complex siderurgic. În fiecare caz, proiectul trebuie împărţit în activităţi şi sarcini ce pot fi gestionate uşor; sarcinile sunt blocurile elementare ale managementului de proiect. Pentru a îndeplini aceste sarcini, resurse precum oameni şi echipamente trebuie repartizate. Managementul de proiect poate răspunde la diverse planificări, resurse şi întrebări, • Cât timp va lua acest proiect? • Dacă o sarcină este întârziată va fi întârzia tot proiectul? • Ce sarcini sunt critice pentru a respecta planificarea? • Există suficiente resurse disponibile pentru a completa proiectul conform planificării? • Care sunt costurile acestui proiect? În continuare se face o trecere în revistă a câtorva din cele mai semnificative realizări în tehnicile de dezvoltare a managementului de proiect. Fiecare din aceste realizări a influenţat dezvoltarea managementului de proiect software. 4.5.1.1 Metoda drumui critic (Critical Path Method - CPM) Procesul de computerizare a managementului de proiect a început în anii 1950. Corporaţia Du Pont, într-un efort de a îmbunătăţi tehnicile de planificare a proiectului, a dezvoltat un sistem de planificare numit Metoda Drumului Critic (Critical Path Method) sau planificare CPM. CPM este un model matematic ce calculează durata totală a proiectului pe baza duratei fiecărei sarcini individuale şi a dependenţelor, identificând ce sarcini sunt critice.
52

Acest model este metoda fundamentală pentru planificare folosită astăzi în managementul de proiect şi a fost dezvoltate aplicaţii software folosind această tehnică. 4.5.1.2 Diagrama Gantt Într-o evoluţie separată a sistemelor de management de proiect, Henry L. Gantt a dezvoltat un sistem de diagrame grafice pentru a descrie activităţile într-o perioadă de timp. La început numite diagrame cu bare, aceste diagrame au fost redenumite diagrame Gantt după numele inventatorului sistemului. Diagramele Gantt implementate în programele pentru calculator pot fi folosite pentru a construi un proiect, a urmări sau a pentru a crea rapoarte ale unui proiect. Presupunem diagrama Gantt din Figura 4−4, unde se regăsesc activităţi specifice proiectării software cu numele lor în engleză: A. Proiectarea structurii programului. B. Programare meniuri şi controale (butoane, acţiuni). C. Programare module pentru afişare rapoarte. D. Construirea structurii de fişiere. E. Programare module de introducere date. F. Crearea datelor de test. G. Desfăşurare teste.

Figura 4-4 Diagrama Gant în dezvoltarea software. Diagrama din Figura 4−4 reprezintă desfăşurearea activităţilor dar nu detaliază care sunt dependenţele între ele: • A înainte de B,C sau D • D în acelaşi timp cu B şi C • B înainte E • E înainte F • Toate înainte H • G în acelaşi timp cu F Activităţile specificate în diagrama Gant se pot desfăşura în serie sau în paralel, după cum sunt chiar ilustrate prin barele din Figura 4−4. 4.5.1.3 Tehnica PERT PERT (Program Evaluation Review Technique) a fost dezvoltată în 1958 de Marina Militară a Statelor Unite ale Americii şi de către Booze, Allen, şi Hamilton, o firmă de consultanţă. Metoda a fost folosită în multe proiecte complexe ce necesitau un management şi o planificare atente. În dezvoltarea sistemului de arme Polaris, Marina Americană avea nevoie de o metodă pentru a planifica evoluţia proiectului şi o cale de a evalua efectul schimbărilor în planificare. Tehnica a avut succes şi Marina Americană a terminat proiectul Polaris cu doi ani înaintea datei programate, timp în care alte proiecte se derulau depăşind bugetele alocate şi având întârzieri faţă de datele planificate.
53

Deşi cea mai bună abordare a managementului de proiect este de a împărţi proiectul în piese mici, gestionabile, există pericolul de a pierde din vedere proiectul ca întreg în timpul conducerii sarcinilor mai mici. Activităţile proiectului sunt de obicei interdependente. Totuşi, interdependenţa sarcinilor nu este evidentă în diagrama cu bare. Sarcinile critice, cele care trebuie îndeplinite într-o anumită ordine, de asemenea nu sunt evidente. Un manager de proiect doreşte să îndeplinească următoarele: să indice activităţile individuale şi timpul necesar pentru fiecare, să arate relaţiile dintre activităţi, să identifice ordinea corectă, să dea estimările de timp, să izoleze ariile unde e posibil să apară probleme sau întârzieri (şi să indice acele arii ce au nevoie de monitorizare şi supraveghere) şi să dispună de mijloace de a urmări evoluţia proiectului. Poate fi necesar să cunoască, de exemplu, ce efect are întârzierea unei activităţi în cadrul întregului proiect sau ce activitate are cea mai mică toleranţă la întârziere. Diagrame PERT construite corect pot oferi aceste informaţii în timp ce diagramele cu bare de abia sugerează interdependenţa sarcinilor. Proiectele conţin evenimente şi activităţi. Diagrama PERT foloseşte noduri şi căi (arce) pentru a reprezenta relaţiile dintre activităţile proiectului. Nodurile reprezintă evenimente şi căile arată activităţile sau sarcinile ce sunt necesare pentru a trece de la un eveniment la altul. Timpul necesar pentru a îndeplini fiecare activitate este indicat pe cale. Într-un proiect mare, reţeaua de linii şi noduri poate fi foarte mare. Diagrama PERT este foarte valoroasă în etapa proiectare şi planificare a unui proiect. Când reţeaua este terminată, se studiază pentru a determina drumul critic (drumul de la început până la sfârşit) pe care timpul total necesar e mai mare decât pe orice alt drum. Dacă activităţile dea lungul acestui drum nu sunt terminate la timp, întregul proiect va întârzia. De aici atenţia ar trebui îndreptată spre aceste activităţi. Diagrama PERT arată, de asemenea, interdependenţele dintre sarcini şi ajută să se răspundă la trei tipuri de întrebări (ce ţin de management): 1. Ce alte activităţi trebuie să preceadă sau să fie terminate înainte de iniţierea unei activităţi specifice? 2. Ce alte activităţi pot fi îndeplinite în timp ce se desfăşoară o altă activitate specifică? 3. Ce activităţi nu pot fi începute decât după completarea unei activităţi specifice? Pentru a dezvolta o reţea PERT pentru un proiect de SI trebuie identificate mai întâi sarcinile şi timpul asociat cu fiecare activitate. Timpul necesar pentru fiecare activitate este durata. Apoi trebuie identificată secvenţa de activităţi şi notate locurile în care sarcini specifice trebuie să preceadă alte sarcini şi unde anumite activităţi pot apărea simultan cu altele.

4.5.2 Estimarea realizării priectului
Estimarea timpului de dezvoltare a unui sistem e o provocare pe care analiştii sistemelor de informaţie trebuie să o rezolve cu succes. Perspectiva managementului corporativ general este că grupurile de sisteme de informaţie nu vor fi văzute ca o parte integrantă a activităţii comerciale pe care o sprijină până când pot livra sisteme la timp şi încadrându-se în buget. Aceasta înseamnă estimarea cu acurateţe şi apoi îndeplinirea acestor estimări combinat cu un management profesional de proiect.

4.5.3 Fazele managementului de proiect
Managementul de proiect implică în general trei faze: 4.5.3.1 Crearea proiectului Aceasta este cea mai importantă fază a managementului de proiect. Include definirea sarcinilor şi durata fiecărei, stabilirea relaţiilor dintre sarcini şi, dacă utilizarea resurselor poate fi urmărită, stabilirea resurselor pentru fiecare sarcină. Toate fazele următoare ale proiectului sunt bazate direct pe informaţia oferită când proiectul este creat.

54

4.5.3.2 Gestionarea proiectului
Această fază a managementului de proiect este un proces continuu ce începe în momentul creării proiectului şi se sfârşeşte când proiectul este terminat. Gestionarea proiectului include urmărirea şi ajustarea proiectului pentru a reflecta schimbările ce pot apare pe măsură ce proiectul avansează.

4.5.3.3 Realizarea rapoartelor despre proiect
În această fază este prezentată informaţia despre proiect. Unul din cele mai importante beneficii ale utilizării de programe (software) pentru managementul de proiect este posibilitatea de a crea rapid şi uşor rapoarte atractive şi informative.

4.5.4 Costurile managementului de proiect
Următorii factori sunt luaţi de obicei în considerare la estimarea proiectelor de dezvoltare a unui sistem: 4.5.4.1 Costul personalului Acesta nu include doar costul personalului pentru dezvoltareci şi costul personalului de întreţinere precum dactilografe, etc. 4.5.4.2 Costuri de subcontractare externă De exemplu costurile asociate cu subcontractarea pentru dezvoltarea a unei firme cu experienţă în fabricarea de electronice.

4.5.4.3 Costurile timpului calculator
Acesta este un cost foarte ridicat ce include timpul pentru activităţile de dezvoltare cum ar fi integrarea, testarea şi sprijinirea activităţilor de genul planificării proiectului şi documentare. 4.5.4.4 Costuri de introducere a datelor Acestea includ activităţi precum introducerea de date d test şi secretarele ce introduc documentaţia. 4.5.4.5 Costuri ale facilităţilor fizice Acestea includ spaţiul pentru birouri, mobila, sistemele de securitate, aer condiţionat, etc. 4.5.4.6 Costuri ale consumabilelor Consumabilele sunt îndeobşte considerate hârtia pentru imprimantă, toner de imprimare, discuri, etc. 4.5.4.7 Costuri de deplasare şi subzistenţă Pentru documentare, pentru interviuri şi în diverse acţiuni de preluarea materiale sau documente se fac deplasări ale personalului în diferite locuri.

55

Bibliografie
1. Ariton V., Fundamente ale tehnologiei informaţiei şi comunicaţiilor, Ed. Didactică şi Pedagogică, 2004. 2. Batini, C., Ceri, S., Navathe, S., B., Conceptual Database Design, Benjamin/Cummings. 1992. 3. Conoly T., Begg C., Baze de date. Proiectare, implementare, gestionare., Editura Teora, 2001. 4. Davidescu N.et al., Sisteme informatice financiar-bancare, Editura All 1998/1999. 5. Florescu V. – Grupul BDASEIG, Baze de date. Fundamente teoretice şi practice, Editura InfoMega, 2002. 6. Florescu V., Stanciu V., Cozgarea G., Cozgarea A., Baze de Date, Ed. Economică, 1999. 7. Fotache M., Baze de date relaţionale. Organizare, interogare, normalizare, Editura Junimea, 1997. 8. Fowler M., Scott K., UML Destilled, Second Edition. A Brief User Guide to the Standard Object Modeling Language. AddisonWesleyLongmanInc., 1999. 9. Hawryszkiewycz I.T., Introduction to System Analysis and Design, Prentice Hall, 1994. 10. Hawryszkiewycz, I.T., Relational Database Design. An Introduction, Prentice Hall Inc. 1990. 11. Jacobson, I, Booch G., Rumbaugh J., The Unified Software Development Process, Addison-Wesley, 1999. 12. Jeffrey H. A., Prescott M. B., McFadden F.R., Modern Database Management, Sixth Edition, Prentice Hall, 2002. 13. Kendall K. E., Kendall J.E., Systems Analysis and Design, Prentice Hall, 4th Edition, 1999. 14. Lungu I., Bordea C., Bădescu G., Ioniţă C., Baze de date: organizare, proiectare şi implementare, Editura ALL, 1996. 15. Lungu I., et al., Sisteme Informatice, Editura Economică, 2003. 16. Panţîru M., Proiectarea sistemelor informatice economice – note de curs, Ed. Fundaţiei Chemarea, 1995, Iaşi 17. Popovici D. M., Popovici I. M., Rican I. G., Proiectare şi implementare software, Editura Teora, 1998 18. Sabău G., Avram V., Sisteme informatice şi baze de date, Ed. Oscar Print, 1998 19. Silberschatz, A., KorthH.F, Sudarshan, S., Database System Concepts, Fourth Edition, McGRAW-HILL. 2001. 20. Stanciu V. Sisteme informatice de gestiune, Editura Tribuna Economică, Bucureşti, 1999. 21. Stanciu V., Proiectarea sistemelor Informatice de Gestiune, Ed. CISON, 2000 22. Teorey, Toby J., Database Modeling & Design, Third Edition, Morgan Kaufmann, 1999. 23. Zaharie D. et al., Proiectarea sistemelor informatice de gestiune, Ed. Economică, Bucureşti, 2002.

56