-
Cap.1.Concepte
1
Cap. 1. Introducere n metodologia de proiectare a bazelor
de date
Atunci cnd se proiecteaz o baz de date se pune problema cum s
iei un sistem din
lumea real i s l transpui ntr-o baz de date. Acest lucru
presupune luarea unor decizii
precum ce tabele trebuie create, ce atribute vor conine, precum
i ce relatii trebuie s existe
ntre tabele. Dei ar fi foarte bine ca acest proces s fie unul
intuitiv sau automatizat, acest
lucru nu este posibil. O baz de date bine proiectat necesit timp
i efort pentru a o concepe,
construi sau rafina.
Avantajele unei baze de date bine concepute, pentru modelul
relaional sunt numeroase.
Printre acestea putem enumera:
Inserrile, modificrile i tergerile sunt efectuate efectuate
eficient Regsirea informaiei i rapoartele se obin intr-un timp
scurt ntruct informaiile se vor reine n baza de date i nu n
aplicaie, baza de date
trebuie s conina metadate
Modificrile n schema bazei de date se realizeaz cu uurin Scopul
acestui curs este de a explica principiile care stau la baza
proiectrii bazelor de
date i s prezentm cum trebuie acestea aplicate.
Pentru modelul relaional, tabelele reprezint obiecte din lumea
real. Fiecare tabel
reprezint un singur obiect. Aceste obiecte (sau entiti) pot fi
obiecte sau evenimente din
lumea real.
De exemplu, un obiect pentru lumea real poate reprezenta un
client, un articol de
inventar sau o factur. Pentru exemplele de evenimente putem
enumera, comenzi, convorbiri
telefonice, etc.
Fiecare din atributele care descriu obiectul trebuie s fie unic.
Dac s-ar accepta
duplicate, nu se va putea identifica unic prin programare. Acest
lucru ar duce la ambiguiti
probleme are trebuie evitate.
Unicitatea unui tabel se realizeaz prin desemnarea unei chei
primare un atribut care
conine o valoare unic. Fiecare relaie trebuie s aib doar o
singur cheie primar, chiar
-
ProiectareaBazelordeDate
2
dac exist i alte atribute cu valoare unic. Acestea (restul
atributelor cu valoare unic, sau o
combinaie a lor) formeaz cheile candidat.
Cheile pot fi simple sau compuse. O cheie simpl este format doar
dintr-un singur
atribut, iar cheile compuse din mai multe atribute. Decizia
privind care cheie candidat s
devin cheie primar este una subiectiv. Nu exist o regul
universal pentru alegerea ei. De
obicei se bazeaz pe principiul de minimalitate: se alege cheia
care cuprinde cele mai puine
atribute, care are cele mai puine anse s i modifice valoarea i
care este cea mai intuitiv
pentru utilizator.
S ilustrm cele prezentate printr-un exemplu: o campanie dorete s
i in evidena
clienilor:
Id_Client Nume Prenume Adresa Ora Jude Telefon
1 Popescu Paul Str. Teilor nr. 13 Bucureti Bucureti 02134553212
Georgescu George Str. Primverii, nr 7 Bucuresti Bucureti
02145544543 Ionescu Ion Str. Brestei, nr 15 Craiova Dolj
0351232433
Fig. 1.1 Exemplu de relaie. Cheia primar cea mai potrivit pentru
a fi aleas este Id_Client
Chei externe i domenii Dei cheile primare in doar de relaii
individuale (tabele independente), dac creezi
baze de date ale cror tabele nu au nici o legtur unul cu altul,
nu vor fi de un prea mare
folos. Cheile primare devin eseniale atunci cnd se creaz relaii
care unesc mai multe tabele
dintr-o baz de date.
O cheie extern este acel atribute dintr-un tabel care face
legtura cu un alt atribut
(dintr-un alt tabel).
S continum exemplul anterior cu un alt tabel, Comenzi, n care se
rein comenzile
pentru fiecare client n parte. (Figura 1.2).
n acest exemplu, ID_client este o cheie extern care face legtura
ntre tabelul Client i
tabelul Comenzi. Acest atribut este considerat cheie extern
ntruct prin el se poate face
referire la un anumit client din tabelul Clienti.
Este important ca att cheile externe ct i cheile primare
folosite, care se refer la
acelai obiect, s aib valori comune i s fie definite pe acelai
domeniu. Dac n exemplul
nostru chia extern Id_Client din tabelul Comenzi ar avea
valorile 1,1 i 4 atunci ar insemna
c n tabelul Clienti trebuie s existe i un client cu id-ul 4
(lucru care nu se ntmpl).
-
Cap.1.Concepte
3
Client
Id_Client Nume Prenume Adresa Ora Jude Telefon
1 Popescu Paul Str. Teilor nr. 13 Bucureti Bucureti 0213455321 2
Georgescu George Str. Primverii, nr 7 Bucuresti Bucureti 0214554454
3 Ionescu Ion Str. Brestei, nr 15 Craiova Dolj 0351232433
Comenzi
Id_Comand Id_Client Produs U.M. Pre_pltit
1 1 Unt Buc 1,3 2 1 Margarin Buc 1,5 3 2 Pine Buc 4
Fig. 1.2 Exemplu de relaie. Cheia primar cea mai potrivit pentru
a fi aleas este Id_Client
Relaii Rolul cheilor externe este acela de a modela relaii din
lumea real. Relaiile dintre entitile din lumea real pot fi foarte
complexe, implicnd mai multe entiti, fiecare din ele
avnd relaii cu mai multe entiti din tabele diferite. De exeplu,
o familie are relaii multiple
ntre mai muli membri, toate n acelai timp.
ntr-o baz de date relaional se consider doar relaii doar ntre
perechi de tabele
(Clieni Comenzi). Aceste tabele pot fi conectate unul cu altul
prin trei tipuri de relaii
diferite: 1:1, 1: m (1 la mai muli), m:m (mai muli la mai
muli).
Relaii 1:1 Dou tabele sunt conectate printr-o relaie 1:1 dac,
pentru fiecare nregistrare din prima
tabel exist cel mult o singur nregistrare n cea de-a doua tabel.
Acest tip de ralie apare
destul de rar n lumea real. Se folosete mai mult pentru a
elimina unele limitri ale
sistemului de gestiune a bazei de date dect pentru a modela un
obiect din lumea real.
Acest tip de relaie poate fi de exemplu util atunci cnd mprim un
tabel n dou tabele
diferite din motive de securitate sau performan.
De exemplu se pot ine toate datele legate de un client ntr-un
tabel, iar datele cu
caracter privat ntr-un altul (sex, cstorit/necstorit, venit,
etc). n felul acesta se poate
aplica o politic care s limiteze accesul la informaiile din cel
de-al doilea tabel, doar pentru
anumii utilizatori.
-
ProiectareaBazelordeDate
4
Ca un al doilea exemplu putem aminti cazul cnd avem un tabel
foarte complex cu zeci
de atribute, dintre care doar o parte din acestea se folosesc
frecvent. n acest caz ar fi util s
transferm o parte din date (cele mai puin utilizate) ntr-un alt
tabel.
Tabelele care formeaz o relatie 1:1 trebuie s aib totdeauna
aceeai cheie primar,
care va putea fi folosit n caz de nevoie pentru a face join ntre
ele.
Client
Id_Client Nume Prenume Funcie
1 Popescu Paul Inginer 2 Georgescu George Medic 3 Ionescu Ion
Aviator
Date personale
Id_Client Adres Localitate Venit Cstorit/Necstorit
1 Str. Teilor nr. 13 Bucureti 1500 NU 2 Str. Primverii, nr 7
Bucuresti 2000 DA 3 Str. Brestei, nr 15 Craiova 2000 DA
Fig. 1.3 Exemplu de relaie 1:1. Cheia primar este Id_Client
Relaii 1:m Dou tabele contin o relaie de tipul 1:m dac fiecrei
nregistrri din primul tabel ii
corespund zero, una sau mai multe nregistrri n cel de-al doilea,
dar fiecrei nregistrri din
cel de-al doilea tabel i corespunde exact o singur nregistrare
din primul tabel.
De exemplu la o pizzerie fiecare comand poate conine una sau mai
multe pizza. De
aceea tabelul Comanda este legat de tabelul DetaliiComand
printr-o relaie de tipul 1:m.
Comand
Id_Client Nume Prenume Data
1 Popescu Paul 23.10.1750 2 Georgescu George 05.11.19003 Ionescu
Ion 11.05.2007
DetaliiComand
Id_Client Id_pizza Cantitate Pre
1 Funghi 1 5,601 Romana 1 7,50 2 Marguerita 1 12,40
Fig. 1.4 Exemplu de relaie 1:m. Cheia primar pentru relaia
Comand este Id_Client, pentru relaia DetaliiComand este Id_Client
Id_pizza (cheie compus); Id_Client din relatia Detalii Comand este
i cheie extern
1:m
-
Cap.1.Concepte
5
Acest tip de relaie este cel mai ntlnit n lumea real.
Relaii m:m Dou tabele sunt conectate printr-o relaie de muli la
muli (m:m) atunci cnd pentru
fiecare nregistrare din primul tabel exist mai multe nregistrri
n cel de-al doilea tabel,
pentru fiecare nregistrare din cel de-al doilea tabel exist mai
multe nregistrri n primul
tabel.
Client
Id_Client Nume Prenume Companie
1 Popescu Paul Unita 1 Popescu Paul Unita 1 Popescu Paul
Omniasig 2 Georgescu George Omniasig 3 Ionescu Ion Aliantz
Tiriac
Companie
Id_Companie Companie Id_client Tip asigurare
1 Unita 1 RCA 1 Unita 1 CASCO2 Omniasig 1 Pensie2 Omniasig 2 RCA
3 Aliantz Tiriac 3 Pensie
Fig. 1.5 Exemplu de relaie m:m. Fiecare client este asigurat la
1 sau mai multe companii i fiecare companie are mai muli clieni
Acet tip de relaii prezint o problem. Ele nu pot fi modelate
direct prin programe,
fiind necesar s se separe n mai multe relaii de tipul 1:m.
Rspunsul este crearea celui de-al
treilea tabel, numit adesea tabel de jonciune, care separ relaia
mai-muli-la-mai-muli
n dou relaii unu-la-mai-muli. Inserai cheia primar a fiecruia
dintre cele dou tabele
n al treilea tabel.
Reguli de integritate Modelul relaional specific dou reguli
generale de integritate. Se numesc generale ntruct se aplic tuturor
bazelor de date. Acestea sunt: regula cheii primare i regula
referinei.
Condiia de integritate a cheii primare este simpl: cheia primar
nu poate conine
cmpuri nule (care lipsesc i au astfel valoarea nul). Motivul
acestei condiii este simplu: o
m:m
-
ProiectareaBazelordeDate
6
nregistrare care are cheia primar nul nu poate fi identificat n
mod unic. Aceast condiie
se aplic att cheilor simple ct i celor compuse. (la cheile
compuse, nici una din atributele
care o formeaz nu trebuie s aib valoarea null)
Regula referintei precizeaz c valoarea unei chei externe trebuie
s se regseasc
totdeauna printre valorile tabelului la care se refer. In figura
1.3, nu poate exista id_client = 1
n tabela Date Personale, dac aceasta nu se regsete i n tabela
Clieni.
Aceast condiie are urmtoarele implicaii:
O nregistrare nu poate fi adugat ntr-un tabel ce are definit o
cheie extern dac valoarea referit nu este deja adugat
Dac o valoare din tabel care este referit de o cheie extern este
modificat (sau ntreaga nregistrare este tears, cheile externe care
refer acea valoare trebuie i ele
modificate (terse)
Exist 3 opiuni posibile atunci cnd cheia primar care este
referiti modific
valoarea sau este ters:
Nu este permis o asemenea operaie Modificarea n cascad. Dac
valoarea este modificat, atunci toate cheile din
celelalte tabele care o refer vor fi i ele modificate. Dac cheia
este tears,
atunci toate inregistrrile care contin cheile ce refer acea
cheie, vor fi i ele
terse.
Proiectarea Bazelor de Date
Primul pas pentru proiectarea bazelor de date reprezint
determinarea scopului acesteia.
Este o idee bun s v notai scopul bazei de date, cum dorii s o
utilizai i cine o va
utiliza. Ideea principal este s se descrie riguros misiunea
bazei de date, care s fie consultat
n cadrul procesului de proiectare. O astfel de instruciune v
ajut s v concentrai asupra
obiectivelor atunci cnd luai decizii.
Gsirea i organizarea informaiilor necesare
Pentru a gsi i organiza informaiile necesare, ncepei cu
informaiile existente. De
exemplu, se pot nregistra comenzile de cumprare ntr-un registru
sau se pot ine informaii
despre clieni n formulare, ntr-un dulap pentru dosare. Colectai
aceste documente i trecei
n list fiecare tip de informaii afiate (de exemplu, fiecare
caset completat dintr-un
formular). Dac nu avei formulare existente, imaginai-v c trebuie
s proiectai un formular
-
Cap.1.Concepte
7
pentru a nregistra informaii despre clieni. Ce informaii ai dori
s punei n formular? Ce
casete de completat ai crea? Identificai i trecei n list toate
aceste elemente. De exemplu,
s presupunem c n prezent inei lista de clieni pe fie indexate.
Examinnd aceste fie vei
descoperi c fiecare fi conine numele, adresa, oraul, statul,
codul potal i numrul de
telefon ale unui client. Fiecare dintre aceste elemente poate
reprezenta o coloan din tabel.
Apoi, luai n considerare tipurile de rapoarte sau de liste
potale pe care dorii s le
obinei din baza de date. De exemplu, se poate crea un raport de
vnzri pentru un produs,
care afieaz vnzrile n funcie de regiune sau un raport de
rezumare a inventarului, care
afieaz nivelurile de inventar ale produselor. De asemenea, se
pot genera scrisori formale,
care li se vor trimite clienilor pentru a i anuna de evenimente
sau de oferte speciale.
Proiectai mintal raportul i imaginai-v cum ar arta. Ce informaii
ai dori s punei n
raport? Trecei fiecare element n list. Facei acelai lucru pentru
scrisoarea formal i pentru
orice alt raport pe care considerai c l vei crea.
Proiectarea mental a rapoartelor i a listelor potale pe care
dorii s le creai v ajut
la identificarea elementelor de care vei avea nevoie n baza de
date. De exemplu, s
presupunem c le oferii clienilor oportunitatea de a se abona
(sau a se dezabona) la
actualizri periodice prin pot electronic i c dorii s imprimai o
list a celor care s-au
abonat. Pentru a nregistra acele informaii, adugai o coloan
Abonat la mesaje de pot
electronic la tabelul pentru clieni. Pentru fiecare client, se
poate seta cmpul la Da sau la
Nu.
Necesitatea de a le trimite mesaje de pot electronic clienilor
sugereaz alt element
de nregistrat. Dup ce tii c un client dorete s primeasc mesaje
de pot electronic, va
trebui s aflai adresa de pot electronic la care s le trimitei.
Aadar, trebuie nregistrat o
adres de pot electronic pentru fiecare client.
Este logic s se construiasc un prototip al fiecrui raport sau
listare de ieire i s se ia
n considerare elementele necesare pentru a produce raportul. De
exemplu, cnd examinai o
scrisoare formal, se poate s v vin n minte alte idei. Pentru a
include o formul
introductiv corespunztoare de exemplu, irul "Dl.", "Dna." sau
"Dra." cu care ncepe o
formul de salut, va trebui creat un element pentru introducere.
De asemenea, este mai bine s
se nceap scrisorile cu Drag Dl. Georgescu, dect cu Drag Dl.
Florin Georgescu.
Aadar, de obicei este mai bine s se stocheze numele de familie
separat de prenume.
Trebuie s se in cont de faptul c informaiile trebuie desprite n
cele mai mici pri
utile. n cazul unui nume, pentru ca numele de familie s fie uor
disponibil, se va despri
numele n dou pri Nume i Prenume. Pentru a sorta un raport dup
numele de familie,
-
ProiectareaBazelordeDate
8
de exemplu, este util s se stocheze separat numele de familie
ale clienilor. n general, pentru
a sorta, cuta, celula sau raporta n funcie de un element
informaional, trebuie pus acel
element ntr-un cmp propriu.
Gndii-v la ntrebrile la care dorii s rspund baza de date. De
exemplu, cte
vnzri s-au finalizat pentru produsul principal? Unde locuiesc
cei mai importani clieni?
Cine este furnizorul produsului care se vinde cel mai bine?
Anticiparea acestor ntrebri c
ajut s v dai seama de elementele suplimentare care trebuie
nregistrate.
Ce reprezint o proiectare bun a unei baze de date?
Anumite principii ghideaz procesul de proiectare al unei baze de
date. Primul principiu
este acela c informaiile dublur (numite i date redundante) au o
influen negativ,
deoarece consum spaiu i sporesc probabilitatea producerii de
erori i inconsistene. Al
doilea principiu l reprezint importana corectitudinii i
caracterulul complet al informaiilor.
Dac baza de date conine informaii incorecte, orice rapoarte care
extrag informaii din baza
de date vor conine, de asemenea, informaii incorecte. Drept
urmare, orice decizie luat
bazndu-v pe aceste rapoarte va fi greit informat.
O proiectare bun a unei baze de date este, dup cum urmeaz, una
care:
mparte informaiile n tabele pe baza subiectelor, pentru a reduce
datele redundante.
Furnizeaz programului Access informaiile necesare pentru a
asocia informaiile din
tabele dup necesiti.
Asist i asigur acurateea i integritatea informaiilor.
Adapteaz necesitile de procesare a datelor i cele de
raportare.
Procesul de proiectare const n urmtorii pai:
Determinarea scopului bazei de date - Acesta ajut la pregtirea
pailor rmai. Gsirea i organizarea informaiilor necesare - Adunarea
tuturor tipurilor de
informaii pe care le nregistrai n baza de date, cum ar fi numele
produsului i
numrul comenzii.
mprirea informaiilor n tabele - mprirea elementelor de informaii
n entiti sau subiecte majore cum ar fi Produse sau Comenzi. Apoi,
fiecare subiect devine
un tabel.
Transformarea elementelor de informaii n coloane - Decidei ce
informaii s stocai n fiecare tabel. Fiecare element devine un cmp
care este afiat sub form
-
Cap.1.Concepte
9
de coloan n tabel. De exemplu, un tabel Angajai poate include
cmpuri, cum ar
fi Nume de familie i Data angajrii.
Specificarea cheilor primare - Alegei cheia primar pentru
fiecare tabel. Configurarea relaiilor din tabel - Privii fiecare
tabel i decidei cum se asociaz
datele dintr-un tabel cu datele din alte tabele. Adugai cmpuri
la tabele sau creai
noi tabele pentru a clarifica relaiile, dup necesiti.
Metodologia de proiectare, const ntr-o abordare structurat, n
care se utilizeaz
proceduri, tehnici, instrumente i documentaii, pentru a susine i
facilita procesul de
proiectare. O metodologie de proiectare const n mai multe faze,
coninnd etape care
ndruma proiectantul n alegerea tehnicilor adecvate fiecrei etape
a proiectului; de asemenea
l ajuta la: planificare, administrare, control i evaluarea
proiectelor de dezvoltare a bazelor de
date. n final are loc o abordare structurat de analiz i modelare
a unui set de cerine privind
BD, ntr-o manier standardizat i organizat.
Metodologia de proiectare a BD, consta din trei faze
principale:
1. Proiectarea conceptual a BD
Aceast faz F1, reprezint procesul de constituire a unui model al
informaiilor
utilizate n cadrul unei ntreprinderi, independent de toate
consideraiile de ordin fizic.
Descrierea bazei de date la acest nivel poart numele de schem
conceptual (numit
uneori i schem logic) a bazei de date. Ea const ntr-o descriere
abstract dar exact a
structurii acesteia, lasnd la o parte detaliile fizice de
implementare. Schema conceptual este
fcut n termenii modelului de date utilizat. Astfel, n cazul
adoptarii modelului relaional,
aceasta const n:
Tabelele care formeaza baza de date
Structura (coloanele) fiecarei tabele
Tipul de date asociat coloanelor
Elementele pe baza carora se realizeaza interconectarea
tabelelor
(coloane comune)
Constrngeri de integritate
Operaii declanate automat la modificarea unor elemente ale bazei
de
date
Implementarea schemei conceptuale se face cu ajutorul limbajului
pentru descrierea
datelor (LDD) asociat sistemului de gestiune utilizat.
-
ProiectareaBazelordeDate
10
o Constituirea modelului de date conceptual local, pentru
fiecare vedere a utilizatorului.
o Identificarea tipurilor de entiti o Identificarea tipurilor de
relaii o Identificarea i asocierea atributelor cu tipurile de
entiti sau relaii o Determinarea domeniilor atributelor o
Determinarea atributelor cheie candidat i primare o
Specializarea/generalizarea tipurilor de identiti o Desenarea
diagramei Entitate-Asociere o Revizuirea modelului de date
conceptual local, mpreun cu utilizatorul
Faza de proiectare conceptual a bazelor de date ncepe cu crearea
unui model de date
conceptual al ntreprinderii, care este total independent de
detaliile privind implementarea,
cum ar fi elementele de software ale sistemului SGBD int,
programele aplicaie, limbajele
de programare, platforma hardware sau orice consideraie de ordin
fizic.
n continuare se vor prezenta etap cu etap realizarea unui
proiect conceptual al unui
BD. Proiectarea conceptual i logic a BD este mprit n trei etape
principale.
Obiectivul este de a descompune proiectarea n activiti mai uor
manevrabile, prin
examinarea diverselor perspective ale utilizatorilor asupra
ntreprinderii sau vederilor
utilizatorilor.
O Vedere este rezultatul dinamic al uneia sau a mai multor
operaii relaionale, care
acioneaz asupra relaiilor de baz pentru a realiza o alt relaie.
O vedere este o relaie
virtual care, n realitate nu exist n BD, ci este produs n
momentul respectiv la cererea
unui anumit utilizator.
n cadrul acestei etape se transpun modelele de date logice
locale pentru modelul
relaional. n aceast etap se elimin caracteristicile indezirabile
care ar fi dificil de
implementat ntr-un sistem SGBD relaional din modelele de date.
Modelele logice sunt
apoi validate prin utilizarea tehnicii de normalizare.
Normalizarea este o tehnic de realizare a unui set de relaii cu
proprieti dezirabile,
date fiind cerinele unei ntreprinderi. Procesul de normalizare a
fost realizat prima dat de
ctre E.F Codd (1972). Normalizarea, adese ori, const dintr-o
serie de teste asupra unei
relaii, pentru a se constata dac aceasta satisface sau violeaz
cerinele unei anumite forme
normale. Iniial au fost introduse trei forme normale denumite
astfel:
prima (1NF) form normal
-
Cap.1.Concepte
11
a doua (2NF) form normal a treia (3NF) form normal.
Toate aceste forme normale se bazeaz pe dependenele funcionale
dintre atributele unei
relaii. Mai trziu, au fost introduse forme normale superioare,
cum ar fi cea de-a patra (4NF)
i cea de-a cincea (5NF) form normal.
Normalizarea constituie un mijloc eficient de garantare a
faptului c modelele sunt
coerente i logice din punct de vedere structural i au o redundan
minim. Modele de date
sunt validate i pentru tranzaciile pe care este necesar s le
accepte.
Validarea reprezint procesul de garantare a faptului c se
realizeaz un model
corect.
Dup etapa 2, modelele de date logice ar putea fi utilizate, dac
este necesar, pentru a
realiza implementarea de prototipuri ale BD pentru vederile
utilizatorilor.
Implic mbinarea modelelor de date logice locale (care reprezint
vederi diferite ale
utilizatorilor), pentru a obine un model de date logice global
unic al ntreprinderii (care
reprezint vederile tuturor utilizatorilor).
Pe parcursul ntregii metodologii, utilizatorii joac un rol
foarte important n revizuirea
i validarea continu a modelului de date i a documentaiei de
susinere a acestuia.
Proiectarea BD este un proces interactiv, care are un punct de
plecare i o procesiune
numeroas de mbuntiri. Este posibil ca deciziile luate n cadrul
unei etape s conduc la
modificarea deciziilor luate n decursul unei etape anterioare.
Metodologia trebuie s
acioneze ca un ghid n mod eficient n activitatea de proiectare a
BD. Const n continuarea
modelului de date conceptual local pentru fiecare vedere a
utilizatorilor specificat.
Prima etap n proiectarea BD const n realizarea unor modele de
date conceptuale,
pentru fiecare vedere a utilizatorilor asupra ntreprinderii. O
vedere a utilizatorului reprezint
datele cerute de ctre un anumit utilizator pentru a lua o
decizie corect sau a efectua o
anumit activitate. De obicei, vederea unui utilizator constituie
o zon funcional a
ntreprinderii, cum ar fi: producia, marketing, vnzrile,
personalul, contabilitatea sau
controlul aprovizionrii. Un utilizator poate fi o persoan real
sau un grup de persoane care
utilizeaz n mod direct sistemul. Utilizatorul se poate referi la
un raport produs de ctre
sistem sau poate solicita rezultatele unei tranzacii care
trebuie acceptat de ctre acestea.
Vederile utilizatorilor pot fi identificate utiliznd diverse
metode: pot fi examinate diagramele
de flux de date care au fost realizate mai nainte, n scopul de a
identifica zonele funcionale i
-
ProiectareaBazelordeDate
12
posibil funciile individuale, ar putea fi chestionai
utilizatorii se pot examina procedurile,
rapoartele i formulrile i/sau observa ntreprinderea n
funciune.
Se realizeaz o referire la modul de date conceptual,
corespunztor fiecrei vederi a
utilizatorilor pe care urmeaz s modeleze, cu termenul de model
de date conceptual local
corespunztor vederii respective. Fiecare model de date
conceptual local cuprinde: tipuri de
entiti, tipuri de relaii, atributele, domeniile atributelor,
cheile candidat, cheile primare.
Identificarea tipurilor de entiti n aceast etap obiectivul este
identificarea principalelor tipuri de entiti din vederea
utilizatorului asupra ntreprinderii. Modelul de date conceptual
local const n definirea
principalelor obiective care pot prezenta interes pentru
utilizator. O metod de identificare a
entitilor const n examinarea specificaiei cerinelor
corespunztoare unei anumite funcii a
utilizatorului n cadrul ntreprinderii.
Din aceast specificaie se identific substantivele sau expresiile
substantivale
menionate. De asemenea, se caut obiectivele principale, cum ar
fi: personale, locurile sau
conceptele de interes, excluzndu-se substantivele care reprezint
doar caliti ale altor
obiecte.
O modalitate alternativ de identificare a entitilor este de a
cuta obiectele care exist
pe cont propriu. Uneori, entitile sunt greu de identificat,
datorit modului n care sunt
prezentate n cadrul specificaiei cerinelor utilizatorului,
uneori utilizatorii se exprim prin
exemple sau analogii. Nu este ntotdeauna evident dac un anumit
obiect este o entitate, o
relaie sau un atribut.
Proiectanii de baze de date trebuie s aib o vedere selectiv
asupra lumii i s clasifice
lucrurile legate de ntreprinderea pe care le observ.
Exist situaii s nu existe un set unic de tipuri de entiti care
pot fi deduse dintr-o
anumit specificaie a cerinelor, dar intervale succesive ale
procesorului de analiz, trebuie s
se ajung la alegerea entitilor care sunt cel puin adecvate
pentru sistemul cerut.
Pe msur ce se identific entitile, li se atribuie denumiri care s
aib semnificaie i s
fie evidente pentru utilizatori. Denumirea i descrierile
entitilor sunt reunite ntr-un dicionar
de date. Atunci cnd este posibil se documenteaz numrul estimat
de apariii ale fiecrei
entiti. O entitate cunoscut sub denumiri diferite, acestea se
numesc aliasuri sau sinonime i
sunt nregistrate n dicionarul de date.
Identificarea tipurilor de relaii
-
Cap.1.Concepte
13
n aceast etap obiectivul este identificarea relaiilor importante
care exist ntre entitile
identificate. De ndat ce entitile sunt identificate, urmtoarea
etap const n identificarea
relaiilor care exist ntre acestea.
Atunci cnd se identific entitile, o metod este de a cuta
substantivele n specificaia
cerinelor utilizatorului, de regul, relaiile sunt indicate prin
expresii verbale. n majoritatea
cazurilor relaiile sunt binare (exist ntre doar dou entiti),
totui trebuie s se determine i
relaiile complexe, care ar putea include mai mult de dou tipuri
de entiti, precum i relaii
recursive, care implic un singur tip de entitate.
O atenie deosebit trebuie pentru a detecta toate relaiile care
sunt: explicite, implicite n
specificaiile utilizatorului. Totui relaiile lips trebuie s ias
la iveal cnd se valideaz
modelul conform tranzaciilor pe care trebuie s le accepte.
Determinarea cardinalitii i constrngerilor de participare a
tipurilor de relaii. Dup identificarea relaiilor care trebuie
modelate, urmeaz determinarea cardinalitii
fiecreia, care poate fi: unu-la-unu (1:1), unu-la-multi (1:M)
sau multi-la-multi (M:M). n plus
se va determina constrngerile de participare al fiecrei entiti
din cadrul unei relaii ca fiind
fie totale, fie pariale. Un model care include cardinalitatea i
constrngerile de participare
reprezint mai explicit semantica relaiei respective.
Cardinalitatea i participarea sunt forme
de constrngeri care sunt folosite pentru a verifica i menine
calitatea datelor.
Determinarea tipurilor de relaii Pe msur ce se identific
tipurile de relaii, li se atribuie denumiri care au semnificaie
i
sunt existente pentru utilizator. De asemenea, se nregistreaz n
dicionarul de date descrierile
relaiilor i constrngerilor de cardinalitate i de
participare.
Utilizarea modelrii Entitate Asociere (EA) Uneori este mai uor
vizualizarea unui sistem complex dect descifrarea unor
descrieri
textuale lungi, din specificaia cerinelor utilizatorilor.
Diagramele Entitate Asociere (EA) se
utilizeaz pentru a reprezenta mai uor entitile i modelul n care
sunt legate acestea unele
de altele. n cadrul fazei de proiectare a BD se recomand modelul
E-A oriunde este necesar,
pentru a servi la construirea unei imagini a sectorului de
ntreprindere care urmeaz s fie
modelat.
-
ProiectareaBazelordeDate
14
2. Proiectarea logic a BD
Aceast faz F2, const n procesul de construire a unui model al
informaiilor utilizate
n cadrul unei ntreprinderi, baza pe un anumit model de date, dar
independent de un anumit
SGBD i de alte considerente de ordin fizic.
Diferitele categorii de utilizatori ai unei baze de date au
nevoie n activitatea lor doar de
poriuni specifice ale acesteia. Descrierea acestor poriuni poart
numele de scheme logice. O
baz de date are deci asociat o singur schema fizic i o singur
schem conceptual, dar
mai multe scheme logice.
Schemele logice sunt descrise de obicei cu ajutorul modelului de
date folosit pentru
schema conceptual. n plus se specific modul n care se face
corespondenta ntre obiectele
celor dou descrieri.
Dac pentru administratorului bazei de date schema logic coincide
cu schema
conceptual, celelalte categorii de utilizatori acceseaza baza de
date doar prin intermediul
schemelor logice specifice acestora. Din aceasta cauz, orice
prelucrare lansat de un
utilizator este translatat de ctre SGBD mai nti la nivel
conceptual si apoi la nivel fizic.
3. Proiectarea fizic a BD
Aceast faz reprezint procesul de realizare a unei descrieri a
implementrii bazei de
date ntr-o capacitate de memorare secundar; descrie structuri de
memorare i metode de
acces utilizate pentru realizarea unui acces eficient la
date.
Baza de date este acum descris din perspectiva stocrii sale pe
dispozitivele fizice:
identificarea discurilor si a cailor unde este stocat, numele
fiierelor care formeaz baza de
date, structura fizic a acestora, etc. Descrierea bazei de date
la acest nivel poart numele de
schem fizic i sistemul de gestiune a bazelor de date pune la
dispoziie facilitile pentru
nregistrarea i modificarea acesteia. Fiecare SGBD are n general
asociat un model specific
de descriere la nivel fizic a bazei de date.
Urmtoarele aspecte s-ar putea dovedi de importan pentru succesul
proiectrii BD:
lucrul interactiv cu utilizatorii ct de muli trebuie;
urmrirea unei metodologii structurate de-a lungul procesului de
modelare a datelor;
utilizarea unei abordri coordonat prin date;
ncorporarea consideraiilor structurale i de integritate n
modelul de date;
combinarea tehnicilor de conceptualizare, normalizare i validare
a tranzaciilor n
metodologia de modelare a datelor;
utilizarea diagramelor, pentru a reprezenta ct mai mult din
modelul de date;
-
Cap.1.Concepte
15
utilizarea unui limbaj de proiectare a BD Data Base Design
Language (BDDL) pentru
a reprezenta semantica suplimentar a datelor;
construirea unui dicionar care s suplimenteze diagramele
modelului de date;
disponibilitatea de a repeta anumite etape.
Determinarea atributelor cheie candidate i primare n aceast etap
obiectivul const n identificarea cheii (cheilor) candidate pentru
fiecare
entitate i dac exist mai mult dect o cheie candidat selecionarea
celei care va fi cheia
primar. O cheie candidat este un atribut sau un set minimal de
atribute ale unei entiti, care
identific n mod unic fiecare apariie a acesteia. Se poate
identifica mai mult dect o singur
cheie candidat, dar n acest caz trebuie s alegem una dintre ele
drept cheie primar, celelalte
chei candidat se numesc chei alternative.
La alegerea unei chei primar din cele candidate trebuie s se in
seama de urmtoarele,
care ajut la efectuarea selectrii:
se alege cheia candidat cu setul minim de atribui;
se alege cheia candidat creia probabilitatea de modificare a
valorii este mai mic;
se alege cheia candidat care are probabilitatea mai mic s-i
piard caracterul de
unitate n viitor;
se alege cheia candidat cu cel mai mic numr de caractere;
se alege cheia candidat cea mai prietenoas din punct de vedere
al utilizatorului.
n procesul de identificare al cheilor primare se constat dac o
entitate este tare sau
slab.
O entitate se numete tare dac i se poate asocia o cheie primar i
este o entitate slab
dac nu i se poate asocia o cheie primar.
Cheia primar a unei entiti slabe poate fi identificat numai
atunci cnd relaia slab
se transform ntr-o entitate i legturile ei cu entitatea de care
aparine prin plasarea unei chei
strine n cadrul acelei relaii. Procesul de transformare n relaii
a entitilor i a legturilor
lor este foarte important, prin urmare, identificarea cheilor
primare pentru entiti slabe nu
poate avea loc nainte de a ajunge la acea etap. Este indicat s
se nregistreze identificarea
cheilor primare i alternative (atunci cnd exist), n dicionarul
de date.
Specializarea/generalizarea tipurilor de entiti Obiectivul este
identificarea tipurilor de entiti superclas i subclas, atunci cnd
este
adecvat. n cadrul acestei etape exist opiunea de a dezvolta
modelul EA prin utilizarea
-
ProiectareaBazelordeDate
16
proceselor de specializare sau de generalizare a entitilor
identificate pe parcursul etapei E
1:1.
Dac se alege tratarea prin specializare se evideniaz diferenele
prin definirea uneia sau
a mai multor subclase ale unei entiti, denumit superclas de
specializare. n cazul cnd se
alege tratarea prin generalizare, se ncearc o identificare a
caracteristicilor comune ale
entitilor, pentru a defini o entitate generalizat denumit
superclas de generalizare. n
general, se opteaz pentru generalizarea entitilor, bazndu-se pe
existena atributelor
comune i a relaiilor asociate fiecruia.
De obicei, nu exist indicaii stricte privind situaiile n care
este recomandabil realizarea
modelului EA prin specializare sau generalizare, deoarece
aceasta alegere este, adeseori,
subiectiv i depinde de caracteristicile particulare a situaiei
de modelat.
Ca o indicaie util n alegerea specializrii sau generalizrii,
este recomandabil
realizarea modelului EA, trebuie s se ncerce reprezentarea
entitilor importante i relaiilor
ct mai riguros posibil. Gradul de specializare/generalizare
afiat ntr-o diagram E-A, trebuie
s fie dictat de lizibilitatea diagramei i de claritatea cu care
aceasta modeleaz tipurile
importante de entiti i relaii. Conceptul de
specializare/generalizare este asociat modelrii
extinse.
Datorit faptului c aceast etap este opional se vor utiliza doar
termenii de diagram
EA sau model EA, atunci cnd se fac referiri la reprezentarea
schematic a modelelor de
date.
Desenarea diagramei Entitate Relaie (E-A) Obiectivul acestei
etape const n desenarea unei diagrame Entitate- Asociere (EA) care
s fie
o reprezentare conceptual a vederii unui utilizator asupra
ntreprinderii.
Sisteme de gestiune a Bazelor de Date Bazele de date sunt
pstrate pe disc. Accesul la disc este controlat n principal de
sistemul de operare care gestioneaz operaiile de I/O/. La un
nivel superior, sistemul de
gestiune a bazei de date este cel care gestioneaz accesul la
informaia stocat pe disc. SGBD-
ul interacioneaz cu sitemul de operare atunci cnd acceseaz
discul. Dac sistemul este
folosit de mai muli utilizatori, sistemul de operare va programa
accesul la disc al SGBD-ului
astfel nct s poat fi executat n paralel cu celelalte procese.
SGBD-ul comunic de
asemenea i cu compilatoarelel pentru executarea comenzilor de la
limbajele de programare.
-
Cap.1.Concepte
17
Pentru a uura utilizarea bazelor de date, SGBD-urile ofer de
cele mai multe ori i interfee
prietenoase.
Pentru procesarea cererilor primite, cele mai multe SGBD-uri au
module dedicate care
execut fiecare anumite sarcini. Cele mai comune tipuri de funcii
sunt:
Modulul de ncrcare: un astfel de modul adaug un fiier cu date n
baza de date. Aceast operaie presupune reformatarea datelor astfel
nct s
corespund formatului destinaie.
Transferarea de informaie ntre dou formate cunoscute este un
proces foarte
intlnit, anumii productori furniznd doar acest tip de
module.
Copii de siguran: un astfel de modul creaz o copie a ntregii
baze de date pe un suport extern. Aceast copie de siguran este
folosit pentru a restaura baza
de date n cazul unei erori. De obicei se folosesc copii
incrementale care
salveaz doar modificrile efectuate fa de copia precedent.
Acestea ocup
mult mai puin spaiu dar sunt mult mai complexe.
Reorganizarea fiierelor: acest tip de modul reorganizeaz un
fiier al bazei de date ntr-un alt fiier pentru a mbunti
performanele. Aproape toate
sistemele de gestiune a bazelor de date necesit reorganizare
periodic datorit
inserrilor i tergerilor succesive.
Monitorizarea performanelor: acest tip de modul ofer statistici
privind utilizarea informaiilor din baza de date precum i timpul
necesar pentru
executarea diferitelor interogri. Aceste statistici pot fi
folosite de SGBD
pentru a decide, de exemplu, dac este necesar o reorganizare a
fiierelor
pentru mbuntirea performanelor.
Confidenialitatea datelor:Un utilizator este identificat
printr-un utilizator i o parol. Fiecrui utilizator i se permite
accesul doar la o poriune a bazei de date
i doar pentru a efectua anumite tipuri de operaii. n cazul
bazelor de date
accesate n reea se pot defini de asemenea locaiile de la care
utilizatorul poate
interaciona cu baza de date. Toate aceste informatii relative la
ce, cum i de
unde poate accesa datele un utilizator reprezint drepturile de
acces asociate
acestuia i sunt stocate n cataloagele sistemului.
Alte tipuri de module utilitare se refer la sortarea fiierelor,
compresia datelor sau
monitorizarea accesului de ctre utilizatori.
Funciile unui SGBD relative la accesul utilizatorilor la baza de
date sunt urmtoarele:
-
ProiectareaBazelordeDate
18
1. Gestiunea utilizatorilor. Un SGBD trebuie s permit crearea,
modificarea i
tergerea utilizatorilor. Operaia este efectuat de obicei de
administratorul bazei de date.
2. Concurena la date. n cazul accesului simultan al mai multor
utilizatori la aceleai
date un SGBD trebuie s aib mecanisme pentru a prentmpina
inconsistena datelor.
Orice SGBD are mecanisme prin care diversilor utilizatori sau
categorii de utilizatori li
se asociaz drepturi de acces specifice la obiectele bazei de
date. n acest mod fiecrui
utilizator i se d dreptul de a efectua doar operaiile specifice
activitii sale i doar pe acea
poriune a bazei de date care este necesar pentru acestea.
Mecanismul de drepturi de acces are ca obiective principale:
Blocarea accesului unor categorii de utilizatori la date pe care
nu trebuie s le
acceseze. n acest fel este asigurat una dintre funciunile de baz
ale unui SGBD i
anume confidenialitatea datelor.
Blocarea accesului unor categorii de utilizatori la date de care
nu au nevoie n
activitatea lor, minimizndu-se astfel riscul distrugerii
accidentale a datelor prin
operaii necorespunztoare.
Fiecare tip de SGBD are propriile sale mecanisme de descriere a
drepturilor de acces
bazate n principal pe acordarea sau neacordarea dreptului de a
citi sau scrie diverse poriuni
ale bazei de date.
Modelarea Datelor - Etapele dezvoltarii unei aplicaii
Proiectarea corect a structurii unei baze de date relaionale este o
premis
fundamental n scrierea programelor de aplicaie i n funcionarea
lor fr anomaliile care
pot apare n cazul unei structuri defectuoase.
Proiectarea structurii bazelor de date relaionale este un
domeniu n care cercetrile au
evoluat spre elaborarea unor metodologii teoretice i a unor
instrumente software care asigur
un grad ridicat de normalizare a schemelor de relaie, pstrarea
integritii, evitarea
anomaliilor datorate unei proiectri nesistematice i eliminarea
subiectivismului
proiectantului prin nlocuirea lui cu exactitatea metodei.
Pn la apariia unor astfel de metodologii se pornea de la o
colecie de tabele i de la
dependenele funcionale i multivalorice asociate i se ajungea,
prin aplicarea unor algoritmi
sau metode de normalizare la schema dorit a bazei de date.
Aceast abordare de tip bottom-
up creaz ns dificulti n cazul bazelor de date complexe n care
numrul de tabele i de
dependene este mare. Probabilitatea ca unele interdependene ntre
date s nu fie sesizate n
-
Cap.1.Concepte
19
procesul de proiectare este n aceste cazuri ridicat rezultnd n
exploatare anomalii care duc la
reluri ale ciclului analiza cerinelor & schema bazei de date
& programe de aplicaie.
Cercetrile n domeniul proiectrii schemei conceptuale s-au
concentrat pe gsirea
unor metodologii top-down pentru obinerea unei structuri optime
a BD. Ele au fost
influenate de rezultatele obinute n domenii care folosesc bazele
de date: inteligena
artificial, proiectarea asistat de calculator, abordarea
orientat pe obiecte.
Impactul conceptelor de abstractizare i generalizare precum i
elaborarea unui model
de descriere informal a datelor, i anume modelul
entitate-asociere (EA), au dus la gsirea
unor ci algoritmizabile de proiectare optim a bazelor de date.
Modelul entitate-asociere este
n acest moment cel mai popular model de comunicare a structurii
bazelor de date datorit
intuitivitii i simplitii elementelor sale.
Extensiile modelului EA au aprut i pentru alte necesiti:
modelarea cerintelor de secretizare a datelor,
documentarea programelor de aplicatie si usurarea comunicarii
ntre proiectantul de
sistem i utilizatorul obinuit,
proiectarea bazelor de date complexe pe portiuni si integrarea
ulterioar a acestora (aa
numita integrare a vederilor).
Avantajul principal al modelului EA este acela al simplitii sale
i al caracterului su
intuitiv. Rezultatul proiectrii const ntr-o diagram
entitate-asociere care poate fi apoi
translatat n modelul de date folosit de sistemul de gestiune a
bazelor de date ales pentru
dezvoltarea aplicaiei. Etapele proiectrii unei noi aplicaii care
gestioneaz o baz de date, cu
accentul pe partea de proiectare a structurii acesteia. Aceste
etape sunt detaliate n paragrafele
urmtoare.
Analiza de sistem
In aceast etap se realizeaz analiza segmentului din lumea real
care va fi gestionat
de aplicaia respectiv. Rezult o specificaie neformalizat a
cerinelor constnd din dou
componente:
1. Cerinte privind coninutul bazei de date: categoriile de date
care vor fi stocate i
interdependenele dintre acestea.
2. Cerinte privind prelucrrile efectuate de aplicaie:
prelucrrile efectuate asupra datelor,
arborele de meniuri al aplicaiei, machetele formatelor de
introducere i prezentare a datelor i
ale rapoartelor tiprite de aceasta.
In general aceasta etapa nu poate fi asistat prin programe de
tip CASE dar exist
reguli care ajuta proiectantul in realizarea sa. Activitatile
desfurate includ:
-
ProiectareaBazelordeDate
20
Analiza activitii desfurate la momentul respectiv de
beneficiarul aplicaiei sau de
o mulime reprezentativ de beneficiari n cazul aplicaiilor de uz
general.
Analiza coninutului de date i a functionalitii aplicaiilor
software - dac exist -
care vor fi nlocuite de noua aplicaie incluznd meniuri, machete
ecran i machete de
rapoarte.
Analiza formularelor tipizate i a altor documente utilizate de
beneficiar pentru
realizarea activitii respective.
Identificarea tuturor interdependenelor dintre datele care vor
fi stocate n baza de
date i a restriciilor privind valorile pe care le pot lua
anumite categorii de date.
Identificarea - dac este cazul - a prelucrrilor care se
declaneaz automat att n
cazul modificrii bazei de date ct i la momente prestabilite de
timp (de exemplu sfrit de
lun, de an, etc.)
Identificarea operatiilor care sunt necesare beneficiarului n
activitatea curent dar
care n acest moment nu sunt realizate prin intermediul
aplicaiilor software folosite precum i
a operaiilor care pot fi incluse n mod natural n noua
aplicaie.
Identificarea bazelor de date existente care pot fi folosite de
noua aplicaie - direct
sau printr-un import iniial de date - evitndu-se n acest fel
reintroducerea manual a
acestora.
Identificarea modalitilor de transfer de date ntre noua aplicaie
i alte aplicaii care
ruleaz deja la beneficiar i care vor fi folosite i n viitor de
ctre acesta.
Identificarea necesitilor privind datele i prelucrrile care pot
fi n viitor necesare
beneficiarului, deci a posibilelor dezvoltri n timp ale
aplicaiei.
Aceasta etap este efectuat de personal calificat avnd n vedere
ca rezultatele sale
sunt baza de la care se pleac n etapele urmtoare, eventualele
erori putnd fi corectate
ulterior cu costuri semnificative.
Proiectarea conceptuala a bazei de date
In aceast etap, pornind de la rezultatele analizei de sistem, se
realizeaz modelarea
cerinelor privind datele folosind un model de nivel nalt. Cel
mai popular model folosit
pentru aceasta este modelul entitate-asociere (EA). Actualmente
exist pe pia numeroase
instrumente CASE care folosesc diverse variante ale modelului.
Motivele pentru care a fost
ales sunt urmtoarele:
-
Cap.1.Concepte
21
Nu este legat direct de nici unul dintre modelele folosite de
sistemele de gestiune a bazelor
de date (relational sau orientat obiect) dar exist algoritmi
bine pui la punct de transformare
din model EA n celelalte modele de date.
Este intuitiv, rezultatul modelrii fiind o diagram care definete
att datele stocate n baza
de date ct i interdependenele dintre acestea.
Poate fi uor de neles de nespecialiti. Aceasta caracteristic
este foarte important n
momentul n care se face punerea de acord cu beneficiarul asupra
structurii bazei de date a
aplicaiei, evitndu-se n acest fel o proiectare neconform cu
realitatea sau cu cerinele
exprimate de acesta.
Proiectarea se poate face pe poriuni, diagramele pariale
rezultate putnd fi apoi integrate pe
baza unor algoritmi i metode bine puse la punct.
Implementarea specifica sistemului de gestiune folosit
In aceasta etap se realizeaz crearea structurii bazei de date
obinut n etapa
precedent pe baza facilitilor oferite de sistemul de gestiune a
bazelor de date ales.
Rezultatul ei este programul de creare scris in limbajul de
definitie a datelor acceptat de
SGBD-ul utilizat. Iata un exemplu:
Schema conceptala:
Student(CodStudent:Numeric, Nume:Sir, DataNasterii:Data)
Program de creare (SQL-Oracle):
Create table Student( CodStudent Number(5) Primary Key, Nume
Varchar2(40), DataNasterii Date);
Programul conine att definirea tabelelor ct i definirea
celorlalte obiecte ale bazei
de date i a interdependenelor dintre acestea (de exemplu
constrngerile de integritate
intratabel i inter-tabele).
De asemenea aici se fac si toate operaiile privind proiectarea
la nivel fizic a bazei de
date. In cazul folosirii de unor unelte CASE programul de creare
poate fi generat i executat
automat.