Inițierea și planificarea realizării unui sistem informatic………. [610589]
CUPRINS
Capitolul 1
Inițierea și planificarea realizării unui sistem informatic……………………….……………
1.1. Identificarea, selecția, inițierea și planificarea proiectelor..………………………….
1.2. Analizele de fezabilitate……… .…………. …………………………………….. … ..
1.3. Tehnici de reprezentare a planurilor și programarea calendaristică………………………..
Capitolul 2
Analiza sistemului existent și definirea cerințelor noului sistem……..………………………….
2.1. Studiul sistemului info rmațional existent………………………………………….….
2.2. Determinarea cerințelor sistemului ……………..……………………………………….
2.2.1. Metodele tradiționale utilizate în analiza și determinarea cerințelor
sistemului ..
2.2.2. Metode moderne de an aliză și determinare a cerințelor sistemului……………..
2.3. Structurarea cerințelor sistemului – modelarea logică a datelor și prelucrărilor………
2.3.1. Diagramele fluxurilor de date (DFD)… ………….. ……………………………
2.3.2. Descompunerea funcți onală și rafinarea DFD…………………………………..
2.3.3. Modelarea sistemului current…………………………………………………….
2.3.4. Modelarea logicii proceselor…………………………………………………….
2.4. Modelarea conceptuală a datelor (diagramele entitate – relație, DER).. ………………….
2.4.1 . Modelul Entitate/Relație (E/R)…………………………………………………………………..
2.5. Selectarea celei mai bune variante strategice de proiectare ……… …..……………..
Capitolul 3
Proiecta rea logică a sistemelor informatice…………………………………………………….. …………. ……………
3.1. Proiectarea formularelor/formatelor și a rapoartelor……………………………………….. …………. ….
3.1.1. Proiectarea situațiilor cu rezultate finale (rapoartelor)…………………….. …………. ……..
3.1.2. Proiectarea codurilor………… …………………….………………… ………. ….…….
3.1.3. Proiectarea intrărilor în sistemul informatic……………. ………………..…….… ………. ……
3.2. Proiectarea interfețelor și a dialogurilor ………….……………………..…………….……..
3.3. Proiectarea logică a bazelor de date………………….………………………… ……… ……
3.3.1. Normalizarea relațiilor – Forme normale …………… ………………………………………..
3.3.2. Simplificarea structurii datelor prin normalizare ………………………………..
3.3.3. Transformarea diagramelor entitate -relație în relații ……………………………
Capitolul 4
Proiectarea fizică a sistemel or informatice…………….…………. …………. …………………………………..
4.1. Proiectarea fizică a bazelor de date și a fișierelor…………………. ………….. ……………………………
4.1.1. Obiectivele fundamental e ale unei baze de date……………………………………………
4.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD)…..…………………………..
4.1.3. Administratorul bazei de date……………………………………………………
4.1.4. Proiectarea secur ității bazelor de date și a fișierelor……………………..……..
4.1.5. Limbajul SQL – crearea, administrarea, interogarea bazelor de date
relaționale.
4.2. Proiectarea programelor și a procedurilor……………………… ……….. ….…………………..
4.2.1. Atributele modulelor…………………………………………………. …………. …………………………….
4.2.2. Structurile de control ale programelor………………………………………………. …………. ……….
4.2.3. Proiectarea și realizarea
programelor………………………………………………….. ………………..
4.3. Proiectarea sistemelor distribuite………………………………………………………………. …………. …….
Capitolul 1
Inițierea și planificarea realizării unui sistem informatic
În cadrul acestui capitol vor fi prezentate o serie de aspecte privind primele
activități desfășurate în vederea realizării sistemelor informatice, activități definite în
literatura de specialitate sub numele de microanaliza sistemelor, componentă preluată din
managementul proiectelor și care are în vedere modalitățile de identificare a proiectelor
de dezvoltare a sistemelor informaționale, precum și modul în care au loc ini țierea și
planificarea acestora, în strânsă legătură cu planul strategic organizațional .
1.1. Identificarea, selecția, inițierea și planificarea proiectelor
Identificarea și selecția proiectelor de dezvoltare a sistemelor informaționale
reprezintă prima etapă din ciclul de viață a dezvoltării sistemelor care, împreună cu
inițierea și planificarea proiectelor, constituie microanaliza, componentă preluată din managementul proiectelor. Evidențierea acestor activități în cadrul modelului cascadă de
derulare a fazelor sau etapelor ciclului de viață a sistemului este reprezentată în figura 4.1
[1].
A.
identificarea
și selectarea
proiectului
B. inițierea și
planificarea
proiectului
C. analiza
D. proiectarea
logică
E. proiectarea
fizică
F. implementarea
G. întreținerea
Figura 2.1 Ciclul de viață al dezvoltării sistemelor [1] microanali
za Fazele ciclu lui de viață
al dezvoltării
sistemului
Din modelul prezentat rezultă că orice etapă se descompune în activități, ceea ce
pentru identificarea și selecția proiectelor înseamnă [1]:
– identificarea p otențialelor proiecte de dezvoltare;
– clasificarea și ierarhizarea lor;
– selecția.
Identificarea potențialelor proiecte de dezvoltare
Problema esențială a activității de identificare a potențialelor proiecte de dezvoltare
a sistemului constă în nominalizar ea celor ce pot fi abilitați să facă propuneri pertinente.
Aceștia pot fi: top -managerii, comitetul de inițiativă, departamentul utilizatorilor, grupul
de dezvoltare. Caracteristicile esențiale ale variantelor de proiecte propuse în cele patru situații sun t prezentate tabelul 2.1.
Tabel 2.1 -variante de proiecte [1]
Propuneri Metoda de selecție
a proiectului Caracteristicile proiectului
De sus în jos Top-managerii • orientare puternică spre strategie;
• cele mai mari dimensiuni ale proiectului;
• cele mai d e durată proiecte.
Comitetul de inițiativă • orientare mixtă (a diferiților reprezentanți);
• vizează schimbările organizaționale cele mai mari;
• analiză formală a costurilor și avantajelor proiectelor;
• proiecte mai mari și mai riscante.
De jos în sus Departamentul
utilizatorilor • limitat, neorientat strategic;
• realizare mai rapidă;
• câțiva utilizatori reprezintă niveluri ale conducerii, precum și funcțiile întreprinderii.
Grupul de dezvoltare • integrare în sistemul existent;
• puține întârzieri în realiz area proiectului;
• mai puțin interesat de analizele cost – avantaje.
Selecția proiectelor de dezvoltare a sistemelor informaționale
Datorită efectelor diferite și a amplitudinii lor, se recomandă evidențierea distinctă
a proiectelor pe termen lung și a celor pe termen scurt. Dintre ele se selectează cele ce
ating obiectivele organizației. De asemenea, se va urmări modul în care proiectele se
aliniază dinamicii unității.
Inițierea și planificarea proiectelor
Pentru realizarea acestei faze este nevoie de comunicarea efectivă dintre părțile
implicate( analiști, clienți – manageri, utilizator).
Inițierea proiectului
Din momentul selecției lui, proiectul trece în faza de inițiere, ceea ce presupune
desfășurarea unei activități laborioase, prestată de un responsabil, cunoscut în practică sub
numele de manager de proiect, care răspunde de [1]:
– Elaborarea unor studii de fezabilitate generală;
– Elaborarea planurilor detaliate ale proiectelor;
– Găsirea celor mai buni membri ai echipei proiectului.
Managerul de p roiect trebuie să dea dovadă de multe calități pentru a putea jongla
cu elemente cum sunt:
– Schimbările tehnologice;
– Ciclul de viață al sistemelor;
– Contractori și furnizori;
– Managementul resurselor umane;
– Metodologie și instrumente de lucru diferite;
– Restr icții de timp și resurse;
– Documentare și comunicare;
– Așteptările managerilor și clienților.
Activitățile efectuate în faza inițierii proiectului sunt:
1. stabilirea echipei de inițiere a proiectului;
2. stabilirea bunelor relații cu beneficiarii;
3. stabilirea pla nului inițierii proiectului;
4. stabilirea procedurilor manageriale;
5. stabilirea cadrului de desfășurare a proiectului și a manualului de operare al acestuia.
Planificarea proiectului
Planificarea proiectului va cuprinde o evaluare a cerințelor informaționale ale
sistemului la nivelul întregii organizații.
Planificarea proiectului este procesul prin care are loc definirea clară a activităților
și a eforturilor necesare înfăptuirii lor în cadrul fiecărui proiect.
Tipurile activităților executate în cadrul plani ficării proiectului cuprind [1]:
1. Descrierea ariei de întindere, a variantelor și fezabilității proiectului
2. Descompunerea proiectului în activități ușor executabile și controlabile
3. Estimarea resurselor și crearea unui plan al resurselor
4. Realizarea unei pr ime planificări calendaristice
5. Realizarea unui plan al comunicărilor
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
1.2. Analizele de fezabilitate
Elaborarea unui sistem informatic poate costa milioane de dolari și se poate realiza
pe parcursul a trei până la șase ani pentru a fi complet. Din aceste motive, este normal ca
factorii de conducere să demare ze proiectarea unui nou sistem după ce se efectuează
studii de fezabilitate.
Un studiu de fezabilitate are rolul de a asigura informațiile obiective necesare
pentru a cunoaște dacă un proiect poate fi demarat sau nu, sau dacă un proiect deja
început mai p oate fi continuat. Proporțiile și durata studiilor de fezabilitate variază, în
funcție de mărimea și natura sistemului implementat. În cazul sistemelor bazate pe
calculatoare mari, studiul are cu totul alte dimensiuni față de varianta utilizării
microcalcu latoarelor [1].
Totuși, fezabilitatea proiectului poate fi studiată în orice fază a elaborării lui, dar
studiile, de regulă, se efectuează în momente certe. Când este propus un proiect, se
efectuează un studiu preliminar de fezabilitate pentru a se stabil i dacă proiectul atinge
obiectivele propuse de unitate. Analiza, în prima ei fază, poate fi oricât de subiectivă,
întrucât proiectul nu este reprezentat cu lux de amănunte. Însă, îndată ce se obține o
situație mai clară despre sistem, despre natura problem ei de rezolvat, precum și despre
doleanțele utilizatorilor, măsurarea preliminară a fezabilității poate fi determinată odată
cu faza de analiză a sistemului. Când proiectanții 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 proiectării, implementării și exploatării. Este ultima șansă a unităților de a mai putea renunța la sistem, înaintea implementării lui.
Pe parcurs, odată cu progresul înregistrat în dezvoltarea sistemului informatic, se
obțin informații din ce în ce mai certe, oferindu -se posibilitatea unor analize de
fezabilitate mult mai concludente, ceea ce atrage studierea fezabilității în diverse faze ale
ciclului de viață al sistemelor. De fiecare dată, studiile de fezabilitate trebuie să aibă la
bază o foarte bună documentație. Aceasta va conține [1]:
– Definirea problemei ( o scurtă descriere a proiectului și explicarea a ceea ce-și propune el să realizeze);
– Descrierea cerințelor sistemului;
– Descrierea soluțiilor sistemului propus;
– Explicația critică a motivării studiului întreprins;
– Cuantificarea tuturor costurilor materiale și beneficiilor aferente;
– O listă a costur ilor și beneficiilor necuantificabile.
1.3. Tehnici de reprezentare a planurilor și programarea calendaristică
Managerul proiectului dispune de o mare varietate de tehnici pentru reprezentarea
și descrierea planurilor proiectelor.
Documentația planificăr ii poate fi alcătuită 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 activitățile planificate. Lungimea barelor este
proporțională cu timpul alocat activităților reprezentate. Se pot folosi diferite culori,
umbre sau forme pentru a scoate în relief anumite activități. Ceea ce s-a planificat și
realizat, de asemenea, pot fi evidențiate prin bare paralele de culori, forme sau umbre
diferite.
Diagramele Gantt nu indică ordinea activităților (precedența lor), ci indică data
începerii și pe cea a finalizării.
Se recomandă pentru descrierea proiectelor simple sau a unor componente ale
proiectelor mari, sau a activităților prestate doar de o singură persoană, precum și pentru monitorizarea modului în care se efectuează activitățile în comparație cu cele planificate
(ca dată) .
Evidența promovării vânzărilor (EPV)
Nr.
Crt. Nume activitate Aprilie
2005 Mai 2005 Iunie
2005 Iulie
2005 August
2005 Septem –
brie
2005
1. Colectarea
cerințelor
2. Proiectare
ecrane
3. Proiectare
rapoarte
4. Proiectare baze
de date
5. Documentație
utilizator
6. Programare
7. Testare
8. Instalare
9. Ședința de
analiză
Proiect: EPV
Data:
Analist: Critic: În lucru: Sinteză:
Necritic: Punct de reper: Derulat:
Figura 2.2. Diagrama Gantt pentru descrierea planului proiectului [1]
Capitolul 2
Analiza sistemului existent și definirea cerințelor noului sistem
În cadrul acestui capitol este prezentată prima etapă a ci clului de viață al
sistemelor informatice, etapă prin care se determină modul în care funcționează sistemul
informațional curent și se evaluează ceea ce ar dori utilizatorii să realizeze noul system
.Astfel, sunt prezentate o serie de aspecte privind:
– determinarea cerințelor sistemului;
– metodele tradiționale utilizate în analiza și determinarea cerințelor sistemulu (interviul și chestionarul);
– metode moderne de analiză și determinare a cerințelor sistemului (JAD,
prototipizarea);
– structurarea cerințelor sis temului – modelarea logică a datelor și prelucrărilor
(diagramele fluxurilor de date DFD);
– modelarea conceptuală a datelor (diagramele entitate – relație, DER).
2.1. Studiul sistemului informațional existent
Prin sistem existent se înțelege realitatea obi ectivă din organizația pentru care
urmează a se realiza sistemul informatic solicitat printr -o comandă numită cererea
beneficiarului.
Analiza sistemului existent și definirea cerințelor noului sistem este prima etapă
din ciclul de viață al dezvoltării sis temelor informatice, etapă prin care se determină
modul în care funcționează sistemul informațional curent și se evaluează ceea ce ar dori
utilizatorii să realizeze noul sistem. Studiul și analiza sistemului existent are ca obiectiv
principal stabilirea ce rințelor informaționale ale conducerii în vederea realizării unui
sistem informatic.
Studiul sistemului existent cuprinde un grup de activități care urmăresc
cunoașterea performantelor tehnico -funcționale ale sistemului informațional, atât în
ansamblul său, cât și pentru elementele de structura ale acestuia, a cerințelor informaționale ale conducerii, cunoașterea lipsurilor și restricțiilor pe care le prezintă
sistemul existent față de aceste cerințe. De modul de realizare a acestor activități depinde
întregul proces de realizare a sistemului informatic [2].
Studiul sistemului existent constă în [2]:
– definirea caracteristicilor generale ale sistemului economic;
– studiul activităților de bază desfășurate în sistem;
– studiul sistemului de conducere;
– studiul sistemului informațional;
– identificarea metodelor și mijloacelor tehnice.
Definirea caracteristicilor generale ale sistemului economic implică :
– cunoașterea profilului, obiectivelor agentului economic;
– cunoașterea locului în sfera serviciilor si sfera producției;
– cunoașterea relațiilor de cooperare cu alți agenți economici;
– cunoașterea specificului activității de bază ( producție, servicii);
– cunoașterea nivelului tehnic;
– cunoașterea principalilor indicatori economici și evoluția lor;
– dezvoltarea, m odernizarea etc.
Studiul activităților desfășurate în sistemul economic , modul de realizare a
funcțiunilor unității economice se face prin [2]:
1. Pe baza statutului de funcționare a societății se studiază:
– activitățile și sarcinile din cadrul acestor f uncțiuni;
– atribuțiile ce revin compartimentelor;
– modul de realizare a activităților funcționale din cadrul unității economice.
2, În cazul activității de producție se prezintă:
– fluxul de producție, amplasarea locurilor de muncă, depozitelor etc.;
– tipurile de produse, structura lor, ciclurile de realizare;
– modul de organizare a producției, stocarea producției, transporturile interne,
controlul de calitate;
– resursele existente:
– capacități;
– asigurarea tehnică / proiectarea de produse noi;
– norme tehnice;
– asigur area cu materiale necesare;
– sistemul existent de programare a producției.
Studiul sistemului de conducere se referă la [2]:
– identificarea caracteristicilor sistemului de conducere existent;
– sistemul de indicatori cantitativi și valorici;
– organizarea co nducerii;
– caracteristicile rezultate din statutul de funcționare a societății, tipuri de decizii,
modul de lucru a deciziilor.
Studiul sistemului informațional presupune [2]:
– elaborarea schemei fluxului informațional global (cu punerea în evidență a
principalelor activități și a legăturilor statice și dinamice dintre acestea);
– estimarea cantitativă și calitativă a informațiilor de intrare -ieșire, modul de
culegere și prelucrare;
– identificarea principalilor algoritmi, regulilor de calcul și a punctelor si regulilor
de control;
– cunoașterea principalelor restricții ale sistemului informațional;
– situația raționalizării fluxurilor și a documentelor din unitatea economica, studii
elaborate, stadiul lor de implementare;
– sistemul de codificare utilizat, res tricții;
– performanțele și limitele sistemului informațional existent.
Identificarea metodelor și mijloacelor tehnice utilizate pentru prelucrarea datelor în
cadrul sistemului informațional existent se face evidențiind: mijloacele tehnice existente
în dot area unității economice ( modul de utilizare, cheltuielile de exploatare, personalul
implicat, performante); existența unor aplicații proiectate și/sau implementate [2].
2.2. Determinarea cerințelor sistemului
Determinarea cerințelor sistemului este act ivitate esențială în aflarea situației
existente și a ceea ce se dorește în viitor. Rezultatul activității de determinare a cerințelor
sistemului se concretizează în diferite forme ale informațiilor colectate, cum sunt copii ale
interviurilor, însemnări ef ectuate în timpul observării și analizei documentelor,
interpretări ale răspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale posturilor de lucru ș.a., precum și rezultate ale prelucrărilor efectuate de calculator, cum
ar fi prototipur ile [1].
Rezultatele prezentate după această activitate pot fi rezumate astfel:
1. Informații obținute în urma conversațiilor cu utilizatorii sau prin observarea
activităților prestate de aceștia: copii sau sinteze ale interviurilor, răspunsurile la
chestionare sau interpretări ale acestora, însemnări și rezultate din observarea
activităților, procese verbale ale ședințelor ce au avut loc în acest scop;
2. Informații scrise care există în unitate: misiunea și strategia afacerii, exemplare ale formularelor, rapoar telor și machetelor de ecrane, manuale ale procedurilor,
descrieri ale posturilor de lucru, manuale de instruire, scheme de sisteme și
documentația sistemului existent, rapoartele consultanților [1];
3. Informații obținute cu ajutorul calculatorului : rezultate ale sesiunilor JAD, copii
ale fișierelor sesiunilor grupului de sprijinire a sistemului, conținutul depozitelor
și rapoartele existente în CASE, ecrane și rapoarte rezultate din prototipurile
sistemului, ș.a [1].
2.2.1. Metodele tradiționale utilizate în analiza și determinarea cerințelor sistemului
Analiza sistemului informațional-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 răspândită pentru culegerea informațiilor din
sistemul informațional. Utilizatorii acestei metode sunt în general analiștii care nu sunt
familiarizați cu unitatea studiată și cu problemele ei. Prezintă avantajul că lasă foarte
multă libertate creativa analistului în construirea și desfășurarea lui [2]. În alegerea
persoanelor de intervievat trebuie avute în vedere următoarele constatări [10]:
– persoanele care ocupă poziții medii în ierarhia structurii organizatorice furnizează
informațiile cele mai apropiate de realitate;
– colectarea de informații corecte necesită intervievarea atât a personalului de
conducere, cât și a celui de execuție;
– în prealabil trebuie verificată comp etența subiecților intervievați;
– lipsa unei atitudini critice poate să denote rețineri î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 către
persoanele intervievate.
Chestionarul poate fi utilizat atât de către analiștii începători, cât și de către cei
avansați, familiarizați sau nu cu problemele informaționale -decizionale ale unității. Prin
utilizarea lui dispare “filtrul de informații” care este analistul iar cel care furnizează
informații are posibilitatea să se concentreze mai bine asupra răspunsurilor. Utilizând
această metodă, participă un număr mare de “furnizori de informații”. Limitele
chestionarul ui constau în faptul că este o metodă de verificare a unor cunoștințe
prealabile, fapt ce implică cunoașterea prealabilă a domeniului.
Această metodă necesită timp relativ îndelungat pentru întocmirea chestionarului
precum și de culegere și prelucrare a răspunsurilor. Chestionarul nu are o arie largă de
utilizare [2].
2.2.2. Metode moderne de analiză și determinare a cerințelor sistemului
Ca efect al tendințelor de mărire a timpului de analiză a sistemelor existente, în
ultimii ani, s -a efectuat trecerea spre analiza mai puțin pronunțată a sistemelor ce urmează
a se realiza. Tehnicile moderne, JAD și prototipizarea, preiau tot mai puține 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 [1].
Joint Application Design(JAD)
Spre sfârșitul anilor 1970, specialiștii în realizarea de sisteme de la IBM au elaborat
un nou proces de culegere a cerințelor informaționale ale sistemelor și de revizuire a
proiectelor sistemelor, numindu -se JAD [1].
Ideea principală a lui JAD o constituie punerea laolaltă a tuturor forțelor interesate
în dezvoltarea sistemelor: utilizator i-cheie, managerii și analiștii de sistem implicați în
analiza sistemului curent. Din acest punct de vedere JAD este similar interviului la nivel
de grup. Totuși în sesiunea JAD se urmărește o anumită secvență de derulare a
activităților, pe baza unor rolu ri bine stabilite.
Prototipizarea și determinarea cerințelor sistemelor
Prototipizarea este un proces interactiv prin care analiștii și utilizatorii pun în
discuție o versiune rudimentară a unui sistem informațional, care va fi într -o continuă
schimbare, î n funcție de reacția utilizatorilor. Prototipizarea renunță la ciclul de viață al
dezvoltării sistemelor sau la creșterea rolului său [1].
Pentru culegerea informațiilor despre cerințele utilizatorilor încă se apelează la
interviuri, dar prin prototipizar e, operațiunea va fi mai simplă și va solicita un timp mai
scurt. Prototipul este văzut și testat de utilizator, având posibilitatea să precizeze ce ar mai dori, dar și să -și genereze această formă nouă, cu ajutorul specialiștilor [1].
Prototipizarea este facilitată de câteva limbaje sau produse program, inclusiv
instrumentele de tip CASE.
Prototipizarea este foarte utilă în determinarea cerințelor sistemului când [1]:
– cerințele utilizatorului nu sunt prea clar formulate sau bine înțelese;
– unul sau mai mu lți utilizatori sau susținători sunt implicați în sistem;
– anumite mijloace de lucru (formulare și rapoarte predefinite).
Prototipizarea generează și deficiențe, cum ar fi:
– tendința de evitare a unui cadru formal de elaborare a documentației privind cerințe le
sistemului, ceea ce va îngreuna în viitor orice control;
– fiind conceput de un număr mic de utilizatori va fi probabil respins de viitorii
utilizatori;
– fiind conceput izolat este puțin probabil ca el să fie integrat în sistemul existent;
– nerespectându -se etapele ciclului de viață al dezvoltării sistemelor pot fi omise
aspecte esențiale, cum ar fi securitatea, controlul datelor introduse și standardizarea la
nivel de sistem.
Pașii prototipizării sunt [1] :
– Identificarea cerințelor principale ale sistemulu i;
– Realizarea prototipului inițial;
– Proces iterativ de adaptare a sistemului la cerințele utilizatorului;
– Folosirea sistemului aprobat de utilizatori.
După determinarea cerințelor sistemului urmează structurarea acestora prin
utilizarea unor instrumente s pecifice de modelare logică.
2.3. Structurarea cerințelor sistemului – modelarea logică a datelor și prelucrărilor
Indiferent de metodologiile folosite în realizarea unui sistem/aplicație, toate
apelează la operațiunea de modelare logică a datelor și pre lucrărilor sub formă de
diagrame, diferențele constând doar în folosirea mai pronunțată a diagramelor pentru
descrierea sistemului, încadrându -le în diagrame de context, diagrame ale fluxurilor de
date fizice și diagrame ale fluxului de date logice. Altele apelează la combinații de
diagrame, tabele și forme descriptive [1].
Diagrama de context scoate în evidență aria de întindere a sistemului analizat, prin
specificarea elementelor din interiorul organizației și a celor externe, sub denumirea de
entități e xterne sistemului analizat.
2.3.1. Diagramele fluxurilor de date (DFD)
Diagrama fluxului de date ale nivelului logic curent, independentă de tehnologie,
reliefează funcțiile de prelucrare a datelor executate de către sistemul informațional
curent.
Diagram a de flux de date ale sistemului logic nou va prezenta circuitul datelor,
structura lor și cerințele funcționale ale noului sistem.
Descrieri ale obiectelor DFD se regăsesc în așa- zisele dicționare ale proiectelor sau
depozitele CASE (repository) [1].
Diagramele fluxului de date DFD au ca obiectiv urmărirea modului de transfer al
datelor între procesele de prelucrare a lor, astfel de diagrame se mai numesc și modele ale
proceselor de prelucrare, iar operațiunea se numește modelarea proceselor.
DFD reprezin tă doar una din tehnicile de analiză structurată.
Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor
fluxurilor de date a căpătat noi accepțiuni prin încorporarea ei în instrumentele de analiză
și proiectare cu ajutorul calculatorulu i, adică în instrumente CASE [1].
Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru
construirea DFD
Când analizăm sistemele folosim frecvent reprezentările grafice, de exemplu
diagramele. În continuare vom folosi tehnic a reprezentării grafice a fluxului
informațional. Proiectarea fluxului informațional reprezintă circulația informației în
sistem, transformările suferite de acesta, stocarea informației precum și scurgerile de
informație în afara sistemului.
Scopul diagram elor de date DFD pentru o anumită componentă organizatorică sau
funcțională la care se referă (secție, birou, compartiment, întreaga unitate, o anumită
activitate – vânzări, cumpărări, încasări, plăți, ș.a) este de a scoate în relief, într -o manieră
cât mai sugestivă, următoarele aspecte [1]:
– sursa datelor de prelucrare;
– operațiunile de prelucrare prin care trec datele;
– destinația datelor prelucrate;
– legătura existentă între prelucrări și activitatea de stocare a datelor.
Întocmirea diagramelor de flux de date (DFD)
DFD este o reprezentare grafică a transformării datelor de intrare în date de ieșire
folosind un set de simboluri de reprezentare și un set de reguli de completare și validare.
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 număr(descriere
a funcției procesului de prelucrare, începând cu un verb, urmat de o descriere
a obiectului funcției de prelucra re). În DFD fizică pentru sistemul existent, se
va preciza și locația (compartiment / persoană) procesului.
flux de date: este constituit din datele transmise între două procese.
Fluxul de date este etichetat printr -un substantiv ce sugerează informaț ia sau
pachetul de informații transmise.
entitate externă (terminator): sursă / receptor de date. Poate fi un alt
sistem (organizație, compartiment).
stoc de date: un depozit temporar sau permanent de date.
Poate fi:
– manual: registre, dosare, a rhivă de documente
– pe suport magnetic: fișiere.
Convenții folosite în diagramele de reprezentare a DFD:
– procesele și stocurile de date sunt numerotate secvențial, pentru a putea fi
identificate. Numerele asociate proceselor nu semnifică ordinea de execuție a
acestora;
– pentru a evita fluxurile de date întretăiate și aspectul de “păienjeniș” al diagramei, entitățile 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 stângă a cutiei;
– pentru a face diagramele mai lizibile, entitățile externe sunt plasate, pe cât
posibil, în jurul diagramei iar stocurile de date, în partea centrală a diagramei;
– fluxurile de date de la – către stocurile de date sunt unidirecționale (fie de
adăugare, fie de consultare) si nu sunt etichetate.
2.3.2. Descompunerea funcțională și rafinarea DFD
Dacă sistemul pe care-l descriem cu ajutorul DFD este complex, va fi dificil să
realizăm de la început o DFD detaliată. Pentru a putea descrie în detaliu sistemele
complexe, metodele structurate propun o abordare TOP -DOWN, respectiv o
descompunere funcțională a sistemului, care este realizată prin rafinarea succesivă a
proceselor.
Primul nivel (n ivelul 0) îl constituie DIAGRAMA CONTEXTUALĂ, care
definește granițele între sistemul analizat si mediu.
Nivelele următoare se obțin prin rafinarea proceselor complexe într -o diagramă de
nivel inferior.
În cazul aplicației Decontări , au rezultat următoar ele diagrame:
Figura 3.1. Diagrama contextuală pentru aplicația Decontări
Figura 3.2. Diagrama fluxului de date de nivel 1 pentru aplicația Decontări
Figura 3.3. Diagrama fluxului de date de nivel 2 pentru aplicația Decontări
Definirea direcțiilor de perfecționare a actualului sistem
Pe baza activităților de evaluare și analiză critică se identifică neajunsurile
actualului sistem și se propun soluții de înlăturare a acestora se formulează variante de
soluții, iar în cadrul acestora se definesc cerinț ele și restricțiile de realizare a sistemului
informatic.
Definirea direcțiilor de perfecționare presupune:
1. specificarea obiectivelor și a performantelor sistemului informatic;
2. stabilirea domeniilor de probleme și a principalelor funcțiuni ale sistemului
informatic;
3. definirea cerințelor si restricțiilor informaționale pe domenii de probleme și funcțiuni
care constă în:
– definirea principalelor intrări/ ieșiri;
– definirea soluției de organizare a datelor;
– definirea variantelor tehnologice de prelucrare;
– definirea restricțiilor informaționale și de control.
4. formularea condițiilor pentru realizarea sistemului informatic, care constă în:
– specificarea termenelor și duratelor solicitate;
– precizarea priorităților în realizarea obiectivelor sistemului inform atic;
– specificarea cerințelor speciale privind flexibilitatea, compatibilitatea cu
alte sisteme, gradul de generalizare al sistemului.
Pentru fiecare variantă de soluție informatică se procedează la:
– evaluarea resurselor necesare (costurile de sistem);
– evaluarea efectelor economice directe si indirecte;
– calculul indicatorilor de eficientă economică.
2.3.3. Modelarea sistemului curent
Indiferent de tipul sistemului analizat, manual sau informatizat, o problemă este
comună: el va fi înlocuit de un nou s istem. Oricât 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, d ar 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ă conțină una sau mai multe DFD, un model de date și logica procesului de
prelucrare. Problema comună ar consta în identificarea unei căi de realizare a modelului
logic al sistemului propus [1].
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 neapărat 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 căruia se realizează:
– pune în evidență ce face sistemul, eliminând detaliile referitoa re la modul cum
funcționează sistemul în implementarea actuală;
– pune în evidență funcțiunile de bază ale sistemului;
– permite identificarea și eliminarea problemelor legate de redundanța datelor și duplicarea proceselor de prelucrare;
– permite stabilirea cu o mai mare precizie a granițelor 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 alcătuit de la procesele “frunză” și va continua prin agregarea proceselor
către nivelurile superioare.
Se parcurg următorii pași:
1. Identificarea stocurilor logice de date – se face pe modelul logic al datelor prin
gruparea într -un stoc logic de date a entităților înrudite sau utilizate frecvent.
După identificarea stocurilor logice de date se construiesc:
– diagrama de corespondență între stocuri logice și entitățile din modelul logic;
– diagrama de corespondență între stocuri fizice și stocuri logice de date.
2. Înlăturarea dependențelor fizice și temporale din denumirea proceselor și a fluxurilor
de date: din DFD la nivel fizic (se observă că nu există referințe fizice și temporale în
aplicația decontări).
3. Derivarea proceselor logice:
– scoaterea în afara granițelor 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ă prelucrări asemănătoare sau multiple care se execută împreună sau în secvență;
– înlăturarea proceselor care țin de implementarea actuală și a pr oceselor redundante.
– În cazul aplicației prezente:
– se combină procesele “Înregistrare încasări în numerar” și “Înregistrare încasări prin
virament” deoarece realizează prelucrări asemănătoare;
– se înlătură procesele redundante “Înregistrare încasări în j urnal” si “Înregistrare plăti
în jurnal”.
4. Derivarea fluxurilor logice care presupune înlocuirea numelui de document numai cu
fluxul de
informații utilizate efectiv de proces.
5. Gruparea proceselor elementare și transformarea diagramei fizice în diagramă
logică , aplicând cei 5 pași.
Relația existentă între DFD și modelul datelor
După cum reiese din prezentările anterioare, fiecare săgeată 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ă. Când 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ă operațiunea, dar foarte important este să prezentăm
structura datelor păstrate. Firesc, și în cazul fluxului de date, și în cel al stocării lor nu
trebuie uitată descrierea semnificației economice. Structura datelor trebuie să fie redusă la a treia formă normalizată, iar conținutul locurilor de stocare a datelor să fie prezentat prin
reduceri la unul sau mai multe tabele relaționale în forma a treia normalizată [1].
În cazul aplicației decontări, se obține următoarea DFD a sistemului logic.
Decontări cu beneficiarii .Nivelul elementar al DFD a sistemului logic. Nivelele
superioare ale DFD a sistemului logic sunt identice.
Figura 3.4. Diagrama fluxului de date
Tabel 3.1 aplicația Decontări
Sursa Destinația Nume flux Continutul fluxului
1.1. Înregistrare
facturi desfacere D2 FACTURI
DESFACERE desfaceri CODCLIENT
DENCLIENT
ADRESAC
CONTC
BANCA_C
DATAFACTD
NRFACTD
TOT ALFACTD
D2 FACTURI
DESFACERE 1.3. Analiza situație client desfaceri CODCLIENT
DENCLIENT
ADRESAC
CONTC
BANCA_C
NRFACTD
TOTALFACTD
2.3.4. Modelarea logicii proceselor
După ce au fost descrise procesele de conversie a datelor în informații, prin
intermediul diagramelor fluxurilor de date DFD, deoarece ele nu reliefează și logica
internă a proceselor, oricât ar fi de detaliate, chiar și la nivelul proceselor primare, se
impune apelarea la alte tehnici pentru descrierea logicii proceselor. Procesele t rebuie
astfel descrise încât să poată fi convertite în programe prin intermediul limbajelor de programare [1].
În faza de analiză modelarea logicii proceselor se va derula cât mai detaliat și
complet posibil, dar operațiunea 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 obținute în urma modelării proceselor sunt
descrieri și diagrame structurate care vor prezenta logica fiecărui proces, precum și
diagrame care vor evidenția dimensiunea temporală a sistemelor, când apar procesele sau
evenimentele și modul în care aceste evenimente schimbă starea sistemului [1].
Pe scurt se poate spune că modelarea logică a proceselor se va concretiza în
următoarele elemente ale documentației [1]:
– reprezentarea în engleza structurată;
– reprezentarea logicii proceselor prin tabele de decizie;
– reprezentarea logicii proceselor prin arbori de decizie;
– tabelul sau diagrama stărilor de tranziție.
Reprezentarea logicii proceselor prin engleza structurată
Engleza structurată este o formă mult simplificată și modificată a limbii engleze,
folosită pentru desc rierea conținutului casetelor care marchează procesele (prelucrările)
din diagrama fluxului de date. Cuvintele folosite sunt în strânsă legătură cu logica folosită
în conceperea procedurilor componente ale sistemelor informatice [1].
Se folosesc verbe pen tru 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 documentație. Utilizarea englezei structurate pentru procesul
“Analiza situație client” din decontări cu beneficiarii este reprezentată mai jos.
Analiza situație client
WRITE CLIENTI,FACTURI_DESF, ÎNCASĂRI
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;
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(ÎNCASĂRI);
vb=0; vb1=0;
while (not eof (ÎNCASĂRI) AND vb=0)
{
if (cod=ÎNCASĂRI.client AND
FACTURI _DESF.nrfactd=ÎNCASĂRI.nrfactd AND
FACTURI_DESF.datafactd =ÎNCASĂRI.datafactd)
{ if (FACTURI_DESF.totalfactd !=ÎNCASĂRI.sumaincasata)
{ sold = sold+ FACTURI _DESF.totalfactd –
ÎNCASĂRI.sumaincasata}
vb1=1;
}
else if (vb1=1) vb=1
READ (ÎNCASĂRI)
}
MOVE FIRST LINE ÎNCASĂRI
READ (FACTURI_DESF)
}
CLOSE (FACTURI_DESF, ÎNCASĂRI, CLIENTI)
2.4. Modelarea conceptuală a datelor (diagramele entitate – relație, DER)
În cadrul modelării conceptuale a datelor se va renunța la abordarea proceselor și
se va trece la abordarea sistemelor prin prisma datelor. La fel ca și în cazul modelării
proceselor și modelării logicii proceselor elementele esențiale vor fi diagramele.
James Martin și Carma McClure, atunci când reliefează importanța teh nicilor
structurate prin obiectivele ce și le propun, consideră că o parte a acestora au legătură și
cu datele, și anume [1]:
– Să se realizeze o administrare riguroasă a datelor. Administrarea datelor se
referă la structurarea corectă a datelor, la uniform itatea modalităților 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 esențiale ale sistemelor: res ursele.
– Să se efectueze o analiză sănătoasă a datelor. Analizele datelor clarifică
problemele de structurare a lor și conduc la structuri stabile ale acestora,
concretizate prin costuri reduse ale realizării sistemelor. Dacă baza de date a
unității este de osebit de importantă, atunci pe analiza datelor trebuie să se pună
un accent aparte, ea fiind întotdeauna realizată înaintea proiectării programelor.
Firesc, dacă știm care sunt cerințele unui sistem (ieșirile), imediat ne vom pune
întrebarea din ce se obț in acestea (intrările) și apoi vom urmări cum se pot obține
ieșirile (procesele).
Obiectivul principal al ingineriei informației este crearea unui set de metodologii
care să poată fi folosite în cele mai diverse medii de lucru, astfel încât 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 văzute două
categorii mari de operațiuni:
– asigurarea datelor (cr eare, actualizare);
– utilizarea datelor (obținere de documente, de diverse rapoarte, analize „What -If”,
sprijin decizional, diferite căutări de informații, control și auditare întreprindere).
Modelul conceptual al datelor înseamnă o modalitate de reprezent are a datelor
organizației. Rolul său este de a scoate în relief toate regulile privind identitatea și legăturile existente între date [1].
Cea mai cunoscută formă utilizată pentru modelarea datelor este diagrama entitate-
relație (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 mul te ori, operațiunea are loc la nivel de întreprindere, prin apelarea
la o categorie foarte largă de date neglijându -se detaliile exagerate. Doar în etapele
următoare, în speță când se trece la definirea proiectului, are loc construirea unui model
anume ent itate-relație prin care să fie scoasă în evidență aria de întindere a proiectului. În
timpul structurării cerințelor, un model entiatate -relație reprezintă cerințele conceptuale
de date pentru sistemul luat în discuție. După ce sunt descrise complet intrăr ile și ieșirile
sistemului în cadrul proiectării logice, modelul conceptual al datelor, redat sub forma entitate -relație, este rafinat înainte de a fi trecut într -un format logic (de regulă, un model
relațional al datelor) din care se definesc bazele de date și are loc proiectarea fizică a
acestora [1].
DER joacă un rol deosebit de important în formarea profesională a veritabililor
analiști.
Se consideră că, în timpul modelării conceptuale a datelor, se produc și se
analizează cel puțin patru diagrame enti tate-relație [1]:
1. DER care să acopere datele necesare aplicației proiectului. Ea va permite stabilirea
necesarului de date ale aplicației proiectului, fără să se țină seama de constrângerile
sau confuziile generate de detaliile care nu sunt încă necesare.
2. DER pentru aplicația ce va fi înlocuită. Diferențele dintre aceste diagrame arată ce
schimbări trebuie întreprinse pentru convertirea bazei de date în noua aplicație. Nu se
aplică în cazul sistemelor complet noi.
3. DER care să scoată în relief întreaga bază de date din care noua aplicație își va
extrage datele. Cât timp mai multe aplicații pot folosi aceeași bază de date, această diagramă și prima evidențiază modul în care noua aplicație apelează la conținutul unor baze de date mult mai extinse.
4. DER pentru întreaga bază de date din care aplicația curentă își extrage datele
necesare. Ea este discutată doar pentru sistemele care există și pentru care se
urmărește îmbunătățirea. Din nou, diferențele dintre diagrama precedentă și cea de
față vor indica modificăr ile majore de efectuat pentru a se putea influența noua
aplicație.
Metodele de determinare a cerințelor trebuie să fie orientate, prin întrebările puse,
prin anchetele efectuate, și asupra datelor, nu numai asupra proceselor și logicii lor. La
început, chi ar fără utilizarea unei terminologii de specialitate, analistul va fi preocupat de
modul în care va afla cât mai multe informații despre datele necesare viitorului sistem
pentru a funcționa la parametrii proiectați. Întrebările vor fi astfel formulate încâ t să se
realizeze o bună înțelegere 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: când și cum sunt
prelucrate sau folosite datele, pentru a se realiza modelarea datelor [1].
Modelarea datelor se realizează printr -o combinație a punctelor de vedere.
Un prim punct de vedere, formulat în literatură sub numele de metoda top- down , va
scoate în evidență regulile derulării activității firmei, printr -o înțelegere foarte clară a
naturii afacerii, și nu se va opri asupra detaliilor privind modul în care ecranele,
rapoartele sau documentele sunt folosite în organizație [1].
În afara metodei top -down , informațiile necesare construirii modelului datelor se
pot obține și prin urmărirea documentației firmei, ecrane, rapoarte, formulare, din
interiorul sistemului. Acest proces este cunoscut în literatura de specialitate sub numele
de metoda bottom -up [1].
Elementele rezultate vor figura în diagramele fluxurilor de date prin car e vor fi
evidențiate datele prelucrate în sistem și de aici va rezulta necesarul de date menținute în
baza de date a sistemului.
Definirea conceptului de entitate
Entitățile 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 simțită prezența la un moment dat [1].
La rândul lor, obiectelor li se pot asocia cel puțin două evenimente: apariția și
dispariția lor. Exemple: încheierea și încetarea contractului de muncă; predarea
produselor la secția expediție ș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.
Entitățile conțin î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 organizația dorește să păstreze anumite date. Se
cuvine precizată diferența dintre tipurile entităților (entity types) și cazurile/instanțele
entității (entity instances) [1].
Tipul entității, cunoscut și sub numele de clasa entității, este o colecție de entități
care au proprietăți sau caracteristici comune. Fiecărui tip de entitate i se atribuie un nume.
Cât timp numele reprezintă o clasă sau un set de cazuri, el este singular. Și încă o
convenție. Cum referirea generală la elementele ce pot fi catalogate ca entități se poate
face prin noțiunea de obiect (deși sensul lui poa te fi altul în contextul analizei și
proiectării orientate obiect), referirea la acesta se va realiza printr -un substantiv la
singular. Se vor folosi litere majuscule, plasate în interiorul dreptunghiului corespunzător
entității.
O instanțiere a entității sau instanță, denumită de noi în continuare, caz al entității
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 rep rezentate prin datele stocate în bazele de date. De exemplu, există o singură entitate
CLIENT, dar ea poate să aibă sute sau mii de cazuri/instanțe ale acestei entități stocate în
baza de date.
Atribute
Fiecare tip de entitate are un set de atribute asocia te lui.
Un atribut este o proprietate sau o caracteristică a unei entități care prezintă interes
pentru organizație. La rândul lor, și relațiile pot avea propriile lor atribute.
Exemplu de entitate pentru aplicația DECONTĂRI și unele dintre atributele
posibile:
CLIENT : CodClient, DenClient, AdresaC
Ca și numele tipurilor entităților, numele atributelor sunt substantive scrise cu
majuscule, plasate în interiorul elipselor, legate de entitatea căreia i se asociază. De multe
ori însă, chiar și în cazul folosi rii produselor CASE, pentru a nu se încărca o diagramă
entitate -relație, se evită prezentarea atributelor. Operațiunea se face, în schimb, în
repository, depozitul de informații despre proiect. Aici orice atribut se descrie separat, ca
orice obiect distinc t.
Unul dintre exemplele anterioare poate fi reprezentat în diagramă conform fig. 3.5.
Figura 3.5. Model de reprezentare a atributelor DER
CLIENT DenClien
AdresaC CodClient
Cheie candidat și cheie primară
Fiecare tip de entitate trebuie să aibă un atribut sau un set de atribute prin care să se
efectueze diferențierea unui caz de același tip.
O cheie candidat aste un atribut sau o combinație de atribute prin care se poate
identifica în mod unic un caz (o instanță) al tipului entității respective.
Sunt entități care pot avea două sau mai multe chei -candidat. În exemplul nostru,
pot fi chei -candidat CodClient, NumeClient, AdresaC (presupunând că ele identifică în
mod unic un angajat). Atunci când 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 [1].
În reprezentările din DER, în elipsa sau elipsele aferente atributului sau atributelor
ce for mează cheia primară, numele respective se subliniază (vezi CodClient din entitatea
CLIENT ).
Relațiile entităților
Relațiile reprezintă legăturile între componentele unei diagrame entitate -relație. O
relație este o asociere între cazurile/instanțele uneia sau mai multor tipuri de entități care
prezintă interes pentru organizație. Ele se pot simboliza printr -un romb. De regulă,
relațiile sunt redate prin verbe.
Cardinalitatea relațiilor
Presupunem că există două tipuri de entități, A și B, între care exi stă o linie de
legătură pentru a marca relația. Cardinalitatea unei relații este dată de un număr al
cazurilor/instanțelor entității B care pot sau care ar putea să fie asociate cu fiecare caz al
entității A. Cardinalitatea este sugerată prin 0 (zero), 1, M (“multe”), cu mențiunea că ele
pot avea prezență obligatorie sau opțională. Trimiterea la cardinalitate se face în moduri
destul de diferite, în funcție de notația folosită. Recomandăm citirea cu atenție a
diagramelor și descifrarea elementelor strict ne cesare înțelegerii, îndeosebi pentru
reflectarea cardinalității. De exemplu, ea poate fi notată cu semne (0, 1, M, N) sau prin
simboluri (linie cu vârf simplu de săgeată pentru 1, linie cu vârf dublu de săgeată pentru
M. Alteori, 1 se reprezintă prin linie simplă și M prin vârf de săgeată). În multe materiale,
inclusiv produse CASE, se folosește notația model -date, cunoscută mai mult sub numele
laba-gâștei , conform cârei cardinalitatea se reprezintă prin următoarele simboluri [1]:
obligatoriu 1
opțional 0 sau 1
n obligatoriu multe (n, unde n ia valori de la 1 la M)
n opțional 1 sau multe (n, unde n ia valori de la 1 la M) CURS_CREDIT STUDENT
Înscris
pentru
Figura 3.6. Tip Relație
Entități compuse sau asociative (gerundive)
Atributele pot fi asociate cu o relație 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 no tă se poate efectua în momente (la
date) diferite. Prezentăm, mai jos, câteva dintre datele concrete [1]:
MATRICOLA STUDENT NUME CURS DATA PROMOVĂRII
1111 Informatică Iulie 1999
1177 Informatică Septembrie 1999
1155 Informatică Septembrie 1999
1111 Drept comercial Ianuarie 2000
Din analiza cazurilor rezultă că atributul DATA_PROMOVĂRII nu este o
proprietate a entității STUDENT, cât timp examenele pot fi date la momente diferite. Dar
nu este nici o proprietate a entității CURS, cât timp același curs po ate fi susținut la date
diferite. În schimb, DATA_PROMOVĂRII este o proprietate a relației dintre STUDENT
și CURS. Atributul se asociază relației și se prezintă sub formă de diagramă, ca în fig.
3.7.
Figura 3.7. Asocierea unui atribut la o relație [1]
De aici rezultă un caz aparte de entitate, numită gerundivă sau compusă sau
asociativă care, de fapt, este o relație folosită de analist în model ca un tip de entitate. În
astfel de cazuri, se folosește un simbol special: dreptunghi cu romb în inte rior, în care se
scrie numele entității (fig. 3.8) [1].
STUDENT Promovare CURS DATA PROMOVĂRII
STUDENT Promovare CURS DATA PROMOVĂRII
Figura 3.8. Redarea unei entități gerundive (asociative) [1]
Nu trebuie confundată această situație cu relațiile transformate în entități
nepurtătoare de informații, descrise anterior.
Scopul diagramelor entitate -relație este de a surprinde cele mai complete sensuri
posibile ale datelor necesare sistemului informațional din organizație.
Tipuri de relații
Din cele prezentate mai sus, rezultă că între entitățile descrise, luate două câte
două, se pot identifica trei tipuri de relații: unu-la -unu, unu-la -multe, multe -la-multe. În
diagrame, descrierea relațiilor se face de-a lungul liniilor care leagă cele două entități.
Simbolul vârf -de-săgeată este cunoscut ca indicator al cardinalității (cardinality
indicator).
În cele ce urmează sunt prezentate exemple de tipuri de relații [1].
1. Relația unu-la -unu (1:1)
Figura 3.9. Descrierea relației 1:1
„Fiecare BIROU este condus de un, și numai un, MANAGER”
„Fiecare MANAGER conduce un, și numai un, BIROU”.
2. Relația unu-la -multe (1:M)
Figura 3.10. Descrierea relației 1:M
„Fiecare VÂNZARE implică unul sau mai multe ATRICOL(e)_VÂNDUT(e) “
„Fiecare ATRICOL_VÂNDUT face parte din numai o VÂNZARE”
3. Relația multe -la-multe
Figura 3.11. De scrierea relației M:N
“Fiecare FURNIZOR livrează unul sau mai multe PRODUS(e)”
“Fiecare PRODUS este livrat de unul sau mai mulți FURNIZOR(i)”
BIROU MANAGER este condus de conduce
implică VÂNZARE ARTICOL
VÂNDUT face parte din
livrează FURNIZOR PRODUS este livrat de
În anumite cazuri, între două entități pot exista mai multe relații.
De exemplu, s-ar putea spune că “FURNIZOR o feră PRODUS”, dar și “PRODUS
este cumpărat de la FURNIZOR”, ceea ce s-ar putea reprezenta ca în fig. 3.12.
Figura 3. 12. Descrierea relațiilor multiple între două entități
4. Relații opționale și obligatorii
Alteori, relațiile dintre entități nu -și fac simțită prezența în toate situațiile. Chiar
cazul cu studiile la care lucrează diverse persoane este destul de elocvent; o persoană
poate să lucreze la un singur studiu sau la câteva, sau la niciunul și, invers, un studiu
poate fi efectuat de o persoană, de mai multe sau de nici una. În astfel de situații, se
apelează la următoarea formă de reprezentare. (fig. 3.13)
Figura 3.13. Exemplu de relație opțională
Cercul suprapus pe latura entității indică, de fapt, poziția 0 (v aloarea minimă poate
fi și zero), conferind relației caracterul opțional.
Un alt aspect se referă la caracterul o bligatoriu al relațiilor. Cu alte cuvinte, o
entitate poate exista fără cealaltă?
Să luăm exemplul vânzărilor. În relația 1:M, dintre VÂNZARE ș i
ARTICOL_VÂNDUT. Ar fi total eronat ca o entitate să existe fără cealaltă: nu poate fi o
vânzare fără cel puțin un articol vândut și, invers, un articol nu poate fi vândut fără o
vânzare (operațiunea nu ar avea sens). Simbolul folosit pt a marca relațiile obligatorii este
același cerc, cu deosebirea că este hașurat.
Figura 3.14. Exemplu de relație obligatorie
5. Relația unei entități cu ea însăși
În practică, apar și situații în care o entitate este pusă în relație cu ea însăși. PRODUS FURNIZOR oferă
este cumpărat de la
PERSOANA STUDIU
este realizat de lucrează la
VÂNZARE ARTICOL
VÂNDUT
Ne oprim la exe mplul entității ANGAJAT. Unii dintre ei dobândesc statutul de
coordonatori ai activității celorlalți, situații în care se poate apela la o diagramă de genul
celei din fig.3.15.
Figura 3.15. Redarea relației unei entități cu ea însăși
Reprezentarea anterioară se citește astfel:
“Un angajat poate fi coordonatorul unuia sau mai multor angajați”
“Oricare angajat întotdeauna raportează altui angajat”
6. Relații alternative (sau/sau)
Uneori se ivesc situații când relațiile posibile se redau alternati v: fie o variantă este
de urmat, fie cealaltă. De exemplu, o marfă destinată vânzării 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 legătur ă cu cele două surse
posibile, PRODUCȚIA_ALTORA și PRODUCȚIA_PROPRIE, printr -un punct comun,
dar nu cu linii de relații distincte, așa cum este prezentat în figura 3.16.
Figura 3.16. Exemplu de diagramă pentru relațiile alternative
Citirea diagra mei este:
“O marfă se poate asocia sau cu un producător din afară, sau cu producția unității”
“Un producător din afară poate livra mai multe mărfuri”
“O linie proprie de producție poate livra mai multe mărfuri”
Deși diagramele entitate-relație se cunosc de către mulți specialiști din lumea bazelor de
date, ele constituie unul din conceptele esențiale ale analizei și proiectării structurate și,
ca atare, provin din acest domeniu [1].
După cum reiese și din citirea cu atenție a numelui diagramei, scopul ei este de a
evidenția entitățile de date (obiectele despre care se solicită păstrarea datelor) și relațiile
ce există între ele. MARFA
PRODUCȚIA
PROPRIE PRODUCȚIA
ALTORA coordonator al
ANGAJAT
raportează la
De remarcat diferența dintre diagrama fluxului de date și diagrama entitate-relație.
În timp ce diagrama fluxurilor de date indică atât procesele de prelucrare, cât și entitățile
de date (redate fie sub forma fluxurilor de date, fie a locurilor de stocare), DER tratează
doar entitățile de date. Din această cauză, DER poate fi considerată și ca diagrama
modelului datelor sau diagra ma conceptuală a datelor [1].
În sistemul analizat pentru descrierea DER se apelează la simbolul dreptunghi,
pentru fiecare entitate. Se recomandă ca numele entității să fie redat printr -un substantiv
la singular (CLIENT, PRODUS, SALARIAT, FACTURA_DESFACERE, ÎNCASĂRI).
După ce se identifică entitățile se continuă cu împerecherea lor, fiecare cu fiecare,
pentru a descrie relațiile dintre ele.
Figura 3.17. DER pentru aplicația Decontări
2.4.1. Modelul Entitate/Relație (E/R)
Cercetările efectuate pentru definirea unui model de date care să permită
reprezentarea cât mai fidelă a realității au condus la definirea conceptului de model
semantic încă din 1976 când Chen a prezentat modelul Entitate -Relatie (E/R), care
constituie astăzi 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, fără a ține seama de anumite constrângeri impuse de utilizarea
unui anumit SGBD, de o anumită platformă hardware, sau de anu mite considerente de
eficiență privind exploatarea bazei de date, ceea ce permite o reprezentare mai fidelă a
realității avute în vedere, constituind astfel o etapă intermediară în proiectarea unei baze de date, fiind din acest punct de vedere asemănător p seudocodului utilizat în activitatea
de programare.
Modelul Entitate/Relație (E/R) permite reprezentarea schematică a realității
avute în vedere cu ajutorul unei diagrame E/R definită plecând de la conceptele de bază:
tip de entitate, tip de relație (legă tură, corelație), atribut.
Pentru reprezentarea unor probleme complexe de tip bază de date, apărute
începând din anii 80, modelul de date semantic a fost extins cu noi concepte semantice,
rezultând astfel modelul entitate relație extins EER. În acest sens la conceptele de bază au
fost adăugate conceptele suplimentare de superclasă, subclasă și moștenire.
O superclasă reprezintă un tip de entitate care conține subclase distincte
care trebuie să fie reprezentate în cadrul modelului, iar o subclasă este un me mbru
al unei superclase. O subclasă, fiind un tip de entitate distinct, poate avea la rândul său subclase, astfel încât se pot construi ierarhii de clase. O subclasă moștenește
toate atributele superclasei, putând 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ă [11], [13] o serie de
simboluri reprezentate în figura 3.18.
Reprezentar e tip entitate cu numele <nume tip entitate>
Reprezentare atribut cheie cu numele <nume atribut>
<num e tip
entitate>
<nume
ib Reprezentare atribut cu numele <nume
atribut>
<nume
ib
<nume tip
li Reprezentare tip de relație cu numele <nume tip
relație>
RELAȚIA R FUNCȚIONAL Ă FAȚĂ DE TIPUL
RELAȚIA R NEFUNCȚION ALĂ FAȚĂ DE TIPUL
E R
E R
Superclas
Subclasa APARTENENȚA SUBCLASE I LA
<nume tip
entitate>
<nume
ib Apartenența atributului <nume atribut>
la tipul de entitate <nume tip entitate>
<nume
ib Reprezenta re atribut derivat cu numele <nume
atribut>
Reprezentare atribut compus <nume
atribut>
format din componentele <atribut1>,
<nume
ib <atribut
1 <atribut
2
FIG. 3.18. SIMBOLURI UTILIZAT E ÎN REPREZENTAREA U NEI
DIAGRAME EER
Problemă rezolvată
Folosind modelul entitate – relație să se reprezinte diagrama E/R pentru un
sistem informatic simplificat al unei firme care desfășoară activitate de comerț fiind
avute în vedere subsistemele;
– aprovizionare (evidența furnizorilor);
– desfacere (situația vânzărilor);
– urmărirea stocurilor.
FURNIZORI Oferte
PRODUSE m n Cod
furnizor
Cod produs
Fig. 3.19. Subsistemul Aprovizionare. Reprezentarea relației de tip m -n Oferte
PRODUSE Vânzări
CLIENTI m n Cod produs
Cod client
Fig. 3.20. Subsistemul Desfacere . Reprezentarea relației de tip m -n Vânzări
Desfacere
PRODUSE
STOCURI Intrări
Ieșiri 1 n
1 n Aprovizionare Cod produs Cod
Produs+Depozit+Preț
Fig. 3.21. Subsistemul Urmărirea stocurilor.
Reprezentarea relațiilor de tip 1 -n Intrări, Ieșiri, pentr u actualizarea stocurilor
PRODUSE Cod produs Denumire
produs Descriere
produs
Fig. 3.22. Reprezentarea entității PRODUSE
PRODUSE Cod furnizor Denumire
furnizor Adresa furnizor
Fig. 3.23 . Reprezentarea entității FURNIZORI
Stradă Număr
Oferta
Oferte Cod produs Unitate de
măsură
Preț unitar
produs
Fig. 3.24. Reprezentarea relației Oferte Cod furnizor
2.5. Selectarea celei mai bune variante strategice de proiectare
Întregul efort depus până în momentul de față s -a concretizat într -o bogată
acum ulare de informații despre cerințele sistemului, structurate sub diverse forme,
precum și despre modul în care am dori să fie conceput noul sistem sau ce corecții să i se
aducă celui vechi.
Ne aflăm în așa -zisa fază a strategiei proiectului.
În afara certi tudinilor concretizate în specificațiile elaborate până acum, asupra
variantei noului sistem planează și o seamă de incertitudini, generate de nehotărârea sau,
încă, needificarea asupra formei finale dorite. Un cuvânt greu au utilizatorii și finanțatorii
proiectului. Pentru a -i ajuta să ajungă la o concluzie finală comună, trebuie pornit de la
cerințele structurate și se vor prezenta câteva strategii concurente de proiectare, dintre
care doar una va fi continuată în pasul următor al ciclului de viață al sistemului, faza de
proiectare, în funcție de performanțele ei și de încadrarea în resursele disponibile [1].
Rezultatul final al studiului de identificare a cerințelor de informații se
concretizează într -un raport detaliat al cerințelor sistemului, în care vor fi prezentate
informațiile necesare noului sistem. Raportul cuprinde tot ceea ce trebuie să fie produs de
către sistem. El va lăsa fazei de proiectare o imagine clară a modului în care se vor obține
cerințele sistemului.
Raportul conține următoarele elemente [1]:
– descrierea funcțiilor principale executate în noul sistem, inclusiv ce trebuie făcut și de cine, cum se realizează interfața funcțiilor cu întregul sistem și cum funcțiile noi vor afecta utilizatorii;
– descrierea tuturor datelor necesare sistem ului, inclusiv nume, mărimea, 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 arăta cum datele vor fi organizate în
înregistrări logice și car e este legătura dintre date;
– descrierea modului de funcționare a noului sistem și a subsistemelor componente, precum și a modului în care vor fi atinse obiectivele de către întregul organism;
– descrierea și prezentarea unui exemplar al tuturor intrărilor î n sistem, inclusiv
numele fiecărei intrări, sursa, cine îl completează, ce date va conține și cum vor fi
culese datele din el;
– o descriere și un model de exemplar pentru fiecare ieșire din sistem (rapoarte, documente);
– descrierea unor norme interne de cond uită privind raportările, programarea
activităților, securitatea și protecția, personalul implicat și zona de acces pe categorii ale acestuia;
– prezentarea restricțiilor existente în sistem, cum ar fi statutele și regulamentele de organizare.
CAPITOLUL 3
PROIECTAREA LOGICĂ A SISTEMELOR INFORMATICE
În cadrul acestui capitol este realizată prezentarea noului sistem prin prezentarea
tuturor intrărilor sistemului, a ieșirilor, precum și a interfețelor și dialogurilor. Având în
vedere intrările și ieșirile sise mului este prezentată proiectarea logică a bazei de date,
activitate prin care se urmărește transformarea diagramelor entitate -relație în relații.
Dacă în primele etape, au fost identificate și structurate cerințele sistemului, în faza
de proiectare logică se efectuează deplasarea atenției de la prezentarea a ceea ce există și
ce se intenționează la descrierea a ceea ce va însemna noul sistem, cum va funcționa.
Modul de percepere a noului sistem se va reda prin prezentarea tuturor intrărilor
sistemului, a ieșirilor, precum și a interfețelor și dialogurile. Ele se construiesc pe baza a
ceea ce s-a identificat în etapele anterioare, dar ținându -se cont și de cerințele identificate
în timpul desfășurării activităților din etapa de proiectare logică [1].
Toate intrările și ieșirile sistemului, în faza de proiectare logică, vor fi prezentate ca
fluxuri ale datelor între un proces manual și altul automat sau între o sursă/ destinație și
un proces automat din diagramele fluxurilor de date. De regulă se poate proie cta câte un
formular sau raport pentru fiecare flux de date dintre utilizator și sistem.
Documentația realizată în cadrul acestei etape constituie proiectul tehnic de
ansamblu al sistemului.
3.1. Proiectarea formularelor/formatelor și a rapoartelor
În cad rul etapei de analiză a sistemului informatic, intrările și ieșirile au fost
identificate și prezentate, exprimând cerințele informaționale la nivelul fiecărui
subsistem/ aplicație informatică. În acel moment nu s -au prezentat toate detaliile privind
formu larele/formatele, rapoartele și procesul de modelare a datelor, insistându -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 regăsi î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
conține unele date predefinite, cărora 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
informația.
Î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 proiectării logice poate fi realizat cu ajutorul unui editor de texte sau
un produs program orientat spre grafică, sub forma unui prototip [1].
3.1.1. Proie ctarea situațiilor cu rezultate finale (rapoartelor)
Obiectivul prezentării detaliate a ieșirilor este și acela de a determina formatul și
conținutul tuturor rapoartelor imprimate și ale documentelor și ecranelor furnizate de
sistem.
Proiectarea ieșirilor se va face astfel încât să servească pentru [2]:
– transmiterea rezultatelor prelucrării pe calculator utilizatorului, într -o formă pe
care acesta să o înțeleagă și în care să-și regăsească cerințele sale;
– transmiterea proiectului situațiilor finale progr amatorului, fără ambiguități, pentru
a-i permite acestuia trecerea la întocmirea programelor necesare editării sau
vizualizării.
În proiectarea ieșirilor, analistul trebuie să elaboreze un model demonstrativ al
raportului sau ecranului și să întrebe utiliz atorul dacă informațiile din raport și formatul
acestuia sunt accesibile. Dacă ieșirile sunt inacceptabile, analistul trebuie să le modifice
[1].
Un instrument util pentru formatul rapoartelor sau ecranelor realizate pe calculator
îl constituie macheta im primantei [2].
Macheta imprimantei este reprezentarea de detaliu a situației de ieșire, cuprinzând:
– antet;
– titlu;
– date de identificare;
– cap de tabel;
– date elementare ce se imprima rând de rând;
– totalurile.
– detalii și indicații tehnice de realizare care se referă la:
– volumul datelor de ieșire;
– frecvență;
– număr de copii și destinația fiecăreia;
– grad de precizie al calculelor;
– condiții speciale de editare;
– criterii de control, validare și interpretare a datelor de ieșire.
Specificațiile de ieșire vor cuprinde , pentru utilizator, macheta situației iar pentru
programator macheta situației și o serie de indicații tehnice de realizare.
Pe baza specificațiilor de ieșire se trece la proiectarea fizică prin care se alege
suportul informațiilor de ieșire, se realize ază definitivarea formei și formatului de editare
a situațiilor (așezarea în pagina / ecran, spațierea între coloane și rânduri, etc.) și se definitivează procedurile de utilizare și interpretare a ieșirilor [2].
Alegerea tipului de suport fizic de ieșir e (imprimanta, display, disc fix, floppy disc,
banda magnetica etc.) se face în funcție de: timpul de răspuns solicitat, amplasarea
utilizatorului față de calculator, hard -ul și soft -ul existent, costul suportului, măsura în
care răspunde necesitaților de redare a conținutului informațional al situației finale [2].
Când se pregătesc ieșirile, este bine să se ia în calcul ce se urmărește prin ele, astfel
încât apelarea la categoriile de date de mai sus să se efectueze în cunoștință de cauză.
În definitivare a formei și formatului de prezentare a situațiilor finale trebuie să
ținem seama de o serie de considerente practice cum ar fi [2]:
– Respectarea unor cerințe ale factorilor de decizie privind macheta situației
finale;
– Restricții tehnice;
– Elemente de efic iență;
– Lizibilitate – spațiere;
– Utilizarea formularelor pretipărite;
– Utilizarea monitoarelor sau terminalelor video;
– Utilizarea generatoarelor de rapoarte.
Respectarea unor cerințe ale factorilor de decizie privind macheta situației finale
O serie de cer ințe ale conducerii privind macheta situației finale obligă proiectantul
la o anumită structurare și machetare a situațiilor finale. Informațiile se pot împărții în
două grupe prin prisma sistemelor informatice interne și externe. Informațiile interne
reprezintă acele informații culese, generate sau folosite în interiorul organizației.
Informațiile externe se referă la cele colectate sau create de la sau pentru parteneri străini
(facturi, rapoarte anuale, etc) [2].
În funcție de informațiile care pot fi văzute din punct de vedere al echipei
manageriale distingem: informații curente, de atenționare, indicatori de bază, etc.
Restricții tehnice
În proiectarea situațiilor finale intervin o serie de restricții datorate caracteristicilor
și performanțelor tehnic e ale echipamentelor periferice și anume: numărul maxim de
caractere pe linie; numărul maxim de linii pe pagina / ecran; facilitățile de imprimare etc.
Pe piață se afla o gamă variată de echipamente de redare a rezultatelor. Există mai multe
tipuri de impr imante, console și terminale video, ceea ce creează posibilitatea unei alegeri
adecvate a perifericelor destinate obținerii diverselor tipuri de situații finale [2].
Elemente de eficiență
În proiectarea situațiilor finale nu trebuie sa scape atenției și a spectele de eficientă
economică privind: reducerea timpului calculator consumat cu editarea propriu-zisa a situațiilor; economie de hârtie de imprimantă. Abilitatea și experiența proprie a
programatorilor joacă în acest sens un rol important.
În vederea o ptimizării obținerii situațiilor finale pe imprimantă se pot folosi de la
caz la caz, diverse tehnici cum ar fi: editarea mai multor tabele pe aceeași pagină de
imprimantă; editarea unei situații imprimând față/verso pe aceeași coală;
Pentru a nu irosi timp cu editarea unor situații finale voluminoase se recomandă
mai întâi 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 situațiilor finale. Programele care editează situații finale voluminoase trebuie
prevăzute cu posibilitatea de întrerupere (respectiv de reluare a editării în cazul unor
incidente ivite în timpul rulării) sau editarea lor sub forma unui fișier ASCII sau te xt pe
hard disc sau floppy disc, urmând imprimarea ulterioara a acestui fișier, total sau parțial [2].
Lizibilitate – spațiere
Parcurgerea unei situații finale trebuie să fie cât mai ușoara, “citirea” unei situații
nu trebuie să dea naștere la ambiguităț i. Este necesar ca situația sa fie autoexplicativă.
Pentru aceasta, antetul va conține informații și coduri ce vor indica sursa de emitere a
raportului, exprimând clar, sintetic, conținutul raportului și perioada la care se referă.
Capul de tabel, împreun a cu titlul și antetul, se afișează pe următoarele pagini
numai dacă au intervenit schimbări în cadrul caracteristicilor de grupare față de prima
pagină, altfel se imprimă doar numerotarea coloanelor de tabel.
Informațiile importante pot fi subliniate. Totalurile se separă de informațiile
analitice. Informațiile care se repetă pe linii succesive se imprimă o singură dată [2].
Utilizarea formularelor pretipărite
Aceasta implica utilizarea unei hârtii de imprimanta ce cuprinde elemente fixe ale
situației finale, cum ar fi antetul, titlul, capul de tabel, textul explicativ etc. Aceasta
conduce la o creștere a vitezei de editare și o diminuare a uzurii imprimantelor, riboanelor
etc. Totodată situațiile obținute sunt mai estetice și sunt ușor de parcurs de utilizatori [2].
Utilizarea monitoarelor sau terminalelor video
Prin intermediul unui soft adecvat, monitoarele sau terminalele video oferă
posibilitatea afișării situațiilor finale, atât în regim alfanumeric, cât și în regim grafic,
alegerea modului de lucru făcându -se prin intermediul unor comenzi sau comutatori.
Ecranul unui terminal video în regim alfanumeric este alcătuit din linii și coloane
iar în regim grafic ecranul este privit ca o matrice de puncte denumite “pixeli”.
Reprezentarea informațiil or de ieșire sub forma grafică reprezintă un pas înainte
față de editarea sub forma de text a rapoartelor. Această formă de afișare se recomandă factorilor de decizie de pe nivelele de conducere superioare, dat fiind gradul de sintetizare
a informațiilor d e ieșire și volumul redus al rapoartelor.
Pe lângă problemele legate de așezarea informațiilor pe ecran, la proiectarea
ecranelor de ieșire se iau în considerare și facilitățile oferite de monitoare sau terminalele
video și anume: regimul de lucru (defila re ecran, pagina sau linie); regimul de afișare
(normal, mai luminos, cu intermitente, invers video); regimul de semnalizare sonoră
(normal, semnal sonor după afișarea unui câmp etc.) [2].
Utilizarea generatoarelor de rapoarte ( REPORT WRITER )
Multe li mbaje 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ă, conținutul unui rând de date (de detaliu),
gradele de total și maniera lor de afișare, la începutul sau la sfârșitul grupului de date, al
paginii sau raportului. De asemenea, se pot selecta dimensiunea unei linii, colo ane,
pagini, spațierea dintre linii, coloane, afișarea datelor privind momentul listării, statistici
etc.
Astfel de module specializate există în pachete de programe pentru gestionarea
bazelor de date cum ar fi: ACCESS, d’BASE, ORACLE, FOXPRO, PARADOX, etc.
3.1.2. Proiectarea codurilor
În proiectarea sistemului de coduri trebuie să avem în vedere două aspecte
importante și anume [2]:
– influența tipului și structurii codului asupra performanțelor sistemului informatic;
– implicațiile utilizării codurilor în operațiile de culegere a datelor și interpretarea
rezultatelor finale de către utilizatorii neinformaticieni.
Primul aspect ridică probleme de ordin tehnic în realizarea nomenclatorului de
coduri și are în vedere facilitarea operațiilor de prelucrare, ocuparea unui spațiu de
memorie internă și externă cât mai mic etc.
Celui de -al doilea aspect trebuie să i se acorde o atenție mai mare în vederea
ușurării activităților de culegere, verificare a datelor și interpretarea rezultatelor din
situațiile finale. Având în vedere aceste considerente, se impune ca la proiectarea unui
sistem de coduri să se respecte o serie de cerințe.
De exemplu, codul persoanei poate fi format din următoarele coduri elementare:
X X X XX XXX XXXX XX
Inițiala
nume Inițiala
prenume Sex Ziua nașterii Luna nașterii Anul
nașterii Grupa
sanguină
Activitățile parcurse în realizarea unui sistem de coduri sunt: [2]
– analiza elementelor ce urmează a fi codificate;
– precizarea și uniformizarea tehnologiei, a denumirilor;
– stabilirea caracter isticilor și a relațiilor dintre elementele de codificat;
– alegerea tipurilor de coduri; estimarea capacității, lungimii și formatului codurilor;
– atribuirea codurilor elementelor de codificat (crearea nomenclatoarelor de coduri);
– întreținerea nomenclatoarelor de coduri.
Este indicat a se utiliza, acolo unde este cazul, sistemele de codificare existente la
nivelul economiei naționale (CAEN, SIRUES, SIRUTA, CNP, etc).
3.1.3. Proiectarea intrărilor în sistemul informatic
Datele de intrare parcurg o succesiu ne de etape până 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; verifi carea sintactică și semantică a datelor de intrare;
corecția datelor eronate etc.
La proiectarea intrărilor este necesar să se realizeze, în principal următoarele
activități:
– alegerea suportului tehnic pentru culegerea datelor
– proiectarea machetelor docum entelor de intrare, stabilirea instrucțiunilor 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 funcție de cerințele
aplicației 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 ved erea prelucrării ulterioare. [4 ]
La proiectarea machetei documentelor de intrare (indiferent de metodele de
prelucrare a datelor folosite ulterior) sunt respectate câteva reguli care să înlesnească
completarea și apoi utilizarea documentului atât pentru prelucrarea automată a datelor cât
mai ales pentru necesită țile curente ale salariaților societății economice. Nu este
recomandabil să dublăm documentele primare, prin proiectarea unor documente destinate exclusiv preluării datelor pentru necesitățile prelucrării automate [2].
Macheta documentului primar trebuie să conțină:
– antetul –ce reprezintă denumirea unității și/sau a serviciului care -l emite;
– denumirea documentului;
– coduri de identificare,
– data documentului;
– rubrici /casete/ rânduri pentru denumirea informațiilor cantitativ -valorice și coduri;
– rubrici /casete /spații pentru semnături și ștampile;
– text explicativ, eventual indicații de completare și verificare.
În ordonarea informațiilor pe document, deci în rubricarea documentului se va ține
seama de câteva reguli: antetul se plasează în stânga sus; codurile și alte informații de
identificare se plasează în dreapta sus; sensul natural de parcurgere este de sus în jos și de la stânga la dreapta; zonele de document ce se completează de compartimente/ persoane
diferite se marchează / grupează distinct; m ărimea și spațierea documentului, distanța
dintre rânduri, dimensiunea rubricilor, depind de locul și modalitatea de completare
(manual, dactilo, automat) precum și de nivelul de calificare a personalului ce
completează documentul.
Așezarea 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 îngroșate în denumirea rubricilor implicate în dialogul
operator -calculator.
Atunci când documentul există într -o formă pe hârtie, în varianta pe calculator se
va urmări păstrarea în mare măsură a structurii existente, dar cu adaptări speci fice noului
mediu.
Regulile de control și procedurile de validare a datelor de intrare trebuie să
cuprindă [2]:
– reguli de verificare a volumului, secvenței 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), corelații logice (între indicatorii înscriși în același document, sau cu alți indicato ri din baza de date), prezența unor informații obligatorii (apartenența
codurilor la nomenclatoarele de coduri specifice aplicației 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 funcție de modul concret de desfășurare a dialogului operator –
calculator. Acest dialog se poate desfășura sub formă de [2]:
– întrebare-răspuns cu defilarea li niilor ecranului;
– afișare pe ecran a machetei de introducere a datelor de intrare.
În prima variantă, mai ușor de realizat practic, operatorul introduce succesiv, ca
răspuns la întrebările afișate pe ecran, date de intrare. La proiectarea formelor de int rare
este necesar ca proiectantul să aibă în vedere o serie de aspecte cum ar fi:
– afișarea la un moment dat a unui volum redus de informații;
– afișarea la un moment dat a unei cereri de răspuns ce se referă la o singură informație;
– scurtarea răspunsului operatorului prin folosirea mnemonicelor și codificărilor;
– utilizarea unor formate clare și precise pentru afișare;
– evitarea cuvintelor și caracterelor dificil de citit sau înțeles;
– 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ă câmpul curent care se
introduce. Ecranul display -ului trebuie să reproducă integral sau simplificat macheta
documentului, respectând aceeași ordine a rubricilor. Mesajele de eroare se pot afișa într –
o zona prestabilita a ecranului, însoțită de avertizare sonora sau luminoasa.
Dacă este cazul, pentru unele câmpuri (rubrici) de date se pot prelua valori
implicite, atunci când nu sunt comple tate. Aceste valori se preiau din nomenclatorul de
coduri, fișierele bazei de date sau tabele special memorate pentru valorile asumate prin
lipsa sau prin aplicarea unui algoritm. Pentru o mai ușoară operare este necesar să folosim
toate facilitățile de af ișare ș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.
3.2. Proiectarea interfețelor și a dialogurilor
Interfața cu utilizatorul – reprezintă o parte a aplicației software care permite
utiliz atorilor să -si exprime intențiile de operare asupra calculatorului și să interpreteze
rezultatele acțiunilor efectuate de mașină.
Prin proiectarea dialogurilor și a interfețelor se definesc modalitățile prin care
oamenii și calculatoarele schimbă informații [1].
Metode și echipamente folosite în dialogul om -mașină
Interfața om – mașină definește modalitatea prin care utilizatorul interacționează cu
un sistem informatic. Interfețele 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 măsură să faciliteze o astfel de interacțiune [1].
Metode de interacțiune
Metodele cele mai utilizate sunt [1]:
– interacțiunea prin limbaj-comandă (în acest tip de interacțiune utilizatorul transmite
calculatorului comenzile sub forma unui șir de caractere)
– interacțiunea prin meniuri(utilizatorul transmite comenzile sale calculatorului prin
intermediul unui sistem de meniuri și opțiuni de meniu sau folosind scurtături sub
formă d e combinații de taste).
– interacțiunea bazată pe obiecte icons(comunicarea se face prin intermediul desenelor.
Imaginile folosite funcționează ca butoanele, la apăsarea lor se activează o anumită
funcție sau comandă)
– interacțiunea prin limbaj natural(comenz ile se transmit folosind vocea și
sintetizatoarele de voce pentru redarea rezultatelor)
Echipamentelor necesare interacțiunii cu sistemul
Cele mai folosite echipamente sunt [1]:
– 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 selecția.
– Light Pen – Stiloul optic efectuează selecția prin apăsarea pe ecran.
– Voice – Vocea constituie modalitatea de transmitere a textelor și comenzilor către
calculator.
Proiectarea dialogurilor
Proiectarea dialogurilor este procesul prin care sunt proiectate toate secvențele
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 condițiile
în care se pot afișa informațiile sau se pot obține de la utilizator.
Pentru a obține rezultate bune trebuie să se țină seama de regulile de bază la
conceperea dialoguri lor cum ar fi: uniformitate, comenzi scurte, ușurința în lucru,
controlul, operațiunea inversă (refacerea unui element șters), rezolvarea erorilor, etc.
O modalitate de prezentare a secvenței dialogurilor este cea care apelează la
tehnica diagramelor. Ea v a face trimitere la meniurile componente ale aplicației.
Figura 4.2. Structura unei diagrame de apelare a meniurilor [1].
Pentru proiectarea interfețelor și dialogurilor se poate apela la ajutorul oferit de
produsele CASE sau la medi ile de dezvoltare grafică ACCESS, Visual Basic, etc.
Pentru a se putea proiecta în condiții optime mediile GUI (Graphical User
Interface) trebuie să se cunoască aceste medii.
În mediile grafice informațiile se plasează în ferestre. Acestea au trăsături specifice
ca: redimensionarea, maximizarea, disponibilitatea la deplasare, meniu sistem, etc.
3.3. Proiectarea logică a bazelor de date
Proiectarea logică a bazelor de date este în strânsă legătură cu modelarea
conceptuală a datelor, aceasta însemnând reprezentarea modului de organizare a datelor,
independent de tehnologiile specifice de prelucrare a bazelor de date, fără să se
înregistreze o preocupare anume referitoare la calitatea modelelor datelor. Ultimului
aspect i se va acorda atenția cuvenită abia acu m, odată cu modelarea logică a datelor,
descriindu -se structurile datelor din bază.
Procesul de modelare logică a datelor se derulează în paralel cu celelalte activități
ale proiectării logice: proiectarea formularelor și a rapoartelor și proiectarea dialo gurilor
și interfețelor. Modelarea logică a datelor se realizează nu numai pe baza diagramei entitate -relație, ci și pe baza machetelor formularelor și a rapoartelor. Se efectuează PO2
ADĂUGARE PO1
ȘTERGERE MENIU_PRINCIPAL MO1
MENIU_INTERO
GARE MO2
PO4
I_DUPĂ_AN PO3
I_DUPĂ_NUME PROCES
MENIU
analiza datelor elementare din intrările și ieșirile sistemului pentru a se desprinde
legăturile dintre ele.
Prin modelarea logică a datelor se urmărește:
– structurarea performantă a datelor prin procesul de normalizare
– obținerea unui model logic al datelor din care să se poată realiza proiectul bazei de
date fizice, adică modelul relațional – cel mai utilizat în prezent, deși se pot obține și
modelele rețea, ierarhic sau orientate-obiect;
– realizarea unui model al datelor care să răspundă cerințelor actuale de date regăsite în formulare și rapoarte. Modelarea logică este un proces ascendent (bottom -up, de jos
în sus) de obținere a relațiilor din formulare și rapoarte prin transformarea modelului
entitate -relație într -o formă relațională.
Modelarea logică a datelor descrie datele cu ajutorul unei notații speciale, care
corespunde unui mod de organizare a acestora de către un sistem de gestiune a bazelor de date.
Procesul de modelare a datelor este complex. În fiecare etapă a ciclului de viață se
regăsește câte o activitate specifică datelor după cum urmează [1]:
– Analiza – Modelele conceptuale ale datelor, prezentarea DER;
– Proiectarea logică – Modelul logic al datelor(relațional);
– Proiectarea fizică – Proiectarea fizică a bazelor de date și a fișierelor (organizarea
fișierelor);
– Implementarea – Descrierea fișierelor și a bazelor de date.
După cum prezintă profesorul Oprea D. În “Analiza și proiectarea sistemelor
informaționale economice” în procesul de modelare logică există patru pași esențiali:
1. Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare și
rapoar te) privind aplicația, folosindu -se principiile normalizării;
2. Contopirea tuturor perspectivelor normalizate ale utilizatorilor într -un model logic
consolidat (centralizat) al datelor, numit și integrarea perspectivelor;
3. Transformarea modelului conceptual a l datelor (entitate -relație), realizat fără să se
țină cont de perspectiva utilizatorului, într -un set de relații normalizate;
4. Compararea modelului logic consolidat al datelor cu modelul transformat al entității-relație și realizarea, prin integrarea persp ectivelor, a unui model logic final al datelor
aplicației.
Rezultatele obținute prin parcurgerea celor patru pași pot fi ilustrate prin
intermediul unor exemple oferite în literatura de specialitate de McFadden și Hoffer [1].
Primul pas al modelării logic e se poate explica prin două rapoarte solicitate de
utilizatori, reprezentând perspectiva utilității sistemului din punctul lor de vedere:
– cel mai bun client al produsului X(ecran);
– situația comenzilor în curs;
Ecranul “Cel mai bun client al produsului X”, prin percepția utilizatorului, are
următorul format:
Cel mai bun client al produsului
Introduceți codul produsului: P1122
Data de început: 10/10/99
Data de sfârșit: 31/12/99
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
COD CLIENT: 1111
NUME CLIENT: S.C. ALPHA S.R.L.
VOLUM: 1000
Figura 4.3 Model de ecran solicitat de utilizatori [1]
Din analiza ecran ului se pot desprinde relațiile:
CLIENT( COD_CLIENT , NUME)
COMANDA( NR_COMANDA, COD_CLIENT , DATA_COMANDA)
PRODUS( COD_P RODUS )
LINIE_COMANDA( NR_COMANDA, COD_PRODUS ,CANTITATE_COMANDATA)
Raportul “Situația comenzilor în curs” are următorul format:
Figura 4.4. Model de raport solicitat de utilizatori [1]
Realizarea raportului este posibi lă prin folosirea următoarelor entități:
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)
Pagina 1
Situația comenzilor în curs
31/03/1998
COD PRODUS
CANTITĂȚI_DE_LIVRAT
A1111 0
A2222 0
B1111 150
Y9999 100
Pasul al doilea presupune comasarea perspectivelor utilizatorilor și crearea unui set
integrat al relațiilor, rezultând următoarele relații:
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)
LIVRARE( COD_PRODUS , NR_FACTURA, CANTITATE_LIVRATA)
Pasul al treilea constă în transformarea modelului conceptual al datelor (diagrama-
entitate -relație) din aplicație fără să se țină cont de punctul de v edere al utilizatorului,
într-un set de relații normalizate. Din analiza diagramei din figura 6.5 se desprind
următoarele relații:
NUME_CLIENT COD_CLIENT ADRESA NR_FACTURA
CLIE NT FACTURA
Facturare Lansează
COMANDA
Linie_comandă PRODUS
COD PRODUS DENUMIRE NR_COMANDA CANTITATE_LIV
Livrar
Figura 4.5. Diagrama entitate -relație pentru gestiunea clienților [1]
Din analiza diagramei se desprind următoarele relații:
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 obținut din pasul doi cu cel din pasul trei și
integrează perspectivele utilizatorilor în vederea obținerii 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)
Așadar, rezultatul modelării logice a datelor îl constituie relațiile normalizate
rezultate din cel de-al patrulea pas al procesului. De asemenea, alt rezultat se va
concretiza în actualizarea depozitului (repository) sau a dicționarului proiectului.
Diferența majoră între modelarea conceptual ă și cea logică este că după modelarea logică
a datelor cerințele structurate de date se concretizează în relații, și nu în entități. Din
cauza normalizării nu este necesară o corespondență unu -la-unu între entități și relații
[1].
3.3.1. Normalizarea r elațiilor – Forme normale
Între atributele unei relații sau între atribute din relații diferite pot exista anumite
legături logice (dependențe), care influențează proprietățile schemelor de relație în raport
cu operațiile curente care intervin în timpul ex ploatării bazei de date: adăugare, ștergere,
actualizare. Aceste legături logice, cunoscute în literatura de specialitate sub denumirile
de dependențele funcționale, dependențele multivalorice și dependențe de cuplare, au
implicații majore asupra criteriilor de proiectare a schemelor relaționale. Alegerea unui
model conceptual convenabil pentru o bază de date relațională poate necesita realizarea
unor descompuneri pentru anumite scheme de relație date, descompuneri care să izoleze
dependențele existente și prin aceasta să elimine anomaliile care se datorează acestor
dependențe.
Dependențe funcționale
Penru definirea acestui tip de dependențe se consideră schema de relație
Prestari_Servicii (Cod, Nume_client, Adresa, Serviciu_prestat, Valoare)
definită pentru urmărirea serviciilor prestate de o firmă pentru diverși clienți.
Atributul Adresa este dependent de atributul Nume_client (presupunând că fiecare client are
o singură adresă, rezultă că fiecare valoare a atributului Nume_client determină î n mod
unic valoarea corespunzătoare a atributului Adresa). Analizând schema de relație de mai
sus, se constată o redundanță relativ la atributul Adresa a cărei valoare este repetată pentru
un client pentru fiecare serviciu prestat pentru acest client , ceea ce conduce la apariția
următoarelor anomalii:
– Anomalia la adăugare:
adresa unui client poate fi preluată numai după ce pentru acesta se prestează cel puțin un
serviciu.
– Anomalia la ștergere:
dacă se șterg toate serviciile prestate pentru un anumit c lient, se pierde adresa acestui client.
– Anomalia la actualizare:
datorită redundanței relativ la atributul Adresa, dacă se schimbă adresa unui client este
necesară parcurgerea întregii relații pentru a identifica și actualiza toate aparițiile acestui
client, în caz contrar baza de date devine inconsistentă (același client poate apare la adrese
diferite).
Aceste anomalii pot fi eliminate, dacă schema de relație Prestari_Servicii se
înlocuiește prin următoarele două scheme de relație:
Clienti(Cod, Nume_cli ent,
Adresa)
Servicii(Cod, Serviciu_prestat,
Valoare).
Relația Clienti conține codul, numele și adresa fiecărui client, fără nici un fel de
redundanță, iar relația Servicii conține serviciile prestate pentru fiecare client și valorile
acestor servicii. Un dezavantaj al descompunerii relației inițiale în cele două relații este
acela că pentru a determina adresa clientului pentru care s -a prestat un anumit serviciu
este necesară efectuarea unei operații de cuplare a relațiilor Clienti și Servicii .
Se consider ă o schemă de relație R și A,B două atribute simple sau compuse ale schemei
de relație R. Atributul A determină funcțional atributul B sau B depinde funcțional de A,
dacă și numai dacă oricărei valori a atributului A îi corespunde o singură valoare a
atributului B (se notează A ->B).
Dependența funcțională A ->B este totală dacă nu există nici un subset C al
atributului A (CcA) astfel încât C ->B și este parțială în caz contrar.
În relația Prestari_Servicii , una din dependențele funcționale care poate fi pus ă în
evidență este Nume_client ->Adresa.
Deoarece într -o relație orice cheie identifică în mod unic fiecare tuplă a relației,
deci determină în mod univoc valorile atributelor tuplei, rezultă că în orice relație
atributele sunt dependente funcțional față de cheile acesteia.
Se pot face, până în acest moment, următoarele precizări:
Eliminarea dependențelor funcționale din schemele de relație și a consecințelor
negative ( redundanța datelor; anomaliile de adăugare, ștergere, actualizare) se realizează
prin des compunerea schemei date într -o colecție de scheme mai simple în care sunt evitate
neajunsurile mai sus menționate. Reconstituirea relației inițiale se poate face prin operația
de cuplare (uniune). Pentru ca descompunerea schemei de relație să fie echivalen tă cu
relația inițială, trebuie să fie îndeplinite condițiile:
– cuplare fără pierdere de informație;
– conservarea dependențelor (dependențele funcționale din relația inițială trebuie să
se regăsească în relațiile rezultate prin descompunere) .
Formele normal e sunt scheme de relație echivalente obținute prin descompunerea
unor scheme de relație în vederea eliminării redundanței datelor și anomaliilor la
adăugare, actualizare, ștergere înregistrări în baza de date. Descompunerile schemelor de
relații în scheme de relații echivalente având în vedere dependențele funcționale 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ă Boyce –
Codd (FNBC).
A patra formă normală (FN4) este definită având în vedere dependențele
multivalorice, iar a cincea formă normală (FN5) este definită având în vedere
dependențele de cuplare. Începând de la prima formă normală și până la forma normală FN5
se impun condiții din ce în ce mai restrictive asupra relațiilor. Astfel o relație aflată pe un
anumit nivel de normalizare (FN5) satisface toate restricțiile cerute de nivele inferioare de
normalizare (FN1, FN2, FN3, FNBC, FN4). În cele ce urmează sunt date definițiile
formelor normale având în vedere dependențele funcționale.
O relație 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 neato mic dacă în cadrul adresei ne- ar interesa
localitatea, strada etc., caz în care trebuie descompus în atribute atomice.
O relație R este în a doua formă normală (FN2) dacă este în FN1 și orice atribut
neprim este total dependent față de orice cheie a relați ei (atributele prime sunt atribute care
fac parte dintr -o cheie a relației și cele neprime sunt atributele care nu aparțin nici unei chei a
relației).
O relație R este în a treia formă normală (FN3) dacă este în FN2 și nici un atribut
neprim nu este funcți onal dependent față de un alt atribut neprim al relației.
O relație R se află în forma normală Boyce -Codd (FNBC) dacă singurele
dependențe funcționale admise sunt cele în care o cheie determină un alt atribut (nici un
atribut prim sau neprim nu poate fi dependent funcțional față de un alt atribut dacă acesta
nu este sau nu conține o cheie).
Dependențe multivalorice
Pentru ilustrarea acestui tip de dependențe se ia în considerare următoarea schemă
de relație:
Clase(Clasa, Discipline, Elevi)
ce conține clasele dintr -o instituție de învățământ, iar pentru fiecare clasă sunt înregistrate
disciplinele ce se predau și elevii înmatriculați în clasa respectivă. Se poate constata că
relația Clase poate rezulta prin operația de cuplare după atributul Clasa a următoa relor
două relații:
CD(Clasa, Discipline)
CE(Clasa, Elevi)
În relația Clase , presupunând că pentru o clasă dată, fiecare elev frecventează toate
disciplinele înregistrate pentru acea clasă, există dependențele multivalorice:
Clasa ->> Discipline
Clasa ->> Elevi .
Ca și în cazul dependențelor funcționale, existența dependențelor multivalorice prezintă
aceleași neajunsuri privind redundanța datelor și anomalii la efectuarea operațiilor de
adăugare, actualizare și ștergere înregistrări în baza de date.
O relație R este în a patra formă normală dacă singurele dependențe multivalorice
admise sunt cele determinate de un alt atribut care este o cheie sau care conține o cheie a
relației.
Întrucât orice dependență funcțională este un caz particular de dependență
multivalorică, rezultă că orice relație care se află în forma normală FN4, se află și în forma
normală FNBC. Transformarea unei relații într -o colecție de relații care să se afle în FN4
este similară cu trecerea în FNBC, însă trebuie avută în vedere atât eliminarea
dependențelor funcționale cât și a dependențelor 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 făcut prin descompunerea unei relații în altele
două, urmărindu- se eliminarea dependențelor funcționale și multivalorice. O relație aflată în
forma normală FN4 nu mai poate fi descompusă în continuare pe baza acestei metode.
Există situații când relații aflate în FN4 conțin redundanțe și prezintă anomalii la operațiile
de adăugare, ștergere și actualizare. Aceste anomalii sunt cauzate de existența
dependențelor de cuplare și pot fi eliminate prin descompunerea relației în 3 sau mai multe
relații a căror cuplare are ca rezultat relația inițială.
Dependențe de cuplare
Se consideră schema de relație:
SDS (Specializari, Discipline, Studenti)
care conține disciplinele care se predau la diverse specializări și studenții care le
frecventează, cu precizarea că pot exista discipline opționale care nu sunt frecventate de
toți stu denții de la specializarea respectivă. În aceste condiții în cadrul schemei de
relație SDS nu au loc dependențele multivalorice:
Specializari ->> Discipline
Specializari ->> Studenti
ceea ce înseamnă că relația SDS este în FN4. Deși este în FN4, relația S DS conține mai
multe redundanțe care pot conduce la anomalii de actualizare. Pe de altă parte, relația SDS
nu poate fi descompusă în două componente din a căror cuplare să rezulte relația inițială cu
conservarea informației. Se constată însă că relația SDS poate fi descompusă în
următoarele 3 relații:
SD(Specializari, Discipline)
SS(Specializari, Studenti)
DS(Discipline, Studenti)
și relația SDS este rezultatul cuplării relațiilor: SD, SS și DS fără pierdere de informație.
SDS = SD ►◄ SS►◄ DS.
În acest caz spu nem că în relația SDS există o dependență de cuplare. Dependențele
multivalorice sunt cazuri particulare de dependențe de cuplare.
A cincea formă normală este o generalizare a formei normale patru, trecerea unei
relații în FN5 presupunând eliminarea dependențelor de cuplare existente în cadrul
relației, împreună cu anomaliile pe care acestea le creează. În cadrul unei relații pot exista
dependențe de cuplare care nu conduc la redundanță în memorarea datelor și nu produc
anomalii la operațiile efectuate asup ra înregistrărilor bazei de date (acestea sunt dependențele
de cuplare implicate de o cheie a relației).
O relație este în forma normală cinci (FN5) dacă și numai dacă toate
dependențele de cuplare existente în relație sunt implicate de o cheie a acesteia. Relația
SDS se poate descompune, cu conservarea conținutului de informație, în cele 3
componente ale sale: SD, SS și DS care sunt în FN5.
Având în vedere similaritatea ce există între definițiile pentru FNBC, FN4 și FN5,
acestea pot fi unificate în următo area definiție [13]:
O relație R este în FNBC , FN4, FN5 dacă și numai dacă singurele dependențe
funcționale, multivalorice, de cuplare existente sunt cele implicate de o cheie a relației R.
În concluzie, prin procesul de normalizare se realizează eliminar ea din schemele
de relație a dependențelor (funcționale, multivalorice și de cuplare) cu scopul de a obține o
schemă relațională mai bună din punctul de vedere al redundanței datelor și al anomaliilor
ce pot apare la operațiile de adăugare, ștergere și a ctualizare înregistrări în baza de date.
Normalizarea unei scheme de relație R înseamnă înlocuirea acesteia cu o mulțime de
proiecții R1,…,Rn astfel încât R să fie echivalentă cu uniunea proiecțiilor R1,…,Rn. Deși
normalizarea este o operație utilă î n proiectarea bazelor de date, aceasta nu oferă
întotdeauna rețete pentru obținerea 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 obținut. În unele cazuri
normalizarea completă, până la FN5, s-ar putea să fie dezavantajoasă. Având în vedere
constatările de mai sus se poate afirma că deși normalizarea nu reprezintă o soluție
general valabilă în orice situație, to tuși dacă pentru proiectarea bazei de date se
aplică corect o metodologie de proiectare descendentă, modelul rezultat va fi de la sine
normalizat. Cercetările în acest domeniu continuă, fiind definite și alte forme normale printre
care FN6 pentru baze de date temporale. O bază de date temporală, pe lângă datele curente,
conține și date istorice, iar factorul (atributul) timp are un rol esențial (exemple concludente
de astfel de baze de date sunt depozitele de date). Astfel, în proiectarea unei baze de da te
temporale trebuie avute în vedere și alte operații de descompunere a schemelor de relație și
anume:
– descompunerea orizontală – pentru separarea datelor curente de datele istorice;
– descompunerea verticală – pentru separarea atributelor aceleiași entități având în vedere
valorile lor raportate la atributul temporal.
În proiectarea unei baze de date nu este exclusă nici operația inversă normalizării
numită denormalizare [12], prin care se urmărește înlocuirea unei colecții de scheme de
relație cu o schemă d e relație echivalentă în vederea eliminării necesității efectuării unor
operații de cuplare care pot fi costisitoare. Dacă în cazul normalizării tendința este de a
ajunge la nivele cât mai înalte (FN5), pentru denormalizare nu există criterii clare putând
fi avute în vedere doar aspecte legate de performanțele anumitor aplicații.
Un alt principiu care se urmărește în proiectarea unei baze de date este principiul
proiectării ortogonale conform căruia în cadrul unei baze de date două scheme de relație
reale ( variabile de relație de bază) nu trebuie să aibă semnificații suprapuse. În timp ce
prin normalizare se urmărește reducerea redundanței din cadrul unei scheme de relație,
prin proiectarea ortogonală se urmărește reducerea redundanței dintre schemele de rel ație.
3.3.2. Simplificarea structurii datelor prin normalizare
Problema de bază a proiectării logice a bazelor de date este cum ar trebui
combinate datele elementare pentru a forma relații(sau tipuri de înregistrări) care să
descrie entitățile și relațiile dintre entități. În limbajul bazelor de date, cuvântul relație
înseamnă un tabel de date, ceea ce duce la concluzia că bazele de date relaționale
(modelul relațional) sunt clădite pe un grup de tabele legate între ele [1].
Modelul relațional a fost dezv oltat de către Codd. Este un model conceptual de
organizare a datelor, destinat reprezentării legăturilor dintre date. El este bazat pe teoria
matematică a relațiilor și este definit cu o deosebită rigoare matematică [Popescu I.,
1996].
În cadrul modelului relațional datele sunt structurate sub forma de relații (de aici și
denumirea). Cea mai directa și intuitiva modalitate de reprezentare a datelor în cadrul
acestui model este sub forma de tabele. Fiecărei relații i se poate asocia un tabel care are
atâtea coloane câte mulțimi leagă relația și are atâtea linii câte tuple conține relația.
Prezentarea structurii relaționale a datelor impune definirea noțiunilor de: domeniu,
relație, atribut și schemă a unei relații. Conceptele utilizate pentru a descrie form al, uzual
sau fizic elementele de bază ale organizării datelor sunt prezentate în tabelul următor:
Formal Uzual Fizic
Relație Tablou Fișier(tabel)
Tuplu Linie Înregistrare
Atribut Coloană Câmp
Domeniu Tip de dată Tip de dată
Definirea domeniului
Un domeniu este o mulțime de valori caracterizată printr -un nume. Un domeniu se
poate defini explicit prin enumerarea tuturor valorilor aparținând acestuia sau definind o proprietate distinctivă a domeniului valorilor, de cele mai multe ori limita superioară și
limita inferioară [Popescu I, 1996] . De exemplu:
D
1: {“F”,”M”} -definire explicită
D2: {x| x∈N, x∈ [0,100]} -definire implicită
D3: {s|s=șir de caractere} -definire implicită
Pentru un ansamblu de domenii D 1,D2,…,D n produsul cartezian al acestora
reprezintă ansamblul tuplurilor (elemente ale unei relații) <v 1,v2,…,v k> unde v i este un
element care aparține domeniului D i. De exemplu, tuplurile <“Maria”,”F”,”50” >,<
“Vasile”,”M”,”60”> aparțin produsului cartezian D 3xD 1xD 2.
Definirea relați ei
O relație R pe mulțimile D1,D2,…,Dn este o submulțime a produsului cartezian
D1xD2x…xDn, deci o mulțime de tupluri [Popescu I, 1996].
Considerând că nu se cunosc decât două persoane, relația R se definește prin
tuplurile care descriu aceste persoane, și anume:
R: {<“Maria”,”F”,”50”>,<“Vasile”,”M”,”60”>}
O relație poate fi reprezentată printr -un tabel bidimensional în care fiecare linie
corespunde unui tuplu și fiecare coloană corespunde unui domeniu.
R: D
3 D1 D2
“Maria” “F” 50
“Vasile” “M” 60
Reprezentarea tabelară este preferată adesea altor forme de reprezentare a relațiilor,
deoarece este ușor de înțeles și de utilizat.
În prezentarea conceptului de relație se poate recurge la analogii cu alte concepte
cum ar fi cel de fișier. Relația poat e avea semnificația unui fișier, tuplul poate fi
considerat o înregistrare, iar valorile din cadrul tuplului pot fi interpretate drept valori ale
câmpurilor de înregistrare.
Definirea atributului
În timp ce tuplurile dintr -o relație trebuie să fie unice, un domeniu poate apare de
mai multe ori în produsul cartezian pe baza căruia este definită relația [Popescu I, 1996].
PERS D3 D1 D2 D3
“Maria” “F” 50 “Vasile”
“Vasile” “M” 60 “Maria”
Relația PERS reprezintă un subansamblu al produsului cartezia n D 3xD 1xD 2xD 3.
Atributul reprezintă coloana unei tabele de date, caracterizată printr -un nume. Numele
coloanei (atributului) exprimă, de obicei, semnificația valorilor din cadrul coloanei
respective.
Semnificația valorilor din cadrul unui tuplu se stabileș te în acest caz nu numai pe
baza domeniului de care aparțin valorile ci și funcție de poziția ocupată în cadrul tuplului.
Dependența față de ordinea datelor înseamnă o reducere a flexibilității organizării datelor.
Într-o organizare eficientă, flexibilă, ordinea liniilor și a coloanelor nu trebuie să prezinte
nici o importanță. Pentru a diferenția coloanele care conțin valori ale aceluiași domeniu,
și a elimina astfel dependența de poziție în cadrul tabelei se introduce tocmai conceptul
de atribut. Fiecare relație are asociat un nume sau un identificator propriu.
Schema unei relații este formată din ansamblul elementelor definitorii sau din
nivelul relației urmat de lista atributelor specifice.
În mulțimile matematice nu este permis ca un obiect să apară de mai multe ori. Cât
timp o relație este o mulțime de tupluri, teoretic nici o linie a unei relații nu poate fi
duplicatul altei linii. După cum reiese din prezentările anterioare, dacă o coloană sau o
combinație de coloane nu poate să identifice în mod uni c 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 entităților definite se org anizează într -o singură
tabelă sau în mai multe și se urmărește descompunerea acestor tabele în altele, fără
pierdere de informații în scopul eliminării 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, înlăturându-se treptat o serie de neajunsuri și asigurând facilități sporite în
privința încărcării, actualizării și exploatării bazei de date. O relație nenormalizată conține
unul sau mai multe grupuri care se repetă.
Necesitatea normalizării progresive este dată de faptul că anum ite relații pot genera
o serie de situații nedorite, așa-numitele “anomalii de actualizare”, cum sunt: anomalia de ștergere, anomalia de adău gare, anomalia de modificare [7 ].
3.3.3. Transformarea diagramelor entitate -relație în relații
Pentru a se putea compara rezultatele obținute în etapa de proiectare logică a
datelor, adică a relațiilor normalizate, cu diagrama entitate -relație, rezultat al proiectării
conceptuale, aceasta din urmă trebuie să fie convertită în relații, de asemenea,
normalizate.
Întregul proces se desfășoară în patru pași, astfel: [1]
– Reprezentarea entităților . Fiecare tip de entitate din diagrama entitate -relație este
reprezentată ca o relație în modulul relațional al datelor. Identificatorul tipului de
entitate devine cheie primar ă a relației, iar celelalte atribute ale tipului entității devin
atribute non -cheie ale relației.
– Reprezentarea legăturilor. Fiecare legătură din diagrama entitate-relație trebuie să fie
reprezentată în modelul relațional al datelor. Reprezentarea legături i se efectuează în
funcție de natura ei. De exemplu, uneori se poate constitui o relație prin includerea
cheii primare a unei relații ca o cheie străină în altă relație. Astfel, se poate crea o
relație separată pentru reprezentarea legăturii.
– Normalizarea relațiilor . Relațiile create în pașii 1 și 2 pot conține redundanțe nedorite
și vor constitui surse de înregistrare a anomaliilor în timpul actualizării. Normalizarea va conduce la o bună structurare a relațiilor.
– Fuziunea relațiilor. În timpul modelării logice a datelor s-au creat diferite relații, atât
pe baza normalizării ascendente a perspectivelor utilizatorilor, cât și a transformării uneia sau a mai multor diagrame entitate-relație în seturi de relații. În structura acestor seturi de relații pot exista unele relații redundante, cum ar fi existența a două
sau mai multe relații care descriu același tip de entitate, ce ar trebui să fuzioneze și să se renormalizeze pentru extragerea eventualelor redundanțe.
CAPITOLUL 4
PROIECTAREA FIZICĂ A SISTEMELOR I NFORMATICE
Proiectarea fizică cunoscută și sub numele de proiectare de detaliu, urmează
proiectării logice. Proiectarea logică întâlnită și sub numele de proiectare generală, o altă
variantă de definire a proiectării logice. De fapt, printr -o astfel de r eferire se scoate în
relief faptul că în timpul proiectării 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 acumul ează informațiile de natură să
sintetizeze cerințele utilizatorilor noului sistem, operațiune prestată de analiștii de sistem,
iar în timpul proiectării fizice se prezintă punctele de vedere ale specialiștilor, cum ar fi
cei din domeniul bazelor de date, s ecurității sistemelor, rețelelor de calculatoare,
programării, etc.
Proiectarea fizică implică parcurgerea următorilor pași [1]:
1. Proiectarea fizică a bazelor de date și a fișierelor. O astfel de activitate înseamnă
descrierea modului în care vor fi stocat e 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 strânsă concordanță cu diagramele fluxurilor de date
și cu cel elalte piese ale documentației realizate în etapele anterioare;
3. Proiectarea strategiilor de prelucrare distribuită. Se vor prezenta modalitățile în care
utilizatorul poate să dispună de date și facilitățile de prelucrare oferite de rețele de
calculatoare.
4.1. Proiectarea fizică a bazelor de date și a fișierelor
Modelul conceptual surprinde structura globală de organizare a datelor,
asigurându-se independența totală față de orice sistem de gestiune a bazelor de date.
Modelul conceptual este prezentat prin intermediul diagramelor entitate -relație(DER),
motiv pentru care este cunoscut și sub numele de modelul entitate-relație al datelor. El
scoate în evidență reprezentarea logică, detaliată a entităților, asocierilor (legăturilor) și
datelor elementare ale un ei organizații sau ale unei părți din ea. Modelul se realizează în
faza de analiză [1].
Modelul logic al datelor înseamnă descrierea datelor în concordanță cu modelul de
organizare a acestora de către sistemele de gestiune a bazelor de date. În acest material s-a ales modelul relațional. Conform cu acest model datele sunt reprezentate în baza de date
sub forma tabelelor sau relațiilor create din diagrama entitate-relație obținută în etapa
anterioară.
O bază de date poate fi definită ca un ansamblu de date elementare sau structurate,
accesibile unei comunități de utilizatori. Mai concret, o bază de date este un ansamblu de fișiere intercorelate, care conține nucleul de date necesare unui sistem informatic
(aplicație informatică). Un fișier este un ansamblu de înregistrări fizice, omogene din
punct de vedere al conținutului și al prelucrării. O înregistrare fizică este unitatea de
transfer între memoria internă și cea externă a calculatorului. Aceasta este formată din
una sau mai multe înregistrări logice. O înregistrare logică este unitatea de prelucrare din
punct de vedere al programului utilizator. Aceasta este formată dintr -un ansamblu de
câmpuri, care descriu o anumită entitate.
Modul de stocare a datelor pe suportul fizic de memorare este funcție de si stemul
de gestiune a bazelor de date utilizat.
Proiectarea fizică a bazelor de date și a fișierelor îș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 et ape o constituie alegerea Sistemului de Gestiune a
Bazelor de Date adecvat soluționării optime a problemelor formulate în etapele anterioare ale realizării sistemului informatic.
4.1.1. Obiectivele fundamentale ale unei baze de date (BD) sunt:
Centraliza rea datelor permite: suprimarea redundanței, asigurarea unicității
înregistrării și controlul centralizat (asupra datelor). În prelucrarea clasică în care fișierele
sunt dedicate aplicațiilor, aceleași date apar înregistrate în mai multe fișiere și în form ate
diferite. Acest lucru implică o utilizare ineficientă a spațiului de memorie externă,
actualizarea dificilă a acestor date și lizibilitate redusă ca urmare a formatelor diferite.
Independența între date și prelucrări . Baza de date, ca imagine a unei an umite
realități, 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 legături între entitățile de date , care sunt indispensabile pentru
exploatarea eficientă a sistemului informatic. Spre exemplu, în cadrul gestiunii aprovizionării, trebuie asociat un furnizor la lista de produse pe care le vinde și invers, un
produs la lista de furnizori, precizând condițiile de vânzare pentru un furnizor și un
produs.
Integritatea datelor asigură fiabilitatea și coerența bazei de date (BD). Pentru
aceasta trebuie definite restricții de integritate cum ar fi:
– apartenența la o listă de valori sau interval;
– apartenența 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 tranzacții; lista operațiilor realizate asupra bazei de date după
ultimul punct de repriză.
Confidențialitatea datelor este asigurată prin proceduri de:
– identifica re a utilizatorilor prin nume sau cod;
– autentificarea prin parole;
– autorizarea accesului diferențiat prin drepturi de creare, consultare modificare sau ștergere pentru anumite segmente de date.
Partajarea datelor permite înlănțuirea tranzacțiilor solicitate simultan pe aceeași
înregistrare din baza de date, prin blocarea cererilor în așteptare și deservirea ulterioară a
acestora.
4.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
întreținerea bazei de date, precum și accesul controlat la baza de date. Un SGBD oferă
următoarele facilități pentru crearea și exploa tarea bazelor de date:
– facilități 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;
– facilități 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 pr in intermediul unui limbaj de control DCL (Data
Control Language) care asigură:
– sistem de securitate, previne accesarea bazei de date de către utilizatori
neautorizați;
– sistem de integritate, menține concordanța datelor stocate în baza de date;
– sistem de control al concurenței, permite accesul partajat la baza de date;
– sistem de control al refacerii, permite recuperarea bazei de date în urma
unor
defecțiuni hard sau soft;
– mecanism de vizualizare, prin care u n utilizator poate vedea acea parte a bazei
de
date care îl interesează.
În majoritatea produselor comerciale de baze de date , cele trei limbaje se regăsesc reunite
în cadrul unui singur limbaj (spre exemplu limbajul SQL).
4.1.3. Adm inistratorul bazei de date
Administratorul bazei de date referit prescurtat DBA (Data Base Administrator),
este o persoană sau un grup de persoane care coordonează și răspunde de ansamblul activităților privind baza de date, începând din faza de proiectare și continuând cu
celelalte etape pe întreaga perioadă de viață a bazei de date. Astfel, în faza de proiectare a bazei de date, administratorul stabilește SGBD-ul ce va fi utilizat, echipamentele
necesare, structurile de date plecând de la necesitățile de informație ale tuturor
utilizatorilor bazei de date, drepturile de acces la date ale fiecărui utilizator. Rezultatul
fazei de proiectare este concretizat prin elaborarea modelului conceptual (schema
generală a bazei de date), modelului extern (subschema p roprie fiecărui utilizator) și
stabilirea modalităților 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,
administratorul va menține permanent legătura cu utilizatorii acesteia pentru rezolvarea
cerințelor utilizatorilor și impun erea unei discipline în vederea alinierii la standardele
existente. Administratorul va realiza, ori de câte ori se impune, reorganizarea structurii
fizice a datelor în vederea optimizării parametrilor de funcționare a întregului sistem și va
stabili proced uri 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 prevăzute [12] și alte mecanisme și anume: evidența de auditare, criptarea da telor.
Evidența de auditare constă dintr -un fișier în care sistemul înregistrează automat
toate operațiile efectuate asupra datelor, fișier ce va putea fi consultat de către persoane autorizate pentru a verifica efectuarea unor operații neautorizate. O înr egistrare din
evidența de auditare va conține următoarele informații: textul sursă al operației neautorizate, terminalul de la care a fost lansată operația, utilizatorul care a lansat
operația, data și ora operării, obiectele bazei de date afectate, imagin ile datelor afectate
înainte de efectuarea operației, imaginile datelor afectate după efectuarea operației.
Pentru a preveni accesul unor intruși la baza de date, care încearcă să
ocolească sistemul, se utilizează criptarea datelor, mecanism ce constă în stocarea și
transmiterea datelor pe căile de comunicație 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).
4.1.4. Proiectarea securității bazelor de date și a fișierelor
Securitatea este abordată din mai multe puncte de vedere, dar cea referitoare la
baze de date și la fișiere presupune luarea unor măsuri pentru reconstituirea datelor
pierdute sau preluate eronat, p recum și pentru accesul neautorizat sau incomodarea până
la a face imposibilă citirea datelor, prin criptare, atunci când ele sunt accesate ilegal.
Așadar două aspecte vor fi relevante: reconstituirea datelor și criptarea lor [1].
Reconstituirea datelor este des asociată cu existența fișierelor de tip back -up, însă
în practică este posibilă și reconstituirea fără apelarea la acest tip de fișiere. În vederea
controlării corectitudinii datelor tranzacționate se apelează la fișiere cu rol special, care
conțin un istoric, în ordine cronologică, al schimbărilor și accesărilor efectuate asupra
fișierelor sau bazelor de date. Cu ajutorul lor se pot reconstitui fișierele distruse, dar și la
verificarea corectitudinii operațiunilor de actualizare [1].
Securitatea p rin criptografiere se referă la asigurarea transformării datelor de
comunicat într -o formă neinteligibilă pentru toți ceilalți receptori, exceptându -l pe cel
autorizat. Criptarea a devenit una dintre cele mai puternice modalități de asigurare a
securității datelor. Ea poate fi realizată prin sistemul de operare sau prin SGBD, dar și
prin rutine create de către specialiști [1].
Având în vedere aspectele prezentate mai sus, criteriile avute în vedere în alegerea
unui anumit tip de SGBD sunt [2]:
a) Porta bilitatea SGBD -ului. Prin aceasta înțelegem 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ă conțină
cât mai puține elemente legate de echipament;
Portabilitatea sistemului de gestiune privit prin prisma portabilitații datelor se
referă la posibilitatea de a folosi o serie de date utilizate în cad rul unui sistem informatic
de către un alt sistem informatic, deci posibilitatea integrării fișierelor deja existente în
cadrul unui alt sistem.
b) Costul sistemului. Acest criteriu trebuie privit prin prisma: timpului de ocupare a
unității centrale; costului de întreținere și dezvoltare; resurselor hard imobilizate; costului de adaptare și trecere pe un nou sistem de calcul; costul documentației etc.
c) Facilitățile de implementare, întreținere și exploatare a bazei de date. Acestea
sunt reflectate prin: modalitatea de descriere a datelor; tehnicile de organizare și regăsire
a datelor, care să permită un acces cât mai rapid la orice informație; timpul cât mai redus
pentru actualizare, căutare și răspuns la cererile de informare; editarea operativă a celor
mai variate tipuri de situații solicitate de către utilizator; posibilitatea de inserție a unor
programe de aplicație, programe de validare de date, de actualizare, rutine statistice,
rutine de sortare, rutine de prezentare grafică a ieșirilor etc.
d) Po sibilitatea gestionarii structurilor complexe de date.
e) Multitudinea metodelor de acces. In funcție de cerințele proprii aplicației,
sistemul va trebui să suporte interogări sau actualizări în timp real având proceduri de tip conversațional.
f) Protecția și securitatea datelor din bază.
g) Specificul aplicației. Este cunoscut faptul că programele sunt orientate pe
aplicații, cum ar fi: programarea producției, aprovizionare -desfacere, optimizări,
prognoze etc.
Toate aceste criterii de alegere pot fi cor elate cu o serie de factori complementari
cum ar fi: mentenanța sistemului, facilitățile ce le oferă administratorului bazei de date, calitatea documentației oferite de furnizori, asistență în implementarea sistemului și în
pregătirea utilizatorilor etc.
Toți acești factori alături de criteriile enunțate pot să influențeze succesul în
implementarea SGBD-ului și eficiența economică pe ansamblul sistemului informatic.
În cele ce urmează se vor prezenta o serie de aspecte privind utilizarea limbajului
SQL pe ntru crearea bazei de date, definirea utilizatorilor și acordarea drepturilor de acces,
definirea interogărilor bazei de date, precum și exemple practice sub SGBD ORACLE.
4.1.5. Limbajul SQL – Crearea, Administrarea și Interogarea bazelor de date
relațio nale
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
răspândite limbaje pentru SGBD-urile relaționale. Limbajul SQL, ca limbaj de interogare
a bazelor de date relaționale, este construit pe baza a două formalisme abstracte enunțate
în cele ce urmează.
1. Algebra relațională – prin care interogările sunt exprimate prin aplicarea unor
operatori unari sau binari care constituie primitive ce acționează asupra relațiilor,
rezultatul interogărilor fiind tot relații, ceea ce permite asocierea și imbricarea acestor
operatori pentru a forma interogări complexe. Operatorii algebrei relaționale se împart în
două grupe și anume:
– operații pe mulțimi (Reuniunea, Intersecția, Diferența, Produsul
cartezian);
– operatori relaționali speciali (Selecția, Proiecția, Cuplarea (JOIN),
Diviziunea).
2. Calculul relațional – prin care interogările descriu mulțimea tuplelor rezultat prin
specificarea unui predicat (co ndiție) care trebuie satisfăcut de aceste tuple.
Începând din 1986 limbajul SQL a devenit standard ANSI pentru limbajele de
interogare ale bazelor de date relaționale fiind utilizat atât în cadrul unor SGBD-uri
complexe cum ar fi SGBD ORACLE (liderul mond ial în domeniul bazelor de date), cât și
în cadrul unor SGBD -uri de complexitate redusă cum ar fi cele din familia xBase (Dbase
IV, FoxPro).
Standardul SQL utilizat pînă la începutul anului 2000 este cel realizat în 1992 și
cunoscut sub numele de SQL’92 s au SQL2.
Noul standard SQL3 lansat în 1999 are în vedere o serie de extensii față de SQL2
după cum urmează:
– facilități orientate obiect – posibilitatea de definire de către utilizator a tipurilor
abstracte de date care să permită descrierea de metode, identitatea obiectelor, subtipuri și moștenire, polimorfism etc.;
– structuri de control – pentru a conferi limbajului completitudine de calcul (IF, FOR,
WHILE, etc.) pentru a deveni un limbaj de sine stătător a cărui putere de expresie să
nu mai fie limitată la nivelul limbajelor relaționale;
– facilități pentru exprimarea prelucrărilor recursive;
– facilități de comunicare în rețea;
– facilități de prelucrare distribuită (mecanisme pentru crearea, memorarea și execuția procedurilor la nivelul serverelor de date – stored procedures);
– facilități multimedia;
– facilități 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>
Adăugarea relațiilor într -o bază de date –comanda CREATE TABLE are sintaxa:
CREATE TABLE <nume relație>[(<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ă relație poate fi creată și ca rezultat al unei operații de interogare astfel:
CREATE TABLE <nume relație> (<nume atribut> <tip dată>,…) AS <subinterogare>
Adăugarea/modificarea de atribute pentru o relație existentă se realizează cu
comanda:
ALTER TABLE <nume relație> ADD|MODIFY (< nume atribut> <tip dată>,…)
Ștergerea unei relații se realizează cu comanda:
DROP TABLE <nume relație>
Comenzi pentru optimizare a interogărilor
Una din principalele căi de optimizare a timpilor de interogare a unei baze de
date este indexarea. Un index poate fi privit ca o relație cu două atribute și anume:
– primul atribut conține valorile atributelor relației după care se crează in dexul;
– al doilea atribut conține un pointer (adresa) la locația tuplelor
corespunzătoare.
Crearea unui index se realizează cu comanda:
CREATE [UNIQUE] INDEX <nume index>
ON <nume relație>(<nume atribut>[ASC|DESC],…)
Dacă pentru atributele utilizate în clauza WHERE a unor instrucțiuni SQL au fost creați
indecși, atunci aceștia vor fi utilizați în vederea optimizării timpului de prelucrare.
Decizia de utilizare sau nu a unui index este luată de limbajul SQL și nu de utilizator.
Pentru aceasta fiecare m odel de limbaj SQL dispune de o componentă numită
optimizator, care examinează interogarea și decide care este modul optim de obținere a
rezultatului.
O altă tehnică de optimizare a interogărilor este tehnica “clustering” disponibilă
în ORACLE și care constă în gruparea tuplelor din mai multe relații și stocarea lor în
aceeași zonă pe disc.
Controlul datelor (comenzi DCL)
Vederi
O vedere este o relație virtuală, definită plecând de la alte relații din baza de date
și care nu conține date și deci nu ocupă sp ațiu fizic pe disc. Vederile se definesc în două
scopuri și anume:
– pentru a simplifica accesul utilizatorilor la date;
– pentru a asigura protecția și securitatea datelor –fiecărui utilizator fiindu -i permis
acces la o porțiune a bazei de date și putând efectua doar anumite operații (conform
drepturilor de acces specificate cu comenzile GRANT/REVOKE).
Asupra unei vederi se pot efectua aceleași operații ca și asupra unei relații cu deosebirea
că vederile nu conțin date și că orice modificări efectuate asupra d atelor sunt reflectate și
în vederi. Astfel, asupra unei vederi se pot realiza operațiile:
– 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);
– adăugare 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 Stoc uriD1(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”
Interogarea vederii se va realiza cu comanda
SELECT * FROM StocuriD1
Utilizarea opțiunii WITH CHECK OPTION asigură faptul că nici o tuplă nu va fi
adaugată sau actualizată cu instrucțiunile INSERT, UPDATE, dacă nu sunt respectate
condițiile specificate în clauza WHERE a instrucțiunii SELECT din definiția vederii.
Pentru acordarea sau retragerea drepturilor de acces la baza de date prin
intermediul vizualizărilor 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 securității datelor presupune definirea drepturilor de acces ale
utilizatorilor și protecția sistemului la accesul neautorizat. În acest sens asigurarea
securității se realizează pe două niveluri și anume:
– nivelul 1 – acordarea dreptului de acces la sistem;
– nivelul 2 – acordarea dreptului de acces la nivel de relații.
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 relație în sistemele multi -user trebuie
precizat utilizatorul care a creat relația (proprietarul relației). Fiecare utilizator are
drepturi doar asupra propriilor relații, iar drepturi asupra unor relații create de alți
utilizatori pot f i 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 dicționarul de date și sunt gestionate de către 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 oricărei operații asupra
oricărei relații din baza de date;
– CONNECT – conferă utilizatorului dreptul de a a face interogări ( SELECT) și
actualizări ( INSERT, UPDATE, DELETE) asupra relaț iilor create de alți
utilizatori, însă nu permite utilizatorului să creeze relații ( CREATE) sau să
șteargă relații create de alți utilizatori ( DROP );
– RESOURCE – conferă utilizatorului drepturile ce rezultă din autorizarea
CONNECT și în plus dreptul de a cr ea relații ( CREATE) și de a șterge relații
ce îi aparțin ( DROP ).
Unui utilizator îi pot fi acordate mai multe tipuri de autorizări în cadrul unei singure comenzi GRANT .
Parola stabilită pentru un utilizator poate fi modificată printr -o comandă GRANT
ulterioară spre exemplu astfel:
GRANT RESOURCE TO <nume utilizator> IDENTIFIED BY <noua parolă>
Unui utilizator căruia i s -a acordat un tip de autorizare îi pot fi acordate și alte tipuri de
autorizare prin comenzi GRANT ulterioare.
Retragerea autorizărilor 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 relații se utilizează
comenzile GRANT respectiv REVOKE cu următ oarea sintaxă:
GRANT ALL|<drept de acces>,… ON <nume relație>
TO <nume utilizator>|PUBLIC [WITH GRANT OPTION]
respectiv
REVOKE ALL|<drept de acces>,… ON <nume relație> FROM <nume
utilizator>|PUBLIC
Privilegiile (drepturile de acces) pot fi acordate sau retrase de următoarele categorii de
utilizatori:
– utilizatorii cu nivel de autorizare DBA;
– proprietarii relațiilor;
– utilizatorii autorizați cu opțiunea 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 rândul
său să acorde aceleași drepturi sau mai puține altor utilizatori.
În ORACLE pot fi acordate următoarele drepturi de access asupra relațiilor:
SELECT, INSERT, DELETE, ALTER, UPDATE, CREATE,DROP pentru tabele și indecși.
Drepturile de acces pot fi acordate asupra întregii relații, sau doar asupra
anumitor atribute ale relației.
Exemple:
Acordarea tuturor drepturilor de acces utilizatorilor Ionescu, Popescu, asupra
relației Persoane care aparține utilizatorului Vasilescu se realizează prin comanda:
GRANT ALL ON Vasilescu.Persoane TO Ionescu,Popescu
Acordarea tuturor utilizatorilor, drepturile SLECT,INSERT,UPDATE asupra
relației Produse aparținând utilizatorulu i Ionescu se realizează cu comanda:
GRANT SELECT,INSERT,UPDATE ON Ionescu.Produse TO PUBLIC
Acordarea privilegiilor SELECT,UPDATE numai asupra atributelor CodP, Denp
din relația Produse aparținând utilizatorului Ionescu , utilizatorului Popescu cu condiția ca
acesta la rândul său să poată acorda oricărui alt utilizator aceleași drepturi sau mai puține,
se realizează cu comanda:
GRANT SELECT,UPDATE ON Ionescu.Produse(CodProdus,Denumire)
TO Popescu WITH GRANT OPTION
Retragerea drepturilor de a cces INSERT,DELETE asupra relației Persoane
aparținând utilizatorului Vasilescu , utilizatorului Ionescu se realizează cu comanda:
REVOKE INSERT,DELETE ON Vasilescu.Persoane FROM Ionescu
Instrucțiuni pentru inserarea și actualizarea datelor în tabele
Inserarea datelor – comanda INSERT are următoarea sintaxă:
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 completând toate atributele)
INSERT INTO Persoane(Nrcrt,Nume,Prenume) VALUES (2,’Ionescu’,’Ana’)
(adaugă o înregistrare în Persoane completând numai atributele Nrcrt,Nume, Pr enume)
Pentru a insera în tabela PersF (Nrcrt,Nume,Prenume) toate înregistrările 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 relație>|<nume vedere>
SET <nume atribut> = <expresie>,…[WHERE <condiție>]
Condiția din clauza WHERE definește tuplele care vor face obiectul actualizării. Clauza
WHERE poate conține ș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 prețului cu 20% pentru produsele vândute cu factura 120).
Dacă în comanda UPDATE clauza WHERE este omisă, actualizarea se va efectua asupra
tuturor tuplelor rela ției.
Ștergerea datelor – comanda DELETE are sintaxa:
DELETE FROM <nume relație>|<nume vedere> [WHERE <condiție>]
unde <condiție> poate fi o condiție simplă, o expresie sau o subinterogare.
Exemple:
DELETE FROM Stocuri WHERE Cant = 0
(șterge toate în registrările din tabela Stocuri pentru care câmpul Cant are valoarea 0).
DELETE Oferte
(șterge toate înregistrările din tabela Oferte).
Comenzi pentru gestiunea tranzacțiilor
Tranzacția este o succesiune de instrucțiuni SQL grupate într -un bloc de
instru cțiuni utilizate pentru actualizarea și/sau interogarea datelor din baza de date. O
tranzacție se consideră încheiată după realizarea tuturor operațiilor pe care le conține.
Operațiile conținute într -o tranzacție pot fi realizate efectiv în baza de date sau nu, fie
automat de către sistem după fiecare operație, fie printr -o comandă explicită dată după o
succesiune de operații. Astfel salvarea automată de către sistem a modificărilor este
realizată prin comanda
SET AUTOCOMMIT ON
Dacă inițial a fost specificată comanda SET AUTOCOMMIT OFF, salvarea modificărilor
efectuate asupra datelor se realizează prin comanda COMMIT, iar abandonarea modificărilor se realizează prin comanda ROLLBACK.
Blocul de operații ce definesc o tranzacție poate fi delimitat de instrucțiunile :
BEGIN TRANSACTION
END TRANSACTION
Problemă rezolvată
Se lansează în execuție 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 instrucțiunea 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ă înregistrări (figura 5.4).
Figura 5.1. Lansare SQL Plus ORACLE pentru utilizatorul system
ORCL
Figura 5.2. Creare utilizator U1 și acor dare privilegii CONNECT, RESOURCE
ORC
Limbajul SQL – Interogarea bazelor de date – Fraza SELECT
Interogarea bazelor de date în limbajul SQL se realizează cu ajutorul unei singure
instru cțiuni și anume instrucțiunea SELECT având următoarea sintaxă:
SELECT [DISTINCT] <lista atribute>|*
FROM <lista relații>
[WHERE <condiție>]
[GROUP BY <lista atribute de grupare>]
Figura 5.4. Creare tabelă Produse și inserare două înregistrări
[HAVING <condiție>]
[ORDER BY <atribut1 de ordonare> [ASC]|DESC,…]
[UNION <f rază SELECT>]
<lista atribute> este o listă ce conține nume de atribute (câmpuri) sau expresii
construite utilizând atribute, separate prin caracterul “,” și care fac parte din relațiile
(tabele, vederi) enumerate în <lista relații> din clauza FROM . Numele fiecărui atribut sau
expresii din <lista atribute> va fi afișat în capul de tabel ce reprezintă rezultatul
interogării, fiecare atribut sau expresie putând primi un alias folosind specificarea AS
<alias>.
Caracterul ‘*’ specifică faptul că se extrag toate atributele tabelei precizate în
clauza FROM .
Clauza DISTINCT precizează faptul că în relația rezultat nu pot apărea duplicate
(tuple identice).
Clauza WHERE precizează condițiile de interogare (condiții care trebuie să fie
satisfăcute de tuplele interogat e, condiții de cuplare relații ( JOIN , relații între tabele). În
clauza WHERE pot fi utilizați operatori logici ( AND, NOT, OR), predicate ( IN, LIKE,
BETWEEN, EXISTS, ALL, ANY), operatori aritmetici (+, -, **, /, *), operatori de
comparare (=, #,<, >, <=, >=, <>), parantezele ( ) pentru schimbarea ordinii de prioritate a
operațiilor, operatorilor, funcții și alte subinterogări SELECT, pentru construirea de
expresii pe care trebuie să le îndeplinească tuplele ce constituie rezultatul interogării.
Predicatul IN permite specificarea unei liste pentru domeniul de căutare pentru un atribut,
iar predicatul BETWEEN permite specificarea unui interval pentru domeniul de căutare a
valorilor unui atribut, fiind echivalent cu o condiție de forma:
<atrib ut> >= <limita inf. interval> AND <atribut> <= <limita sup. interval>
Exemple:
Fie tabela Persoane(Nrcrt,Nume,Prenume, Datan, Sexul, Adresa)
Selectarea tuturor înregistrărilor din tabela Persoane pentru care primele 7 caractere din
câmpul Adresa sunt ‘Suceava’ sau ‘Rădăuți’ se realizează cu comanda:
SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) IN (‘Suceava’,‘Rădăuți’)
Interogarea de mai sus este echivalentă cu interogarea:
SELECT * FROM Persoane
WHERE SUBSTR(Adresa,1,7) = ‘Suceava’ OR SUBSTR(Adresa,1,7 ) =
‘Rădăuți’
Selectarea tuturor înregistrărilor din tabela Persoane pentru care data nașterii 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 selecția șirurilor de caractere care conțin anumite caractere
specificate prin intermediul unei măști definite cu ajutorul unor caractere speciale (%, _
în dBASE IV, FoxPro, ORACLE, sau *, ? în INFORMIX)
Exemple:
SELECT * FROM Persoane WHERE Nume LIKE ‘%a’
(selectează toate înregistrările 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 înregistrările din
tabela Persoane pentru care prima literă din Nume este ‘A’ iar ultima literă este ‘u’).
SELECT Nume FROM Persoane WHERE Nume LIKE ‘_o%’
(selectează valorile atributului Nume pentru toate înregistrările din tabela Persoane pentru
care prima literă din Nume este orice literă, a doua literă din Nume este litera ‘o’ și începând din poziția a treia numele po ate conține orice litere.)
Predicatele ALL, ANY, EXISTS se utilizează pentru interogări ce conțin subinterogări, în
vederea verificării anumitor condiții ce trebuie îndeplinite între rezultatele interogării și rezultatele subinterogării.
Clauza GROUP BY – realizează gruparea tuplelor unei relații pe baza valorilor
unui atribut sau grup de atribute și generează o singură tuplă pentru fiecare grup de tuple
având aceeași valoare pentru atributele care definesc grupul. Atributele care definesc
grupul trebuie obligatoriu să se regăsească în lista atributelor interogate <lista atribute>.
De asemenea asupra unor atribute pot fi aplicate funcții 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>) – numărul înregistrărilor pe gr upare după <atribut>.
Observație. <atribut> poate fi fie un atribut, fie o expresie definită utilizând atribute ale
tabelei.
Clauza HAVING , opțiune a clauzei GROUP BY , este o formă specială a clauzei
WHERE întrucât 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 având aceeași valoare în
câmpul CodDep și numărul înregistrărilor din fiecare grup definit de câmpul CodDep și
afisează rezultatele sub formă de tabel având coloanele CodDep, Valoare, Contor)
SELECT CodDep,CodP,MAX(Pret) FROM Stocuri
GROUP BY CodP HAVING MAX(Pret) < 150000
(selectează pentru fiecare grupă de înregistrări având aceeași valoare în câmpul CodP,
înregistrarea cu prețul maxim mai mic decât 150000)
CLAUZA ORDER BY – PERMITE PRECIZAREA ORDINII D E AFIȘARE A
DATELOR ASTFEL:
ORDER BY <nu me atribut 1> [ASC]|DESC,<nume atribut
2>[ASC]|DESC,…
Exemplu:
SELECT * FROM Persoane ORDER BY Datan DESC,Nume
(afișează toate înregistrările din tabela Persoane în ordine descrescătoare după data
nașterii și în cadrul aceleiași date a nașterii crescător d upă Nume)
Clauza UNION – permite obținerea rezultatului a două sau mai multe interogări
printr -o singură instrucțiune 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
înregistrările pentru care CodDep = ‘Dep01’, la care adaugă tuplele
(CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate înregistrările pentru care Cant
>= 100).
Pentru a nu se elimina tuplele duplicat trebuie specificat UNION ALL.
Pentru a schimba ordinea de afișare a tuplelor extrase se poate utiliza clauza ORDER BY aplicată doar relației finale și nu asupra fiecărei fraze SELECT.
Regăsirea datelor din două sau mai multe re lații
Interogarea datelor din două sau mai multe tabele (relații) presupune existența
unor câmpuri comune pentru realizarea operației de cuplare (operatorul JOIN). În fraza
SELECT operația de cuplare este definită în clauza WHERE sub forma:
<nume tabela1>. <cheie1> = <nume tabela2>.<cheie2>
(unde <cheie1>, <cheie2> reprezintă câmpurile ce identifică înregistrările corespondente în cele două tabele).
Pentru exemplificare pe lângă tabela Stocuri mai considerăm tabela Produse(CodP, DenP, DesP).
SELECT Produse.C odP,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 combinațiile posibile între tuplele celor
două tabele (produsul cartezian).
Fiecărei tabele i se poate atribui un alias astfel încât fraza de mai sus este echivalentă cu
fraza:
SELECT A.CodP,DenP,UmP,Cant,Pret FROM Pro duse A,Stocuri B WHERE A.CodP =
B.CodP
În anumite situații poate fi necesară corelarea (cuplarea) unei relații (tabele) cu ea
însăși. Spre exemplu dacă presupunem că în tabela Stocuri unele produse pot apare de
mai multe ori cu prețuri diferite și ne inter esează pozițiile cu prețul minim, formulăm
următoarea 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 instrucțiu ni SELECT imbricate
care vor fi prezentate în detaliu în cele ce urmează.
Instrucțiuni SELECT imbricate
Limbajul SQL oferă posibilitatea construirii unor interogări complexe prin
includerea în clauza WHERE a unei instrucțiuni SELECT, a altei instrucțiuni SELECT
(numită sub -interogare sau ‘inner’) astfel:
SELECT <lista atribute> FROM <lista relații>
WHERE <condiție> (<sub -interogare>)
La rândul ei sub -interogarea poate conține în clauza WHERE o altă instrucțiune SELECT
obținând astfel o interogare complexă constituită din instrucțiuni SELECT imbricate pe
un număr oarecare de nivele. Instrucțiunea SELECT interioară generează valori pentru
condiția de căutare a instrucțiunii SELECT exterioare care o conține (numită și ‘outer’). O
sub-interogare poate return a o singură valoare, sau poate returna mai multe valori.
În ce privește ordinea de evaluare a interogărilor pot exista :
– sub-interogări simple – în care interogarea interioară este evaluată prima, independent
de interogarea exterioară, iar rezultatul inter ogării interioare este utilizat de
interogarea exterioară;
– sub-interogări corelate – în care interogarea exterioară transmite repetat câte o valoare
pentru interogarea interioară, care în baza valorii primite, parcurge tuplele relației și
transmite interog ării exterioare rezultatul obținut. Astfel de interogări realizează
corelarea unei relații cu ea însăși și sunt cele mai performante.
Spre exemplu dacă presupunem că în tabela Stocuri unele produse pot apare de mai multe
ori cu prețuri diferite și ne inter esează pozițiile cu prețul minim, formulăm următoarea
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-interogări simple care returnează o singură valoare – pot fi ut ilizate în
interogări imbricate având sintaxa:
SELECT <lista atribute> FROM <lista relații>
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
(afișează produsele pentru care există stocuri peste medie, ordonate pe depozite).
Sub-interogari simple care returneaza mai multe valori pot fi utilizate în
interogări imbricată care utilizează în clauza WHERE codiții care generează o mulțime de
valori folosind unul din predicatele: (NOT)IN, (NOT)ANY, (NOT)ALL, (NOT)EXISTS.
Exemplu:
SELECT * FROM Produse WHERE CodP IN (SELECT CodP FROM Facturi WHERE
Numar IN
(SELECT Numar FROM Beneficiari,Com enziWHERE Beneficiari.Nume=’Ionescu’
AND
Beneficiari.Cod_Beneficiar=Comenzi.Cod_Beneficiar))
Predicatul ANY poate fi utilizat în combinație cu oricare din operatorii <, >, =,
<=, >=, != și permite verificarea dacă valoarea unui atribut satisface condiția 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 d in clauza
WHERE sunt <, >, <=, >= decât toate valorile generate de interogarea interioară (acest
predicat nu poate fi utilizat cu operatorul = ce ar corespunde cazului banal în care toate interogările 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 relației există tuple care
satisfac condiția din interogarea interioară (deci EXISTS permite specificarea mai multor
atribute în interogarea interioară).
Astfel spre exemplu instrucțiunea:
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 .
4.2. Proiectarea programelo r și a procedurilor
Proiectantul de soft are ca principală misiune definirea și structurarea
componentelor care vor forma un tot unitar, astfel încât prin acestea să se obțină un
proiect soft operațional. Proiectantul va grupa funcțiile ce trebuie să fie i nterconectate și
va descrie modalitățile de realizare a legăturilor. După proiectanții de soft vor interveni
programatorii, pentru transpunerea în realitate a proiectului. Ei vor controla intrările,
prelucrările și ieșirile din sistem prin intermediul prog ramelor [1].
Softul are două componente de bază instrucțiunile și modulele. Instrucțiunile sunt
operațiuni elementare executate de calculator prin gruparea și selecția controlată a
acestora pentru atingerea obiectivelor funcțiilor de prelucrare orientate pe probleme.
Instrucțiunile constituie cel mai jos nivel al operațiunilor ce pot fi executate de către un
limbaj de programare. Blocurile de instrucțiuni sunt astfel grupate încât să constituie
anumite structuri executabile de calculator. De modul în care sunt grupate instrucțiunile
pentru a da naștere unor structuri standard ale programelor, de relațiile dintre instrucțiuni,
de aranjamentul acestora depinde calitatea softului proiectat [1].
Modulul – este o colecție sau o formă grupată de instrucțiuni de programe sursă.
Modulele se pot grupa pentru a forma programele.
Programul, în concepția diverșilor autori, are semnificații diferite. El este definit
ca:
– un set de instrucțiuni cu ajutorul cărora se efectuează prelucrări 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 execuției pe calculator,
deci o reprezentare a acestora (algoritmi și date) ținând cont de restri cțiile impuse de
calculator;
– o realizare a unei funcții f care, dată fiind o mulțime de date x, specifică valoarea
y=f(x);
Prin algoritm se înțelege o metodă de soluționare a unei clase de probleme,
reprezentată de o succesiune finită de operații bine defi nite, numite instrucțiuni.
Prin prisma complexității lor programele se pot clasifica [1]:
– programe simple (1000 de linii)
– programe de complexitate medie(10 000 de linii)
– programe complexe (peste 100 000 de linii) au numeroase module cu legături
complexe.
Pentru ca programele să fie caracterizate prin eficiență, fiabilitate, flexibilitate,
inteligibilitate, în procesul elaborării lor trebuie să se respecte anumite principii [1]:
– principiul conformării, potrivit căruia programele trebuie să fie elaborate în
conformitate cu cerințele utilizatorului;
– principiul completitudinii constă în realizarea descrierilor complete ale obiectivelor programului pe toate nivelurile ierarhice de descompunere;
– principiul abstractizării se referă la elaborarea funcției programu lui, ținând cont de
elementele esențiale, făcându -se abstracție de detaliile nesemnificative;
– principiul modularizării 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, deși mai corect ar fi să se
numească tehnici de programare [1].
Metoda programării clasice are la bază construirea monolitică a logicii
programului, fără intenții de structurare. Programul este privit în totalitatea lui și analizat
direct la nivelul operațiilor elementare pe care le implică executarea lucrării care se
elaborează .
Programarea modulară constă în descompunerea programului, chiar din faza de
proiectare, în module ușor de întrebuința t. Fiecare modul este apoi analizat ca un program
distinct și rezolvat ca atare [1].
Metoda programării structurate constă în faptul că oferă o rezolvare standardizată
și structurată, în mod unitar, a programelor, reprezentând o ridicare a activității de
programare la nivelul activității industriale, fundamentată pe o metodologie științifică.
Programarea structurată este caracteristică dezvoltării sistemelor pe baza diagramelor fluxului de date și utilizează limbaje structurate. Ea presupune o separare înt re structurile
de date și codul funcțiilor care le prelucrează.
Metoda programării orientate -obiect – constă în abordarea naturală a lumii reale,
folosind componente modularizate și eliminând restricțiile impuse de mediul de
programare. Se definesc concept e noi de tip, clasă, moștenire, etc [Udric ă M., 2000].
4.2.1. Atributele modulelor
La nivelul softului proiectat, componenta de bază este modulul. El este o colecție
sau o formă grupată de instrucțiuni ale programului sursă. La rândul lor, modulele se pot
grupa pentru a forma programe.
Modulele programelor au următoarele caracteristici [1]:
– Un modul este format dintr -un grup de instrucțiuni care sunt contigue din punct de
vedere fizic și sunt executate ca o unitate distinctă;
– Grupurile de instrucțiuni c are formează un modul au începuturi și sfârșituri bine
definite;
– În majoritatea cazurilor, grupul de instrucțiuni are doar un punct de intrare și unul de
ieșire;
– Un modul poate fi un program sau un subprogram distinct compilat sau o procedură
internă a unu i program.
Un modul are trei componente de bază: funcția, logica și interfețele.
Funcția unui modul constă în transformarea datelor prin procesul de execuție a
acestuia. Funcția este tratată în regimul cutiilor negre, ea fiind văzută 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 intrările și ieșirile modulului respectiv [1].
La nivelul softului, referirea la un modul este în același timp o referir e la funcția
lui. La nivelul cel mai de sus, modulele au funcții orientate spre problema de rezolvat, în
timp ce modulele aflate pe nivelurile mai de jos au funcții orientate spre prelucrările pe
care le realizează [1].
În diagrama de structură, folosită pentru reprezentarea grafică a proiectelor soft, un
modul este reprezentat printr -o casetă (dreptunghi) ce poartă denumirea funcției
îndeplinite.
La atribuirea numelui unui modul trebuie să se țină cont de faptul că acesta trebuie
să surprindă at ât funcția proprie, cât și pe cele ale subcomponentelor de ordin inferior. Se
recomandă evitarea conjuncțiilor din structura numelor, deoarece ele ar sugera necesitatea
folosirii mai multor module [1].
Logica modulului descrie prelucrările care au loc în interiorul acestuia [1].
La nivelul programării, preocuparea este, în esență, legată de logica modulului,
algoritmii de prelucrare, redați sub diverse forme – scheme logice, pseudocod, tabele de
decizie, arbori de decizie sau combinații ale acestora – sunt concepuți pentru prezentarea
modului de transformare a intrărilor în ieșiri. Pașii algoritmilor se vor transforma în
instrucțiuni ale limbajelor de programare [1].
Interfețele sunt conexiuni sau cuplaje între module. Interfețele modulelor sunt
utilizate pentru stabilirea căilor prin care să se transfere controlul de la un modul la altul
[1].
Conexiunile dintre module se înregistrează pe două planuri:
– al transferării controlului de la un modul la altul;
– al transmiterii datelor de la un modul la altul.
În concluzie, se poate spune că eficiența proiectelor – soft depinde în mare măsură
de eficiența cu care se transferă controlul între module, precum și de metoda folosită
pentru transmiterea datelor între module.
4.2.2. Structurile de control ale programelo r
Proiectul soft trebuie să fie văzut din două puncte de vedere: logic și fizic.
Din punct de vedere logic, modalitatea în care intră în funcțiune modulele este
redată prin structura ierarhică a lor [1].
Din punct de vedere fizic, după ce s- a stabilit s tructura logică, se va pune problema
adaptării prelucrării lor pe calculator, moment în care se va avea în vedere structura
execuției instrucțiunilor, adică a secvențelor după care se declanșează operațiunile din
interiorul modulelor [1].
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: secvența, selecția, iterația sau repetiția. Ele mai sunt cunoscute
și sub numele de structură secvențială, alternativă (simplă și generalizată), repetitivă
(condiționată anterior sau la început și condiționată posterior sau la sfârșit ).
Secvența asigură parcurgerea instrucțiunilor în ordinea în care apar. Selecția
definește alegerea unui grup de instrucțiuni din două sau mai multe posibile. Iterația oferă
posibilitatea execuției repetate a unui grup de instrucțiuni [1].
În elaborarea p rogramelor structurate este necesar să se respecte o serie de
restricții , și anume [1]:
– fiecare element (secvența, selecția, iterația) are un punct de intrare;
– fiecare element are un punct de ieșire unic;
– elementul de iterație permite și o execuție cu factor de repetiție zero, adică excluderea
elementului respectiv din execuție.
Fiecare element din cele enunțate ( secvența, selecția, iterația ) care respectă
restricțiile de mai sus definește un bloc standard. Structura secvențială (liniară) se
prezintă astfe l [1]:
Figura 5.1. Structura secvențială [1]
Selecția (structura de tip IF -THEN -ELSE) sau structura alternativă are următoarea
formă de prezentare [1]:
Figura 5.2. Structura alternativă [1]
Dacă se îndep linește condiția C, se execută operațiile din Bloc -1, altfel se execută
operațiile din Bloc -2; după execuția blocului, se continuă cu instrucțiunea următoare.
Structura alternativă generalizată (de tip CASE-OF) este o generalizare a selecției.
Ea permite a legerea unei variante din mai multe posibile (figura 5.3). C
Bloc 2 Bloc –
NU DA s1
s2
sn
Figura 5.3. Structura alternativă generalizată [1]
Iterația sau structura repetitivă definește execuția repetată a unei operații sau grup
de operații, funcție de rezultatul evaluări i unei condiții. Evaluarea condiției se face fie
înainte, fie după executarea operațiilor.
Structura repetitivă condiționată anterior (de tip WHILE-DO) se reprezintă ca în
figura 5.4
Figura 5.4. Structura repetitivă condiționată anterior [1]
C
Bloc – n Bloc – 2 Bloc – 1
C Bloc –
D
N
Structura repetitivă condiționată posterior (de tip DO UNTIL) are forma dinn
figura 5.5.
Figura 5.5. Structura condiționată posterior [1]
O formă particulară de structură repetitivă condiționată p osterior este structura
repetitivă cu număr definit de pași (de tip DO FOR). Numărul de repetiții este controlat
de o variabilă, numită variabilă de control . În reprezentarea grafică următoare, V este
variabila de control, Vi este valoarea inițială a variabilei de control, iar R este rația (incrementul). O astfel de structură este redată în figura 5.6.
C Bloc – 1
DA
NU
V>Vf V=Vi+
DA NU Bloc – 1 V=Vi
Figura 5.6. Structura repetitivă cu număr definit de pași [1]
În literatura de specialitate, se consideră că structura secvențială, st ructura
alternativă de tip IF-THEN -ELSE și structura repetitivă condiționată anterior sunt
suficiente pentru a defini structura de control a oricărui program. Din acest motiv, cele
trei structuri de control, enumerate mai sus, sunt numite structuri fundam entale sau
structuri de bază.
4.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 p rogram.
Pentru proiectarea programelor, programatorii vor respecta sistemul de cerințe și
restricții impus de etapele parcurse anterior pentru realizarea sistemului informatic. Urmând principiile programării structurate, realizarea programelor se face în următoarele
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 documentației aferente; dezvoltarea versiunii calitative a
produsului program [2].
Specificațiile elaborate în etapele precedente permit definirea problemei de
programat prin care se formulează elementele specifice și se analizează relațiile dintre
aceste elemente, din punct de vedere dinamic sau stat ic.
Descompunerea aplicației se poate face după criteriul funcționalității, motiv pentru
care elementele rezultate se mai numesc și module funcționale . Din punct de vedere al
fluxului datelor pot fi [2 ]:
– module de intrare, care manipulează datele de intr are;
– modulele de ieșire, care furnizează rezultate ale prelucrărilor;
– module de prelucrare, care efectuează diverse operații asupra datelor.
Pe baza unor funcțiuni identificate sau a altor rațiuni de programare, modulele pot
fi divizate în continuare. Scopul acestei structurări funcționale până la nivel elementar este de a identifica funcțiunile sistemului și de a le separa, eventual, în funcțiuni generale
și cu caracter specific aplicației.
Modulele funcționale pot fi descompuse apoi după criteriul omogenității, rezultând
modulele operaționale.
Realizarea modulară a produselor program presupune următoarele acțiunile [2 ]:
– Examinarea modulelor și specificarea succesiunii operațiilor de prelucrare descrise în
acestea.
– Constituirea setului reprezentativ cu date test. Setul de date trebuie sa acopere
întreaga cazuistică a sistemului informațional și să testeze toate ramurile programului.
– Precizarea elementelor de comunicație între module, respectiv stabilirea parametrilor de intrare/iesire în/din fiecare modul.
– elaborarea algoritmii de prelucrare specifici fiecărui modul și structura programelor.
– transcrierea algoritmilor într -un limbaj de programare.
– scrierea codului sursă și obținerea fișierelor executabile.
Prin compararea rezultatelor propuse a fi ob ținute cu cele efectiv furnizate de
aplicația informatică, sunt verificate sintactic și funcțional module din program. Dacă se
realizează identitatea între cele doua categorii de rezultate, operația de testare se
consideră încheiată.
O atenție deosebită t rebuie acordată întocmirii documentației programului cu
observația că în acest sens este recomandată autodocumentarea la nivel de modul.
4.3. Proiectarea sistemelor distribuite
Un sistem de prelucrare distribuită a datelor presupune existența a două sau mai
multor sisteme independente de prelucrare a datelor, numire noduri, interconectate într -o
configurație de rețea. Ele folosesc facilități de comunicare pentru schimbul de informații
și își coordonează activitățile pentru realizarea unui anumit scop. Cu alte cuvinte un
sistem de prelucrare distribuită a datelor permite realizarea activității de prelucrare
automată a datelor într -un mediu de rețea. Într -un astfel de mediu, cooperează trei
componente tehnologice distincte: prelucrarea datelor, comunicarea datelor și rețeaua de
calculatoare. Scopul lor este de a colabora fiecare cu fiecare, astfel încât să se realizeze
obiectivele comune ale organizației [1].
Figura 5.7. Model de bază al unui sistem de prelucrare distribuită a datelor.
Sistemele de pr elucrare distribuită a datelor trebuie să permită:
– posibilitatea de prelucrare independentă;
– o configurație de rețea;
– o posibilitate de transfer a datelor folosind facilități 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 funcționale.
Din punct de vedere financiar se urmărește maxim de profit cu minimum de
cheltuieli. Din punc t de vedere funcțional, scopul este să se realizeze un sistem care să
aibă cele mai bune rezultate [1].
Costul sistemului se regăsește în costurile inițiale pe procesoare,
perifericelor(imprimantă, scanner, etc), cablări, soft -uri, și costuri funcționale
(operaționale) cu distribuirea datelor, cu personalul, întreținerea sistemului, etc. NOD NOD Legătură/canal
Performanța sistemului este apreciată prin prisma productivității și a
eficienței lui. Ea se determină în funcție de cerințele operaționale ale unui sistem de
calcul. Se consideră că performanța este o funcție a [1]:
– timpului de răspuns(intervalul de timp dintre momentul formulării unei cereri de la un
terminal de comunicație -date și obținerea răspunsului în același loc);
– randamentului(cantitatea de date ce poate fi prelu crată de către un sistem de calcul
într-o perioadă de timp);
– calității 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 prelucrării automate a datelor și a comunicațiilor din sistem.
Performanțele sistemului sunt influențate de mai mulți factori, cum ar fi timpul de
răspuns, randamentul, disponibilitatea, siguranța(securitatea sistemulu i).
La proiectarea sistemelor distribuite trebuie avute în vedere două componente
majore:
– Proiectarea nodurilor;
– Proiectarea rețelei de comunicații.
Ordinea de proiectare nu este strictă rămânând la latitudinea echipei de proiectare.
Trebuie să se țină sea ma de posibilitatea proiectării, după ce anumite etape au fost
îndeplinite [1].
Figura 5.8. Principalele module de proiectare a sistemelor de prelucrare distribuită a
datelor [1]
Modele de sisteme distribuite
Calculatoarele personale și stațiile de lucru pot fi utilizate fie ca sisteme de-sine-
stătătoare pentru execuția diferitelor aplicații informatice, fie într -o configurație de rețea.
O rețea locală se bazează pe un set de calculatoare personale, fiecare cu propria memorie, Sisteme PAD
Proiectare
NODURI Proiectare
subsisteme de
Proiectare
INTERFEȚE
astfel încât să poată folosi în comun toate echipamentele și software-ul din rețea. Dintre
toate calculatoarele, există unul sau unele mai puternice pe care se vor afla aplicații
folosite în comun de celelalte calculatoare ale rețelei. Cea mai utilizată arhitectură este
arhitectura client/server.
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
tradițională de accesare a unui co mputer central numit server de către computere aflate la
distanță sau clienți într-o infrastructură de rețea.
Modelul Client /Server implică o entitate software ( clientul ) care efectuează cereri,
acestea fiind îndeplinite de o altă entitate software( serve rul) . 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 informație ( baze de date ), să efectueze
procesări asupra datelor, să controleze peri ferice sau să efectueze cereri adiționale altor
servere. Un client poate face cereri la multiple servere și un server poate deservi mai mulți clienți.
Sursă de informație (Bază de date)
Cerere Procesare (Logică și Aritmeti că)
Client Server Dispozitive (Imprimantă, periferice
partajate)
Rezultatul Servicii(Cereri adiționale altor
servere)
îndeplinirii cererii
Figura 5.9. O tranzacție Client /Server.
Se poate afirma că tehnologia client / server împarte o aplicație în trei componente
de bază: un client, un server și o rețea care conectează clientul la server. Atât clientul cât
ș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. Când se alege un server pentru
mediul de lucru client / server trebuie avute în veder e: scalabilitatea – posibilitatea de
creștere a capacității serverului, în limite rezonabile; toleranța la erori – posibilitatea de
recuperare a contextului calculatorului server după producerea unei disfuncționalități hardware; service și asistență tehnică. Calculatoarele server au utilizări variate în sistemele client / server (există servere de fișiere care asigură spațiul de disc centralizat
care poate fi folosit conform necesităților calculatoarelor client din rețea; servere de
tipărire – care colecte ază informațiile ce urmează a fi trimise către imprimantă de către
calculatoarele client și le asigură tipărirea într -o anumită ordine; servere de baze de date –
calculatoare care rulează un sistem de gestiune a bazelor de date (DBMS), bazat pe SQL;
server ele de aplicații – calculatoare server care rulează programe mari de aplicații).
Sistemele client -server au apărut ca urmare a descentralizării activității din
diverse domenii, ceea ce presupune o repartizare a realizării sarcinilor pe cele două
nivele: c lient, server. De obicei clienții reprezintă utilizatorii finali care vor
comunica cu serverul bazei de date în cadrul unei rețele 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:
– arhitectura de tip server de obiecte – în care se distribuie prelucrarea între cele
două componente (server, client). Serverul este responsabil de administrarea
memoriei și zăvoarelor, efectuarea operațiilor în memoria secundară, securitatea, integritatea și recuperarea bazei de date, executarea procedurilor stocate și
optimizarea interogărilor. Clientul este responsabil de administrarea tranzacțiilor și
realizarea interfeței cu limbajul de programare;
– arhitectura de tip server de pagini – cea mai mare parte a prelucrărilor este
realizată de către client. Serverul este responsabil de memoria secundară și furnizează paginile corespunzător cererilor formulate de client;
– arhitectura de tip server de bază de date – cea mai mare parte din prelucrările
bazei de date este efectuată de către server. Clientul transmite cererea serverului,
primește rezultatele și le transmite aplicației. Este modul utilizat frecvent de către
sistemele relaționale.
În fiecare dintre cele trei cazuri serverul se găsește pe aceeași mașină ca și baza de
date fizică. Clientul se poate afla pe aceeași mașină sau pe una diferită. În cazul
bazelor de date distribuite pe mai multe mașini, clientul va comunica cu câte un server de pe fiecare mașină. De asemenea mai mulți clienți pot comunica
concomitent cu același server (accesul concurent).
Arhitectura tradițională a sistemelor client -server este o arhitectură pe două
nivele (etaje), în care la primul nivel (clientul) se realizează interfața cu utilizatorul și
logica principală a aplicației, iar la al doilea nivel (serverul) se realizează validarea
datelor și accesul la baza de date. Necesitatea rezolvării unor probleme complexe care
presupun accesul la baza de date a unui număr mare de utili zatori, 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ă interfața cu u tilizatorul aplicației;
– nivelul server de aplicație, la care se realizează logica aplicației și prelucrării datelor;
– nivelul server de baze de date, la care se realizează validarea datelor și accesul la baza de date.
Un server de aplicație poate servi mai mulți clienți, fiind conectat fizic atât la nivelul
client cât și la nivelul server de baze de date. Spre exemplu în mediul Web, clientul poate
fi un browser Web, iar serverul de aplicație poate fi un server Web.
Problemă rezolvată
Se consideră baza de date FurnizoriClienți care conține următoarele tabele (în
ACCESS):
PRODUSE (catalog de produse)
Câmp Semnificație Tip dată Dimensiune Observații
Codp Cod produs Number, Integer 4 Cheie primară
Denp Denumire produs Text 20
Desp Descriere produs Hyperlink Referă document
corespunzător
STOCURI (stocurile de produse pe depozite)
Câmp Semnificație Tip dată Dimensiune Observații
Codp Cod produs Number, Integer
Lookup Wizard 4 Lookup Wizard cu
tabela PRODUSE
CodDep Cod depozit Text 2
Ump Unitate de
măsură produs Lookup Wizard 8 Creare și utilizare listă de valori
Cant Cantitate Number, Integer 4
Pret Preț unitar Number, LongInteger 8
FURNIZORI (catalog de furnizori)
Câmp Semnificație Tip dată Dimensiune Observații
Codf Cod furnizor Number, Integer 4 Cheie primară
Denf Denumire
furnizor Text 30
Adresaf Adresa furnizor Text 25
CLIENTI (catalog de clienți)
Câmp Semnificație Tip dată Dimensiune Observații
Codc Cod client Number, Integer 4 Cheie primară
Denc Denumire client Text 30
Adresac Adresa client Text 25
OFERTE (oferte de produse de la furnizori)
Câmp Semnificație Tip dată Dimensiune Observații
Codf Cod furnizor Number, Integer
Lookup Wizard 4 Lookup Wizard cu
tabela FURNIZORI
Codp Cod produs Number, Integer
Lookup Wizard 4 Lookup Wizar d cu
tabela PRODUSE
Ump Unitate de
măsură produs Lookup Wizard 8 Creare și utilizare listă de valori
Pret Preț unitar Number, LongInteger 8
Datao Data ofertei Date 8
Oferta Oferta furnizor Hyperlink Referă document
corespunzător
VANZARI (vânzările de produse pe clienți)
Câmp Semnificație Tip dată Dimensiune Observații
Codc Cod furnizor Number, Integer
Lookup Wizard 4 Lookup Wizard cu
tabela CLIENTI
Codp Cod produs Number, Integer
Lookup Wizard 4 Lookup Wizard cu tabela
PRODU,03SE
Ump Unitate de măsură produs Lookup Wizard 8 Creare și utilizare
listă de valori
Cant Cantitate Number, Integer 4
Pret Preț unitar Number,
LongInteger 8
Să se scrie comenzile SQL pentru realizarea interogărilor de mai jos:
a) Situația stocurilor
b)Situația ofertelor
c) Situația vânzăr ilor
d) Lista produselor pentru care nu există oferte
e) Lista produselor pentru care nu s -au făcut vânzări în perioada [Data1,Data2]
Răspuns:
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*Pre t 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) Câmp CodDep Codp Denp Ump Cant Pret Valoare
Tabela Stocuri Stocuri Produse Stocuri Stocuri Stocuri Cant*Pret
Câmp Codf Denf Adresaf Codp Denp Ump Pret Datao
Tabela Furnizori Furnizori Furnizori Produse Produse Oferte Oferte Oferte
Câmp Codc Denc Adresac Codp Denp Ump Cant Pret Valoare Datav
Tabela Clienti Clienti Clienti Produse Produse Vanzari Vanzari Vanzari Cant*Pret Vanzari
Câmp Codp Denp
Tabela Produse Produse
Câmp Codp Denp
Tabela Produse Produse
BIBLIOGRAFIE
[ 1 ] O p r e a D . – Analiza și proiectarea sistemelor informaționale economice, Ed.
POLIROM, Iași, 1999
[2] Chindea M. E. – Proiectarea sistemelor informatice economice, București, 1999
[3] Chen, P.P. – Entity -Relationship Approach to Systems Analysis and Design,
Amsterdam, North Holland, 1980
[4] Stanciu V. – Proiectarea sistemelor informatice de gestiune , Ed. Cison, București
2000
[5] Vasilescu P., Dunca V. – Proiectarea sistemelor informatice, Ed. Tehnică,
București, 1979
[6] Popescu I. – Baze de date relaționale: proiectare și implementare, Ed. Universității
din București, București, 1996
[7] Balan D., Balan G. – Sistemul info rmațional în gestionarea întreprinderilor , Ed.
Junimea, Iași, 1998
[8] Roger J. – Utilizare ACCESS 95 , Ed. Teora, București, 1995
[9] Udrică M. – Modelarea orientată obiect , Ed. Cison, București, 2000
[10] Brânzei R. – Sisteme informatice, Ed. Unive rsității “Al. I. Cuza”, Iași, 1995
[11] Thomas Connolly, Carolyn Begg, Anne Strachan – Database Systems – A
Practical Approach to Design, Implementation and Management Second Edition
(trad. Ed. Teora: Baze de date Proiectare . Implementare . Gestionare, Buc. 2001)
[12] C. J. Date, An Introduction to Database Systems, 8th Edition, published by Pearson
Education, Inc. Adison Wesley Higher Education, 2004.
[13] Robert Dollinger -Baze de date și gestiunea tranzacțiilor, ClujNapoca, 1998
[14] lector univ. Nicolae Morariu, lector univ. Valeriu Lupu, ing.ec. Ovidiu Hurjui, Baze
de date, ISBN 973 -8293- 83-9, Editura Univ. “Ștefan cel Mare” Suceava,117 p, Suceava,
2003.
[15] Nicolae Morariu, ”Baze de date. Îndrumar de laborator”, ISB N 973-666 -159-8,
Editura Univ. “Ștefan cel Mare” Suceava, 88 p, Suceava, 2005.
[16] Introduction to ORACLE SQL, SQL* Plus and PL/SQL Course Notes, Glenn Maslen, Published by Oracle Corporation UK Ltd. 1992.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Inițierea și planificarea realizării unui sistem informatic………. [610589] (ID: 610589)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.