Curs 2 – Baze de date

1. Modelul relaţional. Baze de date relaţionale.

Modelul relaţional reprezintă datele sub forma unor structuri bidimensionale,
asemănătoare tabelelor. Conceptele teoretice care formează baza modelului relaţional au
apărut la începutul anilor ’70, în principal datorită lui Edgar F. Codd.
Modelul relaţional nu este orientat spre sistemul de calcul, adică modelul nu include
regulile, structurile şi operaţiile referitoare la implementarea fizică a unui sistem de baze de
date. De fapt, unul din principalele obiective ale sistemului relaţional este separarea clară între
aspectele fizice şi cele logice ale unei baze de date.
În acelaşi timp, modelul relaţional şi operaţiile folosite de către acesta au la bază o
riguroasă fundamentare matematică; se bazeaza pe algebra relaţională şi calculul relaţional.
Deşi are la rândul lui imperfecţiuni, modelul relaţional a devenit în ultima vreme
principalul model de baze de date şi a fost adoptat de majoritatea producătorilor de software
din acest domeniu. Principalele sale avantaje sunt simplitatea, fundamentarea matematică
riguroasă şi independenţa datelor, adică separarea aspectelor logice ale acestora de cele fizice.

1.1. Concepte de bază ale modelului relaţional

În general, definirea unui model de date presupune precizarea şi identificarea
următoarelor elemente:
 Structurile de date folosite;
 Operatorii care acţionează asupra structurilor de date;
 Restricţii care trebuie impuse pentru menţinerea corectitudinii datelor, numite şi
restricţii de integritate.

O bază de date relaţională este compusă dintr-o mulţime finită de relaţii(tabele), fiecare
relaţie reprezentând un tip de entitate sau o asociere dintre două sau mai multe tipuri
(mulţimi) de entităţi.
În modelul relaţional datele sunt reprezentate ca structuri bidimensionale, numite
relaţii. O relaţie este alcătuită dintr-un număr fix de elemente numite atribute, fiecare dintre
acestea putând lua valori într-o mulţime finită, numită domeniu. Numărul de atribute al unei
relaţii se numeşte aritatea relaţiei.

Relaţie(atribut_1, atribut_2, …, atribut_n)

De exemplu datele despre angajaţii unei firme se pot reprezenta ca o relaţie de aritate
7, după cum urmează:

Salariat(cod_salariat, nume, prenume, adresa, dată_naştere, sex, cod_departamant)

Elementele unei relaţii se numesc tupluri sau înregistrări. De obicei relaţiile sunt
reprezentate sub forma unor tabele, în care fiecare rând reprezintă un tuplu şi fiecare coloană
reprezintă valorile tuplurilor corespunzătoare unui anumit atribut.
Cod_ nume prenume adresa dată_nastere sex cod_
Salariat departament
S1 Ion Cosmin Str. Jiului nr.3 01/01/1970 M D1
S2 Popescu Vasile 15/11/1956 M D1
S3 Ionescu Gina Str. Valea Albă 28/02/1976 F D2
S4 Costache Viorel Str. Siret nr.5 12/02/1975 M D2
 Relaţiile ce constituie o bază de date trebuie să satisfacă mai multe condiţii, după cum
urmează:

C1. Fiecare atribut trebuie să poarte un nume, care este unic în cadrul relaţiei. Modelul
relaţional nu permite ca două atribute din cadrul aceleiaşi relaţii să poarte acelaşi nume. Pe de
altă parte, este posibil ca două atribute din două relaţii diferite să poarte acelaşi nume.

C2. Fiecare atribut poate avea două valori atomice, deci care nu se pot descompune din
punct de vedere logic. Să presupunem, de exemplu, că un producător de automobile atribuie
fiecărui automobil fabricat un cod de identificare, care se obţine prin concatenarea mai multor
coduri, reprezentând marca automobilului, culoarea, fabrica unde este produs, seria şi numărul
de fabricaţie, etc. Atunci, definirea acestui cod de identificare ca atribut al unei relaţii ar
încălca această regulă, deoarece fiecare valoare a atributului s-ar putea descompune în mai
multe valori cu semnificaţie logică.

C3. Fiecare tuplu este unic. Nu sunt permise tupluri identice (duplicat). În plus, unicitatea
unui tuplu nu este limitată la datele existente: fiecare tuplu trebuie să fie unic tot timpul.

Aceasta înseamnă că într-o relaţie există întotdeauna una sau mai multe atribute care
asigură că tuplul va rămâne unic tot timpul. Un atribut sau set de atribute care identifică în
mod unic un tuplu se numeşte cheie candidată sau mai simplu cheie. Pentru fiecare relaţie se
alege din mulţimea cheilor candidate o cheie care se numeşte cheie primară a relaţiei.
Eventualele alte chei candidate, diferite de cheia primară, se numesc chei alternative. Când
mai mult de un singur atribut este necesar pentru a crea o cheie, se spune că avem o cheie
compusă. În cazul unei chei compuse, atributele care fac parte din cheie sunt alese astfel încât
nici unul să nu fie în plus, adică nici un atribut nu poate fi şters din cheia candidată astfel încât
partea care rămâne din cheia candidată să identifice încă în mod unic tuplurile; de aceea, se
spune că o cheie trebuie să fie minimală.
Uneori, în unele tupluri dintr-o relaţie, un atribut poate fi necunoscut sau neaplicabil.
Pentru a reprezenta un astfel de atribut se foloseşte o valoare convenţională, notată cu Null.
Ca regulă generală, nici unul din atributele care alcătuiesc cheia primară nu poate avea
valoarea Null pentru nici unul din tuplurile relaţiei.

Exemplu:
Pentru relaţia salariat definită mai sus, o cheie candidată este cod_salariat. Dacă se
presupune că nume, prenume şi dată_naştere identifică în mod unic salariatul, atunci combinaţia
acestor trei atribute este o altă cheie candidată, care, datorită faptului că este alcătuită din mai
multe atribute, este şi cheie compusă. Dacă cheia cod_salariat este aleasă cheie primară, atunci
combinaţia celor trei atribute (nume, prenume, dată_naştere) devine cheie alternativă.
În alegerea cheilor candidate s-a ţinut cont de principiul minimalităţii în sensul că din
cheia compusă nume, prenume şi dată_naştere nu poate fi şters nici un atribut şi nici nu mai
trebuie adăugat altul, aceste trei atribute identificând în mod unic tuplurile. De exemplu,
combinaţia (nume, prenume, dată_naştere, cod_departament) nu este o cheie a relaţiei salariat
pentru că şi în absenţa atributului cod_departament, un salariat este identificat în mod unic de
primele trei atribute. Observăm că tuplul identificat prin valoarea cheii primare egală cu S2
are atributul adresa necunoscut, adică acesta area valoarea Null. Prin urmare, atributul adresa
nu poate fi cheie primară şi nici nu poate intra în componenţa unei chei compuse care este şi
cheie primară.
Se numeşte cheie străină un atribut sau o mulţime de atribute ale unei relaţii R1 care
există şi într-o altă relaţie R2, nu neapărat distinctă de R1, şi care formează cheia primară a
relaţiei R2. În cazul acesta, cheia străină din R1 se spune că face referinţă la cheia primară din
R2. Valorile pe care le ia cheia străină, dacă nu au valoarea Null, trebuie să se găsească printre
valorile cheii primare la care face referinţă.
 Exemplu:
Dacă mai definim o relaţie de aritate 3, după urmează:
departament (cod_departament, denumire, localitate)
cod_departament denumire localitate
D1 Analiză financiară Bucureşti
D2 Depozit Piteşti
D3 Contabilitate Constanţa
D4 Magazin Piteşti

pentru evidenţa departamentelor din firmă, atributul cod_departament din relaţia salariat
devine cheie străină care face referinţă la cheia primară a relaţiei departament. Valoarea cheii
străine cod_departament, din relaţia salariat trebuie ori să fie Null, ori să coincidă cu o valoare a
cheii primare la care face referinţă. Prin urmare, dacă atributul cod_departament, din relaţia
salariat ar fi avut pentru un anumit tuplu valoarea D5, valoare ce nu se regăseşte printre
valorile cheii primare cod_departament, din relaţia departament, atunci s-ar fi încălcat o regulă
de integritate.

Există posibilitatea ca o cheie străină să facă referinţă la cheia primară a propriei

relaţii. Pentru a ilustra acest lucru, să adăugăm la relaţia salariat un nou atribut cod_manager,
reprezentând codul superiorului ierarhic al salariatului (facem presupunerea că un angajat
poate avea cel mult un superior ierarhic).

cod_salariat nume Prenume ….. cod_manager

S1 Ion Bucureşti …..
S2 Popescu Piteşti ….. S1
S3 Ionescu Constanţa ….. S2
S4 Costache Piteşti ….. S3
Deci salariatul cu codul S1 este superiorul ierarhic al salariaţilor cu codurile S2 şi S3,
salariatul cu codul S2 este superiorul ierarhic al salariatului cu codul S4, iar S1 nu are un
superior ierarhic.

C4. Navigaţia în cadrul modelului relaţional se face prin intermediul valorii pe care o ia un
atribut. Aceasta înseamnă că limbajul de interogare va prelua ca parametrii de intrare doar
numele unor atribute şi valorile posibile ale acestora, corespunzătoare cerinţelor utilizatorului,
şi va returna tuplurile care satisfac această cerinţă. Spre deosebire de alte modele, nu există
legături între tupluri şi deci nu există dependenţă de calea urmată.
C5. Tuplurile vor fi prezentate utilizatorului în orice ordine. Deci acesta nu trebuie să facă
nici o presupunere în privinţa ordinii tuplurilor.
C6. Atributele pot fi prezentate în orice ordine, deci utilizatorul nu trebuie să facă nici o
presupunere în privinţa ordinii acestora. Cu alte cuvinte, în modelul relaţional nu există
dependenţă de secvenţă. De exemplu, deşi relaţiile
Salariat(cod_salariat, nume, prenume, adresa, dată_naştere, sex, cod departament)
şi
Salariat(cod_salariat, nume, prenume, cod departament, dată_naştere, sex, adresa)

par diferite, ele sunt echivalente funcţional pentru că au atribute identice, chear dacă sunt în
altă ordine.
C7. Relaţiile pot fi manipulate pentru a furniza utilizatorului diferite vederi asupra datelor,
rezultatul fiind noi relaţii. Cu alte cuvinte, rezultatul manipulării relaţiilor sunt noi relaţii. În
plus, relaţiile produse ca rezultat al comenzilor limbajului de interogare a datelor satisfac toate
regulile la care sunt supuse relaţiile iniţiale.
 Constrângeri de integritate
