Ghid de proiectare a bazelor de date relaionale

0. Introducere
Proiectarea bazei de date este o munc de colectiv care armonizeaz cerinele i posibilitile beneficiarului pe de o parte i proiectantului de sistem pe de alt parte. Baza de date este prima treapt spre o viziune sistemic, de ansamblu, unificatoare i generatoare de rezultate specifice corecte n acelai timp. Vechiul sistem de proiectare a fost bazat pe fiiere. Limitele acestei concepii constau n separarea datelor, duplicarea datelor, dependena programului de concepia fiierului i incompatibilitatea formatelor de fiiere folosite n diverse limbaje. Aceste limitri implic pierdere de timp i spaiu i posibilitatea de inconsisten a datelor. Sistemul de baz de date - n opoziie cu vechiul sistem - d posibilitatea de a definii datele n afara programului i asigur controlul asupra manipulrii datelor. Definiie: Baz de date: Este o colecie partajat de date legate logic, proiectat pentru a satisface necesitile unui sistem informatic. Deci datele sunt strnse ntr-o colectie unic i sunt folosite simultan de mai muli utilizatori. Redundana datelor este controlat prin normalizare, ceea ce implic o redundan minim. O astfel de baz de date are nevoie de un sistem de gestiune a bazei de date. Acesta este un sistem de programe care fac posibil definirea, ntreinerea i accesul controlat la baza de date. Un astfel de sistem trebuie s conin limbajul de definire i limbajul de manipolare a datelor. Putem aminti urmtoarele limbaje: SQL sau QBE (limbaje generale), respectiv DBASE, FOX PRO, PROGRESS, PARADOX .a.m.d. (limbaje specifice). Cum se stabilete structura bazei de date? Tocmai prin proiectarea de care ne ocupm. n opoziie cu proiectarea bazei de date bazate pe fiiere, care pornea de la una sau mai multe aplicaii ale beneficiarului, proiectarea bazei de date se rezolv naintea elaborarii aplicaiei. De aceea aceast aciune devine esenial pentru tot sistemul. Proiectantul bazei de date trebuie s identifice datele relaionale, relaiile dintre ele i restriciile asupra lor. Proiectarea const din dou faze: unul logic i unul fizic. n timpul roiectrii logice este important implicarea viitorilor utilizatori n procesul de proiectare. n proiectarea fizic se decide cum va fi realizat practic modelul logic. Avantajele i dezavantajele sistemului de baze de date:
Page: 1

Avantajele ar fi urmtoarele: controlul redundanei consistena datelor economia de spaiu pentru aceleai date controlul integritii datelor utilizarea standardelor d posibilitatea rspunsului la cereri variate i cu exprimri parial necunorcute la momentul proiectrii. productivitate crescut concuren crescut posibiliti crescute de recuperare n caz de eroare Dezavantaje: complexitate crescut costul SGBD cost crescut rezultat din cerine de hard costul trecerii de la un sistem la altul o eventual defeciune are un impact crescut, global

Page: 2

1. Modelarea ER (Entity-Relationship)
n acest capitol vom descrie urmtoarele obiective: Folosirea modelului conceptual de nivel nalt pentru proiectarea de baze de date. Conceptele modelului ER, model de nivel nalt. O tehnic grafic de reprezentare a modelului ER. Modul de identificare a problemelor ce pot aprea la crearea unui model ER. Limitele modelului ER primar i conceptele necesare pentru modelarea aplicailor complexe. Conceptele modelului EER (Enhanced Entity-Relationship), numite i specializare/generalizare. O tehnic grafic de reprezentare a specializri/generalizri n modelul EER. Utilizarea produsului ERwin produs de Logic Works, pentru proiectarea bazelor de date, ceea ce include i modelul ER. Modelul ER (Entity-Relationship) este un model conceptual de nivel nalt dezvoltat de Chen n 1976, care faciliteaz crearea de baze de date relaionale. n acest capitol, vom descrie conceptele preimare ale modelului ER, dup care vom identifica problemele care pot aprea la un model ER (Howe, 1989). Vom discuta deasemenea, problemele reprezentrii unor aplicatii, folosind modelul ER (Schmidt i Swenson, 1975). Avnd n vedere c modelul ER are anumite limite n modelerea aplicatiilor, vom introduce un model mai complex, modelul EER, numit i specializare/generalizare. 1.1. Conceptele modelului Entity-Relationship Conceptele primare ale modelului ER includ : tip de entitate, tip de relaie, atribute. 1.1.1. Tipuri de entiti Definiie: Tip de entitate: Este un obiect sau un concept, identificat de o ntreprindere, avnd o existen independent. Tipurile de entiti reprezint obiecte reale, din viaa de zi cu zi, avnd proprietile lor, sau obiecte conceptuale, abstracte. Definiie: Entitate: Un obiect sau un concept ce se poate identifica unic. Un tip de entitate conine mai multe entiti. Un tip de entitate se identific prin nume i list de atribute. O baz de date conine n general mai multe tipuri de entiti. Fiecare tip de entitate are propriile lui atribute. Putem clasifica aceste tiburi n tipuri slabe i tipuri tari. Definiie: Tip slab de entitate: Este un tip de entitate, a crui existen este dependent de un alt tip de entitate. Definiie: Tip tare de entitate: Este un tip de entitate, a crui existen nu depinde de nici un alt tip de entitate. Entitile slabe se mai numesc dependente sau cubordonate iar cele tari printe sau dominante.
Page: 3

Reprezentarea grafic a entitilor: Entitile tari se reprezint printr-un dreptughi, etichetate cu numele entitii iar cele slabe se reprezint printr-un dereptunghi desenat cu linie dubl, etichetate deasemenea cu numele lor. Exemplu: nume entitate tare nume entitate slab

1.1.2. Atribute Definiie: Atribute: Proprietaile unui tip de entitate sau de relaie. Definiie: Domeniul atributului: Un set de valori ce se pot da acelui atribut. Domeniul unui atribut nu se poate definii totdeauna foarte exact. De exemplu, atributul nume de familie poate lua orice nume de familie existent. Evident, acest atribut trebuie s fie un ir de caractere, dar oare ce caractere poate s conin? Unele domenii se pot descompune n mai multe subdomenii. De exemplu data naterii se poate descompune in subdomeniile: an, lun, zi. Atributele se pot clasifica n simple sau compuse; cu o singur valoare sau cu mai multe valori; respectiv derivate. Definiie: Atribut simplu: Atribut care are doar o singur component i o existen independent. Aceste atribute nu se pot diviza mai trziu n mai multe atribute distincte. Definiie: Atribut compus: Atribut care are mai multe componente i o existen independent. Aceste atribute se pot diviza n mai multe atribute simple. De exemplu atributul adres se poate descompune n atributele: strada, numr, ora, cod potal i jude. Decizia ca un atribut compus s se descompun n mai multe atribute simple este dependent de modul n care se va utiliza acel atribut: separat pe componente, sau ntregul atribut. Definiie: Atribut cu o singur valoare: Atribut care poate lua o singur valoare pentru fiecare entitate. Majoritatea atributelor sunt atribute cu o singur valoare, ceea ce este indicat n proiectarea bazelor de date. Definiie: Atribut cu mai multe valori: Atribut care poate lua mai multe valori pentru fiecare entitate. Atributele cu mai multe valori, trebuie s aib totdeauna o limit inferioar i una superioar. Definiie: Atribut derivat: Atribvut a crei valoare se poate calcula din unul, sau mai multe alte atribute, care nu sunt neaprat atributele entitii n cauz. De exemplu atributul vrsta este derivat din atributul data naterii i data zilei n care se utilizeaz acest atribut. Alt exemplu ar fi atributul numrul total de entiti, ceea ce se poate calcula, numrnd entitile nregistrate. Chei: Intuitiv, o cheie este un atribut, care determin unic o entitate dintr-un tip de
Page: 4

entitate. n continuare, dm o definiie riguroas a cheii. Definiie: Cheie candidat: Un atribut, sau un set de atribute, care identific unic o entitate ditr-un tip de entitate. Definiie: Cheie primar: O entitate poate s aob una sau mai multe chei candidat, din care doar una selectat este i primar. Decizia referitoare la care din chile candidate s fie cheie primar este dependent de lungimea cheii. Cheia primar este de obicei cea mai scurt dintre cheile candidat. Definiie: Cheie compus: O cheie candidat care contine cel putin dou atribute. Reprezentarea grafic a atributelor: Un atribut se reprezint printr-o elips, legat de entitatea de care aparine cu o linie i etichetat cu numele atributului. Elipsa este punctat, dac atributul este un atribut derivat; respectiv dublat, daca poate lua mai multe valori. Dac un atribut este compus, atunci componentele atributului se reprezint n elipse legate printr-o linie de atributul compus. Atributurile care intr n componena cheii primare, se noteaz prin sublinierea numelui atributului. Exemplu: Numr bloc Scara Nume Locatari Numr matricol Adresa Etaj Apartament

n acest exemplu, entitatea Locatari, fiind o entitate tare, are urmtoarele atribute: Numr matricol, Nume i Adresa. Dintre aceste atribute, atributul Numr matricol este cheie primar; atributul Adresa este atribut compus, care se descompune n Numr bloc, Scara, Etaj i Apartament. 1.1.3. Tipuri de relaii Definiie: Tip de relaie: Asociere ntre tipuri de entiti. Definiie: Relaie: Asociere ntre entitti, cnd asocierea include un tip de entitate dintre toate tipurile participante. Reprezentarea grafic a relaiilor: Relaiile se reprezint printr-un romb etichetat cu numele relaiei. Rombul se deseneaz cu linie dubl, dac relaia leag o entitate slab de entitatea tare de care aparine. Definiie: Gradul relaiei: Nmrul entitiilor participante n relaie. Entitiile dintr-o relaie se numesc participani. Numrul lor d gradul relaiei.
Page: 5

Dac intr-o relaie sunt doi participani, atunci relaia se numete binar. Definiie: Relaie recursiv: Relaie n care aceleai entiti particip n roluri diferite. n cazul relaiilor recursive cele dou arce de la entitate la relaie i napoi, primesc diferite etichete, care sunt importante n nelegerea corect a relaiei. 1.1.4. Atributele relaiilor Atributele descrise mai sus, se pot asocia i relaiilor. Aceste atribute se reprezint grafic, ca i atributele entitiilor, cu deosebirea c legtura nu este cu o entitate, ci cu o relaie. Adic linia leag elipsa de rombul ce semnific relaia. 1.2. Structuralitatea S analizm acum restriciile ce pot aprea la includerea unei entiti participante ntr-o relaie. Avem dou tipuri mari de restricii: cardinalitatea i prticiparea. 1.2.1. Cardinalitatea Definiie: Cardinalul este numrul relaiilor posibile pentru o entitate partricipant. Majoritatea relaiilor au gradul doi, care pot fi: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Relaiile unu-la-unu: n relaiile unu-la-unu, o entitate este legat de cel mult o entitate din partea cealalt a relaiei. Aceast relaie se reprezint grafic prin etichetarea arcului dintre relaie i entitate cu cardinalul relaiei, adic cu 1. Relaiile unu-la-multe: Relaia de tip unu-la-multe are cardinalul 1 n stnga i N n dereapta. Deci o entitate participant este legat n relaia respectiv de 0, 1, sau mai multe entiti. Exemplificm acest tip de relaie prin relaia Sunt locuite dintre tipurile de entiti Scri, respectiv Locatari.

Atribute Nr_bloc Scara Nr_bloc Scara Nr_bloc Scara

Scri Sc.A Sc.B Sc.C

Sunt locuite de R1 R2 R3

Locatari Fam.1 Fam.2 Fam.3

Atribute Nr_mat Numele Nr_mat Numele Nr_mat Numele

Page: 6

Figura 1.1. Exemplu de relaie 1:M n reprezentarea grafic a relaiilor, relaia unu-la-multe se noteaz cu etichetarea arcului cu 1 n partea stng i cu N n partea dreapt. Din exemplul de mai sus observm c dac relaia direct este de unu-la-multe, atunci relatia invers este de unu-la-unu. Relaiile multe-la-multe: Acest tip de relaie se deosebete de relaia unu-la-multe prin faptul c relaia invers nu este de unu-la-unu, ci de unu-la-multe. Deci, dac i relaia direct i reaia invers este de tipul unu-la-multe, atunci relaia este de tipul multe-la-multe i se noteaz cu (N:M). 1.2.2. Participarea Definiie: Participarea determin dac existena unei entiti depinde sau nu de relaia cu o alt entitate. Participarea poate fi de mai multe tipuri: total i parial. n cazul participrii totale, toate entitiile particip n relaia dat. n caz contrar participarea se numete parial. n diagrama ER aceste tipuri de relaii se reprezint prin arc cu linie dubl pentru participarea total, respectiv cu linie simpl pentru participarea parial. Pentru participarea parial, exist un mod de notaie prin care se eticheteaz arcele relaiei cu perechea de numere ce reprezint minimul, respectiv maximul entitiilor participante la relaie. 1.3. Problemele modelului ER n acest capitol vom examina numeroasele probleme ce pot aprea la modelarea unei baze de date. Aceste probleme se refer la capcanele care pot aprea la definirea relaiilor ntre tipuri de entiti. Amintim dou tipuri mari de capcane: de tip labirint (fan trap), respectiv de tip prpastie (chasm trap). Definiie: Fan trap (capcan de tip labirint): Acest tip de capcan reprezint cazul n care modelul reprezint o relaie ntre dou tipuri de entiti, dar calea dintre cele dou membrii este ambigu. Cu alte cuvinte, pornind de la o entitate, nu se tie ca dup parcurgerea cii relaiilor, la ce entitate se ajunge n partea cealalt. Aceast capcan se poate elimina prin rearanjarea ordinii relaiilor dintre cele dou tipuri de entiti. Cellalt tip de capcan este: Definiie: Chasm trap (capcan de tip prpastie): Acest tip de capcan se descrie prin faptul c modelul sugereaz existena relaiei ntre cele dou tipuri de entitate, dar calea dintre tipurile de entiti nu exist. Aceast problem provine din participarea parial a unor entiti la una dintre relaii. Problema se poate rezolva prin introducerea unei relaii directe. 1.4. Modelul Enhanced Entity-Relationship (EER) Modelul ER, discutat n capitolele de mai sus, este adecvat pentru descrierea multor scheme de baze de date. Din 1980 s-au dezvoltat foarte mult aplicaiile care
Page: 7

folosesc baze de date. Modelul ER nu mai era suficient pentru reprezentarea complexelor scheme de baze de date. De aceea s-au introdus alte concepte n modelul ER, dezvoltnd modelul EER. Modelul EER include toate conceptele modelului ER, plus alte completri devenite necesare. Aceste concepte sunt nou introduse sunt: specializarea/generalizarea, categorisirea i ncapsularea. n acest capitol vom descrie conceptele de baz a modelului EER i anume, specializare/generalizare. Specializarea/generalizarea este n strns legtur cu modul de desciere a tipurilor de entiti n superclase i subclase, precun i de motenirea atributelor. De aceea vom descrie aceste concepte. 1.4.1. Superclasele i subclasele tipurilor de entiti Vom descrie aceste concepte, avnd ca exemplu tipul de entitate Locatari. Definiie: Superclas: Superclasa este un tip de entitate care include subclase distincte reprezentate ntr-un model de date. Definiie: Subclas : Subclasa este un tip de entitate care are un rol distinct i este membru al unei superclase. De exemplu superclasa Locatari se divizeaz n dou subclase i anume: ef de scar i Familii. Relaia dintre o superclas i o subclas se numete relaie superclas/subclas. Aceast relaie este de tip unu-la-unu. Relaia Locatari/Familii de exemplu, este o astfel de relaie. Fiecare membru al unei subclase este membru i n superclas, dar are un rol diferit. Exist subclase case se suprapun, adic exist membrii ntr-o subclas care apar i n cealalt subclas. Putem observa c exemplul de mai sus este exact de acest tip, pentru c eful de scar poate s fie i cap de familie. De ce se folosete clasificarea n subclase? Rspunsul este simplu de observat direct din exemplul dat. Dac nu am clasifica entitiile din tipul de entitate Locatari, atunci ar trebui s memorm informaiile specifice efului de scar i capului de familie pentru fiecare locatar. Deoarece majoritatea locatarilor nu aparine niciunei categorii, pentru acestea ar fi informaii nefolositoare, dar care ns ar ocupa mult spaiu pe suportul magnetic. 1.4.2. Motenirea atributelor Fiecare subclas are ca atribute comune, atributele superclasei n care aparine. Deci fiecare membru al unei subclase se caracterizeaz prin atributele superclasei i alte atribute specifice subclasei. De exemplu subclasa Familii se caracterizeaz prin toate atributele superclasei Locatari (Numr matricol, Numr bloc, Scara, Etaj, Apartament i Nume), pe lng care mai are i ate atribute specifice (Numr persoane, Numr persoane prezente, etc.) Fiecare subclas poate s aib subclase, crendu-se un arbore de clase, care se numete ierarhie de tipuri. Aceast ierarhie de tipuri include alte denumiri de ierarhii i anume: ierarhia de specializri (de exemplu, tipul de entitate Familii este o specializare a tipului de entitate Locatari) i ierarhia de generalizri (de exemplu, Locatari este o generalizare a tipului de entitate Familii).
Page: 8

1.4.3. Specializarea Definiie: Specializare este un proces de maximizare a diferenelor unor membrii ale unei entiti, identificnd caracteristicile distincte. Specializarea este o aproximare top-down a definirii unor superclase, mreun cu subclasele lor. Relaia superclas/subclas se reprezint grafic printr-un arc de la superclas la un cerc, care la rndul lui este legat cu un arc de subclas. Pe arcele de la subclase se deseneaz un semn de incluziune de la subclas la superclas. Aceste semn de incluziune indic direcia relaiei superclas/subclas. Atributele specifice doar subclasei sunt ataate direct la dreptunghiul care reprezint subclasa. Toate aceste notaii se exemplific n figura de mai jos: Numr matricol Numr bloc Locatari ef de scar Data intrrii n funcie n exemplul de mai sus tipul superclasa Locatari se compune din mai multe subclase: ef de scar i Familii. Superclasa Locatari va avea ca membrii pe toi locatarii unei scri. ntre aceti locatari, unii sunt capi de familii iar alii efi de scar. Aceti membrii ai tipului de entitate Locatari vor aprea ca membrii i n subclasele ef de scar, respectiv Familii. Definiie: Subclas partajat se numete subclasa care are mai multe superclase. Membrii din subclasa partajat sunt membrii n fiecare dintre superclase. De aceea ei motenesc atributele fiecrei superclase o astfel de motenire se numete motenire multipl. n cazul relaiilor, dac o subclas este n relaie cu un alt tip de entitate, aceast relaie se refer doar la subclasa respectiv, nu i la superclasa lui. 1.4.4. Generalizarea Definiie: Generalizare se numete procesul de minimizare a diferenelor dintre entiti, pentru identificarea caracteristicilor comune. Procesul de generalizare este o aproximare bottom-up a superclaselor, din subclasele originale. Deci generalizarea este inversa specializrii. De exemplu dac privim tipurile de entiti Familii i ef de scar, vom observa c unele atribute ale lor caracterizeaz ambele tipuri. De aici rezult necesitatea crerii unei superclase care s conin toate atributele comune celor dou tipuri.
Page: 9

Familii Numr persoane

Adresa

