Proiectarea logica a sistemelor informatice

In cadrul acestui capitol este realizata prezentarea noului sistem prin prezentarea tuturor intrarilor sistemului, a iesirilor, precum si a interfetelor si dialogurilor. Avand in vedere intrarile si iesirile sisemului este prezentata proiectarea logica a bazei de date, activitate prin care se urmareste transformarea diagramelor entitate-relatie in relatii.

Daca in primele etape, au fost identificate si structurate cerintele sistemului, in faza de proiectare logica se efectueaza deplasarea atentiei de la prezentarea a ceea ce exista si ce se intentioneaza la descrierea a ceea ce va insemna noul sistem, cum va functiona.

Modul de percepere a noului sistem se va reda prin prezentarea tuturor intrarilor sistemului, a iesirilor, precum si a interfetelor si dialogurile. Ele se construiesc pe baza a ceea ce s-a identificat in etapele anterioare, dar tinandu-se cont si de cerintele identificate in timpul desfasurarii activitatilor din etapa de proiectare logica [1]

Toate intrarile si iesirile sistemului, in faza de proiectare logica, vor fi prezentate ca fluxuri ale datelor intre un proces manual si altul automat sau intre o sursa/ destinatie si un proces automat din diagramele fluxurilor de date. De regula se poate proiecta cate un formular sau raport pentru fiecare flux de date dintre utilizator si sistem.

Documentatia realizata in cadrul acestei etape constituie proiectul tehnic de ansamblu al sistemului.

1. Proiectarea formularelor/formatelor si a rapoartelor

In cadrul etapei de analiza a sistemului informatic, intrarile si iesirile au fost identificate si prezentate, exprimand cerintele informationale la nivelul fiecarui subsistem/ aplicatie informatica. In acel moment nu s-au prezentat toate detaliile privind formularele/formatele, rapoartele si procesul de modelare a datelor, insistandu-se mai mult pe identificarea si descrierea lor. Fiecare format/formular de intrare va fi asociat unui flux al datelor de intrare intr-un proces al DFD, iar rapoartele se pot regasi intr-un flux al datelor generate de un proces al DFD.

Un formular/format poate fi un document primar sau o macheta de ecran care contine unele date predefinite, carora li se adauga altele ce urmeaza a fi completate in rubrici speciale.

Un raport este un document economic in care sunt incluse doar date predefinite, ceea ce inseamna ca poate fi numit si document pasiv, folosit pentru a citi si vizualiza informatia.

In faza de proiectatre logica se reprezinta doar o ciorna a formularelor/formatelor, rapoartelor sau ecranelor, ele fiind privite doar ca structura si macheta. Ceea ce ne propunem in cadrul proiectarii logice poate fi realizat cu ajutorul unui editor de texte sau un produs program orientat spre grafica, sub forma unui prototip [1].

1.1. Proiectarea situatiilor cu rezultate finale (rapoartelor)

Obiectivul prezentarii detaliate a iesirilor este si acela de a determina formatul si continutul tuturor rapoartelor imprimate si ale documentelor si ecranelor furnizate de sistem.

Proiectarea iesirilor se va face astfel incat sa serveasca pentru

transmiterea rezultatelor prelucrarii pe calculator utilizatorului, intr-o forma pe care acesta sa o inteleaga si in care sa-si regaseasca cerintele sale;

transmiterea proiectului situatiilor finale programatorului, fara ambiguitati, pentru a-i permite acestuia trecerea la intocmirea programelor necesare editarii sau vizualizarii.

In proiectarea iesirilor, analistul trebuie sa elaboreze un model demonstrativ al raportului sau ecranului si sa intrebe utilizatorul daca informatiile din raport si formatul acestuia sunt acces ibile. Daca iesirile sunt inacceptabile, analistul trebuie sa le modifice [1].

Un instrument util pentru formatul rapoartelor sau ecranelor realizate pe calculator il constituie macheta imprimantei [2].

Macheta imprimantei este reprezentarea de detaliu a situatiei de iesire, cuprinzand:

antet;

titlu;

date de identificare;

cap de tabel;

date elementare ce se imprima rand de rand;

totalurile.

detalii si indicatii tehnice de realizare care se refera la:

volumul datelor de iesire;

frecventa;

numar de copii si destinatia fiecareia;

grad de precizie al calculelor;

conditii speciale de editare;

criterii de control, validare si interpretare a datelor de iesire.

Specificatiile de iesire vor cuprinde, pentru utilizator, macheta situatiei iar pentru programator macheta situatiei si o serie de indicatii tehnice de realizare.

Pe baza specificatiilor de iesire se trece la proiectarea fizica prin care se alege suportul informatiilor de iesire, se realizeaza definitivarea formei si formatului de editare a situatiilor (asezarea in pagina / ecran, spatierea intre coloane si randuri, etc.) si se definitiveaza procedurile de utilizare si interpretare a iesirilor [2].

Alegerea tipului de suport fizic de iesire (imprimanta, display, disc fix, floppy disc, banda magnetica etc.) se face in functie de: timpul de raspuns solicitat, amplasarea utilizatorului fata de calculator, hard-ul si soft-ul existent, costul suportului, masura in care raspunde necesitatilor de redare a continutului informational al situatiei finale [2].

Cand se pregatesc iesirile, este bine sa se ia in calcul ce se urmareste prin ele, astfel incat apelarea la categoriile de date de mai sus sa se efectueze in cunostinta de cauza.

In definitivarea formei si formatului de prezentare a situatiilor finale trebuie sa tinem seama de o serie de considerente practice cum ar fi [2]:

Respectarea unor cerinte ale factorilor de decizie privind macheta situatiei finale;

Restrictii tehnice;

Elemente de eficienta;

Lizibilitate - spatiere;

Utilizarea formularelor pretiparite;

Utilizarea monitoarelor sau terminalelor video;

Utilizarea generatoarelor de rapoarte.

Respectarea unor cerinte ale factorilor de decizie privind macheta situatiei finale

