Proiectarea interfetelor si a dialogurilor

Interfata cu utilizatorul - reprezinta o parte a aplicatiei software care permite utilizatorilor sa-si exprime intentiile de operare asupra calculatorului si sa interpreteze rezultatele actiunilor efectuate de masina.

Prin proiectarea dialogurilor si a interfetelor se definesc modalitatile prin care oamenii si calculatoarele schimba informatii [1].

Metode si echipamente folosite in dialogul om-masina

Interfata om – masina defineste modalitatea prin care utilizatorul interactioneaza cu un sistem informatic. Interfetele sunt destul de variate, conform descrierilor, insa toate trebuie sa dispuna de un stil sau de o metoda prin care sa se foloseasca anumite echipamente in masura sa faciliteze o astfel de interactiune [1].

Metode de interactiune

Metodele cele mai utilizate sunt [1]

interactiunea prin limbaj-comanda (in acest tip de interactiune utilizatorul transmite calculatorului comenzile sub forma unui sir de caractere)

interactiunea prin meniuri(utilizatorul transmite comenzile sale calculatorului prin intermediul unui sistem de meniuri si optiuni de meniu sau folosind scurtaturi sub forma de combinatii de taste).

interactiunea bazata pe obiecte icons(comunicarea se face prin intermediul desenelor. Imaginile folosite functioneaza ca butoanele, la apasarea lor se activeaza o anumita functie sau comanda)

interactiunea prin limbaj natural(comenzile se transmit folosind vocea si sintetizatoarele de voce pentru redarea rezultatelor)

Echipamentelor necesare interactiunii cu sistemul

Cele mai folosite echipamente sunt [1]

keyboard – tastatura este formata 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 selectia.

Light Pen – Stiloul optic efectueaza selectia prin apasarea pe ecran.

Voice – Vocea constituie modalitatea de transmitere a textelor si comenzilor catre calculator.

Proiectarea dialogurilor

Proiectarea dialogurilor este procesul prin care sunt proiectate toate secventele folosite de utilizator pentru a comunica cu un sistem informatic. Rolul proiectantului este de a selecta cele mai potrivite metode si echipamente, precum si de a prezenta conditiile in care se pot afisa informatiile sau se pot obtine de la utilizator.

Pentru a obtine rezultate bune trebuie sa se tina seama de regulile de baza la conceperea dialogurilor cum ar fi: uniformitate, comenzi scurte, usurinta in lucru, controlul, operatiunea inversa (refacerea unui element sters), rezolvarea erorilor, etc.

O modalitate de prezentare a secventei dialogurilor este cea care apeleaza la tehnica diagramelor. Ea va face trimitere la meniurile componente ale aplicatiei.

Figura 2. Structura unei diagrame de apelare a meniurilor [1].

Pentru proiectarea interfetelor si dialogurilor se poate apela la ajutorul oferit de produsele CASE sau la mediile de dezvoltare grafica ACCESS, Visual Basic, etc.

Pentru a se putea proiecta in conditii optime mediile GUI (Graphical User Interface) trebuie sa se cunoasca aceste medii.

In mediile grafice informatiile se plaseaza in ferestre. Acestea au trasaturi specifice ca: redimensionarea, maximizarea, disponibilitatea la deplasare, meniu sistem, etc.

Proiectarea logica a bazelor de date

Proiectarea logica a bazelor de date este in stransa legatura cu modelarea conceptuala a datelor, aceasta insemnand reprezentarea modului de organizare a datelor, independent de tehnologiile specifice de prelucrare a bazelor de date, fara sa se inregistreze o preocupare anume referitoare la calitatea modelelor datelor. Ultimului aspect i se va acorda atentia cuvenita abia acum, odata cu modelarea logica a datelor, descriindu-se structurile datelor din baza.

