Proiectarea logic ă a sistemelor informatice [603990]

Proiectarea logic ă a sistemelor informatice

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 și cum va funcț iona. Prezentarea noului
sistem const ă în prezentarea tuturor intr ărilor sistemului, a ie șirilor, precum și a interfe țelor și
dialogurilor.

1. Proiectarea formularelor/formatelor și a rap oartelor
În cadrul 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 detalii le privind formularele/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 asocia t unui flux al datelor de intrare într-un proces
al DFD, iar rapoartele se pot reg ăsi într-un flux al datelor gene rate 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 s unt 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 proiectare logic ă se reprezint ă doar o ciorn ă a formularelor/formatelor, rapoartelor
sau ecranelor, ele fiind privite doar ca structur ă și machetă, pot fi realizate cu ajutorul unui editor de
texte sau un produs program orientat spre grafic ă sub forma unui prototip.

1.1. Proiectarea 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 d ocumentelor și ecranelor furnizate de sistem.
Proiectarea ie șirilor se va face astfel încât s ă servească pentru [11]:
 transmiterea rezultatelor prelucr ării pe calculator util izatorului, î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 programatorului, 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 utilizatorul dac ă informațiile din raport și formatul acestuia sunt
accesibile. Dac ă ieșirile nu corespund cerin țelor utilizatorului, analistul trebuie s ă le modifice. Un

instrument util pentru formatul rapoartelor sau ecrane lor realizate pe calculator îl constituie macheta
imprimantei.
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 realiz are 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 realizeaz ă definitivarea formei și form atului 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.
Alegerea tipului de suport fizic de ie șire (imprimanta, display, disc fix, floppy disc, banda
magnetică etc.) se face în func ție de: timpul de r ăspuns solicitat, amplas area 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.
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 definitivarea formei și formatului de prezentare a situa țiilor finale trebuie s ă ținem seama
de o serie de considerente practice cum ar fi [11]:
 Respectarea unor cerin țe ale factorilor de decizie privind macheta situa ției finale;
 Restricții tehnice;
 Elemente de eficien ță;
 Lizibilitate – spa țiere;

 Utilizarea formularelor pretip ărite;
 Utilizarea monitoarelor;
 Utilizarea generatoarelor de rapoarte.

Respectarea unor cerin țe ale factorilor de decizie privind macheta situa ției finale
O serie de cerin ț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, rapoar te anuale, etc).
Î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 tehnice 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 echipam
ente de reda re a rezultatelor. Exist ă mai multe tipuri de imprimante și console,
ceea ce creeaz ă posibilitatea unei alegeri adecvate a perifericelor destinate ob ținerii diverselor tipuri
de situații finale.
Elemente de eficien ță
În proiectarea situa țiilor finale nu trebuie sa scape aten ției și aspectele 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 optimiz ă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 text pe hard disc sau floppy disc, ur mând imprimarea ulterioara
a acestui fi șier, total sau par țial.

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, împreuna cu titlul și antetul, se afi șează pe următoarele pagini numai dac ă au
intervenit schimb ări în cadrul caracteri sticilor 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ă.

Utilizarea formularelor pretip ărite
Aceasta implica utilizarea unei hârtii de impr imanta ce cuprinde elemente fixe ale situa ției
finale, cum ar fi antetul, titlul, capul de tabel, textul explicat iv etc. Aceasta conduce la o cre ștere a
vitezei de editare și o dim inuare a uzurii imprimantelor. Totodat ă situaț iile obținute sunt mai
estetice și sunt ușor de parcurs de utilizatori.
Utilizarea generatoarelor de rapoarte ( REPORT WRITER )
Multe limbaje de programa re, pachete de programe și sisteme de gestiune a bazelor de date
dispun de module specializ ate în editarea de rapo arte, 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, coloane, 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: ACCE SS, d’BASE, ORACLE, FOXPRO, PARADOX, etc.

1.2. Proiectarea codurilor
În proiectarea sistemului de coduri trebuie să avem în vedere dou ă aspecte importante ș i
anume [11]:
 influența tipului și structurii codului asupra performan țelor sistemului informatic;

 implicațiile utiliz ării codurilo r în opera țiile de culegere a datelor și interpretarea
