Elemente de proiectare a bazei de date

ELEMENTE DE PROIECTARE A BAZEI DE DATE

1 Entitǎti, atribute, chei.

In introducere am vǎzut cǎ actualizarea datelor despre clienti sau a datelor despre cǎrti este dificilǎ in conceptia initialǎ. Aceastǎ deficientǎ a apǎrut pentru cǎ au fost puse impreunǎ date despre trei lucruri distincte: clienti, cǎrti si comandǎ. Astfel de "lucruri" vor fi numite de acum inainte entitǎti.  

Entitatea este ceva despre care se memoreazǎ date. Clientii si cǎrtile sunt entitǎti tangibile (tari), comenzile nu pot exista fǎrǎ celelalte douǎ, ele nu sunt tangibile desi sunt puse pe hartia comandǎ, comanda este o entitate slabǎ. Entitatea va fi reprezentatǎ in baza noastrǎ de date sub forma unui tabel in care liniile sunt concretizǎrile acestei entitǎti, adicǎ  reprezentantii sau instantele entitǎtii.

Pe fiecare linie nu vom avea chiar reprezentantii entitǎtii ci numai date care caracterizeazǎ din punctual de vedere al aplicatiei reprezentantii entitǎtii; aceste date se numesc atribute. Deci o entitate din viata realǎ genereazǎ intr-o bazǎ de date relationalǎ un tabel ale cǎrui coloane au ca nume atributele entitǎtii, iar pe linii succesive se gǎsesc valorile atributelor pentru fiecare reprezentant al entitǎtii in parte.

De exemplu: entitatea CARTE are atributele: id carte, titlu, autor, editura, pret, in exemplul dat sunt trei reprezentanti ai acestei entitǎti, iar fiecare celulǎ a acestui tabel reprezintǎ o valoare a atributului corespunzǎtor coloanei pentru reprezentantul corespunzǎtor liniei.

CARTE

Dacǎ am avea 10.000 de cǎrti vom avea in tabel 10.000 de linii pe care ar fi memorate valorile atributelor entitǎtii CARTE.

Alt exemplu pentru entitatea CLIENT avand atributele: id client, nume, prenume, oras, str., nr., tel, cod.

CLIENT

Dacǎ avem doi clienti cu acelasi nume cum vom determina care este cel care a comandat o anumitǎ carte?  

Am vǎzut care sunt inconvenientele creǎrii unui cod mixt cum a fost cel initial. Am mai putea folosi pentru identificatori numele plus numǎrul de telefon, dar in acest caz avem multe caractere si rǎman problemele legate de actualizǎri; de exemplu schimbarea numǎrului de telefon. Un astfel de atribut, simplu sau obtinut prin concatenare care identificǎ unic o instantǎ a unei entitǎti se va numi cheie. Asa cum recomandǎ practica si autorii Harrington [2] vom crea chei printr-un numǎr generat succesiv si unic in special pentru persoane, locuri, lucruri etc. Rǎman situatii in care este nevoie de chei concatenate. Existenta unei chei care sǎ identifice unic reprezentantii unei entitǎti este o regulǎ esentialǎ de integritate a datelor.

Intr-un model relational (de care ne ocupǎm in mod special) este esential ca atributele sǎ aibǎ valori unice, adicǎ fiind datǎ o instantǎ a unei entitǎti, un anumit atribut trebuie sǎ aibǎ o singurǎ valoare. De exemplu un client poate avea un singur numǎr de telefon. Dacǎ lǎsǎm mai multe locuri, mǎrim inutil si neproportional baza de date deci in cazul acestei necesitǎti trebuie creatǎ o nouǎ entitate "numǎr de telefon" cu mai multe instante.

2 Diagrama ER (Entitate relatie.)

Odatǎ stabilite entitǎtile si atributele ele trebuie sǎ rǎmanǎ pe un document; de fapt toatǎ activitatea de proiectare trebuie documentatǎ. Pe langǎ tabelele pe care le putem gǎsi in Iacob [3] si [4], avem nevoie de un instrument grafic care sǎ permitǎ o vedere sinteticǎ asupra bazei de date. Chen [1] a "inventat" diagrama E-R (entity‑relationship adicǎ entitate‑relatie). O prezentǎm aici sub o formǎ modificatǎ:

Entitatea se reprezintǎ sub forma unui dreptunghi in care sunt listate atributele si in care este pusǎ in evidentǎ cheia. Apoi vom vedea cum se reprezintǎ si relatiile intre entitǎti.

Iatǎ cum aratǎ, in primǎ instantǎ, entitǎtile reproiectate pentru societatea "Lectura inteligentǎ".

Se observǎ imediat cǎ trebuie sǎ spunem ce valori pot lua atributele si cat loc o sǎ ocupe aceste valori. Aceasta inseamnǎ cǎ trebuie stabilim domeniul atributelor. Practic se utilizeazǎ urmǎtoarele simboluri:

CHARx               text de x caractere, x 256

INTx                                 numǎr intreg de x cifre

DECIMALx.z                   numǎr de x cifre dintre care

NUMERICx.z                  z sunt dupǎ virgule (punctual) zecimal

DATE                               datǎ calendaristicǎ (zz/ll/aa)

TIME                                timp hh:mm:ss

DATETIME                     o combinatie a precedentelor

BOOLEAN                       valoarea logicǎ (adevǎrat sau fals)

In baza de date se vor introduce si relatii intre entitǎtile, care sunt de fapt realizate intre instante.

Vom enumera in continuare tipurile de relatii care se pot stabili intre entitǎti:

Relatii 1 la 1

Este cazul relatiei din cǎsǎtoria dintre douǎ posibile entitǎti "bǎrbati" si "femei" (nu in tǎrile islamice)

Relatii 1 la n

Sunt cele mai frecvente. Exemplu la o editurǎ pot fi mai multe cǎrti, dar o anumitǎ carte provine de la o singurǎ editurǎ.

Relatii n la m

Intre comenzi si cǎrti. Intr-o comandǎ pot fi mai multe cǎrti si aceeasi carte poate sǎ aparǎ in mai multe comenzi. Acest tip de relatii nu este usor de manuit si o astfel de relatie este transformatǎ in douǎ relatii de 1 la n introducand o nouǎ entitate. In cazul nostru noua entitate va fi "detaliu comandǎ". Este obligatoriu ca in aceastǎ entitate sǎ avem cheile celor douǎ entitǎti intre care existǎ relatia de n la m.

Relatiile vor fi descrise in diagramele E-R cu linii intre entitǎti care vor fi intretǎiate de simboluri ale tipurilor. Aceste simboluri sunt descrise mai jos.

| | pentru una si numai una (instantǎ)

0 |        pentru zero sau una

> |        pentru una sau mai multe

> 0        pentru zero, una sau mai multe

O comandǎ contine cel putin o carte, dar o carte poate sǎ nu fie comandatǎ de nimeni, totusi este o relatie de tip n la m. ea poate fi transformatǎ prin introducerea entitǎtii "detaliu comandǎ" in:

0 | |