Proiectarea si gestionarea bazelor de date

Note 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 nu fie 'vizibile' la nivelul de organizare imediat superior).
Asigurarea unei redundante minime i controlate a datelor din baza de date

Proiectarea si gestionarea bazelor de date

Note

de curs
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 dup incidente.
Asigurarea partajabilitii datelor.
Partajabilitatea datelor trebuie neleas i subaspectul posibilitii dezvoltrii unor
aplicaii fr a se modifica structura bazei de date.

Proiectarea si gestionarea bazelor de date

Note

de curs

Tipuri de baze de date

Ierarhic
Toate 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 reea
Un 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 unala 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.

Proiectarea si gestionarea bazelor de date

Note

de curs
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

Proiectarea si gestionarea bazelor de date

Note

de curs
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.
5

Proiectarea si gestionarea bazelor de date

Note

de curs
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.

Atribute
Definiie: Atribute: Proprietaile unui tip de entitate sau de relaie.
Definiie: Domeniul atributului: Un set de valori ce se pot da acelui atribut.
Domeniul unui atribut nu se poate definii totdeauna foarte exact. De exemplu, atributul
nume de familie poate lua orice nume de familie existent. Evident, acest atribut trebuie
s fie un ir de caractere, dar oare ce caractere poate s conin? Unele domenii se pot
descompune n mai multe subdomenii. De exemplu data naterii se poate descompune
in subdomeniile: an, lun, zi.
Atributele se pot clasifica n simple sau compuse; cu o singur valoare sau cu mai
multe valori; respectiv derivate.
Definiie: Atribut simplu: Atribut care are doar o singur component i o
existen independent.
Aceste atribute nu se pot diviza mai trziu n mai multe atribute distincte.
Definiie: Atribut compus: Atribut care are mai multe componente i o existen
independent.
Aceste atribute se pot diviza n mai multe atribute simple. De exemplu atributul adres
se poate descompune n atributele: strada, numr, ora, cod potal i jude. Decizia ca
un atribut compus s se descompun n mai multe atribute simple este dependent de
modul n care se va utiliza acel atribut: separat pe componente, sau ntregul atribut.
Definiie: Atribut cu o singur valoare: Atribut care poate lua o singur valoare
pentru fiecare entitate.
Majoritatea atributelor sunt atribute cu o singur valoare, ceea ce este indicat n
proiectarea bazelor de date.
Definiie: Atribut cu mai multe valori: Atribut care poate lua mai multe valori
pentru fiecare entitate.
Atributele cu mai multe valori, trebuie s aib totdeauna o limit inferioar i una
superioar.

Proiectarea si gestionarea bazelor de date

Note

de curs
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.
7

Proiectarea si gestionarea bazelor de date

Note

de curs
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 relaii
Definiie: 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 relaiilor
Atributele descrise mai sus, se pot asocia i relaiilor. Aceste atribute se reprezint
grafic, ca i atributele entitiilor, cu deosebirea c legtura nu este cu o entitate, ci cu o
relaie. Adic linia leag elipsa de rombul ce semnific relaia.

Structuralitatea
S analizm acum restriciile ce pot aprea la includerea unei entiti participante
ntr-o relaie. Avem dou tipuri mari de restricii: cardinalitatea i prticiparea.

Cardinalitatea
Definiie:
partricipant.

Cardinalul

este

numrul

relaiilor

posibile

pentru

entitate

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

Proiectarea si gestionarea bazelor de date

Note

de curs

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:1

1:M

M:M

Participarea
Definiie: Participarea determin dac existena unei entiti depinde sau nu de
relaia cu o alt entitate. Participarea poate fi de mai multe tipuri: total i parial. n
cazul participrii totale, toate entitiile particip n relaia dat. n caz contrar
participarea se numete parial.

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).

Proiectarea si gestionarea bazelor de date

Note

de curs
Funcia de manipulare a datelor este cea mai complex funcie i realizeaz
urmtoarele activiti:

crearea (ncrcarea) bazei de date;

adugarea de noi nregistrri;
tergerea unor nregistrri

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.

10

Proiectarea si gestionarea bazelor de date

Note

de curs

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 date sunt 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 fizice preia 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 aplicaie realizeaz i implementeaz programele de aplicaie
care confer funcionalitatea cerut de utilizatorii finali. Programele de aplicaie se
11

