Sunteți pe pagina 1din 20

METODOLOGIA DE PROIECTARE CONCEPTUAL A BAZELOR DE DATE Proiectarea unei baze de date cuprinde urmtoarele etape: - proiectarea conceptual - proiectarea

logic - proiectarea fizic. Proiectarea conceptual a bazei de date Proiectarea conceptual a bazei de date este procesul de construire a unui model al informaiilor utilizate n ntreprindere, independent de consideraiile de ordin fizic (SGBD-ul utilizat). Construirea modelului de date conceptual local pentru fiecare vedere a utilizatorilor De regul vederea unui utilizator este o zon funcional a ntreprinderii. Utilizatorul este o persoan real individual sau un grup de persoane; dentificarea vederilor utilizatorilor se realizeaz prin examinarea diagramelor de flux i prin chestionarea utilizatorilor. Modelul de date conceptual corespunztor vederii unui utilizator se numete model de date conceptual local corespunztor vederii respective. Fiecare model de date conceptual local cuprinde elementele enumerate n tabelul de mai jos, din care se desprind sarcinile de proiectare conceptual. Elemente ale modelului de date Sarcini pentru construirea modelului conceptual conceptual local local Tipuri de entiti Identificarea tipurilor de entitati (t.e.) Tipuri de relatii Identificarea tipurilor de relatii (t.r.) Atribute Identificarea si asocierea atributelor cu t.e si t.r. Domeniile atributelor Determinarea domeniilor atributelor Cheile candidat Determinarea atributelor chei candidat si chei primare Cheile primare Specializarea/generalizarea t.e. Desenarea diagramei E-R Revizuirea modelului conceptual local cu utilizatorii Identificarea tipurilor de entiti (t.e.) Modaliti de identificare: - studierea specificaiei cerinelor utilizatorului referitor la funcia utilizatorului n ntreprindere; se caut substantivele n specificaia cerinelor utilizatorului (de exemplu Nr_Personal; NumeP; Nr_Proprietate; AdresaP; Chirie etc.) - se caut obiectele principale de interes, excluzndu-se calitile; se grupeaz (de exemplu Nr_Personal i NumeP vor aparine aceluiai tip de entitate Personal) - se identific obiectele care exist pe cont propriu (de exemplu Personal exist indiferent de Nr_Personal, NumeP, etc.)

- discuii cu utilizatorii (de exemplu pentru eliminarea sinonimelor: Angajat = Personal) Dup identificarea t.e. li se atribuie denumiri evidente, care se trec ntr-un dicionar de date. Identificarea tipurilor de relaii (t.r.) De regul relaiile sunt indicate de expresii verbale n specificaia utilizatorului. De exemplu: filiale are personal; personal administreaz proprietate; chiria viziteaz proprietate etc. Intereseaz numai relaiile dintre entiti cerute. Majoritatea relaiilor sunt binare. Este bine de verificat fiecare pereche de tipuri de entiti, pentru a gsi o posibil relaie ntre ele. Se are in vedere si determinarea cardinalitii (1:1; 1:M; M:N) i constrngerilor de participare (total, parial); eventual se specific i valorile limit ale cardinalitii. Pe msur ce sunt identificate relatiile, li se atribuie denumiri evidente; acestea, precum i constrngerile se trec n dicionarul de date. Identificarea i asocierea atributelor cu t.e. sau t.r. Se caut substantive sau expresii substantivale n specificaia cerinelor utilizatorilor care s caracterizeze t.e. i t.r. gsite. Atributele sunt proprieti, caliti, caracteristici identificatoare ale unei entiti sau relaii. Se deosebete ntre atribute simple, compuse, derivate. Atributele derivate trebuie reprezentate n modelul conceptual pentru a nu pierde informaii. Pe msur ce sunt identificate li se atribuie denumiri evidente i semnificative pentru utilizatori. Pentru fiecare atribut se trec n dicionarul de date: denumirea, sinonime sau aliasuri, tipul de date i lungimea, eventuale valori prestabilite (default value), dac se accept Null-uri (required), dac e compus sau derivat, formula de calcul, dac are valori multiple. Determinarea domeniilor atributelor Domeniul este un recipient de valori din care unul sau mai multe atribute i iau valorile. De exemplu domeniul numerelor de filial valabile este compus din 3 caractere, liter-cifr liter. Domeniul va include i mulimea valorilor permise, dimensiunea i formatul cmpului. Se nregistreaz denumirea i caracteristicile domeniilor atributelor n dicionarul de date. Determinarea atributelor chei candidat i chei primare Pentru fiecare entitate se identific toate cheile candidat i se secioneaz dintre ele cheia primar. O cheie candidat este o submulime minim de atribute ale unei entiti, care identific n mod unic fiecare apariie a acesteia. Cheia primar aleas va ndeplini urmtoarele criterii: - va cuprinde un set minim de atribute - va fi cheia candidat cu cea mai mic probabilitate de modificare a valorilor - va fi cheia candidat cu cea mai mic probabilitate de a-i pierde caracterul de unicitate - va fi cheia candidat cu cele mai puine caractere - va fi cheia candidat cel mai uor de utilizat d.p.d.v. al utilizatorilor