1.4.5. Regurile specializrii i generalizrii n acest capitol vom discuta despre regulile ce trebuie aplicate n cazul specializrii sau al generalizrii. Prima regul se numete regula disjunciei. Aceast regul specific dac subclasele unei clase sunt disjuncte, adic un membru al superclasei aparine cel mult uneia dintre subclase. O specializare disjunct se reprezint cu un d nscris n cercul care leag subclasele de superclase. Dac subclasele nu sunt disjuncte, adic un membru al superclasei poate s aparin la mai multe subclase, atunci subclasele respective se numesc non disjuncte i se noteaz cu o n cercul care leag subclasele de superclase. n exemplul nostru subclasele Sef de scar i Familii - care sunt subclasele clasei Locatari - sunt non disjuncte. A doua regul a specializrii este regula participrii, care poate fi total sau parial. Participarea este total dac toi membrii superclasei sunt i membrii subclaselor. Pentru reprezentarea participrii totale, arcul de la superclas la cercul dintre superclas i subclas se dubleaz. n cazul participrii pariale nu toi membrii superclasei iau parte ntr-o subclas. Acest tip de participare se reprezint cu linie simpl ntre superclas i cerc. n exemplul nostru avem o participare parial n cazul superclasei Locatari, cu subclasele ef de scar i Familii. Cele dou reguli se aplic distinct la procesele de specializare, sau generalizare. De aceea putem avea patru tipuri de specializri: disjunt total, disjunct parial, non disjunct total, sau non disjunct parial. 1.5. Descrierea cerinelor sistemului Asociaie de locatari - Crearea unui model EER n acest capitol vom demonstra crearea unui model EER. Vom descrie cerinele sistemului informatic pentru asociaia de locatari, dup care vom identifica entitile, relaiile, cardinalitatea i participarea relaiilor i atributele asociate entitilor. Dup toate aceste identificri vom crea diagrama EER asociat aplicaiei. 1.5.1. Descrierea sistemului informaic Asociaia de locatari (1) O asociaie de locatari se compune din una sau mai multe scri, aflate n una sau mai multe blocuri indentificate prin numr bloc i numr scar. Pe fiecare scar locuiesc locatari dintre care se alege un ef de scar. Fiecare dintre scri se compune din apartamente, avnd informaii prin care se poate face relaia la scri, precum i alte informaii constnd din: numr apartament, suprafaa, numrul cutiilor potale, a prezelor tv., a legturilor la coul de fum i altele. (2) Locatarii sunt identificai printr-un numr matricol unic n toat asociaia de locatari. Informaiile despre ei sunt memorate n numr bloc, scara, etaj, apartament - reprezentnd adresa - i nume. Unii dintre locatari pot fii efi de scar si/sau capi de familii, ceea ce implic alte informaii n plus pentru aceste
Page: 10

(3)

(4) (5) (6) (7)

(8) (9)

persoane. Aceste informaii sunt: pentru ef de scar, data intrrii n funcie iar pentru capul de familie, numrul de persoane, numrul de persoane prezente, numrul de chei, valoarea fondului de rulment, a fondului de reparaii, a altor fonduri, precum i plata curent i restana. n fiecare lun se primesc facturi de la diferii furnizori, reprezentnd cheltuielile asociaiei de locatari. Aceste cheltuieli sunt identificai unic de un numr de cheltuial i au n componena informaiilor o informaie prin care se face legtura cu un furnizor, tipul de cheltuial, numrul, data i valoarea facturii i scadena. Aceste scheltuieli pot fii pe una sau mai multe scri sau pe una sau mai multe familii. Cheltuielile se vor pltii de asociaia de locatari ori prin virament, ori prin cas. Locatarii i pltesc datoriile la asociaia de locatari cu bani ghea, primind ca dovad a plii, chitane. Despre pli se memoreaz o legtur la capul de familie care a efectuat plata, numrul, data i valoarea chitanei. Furnizorii de la care vin facturile la asociaia de locatari, se identific unic printr-un cod local, sau dup codul fiscal. Pe lng aceste informaii mai memorm informaii despre denumire, contul, banca i adresa sediului. Calculul pliilor pentru locatari se va face la nceputul fiecrei luni, pentru luna anterioar, memornd data efecturii calculului, numrul matricol al capului familiei pentru relaie, valoarea i restana pentru luna aceea. Dup listarea plilor nu se mai admit modificri. Fiecare scar este ntreinut de un personal identificat de un numr matricol (alta dect la locatari) i avnd informaiile: legtura la scara unde lucreaz, numele, data naterii i a angajrii i meseria. n asociaia de locatari pot fi mijloace fixe i obiecte de inventar, identificate prin numrul de inventar i avnd ntre informaii legtura la scara unde sunt amplasate. Se mai poate memora despre ei denumirea, valoarea i valoarea amortizat.

1.5.2. Crearea modelului EER n acest capitol von demonstra crearea modelului EER. Vom crea modelul EER pentru Asociaia de locatari, folosind descrierea de mai sus. Identificarea tipurilor de entiti: La nceput identificm tipurile de entiti din specificaiile de mai sus: Scari Apartamente Locatari ef de scar Familii Pli Chitane
Page: 11

Cheltuieli Achitri Patrimoniu Personal Obiecte de inventar Furnizori

Identificarea tipurilor de relaii: Vom identifica tipurile principare de relaii. Relaiile sunt reprezentate de verbele lor n tabela de mai jos. Tip de entitate Scri Tip de relaie sunt locuite de se compun din sunt ntreinute de se folosete trebuie s plteasc Primesc Provoac se calculeaz pentru se calculeaz pentru se achit prin Tip de entitate Locatari Apartamente Personal Patrimoniu Pli Chitane Cheltuieli Scri Familii Achitri

Familiile Furnizorii Cheltuielile

Determinarea cardinalitii i a participrii n tipurile de relaii: Considerm relaia Scri-le sunt locuite de Locatari. O singur scar este locuit de mai muli locatari. Deci pn acum cardinalitatea este de 1:M, ns trebuie s verificm i relaia invers - Locatarii locuiesc pe Scri - unde se observ c un locatar locuiete pe o singur scar. Deci n final, cardinalitatea relaiei este 1:M. n continuare fie relaia Cheltuielile se calculeaz pentru Scri. Observm c putem avea mai multe scri la care s se refere o cheltuial, precum i mai multe cheltuieli pentru o scar. Deci cardinalul relaiei este de N:M. S analizm acum participarea la relaie a membriilor tipurilor de entiti: Fie relaia Scri-le sunt locuite de Locatari. Putem avea cazul n care o scar s nu fie locuit deloc de locatari. n cazul relaiei inverse nu putem avea cazul n care un locatar s nu locuiasc pe nici o scar. Deci relaia direct este parial, iar cea invers este total. Cardinalitatea i participarea celorlaltor relaii este artat n urmtorul tabel: Tip de entitate Scri Tip de relaie sunt locuite de se compun din sunt ntreinute de se folosesc trebuie s plteasc primesc provoac se calculeaz pentru se calculeaz pentru se achit prin Tip de entitate Locatari Apartamente Personal Patrimoniu Pli Chitane Cheltuieli Scri Familii Achitri Participarea Card. Direct Invers 1:M parial total 1:M total total 1:M partial total 1:M parial total 1:M parial parial 1:M parial parial 1:M parial total M:N total parial M:N total parial 1:M total total

Familiile Furnizorii Cheltuielile Cheltuielile

Page: 12

Am observat c relaia Cheltuilile sunt de tipul Tip cheltuial are cardinalul M:1. De accea avnd n vedere convenia c relaiile se denumesc n direcia 1:M vom schimba numele relaiei n Tip cheltuial este tipul unei Cheltuieli. Indentificarea atributelor asociate entitiilor: Vom identifica atributele entitiilor, atribute ce descriu caracteristicile entitiilor. Aceste atribute sunt trecute n urmtorul tabel: Tip entitate Scri Apartamente Atribute Nr_bloc Scara Lift Apartament Nr_bloc Scara Suprafaa Cutii_potale Nr_prize_tv Nr_mat Nr_Bloc Scara Etaj Apartament Nume Data Nr_mat Valoare Restan Cod_Furnizor Denumire Cod_fiscal Cont Banca Strada Nr Bl Sc Ap Localitate Jude Nr_matricol Nr_bloc Scara Nume
Page: 13

Tip entitate ef de scar

Familii

Locatari

Pli

Furnizori

Chitane

Cheltuieli

Achitri

Personal

Patrimoniu

Atribute Nr_mat Nr_Bloc Scara Etaj Apartament Nume Data_intrare_func Nr_Mat Nr_Bloc Scara Etaj Apartament Nume Nr_pers Nr_pers_prezente Nr_chei Fond_rulment Fond_reparaii Alte_fonduri Nr_Chit Nr_Mat Valoare Data Nr_Crt Cod_Cheltuial Cod_Furnizor Nr_factur Data_factur Valoare_factur Nr_crt Nr_Doc Tip_Op Valoare_Achit Data Nr_inventar

Data_naterii Meseria Data_angajrii

Nr_bloc Scara Denumire Inv_Fix Valoare

Determinarea cheilor canditat i cheilor primare: Vom analiza cheile candidat al fiecrei tip de entitate i vom alege una din ele s fie cheie primar. De exemplu n tipul de entitate Locatari aven o cheie candidat, numit Nr_mat. Deci aceast cheie va fi cheia primar. n general cheia cea mai simpl este aleas n funcia de cheie primar. n tabela urmtoare specificm cheile primare si alternante ale fiecrei tip de entitate: Tip entitate Scri Apartamente Locatari ef de scar Familii Pli Chitane Cheltuieli Furnizori Achitri Personal Patrimoniu Cheie primare Nr_bloc, Scara Nr_bloc, Scara Nr_Mat Nr_Mat Nr_Mat Data, Nr_Mat Nr_Chit Nr_Crt Cod_Furnizor Nr_Doc, Tip_Op Nr_matricol Nr_inventar Chei alternante

Cod_fiscal

Specializarea sau generalizarea tipurilor de entiti: n final putem lua decizia de a specializa o clas. Dac avem tipuri de entiti care au aceleai atribute, atunci putem generaliza aceste tipuri de entiti. De exemplu din tabelul n care apar atributele tipurilor de entiti, putem observa c tipurile de entiti Locatari, ef de scar i Familii au multe atrbute comune. Deci putem generaliza tipurile de entiti ef de scar i Familii la tipul de entitate Locatari. Dup generalizare vom avea o relaie de specializare/grneralizare, care nu este disjunct i este parial. Desenm diagrama EER: Folosind toate informaiile descrise mai sus, desenm diagrama EER a sistemului informatic al Asociaiei de locatari. Scule CASE pentru crearea modelului ER. n acest capitol vom descrie produse CASE (Computer Aided Software Engineering) care ne ajut la proiectarea bazelor de date relaionale. La elaborarea
Page: 14

prezentei lucrri am folorit produsul ERwin produs de Logic Works. La intrare n program fereastra va arta n modul urmtor:

Pentru crearea unui model ER se folosesc butoanele din fereastra ERwin Toolbox. Cu aceste butoane se poate proiecta baza de date, desennd tabelele i relaiile dintre ele. Cum crem o entitate? Pentru a crea o entitate, selectm butonul i l poziionm undeva n pagin. Va aprea un dreptunghi, care are delimitat dou seciuni: cheia principal (deasupra liniei orizontale) i atributele asociate entitii (sub linia orizontal). Deasupra dreptunghiului apare numele tipului de entitate. Dac entitatea este dependent, atunci se selecteaz butonul Exemplu de entiti: .

Page: 15

Locatari Nr_Mat Etaj Nr_Bloc (FK) Apartament Scara (FK) Nume

Plati Data Nr_Mat (FK) Valoare Restanta

Numele acestei entitilor sunt Locatari - entitate independent - i Pli entitate dependent. n cazul entitii Locatari, seciunea chei principale se compune din cmpul Nr_Mat iar cmpurile de sub linie sunt atributele asociate entitii. n teoria de mai sus aceste informaii sunt reprezentate grafic n urmtorul mod: tip de entitate se reprezint cu un dreptunghi etichetat cu numele entitii atributele se reprezint cu o elips etichetat cu numele atributului atributele din cunponena chei principale se subliniaz Cum notm cheile candidate? La editarea numelui atributului care este coninut ntr-o cheie candidat, se trece n continuarea numelul textul: (AKn), unde n reprezint numrul chei candidat de care aparine atributul. n exemplul nostru Nume este cheie candidat. Cum evideniem un tip de relaie? Selectm butonul corespunztor tipului de relaie dorit dintre tipurile , reprezentnd relatie identificare de cardinal 1:M, N:M respectiv relaie neidentificare. Diferena ntre relaiile identificare i neidentificare este c n cazul primului tip cheia entitii printe migreaz n seciunea de cheie principal a entitii fiu iar n cazul al doilea migreaz n seciunea de atribute. Exemplu de tip de relaie: se calculeaz pentru Scri

Cheltuieli

Pentru a specializa/generaliza tipurile de entiti, folosim butoanele , care reprezint specializare cu participare total respectiv parial. n cazul specializrii, cheia principal de la tipul de entitate printe, migreaz n seciunea cheii principale a tipului de entitate fiu. O astfel de relaie este ntre tipurlile de entitate Locatari i Familii: Locatari

Familii
Page: 16

ef de scar

Simbolul de specializare de mai sus reprezint, c nu toate entitile din tipul de entitate Locatari iau parte n una din tipurile de entiti Familii sau ef de scar. Deci participarea este parial. Suportul produsului ERwin pentru normalizarea bazei de date: ERwin are suport pentru normalizarea bazei de date, dar nu are implementat un algoritm de normalizare. Ajutorul acordat proiectantului bazei de date const n avertizarea acestuia n cazul unor erori la normalizare. Suportul Formei Normale Unu: n moledul ER atributele sunt identificate prin nume. ERwin accept orice nume pentru atribute, cu urmtoarele excepii: Avertzeaz n cazul utilizrii unei denumiri de tip de entitate de dou ori (depinde de setaria opiune Nume unic). Avertizeaz n cazul folosirii de dou ori a aceluiai nume de atribut, cu excepia numelui de rol. ERwin nu distinge dac un atribut conine sau nu mai multe informaii. De exemplu se accept i denumirea Numele copiilor ceea ce poate reprezenta un tablou n acel atribut. Suportul pentru Forma Normal Doi i Trei: ERwin nu cunoate dependenele funcionale din baza de date, dar poate ajuta la priectarea bazei de date n forma normal doi sau trei. De exemplu avertizeaz n cazul n care o cheie care migreaz (n cazul unui relaii), apare de dou ori n tipul de entitate. Acesta poate s apar n cazul n care sunt mai multe relaii ntre dou tipuri de entiti. Potem opta pentru pstrarea cheii de dou ori, dnd nume diferite cmpurilor, sau pentru unificarea atributelor ce compun cheia. Baza de date se poate proiecta pe view-uri, ERwin genernd automat imaginea ntregii baze de date. Se poate selecta modul de reprezentare a bazei de date, opiunile fiind: nivel de entitate, la nivel de chei primare, sau la nivel de atribute. Toate aceste opiuni fiind disponibile pentru nume logice i fizice. Dup proiectarea bazei de date, acesta se poate exporta n mai multe formate disponibile, dintre care amintim: FoxPro, Acces, Oracle, Ingres, AS/400, Informix, Progress i altele. Baza de date a sistemului de gestiune a Asociaiei de locatari proiectat cu ERwin este urmtorul:

Page: 17

Locatari Nr_Mat Etaj Nr_Bloc (FK) Apartament Scara (FK) Nume Sunt locuite de Au cheltuieli

Scari Nr_Bloc Scara Lift Patrimoniu Pe scari Scara (FK) Nr_Crt (FK) Nr_Bloc (FK) Contin Nr_Inventar Nr_Bloc (FK) Scara (FK) Denumire Inv_Fix Valoare Se compun din Apartamente Nr_Bloc (FK) Scara (FK) Apartament Suprafata Cutii_postale Nr_prize_tv

Personal Nr_matricol Nume Data_nasterii Meseria Data_angajarii Este

Furnizori Cod_Furnizor Denumire Cod_fiscal (AK1) Cont Banca Strada Nr Bl Sc Ap Localitate Judet

Alocate Nr_matricol (FK) Nr_Bloc (FK) Scara (FK)

Sunt

Se calculeaza Se calculeaza Sef de scara Nr_Mat (FK) Data_intrare_func Familii Nr_Mat (FK) Nr_pers Nr_pers_prezente Nr_chei Fond_rulment Fond_reparatii Alte_fonduri Pe familii Nr_Crt (FK) Nr_Mat (FK) Au cheltuieli Plati Data Nr_Mat (FK) Valoare Restanta Trebuie sa plateasca Cheltuieli Nr_Crt Cod_Furnizor (FK) Cod_cheltuiala Nr_factura Data_factura Valoare_factura Provoaca Se achita

Chitante Nr_Chit Nr_Mat (FK) Valoare Data

Achitari Nr_Doc Tip_Op Nr_Crt (FK) Valoare_Achit Data

Primesc

Page: 18

2. Normalizarea bazei de date

n acest capitol vom discuta despre: Necesitatea normalizrii Problemele asociate cu informaiile redundante n rnduri. Identificarea tipurilor variate de anomalii ce pot aprea la actualizare: inserare, tergere i modificare. Procesul de normalizare. Conceptul de dependen funcional, modalitatea de a grupa atributele n relaii Cum utilizm dependenele funcionale, pentru a grupa atributele n relaii care sunt n forme normale cunoscute? Cum definesc relaiile, formele normale? Cum derulm procesul de normalizare? Cum identificm prima (1NF), a doua (2NF) i a treia (3NF) form normal, resprctiv forma normal Boyce-Codd (BCNF)? 2.1. Necesitatea normalizrii Cnd proiectm o baz de date, dorina noastr este de a reprezenta ct mai corecte informaiile i s diminum ct mai mult posibilitatea de a ajunge la informaii eronate (dac nu putem elimina de tot acest neajuns). Pentru a ajunge la aceast performan, trebuie s folosim normalizarea. Definiie: Normalizare: O tehnic de generare a unor relaii co proprietiile dorite, n scopul memorrii corecte a datelor unei ntreprinderi. Procesul de normalizare prima dat a fost introdus de E. F. Codd (1972). Iniial s-au propul trei forme normale, numerotate de al unu la trei. Mai trziu s-a inclus nc o form normal, numit Boyce-Codd, dup numele celor care l-au introdus: R. Boyce i E. F. Codd. Formele normale cele mai folosite sunt: forma normal 3 i forma normal Boyce-Codd. Exist i forme normale mai tari - forma normal 4 (4NF) i forma normal 5 (5NF) - dar aceste se folosesc foarte rar. Procesul de normalizare este o metod formal de identificare a relaiilor bazate pe chei primare (sau chei candidat n cazul BCNF) i dependenele funcionale cu atributele asociate. Normalizarea d posibilitatea proiectantului bazei de date, pentru a efectua o seria de teste pe baza de date, toate aceste teste ducnd la prevenirea posibilitii de a aprea anomalii la actualizarea bazei de date. Pentru a ilustra procesul de normalizare, vom folosii exemple din sistemul informatic Asociacie de locatari. 2.2. Redundana n informaii i anomalii la actualizare Partea cea mai important a proiectrii bazei de date este de a grupa atributele
Page: 19

n relaii cu scopul de a minimiza redundana n informaii i spaiul ocupat de fiiere pe suportul magnetic. Fie relaia Furnizori_Cheltuieli exemplificat mai jos. La exemple vom simplifica atributele asociate entitiilor. Cod Denumire Cod Nr. Cod Furn. fiscal Crt. Chelt. F100 Romgaz R1234567 1 C15 F100 Romgaz R1234567 2 C16 F110 Renel R7654321 3 C10 F110 Renel R7654321 4 C11 Figura 2.1 Relaia Furnizori_Cheltuieli Denumire Cheltuial Chelt pt. nclzire Chelt pt. buctrii Chelt cu iluminatul Chelt pt. func. liftului Valoare 1500000 500000 3000000 200000