Procesul de modelare logica a datelor se deruleaza in paralel cu celelalte activitati ale proiectarii logice: proiectarea formularelor si a rapoartelor si proiectarea dialogurilor si interfetelor. Modelarea logica a datelor se realizeaza nu numai pe baza diagramei entitate-relatie, ci si pe baza machetelor formularelor si a rapoartelor. Se efectueaza analiza datelor elementare din intrarile si iesirile sistemului pentru a se desprinde legaturile dintre ele.

Prin modelarea logica a datelor se urmareste:

structurarea performanta a datelor prin procesul de normalizare

obtinerea unui model logic al datelor din care sa se poata realiza proiectul bazei de date fizice, adica modelul relational – cel mai utilizat in prezent, desi se pot obtine si modelele retea, ierarhic sau orientate-obiect;

realizarea unui model al datelor care sa raspunda cerintelor actuale de date regasite in formulare si rapoarte. Modelarea logica este un proces ascendent (bottom-up, de jos in sus) de obtinere a relatiilor din formulare si rapoarte prin transformarea modelului entitate-relatie intr-o forma relationala.

Modelarea logica a datelor descrie datele cu ajutorul unei notatii speciale, care corespunde unui mod de organizare a acestora de catre un sistem de gestiune a bazelor de date.

Procesul de modelare a datelor este complex. In fiecare etapa a ciclului de viata se regaseste cate o activitate specifica datelor dupa cum urmeaza [1]:

Analiza – Modelele conceptuale ale datelor, prezentarea DER;

Proiectarea logica – Modelul logic al datelor(relational);

Proiectarea fizica – Proiectarea fizica a bazelor de date si a fisierelor (organizarea fisierelor);

Implementarea – Descrierea fisierelor si a bazelor de date.

Dupa cum prezinta profesorul Oprea D. In “Analiza si proiectarea sistemelor informationale economice” in procesul de modelare logica exista patru pasi esentiali:

1.     Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare si rapoarte) privind aplicatia, folosindu-se principiile normalizarii;

2.     Contopirea tuturor perspectivelor normalizate ale utilizatorilor intr-un model logic consolidat (centralizat) al datelor, numit si integrarea perspectivelor;

3.     Transformarea modelului conceptual al datelor (entitate-relatie), realizat fara sa se tina cont de perspectiva utilizatorului, intr-un set de relatii normalizate;

4.     Compararea modelului logic consolidat al datelor cu modelul transformat al entitatii-relatie si realizarea, prin integrarea perspectivelor, a unui model logic final al datelor aplicatiei.

Rezultatele obtinute prin parcurgerea celor patru pasi pot fi ilustrate prin intermediul unor exemple oferite in literatura de specialitate de McFadden si Hoffer [1].

Primul pas al modelarii logice se poate explica prin doua rapoarte solicitate de utilizatori, reprezentand perspectiva utilitatii sistemului din punctul lor de vedere:

cel mai bun client al produsului X(ecran);

situatia comenzilor in curs;

Ecranul “Cel mai bun client al produsului X”, prin perceptia utilizatorului, are urmatorul format:

	Cel mai bun client al produsului Introduceti codul produsului:             P1122 Data de inceput:                                 10/10/99 Data de sfarsit: 31/12/99 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - COD CLIENT:  1111 NUME CLIENT:                    S.C. ALPHA S.R.L. VOLUM:                                1000

Figura 3 Model de ecran solicitat de utilizatori [1]

Din analiza ecran ului se pot desprinde relatiile:

CLIENT(COD_CLIENT, NUME)

COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA)

PRODUS(COD_PRODUS)

LINIE_COMANDA(NR_COMANDA,COD_PRODUS,CANTITATE_COMANDATA)

Raportul “Situatia comenzilor in curs” are urmatorul format:

	Pagina 1 Situatia comenzilor in curs 31/03/1998 COD PRODUS                       CANTITATI_DE_LIVRAT A1111   0 A2222   0 B1111   150 Y9999   100

Figura Model de raport solicitat de utilizatori [1]

Realizarea raportului este posibila prin folosirea urmatoarelor entitati:

PRODUS(COD_PRODUS)

