ghid de proiectare a bazelor de date

7/30/2019 Ghid de Proiectare a Bazelor de Date

1/79

Ghid de proiectare a bazelor de daterelaionale

Introducere

Proiectarea bazei de date este o munc de colectiv care armonizeaz cerinelei 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 concepiafiierului i incompatibilitatea formatelor de fiiere folosite n diverse limbaje. Acestelimitri implic pierdere de timp i spaiu i posibilitatea de inconsisten a datelor.

Sistemul de baz de date - n opoziie cu vechiul sistem - d posibilitatea de adefinii datele n afara programului i asigur controlul asupra manipulrii datelor.

Definiie: Baz de date: Este o colecie partajat de date legate logic,proiectat pentru a satisface necesitile unui sistem informatic.

Deci datele sunt strnse ntr-o colectie unic i sunt folosite simultan de maimuli utilizatori. Redundana datelor este controlat prin normalizare, ceea ce implic

o redundan minim.

O astfel de baz de date are nevoie de un sistem de gestiune a bazei de date.Acesta este un sistem de programe care fac posibil definirea, ntreinerea i accesulcontrolat la baza de date. Un astfel de sistem trebuie s conin limbajul de definire ilimbajul de manipolare a datelor. Putem aminti urmtoarele limbaje: SQL sau QBE(limbaje generale), respectiv DBASE, FOX PRO, PROGRESS, PARADOX .a.m.d.(limbaje specifice).

Cum se stabilete structura bazei de date? Tocmai prin proiectarea de care ne

ocupm. n opoziie cu proiectarea bazei de date bazate pe fiiere, care pornea de launa sau mai multe aplicaii ale beneficiarului, proiectarea bazei de date se rezolvnaintea elaborarii aplicaiei. De aceea aceast aciune devine esenial pentru totsistemul.

Proiectantul bazei de date trebuie s identifice datele relaionale, relaiile dintreele i restriciile asupra lor. Proiectarea const din dou faze: unul logic i unul fizic.n timpul roiectrii logice este important implicarea viitorilor utilizatori n procesulde proiectare. n proiectarea fizic se decide cum va fi realizat practic modelul logic.

Avantajele i dezavantajele sistemului de baze de date:Avantajele ar fi urmtoarele:

Page: 1


2/79

controlul redundanei consistena datelor economia de spaiu pentru aceleai date

controlul integritii datelor utilizarea standardelor d posibilitatea rspunsului la cereri variate i cu exprimri parial necunorcute la

momentul proiectrii. productivitate crescut concuren crescut posibiliti crescute de recuperare n caz de eroareDezavantaje:

complexitate crescut costul SGBD cost crescut rezultat din cerine de hard costul trecerii de la un sistem la altul o eventual defeciune are un impact crescut, global

Page: 2


3/79

1. Modelarea ER (Entity-Relationship)

n acest capitol vom descrie urmtoarele obiective: Folosirea modelului conceptual de nivel nalt pentru proiectarea de baze de date. Conceptele modelului ER, model de nivel nalt. O tehnic grafic de reprezentare a modelului ER. Modul de identificare a problemelor ce pot aprea la crearea unui model ER. Limitele modelului ER primar i conceptele necesare pentru modelarea aplicailor

complexe. Conceptele modelului EER (Enhanced Entity-Relationship), numite i

specializare/generalizare. O tehnic grafic de reprezentare a specializri/generalizri n modelul EER. Utilizarea produsului ERwin produs de Logic Works, pentru proiectarea bazelor

de date, ceea ce include i modelul ER.Modelul ER (Entity-Relationship) este un model conceptual de nivel nalt

dezvoltat de Chen n 1976, care faciliteaz crearea de baze de date relaionale. nacest capitol, vom descrie conceptele preimare ale modelului ER, dup care vomidentifica problemele care pot aprea la un model ER (Howe, 1989). Vom discutadeasemenea, problemele reprezentrii unor aplicatii, folosind modelul ER (Schmidt

i Swenson, 1975). Avnd n vedere c modelul ER are anumite limite n modelereaaplicatiilor, vom introduce un model mai complex, modelul EER, numit ispecializare/generalizare.

1.1. Conceptele modelului Entity-Relationship

Conceptele primare ale modelului ER includ : tip de entitate, tip de relaie,atribute.

1.1.1. Tipuri de entiti

Definiie: Tip de entitate: Este un obiect sau un concept, identificat de o

ntreprindere, avnd o existen independent.Tipurile de entiti reprezint obiecte reale, din viaa de zi cu zi, avnd proprietilelor, sau obiecte conceptuale, abstracte.

Definiie: Entitate: Un obiect sau un concept ce se poate identifica unic.Un tip de entitate conine mai multe entiti.

Un tip de entitate se identific prin nume i list de atribute. O baz de dateconine n general mai multe tipuri de entiti. Fiecare tip de entitate are propriile luiatribute. Putem clasifica aceste tiburi n tipuri slabe i tipuri tari.

Definiie: Tip slab de entitate: Este un tip de entitate, a crui existen este

dependent de un alt tip de entitate.Definiie: Tip tare de entitate: Este un tip de entitate, a crui existen nudepinde de nici un alt tip de entitate.

Page: 3


4/79

Entitile slabe se mai numesc dependente sau cubordonate iar cele tari printe saudominante.

Reprezentarea grafic a entitilor: Entitile tari se reprezint printr-undreptughi, etichetate cu numele entitii iar cele slabe se reprezint printr-undereptunghi desenat cu linie dubl, etichetate deasemenea cu numele lor.

Exemplu: nume entitate tare nume entitate slab

1.1.2. Atribute

Definiie: Atribute: Proprietaile unui tip de entitate sau de relaie.Definiie: Domeniul atributului: Un set de valori ce se pot da acelui atribut.

Domeniul unui atribut nu se poate definii totdeauna foarte exact. De exemplu,

atributul nume de familie poate lua orice nume de familie existent. Evident, acestatribut trebuie s fie un ir de caractere, dar oare ce caractere poate s conin? Uneledomenii se pot descompune n mai multe subdomenii. De exemplu data naterii se

poate descompune in subdomeniile: an, lun, zi.

Atributele se pot clasifica nsimple sau compuse; cu osingur valoare sau cumai multe valori; respectiv derivate.

Definiie: Atribut simplu: Atribut care are doar o singur component i oexisten independent.Aceste atribute nu se pot diviza mai trziu n mai multe atribute distincte.

Definiie: Atribut compus: Atribut care are mai multe componente i oexisten independent.Aceste atribute se pot diviza n mai multe atribute simple. De exemplu atributuladres se poate descompune n atributele: strada, numr, ora, cod potali jude.Decizia ca un atribut compus s se descompun n mai multe atribute simple estedependent de modul n care se va utiliza acel atribut: separat pe componente, sauntregul atribut.

Definiie: Atribut cu o singur valoare: Atribut care poate lua o singurvaloare pentru fiecare entitate.

Majoritatea atributelor sunt atribute cu o singur valoare, ceea ce este indicat nproiectarea bazelor de date.Definiie: Atribut cu mai multe valori: Atribut care poate lua mai multe valori

pentru fiecare entitate.Atributele cu mai multe valori, trebuie s aib totdeauna o limit inferioar i unasuperioar.

Definiie: Atribut derivat: Atribvut a crei valoare se poate calcula din unul,sau mai multe alte atribute, care nu sunt neaprat atributele entitii n cauz.De exemplu atributul vrsta este derivat din atributul data naterii i data zilei ncare se utilizeaz acest atribut. Alt exemplu ar fi atributul numrul total de entiti,ceea ce se poate calcula, numrnd entitile nregistrate.

Page: 4


5/79

Chei:Intuitiv, o cheie este un atribut, care determin unic o entitate dintr-un tip de

entitate. n continuare, dm o definiie riguroas a cheii.Definiie: Cheie candidat: Un atribut, sau un set de atribute, care identific

unic o entitate ditr-un tip de entitate.Definiie: Cheie primar: O entitate poate s aob una sau mai multe chei

candidat, din care doar una selectat este i primar.Decizia referitoare la care din chile candidate s fie cheie primar este dependent delungimea cheii. Cheia primar este de obicei cea mai scurt dintre cheile candidat.

Definiie: Cheie compus: O cheie candidat care contine cel putin douatribute.

Reprezentarea grafic a atributelor:

Un atribut se reprezint printr-o elips, legat de entitatea de care aparine cu olinie i etichetat cu numele atributului. Elipsa este punctat, dac atributul este unatribut derivat; respectiv dublat, daca poate lua mai multe valori.

Dac un atribut este compus, atunci componentele atributului se reprezint nelipse legate printr-o linie de atributul compus.

Atributurile care intr n componena cheii primare, se noteaz prin subliniereanumelui atributului.

Exemplu:

n acest exemplu, entitatea Locatari, fiind o entitate tare, are urmtoarele

atribute: Numr matricol, Nume i Adresa. Dintre aceste atribute, atributul Numrmatricoleste cheie primar; atributulAdresa este atribut compus, care se descompunenNumr bloc, Scara, Etaj iApartament.

1.1.3. Tipuri de relaii

Definiie: Tip de relaie: Asociere ntre tipuri de entiti.Definiie: Relaie: Asociere ntre entitti, cnd asocierea include un tip de

entitate dintre toate tipurile participante.

Reprezentarea grafic a relaiilor: Relaiile se reprezint printr-un rombetichetat cu numele relaiei. Rombul se deseneaz cu linie dubl, dac relaia leag oentitate slab de entitatea tare de care aparine.

Page: 5

Locatari

Nume

Numrmatricol

Adresa

Numrbloc

Scara

Etaj

Apartament


6/79

Definiie: Gradul relaiei:Nmrul entitiilor participante n relaie.Entitiile dintr-o relaie se numesc participani. Numrul lor d gradul relaiei. Dacintr-o relaie sunt doi participani, atunci relaia se numete binar.

Definiie: Relaie recursiv: Relaie n care aceleai entiti particip n roluridiferite.

n cazul relaiilor recursive cele dou arce de la entitate la relaie i napoi,primesc diferite etichete, care sunt importante n nelegerea corect a relaiei.

1.1.4. Atributele relaiilor

Atributele descrise mai sus, se pot asocia i relaiilor. Aceste atribute sereprezint grafic, ca i atributele entitiilor, cu deosebirea c legtura nu este cu oentitate, ci cu o relaie. Adic linia leag elipsa de rombul ce semnific relaia.

1.2. Structuralitatea

S analizm acum restriciile ce pot aprea la includerea unei entitiparticipante ntr-o relaie. Avem dou tipuri mari de restricii: cardinalitatea iprticiparea.

1.2.1. Cardinalitatea

Definiie: Cardinalul este numrul relaiilor posibile pentru o entitatepartricipant.

Majoritatea relaiilor au gradul doi, care pot fi: unu-la-unu (1:1), unu-la-multe

(1:M), sau multe-la-multe (M:N).Relaiile unu-la-unu:n relaiile unu-la-unu, o entitate este legat de cel mult o entitate din partea

cealalt a relaiei. Aceast relaie se reprezint grafic prin etichetarea arcului dintrerelaie i entitate cu cardinalul relaiei, adic cu 1.

Relaiile unu-la-multe:Relaia de tip unu-la-multe are cardinalul 1 n stnga i N n dereapta. Deci o