Proiectarea si gestionarea bazelor de date

Note

de curs

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 finali reprezint clienii bazei de date i pot fi grupai n dou categorii:
utilizatori simpli i utilizatori specialiti. Utilizatorii simpli nu percep baza de date i
nici SGBD ci doar acceseaz baza de date prin intermediul programelor de aplicaie.
Utilizatorii specialiti cunosc 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.

12

Proiectarea si gestionarea bazelor de date

Note

de curs

Proiectarea bazei de date

Metodologia proiectarii bazelor de date
Definitie: 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 date

Definitie: 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

13

Proiectarea si gestionarea bazelor de date

Note

de curs
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 tranzactii
3. 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 logic

Pasul 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 primare
Pasii din prima etapa a proiectarii logice sunt:

Pasul 1.1. Identificarea tipurilor de entitati

14

Proiectarea si gestionarea bazelor de date

Note

de curs
Obiectivul: 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 entitati
Dupa 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 relatii
Obiectivul: 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:
Furnizorii Vnd 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 relatii
Dupa 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 relatii
Dupa identificarea tipurilor de relatii, le denumim si le introducem n dictionarul
de date, mpreuna cu cardinalitatea si participarea lor.
Utilizarea modelarii ER
Pentru 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 relatii
Obiectivul: 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

15

Proiectarea si gestionarea bazelor de date

Note

de curs
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 compuse
Este 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 atributelor
Dupa 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 atributelor
Obiectivul: 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:
16

Proiectarea si gestionarea bazelor de date

Note

de curs

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 atributelor
Actualizam dictionarul de date cu domeniul de definitie al fiecarui atribut.

Pasul 1.5. Determinarea atributelor care compun cheile candidat si

primare
Obiectivul: Identificarea cheilor candidat pentru fiecare entitate si
alegerea cheilor primare n cazul n care sunt mai multe chei candidat.
Identificarea cheilor si selectarea cheilor primare
Putem 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 alternante
nscriem 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
utilizatorului
Obiectivul: 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.

17

Proiectarea si gestionarea bazelor de date

Note

de curs
Pasul 2. Crearea si validarea modelului logic local
Obiectivul: 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.
Pasul 2.1. Proiectarea modelului conceptual local pe modelul logic local
Obiectivul: Verificarea modelului conceptual local pentru eliminarea structurilor
care se pot implementa greu ntr-un SGBD 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 complexe
O 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 recursive

Relatiile 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 atribute

Daca 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:1

18

Proiectarea si gestionarea bazelor de date

Note

de curs
n modelul conceptual putem avea entitati ntre care sa avem relatie de
tipul
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 redundante
O 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 un model logic local de
date.

Pasul 2.2. Crearea de relatii peste modelul logic local

Relatia 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 tari
Pentru 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 slabe
Descrierea 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:M

19

Proiectarea si gestionarea bazelor de date

Note

de curs
Pentru 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 valori
Pentru 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 straine
Actualizam dictionarul de date, ntroducnd fiacare atribut nou introdus n
compunerea unei chei la acest pas.
Pasul 2.3. Validarea, utiliznd normalizarea
Examinam 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.
Pasul 2.4. Validarea modelului prin tranzactii
Obiectivul: 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.
Pasul 2.5. Desenarea diagramei ER.
Pasul 2.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 datelor

Exista atribute care nu pot contine valoarea nula, ci trebuie sa aiba totdeauna o
valoare.

Reguli asupra domeniului atributelor.

20

Proiectarea si gestionarea bazelor de date

Note

de curs
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 referintelor

Cheia 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 ACIUNE
Neacceptarea 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.
CASCAD
Daca 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
21

Proiectarea si gestionarea bazelor de date

Note

de curs
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 NULL
Daca 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 IMPLICIT Este 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 MODIFICARE n 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.
Pasul 2.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.
Pasul 3. 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

22

Proiectarea si gestionarea bazelor de date

Note

de curs
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:
Pasul 3.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
23

Proiectarea si gestionarea bazelor de date

Note

de curs
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 integritate

Verificam 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 pasii 2.3. si 2.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.

24

Proiectarea si gestionarea bazelor de date

Note

de curs
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.

25