Unei entiti tari i se poate identifica o cheie primar, nu i unei entiti slabe. Unei entiti slabe i se poate identifica o cheie primar numai prin plasarea n ea a unei chei strine, n cadrul relaiei sale cu entitatea tare. Cheile candidat care nu sunt selectate cheie primar devin chei alternative. Specializarea/generalizarea tipurilor de entiti (opional) Acest pas este dictat de reprezentarea ct mai clar a entitilor importante i a relaiilor dintre ele. Diagrama ER final trebuie s fie ct mai lizibil. Modelul ER din figura 5.1 a conine entitile Proprietate_de_Inchiriat i Proprietate_de_Vanzare. Se generalizeaz prin crearea entitii Proprietate (fig. 5.1 b.)

Entitile Proprietate_de_Inchiriat i Proprietate_de_Vanzare devin subclase ale entitii Proprietate n baza atributelor comune (Tipul, Adresa, cheia primar) i n baza relaiilor comune asociate fiecreia (Proprietar_deine_Proprietate). Entitile subclas au i atribute diferite (Chirie respectiv Pre) i relaii diferite (Inchiriaza respectiv Cumpara). Desenarea diagramei ER Diagrama ER care se deseneaz va fi reprezentarea conceptual a vederii unui utilizator asupra ntregii ntreprinderi. Diagrama ER va reprezenta modelul de date conceptual local bazat pe o anumit vedere a utilizatorului asupra ntreprinderii. Revizuirea modelului de date conceptual local mpreun cu utilizatorii Acest pas este necesar pentru a garanta c modelul este o reprezentare adevrat a ntreprinderii d.p.d.v. al utilizatorului. Proiectarea conceptual a bazei de date este procesul de construire a unui model al informaiilor utilizate n ntreprindere, independent de consideraiile de ordin fizic. Proiectarea conceptual ncepe prin crearea unui model de date conceptual al ntreprinderii, complet independent de detaliile de implementare. Pentru fiecare vedere a utilizatorilor asupra ntreprinderii este creat un model de date conceptual local. O vedere a utilizatorului const n datele cerute de ctre un anumit utilizator pentru a lua o decizie sau a efectua o anumit sarcin. De regul vederea unui utilizator este o zon funcional a ntreprinderii. Un utilizator poate fi o persoan sau un grup de persoane care utilizeaz n mod direct sistemul. Vederile utilizatorilor se pot identifica utiliznd diagrame de flux de date care definesc zonele funcionale i eventual funciile individuale sau/i prin chestionarea utilizatorilor, examinarea procedurilor, rapoartelor i observarea ntreprinderii. Fiecare model de date conceptual local cuprinde tipurile de entiti, tipurile de relaii, atributele, domeniile atributelor, cheile candidat i primare. Fiecare model de date conceptual local este susinut de ctre o documentaie, cum ar fi dicionarul de date, care este realizat pe parcursul dezvoltrii modelului. Proiectarea logic Proiectarea logic este procesul de construire a unui model al informaiilor utilizate n ntreprindere pe baza unui anumit model de date, dar independent de SGBD i de alte consideraii de ordin fizic. Construirea i validarea modelului de date logic pentru fiecare vedere a utilizatorilor este bazat pe modelul de date conceptual al vederii utilizatorului asupra ntreprinderii. Se efectueaz modificarea structurii modelului conceptual conform cerinelor modelului de date relaional (conform cerinelor caracteristice unui sistem de gestionare relaional). Transpunerea modelului de date conceptual local ntr-un model de date logic local Se rafineaz modelul de date conceptual local prin eliminarea caracteristicilor nedorite.

