Date post: | 01-Oct-2015 |
Category: |
Documents |
Upload: | ana-maria-huru |
View: | 19 times |
Download: | 2 times |
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
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