1

2. Proiectarea bazelor de date

2.1 PROIECTAREA BD SCHIMBAREA DE PARADIGM Structura unei BD (entitile, atributele, relaiile) este determinat n timpul proiectrii BD. Abordarea proiectrii unei BD este diferit de cea a sistemelor pe baz de fiiere, unde totul era dictat de nevoile aplicative ale departamentelor individuale. n cazul BD trebuie de considerat nti datele apoi aplicaiile. Aceast schimbare a modului de tratare se numete schimbare de paradigm. Cauza principal a eecurilor sistemelor informaionale este lipsa aplicrii unei metodologii de proiectare a BD n mod structurat. Astfel rezult BD ineficiente pentru cerinele aplicaiilor, documentaia este limitat, ntreinerea dificil.

2.1.1 Poziiile persoanelor din mediul BD n acest paragraf se examineaz a 5-a component a mediului SGBD, anume persoanele. Se pot identifica patru tipuri distincte de persoane implicate n mediul SGBD:

- administratorii de date i de BD; - proiectanii de BD; - programatorii de aplicaii; - utilizatorii finali.

Administratorii de date i de BD BD i SGBD sunt resurse comune care trebuie gestionate ca orice resurs. Sarcinile administratorului de date (DA = data administrator):

- responsabil cu gestionarea resurselor de date: planificarea, elaborarea i ntreinerea strategiilor i procedurilor bazei de date

- responsabil cu proiectarea conceptual/logic a BD - consultarea i ndrumarea managerilor superiori cu privire la direcia de

dezvoltare a BD, a. BD s sprijine obiectivele generale ale organizaiei. Administratorul de baze de date (DBA data base administrator) este responsabil cu realizarea fizic a BD, avnd urmtoarele sarcini:

- proiectarea i implementarea BD, - securitatea i controlul integritii BD, - ntreinerea sistemului operaional, - asigurarea de performane satisfctoare pentru aplicaii i utilizatori;

Rolul DBA este mai tehnic i necesit cunoaterea n detaliu a SGBD i a mediului acestuia. Proiectanii de BD Exist proiectani de BD logice i proiectani de BD fizice.

2

Proiectanii de BD logice: ce anume? - se ocup cu identificarea datelor (entiti i atribute) i relaiilor dintre acestea, i

de constrngerile asupra celor care vor fi stocate n BD; - trebuie s cunoasc foarte bine datele organizaiei i a regulilor de operare ale

organizaiei; - trebuie s implice toi posibilii utilizatori ai BD n modelul creat.

Etape de proiectare a BD logice:

a) proiectarea conceptual a BD, independent de detaliile de implementare (de ex. SGBD utilizat, programele de aplicaie, limbajele de programare etc.)

b) proiectarea logic a BD, care se bazeaz pe un anumit model, de ex. relaional, ierarhic, n reea, orientat pe obiecte.

Proiectanii de BD fizice (Cum anume?) preia modelul logic i stabilete realizarea fizic:

- transpunerea modelului logic de date ntr-un set de tabele i constrngeri privind integritatea;

- selectarea de structuri de stocare i metode de acces specifice, a.. s se obin performane bune ale datelor in activitile legate de BD;

- msuri referitoare la securitatea datelor. Proiectarea fizic a unei BD trebuie s in cont de SGBDul avut n vedere; proiectantul trebuie s cunoasc funcionalitatea acestui SGBD i avantajele i dezavantajele fiecrei variante de implementare a BD. Strategia de stocare aleas trebuie s in cont de modul de utilizare. Programatorii de aplicaii Odat realizat BD trebuie implementate programele de aplicaie ce confer funcionalitatea cerut de utilizatorii finali. Aceasta este sarcina programatorilor de aplicaii. Fiecare program conine instruciuni care i cere SGBD s efectueze o operaie oarecare n BD (extragere, inserare, reactualizare, tergere de date). Programele pot fi scrise ntr-un limbaj de generaia a treia sau a patra. Utilizatorii finali Sunt clienii pentru care a fost proiectat, implementat i este ntreinut BD, pentru a le satisface necesitile informaionale. Utilizatorii simpli nu sunt contieni de SGBD. Acceseaz BD prin programe de aplicaie speciale, simplificatoare. Ei folosesc comenzi simple, opiuni din meniu. Utilizatorul simplu nu tie nimic despre BD sau SGBD (de ex. vnztorul care citete codul de bare pentru a afla preul unui produs. Exist totui un program care citete codul de bare, caut preul articolului respectiv n BD, modific cmpul cu stocul de articole, afieaz preul la cas). Utilizatorii sofisticai sunt familiarizai cu structura BD i facilitile SGBD. Pot utiliza un limbaj de interogare de nivel nalt (SQL). Pot scrie programe de aplicaie pentru uz personal.

3

2.2. O METODOLOGIE CLASIC DE DEZVOLTARE A APLICAIILOR

Pn acum am punctat importana datelor n sistemul informaional al organizaiilor, nivelurile la care se poate aborda structura i coninutul unei baze de date, precum i locul "stratului" date n aplicaiile informatice actuale. n acest capitol vom ncerca s ncadrm activitatea (activitile) de proiectare a bazei de date n demersul mai larg al dezvoltrii de aplicaii.

De la bun nceput trebuie precizat c subiectul paragrafului de fa constituie obiect de studiu pentru cel puin dou domenii ale informaiei aplicate n organizaii, sau, mai bine spus, ale sistemelor informaionale n organizaii. Mai nti, este vorba de ceea ce n literatura anglo-saxona se numete software engineering, n francez genie logiciel, iar la noi dezvoltare de aplicaii software. Este un domeniu conturat nc din anii '60 i aflat de atunci, cel puin dup spusele marilor specialiti, ntr-o permanent criz, ce nu d semne de epuizare.