Eliminarea relaiilor de tip M:N O relaie M:N (de mai muli la mai muli) se descompune pentru a identifica o relaie intermediar. Relaia M:N se nlocuiete cu dou relaii 1:M. Exemplu: Relaia Ziar Face Reclama Proprietate (fig. 5.2. a) este de cardinalitate M:N, deoarece un ziar poate face reclam mai multor proprieti, iar unei proprieti i se poate face reclam in mai multe ziare. Relaia se descompune conform figurii 5.2. b, unde Reclama este o entitate slab a crei existen depinde de existena celorlalte dou entiti tari.

Apar dou tipuri de relaii noi: Listeaza i respectiv Reclama In care leag entitatea slab de cele 2 entiti tari. Eliminarea relaiilor complexe O relaie complex include cel puin trei tipuri de entiti. Ea trebuie descompus pentru a identifica o relaie intermediar. Relaia complex se nlocuiete cu un numr corespunztor de relaii binare de cardinalitate 1:M. n exemplul din figura 5.3. relaia complex Inchiriaza s-a descompus n trei relaii 1:M, anume Organizeaza, AsociatCu i ine; s-a identificat o entitate slab: Acord_de_Inchiriere care este legat de entitile tari (iniiale) prin cele trei relaii binare de cardinalitate 1:M identificate. Analizai constrngerile de participare din fig. 5.3. a i 5.3. b!

Eliminarea relaiilor recursive Acesta este un tip particular de relaie care trebuie descompus pentru a identifica o relaie intermediar. n exemplul din figura 5.4. relaia recursiv Supravegheaza este eliminat prin identificarea unei relaii adiionale denumit SupravegheatDe i a unei entiti slabe: Personal_Alocat.

Eliminarea relaiilor cu atribute Atunci cnd o relaie are asociat un atribut, acest lucru sugereaz existena unui tip de entitate neidentificat. Exemplul din figura 5.5 se refer la determinarea numrului de ore lucrate de angajaii temporari atribuii fiecrei filiale. Relaia LucreazaLa are atributul Ore- Lucrate i este de cardinalitate M:N. Se descompune n dou relaii binare de cardinalitate 1:M. Acum atributul Ore_Lucrate aparine noii entiti slabe identificate: Alocaie_Filiala. Analizai constrngerile de participare din fig. 5.5 a i 5.5. b!

Eliminarea atributelor cu valori multiple Este vorba de atribute cu mai multe valori pentru o singur entitate. Acest atribut trebuie descompus pentru a identifica o nou entitate. Exemplul din figura 5.6. se refer la evidena filialelor, unde o filial poate avea mai multe numere de telefon. Se identific o nou entitate: Telefon, legat de entitatea Filiala prin relaia Are.

Reexaminarea relaiilor 1:1 Asemenea relaii pot indica existena a dou relaii care s reprezinte acelai obiect n cadrul ntreprinderii. n astfel de situaii cele dou entiti se mbin, selectnd una din cheile primare, dac acestea nu coincid. Cealalt cheie primar devine alternativ. De exemplu entitile Filiala i departament pot fi sinonime. Eliminarea relaiilor redundante O relaie este redundant atunci cnd aceeai informaie se poate obine i prin alte relaii. Trebuie deci aflat dac exist mai mult dect o singur cale ntre dou entiti. Dac se identific 2 ci, nu nseamn neaprat c una din relaii este redundant. Trebuie inut cont i de semnificaia temporal a relaiilor.