COMANDA(NR_COMANDA, DATA_COMANDA)

LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)

LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA)

FACTURA(NR_FACTURA, DATA_FACTURA)

Pasul al doilea presupune comasarea perspectivelor utilizatorilor si crearea unui set integrat al relatiilor, rezultand urmatoarele relatii:

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)

Eseu: Imobilizarile corporale - definiții, concepte, principii și clasificari privind imobilizarile corporale Eseu: Concluzii si propuneri cu privire la interfata subsistemului cu utilizatorul

Pasul al treilea consta in transformarea modelului conceptual al datelor (diagrama-entitate-relatie) din aplicatie fara sa se tina cont de punctul de vedere al utilizatorului, intr-un set de relatii normalizate. Din analiza diagramei din figura 6.5 se desprind urmatoarele relatii:

Figura 5. Diagrama entitate-relatie pentru gestiunea clientilor [1]

Din analiza diagramei se desprind urmatoarele relatii:

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 compara modelul obtinut din pasul doi cu cel din pasul trei si integreaza perspectivele utilizatorilor in vederea obtinerii unui model logic final, dupa cum urmeaza:

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)

Asadar, rezultatul modelarii logice a datelor il constituie relatiile normalizate rezultate din cel de-al patrulea pas al procesului. De asemenea, alt rezultat se va concretiza in actualizarea depozitului (repository) sau a dictionarului proiectului. Diferenta majora intre modelarea conceptuala si cea logica este ca dupa modelarea logica a datelor cerintele structurate de date se concretizeaza in relatii, si nu in entitati. Din cauza normalizarii nu este necesara o corespondenta unu-la-unu intre entitati si relatii [1]

1. Normalizarea relatiilor - Forme normale

Intre atributele unei relatii sau intre atribute din relatii diferite pot exista anumite legaturi logice (dependente), care influenteaza proprietatile schemelor de relatie in raport cu operatiile curente care intervin in timpul exploatarii bazei de date: adaugare, stergere, actualizare. Aceste legaturi logice, cunoscute in literatura de specialitate sub denumirile de dependentele functionale, dependentele multivalorice si dependente de cuplare, au implicatii majore asupra criteriilor de proiectare a schemelor relationale. Alegerea unui model conceptual convenabil pentru o baza de date relationala poate necesita realizarea unor descompuneri pentru anumite scheme de relatie date, descompuneri care sa izoleze dependentele existente si prin aceasta sa elimine anomaliile care se datoreaza acestor dependente.

Dependente functionale

Penru definirea acestui tip de dependente se considera schema de relatie

Prestari_Servicii (Cod, Nume_client, Adresa, Serviciu_prestat, Valoare)

definita pentru urmarirea serviciilor prestate de o firma pentru diversi clienti.

Atributul Adresa este dependent de atributul Nume_client (presupunand ca fiecare client are o singura adresa, rezulta ca fiecare valoare a atributului Nume_client determina in mod unic valoarea corespunzatoare a atributului Adresa). Analizand schema de relatie de mai sus, se constata o redundanta relativ la atributul Adresa a carei valoare este repetata pentru un client pentru fiecare serviciu prestat pentru acest client, ceea ce conduce la aparitia urmatoarelor anomalii:

- Anomalia la adaugare:

adresa unui client poate fi preluata numai dupa ce pentru acesta se presteaza cel putin un serviciu.

- Anomalia la stergere:

daca se sterg toate serviciile prestate pentru un anumit client, se pierde adresa acestui client.

- Anomalia la actualizare:

datorita redundantei relativ la atributul Adresa, daca se schimba adresa unui client este necesara parcurgerea intregii relatii pentru a identifica si actualiza toate aparitiile acestui client, in caz contrar baza de date devine inconsistenta (acelasi client poate apare la adrese diferite).

Aceste anomalii pot fi eliminate, daca schema de relatie Prestari_Servicii se inlocuieste prin urmatoarele doua scheme de relatie:

Clienti(Cod, Nume_client, Adresa)