Dependenele funcionale pentru relaia Furnizori_Cheltuieli de mai sus sunt urmtoarele: Furnizori (Cod.Furn., Denumire, Cod fiscal) Cheltuieli (Nr.Crt., Cod chelt., Cod.furn., Valoare) Tip_cheltuiala (Cod.Chelt., Denumire chelt.) Furnizori_Cheltuieli (Nr.Crt., Cod chelt., Cod furn., Denumire chelt., Denumire, Cod fiscal, Valoare) n acest exemplu, informaia despre furnizor devine redundant. Detraliile despre furnizor se repet la fiecare introducere a unei cheltuieli noi. n dependenele funcionale specificate pentru entitatea Cheltuieli, apare doar codul furnizorului. Analog, denumirea cheltuielii, apare i ea n plus fa de entitatea Cheltuieli. O alt problem serioas datorat redundanei bazei de date, sunt problemele de actualizare a informaiei stocate. Aceste probleme se pot clasifica n anomalii de inserare, modificare, sau tergere. 2.2.1. Anomalii de inserare Anomaliile de inserare se pot clasifica n dou tipuri mari: Pentru a adauga detaliile despre o cheltuial ctre un furnizor, n relaia Furnizori_Cheltuieli trebuie obligatoriu adugate i detaliile despre furnizorul n cauz, chiar dac el exist deja n baza de date. Aceast anomalie poate duce la apariia aceluiai furnizor, avnd introduse detalii diferite n nregistrri diferite. Pentru a aduga detaliile unui furnizor nou n relaia Furnizori_Cheltuieli, trebuie neaprat adugat i o cheltuial pentru asociaia de locatari ctre acel furnizor. n cazul n care nc nu a sosit factura de la furnizor, nu pot nregistra nici o cheltuial i deci trebuie introduse date vide n locul cheltuieli. Cum Nr.Crt. este cheia primar n relaia Furnizori_Cheltuieli, introducerea de date vide n acest cmp va strica integritatea entitii.
Page: 20

2.2.2. Anomalii de tergere n cazul tergerii ultimei cheltuieli a asociaiei de locatari ctre un furnizor, se va terge i furnizorul. Deci toate detaliile introduse despre acel furnizor vor fi pierdute, ceea ce duce la obligativitatea reintroducerii datelor la o nou folosire al acelui furnizor. n cazul entitii separate pentru cheltuieli i furnizori, dac se terge i ultima cheltuial ctre un furnizor, datele despre furnizor rmn totui n entitatea Furnizori. 2.2.3. Anomalii de modificare Dac n relaia Furnizori_Cheltuieli dorim s schimbm valoarea unui atribut al unui furnizor, va trebui s schimbm datele la fiecare apariie a acelui furnizor. De exemplu dac dorim s schimbm codul fiscal al furnizorului cu codul F100, va trebui s achimbm acest atribut n dou locuri. Dac n timpul modificrilor, care poate dura destul de mult, intervine i un incident n uema cruia vor rmne nregistrri nemodificate, atunci baza de date devine inconsistent. Aceast anomalie se poate evita prin folosirea a dou entiti distincte precum Cheltuieli i Furnizori. n acest caz dac trebuie s modific un atribut al unui furnizor, va trebui s-o modific doar ntr-un singur loc: n entitatea Furnizori. 2.3. Dependene funcionale Unul din cele mai importante concepte asociate normalizrii este dependena funcional. Dependena funcional descrie relaia dintre atribute. n acest capitol vom descrie conceptul de dependen funcional, urmnd ca n capitolele urmtoare s descriem procesul de nlormalizare a bazei de date. 2.3.1. Definiia dependenei funcionale Definiie: Dependen funcional: Descrie relaia dintre atribute. De exemplu dac atrubutul A este n relaia R cu atributul B, atunci atributul B este dependent funcional de atributul A (notat: A B), dac orice valoarea al lui A este asociat prin relaia R cu exact o valoare a atributul B. Dependena funcional este o proprietate a semanticii atributelor n relaii. Semantica indic atributele care sunt n relaie i specific dependenele funcionale dintre atribute. Considerm o relaie ntre dou atribute A i B, unde atributul B este dependent funcional de atributul A (atributele A i B pot fi compuse din mai multe atribute). Cu alte cuvinte, dac tim valorile cmpului A, atunci analiznd valorile lui B n relaia cu A, vom considera c pentru valori diferite al lui A - care fiind cheie, trebuie s aib valori diferite - avem valori diferite i pentru cmpul B. Dependena
Page: 21

funcional dintre dou cmpuri se reprezint grafic n urmtorul mod: A Figura 2.2 Diagrama dependenei funcionale Definiie: Determinant: Numim determinantul unei relaii funcionale, atributul, sau mulimea atributelor din partea stng a sgeii. n acest capitol vom ignora dependenele funcionale triviale, adic acele relaii de tipul AB, n care B este dependent de un subset de atribute al lui A. Pentru a exemplifica dependenele funcionale, considerm urmtorul exemplu: Exemplu: Considerm atributele Cod furnizor i Denumire. Pentru un anumit cod de furnizor, putem determina denumire acelui furnizor. Adic denumirea este dependent funcional de cod furnizor. Dependena invers nu este adevrat pentru c pot exista aceleai denumiri cu coduri diferite. Relaia dintre cod furnizor i denumire este de 1:1, iar relaia invers este de 1:M. S identificm dependenele descris mai sus: Nr. Crt., Cod Furn., Cod Chelt. Nr. Crt., Cod Furn., Cod Chelt. Nr. Crt., Cod Furn., Cod Chelt. Nr. Crt., Cod Furn., Cod Chelt. Cod Furnizor Cod Furnizor Cod fiscal Cod fiscal Cod Chelt. funcionale din relaia Furnizori_Cheltuieli Denumire Cod fiscal Denumire cheltuial Valoare Denumire Cod fiscal Denumire Cod Furnizor Denumire cheltuial B

n aceast relaie avem 9 dependene funcionale, care au determinantele (Nr. Crt., Cod Furn., Cod Chelt.), Cod fiscal, Cod Furn. i Cod Chelt. Putem evidenia aceste dependene i ntr-un alt format: Nr.Crt., Cod Furn., Cod Chelt. Denumire,Cod fiscal, Denumire cheltuial, Valoare Cod Furn. Denumire, Cod fiscal Cod fiscal Denumire, Cod Furn. Cod Chelt. Denumire cheltuial Pentru a identifica cheile candidate, trebuie s identificm atributul, sau grupul de atribute care determin unic fiecare nregistrare al acestei relaii. Dac avem mai mult de o cheie candidat, atunci va trebui s identificm i o cheie primar. Toate atributele care nu aparin cheii primare, depind funcional de cheia primar. n aceast ipostaz este grupul de atribute (Nr. Crt., Cod Furn., Cod Chelt.). Atributele
Page: 22

Cod Furn., Cod fiscal i Cod Chelt. Sunt determinani, dar nu sunt chei candidat. Conceptul de dependen funional este conceptul central al normalizrii, ceea ce vom descrie n capitolele urmtoare. 2.4. Procesul de normalizare Normalizarea este un proces formal de analiz a relaiilor bazate pe chei primare (sau pe baza cheilor candidat n cazul BCNF). Normalizarea presupune urmarea unor reguli prin care baza de date se poate normaliza pn la un anumit grad. Dac o cerin nu este satisfcut, relaia trebuie dezcompus n mai multe relaii, care individual satisfac cerinele formei normale. Normalizarea se execut trecnd prin toate formele nornale, pn la forma normal cerut. La proiectarea unei baze de date trebuie s ajungem cel puin la forma normal unu, dar ca s evitm toate anomaliile descrise mai nainte, este recomandat aducerea bazei de date la BCNF. n figura urmtoare evideniem relaia dintre diversele forme normale. Observm c unele din relaiile n 1NF este i n 2NF, dintre care unele n 3NF i aa mai departe. 1NF 2NF 3NF BCNF 4NF 5NF NF Figura 2.3. Ilustrarea grafic a relaiei dintre formele normale. 2.5. Forma Normal Unu (1NF) nainte s discutm despre forma normal unu, vom da definiia stadiului dinainte de aceast form normal. Definiie: Form Nenormalizat (UNF): O tabel care conine una sau mai multe grupuri repetitive. Definiie: Forma Normal Unu (1NF): Relaie n care la intersecia oricrei linii cu oricare coloan gsim un cmp care conine exact o valoare. n acest capitol ncepem procesul de normalizare. Pentru nceput transferm datele de la surs ntr-o tabel, care va fi o tabel nenormalizat. Pentru a transforma aceast tabel n forma normal unu, identificm i tergem grupurile repetitive din tabel. Grupurile repetitive sunt atribute, sau grup de atribute, pentru care avem
Page: 23

diferite valori pentru aceeasi valoare a cheii, ceea ce este n contradicie cu definiia cheii. Eliminarea acestor grupuri repetitive se poate realiza n dou moduri: Conform primei modaliti, eliminm grupurile repetitive, prin crearea altor nregistrri, n care s fie introduse valorile din aceste grupuri, mpreun cu celelalte valori ai atributelor din nregistrarea la care se lucreaz. Tabele astefel rezultat va fi n form normal unu. n a doua modalitate, fiecere valoare a grupurilor repetitive le copiem ntr-o nou relaie mpreun cu cheia primar din tabela iniial. Putem avea mai multe grupuri repetitive. n acest caz crem mai multe relaii noi. Aceste relaii noi, precum i tabela normalizat vor fi n form normal unu. De exemplu s lum relaia Furnizori_Cheltuieli: Cod Denumire Cod Nr. Cod Denumire Furn. fiscal Crt. Chelt. Cheltuial F100 Romgaz R1234567 1 C15 Chelt pt. nclzire 2 C16 Chelt pt. Buctrii F110 Renel R7654321 3 C10 Chelt cu iluminatul 4 C11 Chelt pt. Func. liftului Figura 2.4. Tabela nenormalizat Furnizori_Cheltuieli. Valoare 1500000 500000 3000000 200000

n aceast tabel observm c pentru furnizorul Romgaz avem dou tipuri de cheltuieli. Pentru a transforma aceast tabel n 1NF, trebuie s avem o singur valoare la fiecare intersecie linie coloan. n cazul primei modaliti, scriem repetiiile pe diferite rnduri iar coloanele care nu conin repetiii, vor fii copiate pe fiecare rnd. Dup desprirea repetiiilor pe mai multe rnduri, identificm o nou cheie. Cod Denumire Cod Nr. Cod Denumire Furn. fiscal Crt. Chelt. Cheltuial F100 Romgaz R1234567 1 C15 Chelt pt. nclzire F100 Romgaz R1234567 2 C16 Chelt pt. Buctrii F110 Renel R7654321 3 C10 Chelt cu iluminatul F110 Renel R7654321 4 C11 Chelt pt. Func. liftului Figura 2.5. Tabela Furnizori_Cheltuieli n 1NF, creat prin prima modaliate de transformare. Valoare 1500000 500000 3000000 200000

n tabela normalizat, noua cheie va fii (Cod Furn., Nr. Crt., Cod Chelt.). Normaliznd tabela iniial dup a doua modalitate, vom crea o a doua tabel cu informaiile care nu se repet, mpreun cu cheia primar din tabela iniial. Deci cele dou tabele vor fi urmtoarele: Furnizori (Cod Furn., Denumire, Cod fiscal)
Page: 24

Cheltuieli (Cod Furn., Cod Chelt., Nr. Crt., Denumire cheltuial, Valoare) Cele dou tabele astfel create sunt n 1NF: Cod Nr. Cod Furn. Crt. Chelt. F100 1 C15 F100 2 C16 F110 3 C10 F110 4 C11 Denumire Cheltuial Chelt pt. nclzire Chelt pt. Buctrii Chelt cu iluminatul Chelt pt. func. Liftului Valoare 1500000 500000 3000000 200000

Cod Denumire Cod Furn. fiscal F100 Romgaz R1234567 F100 Romgaz R1234567 F110 Renel R7654321 F110 Renel R7654321 Figura 2.6. Relaia Cheltuial i Furnizor, create prin metoda a doua de normalizare. Pentru a demonstra trecerea la forma normal doi i mai mari, vom folosii relaia Furnizori_Cheltuieli, evideniat n figura 2.5.

2.6. Forma Normal Doi (2NF) Forma normal doi se bazeaz pe conceptul de dependen funcional total, ceea ce vom descrie n continuare. 2.6.1. Dependena funcional total Definiie: Dependena funcional total: Dac A i B sunt atributele unei relaii, atunci B este total dependent funcional de atributul A, dac B este dependent funcional de A, dar nu este dependent funcional de nici un subset al lui A. De exemplu s lum urmtoarea dependen funcional: Nr. Crt., Cod Chelt. Denumire cheltuial Dependena funcional este corect, pentru c fiecare valoare al lui (Nr. Crt., Cod Chelt.) determin unic denumirea cheltuielii, ns dependena nu este total, pentru c Denumire cheltuial depinde funcional i de un subset al lui (Nr. Crt., Cod Chelt.) i anume atributul Cod Chelt.
Page: 25

2.6.2. Definiia Formei Normale Doi Forma normal doi trebuie verificat doar la relaiile care au cheie compus pe poziie de cheie primar. Relaiile la care cheia primar se compune dintr-un singul atribut, este n 2NF. Relaiile care nu sunt n forma normal doi, pot suferii de anomaliile prezentate in capitolul 2.2. De exemplu dac n cazul relaiei Furnizori_Cheltuieli vream s actualizm datele despre furnizorul F100, trebuie s actualizm dou nregistrri. Definiie: Forma Normal Doi (2NF): O relaie este n forma normal doi, dac este n forma normal unu i fiecare atribut care nu aparine cheii primare, este total dependent funcional de cheia primar. Vom demonstra aducerea la forma normal doi, folosind relaia Furnizori_Cheltuieli evideniat n figura 2.5. Putem trece la forma normal doi prin tergerea atributelor care nu depind total de cheia primar i trecrea lor ntr-o alt tabel mpreun cu determinantul lor. Dup efectuarea acestor transformri, vom avea urmtoarela relaii:

Relatia Cheltuieli Cod Nr. Cod Furn. Crt. Chelt. F100 1 C15 F100 2 C16 F110 3 C10 F110 4 C11 Relaia Furnizori Cod Denumire Furn. F100 Romgaz F100 Romgaz F110 Renel F110 Renel

Valoare 1500000 500000 3000000 200000 Cod fiscal R1234567 R1234567 R7654321 R7654321 Relaia Tip Cheltuial Cod Denumire Chelt. Cheltuial C15 Chelt pt. nclzire C16 Chelt pt. buctrii C10 Chelt cu iluminatul C11 Chelt pt. func. liftului

Figura 2.7. Relaiile rezultate dup trecerea la 2NF a relaiei Furnizori_Cheltuieli. Relaiile rezultate au urmtoarea form:
Page: 26

Furnizori Tip cheltuial Cheltuieli

(Cod Furn., Denumire, Cod fiscal) (Cod Chelt., Denumire cheltuial) (Nr. Crt., Cod Furn., Cod Chelt., Valoare)

2.7. Forma Normal Trei (3NF) Forma normal doi chiar dac nu conine atta redundan ca forma normal unu, totui exist cazuri n care pot aprea anomalii la actualizare. Aceste anomalii apar din cauza redundanei generate de dependena tranzitiv. 2.7.1. Dependena tranzitiv Definiie: Dependen tranzitiv: Dac atributele A, B, C sunt n relaiile AB i BC, atunci spunem c atributul C este dependent tranzitiv de atributul A, via B. 2.7.2. Definiia Formei Normale Trei Definiie: Forma Normal Trei (3NF): O relaie care este n form normal doi i nu exist nici un atribut care s nu aparin cheii principale i care s fie tranzitiv dependent de cheia principal. n cazul existenei dependenei tranzitive, tergem coloanele care sunt tranzitiv dependente de cheia primar i crem o relaie nou cu aceste coloane, mpreun cu determinantul lor, adic cheia primar. Examinnd relaiile n forma normal de mai sus, observm c nu exist dependene tranzitive. Deci relaiile sunt n form normal trei. 2.8. Forma Normal Boyce-Codd (BCNF) Baza de date trebuie broiectat astfel nct s nu conin dependene pariale sau tranzitive, pentru c altfel ne putem confrunta cu anomaliile descrise n cap. 2.2. 2.8.1. Definiia Formei Normale Boyce-Codd Forma normal Boyce-Codd este bazat pe cheile candidat din relaie. O relaie cu o singur cheie candidat n form normal trei este i n form normal Boyce-Codd. Definiie: Forma normal Boyce-Codd (BCNF): O relaie este n forma normal Boyce-Codd dac i numai dac orice determinant din relaie este cheie candidat. S cutm determinanii din exemplul de mai sus: Cod Furn. Denumire, Cod fiscal
Page: 27

Cod Chelt. Denumire cheltuial Nr. Crt., Cod Furn., Cod Chelt. Valoare Toi cei trei determinani sunt i chei candidat. Deci exemplul de mai sus este n form normal Boyce-Codd. Relaiile n form normal trei sunt n general i n form normal Boyce-Codd. n cazul n care relaia nu este n form normal BoyceCodd, trecerea la BCNF se realizeaz prin tergerea din relaia iniial a atributelor care sunt asociate unui determinant care nu este cheie candidat i crearea unei noi relaii cu aceste atribute i determinantul lor. Exist situaii cnd este foarte greu de descompus atributele, ca s ajungem la BCNF. n aceste situaii este indicat rmnerea la forma normal trei.

2.9. S recapitulm procesul de normalizare (de la 1NF la BCNF) Forma Normal Unu (1NF) Trebuie s cutm toate interseciile de linii i coloane, unde exist repetiii. Aceste repetiii se pot elimina prin dou madaliti: Crearea a noi nregistrri pentru fiecare valoare a repetiiei, dup care se caut o nou cheie primar. tergerea atributelor care conin repetiii i crearea a unor noi relaii care vor conine atributele terse, precum i cheia principal din relaia iniial. Forma Normal Doi (2NF) Se caut dependenele pariale de cheia principal, adic toate atributele care depind funcional de un subset de atribute a cheii primare. Dac cheia primar este compus dintr-un singur atribut, atunci releia este n forma normal doi. Dac exist dependene pariale, vom terge atributele care depind parial de cheia principal i crem o relaie nou care s se compun din atributele terse mpreun cu determinantul lor. Forma Normal Trei (3NF) Pentru a trece la forma normal trei, trebuie s eliminm dependenele tranzitive. Eliminarea se realizeaz prin tergerea cmpurilor dependente tranzitiv de cheia primar din relaia iniial i crearea unei noi relaii cu aceste atribute i determinantul lor. Forma Normal Boyce-Codd (BCNF) Cerina la forma normal Boyce-Codd este ca fiecare determinant din relaie s fie cheie candidat. n cazul n care nu este ndeplinit aceast cerin, vom terge
Page: 28

atributele dependente funcional de determinantul care nu este cheie candidat i crem o nou relaie n care s avem atributele terse i determinantul lor. n unele cazuri trecerea la forma normal Boyce-Codd complic foarte mult baza de date, caz n care este de preferat rmnerea la forma normal trei.

