1

PROIECTAREA BAZELOR DE DATE

RELAŢIONALE

3.1. Preliminarii

Modelul relaţional a fost conceput şi dezvoltat de E.F. Codd. El este

un model formal de organizare conceptuală a datelor, destinat reprezentării

legăturilor dintre date, bazat pe teoria matematică a relaţiilor. Este modelul

cel mai accesibil pentru utilizatorul bazei de date deoarece structura sa fizică

este aceeaşi cu cea a datelor care trebuie prelucrate. În general, datele se

prezintă sub forma unor tabele (relaţii) în care liniile constituie

înregistrări, iar coloanele sunt atribute ce caracterizează aceste

înregistrări.

Obiectivele modelului relaţional, considerate de către E.F. Codd, sunt

următoarele:

să permită un grad înalt de independenţă a datelor;

să furnizeze baze solide pentru tratarea semanticii, coerenţei şi

problemelor de redundanţă a datelor;

să permită dezvoltarea limbajelor de prelucrare a datelor. Modelul relaţional a permis introducerea unor limbaje neprocedurale

de prelucrare a datelor. Modelul relaţional nu este orientat spre sistemul de calcul, deci modelul nu include regulile, structurile şi operaţiile referitoare la implementarea fizică a unui sistem de baze de date. De fapt, unul dintre obiectivele modelului este acela de a face o distincţie între aspectele fizice şi logice ale unei baze de date (independenţa datelor).

Definirea unui SGBD relaţional impune analizarea caracteristicilor pe care trebuie să le prezinte un model de date pentru a fi considerat relaţional. Există diferite modalităţi pentru a defini acest concept:

prezentarea datelor în tabele supuse anumitor operaţii de tip proiecţie, selecţie, reuniune, compunere, intersecţie etc. (definiţie simplă);

un sistem de baze de date ce suportă un limbaj de tip SQL – Structured Query Language (definiţie practică);

un sistem de baze de date care respectă principiile modelului relaţional introdus de E.F. Codd (definiţia folosită cel mai frecvent).

2

E.F. Codd a publicat un set de 13 reguli, numite reguli de fidelitate, în raport cu care un SGBD poate fi apreciat ca relaţional. Ulterior, cele 13 reguli de fidelitate ale lui Codd au fost extinse la un număr de 100. Trebuie remarcat că nu există un SGBD care respectă toate regulile definite de Codd. Nu trebuie să apreciem un SGBD ca fiind relaţional sau nu, ci măsura în care acesta este relaţional, deci numărul regulilor de fidelitate pe care le respectă.

3.2. Caracterisicile modelului relaţional

Dintre principalele caracteristici ale modelului relaţional se remarcă:

nu există tupluri identice;

ordinea liniilor şi a coloanelor este arbitrară;

articolele unui domeniu sunt omogene;

fiecare coloană defineşte un domeniu distinct şi nu se poate repeta în cadrul aceleiaşi relaţii;

toate valorile unui domeniu corespunzătoare tuturor cazurilor nu mai pot fi descompuse în alte valori (sunt atomice).

Comparativ cu celelalte modele de date, modelul relaţional are avantaje remarcabile dintre care se remarcă:

fundamentarea matematică riguroasă,

independenţa fizică a datelor,

posibilitatea filtrărilor,

existenţa unor structuri de date simple,

minimizarea redundanţei,

supleţea în comunicarea cu utilizatorul neinformatician etc.

Ca limite ale modelului relaţional pot fi menţionate:

rămâne totuşi redundanţă,

ocupă spaţiu,

apar fenomene de inconsistenţă,

nu există mecanisme pentru tratarea optimă a cererilor recursive,

nu lucrează cu obiecte complexe,

nu există mijloace perfecţionate pentru exprimarea constrângerilor de integritate,

nu realizează gestiunea cunoştinţelor etc.

Un model relaţional este caracterizat de trei elemente:

3

structura relaţională a datelor (caracteristica structurală),

operatorii modelului relaţional (caracteristica de asigurare a prelucrării),

regulile de integritate care guvernează folosirea cheilor în model (caracteristica de asigurare a integrităţii).

Aceste trei elemente corespund celor trei componente ale ingineriei

software: informaţie, proces, integritate.

3.2.1. Structura datelor Conceptelor descrise formal drept relaţie, tuplu sau atribut, le

corespund uzual denumirile tabel, linie sau coloană, iar fizic fişier, înregistrare sau câmp.

Un domeniu este o mulţime de valori care se poate defini fie enumerând elementele componente, fie specificând o proprietate distinctivă a valorilor. Domeniului îi corespunde, atât uzual cât şi fizic, conceptul de

tip de date. Un tip de date este o mulţime de valori, şi anume mulţimea tuturor