Servicii(Cod, Serviciu_prestat, Valoare).

Relatia Clienti contine codul, numele si adresa fiecarui client, fara nici un fel de redundanta, iar relatia Servicii contine serviciile prestate pentru fiecare client si valorile acestor servicii. Un dezavantaj al descompunerii relatiei initiale in cele doua relatii este acela ca pentru a determina adresa clientului pentru care s-a prestat un anumit serviciu este necesara efectuarea unei operatii de cuplare a relatiilor Clienti si Servicii.

Se considera o schema de relatie R si A,B doua atribute simple sau compuse ale schemei de relatie R. Atributul A determina functional atributul B sau B depinde functional de A, daca si numai daca oricarei valori a atributului A ii corespunde o singura valoare a atributului B (se noteaza A->B).

Dependenta functionala A->B este totala daca nu exista nici un subset C al atributului A (CcA) astfel incat C->B si este partiala in caz contrar.

In relatia Prestari_Servicii, una din dependentele functionale care poate fi pusa in evidenta este Nume_client->Adresa.

Deoarece intr-o relatie orice cheie identifica in mod unic fiecare tupla a relatiei, deci determina in mod univoc valorile atributelor tuplei, rezulta ca in orice relatie atributele sunt dependente functional fata de cheile acesteia.

Se pot face, pana in acest moment, urmatoarele precizari:

Eliminarea dependentelor functionale din schemele de relatie si a consecintelor negative (redundanta datelor; anomaliile de adaugare, stergere, actualizare) se realizeaza prin descompunerea schemei date intr-o colectie de scheme mai simple in care sunt evitate neajunsurile mai sus mentionate. Reconstituirea relatiei initiale se poate face prin operatia de cuplare (uniune). Pentru ca descompunerea schemei de relatie sa fie echivalenta cu relatia initiala, trebuie sa fie indeplinite conditiile:

cuplare fara pierdere de informatie;

conservarea dependentelor (dependentele functionale din relatia initiala trebuie sa se regaseasca in relatiile rezultate prin descompunere).

Formele normale sunt scheme de relatie echivalente obtinute prin descompunerea unor scheme de relatie in vederea eliminarii redundantei datelor si anomaliilor la adaugare, actualizare, stergere inregistrari in baza de date. Descompunerile schemelor de relatii in scheme de relatii echivalente avand in vedere dependentele functionale conduc la definirea primelor 4 nivele de forme normale si anume: prima forma normala (FN1), a doua forma normala (FN2), a treia forma normala (FN3) si forma normala Boyce-Codd (FNBC).

A patra forma normala (FN4) este definita avand in vedere dependentele multivalorice, iar a cincea forma normala (FN5) este definita avand in vedere dependentele de cuplare. Incepand de la prima forma normala si pana la forma normala FN5 se impun conditii din ce in ce mai restrictive asupra relatiilor. Astfel o relatie aflata pe un anumit nivel de normalizare (FN5) satisface toate restrictiile cerute de nivele inferioare de normalizare (FN1, FN2, FN3, FNBC, FN4). In cele ce urmeaza sunt date definitiile formelor normale avand in vedere dependentele functionale.

O relatie R este in prima forma normala (FN1) daca si numai daca toate atributele sale iau numai valori atomice (nu pot fi descompuse). Spre exemplu, atributul Adresa ar putea fi considerat un atribut neatomic daca in cadrul adresei ne-ar interesa localitatea, strada etc., caz in care trebuie descompus in atribute atomice.

O relatie R este in a doua forma normala (FN2) daca este in FN1 si orice atribut neprim este total dependent fata de orice cheie a relatiei (atributele prime sunt atribute care fac parte dintr-o cheie a relatiei si cele neprime sunt atributele care nu apartin nici unei chei a relatiei).

O relatie R este in a treia forma normala (FN3) daca este in FN2 si nici un atribut neprim nu este functional dependent fata de un alt atribut neprim al relatiei.