Constrângerile de integritate (integrity constraints) sunt reguli care se definesc la
proiectarea unei bazei de date şi care trebuie să fie respectate de orice stare a acesteia.
Relaţiile unei baze de date reflectă realitatea modelată şi de aceea valorile pe care le
conţin trebuie să respecte anumite reguli, care să corespundă celor din realitate.
Constrângerile se pot clasifica după locul unde sunt definite şi după modul în care sunt
definite. Din punct de vedere al locului unde sunt definite, constrângerile pot fi constrângeri
intra-relaţie şi constrângeri inter-relaţii. Constrângerile intra-relaţie sunt reguli care se impun
în cadrul unei singure relaţii şi asigură integritatea datelor acesteia. Ele sunt, la rândul lor, de
trei categorii:
• Constrângeri de domeniu, care sunt condiţii ce se impun valorilor atributelor şi
asigură integritatea domeniilor atributelor.
• Constrângeri de tuplu, care sunt condiţii ce se impun tuplurilor unei relaţii şi
asigură identificarea corectă a tuplurilor prin intermediul cheilor (primare sau
candidate).
• Constrângeri impuse prin dependenţe de date (dependenţe funcţionale,
multivalorice sau de joncţiune); acestea sunt constrângeri prin care valorile unor
atribute ale unei relaţii determină valorile altor atribute ale aceleiaşi relaţii.
Constrângerile inter-relaţii sunt reguli care se impun între două sau mai multe relaţii.
Cele mai importante constrângeri inter-relaţii sunt constrângerile de integritarea referenţială,
care se realizează prin intermediul cheilor străine şi asigură asocierea corectă a relaţiilor.
Din punct de vedere al modului de definire, constrângerile unei baze date se pot
clasifica în constrângeri inerente, implicite şi explicite.
Constrângerile inerente sunt cele ale modelului de date însuşi, care nu trebuie să fie
specificate la definirea relaţiilor, dar sunt respectate prin modul în care se construiesc relaţiile.
De exemplu, în modelul relaţional constrângerea ca valoarea fiecărui atribut să fie atomică
(indivizibilă) este o constrângere inerentă.
Constrângerile implicite sunt reguli care se definesc odată cu definirea schemelor
relaţiilor (prin intermediul instrucţiunile de definire a datelor), sunt memorate în baza de date
şi sistemul de gestiune verifică şi impune automat respectarea acestora. Connstrângerile de
domeniu, constrângerile de tuplu şi constrângerile de integritate referenţială sunt exemple de
constrângeri implicite.
Constrângerile explicite sunt constrângeri suplimentare pe care trebuie să le respecte
relaţiile unei baze de date şi care nu sunt impuse automat de sistemul SGBD, ci necesită
proceduri speciale de verificare şi impunere a respectării lor. Ca exemple de constrângeri
explicite sunt unele dependenţe de date, şi anume cele care nu sunt determinate de cheile
relaţiilor. Dependenţele de date sunt prezentate în Capitolul 5.

2.3.1 Constrângeri de domeniu

Constrângerile de domeniu sunt condiţii impuse valorilor atributelor, astfel încât
acestea să corespundă semnificaţiei pe care o au în realitatea modelată. Dat fiind că, în
reprezentarea unei relaţiei printr-un tabel, valorile atributelor sunt reprezentate pe coloane,
constrângerile de domeniu se mai numesc şi constrângeri de coloană. Dintre constrângerile de
domeniu, constrângerea NOT NULL şi constrângerea de valoare implicită (DEFAULT) sunt
constrângeri cu caracter mai general, care se pot aplica oricărui atribut; constrângerea de
verificare (CHECK) se poate aplica unor anumite atribute, în funcţie de semnificaţia acestora.
Constrângerea NOT NULL. O valoare particulară pe care o poate lua un atribut este
valoarea NULL, care nu înseamnă zero, ci lipsă de informaţie. Valoarea NULL a unui atribut
într-un tuplu semnifică faptul că valoarea acelui atribut nu este cunoscută pentru acel tuplu
sau că acel atribut nu este aplicabil acelui tuplu.
Lipsa de informaţie (deci valoarea NULL a unui atribut) poate să apară în diferite
situaţii. De exemplu, într-o relaţie de înregistrare a datelor despre personalităţi istorice,
valoarea atributului DataNasterii poate să nu fie cunoscută pentru unele personalităţi şi în
aceste tupluri se trece valoarea NULL. Faptul că nu se cunoaşte data de naştere a unor
personalităţi nu trebuie să împiedice definirea acestui atribut care, pentru majoritatea
înregistrărilor, va avea valori cunoscute şi important să fie memorate.
O altă situaţie în care poate să fie folosită valoarea NULL a unui atribut este aceea în
care la înregistrarea unui tuplu nu se cunoaşte valoarea atributului, aceasta urmând să fie
completată ulterior.
Nu orice atribut poate lua valori de NULL. De exemplu, în relaţia
ANGAJATI(Nume,Prenume, DataNasterii,Adresa,Functie,Salariu) nu are sens să se
înregistreze un angajat al cărui nume nu se cunoaşte, deci nu se vor admite valori de NULL
pentru atributul Nume. În astfel de situaţii la definirea relaţiilor se impune atributului
constrângerea NOT NULL, însemnând că atributul respectiv nu poate lua valoare NULL în
nici un tuplu al relaţiei.
Constrângerea NOT NULL pentru un atribut se introduce la crearea unei relaţii (tabel)
prin comanda SQL CREATE TABLE. Opţiunea implicită (dacă nu se specifică nimic) este
admiterea valorilor de NULL. De exemplu, constrângerea NOT NULL pentru atributele Nume
şi Prenume ale relaţiei ANGAJATI se introduce astfel:
CREATE TABLE ANGAJATI(
Nume varchar(20) NOT NULL, Prenume
varchar(20) NOT NULL,...);
Valori implicite ale atributelor. În limbajul SQL2 sau la crearea bazelor de date în
orice SGBD se poate stabili o valoare implicită (DEFAULT) pentru un atribut al unei relaţii.
În cazul în care la inserarea unui tuplu nu se specifică valoarea unui atribut, atunci atributul
primeşte valoarea implicită (dacă a fost definită) sau valoarea NULL (dacă nu a fost definită o
valoare implicită pentru atributul respectiv, dar sunt admise valori NULL); dacă nu a fost
definită o valoare implicită şi nici nu sunt admise valori NULL, se generează o eroare.
În limbajul SQL2, valoarea implicită a unui atribut se poate specifica la crearea
tabelului corespunzător, ca o constrângere de coloană, împreună cu alte constrângeri. De
exemplu, la crearea tabelului STUDENTI, se poate specifica valoarea implicită pentru
atributul Tara astfel:
CREATE TABLE STUDENTI(
IdStudent int PRIMARY KEY,
Nume varchar (20) NOT NULL,
Prenume varchar (20) NOT NULL,
Tara varchar (20) DEFAULT (‘Romania’) NULL ) ;
Constrângerea de verificare (CHECK). În limbajul SQL2, domeniile se pot stabili ca
tipuri de date predefinite (tipuri numerice, şiruri de caractere de lungime fixă sau variabilă,
data calendaristică, timp). Pentru fiecare atribut, definit pe un tip de date SQL, se pot adăuga
constrângeri de verificare la definirea tabelului prin comanda CREATE TABLE. Forma
generală a unei constrângeri de verificare este:
[CONSTRAINT nume_constrangere] CHECK (conditie)
Numele constrângerii, precedat de cuvântul cheie CONSTRAINT este opţional.
Rezultatul evaluării expresiei care reprezintă condiţia specificată trebuie să fie o valoare
logică (TRUE, FALSE sau NULL). La introducerea (sau modificarea) valorilor atributelor se
admit numai acele valori pentru care conditia de verificare

13
ia valoarea TRUE. De exemplu, în relaţia ANGAJATI se poate introduce condiţia ca atributul Salariu
să aibă valori mai mari sau egale cu o valoare dată (salariul minim pe economie). Atunci, comanda
SQL de creare a tabelului ANGAJATI se completează astfel:
CREATE TABLE ANGAJATI(
Nume varchar(20) NOT NULL,
Prenume varchar(20) NOT NULL,
DataNasterii Date,
Adresa varchar (50),
Functie varchar (20),
Salariu numeric,
CHECK (Salariu >= 1500));
2.3.2 Constrângeri de tuplu - Cheia primară şi cheile secundare
O relaţie este definită ca o mulţime de tupluri, deci tuplurile unei relaţii trebuie să fie
distincte. Aceasta înseamnă că într-o relaţie nu pot exista două (sau mai multe) tupluri care să
conţină aceeaşi combinaţie de valori ale tuturor atributelor.
De obicei, într-o schemă de relaţie există o submulţime de atribute SK cu proprietatea că nu
există două tupluri distincte ale relaţiei (în orice stare s-ar afla relaţia), ti şi tj care să aibă aceeaşi
combinaţie de valori ale atributelor submulţimii respective, adică:
ti[SK] ≠ tj[SK] dacă i ≠ j
O supercheie (superkey) a unei relaţii este o submulţime (SK) de atribute ale relaţiei care
prezintă proprietatea de unicitate, adică orice combinaţie de valori ale atributelor supercheii este
unică pentru orice stare a relaţiei.
Acest lucru înseamnă că, dacă se cunoaşte combinaţia de valori ale atributelor supercheii
(valoarea supercheii), atunci acel tuplu poate fi identificat în mod unic. Orice relaţie are cel puţin o
supercheie: mulţimea tuturor atributelor sale. Un concept mai util în dezvoltarea bazelor de date îl
reprezintă conceptul de cheie candidată (sau, mai simplu, cheie).
O cheie candidată (candidate key) este o supercheie ireductibilă.
Conform definiţiei de mai sus, o cheie candidată CK trebuie să prezinte următoarele două
proprietăţi:
• Unicitate: nu există două tupluri diferite ale relaţiei care să conţină aceeaşi combinaţie de
valori ale atributelor cheii CK;
• Ireductibilitate: nu există nici o submulţime proprie, nevidă a cheii CK care să aibă
proprietatea de unicitate.
Acest lucru înseamnă că, dacă se elimină un atribut oarecare din submulţimea CK, noua
submulţime de atribute CK’ obtinută astfel nu mai are proprietatea de unicitate, adică vor putea
exista două sau mai multe tupluri care să prezinte aceeaşi combinaţie de valori ale atributelor din
submulţimea CK’. Aşadar o cheie candidată este o supercheie minimală, adică o supercheie din
care nu se poate elimina nici un atribut fără a se piarde proprietatea de unicitate.
Proprietatea cheii de a avea o valoare unică pentru fiecare tuplu (adică nu există două tupluri
cu aceleaşi valori ale atributelor cheii) este o constrângere de integritate a tuplurilor relaţiei
respective, care trebuie să fie respectată de orice stare a relaţiei (extensiune a relaţiei), în orice
moment.
O cheie candidată poate să fie simplă (alcătuită dintr-un singur atribut), sau compusă
(alcătuită din mai multe atribute).
O cheie este determinată de înţelesul atributelor şi este o proprietate invariantă în timp; ea
trebuie să se menţină atunci când sunt adăugate tupluri noi în relaţie. De exemplu, în relaţia
ANGAJATI(Nume,Prenume,DataNaşterii,Adresa,Salariu) nu se poate desemna ca şi cheie
submulţimea de atribute {Nume,Prenume}, deoarece nu există nici o garanţie că nu vor exista
niciodată (în aceeaşi instituţie) două persoane cu acelaşi nume şi prenume, chiar dacă în momentul
în care examinăm relaţia această situaţie nu apare. În schimb, submulţimea de atribute
{Nume,Prenume,DataNaşterii,Adresa} poate fi cheie candidată dacă se consideră că nu pot exista
două persoane cu acelaşi nume, prenume, data naşterii şi adresă.
 Atunci când există mai multe chei candidate, una dintre ele se alege ca şi cheie primară,
