UNIVERSITATEA LUCIAN BLAGA DIN SIBIU FACULTATEA DE TIINE ECONOMICE

SISTEME INFORMATICE

- Note de curs -

SIBIU - 2011

CUPRINS

Capitolul 1 Sisteme informatice..... 1.1. Sistem, Sistem informaional, Sistem informatic. 1.1.1. Componentele sistemului informatic 1.1.2. Clasificarea sistemelor informatice. 1.1.3. Obiectivele sistemelor informatice....................................................................... 1.1.4. Ciclul de via a unui sistem informatic....... 1.1.5. Coninutul bazei informaionale a unei ntreprinderi ... 1.1.6. Ciclul prelucrrii datelor pentru sistemul informatic.... 1.1.7. Sistemele informatice de gestiune ... 1.2. Metodologii de realizare a sistemelor informatice....... 1.2.1. Coninutul metodologiilor de realizare a sistemelor informatice..... 1.2.2. Metode i tehnici de realizare a sistemelor informatice ...... 1.3. Instrumente CASE........................................................................................................ 1.3.1. Funciile CASE .................................................... 1.3.2. Trsturi definitorii ale CASE-ului....................................................................... 1.3.3. Exemple de instrumente CASE ........................... Capitolul 2 Iniierea i planificarea realizrii unui sistem informatic.... 2.1. Identificarea, selecia, iniierea i planificarea proiectelor... 2.2. Analizele de fezabilitate.. .. ..... 2.3. Tehnici de reprezentare a planurilor i programarea calendaristic............................. Capitolul 3 Analiza sistemului existent i definirea cerinelor noului sistem........................ 3.1. Studiul sistemului informaional existent..... 3.2. Determinarea cerinelor sistemului .................. 3.2.1. Metodele tradiionale utilizate n analiza i determinarea cerinelor sistemului.. 3.2.2. Metode moderne de analiz i determinare a cerinelor sistemului.. 3.3. Structurarea cerinelor sistemului - modelarea logic a datelor i prelucrrilor... 3.3.1. Diagramele fluxurilor de date (DFD).. 3.3.2. Descompunerea funcional i rafinarea DFD.. 3.3.3. Modelarea sistemului current.... 3.3.4. Modelarea logicii proceselor.... 3.4. Modelarea conceptual a datelor (diagramele entitate relaie, DER)........................ 1

3 3 5 6 7 7 9 9 10 11 11 12 14 15 15 16

18 18 20 21

23 23 24 25 25 26 27 28 31 33 35

Sisteme informatice

3.4.1. Modelul Entitate/Relaie (E/R)............................................................................. 3.5. Selectarea celei mai bune variante strategice de proiectare ....
Capitolul 4 Proiectarea logic a sistemelor informatice..................................................................................... 4.1. Proiectarea formularelor/formatelor i a rapoartelor.......................................................... 4.1.1. Proiectarea situaiilor cu rezultate finale (rapoartelor)....................... 4.1.2. Proiectarea codurilor ... 4.1.3. Proiectarea intrrilor n sistemul informatic...................................... 4.2. Proiectarea interfeelor i a dialogurilor ....... 4.3. Proiectarea logic a bazelor de date.

43 47
48 48 48 51 52 54 55

4.3.1. Normalizarea relaiilor - Forme normale.............................................................. 4.3.2. Simplificarea structurii datelor prin normalizare.. 4.3.3. Transformarea diagramelor entitate-relaie n relaii
Capitolul 5 Proiectarea fizic a sistemelor informatice....................................................... 5.1. Proiectarea fizic a bazelor de date i a fiierelor................................................................. 5.1.1. Obiectivele fundamentale ale unei baze de date................................................... 5.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD).... 5.1.3. Administratorul bazei de date... 5.1.4. Proiectarea securitii bazelor de date i a fiierelor.... 5.1.5. Limbajul SQL crearea, administrarea, interogarea bazelor de date relaionale. 5.2. Proiectarea programelor i a procedurilor............ 5.2.1. Atributele modulelor........................................................................................................ 5.2.2. Structurile de control ale programelor.......................................................................... 5.2.3.Proiectarea i realizarea programelor............................................................................ 5.3. Proiectarea sistemelor distribuite.......................................................................................... Bibliografie..............................................................................................................................

59 63 65

66 66 67 67 68 69 70 81 82 83 87 87 109

CAPITOLUL 1. SISTEME INFORMATICE 1.1. Sistem, sistem informaional, sistem informatic Un sistem reprezint un ansamblu de elemente (componente) interdependente ntre care se stabilete o interaciune dinamic, pe baza unor reguli prestabilite, cu scopul atingerii unui anumit obiectiv [4]. Conform teoriei sistemelor orice organism economic este un sistem. Organizaie o intreprindere, instituie, societate comercial. n orice organizaie se disting 3 componente: - sistemul de conducere sau de decizie; - sistemul informaional; - sistemul operaional. Sistemul informaional cuprinde ansamblul informaiilor interne i externe utilizate n cadrul organizaiei precum i datele care au stat la baza obinerii lor, procedurile i tehnicile de obinere a informaiilor (plecnd de la datele primare) i de difuzare a informaiilor, precum i personalul implicat n culegerea, transmiterea, stocarea i prelucrarea datelor. Sistemul informaional are dou componente: - componenta pentru stocarea (memorarea informaiilor); - componenta pentru prelucrarea informaiilor. Orice organizaie interacioneaz cu alte organizaii externe ei primind informaii din exterior i furniznd informaii ctre lumea exterioar. Funciile unui sistem informaional sunt: - s colecteze informaii din sistemele operaional i decizional precum i informaiile ce provin din mediul extern; - s memoreze aceste informaii precum i informaii rezultate din prelucrarea lor; - s asigure accesul la memorie n vederea comunicrii informaiilor stocate; - s prelucreze informaiile la cererea sistemului operaional i a sistemului de conducere. Noiunea de sistem informatic este legat de informatizarea activitii organizaiei, deci folosirea echipamentelor hardware i a produselor software pentru organizarea i administrarea informaiilor. Utilizarea calculatoarelor n cadrul sistemului informaional (SI) al unei organizaii conduce la definirea componentei Sistem Informaional Automatizat (SIA) care cuprinde numai lucrrile realizate cu ajutorul calculatoarelor. Relaia SI SIA este reprezentat n figura 1.1.

Sisteme informatice Sistem informatizat Procesor de informaii Informaie Reguli

Reguli i proceduri scrise
Programe i Structuri de date

Sistem manual

Om

Fiiere manuale Fiiere informatice

Sistem automatizat

Calculator

Fig. 1.1. Relaia SI SIA (Sursa: [7]) Definiie: Un sistem informatic este un sistem utilizator-calculator integrat, care furnizeaz informaii pentru a sprijini activitile de la nivel operaional i activitile de management ntr-o organizaie, utiliznd echipamente hardware i produse software, proceduri manuale, o baz de date i modele matematice pentru analiz, planificare, control i luarea deciziilor [7]. Elaborarea sistemelor informatice impune modelarea sistemului informaional al organizaiei cu ajutorul unui formalism prin care s poat fi reprezentat ct mai sugestiv i fidel realitatea din cadrul sistemului informaional. Sistemele informatice complexe pot fi descompuse n subsisteme, care la rndul lor pot fi descompuse n aplicaii destinate unor categorii de utilizatori, aplicaii care la rndul lor pot fi constituite din unul sau mai multe programe scrise n diverse limbaje de programare dup cum este ilustrat n figura 1.2.
Sistem Informatic

Subsistem 1

Subsistem 2

Subsistem n

Aplicatia 2.1

Aplicatia 2.k

Program 2.k.1

Program 2.k.s

Fig.1.2. Sistem informatic, subsisteme, aplicaii, programe

Pentru organizaii de complexitate mic, informatizarea poate nsemna realizarea unei singure aplicaii informatice referit de asemenea ca sistem informatic. Sistemele, subsistemele i aplicaiile informatice sunt produse informatice numite i produse software. Un produs informatic este constituit din programe care acceseaz baza de date i din documentaia necesar pentru utilizarea i ntreinerea programelor. Acestea se realizeaz n baza unor metodologii i necesit parcurgerea unor etape ncepnd cu specificarea cerinelor i terminnd cu implementarea, exploatarea i ntreinerea lor. Sistemul informatic economic este un ansamblu structurat de elemente intercorelate funcional pentru automatizarea procesului de obinere a informaiilor i pentru fundamentarea deciziilor. Sistemul informatic este inclus n sfera sistemului informaional atta vreme ct n cadrul sistemului informaional vor exista o serie de activiti care nu vor putea fi automatizate [2].

1.1.1. Componentele sistemului informatic Un sistem informatic este compus din [2]: - baza informaional; - baza tehnic; - sistemul de programe; - baza tiinific i metodologic; - factorul uman (resursele umane); - cadrul organizatoric. Baza informaional cuprinde: - datele supuse prelucrrii; - fluxurile informaionale; - sistemele i nomenclatoarele de coduri. Baza tehnic este constituit din totalitatea mijloacelor tehnice de culegere, transmitere, stocare i prelucrare a datelor, locul central revenind calculatoarelor electronice. Sistemul de programe cuprinde totalitatea programelor utilizate pentru funcionarea sistemului informatic n concordan cu funciunile i obiectivele stabilite. Sunt avute n vedere att programele de baz (software de baz) ct i programele aplicative (software de aplicaie). Baza tiinific i metodologic este constituit din: - algoritmi; - formule; - modele; - tehnici de realizare a sistemelor informatice. Resursele umane constau din: - personalul de specialitate: analiti, programatori, ingineri de sistem, analitiprogramatori ajutori, operatori, etc.; - beneficiarii sistemului. Cadrul organizatoric este cel specificat n regulamentul de organizare i funcionare (ROF) al unitii n care va fi utilizat sistemul informatic.

Sisteme informatice La realizarea i utilizarea unui sistem informatic trebuie avute n vedere reele, echipamente, produse software de baz, produse software de aplicaie. Reele - dup aria de ntindere geografic: - Locale =LAN (Local Area Network) la nivelul unei organizaii; - Metropolitane MAN (Metropolitan Area Network) la nivel de ora, localitate; - De mare ntindere -WAN (World Area Network) (ex. Jude, ar). - dup accesibilitate: - Internet (reeaua Web) o colecie mondial de reele interconectate; - Intranet un sit Web sau un grup de sit-uri care aparin unei organizaii, accesibil numai pentru membrii acesteia; - Extranet o reea intranet care este parial accesibil utilizatorilor externi autorizai. Echipamente - Echipamente de calcul : calculatoare, staii grafice, pentru servere de reea, servere de baze de date, staii de lucru (clieni, utilizatori), UPS-uri. - Echipamente de comunicaie : router-e, hub-uri, modem-uri, switch-uri. Produse software Produse software de baz: - Sisteme de operare pentru serverul de reea (UNIX, Windows NT server, Windows 2000, Novell) i pentru staiile de lucru sau clieni (Windows 95, Windows 98, Windows NT work station, Windows 2000); - Sisteme de Gestiune a Bazelor de Date (ORACLE, SQL Server Microsoft, MySQL, ACCESS, Visual FoxPro, etc.); - Sisteme GIS (Geographical Information System) utilizate pentru realizarea aplicaiilor din domeniul cadastrului (stocarea i prelucrarea datelor spaiale ); - Limbaje (medii) de programare utilizate pentru realizare software de aplicaie. Produse software de aplicaie produse program ce constituie aplicaiile i subsistemele sistemului informatic. 1.1.2. Clasificarea sistemelor informatice Sistemele informatice se clasific dup mai multe criterii. 1. n funcie de domeniul de utilizare, sistemele informatice pot fi pentru : conducerea activitilor economico-sociale conducerea proceselor tehnologice cercetare tiinific i proiectare tehnologic activiti speciale.

2. n funcie de nivelul ierarhic ocupat de sistemul economic n structura organizatoric a societii, conform cruia exist sisteme informatice [2]: - pentru conducerea activitii la nivelul unitilor economice

pentru conducerea activitii la nivelul organizaiilor economico-sociale cu structur de grup sisteme informatice teritoriale pentru conducerea ramurilor, subramurilor i activitilor la nivelul economiei naionale sisteme informatice funcionale generale . 3. n funcie de elementul supus analizei [5]: sisteme informatice orientate spre funcii; sisteme informatice orientate spre proces; sisteme informatice orientate spre date; sisteme informatice orientate spre obiecte; sisteme informatice orientate spre cunotine. 4. Dup modul de organizare a datelor [5]: sisteme bazate pe fiiere; sisteme bazate pe tehnica bazelor de date: ierarhice, reea, relaionale, orientateobiect; sisteme mixte. 5. Dup metoda folosit n analiza i proiectarea sistemelor [5]: sisteme dezvoltate dup metoda sistemelor; sisteme dezvoltate dup metoda clasic a ciclului de via; sisteme dezvoltate dup metoda structurat; sisteme dezvoltate dup metoda orientat-obiect; sisteme dezvoltate dup metoda rapid(RAD); sisteme dezvoltate dup metoda echipelor mixte(JAD); sisteme dezvoltate dup metoda prototipurilor. 6. Dup gradul de centralizare [5]: sisteme centralizate; sisteme descentralizate; 7. Dup gradul de dispersie a resurselor sistemului informatic: sisteme informatice locale (bazate pe reea local, staii de lucru): sisteme informatice distribuite (date distribuite).

8. Dup gradul de automatizare a activitilor de analiz i proiectare a sistemelor informatice [5]: - sisteme informatice dezvoltate pe baza analizei i proiectrii clasice; - sisteme informatice analizate cu instrumente automate i proiectate clasic; - sisteme informatice bazate pe instrumente diverse de automatizare a analizei i proiectrii; - sisteme informatice dezvoltate cu instrumente de tip CASE.

Sisteme informatice 1.1.3. Obiectivele sistemelor informatice Plecnd de la ideea c sistemul informatic este subordonat procesului decizional, al crui rol este de a asigura funcionarea normal i optim a ntregii activiti i de a reduce la minimum pierderile n caz de funcionare anormal, rezult c obiectivul oricrui sistem informatic trebuie s fie subordonat obiectivului propriu-zis al unitii economico-sociale. n acest context, obiectivul principal urmrit prin introducerea unui sistem informatic l constituie asigurarea conducerii cu informaii reale i n timp util, necesare fundamentrii i elaborrii operative a deciziilor [2]. 1.1.4. Ciclul de via a unui sistem informatic Sistemele informatice (SI) se caracterizeaz printr-un ciclu de via care ncepe cu decizia realizrii unui nou SI care s corespund mai bine noilor cerine ale utilizatorilor i se ncheie cu decizia de nlocuire a SI existent cu unul nou, mai performant. Ciclul de via se desfoar pe etape n cadrul fiecreia fiind definite faze i activiti specifice [4]. nc de la nceput facem meniunea c, indiferent de etapa istoric sau metodologic, sistemele sunt abordate prin prisma ciclului lor de via. Ele apar se dezvolt, descresc i pier, sau printr-un nou ciclu, se perfecioneaz, dnd natere unei alte versiuni sau chiar unui nou sistem. Mutaiile din domeniul tehnologiei informaionale i al metodelor de abordare a sistemelor s-au reflectat i n ciclul de via al dezvoltrii sistemelor, fie prin schimbarea etapelor acestuia, fie prin modificarea opticii de parcurgere a lor. Spre exemplu, odat cu abordarea orientat-obiect a sistemelor, s-au lansat i noi modele ale ciclului de via [4]. Prin parcurgerea materialelor de specialitate, se poate constata c numrul fazelor/etapelor variaz de la trei (de exemplu analiza, proiectarea, implementarea) la peste douzeci. Exist mai multe modele ale ciclului de via, multe dintre ele cunoscnd o evoluie n timp. Spre exemplu, modelul cascad (figura 1.3) prevede parcurgerea mai multor etape ale ciclului de via care se deruleaz secvenial fiind ns permis la nevoie revenirea la etapa parcurs anterior n vederea ndeprtrii neajunsurilor identificate n etapele superioare ale ciclului de via [4]. Etape ale ciclului de via a unui sistem informatic n modelul cascad ([7]) 1. Analiza i definirea cerinelor sunt definite scopurile, serviciile i restriciile pe care trebuie s le ndeplineasc sistemul informatic, prezentate ntr-o manier nct s poat fi nelese att de ctre utilizatorii sistemului ct i de personalul de proiectare. 2. Proiectarea sistemului i software-ului satabilirea cerinelor pentru hardware i software i elaborarea arhitecturii generale a sistemului. Funciile sistemului informaional vor fi reprezentate astfel nct s poat fi tranformate n unul sau mai multe programe executabile. 3. Implementarea i testarea unitilor de program proiectarea software-ului din etapa anterioar este transpus ntr-o mulime de programe sau module programi verificarea faptului c fiecare program sau modul satisface specificaia sa.

4. Integrarea i testarea sistemului integrarea i testarea programelor i modulelor program ca un sistem complet pentru a ne asigura c cerinele informaionale sunt satisfcute. Dup testare sistemul este livrat beneficiarului. 5. Exploatarea i ntreinerea sistemului este faza n care sistemul informatic este efectiv utilizat de ctre beneficiar i n care sunt descoperite i rezolvate eventuale erori de proiectare i programare i omisiuni n cerinele informaionale iniiale.
Analiza definirea cerinelor i

Proiectarea sistemului i a software-ului

Implementarea i testarea unitilor de program

Integrarea testarea sistemului

Exploatarea ntreinerea sistemului

Fig. 1.3. Etapele ciclului de via a unui sistem informatic n modelul cascad ([7])

Sisteme informatice 1.1.5. Coninutul bazei informaionale a unei ntreprinderi Prin analiza critic sunt identificate entitile bazei informaionale. n principal, pentru o ntreprindere acestea pot fi grupate dup cum urmeaz: pentru activitatea de aprovizionare: stocuri de materiale, intrri materiale, consumuri de materiale, contracte cu furnizorii, programe de aprovizionare; pentru activitatea de producie: tehnologii i reete de fabricaie, program de lucru, norme de munc i consumuri de manopere; pentru activitatea de desfacere: stocuri de produse, contracte cu clienii, realizri contracte; pentru activitatea de marketing: evoluia cererii i a ofertei, dinamica preurilor, elasticitatea cererii i a produciei; pentru activitatea financiar-contabil: solduri i rulaje contabile, calculaia costurilor, bugete de venituri i cheltuieli, contabilitatea analitic i sintetic; pentru activitatea de personal: evidena personalului, salarizri, dotri social-culturale i gestiunea lor; pentru activitatea de cercetare-dezvoltare: studii tehnico-economice, proiecte tehnice, investiii, etc.

1.1.6. Ciclul prelucrrii datelor pentru sistemul informatic Operaiunile care se execut asupra datelor, din momentul apariiei lor, pentru a genera informaii semnificative i relevante sunt referite la un loc prin noiunea de ciclul prelucrrii datelor. Ciclul cuprinde cinci faze: culegerea datelor, pregtirea datelor, prelucrarea datelor, ntreinerea fiierelor i obinerea informaiilor de ieire. Faza de culegere a datelor cuprinde dou activiti fundamentale [5]: observarea mediului care genereaz datele, fie printr-un observator uman, fie prin diverse echipamente; nregistrarea datelor, fie prin scrierea lor n documentele surs, fie prin captarea lor sub diferite forme cu ajutorul unor echipamente speciale.

Pregtirea datelor const ntr-un numr de operaii executate asupra datelor pentru a facilita prelucrarea lor ulterioar. Ele sunt [5]: clasificarea datelor, care implic atribuirea de coduri de identificare (simbol cont, cod secie, etc.), astfel nct datele s fie incluse n submulimile corespunztoare; gruparea datelor, adic acumularea intrrilor similare, pentru a fi prelucrate n grup; verificarea datelor cuprinde o mare varietate de proceduri pentru controlul corectitudinii datelor, nainte ca ele s fie prelucrate; sortarea datelor, prin care grupurile de date sunt aranjate n loturi de nregistrri, dup criterii de ordonare numeric, alfabetic, alfanumeric sau de timp; cuplarea a dou sau mai multe loturi de nregistrri ntr-unul singur; transmiterea datelor de la un punct la altul; transcrierea datelor dintr-o form n alta, astfel nct s se efectueze trecerea de la scrierea de mn la cea tipizat sau de la documentele scrise la mediile specifice.

10

Pregtirea datelor este o activitate realizat n toate tipurile de sisteme informaionale, dar capt o semnificaie deosebit n sistemele de prelucrare automat a datelor; partea informatizat a acestora fiind cunoscut ca sistem/subsistem informatic.
Culegerea datelor

Pregtirea datelor

Prelucrarea datelor

ntreinere fiiere Informaii ieire de

Fig. 1.4 Ciclul prelucrrii datelor [5] Prelucrarea datelor, poate s includ activiti, cum sunt [5]: calculaiile cuprind unele forme de tratare matematic a datelor; compararea supune unei examinri simultane dou sau mai multe tipuri de date ntre care exist o legtur logic (ex. soldul final i cel final); - sintetizarea este o activitate important prin care se comaseaz informaiile; - filtrarea este o alt operaiune prin care se extrag datele ce vor fi supuse prelucrrilor urmtoare; - restaurarea, prin care sunt aduse datele din memorie ntr-o form accesibil omului, pentru prelucrarea uman n continuare, sau ntr-o form prelucrabil tot pe calculator. n faza de ntreinere a fiierelor exist mai multe activiti, dintre care amintim: - memorarea (stocarea) datelor n vederea utilizrii lor viitoare; - actualizarea datelor memorate astfel nct s surprind cele mai recente evenimente; - indexarea datelor pentru a nlesni o uoar regsire a lor; - protecia datelor memorate, care cuprinde o mare varietate de proceduri i tehnici pentru prevenirea distrugerii lor sau a accesului neautorizat. Ultima faz a ciclului de prelucrare a datelor este obinerea informaiilor de ieire. Informaiile de ieire pot fi regsite n una din urmtoarele trei forme: documente, rapoarte ori rspunsuri la ntrebri. Termenul ieiri le cuprinde pe toate [5]. De cele mai multe ori, datele nu parcurg toate activitile, iar unele dintre ele pot chiar s nu treac prin cele cinci faze. -

11

Sisteme informatice 1.1.7. Sistemele informatice de gestiune Sistemul informatic de gestiune implic urmtoarele patru componente interdependente: domeniile de gestiune, datele, modelele, regulile de gestiune [4]. Sistemul informatic de gestiune asigur obinerea informaiei solicitate de utilizator, folosind mijloacele tehnologiei informaiei (TI). Sistemele informatice de gestiune sunt sisteme integrate. Se caracterizeaz printr-o introducere unic a datelor, preluate din documentele primare care actualizeaz o baz de date unic a contabilitii care va fi ulterior prelucrat pentru obinerea situaiilor specifice fiecrui utilizator [4].
Documente facturi ordin de plat bon de consum Situaia costurilor pe comenzi

Actualizare

Consultare 1

Consultare 2 BD

Balana de verificare Registrul jurnal Casa Banca

Fig. 1.5. Sistem informatic de gestiune integrat al contabilitii [4] Sistemul informatic de gestiune reunete subsisteme informatice specializate pe domenii ntre care se manifest interaciuni specifice. Fiecare subsistem definit grupeaz procese informaionale omogene, specifice unei anumite arii de interes [4]. La nivelul fiecrui subsistem vor fi definite aplicaii distincte corespunztoare acestor activiti. La rndul lor aplicaiile sunt formate din proceduri descompunndu-se n module reprezentnd secvene de cod prin care se realizeaz o funcie independent din cadrul procedurii. Exemplu. O procedur pentru operaia de actualizare se va descompune n urmtoarele module: 1. modulul coordonator al funciei de actualizare; 2. modulul pentru realizarea funciei de adugare de nregistrri; 3. modulul pentru funcia de tergere nregistrri; 4. modulul pentru funcia de modificare a nregistrrilor din baza de date.

1.2. Metodologii de realizare a sistemelor informatice Realizarea sistemelor informatice reprezint o aciune complex, care mbin un numr mare de activiti: analiz, proiectare, implementare, exploatare [2]. n plus, reclam resurse umane, materiale i financiare nsemnate, pe o perioad considerabil de

12

timp. Folosirea eficient a acestor resurse, n scopul obinerii unui sistem informatic performant a impus ordonarea acestui proces complex, ntr-o succesiune bine stabilit de etape i subetape i utilizarea unor metode i tehnici adecvate. Acest lucru a dus deci, la conturarea unor metodologii de realizare a sistemelor informatice. ntre diversele etape de realizare a sistemelor informatice exist o legtur indestructibil, legtur reflectat i de faptul c n mod logic i practic calitatea realizrii unor activiti din etapele i fazele precedente influeneaz n mod decisiv calitatea activitilor din etapa ce i urmeaz [2]. 1.2.1. Coninutul metodologiilor de realizare a sistemelor informatice Metodologiile de realizare a sistemelor informatice cuprind [2]: - modalitatea de abordare a sistemelor, pentru elucidarea raportului dintre variaiile sistemului i dinamismul su; - regulile de formalizare a datelor i proceselor de prelucrare; - instrumentele pentru concepia, realizarea i elaborarea documentaiei; - modalitatea de derulare a proiectului i aciunile specifice fiecrei etape (ciclul de viat); - definirea modului de lucru, rolului analitilor i proiectanilor i a raportului dintre ei; - modalitile de administrare a proiectului (planificare, programare, urmrire). Totodat, metodologiile au rolul de a indica modul de desfurare a acestui proces, stabilind [2]: - componentele procesului de realizare a sistemului informatic (etape, subetape, activiti, operaii) i coninutul lor; - fluxul parcurgerii (executrii) componentelor; metodele, tehnicile, procedeele, instrumentele, normele si standardele utilizate. n funcie de modul de abordare i domeniul de aplicabilitate, metodologiile utilizate sunt: - metodologii din domeniul gestiunii: AXIAL (firma IBM), MERISE (Ministerul industriei-Franta), IE (James Martin), SSADM (Marea Britanie); - metodologii orientate obiect: OMT (General Electric -SUA), OOD (Michael Jackson); - metodologii pentru conducerea proiectelor de sisteme informatice: SDM / S, METHOD/ 1 Arthur Andersen, NAVIGATOR (Ernst & Young - James Martin). 1.2.2. Metode i tehnici de realizare a sistemelor informatice La realizarea sistemelor informatice se utilizeaz : metode, tehnici, instrumente, procedee de lucru [2]. Metodele utilizate n proiectarea sistemelor informatice reprezint modul unitar sau maniera comun n care analitii de sisteme, programatorii i alte categorii de persoane implicate, realizeaz procesul de analiz a sistemului informaional-decizional existent, proiectarea i introducerea sistemului informatic. Deci, metoda are un caracter general, n cadrul ei aplicndu-se anumite tehnici de lucru [2]. Tehnicile de lucru utilizate n proiectarea sistemelor informatice reprezint felul n care se acioneaz eficient i rapid, n cadrul unei metode, pentru soluionarea

13

Sisteme informatice diferitelor probleme ce apar n procesul de proiectare. Prin aceste tehnici se mbin armonios cunotinele despre metode cu miestria personal a celor chemai s aplice metodele si s utilizeze instrumentele adecvate [2]. Utilizarea acestor metode, tehnici, instrumente, procedee de lucru n proiectarea sistemelor informatice se face n conformitate cu o serie de principii i n limita unor metodologii de lucru care se adopt n funcie de situaia real la care se refer. n abordrile incipiente se lucra cu probleme izolate i ulterior s-a efectuat trecerea la abordarea sistemic (modular), odat cu abordarea funcional sau, mai bine zis, cu analiza i descompunerea funcional (n fiecare modul exist cte o funcie) i ulterior abordarea orientat-obiect [2]. Pe parcurs s-au impus dou strategii de abordare i anume: - strategia top down (de sus n jos); - strategia bottom up evolutiv (de jos n sus). n strategia top down abordarea general este divizat n uniti componente prin rafinri repetate, metoda de proiectare putnd fi descris sub forma unei diagrame ierarhice cu module de control pe nivele superioare i cu module detaliate pe nivelele inferioare. Structura organizatoric a unei uniti economico-sociale numit organigrama unitii poate fi reprezentat printr-o astfel de diagram ierarhic. Pentru uniti economice productive n organigram se disting urmtoarele patru nivele de reprezentare [7]: - nivelul conducerii strategice, reprezentat de directorul general i consiliul de administraie; - nivelul conducerii tactice (directori pe funciuni); - nivelul compartimentelor funcionale (servicii i posturi de lucru) i de proiectare, cercetare (laboratoare) care asigur conducerea operativ a sistemului prin efii lor; - nivelul compartimentelor de producie (secii, ateliere) care realizeaz funcia de producie a sistemului economic. n strategia bottom up evolutiv, se pornete de la o tratare minimal care se extinde treptat pe msura naintrii n realizarea sistemului. n practic, de cele mai multe ori se utilizeaz o combinare a celor dou strategii. Metodele de abordare a sistemelor informatice ar putea fi grupate prin prisma celor mai muli autori astfel [5]: - metode orientate spre funcii, numite i metode ale descompunerii funcionale; - metode orientate spre fluxuri date, deci metode orientate spre procese, deoarece diagramele fluxurilor de date se ntrebuineaz pentru descrierea proceselor; - metode orientate spre informaie sau date, orientate-informaii, aprute ca urmare a popularizrii puternice a ingineriei informaiei a lui JAMES MARTIN, dar i a diagramelor entitate-relaie ale lui CHEN [3]; - metode orientate-obiect. Caracteristici eseniale ale principalelor metode Informaia este vzut de DeMarco n 1982, ca fiind posibil de abordat prin trei perspective specifice sistemelor informaionale sau prin trei dimensiuni: date, funcii, comportament.

