Proiectarea Bazelor de Date Relaționale

Cap. 1. Introducere în metodologia de proiectare a bazelor

de date

Atunci când 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 conţine, precum şi ce relatii trebuie să existe

între tabele. Deşi 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 relaţional sunt numeroase.

Printre acestea putem enumera:

- Inserările, modificările şi ştergerile sunt efectuate efectuate eficient

- Regăsirea informaţiei şi rapoartele se obţin intr-un timp scurt

- Întrucât informaţiile se vor reţine în baza de date şi nu în aplicaţie, baza de date

trebuie să conţina metadate

- Modificările în schema bazei de date se realizează cu uşurinţă

Scopul acestui curs este de a explica principiile care stau la baza proiectării bazelor de

date şi să prezentăm cum trebuie acestea aplicate.

Pentru modelul relaţional, tabelele reprezintă „obiecte” din lumea reală. Fiecare tabel

reprezintă un singur obiect. Aceste obiecte (sau entităţi) 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 ambiguităţi şî

probleme are trebuie evitate.

Unicitatea unui tabel se realizează prin desemnarea unei chei primare – un atribut care

conţine o valoare unică. Fiecare relaţie trebuie să aibă doar o singură cheie primară, chiar

Proiectarea Bazelor de Date

dacă există şi alte atribute cu valoare unică. Acestea (restul atributelor cu valoare unică, sau o

combinaţie 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 puţine

atribute, care are cele mai puţine şanse să îşi modifice valoarea şi care este cea mai intuitivă

pentru utilizator.

Să ilustrăm cele prezentate printr-un exemplu: o campanie doreşte să îşi ţină evidenţa

clienţilor:

Id_Client Nume Prenume Adresa Oraş Judeţ Telefon

1 Popescu Paul Str. Teilor nr. 13 Bucureşti Bucureşti 0213455321

2 Georgescu George Str. Primăverii, nr 7 Bucuresti Bucureşti 0214554454

3 Ionescu Ion Str. Brestei, nr 15 Craiova Dolj 0351232433

Fig. 1.1 Exemplu de relaţie. Cheia primară cea mai potrivită pentru a fi aleasă este Id_Client

Chei externe şi domenii

Deşi cheile primare ţin doar de relaţii individuale (tabele independente), dacă creezi

baze de date ale căror tabele nu au nici o legătură unul cu altul, nu vor fi de un prea mare

folos. Cheile primare devin esenţiale atunci când se crează relaţii care unesc mai multe tabele

dintr-o bază de date.

O cheie externă este acel atribute dintr-un tabel care face legătura cu un alt atribut

(dintr-un alt tabel).

Să continuăm exemplul anterior cu un alt tabel, Comenzi, în care se reţin comenzile

pentru fiecare client în parte. (Figura 1.2).

În acest exemplu, ID_client este o cheie externă care face legătura între tabelul Client şi

tabelul Comenzi. Acest atribut este considerat cheie externă întrucât prin el se poate face

referire la un anumit client din tabelul Clienti.

Este important ca atât cheile externe cât şi cheile primare folosite, care se referă la

acelaşi obiect, să aibă valori comune şi să fie definite pe acelaşi 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 întâmplă).