O relatie R se afla in forma normala Boyce-Codd (FNBC) daca singurele dependente functionale admise sunt cele in care o cheie determina un alt atribut (nici un atribut prim sau neprim nu poate fi dependent functional fata de un alt atribut daca acesta nu este sau nu contine o cheie).

Dependente multivalorice

Pentru ilustrarea acestui tip de dependente se ia in considerare urmatoarea schema de relatie:

Clase(Clasa, Discipline, Elevi)

ce contine clasele dintr-o institutie de invatamant, iar pentru fiecare clasa sunt inregistrate disciplinele ce se predau si elevii inmatriculati in clasa respectiva. Se poate constata ca relatia Clase poate rezulta prin operatia de cuplare dupa atributul Clasa a urmatoarelor doua relatii:

CD(Clasa, Discipline)

CE(Clasa, Elevi)

In relatia Clase, presupunand ca pentru o clasa data, fiecare elev frecventeaza toate disciplinele inregistrate pentru acea clasa, exista dependentele multivalorice:

Clasa ->> Discipline

Clasa ->> Elevi

Ca si in cazul dependentelor functionale, existenta dependentelor multivalorice prezinta aceleasi neajunsuri privind redundanta datelor si anomalii la efectuarea operatiilor de adaugare, actualizare si stergere inregistrari in baza de date.

O relatie R este in a patra forma normala daca singurele dependente multivalorice admise sunt cele determinate de un alt atribut care este o cheie sau care contine o cheie a relatiei.

Intrucat orice dependenta functionala este un caz particular de dependenta multivalorica, rezulta ca orice relatie care se afla in forma normala FN4, se afla si in forma normala FNBC. Transformarea unei relatii intr-o colectie de relatii care sa se afle in FN4 este similara cu trecerea in FNBC, insa trebuie avuta in vedere atat eliminarea dependentelor functionale cat si a dependentelor multivalorice.

In concluzie, putem afirma ca in cazul formelor normale de la FN1 la FN4, trecerea de la o forma normala la alta s-a facut prin descompunerea unei relatii in altele doua, urmarindu-se eliminarea dependentelor functionale si multivalorice. O relatie aflata in forma normala FN4 nu mai poate fi descompusa in continuare pe baza acestei metode. Exista situatii cand relatii aflate in FN4 contin redundante si prezinta anomalii la operatiile de adaugare, stergere si actualizare. Aceste anomalii sunt cauzate de existenta dependentelor de cuplare si pot fi eliminate prin descompunerea relatiei in 3 sau mai multe relatii a caror cuplare are ca rezultat relatia initiala.

Dependente de cuplare

Se considera schema de relatie:

SDS (Specializari, Discipline, Studenti)

care contine disciplinele care se predau la diverse specializari si studentii care le frecventeaza, cu precizarea ca pot exista discipline optionale care nu sunt frecventate de toti studentii de la specializarea respectiva. In aceste conditii in cadrul schemei de relatie SDS nu au loc dependentele multivalorice:

Specializari ->> Discipline

Specializari->> Studenti

ceea ce inseamna ca relatia SDS este in FN Desi este in FN4, relatia SDS contine mai multe redundante care pot conduce la anomalii de actualizare. Pe de alta parte, relatia SDS nu poate fi descompusa in doua componente din a caror cuplare sa rezulte relatia initiala cu conservarea informatiei. Se constata insa ca relatia SDS poate fi descompusa in urmatoarele 3 relatii:

SD(Specializari, Discipline)

SS(Specializari, Studenti)

DS(Discipline, Studenti)

si relatia SDS este rezultatul cuplarii relatiilor: SD, SS si DS fara pierdere de informatie.

SDS = SD►◄SS►◄DS.

In acest caz spunem ca in relatia SDS exista o dependenta de cuplare. Dependentele multivalorice sunt cazuri particulare de dependente de cuplare.