entitate participant este legat n relaia respectiv de 0, 1, sau mai multe entiti.Exemplificm acest tip de relaie prin relaia Sunt locuite dintre tipurile de entiti

Scri, respectiv Locatari.

Page: 6

Sc.A

Sc.B

Sc.C

Scri Sunt locuite de

R1

R2

R3

Fam.1

Fam.2

Fam.3

LocatariNr_blocScara

Nr_blocScara

Nr_blocScara

AtributeNr_matNumele

Nr_mat

Numele

Nr_matNumele

Atribute


7/79

Figura 1.1. Exemplu de relaie 1:M

n reprezentarea grafic a relaiilor, relaia unu-la-multe se noteaz cuetichetarea arcului cu 1 n partea stng i cu N n partea dreapt. Din exemplul demai sus observm c dac relaia direct este de unu-la-multe, atunci relatia inverseste de unu-la-unu.

Relaiile multe-la-multe:Acest tip de relaie se deosebete de relaia unu-la-multe prin faptul c relaia

invers nu este de unu-la-unu, ci de unu-la-multe. Deci, dac i relaia direct ireaia invers este de tipul unu-la-multe, atunci relaia este de tipul multe-la-multe i

se noteaz cu (N:M).1.2.2. Participarea

Definiie: Participarea determin dac existena unei entiti depinde sau nu derelaia cu o alt entitate.

Participarea poate fi de mai multe tipuri: total iparial. n cazul participriitotale, toate entitiile particip n relaia dat. n caz contrar participarea se numete

parial. n diagrama ER aceste tipuri de relaii se reprezint prin arc cu linie dublpentru participarea total, respectiv cu linie simpl pentru participarea parial. Pentruparticiparea parial, exist un mod de notaie prin care se eticheteaz arcele relaiei

cu perechea de numere ce reprezint minimul, respectiv maximul entitiilorparticipante la relaie.

1.3. Problemele modelului ER

n acest capitol vom examina numeroasele probleme ce pot aprea la modelareaunei baze de date. Aceste probleme se refer la capcanele care pot aprea la definirearelaiilor ntre tipuri de entiti. Amintim dou tipuri mari de capcane: de tip labirint(fan trap), respectiv de tip prpastie (chasm trap).

Definiie: Fan trap (capcan de tip labirint): Acest tip de capcan reprezintcazul n care modelul reprezint o relaie ntre dou tipuri de entiti, dar calea dintrecele dou membrii este ambigu.

Cu alte cuvinte, pornind de la o entitate, nu se tie ca dup parcurgerea ciirelaiilor, la ce entitate se ajunge n partea cealalt. Aceast capcan se poate elimina

prin rearanjarea ordinii relaiilor dintre cele dou tipuri de entiti.Cellalt tip de capcan este:Definiie: Chasm trap (capcan de tip prpastie): Acest tip de capcan se

descrie prin faptul c modelul sugereaz existena relaiei ntre cele dou tipuri deentitate, dar calea dintre tipurile de entiti nu exist.

Aceast problem provine din participarea parial a unor entiti la una dintre

relaii. Problema se poate rezolva prin introducerea unei relaii directe.

Page: 7


8/79

1.4. Modelul Enhanced Entity-Relationship (EER)

Modelul ER, discutat n capitolele de mai sus, este adecvat pentru descriereamultor scheme de baze de date. Din 1980 s-au dezvoltat foarte mult aplicaiile care

folosesc baze de date. Modelul ER nu mai era suficient pentru reprezentareacomplexelor scheme de baze de date. De aceea s-au introdus alte concepte nmodelul ER, dezvoltnd modelul EER.

Modelul EER include toate conceptele modelului ER, plus alte completridevenite necesare. Aceste concepte sunt nou introduse sunt:specializarea/generalizarea, categorisirea i ncapsularea. n acest capitol vomdescrie conceptele de baz a modelului EER i anume, specializare/generalizare.

Specializarea/generalizarea este n strns legtur cu modul de desciere atipurilor de entiti n superclase i subclase, precun i de motenirea atributelor. Deaceea vom descrie aceste concepte.

1.4.1. Superclasele i subclasele tipurilor de entiti

Vom descrie aceste concepte, avnd ca exemplu tipul de entitate Locatari.Definiie: Superclas: Superclasa este un tip de entitate care include subclase

distincte reprezentate ntr-un model de date.Definiie: Subclas : Subclasa este un tip de entitate care are un rol distinct i

este membru al unei superclase.De exemplu superclasa Locatari se divizeaz n dou subclase i anume: ef

de scar i Familii. Relaia dintre o superclas i o subclas se numete relaie

superclas/subclas. Aceast relaie este de tip unu-la-unu. Relaia Locatari/Familiide exemplu, este o astfel de relaie.Fiecare membru al unei subclase este membru i n superclas, dar are un rol

diferit. Exist subclase case se suprapun, adic exist membrii ntr-o subclas careapar i n cealalt subclas. Putem observa c exemplul de mai sus este exact de acesttip, pentru c eful de scar poate s fie i cap de familie.

De ce se folosete clasificarea n subclase? Rspunsul este simplu de observatdirect din exemplul dat. Dac nu am clasifica entitiile din tipul de entitateLocatari, atunci ar trebui s memorm informaiile specifice efului de scar icapului de familie pentru fiecare locatar. Deoarece majoritatea locatarilor nu aparine

niciunei categorii, pentru acestea ar fi informaii nefolositoare, dar care ns ar ocupamult spaiu pe suportul magnetic.

1.4.2. Motenirea atributelor

Fiecare subclas are ca atribute comune, atributele superclasei n care aparine.Deci fiecare membru al unei subclase se caracterizeaz prin atributele superclasei ialte atribute specifice subclasei. De exemplu subclasa Familii se caracterizeaz printoate atributele superclasei Locatari (Numr matricol, Numr bloc, Scara, Etaj,

Apartament i Nume), pe lng care mai are i ate atribute specifice (Numrpersoane,Numr persoane prezente, etc.)

Fiecare subclas poate s aib subclase, crendu-se un arbore de clase, care senumete ierarhie de tipuri. Aceast ierarhie de tipuri include alte denumiri de ierarhii

Page: 8


9/79

i anume: ierarhia de specializri (de exemplu, tipul de entitate Familii este ospecializare a tipului de entitate Locatari) i ierarhia de generalizri (de exemplu,

Locatari este o generalizare a tipului de entitateFamilii).

1.4.3. SpecializareaDefiniie: Specializare este un proces de maximizare a diferenelor unor

membrii ale unei entiti, identificnd caracteristicile distincte.Specializarea este o aproximare top-down a definirii unor superclase, mreun

cu subclasele lor. Relaia superclas/subclas se reprezint grafic printr-un arc de lasuperclas la un cerc, care la rndul lui este legat cu un arc de subclas. Pe arcele dela subclase se deseneaz un semn de incluziune de la subclas la superclas. Acestesemn de incluziune indic direcia relaiei superclas/subclas.

Atributele specifice doar subclasei sunt ataate direct la dreptunghiul care

reprezint subclasa.Toate aceste notaii se exemplific n figura de mai jos:

n exemplul de mai sus tipul superclasa Locatari se compune din mai multesubclase: ef de scar i Familii. Superclasa Locatari va avea ca membrii pe toilocatarii unei scri. ntre aceti locatari, unii sunt capi de familii iar alii efi de scar.Aceti membrii ai tipului de entitate Locatari vor aprea ca membrii i n subclaseleef de scar, respectivFamilii.

Definiie: Subclas partajat se numete subclasa care are mai multe

superclase.Membrii din subclasa partajat sunt membrii n fiecare dintre superclase. Deaceea ei motenesc atributele fiecrei superclase o astfel de motenire se numetemotenire multipl.

n cazul relaiilor, dac o subclas este n relaie cu un alt tip de entitate,aceast relaie se refer doar la subclasa respectiv, nu i la superclasa lui.

1.4.4. Generalizarea

Definiie: Generalizare se numete procesul de minimizare a diferenelordintre entiti, pentru identificarea caracteristicilor comune.

Procesul de generalizare este o aproximare bottom-up a superclaselor, dinsubclasele originale. Deci generalizarea este inversa specializrii. De exemplu dacprivim tipurile de entiti Familii i ef de scar, vom observa c unele atribute ale

Page: 9

LocatariNumrmatricol

Numrbloc Adresa

ef de scar

Data

intrrii nfuncie

Familii

Numrpersoane


10/79

lor caracterizeaz ambele tipuri. De aici rezult necesitatea crerii unei superclasecare s conin toate atributele comune celor dou tipuri.

1.4.5. Regurile specializrii i generalizrii

n acest capitol vom discuta despre regulile ce trebuie aplicate n cazulspecializrii sau al generalizrii.

Prima regul se numete regula disjunciei. Aceast regul specific dacsubclasele unei clase sunt disjuncte, adic un membru al superclasei aparine cel multuneia dintre subclase. O specializare disjunct se reprezint cu un d nscris n cerculcare leag subclasele de superclase.

Dac subclasele nu sunt disjuncte, adic un membru al superclasei poate saparin la mai multe subclase, atunci subclasele respective se numesc non disjunctei se noteaz cu o n cercul care leag subclasele de superclase. n exemplul nostru

subclasele Sef de scar i Familii - care sunt subclasele clasei Locatari - sunt nondisjuncte.A doua regul a specializrii este regula participrii, care poate fi total sau

parial. Participarea este total dac toi membrii superclasei sunt i membriisubclaselor. Pentru reprezentarea participrii totale, arcul de la superclas la cerculdintre superclas i subclas se dubleaz.

n cazul participrii pariale nu toi membrii superclasei iau parte ntr-osubclas. Acest tip de participare se reprezint cu linie simpl ntre superclas i cerc.n exemplul nostru avem o participare parial n cazul superclasei Locatari, cusubclasele ef de scar iFamilii.

Cele dou reguli se aplic distinct la procesele de specializare, saugeneralizare. De aceea putem avea patru tipuri de specializri: disjunt total,disjunct parial, non disjunct total, sau non disjunct parial.

1.5. Descrierea cerinelor sistemuluiAsociaie de locatari - Crearea unui model EER

n acest capitol vom demonstra crearea unui model EER. Vom descrie cerinelesistemului informatic pentru asociaia de locatari, dup care vom identifica entitile,

relaiile, cardinalitatea i participarea relaiilor i atributele asociate entitilor. Duptoate aceste identificri vom crea diagrama EER asociat aplicaiei.

1.5.1. Descrierea sistemului informaic Asociaia de locatari

(1) O asociaie de locatari se compune din una sau mai multe scri, aflate n una saumai multe blocuri indentificate prin numr bloc i numr scar. Pe fiecare scarlocuiesc locatari dintre care se alege un ef de scar. Fiecare dintre scri secompune din apartamente, avnd informaii prin care se poate face relaia la

scri, precum i alte informaii constnd din: numr apartament, suprafaa,numrul cutiilor potale, a prezelor tv., a legturilor la coul de fum i altele.

(2) Locatarii sunt identificai printr-un numr matricol unic n toat asociaia dePage: 10


11/79

locatari. Informaiile despre ei sunt memorate n numr bloc, scara, etaj,apartament - reprezentnd adresa - i nume. Unii dintre locatari pot fii efi descar si/sau capi de familii, ceea ce implic alte informaii n plus pentru aceste