Al doilea domeniu este mai larg i intete mult mai mult dect realizarea de aplicaii, dei aceasta reprezint totui un obiectiv central. Este vorba de analiza i proiectarea sistemelor informaionale. Analiza i proiectarea se ocup, printre altele, i cu investigarea tuturor proceselor, operaiunilor i tranzaciilor dintr-o firm sau instituie, cerinelor utilizatorilor i perspectivelor organizaionale, astfel nct toate aceste aspecte s fie luate n calcul n realizarea unui sistem informaional coerent, aliniat misiunii, obiectivelor i politicilor firmei. Cu alte cuvinte, analiza i proiectarea pornesc mai din amonte, de la utilizatori, procese, tranzacii economice, ncercnd s formalizeze/modeleze realitatea sub forma unei largi game de diagrame, scheme, specificaii pe care le vor nainta realizatorilor modulelor de interfa, prelucrri i date.

Una dintre cele mai cunoscute scheme de realizare (dezvoltare) a aplicaiilor de lucru cu baze de date sau, altfel spus, schema de principiu a ciclului de via al aplicaiilor cu BD este cea rezentat n figura 2.1.

Amploarea activitilor din ciclul de via a unei BD depinde de anvergura aplicaiei. Cnd sistemul dezvoltat vizeaz un numar redus de utilizatori i se refer la un ansamblu

de funcii nu din cale-afar de complex, multe etape sunt srite sau parcurse sumar. Planificarea bazei de date

Planificarea BD presupune ealonarea pai1or ciclului de viat pentru atingerea unui maximum de eficacitate. Ca i n cazul planificrii software-ului, planificarea BD presupune identificarea i evaluarea activitilor ce trebuie derulate (ntreprinse), resurselor necesare derulrii activitilor, fondului de timp, specialitilor i banilor disponibili. Planificarea BD trebuie integrat n strategia de ansamblu a firmei, unul dintre obiectivele eseniale fiind catalizarea activitilor, politicilor i strategiei unitii.

4

Fig. 2.1 Ciclul de via a aplicaiilor ce utilizeaz baze de date

Definirea sistemului

Definirea sistemului presupune specificarea domeniului i granielor aplicaiei ce lucreaz cu baza de date, utilizatorilor, aplicabilitii sale, precum i a celorlalte componente ale sistemului informaional la care se va conecta noul subsistem.

PlanificareaBD

Definireasistemului

Colectareaianalizacerinelor

ProiectareaBD

Proiectareaconceptual

Proiectarealogic

Proiectareafizic

SelectareaSGBD

Proiectareaaplicaiei

Prototipizare Implementare

ncrcareaiconversiadatelor

Testare

ntreinereoperaional

5

Colectarea i analiza cerinelor Aceasta etap implic adunarea i analiza cerinelor aplicaiilor din partea utilizatorilor.

Cerina reprezint o opiune, un element ce trebuie inclus, tratat n noul sistem. Proiectarea BD se bazeaz pe informaii despre organizaii, informaii ce trebuie preluate i gestionate de baz.

Acestea pot fi culese n diferite moduri :

intervievarea personalului din ntreprindere, cu precdere a celor mai apropiai, prin specificul activitii lor, de profilul aplicaiei, avndu-se n vedere acordarea unei atenii mrite experilor din compartimentele funcionale considerate; observarea modului de derulare a operaiilor n cadrul firmei ; examinarea documentelor, n principal a celor purttoare de informaii (primare, rapoarte) ; folosirea chestionarelor pentru preluarea informaiilor de la un mare numr de utilizatori; utilizarea experienei acumulate la proiectarea unor sisteme similare.

Informaia culeas trebuie s includ: principalele domenii (zone) i grupuri de

utilizatori; documentaia utilizat sau generat de i despre aceste domenii/grupuri de utilizatori; detaliile tranzaciilor reclamate de fiecare domeniu/grup; o list de cerine, pe prioriti a fiecrui domeniu/grup.

Rezultatul acestei activiti l reprezint specificaiile cerinelor organizaionale, prezentate, de obicei, sub forma unui set de documente n care sunt descrise, din diferite unghiuri, operaiile ntreprinderii. De obicei, cerinele specificate se prezint ntr-o form puin structurat i necesit transformarea utiliznd tehnici consacrate, cum ar fi cele de tip SAD - Structured Analisys and Design (analiz i proiectare structurat), DFD - Data Flow Diagrams (diagrame ale fluxurilor de date), diagrame HIPO - Hierarchical Input Process Output (ierarhice - intrri-prelucrri-ieiri) etc. Proiectarea bazei de date

Aceasta include proiectarea logic i fizic a BD. n urma acestei etape va fi elaborat modelul BD care va constitui suportul obiectivelor i operaiunilor organizaiei. Principalele obiective ale proiectrii BD sunt:

reprezentarea datelor i a relaiilor dintre date, formulare pe diferitele zone ale aplicaiei i ale grupurilor de utilizatori ; furnizarea unui model al datelor care s permit orice tranzacie autorizat asupra acestora ;

6

construirea unui proiect care va atinge cerinele de performan ale sistemului, cum ar fi: securitatea, timpul de rspuns etc.

Deseori ns, realizarea unui obiectiv se face n detrimentul altuia. Spre exemplu, un nivel

ridicat de securitate atrage dup sine scderea vitezei de rspuns. Exist dou abordri majore ale proiectrii BD. Abordarea bottom-up pornete de la

nivelul elementar, cel al atributelor, care sunt grupate n clase de entitati i asociaii. Normalizarea este un exemplu tipic de demers bottom-up, care d rezultate bune atunci cnd numrul atributelor nu este prea mare.

Cnd numrul de atribute este ridicat, mai nimerit este abordarea top-down, care dezvolt mai nti un model sintetic, simplificat al datelor. Cele cteva entiti sunt descompuse ulterior n mai multe etape, pn la identificarea atributelor i entitilor elementare. Modelarea folosind diagrame E-R are la baz abordarea top-down.

Exist i alte abordri ale proiectrii BD; spre exemplu, inside-out (de la interior ctre exterior) seamn cu bottom-up, dar difer prin faptul c mai nti se stabilete un set de concepte majore i apoi analiza se lrgete prin includerea n model i a altor concepte care se afla n relatie cu cele majore. Strategia mixt utilizeaz deopotriv, pentru diferitele pri ale modelului, i bottom-up, i top-down, combinnd rezultatele.

Dup cea mai mare parte a autorilor, proiectarea bazelor de date este de dou tipuri, logic i fizic, n timp ce dup alii exist trei tipuri: conceptual, logic, fizic.