14

Datele sunt surprinse din prisma structurii lor sub form de atribute i nseamn de fapt, ceea ce are stocat, i reflect structura static [5]. Funciile scot n eviden n mod limitat ceea ce face sistemul. El poate fi vzut i ca un proces, ntruct elementele sistemului despre care se pstreaz datele de rigoare sunt supuse unor transformrii funcionale, prin intermediul proceselor [5]. Comportamentul este invocat pentru a reda o alt modalitate de percepie a sistemului, influena evenimentele i proprietilor sistemului, i sugereaz dinamica lui [5]. Metoda descompunerii funcionale (orientate funcii) [5]. Dintre autorii remarcabili care au abordat descompunerea funcional i enumerm pe civa cum ar fi DeMarco, Yourdon i Constantine, Jackson, Page-Jones, Warnier-Orr, Dahl, Marco&Gowan. Descompunerea funcional este cea care anun apariia proiectrii structurate i analizei structurate. Fiecare funcie este descompus n subfuncii, pn se obin structuri uor de transpus n instruciunile limbajelor de programare. Metodele fluxurilor de date (orientate-proces) [5]. Prin aceast metod analitii efectueaz reprezentarea lumii reale prin simboluri care reprezint fluxul datelor, transformrile datelor, stocarea datelor, entiti externe, etc. Metoda orientat spre procese are nc un mare grad de asemnare cu descompunerea funcional. Metode orientate spre informaii (orientate-date) [5] Dou realizri importante n domeniu au dat tonul unei orientri n abordarea sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaie, de ctre Peter P. Chen (1976) i ingineria informaiei, n viziunea lui James Martin. Metoda orientat-obiect [5] Metodele OO constituie o categorie particular a metodelor de dezvoltare software, care privesc construirea sistemelor pentru care clasa reprezint unitatea arhitectural fundamental. Clasa este o grupare logic a obiectelor care au aceeai structur i un comportament similar.

1.3. INSTRUMENTE CASE Problema CASE-ului (Proiectarea Sistemelor/Programelor asistat de calculator sau cu Ajutorul Calculatorului Computer Aided Systems Engineering) a devenit foarte important la mijlocul anilor 1980, cnd hardul sa extins prin seria PC-urilor, iar reelele au devenit mai puternice, constituindu-se sistemele distribuite. Obiectivul principal al CASE-ului l constituie punerea n practic a produselor-program de proiectare i realizare a softului cu ajutorul calculatorului. Instrumentele oferite de CASE sunt utilizabile din faza de definire a cerinelor pn la ntreinerea fizic a produsului informatic. Totui, analiza i proiectarea, bazate pe conceptele i metodele structurate, reprezint elementele forte ale instrumentelor CASE, iar n ultimii ani CASE a acordat atenia cuvenit analizei, proiectrii i programrii orientate pe obiecte [5].

15

Sisteme informatice Majoritatea produselor soft au fost construite n mod artizanal, fr posibilitatea testrii complete a lor, fiind nsoite de o documentaie destul de slab. Instrumentele CASE implic utilizarea calculatorului ca un mijloc de susinere a activitilor de planificare, definire, proiectare i realizare a softului. Ele se bazeaz pe logica structural, pe descompunerea funcional i reprezentarea prin diagrame a fluxurilor de date ale aplicaiilor. Potrivit principiilor conceptuale, sistemele CASE au fost realizate pentru a ncuraja abordarea logicii structurate i pentru folosirea calculatorului ca un mod de tezaurizare a lucrrilor i ca o planet de desen, pe care pot fi plasate reprezentrile structurate ale sistemelor sau aplicaiilor. Pe msura evoluiei lor, sistemele CASE au devenit mult mai complexe, permind ca procesele de proiectare i realizare a aplicaiilor s se desfoare ntr-un mediu informatic interactiv, oferind utilizatorilor un ntreg arsenal de instrumente i proceduri, prin care pot proiecta, realiza, testa, documenta, ntreine/actualiza i exploata sistemul. Utilizarea produselor de tip CASE a fost determinat de [5]: - calitatea ndoielnic a aplicaiilor realizate n mod tradiional; - frustrarea utilizatorilor n ncercarea lor de a participa la procesul de proiectare i realizare a aplicaiilor, datorit nivelului ridicat de cunotine informatice solicitate de metodele tradiionale; - costuri deosebit de mari pe care le presupun ntreinerea i actualizarea softului funcional; - imposibilitatea rezolvrii tuturor cerinelor utilizatorilor; - limitarea posibilitii de reprezentare grafic a schemelor de realizare a noilor proiecte. - Folosirea sistemelor CASE este motivat i de urmtoarele avantaje: - reducerea complexitii logicii de descriere a sistemului; - posibilitatea de a alege dintre mai multe variante de proiectare; - creterea vitezei de realizare a sistemelor; - realizarea succesiv a componentelor unui sistem; - creterea integrrii; - consolidarea disciplinei de proiectare; - oferirea unei interfee de proiectare; - folosirea depozitelor modularizate; - salvarea i refolosirea unor componente din diagramele realizate; - simplificarea activitilor de proiectare i realizare a sistemelor/aplicaiilor. Utilizarea sistemelor CASE a nceput cu introducerea diagramelor fluxurilor de date, care fac posibil realizarea unui model al derulrii proceselor sistemului/aplicaiei care se proiecteaz. A urmat folosirea dicionarului de date ca un depozit al tuturor datelor privind sistemul sau aplicaia. Au aprut ecranele predefinite pentru a prezenta ce poate s obin utilizatorul prin exploatarea sistemului. S-a apelat la facilitile grafice, care pot folosi simbolurile logicii structurate i care permit proiectantului s realizeze o diagram coerent a fluxurilor de date [5].

16

1.3.1. Funciile CASE Primele sisteme CASE erau un set de aplicaii neintegrate, cu funcii distincte, fr a fi interconectate. Aceste limite au fost eliminate, n cea mai mare parte, prin generaiile actuale, care ncearc s realizeze o integrare complet i uoar a tuturor elementelor, integrarea reprezentnd, de fapt, factorul cel mai important al metodologiei CASE [5]. CASE se bazeaz pe dou funcii fundamentale [5]. Prima funcie const n posibilitatea descompunerii de sus n jos (top-down) a sistemului informatic n procese i module distincte, fiecare avnd definite responsabilitile funcionale i/sau operaionale. Cea de-a doua funcie se refer la faptul c sistemele informaionale pot fi reprezentate ntr-o form grafic concis, folosind cteva simboluri de baz. Importana acestor dou funcii rezid n posibilitatea utilizrii modularitii aplicaiilor, a diagramelor, obinerea unei documentaii privind realizarea, evaluarea arhitecturii i utilizarea sistemului. Pentru definirea i construirea sistemelor, produsele CASE presupun stabilirea i respectarea unei anumite discipline. Metodologia ofer o interfa ntre crearea i verificarea/validarea proiectului logic, dezvoltarea unei biblioteci cu documentaii, care include i integreaz caracteristicile proceselor i paii de parcurs, pentru descrierea modului de lucru; ofer un model al produsului final, ce poate fi folosit n realizarea operaiilor de exploatare i ntreinere a sistemului/aplicaiei, i ofer o interfa pentru pstrarea evoluiei proiectului. Folosirea reprezentrilor grafice n logica CASE ofer posibilitatea descompunerii aplicaiei n mai multe componente logice. Prin ataarea unei baze de date la elementele grafice, se va obine un depozit ce va conine paii i funciile reprezentate n diagramele construite. Dac aceste elemente sunt corect stabilite, ele vor sta la baza descrierii proceselor, ce vor constitui procedurile de prelucrare ale sistemului/aplicaiei. Modelarea grafic n sistemele CASE prezint o interactivitate ridicat, permind construirea diagramelor, deplasarea de la o diagram la alta, modificarea, extinderea, copierea, evaluarea i descrierea elementelor unei aplicaii [5]. Modelele grafice permit conectarea fluxurilor logice ntre activitile i funciile specifice aplicaiei, relaii care pot fi testate i validate n mod automat. 1.3.2. Trsturi definitorii ale CASE-ului Evoluia CASE-ului, a determinat apariia I-CASE-ului. Integrated CASE se refer la toate aspectele integrrii, chiar dac sistemele sunt deschise sau nu [5]. Caracteristicile mediilor moderne de tip CASE [5]: - un set de instrumente specifice pentru realizarea sistemelor; - diversitatea modurilor de interaciune; - semnificaia reprezentrilor grafice; - elemente de tip verificare i validare (V&V); - natura bidirecional, deplasri pe vertical n structura sistemului; - deschidere pentru interconectarea instrumentelor CASE; - sprijin pentru lucrul cu utilizatori multipli;

17

Sisteme informatice descompunerea; performane de deplasare, pe orizontal, de la un instrument la altul; grade diferite de automatizare; INTEGRAREA. CASE-ul nu este un proces independent. El constituie un set integrat de metodologii, care urmresc realizarea ciclului de via al unui sistem. La sfritul fiecrei faze a ciclului de via, rezultatele obinute trebuie supuse unei analize i verificri, iar utilizatorii trebuie informai asupra modului de gestionare a procedurilor de lucru. Ei sunt cei care trebuie s dea avizul de continuare a parcurgerii fazelor urmtoare, pe baza a ceea ce li s-a prezentat. Este, de fapt, un proces de revalidare a conceptelor folosite n proiectarea sistemului i a modelului proiectat pe msura desfurrii operaiunilor, din faza de proiectare pn la predarea produsului final. CASE poate sprijini aceste proceduri prin punerea la dispoziie a unei documentaii, critici sau modificri asupra elementelor din modelul proiectat. Pe acest fond, pot fi fcute evaluri, critici sau modificri asupra elementelor din modelul proiectat. Rezultatele obinute n urma proiectrii unui anumit model de sistem constau n documentaia oferit, care acoper ntregul ciclul de via al sistemului, cu toate operaiile i procedurile pe care le presupune. Datele din documentaia modelului sunt, de obicei, nlocuite cu cele reale i se parcurg paii de implementare a sistemului pentru a obine un model funcional. n plus, CASE ofer posibilitatea de a analiza ieirile obinute i de a le modifica pentru a reflect schimbrile intervenite n sistem, modulele definite i depozitul de date [5]. 1.3.3. Exemple de instrumente CASE (Conferina Naional de nvmnt Virtual, ediia a III-a, 2005) n literatura de specialitate, instrumentele CASE sunt clasificate i dup un alt criteriu dect cel al activitilor din ciclul de via al sistemelor pe care le sprijin. Acest criteriu se refer la metodologia pe care o ncorporeaz pentru realizarea sistemelor. Astfel, se ntlnesc urmtoarele trei categorii: - instrumente CASE bazate pe metodologia structurat; - instrumente hibride, ce conin elemente specifice orientrii-obiect, dar care nu permit realizarea sistemelor orientate-obiect; - instrumente pur orientate-obiect. n cele ce urmeaz se vor prezenta cteva exemple de CASE folosite de cele mai utilizate metodologii de analiz i proiectare, respectiv metodologia structurat i cea orientat pe obiecte. A) Metodologia structurat Westmount I-CASE Yourdon ofer suport complet pentru realizarea sistemelor informatice. Avnd la baza metoda structurat propus de Yourdon, acest instrument CASE integrat ofer posibilitatea lucrului n echip, posibilitatea de generare i reutilizare a codului i generarea automat a documentaiei de realizare a sistemului informatic. Repository este componenta central a arhitecturii Westmount I-CASE Yourdon. Repository este implementat cu ajutorul unui SGBD relaional: Informix, Ingres sau Oracle. -

18

Analyst, este componenta ce ofer suport pentru analiza structurat. Metoda este implementat de Yourdon i De Marco. Westmount I-CASE Yourdon ofer suport pentru un set extins de instrumente i anume editoare pentru diagrame de flux a datelor, diagrame entitate asociere, diagrame de structur a datelor editoarele matriciale pentru matricea listei de evenimente. Arhitect este componenta ce permite definirea arhitecturii sistemului (proiectarea de ansamblu). Editorul Designer este componenta ce ofer suport pentru proiectarea de detaliu a sistemului informatic. Proiectarea de detaliu a aplicaiei este strns legat de proiectarea bazei de date. Pentru modelarea datelor se utilizeaz diagrama entitate asociere. Programmer este mediul de programare care ofer suport pentru generarea codului surs, compilare, lansare n execuie i testarea aplicaiei. Generatorul de cod translateaz specificaiile de proiectare n cod surs. Astfel, pe baza diagramei entitate asociere se genereaz codul DDL (n SQL) ce definete structura fizic a bazei de date. Codul poate fi completat pentru a defini restriciile de integritate i modul fizic de stocare a bazei de date. Este prezentat i facilitatea de inginerie inversat care translateaz definirile asociate bazei de date existente ntr-o diagram entitate asociere. Codului aplicaiei este generat n limbajul C mbogit cu instruciuni SQL pornind de la specificaiile din schemele de structur. Docwriter este componenta care permite generarea documentaiei pentru fiecare etap de realizare a sistemului. Utilizarea produsului Westmount I-CASEY Yourdon mbuntete productivitatea realizrii sistemelor informatice i ofer garanii pentru calitatea sistemelor obinute. B) Metodologia orientat-obiect Expresia pur orientate-obiect" se refer la faptul c pe de o parte, instrumentele CASE conin numai elemente specifice abordrii orientate-obiect a sistemelor, iar pe de alt parte la faptul c se bazeaz pe metodele i tehnicile de analiz i proiectare orientate-obiect. Instrumentele CASE orientate-obiect, din punct de vedere al etapelor ciclului de via al sistemelor, pot fi grupate ca i cele convenionale, astfel: - Upper CASE orientat-obiect pentru analiza i proiectarea sistemelor; - Lower CASE orientat-obiect pentru generarea codului-surs al aplicaiilor; - I-CASE orientat-obiect care acoper ntregul ciclu de via. Deoarece tendina se ndreapt tot mai mult spre tehnologiile informaionale orientateobiect, nici domeniul instrumentelor ce sprijin realizarea sistemelor nu poate s nu se adapteze la aceast orientare, lucru ce a dus la apariia a numeroase produse CASE orientate-obiect sau la reorientarea firmelor productoare de instrumente convenionale spre nglobarea n produsele lor a elementelor specifice abordrii obiectuale. Designer/2000 Setul de instrumente Designer/2000 este parte integrant din portofoliul de instrumente de dezvoltare oferit de Oracle i reprezint o soluie integrat pentru

19

Sisteme informatice dezvoltarea de sisteme client/server din generaia a doua sau de sisteme Intranet bazate pe Web. Designer/2000 acoper toate fazele ciclului de dezvoltare a aplicaiilor software, pornind de la modelarea sistemului informatic (business modelling) pn la exploatare. Abordarea Designer/2000 bazat pe un Repository permite ca anumite componente sau toate componentele s fie folosite pentru dezvoltarea rapid de aplicaii scalabile, multiplatform, distribuite.

20

Capitolul 2 Iniierea i planificarea realizrii unui sistem informatic n cadrul acestui capitol vor fi prezentate o serie de aspecte privind primele activiti desfurate n vederea realizrii sistemelor informatice, activiti definite n literatura de specialitate sub numele de microanaliza sistemelor, component preluat din managementul proiectelor i care are n vedere modalitile de identificare a proiectelor de dezvoltare a sistemelor informaionale, precum i modul n care au loc iniierea i planificarea acestora, n strns legtur cu planul strategic organizaional. 2.1. Identificarea, selecia, iniierea i planificarea proiectelor Identificarea i selecia proiectelor de dezvoltare a sistemelor informaionale reprezint prima etap din ciclul de via a dezvoltrii sistemelor care, mpreun cu iniierea i planificarea proiectelor, constituie microanaliza, component preluat din managementul proiectelor. Evidenierea acestor activiti n cadrul modelului cascad de derulare a fazelor sau etapelor ciclului de via a sistemului este reprezentat n figura 4.1 [5]. A. identificarea i selectarea proiectului B. iniierea i planificarea proiectului C. analiza D. proiectarea logic E. proiectarea fizic F. implementarea G. ntreinerea Figura 2.1 Ciclul de via al dezvoltrii sistemelor [5] Din modelul prezentat rezult c orice etap se descompune n activiti, ceea ce pentru identificarea i selecia proiectelor nseamn [5]:

microanaliza

Fazele ciclului de via al dezvoltrii sistemului

21

Sisteme informatice identificarea potenialelor proiecte de dezvoltare; clasificarea i ierarhizarea lor; selecia.

Identificarea potenialelor proiecte de dezvoltare Problema esenial a activitii de identificare a potenialelor proiecte de dezvoltare a sistemului const n nominalizarea celor ce pot fi abilitai s fac propuneri pertinente. Acetia pot fi: top-managerii, comitetul de iniiativ, departamentul utilizatorilor, grupul de dezvoltare. Caracteristicile eseniale ale variantelor de proiecte propuse n cele patru situaii sunt prezentate tabelul 2.1. Tabel 2.1-variante de proiecte [5] Propuneri Metoda de selecie a proiectului Top-managerii

Caracteristicile proiectului orientare puternic spre strategie; cele mai mari dimensiuni ale proiectului; cele mai de durat proiecte. orientare mixt (a diferiilor reprezentani); vizeaz schimbrile organizaionale cele mai mari; analiz formal a costurilor i avantajelor proiectelor; proiecte mai mari i mai riscante. limitat, neorientat strategic; realizare mai rapid; civa utilizatori reprezint niveluri ale conducerii, precum i funciile ntreprinderii. integrare n sistemul existent; puine ntrzieri n realizarea proiectului; mai puin interesat de analizele cost avantaje.

De sus n jos

Comitetul de iniiativ

Departamentul utilizatorilor

De jos n sus

Grupul de dezvoltare

Selecia proiectelor de dezvoltare a sistemelor informaionale Datorit efectelor diferite i a amplitudinii lor, se recomand evidenierea distinct a proiectelor pe termen lung i a celor pe termen scurt. Dintre ele se selecteaz cele ce ating obiectivele organizaiei. De asemenea, se va urmri modul n care proiectele se aliniaz dinamicii unitii. Iniierea i planificarea proiectelor Pentru realizarea acestei faze este nevoie de comunicarea efectiv dintre prile implicate( analiti, clieni - manageri, utilizator).

22

Iniierea proiectului Din momentul seleciei lui, proiectul trece n faza de iniiere, ceea ce presupune desfurarea unei activiti laborioase, prestat de un responsabil, cunoscut n practic sub numele de manager de proiect, care rspunde de [5]: - Elaborarea unor studii de fezabilitate general; - Elaborarea planurilor detaliate ale proiectelor; - Gsirea celor mai buni membri ai echipei proiectului. Managerul de proiect trebuie s dea dovad de multe caliti pentru a putea jongla cu elemente cum sunt: - Schimbrile tehnologice; - Ciclul de via al sistemelor; - Contractori i furnizori; - Managementul resurselor umane; - Metodologie i instrumente de lucru diferite; - Restricii de timp i resurse; - Documentare i comunicare; - Ateptrile managerilor i clienilor. Activitile efectuate n faza iniierii proiectului sunt: 1. stabilirea echipei de iniiere a proiectului; 2. stabilirea bunelor relaii cu beneficiarii; 3. stabilirea planului iniierii proiectului; 4. stabilirea procedurilor manageriale; 5. stabilirea cadrului de desfurare a proiectului i a manualului de operare al acestuia. Planificarea proiectului Planificarea proiectului va cuprinde o evaluare a cerinelor informaionale ale sistemului la nivelul ntregii organizaii. Planificarea proiectului este procesul prin care are loc definirea clar a activitilor i a eforturilor necesare nfptuirii lor n cadrul fiecrui proiect. Tipurile activitilor executate n cadrul planificrii proiectului cuprind [5]: 1. Descrierea ariei de ntindere, a variantelor i fezabilitii proiectului 2. Descompunerea proiectului n activiti uor executabile i controlabile 3. Estimarea resurselor i crearea unui plan al resurselor 4. Realizarea unei prime planificri calendaristice 5. Realizarea unui plan al comunicrilor 6. Determinarea standardelor i procedurilor proiectului 7. Identificarea i evaluarea riscului 8. Crearea unui buget preliminar 9. ntocmirea rapoartelor de activitate 10. Definitivarea planului de baz al proiectului

23

Sisteme informatice 2.2. Analizele de fezabilitate Elaborarea unui sistem informatic poate costa milioane de dolari i se poate realiza pe parcursul a trei pn la ase ani pentru a fi complet. Din aceste motive, este normal ca factorii de conducere s demareze proiectarea unui nou sistem dup ce se efectueaz studii de fezabilitate. Un studiu de fezabilitate are rolul de a asigura informaiile obiective necesare pentru a cunoate dac un proiect poate fi demarat sau nu, sau dac un proiect deja nceput mai poate fi continuat. Proporiile i durata studiilor de fezabilitate variaz, n funcie de mrimea i natura sistemului implementat. n cazul sistemelor bazate pe calculatoare mari, studiul are cu totul alte dimensiuni fa de varianta utilizrii microcalculatoarelor [5]. Totui, fezabilitatea proiectului poate fi studiat n orice faz a elaborrii lui, dar studiile, de regul, se efectueaz n momente certe. Cnd este propus un proiect, se efectueaz un studiu preliminar de fezabilitate pentru a se stabili dac proiectul atinge obiectivele propuse de unitate. Analiza, n prima ei faz, poate fi orict de subiectiv, ntruct proiectul nu este reprezentat cu lux de amnunte. ns, ndat ce se obine o situaie mai clar despre sistem, despre natura problemei de rezolvat, precum i despre doleanele utilizatorilor, msurarea preliminar a fezabilitii poate fi determinat odat cu faza de analiz a sistemului. Cnd proiectanii ofer dou sau trei variante de elaborare a sistemului, numai studiile de fezabilitate o pot scoate n relief pe cea optim. Dup ce a avut loc proiectarea primar a sistemului, pot fi determinate n detaliu elementele de cost ale proiectrii, implementrii i exploatrii. Este ultima ans a unitilor de a mai putea renuna la sistem, naintea implementrii lui. Pe parcurs, odat cu progresul nregistrat n dezvoltarea sistemului informatic, se obin informaii din ce n ce mai certe, oferindu-se posibilitatea unor analize de fezabilitate mult mai concludente, ceea ce atrage studierea fezabilitii n diverse faze ale ciclului de via al sistemelor. De fiecare dat, studiile de fezabilitate trebuie s aib la baz o foarte bun documentaie. Aceasta va conine [5]: - Definirea problemei ( o scurt descriere a proiectului i explicarea a ceea ce-i propune el s realizeze); - Descrierea cerinelor sistemului; - Descrierea soluiilor sistemului propus; - Explicaia critic a motivrii studiului ntreprins; - Cuantificarea tuturor costurilor materiale i beneficiilor aferente; - O list a costurilor i beneficiilor necuantificabile. 2.3. Tehnici de reprezentare a planurilor i programarea calendaristic Managerul proiectului dispune de o mare varietate de tehnici pentru reprezentarea i descrierea planurilor proiectelor. Documentaia planificrii poate fi alctuit din: - rapoarte grafice - cele mai folosite (fig. 2.2) - rapoarte sub form de text. O diagrama Gantt este o modalitate de reprezentare grafic a proiectului. Cu ajutorul barelor orizontale sunt prezentate activitile planificate. Lungimea barelor este

24

proporional cu timpul alocat activitilor reprezentate. Se pot folosi diferite culori, umbre sau forme pentru a scoate n relief anumite activiti. Ceea ce s-a planificat i realizat, de asemenea, pot fi evideniate prin bare paralele de culori, forme sau umbre diferite. Diagramele Gantt nu indic ordinea activitilor (precedena lor), ci indic data nceperii i pe cea a finalizrii. Se recomand pentru descrierea proiectelor simple sau a unor componente ale proiectelor mari, sau a activitilor prestate doar de o singur persoan, precum i pentru monitorizarea modului n care se efectueaz activitile n comparaie cu cele planificate (ca dat) .

25

Sisteme informatice

Evidena promovrii vnzrilor (EPV) Nr. Nume activitate Aprilie Mai 2005 Iunie 2005 2005 Crt. Iulie 2005 August 2005 Septembrie 2005

1. 2. 3. 4. 5. 6. 7. 8. 9.

Colectarea cerinelor Proiectare ecrane Proiectare rapoarte Proiectare baze de date Documentaie utilizator Programare Testare Instalare edina de analiz Critic: n lucru: Sintez:

Proiect: EPV Data: Analist:

Necritic:

Punct de reper:

Derulat:

Figura 2.2. Diagrama Gantt pentru descrierea planului proiectului [5]

26

Capitolul 3 Analiza sistemului existent i definirea cerinelor noului sistem n cadrul acestui capitol este prezentat prima etap a ciclului de via al sistemelor informatice, etap prin care se determin modul n care funcioneaz sistemul informaional curent i se evalueaz ceea ce ar dori utilizatorii s realizeze noul system .Astfel, sunt prezentate o serie de aspecte privind: - determinarea cerinelor sistemului; - metodele tradiionale utilizate n analiza i determinarea cerinelor sistemulu (interviul i chestionarul); - metode moderne de analiz i determinare a cerinelor sistemului (JAD, prototipizarea); - structurarea cerinelor sistemului - modelarea logic a datelor i prelucrrilor (diagramele fluxurilor de date DFD); - modelarea conceptual a datelor (diagramele entitate relaie, DER). 3.1. Studiul sistemului informaional existent Prin sistem existent se nelege realitatea obiectiv din organizaia pentru care urmeaz a se realiza sistemul informatic solicitat printr-o comand numit cererea beneficiarului. Analiza sistemului existent i definirea cerinelor noului sistem este prima etap din ciclul de via al dezvoltrii sistemelor informatice, etap prin care se determin modul n care funcioneaz sistemul informaional curent i se evalueaz ceea ce ar dori utilizatorii s realizeze noul sistem. Studiul i analiza sistemului existent are ca obiectiv principal stabilirea cerinelor informaionale ale conducerii n vederea realizrii unui sistem informatic. Studiul sistemului existent cuprinde un grup de activiti care urmresc cunoaterea performantelor tehnico-funcionale ale sistemului informaional, att n ansamblul su, ct i pentru elementele de structura ale acestuia, a cerinelor informaionale ale conducerii, cunoaterea lipsurilor i restriciilor pe care le prezint sistemul existent fa de aceste cerine. De modul de realizare a acestor activiti depinde ntregul proces de realizare a sistemului informatic [2]. Studiul sistemului existent const n [2]: - definirea caracteristicilor generale ale sistemului economic; - studiul activitilor de baz desfurate n sistem; - studiul sistemului de conducere; - studiul sistemului informaional; - identificarea metodelor i mijloacelor tehnice. Definirea caracteristicilor generale ale sistemului economic implic : - cunoaterea profilului, obiectivelor agentului economic; - cunoaterea locului n sfera serviciilor si sfera produciei; - cunoaterea relaiilor de cooperare cu ali ageni economici; - cunoaterea specificului activitii de baz ( producie, servicii);

27

Sisteme informatice cunoaterea nivelului tehnic; cunoaterea principalilor indicatori economici i evoluia lor; dezvoltarea, modernizarea etc.

Studiul activitilor desfurate n sistemul economic, modul de realizare a funciunilor unitii economice se face prin [2]: 1. Pe baza statutului de funcionare a societii se studiaz: - activitile i sarcinile din cadrul acestor funciuni; - atribuiile ce revin compartimentelor; - modul de realizare a activitilor funcionale din cadrul unitii economice. 2, n cazul activitii de producie se prezint: - fluxul de producie, amplasarea locurilor de munc, depozitelor etc.; - tipurile de produse, structura lor, ciclurile de realizare; - modul de organizare a produciei, stocarea produciei, transporturile interne, controlul de calitate; - resursele existente: - capaciti; - asigurarea tehnic / proiectarea de produse noi; - norme tehnice; - asigurarea cu materiale necesare; - sistemul existent de programare a produciei. Studiul sistemului de conducere se refer la [2]: - identificarea caracteristicilor sistemului de conducere existent; - sistemul de indicatori cantitativi i valorici; - organizarea conducerii; - caracteristicile rezultate din statutul de funcionare a societii, tipuri de decizii, modul de lucru a deciziilor. Studiul sistemului informaional presupune [2]: - elaborarea schemei fluxului informaional global (cu punerea n eviden a principalelor activiti i a legturilor statice i dinamice dintre acestea); - estimarea cantitativ i calitativ a informaiilor de intrare-ieire, modul de culegere i prelucrare; - identificarea principalilor algoritmi, regulilor de calcul i a punctelor si regulilor de control; - cunoaterea principalelor restricii ale sistemului informaional; - situaia raionalizrii fluxurilor i a documentelor din unitatea economica, studii elaborate, stadiul lor de implementare; - sistemul de codificare utilizat, restricii; - performanele i limitele sistemului informaional existent. Identificarea metodelor i mijloacelor tehnice utilizate pentru prelucrarea datelor n cadrul sistemului informaional existent se face evideniind: mijloacele tehnice existente n dotarea unitii economice ( modul de utilizare, cheltuielile de exploatare, personalul implicat, performante); existena unor aplicaii proiectate i/sau implementate [2].