Form nenormalizat (UNF) tergem grupurile care se repet Forma normal unu (1NF) tergem dependenele pariale Forma normal doi (2NF) tergem dependenele tranzitive Forma normal trei (3NF)

Page: 29

3. Metodologie - Proiectarea bazei de date

n acest capitol vom nva despre: Scopul metodologiei de proiectarea a bazelor de date. Proiectarea bazelor de date are dou faze mari: proiectarea logic i proiectarea fizic. Utilizatorii sistemului informatic au un rol important n proiectarea bazelor de date. Cum documentm procesul de proiectare a bazelor de date? Cum descompunem scopul proiectrii n vederi (view-uri) specifice utilizatorilor nrtreprinderii? Cum utilizm modelarea Entity-Relationship (ER), pentru a crea un model conceptual local, bazat pe informaiile adunate despre view-urile utilizatorilor? Cum proiectm un model local conceptual ntr-un model local logic de date? Cum crem relaiile pentru un model conceptual local? Cum validm modelul logic de date, utiliznd technica normalizrii? Cum compunem modelele logice locale de date, bazate pe view-urile specifice utilizatorilor, ntr-un model logic global de date al ntreprinderii? Cum ne asigurm c modelul global este o reprezentare adevrat i total a prii ntreprinderii pe care vrem s o modelm? Metodologia proiectrii bazei de date se compune din dou etape mari: proiectarea logic, n care proiectantul decide asupra structurii logice a bazei de date, i proiectarea fizic, n care proiectantul decide cum se va implementa structura logic 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 descris n capitolul 1, pentru proiectarea bazei de date; vom valida acest model prin normalizare, prezentat n capitolul 2; iar n final vom compune diferitele view-uri ntr-un model global al ntreprinderii. n acest capitol vom utiliza covintele entitate i relaie n locul expresiilor tip de entitate i tip de relaie. Unde aceast utilizare ar putea crea confuzii, vom specifica tip de entitate, respectiv tip de relaie. 3.1. Metodologia proiectrii bazelor de date 3.1.1. Ce este o metodologie de proiectare? Definiie: Metodologie de proiectare: O aproximare structurat, care utilizeaz proceduri, tehnici, instrumente i documentaii pentru a facilita procesul de proiectare. Metodologia de proiectare se compune din etape, care la rndul lor se compun din pai, care orienteaz proiectantul la fiecare nivel al crerii bazei de date.
Page: 30

3.1.2. Proiectarea logic i fizic a bazei de date Definiie: Proiectare logic: Procesul de construcie a unui model de informaii folosite ntr-o ntreprindere, bazat pe modelul de date, dar independent de particularizrile sistemului de gestiune a bazei de date i a altor considerente fizice. Proiectarea logic 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 influena mai trziu modelul de date n care se va implementa. Definiie: Proiectare fizic: Este procesul de descriere a implementrii bazei de date ntr-un SGBD. n aceast etap a proiectrii este creat baza de adte ntr-un SGBD, mpreun cu procedurile de actualizare. n aceast etap exist un feedback ntre proiectarea fizic i cea logic, pentru c deciziile luate la implementarea fizic pot afecta baza de date logice. 3.2. Prezentarea metodologiei n acest capitol vom prezenta o descriere a metodologiei de proiectare a bazelor de date. Prima dat s vedem care sunt paii de urmat n proiectare: Pasul 1. Proiectarea logic a bazei de date relaionale: Crearea unui model conceptual local, pentru vederile utilizatorilor. Pasul 1.1. Identificarea tipurilor de entiti. Pasul 1.2. Identificarea tipurilor de relaii. Pasul 1.3. Identificarea i atribuirea de atribute la tipurile de entiti i tipurile de relaii. Pasul 1.4. Determinarea domeniilor de definiie a atributelor. Pasul 1.5. Determinarea atributelor care compun cheile candidate i primare. Pasul 1.6. Specializare/generalizare (pas opional). Pasul 1.7. Desenarea diagramei entity-relationship. Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului. Pasul 2. Crearea i validarea modelului logic local. Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local. Pasul 2.2. Crearea relaiilor pentru modelul logic local. Pasul 2.3. Validarea modelului, utiliznd normalizarea. Pasul 2.4. Validarea modelului din nou, utiliznd tranzaciile. Pasul 2.5. Desenarea diagramei ER. Pasul 2.6. Definirea regulilor de integritate a bazei de date. Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului. Pasul 3. Crearea i validarea modelului logic global de date. Pasul 3.1. Compunerea medelelor logice locale ntr-un model logic global. Pasul 3.2. Validarea modelului logic global. Pasul 3.3. Verificarea posibilitii de a completa baza de date n viitor.
Page: 31

Pasul 3.4. Desenarea diagramei ER finale. Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului. Pasul 4. Proiectarea fizic i implementarea bazei de date relaionale: Translatarea modelului logic global n SGBD. Pasul 4.1. Proiectarea relaiilor de baz n SGBD. Pasul 4.2. Crearea regulilor de integritate n SGBD. Pasul 5. Proiectarea i implementarea reprezentrii fizice. Pasul 5.1. Analizarea tranzaciilor. Pasul 5.2. Alegerea organozrii fiierelor. Pasul 5.3. Alegerea indexilor secundari. Pasul 5.4. Introducerea unei redundane comntrolate. Pasul 5.5. Estimarea spaiului pe disc. Pasul 6. Proiectarea i implementarea unui mechanism de securitate. Pasul 6.1. Crearea view-urilor pentru utilizatori. Pasul 6.2. Proiectarea regulilor de acces la baza de date. Pasul 7. Verificarea sistemului operaional. Proiectarea logic a bazei de date se divide n trei pai mari. Primul pas are ca obiectiv, descompunerea proiectrii sistemului informatic n vederi, care se pot discuta cu utilizatorii sistemului. Modelul de date astfel creat, se valideaz prin normalizare i prin tranzacii n pasul doi. n final, se genereaz modelul global al ntreprinderii, cars este la rndul lui validat i verificat cu ajutorul utilizatorului sistemului. Factori critici pentru succesul proiectrii 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 validrii conceptuale, prin normalizare i prin tranzactii, la proiectarea modelului logic de baze de date. Utilizarea diagramelor pentru a reprezenta ct mai multe modele logice posibile. Crearea dicionarului de date, ca supliment al modelului de date. 3.3. Metodologia de proiectare a bazei de date logice 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.
Page: 32

Primul pas n proiectarea bazei de date este de a colecta datele necesare pentru realizarea sistemului, ceea ce putem culege, discutnd cu viitorii tilizatori ai bazei de date. Acrast discuie presupune o desprire n vederi, a bazei de date, vederi care pot luca separat. Desprirea n vederi se poate realiza n mai multe moduri. O modaliate ar fi analiza datelor globale i gsirea de pri relativ independente. O alt modalitate ar fii analiza rapoartelor, procedurilor cerute i/sau observarea sistemului ixistent n lucru. Modelele conceptuale locale trebuie s conin: tipuri de entiti, tipuri de relaii, atribute, domeniile atributelor, cheile candidat, chei primare Paii din prima etap a proiectrii logice sunt: Pasul 1.1. Identificarea tipurilor de entiti. Pasul 1.2. Identificarea tipurilor de relaii. Pasul 1.3. Identificarea i atribuirea de atribute la tipurile de entiti i tipurile de relaii. Pasul 1.4. Determinarea domeniilor de definiie a atributelor. Pasul 1.5. Determinarea atributelor care compun cheile candidate i primare. Pasul 1.6. Specializare/generalizare (pas opional). Pasul 1.7. Desenarea diagramei entity-relationship. Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului. Pasul 1.1. Identificarea tipurilor de entiti Obiectivul: Identificarea tipurilor de entiti principale n vederile utilizatorilor. Primul pas n proiectarea bazei de date este identificarea entitiilor din datele furnizate de utilizatori. De exemplu, dac avem informaiile Nr_Mat, Nr_Bloc, Scara, Etaj, Apartament i Nume, putem identifica entitatea Locatari. n general putem identifica entitiile n mai multe moduri. De exemplu n locul entitii Locatari, am putea crea o entitate Locatari cu atributele Nr_Mat i Nume, iar celelelte informaii n entitatea ProprietateLocatari. Exist cazuri cnd entitiile sunt greu de identificat, pentru c modul de prezentare a viitorilor utilizatori necesit explicaii. Utilizatorii descriu aceste entiti, folosind sinonime i omonime, ceea ce ngreuneaz identificarea entitilor. Sinonimele prin care se descrie aceai entitate, se pot considera sinonime i la crearea modelului logic, evideniind aceste sinonime ca diverse aliasuri ai entitiilor. Documentarea tipurilor de entiti Dup identificarea entitiilor, le dm cte un nume, iar aceste nume le vom
Page: 33

evidenia n dicionarul de date, mpreun cu explicaiile despre entiti, precum i posibilele aliasuri. Pasul 1.2. Identificarea tipurilor de relaii Obiectivul: Identificarea relaiilor importante dintre entiti. Dup identificarea entitiilor, va trebui s identificm i relaiile importante dintre aceste entiti. Releiile se descriu printr-un verb al relaiei. De exemplu: Scrile sunt Locuite de Locatari Furnizorii Provoac Cheltuieli La identificarea relaiilor vom lua n considerare doar relaiile care ne intereseaz. Degeaba exist i alte relaii care s se poat identificate, dac nu prezint importan pentru problema noastr, atunci nu le lum n consideraie. n cele mai multe din cazuri, relaiile sunt binare, adic se realizeaz ntrea exact dou entiti. Exist i relaii mai complexe, care se realizeaz ntre mai multe entiti, sau relaii recursive, care pune n relaie o singur entitate cu ea nsi. Determinarea cardinalitii i a participrii la tipurile de relaii Dup identificarea tipurilor de relaii, trebuie s determinm cardinalitatea lor, alegnd dintre posibilitiile: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Dac se cunosc valori specifice ale cardinalitiilor, aceste valori se scriu la documentarea relaiilor. n continuare determinm i participarea la relaie, care poate fii total, sau parial. Documentarea tipurilor de relaii Dup identificarea tipurilor de relaii, le denumim i le introducem n dicionarul de date, mpreun cu cardinalitatea i participarea lor. Utilizarea modelrii ER Pentru vizualizarea sistemelor complicate, utilizm diagrama ER, pentru c este mult mai uor de a cuprinde toate informaiile. V propunem ca s utilizai ntotdeauna diagrama ER, pentru o mai bun vizualizare a datelor. Pasul 1.3. Identificarea i asocierea de atribute la tipurile de entiti i tipurile de relaii Obiectivul: Asocierea de atribute la tipurile de entiti i la tipurile de relaii. Urmtorul pas n metodologie este identificarea atributelor. Aceste atribute se identific n aceeai mod ca i entitiile. Pentru o mai uoar identificare, trebuie s lum entitiile i relaiile ra rnd i s ne punem urmtoarea ntrebare: Ce informaii deinem despre aceast ? Rspunsul la aceast ntrebare ne va da atributele cutate. Atribute simple sau compuse Este important s notm dac un atribut este simplu sau compus. Conform acestei informaii va trebui s lum decizii referitoare la acel atribut. Dac un atribut este compus, atunci putem opta pentru descompunerea sa, dac este necesar prelucrarea separat a detelor compuse, sau putem s-l lsm compus n caz contrar.
Page: 34

De exemplu, atributul Adres conine informaiile (Nr_Bloc, Scara, Etaj, Apartament). Noi va trebui s prelucrm aceste informaii separat, deci vom descompune acest atribut n cele patru atribute simple. Putem avea cazuri n care atributele simple s le compunem. De exemplu n cazul atributelor Nume_Familie i Prenume, neavnd nevoie de aceste informaii 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 numrul locatarilor de pe o scar se poate numra n tipul de entitate Locatari. Deci acest atribut este atribut derivat. n general aceste atribute nu trebuie incluse n modelul de date, pentru c n cazul n care se modific atributul din care se calculeaz atributul derivat, trebuie s se modifice i acesta. n cazul n care nu se modific, baza de date devine inconsistent. De aceea este important de a meniona dac un atribut este sau nu derivat. Dac identificm un atribut care s nu-l putem asocia nici unei entiti sau relaii, ne ntoarcem la paii anteriori, identificnd noua relaie sau entitate la care s asociem atributul respectiv. n cazul n care putem asocia acelai atribut la mai multe entiti, atunci va trebui s decidem dac generalizm sau nu aceste entiti, proces care este descris la pasul 1.6. Documentarea atributelor Dup identificarea atributelor, le asociem un nume, i le nregistrm n dicionarul de date, mpreun cu urmtoarele informaii: numele i descrierea atributului, toate aliasurile i sinonimele prin care este cunorcut atributul, tipul de date i lungimea, valorile iniiale ale atributelor (dac exist), dac atributul accept sau nu valoarea nul, dac atributul este sau nu compus, i dac este atunci atributele simple care le compun, dac atributul este sau nu derivat i atributul din care se deriv, dac atributul accept sau nu mai multe valori. Pasul 1.4. Determinarea domeniului atributelor Obiectivul: Determinarea domeniului atributelor n modelul conceptual local. Domeniul atributului este o mulime de valori pe care o poate lua. Pentru a controla n totalitate domeniul atributelor, se poate evidenia urmtoarele: setul de valori admisibile pentru un atribut, operaiile admisibile asupra unui atribut, ce atribute se pot compara cu atributul respectiv, n combinaiile cu alte atribute, mrimea i formatul cmpului atributului. Documentarea domeniilor atributelor Actualizm dicionarul de date cu domeniul de definiie a fiecrui atribut.
Page: 35

Pasul 1.5. Determinarea atributelor care compun cheile candidat i primare Obiectivul: Identificarea cheilor candidat pentru fiecare entitate i alegerea cheilor primare n cazul n care sunt mai multe chei candidat. Identificarea cheilor i selectarea cheilor primare O cheie candidat este un atribut, sau un grup de atribute care identific unic fiecare nregistrare din tipul de entitate. Putem identifica una, sau mai multe chei candidat. n acest caz trebuie s alegem dintre ele o cheie primar. Cheile candidat care nu sunt primare, se vor numii chei alternante. Pentru alegerea unei chei ca fiind cheie primar, vom ine cont de urmtoarele: cheia candidat, care are un numr minimal de atribute, cheia candidat, care i va schimba cel mai rar valoarea, cheia candidat, care este cel mai puin probabil s sufere modificri n viitor, cheia candidat, care este compus din cele mai puine caractere (n cazul atributelor de tip caracter), cheia candidat, care este cel mai uor de folosit din punctul de vedere al utilizatorului. Prin procesul de identificare a cheilor primare, deducem i dac o entitate este entitate tare, sau entitate slab. Dac reuim s identificm o cheie primar, atunci entitatea este tare, altfel este slab. O entitate slab nu poate exista fr o entitate tare, care s-i fie printe. Cheia primar a entitii slabe este derivat parial sau total din cheia primar a entitii tari. Documentarea cheilor primare i alternante nscriem cheile primare i pe cele alternante n dicionarul de date. Pasul 1.6. Specializarea/generalizarea tipuriloe de entiti (pas opional) Obiectivul: Identificarea entitiilor subclas respectiv superclas, ntre entitiile apropiate. n acest pas putem opta pentru a continua modelarea ER, folosind procesul de generalizare sau specializare. Dac alegem procesul de specializare, vom ncerca s definim unul, sau mai multe subclase ai entitii respective. Dac ns alegem procesul de generalizare, vom cuta superclase pentru acea entitate. Un exemplu pentru procesul de generalizare ar fii entitiile ef_de_scar i Familii. Ambele entiti au atribuite urmtoarele atribute: Nr_mat, Nr_bloc, Scara, Etaj, Apartament i Nume. Pe lng aceste atribute, entitatea ef_de_scar mai are asociate atributul Data_intrare_func; iar entitatea Familii, atributele Nr_pers, Nr_pers_prezente i Nr_chei. Deci, cele dou entiti avnd atribute n comun, le putem generaliza n entitatea Locatari, care va conine atrubutele comune, i entitile ef_de_scar i Familii, coninnd doar atributele diferite - particularizrile fa de superclas.
Page: 36

Pasul 1.7. Desenarea diagramei ER. Obiectivul: Desenarea unei diagrame ER. care va fi reprezentarea conceptual a vederilor utilizatorilor despre ntreprindere. n momentul acesta suntem n msur s prezentm o giagram complet 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 dac modelul este o reprezentare adevrat a vederii utilizatorului despre ntreprindere. nainte de a termina pasul 1, trebuie verificat modelul conceptual elaborat. Acest model include diagrama ER i documentaia anexat. n cazul n care apare orice fel de anomalie, repetm procesul de mai nainte i remediem problema. Pasul 2. Crearea i validarea modelului logic local Obiectivul: Crearea unui model logic local bazat pe modelul conceptual al utilizatorilor asupra ntreprinderii i validarea ei prin procesul de normalizare i prin tehnica tranzaciilor cerute. n acest pas verificm modelul conceptual creat n pasul anterior i eliminm din el structurile care sunt dificil de realizat ntr-un SGBD. Dac la sfritul acestui proces modelul alterat, vom corecta aceste probleme i ne vom referii n continuare la modelul rezultat, ca fiind modelul logic local. Vom valida modelul logic prin procesul de normalizare i a tranzaciilor. Activitile din acest pas sunt: Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local. Pasul 2.2. Crearea relaiilor pentru modelul logic local. Pasul 2.3. Validarea modelului, utiliznd normalizarea. Pasul 2.4. Validarea modelului din nou, utiliznd tranzaciile. Pasul 2.5. Desenarea diagramei ER. Pasul 2.6. Definirea regulilor de integritate a 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 i proiectarea modelului rezultat la modelul logic local. n pasul nti am pregtit un model conceptual bazat pe informaiile date de utilizator. Acest model trebuie prelucrat, pentru a putea fi uor de prelucrat de sistemul de gestiune a bazelor de date. Obiectivele acestui pas sunt: (1) Eliminarea relaiilor M:N.
Page: 37

(2) Eliminarea relaiilor complexe. (3) Eliminarea relaiilor recursive. (4) Eliminarea relaiilor cu atribute. (5) Reexaminarea relaiilor 1:1. (6) Eliminarea relaiilor redundante. (1) Eliminarea relaiilor multe-la-multe Dac n modelul de date apar relaii de tipul multe-la-multe (M:N), trebuie descompuse n dou relaii unu-la-multe (1:M) prin adugarea unei noi entiti suplimentare. De exemplu, pot exista mai multe cheltuieli pentru o scar, dar i o cheltuial (factur) poate s se refere la mai multe scri. Deci relaia dintre entitatea Scri i entitatea Cheltuieli este de M:N, ceea de este evideniat n figura 3.1.(a).
Scari Nr_Bloc Scara Lift Cheltuieli Nr_Crt Cod_Cheltuiala (FK) Cod_Furnizor (FK) Nr_factura Data_factura Valoare_factura Sunt platite de
Scari Nr_Bloc Scara Lift Pe scari Scara (FK) Nr_Crt (FK) Nr_Bloc (FK) Cheltuieli Nr_Crt Cod_Furnizor (FK) Cod_cheltuiala Nr_factura Data_factura Valoare_factura

Au cheltuieli

Se calculeaza