Selectarea sistemului de gestiune a bazei de date

Considerat un pas opional, selectarea SGBD presupune alegerea celui mai adecvat SGBD pentru realizarea i exploatarea aplicaiei. Nu toate SGBD-urile satisfac cerinele aplicaiei, iar, pe de alt parte, cele mai performante sunt i cele mai scumpe. Cerinele de funcionalitate trebuie coroborate cu resursele disponibile, n vederea identificrii celui mai adecvat SGBD comercial pentru realizarea i exploatarea aplicaiei. Proiectarea aplicaiei

Proiectarea aplicaiei se refer la conceperea secvenelor de cod (instruciuni n limbaje de programare) ce vor lucra cu baza. Din figura 2.1 se observ c proiectarea BD i proiectarea aplicaiei sunt activiti distincte, paralele ale ciclului de via al aplicaiilor cu BD. n cea mai mare parte a cazurilor, proiectarea aplicaiei nu poate fi finalizat nainte de proiectarea bazei. Pe de alt parte, informaiile proiectrii vor fi transmise proiectrii BD.

n aceast etap trebuie verificat dac toate funciile specificate n cerinele utilizatorului se regsesc n proiectul aplicaiei. Proiectarea aplicaiei include i activitatea de proiectare a

7

tranzaciilor. De asemenea, tot acum se elaboreaz i modelul interfeei cu utilizatorul a aplicaiei. Prototipizarea

Dei opional, prototipizarea se poate dovedi deosebit de util prin construirea unui model de lucru iniial simplificat, model ce permite dezvoltatorilor i utilizatorilor s testeze i s amelioreze incremental noua aplicaie. Un mare avantaj al prototipizarii este gradul mult mai mare de acceptare a noului sistem la final, acesta fiind dezvoltat mpreun cu utilizatorii ce pot s-i exprime pe parcurs doleanele. Etapele prototipizarii sunt descrise n figura 2.2.

Fig. 2.2 Schema de principiu a prototipizrii

Implementarea

Implementarea presupune crearea definiiilor BD la nivelurile conceptual, extern, intern, precum i punerea n lucru a programelor (aplicaiei), fiind realizat utiliznd limbajul de definire a datelor (DDL) pus la dispozitie de SGBD-ul selectat. Implementarea aplicaiei se realizeaz ntr-un mediu de programare utilizand un limbaj de tip 3GL sau 4GL. Conversia i ncrcarea datelor

Acest pas este necesar atunci cnd sistemul (aplicaia) dezvoltat nlocuiete un altul. Datele trebuie transferate din vechea aplicaie n cea nou, operaie ce implic de multe ori schimbarea structurii fiierelor, a formatului, logic i fizic, al datelor, n concordan cu cerinele

Dezvoltareamodeluluidelucru

Construireaprototipului

Testareaiutilizareaprototipului

Revizuireaprototipului

Abandonareaaplicaiei

Implementareaaplicaiei

Redezvoltareaaplicaiei

Dezvoltareaunuinouprototip

Decizie

Repetaredecteoriestenecesar

8

noii aplicaii, dar i ale noului SGBD. Uneori sunt necesare (i posibile) i conversii ale unor programe din vechiul n noul sistem. Majoritatea SGBD-urilor actuale au module de import-export din/n alte SGBD-uri. Conversia aplicaiilor este, n general, mult mai complex atunci cnd se schimb limbajul/mediul de programare. Testarea

Testarea este operaiunea sistematic de verificare a funcionalitii sistemului, a gradului de adecvare la cerinele utilizatorilor. Prin testare, aplicaia este lansat n execuie, urmrindu-se depistarea eventualelor erori i ameliorarea unor parametri precum viteza, securitatea etc. Urmnd o metodologie riguroas, msurtorile din cadrul testrii dau posibilitatea evalurii calitii i fiabilitii software-ului.

Este de preferat ca utilizatorii aplicaiei s fie pe deplin implicai n procesul testrii, iar aplicaia testat s fie instalat pe un alt sistem dect cel pe care a fost conceput; n orice caz, trebuie avut n vedere i un mecanism de recuperare a datelor corupte n caz de avarie.

Exist mai multe strategii de testare a corectitudinii i funcionalitii unei ap1icaii de lucru cu BD ce pot fi aplicate individual sau combinate n cadrul aceluiai sistem:

top-down; bottom-up; fire de execuie ; test de stres.

Testarea top-down ncepe de la nivelul superior al funciilor majore ale aplicaiei. Este

util n verificarea arhitecturii sistemului, reproiectrile majore fiind semnalate din primele momente ale testrii.

Testarea bottom-up ncepe cu modulele elementare i continu pe vertical cu modulele compozite pn la nivelul general al aplicaiei.

Testarea firelor de execuie este foarte important n sistemele de prelucrare n timp real, n care sunt rulate simultan o serie de procese ce coopereaz. Acest tip de testare este mult mai complex, fiind legat de detaliile tehnice ale sistemului de operare. Fiecarui proces i se aloc un fir de execuie (thread) care este urmrit de la declanarea sa, acordndu-se o mare importan punctelor de ntlnire cu celelalte fire executate pe sistem.

Testul de stres presupune suprasolicitarea bazei i aplicaiilor. Astfel, BD se ncarc automat cu un numr extrem de mare de nregistrri, iar la aplicaie se conecteaz ct mai muli utilizatori. Astfel se depisteaz pn la ce limite rezist aplicaia.

9

ntreinerea operaional

Aceast activitate se deruleaz pe toat durata de utilizare a aplicaiei. n afar de monitorizarea BD, a programelor, de "curarea" periodica i repararea eventualelor erori hard/soft, tot n aceast activitate sunt ncorporate operaiunile de actualizare a datelor i programelor (ca urmare a unor noi oportuniti tehnologice), modificarea unor parametri (procente TVA, impozite etc.). Monitorizarea performanei sistemului se realizeaz prin raportarea la un nivel prestabilit de acceptare. Dac este cazul, o situare a performanei generale sub acest punct critic poate antrena reorganizarea BD. Altminteri, chiar i n cazul funcionrii n parametri normali, BD trebuie optimizat, avnd n vedere i facilitile oferite de SGBD.

