Proiectarea si gestionarea bazelor de date Note de curs

Proiectarea si gestionarea bazelor de dateNote de curs

Definiii Date - sunt material brut, fapte, simboluri, numere, cuvinte, poze fr un neles de sine stttor, neintegrate ntr-un context, fr relaii cu alte date sau obiecte.Informaie - Datele organizate i prezentate ntr-un mod sistematic pentru a sublinia sensul acestor date devin informaii. Informaiile se prezint sub form de rapoarte, statistici, diagrame etc. Cunotinele - sunt colecii de date, informaii, adevruri i principii nvate, acumulate de-a lungul timpului. Informaiile despre un subiect reinute i nelese i care pot fi folosite n luarea de decizii, formeaz judeci i opinii devin cunotine. Fiier - un set de informaii memorat n format electronic pe diverse medii de stocare (programe, baze de date, documente text, imagini,secvene video). Baz de date colecie partajat de date legate logic, organizate n scopul optimizrii procesului de cutare i modificare a lor sau a relaiilor dintre ele, independent de o anumit aplicaie. SGBD - un sistem de programe care fac posibil definirea, ntreinerea i accesul controlat la baza de date. Avantajele unei baze de date controlul redundanei consistena datelor economia de spaiu pentru aceleai date controlul integritii datelor utilizarea standardelor d posibilitatea rspunsului la cereri variate i cu exprimri parial necunorcute la momentul proiectrii. productivitate crescut concuren crescut posibiliti crescute de recuperare n caz de eroare Dezavantajele bazei de date complexitate crescut, costul SGBD, cost crescut rezultat din cerine de hard, costul trecerii de la un sistem la altul, eventual defeciune are un impact crescut, global.

Obiectivele bazelor de date Asigurarea independentei datelor (modificrile care se fac la un anumitnivel de structura de date s nufie 'vizibile' la nivelul de organizare imediat superior). Asigurarea unei redundante minime i controlate a datelor din baza de date Pe ct posibil, fiecare informaie s apar o singur dat. Nu sunt excluse nici cazurile ncare s se accepte o anumit redundan a datelor. Asigurarea unor faciliti sporite de utilizare a datelor Obiectivele bazelor de date (continuare) Asigurarea integritii datelor mpotriva unor tergeri intenionate sau neintenionate,prin intermediul unor proceduri de validare, a unor protocoale de control concurent i aunor proceduri de refacere a bazei de date dupincidente. Asigurareapartajabilitiidatelor. Partajabilitatea datelor trebuie neleasi subaspectul posibilitii dezvoltrii unor aplicaii fr a se modificastructura bazei de date. Tipuri de baze de date IerarhicToate datele trebuie dispuse ntr-o structur arborescent, n care fiecare nod printe poate avea mai muli copii, dar fiecare dintre copii are un singur printe. Fiecare nivel posed o relaie de tip una-la-mai-multe cu urmtorul nivel inferior. Pe msur ce coborm nivele, o structur arborescent trece de la general la particular.Acest tip solicit o organizare foarte precis a datelor, ntr-o manier fix.

Tipul n reeaUn model de tip reea este utilizat atunci cnd datele sunt dispuse ntr-o structur complex n care un nod printe poate avea mai muli copii, dar i un nod copii poate avea mai muli prinin. n general ntre un nod i copiii si exist o relaie de tip una-la mai-multe, dar nivelele nu mai sunt dispuse ierarhic, astfel nct informaia nu trece obligatoriu de la general la particular pe msura ce coborm nivelele.