Figura 3.1. (a). Relaie de tipul N:M. (b). Relaie transfornamt n dou relaii 1:M. Aceast relaie se poate elimina, prin crearea unui tip de entitate suplimantar, care s fac legtura dintre scri i cheltuieli. Diagrama acestor relaii se vede n figura 3.1.(b). Notm, c tipul de entitate nou creat - Pe_scri - este tip de entitate slab, pentru c depinde att de tipul de entitate Scri, ct i de tipul de entitate Cheltuieli. (2) Eliminarea relaiilor complexe O relaie complex este o relaie ntre mai mult de cou tipuri de entiti. Dac n modelul conceptual apar relaii complexe, acestea trebuie eliminate. Se pot elimina prin crearea unui nou tip de entitate, care s fie n relaie de tipul 1:M cu fiecare tip de entitate din relatia iniial, partea cu M a relaiei fiind spre tipul de entitate nou creat. (3) Eliminarea relaiilor recursive Relaiile recursive sunt nite relaii particulare, prin care un tip de entitate este n relaie cu el nsi. Dac apare o astfel de relaie n modelul conceptual, ea trebuie eliminat. Eliminarea se poate rezolva prin crearea unei noi entiti unde s se evidenieze fiecare entitate care este legat de entitatea din tipul de entitate iniial. n acest caz vom avea o relaie de tipul 1:M ntre tipul de entitate iniial i tipul de entitate nou creat i o relaie de tipul 1:1 ntre tipul de entitate nou creat i tipul de entitate iniial. (4) Eliminarea relaiilor cu atribute
Page: 38

Dac n modelul conceptual avem relaii cu atribute, putem descompune aceast relaie, identificnd un nou tip de entitate n care s nregistrm atributele necesare. (5) Reexaminarea relaiilor de tipul 1:1 n modelul conceptual putem avea entiti ntre care s avem relaie de tipul 1:1. Se poate ntmpla ca aceste entiti s fie de fapt aceeai entitate cu nume diferite. Dac suntem n acest caz, unim cele dou entiti, cheia primar devenind cheia primar al uneia dintre entiti. (6) Eliminarea relaiilor redundante O relaie este redundant dac se poate ajunge de la un tip de entitate la alt tip de entitate pe mai multe drumuri. V amintim c noi vrem s ajungem la un model minimal i deci relaiile redundante nu sunt necesare. Decizia ca o relaie este redundant trebuie s fie precedat de o analiz amnunit a releiilor care compun cele dou drumuri dintre cele dou entiti, pentru c pot aprea situaii, cnd o relaie este aparent redundant, dar n realitate este nevoie de ea. n finalul acestui pas putem spune c am eliminat din modelul conceptual acele structuri care sunt dificil de implementat i deci este mai corect ca n continuare s ne referim la acest model ca fiind un model logic local de date. Pasul 2.2. Crearea de relaii peste modelul logic local Obiectivul: Crearea de relaii peste modelul logic. Relaia pe care un tip de entitate o are cu alt tip de entitate este reprezentat prin mechanismul cheie primar/cheie strin. Cheia strin pentru o entitate este reproducerea cheii primare altei entiti. Pentru a decide entitiile unde vom include copia cheii primare a altei entiti, trebuie nainte s identificm entitile printe i fiu. Entitile printe se refer la acele entiti ale cror chei primare se vor copia n entitile fiu. Pentru descrierea relaiilor vom folosii un limbaj de definire a bazei de date (Database Definition Language - DBDL). n acest limbaj, specificm prima dat numele entitii, urmat de atributele asociate ntre paranteze. Dup aceea identificm cheia primar i toate cheile alternante, precum i/sau cheile strine. Tipuri de entitate tari Pentru tipurile de entiti tari n modelul logic crearea unei relaii enclude toate atributele entitii. Pentru atributele compuse al unei entiti, vom include numai atributele simple din compunerea atricutului compus n descrierea entitii. De exemplu tipul de entitate Familii, prezentat n figura 3.2. se descrie n urmtorul mod. Familii (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers, Nr_pers_prezente, Nr_chei) Cheie primar: Nr_mat

Page: 39

Familii Nr_Mat Nr_pers Nr_pers_prezente Nr_chei Nr_Bloc Scara Etaj Apartament Fond_rulment Fond_reparatii Alte_fonduri Plati Data Nr_Mat (FK) Valoare Restanta

Trebuie sa plateasca

Figura 3.2. Exemplu de model logic.

Tipurile de entiti slabe Descrierea tipurilor de entiti slabe se face la fel ca i tipurile de entiti tari, cu o completare i anume, evidenierea cheii strine. De exemplu descrierea tipului de entitate de mai sus se descrie astfel: Pli (Data, Nr_mat, Valoare, Restan) Cheie primar: Data, Nr_mat Cheie strin: Nr_mat se refer la Familii(Nr_mat) Menionm c n cazul acesta cheia strin este i n compunerea chei primare. Deci nainte de introducerea cheii strine, cheia primar nu identifica unic o entitate. La terminarea acestui pas, putem identifica cheile prinare pentru toate tipurile de entiti din modelul logic. Tipurile de relaii binare de tipul unu-la-unu (1:1) Pentru fiecare tip de relaie binar de tipul 1:1 ntre dou tipuri de entitate E1 i E2 gsim o copie a cheii primare a tipului de entitate E1 n compunerea tipului de entitate E2, sub denumirea de cheie strin. Identificarea tipului de entitate printe i a tipului de entitate fiu depinde de participarea entitilor la relaie. Tipul de entitate care particip parial la relaie este desemnat ca fiind printe iar cel cu participare total fiu. Dac ambele tipuri de entitate particip parial sau total la relaie, atunci tipurile de entiti se pot evidenia ca fiind printe sau fiu arbitrar. n cazul n care participarea este total, putem ncerca s combinm cele dou tipuri de entiti ntr-una singur. Aceast compunere poate s fie posibil n cazul n care nici unul dintre cele dou tipuri de entiti nu mai ia parte la alt relaie. Tipurile de relaii binare de tipul unu-la-multe 1:M Pentru toate relaiile 1:M ntre dou entiti E1 i E2 n modelul logic de date, vom avea copia cheii primare a entitii E1 n compunerea entitii E2. Totdeauna entitatea de partea unu a relaiei este considerat entitate printe, iar cealalt entitate fiu.
Page: 40

Atributele cu mai multe valori Pentru ficarea atribut A care permite mai multe valori din entitatea E1 n modelul logic de date, crem o nou relaie care va conine atributul A mpreun cu cheia primar a entitii E1 pe post de cheie strin. Cheia primar a noii relaii va fi atributul A, sau dac este necesar, compunerea ei cu cheia primar al lui E1. Relaiile superclas/subclas Pentru fiecare relaie superclas/subclas vom identifica superclasa ca fiind entitatea printe, iar subclasa entitatea fiu. Exist multe moduri de a reprezenta relaia aceasta. De exemplu s lum relaia prezentat n figura 3.3. (Opiunea 1) Locatari (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Data_intrare_func, Nr_pers, Nr_pers_prez, Nr_chei) Cheie primar: Nr_mat (Opiunea 2) Familii (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers, Nr_pers_prez, Nr_chei) Cheie primar: Nr_mat ef_de_scar (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Data_intrare_func) Cheie primar: Nr_mat (Opiunea 3) Locatari (Nr_mat, Nr_bloc, Scara, Apartament, Nume) Cheie primar: Nr_mat ef_de_scar (Nr_mat, Data_intrare_func) Cheie primar: Nr_mat Cheie strin : Nr_mat referire la Locatari(Nr_mat) Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei) Cheie primar: Nr_mat Cheie strin : Nr_mat referire la Locatari(Nr_mat)

Page: 41

L ca ri o ta Nr_ t Ma Nr_ lo (FK B c ) S ra (FK ca ) E j ta A a mn p rta e t Nu e m

S f d sca e e ra Nr_ t Ma (FK ) Da _ tra _ n ta in re fu c

Ca fa ilie p m Nr_ t Ma (FK ) Nr_ e p rs Nr_ e p ze t p rs_ re n e r_ e N ch i Fo d ru e t n _ lm n Fo d re a tii n _ p ra A _ nu lte fo d ri

Figura 3.3. Exemplu de relatie superclas/subclas Documentarea relaiilor i a atributelor din cheile strine Actualizm dicionarul de date, ntroducnd fiacare atribut nou introdus n compunerea unei chei la acest pas. Pasul 2.3. Validarea, utiliznd normalizarea Obiectivul: Validarea modelului logic, utiliznd tehnica normalizrii. Examinm procesul de normalizare dup cum am descris n capitolul 2. Prin normalizare trebuie s demonstrm c modelul creat este consistent, conine redundan minimal i are atabilitate maxim. Normalizarea este procesul prin care se decide dac atributele pot sau nu s rmn npreun. Conceptul de baz a teoriei relaiilor este c atributele sunt grupate mpreun pentru c exist o relaie logic ntre ele. Cteodat baza de date nu este cea mai eficient. Acesta se argumenteaz prin urmtoarele: Proiectarea normalizat organizeaz datele n funcie de dependenele funcionale. Deci acest proces este situat undeva ntre proiectarea conceptual i cea fizic. Proiectul logic nu este un proiect final. El ajut priectantul s neleag natura datelor n ntreprindere. Proiectul fizic poate fi diferit. Exist posibilitatea ca unele tipuri de entiti s se denormalizeze. Totui normalizarea nu este un timp pierdut. Proiectul normalizat este robust i independent de anomaliile de actualizare prezentate n capitolul 2. Calculatoarele moderne au mult mai mult putere de calcul, ca cele de acum civa ani. Din aceast cauz, cteodat este mai convenabil implementarea unei baze de date cu puin redundan, dect suportarea cheltuielilor pentru procedurile adiionale. Normalizarea produce o baz de date care va fi uor extensibil n viitor.
Page: 42

Procesul de normalizare include urmtoarele etape mari: Forma Normal Unu (1NF), eliminarea grupurilor repetitive; Forma Normal Doi (2NF), eliminarea dependenelor pariale de cheia primar; Forma Normal Trei (3NF), eliminarea dependenelor tranzitive de cheia primar; Forma Normal Boyce-Codd (BCNF), eliminarea anomaliilor care au mai rmas. Pasul 2.4. Validarea modelului prin tranzacii

Obiectivul: Verificarea ca modelul de date suporte toate tranzaciile cerute de utilizator. n acest pas se valideaz baza de date prin verificarea tranzaciilor ce se cer de utilizator. Lund n considerare tipurile de entiti, relaiile, cheile primare i strine, ncercm s rezolvm manual cerinele utilizatorilor. Dac reuim s rezolvm fiecare tranzacie cerut, atuci nseamn c modelul creat este valid. Dac nu putem rezolva o tranzacie, atunci este foarte posibil s fi omis un atribut, o relaie, sau o entitate din modelul de date. Trebuie s examinm n dou posibiliti, dac baza de date suport tranzaciile cerute. Una dintre ele ar fi prin rezolvarea de tranzacii. De exemplu s lum relaia dintre Furnizori i Cheltuieli exemplificat n figura 3.4.
Cheltuieli Nr_Crt Cod_Furnizor (FK) Cod_cheltuiala Nr_factura Data_factura Valoare_factura Furnizori Cod_Furnizor Denumire Cod_fiscal (AK1) Cont Banca Strada Nr Bl Sc Ap Localitate Judet

Provoaca

Figura 3.4. Exemplu de relaie pentru validarea prin tranzacii.

Inserarea de detalii despre un nou furnizor. Cheia primar al acestei entiti este Nr_furnizor. Deci prima dat verific dac numrul introdus nu exist deja; dup care n caz c nu exist acest cod, inserez detaliile despre furnizor. Dac exist deja codul, nu admit inserarea. Pot verifica i existena codului fiscal, care pentru aceast entitate este cheie alternant. tergerea detaliilor despre un furnizor Se caut codul furnizorului de ters. Dac exist se terge furnizorul, actualizndu-se i cheia strin n entitatea Cheltuieli. Dac nu exist codul cerut, atunci apare un mesaj de eroare i nu este ters nici un furnizor. A doua modalitate de verificare trebuie folosit n cazul n care avem entiti
Page: 43

care nu iau parte direct la nici o tranzacie. Pentru verificarea acestor entiti, vom verifica nite interogri pergtie special. Pasul 2.5. Desenarea diagramei ER. Obiectivul: Desenarea diagramei Entity-Relationship, care este reprezentarea logic 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 inconsistene. Dac este necesar, putem produce un proiect fizic de baz de date, pentru a putea vedea mai uor ce reguli sunt necesare. Vom considera cinci tipuri de reguli de intagritate: necesitatea datelor, reguli asupra domeniului atributelor, integritatea entitilor, integritatea referinelor, regulile ntreprinderii. Necesitatea datelor Exist atribute care nu pot conine valoarea nul, ci trebuie s aib totdeauna o valoare. De exemplu fiecare cheltuial nregistrat trebuie s aib asociat un furnizor al serviciilor sau al obiactelor ce se pltesc prin acea cheltuial. Aceste reguli deja le-am identificat, cnd am documentat atributele n pasul 1.3. Reguli asupra domeniului atributelor. Unele atribute au un domeniu de definiie bine definit. Aceste domenii trebuie respectate. Domeniile de definiie au fost deja identificate cnd am documentat domeniile atributelor n pasul 1.4. Integritatea entitilor. Cheia primar a entitilor nu poate lua valori nule. De exemplu fiacare furnizor trebuie s aib un cod diferit de zero. Aceste reguli au fost deja identificate, cnd am documentat cheile primare n pasul 1.5. Intagritatea referinelor Cheia strina din tipul de entitate fiu face ligtura cu o entitate din tipul de entitate printe. Deci, dac cheia strin conine o valoare, ea trebuie neaprat s se regseasc i n tipul de entitate printe. De exemplu tipul de entitate Cheltuieli
Page: 44

conine cheia strin Cod_furnizor, care se refer la Furnizori(Cod_furnizor). Dac aceast cheie nu este nul, atunci trebuie s gsim un furnizor care s aib acel cod. Prima ntrebare pe care trebuie s ne-o ponem este: Poate fii cheia strin nul? n cazul exemplului nostru asta ar nsemna c exist cheltuieli care nu se prtesc nimnui. Aceste cazuri nu sunt admise de lege, deci nu putem avea valoare nul n cheia strin din tipul de entitate Cheltuieli. n general dac pariciparea tipului de entitate fiu este total, atunci nu putem avea valoare nul n cheia strin. n caz contrar putem avea valoare nul. Pentru a demonstra diferitele cazuri la definirea acestor reguli, folosim relaia de mai sus dintre Furnizori i Cheltuieli, care este de tipul 1:M. Considerm urmtoarele cazuri: Cazul 1: Inserarea unei entiti n tipul de entitate fiu (Cheltuieli): Pentru a verifica integritatea referinei, varificm dac atributele din componena cheii strine (Cod_furnizor) sunt vide, sau s existe entitate n tipul de entitate printe care s aib valoare cheii primare egal cu valoare cheii strine. Cazul 2: tergerea unei entiti din tipul de entitate fiu (Cheltuieli): tergerea unei entiti din tipul de entitate fiu nu cauzeaz problame cu privin la integritatea referinelor. Cazul 3: Actualizarea cheii strine n tipul de entitate fiu (Cheltuieli): Acest caz este similar cazului 1. Cazul 4: Stergerea unei entiti din tipul de entitate printe (Furnizori): Dac se terge o entitate din tipul de entitate printe, integritatea referinelor se stric n cazul n care exist entiti n tipul de entitate fiu, care se refer la entitatea tears. Exist strategii severe de a rezolva integritatea referinelor: FR ACIUNE Neacceptarea tergerii unei entiti din tipul de entitate printe, dac acesta este referit de o entitate din tipul de entitate fiu. n cazul nostru, nu se accept tergerea furnizorului, dac el are o factur de ncasat. CASCAD Dac o entitate din tipul de entitate printe este tears, se terg automat toate entitiile din tipurile de entiti fiu. Dac tipurile de entiti fiu au i ei la rndul lor alte tipuri de entiti fiu, se va efectua tergerea n cascad n toate tipurile de entiti fiu, pn la ultimul nivel. Cu alte cuvinte, dac se terge un furnizor, atunci automat se terge fiacare factur pe carea are de ncasat acest furnizor. SETARE LA NUL Dac o entitate din tipul de entitate printe se terge, atunci se vor seta la valoare nul toate cheile strine ai tipurilor de entiti fiu n cascad pn la ultimul nivel. n exemplul nortru, dac se terge un furnizor, atunci se vor seta la valoare nul toate referinele la acest furnizor n tipul de entitate Cheltuieli. Acesta nseamn c nu vom tii ca anumite cheltuieli la ce furnizor trebuie pltite. SETARE IMPLICIT Este analog cazului de setare la nul, cu diferena c aici se seteaz cheia strin la o valoare implicit n loc de valoare nul. n exemplul nostru putem seta cheia strin din Cheltuieli la o valoare a cheii primare din Furnizori, care s conin un furnizor predefinit - de exemplu cu numele de Furnizor ters. FR MODIFICARE n cazul tergerii unei entiti din tipul de antitate printe,
Page: 45

nu se actualizeaz deloc cheile strine din tipurile de entiti fiu. Cazul 6: Modificarea cheii primare n tipul de entitate printe (Furnizori): Dac se modific cheia primar din tipul de entitate printe, integritatea referinelor se stric. Pentru meninerea integritii, se pot folosii toate cazurile descrise mai sus, dar cel mai indicat este folosirea cazului CASCAD. Regulile ntreprinderii. n final evideniem 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 dicionarul de date. Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului. Obiectivul: Convingerea c modelul creat reprezint n totalitate realitatea care trebuie modelat n baza de date. La acest pas modelul local logic este clomplet i este bine documentat. nainte de a trece la pasul 3, trebuie verificat modelul, s fie conform cu realitatea. n cazul n care se gsesc diferene, ne vom rentoarce la paii anteriori i modificm cele necasare. Pasul 3. Crearea i validarea modelului global logic de date. Obiectivul: Combinarea modelelor locale logice ntr-un model logic glaobal care s reprezinte ntreprinderea care este modelat. A treia activitate major n proiectarea bazei de date logice este crearea modelului logic global, prin compunerea tuturor modelelor locale. Dup combinarea modelelor locale, trebuie validat modelul global prin tehnica de enormalizare, dup care prin tehnica tranzaciilor. Acest proces utilizeaz aceleai tehnici pe care le-am descris la paii 2.3. i 2.4. Acest proces este foarte important n proiectarea bazei de date, pentru c el demonstreaz c reprezentarea ntreprinderii este independent de orice utilizator, funcie sau aplicaie. Activitile 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 posibilitii de a completa baza de date n viitor. Pasul 3.4. 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.
Page: 46

