Documente online.
Username / Parola inexistente
  Zona de administrare documente. Fisierele tale  
Am uitat parola x Creaza cont nou
  Home Exploreaza



























Ghid de proiectare a bazelor de date relationale

sql











ALTE DOCUMENTE

IMPORTURI-EXPORTURI DE DATE
Modificarea numelui unui obiect
INSTRUCTIUNI SQL
ACTUALIZAREA DATELOR
SUBIECTE PROPUSE Fox PRo
Programarea bazei de date: Avize de racordare
Programarea bazei de date : Evidenta orelor suplimentare
BAZE DE DATE
Algebra relationala




Ghid de proiectare a bazelor de  date relationale

 Metodologia de proiectarea a bazelor de date relationale.

În acest capitol vom învata despre:

Scopul metodologiei de proiectarea a bazelor de date.

Proiectarea bazelor de date are doua faze mari: proiectarea logica si proiectarea fizica.

Utilizatorii sistemului informatic au un rol important în proiectarea bazelor de date.

Cum documentam procesul de proiectare a bazelor de date?

Cum descompunem scopul proiectarii în vederi (view-uri) specifice utilizatorilor înrtreprinderii?

Cum utilizam modelarea Entity-Relationship (ER), pentru a crea un model conceptual local, bazat pe informatiile adunate despre view-urile utilizatorilor?

Cum proiectam un model local conceptual într-un model local logic de date?

Cum cream relatiile pentru un model conceptual local?

Cum validam modelul logic de date, utilizând technica normalizarii?

Cum compunem modelele logice locale de date, bazate pe view-urile specifice utilizatorilor, într-un model logic global de date al întreprinderii?

Cum ne asiguram ca modelul global este o reprezentare adevarata si totala a partii întreprinderii pe care vrem sa o modelam?

            Metodologia proiectarii bazei de date se compune din doua etape mari: proiectarea logica, în care proiectantul decide asupra structurii logice a bazei de date, si proiectarea fizica, în care proiectantul decide cum se va implementa structura logica în sistemul de gestiune a bazelor de date (SGBD).

            În acest capitol vom prezenta pas cu pas, crearea unei baze de date. Vom utiliza modelarea ER descrisa în capitolul 2, pentru proiectarea bazei de date; vom valida acest model prin normalizare, prezentat în capitolul 5; iar în final vom compune diferitele view-uri într-un model global al întreprinderii.

            În acest capitol vom utiliza covintele "entitate" si "relatie" în locul expresiilor "tip de entitate" si "tip de relatie". Unde aceasta utilizare ar putea crea confuzii, vom specifica "tip de entitate", respectiv "tip de relatie".

            6.1.1. Metodologia proiectarii bazelor de date

            6.1.1.1. Ce este o metodologie de proiectare?

            Definitie: Metodologie de proiectare: O aproximare structurata, care utilizeaza proceduri, tehnici, instrumente si documentatii pentru a facilita procesul de proiectare.

            Metodologia de proiectare se compune din etape, care la rândul lor se compun din pasi, care orienteaza proiectantul la fiecare nivel al crearii bazei de date.

            6.1.1.2. Proiectarea logica si fizica a bazei de date

            Definitie: Proiectare logica: Procesul de constructie a unui model de informatii folosite în 17117h711r tr-o întreprindere, bazata pe modelul de date, dar independent de particularizarile sistemului de gestiune a bazei de date si a altor considerente fizice.

            Proiectarea logica începe cu crearea modelului conceptual al bazei de date, care este independent de implementarea într-un SGBD. Modelul conceptual este apoi proiectat pe un model logic, care va influenta mai târziu modelul de date în care se va implementa.

            Definitie: Proiectare fizica: Este procesul de descriere a implementarii bazei de date într-un SGBD.

            În aceasta etapa a proiectarii este creata baza de date într-un SGBD, împreuna cu procedurile de actualizare. În aceasta etapa exista un feedback între proiectarea fizica si cea logica, pentru ca deciziile luate la implementarea fizica pot afecta baza de date logice.

            6.1.2. Prezentarea metodologiei

            În acest capitol vom prezenta o descriere a metodologiei de proiectare a bazelor de date. Prima data sa vedem care sunt pasii de urmat în proiectare:

Proiectarea logica a bazei de date relationale:                                    Crearea unui model conceptual local, pentru vederile utilizatorilor.

Identificarea tipurilor de entitati.

Identificarea tipurilor de relatii.

Identificarea si atribuirea de atribute la tipurile de entitati si tipurile de relatii.

Determinarea domeniilor de definitie a atributelor.

Determinarea atributelor care compun cheile candidate si primare.

Specializare/generalizare (pas optional).

Desenarea diagramei entity-relationship.

Verificarea modelului conceptual local cu ajutorul utilizatorului.

Crearea si validarea modelului logic local.

Proiectarea modelului conceptual local pe un model logic local.

Crearea relatiilor pentru modelul logic local.

Validarea modelului, utilizând normalizarea.

Validarea modelului din nou, utilizând tranzactiile.

Desenarea diagramei ER.

Definirea regulilor de integritate a bazei de date.

Verificarea modelului logic local cu ajutorul utilizatorului.

Crearea si validarea modelului logic global de date.

Compunerea medelelor logice locale într-un model logic global.

Validarea modelului logic global.

Verificarea posibilitatii de a completa baza de date în viitor.

Desenarea diagramei ER finale.

Verificarea modelului logic global cu ajutorul utilizatorului.

Proiectarea fizica si implementarea bazei de date relationale: Translatarea modelului logic global în SGBD.

Proiectarea relatiilor de baza în SGBD.

Crearea regulilor de integritate în SGBD.

Proiectarea si implementarea reprezentarii fizice.

Analizarea tranzactiilor.

Alegerea organizarii fisierelor.

Alegerea indecsilor secundari.

Introducerea unei redundante comntrolate.

Estimarea spatiului pe disc.

Proiectarea si implementarea unui mechanism de securitate.

Crearea view-urilor pentru utilizatori.

Proiectarea regulilor de acces la baza de date.

Verificarea sistemului operational.

            Proiectarea logica a bazei de date se divide în trei pasi mari. Primul pas are ca obiectiv, descompunerea proiectarii sistemului informatic în vederi, care se pot discuta cu utilizatorii sistemului. Modelul de date astfel creat, se valideaza prin normalizare si prin tranzactii în pasul doi. În final, se genereaza modelul global al întreprinderii, cars este la rândul lui validat si verificat cu ajutorul utilizatorului sistemului.

            Factori critici pentru succesul proiectarii logice:

Lucrul interactiv cu utilizatorul sistemului.

Folosirea unei metodologii structurate pentru procesul de proiectare a bazei de date.

Încorporarea regulilor de integritate în modelul logic de date.

Combinarea validarii conceptuale, prin normalizare si prin tranzactii, la proiectarea modelului logic de baze de date.

Utilizarea diagramelor pentru a reprezenta cât mai multe modele logice posibile.

Crearea dictionarului de date, ca supliment al modelului de date.

            6.1.3. Crearea modelului logic

În acest capitol vom prezenta pas cu pas, proiectarea unei baze de date.

            Pasul 1. Crearea modelului conceptual local, pentru utilizatori.

            Obiectivul: Crearea unui model conceptual local, pentru view-urile utilizatorilior.

            Primul pas în proiectarea bazei de date este de a colecta datele necesare pentru realizarea sistemului, ceea ce putem culege, discutând cu viitorii tilizatori ai bazei de date. Acrasta discutie presupune o despartire în vederi, a bazei de date, vederi care pot lucra separat.

            Despartirea în vederi se poate realiza în mai multe moduri. O modaliate ar fi analiza datelor globale si gasirea de parti relativ independente. O alta modalitate ar fii analiza rapoartelor, procedurilor cerute si/sau observarea sistemului existent în lucru.

            Modelele conceptuale locale trebuie sa contina:

tipuri de entitati,

tipuri de relatii,

atribute,

domeniile atributelor,

cheile candidat,

chei primare

            Pasii din prima etapa a proiectarii logice sunt:

Pasul 1.1. Identificarea tipurilor de entitati.

Pasul 1.2. Identificarea tipurilor de relatii.

Pasul 1.3. Identificarea si atribuirea de atribute la tipurile de entitati si tipurile de relatii.

Pasul 1.4. Determinarea domeniilor de definitie a atributelor.

Pasul 1.5. Determinarea atributelor care compun cheile candidate si primare.

Pasul  1.6. Specializare/generalizare (pas optional).

Pasul  1.7. Desenarea diagramei entity-relationship.

Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.

Pasul 1.1. Identificarea tipurilor de entitati

Obiectivul: Identificarea tipurilor de entitati principale în vederile utilizatorilor.

Primul pas în proiectarea bazei de date este identificarea entitatiilor din datele furnizate de utilizatori. De exemplu, daca avem informatiile Nr_Mat, Nr_Bloc, Scara, Etaj, Apartament si Nume, putem identifica entitatea Locatari. În general putem identifica entitatiile în mai multe moduri. De exemplu în locul entitatii Locatari, am putea crea o entitate Locatari cu atributele Nr_Mat si Nume, iar celelelte informatii în entitatea ProprietateLocatari.

Exista cazuri când entitatiile sunt greu de identificat, pentru ca modul de prezentare a viitorilor utilizatori necesita explicatii. Utilizatorii descriu aceste entitati, folosind sinonime si omonime, ceea ce îngreuneaza identificarea entitatilor. Sinonimele prin care se descrie aceasi entitate, se pot considera sinonime si la crearea modelului logic, evidentiind aceste sinonime ca diverse aliasuri ai entitatiilor.

Documentarea tipurilor de entitati

Dupa identificarea entitatiilor, le dam câte un nume, iar aceste nume le vom evidentia în dictionarul de date, împreuna cu explicatiile despre entitati, precum si posibilele aliasuri.

Pasul 1.2. Identificarea tipurilor de relatii

Obiectivul: Identificarea relatiilor importante dintre entitati.

Dupa identificarea entitatiilor, va trebui sa identificam si relatiile importante dintre aceste entitati. Reletiile se descriu printr-un verb al relatiei. De exemplu:

Scarile sunt Locuite de Locatari

Furnizorii Provoaca Cheltuieli

            La identificarea relatiilor vom lua în considerare doar relatiile care ne intereseaza. Degeaba exista si alte relatii care sa se poata identificate, daca nu prezinta importanta pentru problema noastra, atunci nu le luam în consideratie.

            În cele mai multe din cazuri, relatiile sunt binare, adica se realizeaza întrea exact doua entitati. Exista si relatii mai complexe, care se realizeaza între mai multe entitati, sau relatii recursive, care pune în relatie o singura entitate cu ea însasi.

            Determinarea cardinalitatii si a participarii la tipurile de relatii

            Dupa identificarea tipurilor de relatii, trebuie sa determinam cardinalitatea lor, alegând dintre posibilitatiile: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Daca se cunosc valori specifice ale cardinalitatiilor, aceste valori se scriu la documentarea relatiilor. În continuare determinam si participarea la relatie, care poate fii totala, sau partiala.

            Documentarea tipurilor de relatii

            Dupa identificarea tipurilor de relatii, le denumim si le introducem în dictionarul de date, împreuna cu cardinalitatea si participarea lor.

            Utilizarea modelarii ER

            Pentru vizualizarea sistemelor complicate, utilizam diagrama ER, pentru ca este mult mai usor de a cuprinde toate informatiile. Va propunem ca sa utilizati întotdeauna diagrama ER, pentru o mai buna vizualizare a datelor.

