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.