A cincea forma normala este o generalizare a formei normale patru, trecerea unei relatii in FN5 presupunand eliminarea dependentelor de cuplare existente in cadrul relatiei, impreuna cu anomaliile pe care acestea le creeaza. In cadrul unei relatii pot exista dependente de cuplare care nu conduc la redundanta in memorarea datelor si nu produc anomalii la operatiile efectuate asupra inregistrarilor bazei de date (acestea sunt dependentele de cuplare implicate de o cheie a relatiei).

O relatie este in forma normala cinci (FN5) daca si numai daca toate dependentele de cuplare existente in relatie sunt implicate de o cheie a acesteia. Relatia SDS se poate descompune, cu conservarea continutului de informatie, in cele 3 componente ale sale: SD, SS si DS care sunt in FN5.

Avand in vedere similaritatea ce exista intre definitiile pentru FNBC, FN4 si FN5, acestea pot fi unificate in urmatoarea definitie [13]:

O relatie R este in FNBC, FN4, FN5 daca si numai daca singurele dependente functionale, multivalorice, de cuplare existente sunt cele implicate de o cheie a relatiei R.

In concluzie, prin procesul de normalizare se realizeaza eliminarea din schemele de relatie a dependentelor (functionale, multivalorice si de cuplare) cu scopul de a obtine o schema relationala mai buna din punctul de vedere al redundantei datelor si al anomaliilor ce pot apare la   operatiile de adaugare, stergere si actualizare inregistrari in baza de date. Normalizarea unei scheme de relatie R inseamna inlocuirea acesteia cu o multime de proiectii R1,,Rn astfel incat R sa fie echivalenta cu uniunea proiectiilor R1,,Rn. Desi normalizarea este o operatie utila in proiectarea bazelor de date, aceasta nu ofera intotdeauna retete pentru obtinerea celor mai bune modele si de aceea este la latitudinea proiectantului decizia de a aplica sau nu o anumita etapa de normalizare dupa o analiza temeinica a avantajelor si dezavantajelor modelului obtinut. In unele cazuri normalizarea completa, pana la FN5, s-ar putea sa fie dezavantajoasa. Avand in vedere constatarile de mai sus se poate afirma ca desi normalizarea nu reprezinta o solutie general valabila in orice situatie, totusi daca pentru proiectarea bazei de date se aplica corect o metodologie de proiectare descendenta, modelul rezultat va fi de la sine normalizat. Cercetarile in acest domeniu continua, fiind definite si alte forme normale printre care FN6 pentru baze de date temporale. O baza de date temporala, pe langa datele curente, contine si date istorice, iar factorul (atributul) timp are un rol esential (exemple concludente de astfel de baze de date sunt depozitele de date). Astfel, in proiectarea unei baze de date temporale trebuie avute in vedere si alte operatii de descompunere a schemelor de relatie si anume:

descompunerea orizontala – pentru separarea datelor curente de datele istorice;

descompunerea verticala – pentru separarea atributelor aceleiasi entitati avand in vedere valorile lor raportate la atributul temporal.

In proiectarea unei baze de date nu este exclusa nici operatia inversa normalizarii numita denormalizare [12], prin care se urmareste inlocuirea unei colectii de scheme de relatie cu o schema de relatie echivalenta in vederea eliminarii necesitatii efectuarii unor operatii de cuplare care pot fi costisitoare. Daca in cazul normalizarii tendinta este de a ajunge la nivele cat mai inalte (FN5), pentru denormalizare nu exista criterii clare putand fi avute in vedere doar aspecte legate de performantele anumitor aplicatii.

Un alt principiu care se urmareste in proiectarea unei baze de date este principiul proiectarii ortogonale conform caruia in cadrul unei baze de date doua scheme de relatie reale (variabile de relatie de baza) nu trebuie sa aiba semnificatii suprapuse. In timp ce prin normalizare se urmareste reducerea redundantei din cadrul unei scheme de relatie, prin proiectarea ortogonala se urmareste reducerea redundantei dintre schemele de relatie.

2. Simplificarea structurii datelor prin normalizare