persoane. Aceste informaii sunt: pentru ef de scar, data intrrii n funcie iarpentru capul de familie, numrul de persoane, numrul de persoane prezente,numrul de chei, valoarea fondului de rulment, a fondului de reparaii, a altorfonduri, precum i plata curent i restana.

(3) n fiecare lun se primesc facturi de la diferii furnizori, reprezentnd cheltuielileasociaiei de locatari. Aceste cheltuieli sunt identificai unic de un numr decheltuial i au n componena informaiilor o informaie prin care se facelegtura cu un furnizor, tipul de cheltuial, numrul, data i valoarea facturii iscadena. Aceste scheltuieli pot fii pe una sau mai multe scri sau pe una sau maimulte familii.

(4) Cheltuielile se vor pltii de asociaia de locatari ori prin virament, ori prin cas.(5) Locatarii i pltesc datoriile la asociaia de locatari cu bani ghea, primind cadovad a plii, chitane. Despre pli se memoreaz o legtur la capul defamilie care a efectuat plata, numrul, data i valoarea chitanei.

(6) Furnizorii de la care vin facturile la asociaia de locatari, se identific unic printr-un cod local, sau dup codul fiscal. Pe lng aceste informaii mai memorminformaii despre denumire, contul, banca i adresa sediului.

(7) Calculul pliilor pentru locatari se va face la nceputul fiecrei luni, pentru lunaanterioar, memornd data efecturii calculului, numrul matricol al capuluifamiliei pentru relaie, valoarea i restana pentru luna aceea. Dup listarea

plilor nu se mai admit modificri.(8) Fiecare scar este ntreinut de un personal identificat de un numr matricol

(alta dect la locatari) i avnd informaiile: legtura la scara unde lucreaz,numele, data naterii i a angajrii i meseria.

(9) n asociaia de locatari pot fi mijloace fixe i obiecte de inventar, identificate prinnumrul de inventar i avnd ntre informaii legtura la scara unde suntamplasate. Se mai poate memora despre ei denumirea, valoarea i valoareaamortizat.

1.5.2. Crearea modelului EERn acest capitol von demonstra crearea modelului EER. Vom crea modelul EERpentru Asociaia de locatari, folosind descrierea de mai sus.

Identificarea tipurilor de entiti:La nceput identificm tipurile de entiti din specificaiile de mai sus:

Scari CheltuieliApartamente AchitriLocatari Patrimoniuef de scar PersonalFamilii Obiecte de inventar

Page: 11


12/79

Pli FurnizoriChitane

Identificarea tipurilor de relaii:

Vom identifica tipurile principare de relaii. Relaiile sunt reprezentate deverbele lor n tabela de mai jos.

Tip de entitate Tip de relaie Tip de entitate

Scri sunt locuite de Locatarise compun din Apartamente

sunt ntreinute de Personalse folosete Patrimoniu

Familiile trebuie s plteasc Pli

Primesc ChitaneFurnizorii Provoac Cheltuieli

Cheltuielile se calculeaz pentru Scrise calculeaz pentru Familii

se achit prin Achitri

Determinarea cardinalitii i a participrii n tipurile de relaii:Considerm relaia Scri-le sunt locuite de Locatari. O singur scar este

locuit de mai muli locatari. Deci pn acum cardinalitatea este de 1:M, ns trebuies verificm i relaia invers - Locatarii locuiesc pe Scri - unde se observ c unlocatar locuiete pe o singur scar. Deci n final, cardinalitatea relaiei este 1:M. ncontinuare fie relaia Cheltuielile se calculeaz pentru Scri. Observm c putem aveamai multe scri la care s se refere o cheltuial, precum i mai multe cheltuieli pentruo scar. Deci cardinalul relaiei este de N:M.

S analizm acum participarea la relaie a membriilor tipurilor de entiti:Fie relaia Scri-le sunt locuite de Locatari. Putem avea cazul n care o scar s

nu fie locuit deloc de locatari. n cazul relaiei inverse nu putem avea cazul n care unlocatar s nu locuiasc pe nici o scar. Deci relaia direct este parial, iar ceainvers este total.

Cardinalitatea i participarea celorlaltor relaii este artat n urmtorul tabel:

Tip de entitate Tip de relaie Tip de entitate Card. Direct InversScri sunt locuite de Locatari 1:M parial total

se compun din Apartamente 1:M total totalsunt ntreinute de Personal 1:M partial total

se folosesc Patrimoniu 1:M parial totalFamiliile trebuie s plteasc Pli 1:M parial parial

primesc Chitane 1:M parial parialFurnizorii provoac Cheltuieli 1:M parial total

Cheltuielile se calculeaz pentru Scri M:N total parial

Page: 12

Participarea


13/79

se calculeaz pentru Familii M:N total parialCheltuielile se achit prin Achitri 1:M total total

Am observat c relaia Cheltuilile sunt de tipul Tip cheltuial are cardinalulM:1. De accea avnd n vedere convenia c relaiile se denumesc n direcia 1:M vomschimba numele relaiei n Tip cheltuial este tipul unei Cheltuieli.

Indentificarea atributelor asociate entitiilor:Vom identifica atributele entitiilor, atribute ce descriu caracteristicile

entitiilor. Aceste atribute sunt trecute n urmtorul tabel:

Tip entitate Atribute Tip entitate AtributeScri Nr_bloc ef de scar Nr_mat

Scara Nr_BlocLift Scara

Apartamente Apartament EtajNr_bloc ApartamentScara NumeSuprafaa Data_intrare_funcCutii_potale Familii Nr_Mat

Nr_prize_tv Nr_BlocLocatari Nr_mat Scara

Nr_Bloc EtajScara ApartamentEtaj NumeApartament Nr_pers

Nume Nr_pers_prezentePli Data Nr_chei

Nr_mat Fond_rulmentValoare Fond_reparaiiRestan Alte_fonduri

Furnizori Cod_Furnizor Chitane Nr_Chit

Denumire Nr_MatCod_fiscal ValoareCont DataBanca Cheltuieli Nr_CrtStrada Cod_Cheltuial

Nr Cod_FurnizorBl Nr_facturSc Data_facturAp Valoare_facturLocalitate Achitri Nr_crtJude Nr_Doc

Personal Nr_matricol Tip_Op

Page: 13


14/79

Nr_bloc Valoare_AchitScara Data

Nume Patrimoniu Nr_inventarData_naterii Nr_blocMeseria ScaraData_angajrii Denumire

Inv_FixValoare

Determinarea cheilor canditat i cheilor primare:Vom analiza cheile candidat al fiecrei tip de entitate i vom alege una din ele

s fie cheie primar. De exemplu n tipul de entitate Locatari aven o cheie candidat,numit Nr_mat. Deci aceast cheie va fi cheia primar. n general cheia cea mai

simpl este aleas n funcia de cheie primar.n tabela urmtoare specificm cheile primare si alternante ale fiecrei tip deentitate:

Tip entitate Cheie primare Chei alternanteScri Nr_bloc, ScaraApartamente Nr_bloc, ScaraLocatari Nr_Matef de scar Nr_Mat

Familii Nr_MatPli Data, Nr_MatChitane Nr_ChitCheltuieli Nr_CrtFurnizori Cod_Furnizor Cod_fiscalAchitri Nr_Doc, Tip_OpPersonal Nr_matricolPatrimoniu Nr_inventar

Specializarea sau generalizarea tipurilor de entiti:

n final putem lua decizia de a specializa o clas. Dac avem tipuri de entiticare au aceleai atribute, atunci putem generaliza aceste tipuri de entiti. Deexemplu din tabelul n care apar atributele tipurilor de entiti, putem observa ctipurile de entiti Locatari, ef de scar i Familii au multe atrbute comune. Deci

putem generaliza tipurile de entiti ef de scar i Familii la tipul de entitateLocatari. Dup generalizare vom avea o relaie de specializare/grneralizare, care nueste disjunct i este parial.

Desenm diagrama EER:

Folosind toate informaiile descrise mai sus, desenm diagrama EER asistemului informatic al Asociaiei de locatari.

Page: 14


15/79

Scule CASE pentru crearea modelului ER.

n acest capitol vom descrie produse CASE (Computer Aided SoftwareEngineering) care ne ajut la proiectarea bazelor de date relaionale. La elaborarea

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

Pentru crearea unui model ER se folosesc butoanele din fereastra ERwin

Toolbox. Cu aceste butoane se poate proiecta baza de date, desennd tabelele irelaiile dintre ele.

Cum crem o entitate? Pentru a crea o entitate, selectm butonul i lpoziionm undeva n pagin. Va aprea un dreptunghi, care are delimitat douseciuni: cheia principal (deasupra liniei orizontale) i atributele asociate entitii (sublinia orizontal). Deasupra dreptunghiului apare numele tipului de entitate. Dac

entitatea este dependent, atunci se selecteaz butonul .

Exemplu de entiti:

Page: 15


16/79

Locatari

Nr_Mat

Etaj

Nr_Bloc (FK)ApartamentScara (FK)Nume

Plati

Data

Nr_Mat (FK)

Valoare

Restanta

Numele acestei entitilor sunt Locatari - entitate independent - i Pli -entitate dependent. n cazul entitii Locatari, seciunea chei principale se compunedin cmpul Nr_Mat iar cmpurile de sub linie sunt atributele asociate entitii.

n teoria de mai sus aceste informaii sunt reprezentate grafic n urmtorul mod: tip de entitate se reprezint cu un dreptunghi etichetat cu numele entitii

atributele se reprezint cu o elips etichetat cu numele atributului atributele din cunponena chei principale se subliniaz

Cum notm cheile candidate? La editarea numelui atributului care este coninutntr-o cheie candidat, se trece n continuarea numelul textul: (AKn), unde n reprezintnumrul chei candidat de care aparine atributul. n exemplul nostru Nume este cheiecandidat.

Cum evideniem un tip de relaie? Selectm butonul corespunztor tipului de

relaie dorit dintre tipurile , reprezentnd relatie identificare de cardinal1:M, N:M respectiv relaie neidentificare. Diferena ntre relaiile identificare ineidentificare este c n cazul primului tip cheia entitii printe migreaz nseciunea de cheie principal a entitii fiu iar n cazul al doilea migreaz n seciuneade atribute.

Exemplu de tip de relaie:

Pentru a specializa/generaliza tipurile de entiti, folosim butoanele ,care reprezint specializare cu participare total respectiv parial. n cazulspecializrii, cheia principal de la tipul de entitate printe, migreaz n seciuneacheii principale a tipului de entitate fiu.

O astfel de relaie este ntre tipurlile de entitateLocatari iFamilii:

Simbolul de specializare de mai sus reprezint, c nu toate entitile din tipul dePage: 16

Scri Cheltuielise calculeaz pentru

Locatari

Familii ef de scar


17/79

entitateLocatari iau parte n una din tipurile de entitiFamilii sau ef de scar. Deciparticiparea este parial.

Suportul produsului ERwin pentru normalizarea bazei de date:ERwin are suport pentru normalizarea bazei de date, dar nu are implementat un

algoritm de normalizare. Ajutorul acordat proiectantului bazei de date const navertizarea acestuia n cazul unor erori la normalizare.

Suportul Formei Normale Unu:n moledul ER atributele sunt identificate prin nume. ERwin accept orice

nume pentru atribute, cu urmtoarele excepii: Avertzeaz n cazul utilizrii unei denumiri de tip de entitate de dou ori (depinde

de setaria opiune Nume unic).

