Upload
eancrimicri
View
58
Download
1
Embed Size (px)
DESCRIPTION
baze date
Citation preview
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.