valorilor care satisfac o anumită constrângere a tipului. Un tip de date poate fi definit de către sistem sau de către utilizator. De asemenea, fiecare tip are asociat un set de operatori care pot fi aplicaţi valorilor tipului respectiv. Tipurile constrâng operaţiile prin faptul că este necesar ca operanzii unei operaţii să fie de tipurile definite pentru operaţia respectivă.

Tipurile pot fi oricât de simple sau de complexe. Se pot distinge tipuri de date ale căror valori sunt numere, şiruri, date calendaristice, înregistrări

audio sau video, hărţi, puncte geometrice etc. Orice tip de date este scalar (atomic, încapsulat) sau nescalar. Tipul

nescalar are componente vizibile utilizatorului şi direct accesibile. Trebuie făcută distincţia între un tip şi reprezentarea sa fizică,

deoarece tipurile sunt legate de model, iar reprezentarea fizică este un aspect legat de implementare.

Fie D1, D2, ..., Dn domenii finite, nu neapărat disjuncte. Produsul

cartezian D1 D2 ... Dn al domeniilor D1, D2, ..., Dn este definit de

mulţimea tuplurilor (V1, V2, ..., Vn), unde V1 D1, V2 D2, ..., Vn Dn. Numărul n defineşte aritatea tuplului.

O relaţie R pe mulţimile D1, D2, ..., Dn este o submulţime a produsului

cartezian D1 D2 ... Dn, deci este o mulţime de tupluri. Există un alt mod

de a defini relaţia, şi anume ca o mulţime finită de funcţii. Asociem fiecărui domeniu Di un atribut Ai şi definim relaţia R = {f1, f2, ..., fm}, unde

4

fi : {A1, A2, ..., An} D1 D2 ... Dn şi fi(Aj) Dj pentru orice valori ale lui i şi j. În această definiţie nu mai este restricţionată ordinea.