Avertizeaz n cazul folosirii de dou ori a aceluiai nume de atribut, cu excepianumelui de rol.

ERwin nu distinge dac un atribut conine sau nu mai multe informaii. Deexemplu se accept i denumirea Numele copiilor ceea ce poate reprezenta untablou n acel atribut.

Suportul pentru Forma Normal Doi i Trei:ERwin nu cunoate dependenele funcionale din baza de date, dar poate ajuta

la priectarea bazei de date n forma normal doi sau trei. De exemplu avertizeaz n

cazul n care o cheie care migreaz (n cazul unui relaii), apare de dou ori n tipul deentitate. Acesta poate s apar n cazul n care sunt mai multe relaii ntre dou tipuride entiti. Potem opta pentru pstrarea cheii de dou ori, dnd nume diferitecmpurilor, sau pentru unificarea atributelor ce compun cheia.

Baza de date se poate proiecta pe view-uri, ERwin genernd automat imagineantregii baze de date. Se poate selecta modul de reprezentare a bazei de date, opiunilefiind: nivel de entitate, la nivel de chei primare, sau la nivel de atribute. Toate acesteopiuni fiind disponibile pentru nume logice i fizice.

Dup proiectarea bazei de date, acesta se poate exporta n mai multe formate

disponibile, dintre care amintim: FoxPro, Acces, Oracle, Ingres, AS/400, Informix,Progress i altele.

Baza de date a sistemului de gestiune a Asociaiei de locatari proiectat cuERwin este urmtorul:

Page: 17


18/79

Sunt

Este

Primesc

Trebuie sa plateasca

Se calculeaza

Se calculeaza

Au cheltuieli

Au cheltuieli Se compun din

Contin

Sunt locuite de

Provoaca

Se achita

Chitante

Nr_Chit

Nr_Mat (FK)

Valoare

Data

Plati

Data

Nr_Mat (FK)

Valoare

Restanta

Apartamente

Nr_Bloc (FK)

Scara (FK)

Apartament

SuprafataCutii_postale

Nr_prize_tv

Achitari

Nr_Doc

Tip_Op

Nr_Crt (FK)

Valoare_Achit

Data

Furnizori

Cod_Furnizor

Denumire

Cod_fiscal (AK1)

Cont

BancaStrada

Nr

Bl

Sc

ApLocalitate

Judet

Familii

Nr_Mat (FK)

Nr_pers

Nr_pers_prezente

Nr_chei

Fond_rulment

Fond_reparatii

Alte_fonduri

Pe familii

Nr_Crt (FK)Nr_Mat (FK)

Pe scari

Scara (FK)

Nr_Crt (FK)

Nr_Bloc (FK)

Cheltuieli

Nr_CrtCod_Furnizor (FK)

Cod_cheltuiala

Nr_factura

Data_factura

Valoare_factura

Sef de scara

Nr_Mat (FK)Data_intrare_func

Scari

Nr_BlocScara

Lift

Locatari

Nr_Mat

Etaj

Nr_Bloc (FK)

Apartament

Scara (FK)

Nume Patrimoniu

Nr_Inventar

Nr_Bloc (FK)

Scara (FK)

DenumireInv_Fix

Valoare

Personal

Nr_matricol

Nume

Data_nasterii

Meseria

Data_angajarii

Alocate

Nr_matricol (FK)

Nr_Bloc (FK)

Scara (FK)

Page: 18


19/79

2. Normalizarea bazei de date

n acest capitol vom discuta despre: Necesitatea normalizrii Problemele asociate cu informaiile redundante n rnduri. Identificarea tipurilor variate de anomalii ce pot aprea la actualizare:

inserare, tergere i modificare. Procesul de normalizare. Conceptul de dependen funcional, modalitatea de a grupa atributele n

relaii Cum utilizm dependenele funcionale, pentru a grupa atributele n relaii

care sunt n forme normale cunoscute? Cum definesc relaiile, formele normale? Cum derulm procesul de normalizare? Cum identificm prima (1NF), a doua (2NF) i a treia (3NF) form normal,

resprctiv forma normal Boyce-Codd (BCNF)?

2.1. Necesitatea normalizrii

Cnd proiectm o baz de date, dorina noastr este de a reprezenta ct maicorecte informaiile i s diminum ct mai mult posibilitatea de a ajunge la informaiieronate (dac nu putem elimina de tot acest neajuns). Pentru a ajunge la aceast

performan, trebuie s folosim normalizarea.Definiie: Normalizare: O tehnic de generare a unor relaii co proprietiile

dorite, n scopul memorrii corecte a datelor unei ntreprinderi.Procesul de normalizare prima dat a fost introdus de E. F. Codd (1972).

Iniial s-au propul trei forme normale, numerotate de al unu la trei. Mai trziu s-ainclus nc o form normal, numit Boyce-Codd, dup numele celor care l-auintrodus: R. Boyce i E. F. Codd.

Formele normale cele mai folosite sunt: forma normal 3 i forma normalBoyce-Codd. Exist i forme normale mai tari - forma normal 4 (4NF) i formanormal 5 (5NF) - dar aceste se folosesc foarte rar.

Procesul de normalizare este o metod formal de identificare a relaiilor bazatepe chei primare (sau chei candidat n cazul BCNF) i dependenele funcionale cuatributele asociate. Normalizarea d posibilitatea proiectantului bazei de date, pentrua efectua o seria de teste pe baza de date, toate aceste teste ducnd la prevenirea

posibilitii de a aprea anomalii la actualizarea bazei de date.Pentru a ilustra procesul de normalizare, vom folosii exemple din sistemul

informaticAsociacie de locatari.

Page: 19


20/79

2.2. Redundana n informaii i anomalii la actualizare

Partea cea mai important a proiectrii bazei de date este de a grupa atributelen relaii cu scopul de a minimiza redundana n informaii i spaiul ocupat de fiiere

pe suportul magnetic.Fie relaia Furnizori_Cheltuieli exemplificat mai jos. La exemple vomsimplifica atributele asociate entitiilor.

CodFurn.

Denumire Codfiscal

Nr.Crt.

CodChelt.

DenumireCheltuial

Valoare

F100 Romgaz R1234567 1 C15 Chelt pt. nclzire 1500000F100 Romgaz R1234567 2 C16 Chelt pt. buctrii 500000F110 Renel R7654321 3 C10 Chelt cu iluminatul 3000000F110 Renel R7654321 4 C11 Chelt pt. func. liftului 200000Figura 2.1 Relaia Furnizori_Cheltuieli

Dependenele funcionale pentru relaia Furnizori_Cheltuieli de mai sus sunturmtoarele:

Furnizori (Cod.Furn., Denumire, Cod fiscal)Cheltuieli (Nr.Crt., Cod chelt., Cod.furn., Valoare)Tip_cheltuiala (Cod.Chelt., Denumire chelt.)Furnizori_Cheltuieli (Nr.Crt., Cod chelt., Cod furn., Denumire chelt.,

Denumire, Cod fiscal, Valoare)

n acest exemplu, informaia despre furnizor devine redundant. Detraliiledespre furnizor se repet la fiecare introducere a unei cheltuieli noi. n dependenelefuncionale specificate pentru entitatea Cheltuieli, apare doar codul furnizorului.Analog, denumirea cheltuielii, apare i ea n plus fa de entitatea Cheltuieli.

O alt problem serioas datorat redundanei bazei de date, sunt problemelede actualizare a informaiei stocate. Aceste probleme se pot clasifica n anomalii deinserare, modificare, sau tergere.

2.2.1. Anomalii de inserare

Anomaliile de inserare se pot clasifica n dou tipuri mari: Pentru a adauga detaliile despre o cheltuial ctre un furnizor, n relaia

Furnizori_Cheltuieli trebuie obligatoriu adugate i detaliile despre furnizorul ncauz, chiar dac el exist deja n baza de date. Aceast anomalie poate duce laapariia aceluiai furnizor, avnd introduse detalii diferite n nregistrri diferite. Pentru a aduga detaliile unui furnizor nou n relaia Furnizori_Cheltuieli, trebuieneaprat adugat i o cheltuial pentru asociaia de locatari ctre acel furnizor. n

cazul n care nc nu a sosit factura de la furnizor, nu pot nregistra nici o cheltuial ideci trebuie introduse date vide n locul cheltuieli. CumNr.Crt. este cheia primar nrelaia Furnizori_Cheltuieli, introducerea de date vide n acest cmp va strica

Page: 20


21/79

integritatea entitii.

2.2.2. Anomalii de tergere

n cazul tergerii ultimei cheltuieli a asociaiei de locatari ctre un furnizor, seva terge i furnizorul. Deci toate detaliile introduse despre acel furnizor vor fi

pierdute, ceea ce duce la obligativitatea reintroducerii datelor la o nou folosire alacelui furnizor. n cazul entitii separate pentru cheltuieli i furnizori, dac se tergei ultima cheltuial ctre un furnizor, datele despre furnizor rmn totui n entitatea

Furnizori.

2.2.3. Anomalii de modificare

Dac n relaia Furnizori_Cheltuieli dorim s schimbm valoarea unui atribut alunui furnizor, va trebui s schimbm datele la fiecare apariie a acelui furnizor. Deexemplu dac dorim s schimbm codul fiscal al furnizorului cu codul F100, va trebuis achimbm acest atribut n dou locuri. Dac n timpul modificrilor, care poatedura destul de mult, intervine i un incident n uema cruia vor rmne nregistrrinemodificate, atunci baza de date devine inconsistent. Aceast anomalie se poateevita prin folosirea a dou entiti distincte precum Cheltuieli i Furnizori. n acest cazdac trebuie s modific un atribut al unui furnizor, va trebui s-o modific doar ntr-un

singur loc: n entitatea Furnizori.

2.3. Dependene funcionale

Unul din cele mai importante concepte asociate normalizrii este dependenafuncional. Dependena funcional descrie relaia dintre atribute. n acest capitolvom descrie conceptul de dependen funcional, urmnd ca n capitolele urmtoares descriem procesul de nlormalizare a bazei de date.

2.3.1. Definiia dependenei funcionale

Definiie: Dependen funcional: Descrie relaia dintre atribute. De exempludac atrubutul A este n relaia R cu atributul B, atunci atributul B este dependentfuncional de atributul A (notat: A B), dac orice valoarea al lui A este asociat prinrelaia R cu exact o valoare a atributul B.

Dependena funcional este o proprietate a semanticii atributelor n relaii.Semantica indic atributele care sunt n relaie i specific dependenele funcionale

dintre atribute.Considerm o relaie ntre dou atribute A i B, unde atributul B este dependentfuncional de atributul A (atributele A i B pot fi compuse din mai multe atribute). Cu

Page: 21


22/79

alte cuvinte, dac tim valorile cmpului A, atunci analiznd valorile lui B n relaia cuA, vom considera c pentru valori diferite al lui A - care fiind cheie, trebuie s aibvalori diferite - avem valori diferite i pentru cmpul B. Dependena funcional dintredou cmpuri se reprezint grafic n urmtorul mod:

Figura 2.2 Diagrama dependenei funcionale

Definiie: Determinant: Numim determinantul unei relaii funcionale,atributul, sau mulimea atributelor din partea stng a sgeii.

n acest capitol vom ignora dependenele funcionale triviale, adic acele relaiide tipul AB, n care B este dependent de un subset de atribute al lui A. Pentru a