28

3.2. Determinarea cerinelor sistemului Determinarea cerinelor sistemului este activitate esenial n aflarea situaiei existente i a ceea ce se dorete n viitor. Rezultatul activitii de determinare a cerinelor sistemului se concretizeaz n diferite forme ale informaiilor colectate, cum sunt copii ale interviurilor, nsemnri efectuate n timpul observrii i analizei documentelor, interpretri ale rspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale posturilor de lucru .a., precum i rezultate ale prelucrrilor efectuate de calculator, cum ar fi prototipurile [5]. Rezultatele prezentate dup aceast activitate pot fi rezumate astfel: 1. Informaii obinute n urma conversaiilor cu utilizatorii sau prin observarea activitilor prestate de acetia: copii sau sinteze ale interviurilor, rspunsurile la chestionare sau interpretri ale acestora, nsemnri i rezultate din observarea activitilor, procese verbale ale edinelor ce au avut loc n acest scop; 2. Informaii scrise care exist n unitate: misiunea i strategia afacerii, exemplare ale formularelor, rapoartelor i machetelor de ecrane, manuale ale procedurilor, descrieri ale posturilor de lucru, manuale de instruire, scheme de sisteme i documentaia sistemului existent, rapoartele consultanilor [5]; 3. Informaii obinute cu ajutorul calculatorului: rezultate ale sesiunilor JAD, copii ale fiierelor sesiunilor grupului de sprijinire a sistemului, coninutul depozitelor i rapoartele existente n CASE, ecrane i rapoarte rezultate din prototipurile sistemului, .a [5]. 3.2.1. Metodele tradiionale utilizate n analiza i determinarea cerinelor sistemului Analiza sistemului informaional-decizional fiind, n general, axat pe sistemul obiect, metodele utilizate sunt n general comune cu cele ale analizei economice [2]. Metodele utilizate frecvent n analiza sistemului existent sunt: - Interviul; - Chestionarul. Interviul este o metod foarte rspndit pentru culegerea informaiilor din sistemul informaional. Utilizatorii acestei metode sunt n general analitii care nu sunt familiarizai cu unitatea studiat i cu problemele ei. Prezint avantajul c las foarte mult libertate creativa analistului n construirea i desfurarea lui [2]. n alegerea persoanelor de intervievat trebuie avute n vedere urmtoarele constatri [7]: - persoanele care ocup poziii medii n ierarhia structurii organizatorice furnizeaz informaiile cele mai apropiate de realitate; - colectarea de informaii corecte necesit intervievarea att a personalului de conducere, ct i a celui de execuie; - n prealabil trebuie verificat competena subiecilor intervievai; - lipsa unei atitudini critice poate s denote reineri n exprimarea ideilor. Se vor efectua interviuri la nivelul conducerii i interviuri la nivelul posturilor de lucru. Rezultatul interviului este consemnat n raportul de interviu care trebuie semnat de ctre persoanele intervievate.

29

Sisteme informatice Chestionarul poate fi utilizat att de ctre analitii nceptori, ct i de ctre cei avansai, familiarizai sau nu cu problemele informaionale-decizionale ale unitii. Prin utilizarea lui dispare filtrul de informaii care este analistul iar cel care furnizeaz informaii are posibilitatea s se concentreze mai bine asupra rspunsurilor. Utiliznd aceast metod, particip un numr mare de furnizori de informaii. Limitele chestionarului constau n faptul c este o metod de verificare a unor cunotine prealabile, fapt ce implic cunoaterea prealabil a domeniului. Aceast metod necesit timp relativ ndelungat pentru ntocmirea chestionarului precum i de culegere i prelucrare a rspunsurilor. Chestionarul nu are o arie larg de utilizare [2]. 3.2.2. Metode moderne de analiz i determinare a cerinelor sistemului Ca efect al tendinelor de mrire a timpului de analiz a sistemelor existente, n ultimii ani, s-a efectuat trecerea spre analiza mai puin pronunat a sistemelor ce urmeaz a se realiza. Tehnicile moderne, JAD i prototipizarea, preiau tot mai puine elemente din sistemele existente, ca urmare a analizei efectuate. Altele mai radicale renun aproape total la analiza sistemului existent, este cazul proceselor controlate prin RAD, care apeleaz la JAD, prototipizare i alte instrumente de tip CASE [5]. Joint Application Design(JAD) Spre sfritul anilor 1970, specialitii n realizarea de sisteme de la IBM au elaborat un nou proces de culegere a cerinelor informaionale ale sistemelor i de revizuire a proiectelor sistemelor, numindu-se JAD [5]. Ideea principal a lui JAD o constituie punerea laolalt a tuturor forelor interesate n dezvoltarea sistemelor: utilizatori-cheie, managerii i analitii de sistem implicai n analiza sistemului curent. Din acest punct de vedere JAD este similar interviului la nivel de grup. Totui n sesiunea JAD se urmrete o anumit secven de derulare a activitilor, pe baza unor roluri bine stabilite. Prototipizarea i determinarea cerinelor sistemelor Prototipizarea este un proces interactiv prin care analitii i utilizatorii pun n discuie o versiune rudimentar a unui sistem informaional, care va fi ntr-o continu schimbare, n funcie de reacia utilizatorilor. Prototipizarea renun la ciclul de via al dezvoltrii sistemelor sau la creterea rolului su [5]. Pentru culegerea informaiilor despre cerinele utilizatorilor nc se apeleaz la interviuri, dar prin prototipizare, operaiunea va fi mai simpl i va solicita un timp mai scurt. Prototipul este vzut i testat de utilizator, avnd posibilitatea s precizeze ce ar mai dori, dar i s-i genereze aceast form nou, cu ajutorul specialitilor [5]. Prototipizarea este facilitat de cteva limbaje sau produse program, inclusiv instrumentele de tip CASE. Prototipizarea este foarte util n determinarea cerinelor sistemului cnd [5]: - cerinele utilizatorului nu sunt prea clar formulate sau bine nelese; - unul sau mai muli utilizatori sau susintori sunt implicai n sistem; - anumite mijloace de lucru (formulare i rapoarte predefinite). Prototipizarea genereaz i deficiene, cum ar fi:

30

tendina de evitare a unui cadru formal de elaborare a documentaiei privind cerinele sistemului, ceea ce va ngreuna n viitor orice control; fiind conceput de un numr mic de utilizatori va fi probabil respins de viitorii utilizatori; fiind conceput izolat este puin probabil ca el s fie integrat n sistemul existent; nerespectndu-se etapele ciclului de via al dezvoltrii sistemelor pot fi omise aspecte eseniale, cum ar fi securitatea, controlul datelor introduse i standardizarea la nivel de sistem. Paii prototipizrii sunt [5]: Identificarea cerinelor principale ale sistemului; Realizarea prototipului iniial; Proces iterativ de adaptare a sistemului la cerinele utilizatorului; Folosirea sistemului aprobat de utilizatori.

Dup determinarea cerinelor sistemului urmeaz structurarea acestora prin utilizarea unor instrumente specifice de modelare logic. 3.3. Structurarea cerinelor sistemului - modelarea logic a datelor i prelucrrilor Indiferent de metodologiile folosite n realizarea unui sistem/aplicaie, toate apeleaz la operaiunea de modelare logic a datelor i prelucrrilor sub form de diagrame, diferenele constnd doar n folosirea mai pronunat a diagramelor pentru descrierea sistemului, ncadrndu-le n diagrame de context, diagrame ale fluxurilor de date fizice i diagrame ale fluxului de date logice. Altele apeleaz la combinaii de diagrame, tabele i forme descriptive [5]. Diagrama de context scoate n eviden aria de ntindere a sistemului analizat, prin specificarea elementelor din interiorul organizaiei i a celor externe, sub denumirea de entiti externe sistemului analizat. 3.3.1. Diagramele fluxurilor de date (DFD) Diagrama fluxului de date ale nivelului logic curent, independent de tehnologie, reliefeaz funciile de prelucrare a datelor executate de ctre sistemul informaional curent. Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor, structura lor i cerinele funcionale ale noului sistem. Descrieri ale obiectelor DFD se regsesc n aa-zisele dicionare ale proiectelor sau depozitele CASE (repository) [5]. Diagramele fluxului de date DFD au ca obiectiv urmrirea modului de transfer al datelor ntre procesele de prelucrare a lor, astfel de diagrame se mai numesc i modele ale proceselor de prelucrare, iar operaiunea se numete modelarea proceselor. DFD reprezint doar una din tehnicile de analiz structurat.

31

Sisteme informatice Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor fluxurilor de date a cptat noi accepiuni prin ncorporarea ei n instrumentele de analiz i proiectare cu ajutorul calculatorului, adic n instrumente CASE [5]. Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru construirea DFD Cnd analizm sistemele folosim frecvent reprezentrile grafice, de exemplu diagramele. n continuare vom folosi tehnica reprezentrii grafice a fluxului informaional. Proiectarea fluxului informaional reprezint circulaia informaiei n sistem, transformrile suferite de acesta, stocarea informaiei precum i scurgerile de informaie n afara sistemului. Scopul diagramelor de date DFD pentru o anumit component organizatoric sau funcional la care se refer (secie, birou, compartiment, ntreaga unitate, o anumit activitate vnzri, cumprri, ncasri, pli, .a) este de a scoate n relief, ntr-o manier ct mai sugestiv, urmtoarele aspecte [5]: - sursa datelor de prelucrare; - operaiunile de prelucrare prin care trec datele; - destinaia datelor prelucrate; - legtura existent ntre prelucrri i activitatea de stocare a datelor. ntocmirea diagramelor de flux de date (DFD) DFD este o reprezentare grafic a transformrii datelor de intrare n date de ieire folosind un set de simboluri de reprezentare i un set de reguli de completare i validare.

32

Simboluri folosite n diagramele realizate cu SSADM

proces (transformare): Procesele sunt etichetate cu text ce sugereaz modul de transformare a datelor i sunt identificate printr-un numr(descriere a funciei procesului de prelucrare, ncepnd cu un verb, urmat de o descriere a obiectului funciei de prelucrare). n DFD fizic pentru sistemul existent, se va preciza i locaia (compartiment / persoan) procesului.

flux de date: este constituit din datele transmise ntre dou procese. Fluxul de date este etichetat printr-un substantiv ce sugereaz informaia sau pachetul de informaii transmise.

entitate extern (terminator): surs / receptor de date. Poate fi un alt sistem (organizaie, compartiment).

stoc de date: un depozit temporar sau permanent de date. Poate fi: - manual: registre, dosare, arhiv de documente - pe suport magnetic: fiiere.

Convenii folosite n diagramele de reprezentare a DFD: procesele i stocurile de date sunt numerotate secvenial, pentru a putea fi identificate. Numerele asociate proceselor nu semnific ordinea de execuie a acestora; pentru a evita fluxurile de date ntretiate i aspectul de pienjeni al diagramei, entitile externe i stocurile de date pot fi duplicate. O entitate extern duplicat se reprezint prin trasarea unei linii oblice, iar un stoc duplicat printr-o linie suplimentar vertical n partea stng a cutiei; pentru a face diagramele mai lizibile, entitile externe sunt plasate, pe ct posibil, n jurul diagramei iar stocurile de date, n partea central a diagramei; fluxurile de date de la - ctre stocurile de date sunt unidirecionale (fie de adugare, fie de consultare) si nu sunt etichetate.

3.3.2. Descompunerea funcional i rafinarea DFD Dac sistemul pe care-l descriem cu ajutorul DFD este complex, va fi dificil s realizm de la nceput o DFD detaliat. Pentru a putea descrie n detaliu sistemele complexe, metodele structurate propun o abordare TOP-DOWN, respectiv o

33

Sisteme informatice descompunere funcional a sistemului, care este realizat prin rafinarea succesiv a proceselor. Primul nivel (nivelul 0) l constituie DIAGRAMA CONTEXTUAL, care definete graniele ntre sistemul analizat si mediu. Nivelele urmtoare se obin prin rafinarea proceselor complexe ntr-o diagram de nivel inferior. n cazul aplicaiei Decontri, au rezultat urmtoarele diagrame:

Figura 3.1. Diagrama contextual pentru aplicaia Decontri

Figura 3.2. Diagrama fluxului de date de nivel 1 pentru aplicaia Decontri

34

Figura 3.3. Diagrama fluxului de date de nivel 2 pentru aplicaia Decontri Definirea direciilor de perfecionare a actualului sistem Pe baza activitilor de evaluare i analiz critic se identific neajunsurile actualului sistem i se propun soluii de nlturare a acestora se formuleaz variante de soluii, iar n cadrul acestora se definesc cerinele i restriciile de realizare a sistemului informatic. Definirea direciilor de perfecionare presupune: 1. specificarea obiectivelor i a performantelor sistemului informatic; 2. stabilirea domeniilor de probleme i a principalelor funciuni ale sistemului informatic; 3. definirea cerinelor si restriciilor informaionale pe domenii de probleme i funciuni care const n: - definirea principalelor intrri/ ieiri; - definirea soluiei de organizare a datelor; - definirea variantelor tehnologice de prelucrare; - definirea restriciilor informaionale i de control. 4. formularea condiiilor pentru realizarea sistemului informatic, care const n: - specificarea termenelor i duratelor solicitate; - precizarea prioritilor n realizarea obiectivelor sistemului informatic;

35

Sisteme informatice specificarea cerinelor speciale privind flexibilitatea, compatibilitatea cu alte sisteme, gradul de generalizare al sistemului. Pentru fiecare variant de soluie informatic se procedeaz la: - evaluarea resurselor necesare (costurile de sistem); - evaluarea efectelor economice directe si indirecte; - calculul indicatorilor de eficient economic. 3.3.3. Modelarea sistemului curent Indiferent de tipul sistemului analizat, manual sau informatizat, o problem este comun: el va fi nlocuit de un nou sistem. Orict de ineficient, vechiul sistem trebuie s transfere celui nou o serie de elemente, cum sunt datele folosite, procedurile existente. Deci sistemul fizic actual efectueaz n parte sau n ntregime ceea ce-i propune s fac noul sistem fizic, dar la alt nivel de performan. Tocmai necesitatea trecerii de la vechiul la noul sistem ne oblig s decidem asupra celor dou elemente specificate anterior, date i proceduri, ceea ce conduce la obligativitatea constituirii unui model logic al sistemului propus, care s conin una sau mai multe DFD, un model de date i logica procesului de prelucrare. Problema comun ar consta n identificarea unei ci de realizare a modelului logic al sistemului propus [5]. O modalitate de abordare const n prezentarea detaliat a sistemului fizic curent, dup care s se realizeze construirea modelului logic curent, prin abstractizarea celui fizic existent. Se va continua cu scoaterea n relief a ceea ce trebuie neaprat schimbat din sistemul curent i ceea ce trebuie s se realizeze n cel nou. Deci, modelul logic propus poate fi conceput pe baza modelului logic curent. Pornind de la modelul fizic, se deriv modelul logic n cadrul cruia se realizeaz: - pune n eviden ce face sistemul, eliminnd detaliile referitoare la modul cum funcioneaz sistemul n implementarea actual; - pune n eviden funciunile de baz ale sistemului; - permite identificarea i eliminarea problemelor legate de redundana datelor i duplicarea proceselor de prelucrare; - permite stabilirea cu o mai mare precizie a granielor sistemului prin eliminarea proceselor manuale care nu pot fi automatizate complet. Derivarea modelului logic al sistemului existent Construirea modelului logic presupune transformarea diagramei de flux a datelor fizice n diagrama de flux a datelor logice. Procesul de derivare a diagramei logice va ncepe de la ultimul nivel de descompunere alctuit de la procesele frunz i va continua prin agregarea proceselor ctre nivelurile superioare. Se parcurg urmtorii pai: 1. Identificarea stocurilor logice de date - se face pe modelul logic al datelor prin gruparea ntr-un stoc logic de date a entitilor nrudite sau utilizate frecvent. Dup identificarea stocurilor logice de date se construiesc: - diagrama de coresponden ntre stocuri logice i entitile din modelul logic; - diagrama de coresponden ntre stocuri fizice i stocuri logice de date.

36

2. nlturarea dependenelor fizice i temporale din denumirea proceselor i a fluxurilor de date: din DFD la nivel fizic (se observ c nu exist referine fizice i temporale n aplicaia decontri). 3. Derivarea proceselor logice: - scoaterea n afara granielor sistemului a proceselor manuale care nu pot fi automatizate (deciziile); - nlocuirea proceselor care nu realizeaz nici o transformare asupra fluxurilor de date cu fluxurile propriu-zise; - combinarea proceselor care realizeaz prelucrri asemntoare sau multiple care se execut mpreun sau n secven; - nlturarea proceselor care in de implementarea actual i a proceselor redundante. - n cazul aplicaiei prezente: - se combin procesele nregistrare ncasri n numerar i nregistrare ncasri prin virament deoarece realizeaz prelucrri asemntoare; - se nltur procesele redundante nregistrare ncasri n jurnal si nregistrare plti n jurnal. 4. Derivarea fluxurilor logice care presupune nlocuirea numelui de document numai cu fluxul de informaii utilizate efectiv de proces. 5. Gruparea proceselor elementare i transformarea diagramei fizice n diagram logic, aplicnd cei 5 pai. Relaia existent ntre DFD i modelul datelor Dup cum reiese din prezentrile anterioare, fiecare sgeat din DFD reprezint un flux al datelor, n sensul unui traseu pe care structurile datelor elementare sau grupate se vor deplasa n sistem. De exemplu, Facturi desfacere este o dat grupat. Cnd numele ei se plaseaz pe un flux de prelucrare trebuie s vedem i obligativitatea ca acel flux s fie descris prin prisma structurii datelor respective, deci, trebuie prezentate rubricile documentului. Similar va fi abordat i simbolul pentru stocare. La prima vedere, el reprezint locul unde se realizeaz operaiunea, dar foarte important este s prezentm structura datelor pstrate. Firesc, i n cazul fluxului de date, i n cel al stocrii lor nu trebuie uitat descrierea semnificaiei economice. Structura datelor trebuie s fie redus la a treia form normalizat, iar coninutul locurilor de stocare a datelor s fie prezentat prin reduceri la unul sau mai multe tabele relaionale n forma a treia normalizat [5]. n cazul aplicaiei decontri, se obine urmtoarea DFD a sistemului logic. Decontri cu beneficiarii .Nivelul elementar al DFD a sistemului logic. Nivelele superioare ale DFD a sistemului logic sunt identice.

37

Sisteme informatice

Figura 3.4. Diagrama fluxului de date Tabel 3.1 aplicaia Decontri Sursa Destinaia 1.1. nregistrare D2 FACTURI facturi desfacere DESFACERE

Nume flux desfaceri

1.3. Analiza situaie client

D2 FACTURI DESFACERE

desfaceri

Continutul fluxului CODCLIENT DENCLIENT ADRESAC CONTC BANCA_C DATAFACTD NRFACTD TOTALFACTD CODCLIENT DENCLIENT ADRESAC CONTC BANCA_C NRFACTD TOTALFACTD

3.3.4. Modelarea logicii proceselor Dup ce au fost descrise procesele de conversie a datelor n informaii, prin intermediul diagramelor fluxurilor de date DFD, deoarece ele nu reliefeaz i logica

38