ntreinerea i actualizarea aplicaiei sunt necesare n mai mare sau mai mic msur. Spre exemplu, ntr-un mediu economic i legislativ dinamic, cum este cel din ara noastr, deseori este necesar modificarea unor pri importante ale aplicaiei. Uneori, modificarea presupune reluarea unora sau tuturor pailor din ciclul de via al aplicaiei de lucru cu BD. 2.2 PRIVIRE DE ANSAMBLU ASUPRA PROIECTRII BAZELOR DE DATE

Dei au fost publicate destule cri dedicate proiectrii bazelor de date, subiectul continu s fie departe de epuizare. Chiar dac unii autori s-au strduit s aduc rigurozitate, uneori cu preul unei anume rigiditi, proiectarea bazelor de date rmne preponderent o art i mai puin o tiin. Problema proiectarii unei baze de date ine de elaborarea unei structuri logice i a alteia fizice n vederea ntmpinrii nevoilor informaionale ale utilizatorilor ntr-o organizaie, pentru un set definit de aplicaii.

Exist mai multe curente de idei n ceea ce privete proiectarea bazelor de date. Unul dintre acestea mparte procesul de proiectare n dou direcii: modelarea logic a datelor i proiectarea bazelor de date relaionale, definind modelarea logic a datelor ca procedur pentru reprezentarea cerinelor informaionale ntr-un format corect, consistent i stabil, iar proiectarea BD relaionale drept procedur de transformare a modelului logic al datelor ntr-o schem relaional stabil. Aici apare o inadverten, considerndu-se c o schem relaional alctuit din tabele i restriciile la care sunt supuse datele din tabele nu ar corespunde nivelului logic al bazei de date, ci nivelului fizic. n aceast abordare, metodologia de modelare logica a datelor (MLD) se deruleaza n 12 pai:

1. identificarea entitilor majore ; 2. determinarea relaiilor dintre entiti; 3. determinarea cheilor primare i alternative; 4. determinarea cheilor strine; 5. determinarea celor mai importante reguli organizaionale (key business rules) ; 6. adugarea celorlalte atribute (atributele non-cheie) ; 7. validarea perspectivelor utilizatorului folosind normalizarea ; 8. determinarea domeniilor (restriciilor asupra valorilor autorizate ale atributelor) ;

10

9. determinarea operaiunilor declanatoare (regulile care guverneaz efectele modificrilor asupra atributelor i entitilor) ; 10. combinarea perspectivelor utilizatorului; 11. integrarea cu modelele de date existente ; 12. analiza stabilitii i dezvoltrilor ulterioare.

Este evident c, dei se separ artificial proiectarea logic a bazei de date de proiectarea

bazei de date relaionale, o parte dintre paii modelrii logice sunt raportai explicit la modelul relaional. Perspectiva poate fi explicat prin faptul c, la nivelul anilor 80, modelul suveran n materie de gestiune a bazelor de date era cel relaional (suveranitate manifestat din plin i astzi), iar SGBD-urile ce puteau exploata baze de date obiectuale erau ca i inexistente.

Cea de a doua direcie, proiectare a bazei de date relaionale (PBDR), care continu operaiunile derulate n MLD, presupune urmtorii pai:

1. identificarea tabelelor ; 2. identificarea atributelor; 3. adaptarea structurii datelor la specificul SGBD-ului folosit ; 4. inventarierea regulilor organizaionale privind entitile; 5. inventarierea regulilor organizaionale privind relaiile (asociaiile) dintre entiti ; 6. inventarierea regulilor adiionale despre atribute ; 7. optimizarea structurii n vederea unui mecanism de acces ct mai eficient ; 8. definirea secvenelor de "nmnunchiere" (clustering); 9. definirea cheilor pentru calcularea adreselor logice ale nregistrrilor n tabele (hash keys) ; 10. adugarea indexurilor; 11. adugarea de date redundante; 12. redefinirea coloanelor; 13. redefinirea tabelelor.

Literatura de specialitate i practica se raporteaz ns preponderent la doar dou

componente majore ale proiectarii bazelor de date: proiectarea logica i proiectarea fizic. Din acest punct de vedere, cele 12 etape din MLD i primele 6 din aa-numita PBDR ar corespunde, n linii mari, proiectrii logice a bazei, n timp ce etapele urmtoare (7-13) din PBDR - proiectrii fizice.

O alt abordare, structureaz ciclul de via al bazelor de date pe urmtoarele etape:

1. analiza cerinelor; 2. proiectarea logic, ce se materializeaz n schema global ce conine datele i relaiile dintre ele, fiind derulat astfel :

a) modelarea E-R;

11

b) integrarea perspectivelor utilizator; c) conversia diagramelor E-R n tabele; d) normalizarea tabelelor ;

3. proiectarea fizic: selectarea indexurilor, metodelor de acces, cluster-elor de date; tot aici, se include i denormalizarea; 4. distribuirea datelor, materializat n schema de fragmentare i schema de alocare a datelor ; 5. implementarea, monitorizarea i modificarea ulterioar a bazei de date. i aici apar dubii legate de modul de derulare a normalizrii (2.d), o dat ce prin conversia diagramelor E-R se obin deja tabelele relaionale (2.c).

Ambele abordri sunt legate ndeosebi de paradigma relaional folosind n primele etape

modelul E-R, mai apropiat de lumea real. Mai nou, proiectarea bazelor de date este privit pornind de la cele trei modele n vog

astzi: relaional, obiectual i relaional-obiectual. Din aceast perspectiv, procesul proiectrii bazelor de date este prin excelen unul iterativ, incremental, ntr-o msura cu att mai mare cu ct ne apropiem de obiectual. Fiecare iteraie se materializeaz ntr-o form a schemei bazei, pornindu-se de la modelare, apoi trecndu-se de la proiectare la construcie (implementare). Cu toate acestea, activitile principale ale ciclului de via al bazei de date nu difer prea mult, cel puin la nivel general:

analiza cerinelor informaionale; modelarea datelor ; proiectarea i optimizarea bazei de date (proiectare logic i fizic) ; testarea i revizuirea bazei ; certificarea bazei de date; ntreinerea i ameliorarea bazei.