Problema de baza a proiectarii logice a bazelor de date este cum ar trebui combinate datele elementare pentru a forma relatii(sau tipuri de inregistrari) care sa descrie entitatile si relatiile dintre entitati. In limbajul bazelor de date, cuvantul relatie inseamna un tabel de date, ceea ce duce la concluzia ca bazele de date relationale (modelul relational) sunt cladite pe un grup de tabele legate intre ele [1].

Modelul relational a fost dezvoltat de catre Codd. Este un model conceptual de organizare a datelor, destinat reprezentarii legaturilor dintre date. El este bazat pe teoria matematica a relatiilor si este definit cu o deosebita rigoare matematica [Popescu I., 1996].

In cadrul modelului relational datele sunt structurate sub forma de relatii (de aici si denumirea). Cea mai directa si intuitiva modalitate de reprezentare a datelor in cadrul acestui model este sub forma de tabele. Fiecarei relatii i se poate asocia un tabel care are atatea coloane cate multimi leaga relatia si are atatea linii cate tuple contine relatia.

Prezentarea structurii relationale a datelor impune definirea notiunilor de: domeniu, relatie, atribut si schema a unei relatii. Conceptele utilizate pentru a descrie formal, uzual sau fizic elementele de baza ale organizarii datelor sunt prezentate in tabelul urmator:

Definirea domeniului

Un domeniu este o multime de valori caracterizata printr-un nume. Un domeniu se poate defini explicit prin enumerarea tuturor valorilor apartinand acestuia sau definind o proprietate distinctiva a domeniului valorilor, de cele mai multe ori limita superioara si limita inferioara [Popescu I, 1996]. De exemplu:

D₁: -definire explicita

D₂: -definire implicita

D₃: -definire implicita

Pentru un ansamblu de domenii D₁,D₂,…,D_n produsul cartezian al acestora reprezinta ansamblul tuplurilor (elemente ale unei relatii) <v₁,v₂,…,v_k> unde v_i este un element care apartine domeniului D_i. De exemplu, tuplurile <“Maria”,”F”,”50” >,< “Vasile”,”M”,”60”> apartin produsului cartezian D₃xD₁xD₂.

Definirea relatiei

O relatie R pe multimile D1,D2,…,Dn este o submultime a produsului cartezian D1xD2x…xDn, deci o multime de tupluri [Popescu I, 1996].

Considerand ca nu se cunosc decat doua persoane, relatia R se defineste prin tuplurile care descriu aceste persoane, si anume:

R:

O relatie poate fi reprezentata printr-un tabel bidimensional in care fiecare linie corespunde unui tuplu si fiecare coloana corespunde unui domeniu.

R:                     D₃ D₁ D₂

Reprezentarea tabelara este preferata adesea altor forme de reprezentare a relatiilor, deoarece este usor de inteles si de utilizat.

In prezentarea conceptului de relatie se poate recurge la analogii cu alte concepte cum ar fi cel de fisier. Relatia poate avea semnificatia unui fisier, tuplul poate fi considerat o inregistrare, iar valorile din cadrul tuplului pot fi interpretate drept valori ale campurilor de inregistrare.

Definirea atributului

In timp ce tuplurile dintr-o relatie trebuie sa fie unice, un domeniu poate apare de mai multe ori in produsul cartezian pe baza caruia este definita relatia [Popescu I, 1996].

PERS    D₃ D₁ D₂ D₃

Relatia PERS reprezinta un subansamblu al produsului cartezian D₃xD₁xD₂xD Atributul reprezinta coloana unei tabele de date, caracterizata printr-un nume. Numele coloanei (atributului) exprima, de obicei, semnificatia valorilor din cadrul coloanei respective.