Modelul de date orientat obiect (Object Model) Sistemele de baze de date orientate obiect se bazeaz pe limbaje de programare orientate obiect cu capaciti depersisten, n care datele sunt independente de timpul de via al programelor care le creeaz sau acceseaz, prin memorare pe suport magnetic (disc).Caracteristicile importante: abstractizarea, motenirea, ncapsularea, modularizarea.Domenii (n special cele care manipuleaz tipuri de date complexe): proiectarea asistat de calculator, sisteme de informaii geografice, medicin . . .Modelul de date obiect-relaional (Object-Relational Model)reprezint extinderea modelului relaional cu caracteristici ale modelului obiect pentru realizarea bazelor de date care definesc i prelucreaz tipuri de date complexe.n esen, modelul obiect-relaional pstreaz structurarea datelor n relaii (reprezentate ca tabele), dar adaug posibilitatea definirii unor noi tipuri de date, pentru domeniile de valori ale atributelor. Tipurile de date definite de utilizator pot fi extinse prin mecanismul de motenire i pentru fiecare tip sau subtip se pot defini metode pe care le pot executa obiectele de acel tip. Modelul relaional Este un model deoarece el poate fi descris cu ajutorul unui numr mic de concepte care se refer la relaii (structuri de date bidimensionale ce au proprieti speciale), rnduri (datele aflate n cadrul relaiilor), coloane (cmpurile datelor din rndurile corespunztoare) i chei (mecanismul de identificare i asociere a rndurilor aflate n unul sau mai multe tabele). se bazeaz pe teoria matematic a seturilor, ceea ce nseamn faptul c toate operaiile sunt ncheiate cu succes, iar rezultatele operaiilor sunt predictibile. Componentele ale modelului relaional componenta de structur a datelor (relaii cu proprieti speciale); componenta de manipulare a datelor (operaii predefinite prin care tehnologia relaional folosete un optimizator inteligent pentru a gsi calea de acces la date); componenta de integritate a datelor (reguli necesare proteciei datelor la efectuarea unor operaii incorecte). Avantajele bazelor de date relaionale Integritate ncorporat la mai multe nivele. Integritatea datelor este integrat n cadrul modelului la nivel de cmp pentru a asigura precizia datelor. La nivel de tabel asigur faptul c o nregistrare nu mai poate fi introdus nc o dat n baza de date, precum i detectarea lipsei valorilor din cmpurile cheie primar. La nivel de relaie asigur validitatea acestora ntre tabele. La nivel logic, asigur acurateea logic a datelor. Independena logic i fizic a datelor de programele aplicaie: nici modificrile efectuate de ctre utilizator modelului logic al bazei de date, nici modificrile efectuate de ctre productorul bazei de date implementrii fizice a acesteia, nu vor afecta programele aplicaiilor care utilizeaz baza de date. Garanteaz consistena i precizia datelor: datele sunt consistente i precise datorit multiplelor nivele de integritate ce pot fi introduse n baza de date. Extragerea cu uurin a datelor din baza de date. n urma comenzilor introduse de ctre utilizator, datele din baza de date pot fi extrase fie dintr-un singur tabel, fie dintr-o multitudine de tabele asociate prin intermediul relaiilor, ceea ce ofer posibilitatea prezentrii datelor ntr-un numr nelimitat de moduri. Noiuni de baz Relaie tabel ce conine coloane i rnduri. Atribut o coloana a relaiei (tabelului), cu o anumit denumire. Domeniu mulimea de valori permise pentru unul sau mai multe atribute. Tuplu rndul dintr-o relaie. Grad numrul de atribute pe care le conine aceasta. Cardinalitate numrul de tupluri coninute. Schema relaiei denumirea relaiei, urmat de un set de perechi de atribute i denumiri de domenii. Null: lipsa valorii unui atribut; este diferit de valoarea 0 sau un ir de caractere alctuit din spaii albe Obiectele bazei de date relaionale Tabele Unitatea primar de stocare a datelor ntr-o baz de date relaional este tabelul, care este o structur bidimensional compus din rnduri i coloane. Fiecare tabel reprezint o entitate Fiecare rnd al tabelului reprezint o apariie a entitii. Definiie: Entitate: Un obiect sau un concept ce se poate identifica unic.O entitate este un obiect al lumii reale, cu o existen independent i poate reprezenta un obiect fizic, o activitate, un concept. de ex.: persoan particular, automobil, companie, activitate, curs universitar. Orice entitate are o serie de proprieti numite atribute, ce descriu entitatea respectiv. Definiie: Tip de entitate: Este un obiect sau un concept, identificat de o ntreprindere, avnd o existen independent. Tipurile de entiti reprezint obiecte reale, din viaa de zi cu zi, avnd proprietile lor, sau obiecte conceptuale, abstracte.Un tip de entitate conine mai multe entiti. Un tip de entitate se identific prin nume i list de atribute. O baz de date conine n general mai multe tipuri de entiti. Fiecare tip de entitate are propriile lui atribute. Putem clasifica aceste tiburi n tipuri slabe i tipuri tari.Definiie: Tip slab de entitate: Este un tip de entitate, a crui existen este dependent de un alt tip de entitate.Definiie: Tip tare de entitate: Este un tip de entitate, a crui existen nu depinde de nici un alt tip de entitate.Entitile slabe se mai numesc dependente sau cubordonate iar cele tari printe sau dominante.AtributeDefiniie: Atribute: Proprietaile unui tip de entitate sau de relaie.Definiie: Domeniul atributului: Un set de valori ce se pot da acelui atribut.Domeniul unui atribut nu se poate definii totdeauna foarte exact. De exemplu, atributul nume de familie poate lua orice nume de familie existent. Evident, acest atribut trebuie s fie un ir de caractere, dar oare ce caractere poate s conin? Unele domenii se pot descompune n mai multe subdomenii. De exemplu data naterii se poate descompune in subdomeniile: an, lun, zi. Atributele se pot clasifica n simple sau compuse; cu o singur valoare sau cu mai multe valori; respectiv derivate.Definiie: Atribut simplu: Atribut care are doar o singur component i o existen independent.Aceste atribute nu se pot diviza mai trziu n mai multe atribute distincte.Definiie: Atribut compus: Atribut care are mai multe componente i o existen independent.Aceste atribute se pot diviza n mai multe atribute simple. De exemplu atributul adres se poate descompune n atributele: strada, numr, ora, cod potal i jude. Decizia ca un atribut compus s se descompun n mai multe atribute simple este dependent de modul n care se va utiliza acel atribut: separat pe componente, sau ntregul atribut.Definiie: Atribut cu o singur valoare: Atribut care poate lua o singur valoare pentru fiecare entitate.Majoritatea atributelor sunt atribute cu o singur valoare, ceea ce este indicat n proiectarea bazelor de date.Definiie: Atribut cu mai multe valori: Atribut care poate lua mai multe valori pentru fiecare entitate.Atributele cu mai multe valori, trebuie s aib totdeauna o limit inferioar i una superioar.Definiie: Atribut derivat: Atribvut a crei valoare se poate calcula din unul, sau mai multe alte atribute, care nu sunt neaprat atributele entitii n cauz.De exemplu atributul vrsta este derivat din atributul data naterii i data zilei n care se utilizeaz acest atribut. Alt exemplu ar fi atributul numrul total de entiti, ceea ce se poate calcula, numrnd entitile nregistrate.Chei:Definiie: O cheie este un cmp ce are o valoare unic, corespunztoare fiecrei nregistrri dintr-un tabel. Sunt mai multe tipuri de chei, fiecare avnd propriile caracteristici.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 aib una sau mai multe chei candidat, din care doar una selectat este i primar. Orice tabel trebuie s aiba o cheie primar.Decizia referitoare la care din chile candidate s fie cheie primar este dependent de lungimea cheii. Cheia primar este de obicei cea mai scurt dintre cheile candidat. O cheie primar trebuie s fie:1. Stabil. Valoarea unei chei primare nu trebuie s se modifice sau s devin nul pe tot parcursul existenei unei entiti. O cheie primar stabil ajut la pstrarea unui model stabil. 2. Minimal. Cheia primar trebuie s fie alctuit dintr-un numr minim de cmpuri ce sunt capabile s asigure unicitatea.3. Centrat pe date, nu pe informaii. Nu trebuie s apar grupri de caracteristici n cadrul unei valori a unei chei ce pstreaz meta-informaii adiionale, deoarece nu se respect principiul atomicitii atributelor, crescnd astfel posibilitatea ca valorile cheii primare s se modifice.4. Definitiv. n momentul introducerii unei noi nregistrri, trebuie s existe posibilitatea introducerii unei valori. Cheia primar acioneaz ca un mecanism de constrngere suplimentar a entitii deoarece nu poate fi introdus o instan a unui tip de entitate dac aceasta nu are o valoare permis n cheia primar.5. Accesibil. Oricine dorete s creeze, citeasc, sau tearg o nregistrare trebuie s poat vizualiza valoarea cheii primare.