n cazul unui sistem mic, cu puine vederi ai utilizatorilor, este relativ uor de a compune modelele logice locale. n cazul unui sistem mai mare ns, trebuie s urmm un proces sistematic de realizare a modelului global. Paii acestui proces sunt urmtoarele: (1) Verificarea numelor entitilor i a cheilor lor primare. (2) Verificarea numelor relaiilor. (3) Compunerea entitilor de pe view-urile locale. (4) Includerea (fr compunere) a entitilor care apar pe doar una dintre view-uri. (5) Compunerea relaiilor de pe view-urile locale. (6) Includerea (fr compunere) a relailor care apar pe doar una dintre view-uri. (7) Cutarea entitilor i a relailor care lipsesc (dac exist). (8) Cutarea cheilor strine. (9) Cutarea regulilor de integritate. (10) Desenarea modelului logic global. (11) Actualizarea documentaiei. Cel mai uor de compus mai multe modele locale este compunerea succesiv a dou cte dou dintre modele. (1) Verificarea numelor entitilor i a cheilor lor primare. Aceast verificare se face folosind i dicionarul creat n decursul pailor de dinainte. Probleme apar doar atunci cnd: Dou entiti au acelai nume, dar sunt de fapt diferii. Dou entiti sunt aceleai, dar nu au aceleai nume. Probabil va fi necesar analizarea atributelor antitilor, prntru a rezola aceast problem. n particular, putem utiliza cheia primar i numele entitii, pentru a identifica entitile echivalente. (2) Verificarea numelor relaiilor. Aceast activitate este asemntoare celui descris la entiti. (3) Compunerea entitilor de pe view-urile locale. Examinm numele i atributele entitilor ca vor fi compuse. Activitile care se includ n acest pas sunt: Compunerea entitilor cau au aceleai nume i aceleai chei primare. Compunerea entitilor care au aceleai nume, dar cu chei primare diferite. Compunerea entitilor care au nume diferite, cu chei primare egale sau diferite. Compunerea entitilor care au aceleai nume i aceleai chei primare. n general entitile cu aceleai chei primare reprezint lumea real, i deci pot fi compuse. Atributele care apar n entitile de pe ambele view-uri, vor fi trecute doar o singur dat. Dac ntr-un view apre un atribut compus, iar ntr-un alt view acelai atribut dar descompus n atribute simple, atunci vom ntreba, dac se poate, utilizatorii pentru a decide asupra formei de utilizare a atributului. Compunerea entitilor care au aceleai nume, dar au chei primare diferite. n astfel de situaii, cutm dou entitpi care au aceleai nume i nu au aceleai chei primare, dar au aceleai chei candidat. Cele dou entiti pot fi compuse, urmnd ca dup compunere s alegem o cheie primar, restul rmnnd chei alternante.
Page: 47

Compunerea entitilor care nu au nume comune i nu au aceleai chei primare. Aceste entiti se pot depista prin analiza atributelor celor dou entiti. (4) Includerea (fr compunere) a entitilor care apar doar ntr-un view. Pasul anterior identufic toate entitile comune. Celelalte entiti, se vor include n modelul logic global exact aa cum apar n view-ul respectiv. (5) Compunerea relaiilor de pe modelele locale. n acest pas analizm silitudinile dintre relaii de pe diferite modele locale. n timpul compunerii relaiilor trebuie rezolvate i conflictele dintre relaii, ca i regulile de cardinalitate i participare. Putem compune relaii care au aceleai nume i acelai scop, sau acelai scop, dar nume diferite. (6) Includerea (fr compunere) a relaiilor care apar doar pe un view. Relaile care au rmas neincluse n modelul global dup pasul anterior, se includ n modelul global fr modificare. (7) Cutarea entitilor i relailor care lipsesc. Este unul din cei mai grei pai din crearea modelului global. Trebuie cutate acele entiti i relaii, care s-au omis la paii anteriori i n-au ajuns n modelul global. (8) Cutarea cheilor strine. n decursul pailor anterioare, s-au modificat entiti, chei primare i chei strine. n acest pas verificm dac cheile strine sunt corecte n fiecare entitate fiu i efectum toate modificrile necesare. (9) Cutarea regulilor de integritate Verificm dac regulile de integritate a modelului global nu sunt n conflict cu regulile definite la modelele locale. Fiecare problem de acest gen se rezolv cu ajutorul utilizatorului sistemuli. (10) Desenarea diagramei ER. Acum desenm diagrama ER pentru modelul global de date. (11) Actualizarea documentaiei. Actualizm documentaia, ca s reflecte toate modificrile aduse n acest pas modelului. Pasul 3.2. Validarea modelului logic global. Obiectivul: Validarea modelului global logic de date, folosind normalizarea, dup care folosind tranzacile cerute. Acest pas este schivalent cu paii 2.3. i 2.4., unde am validat modelul local de date. Pasul 3.3. Verificarea posibilitilor de extindere a bazei de date n viitor. Obiectivul: Determinarea ca dac modelul se acomodeaz uor la modificri orict de mari ce pot intervenii n viitor. Este important ca modelul creat s fie expansibil n viitor. Dac modelul nu are aceast calitate, viaa lui poate fi scurt i pentru o mai mare modificare va trebui
Page: 48

refcut de la nceput. Pasul 3.4. Desenarea diagramei Entitz-Relationship finale. Obiectivul: Desenarea unei diagrame ER, care s reprezinte modelul global de date al ntreprinderii. Pasul 3.5. Verificarea modelului global cu ajutorul utilizatorului. Obiectivul: Verificarea c modelul global reprezint n totalitate realitatea. n acest moment modelul global este complet i documentat. mpreun cu utilizatorul sistemului se verific acest model i se aduc eventualele corecturi prin ntoarcerea la psurile n cauz.

Page: 49

4. Metodologia proiectrii bazei de date logice - Exemplu

n acest capitol vom nva despre: Cum s folosim metodologia de proiectare a bazelor de date relaionele, desclis n capitolul 3. Cum s folosim aceast metodologie pentru proiectarea bazei de date al sistemului Asociaie de locatari. n acest capitol vom explica detaliat, cum putem folosii metodologia prezentat n capitolul 3. Vom exemplifica folosirea metodologiei cu proiectarea bazei de date pentru sistemul informatic al asociaiei de locatari. n decursul acestui capitol, vom folosii expresiile entitate i relaie n locul expresiilor tip de entitate respectiv tip de relaie. n cazul n care pot aprea ambiguiti, se va folosii tip de entitate respectiv tip de realie. 4.1. Cerinele utilizatorilor. Analiza i colectarea datelor l vom ncepe la o asociaie de locatari. Aici trebuie s cerem informaiile necesare pentru realizarea sistemului. Trebuie s colectm informaiile despre lucrul de zi cu zi a efului asociaiei de locatari. Vom mai avea nevoie de toate rapoartele pe care ei le ntocmesc. Toate informaiile despre sistemul de eviden a asociaiei de locatari se pot mprii n mai multe view-uri. Aceste view-uri sunt: Evidena locatarilor i a apartamentelor din asociaie, Evidena cheltuielilor locatarilor, Evidena personalului asociaiei, Evidena obiectelor de inventar i a mijloacelor fixe, Plata datoriilor asociaiei ctre furnizori. 4.1.1. Cerinele la baza de date. Evidena locatarilor i a apartamentelor din asociaie: (1) n baza de date vor fi memorate toi locatarii asociaiei de locatari. Informaiile necesare despre locatari sunt: adresa (numr bloc, scara, etajul i apartamentul) i numele. Ei vor fi unic determinai de un numr matricol unic pe toat asociaia de locatari. (2) Dintre locatari trebuie s evideniem pentru fiecare familie cte un reprezentant. Pentru fiecare familie trebuie s avem la dispoziie informaiile: numrul membriilor de familie, numrul persoanelor prezente n locuin n luna curent i numrul de chei de la ua principal. (3) Tot dintre locatari se alege cte un ef de scar pentru fiecare scar din asociaie. ef de scar trebuie s fie exact unu pe fiecare scar i trebuie s locuiasc n
Page: 50

scara pentru care s-a ales. Pentru eful de scar mai avem n plus informaia: data intrrii n funcie. (4) La evidena cldirilor din asociaia de locatari, avem de memorat scrile care aparin asociaiei. Scrile sunt identificate unic prin numrul blocului i litera scrii. Mai trebuie s tim despre fiecare scar dac are lift. (5) Pe fiecare scar avem mai multe apartamente. Despre apartamente trebuie s memorm informaiile urmtoare: nr. apartamentului, suprafaa, numrul de cutii potale i numrul de prize tv. (1) Evidena cheltuielilor locatarilor Fiecare cheltuial se nregistreaz n momentul primilii facturii de la furnizor. Cheltuielile sunt identificate unic printr-un numr de ordine care este continuu pe un an. Pentru fiecare cheltuial se nregistreaz informaiile: codul cheltuielii, codul furnizorului, numrul i data facturii, valoarea facturii. Cheltuielile se pot referii la o singur scar sau la mai multe scri, sau se pot referii la o singur familie sau mai multe familii. Pentru fiecare familie se nregistreaz lunar valoarea ce trebuie pltit asociaiei. Dac este cazul, se nregistreaz i restanele. Cnd o familie i achit datoria la asociaie, se emite o chitan, care trebuie s conin informaii despre valoarea pltit, data plii i numele persoanei care a fcut plata. Chitana se identific unic prin numrul su. Pentru a efectua mai uor nregistrarea cheltuielilor, memorm i datele despre furnizori. Aceste date sunt: denumirea, codul fiscal, contul bancar i banca, adresa (strada, numrul, bl., sc., ap., localitatea i judeul). Furnizorii se pot identifica unic printr-un cod intern - cod furnizor. Pe lng cheltuielile ctre furnizori exist i cheltuieli, care trebuiesc pltite de locatari, dar care rmn la asociaie. Astfel de cheltuial este fondul de rulment, fondul de reparaii, sau dac este cazul, i alte fonduri. Aceste cheltuieli se vor nregistra n acelai mod ca i celelalte, cu diferena c aici se va introduce un furnizor special pregtit. Fiecare familie trebuie s aib pltit o sum la asociaia de locatari pentru fondul de rulment. n cazuri speciale se adun bani i pentru fondul de reparaii, sau alte fonduri.

(2) (3) (4) (5)

(6)

(7)

Evidena personalului asociaiei. (1) Personalul asociaiei se va memora n baza de date, identifiacrea fcndu-se dup un numr matricol unic. Mai folosim informaiile: numele, data naterii, meseria, data angajrii i scrile din asociaie unde lucreaz. (2) Un angajat poate s lucreze n mai multe scri i pe o scar pot s lucreze mai muli angajati. Evidena mijloacelor fixe i a obiectelor de inventar. (1) Mijloacele fixe i obiactele de inventar se vor identifica unic, cu ajutorul unui cod numit numar de inventar. Pentru aceste obiecte mei reinem urmtoarele
Page: 51

informaii: numele, valoarea i locul unde este amplasat. Plata datoriilor asociaiei ctre furnizori. (1) O factur sosit de la un furnizor se poate achita prin cas, sau prin ordin de plat. Pentru aceste achitri reinem informaiile: valoarea achitat, data achitrii i numrul urdinului de plat sau a chitanei. 4.1.2. Tranzaciile cerute. (1) (2) (3) (4) Evidena locatarilor i a apartamentelor din asociaie: List cu locatarii de pe o scar, List cu familiile de pe o scar, List cu efii de scar, List cu proprietile apartamentelor ocupate pe o scar.

Evidena cheltuielilor locatarilor (1) List cu cheltuielile fiecrei familii pe scri, (2) List cu toate cheltuielile asociaiei de locatari. (3) Chitana care se emite la fiecare plat. Evidena personalului asociaiei. (1) List cu personalul asociaiei. Evidena mijloacelor fixe i a obiectelor de inventar. (1) List cu mijloacele fixe i valoarea lor, din asociaia de loacatari, (2) List cu obiectele de inventar ai asociaiei de locatari. Plata datoriilor asociaiei ctre furnizori. (1) List cu facturile scadente primite de la furnizori, (2) Situaia plilor facturilor de la furnizori, nglobnd facturile dintr-o perioad dat, mpreun cu modul lor de plat.

4.2. Utilizarea metodologiei de proiectare a bazelor de date relaionale. Pasul 1. Crearea modelelor conceptuale locale, bazate pe view-urile utilizatorilor: nainte s ne apucm de crearea modelului conceptual local, s ne reamintim din ce se compune acest model:
Page: 52

tipuri de entiti, tipuri de relaii, atribute, domeniile atributelor, chei candidat, chei primare. n acest capitol vom exemplifica metodologia de proiectare pe dou vederi ai sistemului informatic: Evidena locatarilor si a apartamentelor din asociaie, Evidena cheltuielilor locatarilor. Pasul 1.1. Identificarea tipurilor de entiti. ncepem s identificm tipurile de entiti din toate vederile utilizatorilor. Vom descrie separat identificarea acestor entiti pentru cele dou vederi. n cazul evidenei locatarilor i al apartamentelor, tipurile de entiti sunt: Locatari Scri ef de scar Apartamente Familii n cazul evidenei plilor tipurile de entiti sunt: Cheltuieli Furnizori Pli Chitane Familii Scri Documentarea tipurilor de entiti n documentarea tipurilor de entiti includem o descriere amnunit a fiecrei entoti, mpreun cu aliasurile lor. Aceste informaii sunt prezentate n anexa 4.1. Pasul 1.2. Identificarea tipurilor dr relaii. n continuare identificm tipurile de relaii. Tipurile de relaii se reprezint prin verbe ale relaiilor. Tipurile de relaii din cele dou view-uri sunt prezentate n tabelele de mai jos: Tipuri de relaii din view-ul Locatari: Tip de entitate Tip de relaie Scri sunt locuite de sunt locuite de sunt conduse de se compun din Tipuri de relaii din view-ul Cheltuieli: Tip de entitate Tip de relaie
Page: 53

Tip de entitate Locatari Familii ef de scar Apartamente Tip de entitate

Furnizorii Celtuieli Familii

provoac sunt pltite de sunt pltite de trebuie s plteasc primesc

Cheltuieli Familii Scri Pli Chitane

Dac la acest pas apar ambiguiti, ele trebuie neaprat clarificate cu utilizatorii. Determinarea cardinalitii i a participrii pentru tipurile de relaii. n contunuare vom determina cardinalul i participarea relaiilor prezentate n tabelele de mai sus. Cardinalul poate s fie unul dentre urmtoarele: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Participarea poate s fie parial sau total. Informaiile pe baza crora trebuie s determinm aceste caracteristici ai tipurilor de relaii, sunt prezentate n capitorul 4.1.1. n cazul n care apar ambiguiti, ele trebuie clarificate cu ajutorul utilizatorului. S lum de exemplu relaia dintre Scri i Locatari. Pentru a fi foarte siguri de cardinalul relaiei, vom pune urmtoarea ntrebare: ntrebare: Pot locui pe o scar mai muli locatari? Rspuns: Da. Deci relaia Scrile sunt locuite de Locatari are cardinalul 1:M. n continuare va trebui s aflm i cardinalul relaiei inverse, adic a relaiei Locatarii locuiesc n apartementele de pe Scri. ntrebare: Un locatar poate locui n mai multe apartamente de pe scri diferite? Rspuns : Nu. La aceast ntrebare avem nevoie de o explicaie: Dac o persoan are dou locuine n aceai asociaie de locatari, atunci el va apare n entitatea locatari de dou ori, cu nrumr matricol diferit. Deci un numr matricol poate s locuiasc doar ntrun singur apartament. Deci cardinalul acestei relaii este de 1:1, de unde rezult c relaia iniial are cardinalul 1:M. Pentru a afla participarea entitilor la relaie, punem urmtoarele ntrebri: ntrebare: Fiecare scar este locuit de cel puin un locatar? Rspuns : Nu. ntrebare: Fiecare locatar locuiete ntr-unul din aceste scri? Rspuns: Da. Deci tipul de entitate scri partcip parial, iar tipul de entitate Locatari particip total la relaie.
Page: 54

Fie relaia Cheltuieli sunt pltite de Scri, din view-ul Cheltuieli. S determinm cardinalul i participarea ei: ntrebare: Exist cheltuial care se refer la mai multe scri? Rspuns : Da. ntrebare: Scrile pot avea mai multe cheltuieli? Rspuns : Da. ntrebare: Fiecare cheltuial trebuie s fie asociat unei scri? Rspuns : Nu, pentru c poate fi asociat doar unor familii. ntrebare: Fiecare scar trebuie s aib cheltuieli? Rspuns : Nu, pentru c pot fi scri fr locatari. Dup aceste ntrebri i rspunsuri, am ajuns la concluzia c relaia are cardinalul N:M (ambele relaii - i cea direct i cea invers - au cardinalul 1:M), iar participarea parial de ambele pri. Cardinalul i partciparea relaiilor de mai sus sunt prezentate n anexa 4.3. Utilizarea modelrii ER. Pentru o nelegere mai uoar a relaiilor dintre entiti, se poate folosi diagrama ER. Diagramele ER ale celor dou view-uri ale cror relaii au fost prezentate mai sus, se pot vedea n figura 4.1. (a) i (b). Menionm, c verbele care reprezint relaiile de cardinal 1:M se pun n direcia unu-la-multe. n cazul n care relaia a fost altfel evideniat, ea va fi redenumit. Documentarea tipurilor de relaii. Documantarea view-urilor care apar n figura 4.1. este realizat n anexa 4.3.
Sunt locuite de Sunt locuite de Familii Sunt conduse de Sef de scara Apartamente Se compun din

Locatari

Scari

Figura 4.1.(a) Diagrama ER. a view-ului Locatari.

Page: 55

Scari

Sunt locuite de

Familii Primesc

Sunt platite de Furnizori

Trebuie sa plateasca

Plati Sunt platite de

Chitante

Cheltuieli

Provoaca

Figura 4.1.(b). Diagrama ER a view-ului Cheltuieli Pasul 1.3. Identificarea i asocierea atributelor la tipurile de releii i tipurile de entiti. n acest pas identificm atributele ce se asociaz tipurilor de entiti sau tipurilor de relaii. Atributele sunt informaii care caracterizeaz entitile, resoective relaiile. Aceste atribute le putem gsi n descrierea acordat de utilizatori. n cazul nostru, atributele identificate i asociate entitilor se pot regsi n tabela 4.2.a. i 4.2.b. Tabela 4.2.a. Atributele tipurilor de entiti 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 Scri Adresa (Nr_bloc, Scara) Lift Apartamente Apartament Suprafaa Cutii_potale Nr_prize_tv Tabela 4.2.b. Atributele tipurilor de entiti din view-ul Cheltuieli:
Page: 56

Tip de entitate Familii

Pli Chitane Cheltuieli

Furnizori

Atribute Nr_mat Fond_rulment Fond_reparaii Alte_fonduri Data Valoare Restan Nr_Chit Valoare Data Nr_crt Cod_cheltuiala Nr_factura Data_factura Valoare Cod_furnizor Denumire Cod_fiscal Cont Banca Adresa (Strada, Nr., Bl., Sc., Ap., Localitate, Jud)

Documentarea atributelor: Pentru documentaie se descrie fiecare atribut, se menioneaz tipul de date folosit precum i lungimea cmpului, reguli, valoarea implicit, toate aliasurile lui, dac atributul este sau nu compus, dac este derivat sau nu, dac admite mai multe valori i dac admite valoarea nul. O parte a acestei documentaii este exemplificat n anexa 4.2. Pasul 1.4. Determinarea domeniilor atributelor: n acest pas determinm domeniile atributelor. Domeniul unui atribut este nulimea acelor valori, pe care le poate lua n lucrul de zi cu zi. Documentarea atributelor. Cteva din domeniile exemplului nostru sunt artate n anexa 4.4. Pasul 1.5. Determinarea atributelor care aparin cheilor candidat i primare: Acum vom examina tabelele 4.2.a. i 4.2.b., i com cuta cheile candidat pentru entitile n cauz. Dintre aceste chei candidat vom selecta cheia primar, dup criterii deja descrise n capitolul 3. Cheile primare i alternante pentru entitile din view-ul Locatari i view-ul Cheltuieli, sunt afiate n anexa 4.2. Menionm, c n acest pas nu asociem chei primare entitilor slabe, acesast operaie fiind rezolvat n pasul 2.2. Documentarea cheilor primare i alternante.
Page: 57