Pasul 1.3. Identificarea si asocierea de atribute la tipurile de entitati si tipurile de relatii

            Obiectivul: Asocierea de atribute la tipurile de entitati si la tipurile de relatii.

            Urmatorul pas în metodologie este identificarea atributelor. Aceste atribute se identifica în aceeasi mod ca si entitatiile. Pentru o mai usoara identificare, trebuie sa luam entitatiile si relatiile ra rând si sa ne punem urmatoarea întrebare: Ce informatii detinem despre aceasta . ? Raspunsul la aceasta întrebare ne va da atributele cautate.

            Atribute simple sau compuse

            Este important sa notam daca un atribut este simplu sau compus. Conform acestei informatii va trebui sa luam decizii referitoare la acel atribut. Daca un atribut este compus, atunci putem opta pentru descompunerea sa, daca este necesara prelucrarea separata a detelor compuse, sau putem sa-l lasam compus în caz contrar.

            De exemplu, atributul Adresa contine informatiile (Nr_Bloc, Scara, Etaj, Apartament). Noi va trebui sa prelucram aceste informatii separat, deci vom descompune acest atribut în cele patru atribute simple.

            Putem avea cazuri în care atributele simple sa le compunem. De exemplu în cazul atributelor Nume_Familie si Prenume, neavând nevoie de aceste informatii separat, le vom compune în atributul Nume.

            Atribute derivate (calculate)

            Sunt acele atribute, care se pot calcula din alte atribute existente în baza de date. De exemplu numarul locatarilor de pe o scara se poate numara în tipul de entitate Locatari. Deci acest atribut este atribut derivat.

            În general aceste atribute nu trebuie incluse în modelul de date, pentru ca în cazul în care se modifica atributul din care se calculeaza atributul derivat, trebuie sa se modifice si acesta. În cazul în care nu se modifica, baza de date devine inconsistenta. De aceea este important de a mentiona daca un atribut este sau nu derivat.

            Daca identificam un atribut care sa nu-l putem asocia nici unei entitati sau relatii, ne întoarcem la pasii anteriori, identificând noua relatie sau entitate la care sa asociem atributul respectiv.

            În cazul în care putem asocia acelasi atribut la mai multe entitati, atunci va trebui sa decidem daca generalizam sau nu aceste entitati, proces care este descris la pasul 1.6.

            Documentarea atributelor

            Dupa identificarea atributelor, le asociem un nume, si le înregistram în dictionarul de date, împreuna cu urmatoarele informatii:

numele si descrierea atributului,

toate aliasurile si sinonimele prin care este cunoscut atributul,

tipul de date si lungimea,

valorile initiale ale atributelor (daca exista),

daca atributul accepta sau nu valoarea nula,

daca atributul este sau nu compus, si daca este atunci atributele simple care îl compun,

daca atributul este sau nu derivat si atributul din care deriva,

daca atributul accepta sau nu mai multe valori.

            Pasul 1.2. Determinarea domeniului atributelor

            Obiectivul: Determinarea domeniului atributelor în modelul conceptual local.

            Domeniul atributului este o multime de valori pe care o poate lua. Pentru a controla în totalitate domeniul atributelor, se poate evidentia urmatoarele:

setul de valori admisibile pentru un atribut,

operatiile admisibile asupra unui atribut,

ce atribute se pot compara cu atributul respectiv, în combinatiile cu alte atribute,

marimea si formatul câmpului atributului.

            Documentarea domeniilor atributelor

            Actualizam dictionarul de date cu domeniul de definitie al fiecarui atribut.

            Pasul 1.5. Determinarea atributelor care compun cheile candidat si primare

                        Obiectivul: Identificarea cheilor candidat pentru fiecare entitate si alegerea cheilor primare în cazul în care sunt mai multe chei candidat.

            Identificarea cheilor si selectarea cheilor primare

O cheie candidat este un atribut, sau un grup de atribute care identifica unic fiecare înregistrare din tipul de entitate. Putem identifica una, sau mai multe chei candidat. În acest caz trebuie sa alegem dintre ele o cheie primara. Cheile candidat care nu sunt primare, se vor numi chei alternante. Pentru alegerea unei chei ca fiind cheie primara, vom tine cont de urmatoarele:

cheia candidat, care are un numar minim de atribute,

cheia candidat, care îsi va schimba cel mai rar valoarea,

cheia candidat, care este cel mai putin probabil sa sufere modificari în viitor,

cheia candidat, care este compusa din cele mai putine caractere (în cazul atributelor de tip caracter),

cheia candidat, care este cel mai usor de folosit din punctul de vedere al utilizatorului.

            Prin procesul de identificare a cheilor primare, deducem si daca o entitate este entitate "tare", sau entitate "slaba". Daca reusim sa identificam o cheie primara, atunci entitatea este tare, altfel este slaba. O entitate slaba nu poate exista fara o entitate tare, care sa-i fie "parinte". Cheia primara a entitatii slabe este derivata partial sau total din cheia primara a entitatii tari.

            Documentarea cheilor primare si alternante

            Înscriem cheile primare si pe cele alternante în dictionarul de date.

            Pasul 1.6. Specializarea/generalizarea tipurilor de entitati (pas optional)

            Obiectivul: Identificarea entitatiilor subclasa respectiv superclasa, între entitatiile apropiate.

            În acest pas putem opta pentru a continua modelarea ER, folosind procesul de generalizare sau specializare. Daca alegem procesul de specializare, vom încerca sa definim una, sau mai multe subclase ale entitatii respective. Daca însa alegem procesul de generalizare, vom cauta superclase pentru acea entitate.

            Un exemplu pentru procesul de generalizare ar fii entitatiile sef_de_scara si Familii. Ambele entitati au atribuite urmatoarele atribute: Nr_mat, Nr_bloc, Scara, Etaj, Apartament si Nume. Pe lânga aceste atribute, entitatea sef_de_scara mai are asociate atributul Data_intrare_func; iar entitatea Familii, atributele Nr_pers, Nr_pers_prezente si Nr_chei. Deci, cele doua entitati având atribute în comun, le putem generaliza în entitatea Locatari, care va contine atributele comune, si entitatile sef_de_scara si Familii, continând doar atributele diferite - particularizarile fata de superclasa.

            Pasul 1.7. Desenarea diagramei ER.

            Obiectivul: Desenarea unei diagrame ER. care va fi reprezentarea conceptuala a vederilor utilizatorilor despre întreprindere.

            În momentul acesta suntem în masura sa prezentam o giagrama completa a modelului bazat pe vederile utilizatorilor despre întreprindere.

            Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului

            Obiectivul: Verificarea modelului conceptual local cu ajutorul utilizatorului, pentru a vedea daca modelul este o reprezentare adevarata a vederii utilizatorului despre întreprindere.

            Înainte de a termina pasul 1, trebuie verificat modelul conceptual elaborat. Acest model include diagrama ER si documentatia anexata. În cazul în care apare orice fel de anomalie, repetam procesul de mai înainte si remediem problema.

            Pasul 2. Crearea si validarea modelului logic local

            Obiectivul: Crearea unui model logic local bazata pe modelul conceptual al utilizatorilor asupra întreprinderii si validarea ei prin procesul de normalizare si prin tehnica tranzactiilor cerute.

            În acest pas verificam modelul conceptual creat în pasul anterior si eliminam din el structurile care sunt dificil de realizat într-un SGBD. Daca la sfârsitul acestui proces modelul ete alterat, vom corecta aceste probleme si ne vom referi în continuare la modelul rezultat, ca fiind modelul logic local. Vom valida modelul logic prin procesul de normalizare si a tranzactiilor.

            Activitatile din acest pas sunt:

Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.

Pasul 2.2. Crearea relatiilor pentru modelul logic local.

Pasul 2.3. Validarea modelului, utilizând normalizarea.

Pasul 2.2. Validarea modelului din nou, utilizând tranzactiile.

Pasul 2.5. Desenarea diagramei ER.

Pasul 2.6. Definirea regulilor de integritate ale bazei de date.

Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.

            Pasul 2.1. Proiectarea modelului conceptual local pe modelul logic local

            Obiectivul: Verificarea modelului conceptual local pentru eliminarea structurilor care se pot implementa greu într-un SGBD si proiectarea modelului rezultat la modelul logic local.

            În pasul întâi am pregatit un model conceptual bazat pe informatiile date de utilizator. Acest model trebuie prelucrat, pentru a putea fi usor de prelucrat de sistemul de gestiune a bazelor de date. Obiectivele acestui pas sunt:

Eliminarea relatiilor M:N.

Eliminarea relatiilor complexe.

Eliminarea relatiilor recursive.

Eliminarea relatiilor cu atribute.

Reexaminarea relatiilor 1:1.

Eliminarea relatiilor redundante.

Eliminarea relatiilor multe-la-multe

            Daca în modelul de date apar relatii de tipul multe-la-multe (M:N), trebuie descompuse în doua relatii unu-la-multe (1:M) prin adaugarea unei noi entitati suplimentare.

            De exemplu, pot exista mai multe cheltuieli pentru o scara, dar si o cheltuiala (factura) poate sa se refere la mai multe scari. Deci relatia dintre entitatea Scari si entitatea Cheltuieli este de M:N, ceea de este evidentiat în figura 6.1.(a).

  

Figura 6.1.  (a). Relatie de tipul N:M.  (b). Relatie transfornamta în doua relatii 1:M.

            Aceasta relatie se poate elimina, prin crearea unui tip de entitate suplimentar, care sa faca legatura dintre scari si cheltuieli. Diagrama acestor relatii se vede în figura 6.1.(b).

            Notam, ca tipul de entitate nou creat - Pe_scari - este tip de entitate slaba, pentru ca depinde atît de tipul de entitate Scari, cât si de tipul de entitate Cheltuieli.

Eliminarea relatiilor complexe

            O relatie complexa este o relatie între mai mult de coua tipuri de entitati. Daca în modelul conceptual apar relatii complexe, acestea trebuie eliminate. Se pot elimina prin crearea unui nou tip de entitate, care sa fie în relatie de tipul 1:M cu fiecare tip de entitate din relatia initiala, partea cu M a relatiei fiind spre tipul de entitate nou creat.

Eliminarea relatiilor recursive

            Relatiile recursive sunt niste relatii particulare, prin care un tip de entitate este în relatie cu el însusi. Daca apare o astfel de relatie în modelul conceptual, ea trebuie eliminata. Eliminarea se poate rezolva prin crearea unei noi entitati unde sa se evidentieze fiecare entitate care este legata de entitatea din tipul de entitate initial. În acest caz vom avea o relatie de tipul 1:M între tipul de entitate initial si tipul de entitate nou creat si o relatie de tipul 1:1 între tipul de entitate nou creat si tipul de entitate initial.