Semnificatia valorilor din cadrul unui tuplu se stabileste in acest caz nu numai pe baza domeniului de care apartin valorile ci si functie de pozitia ocupata in cadrul tuplului. Dependenta fata de ordinea datelor inseamna o reducere a flexibilitatii organizarii datelor. Intr-o organizare eficienta, flexibila, ordinea liniilor si a coloanelor nu trebuie sa prezinte nici o importanta. Pentru a diferentia coloanele care contin valori ale aceluiasi domeniu, si a elimina astfel dependenta de pozitie in cadrul tabelei se introduce tocmai conceptul de atribut. Fiecare relatie are asociat un nume sau un identificator propriu.

Schema unei relatii este formata din ansamblul elementelor definitorii sau din nivelul relatiei urmat de lista atributelor specifice.

In multimile matematice nu este permis ca un obiect sa apara de mai multe ori. Cat timp o relatie este o multime de tupluri, teoretic nici o linie a unei relatii nu poate fi duplicatul altei linii. Dupa cum reiese din prezentarile anterioare, daca o coloana sau o combinatie de coloane nu poate sa identifice in mod unic o linie, atunci trebuie inventata o coloana-cheie speciala.

O tehnica de proiectare a modelului conceptual al bazei de date intr-o abordare bottom-up este tehnica celor cinci forme normale.

Conform acestei tehnici, atributele entitatilor definite se organizeaza intr-o singura tabela sau in mai multe si se urmareste descompunerea acestor tabele in altele, fara pierdere de informatii in scopul eliminarii anomaliilor de ordin logic si fizic. Acest lucru se realizeaza prin parcurgerea a o serie de etape, de normalizare, prin care se trece de la o forma normala la alta. Se apreciaza posibilitatea existentei a cinci forme normale (FN). Prin parcurgerea acestor etape, se ajunge in mod succesiv sa se amelioreze structura bazei de date, inlaturandu-se treptat o serie de neajunsuri si asigurand facilitati sporite in privinta incarcarii, actualizarii si exploatarii bazei de date. O relatie nenormalizata contine unul sau mai multe grupuri care se repeta.

Necesitatea normalizarii progresive este data de faptul ca anumite relatii pot genera o serie de situatii nedorite, asa-numitele “anomalii de actualizare”, cum sunt: anomalia de stergere, anomalia de adaugare, anomalia de modificare [2].

3. Transformarea diagramelor entitate-relatie in relatii

Pentru a se putea compara rezultatele obtinute in etapa de proiectare logica a datelor, adica a relatiilor normalizate, cu diagrama entitate-relatie, rezultat al proiectarii conceptuale, aceasta din urma trebuie sa fie convertita in relatii, de asemenea, normalizate.

Intregul proces se desfasoara in patru pasi, astfel: [1]

Reprezentarea entitatilor. Fiecare tip de entitate din diagrama entitate-relatie este reprezentata ca o relatie in modulul relational al datelor. Identificatorul tipului de entitate devine cheie primara a relatiei, iar celelalte atribute ale tipului entitatii devin atribute non-cheie ale relatiei.

Reprezentarea legaturilor. Fiecare legatura din diagrama entitate-relatie trebuie sa fie reprezentata in modelul relational al datelor. Reprezentarea legaturii se efectueaza in functie de natura ei. De exemplu, uneori se poate constitui o relatie prin includerea cheii primare a unei relatii ca o cheie straina in alta relatie. Astfel, se poate crea o relatie separata pentru reprezentarea legaturii.

Normalizarea relatiilor. Relatiile create in pasii 1 si 2 pot contine redundante nedorite si vor constitui surse de inregistrare a anomaliilor in timpul actualizarii. Normalizarea va conduce la o buna structurare a relatiilor.

Fuziunea relatiilor. In timpul modelarii logice a datelor s-au creat diferite relatii, atat pe baza normalizarii ascendente a perspectivelor utilizatorilor, cat si a transformarii uneia sau a mai multor diagrame entitate-relatie in seturi de relatii. In structura acestor seturi de relatii pot exista unele relatii redundante, cum ar fi existenta a doua sau mai multe relatii care descriu acelasi tip de entitate, ce ar trebui sa fuzioneze si sa se renormalizeze pentru extragerea eventualelor redundante.