celelalte chei candidate fiind numite chei secundare, alternative sau unice. Aşadar:

cheie primară (primary key) este o cheie candidată căreia proiectantul îi conferă un rol
special de accesare şi identificare a tuplurilor relaţiei.
Asupra cheii primare se impun următoarele restricţii:
• Nici o valoare a atributelor cheii primare nu poate fi modificată prin operaţii de
actualizare.
• Nu se admit valori de NULL pentru nici unul dintre atributele cheii primare.
O cheie secundară (alternativă, unică) (secondary, alternate, unique key) este o cheie
candidată care nu a fost desemnată de proiectant ca şi cheie primară.
Cheile secundare admit valori NULL pentru unele din atributele lor dacă se respectă
condiţia de unicitate a valorilor.
Alegerea cheii primare dintre mai multe chei candidate este arbitrară, dar în mod obişnuit se
alege acea cheie care are cel mai mic număr de atribute. Deoarece condiţia de unicitate se verifică la
fiecare tuplu nou introdus şi toate operaţiile de identificare a tuplurilor se fac prin operaţii de
comparaţie a valorilor atributelor cheii primare, este evident că aceste operaţii sunt cu atât mai
eficiente (cu timp de execuţie mai scăzut) cu cât numărul de atribute ale cheii primare este mai mic.
O cheie primară compusă din atributele existente ale tipului de entitate se numeşte cheie
naturală. În general, cheile naturale sunt compuse din mai multe atribute (ceea ce produce scăderea
eficienţei operaţiilor relaţionale) şi de cele mai multe ori se folosesc chei artificiale. O cheie
primară artificială este un atribut care se adaugă în schema relaţiei pentru identificarea unică a
tuplurilor. De exemplu, în relaţia ANGAJATI se adaugă atributul IdAngajat, ca număr de
identificare al fiecărui angajat al instituţiei:
ANGAJATI(IdAngajat,Nume,Prenume,DataNasterii,Adresa,Salariu)
Acest atribut este o cheie artificială a relaţiei şi poate identifica în mod unic un tuplu,
deoarece (prin convenţie) nu se atribuie acelaşi număr de identificare la mai mult de un angajat.
Submulţimi de atribute care includ atributul IdAngajat ca {IdAngajat,Nume},
{IdAngajat,Nume,Prenume}, etc., sunt superchei ale relaţiei. Rămâne în grija programatorului sau a
sistemului de gestiune a bazei de date să asigure unicitatea acestui număr de identificare, dar acest
lucru este întotdeauna posibil. În secţiunile care urmează cheia primară se va marca prin subliniere
sau scriere îngroşată (bold).
În limbajul SQL, constrângerea de cheie primară se introduce la definirea relaţiei (tabelului)
prin comanda CREATE TABLE. Dacă cheia primară este simplă (formată dintr-un singur atribut),
constrângerea de cheie primară se poate specifica la definirea atributului, ca o constrângere de
atribut. Dacă cheia primară este compusă (formată din mai multe atribute), atunci constrângerea de
cheie primară se specifică după definirea atributelor, ca o constrângere de tabel sub forma:
[CONSTRAINT nume_constr] PRIMARY KEY (lista_atribute)
Această formă de definire se poate folosi şi pentru o cheie primară simplă şi atunci lista are
un singur atribut. Cheile secundare se definesc în mod asemănător, folosind specificatorul UNIQUE
în locul specificatorului PRIMARY KEY. Cu aceste notaţii, definiţiile mai complete ale tabelelor
ANGAJATI şi SECTII pot arăta astfel:
CREATE TABLE ANGAJATI (
IdAngajat int PRIMARY KEY,
Nume varchar(20) NOT NULL,
Prenume varchar(20) NOT NULL,
DataNasterii Date,
Adresa varchar(50),
Salariu numeric,
CHECK (Salariu >= 1500),
CONSTRAINT UK UNIQUE(Nume,Prenume,DataNasterii,Adresa));
CREATE TABLE SECTII (
IdSectie int PRIMARY KEY,
Nume varchar(50) NOT NULL,
 Buget numeric);
În fiecare dintre cele două tabele s-a definit cheia primară artificială printr-un atribut de
identificare (IdSectie, respectiv IdAngajat), care trebuie să ia valori unice în cadrul tabelului. În
tabelul ANGAJATI sa mai definit o cheie unică şi o constrângere de verificare.
Modul de asigurare a unicităţii valorii cheii primare artificiale depinde de sistemul SGBD folosit. De
exemplu, în sistemul Microsoft SQL Server se pot obţine valori unice ale cheii primare folosind
parametrul IDENTITY, care asigură incrementarea valorii atributului cheii la introducerea fiecărei
linii noi. .În sistemele Oracle se pot genera chei artificiale folosind obiecte SEQUENCE. Un obiect
SEQUENCE se creează pentru a genera cheia primară artificială a unui tabel, este memorat în baza
de date şi returnează un număr unic la fiecare apel al metodei NEXTVAL.
2.3.3 Constrângeri între relaţii - Cheia străină
Asocierile (relationships) între tipurile de entităţi definite în modelul conceptual (prin
diagrama Entitate-Asociere) al unei baze de date se realizează în modelul relaţional prin intermediul
cheilor străine.
Reluând exemplul din capitolul precedent, se consideră relaţiile SECTII şi ANGAJATI,
aflate în asociere 1:N, conform diagramei E-A şi a semnificaţiei celor două mulţimi de entităţi.
Pentru a asigura asocierea dintre relaţia ANGAJATI şi relaţia SECTII, se adaugă în relaţia
ANGAJATI un atribut suplimentar, IdSectie, care reprezintă identificatorul (numărul) secţiei în care
lucrează angajatul respectiv:
ANGAJATI(IdAngajat,Nume,Prenume,DataNasterii,Adresa,Salariu,IdSectie)
Pentru orice tuplu din relaţia ANGAJATI, atributul IdSectie trebuie să aibă o valoare egală cu
valoarea atributului corespunzător (IdSectie) dintr-un tuplu oarecare din relaţia SECTII (sau poate
avea valoarea NULL, dacă nu este impusă constrângerea NOT NULL). Este evident că pentru starea
la un moment dat a relaţiilor prezentate în figura 2.2, nu poate să existe în relaţia ANGAJATI un
tuplu cu valorile atributelor (5,Marinescu,...5), dat fiind că în instituţia respectivă nu există o secţie
cu identificatorul 5. Bineînţeles, dacă ulterior se adaugă mai întâi în relaţia SECTII un tuplu care să
aibă valoarea atributului IdSectie egală cu 5 (de exemplu tuplul(5,Marketing,1000000)), atunci se
poate admite în relaţia ANGAJATI tuplul(5,Marinescu,... 5). SECTII
IdSectie Nume Buget
1 Productie 4000000
2 Proiectare 3000000
3 Cercetare 2000000
4 Documentare 1000000
ANGAJATI
IdAngajat Nume Prenume DataNasterii Adresa Salariu IdSectie
1 Ionescu Ion 1945.01.05 Bucuresti 4000 1
2 Popescu Petre 1972.06.21 Bucuresti 3500 1
3 Vasilescu Ana 1966.04.02 Bucuresti 3000 2
4 Ionescu Ion 1970.11.12 Bucuresti 2500 3
Fig. 2.2. Tabelele SECTII şi ANGAJATI.
Din punct de vedere al notaţiilor, în instrucţiunile SQL de introducere, actualizare şi
interogare valorile atributelor definite ca şiruri de caractere se scriu între ghilimele simple, de
exemplu 'Marinescu', etc. La listarea sau afişarea rezultatelor însă, se va scrie numai valoarea
atributului, fără acest marcaj, pentru simplificarea prezentării exemplelor.

2.3.3.1 CHEIA STRĂINĂ