exemplifica dependenele funcionale, considerm urmtorul exemplu:Exemplu: Considerm atributele Cod furnizor i Denumire. Pentru un anumit

cod de furnizor, putem determina denumire acelui furnizor. Adic denumirea estedependent funcional de cod furnizor. Dependena invers nu este adevrat pentru c

pot exista aceleai denumiri cu coduri diferite.Relaia dintre cod furnizor i denumire este de 1:1, iar relaia invers este de

1:M.

S identificm dependenele funcionale din relaia Furnizori_Cheltuieli

descris mai sus:Nr. Crt., Cod Furn., Cod Chelt. DenumireNr. Crt., Cod Furn., Cod Chelt. Cod fiscalNr. Crt., Cod Furn., Cod Chelt. Denumire cheltuialNr. Crt., Cod Furn., Cod Chelt. ValoareCod Furnizor DenumireCod Furnizor Cod fiscalCod fiscal DenumireCod fiscal Cod FurnizorCod Chelt. Denumire cheltuial

n aceast relaie avem 9 dependene funcionale, care au determinantele(Nr. Crt., Cod Furn., Cod Chelt.), Cod fiscal, Cod Furn. i Cod Chelt. Putemevidenia aceste dependene i ntr-un alt format:

Nr.Crt., Cod Furn., Cod Chelt.Denumire,Cod fiscal, Denumire cheltuial, ValoareCod Furn. Denumire, Cod fiscalCod fiscal Denumire, Cod Furn.Cod Chelt. Denumire cheltuial

Page: 22

A B


23/79

Pentru a identifica cheile candidate, trebuie s identificm atributul, sau grupulde atribute care determin unic fiecare nregistrare al acestei relaii. Dac avem maimult de o cheie candidat, atunci va trebui s identificm i o cheie primar. Toateatributele care nu aparin cheii primare, depind funcional de cheia primar. n aceastipostaz este grupul de atribute (Nr. Crt., Cod Furn., Cod Chelt.). Atributele CodFurn., Cod fiscal i Cod Chelt. Sunt determinani, dar nu sunt chei candidat.

Conceptul de dependen funional este conceptul central al normalizrii, ceeace vom descrie n capitolele urmtoare.

2.4. Procesul de normalizare

Normalizarea este un proces formal de analiz a relaiilor bazate pe chei

primare (sau pe baza cheilor candidat n cazul BCNF). Normalizarea presupuneurmarea unor reguli prin care baza de date se poate normaliza pn la un anumit grad.Dac o cerin nu este satisfcut, relaia trebuie dezcompus n mai multe relaii, careindividual satisfac cerinele formei normale.

Normalizarea se execut trecnd prin toate formele nornale, pn la formanormal cerut. La proiectarea unei baze de date trebuie s ajungem cel puin la formanormal unu, dar ca s evitm toate anomaliile descrise mai nainte, este recomandataducerea bazei de date la BCNF.

n figura urmtoare evideniem relaia dintre diversele forme normale.Observm c unele din relaiile n 1NF este i n 2NF, dintre care unele n 3NF i aa

mai departe.

Figura 2.3. Ilustrarea grafic a relaiei dintre formele normale.

2.5. Forma Normal Unu (1NF)

nainte s discutm despre forma normal unu, vom da definiia stadiuluidinainte de aceast form normal.

Definiie: Form Nenormalizat (UNF): O tabel care conine una sau mai

multe grupuri repetitive.Definiie: Forma Normal Unu (1NF): Relaie n care la intersecia oricreilinii cu oricare coloan gsim un cmp care conine exact o valoare.

Page: 23

1NF

2NF3NF

BCNF4NF5NF

NF


24/79

n acest capitol ncepem procesul de normalizare. Pentru nceput transfermdatele de la surs ntr-o tabel, care va fi o tabel nenormalizat. Pentru a transformaaceast tabel n forma normal unu, identificm i tergem grupurile repetitive dintabel. Grupurile repetitive sunt atribute, sau grup de atribute, pentru care avemdiferite valori pentru aceeasi valoare a cheii, ceea ce este n contradicie cu definiiacheii. Eliminarea acestor grupuri repetitive se poate realiza n dou moduri:

Conform primei modaliti, eliminm grupurile repetitive, prin crearea altornregistrri, n care s fie introduse valorile din aceste grupuri, mpreun cu celelaltevalori ai atributelor din nregistrarea la care se lucreaz. Tabele astefel rezultat va fin form normal unu.

n a doua modalitate, fiecere valoare a grupurilor repetitive le copiem ntr-onou relaie mpreun cu cheia primar din tabela iniial. Putem avea mai multe

grupuri repetitive. n acest caz crem mai multe relaii noi. Aceste relaii noi, precumi tabela normalizat vor fi n form normal unu.

De exemplu s lum relaia Furnizori_Cheltuieli:

CodFurn.

Denumire Codfiscal

Nr.Crt.

CodChelt.

DenumireCheltuial

Valoare

F100 Romgaz R1234567 1 C15 Chelt pt. nclzire 15000002 C16 Chelt pt. Buctrii 500000

F110 Renel R7654321 3 C10 Chelt cu iluminatul 30000004 C11 Chelt pt. Func. liftului 200000Figura 2.4. Tabela nenormalizat Furnizori_Cheltuieli.

n aceast tabel observm c pentru furnizorul Romgaz avem dou tipuri decheltuieli. Pentru a transforma aceast tabel n 1NF, trebuie s avem o singurvaloare la fiecare intersecie linie coloan.

n cazul primei modaliti, scriem repetiiile pe diferite rnduri iar coloanelecare nu conin repetiii, vor fii copiate pe fiecare rnd. Dup desprirea repetiiilor pemai multe rnduri, identificm o nou cheie.

CodFurn.

Denumire Codfiscal

Nr.Crt.

CodChelt.

DenumireCheltuial

Valoare

F100 Romgaz R1234567 1 C15 Chelt pt. nclzire 1500000F100 Romgaz R1234567 2 C16 Chelt pt. Buctrii 500000F110 Renel R7654321 3 C10 Chelt cu iluminatul 3000000F110 Renel R7654321 4 C11 Chelt pt. Func. liftului 200000Figura 2.5. Tabela Furnizori_Cheltuieli n 1NF,

creat prin prima modaliate de transformare.

n tabela normalizat, noua cheie va fii (Cod Furn., Nr. Crt., Cod Chelt.).

Page: 24


25/79

Normaliznd tabela iniial dup a doua modalitate, vom crea o a doua tabelcu informaiile care nu se repet, mpreun cu cheia primar din tabela iniial. Decicele dou tabele vor fi urmtoarele:

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

Cele dou tabele astfel create sunt n 1NF:

CodFurn.

Nr.Crt.

CodChelt.

DenumireCheltuial

Valoare

F100 1 C15 Chelt pt. nclzire 1500000F100 2 C16 Chelt pt. Buctrii 500000

F110 3 C10 Chelt cu iluminatul 3000000F110 4 C11 Chelt pt. func. Liftului 200000

CodFurn.

Denumire Codfiscal

F100 Romgaz R1234567F100 Romgaz R1234567F110 Renel R7654321F110 Renel R7654321

Figura 2.6. Relaia Cheltuial i Furnizor, create prinmetoda a doua de normalizare.

Pentru a demonstra trecerea la forma normal doi i mai mari, vom folosiirelaia Furnizori_Cheltuieli, evideniat n figura 2.5.

2.6. Forma Normal Doi (2NF)

Forma normal doi se bazeaz pe conceptul de dependen funcional total,ceea ce vom descrie n continuare.

2.6.1. Dependena funcional total

Definiie: Dependena funcional total: Dac A i B sunt atributele uneirelaii, atunci B este total dependent funcional de atributul A, dac B este dependentfuncional de A, dar nu este dependent funcional de nici un subset al lui A.

De exemplu s lum urmtoarea dependen funcional:

Page: 25


26/79

Nr. Crt., Cod Chelt. Denumire cheltuial

Dependena funcional este corect, pentru c fiecare valoare al lui

(Nr. Crt., Cod Chelt.) determin unic denumirea cheltuielii, ns dependena nu estetotal, pentru c Denumire cheltuial depinde funcional i de un subset al lui(Nr. Crt., Cod Chelt.) i anume atributul Cod Chelt.

2.6.2. Definiia Formei Normale Doi

Forma normal doi trebuie verificat doar la relaiile care au cheie compus pepoziie de cheie primar. Relaiile la care cheia primar se compune dintr-un singulatribut, este n 2NF. Relaiile care nu sunt n forma normal doi, pot suferii deanomaliile prezentate in capitolul 2.2. De exemplu dac n cazul relaiei

Furnizori_Cheltuieli vream s actualizm datele despre furnizorul F100, trebuie sactualizm dou nregistrri.

Definiie: Forma Normal Doi (2NF): O relaie este n forma normal doi,dac este n forma normal unu i fiecare atribut care nu aparine cheii primare, estetotal dependent funcional de cheia primar.

Vom demonstra aducerea la forma normal doi, folosind relaiaFurnizori_Cheltuieli evideniat n figura 2.5. Putem trece la forma normal doi printergerea atributelor care nu depind total de cheia primar i trecrea lor ntr-o alttabel mpreun cu determinantul lor. Dup efectuarea acestor transformri, vom aveaurmtoarela relaii:

Relatia Cheltuieli

CodFurn.

Nr.Crt.

CodChelt.

Valoare

F100 1 C15 1500000F100 2 C16 500000F110 3 C10 3000000F110 4 C11 200000

Relaia FurnizoriCod

Furn.

Denumire Cod

fiscalF100 Romgaz R1234567F100 Romgaz R1234567

Page: 26

Relaia Tip CheltuialCod

Chelt.

Denumire

CheltuialC15 Chelt pt. nclzireC16 Chelt pt. buctriiC10 Chelt cu iluminatulC11 Chelt pt. func. liftului


27/79

F110 Renel R7654321F110 Renel R7654321

Figura 2.7. Relaiile rezultate dup trecerea la 2NFa relaiei Furnizori_Cheltuieli.

Relaiile rezultate au urmtoarea form:Furnizori (Cod Furn., Denumire, Cod fiscal)Tip cheltuial (Cod Chelt., Denumire cheltuial)Cheltuieli (Nr. Crt., Cod Furn., Cod Chelt., Valoare)

2.7. Forma Normal Trei (3NF)

Forma normal doi chiar dac nu conine atta redundan ca forma normalunu, totui exist cazuri n care pot aprea anomalii la actualizare. Aceste anomaliiapar din cauza redundanei generate de dependena tranzitiv.

2.7.1. Dependena tranzitiv

Definiie: Dependen tranzitiv: Dac atributele A, B, C sunt n relaiileAB i BC, atunci spunem c atributul C este dependent tranzitiv de atributul A,via B.

2.7.2. Definiia Formei Normale Trei

Definiie: Forma Normal Trei (3NF): O relaie care este n form normaldoi i nu exist nici un atribut care s nu aparin cheii principale i care s fietranzitiv dependent de cheia principal.

n cazul existenei dependenei tranzitive, tergem coloanele care sunt tranzitivdependente de cheia primar i crem o relaie nou cu aceste coloane, mpreun cudeterminantul lor, adic cheia primar.

Examinnd relaiile n forma normal de mai sus, observm c nu existdependene tranzitive. Deci relaiile sunt n form normal trei.