Eliminarea relatiilor cu atribute

            Daca în modelul conceptual avem relatie cu atribute, putem descompune aceasta relatie, identificând un nou tip de entitate în care sa înregistram atributele necesare.

Reexaminarea relatiilor de tipul 1:1

            În modelul conceptual putem avea entitati între care sa avem relatie de        tipul 1:1. Se poate întâmpla ca aceste entitati sa fie de fapt aceeasi entitate cu nume diferite. Daca suntem în acest caz, unim cele doua entitati, cheia primara devenind cheia primara al uneia dintre entitati.

Eliminarea relatiilor redundante

            O relatie este redundanta daca se poate ajunge de la un tip de entitate la alt tip de entitate pe mai multe drumuri. Va amintim ca noi vrem sa ajungem la un model minimal si deci relatiile redundante nu sunt necesare. Decizia ca o relatie este redundanta trebuie sa fie precedata de o analiza amanuntita a relatiilor care compun cele doua drumuri dintre cele doua entitati, pentru ca pot aparea situatii, când o relatie este aparent redundanta, dar în realitate este nevoie de ea.

            În finalul acestui pas putem spune ca am eliminat din modelul conceptual acele structuri care sunt dificil de implementat si deci este mai corect ca în continuare sa ne referim la acest model ca fiind un model logic local de date.

            Pasul 2.2. Crearea de relatii peste modelul logic local

            Obiectivul: Crearea de relatii peste modelul logic.

            Relatia pe care un tip de entitate o are cu alt tip de entitate este reprezentata prin mecanismul cheie primara/cheie straina. Cheia straina pentru o entitate este reproducerea cheii primare a altei entitati. Pentru a decide entitatiile unde vom include copia cheii primare a altei entitati, trebuie înainte sa identificam entitatile "parinte" si "fiu". Entitatile "parinte" se refera la acele entitati ale caror chei primare se vor copia în entitatile "fiu".

            Pentru descrierea relatiilor vom folosi un limbaj de definire a bazei de date (Database Definition Language - DDL). În acest limbaj, specificam prima data numele entitatii, urmat de atributele asociate între paranteze. Dupa aceea identificam cheia primara si toate cheile alternante, precum si/sau cheile straine.

            Tipuri de entitati tari

            Pentru tipurile de entitati tari în modelul logic crearea unei relatii include toate atributele entitatii. Pentru atributele compuse al unei entitati, vom include numai atributele simple din compunerea atributului compus în descrierea entitatii.

            De exemplu tipul de entitate Familii, prezentata în figura 6.2. se descrie în urmatorul mod.

            Familii (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers,

Nr_pers_prezente, Nr_chei)

            Cheie primara: Nr_mat

 Figura 6.2. Exemplu de model logic.

            Tipurile de entitati slabe

            Descrierea tipurilor de entitati slabe se face la fel ca si tipurile de entitati tari, cu o completare si anume, evidentierea cheii straine. De exemplu descrierea tipului de entitate de mai sus se descrie astfel:

            Plati (Data, Nr_mat, Valoare, Restanta)

            Cheie primara: Data, Nr_mat

            Cheie straina:   Nr_mat   se refera la    Familii(Nr_mat)

            Mentionam ca în cazul acesta cheia straina este si în compunerea chei primare. Deci înainte de introducerea cheii straine, cheia primara nu identifica unic o entitate. La terminarea acestui pas, putem identifica cheile prinare pentru toate tipurile de entitati din modelul logic.

            Tipurile de relatii binare de tipul unu-la-unu (1:1)

            Pentru fiecare tip de relatie binara de tipul 1:1 între doua tipuri de entitate E1 si E2 gasim o copie a cheii primare a tipului de entitate E1 în compunerea tipului de entitate E2, sub denumirea de cheie straina. Identificarea tipului de entitate "parinte" si a tipului de entitate "fiu" depinde de participarea entitatilor la relatie. Tipul de entitate care participa partial la relatie este desemnat ca fiind "parinte" iar cel cu participare totala "fiu". Daca ambele tipuri de entitate participa partial sau total la relatie, atunci tipurile de entitati se pot evidentia ca fiind "parinte" sau "fiu" arbitrar. În cazul în care participarea este totala, putem încerca sa combinam cele doua tipuri de entitati într-una singura. Aceasta compunere poate sa fie posibila în cazul în care nici unul dintre cele doua tipuri de entitati nu mai ia parte la alta relatie.

            Tipurile de relatii binare de tipul unu-la-multe 1:M

            Pentru toate relatiile 1:M între doua entitati E1 si E2 în modelul logic de date, vom avea copia cheii primare a entitatii E1 în compunerea entitatii E2. Totdeauna entitatea de partea unu a relatiei este considerata entitate "parinte", iar cealalta entitate "fiu".

            Atributele cu mai multe valori

            Pentru ficarea atribut A care permite mai multe valori din entitatea E1 în modelul logic de date, cream o noua relatie care va contine atributul A împreuna cu cheia primara a entitatii E1 pe post de cheie straina. Cheia primara a noii relatii va fi atributul A, sau daca este necesar, compunerea ei cu cheia primara al lui E1.

            Documentarea relatiilor si a atributelor din cheile straine

            Actualizam dictionarul de date, întroducând fiacare atribut nou introdus în compunerea unei chei la acest pas.

            Pasul 2.3. Validarea, utilizând normalizarea

            Obiectivul: Validarea modelului logic, utilizând tehnica normalizarii.

            Examinam procesul de normalizare dupa cum am descris în capitolul 5 Prin normalizare trebuie sa demonstram ca modelul creat este consistent, contine redundanta minimala si are stabilitate maxima.

            Normalizarea este procesul prin care se decide daca atributele pot sau nu sa ramâna înpreuna. Conceptul de baza a teoriei relatiilor este ca atributele sunt grupate împreuna pentru ca exista o relatie logica între ele. Câteodata baza de date nu este cea mai eficienta. Acesta se argumenteaza prin urmatoarele:

Proiectarea normalizata organizeaza datele în functie de dependentele functionale. Deci acest proces este situat undeva între proiectarea conceptuala si cea fizica.

Proiectul logic nu este un proiect final. El ajuta priectantul sa înteleaga natura datelor în întreprindere. Proiectul fizic poate fi diferit. Exista posibilitatea ca unele tipuri de entitati sa se denormalizeze. Totusi normalizarea nu este un timp pierdut.

Proiectul normalizat este robust si independent de anomaliile de actualizare prezentate în capitolul 5.

Calculatoarele moderne au mult mai multa putere de calcul, ca cele de acum câtiva ani. Din aceasta cauza, câteodata este mai convenabila implementarea unei baze de date cu putina redundanta, decât suportarea cheltuielilor pentru procedurile aditionale.

Normalizarea produce o baza de date care va fi usor extensibila în viitor.

            Pasul 2.2. Validarea modelului prin tranzactii

            Obiectivul: Verificarea ca modelul de date suporte toate tranzactiile cerute de utilizator.

            În acest pas se valideaza baza de date prin verificarea tranzactiilor ce se cer de catre utilizator. Luând în considerare tipurile de entitati, relatiile, cheile primare si straine, încercam sa rezolvam manual cerintele utilizatorilor. Daca reusim sa rezolvam fiecare tranzactie ceruta, atuci înseamna ca modelul creat este valid. Daca nu putem rezolva o tranzactie, atunci este foarte posibil sa fi omis un atribut, o relatie, sau o entitate din modelul de date.

            Trebuie sa examinam daca baza de date suporta tranzactiile cerute. Mai întâir fi prin rezolvarea de tranzactii. De exemplu sa luam relatia dintre Furnizori si Cheltuieli exemplificata în figura 6.3.

Figura 6.3. Exemplu de relatie pentru validarea prin tranzactii.

 
 

            Inserarea de detalii despre un nou furnizor.

            Cheia primara al acestei entitati este Nr_furnizor. Deci prima data verific daca numarul introdus nu exista deja; dupa care, în caz ca nu exista acest cod, inserez detaliile despre furnizor. Daca exista deja codul, nu admit inserarea. Pot verifica si existenta codului fiscal, care pentru aceasta entitate este cheie alternanta.

            stergerea detaliilor despre un furnizor

            Se cauta codul furnizorului de sters. Daca exista se sterge furnizorul, actualizându-se si cheia straina în entitatea Cheltuieli. Daca nu exista codul cerut, atunci apare un mesaj de eroare si nu este sters nici un furnizor.

            A doua modalitate de verificare trebuie folosita în cazul în care avem entitati care nu iau parte direct la nici o tranzactie. Pentru verificarea acestor entitati, vom verifica niste interogari pregatie special.

            Pasul 2.5. Desenarea diagramei ER.

            Obiectivul: Desenarea diagramei Entity-Relationship, care este reprezentarea logica a vederilor utilizatorilor aspra întreprinderii.

            Pasul 2.6. Identificarea regulilor de integritate.

            Obiectivul: Identificarea regulilor de integritate pentru vederile utilizatorilor asupra întreprinderii.

            Regulile de integritate sunt importante pentru a proteja baza de date împotriva posibilelor inconsistente. Daca este necesar, putem produce un proiect fizic de baza de date, pentru a putea vedea mai usor ce reguli sunt necesare.

            Vom considera cinci tipuri de reguli de integritate:

necesitatea datelor,

reguli asupra domeniului atributelor,

integritatea entitatilor,

integritatea referintelor,

regulile întreprinderii.

            Necesitatea datelor

            Exista atribute care nu pot contine valoarea nula, ci trebuie sa aiba totdeauna o valoare. De exemplu fiecare cheltuiala înregistrata trebuie sa aiba asociat un furnizor al serviciilor sau al obiectelor ce se platesc prin acea cheltuiala.

            Aceste reguli deja le-am identificat, când am documentat atributele în pasul 1.3.

            Reguli asupra domeniului atributelor.

            Unele atribute au un domeniu de definitie bine definit. Aceste domenii trebuie respectate. Domeniile de definitie au fost deja identificate când am documentat domeniile atributelor în pasul 1.2.

            Integritatea entitatilor.

            Cheia primara a entitatilor nu poate lua valori nule. De exemplu fiecare furnizor trebuie sa aiba un cod diferit de zero.

            Aceste reguli au fost deja identificate, când am documentat cheile primare în pasul 1.5.

                        Integritatea referintelor

            Cheia straina din tipul de entitate "fiu" face ligatura cu o entitate din tipul de entitate "parinte". Deci, daca cheia straina contine o valoare, ea trebuie neaparat sa se regaseasca si în tipul de entitate "parinte". De exemplu tipul de entitate Cheltuieli contine cheia straina Cod_furnizor, care se refera la Furnizori(Cod_furnizor). Daca aceasta cheie nu este nula, atunci trebuie sa gasim un furnizor care sa aiba acel cod.

            Prima întrebare pe care trebuie sa ne-o ponem este: Poate fii cheia straina nula? În cazul exemplului nostru asta ar însemna ca exista cheltuieli care nu se pratesc nimanui. Aceste cazuri nu sunt admise de lege, deci nu putem avea valoare nula în cheia straina din tipul de entitate Cheltuieli.

            În general daca pariciparea tipului de entitate "fiu" este totala, atunci nu putem avea valoare nula în cheia straina. În caz contrar putem avea valoare nula.

            Pentru a demonstra diferitele cazuri la definirea acestor reguli, folosim relatia de mai sus dintre Furnizori si Cheltuieli, care este de tipul 1:M. Consideram urmatoarele cazuri:

            Cazul 1: Inserarea unei entitati în tipul de entitate "fiu" (Cheltuieli): Pentru a verifica integritatea referintei, verificam daca atributele din componenta cheii straine (Cod_furnizor) sunt vide, sau sa existe entitate în tipul de entitate "parinte" care sa aiba valoare cheii primare egala cu valoare cheii straine.

            Cazul 2: stergerea unei entitati din tipul de entitate "fiu" (Cheltuieli): stergerea unei entitati din tipul de entitate "fiu" nu creeaza probleme la integritatea referintelor.

            Cazul 3: Actualizarea cheii straine în tipul de entitate "fiu" (Cheltuieli): Acest caz este similar cazului 1.

            Cazul 4: Stergerea unei entitati din tipul de entitate "parinte" (Furnizori): Daca se sterge o entitate din tipul de entitate "parinte", integritatea referintelor se strica în cazul în care exista entitati în tipul de entitate "fiu", care se refera la entitatea stearsa. Exista strategii severe de a rezolva integritatea referintelor:

FĂRĂ ACŢIUNE        Neacceptarea stergerii unei entitati din tipul de entitate parinte, daca acesta este referit de o entitate din tipul de entitate fiu. În cazul nostru, nu se accepta stergerea furnizorului, daca el are o factura de încasat.

CASCADĂ                 Daca o entitate din tipul de entitate parinte este stearsa, se sterg automat toate entitatiile din tipurile de entitati fiu. Daca tipurile de entitati fiu au si ei la rândul lor alte tipuri de entitati fiu, se va efectua stergerea în cascada în toate tipurile de entitati fiu, pâna la ultimul nivel. Cu alte cuvinte, daca se sterge un furnizor, atunci automat se sterge fiacare factura pe carea are de încasat acest furnizor.

SETARE LA NUL       Daca o entitate din tipul de entitate parinte se sterge, atunci se vor seta la valoare nula toate cheile straine ai tipurilor de entitati fiu în cascada pâna la ultimul nivel. În exemplul nortru, daca se sterge un furnizor, atunci se vor seta la valoare nula toate referintele la acest furnizor în tipul de entitate Cheltuieli. Acesta înseamna ca nu vom stii ca anumite cheltuieli la ce furnizor trebuie platite.

SETARE IMPLICITĂ Este analog cazului de setare la nul, cu diferenta ca aici se seteaza cheia straina la o valoare implicita în loc de valoare nula. În exemplul nostru putem seta cheia straina din Cheltuieli la o valoare a cheii primare din Furnizori, care sa contina un furnizor predefinit - de exemplu cu numele de "Furnizor sters".

FĂRĂ MODIFICARE În cazul stergerii unei entitati din tipul de antitate parinte, nu se actualizeaza deloc cheile straine din tipurile de entitati fiu.

            Cazul 6: Modificarea cheii primare în tipul de entitate parinte (Furnizori): Daca se modifica cheia primara din tipul de entitate parinte, integritatea referintelor se strica. Pentru mentinerea integritatii, se pot folosii toate cazurile descrise mai sus, dar cel mai indicat este folosirea cazului CASCADĂ.

            Regulile întreprinderii.

            În final evidentiem acele reguli care sunt date de realitatea ce se va modela în baza de date.

            Documentarea tuturor regulilor de integritate.

            Trecem toate regulile de integritate în dictionarul de date.

            Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.

            Obiectivul: Convingerea ca modelul creat reprezinta în totalitate realitatea care trebuie modelata în baza de date.

            La acest pas modelul local logic este clomplet si este bine documentat. Înainte de a trece la pasul 3, trebuie verificat modelul, sa fie conform cu realitatea. În cazul în care se gasesc diferente, ne vom reîntoarce la pasii anteriori si modificam cele necasare.

            Pasul 3. Crearea si validarea modelului global logic de date.

            Obiectivul: Combinarea modelelor locale logice într-un model logic global care sa reprezinte întreprinderea care este modelata.

            A treia activitate majora în proiectarea bazei de date logice este crearea modelului logic global, prin compunerea tuturor modelelor locale. Dupa combinarea modelelor locale, trebuie validat modelul global prin tehnica de normalizare si dupa aceea, prin tehnica tranzactiilor. Acest proces utilizeaza aceleasi tehnici pe care le-am descris la pasii 2.3. si 2.2.

            Acest proces este foarte important în proiectarea bazei de date, pentru ca el demonstreaza ca reprezentarea întreprinderii este independenta de orice utilizator, functie sau aplicatie. Activitatile din acest pas sunt:

Pasul 3.1. Compunerea medelelor logice locale într-un model logic global.

Pasul 3.2. Validarea modelului logic global.

Pasul 3.3. Verificarea posibilitatii de a completa baza de date în viitor.

Pasul 3.2. Desenarea diagramei ER finale.

Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.

            Pasul 3.1. Compunerea modelelor logice locale într-un model logic global.

            Obiectivul: Compunerea tuturor modelelor logice locale într-un model logic global al întreprinderii.

            În cazul unui sistem mic, cu putine vederi ai utilizatorilor, este relativ usor de a compune modelele logice locale. În cazul unui sistem mai mare însa, trebuie sa urmam un proces sistematic de realizare a modelului global. Pasii acestui proces sunt urmatoarele:

Verificarea numelor entitatilor si a cheilor lor primare.

Verificarea numelor relatiilor.

Compunerea entitatilor de pe view-urile locale.

Includerea (fara compunere) a entitatilor care apar pe doar una dintre view-uri.

Compunerea relatiilor de pe view-urile locale.

Includerea (fara compunere) a relatilor care apar pe doar una dintre view-uri.

Cautarea entitatilor si a relatilor care lipsesc (daca exista).

Cautarea cheilor straine.

Cautarea regulilor de integritate.

Desenarea modelului logic global.

Actualizarea documentatiei.

            Cel mai usor de compus mai multe modele locale este compunerea succesiva a doua câte doua dintre modele.

Verificarea numelor entitatilor si a cheilor lor primare.

            Aceasta verificare se face folosind si dictionarul creat în decursul pasilor de dinainte. Probleme apar doar atunci când:

Doua entitati au acelasi nume, dar sunt de fapt diferiti.

Doua entitati sunt aceleasi, dar nu au aceleasi nume.

            Probabil va fi necesara analizarea atributelor antitatilor, prntru a rezola aceasta problema. În particular, putem utiliza cheia primara si numele entitatii, pentru a identifica entitatile echivalente.

Verificarea numelor relatiilor.

            Aceasta activitate este asemanatoare celei descrise la entitati.

Compunerea entitatilor de pe view-urile locale.

            Examinam numele si atributele entitatilor ca vor fi compuse. Activitatile care se includ în acest pas sunt:

Compunerea entitatilor cau au aceleasi nume si aceleasi chei primare.

Compunerea entitatilor care au aceleasi nume, dar cu chei primare diferite.

Compunerea entitatilor care au nume diferite, cu chei primare egale sau diferite.

            Compunerea entitatilor care au aceleasi nume si aceleasi chei primare. În general entitatile cu aceleasi chei primare reprezinta "lumea reala", si deci pot fi compuse. Atributele care apar în entitatile de pe ambele view-uri, vor fi trecute doar o singura data. Daca într-un view apare un atribut compus, iar într-un alt view acelasi atribut dar descompus în atribute simple, atunci vom întreba, daca se poate, utilizatorii pentru a decide asupra formei de utilizare a atributului.

            Compunerea entitatilor care au aceleasi nume, dar au chei primare diferite. În astfel de situatii, cautam doua entitati care au aceleasi nume si nu au aceleasi chei primare, dar au aceleasi chei candidat. Cele doua entitati pot fi compuse, urmând ca dupa compunere sa alegem o cheie primara, restul ramanând chei alternante.

            Compunerea entitatilor care nu au nume comune si nu au aceleasi chei primare. Aceste entitati se pot depista prin analiza atributelor celor doua entitati.

Includerea (fara compunere) a entitatilor care apar doar într-un view.

            Pasul anterior identifica toate entitatile comune. Celelalte entitati, se vor include în modelul logic global exact asa cum apar în view-ul respectiv.

Compunerea relatiilor de pe modelele locale.

            În acest pas analizam similitudinile dintre relatii de pe diferite modele locale. În timpul compunerii relatiilor trebuie rezolvate si conflictele dintre relatii, ca si regulile de cardinalitate si participare. Putem compune relatii care au aceleasi nume si acelasi scop, sau acelasi scop, dar nume diferite.

Includerea (fara compunere) a relatiilor care apar doar pe un view.

            Relatile care au ramas neincluse în modelul global dupa pasul anterior, se includ în modelul global fara modificare.

Cautarea entitatilor si relatilor care lipsesc.

            Este unul din cei mai grei pasi din crearea modelului global. Trebuie cautate acele entitati si relatii, care s-au omis la pasii anteriori si n-au ajuns în modelul global.

Cautarea cheilor straine.

            În decursul pasilor anterioare, s-au modificat entitati, chei primare si chei straine. În acest pas verificam daca cheile straine sunt corecte în fiecare entitate fiu si efectuam toate modificarile necesare.

Cautarea regulilor de integritate

            Verificam daca regulile de integritate a modelului global nu sunt în conflict cu regulile definite la modelele locale. Fiecare problema de acest gen se rezolva cu ajutorul utilizatorului sistemului.

Desenarea diagramei ER.

            Acum desenam diagrama ER pentru modelul global de date.

Actualizarea documentatiei.

            Actualizam documentatia, ca sa reflecte toate modificarile aduse în acest pas modelului.

Pasul 3.2. Validarea modelului logic global.

            Obiectivul: Validarea modelului global logic de date, folosind normalizarea, dupa care folosind tranzactile cerute.

            Acest pas este schivalent cu pasii 2.3. si 2.4., unde am validat modelul local de date.

            Pasul 3.3. Verificarea posibilitatilor de extindere a bazei de date în viitor.

            Obiectivul: Determinarea ca daca modelul se acomodeaza usor la modificari oricât de mari ce pot intervenii în viitor.

            Este important ca modelul creat sa fie expansibil în viitor. Daca modelul nu are aceasta calitate, viata lui poate fi scurta si pentru o mai mare modificare va trebui refacuta de la început.

            Pasul 3.4. Desenarea diagramei Entitz-Relationship finale.

            Obiectivul: Desenarea unei diagrame ER, care sa reprezinte modelul global de date al întreprinderii.

            Pasul 3.5. Verificarea modelului global cu ajutorul utilizatorului.

            Obiectivul: Verificarea ca modelul global reprezinta în totalitate realitatea.

            În acest moment modelul global este complet si documentat. Împreuna cu utilizatorul sistemului se verifica acest model si se aduc eventualele corecturi prin întoarcerea la pasii în cauza.