Specific acestei dezvoltri este activitatea de certificare a bazei care se constituie ca un

fel de atestat de bun funcionare acordat bazei, atestat menit a ntri ncrederea beneficiarilor bazei.

n alt idee recent se definesc trei componente ale proiectrii bazelor de date: proiectarea conceptual, ce ine de construirea unui model informaional independent de orice considerent privind aspectul fizic al datelor; proiectarea logic, ce const n construirea unui model informaional pe calapodul unui model de date consacrat (E-R, relaional, OO, OR), dar independent de tipul SGBD-ului ales i de celelalte aspecte fizice ale modelului; proiectarea fizic, ce se materializeaz n implementarea efectiv a bazei pe suportul de stocare, inclusiv aspecte ce in de asigurarea unui acces eficient i a securitii.

n acest curs, alegnd varianta mai simpl, cu cele dou tipuri de proiectare, logic i fizic, vom discuta aproape exclusiv despre proiectarea logic.

12

2.3 CONSTRUIREA DE DIAGRAME ENTITATE-RELAIE Prima etap pentru realizarea unei baze de date const n analiza sistemului. Se cunosc

mai multe tehnici de analiz, dar cea mai des ntlnit este tehnica entitate-relaie. Prin tehnica entiate-relaie (denumit i entitate-asociere) se construiete o diagram

entiate-relaie (notat E-R) prin parcurgerea urmtorilor pai: a) identificarea entitilor (componentelor) din sistemul proiectului; b) identificarea asocierilor (relaiilor) dintre entiti i calificarea lor; c) identificarea atributelor corespunztoare entitilor; d) stabilirea atributelor de identificare a entitilor.

a) Identificarea entitilor

Prin entitate se nelege un obiect concret sau abstract reprezentat prin proprietile sale. Prin convenie, entitile sunt substantive, se scriu cu litere mari i se reprezint prin dreptunghiuri. ntr-o diagram nu pot exista dou entiti cu acelai nume, sau o aceeai entitate cu nume diferite.

Pentru o baz de date din domeniul imobiliar, se pot pune n eviden urmtoarele entiti:

- DATE_PERSOAN entitate care stocheaz date personale ale ofertantului (vnztorului) sau ale clientului (cumprtorului);

- CERERI_ OFERTE conine ofertele sau cererile imobiliare propuse de vnztori, respectiv cumprtori;

- DESCRIERE_IMOBIL stocheaz informaiile referitoare la imobile; - JUDEE entitate ce conine judeele n care sunt amplasate imobilele; - LOCALITI - entitate ce conine localitile n care sunt amplasate imobilele; - STRZI - entitate ce precizeaz strzile n care sunt amplasate imobilele; - FACTURI formularul necesar unei tranzacii de cumprare-vnzare.

Figura urmtoare prezint o prim form a diagramei entitate-asociere (E-R).

Fig. 2.3. Diagrama E-R pentru domeniul imobiliar (prima form)

LOCALITATI

FACTURI

JUDETE

STRAZI

DATE_PERSOANA

CERERI_OFERTE

DESCRIERE_IMOBIL

13

b) Identificarea asocierilor dintre entiti i calificarea lor

ntre majoritatea componentelor (adic a entitilor) unui sistem economic se stabilesc legturi (asocieri). Exemplu: Exist o asociere ntre entitile CERERI_OFERTE i FACTURI deoarece facturile reprezint finalizarea unei cereri/oferte. Aceast asociere se reprezint ca n figura de mai jos.

Fig. 2.4. Prezentarea asocierii dintre entitile CERERI_OFERTE i FACTURI Sunt necesare precizarea ctorva notaii i noiuni utilizate n exemplul de mai sus:

- legturile (asocierile) se reprezint prin arce neorientate ntre entiti; - fiecrei legturi i se acord un nume plasat la mijlocul arcului i simbolizat printr-un

romb (semnificaia legturii); - numerele simbolizate deasupra arcelor se numesc cardinaliti i reprezint tipul

legturii; - cardinalitatea asocierilor exprim numrul minim i maxim de realizri a unei entiti

cu cealalt entitate asociat. Exemplu: Cardinalitatea (1,1) ataat entitii CERERI_OFERTA nseamn c o factur poate fi rezultatul tranzacionrii a minim unei cereri/oferte i a unui numr maxim de tot o cerere/ofert. Cardinalitatea (0,1) ataat entitii FACTURI nseamn c o cerere se poate finaliza prin maxim o factur sau prin nici una (0 facturi) . Aceast cardinalitate reiese din analiz:

Fig. 2.5. Determinarea cardinalitii asocierii dintre entitile CERERI_OFERTE i

FACTURI

Maximele unei cardinaliti sunt cunoscute i sub denumirea de grad de asociere, iar minimele unei cardinaliti, obligativitatea participrii entitilor la asociere.

Tipuri de asocieri (legturi) ntre entiti

Asocierile pot fi de mai multe feluri, iar odat cu asocierea, se impune stabilirea calificrii acesteia. Asocierea dintre entiti se face n funcie de

CERERI_OFERTE

1 2 3

FACTURI

F1 F2

CERERI_OFERTE suntfinalizate

prin

FACTURI(1,1) (0,1)

14

i) cardinalitatea asocierii; ii) numrul de entiti distincte care particip la asociere.

i. Dup cardinalitatea asocierii n funcie de maxima cardinalitii (gradul de asociere), se cunosc trei tipuri de asocieri, care, la rndul lor, sunt de dou tipuri, n funcie de minima cardinalitii (gradul de obligativitate al participrii la asociere):

asocieri de tip unu la unu; o asocieri pariale de tip unu la unu o asocieri totale de tip unu la unu

asocieri de tip unu la mai muli o asocieri pariale de tip unu la muli o asocieri totale de tip unu la muli

asocieri de tip muli la muli o asocieri pariale de tip muli la muli o asocieri totale de tip muli la muli.

ii. Dup numrul de entiti distincte care particip la asociere: asocieri binare (ntre dou entiti distincte); asocieri recursive (asocieri ale entitilor cu ele nsele); asocieri complexe (ntre mai mult de dou entiti distincte).

n continuare se descriu asocierile grupate dup cardinalitatea ei.

