Ghid de proiectare a bazelor de date relaionale

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 limba e. !ceste limitri implic pierdere de timp i spaiu i posibilitatea de inconsisten a datelor. "istemul de baz de date # n opoziie cu vechiul sistem # d posibilitatea de a definii datele n afara programului i asigur controlul asupra manipulrii datelor. $efiniie% Baz de date% &ste o colecie parta at de date legate logic, proiectat pentru a satisface necesitile unui sistem informatic. $eci datele sunt str'nse ntr#o colectie unic i sunt folosite simultan de mai muli utilizatori. (edundana datelor este controlat prin normalizare, ceea ce implic o redundan minim. ) astfel de baz de date are nevoie de un sistem de gestiune a bazei de date. !cesta este un sistem de programe care fac posibil definirea, ntreinerea i accesul controlat la baza de date. *n astfel de sistem trebuie s conin limba ul de definire i limba ul de manipolare a datelor. Putem aminti urmtoarele limba e% "+L sau +B& ,limba e generale-, respectiv $B!"&, .)/ P(), P()0(&"", P!(!$)/ .a.m.d. ,limba e specifice-. 1um se stabilete structura bazei de date2 3ocmai prin proiectarea de care ne ocupm. 4n 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. $e 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. 4n timpul roiectrii logice este important implicarea viitorilor utilizatori n procesul de proiectare. 4n proiectarea fizic se decide cum va fi realizat practic modelul logic. !vanta ele i dezavanta ele sistemului de baze de date% !vanta ele ar fi urmtoarele%
Page% 5

controlul redundanei consistena datelor economia de spaiu pentru aceleai date controlul integritii datelor utilizarea standardelor d posibilitatea rspunsului la cereri variate i cu e6primri parial necunorcute la momentul proiectrii. productivitate crescut concuren crescut posibiliti crescute de recuperare n caz de eroare $ezavanta e% comple6itate crescut costul "0B$ cost crescut rezultat din cerine de hard costul trecerii de la un sistem la altul o eventual defeciune are un impact crescut, global

Page% 7