intern a proceselor, orict ar fi de detaliate, chiar i la nivelul proceselor primare, se impune apelarea la alte tehnici pentru descrierea logicii proceselor. Procesele trebuie astfel descrise nct s poat fi convertite n programe prin intermediul limbajelor de programare [5]. n faza de analiz modelarea logicii proceselor se va derula ct mai detaliat i complet posibil, dar operaiunea nu va respecta structura sau sintaxa unui anumit limbaj de programare: aceasta se va realiza ntr-o etap ulterioar proiectarea. Modelarea logicii proceselor ca i diagramele fluxurilor de date face parte din etapa de analiz a sistemului. n analiza structurat, rezultatele obinute n urma modelrii proceselor sunt descrieri i diagrame structurate care vor prezenta logica fiecrui proces, precum i diagrame care vor evidenia dimensiunea temporal a sistemelor, cnd apar procesele sau evenimentele i modul n care aceste evenimente schimb starea sistemului [5]. Pe scurt se poate spune c modelarea logic a proceselor se va concretiza n urmtoarele elemente ale documentaiei [5]: - reprezentarea n engleza structurat; - reprezentarea logicii proceselor prin tabele de decizie; - reprezentarea logicii proceselor prin arbori de decizie; - tabelul sau diagrama strilor de tranziie. Reprezentarea logicii proceselor prin engleza structurat Engleza structurat este o form mult simplificat i modificat a limbii engleze, folosit pentru descrierea coninutului casetelor care marcheaz procesele (prelucrrile) din diagrama fluxului de date. Cuvintele folosite sunt n strns legtur cu logica folosit n conceperea procedurilor componente ale sistemelor informatice [5]. Se folosesc verbe pentru cuvintele cheie i substantive pentru descrierea structurii datelor. Nu exist o form standard de englez structurat, fiecare analist ar putea apela la o form proprie, dar scopul este de a nlesni accesul mai multor persoane la rezultatele analizei nglobate n documentaie. Utilizarea englezei structurate pentru procesul Analiza situaie client din decontri cu beneficiarii este reprezentat mai jos. Analiza situaie client WRITE CLIENTI,FACTURI_DESF, NCASRI READ (FACTURI_DESF) cod = FACTURI_DESF.codclient; den = FACTURI_DESF.denclient; adr = FACTURI_DESF.adresac; cont = FACTURI_DESF.contc; banca = FACTURI_DESF.bancac; while (not eof (FACTURI_DESF)) { if (cod!=FACTURI_DESF.codclient) { CLIENTI.codclient = cod; CLIENTI.denclient = den; CLIENTI.adresac = adr;

39

Sisteme informatice CLIENTI.contc = cont; CLIENTI.banca_c = banca; CLIENTI.sold = sold; cod = FACTURI_DESF.codclient; den = FACTURI_DESF.denclient; adr = FACTURI_DESF.adresac; cont = FACTURI_DESF.contc; banca = FACTURI_DESF.bancac; } else { READ(NCASRI); vb=0; vb1=0; while (not eof (NCASRI) AND vb=0) { if (cod=NCASRI.client AND FACTURI_DESF.nrfactd=NCASRI.nrfactd AND FACTURI_DESF.datafactd =NCASRI.datafactd) { if (FACTURI_DESF.totalfactd !=NCASRI.sumaincasata) { sold = sold+ FACTURI_DESF.totalfactd NCASRI.sumaincasata} vb1=1; } else if (vb1=1) vb=1 READ (NCASRI) } MOVE FIRST LINE NCASRI READ (FACTURI_DESF) } CLOSE (FACTURI_DESF, NCASRI, CLIENTI) 3.4. Modelarea conceptual a datelor (diagramele entitate relaie, DER) n cadrul modelrii conceptuale a datelor se va renuna la abordarea proceselor i se va trece la abordarea sistemelor prin prisma datelor. La fel ca i n cazul modelrii proceselor i modelrii logicii proceselor elementele eseniale vor fi diagramele. James Martin i Carma McClure, atunci cnd reliefeaz importana tehnicilor structurate prin obiectivele ce i le propun, consider c o parte a acestora au legtur i cu datele, i anume [5]: - S se realizeze o administrare riguroas a datelor. Administrarea datelor se refer la structurarea corect a datelor, la uniformitatea modalitilor de definire i proiectare a datelor la nivel de ntreprindere i nu a sistemului. Corect efectuate, acestea accelereaz procesele de analiz i proiectare i permit s se utilizeze n comun componentele eseniale ale sistemelor: resursele.

40

S se efectueze o analiz sntoas a datelor. Analizele datelor clarific problemele de structurare a lor i conduc la structuri stabile ale acestora, concretizate prin costuri reduse ale realizrii sistemelor. Dac baza de date a unitii este deosebit de important, atunci pe analiza datelor trebuie s se pun un accent aparte, ea fiind ntotdeauna realizat naintea proiectrii programelor. Firesc, dac tim care sunt cerinele unui sistem (ieirile), imediat ne vom pune ntrebarea din ce se obin acestea (intrrile) i apoi vom urmri cum se pot obine ieirile (procesele). Obiectivul principal al ingineriei informaiei este crearea unui set de metodologii care s poat fi folosite n cele mai diverse medii de lucru, astfel nct s se construiasc modele ale datelor la nivele de ntreprindere, iar sistemele proiectate izolat s se integreze n aceste modele. Datele trebuie s fie unice. Asupra lor, la nivel de ntreprindere, pot fi vzute dou categorii mari de operaiuni: - asigurarea datelor (creare, actualizare); - utilizarea datelor (obinere de documente, de diverse rapoarte, analize What-If, sprijin decizional, diferite cutri de informaii, control i auditare ntreprindere). Modelul conceptual al datelor nseamn o modalitate de reprezentare a datelor organizaiei. Rolul su este de a scoate n relief toate regulile privind identitatea i legturile existente ntre date [5]. Cea mai cunoscut form utilizat pentru modelarea datelor este diagrama entitaterelaie (DER). O modalitate aproape identic este folosit i n analiza i proiectarea orietat-obiect. Modelarea datelor prin DER prezint caracteristicile i structura datelor independent de modul n care acestea sunt memorate n calculator. Modelul se creeaz iterativ. De cele mai multe ori, operaiunea are loc la nivel de ntreprindere, prin apelarea la o categorie foarte larg de date neglijndu-se detaliile exagerate. Doar n etapele urmtoare, n spe cnd se trece la definirea proiectului, are loc construirea unui model anume entitate-relaie prin care s fie scoas n eviden aria de ntindere a proiectului. n timpul structurrii cerinelor, un model entiatate-relaie reprezint cerinele conceptuale de date pentru sistemul luat n discuie. Dup ce sunt descrise complet intrrile i ieirile sistemului n cadrul proiectrii logice, modelul conceptual al datelor, redat sub forma entitate-relaie, este rafinat nainte de a fi trecut ntr-un format logic (de regul, un model relaional al datelor) din care se definesc bazele de date i are loc proiectarea fizic a acestora [5]. DER joac un rol deosebit de important n formarea profesional a veritabililor analiti. Se consider c, n timpul modelrii conceptuale a datelor, se produc i se analizeaz cel puin patru diagrame entitate-relaie [5]: 1. DER care s acopere datele necesare aplicaiei proiectului. Ea va permite stabilirea necesarului de date ale aplicaiei proiectului, fr s se in seama de constrngerile sau confuziile generate de detaliile care nu sunt nc necesare. 2. DER pentru aplicaia ce va fi nlocuit. Diferenele dintre aceste diagrame arat ce schimbri trebuie ntreprinse pentru convertirea bazei de date n noua aplicaie. Nu se aplic n cazul sistemelor complet noi.

41

Sisteme informatice
DER care s scoat n relief ntreaga baz de date din care noua aplicaie i va extrage datele. Ct timp mai multe aplicaii pot folosi aceeai baz de date, aceast diagram i prima evideniaz modul n care noua aplicaie apeleaz la coninutul unor baze de date mult mai extinse. 4. DER pentru ntreaga baz de date din care aplicaia curent i extrage datele necesare. Ea este discutat doar pentru sistemele care exist i pentru care se urmrete mbuntirea. Din nou, diferenele dintre diagrama precedent i cea de fa vor indica modificrile majore de efectuat pentru a se putea influena noua aplicaie. Metodele de determinare a cerinelor trebuie s fie orientate, prin ntrebrile puse, prin anchetele efectuate, i asupra datelor, nu numai asupra proceselor i logicii lor. La nceput, chiar fr utilizarea unei terminologii de specialitate, analistul va fi preocupat de modul n care va afla ct mai multe informaii despre datele necesare viitorului sistem pentru a funciona la parametrii proiectai. ntrebrile vor fi astfel formulate nct s se realizeze o bun nelegere a regulilor dup care vor fi folosite datele n noul sistem, ce politici vor fi utilizate. Nu trebuie, nc, s se intre n detalii de genul: cnd i cum sunt prelucrate sau folosite datele, pentru a se realiza modelarea datelor [5]. Modelarea datelor se realizeaz printr-o combinaie a punctelor de vedere. Un prim punct de vedere, formulat n literatur sub numele de metoda top-down, va scoate n eviden regulile derulrii activitii firmei, printr-o nelegere foarte clar a naturii afacerii, i nu se va opri asupra detaliilor privind modul n care ecranele, rapoartele sau documentele sunt folosite n organizaie [5]. n afara metodei top-down, informaiile necesare construirii modelului datelor se pot obine i prin urmrirea documentaiei firmei, ecrane, rapoarte, formulare, din interiorul sistemului. Acest proces este cunoscut n literatura de specialitate sub numele de metoda bottom-up [5]. Elementele rezultate vor figura n diagramele fluxurilor de date prin care vor fi evideniate datele prelucrate n sistem i de aici va rezulta necesarul de date meninute n baza de date a sistemului. 3.

Definirea conceptului de entitate

Entitile sunt obiecte sau evenimente (fenomene sau procese economice, n cazul nostru). Obiectele se caracterizeaz printr-o existen de-a lungul timpului, iar evenimentele i fac simit prezena la un moment dat [5]. La rndul lor, obiectelor li se pot asocia cel puin dou evenimente: apariia i dispariia lor. Exemple: ncheierea i ncetarea contractului de munc; predarea produselor la secia expediie i desfacerea lor la beneficiari .a. La fel putem spune i despre evenimente. Ele reprezint asocieri ntre dou sau mai multe obiecte. Exemplu: CLIENT COMAND PRODUS. Entitile conin n structura lor atributele prin care ele sunt descrise. O entitate este o persoan, un loc, un obiect, eveniment sau concept din domeniul de activitate a utilizatorului despre care organizaia dorete s pstreze anumite date. Se cuvine precizat diferena dintre tipurile entitilor (entity types) i cazurile/instanele entitii (entity instances) [5]. Tipul entitii, cunoscut i sub numele de clasa entitii, este o colecie de entiti care au proprieti sau caracteristici comune. Fiecrui tip de entitate i se atribuie un nume. Ct timp numele reprezint o clas sau un set de cazuri, el este singular. i nc o convenie. Cum referirea general la elementele ce pot fi catalogate ca entiti se poate face prin noiunea de obiect (dei sensul lui poate fi altul n contextul analizei i proiectrii orientate obiect), referirea la acesta se va realiza printr-un substantiv la singular. Se vor folosi litere majuscule, plasate n interiorul dreptunghiului corespunztor entitii.

42

O instaniere a entitii sau instan, denumit de noi n continuare, caz al entitii sau caz, este o manifestare singular a unui tip de entitate. Un tip de entitate se descrie o singur dat prin modelul datelor, n timp ce mai multe cazuri ale acelui tip de entitate pot fi reprezentate prin datele stocate n bazele de date. De exemplu, exist o singur entitate CLIENT, dar ea poate s aib sute sau mii de cazuri/instane ale acestei entiti stocate n baza de date. Atribute Fiecare tip de entitate are un set de atribute asociate lui. Un atribut este o proprietate sau o caracteristic a unei entiti care prezint interes pentru organizaie. La rndul lor, i relaiile pot avea propriile lor atribute. Exemplu de entitate pentru aplicaia DECONTRI i unele dintre atributele posibile: CLIENT : CodClient, DenClient, AdresaC Ca i numele tipurilor entitilor, numele atributelor sunt substantive scrise cu majuscule, plasate n interiorul elipselor, legate de entitatea creia i se asociaz. De multe ori ns, chiar i n cazul folosirii produselor CASE, pentru a nu se ncrca o diagram entitate-relaie, se evit prezentarea atributelor. Operaiunea se face, n schimb, n repository, depozitul de informaii despre proiect. Aici orice atribut se descrie separat, ca orice obiect distinct. Unul dintre exemplele anterioare poate fi reprezentat n diagram conform fig. 3.5. DenClient

CodClient

CLIENT

AdresaC

Figura 3.5. Model de reprezentare a atributelor DER

Cheie candidat i cheie primar Fiecare tip de entitate trebuie s aib un atribut sau un set de atribute prin care s se efectueze diferenierea unui caz de acelai tip. O cheie candidat aste un atribut sau o combinaie de atribute prin care se poate identifica n mod unic un caz (o instan) al tipului entitii respective. Sunt entiti care pot avea dou sau mai multe chei-candidat. n exemplul nostru, pot fi chei-candidat CodClient, NumeClient, AdresaC (presupunnd c ele identific n mod unic un angajat). Atunci cnd sunt mai multe chei-candidat, proiectantul trebuie s decid care din ele va fi folosit drept cheie-primar. O cheie-primar este o cheie-candidat care a fost selectat pentru a servi ca identificator de cazuri n cadrul unui tip de entitate [5]. n reprezentrile din DER, n elipsa sau elipsele aferente atributului sau atributelor ce formeaz cheia primar, numele respective se subliniaz (vezi CodClient din entitatea CLIENT ). Relaiile entitilor Relaiile reprezint legturile ntre componentele unei diagrame entitate-relaie. O relaie este o asociere ntre cazurile/instanele uneia sau mai multor tipuri de entiti care prezint interes pentru organizaie. Ele se pot simboliza printr-un romb. De regul, relaiile sunt redate prin verbe. Cardinalitatea relaiilor

STUDENT

nscris pentru 43
Figura 3.6. Tip Relaie

CURS_CREDIT

Sisteme informatice
Presupunem c exist dou tipuri de entiti, A i B, ntre care exist o linie de legtur pentru a marca relaia. Cardinalitatea unei relaii este dat de un numr al cazurilor/instanelor entitii B care pot sau care ar putea s fie asociate cu fiecare caz al entitii A. Cardinalitatea este sugerat prin 0 (zero), 1, M (multe), cu meniunea c ele pot avea prezen obligatorie sau opional. Trimiterea la cardinalitate se face n moduri destul de diferite, n funcie de notaia folosit. Recomandm citirea cu atenie a diagramelor i descifrarea elementelor strict necesare nelegerii, ndeosebi pentru reflectarea cardinalitii. De exemplu, ea poate fi notat cu semne (0, 1, M, N) sau prin simboluri (linie cu vrf simplu de sgeat pentru 1, linie cu vrf dublu de sgeat pentru M. Alteori, 1 se reprezint prin linie simpl i M prin vrf de sgeat). n multe materiale, inclusiv produse CASE, se folosete notaia model-date, cunoscut mai mult sub numele labagtei, conform crei cardinalitatea se reprezint prin urmtoarele simboluri [5]:

obligatoriu 1

opional 0 sau 1

obligatoriu multe (n, unde n ia valori de la 1 la M)

opional 1 sau multe (n, unde n ia valori de la 1 la M)

n 44

Entiti compuse sau asociative (gerundive) Atributele pot fi asociate cu o relaie multe-la-multe sau cu o entitate. Un exemplu, din lumea cursurilor-credit, transferabile n cadrul unei perioade. Un student poate lua mai multe cursuri dintr-o list, dar finalizarea cu not se poate efectua n momente (la date) diferite. Prezentm, mai jos, cteva dintre datele concrete [5]: MATRICOLA STUDENT 1111 1177 1155 1111 NUME CURS Informatic Informatic Informatic Drept comercial DATA PROMOVRII Iulie 1999 Septembrie 1999 Septembrie 1999 Ianuarie 2000

Din analiza cazurilor rezult c atributul DATA_PROMOVRII nu este o proprietate a entitii STUDENT, ct timp examenele pot fi date la momente diferite. Dar nu este nici o proprietate a entitii CURS, ct timp acelai curs poate fi susinut la date diferite. n schimb, DATA_PROMOVRII este o proprietate a relaiei dintre STUDENT i CURS. Atributul se asociaz relaiei i se prezint sub form de diagram, ca n fig. 3.7.
DATA PROMOVRII

STUDENT

Promovare

CURS

Figura 3.7. Asocierea unui atribut la o relaie [5] De aici rezult un caz aparte de entitate, numit gerundiv sau compus sau asociativ care, de fapt, este o relaie folosit de analist n model ca un tip de entitate. n astfel de cazuri, se folosete un simbol special: dreptunghi cu romb n interior, n care se scrie numele entitii (fig. 3.8) [5].
DATA PROMOVRII

STUDENT

Promovare

CURS

Figura 3.8. Redarea unei entiti gerundive (asociative) [5]

45

Sisteme informatice Nu trebuie confundat aceast situaie cu relaiile transformate n entiti nepurttoare de informaii, descrise anterior. Scopul diagramelor entitate-relaie este de a surprinde cele mai complete sensuri posibile ale datelor necesare sistemului informaional din organizaie. Tipuri de relaii Din cele prezentate mai sus, rezult c ntre entitile descrise, luate dou cte dou, se pot identifica trei tipuri de relaii: unu-la-unu, unu-la-multe, multe-la-multe. n diagrame, descrierea relaiilor se face de-a lungul liniilor care leag cele dou entiti. Simbolul vrf-de-sgeat este cunoscut ca indicator al cardinalitii (cardinality indicator). n cele ce urmeaz sunt prezentate exemple de tipuri de relaii [5]. 1. Relaia unu-la-unu (1:1) BIROU

este condus de

conduce

MANAGER

Figura 3.9. Descrierea relaiei 1:1 Fiecare BIROU este condus de un, i numai un, MANAGER Fiecare MANAGER conduce un, i numai un, BIROU. 2. Relaia unu-la-multe (1:M)

VNZARE

implic face parte din

Figura 3.10. Descrierea relaiei 1:M

ARTICOL VNDUT

Fiecare VNZARE implic unul sau mai multe ATRICOL(e)_VNDUT(e) Fiecare ATRICOL_VNDUT face parte din numai o VNZARE 3. Relaia multe-la-multe

FURNIZOR

livreaz este livrat de

Figura 3.11. Descrierea relaiei M:N

PRODUS

Fiecare FURNIZOR livreaz unul sau mai multe PRODUS(e) Fiecare PRODUS este livrat de unul sau mai muli FURNIZOR(i) n anumite cazuri, ntre dou entiti pot exista mai multe relaii. De exemplu, s-ar putea spune c FURNIZOR ofer PRODUS, dar i PRODUS este cumprat de la FURNIZOR, ceea ce s-ar putea reprezenta ca n fig. 3.12.

46

ofer PRODUS FURNIZOR

este cumprat de la
Figura 3. 12. Descrierea relaiilor multiple ntre dou entiti

4.

Relaii opionale i obligatorii

Alteori, relaiile dintre entiti nu-i fac simit prezena n toate situaiile. Chiar cazul cu studiile la care lucreaz diverse persoane este destul de elocvent; o persoan poate s lucreze la un singur studiu sau la cteva, sau la niciunul i, invers, un studiu poate fi efectuat de o persoan, de mai multe sau de nici una. n astfel de situaii, se apeleaz la urmtoarea form de reprezentare. (fig. 3.13)

PERSOANA

lucreaz la este realizat de

STUDIU

Figura 3.13. Exemplu de relaie opional Cercul suprapus pe latura entitii indic, de fapt, poziia 0 (valoarea minim poate fi i zero), conferind relaiei caracterul opional. Un alt aspect se refer la caracterul obligatoriu al relaiilor. Cu alte cuvinte, o entitate poate exista fr cealalt? S lum exemplul vnzrilor. n relaia 1:M, dintre VNZARE i ARTICOL_VNDUT. Ar fi total eronat ca o entitate s existe fr cealalt: nu poate fi o vnzare fr cel puin un articol vndut i, invers, un articol nu poate fi vndut fr o vnzare (operaiunea nu ar avea sens). Simbolul folosit pt a marca relaiile obligatorii este acelai cerc, cu deosebirea c este haurat.

VNZARE
Figura 3.14. Exemplu de relaie obligatorie

ARTICOL VNDUT

5.

Relaia unei entiti cu ea nsi

n practic, apar i situaii n care o entitate este pus n relaie cu ea nsi.Ne oprim la exemplul entitii ANGAJAT. Unii dintre ei dobndesc statutul de coordonatori ai activitii celorlali, situaii n care se poate apela la o diagram de genul celei din fig.3.15.

ANGAJAT

coordonator al

raporteaz la
Figura 3.15. Redarea relaiei unei entiti cu ea nsi

47

Sisteme informatice Reprezentarea anterioar se citete astfel: Un angajat poate fi coordonatorul unuia sau mai multor angajai Oricare angajat ntotdeauna raporteaz altui angajat Relaii alternative (sau/sau) Uneori se ivesc situaii cnd relaiile posibile se redau alternativ: fie o variant este de urmat, fie cealalt. De exemplu, o marf destinat vnzrii poate fi realizat de unitatea care o vinde sau poate fi procurat din afar. n ambele cazuri, obiectul comercializat, MARFA, care este o entitate, va fi pus n legtur cu cele dou surse posibile, PRODUCIA_ALTORA i PRODUCIA_PROPRIE, printr-un punct comun, dar nu cu linii de relaii distincte, aa cum este prezentat n figura 3.16.
PRODUCIA ALTORA

6.

MARFA
PRODUCIA PROPRIE

Figura 3.16. Exemplu de diagram pentru relaiile alternative Citirea diagramei este: O marf se poate asocia sau cu un productor din afar, sau cu producia unitii Un productor din afar poate livra mai multe mrfuri O linie proprie de producie poate livra mai multe mrfuri Dei diagramele entitate-relaie se cunosc de ctre muli specialiti din lumea bazelor de date, ele constituie unul din conceptele eseniale ale analizei i proiectrii structurate i, ca atare, provin din acest domeniu [5]. Dup cum reiese i din citirea cu atenie a numelui diagramei, scopul ei este de a evidenia entitile de date (obiectele despre care se solicit pstrarea datelor) i relaiile ce exist ntre ele. De remarcat diferena dintre diagrama fluxului de date i diagrama entitate-relaie. n timp ce diagrama fluxurilor de date indic att procesele de prelucrare, ct i entitile de date (redate fie sub forma fluxurilor de date, fie a locurilor de stocare), DER trateaz doar entitile de date. Din aceast cauz, DER poate fi considerat i ca diagrama modelului datelor sau diagrama conceptual a datelor [5]. n sistemul analizat pentru descrierea DER se apeleaz la simbolul dreptunghi, pentru fiecare entitate. Se recomand ca numele entitii s fie redat printr-un substantiv la singular (CLIENT, PRODUS, SALARIAT, FACTURA_DESFACERE, NCASRI). Dup ce se identific entitile se continu cu mperecherea lor, fiecare cu fiecare, pentru a descrie relaiile dintre ele.

48

Figura 3.17. DER pentru aplicaia Decontri 3.4.1. Modelul Entitate/Relaie (E/R) Cercetrile efectuate pentru definirea unui model de date care s permit reprezentarea ct mai fidel a realitii au condus la definirea conceptului de model semantic nc din 1976 cnd Chen a prezentat modelul Entitate-Relatie (E/R), care constituie astzi o tehnic larg acceptat pentru proiectarea bazelor de date. Modelul E/R permite proiectantului bazei de date s elaboreze un model conceptual de nivel nalt, fr a ine seama de anumite constrngeri impuse de utilizarea unui anumit SGBD, de o anumit platform hardware, sau de anumite considerente de eficien privind exploatarea bazei de date, ceea ce permite o reprezentare mai fidel a realitii avute n vedere, constituind astfel o etap intermediar n proiectarea unei baze de date, fiind din acest punct de vedere asemntor pseudocodului utilizat n activitatea de programare. Modelul Entitate/Relaie (E/R) permite reprezentarea schematic a realitii avute n vedere cu ajutorul unei diagrame E/R definit plecnd de la conceptele de baz: tip de entitate, tip de relaie (legtur, corelaie), atribut. Pentru reprezentarea unor probleme complexe de tip baz de date, aprute ncepnd din anii 80, modelul de date semantic a fost extins cu noi concepte semantice, rezultnd astfel modelul entitate relaie extins EER. n acest sens la conceptele de baz au fost adugate conceptele suplimentare de superclas, subclas i motenire. O superclas reprezint un tip de entitate care conine subclase distincte care trebuie s fie reprezentate n cadrul modelului, iar o subclas este un membru al unei superclase. O subclas, fiind un tip de entitate distinct, poate avea la rndul su subclase, astfel nct se pot construi ierarhii de clase. O subclas motenete toate atributele superclasei, putnd avea n plus i alte atribute. n diagrama EER, pentru subclase se vor reprezenta numai atributele specifice subclasei. Pentru elaborarea unei diagrame EER, se utilizeaz [5], [7] o serie de simboluri reprezentate n figura 3.18.

49

Sisteme informatice

<nume entitate> <nume atribut> <nume atribut> <nume atribut>

tip

Reprezentare tip entitate cu numele <nume tip entitate>

Reprezentare atribut cu numele <nume atribut> Reprezentare atribut cheie cu numele <nume atribut>

Reprezentare atribut derivat cu numele <nume atribut> Reprezentare atribut> format din <atribut2> atribut compus <nume <atribut1>,

<atribut 1> <nume atribut>

<atribut 2>

componentele

<nume entitate> <nume atribut> <nume relaie> E

tip Apartenena atributului <nume atribut> la tipul de entitate <nume tip entitate>

tip

Reprezentare tip de relaie cu numele <nume tip relaie>

RELAIA R FUNCIONAL FA DE TIPUL

RELAIA R NEFUNCIONAL FA DE TIPUL

Superclas a Subclasa

APARTENENA SUBCLASEI LA

50

FIG. 3.18. SIMBOLURI UTILIZATE N REPREZENTAREA UNEI DIAGRAME EER

Problem rezolvat Folosind modelul entitate - relaie s se reprezinte diagrama E/R pentru un sistem informatic simplificat al unei firme care desfoar activitate de comer fiind avute n vedere subsistemele; aprovizionare (evidena furnizorilor); desfacere (situaia vnzrilor); urmrirea stocurilor.

Cod furnizor

Cod produs

FURNIZORI

Oferte

PRODUSE

Fig. 3.19. Subsistemul Aprovizionare. Reprezentarea relaiei de tip m-n Oferte

Cod produs

Cod client

m PRODUSE

Vnzri

CLIENTI

Fig. 3.20. Subsistemul Desfacere. Reprezentarea relaiei de tip m-n Vnzri Aprovizionare 1 PRODUSE 1 51
Ieiri Intrri

Cod produs

Cod Produs+Depozit+Pre

n STOCURI n

Desfacere
Fig. 3.21. Subsistemul Urmrirea stocurilor. Reprezentarea relaiilor de tip 1-n Intrri, Ieiri, pentru actualizarea stocurilor

Sisteme informatice

Cod produs

Denumire produs

Descriere produs

PRODUSE Fig. 3.22. Reprezentarea entitii PRODUSE

Strad

Numr

Cod furnizor

Denumire furnizor

Adresa furnizor

PRODUSE Fig. 3.23. Reprezentarea entitii FURNIZORI

Oferta

Cod produs

Unitate de msur produs

Pre unitar produs

Cod furnizor

Oferte 52 Fig. 3.24. Reprezentarea relaiei Oferte

3.5. Selectarea celei mai bune variante strategice de proiectare ntregul efort depus pn n momentul de fa s-a concretizat ntr-o bogat acumulare de informaii despre cerinele sistemului, structurate sub diverse forme, precum i despre modul n care am dori s fie conceput noul sistem sau ce corecii s i se aduc celui vechi. Ne aflm n aa-zisa faz a strategiei proiectului. n afara certitudinilor concretizate n specificaiile elaborate pn acum, asupra variantei noului sistem planeaz i o seam de incertitudini, generate de nehotrrea sau, nc, needificarea asupra formei finale dorite. Un cuvnt greu au utilizatorii i finanatorii proiectului. Pentru a-i ajuta s ajung la o concluzie final comun, trebuie pornit de la cerinele structurate i se vor prezenta cteva strategii concurente de proiectare, dintre care doar una va fi continuat n pasul urmtor al ciclului de via al sistemului, faza de proiectare, n funcie de performanele ei i de ncadrarea n resursele disponibile [5]. Rezultatul final al studiului de identificare a cerinelor de informaii se concretizeaz ntr-un raport detaliat al cerinelor sistemului, n care vor fi prezentate informaiile necesare noului sistem. Raportul cuprinde tot ceea ce trebuie s fie produs de ctre sistem. El va lsa fazei de proiectare o imagine clar a modului n care se vor obine cerinele sistemului. Raportul conine urmtoarele elemente [5]: - descrierea funciilor principale executate n noul sistem, inclusiv ce trebuie fcut i de cine, cum se realizeaz interfaa funciilor cu ntregul sistem i cum funciile noi vor afecta utilizatorii; - descrierea tuturor datelor necesare sistemului, inclusiv nume, mrimea, format, surs, importan, precum i o list a regulilor pentru a se asigura securitatea i controlul datelor; - o structur preliminar a datelor, prin care se va arta cum datele vor fi organizate n nregistrri logice i care este legtura dintre date; - descrierea modului de funcionare a noului sistem i a subsistemelor componente, precum i a modului n care vor fi atinse obiectivele de ctre ntregul organism; descrierea i prezentarea unui exemplar al tuturor intrrilor n sistem, inclusiv numele fiecrei intrri, sursa, cine l completeaz, ce date va conine i cum vor fi culese datele din el; - o descriere i un model de exemplar pentru fiecare ieire din sistem (rapoarte, documente); - descrierea unor norme interne de conduit privind raportrile, programarea activitilor, securitatea i protecia, personalul implicat i zona de acces pe categorii ale acestuia; - prezentarea restriciilor existente n sistem, cum ar fi statutele i regulamentele de organizare.

53

Sisteme informatice CAPITOLUL 4 PROIECTAREA LOGIC A SISTEMELOR INFORMATICE n cadrul acestui capitol este realizat prezentarea noului sistem prin prezentarea tuturor intrrilor sistemului, a ieirilor, precum i a interfeelor i dialogurilor. Avnd n vedere intrrile i ieirile sisemului este prezentat proiectarea logic a bazei de date, activitate prin care se urmrete transformarea diagramelor entitate-relaie n relaii. Dac n primele etape, au fost identificate i structurate cerinele sistemului, n faza de proiectare logic se efectueaz deplasarea ateniei de la prezentarea a ceea ce exist i ce se intenioneaz la descrierea a ceea ce va nsemna noul sistem, cum va funciona. Modul de percepere a noului sistem se va reda prin prezentarea tuturor intrrilor sistemului, a ieirilor, precum i a interfeelor i dialogurile. Ele se construiesc pe baza a ceea ce s-a identificat n etapele anterioare, dar inndu-se cont i de cerinele identificate n timpul desfurrii activitilor din etapa de proiectare logic [5]. Toate intrrile i ieirile sistemului, n faza de proiectare logic, vor fi prezentate ca fluxuri ale datelor ntre un proces manual i altul automat sau ntre o surs/ destinaie i un proces automat din diagramele fluxurilor de date. De regul se poate proiecta cte un formular sau raport pentru fiecare flux de date dintre utilizator i sistem. Documentaia realizat n cadrul acestei etape constituie proiectul tehnic de ansamblu al sistemului. 4.1. Proiectarea formularelor/formatelor i a rapoartelor n cadrul etapei de analiz a sistemului informatic, intrrile i ieirile au fost identificate i prezentate, exprimnd cerinele informaionale la nivelul fiecrui subsistem/ aplicaie informatic. n acel moment nu s-au prezentat toate detaliile privind formularele/formatele, rapoartele i procesul de modelare a datelor, insistndu-se mai mult pe identificarea i descrierea lor. Fiecare format/formular de intrare va fi asociat unui flux al datelor de intrare ntr-un proces al DFD, iar rapoartele se pot regsi ntr-un flux al datelor generate de un proces al DFD. Un formular/format poate fi un document primar sau o machet de ecran care conine unele date predefinite, crora li se adaug altele ce urmeaz a fi completate n rubrici speciale. Un raport este un document economic n care sunt incluse doar date predefinite, ceea ce nseamn c poate fi numit i document pasiv, folosit pentru a citi i vizualiza informaia. n faza de proiectatre logic se reprezint doar o ciorn a formularelor/formatelor, rapoartelor sau ecranelor, ele fiind privite doar ca structur i machet. Ceea ce ne propunem n cadrul proiectrii logice poate fi realizat cu ajutorul unui editor de texte sau un produs program orientat spre grafic, sub forma unui prototip [5].

54

4.1.1. Proiectarea situaiilor cu rezultate finale (rapoartelor) Obiectivul prezentrii detaliate a ieirilor este i acela de a determina formatul i coninutul tuturor rapoartelor imprimate i ale documentelor i ecranelor furnizate de sistem. Proiectarea ieirilor se va face astfel nct s serveasc pentru [2]: - transmiterea rezultatelor prelucrrii pe calculator utilizatorului, ntr-o form pe care acesta s o neleag i n care s-i regseasc cerinele sale; - transmiterea proiectului situaiilor finale programatorului, fr ambiguiti, pentru a-i permite acestuia trecerea la ntocmirea programelor necesare editrii sau vizualizrii. n proiectarea ieirilor, analistul trebuie s elaboreze un model demonstrativ al raportului sau ecranului i s ntrebe utilizatorul dac informaiile din raport i formatul acestuia sunt accesibile. Dac ieirile sunt inacceptabile, analistul trebuie s le modifice [5]. Un instrument util pentru formatul rapoartelor sau ecranelor realizate pe calculator l constituie macheta imprimantei [2]. Macheta imprimantei este reprezentarea de detaliu a situaiei de ieire, cuprinznd: - antet; - titlu; - date de identificare; - cap de tabel; - date elementare ce se imprima rnd de rnd; - totalurile. - detalii i indicaii tehnice de realizare care se refer la: - volumul datelor de ieire; - frecven; - numr de copii i destinaia fiecreia; - grad de precizie al calculelor; - condiii speciale de editare; - criterii de control, validare i interpretare a datelor de ieire. Specificaiile de ieire vor cuprinde, pentru utilizator, macheta situaiei iar pentru programator macheta situaiei i o serie de indicaii tehnice de realizare. Pe baza specificaiilor de ieire se trece la proiectarea fizic prin care se alege suportul informaiilor de ieire, se realizeaz definitivarea formei i formatului de editare a situaiilor (aezarea n pagina / ecran, spaierea ntre coloane i rnduri, etc.) i se definitiveaz procedurile de utilizare i interpretare a ieirilor [2]. Alegerea tipului de suport fizic de ieire (imprimanta, display, disc fix, floppy disc, banda magnetica etc.) se face n funcie de: timpul de rspuns solicitat, amplasarea utilizatorului fa de calculator, hard-ul i soft-ul existent, costul suportului, msura n care rspunde necesitailor de redare a coninutului informaional al situaiei finale [2]. Cnd se pregtesc ieirile, este bine s se ia n calcul ce se urmrete prin ele, astfel nct apelarea la categoriile de date de mai sus s se efectueze n cunotin de cauz.

55

Sisteme informatice n definitivarea formei i formatului de prezentare a situaiilor finale trebuie s inem seama de o serie de considerente practice cum ar fi [2]: Respectarea unor cerine ale factorilor de decizie privind macheta situaiei finale; Restricii tehnice; Elemente de eficien; Lizibilitate spaiere; Utilizarea formularelor pretiprite; Utilizarea monitoarelor sau terminalelor video; Utilizarea generatoarelor de rapoarte.

Respectarea unor cerine ale factorilor de decizie privind macheta situaiei finale O serie de cerine ale conducerii privind macheta situaiei finale oblig proiectantul la o anumit structurare i machetare a situaiilor finale. Informaiile se pot mprii n dou grupe prin prisma sistemelor informatice interne i externe. Informaiile interne reprezint acele informaii culese, generate sau folosite n interiorul organizaiei. Informaiile externe se refer la cele colectate sau create de la sau pentru parteneri strini (facturi, rapoarte anuale, etc) [2]. n funcie de informaiile care pot fi vzute din punct de vedere al echipei manageriale distingem: informaii curente, de atenionare, indicatori de baz, etc. Restricii tehnice n proiectarea situaiilor finale intervin o serie de restricii datorate caracteristicilor i performanelor tehnice ale echipamentelor periferice i anume: numrul maxim de caractere pe linie; numrul maxim de linii pe pagina / ecran; facilitile de imprimare etc. Pe pia se afla o gam variat de echipamente de redare a rezultatelor. Exist mai multe tipuri de imprimante, console i terminale video, ceea ce creeaz posibilitatea unei alegeri adecvate a perifericelor destinate obinerii diverselor tipuri de situaii finale [2]. Elemente de eficien n proiectarea situaiilor finale nu trebuie sa scape ateniei i aspectele de eficient economic privind: reducerea timpului calculator consumat cu editarea propriu-zisa a situaiilor; economie de hrtie de imprimant. Abilitatea i experiena proprie a programatorilor joac n acest sens un rol important. n vederea optimizrii obinerii situaiilor finale pe imprimant se pot folosi de la caz la caz, diverse tehnici cum ar fi: editarea mai multor tabele pe aceeai pagin de imprimant; editarea unei situaii imprimnd fa/verso pe aceeai coal; Pentru a nu irosi timp cu editarea unor situaii finale voluminoase se recomand mai nti rularea unor programe scurte care s verifice cheile de control aplicate. Numai dac aceste chei sunt corecte, eventual verificate i de utilizator, se poate lansa editarea analitica a situaiilor finale. Programele care editeaz situaii finale voluminoase trebuie prevzute cu posibilitatea de ntrerupere (respectiv de reluare a editrii n cazul unor incidente ivite n timpul rulrii) sau editarea lor sub forma unui fiier ASCII sau text pe hard disc sau floppy disc, urmnd imprimarea ulterioara a acestui fiier, total sau parial [2].

56

Lizibilitate spaiere Parcurgerea unei situaii finale trebuie s fie ct mai uoara, citirea unei situaii nu trebuie s dea natere la ambiguiti. Este necesar ca situaia sa fie autoexplicativ. Pentru aceasta, antetul va conine informaii i coduri ce vor indica sursa de emitere a raportului, exprimnd clar, sintetic, coninutul raportului i perioada la care se refer. Capul de tabel, mpreuna cu titlul i antetul, se afieaz pe urmtoarele pagini numai dac au intervenit schimbri n cadrul caracteristicilor de grupare fa de prima pagin, altfel se imprim doar numerotarea coloanelor de tabel. Informaiile importante pot fi subliniate. Totalurile se separ de informaiile analitice. Informaiile care se repet pe linii succesive se imprim o singur dat [2]. Utilizarea formularelor pretiprite Aceasta implica utilizarea unei hrtii de imprimanta ce cuprinde elemente fixe ale situaiei finale, cum ar fi antetul, titlul, capul de tabel, textul explicativ etc. Aceasta conduce la o cretere a vitezei de editare i o diminuare a uzurii imprimantelor, riboanelor etc. Totodat situaiile obinute sunt mai estetice i sunt uor de parcurs de utilizatori [2]. Utilizarea monitoarelor sau terminalelor video Prin intermediul unui soft adecvat, monitoarele sau terminalele video ofer posibilitatea afirii situaiilor finale, att n regim alfanumeric, ct i n regim grafic, alegerea modului de lucru fcndu-se prin intermediul unor comenzi sau comutatori. Ecranul unui terminal video n regim alfanumeric este alctuit din linii i coloane iar n regim grafic ecranul este privit ca o matrice de puncte denumite pixeli. Reprezentarea informaiilor de ieire sub forma grafic reprezint un pas nainte fa de editarea sub forma de text a rapoartelor. Aceast form de afiare se recomand factorilor de decizie de pe nivelele de conducere superioare, dat fiind gradul de sintetizare a informaiilor de ieire i volumul redus al rapoartelor. Pe lng problemele legate de aezarea informaiilor pe ecran, la proiectarea ecranelor de ieire se iau n considerare i facilitile oferite de monitoare sau terminalele video i anume: regimul de lucru (defilare ecran, pagina sau linie); regimul de afiare (normal, mai luminos, cu intermitente, invers video); regimul de semnalizare sonor (normal, semnal sonor dup afiarea unui cmp etc.) [2]. Utilizarea generatoarelor de rapoarte ( REPORT WRITER ) Multe limbaje de programare, pachete de programe i sisteme de gestiune a bazelor de date dispun de module specializate n editarea de rapoarte, ceea ce conduce la reducerea considerabila a eforturilor programatorilor. De obicei, aceste generatoare solicit precizarea titlului, antetului de coloan, coninutul unui rnd de date (de detaliu), gradele de total i maniera lor de afiare, la nceputul sau la sfritul grupului de date, al paginii sau raportului. De asemenea, se pot selecta dimensiunea unei linii, coloane, pagini, spaierea dintre linii, coloane, afiarea datelor privind momentul listrii, statistici etc. Astfel de module specializate exist n pachete de programe pentru gestionarea bazelor de date cum ar fi: ACCESS, dBASE, ORACLE, VISUAL FOXPRO, PARADOX, etc.

57

Sisteme informatice 4.1.2. Proiectarea codurilor n proiectarea sistemului de coduri trebuie s avem n vedere dou aspecte importante i anume [2]: - influena tipului i structurii codului asupra performanelor sistemului informatic; - implicaiile utilizrii codurilor n operaiile de culegere a datelor i interpretarea rezultatelor finale de ctre utilizatorii neinformaticieni. Primul aspect ridic probleme de ordin tehnic n realizarea nomenclatorului de coduri i are n vedere facilitarea operaiilor de prelucrare, ocuparea unui spaiu de memorie intern i extern ct mai mic etc. Celui de-al doilea aspect trebuie s i se acorde o atenie mai mare n vederea uurrii activitilor de culegere, verificare a datelor i interpretarea rezultatelor din situaiile finale. Avnd n vedere aceste considerente, se impune ca la proiectarea unui sistem de coduri s se respecte o serie de cerine. De exemplu, codul persoanei poate fi format din urmtoarele coduri elementare: X Iniiala nume X Iniiala prenume X Sex XX XXX Ziua naterii Luna naterii XXXX Anul naterii XX Grupa sanguin

Activitile parcurse n realizarea unui sistem de coduri sunt: [2] analiza elementelor ce urmeaz a fi codificate; precizarea i uniformizarea tehnologiei, a denumirilor; stabilirea caracteristicilor i a relaiilor dintre elementele de codificat; alegerea tipurilor de coduri; estimarea capacitii, lungimii i formatului codurilor; atribuirea codurilor elementelor de codificat (crearea nomenclatoarelor de coduri); ntreinerea nomenclatoarelor de coduri. Este indicat a se utiliza, acolo unde este cazul, sistemele de codificare existente la nivelul economiei naionale (CAEN, SIRUES, SIRUTA, CNP, etc). 4.1.3. Proiectarea intrrilor n sistemul informatic Datele de intrare parcurg o succesiune de etape pn la utilizarea efectiv n cadrul sistemului informatic. Aceste etape intermediare sunt: nregistrarea datelor pe documentul de intrare; conversia datelor ntr-o form acceptata de sistemul de calcul / transpunere pe suportul tehnic; verificarea sintactic i semantic a datelor de intrare; corecia datelor eronate etc. La proiectarea intrrilor este necesar s se realizeze, n principal urmtoarele activiti: - alegerea suportului tehnic pentru culegerea datelor - proiectarea machetelor documentelor de intrare, stabilirea instruciunilor de culegere - stabilirea regulilor de control i validare a datelor - proiectarea formularelor (videoformatului) de intrare. Alegerea suportului tehnic al datelor de intrare se face n funcie de cerinele aplicaiei informatice. Datele introduse de la terminalul video fie intr imediat n circuitul de prelucrare-actualizare a unei baze de date, fie sunt stocate pe un suport magnetic sau sunt stocate n vederea prelucrrii ulterioare. [2]

58

La proiectarea machetei documentelor de intrare (indiferent de metodele de prelucrare a datelor folosite ulterior) sunt respectate cteva reguli care s nlesneasc completarea i apoi utilizarea documentului att pentru prelucrarea automat a datelor ct mai ales pentru necesitile curente ale salariailor societii economice. Nu este recomandabil s dublm documentele primare, prin proiectarea unor documente destinate exclusiv prelurii datelor pentru necesitile prelucrrii automate [2]. Macheta documentului primar trebuie s conin: - antetulce reprezint denumirea unitii i/sau a serviciului care-l emite; - denumirea documentului; - coduri de identificare, - data documentului; - rubrici /casete/ rnduri pentru denumirea informaiilor cantitativ-valorice i coduri; - rubrici /casete /spaii pentru semnturi i tampile; - text explicativ, eventual indicaii de completare i verificare. n ordonarea informaiilor pe document, deci n rubricarea documentului se va ine seama de cteva reguli: antetul se plaseaz n stnga sus; codurile i alte informaii de identificare se plaseaz n dreapta sus; sensul natural de parcurgere este de sus n jos i de la stnga la dreapta; zonele de document ce se completeaz de compartimente/ persoane diferite se marcheaz / grupeaz distinct; mrimea i spaierea documentului, distana dintre rnduri, dimensiunea rubricilor, depind de locul i modalitatea de completare (manual, dactilo, automat) precum i de nivelul de calificare a personalului ce completeaz documentul. Aezarea rubricilor pe document trebuie s respecte ordinea fireasc de folosire a documentului i nu ordinea de utilizare a datelor n programe. Ordinea de culegere a datelor este suficient a fi precizat prin numerotarea rubricilor sau simpla lor ncadrare n chenar sau utilizarea de litere ngroate n denumirea rubricilor implicate n dialogul operator-calculator. Atunci cnd documentul exist ntr-o form pe hrtie, n varianta pe calculator se va urmri pstrarea n mare msur a structurii existente, dar cu adaptri specifice noului mediu. Regulile de control i procedurile de validare a datelor de intrare trebuie s cuprind [2]: - reguli de verificare a volumului, secvenei documentelor i a cifrelor de control (dac este cazul) pe pachetele de documente primare; - reguli pentru controlul sintactic i semantic a datelor din documentele primare. Aceste reguli se refer la: ncadrarea indicatorilor numerici (n limitele de verosimilitate), corelaii logice (ntre indicatorii nscrii n acelai document, sau cu ali indicatori din baza de date), prezena unor informaii obligatorii (apartenena codurilor la nomenclatoarele de coduri specifice aplicaiei informatice) etc. Aceste reguli sunt necesare pentru scrierea programelor de verificare logic a datelor de intrare. Proiectarea formularelor(videoformatelor) de intrare pentru introducerea datelor de intrare se face n funcie de modul concret de desfurare a dialogului operatorcalculator. Acest dialog se poate desfura sub form de [2]:

59

Sisteme informatice ntrebare-rspuns cu defilarea liniilor ecranului; afiare pe ecran a machetei de introducere a datelor de intrare. n prima variant, mai uor de realizat practic, operatorul introduce succesiv, ca rspuns la ntrebrile afiate pe ecran, date de intrare. La proiectarea formelor de intrare este necesar ca proiectantul s aib n vedere o serie de aspecte cum ar fi: - afiarea la un moment dat a unui volum redus de informaii; - afiarea la un moment dat a unei cereri de rspuns ce se refer la o singur informaie; - scurtarea rspunsului operatorului prin folosirea mnemonicelor i codificrilor; - utilizarea unor formate clare i precise pentru afiare; - evitarea cuvintelor i caracterelor dificil de citit sau neles; - existenta unor rutine speciale de tipul HELP; - preluarea asistat a unor coduri (ex. utilizare tehnici de tip Lookup wizard n ACCESS) In varianta a doua cursorul marcheaz de fiecare dat cmpul curent care se introduce. Ecranul display-ului trebuie s reproduc integral sau simplificat macheta documentului, respectnd aceeai ordine a rubricilor. Mesajele de eroare se pot afia ntro zona prestabilita a ecranului, nsoit de avertizare sonora sau luminoasa. Dac este cazul, pentru unele cmpuri (rubrici) de date se pot prelua valori implicite, atunci cnd nu sunt completate. Aceste valori se preiau din nomenclatorul de coduri, fiierele bazei de date sau tabele special memorate pentru valorile asumate prin lipsa sau prin aplicarea unui algoritm. Pentru o mai uoar operare este necesar s folosim toate facilitile de afiare i de combinare a culorilor oferite de terminalul video (figura -

4.1). Figura 4.1. Formularul(macheta) de intrare pentru facturi n proiectarea formularelor de intrare pot fi utilizate componente specializate n acest sens din sistemele de gestiune a bazelor de date cum ar fi ACCESS, dBASE, ORACLE, PARADOX precum i programe scrise n diverse limbaje de programare.

60

4.2. Proiectarea interfeelor i a dialogurilor Interfaa cu utilizatorul - reprezint o parte a aplicaiei software care permite utilizatorilor s-si exprime inteniile de operare asupra calculatorului i s interpreteze rezultatele aciunilor efectuate de main. Prin proiectarea dialogurilor i a interfeelor se definesc modalitile prin care oamenii i calculatoarele schimb informaii [5]. Metode i echipamente folosite n dialogul om-main Interfaa om main definete modalitatea prin care utilizatorul interacioneaz cu un sistem informatic. Interfeele sunt destul de variate, conform descrierilor, ns toate trebuie s dispun de un stil sau de o metod prin care s se foloseasc anumite echipamente n msur s faciliteze o astfel de interaciune [5]. Metode de interaciune Metodele cele mai utilizate sunt [5]: - interaciunea prin limbaj-comand (n acest tip de interaciune utilizatorul transmite calculatorului comenzile sub forma unui ir de caractere) - interaciunea prin meniuri(utilizatorul transmite comenzile sale calculatorului prin intermediul unui sistem de meniuri i opiuni de meniu sau folosind scurtturi sub form de combinaii de taste). - interaciunea bazat pe obiecte icons(comunicarea se face prin intermediul desenelor. Imaginile folosite funcioneaz ca butoanele, la apsarea lor se activeaz o anumit funcie sau comand) - interaciunea prin limbaj natural(comenzile se transmit folosind vocea i sintetizatoarele de voce pentru redarea rezultatelor) Echipamentelor necesare interaciunii cu sistemul Cele mai folosite echipamente sunt [5]: keyboard tastatura este format dintr-un set de butoane (taste) Prin intermediul ei se introduc date, comenzo. - Mouse. - Joystick. - Touch Screen atingerea ecranului constituie modalitatea prin care are loc selecia. - Light Pen Stiloul optic efectueaz selecia prin apsarea pe ecran. - Voice Vocea constituie modalitatea de transmitere a textelor i comenzilor ctre calculator. Proiectarea dialogurilor Proiectarea dialogurilor este procesul prin care sunt proiectate toate secvenele folosite de utilizator pentru a comunica cu un sistem informatic. Rolul proiectantului este de a selecta cele mai potrivite metode i echipamente, precum i de a prezenta condiiile n care se pot afia informaiile sau se pot obine de la utilizator.

61

Sisteme informatice Pentru a obine rezultate bune trebuie s se in seama de regulile de baz la conceperea dialogurilor cum ar fi: uniformitate, comenzi scurte, uurina n lucru, controlul, operaiunea invers (refacerea unui element ters), rezolvarea erorilor, etc. O modalitate de prezentare a secvenei dialogurilor este cea care apeleaz la tehnica diagramelor. Ea va face trimitere la meniurile componente ale aplicaiei.
MO1

MENIU_PRINCIPAL

MO2 PO2 ADUGARE PO1 TERGERE MENIU_INTERO GARE

PO4

PO3
I_DUP_NUME

PROCES MENIU

I_DUP_AN

Figura 4.2. Structura unei diagrame de apelare a meniurilor [5]. Pentru proiectarea interfeelor i dialogurilor se poate apela la ajutorul oferit de produsele CASE sau la mediile de dezvoltare grafic ACCESS, Visual Basic, etc. Pentru a se putea proiecta n condiii optime mediile GUI (Graphical User Interface) trebuie s se cunoasc aceste medii. n mediile grafice informaiile se plaseaz n ferestre. Acestea au trsturi specifice ca: redimensionarea, maximizarea, disponibilitatea la deplasare, meniu sistem, etc. 4.3. Proiectarea logic a bazelor de date Proiectarea logic a bazelor de date este n strns legtur cu modelarea conceptual a datelor, aceasta nsemnnd reprezentarea modului de organizare a datelor, independent de tehnologiile specifice de prelucrare a bazelor de date, fr s se nregistreze o preocupare anume referitoare la calitatea modelelor datelor. Ultimului aspect i se va acorda atenia cuvenit abia acum, odat cu modelarea logic a datelor, descriindu-se structurile datelor din baz. Procesul de modelare logic a datelor se deruleaz n paralel cu celelalte activiti ale proiectrii logice: proiectarea formularelor i a rapoartelor i proiectarea dialogurilor

62

i interfeelor. Modelarea logic a datelor se realizeaz nu numai pe baza diagramei entitate-relaie, ci i pe baza machetelor formularelor i a rapoartelor. Se efectueaz analiza datelor elementare din intrrile i ieirile sistemului pentru a se desprinde legturile dintre ele. Prin modelarea logic a datelor se urmrete:
structurarea performant a datelor prin procesul de normalizare obinerea unui model logic al datelor din care s se poat realiza proiectul bazei de date fizice, adic modelul relaional cel mai utilizat n prezent, dei se pot obine i modelele reea, ierarhic sau orientate-obiect; - realizarea unui model al datelor care s rspund cerinelor actuale de date regsite n formulare i rapoarte. Modelarea logic este un proces ascendent (bottom-up, de jos n sus) de obinere a relaiilor din formulare i rapoarte prin transformarea modelului entitate-relaie ntro form relaional. Modelarea logic a datelor descrie datele cu ajutorul unei notaii speciale, care corespunde unui mod de organizare a acestora de ctre un sistem de gestiune a bazelor de date. Procesul de modelare a datelor este complex. n fiecare etap a ciclului de via se regsete cte o activitate specific datelor dup cum urmeaz [5]: - Analiza Modelele conceptuale ale datelor, prezentarea DER; - Proiectarea logic Modelul logic al datelor(relaional); - Proiectarea fizic Proiectarea fizic a bazelor de date i a fiierelor (organizarea fiierelor); - Implementarea Descrierea fiierelor i a bazelor de date. Dup cum prezint profesorul Oprea D. n Analiza i proiectarea sistemelor informaionale economice n procesul de modelare logic exist patru pai eseniali: 1. Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare i rapoarte) privind aplicaia, folosindu-se principiile normalizrii; 2. Contopirea tuturor perspectivelor normalizate ale utilizatorilor ntr-un model logic consolidat (centralizat) al datelor, numit i integrarea perspectivelor; 3. Transformarea modelului conceptual al datelor (entitate-relaie), realizat fr s se in cont de perspectiva utilizatorului, ntr-un set de relaii normalizate; 4. Compararea modelului logic consolidat al datelor cu modelul transformat al entitii-relaie i realizarea, prin integrarea perspectivelor, a unui model logic final al datelor aplicaiei. Rezultatele obinute prin parcurgerea celor patru pai pot fi ilustrate prin intermediul unor exemple oferite n literatura de specialitate de McFadden i Hoffer [5]. Primul pas al modelrii logice se poate explica prin dou rapoarte solicitate de utilizatori, reprezentnd perspectiva utilitii sistemului din punctul lor de vedere: - cel mai bun client al produsului X(ecran); - situaia comenzilor n curs; Ecranul Cel mai bun client al produsului X, prin percepia utilizatorului, are urmtorul format: Cel mai bun client al produsului Introducei codul produsului: P1122 Data de nceput: 10/10/99 Data de sfrit: 31/12/99 ---------------- -------- ------COD CLIENT: NUME CLIENT: VOLUM: 1111 S.C. ALPHA S.R.L. 1000