Definiie: Cheie alternativ: Este o cheie candidat ce nu a fost desemnat drept cheie primar. Ea poate deveni cheie primar dac cheia primar aleas iniial nu mai corespunde la un moment dat. Definiie: Cheie extern: Exist doar n situaia n care se stabilesc dou sau mai multe relaii ntre tabelele bazei de date. Un atribut al unui tabel trebuie s existe i n cellalt tabel legat de primul printr-o relaie.Definiie: Cheie compus: O cheie candidat care contine cel putin dou atribute.Relaiile Definiie: Relaie: Asociere ntre entitti (tabele), cnd asocierea include un tip de entitate dintre toate tipurile participante.Tipuri de relaiiDefiniie: Tip de relaie: Asociere ntre tipuri de entiti.Definiie: Gradul relaiei: Numrul entitiilor participante n relaie.Entitiile dintr-o relaie se numesc participani. Numrul lor d gradul relaiei. Dac intr-o relaie sunt doi participani, atunci relaia se numete binar.Definiie: Relaie recursiv: Relaie n care aceleai entiti particip n roluri diferite.n cazul relaiilor recursive cele dou arce de la entitate la relaie i napoi, primesc diferite etichete, care sunt importante n nelegerea corect a relaiei.Atributele relaiilorAtributele descrise mai sus, se pot asocia i relaiilor. Aceste atribute se reprezint grafic, ca i atributele entitiilor, cu deosebirea c legtura nu este cu o entitate, ci cu o relaie. Adic linia leag elipsa de rombul ce semnific relaia.StructuralitateaS analizm acum restriciile ce pot aprea la includerea unei entiti participante ntr-o relaie. Avem dou tipuri mari de restricii: cardinalitatea i prticiparea.CardinalitateaDefiniie: Cardinalul este numrul relaiilor posibile pentru o entitate partricipant.Majoritatea relaiilor au gradul doi, care pot fi: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N).Relaiile unu-la-unu:

n relaiile unu-la-unu, o entitate este legat de cel mult o entitate din partea cealalt a relaiei. 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. Relaiile multe-la-multe:

Acest tip de relaie se deosebete de relaia unu-la-multe prin faptul c relaia invers nu este de unu-la-unu, ci de unu-la-multe. Deci, dac i relaia direct i reaia invers este de tipul unu-la-multe, atunci relaia este de tipul multe-la-multe i se noteaz cu (N:M).

1: 11: MM: M

ParticipareaDefiniie: Participarea determin dac existena unei entiti depinde sau nu de relaia cu o alt entitate. Participarea poate fi de mai multe tipuri: total i parial. n cazul participrii totale, toate entitiile particip n relaia dat. n caz contrar participarea se numete parial. Sistemul de Gestiune al Bazelor de Date SGBD constituie o interfa ntre utilizatori i baza de date i reprezint un pachet de programe specializat pentru definirea, crearea, ntreinerea i accesul controlat la baza de date.Obiectivul principal al unui SGBD este de a separa datele de programele de aplicaie. Funciile unui SDGBD Funcia de descriere a datelor care permite definirea structurii bazei de date cu ajutorul limbajului de definire a datelor (DDL). Funcia de manipulare a datelor este cea mai complex funcie i realizeaz urmtoarele activiti: crearea (ncrcarea) bazei de date; adugarea de noinregistrri; tergerea unornregistrri

Componentele unui mediu SGBD n structura sistemului sunt cinci componente principale: hardware, software, date, proceduri i persoane.1.Hardware.Reprezint suportul fizic pentru SGBD i poate fi format de un singur calculator personal, un calculator mainframe, sau chiar o reea de calculatoare. Elementele specifice de hardware depind de cerinele organizaiei i de SGBD utilizat. Fiecare SGBD impune cerine minimale pentru echipamentele fizice necesare funcionrii optime.2.Software.Componenta software include programele ce formeaz SGBD, programele de aplicaie, sistemul de operare local i atunci cnd este cazul software de reea. Un SGBD include module program specializate pentru a ndeplini anumite funciuni: Gestionarea bazei de date; Definirea datelor (descrierea datelor); Manipularea datelor (actualizare i interogarea bazei de date); Controlul i securitatea datelor (controlul integritii, accesul concurenial i securitatea datelor);utilitare. Administratorul bazei de date are una dintre cele mai importante funcii n cadrul unui sistem de gestiune al bazelor de date. Principalele componente ale acestuia sunt prezentate n figura 1.4. Aceste componente pot fi urmtoarele: Procesorul de interogare este utilizat pentru a simplifica i uura accesul la date. Acesta conine Evaluatorul de interogare care execut fiecare interogare pe baza unui plan. Administratorul de date este utilizat pentru a minimiza resursele necesare transferului de date dintre memoria intern i cea extern. Administratorul de date este un program care ofer o interfa ntre datele nmagazinate n baza de date i interogrile formulate prin intermediul aplicaiilor. Conine urmtoarele componente: Controlul de autorizare care verific dac utilizatorul are dreptul de a efectua operaia cerut. Administratorul de fiiere. Administratorul de buffer care rspunde de transferul datelor dintre memoria principal i dispozitivele de stocare secundare.

Administratorul de tranzacii este utilizat pentru a controla atomicitatea i concurena tranzaciilor n scopul pstrrii consistenei i durabilitii bazei de date. O tranzacie reprezint o colecie de operaii aplicate bazei de date care sunt efectuate toate deodat sub forma unei singure uniti logice. Aceast component este alctuit din: Administratorul de tranzacii. Administratorul de blocare. Administratorul de reconstituire care garanteaz c baza de date rmne ntr-o stare coerent dup ce n baza de date a aprut o eroare. Acesta este responsabil de reluarea sau abandonarea unei tranzacii. Programele de aplicaie nu fac parte din SGBD, dar acceseaz baza de date prin intermediul SGBD. Ele nu gestioneaza datele ci doar prezinta informaia n termeni specifici aplicaiei prin intermediul unei interfee.