6.2.Proiectarea logica a bazei de date - Exemplu

            În acest capitol vom învata despre:

Cum sa folosim metodologia de proiectare a bazelor de date relationele, descrisa în 6.1.

Cum sa folosim aceasta metodologie pentru proiectarea bazei de date a sistemului 'Asociatie de locatari'.

            În acest capitol vom explica detaliat, cum putem folosi metodologia prezentata în 6.1. Vom exemplifica folosirea metodologiei cu proiectarea bazei de date pentru sistemul informatic al asociatiei de locatari.

            În decursul acestui capitol, vom folosii expresiile "entitate" si "relatie" în locul expresiilor "tip de entitate" respectiv "tip de relatie". În cazul în care pot aparea ambiguitati, se va folosii "tip de entitate" respectiv "tip de realtie".

6.2.1. Cerintele utilizatorilor.

            Analiza si colectarea datelor îl vom începe la o asociatie de locatari. Aici trebuie sa cerem informatiile necesare pentru realizarea sistemului. Trebuie sa colectam informatiile despre lucrul de zi cu zi a sefului asociatiei de locatari. Vom mai avea nevoie de toate rapoartele pe care ei le întocmesc. Toate informatiile despre sistemul de evidenta a asociatiei de locatari se pot împarti în mai multe view-uri. Aceste view-uri sunt:

Evidenta locatarilor si a apartamentelor din asociatie,

Evidenta cheltuielilor locatarilor,

Evidenta personalului asociatiei,

Evidenta obiectelor de inventar si a mijloacelor fixe,

Plata datoriilor asociatiei catre furnizori".

6.2.1.1. Cerintele la baza de date.

            Evidenta locatarilor si a apartamentelor din asociatie:

În baza de date vor fi memorate toti locatarii asociatiei de locatari. Informatiile necesare despre locatari sunt: adresa (numar bloc, scara, etajul si apartamentul) si numele. Ei vor fi unic determinati de un numar matricol unic pe toata asociatia de locatari.

Dintre locatari trebuie sa evidentiem pentru fiecare familie câte un reprezentant. Pentru fiecare familie trebuie sa avem la dispozitie informatiile: numarul membrilor de familie, numarul persoanelor prezente în locuinta în luna curenta si  numarul de chei de la usa principala.

Tot dintre locatari se alege câte un sef de scara pentru fiecare scara din asociatie. sef de scara trebuie sa fie exact unul pe fiecare scara si trebuie sa locuiasca în scara pentru care s-a ales. Pentru seful de scara mai avem în plus informatia: data intrarii în functie.

La evidenta cladirilor din asociatia de locatari, avem de memorat scarile care apartin asociatiei. Scarile sunt identificate unic prin numarul blocului si litera scarii. Mai trebuie sa stim despre fiecare scara daca are lift.

Pe fiecare scara avem mai multe apartamente. Despre apartamente trebuie sa memoram informatiile urmatoare: nr. apartamentului, suprafata, numarul de cutii postale si numarul de prize tv.

            Evidenta cheltuielilor locatarilor

Fiecare cheltuiala se înregistreaza în momentul primilii facturii de la furnizor. Cheltuielile sunt identificate unic printr-un numar de ordine care este continuu pe un an. Pentru fiecare cheltuiala se înregistreaza informatiile: codul cheltuielii, codul furnizorului, numarul si data facturii, valoarea facturii.

Cheltuielile se pot referii la o singura scara sau la mai multe scari, sau se pot referi la o singura familie sau mai multe familii.

Pentru fiecare familie se înregistreaza lunar valoarea ce trebuie platita asociatiei. Daca este cazul, se înregistreaza si restantele.

Când o familie îsi achita datoria la asociatie, se emite o chitanta, care trebuie sa contina informatii despre valoarea platita, data platii si numele persoanei care a facut plata. Chitanta se identifica unic prin numarul sau.

Pentru a efectua mai usor înregistrarea cheltuielilor, memoram si datele despre furnizori. Aceste date sunt: denumirea, codul fiscal, contul bancar si banca, adresa (strada, numarul, bl., sc., ap., localitatea si judetul). Furnizorii se pot identifica unic printr-un cod intern - cod furnizor.

Pe lânga cheltuielile catre furnizori exista si cheltuieli, care trebuiesc platite de locatari, dar care ramân la asociatie. Astfel de cheltuiala este fondul de rulment, fondul de reparatii, sau daca este cazul, si alte fonduri. Aceste cheltuieli se vor înregistra în acelasi mod ca si celelalte, cu diferenta ca aici se va introduce un "furnizor" special pregatit.

Fiecare familie trebuie sa aiba platita o suma la asociatia de locatari pentru fondul de rulment. În cazuri speciale se aduna bani si pentru fondul de reparatii, sau alte fonduri.

            Evidenta personalului asociatiei.

Personalul asociatiei se va memora în baza de date, identificarea facându-se dupa un numar matricol unic. Mai folosim informatiile: numele, data nasterii, meseria, data angajarii si scarile din asociatie unde lucreaza.

Un angajat poate sa lucreze în mai multe scari si pe o scara pot sa lucreze mai multi angajati.

            Evidenta mijloacelor fixe si a obiectelor de inventar.

Mijloacele fixe si obiactele de inventar se vor identifica unic, cu ajutorul unui cod numit numar de inventar. Pentru aceste obiecte mai retinem urmatoarele informatii: numele, valoarea si locul unde este amplasat.

            Plata datoriilor asociatiei catre furnizori.

O factura sosita de la un furnizor se poate achita prin casa, sau prin ordin de plata. Pentru aceste achitari retinem informatiile: valoarea achitata, data achitarii  si numarul urdinului de plata sau a chitantei.

6.2.1.2. Tranzactiile cerute.

            Evidenta locatarilor si a apartamentelor din asociatie:

Lista cu locatarii de pe o scara,

Lista cu familiile de pe o scara,

Lista cu sefii de scara,

Lista cu proprietatile apartamentelor ocupate pe o scara.

            Evidenta cheltuielilor locatarilor

Lista cu cheltuielile fiecarei familii pe scari,

Lista cu toate cheltuielile asociatiei de locatari.

Chitanta care se emite la fiecare plata.

            Evidenta personalului asociatiei.

Lista cu personalul asociatiei.

            Evidenta mijloacelor fixe si a obiectelor de inventar.

Lista cu mijloacele fixe si valoarea lor, din asociatia de loacatari,

Lista cu obiectele de inventar ai asociatiei de locatari.

            Plata datoriilor asociatiei catre furnizori.

Lista cu facturile scadente primite de la furnizori,

Situatia platilor facturilor de la furnizori, înglobând facturile dintr-o perioada data, împreuna cu modul lor de plata.

            6.3. Utilizarea metodologiei de proiectare a bazelor de date relationale.

            Pasul 1. Crearea modelelor conceptuale locale, bazate pe view-urile utilizatorilor:

            Înainte sa ne apucam de crearea modelului conceptual local, sa ne reamintim din ce se compune acest model:

tipuri de entitati,

tipuri de relatii,

atribute,

domeniile atributelor,

chei candidat,

chei primare.

            În acest capitol vom exemplifica metodologia de proiectare pe doua vederi ai sistemului informatic:

Evidenta locatarilor si a apartamentelor din asociatie,

Evidenta cheltuielilor locatarilor.

            Pasul 1.1. Identificarea tipurilor de entitati.

            Începem sa identificam tipurile de entitati din toate vederile utilizatorilor. Vom descrie separat identificarea acestor entitati pentru cele doua vederi.

            În cazul evidentei locatarilor si al apartamentelor, tipurile de entitati sunt:

                        Locatari                                    Scari

                        sef de scara                             Apartamente

                        Familii

            În cazul evidentei platilor tipurile de entitati sunt:

                        Cheltuieli                                  Furnizori

                        Plati                                          Chitante

                        Familii                          Scari

            Documentarea tipurilor de entitati

            În documentarea tipurilor de entitati includem o descriere amanuntita a fiecarei entotati, împreuna cu aliasurile lor. Aceste informatii sunt prezentate în anexa 6.6.2.1.

            Pasul 1.2. Identificarea tipurilor de relatii.

            În continuare identificam tipurile de relatii. Tipurile de relatii se reprezinta prin verbe ale relatiilor. Tipurile de relatii din cele doua view-uri sunt prezentate în tabelele de mai jos:

Tipuri de relatii din view-ul "Locatari":

Tip de entitate

Tip de relatie

Tip de entitate

Scari

sunt locuite de

Locatari

sunt locuite de

Familii

sunt conduse de

sef de scara

se compun din

Apartamente

Tipuri de relatii din view-ul "Cheltuieli":

Tip de entitate

Tip de relatie

Tip de entitate

Furnizorii

provoaca

Cheltuieli

Celtuieli

sunt platite de

Familii

sunt platite de

Scari

Familii

trebuie sa plateasca

Plati

primesc

Chitante

            Daca la acest pas apar ambiguitati, ele trebuie neaparat clarificate cu utilizatorii.

            Determinarea cardinalitatii si a participarii pentru tipurile de relatii.

            În contunuare vom determina cardinalul si participarea relatiilor prezentate în tabelele de mai sus. Cardinalul poate sa fie unul dentre urmatoarele: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Participarea poate sa fie partiala sau totala.

            Informatiile pe baza carora trebuie sa determinam aceste caracteristici ai tipurilor de relatii, sunt prezentate în capitorul XX. În cazul în care apar ambiguitati, ele trebuie clarificate cu ajutorul utilizatorului.

            Sa luam de exemplu relatia dintre Scari si Locatari. Pentru a fi foarte siguri de cardinalul relatiei, vom pune urmatoarea întrebare:

            Întrebare: Pot locui pe o scara mai multi locatari?

            Raspuns:  Da.

            Deci relatia Scarile sunt locuite de Locatari are cardinalul 1:M. În  continuare va trebui sa aflam si cardinalul relatiei inverse, adica a relatiei Locatarii locuiesc în apartementele de pe Scari.

            Întrebare: Un locatar poate locui în mai multe apartamente de pe scari diferite?

            Raspuns : Nu.

            La aceasta întrebare avem nevoie de o explicatie: Daca o persoana are doua locuinte în aceasi asociatie de locatari, atunci el va apare în entitatea locatari de doua ori, cu numar matricol diferit. Deci un numar matricol poate sa locuiasca doar într-un singur apartament.

            Deci cardinalul acestei relatii este de 1:1, de unde rezulta ca relatia initiala are cardinalul 1:M.

            Pentru a afla participarea entitatilor la relatie, punem urmatoarele întrebari:

            Întrebare: Fiecare scara este locuita de cel putin un locatar?

            Raspuns : Nu.

            Întrebare: Fiecare locatar locuieste într-unul din aceste scari?

            Raspuns: Da.

            Deci tipul de entitate scari partcipa partial, iar tipul de entitate Locatari participa total la relatie.

            Fie relatia Cheltuieli sunt platite de Scari, din view-ul "Cheltuieli". Sa determinam cardinalul si participarea ei:

            Întrebare: Exista cheltuiala care se refera la mai multe scari?

            Raspuns : Da.

            Întrebare: Scarile pot avea mai multe cheltuieli?

            Raspuns : Da.

            Întrebare: Fiecare cheltuiala trebuie sa fie asociata unei scari?

            Raspuns : Nu, pentru ca poate fi asociata doar unor familii.

            Întrebare: Fiecare scara trebuie sa aiba cheltuieli?

            Raspuns : Nu, pentru ca pot fi scari fara locatari.

            Dupa aceste întrebari si raspunsuri, am ajuns la concluzia ca relatia are cardinalul N:M (ambele relatii - si cea directa si cea inversa - au cardinalul 1:M), iar participarea partiala de ambele parti.

            Cardinalul si partciparea relatiilor de mai sus sunt prezentate în anexa 6.3.3.

            Utilizarea modelarii ER.

            Pentru o întelegere mai usoara a relatiilor dintre entitati, se poate folosi diagrama ER. Diagramele ER ale celor doua view-uri ale caror relatii au fost prezentate mai sus, se pot vedea în figura 6.3.1. (a) si (b).

            Mentionam, ca verbele care reprezinta relatiile de cardinal 1:M se pun în directia unu-la-multe. În cazul în care relatia a fost altfel evidentiata, ea va fi redenumita.

            Documentarea tipurilor de relatii.

            Documantarea view-urilor care apar în figura 6.3.1. este realizata în anexa 6.2.3.

 