Asocieri n funcie de cardinalitatea legturii

1. Asocieri de tip unu la unu sunt asocieri n care maximele cardinalitii au valoarea 1.

Fig. 2.6. Asociere de tip unu la unu

Exemplu: Asocierea din figura 2.5 este asociere de tip 1 la 1.

2. Asocieri de tip unu la mai muli sunt asocieri n care maxima cardinalitii unei entiti este unu, iar a celeilalte entiti are valoarea muli.

Fig. 2.7. Asociere de tipul unu la mai muli

E1 E2A(...,1) (...,n)

E1 E2A(...,n) (...,1)

A(...,1)E1 E2(...,1)

15

Exemplu:

Fig. 2.8. Asociere de unu la mai muli ntre entitile LOCALITI i CERERI_OFERTE

3. Asocieri de tipul muli la muli sunt asocieri n care maximele cardinalitii au valoarea muli.

Fig. 2.9. Asociere de tipul muli la muli

Exemplu:

Fig. 2.10. Asociere de tipul muli la muli ntre entitile DEPOZIT i PRODUS

DEPOZITPRODUSnmagazie

(0,n)(0,n)

DEPOZIT

D1 D2 D3

PRODUS

P1 P2 P3

A(...,n)E1 E2(...,n)

(0,n)(1,1)LOCALITATI CERERI_OFERTE

icorespunde

LOCALITATI

L1 L2 L3

CERERI_OFERTE

1 2 3

A B

16

Observaie: Uneori (n cazul utilizrii unor SGBD), asocierea de tip muli la muli se transform n dou asocieri de tipul unul la muli fiind, de regul, mai uor de implementat i de utilizat i anume:

Fig. 2.11. Transformarea unei asocieri de tipul muli la muli (a)

n asocieri de tipul unu la muli (b) Exemplu: n cazul exemplului de mai sus (vezi figura 2.10), transformarea asocierii muli la muli n asocieri de tipul unu la muli se poate realiza prin construirea unei noi entiti DEPOZIT_PRODUS astfel:

Fig. 2.12. Transformarea asocierii de tipul muli la muli n asocieri de tipul unu la muli

Asocieri pariale i totale

Printr-o asociere parial se nelege o asociere n care nu exist obligativitatea participrii la aceast asociere a tuturor entitilor vizate, ci numai a unora dintre ele sau a nici uneia. Asocierea parial se caracterizeaz prin faptul c minima cardinalitii ataat unei entiti este zero.

Observaii (asupra minimei cardinalitii) - minima cardinalitii este zero, are drept rezultat lipsa obligativitii participrii

partenerului la aceast asociere; - minima cardinalitii este mai mare dect zero, are drept rezultat obligativitatea

participrii.

Fig. 2.13 Asocieri pariale ntre entitile E1 i E2

E1 E2 E1 E2A A

a) b)

(0,) (,) (,) (0,)

DEPOZIT

D1 D2 D3

PRODUS

P1 P2 P3

DEPOZIT_

PRODUS

D1P1 D1P3 D2P1 D3P4

(0,1)asociaz asociaz

(0,n) (0,n) (0,1)

Din E1 E2(...,n) (...,n)

n E1 E E2(...,1) (...,n) (...,n) (...,1)

A A1 A2

a) b)

17

Exemplu: Asocierea dintre entitile CERERI_OFERTE i FACTURI din fig. 2.5 reprezint o asociere parial, deoarece participarea entitii FACTURI nu este obligatorie, minima caracteristicii corespunztoare entitii CERERI_OFERTE fiind 0. O asociere este total dac toate entitile au obligativitatea s participe la asociere, adic minima cardinalitii este mai mare dect zero.

Fig. 2.14 Asocieri totale ntre entitile E1 i E2

n continuare se dau cteva exemple de asocieri totale, respectiv pariale. Exemplu: Asocieri pariale de tip unu la unu

Exemplu: Asocieri totale de tip unu la unu

E1 E2A

a)

(1,) (1,)

E1 E2(1,) (n,)

E1 E2(n,) (n,)

E1 E2(n,) (1,)

b) c)

d)

A

A

A

CERERI_OFERTE

1 2 3

FACTURI

F1 F2

DESCRIERE_IMOBIL

I1 I2 I3

CERERI_OFERTE

1 2 3

18

Exemplu: Asocieri pariale de tip unu la muli

Exemplu: Asocieri totale de tip unu la muli

Exemplu: Asocieri pariale de tip muli la muli

Exemplu: Asocieri totale de tip muli la muli

Fig. 2.13 Asocieri dup gradul i obiectivitatea lor

ELEVI

E1 E2 E3 E4

CLASE

C1 C2 C3

CERERI_OFERTE

1 2 3

LOCALITATI

L1 L2 L3

PRODUS

P1 P2 P3

DEPOZIT

D1 D2 D3 D4

STUDENTI

S1 S2 S3 S4

CURSURI

C1 C2 C3

19

n exemplul bazei de date AGENTIE_IMOBILIARA, tipurile de asocieri dintre entiti stabilite n funcie de modul n care se desfoar activitatea modelat sunt:

- JUDETE-LOCALITATI 1:n deoarece unui jude i corespund mai multe localiti;

- LOCALITATI-STRAZI 1:n - deoarece unei localiti i corespund mai multe strzi;

- STRAZI-CERERI_OFERTE 1:n deoarece unei strzi i pot corespunde mai multe oferte/cereri;

- FACTURI-CERERI_OFERTE 1:1 deoarece fiecare factur conine doar cte o ofert/cerere;

- CERERI_OFERTE-DECRIERE_IMOBIL 1:1 fiecrei cereri i se face o singur descriere de imobil;

- FACTURI- DATE_PERSOANA 1:1 o factur este ncheiat de o singur persoan;

- DATE_PERSOANA -CERERI 1:n o persoan poate lansa mai multe cereri sau oferte de imobil.

c) Identificarea atributelor entitilor i a asocierilor dintre entiti Atributele unei entiti reprezint proprieti ale acestora. Atributele sunt substantive, iar pentru fiecare atribut i se va preciza tipul fizic (integer, float, char, string etc.) Exemplu: Entitatea LOCALITI are urmtoarele atribute: codul localitii, notat cod_loc, simbolul de identificare al judeului simbol_jude i denumirea localitii nume_loc. d) Stabilirea atributelor de identificare a entitilor