3.Date.Reprezint cea mai important component a unui mediu SGBD i include att meta-datele ct i datele propriu-zise.4.Proceduri.Procedurile includ regulile care guverneaz proiectarea i utilizarea bazei de date. Activitatea utilizatorilor sistemului i a personalul care administreaz baza de date se desfoar conform unor proceduri documentate privind modul de folosire i funcionare a sistemului. Aceste instruciuni se refer la deschiderea i nchiderea unei sesiuni de lucru, utilizarea unor faciliti SGBD i a programelor de aplicaie, activarea i dezactivarea SGBD, arhivarea datelor, utilizarea copiilor de siguran, tratarea defeciunilor hardware, respectiv software, refacerea bazei de date n caz de incident, modificarea i reorganizarea bazei de date.5.Persoane.n mediul SGBD se identific patru tipuri distincte de persoane implicate: administratorii, proiectanii, programatorii de aplicaie i utilizatorii finali. Proiectanii bazei de datesunt persoanele implicate n proiectarea logic i cea fizic a bazei de date. Proiectarea conceptual i logic presupune identificarea entitilor, a relaiilor dintre entiti, a constrngerilor asupra datelor ce vor fi stocate n baza de date. Proiectarea conceptual este independent de detaliile privind implementarea, iar proiectarea logic este presupune utilizarea unui model de date.Proiectantul de baz de date fizicepreia modelul logic de date i l implementeaz folosind un anumit SGBD, el alege strategia de stocare adecvat innd cont de modul de utilizare. Programatorii de aplicaierealizeaz i implementeaz programele de aplicaie care confer funcionalitatea cerut de utilizatorii finali. Programele de aplicaie se realizeaz n conformitate cu documentaia elaborat n etapa de proiectare. Fiecare program de aplicaie este realizat fie cu ajutorul unu limbaj de programare: Java, C++, C#, Php . . . sau cu unul propriu SGBD (Oracle PL/SQL, MS SQL Server Tranzact SQL, Postgres SQL PgSQL, MySQL) i efectueaz o anumit operaie asupra bazei de date: extragere, inserare, reactualizare i tergere de date. Administratorul Bazei de date (DBA Administrator):Administratorul are acces deplin la toate funcionalitile sistemului, fiiere i baze de date aferente sistemului, la echipamente i aplicaiile sau care asigur securitatea datelor.Responsabilitile Administratorului sunt: Stabilirea strategiei de asigurare a integritii bazei de date (execuia de copii, de backup i refacere a bazei de date n caz de deteriorare a ei) Administrarea performanelor bazei de date care pot implica adaptarea i reconfigurarea bazei de date n cazul unor cerine noi privind funcionalitatea, performanele, sigurana, protecia i confidenialitatea datelor. Definirea utilizatorilor i a nivelelor de acces la baza de date. Planificarea, coordonarea i implementarea msurilor de securitate i confidenialitate a datelor. ntreinerea bazei de date i a SGBD-ului. Administrarea serverului WEB de aplicaii prin intermediul crui se presteaz serviciile. Utilizatorii finalireprezint clienii bazei de date i pot fi grupai n dou categorii: utilizatori simpli i utilizatori specialiti. Utilizatorii simplinu percep baza de date i nici SGBD ci doar acceseaz baza de date prin intermediul programelor de aplicaie. Utilizatorii specialiticunosc structura bazei de date i facilitile oferite de SGBD. Ei sunt capabil s efectueze instantaneu interogri ale bazei de date, pentru aceasta folosind fie un limbaj extern, fie unul intern al SGBD pentru a efectua anumite operaii asupra bazei de date, fiind capabili s realizeze chiar propriile programe de aplicaie.