Figura 6.3.1.(a)  Diagrama ER. a view-ului "Locatari".

 


Figura 6.3.1.(b). Diagrama ER a view-ului "Cheltuieli"

            Pasul 1.3. Identificarea si asocierea atributelor la tipurile de reletii si tipurile de entitati.

            În acest pas identificam atributele ce se asociaza tipurilor de entitati sau tipurilor de relatii. Atributele sunt informatii care caracterizeaza entitatile, resoective relatiile. Aceste atribute le putem gasi în descrierea acordata de utilizatori. În cazul nostru, atributele identificate si asociate entitatilor se pot regasi în tabela 6.3.2.a. si 6.3.2.b.

Tabela 6.3.2.a. Atributele tipurilor de entitati din view-ul "Locatari":

Tip de entitate

Atribute

Locatari

Nr_Mat

Adresa (Nr_bloc, Scara, Etaj, Apartament)

Nume

Familii

Nr_Mat

Adresa (Nr_bloc, Scara, Etaj, Apartament)

Nume

Nr_pers

Nr_pers_prez

Nr_chei

Sef_Scara

Nr_Mat

Adresa (Nr_bloc, Scara, Etaj, Apartament)

Nume

Data_intrare_func

Scari

Adresa (Nr_bloc, Scara)

Lift

Apartamente

Apartament

Suprafata

Cutii_postale

Nr_prize_tv

Tabela 6.3.2.b. Atributele tipurilor de entitati din view-ul "Cheltuieli":

Tip de entitate

Atribute

Familii

Nr_mat

Fond_rulment

Fond_reparatii

Alte_fonduri

Plati

Data

Valoare

Restanta

Chitante

Nr_Chit

Valoare

Data

Cheltuieli

Nr_crt

Cod_cheltuiala

Nr_factura

Data_factura

Valoare

Furnizori

Cod_furnizor

Denumire

Cod_fiscal

Cont

Banca

Adresa (Strada, Nr., Bl., Sc., Ap., Localitate, Jud)

            Documentarea atributelor:

            Pentru documentatie se descrie fiecare atribut, se mentioneaza tipul de date folosit precum si lungimea câmpului, reguli, valoarea implicita, toate aliasurile lui, daca atributul este sau nu compus, daca este derivat sau nu, daca admite mai multe valori si daca admite valoarea nula.

O parte a acestei documentatii este exemplificata în anexa 6.3.2.

 Pasul 1.2. Determinarea domeniilor atributelor:

În acest pas determinam domeniile atributelor. Domeniul unui atribut este nultimea acelor valori, pe care le poate lua în lucrul de zi cu zi.

Documentarea atributelor.

Câteva din domeniile exemplului nostru sunt aratate în anexa 6.3.2.

Pasul 1.5. Determinarea atributelor care apartin cheilor candidat si primare:

Acum vom examina tabelele 6.2.2.a. si 6.2.2.b., si vom cauta cheile candidat pentru entitatile în cauza. Dintre aceste chei candidat vom selecta cheia primara, dupa criterii deja descrise în 6.1.

Cheile primare si alternante pentru entitatile din view-ul "Locatari" si view-ul "Cheltuieli", sunt afisate în anexa 6.3.2. Mentionam, ca în acest pas nu asociem chei primare entitatilor slabe, acesasta operatie fiind rezolvata în pasul 2.2.

Documentarea cheilor primare si alternante.

Documentam atributele care compun cheile primare si cheile alternante. Un exemplu de documentare gasiti în anexa 6.3.2.

Pasul 1.6. Specializarea/generalizarea tipurilor de entitati (pas optional).

În acest pas putem dezvolta modelul ER, utilizând procesul de specializare/generalizare  asupra entitatilor identifcate în pasul 1.1. Daca vrem sa folosim procesul de specializare, vom cauta diferentele dintre entitati, iar în cazul procesului de generalizare, asemanarile dintre ele.

De exemplu, în view-ul "Locatari", entitatile Locatari, Familii si sef_scara au atributele Nr_mat, Adresa si Nume în comun. Entitatea Familii mai are în plus atributele Nr_pers, Nr_pers_prez si Nr_chei iar entitatea sef_scara are în plus doar atributul Data_intreare_func. Entitatea Locatari are asociate doar atributele comune cu cele doua entitati. Deci putem generaliza entitatile Familii si sef_scara, punând pe post de superclasa entitatea Locatari, iar celelalte doua fiind subclase. Relatia superclasa-subclasa dintre entitatea Locatari si Familii respectiv sef_scara este o relatie partiala si nondisjuncta, pentru ca în Locatari sunt toti locatarii asociatiei, deci si acelea care nu sunt nici capi de familie si nici sefi de scara iar pe de alta parte, seful de scara poate sa fie si cap de familie. Figura 6.3.3. reprezinta diagrama celor trei entitati dupa procesul de generalizare.

Figura 6.3.3. Exemplu de reltie superclasa - subclasa

 


Pasul 1.7. Desenarea modelului ER.

Pentru o mai buna întelegere a modelului local creat, folosim diagrama ER. Aceasta diagrama si documentatia creata se refera la modelul local conceptual.

Diagramele ER ale celor doua view-uri ai exemplului nostru se pot vedea în figura 6.3.2.a., respectiv 6.3.2.b.

Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.

Înainte de a termina pasul 1, trebuie verificat modelul la care s-a ajuns. Daca se descopera erori, atunci ne întoarcem la pasurile anterioare si le remediem. Vom repeta acesti pasi pâna când modelul creat va fi în conformitate cu realitatea.

Figura 6.3.2.a. Modelul conceptual local al view-ului "Locatari"

 


Figura 6.3.2.b. Modelul conceptual local al view-ului "Cheltuieli".

Pasul 2.2. Crearea si validarea modelului local de date.

În acest pas revizuim modelul creat si eliminam acele structuri care se pot implementa greu în sistemul de gestiune a bazelor de date. Dupa aceea validam modelul, utilizând metoda normalizarii si a tranzactiilor.

Pasul 2.1. Proiectarea modelului local conceptual în modelul local logic.

În acest pas eliminam acele structuri din baza de date, care sunt dificil de implementat în sistemul de gestiune al bazelor de date. Pentru a rezolva aceasta problema, se vor urma urmatorii pasi:

Eliminarea relatiilor de tipul N:M.

Eliminarea relatiilor complexe.

Eliminarea relatiilor recursive.

Eliminarea relatiilor cu atribute.

Reexaminarea relatiilor de tipul 1:1.

Eliminarea relatiilor redundante.

(1)Eliminarea relatiilor de tipul N:M.

            Cum putem observa si în figura 6.2.2.b., relatiile Cheltuieli Sunt platite de Familii si Cheltuieli Sunt platite de Scari au cardinalul de N:M. Vom descompune aceste relatii în câte doua relatii de tipul unu-la-multe (1:M), numite în ambele cazuri Se calculeaza si Au cheltuieli. Aceasta modificare devina posibila prin introducerea a doi entitati noi, numite Pe_familii, respectiv Pe_scari. Aceste entitati noi vor fi entitati slabe, pentru ca vor depinde de entatile Cheltuieli, Familii si Scari. Adica cheia primara a lor va fi derivat din cheia primara a entitatilor tari.

            Modificarile se pot observa în figura 6.3.5.

Figura 6.3.5. View-ul "Cheltuieli", dupa eliminarea relatiilor N:M.

Eliminarea relatiilor complexe.

            În acest pas, eliminam toate relatiile complexe (care sunt între mai mult decât doua entitati) din modelul conceptual. Aceasta eliminare se poate rezolva prin crearea a noi entitati.

Exemplul nostru nu contine nici o relatie complexa.

Eliminarea relatiilor recursive.

            Pasul acesta este pentru eliminarea tuturor relatiilor recursive, adica acele relatii care pun în relatie o entitate cu el însasi. În exemplul nostru nu avem astfel de cazuri.

Eliminarea relatiilor cu atribute.

            Se elimina toate acele relatii, care au asociate atribute. Eliminarea se realizeaza prin adaugarea a noi entitati, care vor memora aceste atribute. Nu este cazul exemplului nostru.

Reexaminarea relatiilor de tipul 1:1.

            În foarte multe din cazuri, entitatile care sunt relationate prin relatii cu cardinalul 1:1, se pot îngloba într-o singura entitate. De aceea este indicata reexaminarea relatiilor de tipul unu-la-unu.

            Exemplul nostru nu contine relatii de acest tip.

Eliminarea relatiilor redundante.

            Pot exista cazuri în care sa avem relatii redundante. Adica sa se poata ajunge de la o entitate la alte prin mai multe drumuri diferite. În acest caz relatiile redundante trebuie eliminate, pentru ca noi trebuie sa ajungem la o baza de date minimala si foarte stabila. Nu este cazul exemplului nostru.

            Desenarea diagramei ER.

            Modelul conceptual care este reprezentat în figura 6.2.a. si b., s-a modificat în acest pas. Am eliminat din acest model, toate structurile greu de implementat într-un sistem de gestiune a bazelor de date. Diagrama modificata se va numi în continuare modelul local logic al bazei de date. Acest model este prezentat în  figura 6.3.6.a. si 6.3.6.b.

Figura 6.3.6.a. Modelul logic local al view-ului "Locatari".

 


Figura 6.3.6.b. Modelul logic local al view-ului "Cheltuieli".

            Pasul 2.2. Crearea de relatii peste modelul logic local.

            În acest pas vom crea relatiile între entitatile din modelul logic local de date, cu ajutorul mecanismului chei primare/chei straine.

            Pentru exemplificarea acestui proces, sa luam relatia Furnizori Provoaca Cheltuieli din view-ul "Cheltuieli". Vom folosi limbajul de definire a bazelor de date (DBDL), pentru descrierea fiecarei relatii.

            Pentru fiecare entitate tare a modelului, cream o relatie care include toate atributele simple ale entitatii. Structura entitatii Furnizori este:

Furnizori (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str., Bl., Sc.,

                  Ap., Loc., Jud.)

Cheie primara: Cod_furnizor

Pentru fiecare entitate slaba, descriem relatia, incluzând atributele simple ale entitatii, specificând cheia straina si entitatea la care se refera aceasta cheie straina. Structura entitatii Cheltuieli este:

            Cheltuieli (Nr_crt, Cod_furnizor, Cod_cheltuiala, Nr_factura, Data_factura,

        Valoare)

            Cheie primara: Nr_crt

Cheie straina  : Cod_furnizor

            Acest proces continua, pâna când se vor prelucra toade relatiile din baza de date.

            Documentarea relatiilor si a atributelor din cheile straine.

            Relatiile derivate pentru view-urile "Locatari" si "Cheltuieli" se pot vedea în anexa 6.3.5., la sfârsitul acestui capitol. La crearea relatiilor trebuie actualizat si dictionarul de date, cu atributele nou introduse si cu noile chei primare si alternante.

            Pasul 2.3. Validarea modelului prin normalizare.

            În acest pas validam baza de date prin normalizare. Procesul de normalizare este descris amanuntit în capitolul 4.

Forma Normala Unu (1NF), eliminarea repetitiilor din atribute.

Forma Normala Doi (2NF), eliminarea dependentelor partiale de cheia primara.

Forma Normala Trei (3NF), eliminarea dependentelor tranzitive de cheia primara.

Forma Normala Boyce-Codd (BCNF), eliminarea anomaliilor care au mai ramas.

            Trebuie sa analizam fiecare relatie care este descrisa în anexa 6.3.5. Verificam daca relatiile sunt în forma normala Boyce-Codd, iar daca gasim una care nu satisface aceasta forma normala, ne întoarcem la pasii precedenti si rezolvam problema.

            Pentru a exemplifica acest proces, sa analizam relatia Furnizori Provoaca Cheltuieli, descrisa în anexa 6.3.5. Mentionam ca notatiile de aici nu includ cheia straina.

Furnizori (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str, Nr, Bl, Sc, Ap,

       Loc, Jud)

Cheie primara: Cod_furnizor

Cheie alternanta: Cod_fiscal

Cod_furnizor ŕ Denumire, Cod_fiscal, Cont, Banca, Str, Nr, Bl, Sc, Ap, Loc, Jud

Cod_fiscal ŕ Cod_furnizor, Denumire, Cont, Banca, Str, Nr, Bl, Sc, Ap, Loc, Jud

Cheltuieli (Nr_crt, Cod_furnizor, Cod_cheltuiala, Nr_factura, Data_factura, Valoare)

Cheie primara: Nr_crt

Nr_crt ŕ Cod_furnizor, Cod_cheltuiala, Nr_factura, Data_factura, Valoare

            Pentru acest exemplu avem urmatoarele demonstratii:

Nu exista grupuri repetitive în niciunul dintre entitati. Deci relatia este în forma normala unu.

Fiecare cheie se compune dintr-un singur atribut. De aceea nu putem avea dependenta partiala de cheie. Deci relatia este în forma normala doi.

Nu exista dependente tranzitive de cheie, deci relatia este în forma normala trei.

Fiecare determinant evidentiat este cheie, deci relatia este în forma normala Boyce-Codd.

            Acest proces se continua pentru fiecare relatie care apare în anexa 6.3.5.

            Pasul 2.2. Validarea modelului prin tranzactiile cerute.

            Pentru a valida prin tranzactii un model logic de date, folosim diagrama ER. din figura 6.3.6.a. respectiv 6.3.6.b. si documentatia întocmita. Încercam sa rezolvam manual toate tranzactiile cerute de utilizator, folosind doar datele si relatiile din modelul de date creat. Daca nu putem rezolva o tranzactie, înseamna ca am omis ceva la modelarea bazei de date si deci trebuie sa ne întoarcem la pasii anteriori si sa remediem eroarea. Pe de alta parte, daca o parte a modelului de date nu este folosita la nici o tranzactie, atunci - în caz ca nu se prevede ca în viitor sa folosim aceasta parte a modelului - va trebui sa-l consideram redundant, si sa-l eliminam din modelul de date.

            Consideram doua posibilitati de verificare a modelului de date. Conform primei metode, ne asiguram ca exista în modelul de date toate entitatile si relatiile care sunt necesare pentru tranzactia aleasa. Pentru a exemplifica aceasta metoda, sa verificam urmatoarea tranzactie:

            Crearea si modificarea de înregistrari cu detaliile unei cheltuieli.

Pentru crearea înregistrarii despre o cheltuiala, dupa introducerea datelor despre cheltuiala, se vor selecta si scarile sau familiile la care este asociata. O cheltuiala nu poate fi asociata si unor familii si unor scari.

Pentru a modifica o cheltuiala, trebuie sa stim numarul cheltuielii din bazs de date. Cautam acea cheltuiala si daca exista modificam detaliile despre cheltuiala, recreînd si legaturile la familii sau scari, depinde cine trebuie sa plateasca. Daca nu exista, atunci apare un mesaj de eroare si procedura de modificare se întrerpe.

În cazul stergerii unei cheltuieli, prima data trebuie cautate înregistrarile de legatura a acelor cheltuieli cu scari sau cu familii. Daca exista - se sterg, dupa care se sterge si cheltuiala. Daca nu exista înseamna ca nu exista nici cheltuiala si se va afisa un mesaj de eroare.

            A doua modaliate de a verifica modelul de date este de a desena caile generate de relatii, pentru fiecare tranzactie în parte. Aceste cai se noteaza cu o linie având o sageata în directia tranzactiei. Tranzactiile descrise în capitolul 6.2.1.2. sunt reprezentate prin diagramele din figurile 6.3.7.a. respectiv 6.3.7.b.

Figura 6.3.7.a.

Diagrama tranzactiilor cerute la view-ul "Locatari".

 

Figura 6.3.7.b. Tranzactiile cerute pentru view-ul "Cheltuieli".

            Pasul 2.5. Desenarea diagramei ER.

            Diagrama ER din figura 6.2.7.a. si 6.2.7.b. ne ajuta sa identificam usor relatiile critice pentru tranzactii, precum si ariile din modelul creat, care nu iau parte la nici o tranzactiie. Dupa identificarea si eliminarea acestor arii, redesenam diagrama ER.

            În cazul nostru acesta diagrama nu se modifica.

            Pasul 2.6. Definirea regulilor de integritate.

            În acest pas identificam acele reguli care sa ne garanteze ca datele introduse în baza de date ramân consistente. Putem identifica cinci tipuri de reguli:

necesitatea datelor,

domeniile atributelor,

integritatea entitatilor,

integritatea relatiilor,

reguli date de intreprindere.

            Necesitatea datelor.

            Identificam acele atribute ale bazei de date, care nu admit valoarea nula. De exemplu atributele Nr_mat - din entitatea Locatari - si Adresa (Nr_bloc, Scara) - din entitatea Scari.

            Aceste reguli asupra atributelor modelului sunt descrise în pasul 1.3. si sunt documentate în anexa 6.3.2.

            Domeniile atributelor.

            Domeniile atributelor identifica valorile posibile pe care le poate loa un atribut. De exemplu atributul Etaj din entitatea locatari poate lua valori între -1 si 100. Domeniile atributelor sunt descrise în pasul 1.2. si sunt documentate în anexa 6.3.2.

            Integritatea entitatilor.

            Cheia primara a entitatilor nu poate lua valori nule. De exemplu Nr_mat, chiea primara a entitatii Locatari nu poate lua valoarea nula. Cheile primare ale fiecarei entitati au fost identificate în pasul 1.6. iar ducumentarea cheilor se gaseste în anexa 6.3.5.

            Integritatea relatiilor.

            Relatiile dintre entitati sunt reprezentate prin copierea chei primare a entitatii "parinte", în cheia straina a entitatii "fiu". Integritatea relatiilor se refera la faptul ca daca cheia straina dintr-o entitate slaba contine o valoare, atunci aceasta valoare sa exista si în entitatea tare la care este asociat prin relatie.

            De exemplu daca se înregistreaza plati unei familii în entitatea Plati, atunci acea familie trebuie sa existe si în entitatea Familii. Atributele care compum cheile primare si cheile straine sunt descrise în anexa 6.3.5.

            Este important ca sa identificam regulile relatiilor, pentru ca relatiile dintre entitati sa ramâna consistente. Mentionam ca relatiile se descriu cu limbajul specific definirii bazelor de date (DDL).

            Prima data sa consideram cazul ca cheile straine au valoare nula. În general când participarea entitatii slabe la relatie este totala, nu se permite valoare nula în cheia straina. De exemplu sa descriem relatia Scari Se compun din Apartamente. Entitatea Apartamente (slaba) participa total la relatie, deci nu admitem valori nule atributelor din cheia straina si anume Nr_bloc si Scara.

            Pe de alta parte, daca entitatea slaba participa partial la relatie, putem admite valoare nula si a cheii straine. Nu este cazul exemplului nostru, pentru ca nu avem entitate slaba cu participare partiala.

            Descriem relatia Scari Se compun din Apartamente cu limbajul DDL:

Scari (Nr_bloc, Scara, Lift)

Cheie primara: Nr_bloc, Scara

Apartamente (Nr_bloc, Scara, Apartament, Suprafata, Cutii_postale, Nr_prize_tv)

Cheie primara: Nr_bloc, Scara, Apartament

Cheie straina  : Nr_bloc, Scara          Nenula referindu-se la Scari (Nr_bloc, Scara)

            În continuare consideram cazul în care se modifica cheia primara a entitatii tari. Mentionam ca inserarea cheii primare, sau stergerea cheii straine nu dauneaza consistentei bazei de date.

            Pentru celelalte chei primare, definim modul de modificare si stergere a cheii primare. Putem alege între patru moduri: FĂRĂ ACŢIUNE, CASCADĂ, SETARE NULĂ si SETARE IMPLICITĂ. Descriem aceste modalitati de modificare/stergere pe baza relatiei Scari Se compun din Apartamente, extinzând în continuare limbajul DBDL.

Scari (Nr_bloc, Scara, Lift)

Cheie primara: Nr_bloc, Scara

Apartamente (Nr_bloc, Scara, Apartament, Suprafata, Cutii_postale, Nr_prize_tv)

Cheie primara: Nr_bloc, Scara, Apartament