2.8. Forma Normal Boyce-Codd (BCNF)

Baza de date trebuie broiectat astfel nct s nu conin dependene parialesau tranzitive, pentru c altfel ne putem confrunta cu anomaliile descrise n cap. 2.2.

2.8.1. Definiia Formei Normale Boyce-Codd

Forma normal Boyce-Codd este bazat pe cheile candidat din relaie. O relaiecu o singur cheie candidat n form normal trei este i n form normal Boyce-

Page: 27


28/79

Codd.Definiie: Forma normal Boyce-Codd (BCNF): O relaie este n forma

normal Boyce-Codd dac i numai dac orice determinant din relaie este cheiecandidat.

S cutm determinanii din exemplul de mai sus:

Cod Furn. Denumire, Cod fiscalCod Chelt. Denumire cheltuial

Nr. Crt., Cod Furn., Cod Chelt. Valoare

Toi cei trei determinani sunt i chei candidat. Deci exemplul de mai sus este nform normal Boyce-Codd. Relaiile n form normal trei sunt n general i n formnormal Boyce-Codd. n cazul n care relaia nu este n form normal Boyce-Codd,trecerea la BCNF se realizeaz prin tergerea din relaia iniial a atributelor care suntasociate unui determinant care nu este cheie candidat i crearea unei noi relaii cuaceste atribute i determinantul lor.

Exist situaii cnd este foarte greu de descompus atributele, ca s ajungem laBCNF. n aceste situaii este indicat rmnerea la forma normal trei.

2.9. S recapitulm procesul de normalizare (de la 1NF la BCNF)

Forma Normal Unu (1NF)Trebuie s cutm toate interseciile de linii i coloane, unde exist repetiii.

Aceste repetiii se pot elimina prin dou madaliti: Crearea a noi nregistrri pentru fiecare valoare a repetiiei, dup care se caut onou cheie primar.

tergerea atributelor care conin repetiii i crearea a unor noi relaii care vorconine atributele terse, precum i cheia principal din relaia iniial.

Forma Normal Doi (2NF)Se caut dependenele pariale de cheia principal, adic toate atributele care

depind funcional de un subset de atribute a cheii primare. Dac cheia primar estecompus dintr-un singur atribut, atunci releia este n forma normal doi. Dac existdependene pariale, vom terge atributele care depind parial de cheia principal icrem o relaie nou care s se compun din atributele terse mpreun cudeterminantul lor.

Forma Normal Trei (3NF)Pentru a trece la forma normal trei, trebuie s eliminm dependenele

Page: 28


29/79

tranzitive. Eliminarea se realizeaz prin tergerea cmpurilor dependente tranzitiv decheia primar din relaia iniial i crearea unei noi relaii cu aceste atribute ideterminantul lor.

Forma Normal Boyce-Codd (BCNF)Cerina la forma normal Boyce-Codd este ca fiecare determinant din relaie s

fie cheie candidat. n cazul n care nu este ndeplinit aceast cerin, vom tergeatributele dependente funcional de determinantul care nu este cheie candidat i cremo nou relaie n care s avem atributele terse i determinantul lor. n unele cazuritrecerea la forma normal Boyce-Codd complic foarte mult baza de date, caz n careeste de preferat rmnerea la forma normal trei.

Page: 29

Form nenormalizat (UNF)

tergem grupurilecare se repet

Forma normal unu (1NF)

tergemdependenele pariale

Forma normal doi (2NF)

tergem dependeneletranzitive

Forma normal trei (3NF)


30/79

3. Metodologie - Proiectarea bazei de date

n acest capitol vom nva despre: Scopul metodologiei de proiectarea a bazelor de date. Proiectarea bazelor de date are dou faze mari: proiectarea logic i proiectarea

fizic. Utilizatorii sistemului informatic au un rol important n proiectarea bazelor de date. Cum documentm procesul de proiectare a bazelor de date? Cum descompunem scopul proiectrii n vederi (view-uri) specifice utilizatorilor

nrtreprinderii? Cum utilizm modelarea Entity-Relationship (ER), pentru a crea un model

conceptual local, bazat pe informaiile adunate despre view-urile utilizatorilor? Cum proiectm un model local conceptual ntr-un model local logic de date? Cum crem relaiile pentru un model conceptual local? Cum validm modelul logic de date, utiliznd technica normalizrii? Cum compunem modelele logice locale de date, bazate pe view-urile specifice

utilizatorilor, ntr-un model logic global de date al ntreprinderii? Cum ne asigurm c modelul global este o reprezentare adevrat i total a prii

ntreprinderii pe care vrem s o modelm?

Metodologia proiectrii bazei de date se compune din dou etape mari:proiectarea logic, n care proiectantul decide asupra structurii logice a bazei de date,i proiectarea fizic, n care proiectantul decide cum se va implementa structura logicn sistemul de gestiune a bazelor de date (SGBD).

n acest capitol vom prezenta pas cu pas, crearea unei baze de date. Vomutiliza modelarea ER descris n capitolul 1, pentru proiectarea bazei de date; vomvalida acest model prin normalizare, prezentat n capitolul 2; iar n final vom compunediferitele view-uri ntr-un model global al ntreprinderii.

n acest capitol vom utiliza covintele entitate i relaie n locul expresiilor

tip de entitate i tip de relaie. Unde aceast utilizare ar putea crea confuzii, vomspecifica tip de entitate, respectiv tip de relaie.

3.1. Metodologia proiectrii bazelor de date

3.1.1. Ce este o metodologie de proiectare?

Definiie: Metodologie de proiectare: O aproximare structurat, careutilizeaz proceduri, tehnici, instrumente i documentaii pentru a facilita procesul de

proiectare.

Metodologia de proiectare se compune din etape, care la rndul lor se compundin pai, care orienteaz proiectantul la fiecare nivel al crerii bazei de date.

Page: 30


31/79

3.1.2. Proiectarea logic i fizic a bazei de date

Definiie: Proiectare logic: Procesul de construcie a unui model de informaii

folosite ntr-o ntreprindere, bazat pe modelul de date, dar independent departicularizrile sistemului de gestiune a bazei de date i a altor considerente fizice.Proiectarea logic ncepe cu crearea modelului conceptual al bazei de date, care

este independent de implementarea ntr-un SGBD. Modelul conceptual este apoiproiectat pe un model logic, care va influena mai trziu modelul de date n care se vaimplementa.

Definiie: Proiectare fizic: Este procesul de descriere a implementrii bazeide date ntr-un SGBD.

n aceast etap a proiectrii este creat baza de adte ntr-un SGBD, mpreuncu procedurile de actualizare. n aceast etap exist un feedback ntre proiectarea

fizic i cea logic, pentru c deciziile luate la implementarea fizic pot afecta baza dedate logice.

3.2. Prezentarea metodologiei

n acest capitol vom prezenta o descriere a metodologiei de proiectare abazelor de date. Prima dat s vedem care sunt paii de urmat n proiectare:

Pasul 1. Proiectarea logic a bazei de date relaionale:

Crearea unui model conceptual local, pentru vederile utilizatorilor.Pasul 1.1. Identificarea tipurilor de entiti.Pasul 1.2. Identificarea tipurilor de relaii.Pasul 1.3. Identificarea i atribuirea de atribute la tipurile de entiti i tipurile

de relaii.Pasul 1.4.Determinarea domeniilor de definiie a atributelor.Pasul 1.5.Determinarea atributelor care compun cheile candidate i primare.Pasul 1.6.Specializare/generalizare (pas opional).Pasul 1.7.Desenarea diagramei entity-relationship.Pasul 1.8.Verificarea modelului conceptual local cu ajutorul utilizatorului.

Pasul 2. Crearea i validarea modelului logic local.Pasul 2.1.Proiectarea modelului conceptual local pe un model logic local.Pasul 2.2.Crearea relaiilor pentru modelul logic local.Pasul 2.3.Validarea modelului, utiliznd normalizarea.Pasul 2.4. Validarea modelului din nou, utiliznd tranzaciile.Pasul 2.5.Desenarea diagramei ER.Pasul 2.6.Definirea regulilor de integritate a bazei de date.Pasul 2.7.Verificarea modelului logic local cu ajutorul utilizatorului.

Pasul 3. Crearea i validarea modelului logic global de date.Pasul 3.1.Compunerea medelelor logice locale ntr-un model logic global.Pasul 3.2.Validarea modelului logic global.Pasul 3.3.Verificarea posibilitii de a completa baza de date n viitor.

Page: 31


32/79

Pasul 3.4.Desenarea diagramei ER finale.Pasul 3.5.Verificarea modelului logic global cu ajutorul utilizatorului.

Pasul 4. Proiectarea fizic i implementarea bazei de date relaionale:Translatarea modelului logic global n SGBD.Pasul 4.1. Proiectarea relaiilor de baz n SGBD.Pasul 4.2.Crearea regulilor de integritate n SGBD.

Pasul 5. Proiectarea i implementarea reprezentrii fizice.Pasul 5.1.Analizarea tranzaciilor.Pasul 5.2.Alegerea organozrii fiierelor.Pasul 5.3.Alegerea indexilor secundari.Pasul 5.4.Introducerea unei redundane comntrolate.Pasul 5.5.Estimarea spaiului pe disc.

Pasul 6. Proiectarea i implementarea unui mechanism de securitate.

Pasul 6.1.Crearea view-urilor pentru utilizatori.Pasul 6.2. Proiectarea regulilor de acces la baza de date.Pasul 7. Verificarea sistemului operaional.

Proiectarea logic a bazei de date se divide n trei pai mari. Primul pas are caobiectiv, descompunerea proiectrii sistemului informatic n vederi, care se potdiscuta cu utilizatorii sistemului. Modelul de date astfel creat, se valideaz prinnormalizare i prin tranzacii n pasul doi. n final, se genereaz modelul global alntreprinderii, cars este la rndul lui validat i verificat cu ajutorul utilizatoruluisistemului.

Factori critici pentru succesul proiectrii logice:

Lucrul interactiv cu utilizatorul sistemului. Folosirea unei metodologii structurate pentru procesul de proiectare a bazei de

date. ncorporarea regulilor de integritate n modelul logic de date. Combinarea validrii conceptuale, prin normalizare i prin tranzactii, la proiectarea

modelului logic de baze de date.

Utilizarea diagramelor pentru a reprezenta ct mai multe modele logice posibile. Crearea dicionarului de date, ca supliment al modelului de date.

3.3. Metodologia de proiectare a bazei de date logice

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

Pasul 1. Crearea modelului conceptual local, pentru utilizatori.

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

Page: 32


33/79

utilizatorilior.Primul pas n proiectarea bazei de date este de a colecta datele necesare pentru

realizarea sistemului, ceea ce putem culege, discutnd cu viitorii tilizatori ai bazei dedate. Acrast discuie presupune o desprire n vederi, a bazei de date, vederi care

pot luca separat.Desprirea n vederi se poate realiza n mai multe moduri. O modaliate ar fi

analiza datelor globale i gsirea de pri relativ independente. O alt modalitate ar fiianaliza rapoartelor, procedurilor cerute i/sau observarea sistemului ixistent n lucru.

Modelele conceptuale locale trebuie s conin: tipuri de entiti, tipuri de relaii, atribute,

domeniile atributelor, cheile candidat, chei primare