n exemplul din figura 5.7. relaia este neredundant, dei exist 2 ci intre entitatea Copil i Barbat. Tatl ar putea avea copii dintr-o cstorie precedent, sau ar putea s nu fie cstorit cu mama copilului, iar n figur se modeleaz numai cstoria curent a tatlui. Extragerea relaiilor (tipurilor de entiti) din modelul de date logic local Componena fiecrei relaii va fi descris utiliznd un limbaj de definire a bazelor de date (DBDL). ntr-un DBDL apare denumirea relaiei, apoi ntre paranteze atributele simple. Se identific cheia primar, cheile alternative i/sau cheile strine ale relaiei. Se trece relaia care conine cheia strin ca i cheie primar. Relaia pe care o entitate o are cu alt entitate este exprimat prin mecanismul cheie primar cheie strin, adic cheia primar din entitatea printe devine cheie strin n entitatea copil. n continuare se prezint cum relaiile care reprezint entitile i relaiile acestora sunt extrase din structurile de date posibile, prezentate n modelul de date logic (fig. 5.8.).

Din acest model de date logic se extrag: a. Tipuri de entiti tari: Pentru fiecare entitate tare (obinuit) se creeaz o relaie care s cuprind toate atributele sale simple. Exemplu: entitatea tare Personal Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu) Cheie primar Nr_Personal b. Tipuri de entiti slabe: Ruda_Apropiata. Pentru fiecare entitate slab se creeaz o relaie care s cuprind toate atributele sale simple. n plus se include cheia primar a entitii printe (sau proprietar) ca i cheie strin. Compoziia acestei relaii va fi: Ruda_Apropiata (Nr_Personal, NumeR, Adresa, Nr_Tel, Rudenie) Cheie primar Nr_Personal mpreun cu NumeR Cheie strin Nr_Personal se refer la Personal (Nr_Personal)

c. Tipuri de relaii binare unu la unu (1:1) n relaia de cardinalitate 1:1 Personal Administreaza Filiala entitatea printe este Personal, deoarece are participare parial. Ca urmare se plaseaz o copie a cheii primare din Personal n Filiala, unde devine cheie strin sub denumirea Nr_Personal_Manager. Compoziia acestor relaii va fi: Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu) Cheie primar Nr_Personal Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager) Cheie primar Nr_Filiala Cheie alternativ Nr_Tel sau Nr_Fax Cheie strin Nr_Personal_Manager, care se refer la Personal (Nr_Personal) d. Tipuri de relaii binare unu-la-mai-muli (1:M) Pentru fiecare relaie binar 1:M ntre entitile E1 i E2 se plaseaz o copie a cheii primare din E1 n E2, unde devine cheie strin. Entitatea aflat n partea notat cu 1 este entitatea printe, iar cea din partea cu M este entitatea copil. ntotdeauna cheia primar din entitatea printe devine cheie strin n entitatea copil. Exemplu: Filiala Are Personal, unde Filiala este printe iar personal este copil. Compoziia acestor relaii va fi: Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu, Nr_Filiala) Cheie primar Nr_Personal Cheie strin Nr_Filiala se refer la Filiala (Nr_Filiala) Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager) Cheie primar Nr_Filiala Cheie alternativ Nr_Tel sau Nr_Fax Cheie strin Nr_Personal_Manager, care se refer la Personal (Nr_Personal) 5.2.1.2. se ncheie cu documentarea relaiilor i atributelor chei strine. Compoziia relaiilor extrase din modelul de date logic se documenteaz utiliznd DBDL. Sintaxa poate fi extins pentru a exprima constrngerile de integritate asupra cheilor strine (vezi 5.2.1.6). i dicionarul de date trebuie reactualizat cu noile atribute cheie identificate la 5.2.1.2 Validarea modelului prin utilizarea normalizrii Normalizarea este o procedur de stabilire a atributelor care aparin mpreun unui tip de entitate. Prin normalizare datele sunt organizate conform dependenelor lor funcionale i se elimin riscul anomaliilor de reactualizare. n prima form normal se elimin grupurile repetitive. Validarea modelului conform tranzaciilor utilizatorului Modelul trebuie s accepte tranzaciile cerute de ctre vederile utilizatorului. Tranzaciile se determin din specificaiile cerinelor utilizatorilor. Prin folosirea diagramei ER, a