Figura 4.3 Model de ecran solicitat de utilizatori [5]

63

Sisteme informatice Din analiza ecran ului se pot desprinde relaiile: CLIENT(COD_CLIENT, NUME) COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA) PRODUS(COD_PRODUS) LINIE_COMANDA(NR_COMANDA,COD_PRODUS,CANTITATE_COMANDATA) Raportul Situaia comenzilor n curs are urmtorul format:

Pagina 1 Situaia comenzilor n curs 31/03/1998 COD PRODUS CANTITI_DE_LIVRAT A1111 0 A2222 0 B1111 150

Y9999

100

Figura 4.4. Model de raport solicitat de utilizatori [5] Realizarea raportului este posibil prin folosirea urmtoarelor entiti: PRODUS(COD_PRODUS) COMANDA(NR_COMANDA, DATA_COMANDA) LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA) LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA) FACTURA(NR_FACTURA, DATA_FACTURA) Pasul al doilea presupune comasarea perspectivelor utilizatorilor i crearea unui set integrat al relaiilor, rezultnd urmtoarele relaii: CLIENT(COD_CLIENT, NUME) PRODUS(COD_PRODUS) FACTURA(NR_FACTURA, DATA_FACTURA) COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA) LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)

64

LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA) Pasul al treilea const n transformarea modelului conceptual al datelor (diagramaentitate-relaie) din aplicaie fr s se in cont de punctul de vedere al utilizatorului, ntr-un set de relaii normalizate. Din analiza diagramei din figura 6.5 se desprind urmtoarele relaii:
COD_CLIENT NUME_CLIENT ADRESA

NR_FACTURA

CLIENT

FACTURA

Lanseaz

Facturare
CANTITATE_LIV

NR_COMANDA

COMANDA

Livrar

PRODUS
Linie_comand

COD_PRODUS

CANTITATE_ COMANDATA

DENUMIRE

Figura 4.5. Diagrama entitate-relaie pentru gestiunea clienilor [5]

65

Sisteme informatice Din analiza diagramei se desprind urmtoarele relaii: CLIENT(COD_CLIENT, NUME, ADRESA) PRODUS(COD_PRODUS, DENUMIRE) FACTURA(NR_FACTURA, NR_COMANDA) COMANDA(NR_COMANDA, COD_CLIENT) LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA) LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA) Pasul al patrulea compar modelul obinut din pasul doi cu cel din pasul trei i integreaz perspectivele utilizatorilor n vederea obinerii unui model logic final, dup cum urmeaz: CLIENT(COD_CLIENT, NUME, ADRESA) PRODUS(COD_PRODUS, DENUMIRE) FACTURA(NR_FACTURA, NR_COMANDA, DATA_FACTURA) COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA) LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA) LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA) Aadar, rezultatul modelrii logice a datelor l constituie relaiile normalizate rezultate din cel de-al patrulea pas al procesului. De asemenea, alt rezultat se va concretiza n actualizarea depozitului (repository) sau a dicionarului proiectului. Diferena major ntre modelarea conceptual i cea logic este c dup modelarea logic a datelor cerinele structurate de date se concretizeaz n relaii, i nu n entiti. Din cauza normalizrii nu este necesar o coresponden unu-la-unu ntre entiti i relaii [5]. 4.3.1. Normalizarea relaiilor - Forme normale ntre atributele unei relaii sau ntre atribute din relaii diferite pot exista anumite legturi logice (dependene), care influeneaz proprietile schemelor de relaie n raport cu operaiile curente care intervin n timpul exploatrii bazei de date: adugare, tergere, actualizare. Aceste legturi logice, cunoscute n literatura de specialitate sub denumirile de dependenele funcionale, dependenele multivalorice i dependene de cuplare, au implicaii majore asupra criteriilor de proiectare a schemelor relaionale. Alegerea unui model conceptual convenabil pentru o baz de date relaional poate necesita realizarea unor descompuneri pentru anumite scheme de relaie date, descompuneri care s izoleze dependenele existente i prin aceasta s elimine anomaliile care se datoreaz acestor dependene. Dependene funcionale Penru definirea acestui tip de dependene se consider schema de relaie Prestari_Servicii (Cod, Nume_client, Adresa, Serviciu_prestat, Valoare)

66

definit pentru urmrirea serviciilor prestate de o firm pentru diveri clieni. Atributul Adresa este dependent de atributul Nume_client (presupunnd c fiecare client are o singur adres, rezult c fiecare valoare a atributului Nume_client determin n mod unic valoarea corespunztoare a atributului Adresa). Analiznd schema de relaie de mai sus, se constat o redundan relativ la atributul Adresa a crei valoare este repetat pentru un client pentru fiecare serviciu prestat pentru acest client, ceea ce conduce la apariia urmtoarelor anomalii: - Anomalia la adugare: adresa unui client poate fi preluat numai dup ce pentru acesta se presteaz cel puin un serviciu. - Anomalia la tergere: dac se terg toate serviciile prestate pentru un anumit client, se pierde adresa acestui client. - Anomalia la actualizare: datorit redundanei relativ la atributul Adresa, dac se schimb adresa unui client este necesar parcurgerea ntregii relaii pentru a identifica i actualiza toate apariiile acestui client, n caz contrar baza de date devine inconsistent (acelai client poate apare la adrese diferite). Aceste anomalii pot fi eliminate, dac schema de relaie Prestari_Servicii se nlocuiete prin urmtoarele dou scheme de relaie: Clienti(Cod, Nume_client, Adresa) Servicii(Cod, Serviciu_prestat, Valoare). Relaia Clienti conine codul, numele i adresa fiecrui client, fr nici un fel de redundan, iar relaia Servicii conine serviciile prestate pentru fiecare client i valorile acestor servicii. Un dezavantaj al descompunerii relaiei iniiale n cele dou relaii este acela c pentru a determina adresa clientului pentru care s-a prestat un anumit serviciu este necesar efectuarea unei operaii de cuplare a relaiilor Clienti i Servicii. Se consider o schem de relaie R i A,B dou atribute simple sau compuse ale schemei de relaie R. Atributul A determin funcional atributul B sau B depinde funcional de A, dac i numai dac oricrei valori a atributului A i corespunde o singur valoare a atributului B (se noteaz A->B). Dependena funcional A->B este total dac nu exist nici un subset C al atributului A (CcA) astfel nct C->B i este parial n caz contrar. n relaia Prestari_Servicii, una din dependenele funcionale care poate fi pus n eviden este Nume_client->Adresa. Deoarece ntr-o relaie orice cheie identific n mod unic fiecare tupl a relaiei, deci determin n mod univoc valorile atributelor tuplei, rezult c n orice relaie atributele sunt dependente funcional fa de cheile acesteia. Se pot face, pn n acest moment, urmtoarele precizri: Eliminarea dependenelor funcionale din schemele de relaie i a consecinelor negative (redundana datelor; anomaliile de adugare, tergere, actualizare) se realizeaz prin descompunerea schemei date ntr-o colecie de scheme mai simple n care sunt evitate neajunsurile mai sus menionate. Reconstituirea relaiei iniiale se poate face prin operaia

67

Sisteme informatice de cuplare (uniune). Pentru ca descompunerea schemei de relaie s fie echivalent cu relaia iniial, trebuie s fie ndeplinite condiiile: - cuplare fr pierdere de informaie; - conservarea dependenelor (dependenele funcionale din relaia iniial trebuie s se regseasc n relaiile rezultate prin descompunere). Formele normale sunt scheme de relaie echivalente obinute prin descompunerea unor scheme de relaie n vederea eliminrii redundanei datelor i anomaliilor la adugare, actualizare, tergere nregistrri n baza de date. Descompunerile schemelor de relaii n scheme de relaii echivalente avnd n vedere dependenele funcionale conduc la definirea primelor 4 nivele de forme normale i anume: prima form normal (FN1), a doua form normal (FN2), a treia form normal (FN3) i forma normal BoyceCodd (FNBC). A patra form normal (FN4) este definit avnd n vedere dependenele multivalorice, iar a cincea form normal (FN5) este definit avnd n vedere dependenele de cuplare. ncepnd de la prima form normal i pn la forma normal FN5 se impun condiii din ce n ce mai restrictive asupra relaiilor. Astfel o relaie aflat pe un anumit nivel de normalizare (FN5) satisface toate restriciile cerute de nivele inferioare de normalizare (FN1, FN2, FN3, FNBC, FN4). n cele ce urmeaz sunt date definiiile formelor normale avnd n vedere dependenele funcionale. O relaie R este n prima form normal (FN1) dac i numai dac toate atributele sale iau numai valori atomice (nu pot fi descompuse). Spre exemplu, atributul Adresa ar putea fi considerat un atribut neatomic dac n cadrul adresei ne-ar interesa localitatea, strada etc., caz n care trebuie descompus n atribute atomice. O relaie R este n a doua form normal (FN2) dac este n FN1 i orice atribut neprim este total dependent fa de orice cheie a relaiei (atributele prime sunt atribute care fac parte dintr-o cheie a relaiei i cele neprime sunt atributele care nu aparin nici unei chei a relaiei). O relaie R este n a treia form normal (FN3) dac este n FN2 i nici un atribut neprim nu este funcional dependent fa de un alt atribut neprim al relaiei. O relaie R se afl n forma normal Boyce-Codd (FNBC) dac singurele dependene funcionale admise sunt cele n care o cheie determin un alt atribut (nici un atribut prim sau neprim nu poate fi dependent funcional fa de un alt atribut dac acesta nu este sau nu conine o cheie). Dependene multivalorice Pentru ilustrarea acestui tip de dependene se ia n considerare urmtoarea schem de relaie: Clase(Clasa, Discipline, Elevi) ce conine clasele dintr-o instituie de nvmnt, iar pentru fiecare clas sunt nregistrate disciplinele ce se predau i elevii nmatriculai n clasa respectiv. Se poate constata c relaia Clase poate rezulta prin operaia de cuplare dup atributul Clasa a urmtoarelor dou relaii: CD(Clasa, Discipline) CE(Clasa, Elevi)

68