Paii din prima etap a proiectrii logice sunt: Pasul 1.1. Identificarea tipurilor de entiti. Pasul 1.2. Identificarea tipurilor de relaii. Pasul 1.3. Identificarea i atribuirea de atribute la tipurile de entiti i

tipurile de relaii.

Pasul 1.4. Determinarea domeniilor de definiie a atributelor. Pasul 1.5. Determinarea atributelor care compun cheile candidate i

primare. Pasul 1.6. Specializare/generalizare (pas opional). Pasul 1.7. Desenarea diagramei entity-relationship. Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.

Pasul 1.1. Identificarea tipurilor de entiti

Obiectivul: Identificarea tipurilor de entiti principale n vederileutilizatorilor.Primul pas n proiectarea bazei de date este identificarea entitiilor din datele

furnizate de utilizatori. De exemplu, dac avem informaiile Nr_Mat, Nr_Bloc, Scara,Etaj, Apartament i Nume, putem identifica entitatea Locatari. n general putemidentifica entitiile n mai multe moduri. De exemplu n locul entitii Locatari, am

putea crea o entitate Locatari cu atributele Nr_Mat i Nume, iar celelelte informaii nentitatea ProprietateLocatari.

Exist cazuri cnd entitiile sunt greu de identificat, pentru c modul deprezentare a viitorilor utilizatori necesit explicaii. Utilizatorii descriu aceste entiti,folosind sinonime i omonime, ceea ce ngreuneaz identificarea entitilor.Sinonimele prin care se descrie aceai entitate, se pot considera sinonime i la crearea

Page: 33


34/79

modelului logic, evideniind aceste sinonime ca diverse aliasuri ai entitiilor.Documentarea tipurilor de entitiDup identificarea entitiilor, le dm cte un nume, iar aceste nume le vom

evidenia n dicionarul de date, mpreun cu explicaiile despre entiti, precum iposibilele aliasuri.

Pasul 1.2. Identificarea tipurilor de relaii

Obiectivul: Identificarea relaiilor importante dintre entiti.Dup identificarea entitiilor, va trebui s identificm i relaiile importante

dintre aceste entiti. Releiile se descriu printr-un verb al relaiei. De exemplu: Scrilesunt Locuite de Locatari FurnizoriiProvoac Cheltuieli

La identificarea relaiilor vom lua n considerare doar relaiile care neintereseaz. Degeaba exist i alte relaii care s se poat identificate, dac nu

prezint importan pentru problema noastr, atunci nu le lum n consideraie.n cele mai multe din cazuri, relaiile sunt binare, adic se realizeaz ntrea

exact dou entiti. Exist i relaii mai complexe, care se realizeaz ntre mai multeentiti, sau relaii recursive, care pune n relaie o singur entitate cu ea nsi.

Determinarea cardinalitii i a participrii la tipurile de relaiiDup identificarea tipurilor de relaii, trebuie s determinm cardinalitatea lor,

alegnd dintre posibilitiile: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-

la-multe (M:N). Dac se cunosc valori specifice ale cardinalitiilor, aceste valori sescriu la documentarea relaiilor. n continuare determinm i participarea la relaie,care poate fii total, sau parial.

Documentarea tipurilor de relaiiDup identificarea tipurilor de relaii, le denumim i le introducem n

dicionarul de date, mpreun cu cardinalitatea i participarea lor.Utilizarea modelrii ERPentru vizualizarea sistemelor complicate, utilizm diagrama ER, pentru c este

mult mai uor de a cuprinde toate informaiile. V propunem ca s utilizaintotdeauna diagrama ER, pentru o mai bun vizualizare a datelor.

Pasul 1.3. Identificarea i asocierea de atribute la tipurile de entiti itipurile de relaii

Obiectivul: Asocierea de atribute la tipurile de entiti i la tipurile de relaii.Urmtorul pas n metodologie este identificarea atributelor. Aceste atribute se

identific n aceeai mod ca i entitiile. Pentru o mai uoar identificare, trebuie slum entitiile i relaiile ra rnd i s ne punem urmtoarea ntrebare: Ce informaiideinem despre aceast ? Rspunsul la aceast ntrebare ne va da atributele

cutate.Atribute simple sau compuseEste important s notm dac un atribut este simplu sau compus. Conform

Page: 34


35/79

acestei informaii va trebui s lum decizii referitoare la acel atribut. Dac un atributeste compus, atunci putem opta pentru descompunerea sa, dac este necesar

prelucrarea separat a detelor compuse, sau putem s-l lsm compus n caz contrar.De exemplu, atributul Adres conine informaiile (Nr_Bloc, Scara, Etaj,

Apartament). Noi va trebui s prelucrm aceste informaii separat, deci vomdescompune acest atribut n cele patru atribute simple.

Putem avea cazuri n care atributele simple s le compunem. De exemplu ncazul atributelor Nume_Familie i Prenume, neavnd nevoie de aceste informaiiseparat, le vom compune n atributul Nume.

Atribute derivate (calculate)Sunt acele atribute, care se pot calcula din alte atribute existente n baza de

date. De exemplu numrul locatarilor de pe o scar se poate numra n tipul deentitate Locatari. Deci acest atribut este atribut derivat.

n general aceste atribute nu trebuie incluse n modelul de date, pentru c ncazul n care se modific atributul din care se calculeaz atributul derivat, trebuie sse modifice i acesta. n cazul n care nu se modific, baza de date devineinconsistent. De aceea este important de a meniona dac un atribut este sau nuderivat.

Dac identificm un atribut care s nu-l putem asocia nici unei entiti saurelaii, ne ntoarcem la paii anteriori, identificnd noua relaie sau entitate la care sasociem atributul respectiv.

n cazul n care putem asocia acelai atribut la mai multe entiti, atunci vatrebui s decidem dac generalizm sau nu aceste entiti, proces care este descris la

pasul 1.6.Documentarea atributelorDup identificarea atributelor, le asociem un nume, i le nregistrm n

dicionarul de date, mpreun cu urmtoarele informaii: numele i descrierea atributului, toate aliasurile i sinonimele prin care este cunorcut atributul, tipul de date i lungimea, valorile iniiale ale atributelor (dac exist),

dac atributul accept sau nu valoarea nul, dac atributul este sau nu compus, i dac este atunci atributele simple care lecompun,

dac atributul este sau nu derivat i atributul din care se deriv, dac atributul accept sau nu mai multe valori.

Pasul 1.4. Determinarea domeniului atributelorObiectivul: Determinarea domeniului atributelor n modelul conceptual local.Domeniul atributului este o mulime de valori pe care o poate lua. Pentru a

controla n totalitate domeniul atributelor, se poate evidenia urmtoarele: setul de valori admisibile pentru un atribut, operaiile admisibile asupra unui atribut,

Page: 35


36/79

ce atribute se pot compara cu atributul respectiv, n combinaiile cu alte atribute, mrimea i formatul cmpului atributului.

Documentarea domeniilor atributelor

Actualizm dicionarul de date cu domeniul de definiie a fiecrui atribut.

Pasul 1.5. Determinarea atributelor care compun cheile candidat i primare

Obiectivul: Identificarea cheilor candidat pentru fiecare entitate i alegereacheilor primare n cazul n care sunt mai multe chei candidat.

Identificarea cheilor i selectarea cheilor primareO 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 cheicandidat. n acest caz trebuie s alegem dintre ele o cheie primar. Cheile candidatcare nu sunt primare, se vor numii chei alternante. Pentru alegerea unei chei ca fiindcheie primar, vom ine cont de urmtoarele: cheia candidat, care are un numr minimal de atribute, cheia candidat, care i va schimba cel mai rar valoarea, cheia candidat, care este cel mai puin probabil s sufere modificri n viitor, cheia candidat, care este compus din cele mai puine caractere (n cazul atributelor

de tip caracter), cheia candidat, care este cel mai uor de folosit din punctul de vedere al

utilizatorului.Prin procesul de identificare a cheilor primare, deducem i dac o entitate este

entitate tare, sau entitate slab. Dac reuim s identificm o cheie primar,atunci entitatea este tare, altfel este slab. O entitate slab nu poate exista fr oentitate tare, care s-i fie printe. Cheia primar a entitii slabe este derivat parialsau total din cheia primar a entitii tari.

Documentarea cheilor primare i alternantenscriem cheile primare i pe cele alternante n dicionarul de date.

Pasul 1.6. Specializarea/generalizarea tipuriloe de entiti (pas opional)

Obiectivul: Identificarea entitiilor subclas respectiv superclas, ntreentitiile apropiate.

n acest pas putem opta pentru a continua modelarea ER, folosind procesul degeneralizare sau specializare. Dac alegem procesul de specializare, vom ncerca sdefinim unul, sau mai multe subclase ai entitii respective. Dac ns alegem

procesul de generalizare, vom cuta superclase pentru acea entitate.Un exemplu pentru procesul de generalizare ar fii entitiile ef_de_scar i

Familii. Ambele entiti au atribuite urmtoarele atribute: Nr_mat, Nr_bloc, Scara,Etaj, Apartament i Nume. Pe lng aceste atribute, entitatea ef_de_scar mai areasociate atributul Data_intrare_func; iar entitatea Familii, atributele Nr_pers,

Page: 36


37/79

Nr_pers_prezente i Nr_chei. Deci, cele dou entiti avnd atribute n comun, leputem generaliza n entitatea Locatari, care va conine atrubutele comune, i entitileef_de_scar i Familii, coninnd doar atributele diferite - particularizrile fa desuperclas.

Pasul 1.7. Desenarea diagramei ER.

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

n momentul acesta suntem n msur s prezentm o giagram complet amodelului bazat pe vederile utilizatorilor despre ntreprindere.

Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului

Obiectivul: Verificarea modelului conceptual local cu ajutorul utilizatorului,pentru a vedea dac modelul este o reprezentare adevrat a vederii utilizatoruluidespre ntreprindere.

nainte de a termina pasul 1, trebuie verificat modelul conceptual elaborat.Acest model include diagrama ER i documentaia anexat. n cazul n care apareorice fel de anomalie, repetm procesul de mai nainte i remediem problema.

Pasul 2. Crearea i validarea modelului logic local

Obiectivul: Crearea unui model logic local bazat pe modelul conceptual alutilizatorilor asupra ntreprinderii i validarea ei prin procesul de normalizare i printehnica tranzaciilor cerute.

n acest pas verificm modelul conceptual creat n pasul anterior i eliminmdin el structurile care sunt dificil de realizat ntr-un SGBD. Dac la sfritul acestui

proces modelul alterat, vom corecta aceste probleme i ne vom referii n continuarela modelul rezultat, ca fiind modelul logic local. Vom valida modelul logic prin

procesul de normalizare i a tranzaciilor.Activitile din acest pas sunt:

Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local. Pasul 2.2. Crearea relaiilor pentru modelul logic local. Pasul 2.3. Validarea modelului, utiliznd normalizarea. Pasul 2.4. Validarea modelului din nou, utiliznd tranzaciile. Pasul 2.5. Desenarea diagramei ER. Pasul 2.6. Definirea regulilor de integritate a bazei de date. Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.

Pasul 2.1. Proiectarea modelului conceptual local pe modelul logic local

Obiectivul: Verificarea modelului conceptual local pentru eliminarea

Page: 37


38/79

structurilor care se pot implementa greu ntr-un SGBD i proiectarea modeluluirezultat la modelul logic local.