Documentm atributele care compun cheile primare i cheile alternante. Un exemplu de ducumentare gsii n anexa 4.2. Pasul 1.6. Specializarea/generalizarea tipurilor de entiti (pas opional). n acest pas putem dezvolta modelul ER, utiliznd procesul de specializare/generalizare asupra entitilor identifcate n pasul 1.1. Dac vrem s folosim procesul de specializare, vom cuta diferenele dintre entiti, iar n cazul procesului de generalizare, asemnrile dintre ele. De exemplu, n view-ul Locatari, entitile Locatari, Familii i ef_scar au atributele Nr_mat, Adresa i Nume n comun. Entitatea Familii mai are n plus atributele Nr_pers, Nr_pers_prez i Nr_chei iar entitatea ef_scar are n plus doar atributul Data_intreare_func. Entitatea Locatari are asociate doar atributele comune cu cele dou entiti. Deci putem generaliza entitile Familii i ef_scar, punnd pe post de superclas entitatea Locatari, iar celelalte dou fiind subclase. Relaia superclas-subclas dintre entitatea Locatari i Familii respectiv ef_scar este o relaie parial i nondisjunct, pentru c n Locatari sunt toi locatarii asociaiei, deci i acelea care nu sunt nici capi de familie i nici efi de scar iar pe de alt parte, eful de scar poate s fie i cap de familie. Figura 4.3. reprezint diagrama celor trei entiti dup procesul de generalizare.
Locatari Nr_Mat Etaj Nr_Bloc (FK) Apartament Scara (FK) Nume Sef de scara Nr_Mat (FK) Data_intrare_func Familii Nr_Mat (FK) Nr_pers Nr_pers_prezente Nr_chei

Figura 4.3. Exemplu de relie superclas - subclas

Pasul 1.7. Desenarea modelului ER. Pentru o mai bun nelegere a modelului local creat, folosim diagrama ER. Aceast diagram i documentaia creat se refer la modelul local conceptual. Diagramele ER ale celor dou view-uri ai exemplului nostru se pot vedea n figura 4.4.a., respectiv 4.4.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. Dac se descoper erori, atunci ne ntoarcem la pasurile anterioare i le remediem. Vom repeta aceti pai pn cnd modelul creat va fi n conformitate cu realitatea.

Page: 58

Locatari

Sunt locuite de Scari Se compun din

Sef de scara

Familii

Apartamente

Figura 4.4.a. Modelul conceptual local al view-ului Locatari

Scari

Familii Trebuie sa plateasca Primesc

Sunt platite de Furnizori

Plati

Chitante Sunt platite de

Cheltuieli

Provoaca

Figura 4.4.b. Modelul conceptual local al view-ului Cheltuieli.

Pasul 2. Crearea i validarea modelului local de date. n acest pas revizuim modelul creat i eliminm acele structuir care se pot implementa greu n sistemul de gestiune a bazelor de date. Dup aceea validm modelul, utiliznd metoda normalizrii i a tranzaciilor. Pasul 2.1. Proiectarea modelului local conceptual n modelul local logic. n acest pas eliminm acele structuri din baza de date, care sunt dificil de implementat n sistemul de gestiune al bazelor de date. Pentru a rezolva aceast problem, se vor urma urmtorii pai: (1)Eliminarea relaiilor de tipul N:M. (2)Eliminarea relaiilor complexe. (3)Eliminarea relaiilor recursive. (4)Eliminarea relaiilor cu atribute. (5)Reexaminarea relaiilor de tipul 1:1. (6)Eliminarea relaiilor redundante. (1) Eliminarea relaiilor de tipul N:M. Cum putem observa i n figura 4.4.b., relaiile Cheltuieli Sunt pltite de Familii i Cheltuieli Sunt pltite de Scri au cardinalul de N:M. Vom descompune aceste relaii n cte dou relaii de tipul unu-la-multe (1:M), numite n ambele cazuri
Page: 59

Se calculeaz i Au cheltuieli. Aceast modificare devin posibil prin introducerea a doi entiti noi, numite Pe_familii, respectiv Pe_scri. Aceste entiti noi vor fi entiti slabe, pentru c vor depinde de entile Cheltuieli, Familii i Scri. Adic cheia primar a lor va fi derivat din cheia primar a entitilor tari. Modificrile se pot observa n figura 4.5.
Scari Familii Trebuie sa plateasca Au cheltuieli Plati Pe scari Chitante Cheltuieli Se calculeaza Au cheltuieli Primesc Pe familii Se calculeaza Provoaca Furnizori

Figura 4.5. View-ul Cheltuieli, dup eliminarea relaiilor N:M. (2) Eliminarea relaiilor complexe. n acest pas, eliminm toate relaiile complexe (care sunt ntre mai mult dect dou entiti) din modelul conceptual. Aceast eliminare se poate rezolva prin crearea a noi entiti. Exemplul nostru nu conine nici o relaie complex. (3) Eliminarea relaiilor recursive. Pasul acesta este pentru eliminarea tuturor relaiilor recursive, adic acele relaii care pun n relaie o entitate cu el nsi. n exemplul nostru nu avem astfel de cazuri. (4) Eliminarea relaiilor cu atribute. Se elimin toate acele relaii, care au asociate atribute. Eliminarea se realizeaz prin adugarea a noi entiti, care vor memora aceste atribute. Nu este cazul exemplului nostru. (5) Reexaminarea relaiilor de tipul 1:1. n foarte multe din cazuri, entitile care sunt relaionate prin relaii cu cardinalul 1:1, se pot ngloba ntr-o singur entitate. De aceea este indicat reexaminarea relaiilor de tipul unu-la-unu. Exemplul nostru nu conine relaii de acest tip. (6) Eliminarea relaiilor redundante. Pot exista cazuri n care s avem relaii redundante. Adic s se poat ajunge de la o entitate la alte prin mai multe drumuri diferite. n acest caz relaiile redundante trebuie eliminate, pentru c noi trebuie s ajungem la o baz de date minimal i foarte stabil. Nu este i cazul exemplului nostru. Desenarea diagramei ER. Modelul conceptual care este reprezentat n figura 4.4. a. i 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 modificat se va numi n
Page: 60

continuare modelul local logic al bazei de date. Acest model este prezentat n figura 4.6.a. i 4.6.b.
Locatari Sunt locuite de Scari Se compun din

Sef de scara

Familii

Apartamente

Figura 4.6.a. Modelul logic local al view-ului Locatari.

Scari

Familii Trebuie sa plateasca

Au cheltuieli Primesc Chitante

Pe familii Se calculeaza Cheltuieli

Furnizori

Au cheltuieli Plati Pe scari

Provoaca

Se calculeaza

Figura 4.6.b. Modelul logic local al view-ului Cheltuieli. Pasul 2.2. Crearea de relaii peste modelul logic local. n acest pas vom crea relaiile ntre entitile din modelul logic local de date, cu ajutorul mechanismului chei primare/chei strine. Pentru exemplificarea acestui proces, s lum relaia Furnizori Provoac Cheltuieli din view-ul Cheltuieli. Vom folosii limbajul de definire a bazelor de date (DBDL), pentru descrierea fiecrei relaii. Pentru fiecare entitate tare a modelului, crem o relaie care include toate atributele simple ale entitii. Structura entitii Furnizori este: Furnizori (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str., Bl., Sc., Ap., Loc., Jud.) Cheie primar: Cod_furnizor Pentru fiecare entitate slab, descriem relaia, ncludnd atributele simple ale entitii, specificnd cheia strin i entitatea la care se refer aceast cheie strin. Structura entitii Cheltuieli este: Cheltuieli (Nr_crt, Cod_furnizor, Cod_cheltuial, Nr_factur, Data_factur, Valoare)
Page: 61

Cheie primar: Nr_crt Cheie strin : Cod_furnizor Acest proces continu, pn cnd se vor prelucra toade relaiile din baza de date. Documentarea relaiilor i a atributelor din cheile strine. Relaiile derivate pentru view-urile Locatari i Cheltuieli se pot vedea n anexa 4.5., la sfritul acestui capitol. La crearea relaiilor trebuie actualizat i dicionarul de date, cu atributele nou introduse i cu noile chei primare i alternante.

Pasul 2.3. Validarea modelului prin normalizare. n acest pas validm baza de date prin normalizare. Procesul de normalizare este descris amnunit n capitolul 2. Forma Normal Unu (1NF), eliminarea repetiiilor din atribute. Forma Normal Doi (2NF), eliminarea dependenelor pariale de cheia primar. Forma Normal Trei (3NF), eliminarea dependenelor tranzitive de cheia primar. Forma Normal Boyce-Codd (BCNF), eliminarea anomaliilor care au mai rmas. Trebuie s analizm fiecare relaie care este edscris n anexa 4.5. Verificm dac relaiile sunt n forma normal Boyce-Codd, iar dac gsim unul care nu satisface aceast form normal, ne ntoarcem la paii precedeni i rezolvm problema. Pentru a exemplifica acest proces, s analizm relaia Furnizori Provoac Cheltuieli, descris n anexa 4.5. Menionm c notaiile de aici nu includ cheia strin. Furnizori (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str, Nr, Bl, Sc, Ap, Loc, Jud) Cheie primar: Cod_furnizor Cheie alternant: 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_cheltuial, Nr_factur, Data_factur, Valoare) Cheie primar: Nr_crt Nr_crt Cod_furnizor, Cod_cheltuial, Nr_factur, Data_factur, Valoare Pentru acest exemplu avem urmtoarele demonstraii: Nu exist grupuri repetitive n niciunul dintre entiti. Deci relaia este n forma normal unu.
Page: 62

 Fiecare cheie se compune dintr-un singur atribut. De aceea nu putem avea dependen parial de cheie. Deci relaia este n form normal doi. Nu exist dependene tranzitive de cheie, deci relaia este n form normal trei. Fiecare determinant evideniat este cheie, deci relaia este n form normal Boyce-Codd. Acest proces se continu pentru fiecare relaie care apare n anexa 4.5. Pasul 2.4. Validarea modelului prin tranzaciile cerute. Pentru a valida prin tranzacii un model logic de date, folosim diagrama ER. din figura 4.6.a. respectiv 4.6.b. i documentaia ntocmit. ncercm s rezolvm manual toate tranzaciile cerute de utilizator, folosind doar datele i relaiile din modelul de date creat. Dac nu putem rezolva o tranzacie, nseamn c am omis ceva la modelarea bazei de date i deci trebuie s ne ntoarcem la paii anteriori i s remediem eroarea. Pe de alt parte, dac o parte a modelului de date nu este folosit la nici o tranzacie, atunci - n caz c nu se prevede ca n viitor s folosim aceast parte a modelului - va trebui s-l considerm redundant, i s-l eliminm din modelul de date. Considerm dou posibiliti de verificare a modelului de date. Conform primei metode, ne asigurm c exist n modelul de date toate entitile i relaiile care sunt necesare pentru tranzacia aleas. Pentru a exemplifica aceast metod, s verificm urmtoarea tranzacie: Crearea i modificarea de nregistrri cu detaliile unei cheltuieli. Pentru crearea nregistrrii despre o cheltuial, dup introducerea datelor despre cheltuial, se vor selecta i scrile sau familiile la care este asociat. O cheltuial nu poate fi asociat i unor familii i unor scri. Pentru a modifica o cheltuial, trebuie s tim numrul cheltuielii din bazs de date. Cutm acea cheltuial i dac exist modificm detaliile despre cheltuial, recreind i legturile la familii sau scri, depinde cine trebuie s plteasc. Dac nu exist, atunci apare un mesaj de eroare i procedura de modificare se ntrerpe. n cazul tergerii unei cheltuieli, prima dat trebuie cutate nregistrrile de legtur a acelor cheltuieli cu scri sau cu familii. Dac exist se terg, dup care se terge i cheltuiala. Dac nu exist nseamn c nu exist nici cheltuiala i se va afia un mesaj de eroare. A doua modaliate de a verifica modelul de date este de a desena cile generate de relaii, pentru fiecare tranzacie n parte. Aceste ci se noteaz cu o linie avnd o sgeat n direcia tranzaciei. Tranzaciile descrise n capitolul 4.1.2. sunt reprezentate prin diagramele din figurile 4.7.a. respectiv 4.7.b.

Page: 63

Locatari
T 3.

T 1.

Sunt locuite de Scari

T 4.

T 2.

Se compun din

Figura 4.7.a. Diagrama tranzaciilor cerute la view-ul Locatari.

Sef de scara

Familii

Apartamente

Scari

Familii Trebuie sa plateasca

Au cheltuieli Primesc
T 3. T 2.

Pe familii Se calculeaza Cheltuieli

Furnizori

Au cheltuieli Plati Pe scari

T 1. T 2.

Chitante Se calculeaza

Provoaca

Figura 4.7.b. Tranzaciile cerute pentru view-ul Cheltuieli. Pasul 2.5. Desenarea diagramei ER. Diagrama ER din figura 4.7.a. i 4.7.b. ne ajuta s identificm uor relaiile critice pentru tranzacii, precum i ariile din modelul creat, care nu iau parte la nici o tranzaciie. Dup identificarea i eliminarea acestor arii, redesenm diagrama ER. n cazul nostru acest diagram nu se modific. Pasul 2.6. Definirea regulilor de integritate. n acest pas identificm acele reguli care s ne garanteze c datele introduse n baza de date rmn consistente. Putem identifica cinci tipuri de reguli: necesitatea datelor, domeniile atributelor, integritatea entitilor, integritatea relaiilor, reguli date de intreprindere. Necesitatea datelor. Identificm acele atribute ale bazei de date, care nu admit valoarea nul. De exemplu atributele Nr_mat - din entitatea Locatari - i Adresa (Nr_bloc, Scara) - din entitatea Scri. Aceste reguli asupra atributelor modelului sunt descrise n pasul 1.3. i sunt documentate n anexa 4.2. Domeniile atributelor.
Page: 64

Domeniile atributelor identific valorile posibile pe care le poate loa un atribut. De exemplu atributul Etaj din entitatea locatari poate lua valori ntre -1 i 100. Domeniile atributelor sunt descrise n pasul 1.4. i sunt documentate n anexa 4.4. Integritatea entitilor. Cheia primar a entitilor nu poate lua valori nule. De exemplu Nr_mat, chiea primar a entitii Locatari nu poate lua valoarea nul. Cheile primare ale fiecrei entiti au fost identificate n pasul 1.6. iar ducumentarea cheilor se gsete n anexa 4.5. Integritatea relaiilor. Relaiile dintre entiti sunt reprezentate prin copierea chei primare a entitii printe, n cheia strin a entitii fiu. Integritatea relaiilor se refer la faptul c dac cheia strin dintr-o entitate slab conine o valoare, atunci aceast valoare s exista i n entitatea tare la care este asociat prin relaie. De exemplu dac se nregistreaz pli unei familii n entitatea Pli, atunci acea familie trebuie s existe i n entitatea Familii. Atributele care compum cheile primare i cheile strine sunt descrise n anexa 4.5. Este important ca s identificm regulile relaiilor, pentru ca relaiile dintre entiti s rmn consistente. Menionm c relaiile se descriu cu limbajul specific definirii bazelor de date (DBDL). Prima dat s considerm cazul c cheile strine au valoare nul. n general cnd participarea entitii slabe la relaie este total, nu se permite valoare nul n cheia strin. De exemplu s descriem relaia Scri Se compun din Apartamente. Entitatea Apartamente (slab) particip total la relaie, deci nu admitem valori nule atributelor din cheia strin i anume Nr_bloc i Scara. Pe de alt parte, dac entitatea slab particip parial la relaie, putem admite valoare nul i cheii strine. Nu este cazul exemplului nostru, pentru c nu avem entitate slab cu participare parial. Descriem relaia Scri Se compun din Apartamente cu limbajul DBDL: Scri (Nr_bloc, Scara, Lift) Cheie primar: Nr_bloc, Scara Apartamente (Nr_bloc, Scara, Apartament, Suprafaa, Cutii_potale, Nr_prize_tv) Cheie primar: Nr_bloc, Scara, Apartament Cheie strin : Nr_bloc, Scara Nenul referindu-se la Scri (Nr_bloc, Scara) n continuare considerm cazul n care se modific cheia primar a entitii tari. Menionm c inserarea cheii primare, sau tergerea cheii strine nu duneaz consistenei bazei de date. Pentru celelalte chei primare, definim modul de modificare i tergere a cheii primare. Putem alege ntre patru moduri: FR ACIUNE, CASCAD, SETARE NUL i SETARE IMPLICIT. Descriem aceste modaliti de modificare/tergere pe baza relaiei Scri Se compun din Apartamente, extinznd n continuare limbajul
Page: 65

DBDL. Scri (Nr_bloc, Scara, Lift) Cheie primar: Nr_bloc, Scara Apartamente (Nr_bloc, Scara, Apartament, Suprafaa, Cutii_potale, Nr_prize_tv) Cheie primar: Nr_bloc, Scara, Apartament Cheie strin : Nr_bloc, Scara Nenul, Cascad, referindu-se la Scri (Nr_bloc, Scara) Aceast operaie se execut pentru fiecare relaie descris n anexa 4.5. Regulile ntreprinderii. Aceste reguli sunt definite de ntreprindere i reprezint reguli ce trebuie respectate i n viaa de zi cu zi. De exemplu lista cu plile locatarilor se poate tiprii doar pe durat de o lun. Toate aceste reguli sunt prezentate n anexa 4.6. Documentarea regulilor de integritate. Toate cele descrise mai sus se documenteaz 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 s fie o reprezentare fidel a realitii. Utilizatorul sistemului trebuie s verifice att diagrama ct i documentaia ntocmit. Dac se gsete o eroare, se vor reface paii necesari pentru corectarea erorii. Pasul 3. Crearea i validarea modelului global de date. n acest pas crem modelul global prin compunerea entitilor de pe diversele modele locale. Acest model global va trebui i ea validat prin normalizare. Pasul 3.1. Compunerea modelelor locale n modelul global. n pasul acesta compunem dou modele locale ntr-un model global de date. Mai multe modele globale se compun tot dou cte dou, pn cnd ajungem la modelul global. Pentru nceput identificm similaritile dintre modelele locale, dup care trebuie identificate i rezolvate ariile de conflicte ntre modele iar n final se trec toate modelele ntr-un singur model. Paii care trebuie urmai pentru compunerea modelelor sunt prezentai n continuare: (1) Revizuirea numelor entitilor i cheile lor primare. Comparm numele i cheile primare dintre dou modele locale, comparaie ce este prezentat n tabela 4.8. Tip de entitate (view-ul Cheie primar
Page: 66

Tip de entitate Cheie primar (view-ul

Locatari) Scri Familii Locatari ef de scar Apartamente

Nr_bloc, Scar Nr_mat Nr_mat Nr_mat Nr_bloc, Scara, Ap.

Cheltuieli) Scri Familii

Nr_bloc, Scar Nr_mat

Pli Data, Nr_mat Chitane Nr_chit Pe_familii Nr_crt Pe_scri Nr_crt Cheltuieli Nr_crt Furnizori Cod_furnizor Tabela 4.8. O comparaie ntre numele entitilor i ale cheilor lor primare. Aceste similariti dintre entiti arat care sunt acele modele care se suprapun. Entitile care se suprapun se pot compune, crend o singur entitate cu toate atributele entitii din cele dou modele. (2) Revizuirea numelor relaiilor. n continuare, comparm numele relaiilor din dou modele de date. O comparaie ntre modelele Locatari i Cheltuieli este prezentat n tabela 4.9. Relaiile sunt incluse n aceast tabel doar o singur dat n direcia de la entitatea tare la cea slab. Tip entitate view-ul Locatari Scri Tip de relaie Sunt locuite de Se compun din Tip entitate view-ul Locatari Locatari Apartamente Tip entitate view-ul Cheltuieli Scri Familii Tip de relaie Au cheltuieli Au cheltuieli Trebuie s plteasc Primesc Se calculeaz Se calculeaz Provoac Tip entitate view-ul Cheltuieli Pe_scri Pe_familii Pli Chitane Pe_familii Pe_scri Cheltuieli