Un atribut de identificare (numit cheie primar), reprezint un atribut care se caracterizeaz prin unicitatea valorii sale pentru fiecare instan a entitii. n cadrul diagramei entitate-asociere, un atribut de identificare se marcheaz prin subliniere sau prin marcarea cu simbolul # plasat la sfritul numelui acestuia.

Fig. 2.16. Notaii uzuale pentru atributele de identificare

Exemplu: Ca atribut de identificare putem considera codul numeric personal cnp pentru entitatea DATE_PERSOAN.

Pentru ca un atribut s fie atribut de identificare, acesta trebuie s satisfac unele cerine: - ofer o identificare unic n cadrul entitii;

Ea

(a)

Ea#

(b)

20

- este uor de utilizat: - este scurt (de cele mai multe ori, atributul de identificare apare i n alte entiti, drept

cheie extern). Pentru o entitate pot exista mai multe atribute de identificare, numite atribute (chei)

candidate. Dac exist mai muli candidai cheie se va selecta unul, preferndu-se unul cu valori mai scurte i mai puin volatile. Exemplu: n urma analizrii celor 4 etape necesare construirii diagramei entitate-asociere:

identificarea entitilor domeniului sau a sistemului economic; identificarea asocierilor dintre entiti; identificarea atributelor aferente entitilor i asocierilor dintre acestea; stabilirea atributelor de identificare a entitilor,

se poate prezenta forma complet a diagramei asociate domeniului ales n exemplu.

Fig. 2.17. Diagrama E-R pentru domeniul imobiliar (a doua form)

n cazul n care se dorete o diagram care s conin i atributele fiecrei entiti nsoite de precizarea atributelor de identificare (adic a cheilor primare), pentru a nu ncrca imaginea, diagrama proiectului se poate fragmenta pe mici domenii, dup cum este cazul entitii OFERTE, prezentat n figura 2.18. (S-au considerat un numr relativ mic de atribute).

STRAZI LOCALITATI JUDETE

DATE_PERSOANA

FACTURI

CERERI_OFERTE

DESCRIERE_IMOBIL

areasociat

finisate

conin

conin

(1,1) (1,1)(0,n) (0,n)areasociat

seregsete

(1,1)

(1,n)

(1,n) (1,1)

(1,1)

(1,1)

(0,1)

(1,1)incheie

(1,1)

(0,1)

21

Fig. 2.18. Reprezentarea atributelor aferente entitii CERERI_OFERTE (detaliu dintr-o diagram E-R)

n reprezentarea atributelor aferente entitii CERERI_OFERTE semnificaia atributelor este urmtoarea: cheia primar a entitii id_co reprezint numrul de ordine al cererii sau ofertei de imobil lansat de o anumit pesoan, atributul tipul specific dac este vorba de o cerere sau de o ofert, prin cnp se precizeaz codul numeric personal al clientului, data_inreg reprezint data la care s-a nregistrat oferta/cererea, apoi uremaz cteva date legate de imobil: codul strzii id_strada, numrul imobilului nr_imobil, preul minim, respectiv preul maxim al imobilului pret_min, pret_max. Ultimul atribut, tip_solutionare precizeaz dac cererea/oferta respectiv a fost soluionat; pentru o cerere/oferta nou introdus, acest atribut se va completa cu explicaia de nesoluionat.

Astfel, diagrama bazei de date AGENIE IMOBILIAR conine 7 entiti a cror asociere a fost prezentat n figura 2.19.

CERERI_OFERTE

tipul

data_inreg

cod_loc

id_strada

nr_imobil

pret_max

tip_solutionare

cnp

pret_min

id_co#

22

Fig. 2.19. Baza de date AGENIE IMOBILIAR- entiti i atribute

2.3.1 Reprezentarea constrngerilor de participare n diagramele E-R Constrngerile de participare determin dac existena unei entiti depinde de legtura

sa de alt entitate prin intermediul unei relaii.

DATE_PERSOANA

cnp#

numele

adresa

nr_telefon

email

banca_client

nr_cont_client

FACTURI

nr_factura#

id_oferta

data_factura

cnp

pret

TVA

total

STRZI

id_strada#

cod_loc#

nume_str

CERERI-OFERTE

id_co #

tip

cnp

data_inreg

tip_solutionare

cod_loc

id_strada

nr_imobil

pret_min

pret_max

LOCALITATI

cod_loc#

simbol_judet

nume_loc

JUDETE

simbol_judet#

nume_judet

DESCRIERE_IMOB IL

id_co#

tip_imobil

etaj

nr_camere

suprafata

garaj

centrala_termica

termopane

23

Exist dou tipuri de constrngeri de participare (a unei entiti ntr-o relaie): - participare total sau obligatorie (reprezentat printr-o linie dubl) - participare parial sau opional (reprezentat printr-o linie simpl).

Participarea unei entiti ntr-o relaie este total, dac existena unei entiti necesit (este condiionat de) existena altei entiti prin intermediul unei anumite relaii. Altfel participarea este parial. Exemplu. n relaia binar FILIALA Este Alocat PERSONAL (fig. 2.20) o filial poate exista, evident, numai dac are alocat personal. Deci existena entitii FILIALA este condiionat de existena entitii PERSONAL. Ca urmare entitatea FILIALA va participa total (obligatoriu) n relaia Este Alocat, i se va reprezenta cu linie dubl.

Conform regulilor de afaceri ale organizaiei, pot ns exista membri de personal care nu sunt alocai unei anumite filiale. Entitatea PERSONAL va avea deci participare parial (opional) n relaia Este Alocat, i se va reprezenta cu linie simpl.

Fig. 2.20. Constrngeri de participare

O reprezentare alternativ a constrngerilor de participare rezult din fig. 2.21, unde pe liniile de legtur sunt trecute valorile minim i maxim cu care pot participa entitile n relaie.

Fig. 2.21 Constrngeri de participare, notaie alternativ n cazul exemplului, o filial poate avea minim 5 i maxim nedefinit (N) angajai. Un angajat poate s nu fie alocat unei filiale (valoare minim 0) sau s fie alocat unei filiale, i numai uneia (valoare maxim 1).