n pasul nti am pregtit un model conceptual bazat pe informaiile date deutilizator. Acest model trebuie prelucrat, pentru a putea fi uor de prelucrat desistemul de gestiune a bazelor de date. Obiectivele acestui pas sunt:(1) Eliminarea relaiilor M:N.(2) Eliminarea relaiilor complexe.(3) Eliminarea relaiilor recursive.(4) Eliminarea relaiilor cu atribute.(5) Reexaminarea relaiilor 1:1.(6) Eliminarea relaiilor redundante.

(1) Eliminarea relaiilor multe-la-multeDac n modelul de date apar relaii de tipul multe-la-multe (M:N), trebuie

descompuse n dou relaii unu-la-multe (1:M) prin adugarea unei noi entitisuplimentare.De exemplu, pot exista mai multe cheltuieli pentru o scar, dar i o cheltuial

(factur) poate s se refere la mai multe scri. Deci relaia dintre entitatea Scri ientitatea Cheltuieli este de M:N, ceea de este evideniat n figura 3.1.(a).

Sunt platite de

Scari

Nr_BlocScara

Lift

Cheltuieli

Nr_Crt

Cod_Cheltuiala (FK)Cod_Furnizor (FK)Nr_facturaData_facturaValoare_factura

Se calculeazaAu cheltuieli

Pe scari

Scara (FK)

Nr_Crt (FK)Nr_Bloc (FK)

Cheltuieli

Nr_Crt

Cod_Furnizor (FK)Cod_cheltuialaNr_facturaData_facturaValoare_factura

Scari

Nr_BlocScara

Lift

Figura 3.1. (a). Relaie de tipul N:M. (b). Relaie transfornamt n dou relaii 1:M.

Aceast relaie se poate elimina, prin crearea unui tip de entitate suplimantar,care s fac legtura dintre scri i cheltuieli. Diagrama acestor relaii se vede n

figura 3.1.(b).Notm, c tipul de entitate nou creat - Pe_scri - este tip de entitate slab,pentru c depinde att de tipul de entitate Scri, ct i de tipul de entitate Cheltuieli.

(2) Eliminarea relaiilor complexeO relaie complex este o relaie ntre mai mult de cou tipuri de entiti. Dac

n modelul conceptual apar relaii complexe, acestea trebuie eliminate. Se pot eliminaprin crearea unui nou tip de entitate, care s fie n relaie de tipul 1:M cu fiecare tip deentitate din relatia iniial, partea cu M a relaiei fiind spre tipul de entitate nou creat.

(3) Eliminarea relaiilor recursiveRelaiile recursive sunt nite relaii particulare, prin care un tip de entitate este

n relaie cu el nsi. Dac apare o astfel de relaie n modelul conceptual, ea trebuieeliminat. Eliminarea se poate rezolva prin crearea unei noi entiti unde s se

Page: 38


39/79

evidenieze fiecare entitate care este legat de entitatea din tipul de entitate iniial. nacest caz vom avea o relaie de tipul 1:M ntre tipul de entitate iniial i tipul deentitate nou creat i o relaie de tipul 1:1 ntre tipul de entitate nou creat i tipul deentitate iniial.

(4) Eliminarea relaiilor cu atributeDac n modelul conceptual avem relaii cu atribute, putem descompune

aceast relaie, identificnd un nou tip de entitate n care s nregistrm atributelenecesare.

(5) Reexaminarea relaiilor de tipul 1:1n modelul conceptual putem avea entiti ntre care s avem relaie de

tipul 1:1. Se poate ntmpla ca aceste entiti s fie de fapt aceeai entitate cu numediferite. Dac suntem n acest caz, unim cele dou entiti, cheia primar devenindcheia primar al uneia dintre entiti.

(6) Eliminarea relaiilor redundanteO relaie este redundant dac se poate ajunge de la un tip de entitate la alt tip

de entitate pe mai multe drumuri. V amintim c noi vrem s ajungem la un modelminimal i deci relaiile redundante nu sunt necesare. Decizia ca o relaie esteredundant trebuie s fie precedat de o analiz amnunit a releiilor care compuncele dou drumuri dintre cele dou entiti, pentru c pot aprea situaii, cnd o relaieeste aparent redundant, dar n realitate este nevoie de ea.

n finalul acestui pas putem spune c am eliminat din modelul conceptual acelestructuri care sunt dificil de implementat i deci este mai corect ca n continuare s nereferim la acest model ca fiind un model logic local de date.

Pasul 2.2. Crearea de relaii peste modelul logic local

Obiectivul: Crearea de relaii peste modelul logic.Relaia pe care un tip de entitate o are cu alt tip de entitate este reprezentat

prin mechanismul cheie primar/cheie strin. Cheia strin pentru o entitate estereproducerea cheii primare altei entiti. Pentru a decide entitiile unde vom includecopia cheii primare a altei entiti, trebuie nainte s identificm entitile printe ifiu. Entitile printe se refer la acele entiti ale cror chei primare se vor copia

n entitile fiu.Pentru descrierea relaiilor vom folosii un limbaj de definire a bazei de date(Database Definition Language - DBDL). n acest limbaj, specificm prima datnumele entitii, urmat de atributele asociate ntre paranteze. Dup aceea identificmcheia primar i toate cheile alternante, precum i/sau cheile strine.

Tipuri de entitate tariPentru tipurile de entiti tari n modelul logic crearea unei relaii enclude toate

atributele entitii. Pentru atributele compuse al unei entiti, vom include numaiatributele simple din compunerea atricutului compus n descrierea entitii.

De exemplu tipul de entitate Familii, prezentat n figura 3.2. se descrie nurmtorul mod.

Page: 39


40/79

Familii (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers,Nr_pers_prezente, Nr_chei)

Cheie primar: Nr_mat

Trebuie sa plateasca

Familii

Nr_Mat

Nr_pers

Nr_pers_prezente

Nr_chei

Nr_Bloc

Scara

Etaj

Apartament

Fond_rulmentFond_reparatii

Alte_fonduri

Plati

Data

Nr_Mat (FK)

Valoare

Restanta

Figura 3.2. Exemplu de model logic.

Tipurile de entiti slabeDescrierea tipurilor de entiti slabe se face la fel ca i tipurile de entiti tari,

cu o completare i anume, evidenierea cheii strine. De exemplu descrierea tipului de

entitate de mai sus se descrie astfel:

Pli (Data, Nr_mat, Valoare, Restan)Cheie primar: Data, Nr_matCheie strin: Nr_mat se refer la Familii(Nr_mat)

Menionm c n cazul acesta cheia strin este i n compunerea chei primare.Deci nainte de introducerea cheii strine, cheia primar nu identifica unic o entitate.La terminarea acestui pas, putem identifica cheile prinare pentru toate tipurile deentiti din modelul logic.

Tipurile de relaii binare de tipul unu-la-unu (1:1)Pentru fiecare tip de relaie binar de tipul 1:1 ntre dou tipuri de entitate E1 i

E2 gsim o copie a cheii primare a tipului de entitate E1 n compunerea tipului deentitate E2, sub denumirea de cheie strin. Identificarea tipului de entitate printei a tipului de entitate fiu depinde de participarea entitilor la relaie. Tipul deentitate care particip parial la relaie este desemnat ca fiind printe iar cel cu

participare total fiu. Dac ambele tipuri de entitate particip parial sau total larelaie, atunci tipurile de entiti se pot evidenia ca fiind printe sau fiu arbitrar.n cazul n care participarea este total, putem ncerca s combinm cele dou tipuri

de entiti ntr-una singur. Aceast compunere poate s fie posibil n cazul n carenici unul dintre cele dou tipuri de entiti nu mai ia parte la alt relaie.Tipurile de relaii binare de tipul unu-la-multe 1:M

Page: 40


41/79

Pentru toate relaiile 1:M ntre dou entiti E1 i E2 n modelul logic de date,vom avea copia cheii primare a entitii E1 n compunerea entitii E2. Totdeaunaentitatea de partea unu a relaiei este considerat entitate printe, iar cealaltentitate fiu.

Atributele cu mai multe valoriPentru ficarea atribut A care permite mai multe valori din entitatea E1 n

modelul logic de date, crem o nou relaie care va conine atributul A mpreun cucheia primar a entitii E1 pe post de cheie strin. Cheia primar a noii relaii va fiatributul A, sau dac este necesar, compunerea ei cu cheia primar al lui E1.

Relaiile superclas/subclasPentru fiecare relaie superclas/subclas vom identifica superclasa ca fiind

entitatea printe, iar subclasa entitatea fiu. Exist multe moduri de a reprezentarelaia aceasta. De exemplu s lum relaia prezentat n figura 3.3.

(Opiunea 1)Locatari (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume,

Data_intrare_func, Nr_pers, Nr_pers_prez, Nr_chei)Cheie primar:Nr_mat

(Opiunea 2)Familii (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume,

Nr_pers, Nr_pers_prez, Nr_chei)Cheie primar: Nr_matef_de_scar (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume,

Data_intrare_func)Cheie primar: Nr_mat

(Opiunea 3)Locatari (Nr_mat, Nr_bloc, Scara, Apartament, Nume)Cheie primar:Nr_matef_de_scar (Nr_mat, Data_intrare_func)Cheie primar: Nr_matCheie strin :Nr_mat referire la Locatari(Nr_mat)

Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)Cheie primar: Nr_matCheie strin : Nr_mat referire la Locatari(Nr_mat)

Page: 41


42/79

Cap familie

Nr_Mat

Nr_pers

Nr_pers_prezent

Nr_chei

Fond_rulment

Fond_reparatii

Alte_fonduri

Sef de scara

Nr_Mat

Data_intrare_func

Locatari

Nr_Mat

Nr_Bloc (FK)

Scara (FK)

Etaj

Apartament

Nume

Figura 3.3. Exemplu de relatie superclas/subclas

Documentarea relaiilor i a atributelor din cheile strineActualizm dicionarul de date, ntroducnd fiacare atribut nou introdus n

compunerea unei chei la acest pas.

Pasul 2.3. Validarea, utiliznd normalizarea

Obiectivul: Validarea modelului logic, utiliznd tehnica normalizrii.Examinm procesul de normalizare dup cum am descris n capitolul 2. Prin

normalizare trebuie s demonstrm c modelul creat este consistent, conineredundan minimal i are atabilitate maxim.

Normalizarea este procesul prin care se decide dac atributele pot sau nu srmn npreun. Conceptul de baz a teoriei relaiilor este c atributele sunt grupatempreun pentru c exist o relaie logic ntre ele. Cteodat baza de date nu estecea mai eficient. Acesta se argumenteaz prin urmtoarele:

Proiectarea normalizat organizeaz datele n funcie de dependenele funcionale.Deci acest proces este situat undeva ntre proiectarea conceptual i cea fizic. Proiectul logic nu este un proiect final. El ajut priectantul s neleag natura

datelor n ntreprindere. Proiectul fizic poate fi diferit. Exist posibilitatea ca uneletipuri de entiti s se denormalizeze. Totui normalizarea nu este un timp pierdut.

Proiectul normalizat este robust i independent de anomaliile de actualizareprezentate n capitolul 2.

Calculatoarele moderne au mult mai mult putere de calcul, ca cele de acum civaani. Din aceast cauz, cteodat este mai convenabil implementarea unei baze de

date cu puin redundan, dect suportarea cheltuielilor pentru procedurileadii

ghid de proiectare a bazelor de date

Documents