dicionarului de date i a legturilor cheie primar/cheie strin prezentate n relaii se ncearc efectuarea manual a tranzaciilor. Desenarea diagramei ER Se deseneaz varianta final a diagramei ER, validat prin normalizare i conform cu tranzaciile pe care trebuie s le accepte. Definirea constrngerilor de integritate Prin impunerea de constrngeri se protejeaz baza de date fa de riscul de incoeren. Se consider 5 tipuri de integritate, anume referitoare la: a. datele cerute b. domeniile atributelor c. integritatea entitilor d. integritatea referenial e. constrngerile ntreprinderii a. Datele cerute Unele atribute nu admit Null-uri. n aceste situaii se selecteaz proprietatea de camp required, care cere date pentru cmpul respectiv. Se verific dac aceste constrngeri au fost identificate i documentate n dreptul atributelor n dicionarul de date (vezi 5.1.2) b. Constrngerile privind domeniile atributelor Se verific dac s-au identificat i documentat la 5.1.4 c. Integritatea entitilor Cheia primar a unei entiti nu poate conine Null-uri. Se verific 5.1.5 d. Integritatea referenial Se refer la relaia entitate printe entitate copil. Se tie c cheia primar din printe se copiaz n copil unde devine cheie strin. Integritatea referenial nseamn ca o valoare nenul a cheii strine din entitatea copil trebuie s se refere la (s coincid cu) o valoare existent n entitatea printe. Dac entitatea copil are participare total n relaie, nu sunt permise Null-uri n cmpul cheie strin. Se admit atunci cnd entitatea copil are participare parial. Asigurarea integritii refereniale se realizeaz prin constrngeri de existen. Acestea definesc condiiile n care poate fi inserat, reactualizat (modificat) sau tears o cheie candidat sau o cheie strin. Se ia ca exemplu relaia Personal Administreaz Proprietate, de cardinalitate 1:M. Entitate printe (Ep): Personal, cheie primar: Nr_Personal Entitate copil (Ec): Proprietate, cheie strin: Nr_Personal, copie a cheii primare din Personal.

Cazul 1. Inserarea unei apariii n relaia (entitatea) copil Pentru a asigura integritatea referenial se verific dac atributul Nr_Personal din apariia nou inserat n Ec este stabilit ca Null sau are o valoare existent n Ep. Cazul 2. tergerea unei apariii din relaia (entitatea) copil Se poate efectua fr probleme, nu afecteaz integritatea referenial. Cazul 3. Reactualizarea cheii strine n relaia (entitatea) copil (Similar cazului 1) Cazul 4. Inserarea unei apariii n relaia (entitatea) printe Se poate efectua fr probleme. Ep are participare parial, deci poate exista un membru al personalului care nu administreaz o proprietate. Cazul 5. tergerea unei apariii din relaia (entitatea) printe. Dac apariie care urmeaz a fi tears din Ep i corespunde o apariie (sau mai multe) din Ec, atunci integritatea referenial se pierde prin tergere. Posibile strategii de luat n considerare: NO ACTION Blocarea tergerii apariiei din Ep, dac are corespondent(i) n Ec CASCADE Dac o apariie n Ec se terge, se terg automat corespondenii din Ec.Dac Ec acioneaz ca Ep n alt relaie, tergerea se propag n cascad. SET NULL Cnd se terge o apariie din Ep, valorile cheii strine n Ec sunt setate la Null. Are loc o reactualizare prin setare la Null a valorilor atributelor selectate din cheia strin a Ec. Aceast strategie se poate aplica numai dac atributele cheie strin accept Null-uri. SET DEFAULT Cnd se terge o apariie din Ep, valorile cheii strine corespunztoare din Ec sunt setate la valori prestabilite (default).Exemplu: se terge un membru al personalului n Ep (Personal) i automat proprietile pe care acestea le-a administrat trecute n Ec (Proprieti) se seteaz la atributul Nr_Pers la valoarea corespunztoare managerului. NO CHECK Nu are loc nici o verificare de integritate. Cnd se terge o apariie din Ep nu este garantat meninerea integritii refereniale. Cazul 6. Reactualizarea cheii primare n relaia (entitatea) printe Dac valorii reactualizate a cheii primare n Ep i corespundeau una (mai multe) valori ale cheii strine n Ec, integritatea referenial este pierdut. Se va aplica una din strategiile de la cazul 5. e. Constrngerile ntreprinderii Sunt de fapt regulile de afaceri care pot uneori genera reactualizri ele entitilor. De exemplu agenia imobiliar poate stabili ca un membru al personalului s administreze maxim 10 proprieti. 5.2.1.6. se ncheie cu documentarea tuturor constrngerilor de integritate. Aceasta se face n dicionarul de date, pentru a fi luate n considerare la implementarea fizic.