Cheltuieli Furnizori Tabela 4.9. Comparaia tipurilor de relaii.

Informaiile cuprinse n aceast tabel arat nc o dat aria modelelor care se suprapun. Este important s inelegem c acelai nume se relaie n dou modele nu nseamn c acele relaii au i acelai rol. Trebuie s avem mare grij la astfel de nume de relaii (se numesc homonome). Mai exist i posibilitatea ca relaii care reprezint aceleai concepte s fie denumite cu nume diferite (sinonime). Aceste probleme la identificarea relaiilor se pot rezolva, analiznd atributele
Page: 67

(i n particular domeniile cheilor) asociate entitilor care fac parte din relaie. n final trebuie s ne asigurm c relaiile pe care le considerm echivalente s reprezinte aceleai relaii i n lumea real. (3) Compunerea entitilor din cele dou modele. n acest pas analizm numele i coninutul entitilor din ambele modele. n particular, utilizm cheia primar s vedem care dintre entiti sunt echivalente, chiar dac apar sub nume diferite n cele dou modele. Acest pas include urmtoarele activiti: Compunerea entitilor cu aceleai nume i aceleai chei primare. Compunerea entitilor cu aceleai nume dar cu chei primare diferite. Compunerea entitilor cu nume diferite dar cu chei primare aceleai sau diferite. Compunerea entitilor cu aceleai nume i aceleai chei primare. Entitile care sunt denumite cu aceleai nume i aceleai chei primare n cele dou modele reprezint n general aceleai concepte a lumii reale. Deci aceste entiti sunt cele mai sumpu de identificat. Astfel de entiti sunt de exemplu entitile Scri i Familii. Entitile combinate vor include toate atributele celor duo entiti din cele dou modele, eliminndu-se dublurile. Exemplul de compunere a entitii Familii este prezentat n figura 4.10. Compunerea entitilor cu aceleai nume dar cu chei primare diferite. n cazurile cnd entitile au acelai nume dar cu chei primare diferite, trebuie s identificm i cheile alternante a celor dou entiti. Dac ntre cheile candidat a unei entiti apare cheia primar a celeilalte, atunci compunem entitile i alegem o cheie primar dintre cele dou cei primare. n exemplul nostru nu avem astfel de caz. Compunerea entitilor cu nume diferite dar cu chei primare aceleai sau diferite. Putem ntlni cazuri n care nici numele entitilor i nici cheile primare nu fie la fel, dar tim din atributele celor dou entiti c ele reprezint aceleai concepte. Aceste entiti se compun ca la cazul anterior, avnd n plus obligaia de a alege un nume care poate s fie una dintre cele dou nume, sau o nume nou. Figura 4.10. Exemplu de compunere a dou entiti. (view-ul Locatari) Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei) Cheie primar: Nr_mat Cheie strin : Nr_mat referindu-se la Locatari (Nr_mat) (view-ul Cheltuieli) Familii (Nr_mat, Fond_rulment, Fond_reparaii, Alte_fonduri) Cheie primar: Nr_mat (modelul global)
Page: 68

Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei, Fond_rulment, Fond_reparaii, Alte_fonduri) Cheie primar: Nr_mat Cheie strin : Nr_mat referindu-se la Locatari (Nr_mat) (4) Includerea (fr compunere) a entitilor unice n cele dou modele. Dup includerea tuturor entitilor comune n modelul global, mai rmn alte entiti care nu sunt comune i care nc nu au fost incluse. Aceste entiti se vor include neschimbat n modelul global. Astfel de entiti sunt: Cheltuieli din modelul Cheltuieli, respectiv Apartamente din modelul Locatari. (5) Compunerea tipurilor de relaii din modelele locale. n acest pas analizm numele i caracteristicile relaiilor pentru a le putea compune. Este important de rezolvat conflictele datorate din participarea i cardinalul relaiilor. Numele relaiilor din cele dou modele sunt listate n tabela 4.9. Compunerea relaiilor cu aceleai nume i aceleai caracteristici. Aceste relaii sunt cel mai uor de identificat. Compunerea se rezolv prin simpla nscriere a relaiei n modelul global. Pot exista situaii cnd cardinalul sau participarea nu coincid la cele dou modele. Cazul acesta trebuie clarificat cu utilizatorul sistemuli. Atragem atenia c pot exista relaii cu aceleai denumiri dar care s aib roluri diferite (omonime). Compunerea relaiilor cu nume diferite dar cu aceleai caracteristici. Identificm acele relaii care apar n ambele modele dar cu denumiri diferite. Acest identificare devine evident dup ce observm c relaia leag aceleai entiti. i n acest caz trebuie rezolvat problema cardinalului i a participrii. (6) Includerea (fr compunere) a relaiilor unice pe cele dou modele. Identificm toate relaiile pe care nu am inclus-o nc i le includem neschimbat n modelul global. Toate relaiile descrise n tabela 4.9. sunt de acest tip. (7) Verificarea dac s-a omis vre-o entitate sau relaie. Aceast aciune de verificare este foarte important dar i foarte grea de rezolvat. Entitile i relaiile compuse pot avea chiar alt nume dect cele de pe modelele locale ceea ce face greu de urmrit includerea entitii sau a relaiei n modelul global. (8) Verificarea cheilor strine. n acest pas verificm dac toate entitile slabe conin cheia strin asociat lor. Aceste chei trebuie s se formeze la compunerea entitilor, ns tot la compunere se pot i redenumii. (9) Verificm regulile de integritate. Verificm toate regulile de integritate pe modelul global de date iar dac apar probleme la verificare, ne ntoarcem la paii anteriori i le remediem. (10) Desenarea modelului global de date. Acum desenm modelul global de date. Modelul global al sistemului de eviden a asociaiei de locatari este prezentat n figura 4.11. Numele entitilor i a relaiilor se poate schimba la aceast aciune.
Page: 69

(11) Completarea documentaiei. Este foarte important actualizarea documentaiei, pentru a reflecta modificrile efectuate asupra bazei de date. Anexa 4.7. descrie relaiile modelului global prezentat n figura 4.11., folosind limbajul DBDL.
Locatari Sunt locuite de Scari Apartamente Se compun din Sunt Au cheltuieli Este Patrimoniu Se calculeaza Sef de scara Familii Personal Contin Pe familii Se calculeaza Achitari Se achita Pe scari Furnizori Provoaca

Alocate

Cheltuieli

Au cheltuieli Chitante Primesc Trebuie sa plateasca Plati

Figura 4.11. Diagrama global i final ER. Pasul 3.2. Validarea modelului global de date. n acelai mod cum am validat modelele locale, trebuie validat i modelul global, folosind normalizarea i validarea prin tranzacii. Acesta este foarte important pentru a verifica (i demonstra) dac nu cumva s-au introdus erori la crearea modelului global. Pasul 3.3. Verificarea posibilitii de extindere n viitor. Este important ca modelul creat s se poat extinde n viitor. De exemplu n sistemul de eviden a asociaiei de locatari se va putea introduce un modul care s rezolve salarizarea personalului asociaiei. Modelul global al aplicaiei este extensibil, extinderea putndu-se realiza cu minime modificri. Pasul 3.4. Desenarea diagramei ER finale. La acest pas observm c nu am modificat nimic de la ultima diagram desenat, deci diagrama ER final este diagrama din figura 4.11. Pasul 3.5. Verificarea modelului global cu ajutorul utilizatorului.
Page: 70

Este important s reexaminm modelul creat mpreun cu utilizatorul, pentru a vedea dac ndeplinete toate cerinele. Dac apar cerine care nu sunt ndeplinite ne ntoarcem la paii anteriori i remediem situaia.

Page: 71

Anexa 4.1. Documentarea tipurilor de entiti n view-urile Locatari i Cheltuieli Tipurile de entiti din view-ul Locatari: Nume tip Descriere Aliasuri de entitate Locatari Oamenii care locuiesc n asociaie Familii Familiile din Cap_familie asociaie Sef_Scara Scri Persoana care se ocup cu problemele unei scri. Scrile din asociaie Entiti Persoanele care au domiciliul n asociaie Cte o persoan din fiecare familie, considerat reprezentantul acesteia Cte o persoan de pe fiecare scar din asociaie Fiecare scar care aparine asociaiei, mpreun cu caracteristicele ei. Fiecare apartament din asociaie, mpreun cu caracteristicile ei. Entiti Analog ca la Locatari Analog ca la Locatari Fiecare furnizor cu care s-a lucrat vreodat n asociaie Fiecare factur, care reprezint o cheltuial a locatarilor din asociaie. Plile calculate pentru fiecare familie Toate chitanele emise ctre locatari.

Apartamente

Apartamentele din asociaie

Tipurile de entiti din view-ul Cheltuieli: Nume tip Descriere Aliasuri de entitate Scri Scrile din asociaie Familii Familiile din Cap_familie asociaie Furnizori Societile de la care vin facturile Cheltuieli Pli Chitane Cheltuielile asociaiei ctre furnizori Plile calculate Chitanele emise

Page: 72

Anexa 4.2. Documentarea atributelor Atributele tipurilor de entiti din view-ul Locatari: Tip de Atribute Descriere Tip de date i entitate lungime Locatari ntreg ntreg [-1,100] ntreg 25 de caractere Familii Ca la Locatari plus Nr. pers. n familie ntreg Nr. pers. prezente n ntreg luna curent Nr_chei Nr. de chei de la ua ntreg principal Sef_Scara Ca la Locatari Ca la Locatari plus plus DataIntrFunc Data intrrii n func Dat Scri Adresa (Nr_bloc, Scara) Lift Exist sau nu lift Logic Apartamente Apartament Apartamentul ntreg Suprafaa Sup. total a ap. Real Cutii_potale Nr. cutii potale ntreg Nr_prize_tv Nr. prize tv. ntreg Nr_Mat Etaj Apartament Nume Ca la Locatari, plus Nr_pers Nr_pers_prez Det. unic locatarii Etajul la care loc. Apartamentul Numele locatarului Valoare Alias Valoare Derivat? implicit nul Cheie primar Nu Nu Nu Nu Nu Nu Nu Nu Ca la Locatari Nu Nu Da Ca la Locatari Cheie primar Nu Nu Nu Nu Nu Nu
Page: 73

Reguli

Nu Nu Nu

Nu Nu Nu Nu Nu Nu

Atributele tipurilor de entiti din view-ul Cheltuieli: Tip de Atribute Descriere Tip de date i entitate lungime Familii Nr_mat Fond_rulment Fond_reparaii Alte_fonduri Data Valoare Restan Nr_chit Valoare Data Nr_crt Cod_cheltuiala Nr_factura Data_factura Valoare Cod_furnizor Denumire Cod_fiscal Cont Banca Adresa Identific familia Fond de rulment Fond de reparaii Alte fonduri Luna pt. care e plata Suma de plat Suma restant Id. unic chitana Valoarea pltit Data plii Identific cheltuiala Tipul cheltuielii Numrul facturii Data facturii Valoarea cheltuialii Identific furnizorul Numele societii Codul fiscal Contul bancar Banca Str,Nr,Bl,Sc,Ap,Loc ntreg Real Real Real Dat Real Real ntreg Real Dat ntreg ntreg ntreg Dat Real ntreg 30 de caractere 10 caractere 25 de caractere 20 de caractere

Reguli Cheie primar

Pli Chitane Cheltuieli

Cheie primar Cheie primar

Furnizori

Cheie primar Cheie alt.

Valoare Alias Valoare Derivat? implicit nul Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Nu Da Nu Da Nu

Page: 74

Ghid de proiectare a bazelor de date relaionale

Trk Mihly gr.7241

Anexa 4.3. Documentarea tipurilor de relaii din view-urile Locatari i Cheltuieli Tipuri de relaii din view-ul Locatari: Tip de Tip de relaie Tip de entitate entitate Scri sunt locuite de Locatari sunt locuite de Familii sunt conduse de ef de scar se compun din Apartamente Tipuri de relaii din view-ul Cheltuieli: Tip de Tip de relaie Tip de entitate entitate Furnizorii provoac Cheltuieli Celtuieli sunt pltite de Familii sunt pltite de Scri Familii trebuie s plteasc Pli primesc Chitane * P=parial, T=total. Cardinal 1:M 1:M 1:M 1:M Cardinal 1:M M:N M:N 1:M 1:M Participare* P:T P:T P:T T:T Participare* P:T P:P P:P T:T P:T

Anexa 4.4. Documentarea domeniilor atributelor Nume domeniu Etaj String30 String10 String20 Caracteristici ntreg ntre -1 i 100 30 de caractere, lungime variabil 10 caractere, lungime variabil 20 de caractere, lungime variabil Exemple 0=Parter ROMGAZ

Page: 75

Ghid de proiectare a bazelor de date relaionale

Trk Mihly gr.7241

Anexa 4.5. Descrierea relaiilor din view-urile Locatari i Cheltuieli Descrierea relaiilor din view-ul Locatari. Locatari (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers, Nr_pers_prez, Nr_chei, Data_intrare_func) Cheie primar: Nr_mat Cheie strin : Nr_bloc, Scara referindu-se la Scri (Nr_bloc, Scara) Scri (Nr_bloc, Scara, Lift) Cheie primar: Nr_bloc, Scara Apartamente (Nr_bloc, Scara, Apartament, Suprafaa, Cutii_potale, Nr_prize_tv) Cheie primar: Nr_bloc, Scara, Apartament Cheie strin : Nr_bloc, Scara referindu-se la Scri (Nr_bloc, Scara) Descrierea relaiilor din view-ul Cheltuieli: Scri (Nr_bloc, Scara) Cheie primar: Nr_bloc, Scara Familii (Nr_mat, Fond_rulment, Fond_reparaii, Alte_fonduri) Cheie primar: Nr_mat Pli (Data, Nr_mat, Valoare, Restan) Cheie primar: Data, Nr_mat Cheie strin : Nr_mat referindu-se la Familii (Nr_mat) Chitane (Nr_chit, Nr_mat, Valoare, Data) Cheie primar: Nr_chit Cheie strin : Nr_mat referindu-se la Familii (Nr_mat) Furnizori (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str, Nr, Bl, Sc, Ap, Loc, Jud) Cheie primar: Cod_furnizor Cheie alternant: Cod_fiscal Cheltuieli (Nr_crt, Cod_furnizor, Cod_cheltuial, Nr_factur, Data_factur, Valoare) Cheie primar: Nr_crt Cheie strin : Cod_furnizor referindu-se la Furnizori (Cod_furnizor)

Pe_familii (Nr_crt, Nr_mat)

Page: 76

Ghid de proiectare a bazelor de date relaionale

Trk Mihly gr.7241

Cheie primar: Nr_crt Cheie strin : Nr_crt referindu-se la Cheltuieli (Nr_crt) Cheie strin : Nr_mat referindu-se la Familii(Nr_mat) Pe_scri (Nr_crt, Nr_bloc, Scara) Cheie primar: Nr_crt Cheie strin : Nr_crt Cheie strin : Nr_bloc, Scara

referindu-se la Cheltuieli (Nr_crt) referindu-se la Scri (Nr_bloc, Scara)

Anexa 4.6. Regulile date de ntreprindere n cazul modelului Locatari i Cheltuieli (1)Lista de pli se elaboreaz doar pe o lun ntreag. (2)Fiecare familie trebuie s declare la nceputul lunii dac va lipsii un membru al familiei toat luna. (3)Nici o familie nu va putea s se mute pn cnd nu si-a pltit toate datoriile.

Page: 77

Ghid de proiectare a bazelor de date relaionale

Trk Mihly gr.7241

Anexa 4.7. Modelul global de date al sistemului Asociaia de Locatari Locatari (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume) Cheie primar: Nr_mat Cheie strin : Nr_bloc, Scara Nenul, referindu-se la Scri (Nr_bloc, Scara) la tergere i la modificare Cascad. Familii (Nr_mat, Nr_pers, Nr_pers_prezente, Nr_chei, Fond_rulment, Fond_reparaii, Alte_fonduri) Cheie primar: Nr_mat Cheie strin : Nr_mat Nenul, referindu-se la Locatari (Nr_mat) la tergere i modificare Cascad. ef_de_scar (Nr_mat, Data_intrare_func) Cheie primar: Nr_mat Cheie strin : Nr_mat Nenul, referindu-se la Locatari (Nr_mat) la tergere i modificare Cascad. Scri (Nr_bloc, Scara, Lift) Cheie primar: Nr_bloc, Scara Apartamente (Nr_bloc, Scara, Apartament, Suprafaa, Cutii_potale, Nr_prize_tv) Cheie primar: Nr_bloc, Scara, Apartament Cheie strin : Nr_bloc, Scara Nenul, referindu-se la Scri (Nr_bloc, Scara) la tergere i modificare Cascad. Pli (Data, Nr_mat, Valoare, Restan) Cheie primar: Data, Nr_mat Cheie strin : Nr_mat Nenul, referindu-se la Familii (Nr_mat) la tergere Fr aciune, la modificare Cascad. Chitane (Nr_chit, Nr_mat, Valoare, Data) Cheie primar: Nr_chit Cheie strin : Nr_mat Nenul, referindu-se la Familii (Nr_mat) la tergere Fr aciune, la modificare Cascad. Furnizori (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Strada, Nr, Bl, Sc, Ap, Localitate, Judet) Cheie primar: Cod_furnizor Cheie alternant: Cod_fiscal Cheltuieli (Nr_crt, Cod_furnizor, Cod_cheltuial, Nr_factur, Data_factur, Valoare_factur)
Page: 78

Ghid de proiectare a bazelor de date relaionale

Trk Mihly gr.7241

Cheie primar: Nr_crt Cheie strin : Cod_furnizor Nenul, referindu-se la Furnizori (Cod_furnizor) la tergere Fr aciune, la modificare Cascad. Pe_familii (Nr_crt, Nr_mat) Cheie primar: Nr_crt Cheie strin : Nr_crt Nenul, referindu-se la Cheltuieli (Nr_crt) la tergere i modificare Cascad. Cheie strin : Nr_mat Nenul, referindu-se la Familii(Nr_mat) la tergere i modificare Cascad. Pe_scri (Nr_crt, Nr_bloc, Scara) Cheie primar: Nr_crt Cheie strin : Nr_crt Nenul, referindu-se la Cheltuieli (Nr_crt) la tergere i modificare Cascad. Cheie strin : Nr_bloc, Scara Nenul, referindu-se la Scri (Nr_bloc, Scara) la tergere i modificare Cascad. Personal (Nr_matricol, Nume, Data_naterii, Meseria, Data_angajrii) Cheie primar: Nr_matricol Alocate (Nr_matricol, Nr_bloc, Scara) Cheie primar: Nr_matricol, Nr_bloc, Scara Cheie strin : Nr_matricol Nenul, referindu-se la Personal (Nr_matricol) la tergere i modificare Cascad. Cheie strin : Nr_bloc, Scara Nenul, referindu-se la Scri (Nr_bloc, Scara) la tergere i modificare Cascad. Patrimoniu (Nr_inventar, Nr_bloc, Scara, Denumire, Inv_fix, Valoare) Cheie primar: Nr_inventar Cheie strin : Nr_bloc, Scara Nenul, referindu-se la Scri (Nr_bloc, Scara) la tergere i modificare Cascad. Achitri (Nr_crt, Nr_doc, Tip_op, Valoare_achit, Data) Cheie primar: Nr_Doc, Tip_Op Cheie strin : Nr_crt Nenul, referindu-se la Cheltuieli (Nr_crt) la tergere i modificare Cascad.

Page: 79