 |
|
 |  |
|
|
| |
 | Biologie | Chimie | Didactica | Fizica | Geografie | Informatica |
| Istorie | Literatura | Matematica | Psihologie |
BAZE DE DATE IN ADMINISTRATIA PUBLICA: PROIECTARE, ORGANIZARE, MANAGEMENT
1. Introducere in metodologia de proiectare a bazelor de date (BD)
Metodologia de proiectare, consta intr-o abordare structurata, in care se utilizeaza proceduri, tehnici, instrumente si documentatii, pentru a sustine si facilita procesul de proiectare.
O metodologie de proiectare consta in mai multe faze, continand etape care indruma proiectantul in alegerea tehnicilor adecvate fiecarei etape a proiectului; de asemenea il ajuta la: planificare, administrare, control si evaluarea proiectelor de dezvoltare a bazelor de date. In final are loc o abordare structurata de analiza si modelare a unui set de cerinte privind BD, intr-o maniera standardizata si organizata.
Metodologia de proiectare a BD, consta din trei faze principale:
1.1. Proiectarea conceptuala a BD
Aceasta faza F1, reprezinta procesul de constituire a unui model al informatiilor utilizate in cadrul unei intreprinderi, independent de toate consideratiile de ordin fizic.
1.2. Proiectarea logica a BD
Aceasta faza F2, consta in procesul de construire a unui model al informatiilor utilizate in cadrul unei intreprinderi, baza pe un anumit model de date, dar independent de un anumit SGBD si de alte considerente de ordin fizic.
1.3. Proiectarea fizica a BD
Aceasta faza F3 reprezinta procesul de realizare a unei descrieri a implementarii bazei de date intr-o capacitate de memorare secundara; descrie structuri de memorare si metode de acces utilizate pentru realizarea unui acces eficient la date [50] .
2. Proiectarea fizica a BD
Urmatoarele aspecte s-ar putea dovedi de importanta pentru succesul proiectarii BD:
lucrul interactiv cu utilizatorii cat de multi trebuie;
urmarirea unei metodologii structurate de-a lungul procesului de modelare a datelor;
utilizarea unei abordari coordonata prin date;
incorporarea consideratiilor structurale si de integritate in modelul de date;
combinarea tehnicilor de conceptualizare, normalizare si validare a tranzactiilor in metodologia de modelare a datelor;
utilizarea diagramelor, pentru a reprezenta cat mai mult din modelul de date;
utilizarea unui limbaj de proiectare a BD Data Base Design Language (BDDL) pentru a reprezenta semantica suplimentara a datelor;
construirea unui dictionar care sa suplimenteze diagramele modelului de date;
disponibilitatea de a repeta anumite etape.
Metodologia de proiectare a BD consta dintr-o serie de etape:
3. Proiectarea conceptuala a BD (etape)
E1. Constituirea modelului de date conceptual local, pentru fiecare vedere a utilizatorului.
E1.1. Identificarea tipurilor de entitati
E1.2. Identificarea tipurilor de relatii
E1.3. Identificarea si asocierea atributelor cu tipurile de entitati sau
relatii
E1. Determinarea domeniilor atributelor
E1.5. Determinarea atributelor cheie candidat si primare
E1.6. Specializarea/generalizarea tipurilor de identitati
E1.7. Desenarea diagramei Entitate-Relatie
E1.8. Revizuirea modelului de date conceptual local, impreuna cu
utilizatorul
Faza de proiectare conceptuala a bazelor de date incepe cu crearea unui model de date conceptual al intreprinderii, care este total independent de detaliile privind implementarea, cum ar fi elementele de software ale sistemului SG-BD tinta, programele aplicatie, limbajele de programare, platforma hardware sau orice consideratie de ordin fizic.
In continuare se vor prezenta etapa cu etapa realizarea unui proiect conceptual al unui BD.
Proiectarea conceptuala si logica a BD este impartita in trei etape principale.
Obiectivul este de a descompune proiectarea in activitati mai usor manevrabile, prin examinarea diverselor perspective ale utilizatorilor asupra intreprinderii sau vederilor utilizatorilor.
O Vedere este rezultatul dinamic al uneia sau a mai multor operatii relationale, care actioneaza asupra relatiilor de baza pentru a realiza o alta
relatie. O vedere este o relatie virtuala care, in realitate nu exista in BD, ci este produsa in momentul respectiv la cererea unui anumit utilizator.
In cadrul acestei etape se transpun modelele de date logice locale pentru modelul relational. In aceasta etapa se elimina caracteristicile indezirabile care ar fi dificil de implementat intr-un sistem SGBD relational - din modelele de date. Modelele logice sunt apoi validate prin utilizarea tehnicii de normalizare.
Normalizarea este o tehnica de realizare a unui set de relatii cu proprietati dezirabile, date fiind cerintele unei intreprinderi. Procesul de normalizare a fost realizat prima data de catre E.F Codd (1972).
Normalizarea, adese ori, consta dintr-o serie de teste asupra unei relatii, pentru a se constata daca aceasta satisface sau violeaza cerintele unei anumite forme normale. Initial au fost introduse trei forme normale denumite astfel: prima (1NF), a doua (2NF), a treia (3NF) forma normala. Toate aceste forme normale se bazeaza pe dependentele functionale dintre atributele unei relatii. Mai tarziu, au fost introduse forme normale superioare, cum ar fi cea de-a patra (4NF) si cea de-a cincea (5NF) forma normala.
Normalizarea constituie un mijloc eficient de garantare a faptului ca modelele sunt coerente si logice din punct de vedere structural si au o redundanta minima. Modele de date sunt validate si pentru tranzactiile pe care este necesar sa le accepte.
Validarea reprezinta procesul de garantare a faptului ca se realizeaza un model "corect".
Dupa etapa E2, modelele de date logice ar putea fi utilizate, daca este necesar, pentru a realiza implementarea de prototipuri ale BD pentru vederile utilizatorilor.
Implica imbinarea modelelor de date logice locale (care reprezinta vederi diferite ale utilizatorilor), pentru a obtine un model de date logice global unic al intreprinderii (care reprezinta vederile tuturor utilizatorilor).
Pe parcursul intregii metodologii, utilizatorii joaca un rol foarte important in revizuirea si validarea continua a modelului de date si a documentatiei de sustinere a acestuia. Proiectarea BD este un proces interactiv, care are un punct de plecare si o procesiune numeroasa de imbunatatiri. Este posibil ca deciziile luate in cadrul unei etape sa conduca la modificarea deciziilor luate in decursul unei etape anterioare.
Metodologia trebuie sa actioneze ca un ghid in mod eficient in activitatea de proiectare a BD.
Consta in continuarea modelului de date conceptual local pentru fiecare vedere a utilizatorilor specificata.
Prima etapa in proiectarea BD consta in realizarea unor modele de date conceptuale, pentru fiecare vedere a utilizatorilor asupra intreprinderii. O vedere a utilizatorului reprezinta datele cerute de catre un anumit utilizator pentru a lua o decizie corecta sau a efectua o anumita activitate. De obicei, vederea unui utilizator constituie o zona functionala a intreprinderii, cum ar fi: productia, marketing, vanzarile, personalul, contabilitatea sau controlul aprovizionarii. Un utilizator poate fi o persoana reala sau un grup de persoane care utilizeaza in mod direct sistemul. Utilizatorul se poate referi la un raport produs de catre sistem sau poate solicita rezultatele unei tranzactii care trebuie acceptata de catre acestea. Vederile utilizatorilor pot fi identificate utilizand diverse metode: pot fi examinate diagramele de flux de date care au fost realizate mai inainte, in scopul de a identifica zonele functionale si posibil functiile individuale, ar putea fi chestionati utilizatorii se pot examina procedurile, rapoartele si formularile si/sau observa intreprinderea in functiune.
Se realizeaza o referire la modul de date conceptual, corespunzator fiecarei vederi a utilizatorilor pe care urmeaza sa modeleze, cu termenul de model de date conceptual local corespunzator vederii respective. Fiecare model de date conceptual local cuprinde: tipuri de entitati, tipuri de relatii, atributele, domeniile atributelor, cheile candidat, cheile primare.
3.1. Identificarea tipurilor de entitati
In aceasta etapa obiectivul este identificarea principalelor tipuri de entitati din vederea utilizatorului asupra intreprinderii. Modelul de date conceptual local consta in definirea principalelor obiective care pot prezenta interes pentru utilizator. O metoda de identificare a entitatilor consta in examinarea specificatiei cerintelor corespunzatoare unei anumite functii a utilizatorului in cadrul intreprinderii.
Din aceasta specificatie se identifica substantivele sau expresiile substantivale mentionate. De asemenea, se cauta obiectivele principale, cum ar fi: personale, locurile sau conceptele de interes, excluzandu-se substantivele care reprezinta doar calitati ale altor obiecte.
O modalitate alternativa de identificare a entitatilor este de a cauta obiectele care exista pe cont propriu.
Uneori, entitatile sunt greu de identificat, datorita modului in care sunt prezentate in cadrul specificatiei cerintelor utilizatorului, uneori utilizatorii se exprima prin exemple sau analogii. Nu este intotdeauna evident daca un anumit obiect este o entitate, o relatie sau un atribut.
Proiectantii de baze de date trebuie sa aiba o vedere selectiva asupra lumii si sa clasifice lucrurile legate de intreprinderea pe care le observa.
Exista situatii sa nu existe un set unic de tipuri de entitati care pot fi deduse dintr-o anumita specificatie a cerintelor, dar intervale succesive ale procesorului de analiza, trebuie sa se ajunga la alegerea entitatilor care sunt cel putin adecvate pentru sistemul cerut.
Pe masura ce se identifica entitatile, li se atribuie denumiri care sa aiba semnificatie si sa fie evidente pentru utilizatori. Denumirea si descrierile entitatilor sunt reunite intr-un dictionar de date. Atunci cand este posibil se documenteaza numarul estimat de aparitii ale fiecarei entitati. O entitate cunoscuta sub denumiri diferite, acestea se numesc aliasuri sau sinonime si sunt inregistrate in dictionarul de date.
3.2. Identificarea tipurilor de relatii
In aceasta etapa obiectivul este identificarea relatiilor importante care exista intre entitatile identificate. De indata ce entitatile sunt identificate, urmatoarea etapa consta in identificarea relatiilor care exista intre acestea. Atunci cand se identifica entitatile, o metoda este de a cauta substantivele in specificatia cerintelor utilizatorului, de regula, relatiile sunt indicate prin expresii verbale.
In majoritatea cazurilor relatiile sunt binare (exista intre doar doua entitati), totusi trebuie sa se determine si relatiile complexe, care ar putea include mai mult de doua tipuri de entitati, precum si relatii recursive, care implica un singur tip de entitate.
O atentie deosebita trebuie pentru a detecta toate relatiile care sunt: explicite, implicite in specificatiile utilizatorului. Totusi relatiile lipsa trebuie sa iasa la iveala cand se valideaza modelul conform tranzactiilor pe care trebuie sa le accepte.
Determinarea cardinalitatii si constrangerilor de participare a tipurilor de relatii.
Dupa identificarea relatiilor care trebuie modelate, urmeaza determinarea cardinalitatii fiecareia, care poate fi: unu-la-unu (1:1), unu-la-multi (1:M) sau multi-la-multi (M:M). In plus se va determina constrangerile de participare al fiecarei entitati din cadrul unei relatii ca fiind fie totale, fie partiale. Un model care include cardinalitatea si constrangerile de participare reprezinta mai explicit semantica relatiei respective. Cardinalitatea si participarea sunt forme de constrangeri care sunt folosite pentru a verifica si mentine calitatea datelor.
Determinarea tipurilor de relatii
Pe masura ce se identifica tipurile de relatii, li se atribuie denumiri care au semnificatie si sunt existente pentru utilizator. De asemenea, se inregistreaza in dictionarul de date descrierile relatiilor si constrangerilor de cardinalitate si de participare.
Utilizarea modelarii Entitate - Relatie (ER)
Uneori este mai usor vizualizarea unui sistem complex decat descifrarea unor descrieri textuale lungi, din specificatia cerintelor utilizatorilor. Diagramele Entitate - Relatie (ER) se utilizeaza pentru a reprezenta mai usor entitatile si modelul in care sunt legate acestea unele de altele.
In cadrul fazei de proiectare a BD se recomanda modelul E-R oriunde este necesar, pentru a servi la construirea unei imagini a sectorului de intreprindere care urmeaza sa fie modelat.
3.3.Identificarea si asocierea atributelor cu tipurile
de entitati sau relatii
Obiectivul acestei etape consta in asocierea atributelor cu tipurile de entitati sau relatii adecvate. Aceasta etapa din cadrul metodologiei consta in identificarea tipurilor de fapt privind entitatile si relatiilor care trebuie reprezentate in BD.
Atributele pot fi identificate acolo unde substantivul sau expresia substantivala exprima o proprietate, calitate, identificator sau caracteristica a uneia din acela entitati sau relatii.
Atribute simple/compuse
Este foarte important de a determina daca un atribut este simplu sau compus. Atributele compuse sunt formate din atribute simple. De exemplu, atributul Adresa poate fi simplu continand toate detaliile adresei ca o singura valoare. Dar atributul poate fi si compus, fiind format din atribute simple care contin detaliile adresei ca valori separate in atribute. Strada, zona, oras si cod P. optiunea de a reprezenta detaliile adresei ca un atribut simplu sau compus este determinata de cerintele utilizatorului.
In cadrul acestei etape, este important de identificat toate atributele simple care vor fi reprezentate in modelul de date conceptual-inclusiv acela care formeaza atributele compuse.
Atributele derivate
Atributele ale caror valori pot fi deduse din valorile altor atribute se numesc derivate sau calculate. Exemple de atribute derivate sunt:
numarul de membri ai personalului care lucreaza in cadrul unei anumite filiale;
varsta unui membru al personalului;
salariile lunare totale ale tuturor membrilor personalului din cadrul unei anumite filiale;
numarul de proprietati pe care le administreaza un membru al personalului.
Uneori, aceste atribute nu sunt prezentate in modelul de date conceptuale. Atributele derivate trebuie sa fie prezente in modelul de date pentru a evita pierderea potentiala de informatii. Reprezentarea atributelor derivate va fi luata in considerare in decursul proiectarii fizice a bazei de date. In functie de modul de utilizare a atributului, pot fi calculate noi valori ale atributului derivat de fiecare data cand acesta este accesat sau cand valoarea din care deriva se modifica.
Exista situatii in care atributele par sa fie asociate mai multor tipuri de entitati, deoarece aceasta poate indica urmatoarele:
au fost identificate o serie de entitati cum ar fi Manager, Supervizor si Secretar, care pot fi identificate ca o singura entitate, denumita Personal;
a fost identificata o relatie intre tipuri de entitati, in acest caz, trebuie asociat atributului o singura entitate - si anume cea parinte.
Documentarea atributelor
De indata ce se identifica atributele, li se atribuie denumiri care sunt semnificative si evidente pentru utilizatori.
Pentru fiecare atribut se inregistreaza urmatoarele informatii:
denumirea si descrierea atributului;
orice aliasuri sau sinonime cunoscute ale atributului;
tipul de date si lungimea lor;
valorile prestabilite ale atributelor (daca sunt specificate);
faptul daca atributul trebuie specificat;
daca atributul este compus si in acest caz, care sunt atributele simple din care este format;
daca atributul este derivat si in acest caz cum trebuie calculat;
daca atributul are valori multiple [48] .
3. Determinarea domeniilor atributelor
In aceasta etapa obiectivul este, determinarea domeniilor atributelor din modelul de date conceptual local.
Un domeniu este un recipient de valori din care unul sau mai multe atribute isi iau valorile. De exemplu, s-ar putea defini:
domeniul atributelor ce reprezinta numerele de filiala valabile, ca fiind un sir de trei caractere, de lungime variabila, in care primul caracter este o litera, iar urmatorul sau urmatoarele doua sunt cifre de la 1 la 99;
domeniul atributelor corespunzatoare numerelor de telefon si de fax valabile, ca fiind un sir de cifre;
valorile posibile ale atributelor Sex din entitatea Personal, ca fiind ori "B" ori "F". domeniul acestui atribut este un sir format dintr-un singur caracter care consta in valorile "B" sau "F".
Intr-un model de date complete se specifica domeniul corespunzator fiecaruia dintre atributele acestuia care include:
setul de valori impuse pentru un atribut;
dimensiunea si formatele campurilor atributelor.
Se pot specifica si alte informatii referitoare la domeniu, cum ar fi operatiile permise asupra unui atribut. Documentarea domeniului atributelor se realizeaza pe masura ce se identifica domeniile atributelor, se inregistreaza caracteristicile acestora in dictionarul de date.
Intrarile de atribute din dictionarele de date se reactualizeaza, pentru a inregistra domeniile acestora.
3.5. Determinarea atributelor cheie candidate si primare
In aceasta etapa obiectivul consta in identificarea cheii (cheilor) candidate pentru fiecare entitate si daca exista mai mult decat o cheie candidat - selectionarea celei care va fi cheia primara.
O cheie candidat este un atribut sau un set minimal de atribute ale unei entitati, care identifica in mod unic fiecare aparitie a acesteia. Se poate identifica mai mult decat o singura cheie candidat, dar in acest caz trebuie sa alegem una dintre ele drept cheie primara, celelalte chei candidat se numesc chei alternative.
La alegerea unei chei primara din cele candidate trebuie sa se tina seama de urmatoarele, care ajuta la efectuarea selectarii:
se alege cheia candidat cu setul minim de atributi;
se alege cheia candidat careia probabilitatea de modificare a valorii este mai mica;
se alege cheia candidat care are probabilitatea mai mica sa-si piarda caracterul de unitate in viitor;
se alege cheia candidat cu cel mai mic numar de caractere;
se alege cheia candidat cea mai prietenoasa din punct de vedere al utilizatorului.
In procesul de identificare al cheilor primare se constata daca o entitate este tare sau slaba.
O entitate se numeste tare daca i se poate asocia o cheie primara si este o entitate slaba daca nu i se poate asocia o cheie primara.
Cheia primara a unei entitati slabe poate fi identificata numai atunci cand relatia slaba se transforma intr-o entitate si legaturile ei cu entitatea de care apartine prin plasarea unei chei straine in cadrul acelei relatii.
Procesul de transformare in relatii a entitatilor si a legaturilor lor este foarte important, prin urmare, identificarea cheilor primare pentru entitati slabe nu poate avea loc inainte de a ajunge la acea etapa.
Este indicat sa se inregistreze identificarea cheilor primare si alternative (atunci cand exista), in dictionarul de date [28] .
3.6. Specializarea/generalizarea tipurilor de entitati
Obiectivul este identificarea tipurilor de entitati superclasa si subclasa, atunci cand este adecvat.
In cadrul acestei etape exista optiunea de a dezvolta modelul ER prin utilizarea proceselor de specializare sau de generalizare a entitatilor identificate pe parcursul etapei E 1:1.
Daca se alege tratarea prin specializare se evidentiaza diferentele prin definirea uneia sau a mai multor subclase ale unei entitati, denumita superclasa de specializare.
In cazul cand se alege tratarea prin generalizare, se incearca o identificare a caracteristicilor comune ale entitatilor,pentru a defini o entitate generalizata denumita superclasa de generalizare. In general, se opteaza pentru generalizarea entitatilor, bazandu-se pe existenta atributelor comune si a relatiilor asociate fiecaruia.
De obicei, nu exista indicatii stricte privind situatiile in care este recomandabila realizarea modelului ER prin specializare sau generalizare, deoarece aceasta alegere este, adeseori, subiectiva si depinde de caracteristicile particulare a situatiei de modelat.
Ca o indicatie utila in alegerea specializarii sau generalizarii, este recomandabila realizarea modelului ER, trebuie sa se incerce reprezentarea entitatilor importante si relatiilor cat mai riguros posibil. Gradul de specializare/generalizare afisat intr-o diagrama E-R, trebuie sa fie dictat de lizibilitatea diagramei si de claritatea cu care aceasta modeleaza tipurile importante de entitati si relatii. Conceptul de specializare/generalizare este asociat modelarii extinse.
Datorita faptului ca aceasta etapa este optionala se vor utiliza doar termenii de "diagrama ER" sau "model ER", atunci cand se fac referiri la reprezentarea schematica a modelelor de date.
3.7. Desenarea diagramei Entitate - Relatie (E-R)
Obiectivul acestei etape consta in desenarea unei diagrame Entitate-Relatie (ER) care sa fie o reprezentare conceptuala a vederii unui utilizator asupra intreprinderii.
3.8. Revizuirea modelului de date conceptual local,
impreuna cu utilizatorul
Aceasta se face pentru a garanta ca modelul este o reprezentare "reala" al punctului de vedere al utilizatorului asupra intreprinderii inainte de terminarea etapei E1, este necesar ca impreuna cu utilizatorul sa se treaca in revista modelul de date conceptual local, care include diagrama ER si documentatia de sustinere care-l descrie.
In cazul in care exista anomalii in modelul de date, trebuie efectuate modificarile necesare, care ar putea necesita reluarea unor etape elementare anterioare. Se va repeta acest proces, pana cand utilizatorul este gata de a "parafa" modelul drept o reprezentare "corecta" a sectorului de intreprindere care trebuie modelat.
In rezumat o metodologie de proiectare reprezinta o structura in care se utilizeaza: proceduri, tehnici, instrumente si documentatii care sustin si faciliteaza procesul de proiectare. Exista o serie de factori critici pentru succesul etapei de proiectare a bazelor de date care includ, de exemplu, lucrul introductiv cu utilizatorul si disponibilitatea de a repeta o serie de etape elementare, intermediare.
Obiectivul principal al etapei E1 din metodologia prezentata este de a construi un model de date conceptual local al unei intreprinderi, corespunzator unei anumite vederi a utilizatorului:
Vederile utilizatorilor se pot identifica utilizand diagrame de flux de date, care definesc zonele functionale si posibil functiile individuale, si/sau observarea intreprinderii in functiune;
Fiecare model de date conceptual local cuprinde: tipurile de entitati, tipurile de relatii, atributele, domeniile atributelor, cheile candidate si cheile primare;
Fiecare model de date conceptual local este sustinut de catre o documentatie, cum ar fi: dictionarul de date, care este realizat in decursul dezvoltarii modelului.
Tehnici privind organizarea logica a bazelor de date
pentru modelul relational
In decursul acestui capitol se va prezenta etapa cu etapa, o tehnologie de proiectare logica a BD pentru modelul relational. Aceasta tehnologie, incepe prin a rafina modelele de baze, conceptuale locale, transpunandu-le in modele de date logice locale, dupa care se utilizeaza acestea la extragerea unui set de relatii.
Proiectarea logica a bazelor de date reprezinta procesul de construire a unui model al informatiilor utilizate in cadrul unei intreprinderi, bazat pe un anumit model de date, dar independent de un anumit SGBD si de alte constructii de ordin fizic.
Etapele metodologiei de organizare logica a bazelor de date pentru modelul relational sunt urmatoarele:
Construirea si validarea modelului de date logice pentru fiecare vedere a utilizatorilor.
Construirea si validarea modelului de date logic global.
Etapa E2 are ca obiectiv realizarea unui model de date logic - bazat pe modelul de date conceptual al vederii utilizatorului asupra intreprinderii - urmat de validarea acestuia prin utilizarea tehnicii de normalizare si conform tranzactiilor cerute.
Operatiile efectuate in cadrul acestei etape (E2) sunt:
E2.1. Transpunerea modelului de date conceptual local in modelul de date logic local.
E2.2. Extragerea relatiilor din modelul de date logic local.
E2.3. Validarea modelului prin utilizarea normalizarii.
E2. Validarea modelului conform tranzactiilor utilizatorului.
E2.5. Desenarea diagramei Entitate - Relatie (ER).
E2..6. Definirea constrangerilor de integritate.
E2.7. Revizuirea modelului de date logic loca, impreuna cu utilizatorii.
La incheierea acestei etape, (E2) trebuie sa se obtina un model al vederilor utilizatorului care sa fie: riguros, cuprinzator si fara echivoc. Daca sunt respectate aceste cerinte, se va dispune in acest stadiu de un fundament solid pentru a putea trece la etapa urmatoare (E3) care consta in combinarea modelelor de date logice locale individuale, pentru a realiza un model de date logic global al intreprinderii [3] .
1. Transpunerea modelului de date conceptual local
in model de date logic local
Dupa etapa E1 se dispune de un model de date conceptual local corespunzator vederii utilizatorului asupra intreprinderii. Dar trebuie mentionat faptul ca modelul de date poate contine unele structuri de date care ne pot fi modelate cu usurinta de catre sistemele de gestiune a BD conventionale. In cadrul acestei etape se transforma aceste randuri de date intr-o forma care este manipulata cu mai multa usurinta de aceste sisteme de gestiune conventionale.
Acest proces determina utilizatorul sa se gandeasca mai profund la semnificatia datelor si in final are ca efect o reprezentare mai reala a intreprinderii.
Obiectivele acestei etape (E2.1.) sunt:
Eliminarea relatiilor de tip M:N
In cazul cand o relatie de tip M:N este reprezentata in modelul de date conceptual, atunci trebuie sa se descompuna pentru a identifica o relatie intermediara.
Relatia de tip M:N este inlocuita cu doua relatii de tip 1:M, corespunzatoare entitatii nou identificate.
Eliminarea relatiilor complexe
O relatie complexa este cea formata din trei sau mai multe entitati. In cazul cand in modelul conceptual este identificata o reprezentare complexa, ea trebuie descompusa pentru a identifica o entitate intermediara. Relatia complexa este inlocuita cu numarul necesar de relatii de tip 1:M (binare), corespunzatoare noii entitati identificate.
Eliminarea relatiilor recursive
O relatie recursiva este un tip particular de relatie, in care un tip de entitate are o relatie cu ea insasi. In cazul cand in modelul conceptual este reprezentata o relatie recursiva, trebuie sa o descompunem pentru a identifica o entitate intermediara.
De exemplu, pentru a reprezenta situatia in care un membru al personalului supravegheaza alti membrii, se poate defini o relatie recursiva de tip unu-la-multi (1:M). Personal Supravegheaza Personal, asa cum se arata in fig. 1.(a).
Natura recursiva a acestei relatii necesita o tratare speciala, pentru a permite reprezentarea sa atat in proiectarea logica a bazei de date, cat si in implementarea fizica a acesteia. Pentru a simplifica aceasta relatie slaba denumita Personal - Alocat si o relatie aditionala de tip 1:1, denumita Supravegheat De, asa cum se arata in fig. 2. (b).
Relatia recursiva de tip M:N se descompune in acelasi mod ca si relatia binara de tip M:N descrisa anterior.
M N
Fig. 1. (a) Relatie de tip M:N Publicatie Face Reclama la anumite articole de bun casnic
Articol Publicatie
M 1
Fig. 2.(b) Descompunerea relatiei de tip M:N Face Reclama in doua relatii de tip 1:M (Enumerare si Reclama In) si entitate Reclama.
Eliminarea relatiilor cu atribute
In cazul in care in modelul de date conceptuale este reprezentata o relatie cu atribute, ea trebuie sa fie descompusa pentru a identifica o entitate.
De exemplu, se considera situatia in care se doreste sa se inregistreze numarul de ore lucrate de catre personalul angajat temporar la fiecare filiala asa cum arata fig. 3. Relatia Personal Lucreaza La Filiala are un atribut Ore_Lucrate Descompunerea relatiei Lucreaza La intr-o entitate slaba, denumita Alocatie - filiala, careia ii este alocat atributul Ore_Lucrate si se creeaza doua relatii noi de tip 1:M asa cum se arata in fig.
M N
Fig. 3. Relatia Lucreaza_La, cu atribute Ore_Lucrate
Personal Atribut La Filiala
1 M M 1
Fig. Descompunerea relatie Lucreaza La, pentru a realiza entitate Alocatie_Filiala si doua relatii de tip 1:M (Atribut La si Necesita)
Eliminarea atributelor cu valori multiple
Un atribut cu valori multiple contine mai multe valori pentru o singura entitate.
In cazul cand modelul de date conceptual este reprezentat un atribut cu valori multiple, el trebuie descompus pentru a identifica o entitate.
De exemplu, pentru a reprezenta situatia in care o singura filiala are mai multe numere de telefon, se va defini atributul Nr_Tel. al entitatii Filiala ca atribut cu valori multiple, asa cum arata in fig. 5.
Se elimina acest atribut cu valori multiple, asa cum rezulta din fig. 6. si se identifica o noua entitate denumita Telefon cu Nr._Tel. reprezentat acum ca atribut simplu - si o noua relatie de tip 1:M denumita Are.
Fig. 5. Entitatea Filiala cu un atribut cu valori multiple denumit Nr_Tel
Filiala Telefon Adresa
1 M
Fig. 6. Descompunerea atributului cu valori multiple Nr_tel intr-o relatie de tip 1:M, denumita Are si o entitate denumita telefon, cu un atribut simplu, denumit Nr_Tel
Relaxarea relatiilor de tip 1:1
In cazul cand se identifica entitatile s-ar putea intampla sa se gaseasca doua care sa reprezinte aceleasi obiecte din cadrul intreprinderii. Un exemplu poate fi urmatorul, se identifica entitatile Filiala si Departament, care, de fapt, reprezinta acelasi lucru, deoarece Filiala este un sinonim pentru Departament. In acest caz din cele doua entitati trebuie sa alegem una dintre ele, cealalta ramanand cheie alternativa.
Eliminarea Relatiilor Redundante
O relatie este redundanta daca aceeasi informatie poate fi obtinuta prin intermediul altor relatii. Obiectivul este de a realiza un model de date minimal, deci relatiile redundante nu sunt necesare, acestea trebuie eliminate. Se poate determina cu usurinta daca exista mai mult decat o cale intre doua entitati. Totusi, aceasta nu inseamna ca una dintre relatii este redundanta, deoarece ele pot reprezenta diferite asociatii din cadrul intreprinderii. Estimarea redundantei este determinata de dimensiunea temporala a relatiilor.
Se considera ca exemplu modelarea relatiei dintre entitatile Copil, Femeie, Barbat asa cum este reprezentata in fig.5.7.
1 1
Femeie Barbat
1 1
M M
Copil
Fig. 7. Relatie neredundanta
Din figura se observa ca exista doua cai intre entitatile Barbat si Copil: una directa prin intermediul relatiei Tatalui, iar cealalta prin intermediul relatiilor Casatorit Cu si Mama lui. Aparent se poate crede ca relatia Tatal Lui nu este necesara.
Aceasta presupunere este incorecta din doua motive:
Rezulta faptul ca atunci cand se estimeaza redundanta, este foarte importanta sa se analizeze semnificatia fiecarei relatii dintre entitati.
Aceasta etapa a prezentat metodele prin care poate fi simplificat modelul de date conceptual local, prin eliminarea structurilor de date care sunt dificil de implementat in bazele de date relationale.
Aceasta etapa corecta se refera la modelul de date conceptual rafinat cu denumirea de model de date logic local [6] .
2. Extragerea relatiilor din modelul de date logic local
In aceasta etapa se extrag relatiile din modelul de date logic local pentru a reprezenta entitatile si relatiile descrise in vederea utilizatorului asupra intreprinderii.
Va fi descrisa componenta fiecarei relatii utilizand un limbaj de Definirea Bazelor de Date din punct de vedere Logic (DBDL) pentru bazele de date relational (BDR).
La utilizarea limbajului DBDL se specifica urmatoarele:
Relatia pe care o are o entitate cu alta entitate este reprezentata prin mecanismul cheie primara/cheie straina.
Atunci cand se decide unde se va expedia sau plasa atributul (atributele) cheii straine, trebuie sa se identifice entitatile "parinte" si "copil" implicate in relatie.
Entitatea parinte se refera la entitatea care plaseaza o copie a cheii sale primare in relatia care reprezinta entitatea copil, unde va actiona ca o cheie straina.
Filiala Personal
1 1
M
1
1
M
Fig. 8. Un exemplu de model de date logic
Tipuri de entitati
Pentru fiecare entitate tare (obisnuita) din modelul de date logic, se creeaza o relatie care cuprinde toate atributele simple ale acelei entitati. Pentru atributele compuse, cum ar fi adresa, se introduc in relatie numai atributele constituante simple si anume: Strada, Orasul si Cod postal. De exemplu, compozitia relatiei Personal din fig. 8. este: personal (Nr_Personal, Pronume, Nume, Strada, Oras, CodP, Functie, Sex, Salariu). Cheie primara Nr_Personal.
Tipuri de entitati slabe
Pentru fiecare entitate din modelul de date logic se creeaza o relatie care sa cuprinda toate atributele simple ale acelei entitati. In plus, se include cheia primara a entitatii proprietar ca o cheie straina. Cheia primara a unei entitati slabe este partial sau total derivata din entitatea proprietar.
Din fig.8 se observa ca entitatea Personal este proprietatea entitatii slabe Ruda_Apropriata.
Compozitic relatiei Ruda_Apropriata este: Ruda_Apropiata (Nr_Personal, NumeR, Adresa, Nr_Tel, Rudenie) cheia primara Nr_Personal, NumeR; cheie straina Nr_Personal se refera la Personal (Nr_Personal).
Se observa ca atributul cheie straina al relatiei Ruda_Apropiata formeaza o parte a cheii primare corespunzatoare acestei entitati. In aceasta situatie, cheia primara a relatiei Ruda_Apropiata nu poate fi identificata decat dupa ce cheia straina a fost expediata din relatia Personal in relatia Ruda_Apropiata. In finalul acestei etape trebuie sa se identifice orice cheie primara sau cheie candidat care au fost formate in procesul de extragere a relatiilor din modelul de date logice.
Tipuri de relatii binare unu-la-unu (1:1)
In cazul fiecarei relatii binare de tipul 1:1 dintre entitatile E1 si E2 din modelul de date logic, se expediaza o copie a atributului (atributelor) cheie primara al entitatii E1 in relatia care reprezinta entitatea E2. identificarea entitatilor parinte si copil depinde de constrangerile de participare ale entitatilor E1 si E2 din cadrul relatiei. Entitatea care participa partial in relatie este desemnata drept entitate parinte, iar cea care participa total este desemnata drept entitate copil. O copie a cheii primare a entitatii parinte este plasata in relatia care reprezinta entitatea copil.
In cazul in care ambele tipuri de entitati participa total sau partial intr-o relatie de tip 1:1, desemnarea entitatilor parinte, respectiv copil, este arbitrara. Mai mult, atunci cand ambele entitati participa total intr-o relatie, exista optiunea de a reprezenta aceasta relatie utilizand legatura cheie primara/cheie straina ca mai sus, sau de a imbina atributele asociate ambelor entitati intr-o singura relatie.
In general, exista tendinte de a imbina cele doua tipuri de entitati atunci cand ele nu sunt implicate in alte relatii. Un exemplu care ilustreaza modul in care se poate reprezenta o relatie de tip 1:1 in relatiile extrase dintr-un model de date logic.
Relatia Personal Administreaza Filiala - reprezentata in fig. 8. este de tip 1:1, deoarece un singur membru al personalului administreaza o singura filiala.
Entitatea personal participa la relatia Administreaza in timp ce entitatea Filiala participa total. Entitatea care participa partial in relatia (Personal) este desemnata drept entitatea parinte, iar cea care participa total in relatie (Filiala) este desemnata drept entitate copil. Prin urmare, o copie a cheii primare a entitatii Personal (parinte) si anume Nr_Personal_este plasata in relatia Filiala (copil).
Compozitia relatiilor Personal si Filiala este:
Personal (Nr_Personal, Pronume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu).
Cheie primara Nr_Personal
Filiala (Nr_Filiala, adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager
Cheie primara Nr_Filiala
Cheie alternativa Nr_Tel sau Nr_Fax
Cheie straina Nr_Personal_Manager se refera la Personal (Nr_Personal)
De observat ca atributul Nr_Personal, care reprezinta managementul unei filiale a fost redenumit Nr_Personal_Manager, pentru a indica mai clar scopul cheii straine in relatia Filiala.
Tipuri de relatii binare unu-la-multi (1:M)
In cazul fiecarei relatii binare de tipul 1:M dintre entitatile E1 si E2 din modelul de date logic, se expediaza o copie a atributului (atributelor) cheie primara al entitatii E1 in relatia E2 pentru a actiona ca o cheie straina. Entitatea aflata in "partea singulara" a relatiei este desemnata drept entitate parinte, iar cea din "partea multipla" drept entitate copil.
Ca si anterior, pentru a reprezenta aceasta relatie, o copie a cheii primare a entitatii parinte este plasata drept cheie straina in relatia reprezentand entitatea copil.
In exemplul urmator se ilustreaza modul in care se poate reprezenta o relatie de tip 1:M prin relatii derivate dintr-un model de date logic.
Relatia Filiala Are Personal, prezentata in fig. 8., este de tip 1:M, deoarece o singura filiala are mai multi membrii de personal. In fig. 8. se observa ca entitatea Filiala se afla in partea singulara si reprezinta entitatea parinte, iar entitatea personal se afla in "partea multipla" si reprezinta entitatea copil. Relatia dintre aceste entitati este stabilit prin plasarea unei copii a cheii primare a entitatii Filiala (parinte) - si anume Nr_Filiala in relatia Personal (copil).
Compozitia relatiilor Filiala si Personal este:
Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functie, Sex, Salariu, Nr_Filial).
Cheie primara Nr_Personal
Cheie straina Nr_Filiala se refera la Filiala (Nr_Filiala)
Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)
Cheie primara Nr_Filiala
Cheie alternativa Nr_Tel sau Nr_Fax
Cheie straina Nr_Personal_Manager se refera la personal (Nr_Personal) [15] .
Relatii de tip superclasa/subclasa
In modelul de date logic fiecare relatie de tip supraclasa/subclasa se identifica entitatea de tip superclasa drept entitate de parinte, iar cea de tip subclasa drept entitate copil.
Exista o serie de optiuni privind modul in care se poate reprezenta o astfel de relatie, sub forma de una sau mai multe relatii. Alegerea celei mai adecvate optiuni depinde de constrangerile de disjunctie si de participare ale relatiei de tip superclasa/subclasa.
De exemplu, se considera entitatile Proprietate_de_Inchiriat si Proprietate_de_Vanzare, avand la baza existenta atributelor comune si relatiile asociate fiecareia [78] .
Prin urmare, se vor prezenta entitatile Proprietate_de_Inchiriat si Proprietate_de_Vanzare drept subclase definite ale superclasei Proprietate asa cum rezulta din fig. 9.
Chirias Cumparator Proprietate-de-Vanzare Proprietate-de-Inchiriat
M N M 1
Proprietate Proprietar
M 1
Fig. 9. Superclasa Proprietate cu subclasele Proprietate:de:Inchiriat si Proprietate_de_Vanzare (Atributul adresa nu este descompus)
Exista diverse modalitati de reprezentare a acestei relatii, dupa cum se prezinta in continuare:
(Optiunea 1)
Toata_Proprietatea (Nr_proprietate, Adresa, Tipul, Cheie, Pret)
Cheia Primara Nr_Proprietate
(Optiunea 2)
Proprietatea_de_Inchiriat (Nr_Proprietate, Adresa, Tipul, Chirie)
Cheie primara Nr_Proprietate
Proprietate_de_Vanzare (Nr_Proprietate, Adresa, Tipul; Pret)
Cheie primara Nr_Proprietate
(Optiunea 3)
Proprietate (Nr_Proprietate, Adresa, Tipul)
Cheie primara Nr_Proprietate
Proprietate_de_Inchiriat (Nr_Proprietate, Chirie)
Cheie primara Nr_Proprietate
Cheie straina Nr_Proprietate se refera la Proprietate (Nr_Proprietate).
Optiunea variaza de la plasarea tuturor atributelor proprietatii intr-o singura relatie (optiunea 1), pana la impartirea acestora in trei relatii (Optiunea 3). Cea mai adecvata reprezentare a relatiei de tip superclasa/subclasa este determinata de constrangerile impuse acesteia.
Relatia pe care o are superclasa Proprietate cu subclasele sale este total disjuncta, intrucat fiecare membru al superclasei Proprietate trebuie sa fie membru al uneia dintre subclase (Proprietatea_de_Inchiriat sau Proprietate_de_Vanzare), dar nu poate apartine ambelor. Altfel spus, pentru o relatie de tip superclasa/subclasa care este total disjuncta, se creeaza catre o relatie separata care sa reprezinte fiecare subclasa si se include cate o copie a atributului (atributelor) cheie primara al superclasei in fiecare dintre acestea. Prin urmare, se va alege Optiunea 2 drept cea mai buna reprezentare a acestei relatii.
Totusi, mai exista si altii factori care pot influenta alegerea finala, cum ar fi daca subclasele sunt implicate in relatii diferite.
Documentarea relatiilor si atributelor chei straine
Compozitia relatiilor extrase din modulul de date logic se documenteaza utilizand limbajul DBDL. Se constata ca sintaxa limbajului DBDL poate fi extinsa pentru a reprezenta constrangerile de integritate asupra cheilor straine. De asemenea, Dictionarul de date trebuie reactualizat pentru a reflecta orice atribute chei noi care au fost identificate in decursul acestei etape [12] .
3 Validarea modelului de date logic prin utilizarea normalizarii
Normalizarea este utilizata pentru a imbunatatii modelul, astfel incat acesta sa satisfaca diverse constrangeri care evita dublarea inutila a datelor. Normalizarea garanteaza ca modelul este mai apropiat de intreprindere, este coerent are o redundanta minima si o stabilitate maxima. Normalizarea are rolul de stabilire a atributelor care apartin unui tip de entitate. Conceptul fundamental al teoriei relationale este acela ca atributele sunt grupate, impreuna intr-o relatie deoarece intre ele exista o legatura logica. Uneori se argumenteaza ca un proiect normalizat al unei baze de date nu prezinta o eficienta de prelucrare maxima. In general in favoarea normalizarii pledeaza urmatoarele argumente:
Proiectul normalizat organizeaza datele conform dependentelor lor functionale, astfel spus procesul se afla situat undeva intre proiectarea conceptuala si fizica
Proiectarea logica poate sa nu conduca la proiectul final, ca trebuie sa reprezinte cea mai mare conceptie, a proiectului, privind natura si semnificatie datelor din cadrul intreprinderii.
In momentul cand exista criterii specifice privind performantele proiectarea fizica poate fi diferita.
Un proiect normalizat este robust si fara anomali de reactualizare
Calculatoarele prezente sunt mult mai performante fasa de cele din anii anteriori, fapt care face ca implementarea unui proiect care exceleaza prin facilitati flexibile de utilizare, pe baza unui tip de prelucrare suplimentar.
Normalizarea implica intelegerea in totalitate a fiecarui atribut care trebuie sa fie reprezentat in baza de date, acesta reprezinta cel mai important beneficiu.
Normalizarea realizeaza un proiect al bazei de date flexibil, care poate fi extins cu usurinta
In etapa E.2.2 au fost extrase relatiile din modelul de date logic local, iar in aceasta etapa E.2.3 se va examina gruparile atributelor din fiecare din aceste relatii.
Astfel spus se va valida compozitia fiecarei relatii, utilizand regulile de normalizare.
Procesul de normalizare contine urmatoarele etape principale:
Prima forma normala (1NF), care elimina gruparile repetitive;
A doua forma normala (2NF), care elimina dependentele partiale de cheia primara;
A treia forma normala (3NF), care elimina dependentele tranzitive de cheia primara
Forma normala Boyce-Cold (BCNF), care elimina anomaliile ramase din dependentele functionale.
Obiectivul etapei E.2.3 este de a garanta ca fiecare relatie extrasa din modelul de date logic se afla cel putin in forma normala Boyce-Cold (BCFN).
In cazul cand se identifica relatii care nu se gasesc in BCNF, acest lucru ar putea indica faptul ca o parte din modelul de date logic este gresita sau ca a fost introdusa o eroare la extragerea relatiei din model. In acest caz, daca este necesar trebuie restructurat modelul de date, pentru a garanta faptul ca aceasta este o reprezentare "adevarata" a sectorului de intreprindere care este modelat [13] .
Validarea modelului conform tranzactiilor utilizatorului
Aceasta etapa consta in garantarea faptului ca modelul de date logic local accepta tranzactiile cerute de catre vederile utilizatorilor. Tranzactiile cerute de catre fiecare vedere a utilizatorilor pot fi determinate din specificatia cerintelor acestora. Prin folosirea diagramei ER, a dictionarului de date si a legaturilor cheie primara/cheie straina prezentate in relatii, se incearca efectuarea manuala a operatiilor. In cazul cand toate tranzactiile pot fi rezolvate in acest mod, se realizeaza o validare a modelului de date logic conform tranzactiilor.
Daca o tranzactie nu poate fi efectuata manual, inseamna ca exista o problema in cadrul modelului de date, care este necesar sa fie rezolvata.
In acest caz, este posibil sa se fi omis o entitate o relatie sau un atribut din componenta modelului de date.
Pentru a garanta faptul ca modelul de date logic local accepta tranzactiile cerute se vor analiza doua abordari posibile:
Necesita verificarea faptului ca modelul furnizeaza informatiile (entitati, relatii in atributele acestora) cerute de catre fiecare tranzactie, prin documentarea unei descrieri a cerintelor acestora.
Ca exemple putem lua, tranzactiile corespunzatoare entitatii Manager din cadrul unei filiale ar putea cuprinde urmatoarele operatii:
Inserarea detaliilor referitoare la un nou membru al personalului. Cheia primara a relatiei Personal este atributul Nr-personal si mai intai se verifica daca nu cumva noul numar de personal exista deja, daca exista, se interzice inserarea si se abandoneaza procesul. In cazul contrar, se insereaza detaliile referitoare la noul membru al personalului. Se controleaza ca fiecare detaliu sa fie reprezentat de catre un atribut din relatia Personal.
Stergerea detaliilor referitoare la un membru al personalului, cunoscandu-se numarul de personal. In acest caz se cauta numarul de personal respectiv in coloana corespunzatoare a relatiei Personal.
Daca nu exista a aparut o eroare a utilizatorului si detaliile nu pot fi sterse; in caz contrar se sterge treptat din relatia Proprietate, corespunzatoare proprietatii alocate acelui membru al personalului pentru a fi administrata.
A doua abordare in validarea modelului de date conform tranzactiilor cerute presupune reprezentarea schematica a caii urmate de fiecare tranzactie, direct in diagrama ER.
In figura 10 se prezinta o astfel de abordare, in care se utilizeaza tranzactiile (a) respectiv (b).
1 M
(a) (b)
Fig. 10
O reprezentare schematica a tranzactiilor (a) si (b)
Aceasta abordare permite vizualizarea zonelor din model care nu sunt cerute de catre tranzactii, precum si a acelor zone care sunt de importanta critica pentru acestea.
Prin urmare este necesar a se revedea direct suportul oferit de catre modelul de date pentru tranzactiile cerute.
In cazul cand exista zone ale modelului care nu par sa fie utilizate de vreo tranzactie, se poate pune in discutie costul reprezentarii acestor informatii in modelul de date. Pe de alta parte, daca exista zone ale modelului care nu sunt adecvate pentru furnizarea caii corecte a unei tranzactii, s-ar putea sa fie necesara analizarea posibilitatii ca anumite tipuri de entitati sau de relatii de importanta critica sa fi fost omise.
5 Desemnarea diagramei Entitate-Relatie (E.R)
Obiectivul acestei etape consta in desemnarea unei diagrame Entitate-Relatie (ER) finale, care sa constituie o reprezentare logica locala a datelor dintr-o vedere a utilizatorului asupra intreprinderii. Aceasta diagrama a fost validata prin utilizarea procesului de normalizare si conform tranzactiilor pe care trebuie sa le accepte.
6. Definirea constrangerilor de integritate
Constrangerile de integritate din cadrul unui vederi a utilizatorului asupra intreprinderii nu sunt acele care trebuie impuse pentru a proteja baza de date fata de situatia de a deveni incoerenta.
In aceasta se va specifica numai ca constrangeri de integritate sunt necesare, fara a stabili modul in care se va realiza aceasta. Se considera cinci tipuri de constrangeri de integritate privind:
Datele necesare. Se identifica atributele care trebuie sa contina o valoare valabila, adica atributele care nu au voie sa contina informatii lipsa sau null-uri. De exemplu cum ar fi atributele Nr-Persoana si Nume-Prenume din entitatea personal, trebuie sa contina intotdeauna o valoare si nu pot contine null-uri. Totusi, atributul Nr-Tel din entitatea Personal nu este necesar sa contina intotdeauna o valoare si prin urmare poate contine null-uri care pot reprezenta informatii lipsa, necunoscute sau inaplicabile.
Detaliile despre atributele din modelul de date corespunzator vederii supervizorului au fost descrise in E1.3.
Domeniile atributelor. Domeniul corespunzator unui atribut identifica multimea de valori permise pe care le poate contine acesta. De exemplu, multimea de valori corespunzatoare atributului Nr-client din entitatea Client este formata din variabile de tip sir de cinci caractere care contin valorile cuprinse intre CR1 si CR999.
Un numar de exemple de domenii ale atributelor din modelul de date logic local al supervizorului au fost descrise in E1.
Integritatea Entitatilor. Cheia primara a unei entitati nu trebuie sa admita null-uri. De exemplu, fiecare aparitie a entitatii Filiala, trebuie sa contina o valoare a atributului cheie primara, Nr-Filiala. Atributele care constituie cheia primara a fiecarei entitati au fost identificate in etapele E1.5 si E2.2.
Integritatea referentiala. In general relatiile dintre entitati sunt reprezentate prin luarea unei copii a cheii primare a entitatii parinte in relatia copil. Integritatea referentiala semnifica faptul ca, daca cheia straina a unei relatii copil contine o valoare, acea valoare trebuie sa se refere la o aparitie existenta si valabila din relatia parinte. Cum ar fi daca atributul Nr-Filiala (Cheie straina) din relatia (copil) Personal contine valoarea B3 aceasta valoare trebuie sa fie continuta in atributul Nr-Filiala (cheie primara) din relatia (parinte) Filiala.
Se va asigura integritatea referentiala prin specificarea unor constrangeri de existenta asupra cheilor primare si straine. Aceste constrangeri definesc conditiile in care sunt reactualizate sau sterse aparitiile unei chei primare, respectiv inserate sau reactualizate aparitiile unei chei straine.
Inserarea unei noi aparitii a unei chei primare sau stergerea unei aparitii a unui chei straine nu constituie cauza unor probleme privind integritatea referentiala.
Pentru fiecare cheie straina unei relatii, trebuie definite conditiile de reactualizare sau stergerea cheii primare corespunzatoare. In definirea acestor conditii se poate alege dintr-o serie de strategii. Si anume NO ACTION; CASACADE, SET NULL SET DEFAULT si NO CHECK.
Constrangerile de existenta asupra cheilor straine ale relatiei Proprietate_de_inchiriat vor fi descrise utilizand limbajul de definire al bazelor de date (DBDL):
Proprietate_ de_ inchiriat (Nr_Proprietate, Strada, Zona, Orasul, Cod P, Tipul, Camere, chirie, Nr_Proprietar, Nr_Personal, Nr_Filiala).
Cheie primara Nr_Proprietate
Cheie straina Nr_Proprietar se refera la Proprietar_Privat, (Nr_Proprietar) si Proprietar _Afacere (Nr_Proprietar) la stergere NO ACTION la reactualizare CASCADE
Cheie straina Nr_Personal se refera la Personal (Nr_Personal) la stergere SET Null la reactualizare CASCADE.
Cheie straina Nr_Filiala se refera la Filiala (Nr_Filiala) la stergere NO ACTION la reactualizarea CASCADE.
Constrangerile intreprinderii, sunt definite de catre regulile intreprinderii, care controleaza tranzactiile din "lumea reala".
De exemplu o agentie specifica faptul ca un supervizor poate supraveghea minim 5 si maxim 10 membri de personal in acelasi timp Regulile intreprinderii din specificatia cerintelor utilizatorului sunt enumerate anterior.
Documentarea constrangerilor de integritate - in modelul de date logic corespunzator vederii supervizorului se documenteaza detaliile referitoare la toate constrangerile de integritate.
Revizuirea modelului de date logic impreuna cu utilizatorul
In cadrul acestei etape se valideaza modelul de date logic local, corespunzator vederii supervizorului, prin revizuirea acesteia impreuna cu utilizatarul (utilizatarii). Este foarte important ca modelul, sa constituie o reprezentare "adevarata" a "lumii reale" asa cum este perceputa de catre supervizori. Diagrama ER actioneaza ca un mijloc de comunicare intre realizatorul (realizatorii) modelui si utilizator (utilizatori).
Este foarte important ca utilizatorii sa analizeze documentatia care sustine modelul. In cazul cand utilizatorii constata un punct slab in model sau documentatie, trebuie repetate etapele necesare. Modelul de date logic local, corespunzator vederii supervizorului din studiu evolutiv, cuprinde un model ER ca cel prezentat in figura 11 si documentatie care descrie componentele acesteia.
Fig. 11. un exemplu de model de date logic local, corespunzator vederii supervizorului din studiul evolutiv ca versiune finala [15] .
1 M
M
1 M 1
1
1
M
M
M
M
1 1
1 M
1
1
1 M
M
M 1
Fig. 11.Construirea si validarea modelului de date logic global
In cadrul acestui paragraf se va imbina modelul de date logic local, corespunzator vederii supervizorului cu cel corespunzator vederii managementului pentru a realiza modelul de date logic global. In aceasta etapa se va prezenta o posibila abordare a procesului de imbinare a modelelor de date logice locale pentru a construi un singur model de date logic global. Modelele de date logice locale care vor fi imbinate in aceasta etapa sunt prezentate in figura 11 (vederea supervizorului) si in fig. 12 (vederea managerului).
1 1
1 1 1
M
1
L
M 1 1
1 M
1 M
M M
M
M
M
1 M
M
M 1
Fig. 12 Un exemplu de model Entitate -Relatie extins, vederea managerului asupra studiului.
Copyright © 2024 - Toate drepturile rezervate