Cheie straina  : Nr_bloc, Scara          Nenula, Cascada,

                                                   referindu-se la Scari (Nr_bloc, Scara)

            Aceasta operatie se executa pentru fiecare relatie descrisa în anexa 6.3.5.

            Regulile întreprinderii.

            Aceste reguli sunt definite de întreprindere si reprezinta reguli ce trebuie respectate si în viata de zi cu zi. De exemplu lista cu platile locatarilor se poate tiparii doar pe durata de o luna. Toate aceste reguli sunt prezentate în anexa 6.3.6.

            Documentarea regulilor de integritate.

            Toate cele descrise mai sus se documenteaza în modelul de date.

            Pasul 2.7. Revizuirea modelului de date cu ajutorul utilizatorului.

            În acest pas revizuim modelul creat cu ajutorul utilizatorului. Este foarte important ca modelul sa fie o reprezentare fidela a realitatii. Utilizatorul sistemului trebuie sa verifice atât diagrama cât si documentatia întocmita. Daca se gaseste o eroare, se vor reface pasii necesari pentru corectarea erorii.

            Pasul 3. Crearea si validarea modelului global de date.

            În acest pas cream modelul global prin compunerea entitatilor de pe diversele modele locale. Acest model global va trebui si ea validat prin normalizare.

            Pasul 3.1. Compunerea modelelor locale în modelul global.

            În pasul acesta compunem doua modele locale într-un model global de date. Mai multe modele globale se compun tot doua câte doua, pâna când ajungem la modelul global. Pentru început identificam similaritatile dintre modelele locale, dupa care trebuie identificate si rezolvate ariile de conflicte între modele iar în final se trec toate modelele într-un singur model. Pasii care trebuie urmati pentru compunerea modelelor sunt prezentati în continuare:

Revizuirea numelor entitatilor si cheile lor primare.

            Comparam numele si cheile primare dintre doua modele locale, comparatie ce este prezentata în tabela 6.3.8.

Tip de entitate

(view-ul Locatari)

Cheie primara

Tip de entitate

(view-ul Cheltuieli)

Cheie primara

Scari

Nr_bloc, Scara

Scari

Nr_bloc, Scara

Familii

Nr_mat

Familii

Nr_mat

Locatari

Nr_mat

sef de scara

Nr_mat

Apartamente

Nr_bloc, Scara, Ap.

Plati

Data, Nr_mat

Chitante

Nr_chit

Pe_familii

Nr_crt

Pe_scari

Nr_crt

Cheltuieli

Nr_crt

Furnizori

Cod_furnizor

Tabela 6.3.8. O comparatie între numele entitatilor si ale cheilor lor primare.

            Aceste similaritati dintre entitati arata care sunt acele modele care se suprapun. Entitatile care se suprapun se pot compune, creând o singura entitate cu toate atributele entitatii din cele doua modele.

Revizuirea numelor relatiilor.

            În continuare, comparam numele relatiilor din doua modele de date. O comparatie între modelele Locatari si Cheltuieli este prezentata în tabela 6.3.9. Relatiile sunt incluse în aceasta tabela doar o singura data în directia de la entitatea tare la cea slaba.

Tip entitate

view-ul Locatari

Tip de

 relatie

Tip entitate view-ul Locatari

Tip entitate view-ul Cheltuieli

Tip de relatie

Tip entitate view-ul Cheltuieli

Scari

Sunt locuite de

Locatari

Scari

Au cheltuieli

Pe_scari

Se compun din

Apartamente

Familii

Au cheltuieli

Pe_familii

Trebuie sa plateasca

Plati

Primesc

Chitante

Cheltuieli

Se calculeaza

Pe_familii

Se calculeaza

Pe_scari

Furnizori

Provoaca

Cheltuieli

Tabela 6.3.9. Comparatia tipurilor de relatii.

            Informatiile cuprinse în aceasta tabela arata înca o data aria modelelor care se suprapun. Este important sa intelegem ca acelasi nume se relatie în doua modele nu înseamna ca acele relatii au si acelasi rol. Trebuie sa avem mare grija la astfel de nume de relatii (se numesc omonime). Mai exista si posibilitatea ca relatii care reprezinta aceleasi concepte sa fie denumite cu nume diferite (sinonime).

            Aceste probleme la identificarea relatiilor se pot rezolva, analizând atributele (si în particular domeniile cheilor) asociate entitatilor care fac parte din relatie.

            În final trebuie sa ne asiguram ca relatiile pe care le consideram echivalente sa reprezinte aceleasi relatii si în "lumea reala".

Compunerea entitatilor din cele doua modele.

            În acest pas analizam numele si continutul entitatilor din ambele modele. În particular, utilizam cheia primara sa vedem care dintre entitati sunt echivalente, chiar daca apar sub nume diferite în cele doua modele.

            Acest pas include urmatoarele activitati:

Compunerea entitatilor cu aceleasi nume si aceleasi chei primare.

Compunerea entitatilor cu aceleasi nume dar cu chei primare diferite.

Compunerea entitatilor cu nume diferite dar cu chei primare aceleasi sau diferite.

Compunerea entitatilor cu aceleasi nume si aceleasi chei primare.

            Entitatile care sunt denumite cu aceleasi nume si aceleasi chei primare în cele doua modele reprezinta în general aceleati concepte a "lumii reale". Deci aceste entitati sunt cele mai simplu de identificat. Astfel de entitati sunt de exemplu entitatile Scari si Familii.

            Entitatile combinate vor include toate atributele celor doua entitati din cele doua modele, eliminându-se dublurile. Exemplul de compunere a entitatii Familii este prezentata în figura 6.3.10.

Compunerea entitatilor cu aceleasi nume dar cu chei primare diferite.

            În cazurile când entitatile au acelasi nume dar cu chei primare diferite, trebuie sa identificam si cheile alternante a celor doua entitati. Daca între cheile candidat ale unei entitati apare cheia primara a celeilalte, atunci compunem entitatile si alegem o cheie primara dintre cele doua chei primare.

            În exemplul nostru nu avem astfel de caz.

Compunerea entitatilor cu nume diferite dar cu chei primare aceleasi sau diferite.

            Putem întâlni cazuri în care nici numele entitatilor si nici cheile primare sa nu fie la fel, dar stim din atributele celor doua entitati ca ele reprezinta aceleasi concepte. Aceste entitati se compun ca la cazul anterior, având în plus obligatia de a alege un nume care poate sa fie una dintre cele doua nume, sau o nume noua.

Figura 6.2.10. Exemplu de compunere a doua entitati.

(view-ul Locatari)

Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)

Cheie primara: Nr_mat

Cheie straina  : Nr_mat  referindu-se la Locatari (Nr_mat)

(view-ul Cheltuieli)

Familii (Nr_mat, Fond_rulment, Fond_reparatii, Alte_fonduri)

Cheie primara: Nr_mat

Ż

(modelul global)

Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei, Fond_rulment, Fond_reparatii,

              Alte_fonduri)

Cheie primara: Nr_mat

Cheie straina  : Nr_mat  referindu-se la Locatari (Nr_mat)

Includerea (fara compunere) a entitatilor unice în cele doua modele.

            Dupa includerea tuturor entitatilor comune în modelul global, mai ramân alte entitati care nu sunt comune si care înca nu au fost incluse. Aceste entitati se vor include neschimbat în modelul global. Astfel de entitati sunt: Cheltuieli din modelul Cheltuieli, respectiv Apartamente din modelul Locatari.

Compunerea tipurilor de relatii din modelele locale.

            În acest pas analizam numele si caracteristicile relatiilor pentru a le putea compune. Este important de rezolvat conflictele datorate din participarea si cardinalul relatiilor. Numele relatiilor din cele doua modele sunt listate în tabela 6.2.9.

            Compunerea relatiilor cu aceleasi nume si aceleasi caracteristici.

            Aceste relatii sunt cel mai usor de identificat. Compunerea se rezolva prin simpla înscriere a relatiei în modelul global. Pot exista situatii când cardinalul sau participarea nu coincid în cele doua modele. Cazul acesta trebuie clarificat cu utilizatorul sistemului. Atragem atentia ca pot exista relatii cu aceleasi denumiri dar care sa aiba roluri diferite (omonime).

            Compunerea relatiilor cu nume diferite dar cu aceleasi caracteristici.

            Identificam acele relatii care apar în ambele modele dar cu denumiri diferite. Acesta identificare devine evidenta dupa ce observam ca relatia leaga aceleasi entitati. si în acest caz trebuie rezolvata problema cardinalului si a participarii.

Includerea (fara compunere) a relatiilor unice pe cele doua modele.

            Identificam toate relatiile pe care nu am inclus-o înca si le includem neschimbat în modelul global. Toate relatiile descrise în tabela 6.3.9. sunt de acest tip.

Verificarea daca s-a omis vre-o entitate sau relatie.

            Aceasta actiune de verificare este foarte importanta dar si foarte grea de rezolvat. Entitatile si relatiile compuse pot avea chiar alt nume decât cele de pe modelele locale ceea ce face greu de urmarit includerea entitatii sau a relatiei în modelul global.

Verificarea cheilor straine.

            În acest pas verificam daca toate entitatile slabe contin cheia straina asociata lor. Aceste chei trebuie sa se formeze la compunerea entitatilor, însa tot la compunere se pot si redenumi.

Verificam regulile de integritate.

            Verificam toate regulile de integritate pe modelul global de date si, daca apar probleme la verificare, ne întoarcem la pasii anteriori si le remediem.

Desenarea modelului global de date.

            Acum desenam modelul global de date. Modelul global al sistemului de evidenta a asociatiei de locatari este prezentata în figura 6.3.11.

            Numele entitatilor si a relatiilor se poate schimba la aceasta actiune.

Completarea documentatiei.

            Este foarte importanta actualizarea documentatiei, pentru a reflecta modificarile efectuate asupra bazei de date. Anexa 6.3.7. descrie relatiile modelului global prezentat în figura 6.3.11., folosind limbajul DDL.

Figura 6.3.11. Diagrama globala si finala ER.

            Pasul 3.2. Validarea modelului global de date.

            În acelasi mod cum am validat modelele locale, trebuie validat si modelul global, folosind normalizarea si validarea prin tranzactii. Acesta este foarte important pentru a verifica (si demonstra) daca nu cumva s-au introdus erori la crearea modelului global.

            Pasul 3.3. Verificarea posibilitatii de extindere în viitor.

            Este important ca modelul creat sa se poata extinde în viitor. De exemplu în sistemul de evidenta a asociatiei de locatari se va putea introduce un modul care sa rezolve salarizarea personalului asociatiei. Modelul global al aplicatiei este extensibil, extinderea putându-se realiza cu minime modificari.

            Pasul 3.4. Desenarea diagramei ER finale.

            La acest pas observam ca nu am modificat nimic de la ultima diagrama desenata, deci diagrama ER finala este diagrama din figura 6.3.11.

            Pasul 3.5. Verificarea modelului global cu ajutorul utilizatorului.

            Este important sa reexaminam modelul creat împreuna cu utilizatorul, pentru a vedea daca îndeplineste toate cerintele. Daca apar cerinte care nu sunt îndeplinite, ne întoarcem la pasii anteriori si remediem situatia.


Document Info


Accesari: 2171
Apreciat:

Comenteaza documentul:

Nu esti inregistrat
Trebuie sa fii utilizator inregistrat pentru a putea comenta


Creaza cont nou

A fost util?

Daca documentul a fost util si crezi ca merita
sa adaugi un link catre el la tine in site

Copiaza codul
in pagina web a site-ului tau.

 


Copyright © Contact (SCRIGROUP Int. 2014 )