rezultatelor finale de c ătre utilizatorii neinformaticieni.
Primul aspect ridic ă probleme de ordin tehnic în r ealizarea 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, ve rificare 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.
Activitățile parcurse în realizarea un ui sistem de coduri sunt:
 analiza elementelor ce urmeaz ă a fi codificate;
 precizarea și uniformizarea tehnologiei, a denumirilor;
 stabilirea caracteristicilor și a relaț iilor dintre elementele de codificat;
 alegerea tipurilor de coduri; estimarea capacit ății, lungimii și formatului codurilor;
 atribuirea codurilor elem entelor 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).

1.3. Proiectarea intr ărilor în siste
mul informatic
Datele de intrare parcurg o succesiune 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 cal cul / transpunere pe suportul
tehnic; verificarea 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 documentelo r de intrare, stabilirea instruc țiunilor de culegere;
– stabilirea regulilor de control și de validare a datelor;
– proiectarea formularelor (vid eoformatului) de intrare.
Alegerea suportului tehni c al datelor de intrare se face în funcț ie de cerin țele aplica ției
informatice. Datele introduse de la terminal, fie intr ă imediat în circuitul de prelucrare-actualizare a
unei baze de date, fie sunt stocate pe un suport magnetic sau s unt stocate în vederea prelucr ării
ulterioare.

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.
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 ă / gru peaz ă 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 progr ame. 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 specifice noului mediu.
Regulile de control ș i procedurile de validare a da telor de intrare trebuie s ă cuprindă [11]:
 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 indicatori 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 opera tor-calculator. Acest
dialog se poate desf ășura sub urm ătoarele forme:
 întrebare-r ăspuns cu defilarea liniilor 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 intrar e. La proiectarea formelor de intrare 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 pr in 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 Loo kup wizard în ACCESS)
În 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. Mesaje le 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 va lori implicite, atunci
când nu sunt completate. Aceste valori se preiau din nomenclatorul de coduri, fi șierele bazei de date
sau tabele special memorate pent ru valorile asumate pr in lipsa sau prin ap licarea unui algoritm.
Pentru o mai u șoară operare este necesar s ă folosim toate facilit ățile de afiș are și de combinare a
culorilor (figura 1).

Figura 1. Posibil ecran al unei aplica ții de facturare

În proiectarea formularelor de intrare pot fi utilizate componente speci alizate î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.

2. Proiectarea interfe țelor și a dia logurilor
Interfa ța cu utilizatorul reprezint ă o parte a aplica ției software care permite utilizatorilor 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
utilizatorii și calculatoarele schimb ă informații [46].

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.

Metode de interac țiune
Metodele cele mai utilizate sunt:
 interacțiunea prin limbaj-comand ă (în acest tip de interacț iune utilizatorul transmite
calculatorului com
enzile 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 ă
de combinaț ii de taste);
 interacțiunea bazat ă pe obiecte icons(comunicarea se face prin intermediul
pictogramelor. La ap ăsarea lor se activeaz ă o anumit ă funcț ie sau comand ă);
 interacțiunea prin limbaj natural(comenzile se transmit folosind vocea și sintetizatoarele
de voce pentru reda rea rezultatelor).

Echipamentelor necesare interac țiunii cu sistemul
Cele mai folosite echipamente sunt:
 keyboard – tastatura este format ă dintr-un set de butoane (tas te) Prin intermediul ei se
introduc date, comenzi;
 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 es te 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
dialogurilor cum ar fi: unifo rmitate, 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 prin care se reprezintă meniurile componente ale aplica ției.

Fig. 4.2. Exemplu de diagram ă de apelare a meniurilor.
Pentru proiectarea interfe țelor și dialogurilor se poate apela la ajutorul oferit de produsele
CASE sau la mediile de dezvoltare grafic ă ACCESS, Visual Basic, etc. Pe ntru 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, disponibilita tea la deplasare, meniu sistem, etc.

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 modulu i de organizare a date lor, independent de
tehnologiile specifice de prelucrare a bazelor de date. 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 dialogurilor ș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 ă analiza datelor elementare din intr ările și ieșirile sistemului pent ru 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 func ție de tipul de SGBD utilizat: rela țional – cel mai utilizat în prezent, re țea,
ierarhic, sau orientate-obiect;
 realizarea unui model al datelor care s ă răspundă cerințelor actuale de date reg ăsi te î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 ba zelor 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 ă [46]:
 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 m