O cheie străină (foreign key) este o submulţime FK de atribute ale unei relaţiei R1 care
referă relaţia R2 şi satisface următoarele condiţii: (a) atributele cheii străine FK sunt definite pe
domenii compatibile cu cele ale atributelor unei cheii candidate CK a relaţiei R2 şi (b) combinaţia de
valori ale atributelor FK într-un tuplu din relaţia R1, fie este identică cu combinaţia de valori ale
atributelor CK a unui tuplu oarecare din starea curentă a relaţiei R2, fie ia valoarea NULL.
Relaţia care conţine cheia străină se numeşte relaţia care referă (R1 în definiţia de mai sus),
iar relaţia care conţine cheia candidată se numeşte relaţia referită (R2 în definiţia de mai sus).
Din punct de vedere relaţional, două domenii sunt compatibile dacă ele sunt comparabile
din punct de vedere semantic. De exemplu, are sens să se compare atributul IdSectie din relaţia
SECTII cu atributul IdSectie din relaţia ANGAJATI, deoarece aceste atribute reprezintă numere de
identificare ale secţiilor, deci domeniile celor două atribute sunt compatibile. În schimb, nu are sens
să fie comparate numerele de identificare ale secţiilor (atributul IdSecţie) cu numerele de
identificare ale angajaţilor (atributul IdAngajat), deci domeniile celor două atribute sunt
incompatibile.
Cheia străină realizează asocierea N:1 între relaţiile R1 şi R2 (ceea ce este echivalent cu
asocierea 1:N între relaţiile R2 şi R1) şi reprezintă o constrângere între două relaţii, numită
constrângere referenţială.
Din punct de vedere al sistemelor SGBD reale şi al limbajelor de definiţie şi manipulare a
datelor, noţiunea de compatibilitate semantică a domeniilor este mai puţin evidenţiată. În limbajul
SQL2 verificarea de compatibilitate a domeniilor se rezumă la verificarea tipurilor de date ale
atributelor corespondente, iar compatibiltatea semantică trebuie să fie asigurată de către proiectant.
Limbajul SQL2 admite ca şi “compatibile” domenii care sunt definite pe acelaşi tip de date sau pe
tipuri de date din aceeaşi categorie (şir de caractere, număr real, etc), chiar dacă sunt incompatibile
din punct de vedere semantic. De exemplu, limbajul SQL permite compararea valorilor atributului
IdSectie cu valori ale atributului IdAngajat ale relaţiei ANGAJATI, dat fiind că acestea sunt definite
pe acelaşi tip de date (integer).
În limbajul SQL cheia străină se specifică la crearea relaţiei (tabelului) care referă printr-o
constrângere (CONSTRAINT) în care se specifică atributele cheii străine şi atributele cheii
candidate (primare) corespunzătoare din relaţia referită:
[CONSTRAINT nume_constr] FOREIGN KEY (cheie_straina)
REFERENCES relatia_referita (cheie_candidata)
Numele atributelor cheii străine nu trebuie să fie neapărat aceleaşi cu numele atributelor
corespondente din cheia candidată referită, deşi această notaţie este frecvent folosită. Cu această
notaţie, se completează instrucţiunea de creare a tabelului ANGAJATI astfel:
CREATE TABLE ANGAJATI (
IdAngajat integer PRIMARY KEY, .............
IdSecţie integer,
CHECK (Salariu >=1500),
UNIQUE (Nume,Prenume,DataNasterii,Adresa),
FOREIGN KEY (IdSectie)REFERENCES SECTII(IdSectie));
Se observă că în modelul relaţional asocierea între relaţii se realizează prin egalitatea
valorilor atributelor cheii străine cu ale cheii referite, fără să fie necesară memorarea unor legături
(link-uri) explicite. Aceasta este una dintre cele mai remarcabile proprietăţile ale modelului
relaţional, care permite efectuarea oricărei interogări fără ca aceasta să fie prevăzută prin
structurarea explicită a datelor.
2.3.3.2 MENŢINEREA INTEGRITĂŢII REFERENŢIALE A DATELOR
Integritatea referenţială (referential integrity) este proprietatea bazei de date care
garantează că oricare valoare a unei chei străine se regăseşte printre valorile cheii candidate
corespunzătoare din relaţia referită, sau cheia străină are valoarea NULL (dacă atributele acesteia
nu sunt supuse constr. NOT NULL).
Operaţiile de modificare a stării unei relaţii (introducerea, ştergerea şi actualizarea tuplurilor
relaţiei) pot afecta integritatea referenţială a unei baze de date, dacă modificările dintr-o relaţie se
fac individual, fără să se ţină seama de referinţele către şi de la aceasta. Restricţiile care se impun
operaţiilor de modificare a relaţiilor depind de rolul relaţiei în diagrama de referenţiere a bazei de
date: relaţie care referă sau relaţie referită. De multe ori însă, o relaţie poate avea ambele roluri, atât
de relaţie care referă cât şi de relaţia referită şi atunci restricţiile de modificare trebuie să respecte
ambele situaţii.
Operaţia de introducere se poate face fără restricţii într-o relaţie referită. În schimb, la
introducerea unui tuplu nou într-o relaţie care referă (care conţine o cheie străină) trebuie să se
verifice că în relaţia referită există un tuplu care are valorile atributelor cheii referite egale cu
valorile atributelor cheii străine a tuplului de introdus. Dacă această condiţie nu este satisfăcută,
operaţia de introducere este refuzată.
Operaţia de ştergere a unui tuplu se poate face fără nici o restricţie într-o relaţie care referă
o altă relatie. Într-o relaţie referită, ştergerea unui tuplu poate fi executată în două moduri: ştergere
restricţionată sau ştergere în cascadă.
Ştergerea restricţionată interzice ştergerea unui tuplu din relaţia referită dacă acesta este
referit de un tuplu din relaţia care o referă. Pentru exemplul din figura 2.2, nu se poate şterge tuplul
(2,Proiectare,3000000) din relaţia SECTII, deoarece acest tuplu este referit de tuplul
(3,Vasilescu,...2) din relaţia ANGAJATI. În schimb, tuplul (4,Documentare,1000000) poate fi şters
din relaţia SECTII, deoarece acesta nu este referit de nici un tuplu din relaţia ANGAJATI.
Ştergerea în cascadă permite ştergerea unui tuplu din relaţia referită; dacă tuplul şters era
referit de unul sau mai multe tupluri, atunci se şterg şi acestea din relaţia care o referă; dacă tuplurile
şterse din relaţia care referă sunt, la rândul lor referite de alte tupluri, atunci trebuie să fie şterse şi
acestea, ş.a.m.d. Se execută deci o ştegere în cascadă, pe tot lanţul de referiri.
Operaţia de actualizare poate fi privită ca o ştergere urmată de o introducere, deci
restricţiile de actualizare reprezintă combinaţia restricţiilor de introducere şi de ştergere. Într-o
relaţie care referă, actualizarea cheii străine a unui tuplu este admisă dacă noua valoare a cheii
străine se regăseşte ca valoare a cheii candidate corespunzătoare într-unul din tuplurile relaţiei
referite. Într-o relaţie referită, actualizarea valorii cheii secundare (cheia primară nu poate fi
modificată) poate fi făcută în aceleaşi moduri ca şi ştergerea tuplurilor: actualizare restricţionată sau
actualizare în cascadă.
Stabilirea modului de ştergere sau de actualizare a tuplurilor se face în comenzile SQL de
creare sau modificare a tabelelor, prin adăugarea uneia din opţiunile ON DELETE, respectiv ON
UPDATE, constrîngerii de cheie străină. Valorile posibile ale acestor opţiuni sunt RESTRICT
(pentru ştergerea restricţionată) sau CASCADE (pentru ştergerea în cascadă); valoarea RESTRICT
este implicită. Ca exemplu, se completează instrucţiunea SQL de creare a tabelului ANGAJATI cu
opţiunea de ştergere în cascadă pentru cheia străină IdSecţie:
CREATE TABLE ANGAJATI (
IdAngajat integer PRIMARY KEY,
Nume varchar (20) NOT NULL,
FOREIGN KEY (IdSectie)REFERENCES SECTII(IdSectie) , ON
DELETE CASCADE );

2.4 Indexarea relaţiilor

Unul din avantajele sistemelor de gestiune este acela de a elibera proiectantul bazei de date
de necesitatea de a cunoaşte detaliile de organizare a datelor, prin asigurarea independenţei datelor.
Totuşi, această independenţă nu este completă şi, în stadiul actual de realizare a sistemelor de baze
de date, programatorii de aplicaţii trebuie să ia în consideraţie influenţa pe care modul de stocare şi
de regăsire a datelor îl are asupra performanţelor aplicaţiilor.
Într-o relaţie, privită ca o colecţie de elemente în care nu sunt admise elemente duplicat
(deoarece este o mulţime), operaţiile de bază sunt, ca în orice colecţie de elemente, căutarea,
inserarea şi ştergerea unui element, cărora, desigur, le corespund operaţiile (interogare, inserare,
ştergere) din limbajele de manevrare a datelor în relaţii. Relaţiile unei baze de date sunt memorate
în fişiere pe disc, iar comenzile de manevrare a datelor sunt transformate de SGBD în operaţii
asupra fişierelor care stochează relaţiile bazei de date. Modul şi timpul de execuţie a acestor
operaţii de bază depind de modul de reprezentare a mulţimii de elemente (tupluri) ale relaţiei.
În cazul unei mulţimi reprezentate printr-o colecţie neordonată de elemente, timpul de
căutare a unui element creşte proporţional cu numărul de elemente ale mulţimii, deoarece, în cazul
cel mai defavorabil, este necesar să fie parcurse toate elementele colecţiei pentru a găsi elementul
dorit. În acest caz se poate considera timpul de căutare în O(N) pentru o mulţime cu N elemente.
Timpul de căutare a unui element poate să fie micşorat semnificativ dacă elementele
mulţimii sunt ordonate; de exemplu, la reprezentarea unei mulţimi ca arbore binar ordonat, limita
asimptotică a timpului de căutare este în O(log N).
Pentru inserarea unui element într-o mulţime, trebuie mai întâi să fie căutat elementul
respectiv în colecţia (ordonată sau nu) prin care este reprezentată mulţimea respectivă; dacă există
deja un element identic, se interzice inserarea noului element; dacă nu există, atunci se introduce
noul element. Timpul de inserare a unui element într-o mulţime este compus din timpul de căutare al
unui element, la care se adaugă timpul de memorare propriu-zis. Observaţii similare se pot face
privind timpul de ştergere a unui element dintr-o mulţime.
În general, operaţiile de căutare, inserare şi ştergere a elementelor într-o mulţime se
execută mai rapid dacă elementele mulţimii sunt reprezentate printr-o colecţie ordonată. Astfel se
ajunge la situaţia că, deşi o relaţie nu presupune ordonarea tuplurilor sale, pentru accelerarea
operaţiilor de căutare, inserare şi ştergere, se folosesc colecţii ordonate, ca de exemplu arbori binari
ordonaţi sau tabele de dispersie (hash table).
Un index al unei relaţii (index) este o structură auxiliară memorată în baza de date care
permite accesul rapid la înregistrările (tuplurile) relaţiilor prin ordonarea acestora.
La definirea unei relaţii se stabilesc două categorii de indexuri: indexul primar al relaţiei,
care determină localizarea tuplurilor în fişierele bazei de date, şi zero, unul sau mai mulţi indexuri
secundare, care nu modifică localizarea tuplurilor, dar sunt folosiţi pentru regăsirea tuplurilor după
un criteriu dat.

2.4.1 Indexul primar