1. Modelarea ER (Entity-Relationship)
4n acest capitol vom descrie urmtoarele obiective% .olosirea modelului conceptual de nivel nalt pentru proiectarea de baze de date. 1onceptele modelului &(, model de nivel nalt. ) tehnic grafic de reprezentare a modelului &(. 8odul de identificare a problemelor ce pot aprea la crearea unui model &(. Limitele modelului &( primar i conceptele necesare pentru modelarea aplicailor comple6e. 1onceptele modelului &&( ,&nhanced &ntit9#(elationship-, numite i specializare:generalizare. ) tehnic grafic de reprezentare a specializri:generalizri n modelul &&(. *tilizarea produsului &(;in produs de Logic <or=s, pentru proiectarea bazelor de date, ceea ce include i modelul &(. 8odelul &( ,&ntit9#(elationship- este un model conceptual de nivel nalt dezvoltat de 1hen n 5>?@, care faciliteaz crearea de baze de date relaionale. 4n acest capitol, vom descrie conceptele preimare ale modelului &(, dup care vom identifica problemele care pot aprea la un model &( ,Ao;e, 5>B>-. Vom discuta deasemenea, problemele reprezentrii unor aplicatii, folosind modelul &( ,"chmidt i ";enson, 5>?C-. !v'nd n vedere c modelul &( are anumite limite n modelerea aplicatiilor, vom introduce un model mai comple6, modelul &&(, numit i specializare:generalizare. 1.1. Conceptele modelului Entity-Relationship 1onceptele primare ale modelului &( includ % tip de entitate, tip de relaie, atribute. 1.1.1. Tipuri de entiti $efiniie% Tip de entitate: &ste un obiect sau un concept, identificat de o ntreprindere, av'nd o e6isten independent. 3ipurile de entiti reprezint obiecte reale, din viaa de zi cu zi, av'nd proprietile lor, sau obiecte conceptuale, abstracte. $efiniie% Entitate: *n obiect sau un concept ce se poate identifica unic. *n tip de entitate conine mai multe entiti. *n tip de entitate se identific prin nume i list de atribute. ) baz de date conine n general mai multe tipuri de entiti. .iecare tip de entitate are propriile lui atribute. Putem clasifica aceste tiburi n tipuri slabe i tipuri tari. $efiniie% Tip slab de entitate: &ste un tip de entitate, a crui e6isten este dependent de un alt tip de entitate. $efiniie% Tip tare de entitate: &ste un tip de entitate, a crui e6isten nu depinde de nici un alt tip de entitate.
Page% D

&ntitile slabe se mai numesc dependente sau cubordonate iar cele tari printe sau dominante. (eprezentarea grafic a entitilor% &ntitile 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. &6emplu% nume entitate tare nume entitate slab

1.1.2. Atribute $efiniie% Atribute: Proprietaile unui tip de entitate sau de relaie. $efiniie% Domeniul atributului: *n set de valori ce se pot da acelui atribut. $omeniul unui atribut nu se poate definii totdeauna foarte e6act. $e e6emplu, atributul nume de familie poate lua orice nume de familie e6istent. &vident, acest atribut trebuie s fie un ir de caractere, dar oare ce caractere poate s conin2 *nele domenii se pot descompune n mai multe subdomenii. $e e6emplu data naterii se poate descompune in subdomeniile% an, lun, zi. !tributele se pot clasifica n simple sau compuseE cu o singur valoare sau cu mai multe valoriE respectiv derivate. $efiniie% Atribut simplu: !tribut care are doar o singur component i o e6isten independent. !ceste atribute nu se pot diviza mai t'rziu n mai multe atribute distincte. $efiniie% Atribut compus: !tribut care are mai multe componente i o e6isten independent. !ceste atribute se pot diviza n mai multe atribute simple. $e e6emplu atributul adres se poate descompune n atributele% strada, numr, ora, cod potal i jude. $ecizia 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. $efiniie% Atribut cu o singur valoare: Atribut care poate lua o singur valoare pentru fiecare entitate. 8a oritatea atributelor sunt atribute cu o singur valoare, ceea ce este indicat n proiectarea bazelor de date. $efiniie% Atribut cu mai multe valori: !tribut care poate lua mai multe valori pentru fiecare entitate. !tributele cu mai multe valori, trebuie s aib totdeauna o limit inferioar i una superioar. $efiniie% Atribut derivat: !tribvut a crei valoare se poate calcula din unul, sau mai multe alte atribute, care nu sunt neaprat atributele entitii n cauz. $e e6emplu atributul vrsta este derivat din atributul data naterii i data zilei n care se utilizeaz acest atribut. !lt e6emplu ar fi atributul numrul total de entiti, ceea ce se poate calcula, numr'nd entitile nregistrate.
Page% F

1hei% Gntuitiv, o cheie este un atribut, care determin unic o entitate dintr#un tip de entitate. 4n continuare, dm o definiie riguroas a cheii. $efiniie% Cheie candidat: *n atribut, sau un set de atribute, care identific unic o entitate ditr#un tip de entitate. $efiniie% Cheie primar: ) entitate poate s aob una sau mai multe chei candidat, din care doar una selectat este i primar. $ecizia referitoare la care din chile candidate s fie cheie primar este dependent de lungimea cheii. 1heia primar este de obicei cea mai scurt dintre cheile candidat. $efiniie% Cheie compus: ) cheie candidat care contine cel putin dou atribute. (eprezentarea grafic a atributelor% *n atribut se reprezint printr#o elips, legat de entitatea de care aparine cu o linie i etichetat cu numele atributului. &lipsa este punctat, dac atributul este un atribut derivatE respectiv dublat, daca poate lua mai multe valori. $ac un atribut este compus, atunci componentele atributului se reprezint n elipse legate printr#o linie de atributul compus. !tributurile care intr n componena cheii primare, se noteaz prin sublinierea numelui atributului. &6emplu% Humr bloc "cara Hume Locatari Humr matricol !dresa &ta !partament

4n acest e6emplu, entitatea Locatari, fiind o entitate tare, are urmtoarele atribute% Numr matricol, Nume i Adresa. $intre aceste atribute, atributul Numr matricol este cheie primarE atributul Adresa este atribut compus, care se descompune n Numr bloc, Scara, Etaj i Apartament. 1.1.3. Tipuri de relaii $efiniie% Tip de relaie: !sociere ntre tipuri de entiti. $efiniie% elaie: !sociere ntre entitti, c'nd asocierea include un tip de entitate dintre toate tipurile participante. (eprezentarea grafic a relaiilor% (elaiile se reprezint printr#un romb etichetat cu numele relaiei. (ombul se deseneaz cu linie dubl, dac relaia leag o entitate slab de entitatea tare de care aparine.
Page% C

$efiniie% !radul relaiei: Hmrul entitiilor participante n relaie. &ntitiile dintr#o relaie se numesc participani. Humrul lor d gradul relaiei. $ac intr#o relaie sunt doi participani, atunci relaia se numete binar. $efiniie% elaie recursiv: (elaie n care aceleai entiti particip n roluri diferite. 4n 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 !tributele descrise mai sus, se pot asocia i relaiilor. !ceste atribute se reprezint grafic, ca i atributele entitiilor, cu deosebirea c legtura nu este cu o entitate, ci cu o relaie. !dic linia leag elipsa de rombul ce semnific relaia. 1.2. Structuralitatea " analizm acum restriciile ce pot aprea la includerea unei entiti participante ntr#o relaie. !vem dou tipuri mari de restricii% cardinalitatea i prticiparea. 1.2.1. Cardinalitatea $efiniie% Cardinalul este numrul relaiilor posibile pentru o entitate partricipant. 8a oritatea relaiilor au gradul doi, care pot fi% unu#la#unu ,5%5-, unu#la#multe ,5%8-, sau multe#la#multe ,8%H-. (elaiile unu#la#unu% 4n relaiile unu#la#unu, o entitate este legat de cel mult o entitate din partea cealalt a relaiei. !ceast relaie se reprezint grafic prin etichetarea arcului dintre relaie i entitate cu cardinalul relaiei, adic cu 5. (elaiile unu#la#multe% (elaia de tip unu#la#multe are cardinalul 5 n st'nga i H n dereapta. $eci o entitate participant este legat n relaia respectiv de I, 5, sau mai multe entiti. &6emplificm acest tip de relaie prin relaia J"unt locuiteK dintre tipurile de entiti J"criK, respectiv JLocatariK.

!tribute HrLbloc "cara HrLbloc "cara HrLbloc "cara

"cri "c.! "c.B "c.1

"unt locuite de (5 (7 (D
Page% @

Locatari .am.5 .am.7 .am.D

!tribute HrLmat Humele HrLmat Humele HrLmat Humele

"igura #.#. &6emplu de relaie 5%8 4n reprezentarea grafic a relaiilor, relaia unu#la#multe se noteaz cu etichetarea arcului cu 5 n partea st'ng i cu H n partea dreapt. $in e6emplul de mai sus observm c dac relaia direct este de unu#la#multe, atunci relatia invers este de unu#la#unu. (elaiile multe#la#multe% !cest 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. $eci, 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 ,H%8-. 1.2.2. Participarea $efiniie% $articiparea determin dac e6istena unei entiti depinde sau nu de relaia cu o alt entitate. Participarea poate fi de mai multe tipuri% total i parial. 4n cazul participrii totale, toate entitiile particip n relaia dat. 4n caz contrar participarea se numete parial. 4n diagrama &( aceste tipuri de relaii se reprezint prin arc cu linie dubl pentru participarea total, respectiv cu linie simpl pentru participarea parial. Pentru participarea parial, e6ist un mod de notaie prin care se eticheteaz arcele relaiei cu perechea de numere ce reprezint minimul, respectiv ma6imul entitiilor participante la relaie. 1.3. Problemele modelului ER 4n acest capitol vom e6amina numeroasele probleme ce pot aprea la modelarea unei baze de date. !ceste probleme se refer la capcanele care pot aprea la definirea relaiilor ntre tipuri de entiti. !mintim dou tipuri mari de capcane% de tip labirint ,fan trap-, respectiv de tip prpastie ,chasm trap-. $efiniie% "an trap ,capcan de tip labirint-% !cest tip de capcan reprezint cazul n care modelul reprezint o relaie ntre dou tipuri de entiti, dar calea dintre cele dou membrii este ambigu. 1u alte cuvinte, pornind de la o entitate, nu se tie ca dup parcurgerea cii relaiilor, la ce entitate se a unge n partea cealalt. !ceast capcan se poate elimina prin rearan area ordinii relaiilor dintre cele dou tipuri de entiti. 1ellalt tip de capcan este% $efiniie% Chasm trap ,capcan de tip prpastie-% !cest tip de capcan se descrie prin faptul c modelul sugereaz e6istena relaiei ntre cele dou tipuri de entitate, dar calea dintre tipurile de entiti nu e6ist. !ceast problem provine din participarea parial a unor entiti la una dintre relaii. Problema se poate rezolva prin introducerea unei relaii directe.

Page% ?

1.4. Modelul Enhanced Entity-Relationship (EER 8odelul &(, discutat n capitolele de mai sus, este adecvat pentru descrierea multor scheme de baze de date. $in 5>BI s#au dezvoltat foarte mult aplicaiile care folosesc baze de date. 8odelul &( nu mai era suficient pentru reprezentarea comple6elor scheme de baze de date. $e aceea s#au introdus alte concepte n modelul &(, dezvolt'nd modelul &&(. 8odelul &&( include toate conceptele modelului &(, plus alte completri devenite necesare. !ceste concepte sunt nou introduse sunt% specializarea:generalizarea, categorisirea i ncapsularea. 4n acest capitol vom descrie conceptele de baz a modelului &&( i anume, specializare:generalizare. "pecializarea:generalizarea este n str'ns legtur cu modul de desciere a tipurilor de entiti n superclase i subclase, precun i de motenirea atributelor. $e aceea vom descrie aceste concepte. 1.4.1. Superclasele i subclasele tipurilor de entiti Vom descrie aceste concepte, av'nd ca e6emplu tipul de entitate JLocatariK. $efiniie% %uperclas% "uperclasa este un tip de entitate care include subclase distincte reprezentate ntr#un model de date. $efiniie% %ubclas % "ubclasa este un tip de entitate care are un rol distinct i este membru al unei superclase. $e e6emplu superclasa JLocatariK se divizeaz n dou subclase i anume% JMef de scarK i J.amiliiK. (elaia dintre o superclas i o subclas se numete relaie superclas:subclas. !ceast relaie este de tip unu#la#unu. (elaia JLocatari:.amiliiK de e6emplu, este o astfel de relaie. .iecare membru al unei subclase este membru i n superclas, dar are un rol diferit. &6ist subclase case se suprapun, adic e6ist membrii ntr#o subclas care apar i n cealalt subclas. Putem observa c e6emplul de mai sus este e6act de acest tip, pentru c eful de scar poate s fie i cap de familie. $e ce se folosete clasificarea n subclase2 (spunsul este simplu de observat direct din e6emplul dat. $ac nu am clasifica entitiile din tipul de entitate JLocatariK, atunci ar trebui s memorm informaiile specifice efului de scar i capului de familie pentru fiecare locatar. $eoarece ma oritatea 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 .iecare subclas are ca atribute comune, atributele superclasei n care aparine. $eci fiecare membru al unei subclase se caracterizeaz prin atributele superclasei i alte atribute specifice subclasei. $e e6emplu subclasa Familii se caracterizeaz prin toate atributele superclasei Locatari ,Numr matricol, Numr bloc, Scara, Etaj, Apartament i Nume-, pe l'ng care mai are i ate atribute specifice ,Numr persoane, Numr persoane prezente, etc..iecare subclas poate s aib subclase, crendu#se un arbore de clase, care se numete ierarhie de tipuri. !ceast ierarhie de tipuri include alte denumiri de ierarhii
Page% B

i anume% ierarhia de specializri ,de e6emplu, tipul de entitate Familii este o specializare a tipului de entitate Locatari- i ierarhia de generalizri ,de e6emplu, Locatari este o generalizare a tipului de entitate Familii-. 1.4.3. Specializarea $efiniie% %pecializare este un proces de ma6imizare a diferenelor unor membrii ale unei entiti, identific'nd caracteristicile distincte. "pecializarea este o apro6imare top#do;n a definirii unor superclase, mreun cu subclasele lor. (elaia superclas:subclas se reprezint grafic printr#un arc de la superclas la un cerc, care la r'ndul lui este legat cu un arc de subclas. Pe arcele de la subclase se deseneaz un semn de incluziune de la subclas la superclas. !ceste semn de incluziune indic direcia relaiei superclas:subclas. !tributele specifice doar subclasei sunt ataate direct la dreptunghiul care reprezint subclasa. 3oate aceste notaii se e6emplific n figura de mai os% Humr matricol Humr bloc Locatari Mef de scar $ata intrrii n funcie 4n e6emplul de mai sus tipul superclasa Locatari se compune din mai multe subclase% ef de scar i Familii. "uperclasa Locatari va avea ca membrii pe toi locatarii unei scri. 4ntre aceti locatari, unii sunt capi de familii iar alii efi de scar. !ceti membrii ai tipului de entitate Locatari vor aprea ca membrii i n subclasele ef de scar, respectiv Familii. $efiniie% %ubclas parta&at se numete subclasa care are mai multe superclase. 8embrii din subclasa parta at sunt membrii n fiecare dintre superclase. $e aceea ei motenesc atributele fiecrei superclase o astfel de motenire se numete mo'tenire multipl. 4n 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 $efiniie% !eneralizare se numete procesul de minimizare a diferenelor dintre entiti, pentru identificarea caracteristicilor comune. Procesul de generalizare este o apro6imare bottom#up a superclaselor, din subclasele originale. $eci generalizarea este inversa specializrii. $e e6emplu dac privim tipurile de entiti .amilii i Mef de scar, vom observa c unele atribute ale lor
Page% >

.amilii Humr persoane

!dresa

caracterizeaz ambele tipuri. $e aici rezult necesitatea crerii unei superclase care s conin toate atributele comune celor dou tipuri. 1.4. . !e"urile specializrii i "eneralizrii 4n acest capitol vom discuta despre regulile ce trebuie aplicate n cazul specializrii sau al generalizrii. Prima regul se numete regula dis&unciei. !ceast regul specific dac subclasele unei clase sunt dis uncte, adic un membru al superclasei aparine cel mult uneia dintre subclase. ) specializare dis unct se reprezint cu un J dK nscris n cercul care leag subclasele de superclase. $ac subclasele nu sunt dis uncte, adic un membru al superclasei poate s aparin la mai multe subclase, atunci subclasele respective se numesc non dis&uncte i se noteaz cu J oK n cercul care leag subclasele de superclase. 4n e6emplul nostru subclasele Sef de scar i Familii # care sunt subclasele clasei Locatari # sunt non dis uncte. ! 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. 4n cazul participrii pariale nu toi membrii superclasei iau parte ntr#o subclas. !cest tip de participare se reprezint cu linie simpl ntre superclas i cerc. 4n e6emplul nostru avem o participare parial n cazul superclasei Locatari, cu subclasele ef de scar i Familii. 1ele dou reguli se aplic distinct la procesele de specializare, sau generalizare. $e aceea putem avea patru tipuri de specializri% dis unt total, dis unct parial, non dis unct total, sau non dis unct parial. 1.!. "escrierea cerin#elor sistemului $%socia#ie de locatari& - Crearea unui model EER 4n acest capitol vom demonstra crearea unui model &&(. Vom descrie cerinele sistemului informatic pentru asociaia de locatari, dup care vom identifica entitile, relaiile, cardinalitatea i participarea relaiilor i atributele asociate entitilor. $up toate aceste identificri vom crea diagrama &&( asociat aplicaiei. 1. .1. #escrierea siste$ului in%or$aic &Asociaia de locatari' ,5- ) 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. .iecare dintre scri se compune din apartamente, av'nd informaii prin care se poate face relaia la scri, precum i alte informaii const'nd din% numr apartament, suprafaa, numrul cutiilor potale, a prezelor tv., a legturilor la coul de fum i altele. ,7- Locatarii sunt identificai printr#un numr matricol unic n toat asociaia de
Page% 5I

,D-

,F,C,@,?-

,B,>-

locatari. Gnformaiile despre ei sunt memorate n numr bloc, scara, eta , apartament # reprezent'nd adresa # i nume. *nii dintre locatari pot fii efi de scar si:sau capi de familii, ceea ce implic alte informaii n plus pentru aceste persoane. !ceste 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. 4n fiecare lun se primesc facturi de la diferii furnizori, reprezent'nd cheltuielile asociaiei de locatari. !ceste 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. !ceste scheltuieli pot fii pe una sau mai multe scri sau pe una sau mai multe familii. 1heltuielile 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. $espre pli se memoreaz o legtur la capul de familie care a efectuat plata, numrul, data i valoarea chitanei. .urnizorii de la care vin facturile la asociaia de locatari, se identific unic printr# un cod local, sau dup codul fiscal. Pe l'ng aceste informaii mai memorm informaii despre denumire, contul, banca i adresa sediului. 1alculul pliilor pentru locatari se va face la nceputul fiecrei luni, pentru luna anterioar, memor'nd data efecturii calculului, numrul matricol al capului familiei pentru relaie, valoarea i restana pentru luna aceea. $up listarea plilor nu se mai admit modificri. .iecare scar este ntreinut de un personal identificat de un numr matricol ,alta dec't la locatari- i av'nd informaiile% legtura la scara unde lucreaz, numele, data naterii i a anga rii i meseria. 4n asociaia de locatari pot fi mi loace fi6e i obiecte de inventar, identificate prin numrul de inventar i av'nd ntre informaii legtura la scara unde sunt amplasate. "e mai poate memora despre ei denumirea, valoarea i valoarea amortizat.

1. .2. Crearea $odelului ((! 4n acest capitol von demonstra crearea modelului &&(. Vom crea modelul &&( pentru J!sociaia de locatariK, folosind descrierea de mai sus. !dentificarea tipurilor de entiti" La nceput identificm tipurile de entiti din specificaiile de mai sus% "cari !partamente Locatari Mef de scar .amilii
Page% 55

1heltuieli !chitri Patrimoniu Personal )biecte de inventar

Pli 1hitane

.urnizori

!dentificarea tipurilor de relaii" Vom identifica tipurile principare de relaii. (elaiile sunt reprezentate de verbele lor n tabela de mai os. Tip de entitate "cri Tip de relaie sunt locuite de se compun din sunt #ntreinute de se folosete trebuie s plteasc $rimesc $rovoac se calculeaz pentru se calculeaz pentru se ac%it prin Tip de entitate Locatari !partamente Personal Patrimoniu Pli 1hitane 1heltuieli "cri .amilii !chitri

.amiliile .urnizorii 1heltuielile

&eterminarea cardinalitii i a participrii #n tipurile de relaii" 1onsiderm relaia "cri#le sunt locuite de Locatari. ) singur scar este locuit de mai muli locatari. $eci p'n acum cardinalitatea este de 5%8, ns trebuie s verificm i relaia invers # Locatarii locuiesc pe "cri # unde se observ c un locatar locuiete pe o singur scar. $eci n final, cardinalitatea relaiei este 5%8. 4n continuare fie relaia 1heltuielile se calculeaz pentru "cri. )bservm c putem avea mai multe scri la care s se refere o cheltuial, precum i mai multe cheltuieli pentru o scar. $eci cardinalul relaiei este de H%8. " analizm acum participarea la relaie a membriilor tipurilor de entiti% .ie relaia "cri#le sunt locuite de Locatari. Putem avea cazul n care o scar s nu fie locuit deloc de locatari. 4n cazul relaiei inverse nu putem avea cazul n care un locatar s nu locuiasc pe nici o scar. $eci relaia direct este parial, iar cea invers este total. 1ardinalitatea i participarea celorlaltor relaii este artat n urmtorul tabel% 3ip de entitate "cri 3ip de relaie sunt locuite de se compun din sunt #ntreinute de se folosesc trebuie s plteasc primesc provoac se calculeaz pentru 3ip de entitate Locatari !partamente Personal Patrimoniu Pli 1hitane 1heltuieli "cri 1ard. 5%8 5%8 5%8 5%8 5%8 5%8 5%8 8%H Participarea $irect Gnvers parial total total total partial total parial total parial parial parial parial parial total total parial

.amiliile .urnizorii 1heltuielile

Page% 57

1heltuielile

se calculeaz pentru se ac%it prin

.amilii !chitri

8%H 5%8

total total

parial total

!m observat c relaia 1heltuilile sunt de tipul 3ip cheltuial are cardinalul 8%5. $e accea av'nd n vedere convenia c relaiile se denumesc n direcia 5%8 vom schimba numele relaiei n 3ip cheltuial este tipul unei 1heltuieli. !ndentificarea atributelor asociate entitiilor" Vom identifica atributele entitiilor, atribute ce descriu caracteristicile entitiilor. !ceste atribute sunt trecute n urmtorul tabel% Tip entitate "cri !partamente Atribute HrLbloc "cara Lift !partament HrLbloc "cara "uprafaa 1utiiLpotale HrLprizeLtv HrLmat HrLBloc "cara &ta !partament Hume $ata HrLmat Valoare (estan 1odL.urnizor $enumire 1odLfiscal 1ont Banca "trada Hr Bl "c !p Localitate Nude HrLmatricol
Page% 5D

Tip entitate Mef de scar

.amilii

Locatari

Pli

.urnizori

1hitane

1heltuieli

!chitri

Personal

Atribute HrLmat HrLBloc "cara &ta !partament Hume $ataLintrareLfunc HrL8at HrLBloc "cara &ta !partament Hume HrLpers HrLpersLprezente HrLchei .ondLrulment .ondLreparaii !lteLfonduri HrL1hit HrL8at Valoare $ata HrL1rt 1odL1heltuial 1odL.urnizor HrLfactur $ataLfactur ValoareLfactur HrLcrt HrL$oc 3ipL)p

HrLbloc "cara Hume $ataLnaterii 8eseria $ataLanga rii

Patrimoniu

ValoareL!chit $ata HrLinventar HrLbloc "cara $enumire GnvL.i6 Valoare

&eterminarea c%eilor canditat i c%eilor primare" Vom analiza cheile candidat al fiecrei tip de entitate i vom alege una din ele s fie cheie primar. $e e6emplu n tipul de entitate Locatari aven o cheie candidat, numit HrLmat. $eci aceast cheie va fi cheia primar. 4n general cheia cea mai simpl este aleas n funcia de cheie primar. 4n tabela urmtoare specificm cheile primare si alternante ale fiecrei tip de entitate% Tip entitate "cri !partamente Locatari Mef de scar .amilii Pli 1hitane 1heltuieli .urnizori !chitri Personal Patrimoniu Cheie primare HrLbloc, "cara HrLbloc, "cara HrL8at HrL8at HrL8at $ata, HrL8at HrL1hit HrL1rt 1odL.urnizor HrL$oc, 3ipL)p HrLmatricol HrLinventar Chei alternante

1odLfiscal

Specializarea sau generalizarea tipurilor de entiti" 4n final putem lua decizia de a specializa o clas. $ac avem tipuri de entiti care au aceleai atribute, atunci putem generaliza aceste tipuri de entiti. $e e6emplu 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. $eci putem generaliza tipurile de entiti ef de scar i Familii la tipul de entitate Locatari. $up generalizare vom avea o relaie de specializare:grneralizare, care nu este dis unct i este parial. &esenm diagrama EE'" .olosind toate informaiile descrise mai sus, desenm diagrama &&( a sistemului informatic al J!sociaiei de locatariK.
Page% 5F

Scule CAS( pentru crearea $odelului (!. 4n acest capitol vom descrie produse 1!"& ,1omputer !ided "oft;are &ngineering- care ne a ut la proiectarea bazelor de date relaionale. La elaborarea prezentei lucrri am folorit produsul &(;in produs de Logic <or=s. La intrare n program fereastra va arta n modul urmtor%

Pentru crearea unui model &( se folosesc butoanele din fereastra &(;in 3oolbo6. 1u aceste butoane se poate proiecta baza de date, desen'nd tabelele i relaiile dintre ele. 1um crem o entitate2 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-. $easupra dreptunghiului apare numele tipului de entitate. $ac entitatea este dependent, atunci se selecteaz butonul &6emplu de entiti% .

Page% 5C

)ocatari *r+Mat (ta, *r+-loc ./01 Aparta$ent Scara ./01 *u$e

Plati #ata *r+Mat ./01 2aloare !estanta

Humele acestei entitilor sunt Locatari # entitate independent # i Pli # entitate dependent. 4n cazul entitii Locatari, seciunea chei principale se compune din c'mpul HrL8at iar c'mpurile de sub linie sunt atributele asociate entitii. 4n 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 1um notm cheile candidate2 La editarea numelui atributului care este coninut ntr#o cheie candidat, se trece n continuarea numelul te6tul% ,!On-, unde n reprezint numrul chei candidat de care aparine atributul. 4n e6emplul nostru Nume este cheie candidat. 1um evideniem un tip de relaie2 "electm butonul corespunztor tipului de relaie dorit dintre tipurile , reprezent'nd relatie JidentificareK de cardinal 5%8, H%8 respectiv relaie JneidentificareK. $iferena ntre relaiile JidentificareK i JneidentificareK 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. &6emplu de tip de relaie% "cri se calculeaz pentru

1heltuieli

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

.amilii
Page% 5@

Mef de scar

"imbolul 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. $eci participarea este parial. "uportul produsului &(;in pentru normalizarea bazei de date% &(;in are suport pentru normalizarea bazei de date, dar nu are implementat un algoritm de normalizare. ! utorul acordat proiectantului bazei de date const n avertizarea acestuia n cazul unor erori la normalizare. "uportul .ormei Hormale *nu% 4n moledul &( atributele sunt identificate prin nume. &(;in accept orice nume pentru atribute, cu urmtoarele e6cepii% !vertzeaz n cazul utilizrii unei denumiri de tip de entitate de dou ori ,depinde de setaria opiune JHume unicK-. !vertizeaz n cazul folosirii de dou ori a aceluiai nume de atribut, cu e6cepia numelui de rol. &(;in nu distinge dac un atribut conine sau nu mai multe informaii. $e e6emplu se accept i denumirea JHumele copiilorK ceea ce poate reprezenta un tablou n acel atribut. "uportul pentru .orma Hormal $oi i 3rei% &(;in nu cunoate dependenele funcionale din baza de date, dar poate a uta la priectarea bazei de date n forma normal doi sau trei. $e e6emplu avertizeaz n cazul n care o cheie care migreaz ,n cazul unui relaii-, apare de dou ori n tipul de entitate. !cesta poate s apar n cazul n care sunt mai multe relaii ntre dou tipuri de entiti. Potem opta pentru pstrarea cheii de dou ori, d'nd nume diferite c'mpurilor, sau pentru unificarea atributelor ce compun cheia. Baza de date se poate proiecta pe vie;#uri, &(;in gener'nd automat imaginea ntregii baze de date. "e poate selecta modul de reprezentare a bazei de date, opiunile fiind% nivel de entitate, la nivel de chei primare, sau la nivel de atribute. 3oate aceste opiuni fiind disponibile pentru nume logice i fizice. $up proiectarea bazei de date, acesta se poate e6porta n mai multe formate disponibile, dintre care amintim% .o6Pro, !cces, )racle, Gngres, !":FII, Gnformi6, Progress i altele. Baza de date a sistemului de gestiune a !sociaiei de locatari proiectat cu &(;in este urmtorul%

Page% 5?

)ocatari *r+Mat (ta, *r+-loc ./01 Aparta$ent Scara ./01 *u$e Sunt locuite de Au c3eltuieli

Scari *r+-loc Scara )i%t Patri$oniu Pe scari Scara ./01 *r+Crt ./01 *r+-loc ./01 Contin *r+7n4entar *r+-loc ./01 Scara ./01 #enu$ire 7n4+/i8 2aloare Se co$pun din Aparta$ente *r+-loc ./01 Scara ./01 Aparta$ent Supra%ata Cutii+postale *r+prize+t4

Personal *r+$atricol *u$e #ata+nasterii Meseria #ata+an"a,arii (ste

/urnizori Cod+/urnizor #enu$ire Cod+%iscal .A011 Cont -anca Strada *r -l Sc Ap )ocalitate 6udet

Alocate *r+$atricol ./01 *r+-loc ./01 Scara ./01

Sunt

Se calculeaza Se calculeaza Se% de scara *r+Mat ./01 #ata+intrare+%unc /a$ilii *r+Mat ./01 *r+pers *r+pers+prezente *r+c3ei /ond+rul$ent /ond+reparatii Alte+%onduri Pe %a$ilii *r+Crt ./01 *r+Mat ./01 Au c3eltuieli Plati #ata *r+Mat ./01 2aloare !estanta Trebuie sa plateasca C3eltuieli *r+Crt Cod+/urnizor ./01 Cod+c3eltuiala *r+%actura #ata+%actura 2aloare+%actura Pro4oaca Se ac3ita

C3itante *r+C3it *r+Mat ./01 2aloare #ata

Ac3itari *r+#oc Tip+5p *r+Crt ./01 2aloare+Ac3it #ata

Pri$esc

Page% 5B

2. Nor alizarea bazei de date

4n acest capitol vom discuta despre% Hecesitatea normalizrii Problemele asociate cu informaiile redundante n r'nduri. Gdentificarea tipurilor variate de anomalii ce pot aprea la actualizare% inserare, tergere i modificare. Procesul de normalizare. 1onceptul de dependen funcional, modalitatea de a grupa atributele n relaii 1um utilizm dependenele funcionale, pentru a grupa atributele n relaii care sunt n forme normale cunoscute2 1um definesc relaiile, formele normale2 1um derulm procesul de normalizare2 1um identificm prima ,5H.-, a doua ,7H.- i a treia ,DH.- form normal, resprctiv forma normal Bo9ce#1odd ,B1H.-2 2.1. 'ecesitatea normali()rii 1'nd proiectm o baz de date, dorina noastr este de a reprezenta c't mai corecte informaiile i s diminum c't mai mult posibilitatea de a a unge la informaii eronate ,dac nu putem elimina de tot acest nea uns-. Pentru a a unge la aceast performan, trebuie s folosim normalizarea. $efiniie% (ormalizare% ) 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 &. .. 1odd ,5>?7-. Gniial s#au propul trei forme normale, numerotate de al unu la trei. 8ai t'rziu s#a inclus nc o form normal, numit Bo9ce#1odd, dup numele celor care l#au introdus% (. Bo9ce i &. .. 1odd. .ormele normale cele mai folosite sunt% forma normal D i forma normal Bo9ce#1odd. &6ist i forme normale mai tari # forma normal F ,FH.- i forma normal C ,CH.- # 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 B1H.- i dependenele funcionale cu atributele asociate. Hormalizarea d posibilitatea proiectantului bazei de date, pentru a efectua o seria de teste pe baza de date, toate aceste teste duc'nd la prevenirea posibilitii de a aprea anomalii la actualizarea bazei de date. Pentru a ilustra procesul de normalizare, vom folosii e6emple din sistemul informatic Asociacie de locatari.

Page% 5>

2.2. Redundan#a *n in+orma#ii ,i anomalii la actuali(are Partea cea mai important a proiectrii bazei de date este de a grupa atributele n relaii cu scopul de a minimiza redundana n informaii i spaiul ocupat de fiiere pe suportul magnetic. .ie relaia .urnizoriL1heltuieli e6emplificat mai os. La e6emple vom simplifica atributele asociate entitiilor. Cod Denumire Cod (r. "urn. )iscal Crt. .5II (omgaz (57DFC@? 5 .5II (omgaz (57DFC@? 7 .55I (enel (?@CFD75 D .55I (enel (?@CFD75 F "igura +.# (elaia .urnizoriL1heltuieli Cod Chelt. 15C 15@ 15I 155 Denumire Cheltuial 1helt pt. nclzire 1helt pt. buctrii 1helt cu iluminatul 1helt pt. func. liftului *aloare 5CIIIII CIIIII DIIIIII 7IIIII

$ependenele funcionale pentru relaia .urnizoriL1heltuieli de mai sus sunt urmtoarele% .urnizori ,1od..urn., $enumire, 1od fiscal1heltuieli ,Hr.1rt., 1od chelt., 1od.furn., Valoare3ipLcheltuiala ,1od.1helt., $enumire chelt..urnizoriL1heltuieli ,Hr.1rt., 1od chelt., 1od furn., $enumire chelt., $enumire, 1od fiscal, Valoare4n acest e6emplu, informaia despre furnizor devine redundant. $etraliile despre furnizor se repet la fiecare introducere a unei cheltuieli noi. 4n dependenele funcionale specificate pentru entitatea (%eltuieli, apare doar codul furnizorului. !nalog, denumirea cheltuielii, apare i ea n plus fa de entitatea (%eltuieli. ) alt problem serioas datorat redundanei bazei de date, sunt problemele de actualizare a informaiei stocate. !ceste probleme se pot clasifica n anomalii de inserare, modificare, sau tergere. 2.2.1. Ano$alii de inserare !nomaliile de inserare se pot clasifica n dou tipuri mari% Pentru a adauga detaliile despre o cheltuial ctre un furnizor, n relaia Furnizori)(%eltuieli trebuie obligatoriu adugate i detaliile despre furnizorul n cauz, chiar dac el e6ist de a n baza de date. !ceast anomalie poate duce la apariia aceluiai furnizor, av'nd introduse detalii diferite n nregistrri diferite. Pentru a aduga detaliile unui furnizor nou n relaia Furnizori)(%eltuieli, trebuie neaprat adugat i o cheltuial pentru asociaia de locatari ctre acel furnizor. 4n 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. 1um Nr*(rt* este cheia primar n relaia Furnizori)(%eltuieli, introducerea de date vide n acest c'mp va strica
Page% 7I

integritatea entitii. 2.2.2. Ano$alii de ter"ere 4n cazul tergerii ultimei cheltuieli a asociaiei de locatari ctre un furnizor, se va terge i furnizorul. $eci toate detaliile introduse despre acel furnizor vor fi pierdute, ceea ce duce la obligativitatea reintroducerii datelor la o nou folosire al acelui furnizor. 4n cazul entitii separate pentru cheltuieli i furnizori, dac se terge i ultima cheltuial ctre un furnizor, datele despre furnizor rm'n totui n entitatea Furnizori. 2.2.3. Ano$alii de $odi%icare $ac n relaia .urnizoriL1heltuieli dorim s schimbm valoarea unui atribut al unui furnizor, va trebui s schimbm datele la fiecare apariie a acelui furnizor. $e e6emplu dac dorim s schimbm codul fiscal al furnizorului cu codul .5II, va trebui s achimbm acest atribut n dou locuri. $ac n timpul modificrilor, care poate dura destul de mult, intervine i un incident n uema cruia vor rm'ne nregistrri nemodificate, atunci baza de date devine inconsistent. !ceast anomalie se poate evita prin folosirea a dou entiti distincte precum 1heltuieli i .urnizori. 4n acest caz dac trebuie s modific un atribut al unui furnizor, va trebui s#o modific doar ntr#un singur loc% n entitatea .urnizori. 2.3. "ependen#e +unc#ionale *nul din cele mai importante concepte asociate normalizrii este dependena funcional. $ependena funcional descrie relaia dintre atribute. 4n acest capitol vom descrie conceptul de dependen funcional, urm'nd ca n capitolele urmtoare s descriem procesul de nlormalizare a bazei de date. 2.3.1. #e%iniia dependenei %uncionale $efiniie% Dependen )uncional: $escrie relaia dintre atribute. $e e6emplu dac atrubutul ! este n relaia ( cu atributul B, atunci atributul B este dependent funcional de atributul ! ,notat% ! B-, dac orice valoarea al lui ! este asociat prin relaia ( cu e6act o valoare a atributul B. $ependena funcional este o proprietate a semanticii atributelor n relaii. "emantica indic atributele care sunt n relaie i specific dependenele funcionale dintre atribute. 1onsiderm o relaie ntre dou atribute ! i B, unde atributul B este dependent funcional de atributul ! ,atributele ! i B pot fi compuse din mai multe atribute-. 1u
Page% 75

alte cuvinte, dac tim valorile c'mpului !, atunci analiz'nd valorile lui B n relaia cu !, vom considera c pentru valori diferite al lui ! # care fiind cheie, trebuie s aib valori diferite # avem valori diferite i pentru c'mpul B. $ependena funcional dintre dou c'mpuri se reprezint grafic n urmtorul mod% ! "igura +.+ $iagrama dependenei funcionale $efiniie% Determinant: Humim determinantul unei relaii funcionale, atributul, sau mulimea atributelor din partea st'ng a sgeii. 4n acest capitol vom ignora dependenele funcionale triviale, adic acele relaii de tipul !B, n care B este dependent de un subset de atribute al lui !. Pentru a e6emplifica dependenele funcionale, considerm urmtorul e6emplu% &6emplu% 1onsiderm atributele (od furnizor i &enumire. Pentru un anumit cod de furnizor, putem determina denumire acelui furnizor. !dic denumirea este dependent funcional de cod furnizor. $ependena invers nu este adevrat pentru c pot e6ista aceleai denumiri cu coduri diferite. (elaia dintre cod furnizor i denumire este de 5%5, iar relaia invers este de 5%8. " identificm dependenele descris mai sus% Hr. 1rt., 1od .urn., 1od 1helt. Hr. 1rt., 1od .urn., 1od 1helt. Hr. 1rt., 1od .urn., 1od 1helt. Hr. 1rt., 1od .urn., 1od 1helt. 1od .urnizor 1od .urnizor 1od fiscal 1od fiscal 1od 1helt. funcionale din relaia .urnizoriL1heltuieli $enumire 1od fiscal $enumire cheltuial Valoare $enumire 1od fiscal $enumire 1od .urnizor $enumire cheltuial B

4n aceast relaie avem > dependene funcionale, care au determinantele ,Hr. 1rt., 1od .urn., 1od 1helt.-, 1od fiscal, 1od .urn. i 1od 1helt. Putem evidenia aceste dependene i ntr#un alt format% Hr.1rt., 1od .urn., 1od 1helt. $enumire,1od fiscal, $enumire cheltuial, Valoare 1od .urn. $enumire, 1od fiscal 1od fiscal $enumire, 1od .urn. 1od 1helt. $enumire cheltuial
Page% 77

Pentru a identifica cheile candidate, trebuie s identificm atributul, sau grupul de atribute care determin unic fiecare nregistrare al acestei relaii. $ac avem mai mult de o cheie candidat, atunci va trebui s identificm i o cheie primar. 3oate atributele care nu aparin cheii primare, depind funcional de cheia primar. 4n aceast ipostaz este grupul de atribute ,Hr. 1rt., 1od .urn., 1od 1helt.-. !tributele 1od .urn., 1od fiscal i 1od 1helt. "unt determinani, dar nu sunt chei candidat. 1onceptul de dependen funional este conceptul central al normalizrii, ceea ce vom descrie n capitolele urmtoare. 2.4. Procesul de normali(are Hormalizarea este un proces formal de analiz a relaiilor bazate pe chei primare ,sau pe baza cheilor candidat n cazul B1H.-. Hormalizarea presupune urmarea unor reguli prin care baza de date se poate normaliza p'n la un anumit grad. $ac o cerin nu este satisfcut, relaia trebuie dezcompus n mai multe relaii, care individual satisfac cerinele formei normale. Hormalizarea se e6ecut trec'nd prin toate formele nornale, p'n la forma normal cerut. La proiectarea unei baze de date trebuie s a ungem cel puin la forma normal unu, dar ca s evitm toate anomaliile descrise mai nainte, este recomandat aducerea bazei de date la B1H.. 4n figura urmtoare evideniem relaia dintre diversele forme normale. )bservm c unele din relaiile n 5H. este i n 7H., dintre care unele n DH. i aa mai departe. 5H. 7H. DH. B1H. FH. CH. H. "igura +.,. Glustrarea grafic a relaiei dintre formele normale. 2.!. -orma 'ormal) .nu (1'4nainte s discutm despre forma normal unu, vom da definiia stadiului dinainte de aceast form normal. $efiniie% "orm (enormalizat -.("/: ) tabel care conine una sau mai multe grupuri repetitive. $efiniie% "orma (ormal .nu -#("/: (elaie n care la intersecia oricrei linii cu oricare coloan gsim un c'mp care conine e6act o valoare.
Page% 7D

4n 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. 0rupurile repetitive sunt atribute, sau grup de atribute, pentru care avem diferite valori pentru aceeasi valoare a cheii, ceea ce este n contradicie cu definiia cheii. &liminarea acestor grupuri repetitive se poate realiza n dou moduri% 1onform 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. 3abele astefel rezultat va fi n form normal unu. 4n 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. 4n acest caz crem mai multe relaii noi. !ceste relaii noi, precum i tabela normalizat vor fi n form normal unu. $e e6emplu s lum relaia .urnizoriL1heltuieli% Cod Denumire Cod (r. Cod Denumire "urn. )iscal Crt. Chelt. Cheltuial .5II (omgaz (57DFC@? 5 15C 1helt pt. 4nclzire 7 15@ 1helt pt. Buctrii .55I (enel (?@CFD75 D 15I 1helt cu iluminatul F 155 1helt pt. .unc. liftului "igura +.0. 3abela nenormalizat .urnizoriL1heltuieli. *aloare 5CIIIII CIIIII DIIIIII 7IIIII

4n aceast tabel observm c pentru furnizorul J(omgazK avem dou tipuri de cheltuieli. Pentru a transforma aceast tabel n 5H., trebuie s avem o singur valoare la fiecare intersecie linie coloan. 4n cazul primei modaliti, scriem repetiiile pe diferite r'nduri iar coloanele care nu conin repetiii, vor fii copiate pe fiecare r'nd. $up desprirea repetiiilor pe mai multe r'nduri, identificm o nou cheie. Cod Denumire Cod (r. Cod Denumire "urn. )iscal Crt. Chelt. Cheltuial .5II (omgaz (57DFC@? 5 15C 1helt pt. 4nclzire .5II (omgaz (57DFC@? 7 15@ 1helt pt. Buctrii .55I (enel (?@CFD75 D 15I 1helt cu iluminatul .55I (enel (?@CFD75 F 155 1helt pt. .unc. liftului "igura +.1. 3abela .urnizoriL1heltuieli n 5H., creat prin prima modaliate de transformare. *aloare 5CIIIII CIIIII DIIIIII 7IIIII

4n tabela normalizat, noua cheie va fii ,1od .urn., Hr. 1rt., 1od 1helt.-.
Page% 7F

Hormaliz'nd 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. $eci cele dou tabele vor fi urmtoarele% .urnizori ,1od .urn., $enumire, 1od fiscal1heltuieli ,1od .urn., 1od 1helt., Hr. 1rt., $enumire cheltuial, Valoare1ele dou tabele astfel create sunt n 5H.% Cod (r. Cod "urn. Crt. Chelt. .5II 5 15C .5II 7 15@ .55I D 15I .55I F 155 Denumire Cheltuial 1helt pt. 4nclzire 1helt pt. Buctrii 1helt cu iluminatul 1helt pt. func. Liftului *aloare 5CIIIII CIIIII DIIIIII 7IIIII

Cod Denumire Cod "urn. )iscal .5II (omgaz (57DFC@? .5II (omgaz (57DFC@? .55I (enel (?@CFD75 .55I (enel (?@CFD75 "igura +.2. (elaia 1heltuial i .urnizor, create prin metoda a doua de normalizare. Pentru a demonstra trecerea la forma normal doi i mai mari, vom folosii relaia .urnizoriL1heltuieli, evideniat n figura 7.C.

2./. -orma 'ormal) "oi (2'.orma normal doi se bazeaz pe conceptul de dependen funcional total, ceea ce vom descrie n continuare. 2.9.1. #ependena %uncional total $efiniie% Dependena )uncional total: $ac ! i B sunt atributele unei relaii, atunci B este total dependent funcional de atributul !, dac B este dependent funcional de !, dar nu este dependent funcional de nici un subset al lui !. $e e6emplu s lum urmtoarea dependen funcional%
Page% 7C

Hr. 1rt., 1od 1helt. $enumire cheltuial $ependena funcional este corect, pentru c fiecare valoare al lui ,Hr. 1rt., 1od 1helt.- determin unic denumirea cheltuielii, ns dependena nu este total, pentru c &enumire c%eltuial depinde funcional i de un subset al lui ,Hr. 1rt., 1od 1helt.- i anume atributul (od (%elt* 2.9.2. #e%iniia /or$ei *or$ale #oi .orma normal doi trebuie verificat doar la relaiile care au cheie compus pe poziie de cheie primar. (elaiile la care cheia primar se compune dintr#un singul atribut, este n 7H.. (elaiile care nu sunt n forma normal doi, pot suferii de anomaliile prezentate in capitolul 7.7. $e e6emplu dac n cazul relaiei .urnizoriL1heltuieli vream s actualizm datele despre furnizorul .5II, trebuie s actualizm dou nregistrri. $efiniie% "orma (ormal Doi -+("/: ) 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 .urnizoriL1heltuieli evideniat n figura 7.C. 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. $up efectuarea acestor transformri, vom avea urmtoarela relaii%

(elatia 1heltuieli Cod (r. Cod "urn. Crt. Chelt. .5II 5 15C .5II 7 15@ .55I D 15I .55I F 155 (elaia .urnizori Cod Denumire "urn. .5II (omgaz .5II (omgaz

*aloare 5CIIIII CIIIII DIIIIII 7IIIII Cod )iscal (57DFC@? (57DFC@?

Page% 7@

(elaia 3ip 1heltuial Cod Denumire Chelt. Cheltuial 15C 1helt pt. nclzire 15@ 1helt pt. buctrii 15I 1helt cu iluminatul 155 1helt pt. func. liftului

.55I .55I

(enel (enel

(?@CFD75 (?@CFD75

"igura +.3. (elaiile rezultate dup trecerea la 7H. a relaiei .urnizoriL1heltuieli. (elaiile rezultate au urmtoarea form% .urnizori ,1od .urn., $enumire, 1od fiscal3ip cheltuial ,1od 1helt., $enumire cheltuial1heltuieli ,Hr. 1rt., 1od .urn., 1od 1helt., Valoare2.0. -orma 'ormal) 1rei (3'.orma normal doi chiar dac nu conine at'ta redundan ca forma normal unu, totui e6ist cazuri n care pot aprea anomalii la actualizare. !ceste anomalii apar din cauza redundanei generate de dependena tranzitiv. 2.:.1. #ependena tranziti4 $efiniie% Dependen tranzitiv: $ac atributele !, B, 1 sunt n relaiile !B i B1, atunci spunem c atributul 1 este dependent tranzitiv de atributul !, via B. 2.:.2. #e%iniia /or$ei *or$ale Trei $efiniie% "orma (ormal Trei -,("/: ) relaie care este n form normal doi i nu e6ist nici un atribut care s nu aparin cheii principale i care s fie tranzitiv dependent de cheia principal. 4n cazul e6istenei 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. &6amin'nd relaiile n forma normal de mai sus, observm c nu e6ist dependene tranzitive. $eci relaiile sunt n form normal trei. 2.2. -orma 'ormal) 3oyce-Codd (3C'Baza de date trebuie broiectat astfel nc't s nu conin dependene pariale sau tranzitive, pentru c altfel ne putem confrunta cu anomaliile descrise n cap. 7.7. 2.;.1. #e%iniia /or$ei *or$ale -o<ce=Codd .orma normal Bo9ce#1odd este bazat pe cheile candidat din relaie. ) relaie cu o singur cheie candidat n form normal trei este i n form normal Bo9ce#
Page% 7?

1odd. $efiniie% "orma normal Bo4ce5Codd -BC("/: ) relaie este n forma normal Bo9ce#1odd dac i numai dac orice determinant din relaie este cheie candidat. " cutm determinanii din e6emplul de mai sus% 1od .urn. $enumire, 1od fiscal 1od 1helt. $enumire cheltuial Hr. 1rt., 1od .urn., 1od 1helt. Valoare 3oi cei trei determinani sunt i chei candidat. $eci e6emplul de mai sus este n form normal Bo9ce#1odd. (elaiile n form normal trei sunt n general i n form normal Bo9ce#1odd. 4n cazul n care relaia nu este n form normal Bo9ce#1odd, trecerea la B1H. 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. &6ist situaii c'nd este foarte greu de descompus atributele, ca s a ungem la B1H.. 4n aceste situaii este indicat rm'nerea la forma normal trei.

2.4. S) recapitul)m procesul de normali(are (de la 1'- la 3C'"orma (ormal .nu -#("/ 3rebuie s cutm toate interseciile de linii i coloane, unde e6ist repetiii. !ceste repetiii se pot elimina prin dou madaliti% 1rearea a noi nregistrri pentru fiecare valoare a repetiiei, dup care se caut o nou cheie primar. Mtergerea atributelor care conin repetiii i crearea a unor noi relaii care vor conine atributele terse, precum i cheia principal din relaia iniial. "orma (ormal Doi -+("/ "e caut dependenele pariale de cheia principal, adic toate atributele care depind funcional de un subset de atribute a cheii primare. $ac cheia primar este compus dintr#un singur atribut, atunci releia este n forma normal doi. $ac e6ist 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. "orma (ormal Trei -,("/ Pentru a trece la forma normal trei, trebuie s eliminm dependenele
Page% 7B

tranzitive. &liminarea se realizeaz prin tergerea c'mpurilor dependente tranzitiv de cheia primar din relaia iniial i crearea unei noi relaii cu aceste atribute i determinantul lor. "orma (ormal Bo4ce5Codd -BC("/ 1erina la forma normal Bo9ce#1odd este ca fiecare determinant din relaie s fie cheie candidat. 4n cazul n care nu este ndeplinit aceast cerin, vom terge atributele dependente funcional de determinantul care nu este cheie candidat i crem o nou relaie n care s avem atributele terse i determinantul lor. 4n unele cazuri trecerea la forma normal Bo9ce#1odd complic foarte mult baza de date, caz n care este de preferat rm'nerea la forma normal trei.

.orm nenormalizat ,*H.Mtergem grupurile care se repet .orma normal unu ,5H.Mtergem dependenele pariale .orma normal doi ,7H.Mtergem dependenele tranzitive .orma normal trei ,DH.-

Page% 7>

!. Metodolo"ie - #roiectarea bazei de date

4n acest capitol vom nva despre% "copul metodologiei de proiectarea a bazelor de date. Proiectarea bazelor de date are dou faze mari% proiectarea logic i proiectarea fizic. *tilizatorii sistemului informatic au un rol important n proiectarea bazelor de date. 1um documentm procesul de proiectare a bazelor de date2 1um descompunem scopul proiectrii n vederi ,vie;#uri- specifice utilizatorilor nrtreprinderii2 1um utilizm modelarea &ntit9#(elationship ,&(-, pentru a crea un model conceptual local, bazat pe informaiile adunate despre vie;#urile utilizatorilor2 1um proiectm un model local conceptual ntr#un model local logic de date2 1um crem relaiile pentru un model conceptual local2 1um validm modelul logic de date, utiliz'nd technica normalizrii2 1um compunem modelele logice locale de date, bazate pe vie;#urile specifice utilizatorilor, ntr#un model logic global de date al ntreprinderii2 1um ne asigurm c modelul global este o reprezentare adevrat i total a prii ntreprinderii pe care vrem s o modelm2 8etodologia 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 ,"0B$-. 4n acest capitol vom prezenta pas cu pas, crearea unei baze de date. Vom utiliza modelarea &( descris n capitolul 5, pentru proiectarea bazei de dateE vom valida acest model prin normalizare, prezentat n capitolul 7E iar n final vom compune diferitele vie;#uri ntr#un model global al ntreprinderii. 4n acest capitol vom utiliza covintele JentitateK i JrelaieK n locul e6presiilor Jtip de entitateK i Jtip de relaieK. *nde aceast utilizare ar putea crea confuzii, vom specifica Jtip de entitateK, respectiv Jtip de relaieK. 3.1. Metodolo5ia proiect)rii ba(elor de date 3.1.1. Ce este o $etodolo"ie de proiectare> $efiniie% 6etodologie de proiectare: ) apro6imare structurat, care utilizeaz proceduri, tehnici, instrumente i documentaii pentru a facilita procesul de proiectare. 8etodologia de proiectare se compune din etape, care la r'ndul lor se compun din pai, care orienteaz proiectantul la fiecare nivel al crerii bazei de date.
Page% DI

3.1.2. Proiectarea lo"ic i %izic a bazei de date $efiniie% $roiectare 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 "0B$. 8odelul conceptual este apoi proiectat pe un model logic, care va influena mai t'rziu modelul de date n care se va implementa. $efiniie% $roiectare )izic: &ste procesul de descriere a implementrii bazei de date ntr#un "0B$. 4n aceast etap a proiectrii este creat baza de adte ntr#un "0B$, mpreun cu procedurile de actualizare. 4n aceast etap e6ist un feedbac= ntre proiectarea fizic i cea logic, pentru c deciziile luate la implementarea fizic pot afecta baza de date logice. 3.2. Pre(entarea metodolo5iei 4n 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 5. $roiectarea logic a bazei de date relaionale: 1rearea unui model conceptual local, pentru vederile utilizatorilor. Pasul 5.5. Gdentificarea tipurilor de entiti. Pasul 5.7. Gdentificarea tipurilor de relaii. Pasul 5.D. Gdentificarea i atribuirea de atribute la tipurile de entiti i tipurile de relaii. Pasul 5.F. $eterminarea domeniilor de definiie a atributelor. Pasul 5.C. $eterminarea atributelor care compun cheile candidate i primare. Pasul 5.@. "pecializare:generalizare ,pas opional-. Pasul 5.?. $esenarea diagramei entit9#relationship. Pasul 5.B. Verificarea modelului conceptual local cu a utorul utilizatorului. Pasul 7. 1rearea i validarea modelului logic local. Pasul 7.5. Proiectarea modelului conceptual local pe un model logic local. Pasul 7.7. 1rearea relaiilor pentru modelul logic local. Pasul 7.D. Validarea modelului, utiliz'nd normalizarea. Pasul 7.F. Validarea modelului din nou, utiliz'nd tranzaciile. Pasul 7.C. $esenarea diagramei &(. Pasul 7.@. $efinirea regulilor de integritate a bazei de date. Pasul 7.?. Verificarea modelului logic local cu a utorul utilizatorului. Pasul D. 1rearea i validarea modelului logic global de date. Pasul D.5. 1ompunerea medelelor logice locale ntr#un model logic global. Pasul D.7. Validarea modelului logic global. Pasul D.D. Verificarea posibilitii de a completa baza de date n viitor.
Page% D5

Pasul D.F. $esenarea diagramei &( finale. Pasul D.C. Verificarea modelului logic global cu a utorul utilizatorului. Pasul F. $roiectarea )izic 'i implementarea bazei de date relaionale: 3ranslatarea modelului logic global n "0B$. Pasul F.5. Proiectarea relaiilor de baz n "0B$. Pasul F.7. 1rearea regulilor de integritate n "0B$. Pasul C. Proiectarea i implementarea reprezentrii fizice. Pasul C.5. !nalizarea tranzaciilor. Pasul C.7. !legerea organozrii fiierelor. Pasul C.D. !legerea inde6ilor secundari. Pasul C.F. Gntroducerea unei redundane comntrolate. Pasul C.C. &stimarea spaiului pe disc. Pasul @. Proiectarea i implementarea unui mechanism de securitate. Pasul @.5. 1rearea vie;#urilor pentru utilizatori. Pasul @.7. Proiectarea regulilor de acces la baza de date. Pasul ?. 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. 8odelul de date astfel creat, se valideaz prin normalizare i prin tranzacii n pasul doi. 4n final, se genereaz modelul global al ntreprinderii, cars este la r'ndul lui validat i verificat cu a utorul utilizatorului sistemului. Factori critici pentru succesul proiectrii logice" Lucrul interactiv cu utilizatorul sistemului. .olosirea unei metodologii structurate pentru procesul de proiectare a bazei de date. 4ncorporarea regulilor de integritate n modelul logic de date. 1ombinarea validrii conceptuale, prin normalizare i prin tranzactii, la proiectarea modelului logic de baze de date. *tilizarea diagramelor pentru a reprezenta c't mai multe modele logice posibile. 1rearea dicionarului de date, ca supliment al modelului de date. 3.3. Metodolo5ia de proiectare a ba(ei de date lo5ice 4n acest capitol vom prezenta pas cu pas, proiectarea unei baze de date.

$asul #. Crearea modelului conceptual local, pentru utilizatori. )biectivul% 1rearea unui model conceptual local, pentru vie;#urile
Page% D7

utilizatorilior. Primul pas n proiectarea bazei de date este de a colecta datele necesare pentru realizarea sistemului, ceea ce putem culege, discut'nd cu viitorii tilizatori ai bazei de date. !crast discuie presupune o desprire n vederi, a bazei de date, vederi care pot luca separat. $esprirea n vederi se poate realiza n mai multe moduri. ) modaliate ar fi analiza datelor globale i gsirea de pri relativ independente. ) alt modalitate ar fii analiza rapoartelor, procedurilor cerute i:sau observarea sistemului i6istent n lucru. 8odelele 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 5.5. Gdentificarea tipurilor de entiti. Pasul 5.7. Gdentificarea tipurilor de relaii. Pasul 5.D. Gdentificarea i atribuirea de atribute la tipurile de entiti i tipurile de relaii. Pasul 5.F. $eterminarea domeniilor de definiie a atributelor. Pasul 5.C. $eterminarea atributelor care compun cheile candidate i primare. Pasul 5.@. "pecializare:generalizare ,pas opional-. Pasul 5.?. $esenarea diagramei entit9#relationship. Pasul 5.B. Verificarea modelului conceptual local cu a utorul utilizatorului. $asul +*+* !dentificarea tipurilor de entiti )biectivul% Gdentificarea tipurilor de entiti principale n vederile utilizatorilor. Primul pas n proiectarea bazei de date este identificarea entitiilor din datele furnizate de utilizatori. $e e6emplu, dac avem informaiile HrL8at, HrLBloc, "cara, &ta , !partament i Hume, putem identifica entitatea Locatari. 4n general putem identifica entitiile n mai multe moduri. $e e6emplu n locul entitii Locatari, am putea crea o entitate Locatari cu atributele HrL8at i Hume, iar celelelte informaii n entitatea ProprietateLocatari. &6ist cazuri c'nd entitiile sunt greu de identificat, pentru c modul de prezentare a viitorilor utilizatori necesit e6plicaii. *tilizatorii descriu aceste entiti, folosind sinonime i omonime, ceea ce ngreuneaz identificarea entitilor. "inonimele prin care se descrie aceai entitate, se pot considera sinonime i la crearea modelului logic, evideniind aceste sinonime ca diverse aliasuri ai entitiilor.
Page% DD

&ocumentarea tipurilor de entiti $up identificarea entitiilor, le dm c'te un nume, iar aceste nume le vom evidenia n dicionarul de date, mpreun cu e6plicaiile despre entiti, precum i posibilele aliasuri. $asul +*,* !dentificarea tipurilor de relaii )biectivul% Gdentificarea relaiilor importante dintre entiti. $up identificarea entitiilor, va trebui s identificm i relaiile importante dintre aceste entiti. (eleiile se descriu printr#un verb al relaiei. $e e6emplu% "crile sunt Locuite de Locatari .urnizorii $rovoac 1heltuieli La identificarea relaiilor vom lua n considerare doar relaiile care ne intereseaz. $egeaba e6ist i alte relaii care s se poat identificate, dac nu prezint importan pentru problema noastr, atunci nu le lum n consideraie. 4n cele mai multe din cazuri, relaiile sunt binare, adic se realizeaz ntrea e6act dou entiti. &6ist i relaii mai comple6e, care se realizeaz ntre mai multe entiti, sau relaii recursive, care pune n relaie o singur entitate cu ea nsi. &eterminarea cardinalitii i a participrii la tipurile de relaii $up identificarea tipurilor de relaii, trebuie s determinm cardinalitatea lor, aleg'nd dintre posibilitiile% unu#la#unu ,5%5-, unu#la#multe ,5%8-, sau multe# la#multe ,8%H-. $ac se cunosc valori specifice ale cardinalitiilor, aceste valori se scriu la documentarea relaiilor. 4n continuare determinm i participarea la relaie, care poate fii total, sau parial. &ocumentarea tipurilor de relaii $up identificarea tipurilor de relaii, le denumim i le introducem n dicionarul de date, mpreun cu cardinalitatea i participarea lor. -tilizarea modelrii E' Pentru vizualizarea sistemelor complicate, utilizm diagrama &(, pentru c este mult mai uor de a cuprinde toate informaiile. V propunem ca s utilizai ntotdeauna diagrama &(, pentru o mai bun vizualizare a datelor. $asul +*.* !dentificarea i asocierea de atribute la tipurile de entiti i tipurile de relaii )biectivul% !socierea de atribute la tipurile de entiti i la tipurile de relaii. *rmtorul pas n metodologie este identificarea atributelor. !ceste atribute se identific n aceeai mod ca i entitiile. Pentru o mai uoar identificare, trebuie s lum entitiile i relaiile ra r'nd i s ne punem urmtoarea ntrebare% (e informaii deinem despre aceast / 0 (spunsul la aceast ntrebare ne va da atributele cutate. Atribute simple sau compuse &ste important s notm dac un atribut este simplu sau compus. 1onform acestei informaii va trebui s lum decizii referitoare la acel atribut. $ac un atribut
Page% DF

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. $e e6emplu, atributul !dres conine informaiile ,HrLBloc, "cara, &ta , !partament-. Hoi 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. $e e6emplu n cazul atributelor HumeL.amilie i Prenume, neav'nd nevoie de aceste informaii separat, le vom compune n atributul Hume. Atribute derivate 1calculate2 "unt acele atribute, care se pot calcula din alte atribute e6istente n baza de date. $e e6emplu numrul locatarilor de pe o scar se poate numra n tipul de entitate Locatari. $eci acest atribut este atribut derivat. 4n 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. 4n cazul n care nu se modific, baza de date devine inconsistent. $e aceea este important de a meniona dac un atribut este sau nu derivat. $ac identificm un atribut care s nu#l putem asocia nici unei entiti sau relaii, ne ntoarcem la paii anteriori, identific'nd noua relaie sau entitate la care s asociem atributul respectiv. 4n 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 5.@. &ocumentarea atributelor $up 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 e6ist-, 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. $asul +*3* &eterminarea domeniului atributelor )biectivul% $eterminarea domeniului atributelor n modelul conceptual local. $omeniul 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,
Page% DC

 mrimea i formatul c'mpului atributului. &ocumentarea domeniilor atributelor !ctualizm dicionarul de date cu domeniul de definiie a fiecrui atribut. $asul +*4* &eterminarea atributelor care compun c%eile candidat i primare )biectivul% Gdentificarea cheilor candidat pentru fiecare entitate i alegerea cheilor primare n cazul n care sunt mai multe chei candidat. !dentificarea c%eilor i selectarea c%eilor primare ) 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. 4n acest caz trebuie s alegem dintre ele o cheie primar. 1heile 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 JtareK, sau entitate JslabK. $ac reuim s identificm o cheie primar, atunci entitatea este tare, altfel este slab. ) entitate slab nu poate e6ista fr o entitate tare, care s#i fie JprinteK. 1heia primar a entitii slabe este derivat parial sau total din cheia primar a entitii tari. &ocumentarea c%eilor primare i alternante 4nscriem cheile primare i pe cele alternante n dicionarul de date. $asul +*5* Specializarea6generalizarea tipuriloe de entiti 1pas opional2 )biectivul% Gdentificarea entitiilor subclas respectiv superclas, ntre entitiile apropiate. 4n acest pas putem opta pentru a continua modelarea &(, folosind procesul de generalizare sau specializare. $ac alegem procesul de specializare, vom ncerca s definim unul, sau mai multe subclase ai entitii respective. $ac ns alegem procesul de generalizare, vom cuta superclase pentru acea entitate. *n e6emplu pentru procesul de generalizare ar fii entitiile MefLdeLscar i .amilii. !mbele entiti au atribuite urmtoarele atribute% HrLmat, HrLbloc, "cara, &ta , !partament i Hume. Pe l'ng aceste atribute, entitatea MefLdeLscar mai are asociate atributul $ataLintrareLfuncE iar entitatea .amilii, atributele HrLpers, HrLpersLprezente i HrLchei. $eci, cele dou entiti av'nd atribute n comun, le
Page% D@

putem generaliza n entitatea Locatari, care va conine atrubutele comune, i entitile MefLdeLscar i .amilii, conin'nd doar atributele diferite # particularizrile fa de superclas. $asul +*7* &esenarea diagramei E'* )biectivul% $esenarea unei diagrame &(. care va fi reprezentarea conceptual a vederilor utilizatorilor despre ntreprindere. 4n momentul acesta suntem n msur s prezentm o giagram complet a modelului bazat pe vederile utilizatorilor despre ntreprindere. $asul +*8* 9erificarea modelului conceptual local cu ajutorul utilizatorului )biectivul% Verificarea modelului conceptual local cu a utorul utilizatorului, pentru a vedea dac modelul este o reprezentare adevrat a vederii utilizatorului despre ntreprindere. 4nainte de a termina pasul 5, trebuie verificat modelul conceptual elaborat. !cest model include diagrama &( i documentaia ane6at. 4n cazul n care apare orice fel de anomalie, repetm procesul de mai nainte i remediem problema. $asul +. Crearea 'i validarea modelului logic local )biectivul% 1rearea unui model logic local bazat pe modelul conceptual al utilizatorilor asupra ntreprinderii i validarea ei prin procesul de normalizare i prin tehnica tranzaciilor cerute. 4n acest pas verificm modelul conceptual creat n pasul anterior i eliminm din el structurile care sunt dificil de realizat ntr#un "0B$. $ac la sf'ritul 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. !ctivitile din acest pas sunt% Pasul 7.5. Proiectarea modelului conceptual local pe un model logic local. Pasul 7.7. 1rearea relaiilor pentru modelul logic local. Pasul 7.D. Validarea modelului, utiliz'nd normalizarea. Pasul 7.F. Validarea modelului din nou, utiliz'nd tranzaciile. Pasul 7.C. $esenarea diagramei &(. Pasul 7.@. $efinirea regulilor de integritate a bazei de date. Pasul 7.?. Verificarea modelului logic local cu a utorul utilizatorului. $asul ,*+* $roiectarea modelului conceptual local pe modelul logic local )biectivul% Verificarea modelului conceptual local pentru eliminarea structurilor care se pot implementa greu ntr#un "0B$ i proiectarea modelului
Page% D?

rezultat la modelul logic local. 4n pasul nt'i am pregtit un model conceptual bazat pe informaiile date de utilizator. !cest model trebuie prelucrat, pentru a putea fi uor de prelucrat de sistemul de gestiune a bazelor de date. )biectivele acestui pas sunt% ,5- &liminarea relaiilor 8%H. ,7- &liminarea relaiilor comple6e. ,D- &liminarea relaiilor recursive. ,F- &liminarea relaiilor cu atribute. ,C- (ee6aminarea relaiilor 5%5. ,@- &liminarea relaiilor redundante. 1+2 Eliminarea relaiilor multe:la:multe $ac n modelul de date apar relaii de tipul multe#la#multe ,8%H-, trebuie descompuse n dou relaii unu#la#multe ,5%8- prin adugarea unei noi entiti suplimentare. $e e6emplu, pot e6ista mai multe cheltuieli pentru o scar, dar i o cheltuial ,factur- poate s se refere la mai multe scri. $eci relaia dintre entitatea "cri i entitatea 1heltuieli este de 8%H, ceea de este evideniat n figura D.5.,a-.
Scari *r+-loc Scara )i%t C3eltuieli *r+Crt Cod+C3eltuiala ./01 Cod+/urnizor ./01 *r+%actura #ata+%actura 2aloare+%actura Sunt platite de
Scari *r+-loc Scara )i%t Pe scari Scara ./01 *r+Crt ./01 *r+-loc ./01 C3eltuieli *r+Crt Cod+/urnizor ./01 Cod+c3eltuiala *r+%actura #ata+%actura 2aloare+%actura

Au c3eltuieli

Se calculeaza

"igura ,.#. ,a-. (elaie de tipul H%8. ,b-. (elaie transfornamt n dou relaii 5%8. !ceast relaie se poate elimina, prin crearea unui tip de entitate suplimantar, care s fac legtura dintre scri i cheltuieli. $iagrama acestor relaii se vede n figura D.5.,b-. Hotm, c tipul de entitate nou creat # PeLscri # este tip de entitate slab, pentru c depinde att de tipul de entitate "cri, c't i de tipul de entitate 1heltuieli. 1,2 Eliminarea relaiilor comple;e ) relaie comple6 este o relaie ntre mai mult de cou tipuri de entiti. $ac n modelul conceptual apar relaii comple6e, acestea trebuie eliminate. "e pot elimina prin crearea unui nou tip de entitate, care s fie n relaie de tipul 5%8 cu fiecare tip de entitate din relatia iniial, partea cu 8 a relaiei fiind spre tipul de entitate nou creat. 1.2 Eliminarea relaiilor recursive (elaiile recursive sunt nite relaii particulare, prin care un tip de entitate este n relaie cu el nsi. $ac apare o astfel de relaie n modelul conceptual, ea trebuie eliminat. &liminarea se poate rezolva prin crearea unei noi entiti unde s se evidenieze fiecare entitate care este legat de entitatea din tipul de entitate iniial. 4n
Page% DB

acest caz vom avea o relaie de tipul 5%8 ntre tipul de entitate iniial i tipul de entitate nou creat i o relaie de tipul 5%5 ntre tipul de entitate nou creat i tipul de entitate iniial. 132 Eliminarea relaiilor cu atribute $ac n modelul conceptual avem relaii cu atribute, putem descompune aceast relaie, identific'nd un nou tip de entitate n care s nregistrm atributele necesare. 142 'ee;aminarea relaiilor de tipul +"+ 4n modelul conceptual putem avea entiti ntre care s avem relaie de tipul 5%5. "e poate nt'mpla ca aceste entiti s fie de fapt aceeai entitate cu nume diferite. $ac suntem n acest caz, unim cele dou entiti, cheia primar devenind cheia primar al uneia dintre entiti. 152 Eliminarea relaiilor redundante ) relaie este redundant dac se poate a unge de la un tip de entitate la alt tip de entitate pe mai multe drumuri. V amintim c noi vrem s a ungem la un model minimal i deci relaiile redundante nu sunt necesare. $ecizia 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, c'nd o relaie este aparent redundant, dar n realitate este nevoie de ea. 4n 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. $asul ,*,* (rearea de relaii peste modelul logic local )biectivul% 1rearea de relaii peste modelul logic. (elaia pe care un tip de entitate o are cu alt tip de entitate este reprezentat prin mechanismul cheie primar:cheie strin. 1heia 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 JprinteK i JfiuK. &ntitile JprinteK se refer la acele entiti ale cror chei primare se vor copia n entitile JfiuK. Pentru descrierea relaiilor vom folosii un limba de definire a bazei de date ,$atabase $efinition Language # $B$L-. 4n acest limba , specificm prima dat numele entitii, urmat de atributele asociate ntre paranteze. $up aceea identificm cheia primar i toate cheile alternante, precum i:sau cheile strine. <ipuri 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. $e e6emplu tipul de entitate .amilii, prezentat n figura D.7. se descrie n urmtorul mod. "amilii ,HrLmat, HrLbloc, "cara, &ta , !partament, Hume, HrLpers,
Page% D>

HrLpersLprezente, HrLcheiCheie primar: HrLmat

/a$ilii *r+Mat *r+pers *r+pers+prezente *r+c3ei *r+-loc Scara (ta, Aparta$ent /ond+rul$ent /ond+reparatii Alte+%onduri Plati #ata *r+Mat ./01 2aloare !estanta

Trebuie sa plateasca

"igura ,.+. &6emplu de model logic.

<ipurile de entiti slabe $escrierea tipurilor de entiti slabe se face la fel ca i tipurile de entiti tari, cu o completare i anume, evidenierea cheii strine. $e e6emplu descrierea tipului de entitate de mai sus se descrie astfel% $li ,$ata, HrLmat, Valoare, (estanCheie primar: $ata, HrLmat Cheie strin: HrLmat se re)er la .amilii,HrLmat8enionm c n cazul acesta cheia strin este i n compunerea chei primare. $eci 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. <ipurile de relaii binare de tipul unu:la:unu 1+"+2 Pentru fiecare tip de relaie binar de tipul 5%5 ntre dou tipuri de entitate &5 i &7 gsim o copie a cheii primare a tipului de entitate &5 n compunerea tipului de entitate &7, sub denumirea de cheie strin. Gdentificarea tipului de entitate JprinteK i a tipului de entitate JfiuK depinde de participarea entitilor la relaie. 3ipul de entitate care particip parial la relaie este desemnat ca fiind JprinteK iar cel cu participare total JfiuK. $ac ambele tipuri de entitate particip parial sau total la relaie, atunci tipurile de entiti se pot evidenia ca fiind JprinteK sau JfiuK arbitrar. 4n cazul n care participarea este total, putem ncerca s combinm cele dou tipuri de entiti ntr#una singur. !ceast compunere poate s fie posibil n cazul n care nici unul dintre cele dou tipuri de entiti nu mai ia parte la alt relaie. <ipurile de relaii binare de tipul unu:la:multe +"= Pentru toate relaiile 5%8 ntre dou entiti &5 i &7 n modelul logic de date,
Page% FI

vom avea copia cheii primare a entitii &5 n compunerea entitii &7. 3otdeauna entitatea de partea unu a relaiei este considerat entitate JprinteK, iar cealalt entitate JfiuK. Atributele cu mai multe valori Pentru ficarea atribut ! care permite mai multe valori din entitatea &5 n modelul logic de date, crem o nou relaie care va conine atributul ! mpreun cu cheia primar a entitii &5 pe post de cheie strin. 1heia primar a noii relaii va fi atributul !, sau dac este necesar, compunerea ei cu cheia primar al lui &5. 'elaiile superclas6subclas Pentru fiecare relaie superclas:subclas vom identifica superclasa ca fiind entitatea JprinteK, iar subclasa entitatea JfiuK. &6ist multe moduri de a reprezenta relaia aceasta. $e e6emplu s lum relaia prezentat n figura D.D. ,)piunea 57ocatari ,HrLmat, HrLbloc, "cara, &ta , !partament, Hume, $ataLintrareLfunc, HrLpers, HrLpersLprez, HrLcheiCheie primar: HrLmat ,)piunea 7"amilii ,HrLmat, HrLbloc, "cara, &ta , !partament, Hume, HrLpers, HrLpersLprez, HrLcheiCheie primar: HrLmat 8e)9de9scar ,HrLmat, HrLbloc, "cara, &ta , !partament, Hume, $ataLintrareLfuncCheie primar: HrLmat ,)piunea D7ocatari ,HrLmat, HrLbloc, "cara, !partament, HumeCheie primar: HrLmat 8e)9de9scar ,HrLmat, $ataLintrareLfuncCheie primar: HrLmat Cheie strin : HrLmat re)erire la Locatari,HrLmat"amilii ,HrLmat, HrLpers, HrLpersLprez, HrLcheiCheie primar: HrLmat Cheie strin : HrLmat re)erire la Locatari,HrLmat-

Page% F5

)ocatari *r+Mat *r+-loc ./01 Scara ./01 (ta, Aparta$ent *u$e

Se% de scara *r+Mat ./01 #ata+intrare+%unc

Cap %a$ilie *r+Mat ./01 *r+pers *r+pers+prezent e * r+c3ei /ond+rul$ent /ond+reparatii Alte+%onduri

"igura ,.,. &6emplu de relatie superclas:subclas &ocumentarea relaiilor i a atributelor din c%eile strine !ctualizm dicionarul de date, ntroduc'nd fiacare atribut nou introdus n compunerea unei chei la acest pas. $asul ,*.* 9alidarea> utiliznd normalizarea )biectivul% Validarea modelului logic, utiliz'nd tehnica normalizrii. &6aminm procesul de normalizare dup cum am descris n capitolul 7. Prin normalizare trebuie s demonstrm c modelul creat este consistent, conine redundan minimal i are atabilitate ma6im. Hormalizarea este procesul prin care se decide dac atributele pot sau nu s rm'n npreun. 1onceptul de baz a teoriei relaiilor este c atributele sunt grupate mpreun pentru c e6ist o relaie logic ntre ele. 1'teodat baza de date nu este cea mai eficient. !cesta se argumenteaz prin urmtoarele% Proiectarea normalizat organizeaz datele n funcie de dependenele funcionale. $eci acest proces este situat undeva ntre proiectarea conceptual i cea fizic. Proiectul logic nu este un proiect final. &l a ut priectantul s neleag natura datelor n ntreprindere. Proiectul fizic poate fi diferit. &6ist posibilitatea ca unele tipuri de entiti s se denormalizeze. 3otui normalizarea nu este un timp pierdut. Proiectul normalizat este robust i independent de anomaliile de actualizare prezentate n capitolul 7. 1alculatoarele moderne au mult mai mult putere de calcul, ca cele de acum c'iva ani. $in aceast cauz, c'teodat este mai convenabil implementarea unei baze de date cu puin redundan, dec't suportarea cheltuielilor pentru procedurile adiionale. Hormalizarea produce o baz de date care va fi uor e6tensibil n viitor.
Page% F7

Procesul de normalizare include urmtoarele etape mari% .orma Hormal *nu ,5H.-, eliminarea grupurilor repetitiveE .orma Hormal $oi ,7H.-, eliminarea dependenelor pariale de cheia primarE .orma Hormal 3rei ,DH.-, eliminarea dependenelor tranzitive de cheia primarE .orma Hormal Bo9ce#1odd ,B1H.-, eliminarea anomaliilor care au mai rmas. $asul ,*3* 9alidarea modelului prin tranzacii

)biectivul% Verificarea ca modelul de date suporte toate tranzaciile cerute de utilizator. 4n acest pas se valideaz baza de date prin verificarea tranzaciilor ce se cer de utilizator. Lu'nd n considerare tipurile de entiti, relaiile, cheile primare i strine, ncercm s rezolvm manual cerinele utilizatorilor. $ac reuim s rezolvm fiecare tranzacie cerut, atuci nseamn c modelul creat este valid. $ac nu putem rezolva o tranzacie, atunci este foarte posibil s fi omis un atribut, o relaie, sau o entitate din modelul de date. 3rebuie s e6aminm n dou posibiliti, dac baza de date suport tranzaciile cerute. *na dintre ele ar fi prin rezolvarea de tranzacii. $e e6emplu s lum relaia dintre .urnizori i 1heltuieli e6emplificat n figura D.F.
C3eltuieli *r+Crt Cod+/urnizor ./01 Cod+c3eltuiala *r+%actura #ata+%actura 2aloare+%actura /urnizori Cod+/urnizor #enu$ire Cod+%iscal .A011 Cont -anca Strada *r -l Sc Ap )ocalitate 6udet

Pro4oaca

"igura ,.0. &6emplu de relaie pentru validarea prin tranzacii.

!nserarea de detalii despre un nou furnizor* 1heia primar al acestei entiti este HrLfurnizor. $eci prima dat verific dac numrul introdus nu e6ist de aE dup care n caz c nu e6ist acest cod, inserez detaliile despre furnizor. $ac e6ist de a codul, nu admit inserarea. Pot verifica i e6istena codului fiscal, care pentru aceast entitate este cheie alternant. tergerea detaliilor despre un furnizor "e caut codul furnizorului de ters. $ac e6ist se terge furnizorul, actualiz'ndu#se i cheia strin n entitatea 1heltuieli. $ac nu e6ist codul cerut,
Page% FD

atunci apare un mesa de eroare i nu este ters nici un furnizor. ! doua modalitate de verificare trebuie folosit n cazul n care avem entiti care nu iau parte direct la nici o tranzacie. Pentru verificarea acestor entiti, vom verifica nite interogri pergtie special. $asul ,*4* &esenarea diagramei E'* )biectivul% $esenarea diagramei &ntit9#(elationship, care este reprezentarea logic a vederilor utilizatorilor aspra ntreprinderii. $asul ,*5* !dentificarea regulilor de integritate* )biectivul% Gdentificarea regulilor de integritate pentru vederile utilizatorilor asupra ntreprinderii. (egulile de integritate sunt importante pentru a prote a baza de date mpotriva posibilelor inconsistene. $ac 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 &6ist atribute care nu pot conine valoarea nul, ci trebuie s aib totdeauna o valoare. $e e6emplu fiecare cheltuial nregistrat trebuie s aib asociat un furnizor al serviciilor sau al obiactelor ce se pltesc prin acea cheltuial. !ceste reguli de a le#am identificat, c'nd am documentat atributele n pasul 5.D. 'eguli asupra domeniului atributelor* *nele atribute au un domeniu de definiie bine definit. !ceste domenii trebuie respectate. $omeniile de definiie au fost de a identificate c'nd am documentat domeniile atributelor n pasul 5.F. !ntegritatea entitilor* 1heia primar a entitilor nu poate lua valori nule. $e e6emplu fiacare furnizor trebuie s aib un cod diferit de zero. !ceste reguli au fost de a identificate, c'nd am documentat cheile primare n pasul 5.C. !ntagritatea referinelor 1heia strina din tipul de entitate JfiuK face ligtura cu o entitate din tipul de entitate JprinteK. $eci, dac cheia strin conine o valoare, ea trebuie neaprat s se
Page% FF

regseasc i n tipul de entitate JprinteK. $e e6emplu tipul de entitate 1heltuieli conine cheia strin 1odLfurnizor, care se refer la .urnizori,1odLfurnizor-. $ac 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 nul2 4n cazul e6emplului nostru asta ar nsemna c e6ist cheltuieli care nu se prtesc nimnui. !ceste cazuri nu sunt admise de lege, deci nu putem avea valoare nul n cheia strin din tipul de entitate 1heltuieli. 4n general dac pariciparea tipului de entitate JfiuK este total, atunci nu putem avea valoare nul n cheia strin. 4n caz contrar putem avea valoare nul. Pentru a demonstra diferitele cazuri la definirea acestor reguli, folosim relaia de mai sus dintre .urnizori i 1heltuieli, care este de tipul 5%8. 1onsiderm urmtoarele cazuri% (azul +" !nserarea unei entiti #n tipul de entitate ?fiu@ 1(%eltuieli2" Pentru a verifica integritatea referinei, varificm dac atributele din componena cheii strine ,1odLfurnizor- sunt vide, sau s e6iste entitate n tipul de entitate JprinteK care s aib valoare cheii primare egal cu valoare cheii strine. (azul ," tergerea unei entiti din tipul de entitate ?fiu@ 1(%eltuieli2" Mtergerea unei entiti din tipul de entitate JfiuK nu cauzeaz problame cu privin la integritatea referinelor. (azul ." Actualizarea c%eii strine #n tipul de entitate ?fiu@ 1(%eltuieli2" !cest caz este similar cazului 5. (azul 3" Stergerea unei entiti din tipul de entitate ?printe@ 1Furnizori2" $ac se terge o entitate din tipul de entitate JprinteK, integritatea referinelor se stric n cazul n care e6ist entiti n tipul de entitate JfiuK, care se refer la entitatea tears. &6ist strategii severe de a rezolva integritatea referinelor% .P(P !1QG*H& Heacceptarea tergerii unei entiti din tipul de entitate printe, dac acesta este referit de o entitate din tipul de entitate fiu. 4n cazul nostru, nu se accept tergerea furnizorului, dac el are o factur de ncasat. 1!"1!$P $ac o entitate din tipul de entitate printe este tears, se terg automat toate entitiile din tipurile de entiti fiu. $ac tipurile de entiti fiu au i ei la r'ndul lor alte tipuri de entiti fiu, se va efectua tergerea n cascad n toate tipurile de entiti fiu, p'n la ultimul nivel. 1u alte cuvinte, dac se terge un furnizor, atunci automat se terge fiacare factur pe carea are de ncasat acest furnizor. "&3!(& L! H*L $ac 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 p'n la ultimul nivel. 4n e6emplul nortru, dac se terge un furnizor, atunci se vor seta la valoare nul toate referinele la acest furnizor n tipul de entitate 1heltuieli. !cesta nseamn c nu vom tii ca anumite cheltuieli la ce furnizor trebuie pltite. "&3!(& G8PLG1G3P &ste analog cazului de setare la nul, cu diferena c aici se seteaz cheia strin la o valoare implicit n loc de valoare nul. 4n e6emplul nostru putem seta cheia strin din 1heltuieli la o valoare a cheii primare din .urnizori, care s conin un furnizor predefinit # de e6emplu cu numele de J.urnizor tersK.
Page% FC

 .P(P 8)$G.G1!(& 4n cazul tergerii unei entiti din tipul de antitate printe, nu se actualizeaz deloc cheile strine din tipurile de entiti fiu. (azul 5" =odificarea c%eii primare #n tipul de entitate printe 1Furnizori2" $ac 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 1!"1!$P. 'egulile #ntreprinderii* 4n final evideniem acele reguli care sunt date de realitatea ce se va modela n baza de date. &ocumentarea tuturor regulilor de integritate* 3recem toate regulile de integritate n dicionarul de date. $asul ,*7* 9erificarea modelului logic local cu ajutorul utilizatorului* )biectivul% 1onvingerea 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. 4nainte de a trece la pasul D, trebuie verificat modelul, s fie conform cu realitatea. 4n cazul n care se gsesc diferene, ne vom rentoarce la paii anteriori i modificm cele necasare. $asul ,. Crearea 'i validarea modelului global logic de date. )biectivul% 1ombinarea modelelor locale logice ntr#un model logic glaobal care s reprezinte ntreprinderea care este modelat. ! treia activitate ma or n proiectarea bazei de date logice este crearea modelului logic global, prin compunerea tuturor modelelor locale. $up combinarea modelelor locale, trebuie validat modelul global prin tehnica de enormalizare, dup care prin tehnica tranzaciilor. !cest proces utilizeaz aceleai tehnici pe care le#am descris la paii 7.D. i 7.F. !cest proces este foarte important n proiectarea bazei de date, pentru c el demonstreaz c reprezentarea ntreprinderii este independent de orice utilizator, funcie sau aplicaie. !ctivitile din acest pas sunt% Pasul D.5. 1ompunerea medelelor logice locale ntr#un model logic global. Pasul D.7. Validarea modelului logic global. Pasul D.D. Verificarea posibilitii de a completa baza de date n viitor. Pasul D.F. $esenarea diagramei &( finale. Pasul D.C. Verificarea modelului logic global cu a utorul utilizatorului. $asul .*+* (ompunerea modelelor logice locale #ntr:un model logic global*
Page% F@

)biectivul% 1ompunerea tuturor modelelor logice locale ntr#un model logic global al ntreprinderii. 4n cazul unui sistem mic, cu puine vederi ai utilizatorilor, este relativ uor de a compune modelele logice locale. 4n cazul unui sistem mai mare ns, trebuie s urmm un proces sistematic de realizare a modelului global. Paii acestui proces sunt urmtoarele% ,5- Verificarea numelor entitilor i a cheilor lor primare. ,7- Verificarea numelor relaiilor. ,D- 1ompunerea entitilor de pe vie;#urile locale. ,F- Gncluderea ,fr compunere- a entitilor care apar pe doar una dintre vie;#uri. ,C- 1ompunerea relaiilor de pe vie;#urile locale. ,@- Gncluderea ,fr compunere- a relailor care apar pe doar una dintre vie;#uri. ,?- 1utarea entitilor i a relailor care lipsesc ,dac e6ist-. ,B- 1utarea cheilor strine. ,>- 1utarea regulilor de integritate. ,5I- $esenarea modelului logic global. ,55- !ctualizarea documentaiei. 1el mai uor de compus mai multe modele locale este compunerea succesiv a dou c'te dou dintre modele. 1+2 9erificarea numelor entitilor i a c%eilor lor primare* !ceast verificare se face folosind i dicionarul creat n decursul pailor de dinainte. Probleme apar doar atunci c'nd% $ou entiti au acelai nume, dar sunt de fapt diferii. $ou entiti sunt aceleai, dar nu au aceleai nume. Probabil va fi necesar analizarea atributelor antitilor, prntru a rezola aceast problem. 4n particular, putem utiliza cheia primar i numele entitii, pentru a identifica entitile echivalente. 1,2 9erificarea numelor relaiilor* !ceast activitate este asemntoare celui descris la entiti. 1.2 (ompunerea entitilor de pe vieA:urile locale* &6aminm numele i atributele entitilor ca vor fi compuse. !ctivitile care se includ n acest pas sunt% 1ompunerea entitilor cau au aceleai nume i aceleai chei primare. 1ompunerea entitilor care au aceleai nume, dar cu chei primare diferite. 1ompunerea entitilor care au nume diferite, cu chei primare egale sau diferite. (ompunerea entitilor care au aceleai nume i aceleai c%ei primare* 4n general entitile cu aceleai chei primare reprezint Jlumea realK, i deci pot fi compuse. !tributele care apar n entitile de pe ambele vie;#uri, vor fi trecute doar o singur dat. $ac ntr#un vie; apre un atribut compus, iar ntr#un alt vie; acelai atribut dar descompus n atribute simple, atunci vom ntreba, dac se poate, utilizatorii pentru a decide asupra formei de utilizare a atributului. (ompunerea entitilor care au aceleai nume> dar au c%ei primare diferite* 4n astfel de situaii, cutm dou entitpi care au aceleai nume i nu au aceleai chei
Page% F?

primare, dar au aceleai chei candidat. 1ele dou entiti pot fi compuse, urm'nd ca dup compunere s alegem o cheie primar, restul rmn'nd chei alternante. (ompunerea entitilor care nu au nume comune i nu au aceleai c%ei primare* !ceste entiti se pot depista prin analiza atributelor celor dou entiti. 132 !ncluderea 1fr compunere2 a entitilor care apar doar #ntr:un vieA* Pasul anterior identufic toate entitile comune. 1elelalte entiti, se vor include n modelul logic global e6act aa cum apar n vie;#ul respectiv. 142 (ompunerea relaiilor de pe modelele locale* 4n acest pas analizm silitudinile dintre relaii de pe diferite modele locale. 4n 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. 152 !ncluderea 1fr compunere2 a relaiilor care apar doar pe un vieA* (elaile care au rmas neincluse n modelul global dup pasul anterior, se includ n modelul global fr modificare. 172 (utarea entitilor i relailor care lipsesc* &ste unul din cei mai grei pai din crearea modelului global. 3rebuie cutate acele entiti i relaii, care s#au omis la paii anteriori i n#au a uns n modelul global. 182 (utarea c%eilor strine* 4n decursul pailor anterioare, s#au modificat entiti, chei primare i chei strine. 4n acest pas verificm dac cheile strine sunt corecte n fiecare entitate fiu i efectum toate modificrile necesare. 1B2 (utarea regulilor de integritate Verificm dac regulile de integritate a modelului global nu sunt n conflict cu regulile definite la modelele locale. .iecare problem de acest gen se rezolv cu a utorul utilizatorului sistemuli. 1+C2 &esenarea diagramei E'* !cum desenm diagrama &( pentru modelul global de date. 1++2 Actualizarea documentaiei* !ctualizm documentaia, ca s reflecte toate modificrile aduse n acest pas modelului. $asul .*,* 9alidarea modelului logic global* )biectivul% Validarea modelului global logic de date, folosind normalizarea, dup care folosind tranzacile cerute. !cest pas este schivalent cu paii 7.D. i 7.F., unde am validat modelul local de date. $asul .*.* 9erificarea posibilitilor de e;tindere a bazei de date #n viitor* )biectivul% $eterminarea ca dac modelul se acomodeaz uor la modificri oric't de mari ce pot intervenii n viitor. &ste important ca modelul creat s fie e6pansibil n viitor. $ac modelul nu are
Page% FB

aceast calitate, viaa lui poate fi scurt i pentru o mai mare modificare va trebui refcut de la nceput. $asul .*3* &esenarea diagramei Entitz:'elations%ip finale* )biectivul% $esenarea unei diagrame &(, care s reprezinte modelul global de date al ntreprinderii. $asul .*4* 9erificarea modelului global cu ajutorul utilizatorului* )biectivul% Verificarea c modelul global reprezint n totalitate realitatea. 4n acest moment modelul global este complet i documentat. 4mpreun cu utilizatorul sistemului se verific acest model i se aduc eventualele corecturi prin ntoarcerea la psurile n cauz.

Page% F>

$. Metodolo"ia proiect%rii bazei de date lo"ice - E&e plu

4n acest capitol vom nva despre% 1um s folosim metodologia de proiectare a bazelor de date relaionele, desclis n capitolul D. 1um s folosim aceast metodologie pentru proiectarea bazei de date al sistemului !sociaie de locatari. 4n acest capitol vom e6plica detaliat, cum putem folosii metodologia prezentat n capitolul D. Vom e6emplifica folosirea metodologiei cu proiectarea bazei de date pentru sistemul informatic al asociaiei de locatari. 4n decursul acestui capitol, vom folosii e6presiile JentitateK i JrelaieK n locul e6presiilor Jtip de entitateK respectiv Jtip de relaieK. 4n cazul n care pot aprea ambiguiti, se va folosii Jtip de entitateK respectiv Jtip de realieK. 4.1. Cerin#ele utili(atorilor. !naliza i colectarea datelor l vom ncepe la o asociaie de locatari. !ici trebuie s cerem informaiile necesare pentru realizarea sistemului. 3rebuie 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. 3oate informaiile despre sistemul de eviden a asociaiei de locatari se pot mprii n mai multe vie;#uri. !ceste vie;#uri sunt% &videna locatarilor i a apartamentelor din asociaie, &videna cheltuielilor locatarilor, &videna personalului asociaiei, &videna obiectelor de inventar i a mi loacelor fi6e, Plata datoriilor asociaiei ctre furnizoriK. 4.1.1. Cerinele la baza de date. Evidena locatarilor 'i a apartamentelor din asociaie: ,5- 4n baza de date vor fi memorate toi locatarii asociaiei de locatari. Gnformaiile necesare despre locatari sunt% adresa ,numr bloc, scara, eta ul i apartamentul- i numele. &i vor fi unic determinai de un numr matricol unic pe toat asociaia de locatari. ,7- $intre locatari trebuie s evideniem pentru fiecare familie c'te 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.
Page% CI

,D- 3ot dintre locatari se alege c'te un ef de scar pentru fiecare scar din asociaie. Mef de scar trebuie s fie e6act unu pe fiecare scar i trebuie s locuiasc n scara pentru care s#a ales. Pentru eful de scar mai avem n plus informaia% data intrrii n funcie. ,F- La evidena cldirilor din asociaia de locatari, avem de memorat scrile care aparin asociaiei. "crile sunt identificate unic prin numrul blocului i litera scrii. 8ai trebuie s tim despre fiecare scar dac are lift. ,C- Pe fiecare scar avem mai multe apartamente. $espre apartamente trebuie s memorm informaiile urmtoare% nr. apartamentului, suprafaa, numrul de cutii potale i numrul de prize tv. ,5Evidena cheltuielilor locatarilor .iecare cheltuial se nregistreaz n momentul primilii facturii de la furnizor. 1heltuielile 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. 1heltuielile 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. $ac este cazul, se nregistreaz i restanele. 1'nd 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. 1hitana se identific unic prin numrul su. Pentru a efectua mai uor nregistrarea cheltuielilor, memorm i datele despre furnizori. !ceste date sunt% denumirea, codul fiscal, contul bancar i banca, adresa ,strada, numrul, bl., sc., ap., localitatea i udeul-. .urnizorii se pot identifica unic printr#un cod intern # cod furnizor. Pe l'ng cheltuielile ctre furnizori e6ist i cheltuieli, care trebuiesc pltite de locatari, dar care rm'n la asociaie. !stfel de cheltuial este fondul de rulment, fondul de reparaii, sau dac este cazul, i alte fonduri. !ceste cheltuieli se vor nregistra n acelai mod ca i celelalte, cu diferena c aici se va introduce un JfurnizorK special pregtit. .iecare familie trebuie s aib pltit o sum la asociaia de locatari pentru fondul de rulment. 4n cazuri speciale se adun bani i pentru fondul de reparaii, sau alte fonduri.

,7,D,F,C-

,@-

,?-

Evidena personalului asociaiei. ,5- Personalul asociaiei se va memora n baza de date, identifiacrea fc'ndu#se dup un numr matricol unic. 8ai folosim informaiile% numele, data naterii, meseria, data anga rii i scrile din asociaie unde lucreaz. ,7- *n anga at poate s lucreze n mai multe scri i pe o scar pot s lucreze mai muli anga ati. Evidena mi&loacelor )i:e 'i a obiectelor de inventar.
Page% C5

,5- 8i loacele fi6e i obiactele de inventar se vor identifica unic, cu a utorul unui cod numit numar de inventar. Pentru aceste obiecte mei reinem urmtoarele informaii% numele, valoarea i locul unde este amplasat. $lata datoriilor asociaiei ctre )urnizori. ,5- ) 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. ,5,7,D,FEvidena 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 ,5- List cu cheltuielile fiecrei familii pe scri, ,7- List cu toate cheltuielile asociaiei de locatari. ,D- 1hitana care se emite la fiecare plat. Evidena personalului asociaiei. ,5- List cu personalul asociaiei. Evidena mi&loacelor )i:e 'i a obiectelor de inventar. ,5- List cu mi loacele fi6e i valoarea lor, din asociaia de loacatari, ,7- List cu obiectele de inventar ai asociaiei de locatari. $lata datoriilor asociaiei ctre )urnizori. ,5- List cu facturile scadente primite de la furnizori, ,7- "ituaia plilor facturilor de la furnizori, nglob'nd facturile dintr#o perioad dat, mpreun cu modul lor de plat.

4.2. .tili(area metodolo5iei de proiectare a ba(elor de date rela#ionale. $asul #. Crearea modelelor conceptuale locale, bazate pe vie;5urile utilizatorilor:
Page% C7

4nainte s ne apucm de crearea modelului conceptual local, s ne reamintim din ce se compune acest model% tipuri de entiti, tipuri de relaii, atribute, domeniile atributelor, chei candidat, chei primare. 4n acest capitol vom e6emplifica metodologia de proiectare pe dou vederi ai sistemului informatic% &videna locatarilor si a apartamentelor din asociaie, &videna cheltuielilor locatarilor. $asul +*+* !dentificarea tipurilor de entiti* 4ncepem s identificm tipurile de entiti din toate vederile utilizatorilor. Vom descrie separat identificarea acestor entiti pentru cele dou vederi. 4n cazul evidenei locatarilor i al apartamentelor, tipurile de entiti sunt% Locatari "cri Mef de scar !partamente .amilii 4n cazul evidenei plilor tipurile de entiti sunt% 1heltuieli .urnizori Pli 1hitane .amilii "cri &ocumentarea tipurilor de entiti 4n documentarea tipurilor de entiti includem o descriere amnunit a fiecrei entoti, mpreun cu aliasurile lor. !ceste informaii sunt prezentate n ane6a F.5. $asul +*,* !dentificarea tipurilor dr relaii* 4n continuare identificm tipurile de relaii. 3ipurile de relaii se reprezint prin verbe ale relaiilor. 3ipurile de relaii din cele dou vie;#uri sunt prezentate n tabelele de mai os% 3ipuri de relaii din vie;#ul JLocatariK% 3ip de entitate 3ip de relaie "cri sunt locuite de sunt locuite de sunt conduse de se compun din
Page% CD

3ip de entitate Locatari .amilii Mef de scar !partamente

3ipuri de relaii din vie;#ul J1heltuieliK% 3ip de entitate 3ip de relaie .urnizorii provoac 1eltuieli sunt pltite de sunt pltite de .amilii trebuie s plteasc primesc

3ip de entitate 1heltuieli .amilii "cri Pli 1hitane

$ac la acest pas apar ambiguiti, ele trebuie neaprat clarificate cu utilizatorii. &eterminarea cardinalitii i a participrii pentru tipurile de relaii* 4n contunuare vom determina cardinalul i participarea relaiilor prezentate n tabelele de mai sus. 1ardinalul poate s fie unul dentre urmtoarele% unu#la#unu ,5%5-, unu#la#multe ,5%8-, sau multe#la#multe ,8%H-. Participarea poate s fie parial sau total. Gnformaiile pe baza crora trebuie s determinm aceste caracteristici ai tipurilor de relaii, sunt prezentate n capitorul F.5.5. 4n cazul n care apar ambiguiti, ele trebuie clarificate cu a utorul utilizatorului. " lum de e6emplu relaia dintre "cri i Locatari. Pentru a fi foarte siguri de cardinalul relaiei, vom pune urmtoarea ntrebare% 4ntrebare% Pot locui pe o scar mai muli locatari2 (spuns% $a. $eci relaia "crile sunt locuite de Locatari are cardinalul 5%8. 4n continuare va trebui s aflm i cardinalul relaiei inverse, adic a relaiei Locatarii locuiesc #n apartementele de pe "cri. 4ntrebare% *n locatar poate locui n mai multe apartamente de pe scri diferite2 (spuns % Hu. La aceast ntrebare avem nevoie de o e6plicaie% $ac o persoan are dou locuine n aceai asociaie de locatari, atunci el va apare n entitatea locatari de dou ori, cu nrumr matricol diferit. $eci un numr matricol poate s locuiasc doar ntr#un singur apartament. $eci cardinalul acestei relaii este de 5%5, de unde rezult c relaia iniial are cardinalul 5%8. Pentru a afla participarea entitilor la relaie, punem urmtoarele ntrebri% 4ntrebare% .iecare scar este locuit de cel puin un locatar2 (spuns % Hu. 4ntrebare% .iecare locatar locuiete ntr#unul din aceste scri2 (spuns% $a.
Page% CF

$eci tipul de entitate scri partcip parial, iar tipul de entitate Locatari particip total la relaie. .ie relaia 1heltuieli sunt pltite de "cri, din vie;#ul J1heltuieliK. " determinm cardinalul i participarea ei% 4ntrebare% &6ist cheltuial care se refer la mai multe scri2 (spuns % $a. 4ntrebare% "crile pot avea mai multe cheltuieli2 (spuns % $a. 4ntrebare% .iecare cheltuial trebuie s fie asociat unei scri2 (spuns % Hu, pentru c poate fi asociat doar unor familii. 4ntrebare% .iecare scar trebuie s aib cheltuieli2 (spuns % Hu, pentru c pot fi scri fr locatari. $up aceste ntrebri i rspunsuri, am a uns la concluzia c relaia are cardinalul H%8 ,ambele relaii # i cea direct i cea invers # au cardinalul 5%8-, iar participarea parial de ambele pri. 1ardinalul i partciparea relaiilor de mai sus sunt prezentate n ane6a F.D. -tilizarea modelrii E'* Pentru o nelegere mai uoar a relaiilor dintre entiti, se poate folosi diagrama &(. $iagramele &( ale celor dou vie;#uri ale cror relaii au fost prezentate mai sus, se pot vedea n figura F.5. ,a- i ,b-. 8enionm, c verbele care reprezint relaiile de cardinal 5%8 se pun n direcia unu#la#multe. 4n cazul n care relaia a fost altfel evideniat, ea va fi redenumit. &ocumentarea tipurilor de relaii* $ocumantarea vie;#urilor care apar n figura F.5. este realizat n ane6a F.D.
Sunt locuite de Sunt locuite de /a$ilii Sunt conduse de Se% de scara Aparta$ente Se co$pun din

)ocatari

Scari

"igura 0.#.-a/ $iagrama &(. a vie;#ului JLocatariK.

Page% CC

Scari

Sunt locuite de

/a$ilii Pri$esc

Sunt platite de /urnizori

Trebuie sa plateasca

Plati Sunt platite de

C3itante

C3eltuieli

Pro4oaca

"igura 0.#.-b/. $iagrama &( a vie;#ului J1heltuieliK $asul +*.* !dentificarea i asocierea atributelor la tipurile de releii i tipurile de entiti* 4n acest pas identificm atributele ce se asociaz tipurilor de entiti sau tipurilor de relaii. !tributele sunt informaii care caracterizeaz entitile, resoective relaiile. !ceste atribute le putem gsi n descrierea acordat de utilizatori. 4n cazul nostru, atributele identificate i asociate entitilor se pot regsi n tabela F.7.a. i F.7.b. Tabela 0.+.a. !tributele tipurilor de entiti din vie;#ul JLocatariK% Tip de entitate Atribute Locatari HrL8at !dresa ,HrLbloc, "cara, &ta , !partamentHume .amilii HrL8at !dresa ,HrLbloc, "cara, &ta , !partamentHume HrLpers HrLpersLprez HrLchei "efL"cara HrL8at !dresa ,HrLbloc, "cara, &ta , !partamentHume $ataLintrareLfunc "cri !dresa ,HrLbloc, "caraLift !partamente !partament "uprafaa 1utiiLpotale HrLprizeLtv Tabela 0.+.b. !tributele tipurilor de entiti din vie;#ul J1heltuieliK%
Page% C@

Tip de entitate .amilii

Pli 1hitane 1heltuieli

.urnizori

Atribute HrLmat .ondLrulment .ondLreparaii !lteLfonduri $ata Valoare (estan HrL1hit Valoare $ata HrLcrt 1odLcheltuiala HrLfactura $ataLfactura Valoare 1odLfurnizor $enumire 1odLfiscal 1ont Banca !dresa ,"trada, Hr., Bl., "c., !p., Localitate, Nud-

&ocumentarea atributelor" Pentru documentaie se descrie fiecare atribut, se menioneaz tipul de date folosit precum i lungimea c'mpului, 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. ) parte a acestei documentaii este e6emplificat n ane6a F.7. $asul +*3* &eterminarea domeniilor atributelor" 4n acest pas determinm domeniile atributelor. $omeniul unui atribut este nulimea acelor valori, pe care le poate lua n lucrul de zi cu zi. &ocumentarea atributelor* 1'teva din domeniile e6emplului nostru sunt artate n ane6a F.F. $asul +*4* &eterminarea atributelor care aparin c%eilor candidat i primare" !cum vom e6amina tabelele F.7.a. i F.7.b., i com cuta cheile candidat pentru entitile n cauz. $intre aceste chei candidat vom selecta cheia primar, dup criterii de a descrise n capitolul D. 1heile primare i alternante pentru entitile din vie;#ul JLocatariK i vie;#ul J1heltuieliK, sunt afiate n ane6a F.7. 8enionm, c n acest pas nu asociem chei primare entitilor slabe, acesast operaie fiind rezolvat n pasul 7.7. &ocumentarea c%eilor primare i alternante*
Page% C?

$ocumentm atributele care compun cheile primare i cheile alternante. *n e6emplu de ducumentare gsii n ane6a F.7. $asul +*5* Specializarea6generalizarea tipurilor de entiti 1pas opional2* 4n acest pas putem dezvolta modelul &(, utiliz'nd procesul de specializare:generalizare asupra entitilor identifcate n pasul 5.5. $ac vrem s folosim procesul de specializare, vom cuta diferenele dintre entiti, iar n cazul procesului de generalizare, asemnrile dintre ele. $e e6emplu, n vie;#ul JLocatariK, entitile Locatari, .amilii i MefLscar au atributele HrLmat, !dresa i Hume n comun. &ntitatea .amilii mai are n plus atributele HrLpers, HrLpersLprez i HrLchei iar entitatea MefLscar are n plus doar atributul $ataLintreareLfunc. &ntitatea Locatari are asociate doar atributele comune cu cele dou entiti. $eci putem generaliza entitile .amilii i MefLscar, pun'nd pe post de superclas entitatea Locatari, iar celelalte dou fiind subclase. (elaia superclas#subclas dintre entitatea Locatari i .amilii respectiv MefLscar este o relaie parial i nondis unct, 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. .igura F.D. reprezint diagrama celor trei entiti dup procesul de generalizare.
)ocatari *r+Mat (ta, *r+-loc ./01 Aparta$ent Scara ./01 *u$e Se% de scara *r+Mat ./01 #ata+intrare+%unc /a$ilii *r+Mat ./01 *r+pers *r+pers+prezente *r+c3ei

"igura 0.,. &6emplu de relie superclas # subclas

$asul +*7* &esenarea modelului E'* Pentru o mai bun nelegere a modelului local creat, folosim diagrama &(. !ceast diagram i documentaia creat se refer la modelul local conceptual. $iagramele &( ale celor dou vie;#uri ai e6emplului nostru se pot vedea n figura F.F.a., respectiv F.F.b. $asul +*8* 9erificarea modelului conceptual local cu ajutorul utilizatorului* 4nainte de a termina pasul 5, trebuie verificat modelul la care s#a a uns. $ac se descoper erori, atunci ne ntoarcem la pasurile anterioare i le remediem. Vom repeta aceti pai p'n c'nd modelul creat va fi n conformitate cu realitatea.

Page% CB

)ocatari

Sunt locuite de Scari Se co$pun din

Se% de scara

/a$ilii

Aparta$ente

"igura 0.0.a. 8odelul conceptual local al vie;#ului JLocatariK

Scari

/a$ilii Trebuie sa plateasca Pri$esc

Sunt platite de /urnizori

Plati

C3itante Sunt platite de

C3eltuieli

Pro4oaca

"igura 0.0.b. 8odelul conceptual local al vie;#ului J1heltuieliK.

$asul +. Crearea 'i validarea modelului local de date. 4n acest pas revizuim modelul creat i eliminm acele structuir care se pot implementa greu n sistemul de gestiune a bazelor de date. $up aceea validm modelul, utiliz'nd metoda normalizrii i a tranzaciilor. $asul ,*+* $roiectarea modelului local conceptual #n modelul local logic* 4n 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% ,5-&liminarea relaiilor de tipul H%8. ,7-&liminarea relaiilor comple6e. ,D-&liminarea relaiilor recursive. ,F-&liminarea relaiilor cu atribute. ,C-(ee6aminarea relaiilor de tipul 5%5. ,@-&liminarea relaiilor redundante. 1+2 Eliminarea relaiilor de tipul N"=* 1um putem observa i n figura F.F.b., relaiile 1heltuieli Sunt pltite de .amilii i 1heltuieli Sunt pltite de "cri au cardinalul de H%8. Vom descompune aceste relaii n c'te dou relaii de tipul unu#la#multe ,5%8-, numite n ambele cazuri Se
Page% C>

calculeaz i Au c%eltuieli. !ceast modificare devin posibil prin introducerea a doi entiti noi, numite PeLfamilii, respectiv PeLscri. !ceste entiti noi vor fi entiti slabe, pentru c vor depinde de entile 1heltuieli, .amilii i "cri. !dic cheia primar a lor va fi derivat din cheia primar a entitilor tari. 8odificrile se pot observa n figura F.C.
Scari /a$ilii Trebuie sa plateasca Au c3eltuieli Plati Pe scari C3itante C3eltuieli Se calculeaza Au c3eltuieli Pri$esc Pe %a$ilii Se calculeaza Pro4oaca /urnizori

"igura 0.1. Vie;#ul J1heltuieliK, dup eliminarea relaiilor H%8. 1,2 Eliminarea relaiilor comple;e* 4n acest pas, eliminm toate relaiile comple6e ,care sunt ntre mai mult dec't dou entiti- din modelul conceptual. !ceast eliminare se poate rezolva prin crearea a noi entiti. &6emplul nostru nu conine nici o relaie comple6. 1.2 Eliminarea relaiilor recursive* Pasul acesta este pentru eliminarea tuturor relaiilor recursive, adic acele relaii care pun n relaie o entitate cu el nsi. 4n e6emplul nostru nu avem astfel de cazuri. 132 Eliminarea relaiilor cu atribute* "e elimin toate acele relaii, care au asociate atribute. &liminarea se realizeaz prin adugarea a noi entiti, care vor memora aceste atribute. Hu este cazul e6emplului nostru. 142 'ee;aminarea relaiilor de tipul +"+* 4n foarte multe din cazuri, entitile care sunt relaionate prin relaii cu cardinalul 5%5, se pot ngloba ntr#o singur entitate. $e aceea este indicat ree6aminarea relaiilor de tipul unu#la#unu. &6emplul nostru nu conine relaii de acest tip. 152 Eliminarea relaiilor redundante* Pot e6ista cazuri n care s avem relaii redundante. !dic s se poat a unge de la o entitate la alte prin mai multe drumuri diferite. 4n acest caz relaiile redundante trebuie eliminate, pentru c noi trebuie s a ungem la o baz de date minimal i foarte stabil. Hu este i cazul e6emplului nostru. &esenarea diagramei E'* 8odelul conceptual care este reprezentat n figura F.F. a. i b., s#a modificat n acest pas. !m eliminat din acest model, toate structurile greu de implementat ntr#un sistem de gestiune a bazelor de date. $iagrama modificat se va numi n continuare modelul local logic al bazei de date. !cest model este prezentat n figura F.@.a. i
Page% @I

F.@.b.
)ocatari Sunt locuite de Scari Se co$pun din

Se% de scara

/a$ilii

Aparta$ente

"igura 0.2.a. 8odelul logic local al vie;#ului JLocatariK.

Scari

/a$ilii Trebuie sa plateasca

Au c3eltuieli Pri$esc C3itante

Pe %a$ilii Se calculeaza C3eltuieli

/urnizori

Au c3eltuieli Plati Pe scari

Pro4oaca

Se calculeaza

"igura 0.2.b. 8odelul logic local al vie;#ului J1heltuieliK. $asul ,*,* (rearea de relaii peste modelul logic local* 4n acest pas vom crea relaiile ntre entitile din modelul logic local de date, cu a utorul mechanismului chei primare:chei strine. Pentru e6emplificarea acestui proces, s lum relaia .urnizori $rovoac 1heltuieli din vie;#ul J1heltuieliK. Vom folosii limba ul de definire a bazelor de date ,$B$L-, pentru descrierea fiecrei relaii. Pentru fiecare entitate tare a modelului, crem o relaie care include toate atributele simple ale entitii. "tructura entitii .urnizori este% "urnizori ,1odLfurnizor, $enumire, 1odLfiscal, 1ont, Banca, "tr., Bl., "c., !p., Loc., Nud.Cheie primar: 1odLfurnizor Pentru fiecare entitate slab, descriem relaia, nclud'nd atributele simple ale entitii, specific'nd cheia strin i entitatea la care se refer aceast cheie strin. "tructura entitii 1heltuieli este% Cheltuieli ,HrLcrt, 1odLfurnizor, 1odLcheltuial, HrLfactur, $ataLfactur, ValoareCheie primar: HrLcrt
Page% @5

Cheie strin : 1odLfurnizor !cest proces continu, p'n c'nd se vor prelucra toade relaiile din baza de date. &ocumentarea relaiilor i a atributelor din c%eile strine* (elaiile derivate pentru vie;#urile JLocatariK i J1heltuieliK se pot vedea n ane6a F.C., la sf'ritul acestui capitol. La crearea relaiilor trebuie actualizat i dicionarul de date, cu atributele nou introduse i cu noile chei primare i alternante.

$asul ,*.* 9alidarea modelului prin normalizare* 4n acest pas validm baza de date prin normalizare. Procesul de normalizare este descris amnunit n capitolul 7. .orma Hormal *nu ,5H.-, eliminarea repetiiilor din atribute. .orma Hormal $oi ,7H.-, eliminarea dependenelor pariale de cheia primar. .orma Hormal 3rei ,DH.-, eliminarea dependenelor tranzitive de cheia primar. .orma Hormal Bo9ce#1odd ,B1H.-, eliminarea anomaliilor care au mai rmas. 3rebuie s analizm fiecare relaie care este edscris n ane6a F.C. Verificm dac relaiile sunt n forma normal Bo9ce#1odd, iar dac gsim unul care nu satisface aceast form normal, ne ntoarcem la paii precedeni i rezolvm problema. Pentru a e6emplifica acest proces, s analizm relaia .urnizori $rovoac 1heltuieli, descris n ane6a F.C. 8enionm c notaiile de aici nu includ cheia strin. "urnizori ,1odLfurnizor, $enumire, 1odLfiscal, 1ont, Banca, "tr, Hr, Bl, "c, !p, Loc, NudCheie primar: 1odLfurnizor Cheie alternant: 1odLfiscal 1odLfurnizor $enumire, 1odLfiscal, 1ont, Banca, "tr, Hr, Bl, "c, !p, Loc, Nud 1odLfiscal 1odLfurnizor, $enumire, 1ont, Banca, "tr, Hr, Bl, "c, !p, Loc, Nud Cheltuieli ,HrLcrt, 1odLfurnizor, 1odLcheltuial, HrLfactur, $ataLfactur, ValoareCheie primar: HrLcrt HrLcrt 1odLfurnizor, 1odLcheltuial, HrLfactur, $ataLfactur, Valoare Pentru acest e6emplu avem urmtoarele demonstraii% Hu e6ist grupuri repetitive n niciunul dintre entiti. $eci relaia este n forma normal unu. .iecare cheie se compune dintr#un singur atribut. $e aceea nu putem avea
Page% @7

dependen parial de cheie. $eci relaia este n form normal doi. Hu e6ist dependene tranzitive de cheie, deci relaia este n form normal trei. .iecare determinant evideniat este cheie, deci relaia este n form normal Bo9ce# 1odd. !cest proces se continu pentru fiecare relaie care apare n ane6a F.C. $asul ,*3* 9alidarea modelului prin tranzaciile cerute* Pentru a valida prin tranzacii un model logic de date, folosim diagrama &(. din figura F.@.a. respectiv F.@.b. i documentaia ntocmit. 4ncercm s rezolvm manual toate tranzaciile cerute de utilizator, folosind doar datele i relaiile din modelul de date creat. $ac 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. 1onsiderm dou posibiliti de verificare a modelului de date. 1onform primei metode, ne asigurm c e6ist n modelul de date toate entitile i relaiile care sunt necesare pentru tranzacia aleas. Pentru a e6emplifica aceast metod, s verificm urmtoarea tranzacie% Crearea 'i modi)icarea 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. ) 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. 1utm acea cheltuial i dac e6ist modificm detaliile despre cheltuial, recreind i legturile la familii sau scri, depinde cine trebuie s plteasc. $ac nu e6ist, atunci apare un mesa de eroare i procedura de modificare se ntrerpe. 4n cazul tergerii unei cheltuieli, prima dat trebuie cutate nregistrrile de legtur a acelor cheltuieli cu scri sau cu familii. $ac e6ist se terg, dup care se terge i cheltuiala. $ac nu e6ist nseamn c nu e6ist nici cheltuiala i se va afia un mesa de eroare. ! doua modaliate de a verifica modelul de date este de a desena cile generate de relaii, pentru fiecare tranzacie n parte. !ceste ci se noteaz cu o linie av'nd o sgeat n direcia tranzaciei. 3ranzaciile descrise n capitolul F.5.7. sunt reprezentate prin diagramele din figurile F.?.a. respectiv F.?.b.

Page% @D

)ocatari
T 3.

T 1.

Sunt locuite de Scari

T 4.

T 2.

Se co$pun din

"igura 0.3.a. $iagrama tranzaciilor cerute la vie;#ul JLocatariK.

Se% de scara

/a$ilii

Aparta$ente

Scari

/a$ilii Trebuie sa plateasca

Au c3eltuieli Pri$esc
T 3. T 2.

Pe %a$ilii Se calculeaza C3eltuieli

/urnizori

Au c3eltuieli Plati Pe scari

T 1. T 2.

C3itante Se calculeaza

Pro4oaca

"igura 0.3.b. 3ranzaciile cerute pentru vie;#ul J1heltuieliK. $asul ,*4* &esenarea diagramei E'* $iagrama &( din figura F.?.a. i F.?.b. ne a uta s identificm uor relaiile critice pentru tranzacii, precum i ariile din modelul creat, care nu iau parte la nici o tranzaciie. $up identificarea i eliminarea acestor arii, redesenm diagrama &(. 4n cazul nostru acest diagram nu se modific. $asul ,*5* &efinirea regulilor de integritate* 4n acest pas identificm acele reguli care s ne garanteze c datele introduse n baza de date rm'n consistente. Putem identifica cinci tipuri de reguli% necesitatea datelor, domeniile atributelor, integritatea entitilor, integritatea relaiilor, reguli date de intreprindere. Necesitatea datelor* Gdentificm acele atribute ale bazei de date, care nu admit valoarea nul. $e e6emplu atributele HrLmat # din entitatea Locatari # i !dresa ,HrLbloc, "cara- # din entitatea "cri. !ceste reguli asupra atributelor modelului sunt descrise n pasul 5.D. i sunt documentate n ane6a F.7. &omeniile atributelor*
Page% @F

$omeniile atributelor identific valorile posibile pe care le poate loa un atribut. $e e6emplu atributul &ta din entitatea locatari poate lua valori ntre #5 i 5II. $omeniile atributelor sunt descrise n pasul 5.F. i sunt documentate n ane6a F.F. !ntegritatea entitilor* 1heia primar a entitilor nu poate lua valori nule. $e e6emplu HrLmat, chiea primar a entitii Locatari nu poate lua valoarea nul. 1heile primare ale fiecrei entiti au fost identificate n pasul 5.@. iar ducumentarea cheilor se gsete n ane6a F.C. !ntegritatea relaiilor* (elaiile dintre entiti sunt reprezentate prin copierea chei primare a entitii JprinteK, n cheia strin a entitii JfiuK. Gntegritatea relaiilor se refer la faptul c dac cheia strin dintr#o entitate slab conine o valoare, atunci aceast valoare s e6ista i n entitatea tare la care este asociat prin relaie. $e e6emplu dac se nregistreaz pli unei familii n entitatea Pli, atunci acea familie trebuie s e6iste i n entitatea .amilii. !tributele care compum cheile primare i cheile strine sunt descrise n ane6a F.C. &ste important ca s identificm regulile relaiilor, pentru ca relaiile dintre entiti s rm'n consistente. 8enionm c relaiile se descriu cu limba ul specific definirii bazelor de date ,$B$L-. Prima dat s considerm cazul c cheile strine au valoare nul. 4n general c'nd participarea entitii slabe la relaie este total, nu se permite valoare nul n cheia strin. $e e6emplu s descriem relaia "cri Se compun din !partamente. &ntitatea !partamente ,slab- particip total la relaie, deci nu admitem valori nule atributelor din cheia strin i anume HrLbloc i "cara. Pe de alt parte, dac entitatea slab particip parial la relaie, putem admite valoare nul i cheii strine. Hu este cazul e6emplului nostru, pentru c nu avem entitate slab cu participare parial. $escriem relaia "cri Se compun din !partamente cu limba ul $B$L% %cri ,HrLbloc, "cara, LiftCheie primar: HrLbloc, "cara Apartamente ,HrLbloc, "cara, !partament, "uprafaa, 1utiiLpotale, HrLprizeLtvCheie primar: HrLbloc, "cara, !partament Cheie strin : HrLbloc, "cara (enul re)erindu5se la "cri ,HrLbloc, "cara4n continuare considerm cazul n care se modific cheia primar a entitii tari. 8enionm 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% .P(P !1QG*H&, 1!"1!$P, "&3!(& H*LP i "&3!(& G8PLG1G3P. $escriem aceste modaliti de modificare:tergere pe baza relaiei "cri Se compun din !partamente, e6tinz'nd n continuare limba ul $B$L.
Page% @C

%cri ,HrLbloc, "cara, LiftCheie primar: HrLbloc, "cara Apartamente ,HrLbloc, "cara, !partament, "uprafaa, 1utiiLpotale, HrLprizeLtvCheie primar: HrLbloc, "cara, !partament Cheie strin : HrLbloc, "cara (enul, Cascad, re)erindu5se la "cri ,HrLbloc, "cara!ceast operaie se e6ecut pentru fiecare relaie descris n ane6a F.C. 'egulile #ntreprinderii* !ceste reguli sunt definite de ntreprindere i reprezint reguli ce trebuie respectate i n viaa de zi cu zi. $e e6emplu lista cu plile locatarilor se poate tiprii doar pe durat de o lun. 3oate aceste reguli sunt prezentate n ane6a F.@. &ocumentarea regulilor de integritate* 3oate cele descrise mai sus se documenteaz n modelul de date. $asul ,*7* 'evizuirea modelului de date cu ajutorul utilizatorului* 4n acest pas revizuim modelul creat cu a utorul utilizatorului. &ste foarte important ca modelul s fie o reprezentare fidel a realitii. *tilizatorul sistemului trebuie s verifice at't diagrama c't i documentaia ntocmit. $ac se gsete o eroare, se vor reface paii necesari pentru corectarea erorii. $asul ,. Crearea 'i validarea modelului global de date. 4n acest pas crem modelul global prin compunerea entitilor de pe diversele modele locale. !cest model global va trebui i ea validat prin normalizare. $asul .*+* (ompunerea modelelor locale #n modelul global* 4n pasul acesta compunem dou modele locale ntr#un model global de date. 8ai multe modele globale se compun tot dou c'te dou, p'n c'nd a ungem 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+2 'evizuirea numelor entitilor i c%eile lor primare* 1omparm numele i cheile primare dintre dou modele locale, comparaie ce este prezentat n tabela F.B. Tip de entitate -vie;5ul 7ocatari/ Cheie primar Tip de entitate Cheie primar -vie;5ul Cheltuieli/
Page% @@

"cri .amilii Locatari Mef de scar !partamente

HrLbloc, "car HrLmat HrLmat HrLmat HrLbloc, "cara, !p.

"cri .amilii

HrLbloc, "car HrLmat

Pli $ata, HrLmat 1hitane HrLchit PeLfamilii HrLcrt PeLscri HrLcrt 1heltuieli HrLcrt .urnizori 1odLfurnizor Tabela 0.=. ) comparaie ntre numele entitilor i ale cheilor lor primare. !ceste similariti dintre entiti arat care sunt acele modele care se suprapun. &ntitile care se suprapun se pot compune, cre'nd o singur entitate cu toate atributele entitii din cele dou modele. 1,2 'evizuirea numelor relaiilor* 4n continuare, comparm numele relaiilor din dou modele de date. ) comparaie ntre modelele Locatari i 1heltuieli este prezentat n tabela F.>. (elaiile sunt incluse n aceast tabel doar o singur dat n direcia de la entitatea tare la cea slab. Tip entitate vie;5ul 7ocatari "cri Tip de relaie Sunt locuite de Se compun din Tip entitate vie;5ul 7ocatari Locatari !partamente Tip entitate vie;5ul Cheltuieli "cri .amilii Tip de relaie Au c%eltuieli Au c%eltuieli <rebuie s plteasc $rimesc Se calculeaz Se calculeaz $rovoac Tip entitate vie;5ul Cheltuieli PeLscri PeLfamilii Pli 1hitane PeLfamilii PeLscri 1heltuieli

1heltuieli .urnizori Tabela 0.>. 1omparaia tipurilor de relaii.

Gnformaiile cuprinse n aceast tabel arat nc o dat aria modelelor care se suprapun. &ste important s inelegem c acelai nume se relaie n dou modele nu nseamn c acele relaii au i acelai rol. 3rebuie s avem mare gri la astfel de nume de relaii ,se numesc homonome-. 8ai e6ist i posibilitatea ca relaii care reprezint aceleai concepte s fie denumite cu nume diferite ,sinonime-. !ceste probleme la identificarea relaiilor se pot rezolva, analiz'nd atributele ,i n particular domeniile cheilor- asociate entitilor care fac parte din relaie.
Page% @?

4n final trebuie s ne asigurm c relaiile pe care le considerm echivalente s reprezinte aceleai relaii i n Jlumea realK. 1.2 (ompunerea entitilor din cele dou modele* 4n acest pas analizm numele i coninutul entitilor din ambele modele. 4n particular, utilizm cheia primar s vedem care dintre entiti sunt echivalente, chiar dac apar sub nume diferite n cele dou modele. !cest pas include urmtoarele activiti% 1ompunerea entitilor cu aceleai nume i aceleai chei primare. 1ompunerea entitilor cu aceleai nume dar cu chei primare diferite. 1ompunerea entitilor cu nume diferite dar cu chei primare aceleai sau diferite. (ompunerea entitilor cu aceleai nume i aceleai c%ei primare* &ntitile care sunt denumite cu aceleai nume i aceleai chei primare n cele dou modele reprezint n general aceleai concepte a Jlumii realeK. $eci aceste entiti sunt cele mai sumpu de identificat. !stfel de entiti sunt de e6emplu entitile "cri i .amilii. &ntitile combinate vor include toate atributele celor duo entiti din cele dou modele, elimin'ndu#se dublurile. &6emplul de compunere a entitii .amilii este prezentat n figura F.5I. (ompunerea entitilor cu aceleai nume dar cu c%ei primare diferite* 4n cazurile c'nd entitile au acelai nume dar cu chei primare diferite, trebuie s identificm i cheile alternante a celor dou entiti. $ac ntre cheile candidat a unei entiti apare cheia primar a celeilalte, atunci compunem entitile i alegem o cheie primar dintre cele dou cei primare. 4n e6emplul nostru nu avem astfel de caz. (ompunerea entitilor cu nume diferite dar cu c%ei primare aceleai sau diferite* Putem nt'lni 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. !ceste entiti se compun ca la cazul anterior, av'nd n plus obligaia de a alege un nume care poate s fie una dintre cele dou nume, sau o nume nou. "igura 0.#?. &6emplu de compunere a dou entiti. -vie;5ul 7ocatari/ "amilii ,HrLmat, HrLpers, HrLpersLprez, HrLcheiCheie primar: HrLmat Cheie strin : HrLmat re)erindu5se la Locatari ,HrLmat-vie;5ul Cheltuieli/ "amilii ,HrLmat, .ondLrulment, .ondLreparaii, !lteLfonduriCheie primar: HrLmat ,modelul globalPage% @B

"amilii ,HrLmat, HrLpers, HrLpersLprez, HrLchei, .ondLrulment, .ondLreparaii, !lteLfonduriCheie primar: HrLmat Cheie strin : HrLmat re)erindu5se la Locatari ,HrLmat132 !ncluderea 1fr compunere2 a entitilor unice #n cele dou modele* $up includerea tuturor entitilor comune n modelul global, mai rm'n alte entiti care nu sunt comune i care nc nu au fost incluse. !ceste entiti se vor include neschimbat n modelul global. !stfel de entiti sunt% 1heltuieli din modelul 1heltuieli, respectiv !partamente din modelul Locatari. 142 (ompunerea tipurilor de relaii din modelele locale* 4n acest pas analizm numele i caracteristicile relaiilor pentru a le putea compune. &ste important de rezolvat conflictele datorate din participarea i cardinalul relaiilor. Humele relaiilor din cele dou modele sunt listate n tabela F.>. (ompunerea relaiilor cu aceleai nume i aceleai caracteristici* !ceste relaii sunt cel mai uor de identificat. 1ompunerea se rezolv prin simpla nscriere a relaiei n modelul global. Pot e6ista situaii c'nd cardinalul sau participarea nu coincid la cele dou modele. 1azul acesta trebuie clarificat cu utilizatorul sistemuli. !tragem atenia c pot e6ista relaii cu aceleai denumiri dar care s aib roluri diferite ,omonime-. (ompunerea relaiilor cu nume diferite dar cu aceleai caracteristici* Gdentificm acele relaii care apar n ambele modele dar cu denumiri diferite. !cest identificare devine evident dup ce observm c relaia leag aceleai entiti. Mi n acest caz trebuie rezolvat problema cardinalului i a participrii. 152 !ncluderea 1fr compunere2 a relaiilor unice pe cele dou modele* Gdentificm toate relaiile pe care nu am inclus#o nc i le includem neschimbat n modelul global. 3oate relaiile descrise n tabela F.>. sunt de acest tip. 172 9erificarea dac s:a omis vre:o entitate sau relaie* !ceast aciune de verificare este foarte important dar i foarte grea de rezolvat. &ntitile i relaiile compuse pot avea chiar alt nume dec't cele de pe modelele locale ceea ce face greu de urmrit includerea entitii sau a relaiei n modelul global. 182 9erificarea c%eilor strine* 4n acest pas verificm dac toate entitile slabe conin cheia strin asociat lor. !ceste chei trebuie s se formeze la compunerea entitilor, ns tot la compunere se pot i redenumii. 1B2 9erificm 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. 1+C2 &esenarea modelului global de date* !cum desenm modelul global de date. 8odelul global al sistemului de eviden a asociaiei de locatari este prezentat n figura F.55. Humele entitilor i a relaiilor se poate schimba la aceast aciune.
Page% @>

1++2 (ompletarea documentaiei* &ste foarte important actualizarea documentaiei, pentru a reflecta modificrile efectuate asupra bazei de date. !ne6a F.?. descrie relaiile modelului global prezentat n figura F.55., folosind limba ul $B$L.
)ocatari Sunt locuite de Scari Aparta$ente Se co$pun din Sunt Au c3eltuieli (ste Patri$oniu Se calculeaza Se% de scara /a$ilii Personal Contin Pe %a$ilii Se calculeaza Ac3itari Se ac3ita Pe scari /urnizori Pro4oaca

Alocate

C3eltuieli

Au c3eltuieli C3itante Pri$esc Trebuie sa plateasca Plati

"igura 0.##. $iagrama global i final &(. $asul .*,* 9alidarea modelului global de date* 4n acelai mod cum am validat modelele locale, trebuie validat i modelul global, folosind normalizarea i validarea prin tranzacii. !cesta este foarte important pentru a verifica ,i demonstra- dac nu cumva s#au introdus erori la crearea modelului global. $asul .*.* 9erificarea posibilitii de e;tindere #n viitor* &ste important ca modelul creat s se poat e6tinde n viitor. $e e6emplu n sistemul de eviden a asociaiei de locatari se va putea introduce un modul care s rezolve salarizarea personalului asociaiei. 8odelul global al aplicaiei este e6tensibil, e6tinderea put'ndu#se realiza cu minime modificri. $asul .*3* &esenarea diagramei E' finale* La acest pas observm c nu am modificat nimic de la ultima diagram desenat, deci diagrama &( final este diagrama din figura F.55. $asul .*4* 9erificarea modelului global cu ajutorul utilizatorului*
Page% ?I

&ste important s ree6aminm modelul creat mpreun cu utilizatorul, pentru a vedea dac ndeplinete toate cerinele. $ac apar cerine care nu sunt ndeplinite ne ntoarcem la paii anteriori i remediem situaia.

Page% ?5

Ane8a 4.1. #ocu$entarea tipurilor de entiti ?n 4ie@=urile )ocatari i C3eltuieli 3ipurile de entiti din vie;#ul JLocatariK% (ume tip Descriere Aliasuri de entitate Locatari )amenii care locuiesc n asociaie .amilii .amiliile din asociaie 1apLfamilie Entiti Persoanele care au domiciliul n asociaie 1'te o persoan din fiecare familie, considerat reprezentantul acesteia 1'te o persoan de pe fiecare scar din asociaie .iecare scar care aparine asociaiei, mpreun cu caracteristicele ei. .iecare apartament din asociaie, mpreun cu caracteristicile ei. Entiti !nalog ca la JLocatariK !nalog ca la JLocatariK .iecare furnizor cu care s# a lucrat vreodat n asociaie .iecare factur, care reprezint o cheltuial a locatarilor din asociaie. Plile calculate pentru fiecare familie 3oate chitanele emise ctre locatari.

"efL"cara "cri

Persoana care se ocup cu problemele unei scri. "crile din asociaie

!partamente

!partamentele din asociaie

3ipurile de entiti din vie;#ul J1heltuieliK% (ume tip Descriere Aliasuri de entitate "cri "crile din asociaie .amilii .amiliile din asociaie 1apLfamilie .urnizori "ocietile de la care vin facturile 1heltuieli Pli 1hitane 1heltuielile asociaiei ctre furnizori Plile calculate 1hitanele emise

Page% ?7

%ne6a 4.2. "ocumentarea atributelor !tributele tipurilor de entiti din vie;#ul JLocatariK% Tip de Atribute Descriere Tip de date 'i entitate lungime Locatari 4ntreg 4ntreg R#5,5IIS 4ntreg 7C de caractere .amilii 1a la Locatari plus Hr. pers. n familie 4ntreg Hr. pers. prezente n 4ntreg luna curent HrLchei Hr. de chei de la ua 4ntreg principal "efL"cara 1a la Locatari 1a la Locatari plus plus $ataGntr.unc $ata intrrii n func $at "cri !dresa ,HrLbloc, "caraLift &6ist sau nu lift Logic !partamente !partament !partamentul 4ntreg "uprafaa "up. total a ap. (eal 1utiiLpotale Hr. cutii potale 4ntreg HrLprizeLtv Hr. prize tv. 4ntreg HrL8at &ta !partament Hume 1a la Locatari, plus HrLpers HrLpersLprez $et. unic locatarii &ta ul la care loc. !partamentul Humele locatarului eguli 1heie primar *aloare Alias *aloare Derivat@ implicit nul Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu $a 1a la Locatari 1heie primar Hu Hu Hu Hu Hu Hu
Page% ?D

1a la Locatari Hu Hu Hu

Hu Hu Hu Hu Hu Hu

!tributele tipurilor de entiti din vie;#ul J1heltuieliK% Tip de Atribute Descriere Tip de date 'i entitate lungime .amilii HrLmat .ondLrulment .ondLreparaii !lteLfonduri $ata Valoare (estan HrLchit Valoare $ata HrLcrt 1odLcheltuiala HrLfactura $ataLfactura Valoare 1odLfurnizor $enumire 1odLfiscal 1ont Banca !dresa Gdentific familia .ond de rulment .ond de reparaii !lte fonduri Luna pt. care e plata "uma de plat "uma restant Gd. unic chitana Valoarea pltit $ata plii Gdentific cheltuiala 3ipul cheltuielii Humrul facturii $ata facturii Valoarea cheltuialii Gdentific furnizorul Humele societii 1odul fiscal 1ontul bancar Banca "tr,Hr,Bl,"c,!p,Loc 4ntreg (eal (eal (eal $at (eal (eal 4ntreg (eal $at 4ntreg 4ntreg 4ntreg $at (eal 4ntreg DI de caractere 5I caractere 7C de caractere 7I de caractere

eguli 1heie primar

Pli 1hitane 1heltuieli

1heie primar 1heie primar

.urnizori

1heie primar 1heie alt.

*aloare Alias *aloare Derivat@ implicit nul Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu Hu $a Hu $a Hu

Page% ?F

%ne6a 4.3. "ocumentarea tipurilor de rela#ii din 7ie8-urile $9ocatari& ,i $Cheltuieli& 3ipuri de relaii din vie;#ul JLocatariK% Tip de Tip de relaie Tip de entitate entitate "cri sunt locuite de Locatari sunt locuite de .amilii sunt conduse de Mef de scar se compun din !partamente 3ipuri de relaii din vie;#ul J1heltuieliK% Tip de Tip de relaie Tip de entitate entitate .urnizorii provoac 1heltuieli 1eltuieli sunt pltite de .amilii sunt pltite de "cri .amilii trebuie s plteasc Pli primesc 1hitane T PUparial, 3Utotal. Cardinal 5%8 5%8 5%8 5%8 Cardinal 5%8 8%H 8%H 5%8 5%8 $articipareA P%3 P%3 P%3 3%3 $articipareA P%3 P%P P%P 3%3 P%3

%ne6a 4.4. "ocumentarea domeniilor atributelor (ume domeniu &ta "tringDI "tring5I "tring7I Caracteristici 4ntreg ntre #5 i 5II DI de caractere, lungime variabil 5I caractere, lungime variabil 7I de caractere, lungime variabil E:emple IUParter ()80!V

Page% ?C

%ne6a 4.!. "escrierea rela#iilor din 7ie8-urile $9ocatari& ,i $Cheltuieli& $escrierea relaiilor din vie;#ul JLocatariK. 7ocatari ,HrLmat, HrLbloc, "cara, &ta , !partament, Hume, HrLpers, HrLpersLprez, HrLchei, $ataLintrareLfuncCheie primar: HrLmat Cheie strin : HrLbloc, "cara re)erindu5se la "cri ,HrLbloc, "cara%cri ,HrLbloc, "cara, LiftCheie primar: HrLbloc, "cara Apartamente ,HrLbloc, "cara, !partament, "uprafaa, 1utiiLpotale, HrLprizeLtvCheie primar: HrLbloc, "cara, !partament Cheie strin : HrLbloc, "cara re)erindu5se la "cri ,HrLbloc, "cara$escrierea relaiilor din vie;#ul J1heltuieliK% %cri ,HrLbloc, "caraCheie primar: HrLbloc, "cara "amilii ,HrLmat, .ondLrulment, .ondLreparaii, !lteLfonduriCheie primar: HrLmat $li ,$ata, HrLmat, Valoare, (estanCheie primar: $ata, HrLmat Cheie strin : HrLmat re)erindu5se la .amilii ,HrLmatChitane ,HrLchit, HrLmat, Valoare, $ataCheie primar: HrLchit Cheie strin : HrLmat re)erindu5se la .amilii ,HrLmat"urnizori ,1odLfurnizor, $enumire, 1odLfiscal, 1ont, Banca, "tr, Hr, Bl, "c, !p, Loc, NudCheie primar: 1odLfurnizor Cheie alternant: 1odLfiscal Cheltuieli ,HrLcrt, 1odLfurnizor, 1odLcheltuial, HrLfactur, $ataLfactur, ValoareCheie primar: HrLcrt Cheie strin : 1odLfurnizor re)erindu5se la .urnizori ,1odLfurnizor-

$e9)amilii ,HrLcrt, HrLmatCheie primar: HrLcrt

Page% ?@

Cheie strin : HrLcrt re)erindu5se la 1heltuieli ,HrLcrtCheie strin : HrLmat re)erindu5se la .amilii,HrLmat$e9scri ,HrLcrt, HrLbloc, "caraCheie primar: HrLcrt Cheie strin : HrLcrt Cheie strin : HrLbloc, "cara

re)erindu5se la 1heltuieli ,HrLcrtre)erindu5se la "cri ,HrLbloc, "cara-

%ne6a 4./. Re5ulile date de *ntreprindere *n ca(ul modelului $9ocatari& ,i $Cheltuieli& ,5-Lista de pli se elaboreaz doar pe o lun ntreag. ,7-.iecare familie trebuie s declare la nceputul lunii dac va lipsii un membru al familiei toat luna. ,D-Hici o familie nu va putea s se mute p'n c'nd nu si#a pltit toate datoriile.

Page% ??

%ne6a 4.0. Modelul 5lobal de date al sistemului %socia#ia de 9ocatari 7ocatari ,HrLmat, HrLbloc, "cara, &ta , !partament, HumeCheie primar: HrLmat Cheie strin : HrLbloc, "cara (enul, re)erindu5se la "cri ,HrLbloc, "carala tergere i la modificare Cascad. "amilii ,HrLmat, HrLpers, HrLpersLprezente, HrLchei, .ondLrulment, .ondLreparaii, !lteLfonduriCheie primar: HrLmat Cheie strin : HrLmat (enul, re)erindu5se la Locatari ,HrLmatla tergere i modificare Cascad. 8e)9de9scar ,HrLmat, $ataLintrareLfuncCheie primar: HrLmat Cheie strin : HrLmat (enul, re)erindu5se la Locatari ,HrLmatla tergere i modificare Cascad. %cri ,HrLbloc, "cara, LiftCheie primar: HrLbloc, "cara Apartamente ,HrLbloc, "cara, !partament, "uprafaa, 1utiiLpotale, HrLprizeLtvCheie primar: HrLbloc, "cara, !partament Cheie strin : HrLbloc, "cara (enul, re)erindu5se la "cri ,HrLbloc, "carala tergere i modificare Cascad. $li ,$ata, HrLmat, Valoare, (estanCheie primar: $ata, HrLmat Cheie strin : HrLmat (enul, re)erindu5se la .amilii ,HrLmatla tergere "r aciune, la modificare Cascad. Chitane ,HrLchit, HrLmat, Valoare, $ataCheie primar: HrLchit Cheie strin : HrLmat (enul, re)erindu5se la .amilii ,HrLmatla tergere "r aciune, la modificare Cascad. "urnizori ,1odLfurnizor, $enumire, 1odLfiscal, 1ont, Banca, "trada, Hr, Bl, "c, !p, Localitate, NudetCheie primar: 1odLfurnizor Cheie alternant: 1odLfiscal Cheltuieli ,HrLcrt, 1odLfurnizor, 1odLcheltuial, HrLfactur, $ataLfactur, ValoareLfacturPage% ?B

Cheie primar: HrLcrt Cheie strin : 1odLfurnizor (enul, re)erindu5se la .urnizori ,1odLfurnizorla tergere "r aciune, la modificare Cascad. $e9)amilii ,HrLcrt, HrLmatCheie primar: HrLcrt Cheie strin : HrLcrt (enul, re)erindu5se la 1heltuieli ,HrLcrtla tergere i modificare Cascad. Cheie strin : HrLmat (enul, re)erindu5se la .amilii,HrLmatla tergere i modificare Cascad. $e9scri ,HrLcrt, HrLbloc, "caraCheie primar: HrLcrt Cheie strin : HrLcrt (enul, re)erindu5se la 1heltuieli ,HrLcrtla tergere i modificare Cascad. Cheie strin : HrLbloc, "cara (enul, re)erindu5se la "cri ,HrLbloc, "carala tergere i modificare Cascad. $ersonal ,HrLmatricol, Hume, $ataLnaterii, 8eseria, $ataLanga riiCheie primar: HrLmatricol Alocate ,HrLmatricol, HrLbloc, "caraCheie primar: HrLmatricol, HrLbloc, "cara Cheie strin : HrLmatricol (enul, re)erindu5se la Personal ,HrLmatricolla tergere i modificare Cascad. Cheie strin : HrLbloc, "cara (enul, re)erindu5se la "cri ,HrLbloc, "carala tergere i modificare Cascad. $atrimoniu ,HrLinventar, HrLbloc, "cara, $enumire, GnvLfi6, ValoareCheie primar: HrLinventar Cheie strin : HrLbloc, "cara (enul, re)erindu5se la "cri ,HrLbloc, "carala tergere i modificare Cascad. Achitri ,HrLcrt, HrLdoc, 3ipLop, ValoareLachit, $ataCheie primar: HrL$oc, 3ipL)p Cheie strin : HrLcrt (enul, re)erindu5se la 1heltuieli ,HrLcrtla tergere i modificare Cascad.

Page% ?>