odel logic al datelor di n perspectiva utilizat orului (formulare și rapoarte)
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 conceptu al al 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 perspectivelor, a unui model logic fi nal 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.
Primul pas al modelă rii logice poate fi ilustrat prin dou ă rapoarte solicitate de utilizatori,
reprezentând perspectiva utilit ății sistemului din punctul lor de vedere:
– cel mai bun client al produsului X;
– 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: 1/01/2016 Data de sfâr șit: 31/03/2016
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
COD CLIENT: 1111 NUME CLIENT: S.C. ALPHA S.R.L.
VOLUM: 1000
Fi
g. 4.3 Model de ecran solicitat de utilizatori [46]

Din analiza ecranu
lui se pot desprinde rela țiile:
CLIENT(COD_CLIENT , NUME)
COMANDA(NR_COMANDA , COD_CLIENT , DATA_COMANDA)
PRODUS(COD_PRODUS )
COMANDA(NR_COMANDA ,COD_PRODUS ,CANTITATE_COMANDATA)

Pagina 1
Situația comenzilor în curs
31/03/2016
COD PRODUS CANTIT ĂȚI_DE_LIVRAT
A1111 0 A2222 0 B1111 150
Y9999 100
Fig. 4.4. Model de ra portsolicitat de utilizatori [46]

Realizarea raportului este posibil ă prin folosirea urm ătoarelor entităț i:

PRODUS(COD_PRODUS ), COMANDA(NR_COMANDA , DATA_COMANDA)
COMANDA(NR_COMANDA , COD_PRODUS , CANTITATE_COMANDATA)
LIVRARE(COD_PRODUS , NR_FACTURA , CANTITATE_LIVRATA)
FACTURA(NR_FACTURA , DATA_FACTURA)

Pasul al doilea presupune comasarea pers pectivelor utilizatorilor și crearea unui set integrat
al relațiilor, rezultând urm ătoarele rela ții (tabele):

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 concep tual al datelor (diagrama entitate-
relație) din aplica ție fără să se țină cont de punctul de vedere al utilizatorului, într -un set de relaț ii
normalizate. Din analiza diagrame i din figura 4.5 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 utilizat orilor î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)

Rezultatul model ării logice a datelor îl constituie rela țiile normalizate rezultate din cel de-al
patrulea pas al procesului. De asemenea, alt r ezultat 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.

Fig. 4.5. Diagrama entitate-rela ție pentru gestiunea clien ților [46]

3.1. Normalizarea rela ț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 exploat ării bazei de date: ad ăugare, ștergere, actualizare. Aceste
legături logice, cunoscute în li teratura 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
Pentru definirea acestui tip de dependen țe se consider ă schema de rela ție
Prestari_Servicii (Cod, Nume_client, Ad resa, Serviciu_prestat, Valoare)
definită pentru urm ărirea serviciilor pr estate 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ă că atributul
Adresa este redundant, deoarece va loarea acestuia este repetată 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 client, 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_client, 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
(CA) 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 tuplu al rela ției, deci
determină în mod univoc valorile atributelor tuplului, 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 descompunerea
schemei date într-o colec ție de scheme mai simple în care sunt evitate neaj unsurile 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 echivalent ă 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 normale 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 definir ea 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 nor malizare (FN5) satisface toate
restricțiile cerute de nivele inf erioare de normali zare (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 neatomic 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 ției (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 țional 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ătoarelor 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 înregistra te 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 atri but 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 ă F N B C .
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 ba za 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, Di scipline, 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 studenț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 SDS 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 spunem 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 asupra
înregistră rilor bazei de date (acestea sunt dependen țele de cuplare implicate de o cheie a rela ției).
Dependen ța de cuplare este o proprietate ce garanteaz ă că nu se genereaz ă înregistrări false
la reunirea rela țiilor obținute prin descompunere. O relaț ie se află în forma normală cinci dac ă ea nu
poate fi descompus ă în alte rela ții fără a pierde informa ție.
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 si milaritatea ce exist ă între defini țiile pentru FNBC, FN4 și FN5, acestea pot
fi unificate în urm ătoarea defini ție [20]:

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 ă eliminarea 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 actualizare înregistr ări în baza de date. Normal izarea 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 sa u 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,
totuș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 pe ntru 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 date 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 [16], prin care se urm ărește înlocuirea unei colec ții de scheme de rela ție cu o schem ă
de 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 nive le cât mai înalte (FN5),
pentru denormalizare nu exist ă criterii clare putând fi avute în vedere doar asp ecte legate de
performan țele anumitor aplica ții.
Un alt principiu care se urm ărește în proiectarea unei baze de da te 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 rela ție.