Indexul primar (primary index) se defineşte pe unul sau mai multe atribute ale relaţiei şi
reprezintă cheia (eticheta) după care ordonează tuplurile relaţiei.
Fiecare SGBD prevede o anumită modalitate de reprezentare a indexului primar. În
continuare se va folosi termenul de etichetă de ordonare, iar termenul de cheie de ordonare va fi
evitat, pentru a nu se confunda cu cheia relaţiei, întrucât este posibil să nu reprezinte acelaşi lucru,
deşi, în general, sistemele SGBD definesc în mod implicit indexul primar pe cheia primară a
relaţiei.
Operaţiile de căutare sau ştergere în care se specifică valoarea atributului index primar se
execută de asemenea eficient: se calculează mai întâi grupul căruia îi aparţine tuplul, prin aplicarea
funcţiei de dispersie h asupra valorii atributului index, apoi se caută poziţia tuplului în lista
înlănţuită corespunzătoare grupului. După aceasta, se continuă cu execuţii specifice operaţiei: se
şterge sau se citeşte tuplul găsit. De exemplu, pentru rezolvarea interogării "Care este oraşul de
domiciliu al studentului cu identificatorul 200?" se găseşte tuplul (200,Marin,Dan,Craiova) folosind
valoarea indexului primar (200).
Dacă într-o operaţie de căutare sau ştergere nu se specifică valoarea atributului index
primar, atunci căutarea unui anumit tuplu presupune parcurgerea (în cazul cel mai defavorabil) a
tuturor listelor tuturor grupurilor tabelei de dispersie. De exemplu, interogarea "Care este oraşul de
domiciliu al studentului cu numele Marin?" găseşte tuplul (200,Marin,Dan,Craiova) parcurgând
toate tuplurile şi comparând valoarea atributului Nume cu constanta Marin, până este găsit tuplul
care îndeplineşte această condiţie.
Astfel de situaţii sunt frecvent întâlnite în aplicaţii, dat fiind că interogările se formulează de
obicei folosind un nume, nu un identificator (care este probabil cheie primară, deci conţine indexul
primar, dar este necunoscut utilizatorilor). Pentru rezolvarea mai eficientă a unor astfel de interogări
se pot defini indexuri secundare pe acele atribute care intervin frecvent în interogări.
 2.4.2 Indexuri secundare
Un index secundar pe un atribut A al unei relaţii (secondary index) este o structură care
conţine o mulţime de perechi (v,L) ordonate după v; fiecare pereche corespunde unui tuplu al
relaţiei, v este valoarea atributului A, iar L este adresa tuplului respectiv în structura indexului
primar al relaţiei.
Un index secundar nu modifică adresa de memorare a unui tuplu (care este conţinută în
structura indexului primar), dar conţine informaţii suplimentare care permit identificarea rapidă a
unui tuplu după valoarea atributului indexului.
Din punct de vedere al eficienţei operaţiilor de căutare în relaţii este avantajos să fie definiţi
oricât de mulţi indexuri secundare, dar fiecare index secundar ocupă spaţiu de memorare
suplimentar şi trebuie să fie actualizat la fiecare operaţie de inserare şi ştergere a unui tuplu, ceea
ce înseamnă timp de execuţie suplimentar. În general, se recomandă utilizarea unui număr cât mai
mic de indexuri secundare, definiţi pe atributele care intervin cel mai frecvent în condiţiile de
interogare. Această decizie o ia proiectantul bazei de date prin analiza cerinţelor din domeniul
pentru care se dezvoltă baza de date şi aplicaţiile corespunzătoare.
Dat fiind că indexurile sunt folosite în special pentru îmbunătăţirea performanţelor bazelor de
date şi nu fac parte din modelul relaţional de bază, ei nu sunt cuprinşi în standardul limbajului SQL.
Însă majoritatea sistemelor SGBD încorporează indexuri, conţinând instrucţiuni pentru crearea
indexurilor de forma:
CREATE [optiuni] INDEX nume_index ON tabel (lista_atribute);
Forma exactă şi opţiunile acestei instrucţiuni variază de la un sistem SGBD la altul. Una din
opţiunile care se pot introduce în instrucţiunea CREATE INDEX este opţiunea UNIQUE, care
specifică faptul că nu pot exista două tupluri cu aceeaşi combinaţie de valori ale atributelor
indexului, deci acele atribute reprezintă o cheie unică a relaţiei. Unele sisteme SGBD adaugă câte un
index secundar pentru fiecare cheie unică, definită prin constrângerea UNIQUE din comanda
CREATE TABLE.
 2. Proiectarea bazelor de date relaţionale
2. Proiectarea bazelor de date relaţionale. Metode de proiectare.
După mai bine de două decenii de folosire a modelului relaţional, proiectarea (designul)
bazelor de date rămâne mai degrabă artă decât ştiinţă. Au fost sugerate un număr de metode, dar
până în prezent nici una nu e dominantă.
Proiectarea modelul relaţional al datelor are ca scop obţinerea unor colecţii de date ce
respectă atât cerinţele informaţionale ale utilizatorului cât şi restricţiile impuse de modelul
relaţional. În funcţie de complexitatea bazei de date, există două metode de proiectare a modelului
relaţional:
a. Conceperea modelului relaţional pe baza unui model conceptual semantic, model
numit modelul entitate-legătură (entitate-relaţie). Acesta permite
modelarea realităţii prin intermediul unor concepte abstracte: entităţi, asocieri şi
atribute. Este metoda cea mai folosită în practică, mai ales pentru baze de date
mari.
b. Conceperea modelului relaţional prin procesul de normalizare, proces ce
presupune aplicarea formelor normale asupra unui set de atribute ce formează un
singur tabel. În urma normalizării va rezulta un set de tabele normalizate. Metoda
se poate aplica în cazul unor baze de date mici sau al construirii unor aplicaţii
informatice, nu al unor sisteme informatice complexe.

Metodele curente de proiectare a bazelor de date sunt divizate în 3 etape separate: crearea
schemei conceptuale, crearea design-ului logic al bazelor de date şi crearea design-ului fizic al
bazei de date.

1. Crearea schemei conceptuale. Aceasta este un design de nivel înalt (incluzînd relaţiile
dintre datele întregului sistem), care descrie datele şi relaţiile necesare pentru execuţia
operaţiilor necesare, fiind independent de orice model de baze de date. Designul de la acest
nivel este foarte general, se realizează într-o perioadă foarte scurtă de timp şi prezintă modul
în care grupările de date sunt integrate în sistemul de ansamblu.

2. Crearea design-ului logic al bazei de date. În această fază schema conceptuală este
transformată în structuri specifice unui anumit sistem de gestiune a bazei de date. La acest
nivel designul este rafinat, sunt definite elemente de date specifice care sunt grupate în
înregistrări. În cazul modelului relaţional, la sfârşitul acestei etape vom avea un număr de
tabele care vor permite stocarea şi manipularea corectă a tuturor datelor necesare sistemului.

3. Crearea design-ului fizic al bazei de date. În această etapă designul logic este transformat
într-o stuctură fizică eficientă.

2.1. Crearea schemei conceptuale

Procesul de proiectare al schemei conceptuale începe prin identificarea datelor necesare
activităţiilor cerute de aplicaţie. Este creată o echipă de design a schemei conceptuale care se
ocupă cu determinarea datelor necesare, eventual prin folosirea de interviuri cu managerii
antreprizei. După ce echipa proiectează datele, ea le revizuieşte şi le organizează.

2.1.1.Modelul entitate-legătură (entitate-relaţie)

 Una dintre tehnicile folosite pentru organizarea rezultatelor din etapa de colectare a datelor
este modelul entitate-legătură, care împarte elementele unui sistem real în două categorii şi anume:
entităţi şi legături (relaţii) între aceste entităţi.
Principalele concepte folosite în acest model sunt cele de entitate, relaţie (legătură) şi
atribut.
Entitate
O entitate este un obiect de interes pentru care trebuie să existe date înregistrate. O entitate
poate fi atât un obiect tangibil – precum persoane, locuri sau lucruri – cât şi abstracte – precum
comenzi, conturi bancare, etc.
De exemplu, să considerăm o universitate formată din mai multe facultăţi; în fiecare
facultate studiază mai mulţi studenţi şi predau mai mulţi profesori. Fiecare student urmează mai
multe cursuri, după cum un profesor poate preda mai multe cursuri. În plus, un curs poate fi predat
de mai mulţi profesori (de exemplu la grupe/serii diferite). Elementele semnificative ale acestui
sistem sunt: facultate, student, profesor şi curs; acestea sunt entităţile sistemului. Ele sunt
reprezentate în figura 2.1. împreună cu relaţiile dintre ele. Entităţile se reprezintă prin
dreptunghiuri, iar relaţiile prin arce neorientate.

Lucrează în
FACULTATE PROFESOR

Studiază predă
în

urmează
STUDENT CURS

Figura 2.1
Ideile de bază pentru identificarea şi reprezentarea entităţiilor sunt următoarele:
 Fiecare entitate este denumită în mod unic; nu pot exista două entităţi cu acelaşi nume.
Entităţile sunt reprezentate întotdeauna prin substantive, dar nu orice substantiv folosit în
descrierea sistemului este o entitate a acestuia. Entităţile sistemului sunt doar acele
substantive care au o semnificaţie deosebită asupra sistemului . De exemplu,
chiar dacă suntem interesaţi de numărul, de ore de predare efectuate de un profesor pe
săptămână, aceasta nu înseamnă că vom crea o entitate pentru aceasta. De fapt, vom vedea
în continuare că număr de ore predate va fi un atribut al entităţii PROFESOR.
 De asemenea, pentru fiecare entitate trebuie să se dea o descriere detaliată; de exemplu,
putem spune că un PROFESOR este un cadru didactic angajat al universităţii pe o perioadă
nedetermintă, din această categorie făcând parte atât profesorii permanenţi cât şi cei
asociaţi, dar fiind excluşi cei care predau la universitate numai o perioadă limitată.
 Relaţie (legătură, asociere)
Entităţile pot forma relaţii între ele. O relaţie este o asociere nedirecţionată între două
entităţi. Ea exprimă un raport care există între entităţile respective. De exemplu, “lucrează în” este
o relaţie între entităţile PROFESOR şi FACULTATE, iar “predă “ este o relaţie între entităţile
PROFESOR şi CURS.
Principalele idei pentru identificarea şi reprezentarea relaţiilor sunt următoarele:
 Relaţiile sunt reprezentate prin verbe, dar nu orice verb este o relaţie;
 Între două entităţi poate exista mai mult decât o singură relaţie. De exemplu, dacă
luăm în vedere că fiecare facultate este condusă de un decan şi că acesta este ales din
rândurile profesorilor, atunci între entităţile PROFESOR şi FACULTATE va mai
exista o relaţie numită “conduce”.
 Pot exista relaţii cu acelaşi nume, dar relaţiile care asociază aceleaşi entităţi trebuie să