n relaia Clase, presupunnd c pentru o clas dat, fiecare elev frecventeaz toate disciplinele nregistrate pentru acea clas, exist dependenele multivalorice: Clasa ->> Discipline Clasa ->> Elevi. Ca i n cazul dependenelor funcionale, existena dependenelor multivalorice prezint aceleai neajunsuri privind redundana datelor i anomalii la efectuarea operaiilor de adugare, actualizare i tergere nregistrri n baza de date. O relaie R este n a patra form normal dac singurele dependene multivalorice admise sunt cele determinate de un alt atribut care este o cheie sau care conine o cheie a relaiei. ntruct orice dependen funcional este un caz particular de dependen multivaloric, rezult c orice relaie care se afl n forma normal FN4, se afl i n forma normal FNBC. Transformarea unei relaii ntr-o colecie de relaii care s se afle n FN4 este similar cu trecerea n FNBC, ns trebuie avut n vedere att eliminarea dependenelor funcionale ct i a dependenelor multivalorice. n concluzie, putem afirma c n cazul formelor normale de la FN1 la FN4, trecerea de la o form normal la alta s-a fcut prin descompunerea unei relaii n altele dou, urmrindu-se eliminarea dependenelor funcionale i multivalorice. O relaie aflat n forma normal FN4 nu mai poate fi descompus n continuare pe baza acestei metode. Exist situaii cnd relaii aflate n FN4 conin redundane i prezint anomalii la operaiile de adugare, tergere i actualizare. Aceste anomalii sunt cauzate de existena dependenelor de cuplare i pot fi eliminate prin descompunerea relaiei n 3 sau mai multe relaii a cror cuplare are ca rezultat relaia iniial. Dependene de cuplare Se consider schema de relaie: SDS (Specializari, Discipline, Studenti) care conine disciplinele care se predau la diverse specializri i studenii care le frecventeaz, cu precizarea c pot exista discipline opionale care nu sunt frecventate de toi studenii de la specializarea respectiv. n aceste condiii n cadrul schemei de relaie SDS nu au loc dependenele multivalorice: Specializari ->> Discipline Specializari->> Studenti ceea ce nseamn c relaia SDS este n FN4. Dei este n FN4, relaia SDS conine mai multe redundane care pot conduce la anomalii de actualizare. Pe de alt parte, relaia SDS nu poate fi descompus n dou componente din a cror cuplare s rezulte relaia iniial cu conservarea informaiei. Se constat ns c relaia SDS poate fi descompus n urmtoarele 3 relaii: SD(Specializari, Discipline) SS(Specializari, Studenti) DS(Discipline, Studenti) i relaia SDS este rezultatul cuplrii relaiilor: SD, SS i DS fr pierdere de informaie. SDS = SDSSDS.

69

Sisteme informatice n acest caz spunem c n relaia SDS exist o dependen de cuplare. Dependenele multivalorice sunt cazuri particulare de dependene de cuplare. A cincea form normal este o generalizare a formei normale patru, trecerea unei relaii n FN5 presupunnd eliminarea dependenelor de cuplare existente n cadrul relaiei, mpreun cu anomaliile pe care acestea le creeaz. n cadrul unei relaii pot exista dependene de cuplare care nu conduc la redundan n memorarea datelor i nu produc anomalii la operaiile efectuate asupra nregistrrilor bazei de date (acestea sunt dependenele de cuplare implicate de o cheie a relaiei). O relaie este n forma normal cinci (FN5) dac i numai dac toate dependenele de cuplare existente n relaie sunt implicate de o cheie a acesteia. Relaia SDS se poate descompune, cu conservarea coninutului de informaie, n cele 3 componente ale sale: SD, SS i DS care sunt n FN5. Avnd n vedere similaritatea ce exist ntre definiiile pentru FNBC, FN4 i FN5, acestea pot fi unificate n urmtoarea definiie [13]: O relaie R este n FNBC, FN4, FN5 dac i numai dac singurele dependene funcionale, multivalorice, de cuplare existente sunt cele implicate de o cheie a relaiei R. n concluzie, prin procesul de normalizare se realizeaz eliminarea din schemele de relaie a dependenelor (funcionale, multivalorice i de cuplare) cu scopul de a obine o schem relaional mai bun din punctul de vedere al redundanei datelor i al anomaliilor ce pot apare la operaiile de adugare, tergere i actualizare nregistrri n baza de date. Normalizarea unei scheme de relaie R nseamn nlocuirea acesteia cu o mulime de proiecii R1,...,Rn astfel nct R s fie echivalent cu uniunea proieciilor R1,...,Rn. Dei normalizarea este o operaie util n proiectarea bazelor de date, aceasta nu ofer ntotdeauna reete pentru obinerea celor mai bune modele i de aceea este la latitudinea proiectantului decizia de a aplica sau nu o anumit etap de normalizare dup o analiz temeinic a avantajelor i dezavantajelor modelului obinut. n unele cazuri normalizarea complet, pn la FN5, s-ar putea s fie dezavantajoas. Avnd n vedere constatrile de mai sus se poate afirma c dei normalizarea nu reprezint o soluie general valabil n orice situaie, totui dac pentru proiectarea bazei de date se aplic corect o metodologie de proiectare descendent, modelul rezultat va fi de la sine normalizat. Cercetrile n acest domeniu continu, fiind definite i alte forme normale printre care FN6 pentru baze de date temporale. O baz de date temporal, pe lng datele curente, conine i date istorice, iar factorul (atributul) timp are un rol esenial (exemple concludente de astfel de baze de date sunt depozitele de date). Astfel, n proiectarea unei baze de date temporale trebuie avute n vedere i alte operaii de descompunere a schemelor de relaie i anume: - descompunerea orizontal pentru separarea datelor curente de datele istorice; - descompunerea vertical pentru separarea atributelor aceleiai entiti avnd n vedere valorile lor raportate la atributul temporal. n proiectarea unei baze de date nu este exclus nici operaia invers normalizrii numit denormalizare [12], prin care se urmrete nlocuirea unei colecii de scheme de relaie cu o schem de relaie echivalent n vederea eliminrii necesitii efecturii unor operaii de cuplare care pot fi costisitoare. Dac n cazul normalizrii tendina este de a

70

ajunge la nivele ct mai nalte (FN5), pentru denormalizare nu exist criterii clare putnd fi avute n vedere doar aspecte legate de performanele anumitor aplicaii. Un alt principiu care se urmrete n proiectarea unei baze de date este principiul proiectrii ortogonale conform cruia n cadrul unei baze de date dou scheme de relaie reale (variabile de relaie de baz) nu trebuie s aib semnificaii suprapuse. n timp ce prin normalizare se urmrete reducerea redundanei din cadrul unei scheme de relaie, prin proiectarea ortogonal se urmrete reducerea redundanei dintre schemele de relaie. 4.3.2. Simplificarea structurii datelor prin normalizare Problema de baz a proiectrii logice a bazelor de date este cum ar trebui combinate datele elementare pentru a forma relaii(sau tipuri de nregistrri) care s descrie entitile i relaiile dintre entiti. n limbajul bazelor de date, cuvntul relaie nseamn un tabel de date, ceea ce duce la concluzia c bazele de date relaionale (modelul relaional) sunt cldite pe un grup de tabele legate ntre ele [5]. Modelul relaional a fost dezvoltat de ctre Codd. Este un model conceptual de organizare a datelor, destinat reprezentrii legturilor dintre date. El este bazat pe teoria matematic a relaiilor i este definit cu o deosebit rigoare matematic [Popescu I., 1996]. n cadrul modelului relaional datele sunt structurate sub forma de relaii (de aici i denumirea). Cea mai directa i intuitiva modalitate de reprezentare a datelor n cadrul acestui model este sub forma de tabele. Fiecrei relaii i se poate asocia un tabel care are attea coloane cte mulimi leag relaia i are attea linii cte tuple conine relaia. Prezentarea structurii relaionale a datelor impune definirea noiunilor de: domeniu, relaie, atribut i schem a unei relaii. Conceptele utilizate pentru a descrie formal, uzual sau fizic elementele de baz ale organizrii datelor sunt prezentate n tabelul urmtor: Formal Relaie Tuplu Atribut Domeniu Uzual Tablou Linie Coloan Tip de dat Fizic Fiier(tabel) nregistrare Cmp Tip de dat

Definirea domeniului Un domeniu este o mulime de valori caracterizat printr-un nume. Un domeniu se poate defini explicit prin enumerarea tuturor valorilor aparinnd acestuia sau definind o proprietate distinctiv a domeniului valorilor, de cele mai multe ori limita superioar i limita inferioar [Popescu I, 1996]. De exemplu: D1: {F,M} -definire explicit D2: {x| xN, x [0,100]} -definire implicit D3: {s|s=ir de caractere} -definire implicit Pentru un ansamblu de domenii D1,D2,,Dn produsul cartezian al acestora reprezint ansamblul tuplurilor (elemente ale unei relaii) <v1,v2,,vk> unde vi este un element care aparine domeniului Di. De exemplu, tuplurile <Maria,F,50 >,< Vasile,M,60> aparin produsului cartezian D3xD1xD2.

71

Sisteme informatice Definirea relaiei O relaie R pe mulimile D1,D2,,Dn este o submulime a produsului cartezian D1xD2xxDn, deci o mulime de tupluri [Popescu I, 1996]. Considernd c nu se cunosc dect dou persoane, relaia R se definete prin tuplurile care descriu aceste persoane, i anume: R: {<Maria,F,50>,<Vasile,M,60>} O relaie poate fi reprezentat printr-un tabel bidimensional n care fiecare linie corespunde unui tuplu i fiecare coloan corespunde unui domeniu. R: Maria Vasile D3 F M D1 50 60 D2

Reprezentarea tabelar este preferat adesea altor forme de reprezentare a relaiilor, deoarece este uor de neles i de utilizat. n prezentarea conceptului de relaie se poate recurge la analogii cu alte concepte cum ar fi cel de fiier. Relaia poate avea semnificaia unui fiier, tuplul poate fi considerat o nregistrare, iar valorile din cadrul tuplului pot fi interpretate drept valori ale cmpurilor de nregistrare. Definirea atributului n timp ce tuplurile dintr-o relaie trebuie s fie unice, un domeniu poate apare de mai multe ori n produsul cartezian pe baza cruia este definit relaia [Popescu I, 1996]. PERS D3 Maria Vasile D1 F M 50 60 D2 Vasile Maria D3

Relaia PERS reprezint un subansamblu al produsului cartezian D3xD1xD2xD3. Atributul reprezint coloana unei tabele de date, caracterizat printr-un nume. Numele coloanei (atributului) exprim, de obicei, semnificaia valorilor din cadrul coloanei respective. Semnificaia valorilor din cadrul unui tuplu se stabilete n acest caz nu numai pe baza domeniului de care aparin valorile ci i funcie de poziia ocupat n cadrul tuplului. Dependena fa de ordinea datelor nseamn o reducere a flexibilitii organizrii datelor. ntr-o organizare eficient, flexibil, ordinea liniilor i a coloanelor nu trebuie s prezinte nici o importan. Pentru a diferenia coloanele care conin valori ale aceluiai domeniu, i a elimina astfel dependena de poziie n cadrul tabelei se introduce tocmai conceptul de atribut. Fiecare relaie are asociat un nume sau un identificator propriu. Schema unei relaii este format din ansamblul elementelor definitorii sau din nivelul relaiei urmat de lista atributelor specifice. n mulimile matematice nu este permis ca un obiect s apar de mai multe ori. Ct timp o relaie este o mulime de tupluri, teoretic nici o linie a unei relaii nu poate fi duplicatul altei linii. Dup cum reiese din prezentrile anterioare, dac o coloan sau o

72

combinaie de coloane nu poate s identifice n mod unic o linie, atunci trebuie inventat o coloan-cheie special. O tehnica de proiectare a modelului conceptual al bazei de date ntr-o abordare bottom-up este tehnica celor cinci forme normale. Conform acestei tehnici, atributele entitilor definite se organizeaz ntr-o singur tabel sau n mai multe i se urmrete descompunerea acestor tabele n altele, fr pierdere de informaii n scopul eliminrii anomaliilor de ordin logic i fizic. Acest lucru se realizeaz prin parcurgerea a o serie de etape, de normalizare, prin care se trece de la o forma normal la alta. Se apreciaz posibilitatea existentei a cinci forme normale (FN). Prin parcurgerea acestor etape, se ajunge n mod succesiv s se amelioreze structura bazei de date, nlturndu-se treptat o serie de neajunsuri i asigurnd faciliti sporite n privina ncrcrii, actualizrii i exploatrii bazei de date. O relaie nenormalizat conine unul sau mai multe grupuri care se repet. Necesitatea normalizrii progresive este dat de faptul c anumite relaii pot genera o serie de situaii nedorite, aa-numitele anomalii de actualizare, cum sunt: anomalia de tergere, anomalia de adugare, anomalia de modificare [2]. 4.3.3. Transformarea diagramelor entitate-relaie n relaii Pentru a se putea compara rezultatele obinute n etapa de proiectare logic a datelor, adic a relaiilor normalizate, cu diagrama entitate-relaie, rezultat al proiectrii conceptuale, aceasta din urm trebuie s fie convertit n relaii, de asemenea, normalizate. ntregul proces se desfoar n patru pai, astfel: [5] - Reprezentarea entitilor. Fiecare tip de entitate din diagrama entitate-relaie este reprezentat ca o relaie n modulul relaional al datelor. Identificatorul tipului de entitate devine cheie primar a relaiei, iar celelalte atribute ale tipului entitii devin atribute non-cheie ale relaiei. - Reprezentarea legturilor. Fiecare legtur din diagrama entitate-relaie trebuie s fie reprezentat n modelul relaional al datelor. Reprezentarea legturii se efectueaz n funcie de natura ei. De exemplu, uneori se poate constitui o relaie prin includerea cheii primare a unei relaii ca o cheie strin n alt relaie. Astfel, se poate crea o relaie separat pentru reprezentarea legturii. - Normalizarea relaiilor. Relaiile create n paii 1 i 2 pot conine redundane nedorite i vor constitui surse de nregistrare a anomaliilor n timpul actualizrii. Normalizarea va conduce la o bun structurare a relaiilor. - Fuziunea relaiilor. n timpul modelrii logice a datelor s-au creat diferite relaii, att pe baza normalizrii ascendente a perspectivelor utilizatorilor, ct i a transformrii uneia sau a mai multor diagrame entitate-relaie n seturi de relaii. n structura acestor seturi de relaii pot exista unele relaii redundante, cum ar fi existena a dou sau mai multe relaii care descriu acelai tip de entitate, ce ar trebui s fuzioneze i s se renormalizeze pentru extragerea eventualelor redundane.

73

Sisteme informatice CAPITOLUL 5 PROIECTAREA FIZIC A SISTEMELOR INFORMATICE Proiectarea fizic cunoscut i sub numele de proiectare de detaliu, urmeaz proiectrii logice. Proiectarea logic ntlnit i sub numele de proiectare general, o alt variant de definire a proiectrii logice. De fapt, printr-o astfel de referire se scoate n relief faptul c n timpul proiectrii logice se prezint o imagine de ansamblu (general) a sistemului, n timp ce proiectarea fizic nseamn o abordare detaliat a sistemului. Cu alte cuvinte, n etapa de proiectare logic se acumuleaz informaiile de natur s sintetizeze cerinele utilizatorilor noului sistem, operaiune prestat de analitii de sistem, iar n timpul proiectrii fizice se prezint punctele de vedere ale specialitilor, cum ar fi cei din domeniul bazelor de date, securitii sistemelor, reelelor de calculatoare, programrii, etc. Proiectarea fizic implic parcurgerea urmtorilor pai [5]: 1. Proiectarea fizic a bazelor de date i a fiierelor. O astfel de activitate nseamn descrierea modului n care vor fi stocate datele i cum se va asigura controlul lor pentru a se oferi o securitate maxim; 2. Proiectarea structurii sistemului i a programelor. Se descriu programele sau modulele acestora care s fie n strns concordan cu diagramele fluxurilor de date i cu celelalte piese ale documentaiei realizate n etapele anterioare; 3. Proiectarea strategiilor de prelucrare distribuit. Se vor prezenta modalitile n care utilizatorul poate s dispun de date i facilitile de prelucrare oferite de reele de calculatoare. 5.1. Proiectarea fizic a bazelor de date i a fiierelor Modelul conceptual surprinde structura global de organizare a datelor, asigurndu-se independena total fa de orice sistem de gestiune a bazelor de date. Modelul conceptual este prezentat prin intermediul diagramelor entitate-relaie(DER), motiv pentru care este cunoscut i sub numele de modelul entitate-relaie al datelor. El scoate n eviden reprezentarea logic, detaliat a entitilor, asocierilor (legturilor) i datelor elementare ale unei organizaii sau ale unei pri din ea. Modelul se realizeaz n faza de analiz [5]. Modelul logic al datelor nseamn descrierea datelor n concordan cu modelul de organizare a acestora de ctre sistemele de gestiune a bazelor de date. n acest material sa ales modelul relaional. Conform cu acest model datele sunt reprezentate n baza de date sub forma tabelelor sau relaiilor create din diagrama entitate-relaie obinut n etapa anterioar. O baz de date poate fi definit ca un ansamblu de date elementare sau structurate, accesibile unei comuniti de utilizatori. Mai concret, o baz de date este un ansamblu de fiiere intercorelate, care conine nucleul de date necesare unui sistem informatic (aplicaie informatic). Un fiier este un ansamblu de nregistrri fizice, omogene din

74

punct de vedere al coninutului i al prelucrrii. O nregistrare fizic este unitatea de transfer ntre memoria intern i cea extern a calculatorului. Aceasta este format din una sau mai multe nregistrri logice. O nregistrare logic este unitatea de prelucrare din punct de vedere al programului utilizator. Aceasta este format dintr-un ansamblu de cmpuri, care descriu o anumit entitate. Modul de stocare a datelor pe suportul fizic de memorare este funcie de sistemul de gestiune a bazelor de date utilizat. Proiectarea fizic a bazelor de date i a fiierelor i propune s asigure trecerea de la descrierea logic a datelor la una tehnic, de stocare a datelor. O problem de importan major n cadrul acestei etape o constituie alegerea Sistemului de Gestiune a Bazelor de Date adecvat soluionrii optime a problemelor formulate n etapele anterioare ale realizrii sistemului informatic. 5.1.1. Obiectivele fundamentale ale unei baze de date (BD) sunt: Centralizarea datelor permite: suprimarea redundanei, asigurarea unicitii nregistrrii i controlul centralizat (asupra datelor). n prelucrarea clasic n care fiierele sunt dedicate aplicaiilor, aceleai date apar nregistrate n mai multe fiiere i n formate diferite. Acest lucru implic o utilizare ineficient a spaiului de memorie extern, actualizarea dificil a acestor date i lizibilitate redus ca urmare a formatelor diferite. Independena ntre date i prelucrri. Baza de date, ca imagine a unei anumite realiti, trebuie actualizat permanent. Acest lucru nu trebuie s afecteze programele de prelucrare. Pentru aceasta trebuie ca fiecare program s aib o viziune proprie asupra BD Realizarea de legturi ntre entitile de date, care sunt indispensabile pentru exploatarea eficient a sistemului informatic. Spre exemplu, n cadrul gestiunii aprovizionrii, trebuie asociat un furnizor la lista de produse pe care le vinde i invers, un produs la lista de furnizori, preciznd condiiile de vnzare pentru un furnizor i un produs. Integritatea datelor asigur fiabilitatea i coerena bazei de date (BD). Pentru aceasta trebuie definite restricii de integritate cum ar fi: - apartenena la o list de valori sau interval; - apartenena la un anumit format; - reguli de coeren cu alte date. Securitatea datelor. Baza de date trebuie s fie protejat mpotriva unei distrugeri logice (anomalie de actualizare) sau fizice. Pentru aceasta exist instrumente care permit: - crearea unor puncte de repriz; altfel spus, salvarea din timp n timp a unor copii coerente ale bazei de date; - gestiunea unui jurnal de tranzacii; lista operaiilor realizate asupra bazei de date dup ultimul punct de repriz. Confidenialitatea datelor este asigurat prin proceduri de: - identificare a utilizatorilor prin nume sau cod; - autentificarea prin parole; - autorizarea accesului difereniat prin drepturi de creare, consultare modificare sau tergere pentru anumite segmente de date.

75

Sisteme informatice Partajarea datelor permite nlnuirea tranzaciilor solicitate simultan pe aceeai nregistrare din baza de date, prin blocarea cererilor n ateptare i deservirea ulterioar a acestora. 5.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD) Sistemul de gestiune a bazelor de date referit prescurtat SGBD sau DBMS (Data Base Management System) este un sistem de programe care permite definirea, crearea i ntreinerea bazei de date, precum i accesul controlat la baza de date. Un SGBD ofer urmtoarele faciliti pentru crearea i exploatarea bazelor de date: - faciliti de descriere a datelor, prin intermediul unui limbaj de descriere a datelor DDL (Data Description Language) care permite utilizatorului s descrie structurile de date ce vor fi memorate n baza de date; - faciliti de manipulare a datelor, prin intermediul unui limbaj de manipulare a datelor DML (Data Manipulation Language) care permite utilizatorului s insereze, actualizeze, tearg, s prelucreze i s extrag date din baza de date; - controlul accesului la baza de date prin intermediul unui limbaj de control DCL (Data Control Language) care asigur: sistem de securitate, previne accesarea bazei de date de ctre utilizatori neautorizai; - sistem de integritate, menine concordana datelor stocate n baza de date; - sistem de control al concurenei, permite accesul partajat la baza de date; - sistem de control al refacerii, permite recuperarea bazei de date n urma unor defeciuni hard sau soft; - mecanism de vizualizare, prin care un utilizator poate vedea acea parte a bazei de date care l intereseaz. n majoritatea produselor comerciale de baze de date , cele trei limbaje se regsesc reunite n cadrul unui singur limbaj (spre exemplu limbajul SQL). 5.1.3. Administratorul bazei de date Administratorul bazei de date referit prescurtat DBA (Data Base Administrator), este o persoan sau un grup de persoane care coordoneaz i rspunde de ansamblul activitilor privind baza de date, ncepnd din faza de proiectare i continund cu celelalte etape pe ntreaga perioad de via a bazei de date. Astfel, n faza de proiectare a bazei de date, administratorul stabilete SGBD-ul ce va fi utilizat, echipamentele necesare, structurile de date plecnd de la necesitile de informaie ale tuturor utilizatorilor bazei de date, drepturile de acces la date ale fiecrui utilizator. Rezultatul fazei de proiectare este concretizat prin elaborarea modelului conceptual (schema general a bazei de date), modelului extern (subschema proprie fiecrui utilizator) i stabilirea modalitilor de reprezentare a structurilor de date la nivel fizic pe suporturile de memorare externe utilizate. Drepturile de acces la baza de date pot fi definite [ORA92] fie pentru fiecare utilizator n parte, fie pentru grupuri de utilizatori (denumite Role), fiecare utilizator fiind apoi asignat unui grup. Dup proiectarea bazei de date,

76

administratorul va menine permanent legtura cu utilizatorii acesteia pentru rezolvarea cerinelor utilizatorilor i impunerea unei discipline n vederea alinierii la standardele existente. Administratorul va realiza, ori de cte ori se impune, reorganizarea structurii fizice a datelor n vederea optimizrii parametrilor de funcionare a ntregului sistem i va stabili proceduri de arhivare a datelor i proceduri de recuperare a bazei de date la avarii i defecte. Pentru a preveni accesul neautorizat la date, n cadrul sistemului de securitate pot fi prevzute [12] i alte mecanisme i anume: evidena de auditare, criptarea datelor. Evidena de auditare const dintr-un fiier n care sistemul nregistreaz automat toate operaiile efectuate asupra datelor, fiier ce va putea fi consultat de ctre persoane autorizate pentru a verifica efectuarea unor operaii neautorizate. O nregistrare din evidena de auditare va conine urmtoarele informaii: textul surs al operaiei neautorizate, terminalul de la care a fost lansat operaia, utilizatorul care a lansat operaia, data i ora operrii, obiectele bazei de date afectate, imaginile datelor afectate nainte de efectuarea operaiei, imaginile datelor afectate dup efectuarea operaiei. Pentru a preveni accesul unor intrui la baza de date, care ncearc s ocoleasc sistemul, se utilizeaz criptarea datelor, mecanism ce const n stocarea i transmiterea datelor pe cile de comunicaie sub form cifrat. Criptarea se realizeaz cu ajutorul unor algoritmi de criptare printre care cel mai recent este standardul american de criptare avansat AES (Advanced Encryption Standard). 5.1.4. Proiectarea securitii bazelor de date i a fiierelor Securitatea este abordat din mai multe puncte de vedere, dar cea referitoare la baze de date i la fiiere presupune luarea unor msuri pentru reconstituirea datelor pierdute sau preluate eronat, precum i pentru accesul neautorizat sau incomodarea pn la a face imposibil citirea datelor, prin criptare, atunci cnd ele sunt accesate ilegal. Aadar dou aspecte vor fi relevante: reconstituirea datelor i criptarea lor [5]. Reconstituirea datelor este des asociat cu existena fiierelor de tip back-up, ns n practic este posibil i reconstituirea fr apelarea la acest tip de fiiere. n vederea controlrii corectitudinii datelor tranzacionate se apeleaz la fiiere cu rol special, care conin un istoric, n ordine cronologic, al schimbrilor i accesrilor efectuate asupra fiierelor sau bazelor de date. Cu ajutorul lor se pot reconstitui fiierele distruse, dar i la verificarea corectitudinii operaiunilor de actualizare [5]. Securitatea prin criptografiere se refer la asigurarea transformrii datelor de comunicat ntr-o form neinteligibil pentru toi ceilali receptori, exceptndu-l pe cel autorizat. Criptarea a devenit una dintre cele mai puternice modaliti de asigurare a securitii datelor. Ea poate fi realizat prin sistemul de operare sau prin SGBD, dar i prin rutine create de ctre specialiti [5]. Avnd n vedere aspectele prezentate mai sus, criteriile avute n vedere n alegerea unui anumit tip de SGBD sunt [2]: a) Portabilitatea SGBD-ului. Prin aceasta nelegem posibilitatea de a utiliza un SGBD de pe un sistem de calcul pe un altul. Portabilitatea cuprinde dou aspecte i anume: portabilitatea programelor propriu-zise i portabilitatea datelor. Pentru realizarea unor programe portabile este necesar ca: programele s conin ct mai puine elemente legate de echipament;

77

Sisteme informatice Portabilitatea sistemului de gestiune privit prin prisma portabilitaii datelor se refer la posibilitatea de a folosi o serie de date utilizate n cadrul unui sistem informatic de ctre un alt sistem informatic, deci posibilitatea integrrii fiierelor deja existente n cadrul unui alt sistem. b) Costul sistemului. Acest criteriu trebuie privit prin prisma: timpului de ocupare a unitii centrale; costului de ntreinere i dezvoltare; resurselor hard imobilizate; costului de adaptare i trecere pe un nou sistem de calcul; costul documentaiei etc. c) Facilitile de implementare, ntreinere i exploatare a bazei de date. Acestea sunt reflectate prin: modalitatea de descriere a datelor; tehnicile de organizare i regsire a datelor, care s permit un acces ct mai rapid la orice informaie; timpul ct mai redus pentru actualizare, cutare i rspuns la cererile de informare; editarea operativ a celor mai variate tipuri de situaii solicitate de ctre utilizator; posibilitatea de inserie a unor programe de aplicaie, programe de validare de date, de actualizare, rutine statistice, rutine de sortare, rutine de prezentare grafic a ieirilor etc. d) Posibilitatea gestionarii structurilor complexe de date. e) Multitudinea metodelor de acces. In funcie de cerinele proprii aplicaiei, sistemul va trebui s suporte interogri sau actualizri n timp real avnd proceduri de tip conversaional. f) Protecia i securitatea datelor din baz. g) Specificul aplicaiei. Este cunoscut faptul c programele sunt orientate pe aplicaii, cum ar fi: programarea produciei, aprovizionare-desfacere, optimizri, prognoze etc. Toate aceste criterii de alegere pot fi corelate cu o serie de factori complementari cum ar fi: mentenana sistemului, facilitile ce le ofer administratorului bazei de date, calitatea documentaiei oferite de furnizori, asisten n implementarea sistemului i n pregtirea utilizatorilor etc. Toi aceti factori alturi de criteriile enunate pot s influeneze succesul n implementarea SGBD-ului i eficiena economic pe ansamblul sistemului informatic. n cele ce urmeaz se vor prezenta o serie de aspecte privind utilizarea limbajului SQL pentru crearea bazei de date, definirea utilizatorilor i acordarea drepturilor de acces, definirea interogrilor bazei de date, precum i exemple practice sub SGBD ORACLE. 5.1.5. Limbajul SQL - Crearea, Administrarea i Interogarea bazelor de date relaionale Limbajul SQL (Structured Query Language) a fost realizat n cadrul firmei IBM ca limbaj de interogare al SGBD System R i ulterior a devenit unul din cele mai rspndite limbaje pentru SGBD-urile relaionale. Limbajul SQL, ca limbaj de interogare a bazelor de date relaionale, este construit pe baza a dou formalisme abstracte enunate n cele ce urmeaz. 1. Algebra relaional prin care interogrile sunt exprimate prin aplicarea unor operatori unari sau binari care constituie primitive ce acioneaz asupra relaiilor, rezultatul interogrilor fiind tot relaii, ceea ce permite asocierea i imbricarea acestor