Definirea unei relaţii ca o mulţime de tupluri sau ca o mulţime de funcţii se referă la mulţimi care variază în timp (se adaugă, se şterg sau se modifică elemente). Pentru a caracteriza o relaţie este necesară existenţa unui element invariant în timp, iar acest invariant este dat de structura relaţiei (schema relaţională.

Mulţimea numelor atributelor corespunzătoare unei relaţii R defineşte schema relaţională a relaţiei respective. Vom nota schema relaţională prin R(A1, A2, ..., An).

De exemplu, pentru modelul de date analizat în această lucrare,

VESTIMENTATIE(cod_vestimentatie, cod_creator, cod_model,

cod_prezentare , denumire, valoare, descriere) reprezintă o schemă

relaţională.

Putem reprezenta o relaţie printr-un tabel bidimensional în care

fiecare linie corespunde unui tuplu şi fiecare coloană corespunde unui domeniu din produsul cartezian. O coloană corespunde unui atribut.

Numărul atributelor defineşte gradul relaţiei, iar numărul de tupluri din relaţie defineşte cardinalitatea relaţiei.

Bazele de date relaţionale sunt percepute de către utilizatori ca o mulţime de tabele. Tabelul reprezintă structura logică dintr-un sistem

relaţional, nu structura fizică. La nivel fizic, sistemul poate stoca datele în diferite moduri, folosind fişiere secvenţiale, indexări, înlănţuiri de pointeri etc., cu condiţia să poată realiza corespondenţa dintre reprezentarea stocată şi tabelele de la nivelul logic.

Bazele de date relaţionale respectă principiul informaţiei (principiul reprezentării uniforme), care afirmă că întregul conţinut informaţional al bazei este reprezentat într-un mod unic, şi anume, ca valori explicite ale celulelor unui tabel. Această modalitate de reprezentare este singura disponibilă, la nivel

logic, într-un sistem relaţional.

Când se inserează tupluri într-o relaţie, de multe ori valoarea unui

atribut este necunoscută sau nu este aplicabilă tuplului respectiv. Pentru a

reprezenta valoarea acestui atribut a fost introdusă o valoare convenţională

în relaţie, şi anume null. De fapt, null nu reprezintă o valoare, ci absenţa

uneia. Un null nu este acelaşi lucru cu o valoare numerică egală cu zero sau

cu un şir de caractere vid. Zerourile şi spaţiile libere (şirul vid) sunt valori,

pe când null semnifică absenţa unei valori. Prin urmare, null trebuie tratat în

5

mod diferit faţă de alte valori şi trebuie înţeles că termenul „valoare nulă“

este depreciativ.

Evident, este necesară o aritmetică şi o logică (polivalentă) nouă

(fig.3.1) care să cuprindă acest element. De exemplu, ce valoare are „10 >

null“ ? Răspunsul este null. În general, rezultatul operaţiilor aritmetice sau

logice este null când unul din operanzi este null. Prin urmare, „null = null“

are valoarea null, iar null este null.

Întroducerea null-urilor în modelul relaţional constituie o problemă

controversată, deşi Codd tratează null ca parte integrantă a modelului. Alţii

consideră această abordare greşită şi prematură. Trebuie remarcat că nu toate

sistemele relaţionale acceptă null-urile.

AND T F Null OR T F Null

T T F Null T T T T

F F F F F T F Null

Null Null F Null Null T Null Null

Fig. 3.1. Tabele de adevăr pentru operatorii AND şi OR

Tabelul vizualizare (view, filtru, relaţie virtuală, vedere) constituie un

filtru asupra tabelului iniţial, care conţine numai informaţia necesară unei

anumite abordări sau aplicaţii. De fapt, vizualizarea este o expresie

relaţională căreia i se atribuie un nume.

Dacă baza de date conţine tabele reale depuse pe disc, o vizualizare

este virtuală deoarece datele pe care le conţine nu sunt în realitate memorate

într-o bază de date. Este memorată numai definiţia vizualizării. Vizualizarea

nu este definită explicit, ca relaţiile de bază, prin mulţimea tuplurilor

componente, ci implicit, pe baza altor relaţii obţinute prin intermediul unor

expresii relaţionale. Stabilirea efectivă a tuplurilor care compun vizualizarea

se realizează prin evaluarea expresiei atunci când utilizatorul se referă la

acest tabel.

Utilizarea vizualizărilor este avantajoasă, deoarece:

asigură securitatea tabelului iniţial (care este protejat de ştergeri,

6

modificări etc.) prin capacitatea de a ascunde datele;

permit vizualizarea simultană a aceloraşi date de către diverşi utilizatori;

sunt concise, punând la dispoziţie capacităţi „macro“;

asigură independenţa logică faţă de date (imunitatea programelor de aplicaţie faţă de modificările din structura logică a bazei de date).

Există totuşi limitări în utilizarea acestor tabele, în special legate de problema reactualizării. De exemplu, coloanele calculate nu pot fi

reactualizate. De asemenea, inserarea, reactualizarea şi ştergerea nu sunt, în general, recomandate şi sunt permise numai cu anumite restricţii care sunt specifice fiecărui SGBD. De exemplu, Oracle9i rezolvă problema dificilă a reactualizării vizualizărilor, în anumite situaţii, utilizând o clasă specială de declanşatoare (TRIGGER de tip INSTEAD OF).

3.2.2. Reguli de integritate

Regulile de integritate sunt aserţiuni pe care datele conţinute în baza

de date trebuie să le satisfacă. Trebuie făcută distincţia între regulile

structurale care sunt inerente modelării datelor şi regulile de funcţionare (comportament) care sunt specifice unei aplicaţii particulare.

Există trei tipuri de constrângeri structurale (de cheie, de referinţă, de entitate) ce constituie mulţimea minimală de reguli de integritate pe care trebuie să le respecte un SGBD relaţional. Restricţiile de integritate

minimale sunt definite în raport cu noţiunea de cheie a unei relaţii. O mulţime minimală de atribute ale căror valori identifică unic un

tuplu într-o relaţie reprezintă o cheie pentru relaţia respectivă. Prin urmare, o cheie a unei relaţii R este o mulţime K de atribute,

astfel încât:

(1) pentru orice două tupluri t1, t2 ale lui R t1(K) t2(K);

(2) nu există nicio submulţime proprie a lui K având proprietatea (1).

Fiecare relaţie are cel puţin o cheie. Dacă există diferite chei posibile, ele se numesc chei candidat. Una dintre cheile candidat va fi aleasă pentru a identifica efectiv tupluri şi ea va primi numele de cheie primară. Cheia primară nu poate fi reactualizată. Restul cheilor candidat vor purta numele de chei alternative sau secundare. Atributele care reprezintă cheia primară pot fi

subliniate sau urmate de semnul „#“. O cheie identifică linii şi este diferită de un index care localizează

liniile.

7

Fie schemele relaţionale R1(P1, S1) şi R2(S1, S2), unde P1 este cheie primară pentru R1, S1 este cheie secundară pentru R1, iar S1 este cheie primară pentru R2. În acest caz, vom spune că S1 este cheie externă (cheie străină) pentru relaţia R1.

De exemplu, cod_casa_moda este cheie externă pentru relaţia CREATOR şi este cheie primară pentru relaţia CASA_MODA. Cheia primară poate conţine cheia externă. De exemplu, relaţia ACCESORIU are cheia primară formată din atributele cod_accesoriu şi cod_vestimentatie, iar atributul cod_vestimentatie fiind cheie primară în relaţia VESTIMENTATIE, devine cheie externă în relaţia ACCESORIU.

Modelul relaţional respectă trei reguli de integritate structurală.

Regula 1 – unicitatea cheii. Cheia primară trebuie să fie unică şi minimală.

Regula 2 – integritatea entităţii. Atributele cheii primare trebuie să fie diferite de null.

Regula 3 – integritatea referirii. O cheie externă trebuie să fie ori null în întregime, ori să corespundă unei valori a cheii primare asociate.

3.2.3. Operatorii modelului relaţional Operatorii modelului relaţional definesc operaţiile care se pot efectua

asupra relaţiilor în scopul realizării funcţiilor de prelucrare asupra bazei de date. Modelul relaţional oferă două mulţimi de operatori pe relaţii, şi anume: algebra relaţională şi calculul relaţional. La rândul său, calculul relaţional este de două tipuri: orientat pe tupluri sau orientat pe domenii.

Operatorii algebrei relaţionale sunt fie operatori tradiţionali pe

mulţimi (UNION, INTERSECT, PRODUCT, DIFFERENCE), fie operatori

relaţionali speciali (PROJECT, SELECT, JOIN, DIVISION).

8

3.3. Proiectarea modelului relaţional

Proiectarea bazelor de date este mai mult o artă, decât o ştiinţă. Pot

exista criterii obiective care să favorizeze o abordare în raport cu celelalte.

În cursul 2 s-a prezentat o abordare (proiectarea modelului E/R) care

are meritul că este frecvent utilizată în practică.

Pentru rafinarea proiectării modelului de date, pentru obţinerea

schemei conceptuale a bazei de date relaţionale, se pleacă de la o formă de

modelare semantică specială a datelor, mai precis de la diagrama E/R.

In acest curs se va prezenta schema conceptuală.

Ideea generală este de a reprezenta entităţile şi legăturile dintre

acestea sub forma unor tabele speciale (relaţii). Vor fi prezentate 9 reguli

care arată maniera în care se transformă entităţile, relaţiile şi atributele

acestora, în vederea obţinerii schemei conceptuale.

Ca formalism, în diagrama conceptuală, simbolul „ “ indică

plasamentul cheii externe. Dacă simbolul este subliniat („ “), se exprimă şi

faptul că respectiva cheie externă este conţinută în cheia primară.

3.3.1. Transformarea entităţilor

Entităţile independente devin tabele independente. Cheia primară

nu conţine chei externe. De exemplu, entitatea independentă

PREZENTARE generează un tabel independent pentru care

atributul cod_prezentare reprezintă cheia primară.

Entităţile dependente devin tabele dependente. Cheia primară a

entităţilor dependente conţine cheia primară a entităţii de care

depinde (cheie externă) plus unul sau mai multe atribute

adiţionale. De exemplu, cheia primară a entităţii dependente

ACCESORIU este formată din atributul cod_vestimentatie, care

reprezintă cheia primară a entităţii de care depinde

(VESTIMENTATIE), plus atributul adiţional cod_accesoriu.

Subentităţile devin subtabele. Cheia externă se referă la

supertabel, iar cheia primară este această cheie externă. De

exemplu, cheia primară a subentităţii MODEL este cod_angajat

care este o cheie externă (cheie primară a entităţii

ANGAJAT_TEMP).

9

3.3.2. Transformarea relaţiilor

Relaţiile 1:1 şi 1:n devin chei externe. De exemplu, relaţia creeaza

(CREATOR_creeaza_VESTIMENTATIE) devine coloană în

tabelul VESTIMENTATIE. Atributul cod_creator, care este cheie

primară în tabelul CREATOR, va fi cheie externă în tabelul

VESTIMENTATIE. Relaţia 1:1 plasează cheia externă în tabelul cu

mai puţine linii.

Relaţia m:n devine un tabel special, numit tabel asociativ, care are

două chei externe pentru cele două tabele asociate. Cheia primară este compunerea acestor două chei externe plus eventuale coloane

adiţionale. Un tabel asociativ se desenează punctat. De exemplu,

relaţia participa (CASA_MODA_participa_PREZENTARE), care

este de tip m:n, devine tabel asociativ având cheia primară formată

din atributele cod_casa_moda şi cod_prezentare.

Relaţiile de tip trei devin tot tabele asociative. De exemplu, relaţia

primeste ce leagă entităţile ANGAJAT_TEMP, PREZENTARE şi

CASA_MODA, devine tabel asociativ. Cheia primară a tabelului este compunerea a trei chei externe: cod_angajat, cod_casa_moda

şi cod_prezentare. Practic, în acest caz, este preferabil să fie

introdusă o cheie primară artificială.

3.3.3. Transformarea atributelor

Un atribut singular devine o coloană.

Atributele multiple devin tabele dependendente ce conţin cheia

primară a entităţii şi atributul multiplu. Cheia primară este formată

dintr-o cheie externă, plus una sau mai multe coloane adiţionale. De exemplu, o persoană de contact poate cunoaşte mai multe limbi

străine. În acest caz, atributul limba_cunoscuta este multiplu şi va

genera tabelul dependent LIMBA.

Entităţile devin tabele, iar atributele lor devin coloane în aceste tabele. Ce devin atributele relaţiilor? Pentru relaţii 1:1 şi 1:n,

atributele relaţiilor vor aparţine tabelului care conţine cheia

externă, iar pentru relaţii m:n şi de tipul trei, atributele vor fi

plasate în tabelele asociative.

10

Tabel Reprezintă Cheie primară

Independent entitate independentă nu conţine chei externe

Subtabel subentitate o cheie externă

Dependent entitate dependentă o cheie externă şi una sau mai

multe coloane adiţionale Atribut multiplu

Asociativ relaţie m:n două sau mai multe chei externe

şi (opţional) coloane adiţionale relaţie de tip 3

Fig. 3.2. Clasificarea tabelelor

11

Fig. 3.3. Diagrama conceptuală.

FIRMA_PUB

PUBLICITATE

PREZENTARE

ORGANIZATOR PERS_CONTACT

LOCATIE

INFO_CONTACT

LOCALIZARE

SPONSOR ANGAJAT_SEC

FIRMA_SEC

CASA_MODA

CREATOR

VESTIMENTATIE

ACCESORIU

ANGAJAT_TEMP

MODEL

ISTORIC

SOC_ASIG

AGENTIE are

refera are

creeaza

lucreaza

prezinta

face

asigura

are

se_face

face

organizeaza

are

are

are

are

prezinta lucreaza_la

×

× × ×

×

×

× ×

×

×

× ×

×

× ×

PRIMESTE ×

PARTICIPA

PAZA FINANTEAZA

LIMBA

cunoaste

12

Cele patru tipuri de tabele (independente, dependente, subtabele şi

asociative) se deosebesc prin structura cheii primare (figura 3.2.).

În figura 3.3 este prezentată diagrama conceptuală pentru proiectarea

modelului relaţional comentat. Ea a fost construită din diagrama E/R prin

adăugarea tabelelor asociative şi prin marcarea cheilor externe.

În continuare va fi prezentată modalitatea efectivă de trecere de la

diagrama entitate-relaţie la diagrama conceptuală pentru modelul de date

real analizat în capitolul 2.

Entităţile independente PERS_CONTACT, ORGANIZATOR,

PREZENTARE, PUBLICITATE, SPONSOR, FIRMA_PUB,

CASA_MODA, CREATOR, ANGAJAT_TEMP, VESTIMENTATIE,

LOCALIZARE, FIRMA_SEC, ANGAJAT_SEC, SOCIETATE_ASIG,

INFO_CONTACT, AGENTIE, LOCATIE devin tabele independente.

Cheile primare ale fiecărei entităţi au fost specificate în capitolul 2.

Entităţile dependente ISTORIC şi ACCESORIU, care intervin în

model, devin tabele dependente, iar cheile primare au fost specificate în

capitolul 2.

Subentitatea MODEL devine subtabel, având aceeaşi cheie primară cu

superentitatea ANGAJAT_TEMP, adică atributul cod_angajat.

Relaţiile de tip one-to-one şi one-to-many devin chei externe.

Relaţia PERS_CONTACT_are_LOCALIZARE devine cheie externă în

tabelul PERS_CONTACT. Dacă restricţia că o persoană de contact are o

singură localizare este eliminată, atunci cardinalitatea relaţiei devine 1:n, iar

atributul cod_pers_contact devine cheie externă în tabelul LOCALIZARE.

Toate comentariile anterioare rămân valabile şi pentru entităţile

FIRMA_PUB, FIRMA_SEC, PREZENTARE, ORGANIZATOR,

CASA_MODA, SPONSOR, SOC_ASIG, CREATOR, LOCATIE,

ANGAJAT_TEMP şi AGENTIE, care sunt legate de entitatea

LOCALIZARE, permiţând astfel localizarea tuturor structurilor modelului.

Relaţia PERS_CONTACT_are_INFO_CONTACT devine cheie externă în

tabelul PERS_CONTACT. Dacă restricţia că pentru o persoană de contact

există o singură posibilitate de contactare este eliminată, atunci

cardinalitatea relaţiei devine 1:n, iar atributul cod_pers_contact devine cheie

externă în tabelul INFO_CONTACT. Toate comentariile anterioare rămân

valabile şi pentru entităţile FIRMA_PUB, FIRMA_SEC,

ANGAJAT_TEMP, PREZENTARE, ORGANIZATOR, CASA_MODA,

SPONSOR, SOC_ASIG, CREATOR, LOCATIE şi AGENTIE, care sunt

legate de entitatea INFO_CONTACT, permiţând astfel accesarea tuturor

structurilor modelului.

13

Relaţia FIRMA_PUB_face_PUBLICITATE devine cheie externă în tabelul

PUBLICITATE. Relaţia PUBLICITATE_se_face_pentru_PREZENTARE devine cheie externă în tabelul PUBLICITATE. Relaţia ORGANIZATOR_are_PERS_CONTACT devine cheie externă în tabelul PERS_CONTACT. Relaţia FIRMA_SEC_are_ANGAJAT_SEC devine cheie externă în tabelul ANGAJAT_SEC. Relaţia SOC_ASIG_asigura_PREZENTARE devine cheie externă în tabelul PREZENTARE. Relaţia CASA_MODA_lucreaza_CREATOR devine cheie externă în tabelul CREATOR. Relaţia CREATOR_creeaza_VESTIMENTATIE devine cheie externă în tabelul VESTIMENTATIE. Relaţia VESTIMENTATIE_are_ACCESORIU devine cheie externă în tabelul ACCESORIU. Relaţia MODEL_prezintă_VESTIMENTATIE devine cheie externă în tabelul VESTIMENTATIE. Relaţia CREATOR_face_ACCESORIU devine cheie externă în tabelul ACCESORIU. Relaţia PREZENTARE_prezinta_VESTIMENTATIE devine cheie externă în tabelul VESTIMENTATIE. Relaţia PREZENTARE_are_LOCATIE devine cheie externă în PREZENTARE. Relaţia MODEL_lucreaza_AGENTIE devine cheie externă în tabelul MODEL. Relaţia MODEL_are_ISTORIC devine cheie externă în tabelul ISTORIC. Relaţia ISTORIC_refera_AGENTIE devine cheie externă în tabelul ISTORIC.

Relaţiile de tip many-to-many devin tabele asociative, având două chei externe pentru cele două tabele asociate. Relaţia ANGAJAT_SEC_paza_PREZENTARE devine tabel asociativ (PAZA). SPONSOR_finanteaza_PREZENTARE devine tabel asociativ (FINANTEAZA). CASA_MODA_participa_PREZENTARE devine tabel asociativ (PARTICIPA).

Relaţiile de tipul trei (adică cele care leagă cel puţin trei entităţi) devin tabele asociative, având chei externe pentru fiecare dintre tabelele asociate.

14

Relaţia primeste, care leagă entităţile ANGAJAT_TEMP, PREZENTARE şi CASA_MODA, devine tabel asociativ (PRIMESTE). În acest caz, s-a considerat o cheie primară artificială (atributul cod_primeste). Tabelul asociativ are drept chei externe atributele: cod_angajat, cod_casa_moda şi cod_prezentare.

Atributele multiple devin tabele dependendente ce conţin cheia primară a entităţii şi atributul multiplu. Atributul limba_cunoscuta este multiplu (relativ la entitatea PERS_CONTACT) şi va genera tabelul dependent LIMBA. Acesta va avea drept cheie primară atributele cod_pers_contact şi limba_cunoscuta. Tabelul mai conţine trei atribute ce reprezintă nivelul de cunoaştere (scris, citit, vorbit) a limbii.

Atributele entităţilor devin coloane în tabelele corespunzătoare. Pentru

relaţii 1:1 şi 1:n, atributele relaţiilor vor aparţine tabelului care conţine cheia

externă, iar pentru relaţii m:n şi de tipul trei, atributele vor fi plasate în

tabelele asociative.

Tabelul asociativ PRIMESTE va avea ca atribute, pe lângă cele ce constituie

cheia primară, suma, data_achitare, cont, banca.

Schemele relaţionale corespunzătoare diagramei conceptuale din

figura 3.3. sunt următoarele:

MODEL(cod_angajat#, cod_agentie, inaltime, nr_pantof, info)

ANGAJAT_TEMP(cod_angajat#, nume, prenume, data_nastere,

nationalitate, sex, cod_localizare, cod_info_acces, tip)

PUBLICITATE(cod_publicitate#, cod_firma_pub, cod_prezentare, tip,

nume, suma, observatii)

FIRMA_PUB(cod_firma_pub#, nume, info, director, observatii,

cod_localizare, nume_pers_contact, cod_info_acces)

ORGANIZATOR(cod_organizator#, denumire, banca, cont, cod_info_acces,

informatii, cod_localizare)

PERS_CONTACT(cod_pers_contact#, cod_organizator, nume, prenume,

directie, cod_localizare, cod_info_acces)

PREZENTARE(cod_prezentare#, denumire, data_start, data_final,

cod_soc_asig, cod_organizator, cod_locatie)

LOCATIE(cod_locatie#, denumire, tip, cod_localizare, cod_info_acces,

capacitate)

SPONSOR(cod_sponsor#, tip, nume, info, cod_localizare, cod_info_acces)

15

CASA_MODA(cod_casa_moda#, nume, cifra_afaceri, proprietar, director,

istoric, data_creare, cod_localizare, cod_info_acces)

CREATOR(cod_creator#, nume, prenume, data_nastere, data_angajare, tip,

mod_angajare, info, cod_casa_moda, cod_localizare, cod_info_acces)

VESTIMENTATIE(cod_vestimentatie#, denumire, valoare, descriere,

cod_creator, cod_model, cod_prezentare)

ACCESORIU(cod_vestimentatie#, cod_accesoriu#, cod_creator, descriere,

tip, valoare)

AGENTIE(cod_agentie#, nume, data_creare, director, cifra_afaceri, info,

cod_localizare, cod_info_acces)

ISTORIC(cod_model#, data_angajare#, data_final, cod_agentie, conditii)

LOCALIZARE(cod_localizare#, adresa, cod_postal, oras, tara)

INFO_CONTACT(cod_info_acces#, telefon_fix, telefon_mobil, mail, fax)

FIRMA_SEC(cod_firma_sec#, nume_firma, tip_servicii, director,

cod_localizare, cod_info_acces, observatii)

ANGAJAT_SEC(cod_angajat#, nume, prenume, data_nastere, specializare,

nivel, observatii, cod_info_acces, cod_firma_sec)

PAZA(cod_angajat#, cod_prezentare#, tip_paza, dotare, observatii)

SOC_ASIG(cod_soc_asig#, conditii, suma, director, observatii,

cod_localizare, nume_pers_contact_firma, cod_info_acces)

PARTICIPA(cod_prezentare#, cod_casa_moda#, tip, data)

FINANTEAZA(cod_sponsor#, cod_prezentare#, suma, banca, cont_emitent,

data_emitere, cod_ordin_plata)

PRIMESTE(cod_primeste#, cod_angajat, cod_prezentare, cod_casa_moda,

data_achitare, suma, cont, banca)

LIMBA(cod_pers_contact#, limba_cunoscuta#, niv_scris, niv_citit,

niv_vorbit)

16

3.4. Regulile lui Codd

Un SGBD relaţional îndeplineşte funcţiile unui SGBD, dar cu anumite particularităţi care decurg din concepţia de organizare a datelor, respectiv din modelul relaţional. Fiecare SGBD relaţional implementează modelul relaţional într-o manieră proprie, care îl diferenţiază de restul sistemelor relaţionale.

În anul 1985, E.F. Codd a publicat un set de 13 reguli în raport cu care un sistem de gestiune a bazelor de date poate fi apreciat ca relaţional. Niciun sistem de gestiune a bazelor de date pus în vânzare pe piaţa comercială nu respectă absolut toate regulile definite de Codd, dar acest lucru nu împiedică etichetarea acestor sisteme drept relaţionale. Nu trebuie apreciat un SGBD ca fiind relaţional sau nu, ci măsura în care acesta este relaţional, deci numărul regulilor lui Codd pe care le respectă.

Regulile lui Codd au fost şi sunt cauza multor controverse. Unii le consideră doar un exerciţiu academic, alţii pretind că produsele lor satisfac majoritatea regulilor. De fapt, discuţiile în jurul acestor reguli au generat o cunoaştere mai bună a caracteristicilor esenţiale ale unui SGBD relaţional, atât din punctul de vedere al utilizatorilor, cât şi din cel al producătorilor de software.

Regulile pot fi organizate în următoarele cinci domenii de funcţionalitate: reguli fundamentale, reguli structurale, reguli de integritate, reguli de prelucrare a datelor şi reguli privind independenţa datelor.

Regula 1 – regula gestionării datelor. Un SGBD relaţional trebuie să fie capabil să gestioneze o bază de date prin posibilităţile sale relaţionale. Practic, nicio implementare curentă de SGBD nu respectă această regulă, deoarece implementările conţin atât caracteristici relaţionale cât şi nerelaţionale.

Regula 2 – regula reprezentării informaţiei. Într-o bază de date relaţională, informaţia este reprezentată la nivel logic sub forma unor tabele ce poartă numele de relaţii. Este regula cea mai importantă şi conform lui Codd, un SGBD care nu respectă această regulă, nu poate fi considerat relaţional. Chiar şi meta-datele, conţinute în catalogul de sistem, trebuie să fie stocate ca relaţii.

Regula 3 – regula accesului garantat la date. Fiecare valoare dintr-o bază de date relaţională trebuie să poată fi adresată în mod logic printr-o

17

combinaţie formată din numele relaţiei, valoarea cheii primare şi numele atributului.

Regula 4 – regula reprezentării informaţiei necunoscute. Un sistem relaţional trebuie să permită utilizatorului definirea unui tip de date numit „null“ pentru reprezentarea unei informaţii necunoscute la momentul respectiv. Într-un SGBD relaţional trebuie să putem face diferenţa între valoarea zero, un şir vid de caractere şi o valoare necunoscută.

Regula 5 – regula dicţionarelor de date. Asupra descrierii bazelor de date (informaţii relative la relaţii, vizualizări, indecşi etc.) trebuie să se poată aplica aceleaşi operaţii ca şi asupra datelor din baza de date. Descrierea bazei de date este reprezentată la nivel logic sub forma unor tabele care pot fi accesate în acelaşi mod ca şi datele efective. Prin urmare există un singur limbaj de prelucrare atât a meta-datelor, cât şi a datelor.

Regula 6 – regula limbajului de interogare. Trebuie să existe cel puţin un limbaj pentru prelucrarea bazei de date. În general, toate implementările SQL respectă această regulă. Limbajul permite utilizatorilor să definească relaţii şi vizualizări, să prelucreze datele interactiv sau prin intermediul programului, să regăsească informaţia şi să o poată actualiza, să verifice şi să corecteze datele de intrare, să implementeze constrângeri, să stabilească limite pentru tranzacţii etc.

Regula 7 – regula de actualizare a vizualizării. Un SGBD trebuie să poată determina dacă o vizualizare poate fi actualizată şi să stocheze rezultatul interogării, ce defineşte vizualizarea, într-un dicţionar de tipul unui catalog de sistem. Trebuie să existe un mecanism prin care să se poată determina dacă anumite vizualizări pot fi actualizate sau nu. Regula stabileşte că toate vizualizările care sunt teoretic reactualizabile pot fi reactualizate şi de către sistemul de gestiune. Nu au fost încă descoperite condiţiile pentru identificarea tuturor vizualizărilor care pot fi teoretic reactualizate.

Regula 8 – regula limbajului de nivel înalt. Capacitatea de tratare a unei relaţii de bază sau a unei vizualizări ca pe un singur operand se aplică atât pentru operaţiile de regăsire a datelor, cât şi asupra operaţiilor de inserare, actualizare şi ştergere a datelor. Un SGBD relaţional nu trebuie să oblige utilizatorul să caute într-o relaţie, tuplu cu tuplu, pentru a regăsi informaţia dorită. Operaţiile de prelucrare a datelor pot să fie aplicate atât în mod interactiv cât şi prin program, într-un limbaj gazdă.

Regula 9 – regula independenţei fizice a datelor. Programele de aplicaţie şi activităţile utilizatorilor nu depind de modul de depunere a datelor sau de modul de acces la date. Într-un SGBD relaţional trebuie să se

18

separe aspectul fizic al datelor (stocare sau acces la date) de aspectul logic al datelor.

Regula 10 – regula independenţei logice a datelor. Programele de aplicaţie trebuie să fie transparente la modificările de orice tip efectuate asupra datelor. Orice modificare efectuată asupra unei relaţii nu trebuie să afecteze operaţiile de prelucrare a datelor.

Regula 11 – regula independenţei datelor din punct de vedere al inte-

grităţii. Regulile de integritate trebuie să fie definite într-un sublimbaj

relaţional de date, nu în programul de aplicaţie. SQL permite definirea de

restricţii privind integritatea datelor şi stocarea lor în catalogul de sistem. Cu

cât sunt mai multe constrângeri de integritate care pot fi întreţinute mai

degrabă de către SGBD, decât în cadrul fiecărui program aplicaţie, cu atât

garantarea calităţii datelor este mai bună.

Regula 12 – regula independenţei datelor din punct de vedere al

distribuirii. Distribuirea datelor pe mai multe calculatoare dintr-o reţea de

comunicaţii de date nu trebuie să afecteze programele de aplicaţie. ANSI-

SQL nu menţionează regula în specificaţiile sale, deoarece este destul de

greu de respectat. De observat că regula nu cere ca SGBD-ul să accepte o

bază de date distribuite pentru a fi relaţional, dar stabileşte că limbajul de

interogare va rămâne acelaşi atunci când se va introduce această capacitate,

iar datele vor fi distribuite.

Regula 13 – regula versiunii procedurale a unui SGBD. Orice

componentă procedurală a unui SGBD trebuie să respecte aceleaşi restricţii

de integritate ca şi componenta relaţională. De exemplu, dacă în partea de

prelucrare a datelor a limbajului relaţional valoarea dintr-o coloană este de

tipul not null, orice altă metodă procedurală de accesare a acestei coloane nu

trebuie să permită introducerea unui null în această coloană. Prin urmare,

regulile de integritate exprimate într-un limbaj relaţional de un anumit nivel

nu pot fi distruse de un limbaj de nivel inferior.

Deoarece regulile lui Codd sunt prea severe pentru a fi respectate de

un SGBD operaţional, s-au formulat criterii minimale de definire a unui

SGBD relaţional.

Un SGBD este minimal relaţional dacă:

toate datele din cadrul bazei sunt reprezentate prin valori în tabele;

nu există pointeri observabili de către utilizator;

19

sistemul suportă operatorii relaţionali de proiecţie, selecţie şi

compunere naturală, fără limitări impuse din considerente interne.

Un SGBD este complet relaţional dacă este minimal relaţional şi

satisface în plus condiţiile:

sistemul suportă restricţiile de integritate de bază (unicitatea cheii

primare, constrângerile referenţiale, integritatea entităţii);

sistemul suportă toate operaţiile de baza ale algebrei relaţionale.