poarte nume diferite.

Cardinalitatea unei relaţii indică numărul maxim de instanţe din fiecare entitate care poate
participa la relaţie. Cu alte cuvinte, cardinalitatea unei relaţii reprezintă răspunsul la întrebări de
genul: Câţi studenţi pot studia la o facultate? Mulţi. Dar la câte facultăţi poate studia un student? La
cel mult una. Deci cardinalitatea relaţiei “studiază-la” este mulţi-la-unu. Cardinalitatea unei relaţii
poate fi de trei feluri: mulţi-la-unu, unu-la-unu, mulţi-la-mulţi.
 mulţi-la-unu (many-to-one) N:1): Relaţia dintre entităţiile A şi B este de tipul mulţi-la-
unul dacă fiecărei instanţe din A îi poate fi asociată cel mult o singură instanţă din B şi
fiecărei instanţe din B îi pot fi asociate mai multe instanţe din A. De exemplu, relaţiile
“lucrează_în” dintre PROFESOR şi FACULTATE şi “studiază_în” dintre STUDENT
şi FACULTATE sunt de tipul N:1. O relaţie mulţi-la-unul se reprezintă în modul
următor:

M 1
studiază_la
STUDENT FACULTATE
Figura 2.2
 unu-la-unu (one-to-one, 1:1): Relaţia dintre entităţile A şi B este de tipul unu-la-unu
dacă fiecărei instanţe din A îi poate fi asociată cel mult o singură instanţă din B şi
fiecărei instanţe din B îi poate fi asociată cel mult o singură instanţă din A. De
exemplu, relaţia “conduce” dintre PROFESOR şi FACULTATE este o relaţie 1:1.

1 conduce 1
PROFESOR FACULTATE

Figura 2.3

 mulţi-la-mulţi(many-to-many, N:M) :relaţia dintre entităţile A şi B este de tipul

mulţi-la-mulţi dacă fiecărei instanţe din A îi pot fi asociate mai multe instanţe din B
şi fiecărei instanţe din B îi pot fi asociate mai multe instanţe din A. De exemplu,
relaţiile “predă” dintre PROFESOR şi CURS şi “urmează” dintre STUDENT şi
CURS sunt de tipul N:M. O relaţie N:M se reprezintă în modul următor:
M M
predă
PROFESOR Figura 2.4 CURS

Valorile discutate până acum (N:1,1:1,N:M) reprezintă cardinalitatea maximă a unei relaţii.
Pe de altă parte, o relaţie este caracterizată şi de o cardinalitate minimă, care indică obligativitatea
participării entităţilor la o relaţie. Cu alte cuvinte, aceasta furnizează răspunsul la întrebări de genul:
 Câţi studenţi trebuie să studieze la o facultate? Zero. (De exemplu dacă facultatea este nou
înfiinţată). Dar la câte facultăţi trebuie să studieze un student? Cel puţin una. Deci cardinalitatea
minimă a relaţiei “studiază_la” dintre STUDENT şi FACULTATE este de 0:1. În mod similar,
relaţia “predă” dintre PROFESOR şi CURS are cardinalitatea minimă 0:0 (un profesor trebuie să
predea zero cursuri şi un curs trebuie să fie predat de zero profesori-de exemplu dacă cursul este
nou şi nu s-a stabilit încă titularul de curs). Deci cardinalitatea minimă a unei relaţii poate avea
valorile 0:0, 0:1 şi 1:1.
Dacă participarea unei entităţi la o relaţie este obligatorie (cardinalitatea minimă respectivă
este 1) se mai spune şi că participarea acesteia la relaţie este totală. În caz contrar (cardinalitatea
minimă respectivă este zero), participarea entităţii la relaţie se numeşte parţială.. De exemplu
participarea entităţii STUDENT la relaţia “studiază _la” este parţială, pe când participarea entităţii
FACULTATE la aceeaşi relaţie este totală.
În cadrul reprezentării grafice, cardinalitatea maximă a unei relaţii se va indica fără
paranteze, în timp ce cardinalitatea minimă, dacă este diferită de cea maximă, se va scrie în
paranteze, vezi figurile 2.5, 2.6 şi 2.7. De multe ori, cardinalitatea minimă nu este indicată în
diagrama entitate-legătură, pe când cardinalitatea maximă trebuie indicată întotdeauna, ea
fiind esenţială.
Studiază_la
M(0) 1
STUDENT FACULTATE
Figura 2.5
1(0) 1(0)
conduce
PROFESOR FACULTATE

Figura 2.6
M(0) M(0)
predă
PROFESOR CURS
M(0)
Figura 2.7

Un alt mod de a reprezentă relaţiile (folosit si in SGBD.urile cunoscute), indicând doar

cardinalitatea lor maximă este următorul:

 relaţii mulţi-la-unu
studiază_la
STUDENT FACULTATE

Figura 2.8
 relaţii unu-la-unu
conduce
PROFESOR FACULTATE

Figura 2.9
 relaţii mulţi-la-mulţi
predă
PROFESOR CURS

Figura 2.10
Atribut
Un atribut este o caracteristică a unei entităţi sau a unei relaţii. Fiecare entitate are un
anumit numărul de atribute despre care sunt înregistrate date. De exemplu, numele, prenumele,
vârsta şi numărul de ore predate sunt atribute ale entităţii PROFESOR. Fiecare atribut poate lua o
valoare care furnizează informaţii despre entitatea respectivă. Exemple de valori de atribute sunt
“Ionescu” pentru nume, “Mihai” pentru prenume etc. Pe de altă parte şi relaţiile pot avea atribute.
De exemplu, relaţia “urmează” dintre STUDENT şi CURS poate avea ca atribute nota obţinută la
examen şi nota obţinută la restanţă - pentru cei care nu au promovat examenul - iar relaţia
“lucrează_în” dintre PROFESOR şi FACULTATE poate avea ca atribut data înregistrării.

Principalele idei pentru identificarea şi reprezentarea atributelor sunt următoarele:

 Numele unui atribut este unic în cadrul unei entităţi sau al unei relaţii;
 Atributele sunt întotdeauna substantive, dar nu orice substantiv este un atribut;
 Pentru fiecare atribut, trebuie furnizată o descriere, împreună cu domeniul de valori
(întreg, şir de caractere, dată calendaristică,etc.);
 Alegerea atributelor trebuie făcută în aşa fel încât să se evite aşa-numitele atribute
indirecte. Un atribut indirect al unei entităţi sau relaţii este un atribut care nu aparţine
în mod real acelei entităţi sau relaţii, fiind o caracteristică a unui alt obiect al
sistemului. De exemplu, numele facultăţii este un atribut indirect al entităţii
STUDENT, el descriind de fapt o proprietate a entităţii FACULTATE. De aceea, el
va trebui redistribuit acestei entităţi.

Modelul entitate-legătură şi modelul relaţional

Modelul entitate-legătură poate fi transformat în mod natural într-o bază de date relaţională.
Ideile principalele ale acestei transformări sunt:
 O entitate devine un tabel;
 Un atribut al unei entităţi devine o coloană a tabelului respectiv;
 O relaţie va fi reprezentată fie într-un tabel special, fie printr-o cheie străină într-unul
dintre cele două tabele entitate, care face referire la cheia primară a celuilalt tabel
entitate.

Chei primare. Chei naturale şi chei artificiale.

O cheie a unei entităţi va fi un atribut sau un set de atribute care identifică în mod unic o
instanţă a acelei entităţi. Cu alte cuvinte, o cheie face distincţie între oricare două rânduri diferite
ale tabelului provenit din entitatea respectivă. De exemplu, putem presupune că fiecare student va fi
identificat în cadrul universităţii printr-un cod unic (nr. matricol); atunci codul studentului este o
cheie a entităţii STUDENT. Pe de altă parte, numele studentului nu poate fi cheie a acestei entităţi
deoarece pot exista mai mulţi studenţi cu acelaşi nume. Dacă însă presupunem că nu pot exista
studenţi cu acelaşi nume, prenume şi dată de naştere atunci combinaţia acestor atribute este la
rândul ei cheie a entităţii STUDENT.
Există două tipuri de chei primare: naturale şi artificiale. O cheie
naturală este constituită dintr-un atribut sau o combinaţie de atribute cu semnificaţie reală pentru
entitatea în cauză. De exemplu, combinaţia nume, prenume, dată de naştere este o cheie naturală a
entităţii STUDENT. O cheie artificială este un atribut al unei entităţi care nu are semnificaţie reală
pentru entitatea în cauză, fiind folosită doar pentru a face distincţie între instanţele entităţii. De
exemplu, codul studentului este o cheie artificială a entităţii STUDENT.
Una dintre cheile entităţii va fi declarată cheie primară. Deci, în principiu, oricare dintre
cele două chei ale entităţii STUDENT poate fi declarată cheie primară. Pe de altă parte însă, este
perferată folosirea cheilor artificiale, excepţie făcând cazul când cheia primară respectivă nu va fi
stocată în alte tabele ca şi cheie străină. Principalele avantaje ale cheilor primare artificiale faţă de
cele naturale sunt următoarele:
 Stabilitatea. Valoarea unei chei artificiale rămâne aceeaşi pe parcursul funcţionării
sistemului, în timp ce valoarea unei chei naturale poate fi în general modificată, această
modificare atrăgând, la rândul ei, schimbarea cheilor stăine care fac referire la ea. De
exemplu, numele unei studente se poate schimba prin căsătorie; dacă se consideră
combinaţia nume, prenume, data naşterii ca fiind cheia primară a entităţii STUDENT, atunci
orice schimbare a numelui va impune modificarea valorilor cheilor străine corespunzătoare.
  Simplitatea. În general, o cheie artificială e mai simplă decât una naturală. Cheile naturale
sunt mai complexe, atât din punct de vedere fizic (număr de octeţi) cât şi al numărului de
coloane. De exemplu, este mult mai comodă stocarea codului studentului ca şi cheie stăină,
decât a combinaţiei dintre nume, prenume şi data naşterii;
 Nu prezintă ambiguităţi. O cheie primară trebuie să nu prezinte ambiguităţi, astfel încât să
poată fi folosită cu uşurinţă de către dezvoltator sau utilizator în filtrările efectuate pe tabele.
Şi în această privinţă, o cheie naturală creează probleme. De exemplu, numele şi prenumele
unui student pot fi formate dintr-unul sau mai multe cuvinte care pot fi despărţite de un
spaţiu sau de o linie, etc;
 Elimină valorile Null. În cazul cheilor primare naturale, valorile Null reprezintă o problemă.