78

operatori pentru a forma interogri complexe. Operatorii algebrei relaionale se mpart n dou grupe i anume: - operaii pe mulimi (Reuniunea, Intersecia, Diferena, Produsul cartezian); - operatori relaionali speciali (Selecia, Proiecia, Cuplarea (JOIN), Diviziunea). 2. Calculul relaional prin care interogrile descriu mulimea tuplelor rezultat prin specificarea unui predicat (condiie) care trebuie satisfcut de aceste tuple. ncepnd din 1986 limbajul SQL a devenit standard ANSI pentru limbajele de interogare ale bazelor de date relaionale fiind utilizat att n cadrul unor SGBD-uri complexe cum ar fi SGBD ORACLE (liderul mondial n domeniul bazelor de date), ct i n cadrul unor SGBD-uri de complexitate redus cum ar fi cele din familia xBase (Dbase IV, FoxPro). Standardul SQL utilizat pn la nceputul anului 2000 este cel realizat n 1992 i cunoscut sub numele de SQL92 sau SQL2. Noul standard SQL3 lansat n 1999 are n vedere o serie de extensii fa de SQL2 dup cum urmeaz: - faciliti orientate obiect posibilitatea de definire de ctre utilizator a tipurilor abstracte de date care s permit descrierea de metode, identitatea obiectelor, subtipuri i motenire, polimorfism etc.; - structuri de control pentru a conferi limbajului completitudine de calcul (IF, FOR, WHILE, etc.) pentru a deveni un limbaj de sine stttor a crui putere de expresie s nu mai fie limitat la nivelul limbajelor relaionale; - faciliti pentru exprimarea prelucrrilor recursive; - faciliti de comunicare n reea; - faciliti de prelucrare distribuit (mecanisme pentru crearea, memorarea i execuia procedurilor la nivelul serverelor de date stored procedures); - faciliti multimedia; - faciliti pentru tratarea timpului n bazele de date. Comenzi pentru crearea/actualizarea schemei bazei de date Crearea unui utilizator se realizeaz cu comanda CREATE USER <nume utilizator> IDENTIFIED BY <parola> Adugarea relaiilor ntr-o baz de date comanda CREATE TABLE are sintaxa: CREATE TABLE <nume relaie>[(<nume atribut> <tip dat>,)] Exemplu -crearea tabelei Persoane n SQL Oracle se realizeaz cu comanda: CREATE TABLE Persoane (Nrcrt NUMBER UNIQUE NOT NULL,Nume CHAR(15),Prenume CHAR(15),Datan DATE,Sexul CHAR,Adresa VARCHAR2(50)); O nou relaie poate fi creat i ca rezultat al unei operaii de interogare astfel: CREATE TABLE <nume relaie> (<nume atribut> <tip dat>,) AS <subinterogare> Adugarea/modificarea de atribute pentru o relaie existent se realizeaz cu comanda: ALTER TABLE <nume relaie> ADD|MODIFY (< nume atribut> <tip dat>,) tergerea unei relaii se realizeaz cu comanda: DROP TABLE <nume relaie>

79

Sisteme informatice Comenzi pentru optimizarea interogrilor Una din principalele ci de optimizare a timpilor de interogare a unei baze de date este indexarea. Un index poate fi privit ca o relaie cu dou atribute i anume: - primul atribut conine valorile atributelor relaiei dup care se creaz indexul; - al doilea atribut conine un pointer (adresa) la locaia tuplelor corespunztoare. Crearea unui index se realizeaz cu comanda: CREATE [UNIQUE] INDEX <nume index> ON <nume relaie>(<nume atribut>[ASC|DESC],) Dac pentru atributele utilizate n clauza WHERE a unor instruciuni SQL au fost creai indeci, atunci acetia vor fi utilizai n vederea optimizrii timpului de prelucrare. Decizia de utilizare sau nu a unui index este luat de limbajul SQL i nu de utilizator. Pentru aceasta fiecare model de limbaj SQL dispune de o component numit optimizator, care examineaz interogarea i decide care este modul optim de obinere a rezultatului. O alt tehnic de optimizare a interogrilor este tehnica clustering disponibil n ORACLE i care const n gruparea tuplelor din mai multe relaii i stocarea lor n aceeai zon pe disc. Controlul datelor (comenzi DCL) - Vederi O vedere este o relaie virtual, definit plecnd de la alte relaii din baza de date i care nu conine date i deci nu ocup spaiu fizic pe disc. Vederile se definesc n dou scopuri i anume: - pentru a simplifica accesul utilizatorilor la date; - pentru a asigura protecia i securitatea datelor fiecrui utilizator fiindu-i permis acces la o poriune a bazei de date i putnd efectua doar anumite operaii (conform drepturilor de acces specificate cu comenzile GRANT/REVOKE). Asupra unei vederi se pot efectua aceleai operaii ca i asupra unei relaii cu deosebirea c vederile nu conin date i c orice modificri efectuate asupra datelor sunt reflectate i n vederi. Astfel, asupra unei vederi se pot realiza operaiile: - creare vedere (CREATE VIEW); - creare sinonim pentru vedere (CREATE SYNONIM); - tergere vedere (DROP VIEW); - interogare vedere (SELECT); - actualizare date din vedere (UPDATE); - tergere date din vedere (DELETE); - adugare date (INSERT). Crearea unei vederi se realizeaz cu comanda CREATE VIEW care are sintaxa: CREATE VIEW <nume vedere> [<lista atribute>] AS <fraza SELECT> [WITH CHECK OPTION] Exemplu: CREATE VIEW StocuriD1(Codp,Denp,Ump,Cant,Pret,Valoare) AS SELECT Stocuri.Codp, Denp,Ump,Cant,Pret,Cant*Pret FROM Produse,Stocuri WHERE Produse.codp=Stocuri.Codp AND CodDep = D1

80

Interogarea vederii se va realiza cu comanda SELECT * FROM StocuriD1 Utilizarea opiunii WITH CHECK OPTION asigur faptul c nici o tupl nu va fi adaugat sau actualizat cu instruciunile INSERT, UPDATE, dac nu sunt respectate condiiile specificate n clauza WHERE a instruciunii SELECT din definiia vederii. Pentru acordarea sau retragerea drepturilor de acces la baza de date prin intermediul vizualizrilor se vor folosi comenzi de forma: GRANT [ALL|SELECT|INSERT|UPDATE|DELETE] ON <nume vedere> TO <nume utilizator> sau REVOKE [ALL|SELECT|INSERT|UPDATE|DELETE] ON <nume vedere> FROM <nume utilizator> Asigurarea securitii datelor presupune definirea drepturilor de acces ale utilizatorilor i protecia sistemului la accesul neautorizat. n acest sens asigurarea securitii se realizeaz pe dou niveluri i anume: - nivelul 1 acordarea dreptului de acces la sistem; - nivelul 2 acordarea dreptului de acces la nivel de relaii. Pentru conectarea utilizatorilor la sistem n majoritatea versiunilor de SQL se utilizeaz un nume de utilizator i o parol. Referitor la drepturile de acces la nivel de relaie n sistemele multi-user trebuie precizat utilizatorul care a creat relaia (proprietarul relaiei). Fiecare utilizator are drepturi doar asupra propriilor relaii, iar drepturi asupra unor relaii create de ali utilizatori pot fi acordate prin comanda GRANT i pot fi retrase prin comanda REVOKE. Datele privind definirea bazei de date, utilizatorii i drepturile de acces sunt stocate n dicionarul de date i sunt gestionate de ctre sistemul de gestiune a bazei de date (SGBDR). n cele ce urmeaz se va prezenta modul de realizare a celor dou nivele de securitate n cadrul sistemului ORACLE. Nivelul 1 de securitate a datelor se realizeaz cu comanda: GRANT <autorizare,> TO <nume utilizator> [IDENTIFIED BY <parola>] unde <autorizare> poate fi: - DBA confer utilizatorului dreptul de efectuare a oricrei operaii asupra oricrei relaii din baza de date; - CONNECT confer utilizatorului dreptul de a a face interogri (SELECT) i actualizri (INSERT, UPDATE, DELETE) asupra relaiilor create de ali utilizatori, ns nu permite utilizatorului s creeze relaii (CREATE) sau s tearg relaii create de ali utilizatori (DROP); - RESOURCE confer utilizatorului drepturile ce rezult din autorizarea CONNECT i n plus dreptul de a crea relaii (CREATE) i de a terge relaii ce i aparin (DROP). Unui utilizator i pot fi acordate mai multe tipuri de autorizri n cadrul unei singure comenzi GRANT. Parola stabilit pentru un utilizator poate fi modificat printr-o comand GRANT ulterioar spre exemplu astfel:

81

Sisteme informatice GRANT RESOURCE TO <nume utilizator> IDENTIFIED BY <noua parol> Unui utilizator cruia i s-a acordat un tip de autorizare i pot fi acordate i alte tipuri de autorizare prin comenzi GRANT ulterioare. Retragerea autorizrilor acordate unui utilizator se realizeaz cu comanda: REVOKE <autorizare,> FROM <nume utilizator> Nivelul 2 de securitate a datelor Pentru acordarea respectiv retragerea drepturilor de acces la relaii se utilizeaz comenzile GRANT respectiv REVOKE cu urmtoarea sintax: GRANT ALL|<drept de acces>, ON <nume relaie> TO <nume utilizator>|PUBLIC [WITH GRANT OPTION] respectiv REVOKE ALL|<drept de acces>, ON <nume relaie> FROM <nume utilizator>|PUBLIC Privilegiile (drepturile de acces) pot fi acordate sau retrase de urmtoarele categorii de utilizatori: - utilizatorii cu nivel de autorizare DBA; - proprietarii relaiilor; - utilizatorii autorizai cu opiunea WITH GRANT OPTION. Prin specificarea PUBLIC acordarea respectiv retragerea drepturilor de acces se aplic tuturor utilizatorilor. Prin specificarea WITH GRANT OPTION, utilizatorul respectiv poate la rndul su s acorde aceleai drepturi sau mai puine altor utilizatori. n ORACLE pot fi acordate urmtoarele drepturi de access asupra relaiilor: SELECT, INSERT, DELETE, ALTER, UPDATE, CREATE,DROP pentru tabele i indeci. Drepturile de acces pot fi acordate asupra ntregii relaii, sau doar asupra anumitor atribute ale relaiei. Exemple: Acordarea tuturor drepturilor de acces utilizatorilor Ionescu, Popescu, asupra relaiei Persoane care aparine utilizatorului Vasilescu se realizeaz prin comanda: GRANT ALL ON Vasilescu.Persoane TO Ionescu,Popescu Acordarea tuturor utilizatorilor, drepturile SLECT,INSERT,UPDATE asupra relaiei Produse aparinnd utilizatorului Ionescu se realizeaz cu comanda: GRANT SELECT,INSERT,UPDATE ON Ionescu.Produse TO PUBLIC Acordarea privilegiilor SELECT,UPDATE numai asupra atributelor CodP, Denp din relaia Produse aparinnd utilizatorului Ionescu, utilizatorului Popescu cu condiia ca acesta la rndul su s poat acorda oricrui alt utilizator aceleai drepturi sau mai puine, se realizeaz cu comanda: GRANT SELECT,UPDATE ON Ionescu.Produse(CodProdus,Denumire) TO Popescu WITH GRANT OPTION Retragerea drepturilor de acces INSERT,DELETE asupra relaiei Persoane aparinnd utilizatorului Vasilescu, utilizatorului Ionescu se realizeaz cu comanda: REVOKE INSERT,DELETE ON Vasilescu.Persoane FROM Ionescu Instruciuni pentru inserarea i actualizarea datelor n tabele Inserarea datelor comanda INSERT are urmtoarea sintax:

82

INSERT INTO <nume relatie>|<nume vedere> [(<nume atribut>)] [VALUES] <lista valori>|<subinterogare> Exemple: Fie tabela Persoane(Nrcrt,Nume,Prenume, Datan, Sexul, Adresa) INSERT INTO Persoane VALUES (1,Ionescu,Ion,05/23/82,M,Suceava) (adaug o nregistrare n tabela Persoane completnd toate atributele) INSERT INTO Persoane(Nrcrt,Nume,Prenume) VALUES (2,Ionescu,Ana) (adaug o nregistrare n Persoane completnd numai atributele Nrcrt,Nume, Prenume) Pentru a insera n tabela PersF(Nrcrt,Nume,Prenume) toate nregistrrile din tabela Persoane pentru care Sexul=F se scrie comanda: INSERT INTO PersF(Nrcrt,Nume,Prenume) SELECT Nrcrt,Nume,Prenume FROM Persoane WHERE Sexul = F Actualizarea datelor comanda UPDATE are sintaxa: UPDATE <nume relaie>|<nume vedere> SET <nume atribut> = <expresie>,[WHERE <condiie>] Condiia din clauza WHERE definete tuplele care vor face obiectul actualizrii. Clauza WHERE poate conine i o subinterogare. Exemple: UPDATE Persoane SET Nume = Popescu, Prenume = Ana Maria WHERE Nume = Ionescu AND Prenume = Ana (actualizeaz numele i prenumele persoanei Ionescu Ana cu valorile Popescu respectiv Ana Maria). UPDATE Vanzari SET Pret = Pret*1.2 WHERE CodP IN (SELECT CodP FROM Facturi WHERE Numar = 120 AND Vanzari.Codc=Facturi.Codc ) (realizeaz majorarea preului cu 20% pentru produsele vndute cu factura 120). Dac n comanda UPDATE clauza WHERE este omis, actualizarea se va efectua asupra tuturor tuplelor relaiei. tergerea datelor comanda DELETE are sintaxa: DELETE FROM <nume relaie>|<nume vedere> [WHERE <condiie>] unde <condiie> poate fi o condiie simpl, o expresie sau o subinterogare. Exemple: DELETE FROM Stocuri WHERE Cant = 0 (terge toate nregistrrile din tabela Stocuri pentru care cmpul Cant are valoarea 0). DELETE Oferte (terge toate nregistrrile din tabela Oferte). Comenzi pentru gestiunea tranzaciilor Tranzacia este o succesiune de instruciuni SQL grupate ntr-un bloc de instruciuni utilizate pentru actualizarea i/sau interogarea datelor din baza de date. O tranzacie se consider ncheiat dup realizarea tuturor operaiilor pe care le conine. Operaiile coninute ntr-o tranzacie pot fi realizate efectiv n baza de date sau nu, fie automat de ctre sistem dup fiecare operaie, fie printr-o comand explicit dat dup o

83

Sisteme informatice succesiune de operaii. Astfel salvarea automat de ctre sistem a modificrilor este realizat prin comanda SET AUTOCOMMIT ON Dac iniial a fost specificat comanda SET AUTOCOMMIT OFF, salvarea modificrilor efectuate asupra datelor se realizeaz prin comanda COMMIT, iar abandonarea modificrilor se realizeaz prin comanda ROLLBACK. Blocul de operaii ce definesc o tranzacie poate fi delimitat de instruciunile : BEGIN TRANSACTION END TRANSACTION Problem rezolvat Se lanseaz n execuie SQL Plus Oracle sub utilizatorul system (figura 5.1). n baza de date ORCL sub S.G.B.D. Oracle se creaz utilizatorul U1 identificat prin parola PW1 i i se acord privilegiile CONNECT, RESOURCE (figura 5.2). Se nchide sesiunea de lucru SQL Plus a utilizatorului system (cu instruciunea EXIT) i se deschide o nou sesiune de lucru SQL Plus pentru utilizatorul U1 (figura 5.3). Se creaz tabela Produse i se insereaz dou nregistrri (figura 5.4).

ORCL

Figura 5.1. Lansare SQL Plus ORACLE pentru utilizatorul system

84

Figura 5.2. Creare utilizator U1 i acordare privilegii CONNECT, RESOURCE

85 OR

Figura 5.3. Lansare SQL Plus ORACLE pentru utilizatorul U1

Sisteme informatice

Figura 5.4. Creare tabel Produse i inserare dou nregistrri

Limbajul SQL - Interogarea bazelor de date - Fraza SELECT Interogarea bazelor de date n limbajul SQL se realizeaz cu ajutorul unei singure instruciuni i anume instruciunea SELECT avnd urmtoarea sintax: SELECT [DISTINCT] <lista atribute>|* FROM <lista relaii> [WHERE <condiie>] [GROUP BY <lista atribute de grupare>] [HAVING <condiie>] [ORDER BY <atribut1 de ordonare> [ASC]|DESC,] [UNION <fraz SELECT>] <lista atribute> este o list ce conine nume de atribute (cmpuri) sau expresii construite utiliznd atribute, separate prin caracterul , i care fac parte din relaiile (tabele, vederi) enumerate n <lista relaii> din clauza FROM. Numele fiecrui atribut sau expresii din <lista atribute> va fi afiat n capul de tabel ce reprezint rezultatul interogrii, fiecare atribut sau expresie putnd primi un alias folosind specificarea AS <alias>. Caracterul * specific faptul c se extrag toate atributele tabelei precizate n clauza FROM.

86