O serie de cerinte ale conducerii privind macheta situatiei finale obliga proiectantul la o anumita structurare si machetare a situatiilor finale. Informatiile se pot impartii in doua grupe prin prisma sistemelor informatice interne si externe. Informatiile interne reprezinta acele informatii culese, generate sau folosite in interiorul organizatiei. Informatiile externe se refera la cele colectate sau create de la sau pentru parteneri straini (facturi, rapoarte anuale, etc) [2

In functie de informatiile care pot fi vazute din punct de vedere al echipei manageriale distingem: informatii curente, de atentionare, indicatori de baza, etc.

Restrictii tehnice

In proiectarea situatiilor finale intervin o serie de restrictii datorate caracteristicilor si performantelor tehnice ale echipamentelor periferice si anume: numarul maxim de caractere pe linie; numarul maxim de linii pe pagina / ecran; facilitatile de imprimare etc. Pe piata se afla o gama variata de echipamente de redare a rezultatelor. Exista mai multe tipuri de imprimante, console si terminale video, ceea ce creeaza posibilitatea unei alegeri adecvate a perifericelor destinate obtinerii diverselor tipuri de situatii finale [2].

Elemente de eficienta

In proiectarea situatiilor finale nu trebuie sa scape atentiei si aspectele de eficienta economica privind: reducerea timpului calculator consumat cu editarea propriu-zisa a situatiilor; economie de hartie de imprimanta. Abilitatea si experienta proprie a programatorilor joaca in acest sens un rol important.

In vederea optimizarii obtinerii situatiilor finale pe imprimanta se pot folosi de la caz la caz, diverse tehnici cum ar fi: editarea mai multor tabele pe aceeasi pagina de imprimanta; editarea unei situatii imprimand fata/verso pe aceeasi coala;

Pentru a nu irosi timp cu editarea unor situatii finale voluminoase se recomanda mai intai rularea unor programe scurte care sa verifice cheile de control aplicate. Numai daca aceste chei sunt corecte, eventual verificate si de utilizator, se poate lansa editarea analitica a situatiilor finale. Programele care editeaza situatii finale voluminoase trebuie prevazute cu posibilitatea de intrerupere (respectiv de reluare a editarii in cazul unor incidente ivite in timpul rularii) sau editarea lor sub forma unui fisier ASCII sau text pe hard disc sau floppy disc, urmand imprimarea ulterioara a acestui fisier, total sau partial [2].

Lizibilitate - spatiere

Parcurgerea unei situatii finale trebuie sa fie cat mai usoara, "citirea" unei situatii nu trebuie sa dea nastere la ambiguitati. Este necesar ca situatia sa fie autoexplicativa. Pentru aceasta, antetul va contine informatii si coduri ce vor indica sursa de emitere a raportului, exprimand clar, sintetic, continutul raportului si perioada la care se refera.

Capul de tabel, impreuna cu titlul si antetul, se afiseaza pe urmatoarele pagini numai daca au intervenit schimbari in cadrul caracteristicilor de grupare fata de prima pagina, altfel se imprima doar numerotarea coloanelor de tabel.

Informatiile importante pot fi subliniate. Totalurile se separa de informatiile analitice. Informatiile care se repeta pe linii succesive se imprima o singura data [2].

Utilizarea formularelor pretiparite

Aceasta implica utilizarea unei hartii de imprimanta ce cuprinde elemente fixe ale situatiei finale, cum ar fi antetul, titlul, capul de tabel, textul explicativ etc. Aceasta conduce la o crestere a vitezei de editare si o diminuare a uzurii imprimantelor, riboanelor etc. Totodata situatiile obtinute sunt mai estetice si sunt usor de parcurs de utilizatori [2].

Utilizarea monitoarelor sau terminalelor video

Prin intermediul unui soft adecvat, monitoarele sau terminalele video ofera posibilitatea afisarii situatiilor finale, atat in regim alfanumeric, cat si in regim grafic, alegerea modului de lucru facandu-se prin intermediul unor comenzi sau comutatori.

Ecranul unui terminal video in regim alfanumeric este alcatuit din linii si coloane iar in regim grafic ecranul este privit ca o matrice de puncte denumite "pixeli".

Reprezentarea informatiilor de iesire sub forma grafica reprezinta un pas inainte fata de editarea sub forma de text a rapoartelor. Aceasta forma de afisare se recomanda factorilor de decizie de pe nivelele de conducere superioare, dat fiind gradul de sintetizare a informatiilor de iesire si volumul redus al rapoartelor.

Pe langa problemele legate de asezarea informatiilor pe ecran, la proiectarea ecranelor de iesire se iau in considerare si facilitatile oferite de monitoare sau terminalele video si anume: regimul de lucru (defilare ecran, pagina sau linie); regimul de afisare (normal, mai luminos, cu intermitente, invers video); regimul de semnalizare sonora (normal, semnal sonor dupa afisarea unui camp etc.) [2].

Utilizarea generatoarelor de rapoarte ( REPORT WRITER )

Multe limbaje de programare, pachete de programe si sisteme de gestiune a bazelor de date dispun de module specializate in editarea de rapoarte, ceea ce conduce la reducerea considerabila a eforturilor programatorilor. De obicei, aceste generatoare solicita precizarea titlului, antetului de coloana, continutul unui rand de date (de detaliu), gradele de total si maniera lor de afisare, la inceputul sau la sfarsitul grupului de date, al paginii sau raportului. De asemenea, se pot selecta dimensiunea unei linii, coloane, pagini, spatierea dintre linii, coloane, afisarea datelor privind momentul listarii, statistici etc.

Astfel de module specializate exista in pachete de programe pentru gestionarea bazelor de date cum ar fi: ACCESS, d'BASE, ORACLE, FOXPRO, PARADOX, etc.

1.2. Proiectarea codurilor

In proiectarea sistemului de coduri trebuie sa avem in vedere doua aspecte importante si anume [2]:

influenta tipului si structurii codului asupra performantelor sistemului informatic;

implicatiile utilizarii codurilor in operatiile de culegere a datelor si interpretarea rezultatelor finale de catre utilizatorii neinformaticieni.

Primul aspect ridica probleme de ordin tehnic in realizarea nomenclatorului de coduri si are in vedere facilitarea operatiilor de prelucrare, ocuparea unui spatiu de memorie interna si externa cat mai mic etc.

Celui de-al doilea aspect trebuie sa i se acorde o atentie mai mare in vederea usurarii activitatilor de culegere, verificare a datelor si interpretarea rezultatelor din situatiile finale. Avand in vedere aceste considerente, se impune ca la proiectarea unui sistem de coduri sa se respecte o serie de cerinte.

De exemplu, codul persoanei poate fi format din urmatoarele coduri elementare:

Activitatile parcurse in realizarea unui sistem de coduri sunt: [2]

analiza elementelor ce urmeaza a fi codificate;

precizarea si uniformizarea tehnologiei, a denumirilor;

stabilirea caracteristicilor si a relatiilor dintre elementele de codificat;

alegerea tipurilor de coduri; estimarea capacitatii, lungimii si formatului codurilor;

atribuirea codurilor elementelor de codificat (crearea nomenclatoarelor de coduri);

intretinerea nomenclatoarelor de coduri.

Este indicat a se utiliza, acolo unde este cazul, sistemele de codificare existente la nivelul economiei nationale (CAEN, SIRUES, SIRUTA, CNP, etc).

1.3. Proiectarea intrarilor in sistemul informatic

Datele de intrare parcurg o succesiune de etape pana la utilizarea efectiva in cadrul sistemului informatic. Aceste etape intermediare sunt: inregistrarea datelor pe documentul de intrare; conversia datelor intr-o forma acceptata de sistemul de calcul / transpunere pe suportul tehnic; verificarea sintactica si semantica a datelor de intrare; corectia datelor eronate etc.

La proiectarea intrarilor este necesar sa se realizeze, in principal urmatoarele activitati:

alegerea suportului tehnic pentru culegerea datelor

proiectarea machetelor documentelor de intrare, stabilirea instructiunilor de culegere

stabilirea regulilor de control si validare a datelor

proiectarea formularelor (videoformatului) de intrare.

Alegerea suportului tehnic al datelor de intrare se face in functie de cerintele aplicatiei informatice. Datele introduse de la terminalul video fie intra imediat in circuitul de prelucrare-actualizare a unei baze de date, fie sunt stocate pe un suport magnetic sau sunt stocate in vederea prelucrarii ulterioare. [2]

La proiectarea machetei documentelor de intrare (indiferent de metodele de prelucrare a datelor folosite ulterior) sunt respectate cateva reguli care sa inlesneasca completarea si apoi utilizarea documentului atat pentru prelucrarea automata a datelor cat mai ales pentru necesitatile curente ale salariatilor societatii economice. Nu este recomandabil sa dublam documentele primare, prin proiectarea unor documente destinate exclusiv preluarii datelor pentru necesitatile prelucrarii automate [2]

Macheta documentului primar trebuie sa contina:

antetul-ce reprezinta denumirea unitatii si/sau a serviciului care-l emite;

denumirea documentului;

coduri de identificare,

data documentului;

rubrici /casete/ randuri pentru denumirea informatiilor cantitativ-valorice si coduri;

rubrici /casete /spatii pentru semnaturi si stampile;

text explicativ, eventual indicatii de completare si verificare.

In ordonarea informatiilor pe document, deci in rubricarea documentului se va tine seama de cateva reguli: antetul se plaseaza in stanga sus; codurile si alte informatii de identificare se plaseaza in dreapta sus; sensul natural de parcurgere este de sus in jos si de la stanga la dreapta; zonele de document ce se completeaza de compartimente/ persoane diferite se marcheaza / grupeaza distinct; marimea si spatierea documentului, distanta dintre randuri, dimensiunea rubricilor, depind de locul si modalitatea de completare (manual, dactilo, automat) precum si de nivelul de calificare a personalului ce completeaza documentul.

Asezarea rubricilor pe document trebuie sa respecte ordinea fireasca de folosire a documentului si nu ordinea de utilizare a datelor in programe. Ordinea de culegere a datelor este suficient a fi precizata prin numerotarea rubricilor sau simpla lor incadrare in chenar sau utilizarea de litere ingrosate in denumirea rubricilor implicate in dialogul operator-calculator.

Atunci cand documentul exista intr-o forma pe hartie, in varianta pe calculator se va urmari pastrarea in mare masura a structurii existente, dar cu adaptari specifice noului mediu.

Regulile de control si procedurile de validare a datelor de intrare trebuie sa cuprinda [2]

reguli de verificare a volumului, secventei documentelor si a cifrelor de control (daca este cazul) pe pachetele de documente primare;

reguli pentru controlul sintactic si semantic a datelor din documentele primare. Aceste reguli se refera la: incadrarea indicatorilor numerici (in limitele de verosimilitate), corelatii logice (intre indicatorii inscrisi in acelasi document, sau cu alti indicatori din baza de date), prezenta unor informatii obligatorii (apartenenta codurilor la nomenclatoarele de coduri specifice aplicatiei informatice) etc. Aceste reguli sunt necesare pentru scrierea programelor de verificare logica a datelor de intrare.

Proiectarea formularelor(videoformatelor) de intrare pentru introducerea datelor de intrare se face in functie de modul concret de desfasurare a dialogului operator-calculator. Acest dialog se poate desfasura sub forma de [2]

intrebare-raspuns cu defilarea liniilor ecranului;

afisare pe ecran a machetei de introducere a datelor de intrare.

In prima varianta, mai usor de realizat practic, operatorul introduce succesiv, ca raspuns la intrebarile afisate pe ecran, date de intrare. La proiectarea formelor de intrare este necesar ca proiectantul sa aiba in vedere o serie de aspecte cum ar fi:

afisarea la un moment dat a unui volum redus de informatii;

afisarea la un moment dat a unei cereri de raspuns ce se refera la o singura informatie;

scurtarea raspunsului operatorului prin folosirea mnemonicelor si codificarilor;

utilizarea unor formate clare si precise pentru afisare;

evitarea cuvintelor si caracterelor dificil de citit sau inteles;

existenta unor rutine speciale de tipul HELP;

preluarea asistata a unor coduri (ex. utilizare tehnici de tip Lookup wizard in ACCESS)

In varianta a doua cursorul marcheaza de fiecare data campul curent care se introduce. Ecranul display-ului trebuie sa reproduca integral sau simplificat macheta documentului, respectand aceeasi ordine a rubricilor. Mesajele de eroare se pot afisa intr-o zona prestabilita a ecranului, insotita de avertizare sonora sau luminoasa.

Daca este cazul, pentru unele campuri (rubrici) de date se pot prelua valori implicite, atunci cand nu sunt completate. Aceste valori se preiau din nomenclatorul de coduri, fisierele bazei de date sau tabele special memorate pentru valorile asumate prin lipsa sau prin aplicarea unui algoritm. Pentru o mai usoara operare este necesar sa folosim toate facilitatile de afisare si de combinare a culorilor oferite de terminalul video (figura 1).

Figura 1. Formularul(macheta) de intrare pentru facturi

In proiectarea formularelor de intrare pot fi utilizate componente specializate in acest sens din sistemele de gestiune a bazelor de date cum ar fi ACCESS, dBASE, ORACLE, PARADOX precum si programe scrise in diverse limbaje de programare.

2. 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.

3. 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:

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

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

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

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 COD PRODUS                       CANTITATI_DE_LIVRAT A1111   0 A2222   0 B1111    150 Y9999   100

Figura Model de raport solicitat de utilizatori

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)

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

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]

3.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.

3.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.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.