Nr.Filiala Nr.Personal

FILIALA PERSONALEsteAlocat1 M

Nr.Filiala Nr.Personal

FILIALA PERSONALEsteAlocat(5,N) (0,1)

24

2.3.2 Problemele modelului ER n proiectarea unui model de date conceptual pot aprea aa-numite capcane de

conectare, datorit interpretrii eronate a sensului unei relaii. 2.3.2.1 Capcane n evantai Capcanele n evantai sunt acele capcane de conectare care ntr-un model ER reprezint o relaie dintre tipuri de entiti, dar cile dintre anumite apariii ale entitilor sunt ambigue.

Capcanele n evantai apar cnd dou sau mai multe relaii 1:M provin din aceeai entitate (fig. 2.22).

Din model nu rezult la ce filial este alocat un anumit membru al personalului dintr-o secie, tiind c o secie coordoneaz mai multe filiale.

Fig. 2.22 Capcan n evantai

Examinm modelul la nivel de apariii individuale prin intermediul reelei semantice (fig. 2.23).

Fig. 2.23. Reeaua semantic a modelului ER din fig. 2.22

Se poate observa capcana n evantai: Angajatul SA1 este alocat seciei S1, dar secia S1 coordonnd filialele F1 i F3, nu se tie la care dintre aceste dou filiale este alocat SA1.

SA1

SA2

SA3

r1

r2

r3

S1

S2

r4

r5

r6

F1

F2

F3

EntitilePERSONAL

RelaiaEstealocat

EntitileSECIE

RelaiaCoordoneaz

EntitileFILIALA

SECIE

Estealocat Coordoneaz

PERSONAL FILIALA

1 1

M M

25

Capcana se rezolv prin restructurarea modelului ER, a.. acesta s reprezinte corect asocierile dintre entiti (fig. 2.24).

Se observ care secie coordoneaz care filiale, i ce personal este alocat fiecrei filiale.

Fig. 2.24. Model ER restructurat

Reeaua semantic a modelului restructurat (corect) este cea din fig. 2.25.

Fig. 2.25. Reeaua semantic a modelului ER din fig. 2.24.

Angajatul SA1 este alocat filialei F1, coordonat de secia S1.

2.3.2.2 Capcane de ntrerupere

Capcanele de ntrerupere sunt acele capcane de conectare n care un model sugereaz existena unei relaii ntre tipurile de entiti, dar nu exist ci ntre anumite apariii ale acestor entiti.

EntitilePERSONAL

RelaiaEstealocat

EntitileSECIE

RelaiaCoordoneaz

EntitileFILIALA

SA1

SA2

SA3

r1

r2

r3

S1

S2

r4

r5

r6

F1

F2

F3

SECIE

EstealocatCoordoneaz

PERSONAL

FILIALA

1

1M

M

26

Capcanele de ntrerupere apar cnd n calea prin care sunt legate entitile intervine o entitate cu participare parial.

Exemplu. Din modelul din fig. 2.26 se observ urmtoarele:

Pe ramura din stnga:

- unei singure filiale i sunt alocai mai muli angajai (relaie 1:M) - filiale exist numai dac are personal, fiecare membru al personalului este obligatoriu alocat unei filiale (participri totale linii duble de legtur).

Pe ramura din dreapta:

- Un angajat (membru al personalului) poate superviza mai multe proprieti, o proprietate poate fi supravegheat de un membru al personalului (relaie 1: M)

- Nu fiecare membru al personalului supravegheaz obligatoriu proprieti i nu toate proprietile sunt supravegheate obligatoriu de un membru al personalului (participri pariale linii simple de legtur).

Din modelul din fig. 2.26 nu se poate deduce ce proprieti sunt disponibile la care filiale.

Fig. 2.26 Capcan de ntrerupere

Modelul ER sugereaz existena unei relaii ntre entitile FILIALA i PROPRIETATE_DE_NCHIRIAT, dar, aa cum rezult din reeaua semantic asociat (fig. 2.27) nu exist ci ntre anumite apariii ale entitilor.

FILIALA

SupervizeazEstealocat

Proprietatedenchiriat

PERSONAL

1

1M

M

27

Fig. 2.27. Reeaua semantic a modelului ER din fig. 2.26.

Lipsa cilor ntre anumite apariii ale entitilor FILIALA i Proprietate_de_Inchiriat se observ clar din reeaua semantic din figura 2.27.

Nu se poate deduce la ce filial este disponibil proprietatea P2.

Participarea parial a entitilor PERSONAL i PROPRIETATE_DE_NCHIRIAT n relaia Supravegheaza are ca efect faptul c unele proprieti nu pot fi asociate cu o filial prin intermediul unui membru al personalului.

Pentru rezolvarea acestei capcane de ntrerupere trebuie identificat relaia care lipsete. Aceasta este relaia Are dintre entitile FILIALA i PROPRIETATE_DE_NCHIRIAT. Se restructureaz modelul ER, introducnd relaia nou identificat Are ntre entitile ntre care lipseau cile (fig. 2.28).

Fig. 2.28. Model ER restructurat pentru eliminarea capcanei de ntrerupere.

FILIALA

SupervizeazEstealocat

PROPRIETATE_DE_NCHIRIAT

PERSONAL

1

1M

M

Are

EntitilePROPRIETATE_DE_NCHIRIATRelaia

SupervizeazEntitileFILIALA

RelaiaEstealocat

EntitilePERSONAL

P1

P2

P3

r4

r5

F1

F3

r1

r2

r3

SA1

SA2

SA3

F2

28

Fig. 2.29. Reeaua semantic a modelului ER restructurat din fig. 2.28.

Acum la nivelul apariiilor individuale, adic din reeaua semantic, se poate stabili c proprietatea P2 este disponibil la filiala F2 (fig. 2.29).

EntitilePROPRIETATE_DE_NCHIRIAT

RelaiaSupervizeaz

EntitileFILIALA

RelaiaEstealocat

EntitilePERSONAL

P1

P2

P3

r4

r5

F1

F3

r1

r2

r3

SA1

SA2

SA3

F2

Relaia Are

r1

r2

r3