Clauza DISTINCT precizeaz faptul c n relaia rezultat nu pot aprea duplicate (tuple identice). Clauza WHERE precizeaz condiiile de interogare (condiii care trebuie s fie satisfcute de tuplele interogate, condiii de cuplare relaii (JOIN, relaii ntre tabele). n clauza WHERE pot fi utilizai operatori logici (AND, NOT, OR), predicate (IN, LIKE, BETWEEN, EXISTS, ALL, ANY), operatori aritmetici (+, -, **, /, *), operatori de comparare (=, #,<, >, <=, >=, <>), parantezele ( ) pentru schimbarea ordinii de prioritate a operaiilor, operatorilor, funcii i alte subinterogri SELECT, pentru construirea de expresii pe care trebuie s le ndeplineasc tuplele ce constituie rezultatul interogrii. Predicatul IN permite specificarea unei liste pentru domeniul de cutare pentru un atribut, iar predicatul BETWEEN permite specificarea unui interval pentru domeniul de cutare a valorilor unui atribut, fiind echivalent cu o condiie de forma: <atribut> >= <limita inf. interval> AND <atribut> <= <limita sup. interval> Exemple: Fie tabela Persoane(Nrcrt,Nume,Prenume, Datan, Sexul, Adresa) Selectarea tuturor nregistrrilor din tabela Persoane pentru care primele 7 caractere din cmpul Adresa sunt Suceava sau Rdui se realizeaz cu comanda: SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) IN (Suceava,Rdui) Interogarea de mai sus este echivalent cu interogarea: SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) = Suceava OR SUBSTR(Adresa,1,7) = Rdui Selectarea tuturor nregistrrilor din tabela Persoane pentru care data naterii este cuprins ntre 01/01/72 i 01/01/82 se realizeaz astfel: SELECT * FROM Persoane WHERE Datan BETWEEN {01/01/72} AND {01/01/82} Interogarea de mai sus este echivalent cu interogarea: SELECT * FROM Persoane WHERE Datan >= {01/01/72} AND Datan <= {01/01/82} Predicatul LIKE permite selecia irurilor de caractere care conin anumite caractere specificate prin intermediul unei mti definite cu ajutorul unor caractere speciale (%, _ n dBASE IV, FoxPro, ORACLE, sau *, ? n INFORMIX) Exemple: SELECT * FROM Persoane WHERE Nume LIKE %a (selecteaz toate nregistrrile din tabela Persoane pentru care valorile atributului Nume se termin cu litera a). SELECT Nume,Prenume,Datan FROM Persoane WHERE Nume LIKE A%u (selecteaz valorile atributelor Nume, Prenume, Datan pentru toate nregistrrile din tabela Persoane pentru care prima liter din Nume este A iar ultima liter este u). SELECT Nume FROM Persoane WHERE Nume LIKE _o%

87

Sisteme informatice (selecteaz valorile atributului Nume pentru toate nregistrrile din tabela Persoane pentru care prima liter din Nume este orice liter, a doua liter din Nume este litera o i ncepnd din poziia a treia numele poate conine orice litere.) Predicatele ALL, ANY, EXISTS se utilizeaz pentru interogri ce conin subinterogri, n vederea verificrii anumitor condiii ce trebuie ndeplinite ntre rezultatele interogrii i rezultatele subinterogrii. Clauza GROUP BY realizeaz gruparea tuplelor unei relaii pe baza valorilor unui atribut sau grup de atribute i genereaz o singur tupl pentru fiecare grup de tuple avnd aceeai valoare pentru atributele care definesc grupul. Atributele care definesc grupul trebuie obligatoriu s se regseasc n lista atributelor interogate <lista atribute>. De asemenea asupra unor atribute pot fi aplicate funcii agregat: - AVG(<atribut>) media valorilor atributului specificat ca parametru, pe grup; - SUM(<atribut>) suma valorilor atributului specificat ca parametru, pe grup; - MAX(<atribut>) maximum valorilor atributului specificat ca parametru, pe grup; - MIN(<atribut>) minimum valorilor atributului specificat ca parametru, pe grup; - COUNT(<atribut>) numrul nregistrrilor pe grupare dup <atribut>. Observaie. <atribut> poate fi fie un atribut, fie o expresie definit utiliznd atribute ale tabelei. Clauza HAVING, opiune a clauzei GROUP BY, este o form special a clauzei WHERE ntruct se aplic unor grupuri de tuple (i nu unor tuple) definite de clauza GROUP BY. Exemple: Fie tabela Stocuri(CodDep,CodP,UmP,Cant,Pret) SELECT CodDep,SUM(Cant*Pret) AS Valoare,COUNT(CodDep) AS Contor FROM Stocuri GROUP BY CodDep (Calculeaz suma produselor Cant*Pret pentru toate tuplele avnd aceeai valoare n cmpul CodDep i numrul nregistrrilor din fiecare grup definit de cmpul CodDep i afiseaz rezultatele sub form de tabel avnd coloanele CodDep, Valoare, Contor) SELECT CodDep,CodP,MAX(Pret) FROM Stocuri GROUP BY CodP HAVING MAX(Pret) < 150000 (selecteaz pentru fiecare grup de nregistrri avnd aceeai valoare n cmpul CodP, nregistrarea cu preul maxim mai mic dect 150000) CLAUZA ORDER BY PERMITE PRECIZAREA ORDINII DE AFIARE A DATELOR ASTFEL: ORDER BY <nume atribut 1> [ASC]|DESC,<nume 2>[ASC]|DESC, Exemplu: SELECT * FROM Persoane ORDER BY Datan DESC,Nume atribut

88

(afieaz toate nregistrrile din tabela Persoane n ordine descresctoare dup data naterii i n cadrul aceleiai date a naterii cresctor dup Nume) Clauza UNION permite obinerea rezultatului a dou sau mai multe interogri printr-o singur instruciune SELECT. Exemplu: SELECT CodDep,CodP,Cant FROM Stoc_Prod WHERE CodDep = Dep01 UNION SELECT CodDep,CodP,Cant FROM Stoc_Prod WHERE Cant >= 100 (selecteaz tuplele (CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate nregistrrile pentru care CodDep = Dep01, la care adaug tuplele (CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate nregistrrile pentru care Cant >= 100). Pentru a nu se elimina tuplele duplicat trebuie specificat UNION ALL. Pentru a schimba ordinea de afiare a tuplelor extrase se poate utiliza clauza ORDER BY aplicat doar relaiei finale i nu asupra fiecrei fraze SELECT. Regsirea datelor din dou sau mai multe relaii Interogarea datelor din dou sau mai multe tabele (relaii) presupune existena unor cmpuri comune pentru realizarea operaiei de cuplare (operatorul JOIN). n fraza SELECT operaia de cuplare este definit n clauza WHERE sub forma: <nume tabela1>.<cheie1> = <nume tabela2>.<cheie2> (unde <cheie1>, <cheie2> reprezint cmpurile ce identific nregistrrile corespondente n cele dou tabele). Pentru exemplificare pe lng tabela Stocuri mai considerm tabela Produse(CodP, DenP, DesP). SELECT Produse.CodP,DenP,UmP,Cant,Pret FROM Produse,Stocuri WHERE Produse.CodP = Stocuri.CodP (extrage toate tuplele (CodP,DenP,UmP,Cant,Pret) pentru care valoarea atributului CodP din tabela Produse este egal cu valoarea atributului CodP din tabela Stocuri ). n lipsa clauzei WHERE se vor extrage toate combinaiile posibile ntre tuplele celor dou tabele (produsul cartezian). Fiecrei tabele i se poate atribui un alias astfel nct fraza de mai sus este echivalent cu fraza: SELECT A.CodP,DenP,UmP,Cant,Pret FROM Produse A,Stocuri B WHERE A.CodP = B.CodP n anumite situaii poate fi necesar corelarea (cuplarea) unei relaii (tabele) cu ea nsi. Spre exemplu dac presupunem c n tabela Stocuri unele produse pot apare de mai multe ori cu preuri diferite i ne intereseaz poziiile cu preul minim, formulm urmtoarea interogare: SELECT A.CodP,A.Cant,A.Pret FROM Stocuri A WHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP = B.CodP) Pentru rezolvarea unor astfel de probleme s-au utilizat instruciuni SELECT imbricate care vor fi prezentate n detaliu n cele ce urmeaz.

89

Sisteme informatice Instruciuni SELECT imbricate Limbajul SQL ofer posibilitatea construirii unor interogri complexe prin includerea n clauza WHERE a unei instruciuni SELECT, a altei instruciuni SELECT (numit sub-interogare sau inner) astfel: SELECT <lista atribute> FROM <lista relaii> WHERE <condiie> (<sub-interogare>) La rndul ei sub-interogarea poate conine n clauza WHERE o alt instruciune SELECT obinnd astfel o interogare complex constituit din instruciuni SELECT imbricate pe un numr oarecare de nivele. Instruciunea SELECT interioar genereaz valori pentru condiia de cutare a instruciunii SELECT exterioare care o conine (numit i outer). O sub-interogare poate returna o singur valoare, sau poate returna mai multe valori. n ce privete ordinea de evaluare a interogrilor pot exista : - sub-interogri simple - n care interogarea interioar este evaluat prima, independent de interogarea exterioar, iar rezultatul interogrii interioare este utilizat de interogarea exterioar; - sub-interogri corelate - n care interogarea exterioar transmite repetat cte o valoare pentru interogarea interioar, care n baza valorii primite, parcurge tuplele relaiei i transmite interogrii exterioare rezultatul obinut. Astfel de interogri realizeaz corelarea unei relaii cu ea nsi i sunt cele mai performante. Spre exemplu dac presupunem c n tabela Stocuri unele produse pot apare de mai multe ori cu preuri diferite i ne intereseaz poziiile cu preul minim, formulm urmtoarea interogare: SELECT A.CodP,A.Cant,A.Pret FROM Stocuri A WHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP = B.CodP) Sub-interogri simple care returneaz o singur valoare - pot fi utilizate n interogri imbricate avnd sintaxa: SELECT <lista atribute> FROM <lista relaii> WHERE <atribut> = < > <= >= != (<sub-interogare>) [ORDER BY <atribut[ASC]|DESC,] Exemplu: SELECT CodDep,CodP,Cant FROM Stocuri WHERE Cant > (SELECT AVG(Cant) FROM Stocuri ) ORDER BY CodDep (afieaz produsele pentru care exist stocuri peste medie, ordonate pe depozite). Sub-interogari simple care returneaza mai multe valori pot fi utilizate n interogri imbricat care utilizeaz n clauza WHERE codiii care genereaz o mulime de valori folosind unul din predicatele: (NOT)IN, (NOT)ANY, (NOT)ALL, (NOT)EXISTS. Exemplu:

90

SELECT * FROM Produse WHERE CodP IN (SELECT CodP FROM Facturi WHERE Numar IN (SELECT Numar FROM Beneficiari,ComenziWHERE Beneficiari.Nume=Ionescu AND Beneficiari.Cod_Beneficiar=Comenzi.Cod_Beneficiar)) Predicatul ANY poate fi utilizat n combinaie cu oricare din operatorii <, >, =, <=, >=, != i permite verificarea dac valoarea unui atribut satisface condiia precizat pentru orice valoare din lista rezultat din subinterogare. SELECT CodP FROM Stocuri WHERE Cant > ANY (SELECT Cant FROM Stocuri WHERE CodDep = D1) Predicatul ALL returneaz toate tuplele pentru care valorile atributului din clauza WHERE sunt <, >, <=, >= dect toate valorile generate de interogarea interioar (acest predicat nu poate fi utilizat cu operatorul = ce ar corespunde cazului banal n care toate interogrile din list sunt egale). Exemplu: SELECT * FROM Stocuri WHERE Cant < ALL (SELECT Cant FROM Stocuri WHERE CodDep = D1) Predicatul EXISTS verific dac pentru fiecare tupl a relaiei exist tuple care satisfac condiia din interogarea interioar (deci EXISTS permite specificarea mai multor atribute n interogarea interioar). Astfel spre exemplu instruciunea: SELECT * FROM Produse A WHERE NOT EXISTS (SELECT * FROM Stocuri B WHERE B.CodP=A.CodP) va returna o list de produse care nu au nici o nregistrare n Stocuri. 5.2. Proiectarea programelor i a procedurilor Proiectantul de soft are ca principal misiune definirea i structurarea componentelor care vor forma un tot unitar, astfel nct prin acestea s se obin un proiect soft operaional. Proiectantul va grupa funciile ce trebuie s fie interconectate i va descrie modalitile de realizare a legturilor. Dup proiectanii de soft vor interveni programatorii, pentru transpunerea n realitate a proiectului. Ei vor controla intrrile, prelucrrile i ieirile din sistem prin intermediul programelor [5]. Softul are dou componente de baz instruciunile i modulele. Instruciunile sunt operaiuni elementare executate de calculator prin gruparea i selecia controlat a acestora pentru atingerea obiectivelor funciilor de prelucrare orientate pe probleme. Instruciunile constituie cel mai jos nivel al operaiunilor ce pot fi executate de ctre un limbaj de programare. Blocurile de instruciuni sunt astfel grupate nct s constituie anumite structuri executabile de calculator. De modul n care sunt grupate instruciunile pentru a da natere unor structuri standard ale programelor, de relaiile dintre instruciuni, de aranjamentul acestora depinde calitatea softului proiectat [5]. Modulul este o colecie sau o form grupat de instruciuni de programe surs. Modulele se pot grupa pentru a forma programele. Programul, n concepia diverilor autori, are semnificaii diferite. El este definit ca:

91

Sisteme informatice un set de instruciuni cu ajutorul crora se efectueaz prelucrri specifice; o entitate ce poate fi executat pe calculator; un mijloc de comunicare cu calculatorul pentru rezolvarea unor probleme; o descriere a unui algoritm i a datelor asociate n vederea execuiei pe calculator, deci o reprezentare a acestora (algoritmi i date) innd cont de restriciile impuse de calculator; - o realizare a unei funcii f care, dat fiind o mulime de date x, specific valoarea y=f(x); Prin algoritm se nelege o metod de soluionare a unei clase de probleme, reprezentat de o succesiune finit de operaii bine definite, numite instruciuni. Prin prisma complexitii lor programele se pot clasifica [5]: - programe simple (1000 de linii) - programe de complexitate medie(10 000 de linii) - programe complexe (peste 100 000 de linii) au numeroase module cu legturi complexe. Pentru ca programele s fie caracterizate prin eficien, fiabilitate, flexibilitate, inteligibilitate, n procesul elaborrii lor trebuie s se respecte anumite principii [5]: - principiul conformrii, potrivit cruia programele trebuie s fie elaborate n conformitate cu cerinele utilizatorului; - principiul completitudinii const n realizarea descrierilor complete ale obiectivelor programului pe toate nivelurile ierarhice de descompunere; - principiul abstractizrii se refer la elaborarea funciei programului, innd cont de elementele eseniale, fcndu-se abstracie de detaliile nesemnificative; - principiul modularizrii const n descompunerea programelor n subdiviziuni logice (module), care vor fi analizate n procesul de concepere i elaborare a programelor. n timp s-au conturat mai multe metode de programare, dei mai corect ar fi s se numeasc tehnici de programare [5]. Metoda programrii clasice are la baz construirea monolitic a logicii programului, fr intenii de structurare. Programul este privit n totalitatea lui i analizat direct la nivelul operaiilor elementare pe care le implic executarea lucrrii care se elaboreaz . Programarea modular const n descompunerea programului, chiar din faza de proiectare, n module uor de ntrebuinat. Fiecare modul este apoi analizat ca un program distinct i rezolvat ca atare [5]. Metoda programrii structurate const n faptul c ofer o rezolvare standardizat i structurat, n mod unitar, a programelor, reprezentnd o ridicare a activitii de programare la nivelul activitii industriale, fundamentat pe o metodologie tiinific. Programarea structurat este caracteristic dezvoltrii sistemelor pe baza diagramelor fluxului de date i utilizeaz limbaje structurate. Ea presupune o separare ntre structurile de date i codul funciilor care le prelucreaz. Metoda programrii orientate-obiect - const n abordarea natural a lumii reale, folosind componente modularizate i eliminnd restriciile impuse de mediul de programare. Se definesc concepte noi de tip, clas, motenire, etc [Udric M., 2000]. -

92

5.2.1. Atributele modulelor La nivelul softului proiectat, componenta de baz este modulul. El este o colecie sau o form grupat de instruciuni ale programului surs. La rndul lor, modulele se pot grupa pentru a forma programe. Modulele programelor au urmtoarele caracteristici [5]: - Un modul este format dintr-un grup de instruciuni care sunt contigue din punct de vedere fizic i sunt executate ca o unitate distinct; - Grupurile de instruciuni care formeaz un modul au nceputuri i sfrituri bine definite; - n majoritatea cazurilor, grupul de instruciuni are doar un punct de intrare i unul de ieire; - Un modul poate fi un program sau un subprogram distinct compilat sau o procedur intern a unui program. Un modul are trei componente de baz: funcia, logica i interfeele. Funcia unui modul const n transformarea datelor prin procesul de execuie a acestuia. Funcia este tratat n regimul cutiilor negre, ea fiind vzut la nivel de modul doar prin ceea ce se percepe n exteriorul lui, nu privindu-i componentele interne sau, altfel spus, rolul acestora. Interes prezint doar intrrile i ieirile modulului respectiv [5]. La nivelul softului, referirea la un modul este n acelai timp o referire la funcia lui. La nivelul cel mai de sus, modulele au funcii orientate spre problema de rezolvat, n timp ce modulele aflate pe nivelurile mai de jos au funcii orientate spre prelucrrile pe care le realizeaz [5]. n diagrama de structur, folosit pentru reprezentarea grafic a proiectelor soft, un modul este reprezentat printr-o caset (dreptunghi) ce poart denumirea funciei ndeplinite. La atribuirea numelui unui modul trebuie s se in cont de faptul c acesta trebuie s surprind att funcia proprie, ct i pe cele ale subcomponentelor de ordin inferior. Se recomand evitarea conjunciilor din structura numelor, deoarece ele ar sugera necesitatea folosirii mai multor module [5]. Logica modulului descrie prelucrrile care au loc n interiorul acestuia [5]. La nivelul programrii, preocuparea este, n esen, legat de logica modulului, algoritmii de prelucrare, redai sub diverse forme scheme logice, pseudocod, tabele de decizie, arbori de decizie sau combinaii ale acestora sunt concepui pentru prezentarea modului de transformare a intrrilor n ieiri. Paii algoritmilor se vor transforma n instruciuni ale limbajelor de programare [5]. Interfeele sunt conexiuni sau cuplaje ntre module. Interfeele modulelor sunt utilizate pentru stabilirea cilor prin care s se transfere controlul de la un modul la altul [5]. Conexiunile dintre module se nregistreaz pe dou planuri: - al transferrii controlului de la un modul la altul; - al transmiterii datelor de la un modul la altul.

93

Sisteme informatice n concluzie, se poate spune c eficiena proiectelor soft depinde n mare msur de eficiena cu care se transfer controlul ntre module, precum i de metoda folosit pentru transmiterea datelor ntre module. 5.2.2. Structurile de control ale programelor Proiectul soft trebuie s fie vzut din dou puncte de vedere: logic i fizic. Din punct de vedere logic, modalitatea n care intr n funciune modulele este redat prin structura ierarhic a lor [5]. Din punct de vedere fizic, dup ce s-a stabilit structura logic, se va pune problema adaptrii prelucrrii lor pe calculator, moment n care se va avea n vedere structura execuiei instruciunilor, adic a secvenelor dup care se declaneaz operaiunile din interiorul modulelor [5]. Structurile de control al logicii cunoscute i sub numele de structuri de control fundamentale, reprezint un set minim, dar i necesar, de reguli prin care s se controleze procesul de activare a componentelor de prelucrare dintr-un program sau ntre modulele acestuia. Structurile sunt: secvena, selecia, iteraia sau repetiia. Ele mai sunt cunoscute i sub numele de structur secvenial, alternativ (simpl i generalizat), repetitiv (condiionat anterior sau la nceput i condiionat posterior sau la sfrit ). Secvena asigur parcurgerea instruciunilor n ordinea n care apar. Selecia definete alegerea unui grup de instruciuni din dou sau mai multe posibile. Iteraia ofer posibilitatea execuiei repetate a unui grup de instruciuni [5]. n elaborarea programelor structurate este necesar s se respecte o serie de restricii, i anume [5]: - fiecare element (secvena, selecia, iteraia) are un punct de intrare; - fiecare element are un punct de ieire unic; - elementul de iteraie permite i o execuie cu factor de repetiie zero, adic excluderea elementului respectiv din execuie. Fiecare element din cele enunate (secvena, selecia, iteraia) care respect restriciile de mai sus definete un bloc standard. Structura secvenial (liniar) se prezint astfel [5]:

s1
s2

sn
Figura 5.1. Structura secvenial [5] Selecia (structura de tip IF-THEN-ELSE) sau structura alternativ are urmtoarea form de prezentare [5]:

94

NU

DA

Bloc - 2

Bloc - 1

Figura 5.2. Structura alternativ [5] Dac se ndeplinete condiia C, se execut operaiile din Bloc-1, altfel se execut operaiile din Bloc2; dup execuia blocului, se continu cu instruciunea urmtoare. Structura alternativ generalizat (de tip CASE-OF) este o generalizare a seleciei. Ea permite alegerea unei variante din mai multe posibile (figura 5.3).

Bloc - 1

Bloc - 2

Bloc - n

Figura 5.3. Structura alternativ generalizat [5] Iteraia sau structura repetitiv definete execuia repetat a unei operaii sau grup de operaii, funcie de rezultatul evalurii unei condiii. Evaluarea condiiei se face fie nainte, fie dup executarea operaiilor.Structura repetitiv condiionat anterior (de tip WHILE-DO) se reprezint ca n figura 5.4

Bloc - 1

C DA

95

NU

Sisteme informatice
Figura 5.4. Structura repetitiv condiionat anterior [5]

Structura repetitiv condiionat posterior (de tip DO UNTIL) are forma dinn figura 5.5.

Bloc - 1

C NU

DA

Figura 5.5. Structura condiionat posterior [5]

O form particular de structur repetitiv condiionat posterior este structura repetitiv cu numr definit de pai (de tip DO FOR). Numrul de repetiii este controlat de o variabil, numit variabil de control. n reprezentarea grafic urmtoare, V este variabila de control, Vi este valoarea iniial a variabilei de control, iar R este raia (incrementul). O astfel de structur este redat n figura 5.6.

V=Vi

Bloc - 1

V=Vi+R

V>Vf NU DA

Figura 5.6. Structura repetitiv cu numr definit de pai [5]

96

n literatura de specialitate, se consider c structura secvenial, structura alternativ de tip IF-THEN-ELSE i structura repetitiv condiionat anterior sunt suficiente pentru a defini structura de control a oricrui program. Din acest motiv, cele trei structuri de control, enumerate mai sus, sunt numite structuri fundamentale sau structuri de baz. 5.2.3. Proiectarea i realizarea programelor Ideea de baz n proiectarea programelor const n faptul c acesta trebuie s respecte ntocmai structurile diagramelor fluxurilor de date, prin nivelurile arhitecturale de tip program. Pentru proiectarea programelor, programatorii vor respecta sistemul de cerine i restricii impus de etapele parcurse anterior pentru realizarea sistemului informatic. Urmnd principiile programrii structurate, realizarea programelor se face n urmtoarele faze: definirea problemei de programat; descompunerea problemei de programat; realizarea modular a produselor program; testarea top-down a produselor program; definirea programului testat i a documentaiei aferente; dezvoltarea versiunii calitative a produsului program [2]. Specificaiile elaborate n etapele precedente permit definirea problemei de programat prin care se formuleaz elementele specifice i se analizeaz relaiile dintre aceste elemente, din punct de vedere dinamic sau static. Descompunerea aplicaiei se poate face dup criteriul funcionalitii, motiv pentru care elementele rezultate se mai numesc i module funcionale. Din punct de vedere al fluxului datelor pot fi [2]: - module de intrare, care manipuleaz datele de intrare; - modulele de ieire, care furnizeaz rezultate ale prelucrrilor; - module de prelucrare, care efectueaz diverse operaii asupra datelor. Pe baza unor funciuni identificate sau a altor raiuni de programare, modulele pot fi divizate n continuare. Scopul acestei structurri funcionale pn la nivel elementar este de a identifica funciunile sistemului i de a le separa, eventual, n funciuni generale i cu caracter specific aplicaiei. Modulele funcionale pot fi descompuse apoi dup criteriul omogenitii, rezultnd modulele operaionale. Realizarea modular a produselor program presupune urmtoarele aciunile [2]: - Examinarea modulelor i specificarea succesiunii operaiilor de prelucrare descrise n acestea. - Constituirea setului reprezentativ cu date test. Setul de date trebuie sa acopere ntreaga cazuistic a sistemului informaional i s testeze toate ramurile programului. - Precizarea elementelor de comunicaie ntre module, respectiv stabilirea parametrilor de intrare/iesire n/din fiecare modul. - elaborarea algoritmii de prelucrare specifici fiecrui modul i structura programelor. - transcrierea algoritmilor ntr-un limbaj de programare. - scrierea codului surs i obinerea fiierelor executabile.

97

Sisteme informatice Prin compararea rezultatelor propuse a fi obinute cu cele efectiv furnizate de aplicaia informatic, sunt verificate sintactic i funcional module din program. Dac se realizeaz identitatea ntre cele doua categorii de rezultate, operaia de testare se consider ncheiat. O atenie deosebit trebuie acordat ntocmirii documentaiei programului cu observaia c n acest sens este recomandat autodocumentarea la nivel de modul. 5.3. Proiectarea sistemelor distribuite Un sistem de prelucrare distribuit a datelor presupune existena a dou sau mai multor sisteme independente de prelucrare a datelor, numire noduri, interconectate ntr-o configuraie de reea. Ele folosesc faciliti de comunicare pentru schimbul de informaii i i coordoneaz activitile pentru realizarea unui anumit scop. Cu alte cuvinte un sistem de prelucrare distribuit a datelor permite realizarea activitii de prelucrare automat a datelor ntr-un mediu de reea. ntr-un astfel de mediu, coopereaz trei componente tehnologice distincte: prelucrarea datelor, comunicarea datelor i reeaua de calculatoare. Scopul lor este de a colabora fiecare cu fiecare, astfel nct s se realizeze obiectivele comune ale organizaiei [5].

Legtur/canal
NOD

NOD

Figura 5.7. Model de baz al unui sistem de prelucrare distribuit a datelor. Sistemele de prelucrare distribuit a datelor trebuie s permit: posibilitatea de prelucrare independent; o configuraie de reea; o posibilitate de transfer a datelor folosind faciliti de partajare a datelor; un obiectiv comun de realizat. La proiectarea unui sistem nou trebuie s se defineasc clar obiectivele pe care trebuie s le ndeplineasc noul sistem. Aceste obiective pot fi clasificate n financiare i funcionale. Din punct de vedere financiar se urmrete maxim de profit cu minimum de cheltuieli. Din punct de vedere funcional, scopul este s se realizeze un sistem care s aib cele mai bune rezultate [5]. Costul sistemului se regsete n costurile iniiale pe procesoare, perifericelor(imprimant, scanner, etc), cablri, soft-uri, i costuri funcionale (operaionale) cu distribuirea datelor, cu personalul, ntreinerea sistemului, etc. Performana sistemului este apreciat prin prisma productivitii i a eficienei lui. Ea se determin n funcie de cerinele operaionale ale unui sistem de calcul. Se consider c performana este o funcie a [5]: - timpului de rspuns(intervalul de timp dintre momentul formulrii unei cereri de la un terminal de comunicaie-date i obinerea rspunsului n acelai loc);

98

randamentului(cantitatea de date ce poate fi prelucrat de ctre un sistem de calcul ntr-o perioad de timp); - calitii serviciilor oferite utilizatorilor(siguran, fidelitate, integrare, control i acceptabilitate); - nivelul serviciilor. Sistemul propus trebuie s fie fezabil, din punct de vedere tehnic, i eficient, prin prisma costurilor prelucrrii automate a datelor i a comunicaiilor din sistem. Performanele sistemului sunt influenate de mai muli factori, cum ar fi timpul de rspuns, randamentul, disponibilitatea, sigurana(securitatea sistemului). La proiectarea sistemelor distribuite trebuie avute n vedere dou componente majore: - Proiectarea nodurilor; - Proiectarea reelei de comunicaii. Ordinea de proiectare nu este strict rmnnd la latitudinea echipei de proiectare. Trebuie s se in seama de posibilitatea proiectrii, dup ce anumite etape au fost ndeplinite [5]. -

Sisteme PAD

Proiectare NODURI

Proiectare subsisteme de COMUNICAII Proiectare INTERFEE

Figura 5.8. Principalele module de proiectare a sistemelor de prelucrare distribuit a datelor [5] Modele de sisteme distribuite Calculatoarele personale i staiile de lucru pot fi utilizate fie ca sisteme de-sinestttoare pentru execuia diferitelor aplicaii informatice, fie ntr-o configuraie de reea. O reea local se bazeaz pe un set de calculatoare personale, fiecare cu propria memorie, astfel nct s poat folosi n comun toate echipamentele i software-ul din reea. Dintre toate calculatoarele, exist unul sau unele mai puternice pe care se vor afla aplicaii folosite n comun de celelalte calculatoare ale reelei. Cea mai utilizat arhitectur este arhitectura client/server.

99

Sisteme informatice Arhitectura client/server Modelul Client /Server ofer date distribuite, portabilitate ntre platforme i un acces standardizat la resurse. Termenul de Client /Server provine de la metoda tradiional de accesare a unui computer central numit server de ctre computere aflate la distan sau clieni ntr-o infrastructur de reea. Modelul Client /Server implic o entitate software (clientul) care efectueaz cereri, acestea fiind ndeplinite de o alt entitate software(serverul) . Clientul este cel care transmite o cerere severului, acesta o interpreteaz i apoi o efectueaz. Pentru a putea ndeplini cererea, serverul poate referi o surs de informaie (baze de date), s efectueze procesri asupra datelor, s controleze periferice sau s efectueze cereri adiionale altor servere. Un client poate face cereri la multiple servere i un server poate deservi mai muli clieni. Surs de informaie (Baz de date) Procesare (Logic i Aritmetic) Server Dispozitive (Imprimant, periferice partajate) Servicii(Cereri adiionale altor servere)

Cerere Client Rezultatul ndeplinirii cererii

Figura 5.9. O tranzacie Client /Server Se poate afirma c tehnologia client / server mparte o aplicaie n trei componente de baz: un client, un server i o reea care conecteaz clientul la server. Att clientul ct i serverul sunt calculatoare cu grade variate de putere de calcul, ce colaboreaz la ndeplinirea sarcinilor. Calculatorul server este responsabil cu administrarea accesului la baza de date, precum i cu alte sarcini care-i revin direct serverului. Cnd se alege un server pentru mediul de lucru client / server trebuie avute n vedere: scalabilitatea posibilitatea de cretere a capacitii serverului, n limite rezonabile; tolerana la erori posibilitatea de recuperare a contextului calculatorului server dup producerea unei disfuncionaliti hardware; service i asisten tehnic. Calculatoarele server au utilizri variate n sistemele client / server (exist servere de fiiere care asigur spaiul de disc centralizat care poate fi folosit conform necesitilor calculatoarelor client din reea; servere de tiprire care colecteaz informaiile ce urmeaz a fi trimise ctre imprimant de ctre calculatoarele client i le asigur tiprirea ntr-o anumit ordine; servere de baze de date calculatoare care ruleaz un sistem de gestiune a bazelor de date (DBMS), bazat pe SQL; serverele de aplicaii calculatoare server care ruleaz programe mari de aplicaii). Sistemele client-server au aprut ca urmare a descentralizrii activitii din diverse domenii, ceea ce presupune o repartizare a realizrii sarcinilor pe cele dou nivele: client, server. De obicei clienii reprezint utilizatorii finali care vor comunica cu serverul bazei de date n cadrul unei reele de calculatoare. Dup rolul pe care l are fiecare din componentele client, server, se pot distinge trei arhitecturi de baz pentru un sistem client-server (Loomis 1992) i anume:

100

arhitectura de tip server de obiecte n care se distribuie prelucrarea ntre cele dou componente (server, client). Serverul este responsabil de administrarea memoriei i zvoarelor, efectuarea operaiilor n memoria secundar, securitatea, integritatea i recuperarea bazei de date, executarea procedurilor stocate i optimizarea interogrilor. Clientul este responsabil de administrarea tranzaciilor i realizarea interfeei cu limbajul de programare; arhitectura de tip server de pagini cea mai mare parte a prelucrrilor este realizat de ctre client. Serverul este responsabil de memoria secundar i furnizeaz paginile corespunztor cererilor formulate de client; arhitectura de tip server de baz de date cea mai mare parte din prelucrrile bazei de date este efectuat de ctre server. Clientul transmite cererea serverului, primete rezultatele i le transmite aplicaiei. Este modul utilizat frecvent de ctre sistemele relaionale. n fiecare dintre cele trei cazuri serverul se gsete pe aceeai main ca i baza de date fizic. Clientul se poate afla pe aceeai main sau pe una diferit. n cazul bazelor de date distribuite pe mai multe maini, clientul va comunica cu cte un server de pe fiecare main. De asemenea mai muli clieni pot comunica concomitent cu acelai server (accesul concurent). Arhitectura tradiional a sistemelor client-server este o arhitectur pe dou nivele (etaje), n care la primul nivel (clientul) se realizeaz interfaa cu utilizatorul i logica principal a aplicaiei, iar la al doilea nivel (serverul) se realizeaz validarea datelor i accesul la baza de date. Necesitatea rezolvrii unor probleme complexe care presupun accesul la baza de date a unui numr mare de utilizatori, utilizarea unor platforme hard-soft diferite, precum i integrarea bazelor de date n mediul Web, au impus definirea unei noi arhitecturi client-server n care sunt definite trei nivele i anume: - nivelul client, la care se realizeaz interfaa cu utilizatorul aplicaiei; - nivelul server de aplicaie, la care se realizeaz logica aplicaiei i prelucrrii datelor; - nivelul server de baze de date, la care se realizeaz validarea datelor i accesul la baza de date. Un server de aplicaie poate servi mai muli clieni, fiind conectat fizic att la nivelul client ct i la nivelul server de baze de date. Spre exemplu n mediul Web, clientul poate fi un browser Web, iar serverul de aplicaie poate fi un server Web.

Problem rezolvat Se consider baza de date FurnizoriClieni care conine urmtoarele tabele (n ACCESS): PRODUSE (catalog de produse)

101

Sisteme informatice Cmp Codp Denp Desp Semnificaie Cod produs Denumire produs Descriere produs Tip dat Number, Integer Text Hyperlink Dimensiune 4 20 Refer document corespunztor STOCURI (stocurile de produse pe depozite) Cmp Codp CodDep Ump Cant Pret Semnificaie Cod produs Cod depozit Tip dat Number, Integer Lookup Wizard Text Dimensiune 4 2 8 4 8 Creare i utilizare list de valori Observaii Lookup Wizard cu tabela PRODUSE Observaii Cheie primar

Unitate de Lookup Wizard msur produs Cantitate Pre unitar Number, Integer Number, LongInteger

FURNIZORI (catalog de furnizori) Cmp Codf Denf Adresaf Semnificaie Cod furnizor Denumire furnizor Adresa furnizor Tip dat Number, Integer Text Text Dimensiune 4 30 25 Observaii Cheie primar

102

CLIENTI (catalog de clieni) Cmp Codc Denc Adresac Semnificaie Cod client Denumire client Adresa client Tip dat Number, Integer Text Text Dimensiune 4 30 25 Observaii Cheie primar

OFERTE (oferte de produse de la furnizori) Cmp Codf Codp Ump Pret Datao Oferta Semnificaie Cod furnizor Cod produs Tip dat Number, Integer Lookup Wizard Number, Integer Lookup Wizard Dimensiune 4 4 8 8 8 Refer document corespunztor Observaii Lookup Wizard cu tabela FURNIZORI Lookup Wizard cu tabela PRODUSE Creare i utilizare list de valori

Unitate de Lookup Wizard msur produs Pre unitar Data ofertei Oferta furnizor Number, LongInteger Date Hyperlink

VANZARI (vnzrile de produse pe clieni) Cmp Codc Codp Semnificaie Cod furnizor Cod produs Tip dat Number, Integer Lookup Wizard Number, Integer Lookup Wizard Dimensiune 4 4 Observaii Lookup Wizard cu tabela CLIENTI Lookup Wizard cu tabela PRODU,03SE Creare i utilizare list de valori

Ump Cant Pret

Unitate de Lookup Wizard msur produs Cantitate Pre unitar Number, Integer Number, LongInteger

8 4 8

S se scrie comenzile SQL pentru realizarea interogrilor de mai jos:

103

Sisteme informatice a) Situaia stocurilor CodDep Cmp Stocuri Tabela b)Situaia ofertelor Codp Stocuri Denp Produse Ump Stocuri Cant Stocuri Pret Stocuri Valoare Cant*Pret Pret Oferte Datao Oferte

Denf Adresaf Codp Denp Ump Cmp Codf Tabela Furnizori Furnizori Furnizori Produse Produse Oferte c) Situaia vnzrilor

Denc Adresac Codp Denp Ump Cant Pret Valoare Datav Cmp Codc Produse Produse Vanzari Vanzari Vanzari Cant*Pret Vanzari Tabela Clienti Clienti Clienti d) Lista produselor pentru care nu exist oferte Cmp Tabela Codp Produse Denp Produse

e) Lista produselor pentru care nu s-au fcut vnzri n perioada [Data1,Data2] Cmp Tabela Codp Produse Denp Produse

Rspuns: a) SELECT CodDep, Stocuri.Codp, Denp, Ump, Cant, Pret, Cant*Pret AS Valoare FROM Stocuri, Produse WHERE Stocuri.Codp = Produse.Codp b) SELECT Oferte.Codf, Denf, Adresaf, Oferte.Codp, Denp, Ump, Pret, Datao FROM Oferte, Produse,Furnizori WHERE Oferte.Codp = Produse.Codp AND Oferte.Codf = Furizori.Codf c) SELECT Vanzari.Codc, Denc, Adresac, Vanzari.Codp, Denp, Ump,Cant, Pret, Cant*Pret AS Valoare, Datav FROM Vanzari, Produse,Clienti WHERE Vanzari.Codp = Produse.Codp AND Vanzari.Codc = Clienti.Codc d) SELECT * FROM Produse WHERE NOT EXISTS (SELECT * FROM Oferte WHERE Produse.Codp=Oferte.Codp) e) SELECT * FROM Produse WHERE NOT EXISTS (SELECT * FROM Vanzari WHERE Produse.Codp=Vanzari.Codp AND Datav BETWEEN Data1 AND Data2)

104

BIBLIOGRAFIE [1] - Botezatu C., Iacob I., Proiectarea sistemelor informatice. Studii de caz pentru managementul activitii unei societi, Editura Universul Juridic, 2005; [2] - Botezatu C., Proiectarea sistemelor informatice. Metode sistemice, Editura Sylvi, 2004; [3] - Botezatu C., Proiectarea sistemelor informatice. Ediie revizuit i completat, Editura Universul Juridic, 2005; [4] - Chichernea V., Botezatu C., Iacob I., Fabian C., Mihalca R., Goron S., Proiectarea sistemelor informatice. Metode de realizare, Editura Sylvi, Bucureti 2001, partea a-I-a, a-II-a, a-III-a; [5] - Chichernea V., Proiectarea sistemelor informatice orientat pe obiecte, Editura Prouniversitaria, 2005; [6] Chindea M. E., Proiectarea sistemelor informatice economice, Bucureti, 1999; [7] Cristescu M., - Baze de date utilizate n mediul economic, Editura ALMA MATER, Sibiu, 2007; [8] Cristescu M., - Baze de date post-relationale, Editura Universitii Lucian Blaga din Sibiu, Sibiu, 2008; [9] Morariu N., Lupu V., Hurjui O., - Baze de date, Editura Universitatii tefan cel Mare Suceava, 2003; [10] Oprea D. Analiza i proiectarea sistemelor informaionale economice, Editura POLIROM, Iai, 1999; [11] Stanciu V. Proiectarea sistemelor informatice de gestiune, Editura Cison, Bucureti 2000; [12] Connolly T., Begg C., Strachan A. Database Systems A Practical Approach to Design, Implementation and Management, Second Edition (traducere Editura Teora: Baze de date. Proiectare, implementare, gestionare), Bucuresti 2001; [13] Udric M. Modelarea orientat obiect, Editura Cison, Bucureti, 2000.

[14] - Zaharie D., Roca I., Proiectarea sistemelor informatice de gestiune, suport de curs, Editura A.S.E., Bucureti, 1999;

105