De exemplu, aceasta înseamnă că un student nu poate fi înregistrat dacă nu i se ştie data de
naştere.
În concluzie, o cheie primară trebuie să fie unică, diferită de Null, scurtă, simplă, fară
ambiguităţi, să nu conţină informaţii descriptive, să fie uşor de manipulat, să fie stabilă şi
familiară utilizatorului. Cheile artificiale îndeplinesc toate aceste condiţii în afară de ultima,
fiind preferate aproape întotdeauna celor naturale.

Diagrama entitate-legătură pentru baza de date din sistemul informatic

Entităţile sistemului, împreună cu relaţiile dintre ele se reprezintă prin aşa numita diagramă
entitate-legătură, în care entităţiile sunt reprezentate prin dreptunghiuri, iar relaţiile dintre acestea
prin arce neorientate, specificându-se şi cardinalitatea acestora. Pentru fiecare entitate se specifică
cheile primare şi eventual atributele mai semnificative, atributele care reprezintă chei primare
trebuind să fie subliniate. Diagrama entitate–legătură a sistemului descris la începutul acestui curs
este reprezentată în figura 2.11.
FACULTATE 1 Lucrează_în M(0) PROFESOR
cod_facultate cod_profesor
1(0) conduce 1(0) nume
nume_facultate
adresa prenume

1 data_naşterii
grad_didactic
M(0)
studiază_în

predă

M(0) M(0)
STUDENT CURS
cod_student M(0) urmează M(0) cod_curs
nume nume-curs
prenume descriere
data_naşterii Figura 2.11

Cazuri speciale de entităţi, relaţii şi atribute

În continuare vom considera câteva cazuri speciale de entităţi, relaţii şi atribute, încercând
în acelaşi timp o clasificare a acestora.
 Subentitate/Superentitate.
 O subentitate este o submulţime a unei alte entităţi, numită superentitate. De exemplu, să
presupunem că în sistemul prezentat mai sus nu vom reţine date numai despre profesorii
universităţii, ci şi despre tot personalul din universitate. Atunci vom crea o superentitate
PERSONAL, pentru care PROFESOR este o subentitate. O altă subentitate a acestei
surepentităţi va fi PERSONAL-ADMINISTRATIV. O subentitate se reprezintă printr-un
dreptunghi inclus în dreptunghiul care reprezintă superentitatea corespunzătoare, vezi figura
2.12. Cheia primară, atributele şi relaţiile unei superentităţi sunt valabile pentru orice
subentitate, reciproca fiind evident falsă. De exemplu, cheia primară a entităţii PROFESOR va
fi acum “cod_personal”, care este cheia primară a entităţii PERSONAL, în timp ce unele dintre
atributele subentităţii PROFESOR (de exemplu “nume”, “prenume”, “data_naşterii”) se
regăsesc printre atributele entităţii PERSONAL. Pe de altă parte însă, subentitatea PROFESOR
poate avea şi alte atribute decât cele specifice superentităţii PERSONAL, de exemplu gradul
didactic. Cu alte cuvinte, atributele comune vor fi repartizate superentităţii, în timp ce atributele
specifice vor fi repartizate subentităţiilor.
Între o subentitate şi superentitate corespunzătoare există întotdeauna o relaţie 1:1, având
cardinalitatea minimă 1:0.
Uneori este convenabil să se creeze superentităţi din entităţi cu mai multe atribute comune.
De exemplu, din entităţile PROFESOR şi PERSONAL_ADMINISTRATIV s-a creat
superentitatea PERSONAL. Superentitatea astfel creată va conţine atributele comune, iar
atributele specifice vor fi repartizate subentităţilor componente. În plus, se va crea o nouă cheie
artificială pentru superentitatea nou formată. De exemplu, pentru PERSONAL s-a creat un cod
personal, care a devenit cheie primară a acestei entităţi.

PERSONAL
Cod-personal
Nume
Prenume
Data-naşterii

PROFESOR
Grad-didactic
PROFESOR
Grad-didactic
PERSONAL-ADMINISTRATIV

Figura 2.12

 Entitate dependentă (detaliu)/entitate master.

O entitate dependentă (detaliu) este o entitate care nu poate exista de sine stătătoare, ci
numai ataşată unei alte entităţi, aceasta din urmă fiind numită entitatea master a acestei
legături. De exemplu, dacă presupunem că fiecare curs poate fi constituit dintr-unul sau mai
multe module, atunci entitatea MODUL va fi o entitate dependentă de CURS, vezi figura
2.13. Între entităţile master şi detaliu va exista întotdeauna o relaţie 1:N, având
cardinalitatea minimă 1:0. Cheia primară a unei entităţi detaliu va fi formată din cheia
primară a entităţii master plus una sau mai multe atribute ale entităţii detaliu. De exemplu,
cheia entităţii MODUL poate fi aleasă ca fiind combinaţia între cod_curs şi nr_modul,
acesta din urmă specificând numărul de ordine al unui modul în cadrul unui curs.

MODUL CURS
cod_curs M(0) cod_curs
face_parte_din 1
nr_modul nume_curs
descriere Figura 2.13 descriere
 • Atribute simple /compuse/repetitive(multivaloare)/calculate(deduse)

Atributele pot fi de patru feluri: simple, compuse, repetitive (multivaloare) şi calculate (deduse).
Unui atribut simplu îi corespunde o singură valoare, atomică. De exemplu numele şi prenumele
unui student, sunt atribute simple. Un atribut compus este format din mai multe atribute simple,
numite componentele sale. Valoarea unui atribut compus este reprezentată de valorile atributelor
componente. Dacă presupunem, de exemplu, că o adresă se poate descompune în componentele
ţară, oraş, stradă, număr şi cod, atunci "adresa" este un atribut compus din 5 componente. Un atribut
repetitiv (multivaloare) este un atribut care poate avea mai multe valori, numărul acestora variind de
la o instanţă la alta. De exemplu, un student poate avea mai multe numere de telefon, deci acesta
este un atribut repetitiv. Un atribut calculat reprezintă un atribut a cărui valoare nu este cunoscută
direct, ci calculată pe baza valorilor altor atribute. De exemplu atributul "valoare" este calculat ca
produs între atributele "cantitate" şi "preţ". Atributele calculate se folosesc foarte rar deoarece ele
reprezintă de fapt o redundanţă a datelor.

Probleme în identificarea entităţitor, relaţiilor şi atributelor

• Relaţie sau entitate?

Uneori este greu de identificat dacă o componenta a sistemului este relaţie sau entitate. Dacă o
entitate are o cheie provenită din combinaţia cheilor primare a două sau mai multe entităţi, atunci
trebuie definită o relaţie. Deci entitatea PREDĂ din figura 2.17 a) va avea semnificaţia unei relaţii
între entităţile PROFESOR şi CURS, reprezentată în figura 2.17 b).

PREDĂ
PROFESOR cod_profesor CURS
cod_profesor cod_curs cod_curs

PROFESOR CURS
M predă M M cod_curs
cod_profesor

Figura2.17

• Relaţie sau atribut ?

O relaţie poate fi reprezentată ca un atribut al unei entităţi, după cum atributele unei entităţi
pot fi înlocuite cu relaţii. Deci, care este diferenţa între o relaţie şi un atribut? Atunci când un atribut
al unei entităţi reprezintă cheia primară a altei entităţi, el exprimă de fapt o relaţie. Deci figura 2.18
va reprezenta o relaţie între entităţile STUDENT şi FACULTATE.

STUDIAZA
cod_student
cod_facultate

STUDENT M studiază_la 1 FACULTATE

cod_student cod_facultate
 Figura 2.18
Etapele obţinerii modelului entitate-legătură.
Pentru realizarea modelului entitate - legătură a sistemului analizat sunt parcurse următoarele
etape:
• Identificarea entităţilor sistemului;
• Identificarea relaţiilor sistemului şi stabilirea cardinalităţii acestora;
• Identificarea atributelor entităţilor şi relaţiilor sistemului;
• Stabilirea cheilor primare ale entităţilor;
• Trasarea diagramei entitate-legătură.

Diagrama entitate-legătură a sistemului prezentat ca exemplu în această secţiune, incluzând

entităţile şi relaţiile menţionate mai sus, este prezentată în figura 2.19.
PERSONAL

cod_personal

nume, prenume, data_naşterii

PERSONAL_ADMINISTRATIV
este_şef
FACULTATE
lucrează_în M (0) M (0)
1
PROFESOR
cod_facultate 1(0) conduce 1 (0)
nume_facultate 1 (0)
grad_didactic
adresa M (0)
1 M (0)
studiază_la coordonează

M (0)
STUDENT PROIECT predă
cod_student M (0) M (0)
nume efectuează cod_proiect
prenume nume_proiect
data_naşterii
M (0) M (0)
urmează M (0) CURS
cod_curs
nume_curs
descriere
1

face_parte_din

M (0)
MODUL
cod_curs
nr modul
descriere

Figura 2.19
Trebuie remarcat că aceeaşi realitate poate fi percepută diferit de către analişti diferiţi, aşa că este
posibilă obţinerea de modele diferite pentru acelaşi sistem, după cum şi un sistem poate să se
modifice în timp, ceea ce va atrage la rândul său modificarea modelului asociat.
2.2. Crearea design-ului logic al bazei de date
Pentru realizarea design-ului logic al bazei de date, schema conceptuală este transformată într-un
design al bazei de date care va funcţiona într-un sistem de gestiune a1 bazelor de date specific.
Design-ul logic al bazei de date este o rafinare a modelului iniţial furnizat de schema conceptuală.
Aceasta nu înseamnă că modelul conceptual nu este corect, dar trebuie stabilite detalii suplimentare
necesare dezvoltării proiectului.
2.2.1. Transformarea modelului entitate legătură în modelul relaţional
Deci pentru obţinerea design-ului logic al unei baze de date relaţionale se porneşte de la
schema conceptuală, mai precis de la modelul entitate-legătură, şi se încearcă reprezentarea
entităţilor şi a legăturilor sub forma de tabele relaţionale. Regulile de conversie ale entităţilor,
legăturilor şi atributelor sunt următoarele:

Transformarea entităţilor:
Regula generală este că entităţile devin tabele, distingându-se următoarele subcazuri:
• Entităţile independente devin tabele independente, adică tabele a căror cheie primară nu
conţine chei străine. De exemplu, entitatea STUDENT va deveni un tabel a cărui cheie primară este
"cod_student".
• Entităţile dependente devin tabele dependente (tabele detaliu) adică tabele a căror cheie
primară conţine cheia străină ce face referinţă la cheia primară a entităţii de care depinde entitatea
în cauză. De exemplu, cheia primară a entităţii MODUL va fi formată din ''cod_curs", care
reprezintă o cheie străină pentru entitatea CURS, plus "nr_modul".
• Subentităţile devin subtabele adică tabele a căror cheie primară este cheia străină pentru
tabelul superentitate. De exemplu, cheia primară a tabelului PROFESOR este "cod_personal", care
este o cheie străină ce face referinţă la cheia primară "cod_personal" din tabelul PERSONAL.
Uneori, se preferă construirea unor supertabele, formate atât din atributele superentităţii -
cele comune tuturor subentităţilor - cât şi din atributele specifice fiecărei subentităţi. Avantajul unor
astfel de supertabele este simplificarea programelor de manipulare a datelor. Pe de altă parte însă,
ele creează probleme suplimentare privind integritatea datelor, de exemplu dacă vom avea un singur
tabel pentru tot personalul din facultate, atunci atributele specifice profesorului pot avea valori
diferite de Null numai atunci când în tabel se inserează un rând corespunzător unui profesor. In
plus, subtabelele obţinute din descompunerea unui astfel de supertabel sunt mai stabile, mai
flexibile, ocupă spaţiu fizic mai mic şi conţin mai puţine valori Null.

Transformarea relaţiilor:
• Relaţiile 1:1 devin chei străine, cheia străină fiind plasată în tabelul cu mai puţine linii. De
exemplu, relaţia "conduce" dintre PROFESOR şi FACULTATE se realizează prin inserarea unei
chei străine în tabelul FACULTATE care face referinţă la cheia primară a tabelului PROFESOR,
vezi figura 2.20.
Notă: Plasamentul cheii străine va fi indicat printr-o săgeată (→), iar când cheia străină va fi
conţinută în cheia primară, atunci vârful săgeţii va fi umplut ( ).
Deci într-o relaţie 1:1 poziţia cheii străine depinde de cardinalitatea minimă a relaţiei. Dacă aceasta
este tot 1:1, atunci cheia poate fi plasată în oricare din cele două tabele. Dacă însă această
cardinalitate minimă este 1:0, atunci cheia străină este plasată în tabelul a cărui cardinalitate minimă
în relaţie este 0. In cazul în care cardinalitatea minimă e 0:0 se alege pur şi simplu tabelul cu mai
puţine linii.
• Relaţiile N:l devin chei străine plasate în tabelul care se află de partea "mulţi" a relaţiei. De
exemplu relaţia "lucrează_în'' va fi realizată prin inserarea unei chei străine în tabelul PROFESOR
care va face referinţă la cheia primară a tabelului FACULTATE, vezi figura 2.21. Şi în cazul
relaţiilor N:l se disting două cazuri în funcţie de cardinalitatea minimă a relaţiei. Dacă aceasta este
0:1, atunci cheia străină respectivă nu poate avea valoarea Null, iar în cazul entităţilor dependente
ea va face chiar parte din cheia primara a tabelului. Dacă însă cardinalitatea minimă a relaţiei este
0:0 atunci cheia străină poate avea valoarea Null şi nu poate face parte din cheia primară.
• O relaţie mulţi-la-mulţi se transformă într-un tabel special, numit tabel asociativ, care are
două chei străine pentru cele doua tabele asociate; cheia primară a tabelului asociativ este
compusă din aceste două chei străine plus eventual alte coloane adiţionale.
În acest caz se spune că o relaţie mulţi-la-mulţi se sparge în două relaţii mulţi-la-unu, tabelul
asociativ fiind în relaţie de mulţi–la-unu cu fiecare dintre cele dona tabele entitate. De
exemplu, relaţia "predă" dintre PROFESOR şi CURS se realizează printr-un tabel a cărui
cheie primară este combinaţia cheilor străine ale acestor două entităţi, vezi figura 2.22.
• O relaţie de tip 3 (relaţie între mai mult de două entităţi) devine un tabel asociativ care are câte o
cheie străină pentru fiecare dintre tabelele asociate; cheia primară este compusă din aceste chei
străine plus eventual alte coloane adiţionale. De exemplu, tabelul reprezentat în figura 2.23 exprimă
relaţia "efectuează_coordonează" dintre STUDENT, PROIECT şi PROFESOR. În acest caz, cheia
primară este combinaţia cheilor străine corespunzătoare celor trei entităţi.
1(0) conduce 1(0)
PROFESOR FACULTATE
cod_personal cod_facultate

Figura 2.20

M(0) lucrează în 1 FACULTATE

PROFESOR
cod_personal cod_facultate
Figura 2.21

Figura 2.22

1 M(0) PREDĂ M(0) 1

PROFESOR CURS
cod_personal cod_curs
cod_personal
cod_curs

PROFESOR
cod_personal

M(0)
M(0)
EFECTUEAZĂ
1 M(0) COORDONEAZĂ M(0) 1
PROIECT
STUDENT cod_student
cod_student cod_proiect
cod_proiect
cod_personal

Figura 2.23.
 Transformarea atributelor:
• Atributele simple ale unei entităţi devin coloane în tabelul provenit din entitatea corespunzătoare.
De asemenea, fiecare componentă a unui atribut compus devine o coloană în tabel. De exemplu,
pentru atributul compus "adresă", format din "ţară", "oraş", "stradă", "număr" şi "cod", vom avea
cinci coloane, câte una pentru fiecare componentă a sa.
• Atributele repetitive (multivaloare) ale unei entităţi devin tabele dependente ce conţin o cheie
străină (care face referinţă la cheia primară a entităţii) şi atributul multivaloare; cheia primară a
acestui nou tabel este formată din cheia străină plus una sau mai multe coloane adiţionale. De
exemplu, dacă presupunem că un student poate avea mai multe numere de telefon, atunci
"nr_telefon" este un atribut multivaloare al entităţii STUDENT, care va da naştere unui tabel
TELEFON, a cărui cheie primara va fi combinaţia dintre "cod_student" şi "nr_telefon ", vezi
figura 2.24.
• Atributele simple ale unei relaţii 1:1 sau 1:N vor deveni coloane ale tabelului care conţin cheia
străină. De exemplu, data înscrierii, care este un atribut al relaţiei "studiază_la" dintre STUDENT
şi FACULTATE, va fi reprezentată ca o coloană în tabelul STUDENT.
De asemenea, fiecare atribut compus al unei relaţii 1:1 sau 1:N va deveni o coloană în tabelul care
conţine cheia străină.
• Atributele simple ale unei relaţii N:M vor deveni coloane ale tabelului asociativ. De exemplu, nota
obţinută la examen, care este un atribut al relaţiei "urmează" dintre STUDENT şi CURS va fi
reprezentată ca o coloană în tabelul asociativ corespunzător acestei relaţii. De asemenea, fiecare
componentă a unui atribut compus al unei relaţii N:M va deveni o coloană în tabelul asociativ.

Atributele repetitive (multivaloare) ale unei relaţii 1:1 sau 1:N vor deveni tabele dependente de
tabelul care conţine cheia străină, iar atributele repetitive ale unei relaţii N:M vor deveni tabele
dependente de tabelul asociativ corespunzător relaţiei. Evident, cheia primară a acestor tabele
dependente va fi o combinaţie formată din cheia străină respectivă şi una sau mai multe coloane
adiţionale. De exemplu, dacă presupunem că în cadrul anumitor cursuri studenţii trebuie să dea un
număr de teste, atunci "test" va fi un atribut multivaloare al relaţiei "urmează" dintre STUDENT şi
CURS şi care va da naştere unui tabel dependent de tabelul asociativ al acestei relaţii, vezi figura
2.25.
STUDENT 1 M(0) TELEFON
cod_student cod_student
nr_telefon

Figura
TEST2.24
cod_student
cod_curs
nr_test

M(0)

STUDENT
1 M(0) URMEAZĂ M (0) 1 CURS
cod_student cod_student cod_curs
cod_curs

Figura 2.25
 In figura 2.26 este prezentată diagrama logică a bazei de date pentru sistemul descris ca
exemplu. Aceasta a rezultat din diagrama entitate-legătură, în urma transformărilor prezentate mai
sus.
PERSONAL

cod_personal

nume, prenume, data_naşterii

PERSONAL_ADMINISTR
ATIV
M (0) este_şef
FACULTATE
lucrează_în M (0)
1
cod_facultate conduce PROFESOR
nume_facultate 1 (0) 1 (0) grad_didactic
adresa
1 1 (0)
1 1

studiază_la

M (0) M (0) M (0)

STUDENT EFECTUEAZĂ PROIECT PREDĂ
COORDONEAZĂ
cod_student 1 M (0) M (0) 1 cod_personal
cod_proiect
nume cod_student nume_proiect cod_curs
prenume cod_proiect
data_naşterii cod_personal 1
1 1 M (0)

CURS
URMEAZĂ
M (0) M (0) 1 cod_curs
cod_student nume_curs
cod_curs descriere
M (0) 1
1
TEST
face_parte_din
cod_student M (0)
nr_telefon

M (0)
MODUL
TEST
cod_curs
cod_student nr modul
cod_curs descriere
nr_test

Figura 2.26
Tabelele asociate acestei diagrame sunt următoarele:
PERSONAL (cod_ personal, nume, prenume. data_naştere, sex, stare_civilă, data_angajare)
PERSONAL_ADMINISTRATIV (cod_ personal ,profesie, funcţie)
PROFESOR (cod_ personal ,grad_didactic, titlu, şef, ore_predate, cod_facultate}
CURS (cod curs, nume_curs, descriere, nr_ore)
PREDA (cod_ personal , cod curs, dată început)
MODUL (cod curs, nr modul, descriere)
FACULTATE (cod_facultate, nume_facultate, localitate, strada, nr, cod_poştal, cod__decan)
STUDENT (cod student ,nume, prenume, data_naşterii, ţara, localitate, strada, nr, cod_poştal, studii_anteriore,
dată_înscriere)
TELEFON (cod student. nr telefon, tip_telefon)
PROIECT (cod_proiect nume_proiect, domeniu)
EFECTUEAZA_COORDONEAZĂ (cod_student, cod_proiect, cod_personal)
URMEAZĂ (cod_student, cod_curs, nota _examen, nota_restanţă, observaţii)
TEST ( cod_student, cod_curs, nr_test, nota_test, observaţii)

Notă: Atributele subliniate constituie cheia primară a tabelului iar cele italice constituie chei străine.