Proiectarea bazei de dateMetodologia proiectarii bazelor de dateDefinitie:Metodologie de proiectare:O aproximare structurata, care utilizeaza proceduri, tehnici, instrumente si documentatii pentru a facilita procesul de proiectare.Metodologia de proiectare se compune din etape, care la rndul lor se compun din pasi, care orienteaza proiectantul la fiecare nivel al crearii bazei de date.Proiectarea logica si fizica a bazei de dateDefinitie:Proiectare logica:Procesul de constructie a unui model de informatii folosite n tr-o ntreprindere, bazata pe modelul de date, dar independent de particularizarile sistemului de gestiune a bazei de date si a altor considerente fizice.Proiectarea logica ncepe cu crearea modelului conceptual al bazei de date, care este independent de implementarea ntr-un SGBD. Modelul conceptual este apoi proiectat pe un model logic, care va influenta mai trziu modelul de date n care se va implementa.Definitie:Proiectare fizica:Este procesul de descriere a implementarii bazei de date ntr-un SGBD.n aceasta etapa a proiectarii este creata baza de date ntr-un SGBD, mpreuna cu procedurile de actualizare. n aceasta etapa exista un feedback ntre proiectarea fizica si cea logica, pentru ca deciziile luate la implementarea fizica pot afecta baza de date logice.Proiectarea logica a bazei de date se divide n trei pasi mari:1. descompunerea proiectarii sistemului informatic n vederi, care se pot discuta cu utilizatorii sistemului. 2. Modelul de date astfel creat, se valideaza prin normalizare si prin tranzactii3. Se genereaza modelul global al ntreprinderii, cars este la rndul lui validat si verificat cu ajutorul utilizatorului sistemului.Factori critici pentru succesul proiectarii logice: Lucrul interactiv cu utilizatorul sistemului. Folosirea unei metodologii structurate pentru procesul de proiectare a bazei de date. ncorporarea regulilor de integritate n modelul logic de date. Combinarea validarii conceptuale, prin normalizare si prin tranzactii, la proiectarea modelului logic de baze de date. Utilizarea diagramelor pentru a reprezenta ct mai multe modele logice posibile. Crearea dictionarului de date, ca supliment al modelului de date.Crearea modelului logicPasul 1. Crearea modelului conceptual local, pentru utilizatori.Obiectivul:Crearea unui model conceptual local, pentru view-urile utilizatorilior.Primul pas n proiectarea bazei de date este de a colecta datele necesare pentru realizarea sistemului, ceea ce putem culege, discutnd cu viitorii tilizatori ai bazei de date. Acrasta discutie presupune o despartire n vederi, a bazei de date, vederi care pot lucra separat.Despartirea n vederi se poate realiza n mai multe moduri. O modaliate ar fi analiza datelor globale si gasirea de parti relativ independente. O alta modalitate ar fii analiza rapoartelor, procedurilor cerute si/sau observarea sistemului existent n lucru.Modelele conceptuale locale trebuie sa contina: tipuri de entitati, tipuri de relatii, atribute, domeniile atributelor, cheile candidat, chei primarePasii din prima etapa a proiectarii logice sunt:Pasul 1.1. Identificarea tipurilor de entitatiObiectivul:Identificarea tipurilor de entitati principale n vederile utilizatorilor.Primul pas n proiectarea bazei de date este identificarea entitatiilor din datele furnizate de utilizatori. De exemplu, daca avem informatiile Nr_Mat, Nr_Bloc, Scara, Etaj, Apartament si Nume, putem identifica entitatea Locatari. n general putem identifica entitatiile n mai multe moduri. De exemplu n locul entitatii Locatari, am putea crea o entitate Locatari cu atributele Nr_Mat si Nume, iar celelelte informatii n entitatea ProprietateLocatari.Documentarea tipurilor de entitatiDupa identificarea entitatiilor, le dam cte un nume, iar aceste nume le vom evidentia n dictionarul de date, mpreuna cu explicatiile despre entitati, precum si posibilele aliasuri.Pasul 1.2.Identificarea tipurilor de relatiiObiectivul:Identificarea relatiilor importante dintre entitati.Dupa identificarea entitatiilor, va trebui sa identificam si relatiile importante dintre aceste entitati. Reletiile se descriu printr-un verb al relatiei. De exemplu: FurnizoriiVnd Produse; Produsele sunt Comandate de Clieni La identificarea relatiilor vom lua n considerare doar relatiile care ne intereseaza. Degeaba exista si alte relatii care sa se poata identificate, daca nu prezinta importanta pentru problema noastra, atunci nu le luam n consideratie.n cele mai multe din cazuri, relatiile sunt binare, adica se realizeaza ntrea exact doua entitati. Exista si relatii mai complexe, care se realizeaza ntre mai multe entitati, sau relatii recursive, care pune n relatie o singura entitate cu ea nsasi.Determinarea cardinalitatii si a participarii la tipurile de relatiiDupa identificarea tipurilor de relatii, trebuie sa determinam cardinalitatea lor, alegnd dintre posibilitatiile: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Daca se cunosc valori specifice ale cardinalitatiilor, aceste valori se scriu la documentarea relatiilor. n continuare determinam si participarea la relatie, care poate fii totala, sau partiala.Documentarea tipurilor de relatiiDupa identificarea tipurilor de relatii, le denumim si le introducem n dictionarul de date, mpreuna cu cardinalitatea si participarea lor.Utilizarea modelarii ERPentru vizualizarea sistemelor complicate, utilizam diagrama ER, pentru ca este mult mai usor de a cuprinde toate informatiile. Pasul 1.3. Identificarea si asocierea de atribute la tipurile de entitati si tipurile de relatiiObiectivul:Asocierea de atribute la tipurile de entitati si la tipurile de relatii.Urmatorul pas n metodologie este identificarea atributelor. Aceste atribute se identifica n aceeasi mod ca si entitatiile. Pentru o mai usoara identificare, trebuie sa luam entitatiile si relatiile ra rnd si sa ne punem urmatoarea ntrebare:Ce informatii detinem despre aceasta . ?Raspunsul la aceasta ntrebare ne va da atributele cautate.Atribute simple sau compuseEste important sa notam daca un atribut este simplu sau compus. Conform acestei informatii va trebui sa luam decizii referitoare la acel atribut. Daca un atribut este compus, atunci putem opta pentru descompunerea sa, daca este necesara prelucrarea separata a detelor compuse, sau putem sa-l lasam compus n caz contrar.De exemplu, atributul Adresa contine informatiile (Raion, Localitate, Strada, Bloc, Apartament). Noi va trebui sa prelucram aceste informatii separat, deci vom descompune acest atribut n cele patru atribute simple.Putem avea cazuri n care atributele simple sa le compunem. De exemplu n cazul atributelor Nume_Familie si Prenume, neavnd nevoie de aceste informatii separat, le vom compune n atributul Nume.Atribute derivate (calculate)Sunt acele atribute, care se pot calcula din alte atribute existente n baza de date. De exemplu numarul locatarilor de pe o scara se poate numara n tipul de entitate Locatari. Deci acest atribut este atribut derivat.n general aceste atribute nu trebuie incluse n modelul de date, pentru ca n cazul n care se modifica atributul din care se calculeaza atributul derivat, trebuie sa se modifice si acesta. n cazul n care nu se modifica, baza de date devine inconsistenta. De aceea este important de a mentiona daca un atribut este sau nu derivat.Daca identificam un atribut care sa nu-l putem asocia nici unei entitati sau relatii, ne ntoarcem la pasii anteriori, identificnd noua relatie sau entitate la care sa asociem atributul respectiv.n cazul n care putem asocia acelasi atribut la mai multe entitati, atunci va trebui sa decidem daca generalizam sau nu aceste entitati, proces care este descris la pasul 1.6.Documentarea atributelorDupa identificarea atributelor, le asociem un nume, si le nregistram n dictionarul de date, mpreuna cu urmatoarele informatii: numele si descrierea atributului, toate aliasurile si sinonimele prin care este cunoscut atributul, tipul de date si lungimea, valorile initiale ale atributelor (daca exista), daca atributul accepta sau nu valoarea nula, daca atributul este sau nu compus, si daca este atunci atributele simple care l compun, daca atributul este sau nu derivat si atributul din care deriva, daca atributul accepta sau nu mai multe valori.Pasul 1.2.Determinarea domeniului atributelorObiectivul:Determinarea domeniului atributelor n modelul conceptual local.Domeniul atributului este o multime de valori pe care o poate lua. Pentru a controla n totalitate domeniul atributelor, se poate evidentia urmatoarele: setul de valori admisibile pentru un atribut, operatiile admisibile asupra unui atribut, ce atribute se pot compara cu atributul respectiv, n combinatiile cu alte atribute, marimea si formatul cmpului atributului.Documentarea domeniilor atributelorActualizam dictionarul de date cu domeniul de definitie al fiecarui atribut.Pasul 1.5. Determinarea atributelor care compun cheile candidat si primareObiectivul:Identificarea cheilor candidat pentru fiecare entitate si alegerea cheilor primare n cazul n care sunt mai multe chei candidat.Identificarea cheilor si selectarea cheilor primarePutem identifica una, sau mai multe chei candidat. n acest caz trebuie sa alegem dintre ele o cheie primara. Cheile candidat care nu sunt primare, se vor numi chei alternante. Pentru alegerea unei chei ca fiind cheie primara, vom tine cont de urmatoarele: cheia candidat, care are un numar minim de atribute, cheia candidat, care si va schimba cel mai rar valoarea, cheia candidat, care este cel mai putin probabil sa sufere modificari n viitor, cheia candidat, care este compusa din cele mai putine caractere (n cazul atributelor de tip caracter), cheia candidat, care este cel mai usor de folosit din punctul de vedere al utilizatorului.Prin procesul de identificare a cheilor primare, deducem si daca o entitate este entitate "tare", sau entitate "slaba". Daca reusim sa identificam o cheie primara, atunci entitatea este tare, altfel este slaba. O entitate slaba nu poate exista fara o entitate tare, care sa-i fie "parinte". Cheia primara a entitatii slabe este derivata partial sau total din cheia primara a entitatii tari.Documentarea cheilor primare si alternantenscriem cheile primare si pe cele alternante n dictionarul de date.Pasul 1.6. Desenarea diagramei ER.Obiectivul:Desenarea unei diagrame ER. care va fi reprezentarea conceptuala a vederilor utilizatorilor despre ntreprindere.Pasul 1.7. Verificarea modelului conceptual local cu ajutorul utilizatoruluiObiectivul:Verificarea modelului conceptual local cu ajutorul utilizatorului, pentru a vedea daca modelul este o reprezentare adevarata a vederii utilizatorului despre ntreprindere.n cazul n care apare orice fel de anomalie, repetam procesul de mai nainte si remediem problema.Pasul 2. Crearea si validarea modelului logic localObiectivul:Crearea unui model logic local bazata pe modelul conceptual al utilizatorilor asupra ntreprinderii si validarea ei prin procesul de normalizare si prin tehnica tranzactiilor cerute.n acest pas verificam modelul conceptual creat n pasul anterior si eliminam din el structurile care sunt dificil de realizat ntr-un SGBD. Daca la sfrsitul acestui proces modelul ete alterat, vom corecta aceste probleme si ne vom referi n continuare la modelul rezultat, ca fiind modelul logic local. Vom valida modelul logic prin procesul de normalizare si a tranzactiilor.Pasul2.1.Proiectarea modelului conceptual local pe modelul logic localObiectivul:Verificarea modelului conceptual local pentru eliminarea structurilor care se pot implementa greu ntr-un SGBD si proiectarea modelului rezultat la modelul logic local.Acest model trebuie prelucrat, pentru a putea fi usor de prelucrat de sistemul de gestiune a bazelor de date. Obiectivele acestui pas sunt: Eliminarea relatiilor M:N.Daca n modelul de date apar relatii de tipul multe-la-multe (M:N), trebuie descompuse n doua relatii unu-la-multe (1:M) prin adaugarea unei noi entitati suplimentare. Aceasta relatie se poate elimina, prin crearea unui tip de entitate suplimentar. Eliminarea relatiilor complexeO relatie complexa este o relatie ntre mai mult de coua tipuri de entitati. Daca n modelul conceptual apar relatii complexe, acestea trebuie eliminate. Se pot elimina prin crearea unui nou tip de entitate, care sa fie n relatie de tipul 1:M cu fiecare tip de entitate din relatia initiala, partea cu M a relatiei fiind spre tipul de entitate nou creat. Eliminarea relatiilor recursiveRelatiile recursive sunt niste relatii particulare, prin care un tip de entitate este n relatie cu el nsusi. Daca apare o astfel de relatie n modelul conceptual, ea trebuie eliminata. Eliminarea se poate rezolva prin crearea unei noi entitati unde sa se evidentieze fiecare entitate care este legata de entitatea din tipul de entitate initial. n acest caz vom avea o relatie de tipul 1:M ntre tipul de entitate initial si tipul de entitate nou creat si o relatie de tipul 1:1 ntre tipul de entitate nou creat si tipul de entitate initial. Eliminarea relatiilor cu atributeDaca n modelul conceptual avem relatie cu atribute, putem descompune aceasta relatie, identificnd un nou tip de entitate n care sa nregistram atributele necesare. Reexaminarea relatiilor de tipul 1:1n modelul conceptual putem avea entitati ntre care sa avem relatie detipul 1:1. Se poate ntmpla ca aceste entitati sa fie de fapt aceeasi entitate cu nume diferite. Daca suntem n acest caz, unim cele doua entitati, cheia primara devenind cheia primara al uneia dintre entitati. Eliminarea relatiilor redundanteO relatie este redundanta daca se poate ajunge de la un tip de entitate la alt tip de entitate pe mai multe drumuri.n finalul acestui pas putem spune ca am eliminat din modelul conceptual acele structuri care sunt dificil de implementat si deci este mai corect ca n continuare sa ne referim la acest model ca fiind unmodel logic local de date.Pasul2.2.Crearea de relatii peste modelul logic localRelatia pe care un tip de entitate o are cu alt tip de entitate este reprezentata prin mecanismul cheie primara/cheie straina. Cheia straina pentru o entitate este reproducerea cheii primare a altei entitati. Pentru a decide entitatiile unde vom include copia cheii primare a altei entitati, trebuie nainte sa identificam entitatile "parinte" si "fiu". Entitatile "parinte" se refera la acele entitati ale caror chei primare se vor copia n entitatile "fiu".Pentru descrierea relatiilor vom folosi un limbaj de definire a bazei de date (Database Definition Language - DDL). n acest limbaj, specificam prima data numele entitatii, urmat de atributele asociate ntre paranteze. Dupa aceea identificam cheia primara si toate cheile alternante, precum si/sau cheile straine.Tipuri de entitati tariPentru tipurile de entitati tari n modelul logic crearea unei relatii include toate atributele entitatii. Pentru atributele compuse al unei entitati, vom include numai atributele simple din compunerea atributului compus n descrierea entitatii.Tipurile de entitati slabeDescrierea tipurilor de entitati slabe se face la fel ca si tipurile de entitati tari, cu o completare si anume, evidentierea cheii straine. Mentionam ca n cazul acesta cheia straina este si n compunerea chei primare. Deci nainte de introducerea cheii straine, cheia primara nu identifica unic o entitate. La terminarea acestui pas, putem identifica cheile prinare pentru toate tipurile de entitati din modelul logic.Tipurile de relatii binare de tipul unu-la-unu (1:1)Pentru fiecare tip de relatie binara de tipul 1:1 ntre doua tipuri de entitate E1 si E2 gasim o copie a cheii primare a tipului de entitate E1 n compunerea tipului de entitate E2, sub denumirea de cheie straina. Identificarea tipului de entitate "parinte" si a tipului de entitate "fiu" depinde de participarea entitatilor la relatie. Tipul de entitate care participa partial la relatie este desemnat ca fiind "parinte" iar cel cu participare totala "fiu". Daca ambele tipuri de entitate participa partial sau total la relatie, atunci tipurile de entitati se pot evidentia ca fiind "parinte" sau "fiu" arbitrar. n cazul n care participarea este totala, putem ncerca sa combinam cele doua tipuri de entitati ntr-una singura. Aceasta compunere poate sa fie posibila n cazul n care nici unul dintre cele doua tipuri de entitati nu mai ia parte la alta relatie.Tipurile de relatii binare de tipul unu-la-multe 1:MPentru toate relatiile 1:M ntre doua entitati E1 si E2 n modelul logic de date, vom avea copia cheii primare a entitatii E1 n compunerea entitatii E2. Totdeauna entitatea de partea unu a relatiei este considerata entitate "parinte", iar cealalta entitate "fiu".Atributele cu mai multe valoriPentru ficarea atribut A care permite mai multe valori din entitatea E1 n modelul logic de date, cream o noua relatie care va contine atributul A mpreuna cu cheia primara a entitatii E1 pe post de cheie straina. Cheia primara a noii relatii va fi atributul A, sau daca este necesar, compunerea ei cu cheia primara al lui E1.Documentarea relatiilor si a atributelor din cheile straineActualizam dictionarul de date, ntroducnd fiacare atribut nou introdus n compunerea unei chei la acest pas.Pasul2.3.Validarea, utiliznd normalizareaExaminam procesul de normalizare.Prin normalizare trebuie sa demonstram ca modelul creat este consistent, contine redundanta minimala si are stabilitate maxima.Normalizarea produce o baza de date care va fi usor extensibila n viitor.Pasul2.4.Validarea modelului prin tranzactiiObiectivul:Verificarea ca modelul de date suporte toate tranzactiile cerute de utilizator.n acest pas se valideaza baza de date prin verificarea tranzactiilor ce se cer de catre utilizator. Lund n considerare tipurile de entitati, relatiile, cheile primare si straine, ncercam sa rezolvam manual cerintele utilizatorilor. Daca reusim sa rezolvam fiecare tranzactie ceruta, atuci nseamna ca modelul creat este valid. Daca nu putem rezolva o tranzactie, atunci este foarte posibil sa fi omis un atribut, o relatie, sau o entitate din modelul de date.Pasul2.5. Desenarea diagramei ER.Pasul2.6.Identificarea regulilor de integritate.Regulile de integritate sunt importante pentru a proteja baza de date mpotriva posibilelor inconsistente. Daca este necesar, putem produce un proiect fizic de baza de date, pentru a putea vedea mai usor ce reguli sunt necesare.Vom considera cinci tipuri de reguli de integritate: Necesitatea datelorExista atribute care nu pot contine valoarea nula, ci trebuie sa aiba totdeauna o valoare. Reguli asupra domeniului atributelor.Unele atribute au un domeniu de definitie bine definit. Aceste domenii trebuie respectate. Domeniile de definitie au fost deja identificate cnd am documentat domeniile atributelor n pasul 1.2. Integritatea entitatilor.Cheia primara a entitatilor nu poate lua valori nule. De exemplu fiecare furnizor trebuie sa aiba un cod diferit de zero. Integritatea referintelorCheia straina din tipul de entitate "fiu" face ligatura cu o entitate din tipul de entitate "parinte". Deci, daca cheia straina contine o valoare, ea trebuie neaparat sa se regaseasca si n tipul de entitate "parinte". De exemplu tipul de entitate Cheltuieli contine cheia straina Cod_furnizor, care se refera la Furnizori(Cod_furnizor). Daca aceasta cheie nu este nula, atunci trebuie sa gasim un furnizor care sa aiba acel cod.Prima ntrebare pe care trebuie sa ne-o ponem este: Poate fii cheia straina nula? n cazul exemplului nostru asta ar nsemna ca exista cheltuieli care nu se pratesc nimanui. Aceste cazuri nu sunt admise de lege, deci nu putem avea valoare nula n cheia straina din tipul de entitate Cheltuieli.n general daca pariciparea tipului de entitate "fiu" este totala, atunci nu putem avea valoare nula n cheia straina. n caz contrar putem avea valoare nula.Pentru a demonstra diferitele cazuri la definirea acestor reguli, folosim relatia de mai sus dintre Furnizori si Cheltuieli, care este de tipul 1:M. Consideram urmatoarele cazuri:Cazul 1: Inserarea unei entitati n tipul de entitate "fiu" (Cheltuieli):Pentru a verifica integritatea referintei, verificam daca atributele din componenta cheii straine (Cod_furnizor) sunt vide, sau sa existe entitate n tipul de entitate "parinte" care sa aiba valoare cheii primare egala cu valoare cheii straine.Cazul 2: stergerea unei entitati din tipul de entitate "fiu" (Cheltuieli):stergerea unei entitati din tipul de entitate "fiu" nu creeaza probleme la integritatea referintelor.Cazul 3: Actualizarea cheii straine n tipul de entitate "fiu" (Cheltuieli):Acest caz este similar caz. 1.Cazul 4: Stergerea unei entitati din tipul de entitate "parinte" (Furnizori):Daca se sterge o entitate din tipul de entitate "parinte", integritatea referintelor se strica n cazul n care exista entitati n tipul de entitate "fiu", care se refera la entitatea stearsa. Exista strategii severe de a rezolva integritatea referintelor:FR ACIUNENeacceptarea stergerii unei entitati din tipul de entitate parinte, daca acesta este referit de o entitate din tipul de entitate fiu. n cazul nostru, nu se accepta stergerea furnizorului, daca el are o factura de ncasat.CASCADDaca o entitate din tipul de entitate parinte este stearsa, se sterg automat toate entitatiile din tipurile de entitati fiu. Daca tipurile de entitati fiu au si ei la rndul lor alte tipuri de entitati fiu, se va efectua stergerea n cascada n toate tipurile de entitati fiu, pna la ultimul nivel. Cu alte cuvinte, daca se sterge un furnizor, atunci automat se sterge fiacare factura pe carea are de ncasat acest furnizor.SETARE LA NULLDaca o entitate din tipul de entitate parinte se sterge, atunci se vor seta la valoare nula toate cheile straine ai tipurilor de entitati fiu n cascada pna la ultimul nivel. n exemplul nortru, daca se sterge un furnizor, atunci se vor seta la valoare nula toate referintele la acest furnizor n tipul de entitate Cheltuieli. Acesta nseamna ca nu vom stii ca anumite cheltuieli la ce furnizor trebuie platite.SETARE IMPLICITEste analog cazului de setare la nul, cu diferenta ca aici se seteaza cheia straina la o valoare implicita n loc de valoare nula. n exemplul nostru putem seta cheia straina din Cheltuieli la o valoare a cheii primare din Furnizori, care sa contina un furnizor predefinit - de exemplu cu numele de "Furnizor sters".FR MODIFICAREn cazul stergerii unei entitati din tipul de antitate parinte, nu se actualizeaza deloc cheile straine din tipurile de entitati fiu.Cazul 6: Modificarea cheii primare n tipul de entitate parinte (Furnizori):Daca se modifica cheia primara din tipul de entitate parinte, integritatea referintelor se strica. Pentru mentinerea integritatii, se pot folosii toate cazurile descrise mai sus, dar cel mai indicat este folosirea cazului CASCAD.Regulile ntreprinderii.n final evidentiem acele reguli care sunt date de realitatea ce se va modela n baza de date.Documentarea tuturor regulilor de integritate.Trecem toate regulile de integritate n dictionarul de date.Pasul2.7.Verificarea modelului logic local cu ajutorul utilizatorului.Obiectivul:Convingerea ca modelul creat reprezinta n totalitate realitatea care trebuie modelata n baza de date.La acest pas modelul local logic este complet si este bine documentat. nainte de a trece la pasul 3, trebuie verificat modelul, sa fie conform cu realitatea. n cazul n care se gasesc diferente, ne vom rentoarce la pasii anteriori si modificam cele necasare.Pasul3.Crearea si validarea modelului global logic de date.Obiectivul:Combinarea modelelor locale logice ntr-un model logic global care sa reprezinte ntreprinderea care este modelata.A treia activitate majora n proiectarea bazei de date logice este crearea modelului logic global, prin compunerea tuturor modelelor locale. Dupa combinarea modelelor locale, trebuie validat modelul global prin tehnica de normalizare si dupa aceea, prin tehnica tranzactiilor. Acest proces utilizeaza aceleasi tehnici pe care le-am descris la pasii 2.3. si 2.2.Acest proces este foarte important n proiectarea bazei de date, pentru ca el demonstreaza ca reprezentarea ntreprinderii este independenta de orice utilizator, functie sau aplicatie. Activitatile din acest pas sunt:Pasul3.1.Compunerea modelelor logice locale ntr-un model logic global.n cazul unui sistem mic, cu putine vederi ai utilizatorilor, este relativ usor de a compune modelele logice locale. n cazul unui sistem mai mare nsa, trebuie sa urmam un proces sistematic de realizare a modelului global. Pasii acestui proces sunt urmatoarele: Verificarea numelor entitatilor si a cheilor lor primare.Aceasta verificare se face folosind si dictionarul creat n decursul pasilor de dinainte. Probleme apar doar atunci cnd: Doua entitati au acelasi nume, dar sunt de fapt diferiti. Doua entitati sunt aceleasi, dar nu au aceleasi nume.Probabil va fi necesara analizarea atributelor antitatilor, prntru a rezola aceasta problema. n particular, putem utiliza cheia primara si numele entitatii, pentru a identifica entitatile echivalente. Verificarea numelor relatiilor (ca i la entitati). Compunerea entitatilor de pe view-urile locale.Examinam numele si atributele entitatilor ca vor fi compuse. Activitatile care se includ n acest pas sunt: Compunerea entitatilor care au aceleasi nume si aceleasi chei primare.n general entitatile cu aceleasi chei primare reprezinta "lumea reala", si deci pot fi compuse. Atributele care apar n entitatile de pe ambele view-uri, vor fi trecute doar o singura data. Daca ntr-un view apare un atribut compus, iar ntr-un alt view acelasi atribut dar descompus n atribute simple, atunci vom ntreba, daca se poate, utilizatorii pentru a decide asupra formei de utilizare a atributului. Compunerea entitatilor care au aceleasi nume, dar au chei primare diferite.n astfel de situatii, cautam doua entitati care au aceleasi nume si nu au aceleasi chei primare, dar au aceleasi chei candidat. Cele doua entitati pot fi compuse, urmnd ca dupa compunere sa alegem o cheie primara, restul ramannd chei alternante. Compunerea entitatilor care nu au nume comune si nu au aceleasi chei primare.Aceste entitati se pot depista prin analiza atributelor celor doua entitati. Includerea (fara compunere) a entitatilor care apar doar ntr-un view. Compunerea relatiilor de pe modelele locale.n acest pas analizam similitudinile dintre relatii de pe diferite modele locale. n timpul compunerii relatiilor trebuie rezolvate si conflictele dintre relatii, ca si regulile de cardinalitate si participare. Putem compune relatii care au aceleasi nume si acelasi scop, sau acelasi scop, dar nume diferite. Includerea (fara compunere) a relatiilor care apar doar pe un view.Relatile care au ramas neincluse n modelul global dupa pasul anterior, se includ n modelul global fara modificare. Cautarea entitatilor si relatilor care lipsesc.Este unul din cei mai grei pasi din crearea modelului global. Trebuie cautate acele entitati si relatii, care s-au omis la pasii anteriori si n-au ajuns n modelul global. Cautarea cheilor straine.n decursul pasilor anterioare, s-au modificat entitati, chei primare si chei straine. n acest pas verificam daca cheile straine sunt corecte n fiecare entitate fiu si efectuam toate modificarile necesare. Cautarea regulilor de integritateVerificam daca regulile de integritate a modelului global nu sunt n conflict cu regulile definite la modelele locale. Fiecare problema de acest gen se rezolva cu ajutorul utilizatorului sistemului. Desenarea diagramei ER.Acum desenam diagrama ER pentru modelul global de date. Actualizarea documentatiei.Actualizam documentatia, ca sa reflecte toate modificarile aduse n acest pas modelului.

Pasul 3.2. Validarea modelului logic global.Obiectivul:Validarea modelului global logic de date, folosind normalizarea, dupa care folosind tranzactile cerute.Acest pas este schivalent cu pasii2.3. si2.4., unde am validat modelul local de date.Pasul 3.3. Verificarea posibilitatilor de extindere a bazei de date n viitor.Obiectivul:Determinarea ca daca modelul se acomodeaza usor la modificari orict de mari ce pot intervenii n viitor.Este important ca modelul creat sa fie expansibil n viitor. Daca modelul nu are aceasta calitate, viata lui poate fi scurta si pentru o mai mare modificare va trebui refacuta de la nceput.Pasul 3.4.Desenarea diagramei Entitz-Relationship finale.Obiectivul:Desenarea unei diagrame ER, care sa reprezinte modelul global de date al ntreprinderii.Pasul 3.5. Verificarea modelului global cu ajutorul utilizatorului.Obiectivul:Verificarea ca modelul global reprezinta n totalitate realitatea.n acest moment modelul global este complet si documentat. mpreuna cu utilizatorul sistemului se verifica acest model si se aduc eventualele corecturi prin ntoarcerea la pasii n cauza.

6