Revizuirea modelului de date logic local mpreun cu utilizatorii Se verific dac modelul de date logic local este o reprezentare adevrat a vederii utilizatorului. Modelul de date logic local trebuie s fie complet i in ntregime documentat. Modelul i documentaia se revd mpreun cu utilizatorul. Construirea i validarea modelului de date logic global n aceast etap se construiete un model de date logic global prin mbinarea modelelor de date logice locale individuale, care au fost realizate pentru a reprezenta fiecare vedere a utilizatorilor. Dup mbinare trebuie rezolvate conflictele dintre vederi, ca i orice suprapuneri existente. Va rezulta o reprezentare a ntregii ntreprinderi independent de orice utilizator sau aplicaie. mbinarea modelelor de date logice locale individuale ntr-un singur model de date logic global al ntreprinderii (1) Revizuirea denumirilor entitilor i cheilor primare din modelele locale. Pot exista dou sau mai multe entiti care au aceeai denumire dar sunt de fapt diferite, respective acre au denumiri diferite, dar sunt aceleai. Se compar coninutul de date al fiecrui tip de entitate. Se utilizeaz cheile primare pentru a identifica tipurile de entiti echivalente, dar cu denumiri diferite. (2) Revizuirea denumirilor relaiilor. Se procedeaz ca la (1). (3) mbinarea entitilor din vederile locale mbinarea entitilor cu aceeai denumire i aceeai cheie primar (fig. 5.9) Astfel de entiti reprezint de regul acelai obiect n lumea real. La fuziune se includ atributele entitilor iniiale, eliminndu-se dublurile.

n versiunea global obinut prin mbinare s-a utilizat versiunea descompus a atributului Nume_Prenume (n urma consultrii cu utilizatorii). mbinarea entitilor cu aceeai denumire i chei primare diferite (fig. 5.10) Astfel de entiti nu au aceeai cheie primar, dar au chei candidat similare. Rezult aceeai vedere global ca n fig. 5.9.

mbinarea entitilor cu denumiri diferite, cu chei primare similare sau diferite Astfel de entiti se pot identifica atunci cnd: denumirile sunt diferite, dar indic acelai scop, dup cheia primar, dup participarea n anumite relaii. Exemplu: Entitile Personal i Angajai. (4) Includerea (fr mbinare) a entitilor unice din fiecare vedere local Toate entitile care nu au echivalent se includ nemodificate n modelul global. (5) mbinarea relaiilor din vederile locale Se examineaz toate relaiile (denumire, scop, constrngeri structurale) din toate vederile locale i se elimin conflictele, prin: - mbinarea relaiilor cu aceeai denumire i acelai scop, apoi - mbinarea relaiilor cu denumiri diferite dar acelai scop (6) Includerea (fr mbinare) a relaiilor unice din fiecare vedere local Relaiile pentru care nu s-au gsit relaii identice n alte vederi se includ nemodificate n modelul global. (7) Cutarea entitilor i relaiilor lips Identificarea entitilor i relaiilor lips dintre diversele vederi ale utilizatorilor i care nu apar n nici una dintre vederi este o operaiune dificil: Acestea pot rezulta din modelul de date general, dac exist. Cnd se consult utilizatorii asupra unei anumite vederi, ei trebuie rugai s examineze i entitile i relaiile din alte vederi. Se examineaz atributele fiecrui tip de entitate i se compar cu atributele entitilor

din alte vederi. Poate exista un atribut al unei entiti dintr-o vedere care corespunde unui atribut cheie primar, cheie alternativ sau unui atribut simplu al unei entiti din alt vedere. Dintr-o astfel de coresponden rezult existena unei relaii neidentificate, construibil prin mecanismul cheie primar/cheie strin. (8) Verificarea cheilor strine Se verific dac cheile strine din entitile copil mai sunt corecte i se efectueaz modificrile necesare. (9) Verificarea constrngerilor de integritate Se verific dac constrngerile de integritate ale modelului global nu intr n conflict cu constrngerile de integritate din vederile utilizatorilor. Conflictele se rezolv prin consultarea cu utilizatorii. (10) Desenarea modelului de date logic global Se deseneaz diagrama ER a modelului de date logic global, care reprezint mbinarea tuturor modelelor de date logica locale. (11) Reactualizarea documentaiei Documentaia trebuie reactualizat n urma modificrilor intervenite la realizarea modelului global. Documentaia trebuie s reflecte ntotdeauna modelul de date curent. Validarea modelului de date logic global Se realizeaz prin utilizarea normalizrii i conform tranzaciilor cerute, dac este necesar. Este un pas echivalent cu 5.2.1.3 respectiv 5.2.1.4, anume se fac aceleai validri dar acum pentru modelul de date logic global. Verificarea n vederea dezvoltrii locale Se determin dac este probabil ca n viitorul previzibil s apar modificri i se evalueaz capacitatea modelului de date logic global de a cuprinde aceste modificri. Modelul de date logic global trebuie s poat fi extins cu uurin. Modelul creat trebuie s fie extensibil, s poat evolua n condiiile afectrii minime a utilizatorului. Se incorporeaz modificri numai dac utilizatorul o cere. Desenarea diagramei ER finale Diagrama ER final reprezint modelul de date logic global al ntreprinderii. Se deseneaz dup ce modelul de date logic global a fost validat. Documentaia (schema relaional i dicionarul de date) trebuie reactualizat i completat. Revizuirea modelului de date logic global mpreun cu utilizatorii Revizuirea va garanta faptul c modelul de date logic global este o reprezentare adevrat a ntreprinderii. Modelul mpreun cu documentaia se revizuiesc n colaborare cu utilizatorii, pentru a confirma c sunt corecte i complete.

Rezumatul capitolului 5.2. Proiectarea logic a bazelor de date este procesul de construire a unui model al informaiilor utilizate n cadrul unei ntreprinderi, bazat pe un anumit model de date, dar independent de un anumit SGBD i de alte consideraii de ordin fizic. Principalele etape cuprind: construirea i validarea unui model de date logic local corespunztor fiecrei vederi a utilizatorilor (5.2.) i construirea i validarea unui model de date logic global (5.2.2). Rafinarea unui model de date conceptual pentru a obine un model de date logic include: eliminarea relaiilor de tip M:N, a relaiilor complexe, recursive, cu atribute, a atributelor cu valori multiple, reexaminarea relaiilor de tip 1:1 i eliminarea relaiilor neredundante. Modelul de date logic se valideaz prin normalizare, prin care se garanteaz c modelul reprezint fidel ntreprinderea, este coerent, cu redundan minim i stabilitate maxim. Constrngerile de integritate se impun pentru a proteja BD fa de a devein incoerent. Exist 5 tipuri de constrngeri de integritate: asupra datelor necesare, ale domeniilor atributelor, de integritate a entitilor, de integritate referenial i ale ntreprinderii. Integritatea referenial se asigur prin constrngeri de existen, care definesc n ce condiii poate fi o cheie candidata sau strin inserat, reactualizat sau tears. Exist mai multe strategii care pot fi aplicate atunci cnd o apariie a entitii printe pe care vrem s o tergem are corespondent n entitatea copil: NO ACTION, CASCADE, SET NULL, SET DEFAULT i NO CHECK. Constrngerile ntreprinderii se numesc uneori i reguli de afaceri. Modelul de date logic este susinut de ctre documentaie, cum ar fi dicionarul de date sau schema relaional, care sunt realizate pe parcursul construirii modelului.