Diagrame entitate-relaie

Diagrama E/R model neformalizat pentru reprezentarea unui sistem din lumea real. Este un model de date conceptual de nivel nalt dezvoltat de Chen (1976) pentru a facilita proiectarea bazelor de date. Modelul de date conceptual este independent de: tipul SGBD-ului; platforma hardware utilizata. Modelul conceptual este constituit din concepte care descriu: structura bazei de date; tranzactii de regasire si reactualizare asociate.

Entitate: persoan, loc, concept, activitate, eveniment care este

semnificativ pentru ceea ce modelm.
DEPARTAMENT SARCINA lucreaza_in conduce apartine_la SALARIAT atasat_la PROIECT

Observaii: Entitile devin tabele n modelele relaionale. n general, entitile se scriu cu litere mari. Entitile sunt substantive, dar nu orice substantiv este o entitate. Pentru fiecare entitate este obligatoriu s se dea o descriere detaliat. Nu pot exista, n aceeai diagram, dou entiti cu acelai nume, sau o aceeai entitate cu nume diferite.

Cheia primar este un identificator unic n cadrul entitii, fcnd distincie ntre valori diferite ale acesteia. Cheia primar: trebuie s fie unic i cunoscut la orice moment; trebuie s fie controlat de administratorul bazei; trebuie s nu conin informaii descriptive, s fie simpl, fr ambiguiti; s fie stabil; s fie familiar utilizatorului.

Relaie (asociere): o comunicare ntre dou sau mai multe entiti.

Existena unei relaii este subordonat existenei entitilor pe care le leag. Gradul (tipul) unei relatii este dat de numarul entitatilor participante la relatia respectiva. Observaii: n modelul relaional, relaiile devin tabele speciale sau coloane speciale care refer chei primare. Relaiile sunt verbe, dar nu orice verb este o relaie. Pentru fiecare relaie este important s se dea o descriere detaliat. n aceeai diagram pot exista relaii diferite cu acelai nume. n acest caz, le difereniaz entitile care sunt asociate prin relaia respectiv. Pentru fiecare relaie trebuie stabilit cardinalitatea (maxim i minim) relaiei, adic numrul de tupluri ce aparin relaiei.

poate (cardinalitate maxim) trebuie (cardinalitate minima) Exemplu: Ci salariai pot lucra ntr-un departament? Muli! n cte departamente poate lucra un salariat? In cel mult unul! Relaia SALARIAT_lucreaza_in_DEPARTAMENT are cardinalitatea maxim many-one (n:1). Exemplu: Ci salariai trebuie s conduc un departament? Cel puin unul! Cte departamente trebuie s conduc un salariat? Zero!

Relaia SALARIAT_conduce_DEPARTAMENT are cardinalitatea minim one-zero (1:0).

Atribut: proprietate descriptiv a unei entiti sau a unei relaii.

Atributele pot fi simple, compuse, cu valori multiple, derivate. Observaii: Trebuie fcut distincia ntre tipul atributului (devine coloan n modelele relaionale) i valoarea acestuia (devine valoare n coloane). Atributele sunt substantive, dar nu orice substantiv este atribut. Fiecrui atribut trebuie s i se dea o descriere complet (exemple, contraexemple, caracteristici). Pentru fiecare atribut trebuie specificat numele, tipul fizic (integer, float, char etc.), valori posibile, valori implicite, reguli de validare, tipuri compuse.

Pentru proiectarea diagramei entitate-relaie au fost stabilite anumite reguli (nu sunt unice): 1. entitile sunt reprezentate prin dreptunghiuri; 2. relaiile dintre entiti sunt reprezentate prin arce neorientate; 3. atributele care reprezint chei primare trebuie subliniate sau marcate prin simbolul #, plasat la sfritul numelui acestor atribute; 4. cardinalitatea minim este indicat n paranteze, iar cardinalitatea maxim se scrie fr paranteze; 5. nu trebuie specificate toate atributele.

4
SALARIAT cod_salariat nume prenume sex salariu
1 M(0)

M(0)

atasat_la data_initiala functia

M(0)

PROIECT nr_proiect descriere buget_alocat

1

conduce
1(0)

lucreaza_in
1

apartine_la

DEPARTAMENT cod_departament nume nr_cladire

SARCINA nr_proiect nr_sarcina data_inceperii stare

Diagrama E/R. Cazuri speciale de entiti, relaii, atribute i modul lor de reprezentare n cadrul diagramei entitate-relaie.
1.

Entitate dependent nu poate exista n mod independent (SARCINA depinde de PROIECT). Cheia primar a unei entiti dependente include cheia primar a sursei (nr_proiect) i cel puin o descriere a entitii (nr_sarcina). Entitatea dependent se deseneaz prin dreptunghiuri cu linii mai subiri. Motenirea atributelor. Subentitate (subclas) submulime a unei alte entiti, numit superentitate (superclas) (SALARIAT < > PROGRAMATOR). Subentitatea se deseneaz prin dreptunghiuri incluse n superentitate. Exist o relaie ntre o subentitate i o superentitate, numit ISA, care are cardinalitatea maxim 1:1 i minim 1:0. Cheile primare, atributele i relaiile unei superentiti sunt valabile pentru orice subentitate. Afirmaia reciproc este fals. Generalizare. Din entiti similare care au mai multe atribute comune se pot crea superentiti. Aceste superentiti conin atributele comune, iar atributele speciale sunt asignate la subentiti. Pentru noile superentiti se introduc chei primare artificiale. Specializare. Dup valorile unor atribute clasificatoare se pot determina clase. Un grup de subentiti reciproc exclusive definete o clas. Clasele se aliniaz n desen vertical. ntr-o diagram E/R se pot defini relaii recursive. Unele relaii sunt relative la dou entiti i le numim de tip 2, iar dac relaiile implic mai mult de dou entiti, le vom numi de tip 3.

2.

3.

4.

5. 6.

Trei relaii de tip 2 sunt diferite de o relaie de tip 3. Rupnd o relaie de tip 3 n trei relaii de tip 2, pot aprea informaii incorecte.
7. 8. 9.

Trebuie excluse din model relaiile indirecte deoarece ele pot conduce la redundan n baza de date. Atributele derivabile trebuie eliminate i introduse expresii prin care aceste atribute pot fi calculate. Relaie sau atribut? Dac un atribut al unei entiti reprezint cheia primar a unei alte entiti, atunci el refer o relaie (cod_departament n tabelul SALARIAT). Entitate sau relaie? Se cerceteaz cheia primar. Dac aceasta combin cheile primare a dou entiti, atunci este vorba de o relaie. (cheia primar a relaiei asociat_la combin cod_salariat cu nr_proiect, prin urmare, SALARIAT_asociat la_PROIECT va defini o relaie i nu o entitate). Un atribut indirect este inoportun. El nu descrie real relaia sau entitatea. Prin urmare, atributele indirecte trebuie reasignate. De fapt, un atribut indirect este un caz special de relaie indirect care trebuie eliminat pentru c introduce redundan n date (numrul cldirii n care lucreaz un salariat este un atribut al entitii DEPARTAMENT i nu este o caracteristic a entitii SALARIAT). Exist atribute opionale, a cror valoare este uneori necunoscut, alteori neaplicabil. Aceste atribute trebuie introduse la subentiti (comisionul pentru deplasare i zona de lucru sunt atribute specifice unui agent teritorial i trebuie introduse la subentitatea AGENT_TERITORIAL). Algoritmul pentru proiectarea diagramei entitate-relaie: 1. identificarea entitilor din cadrul sistemului analizat; 2. identificarea relaiilor dintre entiti i stabilirea cardinalitii; 3. identificarea atributelor aferente entitilor i asocierilor dintre entiti; 4. stabilirea atributelor de identificare a entitilor (stabilirea cheilor).

10.

11.

12.

6
SALARIAT cod_salariat nume
ISA 1 1(0)

job_cod AGENT_TERITORIAL zona comision PROGRAMATOR limbaj nivel

M(0) atasat_la data_initiala functia

PROIECT nr_proiect descriere M(0) buget_alocat

1 apartine_la

ISA 1 1(0)

1(0) M(1)

1 conduce 1(0)

M(0) lucreaza_in 1

1(0)

casatorit

SARCINA nr_proiect nr_sarcina data_inceperii stare

DEPARTAMENT cod_departament nume nr_cladire

Diagrama E/R. Modelul EER (modelul E/R extins) = Diagrama E/R + concepte aditionale (subclas, superclas, motenire, specializare, generalizare).

Gestiunea activitilor de mprumut dintr-o bibliotec

S-a presupus (restrictiv) c ntr-o zi un cititor nu poate mprumuta, de mai multe ori, aceeai carte. Modelul prezint anomalii (de exemplu, cheia primar de la entitatea carte)! A fost gndit n aceast manier cu scop pur didactic. Entitile i relaiile care intervin n acest model sunt urmtoarele: 1. CARTE (entitate independent) orice carte care se gsete n inventarul bibliotecii. Cheia primar este atributul codel. 2. CITITOR (entitate independent) orice cititor care poate mprumuta cri. Cheia primar este atributul codec. 3. DOMENIU (entitate independenta) domeniul cruia i aparine o carte. Cheia primar este atributul coded.

4. 5.

IMPRUMUTA relaie avnd cardinalitatea m:m care leag entitile CITITOR i CARTE. APARTINE relaie care leag atributele CARTE i DOMENIU. Relaia are cardinalitatea maxim m:1, iar cardinalitatea minim 1:1.

CARTE codel# titlu autor pret nrex

M(1) imprumuta

M(0)

CITITOR codec# nume dep

M(0) apartine

DOMENIU coded# intdom

Gestiunea activitilor de editare dintr-o editur

Se analizeaza activitatea dintr-o editur referitoare la culegerea textelor, realizarea elementelor grafice, machetarea unor publicaii.

SALARIAT cod_salariat# nume job tip

ISA 1 1(0)

M(1) scrie

M(0)

FRAME nr_publicatie# nr_capitol# nr_frame#

M(0) 1 include

GRAFICIAN tip

ISA 1 1(0)

TEHNOREDACTOR tip_editor

M(0)

1 realizeaz

CAPITOL nr_publicatie# nr_capitol#

M(1) cuprinde 1

ISA 1 1(0)

REDACTOR_SEF experienta

M(0) coordoneaza

PUBLICATIE nr_publicatie# stil limba

Gestiunea activitilor unei firme de construcii

Baza de date construit prin acest model, furnizeaz informaii legate de obiective de execuie, investitori, executani, antiere, contracte etc. necesare unui manager al unei firme de construcii

9
SANTIER nr_santier# specialitate sef
1 executa

CONTRACTANT cod_contractant# adresa telefon cont banca

tip_contractant SUBANTREPENOR nume nume_adm functie_adm

executa 1

M(0)

LUCRARE
M( cod_obiectiv# 1) cod_lucrare#

adresa
M(1)

ISA

1(0)

INVESTITOR tip_investitor PERS_FIZICA nume prenume bi

investeste_in 1

necesita 1

ISA 1 ISA 1(0)

OBIECTIV_ INVESTITIE M(1) cod_obiectiv# denumire adresa

1 atasat_la

ISA

PERS_JURIDICA tip_juridic nume functie

1

1 incheie

CONTRACT nr_contract# M(1) tip_contract data_avans

Tabelele din cursurile Oracle Education. Tabelele emp, dept, salgrade modeleaz gestiunea salariailor unei firme. Tabelul emp(empno#, ename, job, mgr, hiredate, sal, com, deptno) conine informaii despre salariaii unei firme. Pentru fiecare salariat sunt definite urmtoarele atribute: empno: codul salariatului; ename: numele salariatului; job: funcia; mgr: codul efului; hiredate: data angajrii; sal: salariul; com: comisionul; deptno: codul departamentului n care lucreaz. Tabelul dept (deptno#, dname, loc) conine informaii despre departamentele n care lucreaz salariaii. Atributele sale reprezint: deptno: codul departamentului; dname: numele departamentului; loc: localitatea unde funcioneaz departamentul. Tabelul salgrade(grade#, losal, hisal) conine informaii despre grilele de salarizare. Atributele tabelului au urmtoarea semnificaie: grade: codul grilei de salarizare; losal: limita inferioar a grilei de salarizare; hisal: limita superioar a grilei de salarizare.

10

Ordonarea informaiilor cu privire la descoperirile de monede antice din Romania

PUNCT
petrecut_in

EVENIMENT

gasita_in

ARTICOL

publicata

MONEDA

stantata_cu

STANTA

inclusa_in

pastrata_la

TEZAUR

MUZEU

STANA (nr_stan, mprat emitent, valoare nominal, an emitere, monetria, legenda de pe avers, legenda de pe revers) == > atribute ale entitii STANTA Completai cardinalitatea!

Evidena colilor de oferi din Romania

SCOALA
cod_scoala#

CLIENT
cod_client#

INSTRUCTOR
cod_instructor#

EXAMEN
cod_examen#

MASINA
cod_masina#

EXAMINATOR
cod_examinator#

Completai relaiile (lucreaza_la, conduce, sustine, asista, instruieste ) dintre entiti i specificai cardinalitatea!

11

Campionatele de fotbal ale diferitelor ri

ECHIPA
Cod_echipa# Nume Oras 2 joaca M(1) sustine M(1)

SPONSOR
Cod_sponsor# Nume

M(1)

MECI
Tara# Nr_etapa# Cod_meci#

M(1) apartine_de 1

ETAPA
Tara Nr_etapa M(1) atasata_la 1

CAMPIONAT
Tara#

12

Modelul relaional
Modelul relaional a fost conceput i dezvoltat de E.F. Codd. El este un model formal de organizare conceptual a datelor, destinat reprezentrii legturilor dintre date, bazat pe teoria matematic a relaiilor. Modelul relaional este alctuit numai din relaii i prin urmare, orice interogare asupra bazei de date este tot o relaie. Cercetarea n domeniu 3 mari proiecte (System R, INGRES, PRTV) Caliti: este simplu; riguros din punct de vedere matematic; nu este orientat spre sistemul de calcul. Modaliti pentru definirea unui SGBD relaional: prezentarea datelor n tabele supuse anumitor operaii de tip proiecie, selecie, reuniune, compunere, intersecie etc. un sistem de baze de date ce suport un limbaj de tip SQL Structured Query Language; un sistem de baze de date care respect principiile modelului relaional introdus de E.F. Codd. structura relaional a datelor; operatorii modelului relaional; regulile de integritate care guverneaz folosirea cheilor n model.

Caracteristicile unui model relaional:

Aceste trei elemente corespund celor trei componente ale ingineriei software: informaie, proces, integritate.

Structura datelor
Definirea noiunilor de domeniu, relaie, schem relaional, valoare null i tabel vizualizare (view). Conceptele utilizate pentru a descrie formal, uzual sau fizic elementele de baz ale organizrii datelor sunt date n urmtorul tabel: Formal relaie tuplu atribut Uzual tablou linie coloan Fizic fiier nregistrare cmp

13

domeniu tip de dat tip de dat Domeniu mulime de valori care poate fi definit fie enumernd elementele componente, fie definind o proprietate distinctiv a domeniului valorilor. Fie D1, D2, ..., Dn domenii finite, nu neaprat disjuncte. Produsul cartezian D1 D2 ... Dn al domeniilor D1, D2, ..., Dn este definit de mulimea tuplurilor (V1, V2, ..., Vn), unde V1 D1, V2 D2, ..., Vn Dn. Numrul n definete aritatea tuplului. O relaie R pe mulimile D1, D2, ..., Dn este o submulime a produsului cartezian D1 D2 ... Dn, deci este o mulime de tupluri. Caracteristicile unei relaii comentat curs! Caracteristicile unei relatii: are o denumire unica; fiecare celula contine o valoare atomica; fiecare atribut are nume unic; toate valorile unui atribut apartin aceluiasi domeniu; ordinea atributelor nu are importanta; nu exista dubluri ale tuplurilor; teoretic, ordinea tuplurilor nu are importanta. Definirea unei relaii se refer la mulimi care variaz n timp. Pentru a caracteriza o relaie este necesar existena un element invariant n timp: structura relaiei (schema relaional). Mulimea numelor atributelor corespunztoare unei relaii R definete schema relaional a relaiei respective. Vom nota schema relaional prin R(A1, A2, ..., An). Exemplu! Putem reprezenta o relaie printr-un tabel bidimensional n care fiecare linie corespunde unui tuplu i fiecare coloan corespunde unui domeniu din produsul cartezian. O coloan corespunde de fapt unui atribut. Numrul atributelor definete gradul (aritatea) relaiei, iar numrul de tupluri din relaie definete cardinalitatea relaiei. Exemplu (crearea unui tabel n SQL): CREATE TABLE salariat ( cod_salariat SMALLINT, nume VARCHAR(25), prenume VARCHAR(20), sex CHAR(1), salariu INTEGER, sot SMALLINT,

14

job_cod cod_departament

VARCHAR(6), SMALLINT );

Cnd se insereaz tupluri ntr-o relaie, de multe ori un atribut este necunoscut sau neaplicabil. Pentru a reprezenta acest atribut a fost introdus o valoare convenional n relaie, i anume valoarea null. Este necesar o aritmetic i o logic nou care s cuprind acest element. Rezultatul operatorilor aritmetici sau logici este null cnd unul din argumente este null. Comentat excepii! Prin urmare, null = null are valoarea null, iar null este null. AND T F Null T T F Null F F F F Null Null F Null OR T F Null T T T T F T F Null Null T Null Null

Tabele de adevr pentru operatorii AND i OR. Multe din echivalentele adevarate in logica cu 2 valori nu mai sunt adevarate in aceasta logica (3VL). De exemplu comparatia x = x nu are in mod necesar valoarea true; expresia p OR NOT (p) nu are in mod necesar valoarea true; expresia t JOIN t nu este evaluata neaparat ca fiind egala cu t, deoarece join-ul, spre deosebire de reuniune, se bazeaza pe verificarea egalitatii in stil de gasire, nu in stil de duplicat. Se observa ca null-urile ruineaza modelul relational. Logica 3VL nu corespunde realitatii, adica rezultatele care sunt corecte conform acestei logici sunt uneori eronate in lumea reala. Modelul relational a functionat perfect fara null in perioada 1969-1979. Este preferabil (in multe cazuri) utilizarea unor valori speciale pentru a reprezenta informatiile lipsa. De exemplu, se poate utiliza valoarea speciala ? pentru a indica numarul de ore lucrate de un salariat. Atentie! Valoarea speciala sa fie de tipul aplicabil. In SQL, tratarea informatiilor lipsa se bazeaza substantial pe logica 3VL. Tabelul vizualizare (view, filtru, relaie virtual, vedere) constituie un filtru relativ la unul sau mai multe tabele, care conine numai informaia necesar unei anumite abordri sau aplicaii. Consultarea vizualizarilor functioneaza perfect. Securitate, reactualizri comentat la curs! Vizualizarea este virtual deoarece datele pe care le conine nu sunt n realitate memorate ntr-o baz de date. Este memorat numai definiia vizualizrii. Vizualizarea nu este definit explicit, ca relaiile de baz, prin mulimea tuplurilor componente, ci implicit, pe baza altor relaii prin intermediul unor expresii relaionale. Stabilirea efectiv a tuplurilor care compun vizualizarea se realizeaz prin evaluarea expresiei atunci cnd utilizatorul se refer la acest tabel. Vezi C.J.Date (capitol 10)!

15

Exemplu (crearea unei vizualizri n SQL): CREATE VIEW programator(nume,departament) AS SELECT nume,cod_departament FROM salariat WHERE job_cod=programator;

de date trebuie s le satisfac.

Reguli de integritate aseriuni pe care datele coninute n baza

Trebuie fcut distincia ntre: regulile structurale inerente modelrii datelor; regulile de funcionare specifice unei aplicaii particulare.

Exist trei tipuri de constrngeri structurale (de cheie, de referin, de entitate) ce constituie mulimea minimal de reguli de integritate pe care trebuie s le respecte un SGBD relaional. Restriciile de integritate minimale sunt definite n raport cu noiunea de cheie a unei relaii. O mulime minimal de atribute ale cror valori identific unic un tuplu ntr-o relaie reprezint o cheie pentru relaia respectiv. Fiecare relaie are cel puin o cheie. 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. Atributele care reprezint cheia primar sunt fie subliniate, fie urmate de semnul #. O cheie identific linii i este diferit de un index care localizeaz liniile. O cheie secundar este folosit ca index pentru a accesa tupluri. Un grup de atribute din cadrul unei relaii care conine o cheie a relaiei poart numele de supercheie. Fie schemele relaionale 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 strin) pentru R1. Modelul relaional respect trei reguli de integritate structural. Regula 1 unicitatea cheii. Cheia primar trebuie s fie unic i minimal.

Regula 2 integritatea entitii. Atributele cheii primare trebuie s fie diferite de valoarea null. Regula 3 integritatea referirii. O cheie extern trebuie s fie ori null n ntregime, ori s corespund unei valori a cheii primare asociate.

16

Proiectarea modelului relaional (exemple curs!)

Transformarea entitilor

Entitile independente devin tabele independente. Cheia primar nu conine chei externe. Entitile dependente devin tabele dependente. Cheia primar a entitilor dependente conine cheia primar a entitii de care depinde (cheie extern) plus unul sau mai multe atribute adiionale. Subentitile devin subtabele. Cheia extern se refer la supertabel, iar cheia primar este aceast cheie extern (cheia primar a subentitii PROGRAMATOR este cod_salariat care este o cheie extern).

Transformarea relaiilor

Relaiile 1:1 i 1:n devin chei externe. Relaia conduce devine coloan n tabelul DEPARTAMENT, iar relaia lucreaza_in devine coloan n tabelul SALARIAT. Simbolul indic plasamentul cheii externe, iar simbolul exprim faptul c aceast cheie extern este coninut n cheia primar. Relaia 1:1 plaseaz cheia extern n tabelul cu mai puine linii. Relaia 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 adiionale. Tabelul se deseneaz punctat. Relaiile de tip trei devin tabele asociative. Cheia primar este compunerea a trei chei externe plus eventuale coloane adiionale.

Transformarea atributelor

Un atribut singular devine o coloan. Atributele multiple devin tabele dependendente ce conin cheia primar a entitii i atributul multiplu. Cheia primar este o cheie extern, plus una sau mai multe coloane adiionale. Entitile devin tabele, iar atributele lor devin coloane n aceste tabele. Ce devin atributele relaiilor? Pentru relaii 1:1 i 1: n, atributele relaiilor vor aparine tabelului care conine cheia

17

extern, iar pentru relaii m:n i de tipul trei, atributele vor fi plasate n tabelele asociative. SALARIAT
cod_salariat#

PROIECT
nr_proiect#

conduce

lucreaza_in

apartine_la

DEPARTAMENT
cod_departament#

SARCINA
nr_proiect# nr_sarcina#

SALARIAT
cod_salariat#

atasat_la
cod_salariat# nr_proiect#

PROIECT
nr_proiect#

TELEFON SALARIAT
cod_salariat# cod_salariat# nr_telefon#

Cele patru tipuri de tabele (independente, dependente, subtabele i asociative) se deosebesc prin structura cheii primare. Tabel Independent Subtabel Dependent Asociativ Reprezint entitate independent subentitate entitate dependent atribute multiple relaie m:n relaii de tip 3 Cheie primar nu conine chei externe o cheie extern o cheie extern i una sau mai multe coloane adiionale dou sau mai multe chei externe i (opional) coloane adiionale

Diagrama conceptual pentru proiectarea modelului relaional comentat a fost construit din diagrama E/R prin adugarea tabelelor asociative i prin marcarea cheilor externe.

18

SALARIAT cod_salariat# salariu nume sex

job_cod AGENT_TERITORIAL zona comision PROGRAMATOR limbaj nivel ATASAT_LA cod_salariat# nr_proiect# functie

PROIECT nr_proiect# descriere buget_alocat

apartine_la

conduce

lucreaza_in

casatorit

DEPARTAMENT cod_departament# nume nr_cladire

TELFON cod_salariat# nr_telefon#

SARCINA nr_proiect# nr_sarcina# data_inceperii stare

Schemele relaionale corespunztoare acestei diagrame conceptuale sunt urmtoarele: SALARIAT(cod_salariat#, nume, prenume, sex, job_cod, cod_sot, forma_plata, nr_depart); DEPARTAMENT(cod_departament#, nume, numar_cladire, cod_sal); ATASAT_LA(cod_salariat#, nr_proiect#, functia); PROIECT(nr_proiect#, descriere, buget_alocat); SARCINA(nr_proiect#, nr_sarcina, data_inceperii, stare); AGENT_TERITORIAL(cod_salariat#, zona, comision); PROGRAMATOR(cod_salariat#, limbaj, nivel); TELEFON(cod_salariat#, nr_telefon#).

19

Gestiunea activitilor unei firme de construcii

CONTRACTANT(cod_contractant#, tip_contractant); adresa, telefon, cont, banca,

SUBANTREPRENOR(cod_contractant#, nume, nr_reg_comert, nume_adm, functie_adm); INVESTITOR(cod_contractant#, tip_investitor); PERS_FIZICA(cod_contractant#, nume, prenume, bi); PERS_JURIDICA(cod_contractant#, tip_juridic, nume, reprez_legal, functie); CONTRACT(nr_contract#, tip_contract, data_incheiere, garantie, val_investitie, durate_executie, cont, banca, perioada, avans, data_avans, cod_contractant); SANTIER(nr_santier#, specialitate, sef); OBIECTIV_INVESTITIE(cod_obiectiv#, denumire, adresa, adc, nr_cert_urb, nr_aut_constr, nr_contract, cod_contractant); LUCRARE(cod_lucrare#, cod_obiectiv#, tip_lucrare, nume, data_inc, data_sf, nr_santier, cod_contractant);

20

CONTRACTANT cod_contractant# adresa telefon cont banca

tip_contractant SUBANTREPENOR nume nume_adm funcie_adm LUCRARE cod_lucrare# executa cod_obiectiv# ANTIER nr_antier# specialitate ef

executa

necesita

INVESTITOR tip_investitor

OBIECTIV_INVESTITIE cod_obiectiv# denumire adresa

PERS_FIZICA nume prenume bi

investeste_in

atasat_la

CONTRACT PERS_JURIDICA tip_juridic nume functie nr_contract# tip_contract data_avans

incheie

21

Gestiunea activitilor de editare dintr-o editur

SALARIAT cod_salariat# nume job GRAFICIAN tip TEHNOREDACTOR tip_editor REDACTOR_SEF experienta coordoneaza TELEFON cod_salariat# nr_telefon# LIMBA cod_salariat# limba_cun# PUBLICATIE nr_publicatie# stil REALIZEAZA cod_salariat# nr_publicatie# nr_capitol# nr_frame# FRAME nr_publicatie# nr_capitol# nr_frame# tip include scrie CAPITOL nr_publicatie# nr_capitol# dimensiune cuprinde

SALARIAT(cod_salariat#, nume, prenume, vechime, salariu, job); GRAFICIAN(cod_salariat#, tip); TEHNOREDACTOR(cod_salariat#, tip_platforma, tip_editor, viteza); REDACTOR_SEF(cod_salariat#, experienta); LIMBA(cod_salariat#, limba_cunos#); TELEFON(cod_salariat#, nr_telefon#); REALIZEAZA(cod_salariat#, nr_frame#, nr_publicatie#, nr_capitol#, data_inc, data_lim); FRAME(nr_frame#, nr_publicatie#, nr_capitol#, tip, dim, format); CAPITOL(nr_publicatie#, nr_capitol#, dimensiune, cod_salariat); PUBLICATIE(nr_publicatie#, stil, beneficiar, autor, cod_salariat, cost, titlu, limba). Exemple curs!

22

Algebra relaional
Limbajul de definire a datelor (LDD) precizeaz entitile, relaiile dintre ele, atributele, structura atributelor, cheile, constrngerile, prin urmare definete structura obiectelor bazei de date (schema bazei). Limbajul de prelucrare a datelor (LMD) dintr-o baz de date relaionale cuprinde aspecte referitoare la introducerea, eliminarea, modificarea i cutarea datelor. Introducerea datelor permite adugarea de tupluri la o relaie. Tuplurile pot fi introduse de utilizator sau pot fi obinute din alte relaii existente n baza de date. Eliminarea datelor permite tergerea tuplurilor ce satisfac condiii date. Modificarea datelor permite reactualizarea tuplurilor ce satisfac condiii date cu noi valori ale atributelor sau cu rezultate ale unor operaii aritmetice efectuate asupra unor valori existente. Cutarea datelor permite gsirea tuplurilor sau a unor pri ale tuplurilor ce satisfac condiii date.

Modelul relaional ofer dou mulimi de operatori pe relaii: algebra relaional (filtrele se obin aplicnd operatori specializai asupra uneia sau mai multor relaii din cadrul bazei relaionale); calculul relaional (filtrele se obin cu ajutorul unor formule logice pe care tuplurile rezultatului trebuie s le satisfac). Algebra relaional a fost introdus de E.F. Codd ca o mulime de operaii formale acionnd asupra unor relaii i avnd ca rezultat alte relaii. Baza teoretic pentru limbajele de interogare relaionale o constituie operatorii introdui de Codd pentru prelucrarea relaiilor. Operatorii modelului relaional definesc operaiile care se pot efectua asupra relaiilor n scopul realizrii funciilor de prelucrare asupra BD. Operatorii sunt numai pentru citire (nu actualizeaza operanzi)!!! Scopul fundamental al algebrei relationale este de a permite scrierea expresiilor relationale. Expresiile servesc ca o reprezentare de nivel superior, simbolic, a inteniilor utilizatorului i pot fi supuse unei diversiti de reguli de transformare (optimizare).

23

Relaiile sunt nchise fa de algebra relaional (operanzii i rezultatele sunt relaii ieirea unei operaii poate deveni intrare pentru alta) posibilitatea imbricrii rxpresiilor n algebra relaional). Operatorii algebrei relaionale sunt: operatori tradiionali pe mulimi (UNION, INTERSECT, PRODUCT, DIFFERENCE); operatori relaionali speciali (PROJECT, SELECT, JOIN, DIVISION). Calculul relaional reprezint o adaptare a calculului predicatelor la domeniul bazelor de date relaionale. Ideea de baz este de a identifica o relaie cu un predicat. Pe baza unor predicate iniiale, prin aplicarea unor operatori ai calculului cu predicate (conjuncia, disjuncia, negaia, cuantificatorul existenial i cel universal) se pot defini noi relaii. Calculul relaional poate s fie orientat pe tupluri sau orientat pe domenii. Echivalena dintre algebra relaional i calculul relaional a fost demonstrat de J.D.Ullman. Aceast echivalen arat c orice relaie posibil de definit n algebra relaional poate fi definit i n cadrul calcului relaional, i reciproc. Operatorii (unari sau binari) algebrei relaionale realizeaz urmtoarele funcii: SELECT (selecie) extrage tupluri ce satisfac o condiie specificat; PROJECT (proiecie) extrage atributele specificate; DIFFERENCE (diferen) extrage tupluri care apar ntr-o relaie, dar nu apar n cealalt; PRODUCT (produs cartezian) genereaz toate perechile posibile de tupluri, primul element al perechii fiind luat din prima relaie, iar cel deal doilea element din cealalt relaie; UNION (reuniune) reunete dou relaii; INTERSECT (intersecie) extrage tupluri care apar n ambele relaii; DIVISION (diviziune) extrage valorile atributelor dintr-o relaie, care apar n toate valorile atributelor din cealalt relaie; JOIN (compunere) extrage tupluri din mai multe relaii corelate: NATURAL JOIN (compunere natural) combin tupluri din dou relaii, cu condiia ca atributele comune s aib valori identice;

24

SEMI-JOIN (semi-compunere) selecteaz tupluri ce aparin unei singure relaii, care sunt corelate cu tupluri din cea de a doua relaie; -JOIN (-compunere) combin tupluri din dou relaii (nu neaparat corelate), cu condiia ca valorile atributelor specificate s satisfac o anumit condiie; OUTER JOIN (compunere extern) combin tupluri din dou relaii, astfel nct condiiile de corelare s fie satisfcute. Tuplurile din orice relaie care nu satisfac aceste condiii sunt completate cu valori null. Pentru operatorii UNION, INTERSECT i DIFFERENCE, se presupune c sunt aplicai numai la relaii avnd aceeai aritate, iar ordinea (nu numele) atributelor este aceeai.

Operatorul PROJECT
Proiecia este o operaie unar care elimin anumite atribute ale unei relaii producnd o submulime pe vertical a acesteia. Suprimarea unor atribute poate avea ca efect apariia unor tupluri duplicate, care trebuie eliminate. Prin proiecie se construiete dintr-o relaie R, o nou relaie: a) tergnd din R atributele care nu sunt menionate n parametrii proieciei; b) eliminnd dublurile care apar dup tergere. Pentru a reprezenta operatorul proiecie sunt utilizate diferite notaii: A1, ..., Am (R) R[A1, ..., Am] unde A1, A2, ..., Am sunt parametrii proieciei relativ la relaia R. Exemplu. S se obin o list ce conine numele, prenumele i sexul angajailor. 1. Proiecie n algebra relaional: Rezultat = PROJECT(SALARIAT, nume, prenume, sex) Proiecie cu dubluri n SQL: SELECT nume, prenume, sex FROM salariat;
2.

PROJECT (R, A1, ..., Am)

Proiecie fr dubluri n SQL: SELECT DISTINCT nume, prenume, sex FROM salariat;
3.

25

Operatorul SELECT
Selecia (restrictia) este o operaie unar care produce o submulime pe orizontal a unei relaii R. Aceast submulime se obine prin extragerea tuplurilor din R care satisfac o condiie specificat. Sunt utilizate diferite notaii: condiie(R) SELECT(R, condiie) R[condiie] RESTRICT(R, condiie).

Exemplu. S se obin informaii complete despre angajaii de sex masculin.

1.

Selecie n algebra relaional:

Rezultat = SELECT(SALARIAT, sex = m) Selecie n SQL: SELECT * FROM salariat WHERE sex = m;
2.

Operatorul UNION
Reuniunea a dou relaii R i S este mulimea tuplurilor aparinnd fie lui R, fie lui S, fie ambelor relaii. Sunt utilizate notaiile: RS UNION(R, S) OR(R, S) APPEND(R, S). Exemplu. S se obin lista cu numele persoanelor fizice i a subantreprenorilor. SELECT nume FROM subantreprenor UNION SELECT nume FROM pers_fizica;

26

Operatorul DIFFERENCE
Diferena a dou relaii R i S este mulimea tuplurilor care aparin lui R, dar nu aparin lui S. Diferena este o operaie binar necomutativ care permite obinerea tuplurilor ce apar numai ntr-o relaie. Sunt utilizate diferite notaii: RS DIFFERENCE(R, S) REMOVE(R, S) MINUS(R, S). Exemplu. S se obin lista cu numrul contractului, tipul contractului, valoarea investiiei i durata lucrrii pentru contractele de subantrepriz pentru care valoarea investiiei nu depete 60000$.
1. Diferen n algebra relaional:

R=PROJECT(SELECT(CONTRACT, tip_contract=T), nr_contract, tip_contract, val_investitie, durata_lucrare); S=PROJECT(SELECT(CONTRACT, val_investitie > 60000), nr_contract, tip_contract, val_investitie, durata_lucrare); Rezultat = DIFFERENCE(R, S)
2. Diferena n SQL:

SELECT

FROM WHERE MINUS SELECT nr_contract,tip_contract, val_investitie,durata_lucrare FROM contract WHERE val_investitie>60000; Evident diferena se poate referi la tabele diferite! Implementai cererea prin care se listeaz toate oraele n care se afl o filial, dar nici o proprietate.

nr_contract,tip_contract, val_investitie,durata_lucrare contract tip_contract

Operatorul INTERSECT
Intersecia a dou relaii R i S este mulimea tuplurilor care aparin i lui R i lui S. Operatorul INTERSECT este un operator binar, comutativ, derivat:

27

R S = R (R S) R S = S (S R). Sunt utilizate diferite notaii: INTERSECT(R, S) RS AND(R, S). n anumite dialecte SQL exist operator special (INTERSECT), care realizeaz aceast operaie. Operatorii INTERSECT i DIFFERENCE pot fi simulai n SQL (n cadrul comenzii SELECT) cu ajutorul opiunilor EXISTS, NOT EXISTS, IN, != ANY. Exemplu. Utiliznd tabelele agent_teritorial i programator s se obin lista codurilor salariailor care sunt programatori, dar care lucreaz i ca ageni teritoriali.
1.

Intersecie n algebra relaional:

R = PROJECT(AGENT_TERITORIAL, cod_salariat); S = PROJECT(PROGRAMATOR, cod_salariat), Rezultat = INTERSECT(R, S). Intersecie n SQL: SELECT cod_salariat FROM agent_teritorial INTERSECT SELECT cod_salariat FROM programator;
2.

Simularea interseciei n SQL: SELECT cod_salariat FROM programator p WHERE EXISTS (SELECT cod_salariat FROM agent_teritorial a WHERE p.cod_salariat=a.cod_salariat);
3.

Operatorul PRODUCT
Fie R i S relaii de aritate m, respectiv n. Produsul cartezian al lui R cu S este mulimea tuplurilor de aritate m + n unde primele m componente formeaz un tuplu n R, iar ultimele n componente formeaz un tuplu n S. Sunt utilizate diferite notaii:

28

RS PRODUCT(R, S) TIMES(R, S). Exemplu. S se obin lista tuturor posibilitilor de investiie n diverse obiective de ctre o firm care este persoan juridic.
1.

Produs cartezian n algebra relaional:

R = PROJECT(PERS_JURIDICA, nume, cod_contractant); S = PROJECT(OBIECTIV_INVESTITIE, denumire); Rezultat = PRODUCT(R, S). Produs cartezian n SQL: SELECT cod_contractant, nume, denumire FROM obiectiv_investitie, pers_juridica;
2.

Operatorul DIVISION
Diviziunea este o operaie binar care definete o relaie ce conine valorile atributelor dintr-o relaie care apar n toate valorile atributelor din cealalt relaie. Sunt utilizate diferite notaii: DIVIDE(R, S) DIVISION(R, S) R S. Diviziunea conine acele tupluri de dimensiune n m la care, adugnd orice tuplu din S, se obine un tuplu din R. Operatorul diviziune poate fi exprimat formal astfel: R(n) S(m) = {t(n-m) s S, (t, s) R} unde n > m i S . Operatorul DIVISION este legat de cuantificatorul universal ( ) care nu exist n SQL. Cuantificatorul universal poate fi ns simulat cu ajutorul cuantificatorului existenial () utiliznd relaia: x P(x) x P(x). Prin urmare, operatorul DIVISION poate fi exprimat n SQL prin succesiunea a doi operatori NOT EXISTS. Exemplu. S se obin codurile salariailor ataai tuturor proiectelor pentru care s-a alocat un buget egal cu 1000.
1.

Diviziune n algebra relaional:

29

R = PROJECT(ATASAT_LA, cod_salariat, nr_proiect); S = PROJECT(SELECT(PROIECT, buget = 1000), nr_proiect); Rezultat = DIVISION(R, S). Diviziune n SQL: SELECT UNIQUE cod_salariat FROM atasat_la sx WHERE NOT EXISTS (SELECT * FROM proiect pp WHERE proiect.buget=1000 AND NOT EXISTS (SELECT * FROM atasat_la bb WHERE pp.nr_proiect=bb.nr_proiect AND bb.cod_salariat=sx.cod_salariat));
2.

Simularea diviziunii cu ajutorul funciei COUNT: SELECT cod_salariat FROM atasat_la WHERE nr_proiect IN (SELECT nr_proiect FROM proiect WHERE buget=1000) GROUP BY cod_salariat HAVING COUNT(nr_proiect)= (SELECT COUNT(*) FROM proiect WHERE buget=1000);
3.

Operatorul JOIN
Operatorul de compunere (uniune) permite regsirea informaiei din mai multe relaii corelate. Operatorul combin produsul cartezian, selecia i proiecia.

Operatorul NATURAL JOIN

Operatorul de compunere natural (NATURAL JOIN) combin tupluri din dou relaii R i S, cu condiia ca atributele comune s aib valori identice. Algoritmul care realizeaz compunerea natural este urmtorul:
1.

se calculeaz produsul cartezian R S;

30

2.

pentru fiecare atribut comun A care definete o coloan n R i o coloan n S, se selecteaz din R S tuplurile ale cror valori coincid n coloanele R.A i S.A (atributul R.A reprezint numele coloanei din R S corespunztoare coloanei A din R); pentru fiecare astfel de atribut A se proiecteaz coloana S.A, iar coloana R.A se va numi A. JOIN(R, S) = i1,...,im (R.A1 = S.A1) ... (R.Ak = S.Ak)(R S),

3.

Operatorul NATURAL JOIN poate fi exprimat formal astfel: unde A1, ..., Ak sunt atributele comune lui R i S, iar i1, ..., im reprezint lista componentelor din R S (pstrnd ordinea iniial) din care au fost eliminate componentele S.A1, ..., S.Ak. Exemplu. S se obin informaii complete despre angajai i departamentele n care lucreaz.
1.

Operatorul de compunere natural n algebra relaional:

Rezultat = JOIN(SALARIAT, DEPARTAMENT). Operatorul de compunere natural n SQL: SELECT * FROM salariat, departament WHERE nr_depart = cod_departament;
2.

Operatorul -JOIN
Operatorul -JOIN combin tupluri din dou relaii (nu neaprat corelate) cu condiia ca valorile atributelor specificate s satisfac o anumit condiie specificat explicit n cadrul operaiei. Operatorul -JOIN este un operator derivat, fiind o combinaie de produs scalar i selecie: JOIN(R, S, condiie) = condiie (R S) Exemplu. S se afieze pentru fiecare salariat, codul acestuia i grila sa de salarizare. SELECT empno, level FROM salgrade, emp WHERE sal BETWEEN losal AND hisal; Exemplu. S se obin informaii despre contractani (codul i banca) i obiectivele de investiie asociate acestora (denumire, numr certificat de urbanizare) cu condiia ca obiectivele s nu fie la aceeai adres ca i contractanii.

31

1.

Operatorul -JOIN n algebra relaional:

R = PROJECT(CONTRACTANT, cod_contractant, banca); S = PROJECT(OBIECTIV_INVESTITIE, denumire, nr_cert_urb); Rezultat = JOIN(R, S, OBIECTIV_INVESTITIE.adresa <> CONTRACTANT.adresa). Opratorul -JOIN n SQL: SELECT cod_contractant,banca, nr_cert_urb, denumire FROM contractant a,obiectiv_investitie b WHERE b.adresa <> a.adresa;
2.

Operatorul SEMI-JOIN
Operatorul SEMI-JOIN conserv atributele unei singure relaii participante la compunere i este utilizat cnd nu sunt necesare toate atributele compunerii. Operatorul este asimetric. Tupluri ale relaiei R care particip n compunerea (natural sau -JOIN) dintre relaiile R i S. SEMI-JOIN este un operator derivat, fiind o combinaie de proiecie i compunere natural sau proiecie i -JOIN: SEMIJOIN(R, S) = M (JOIN(R, S)) SEMIJOIN(R, S, condiie) = M (JOIN(R, S, condiie)), unde am notat prin M atributele relaiei R. Exemplu. S se obin informaii referitoare la persoanele fizice (nume, buletin) care investesc n obiective cu caracter recreativ.
1.

Operatorul SEMI-JOIN n algebra relaional:

R = SELECT(OBIECTIV_INVESTITIE, denumire = cabana OR denumire = casa de vacanta) S = JOIN(PERS_FIZICA, R) Rezultat = PROJECT(S, nume, buletin). Operatorul SEMI-JOIN n SQL: SELECT nume,bi FROM pers_fizica a,obiectiv_investitie b WHERE a.cod_contractant = b.cod_contractant AND (denumire=cabana)OR (denumire= casa de vacanta);
2.

32

Operatorul OUTER JOIN

Operaia de compunere extern combin tupluri din dou relaii pentru care sunt satisfcute condiiile de corelare. n cazul aplicrii operatorului JOIN se pot pierde tupluri, atunci cnd exist un tuplu n una din relaii pentru care nu exist nici un tuplu n cealalt relaie, astfel nct s fie satisfcut relaia de corelare. Operatorul elimin acest inconvenient prin atribuirea valorii null valorilor atributelor care exist ntr-un tuplu din una dintre relaiile de intrare, dar care nu exist i n cea de-a doua relaie. Practic, se realizeaz compunerea a dou relaii R i S la care se adaug tupluri din R i S, care nu sunt coninute n compunere, completate cu valori null pentru atributele care lipsesc. Compunerea extern poate fi: LEFT, RIGHT, FULL. De exemplu, OUTER JOIN LEFT reprezint compunerea n care tuplurile din R, care nu au valori similare n coloanele comune cu relaia S, sunt de asemenea incluse n relaia rezultat. Exemplu. S se obin informaii referitoare la persoanele fizice care sunt investitori (chiar dac nu au investit n obiective industriale) i la obiectivele de investiie industriale (chiar i cele care nu sunt construite de persoane fizice). R = SELECT(OBIECTIV_INVESTITIE, denumire = 'industrial') Rezultat = OUTERJOIN(PERS_FIZICA, R). Operatorii algebrei relaionale pot fi reprezentai grafic cu ajutorul unor simboluri speciale. curs! Operaii adiionale: complement, despicare, nchidere tranzitiv. Funcii asociate: MIN, MAX, COUNT, AVG, SUM, VAR, STD etc.

33

Evaluarea i optimizarea interogrilor

Procesarea interogrilor
O expresie a algebrei relaionale este constituit din relaii legate prin operaii din algebra relaional. O expresie se poate reprezenta grafic cu ajutorul unui arbore, numit arbore algebric, n care nodurile corespund operatorilor din cadrul expresiei respective. Evaluarea unei expresii presupune efectuarea prelucrrilor indicate de operatorii din expresie n ordinea apariiilor sau n ordinea fixat prin paranteze. Rezultatul evalurii unei expresii este o relaie derivat din relaiile menionate ca operanzi n cadrul expresiei. Dou expresii sunt echivalente, dac n urma evalurii lor se obine ca rezultat aceeai relaie. Exemple referitoare la moduri echivalente de exprimare a unei cereri (vor fi rezolvate la curs!). 1. Informaii despre salariaii care nu contribuie la machetarea nici unei publicaii, dar au retribuia mai mare dect o valoare dat. 2. Codul i numele subantreprenorilor care au realizat lucrri specializate la obiective case de vacan sau cabane. 3. Codurile i telefoanele investitorilor, valoarea si durata de execuie a investitiilor a caror valoare este ntre dou limite specificate. 4. Perioada de desfurare i preul ofertelor care ncep dup 1 ianuarie 2003 i sunt: sejururi la munte; excursii n care autocarele sunt conduse de oferi angajai dup 1 mai 1987 i supravegheate de ghizi ce cunosc limba englez care au fcut specializare n Suedia. n majoritatea sistemelor de gestiune, i n special n cele relaionale, interfaa cu utilizatorul este de tip neprocedural. Utilizatorul definete datele pe care dorete s le vizualizeze fr a da algoritmii de acces. Sistemul trebuie s converteasc cererea utilizatorului: ntr-o cerere optimal; n proceduri de acces optimal la datele fizice. Garantarea absolut a performanelor optime pentru procesorul limbajului relaional este imposibil. Corect ar fi utilizarea cuvntului ameliorare n locul cuvntului optimizare.

34

Evaluarea unei interogri se efectueaz n trei etape.

Analiza cererii presupune studierea sintactic i semantic a cererii pentru a verifica corectitudinea sa i a simplifica criteriul de cutare. Ordonanarea presupune descompunerea cererii ntr-o mulime de operaii elementare i determinarea unei ordini optimale a acestor operaii. Operaiile sunt, n general, cele ale algebrei relaionale. La sfritul etapei se obine un plan de execuie pentru cerere. Execuia presupune efectuarea (paralel i/sau secvenial) operaiilor elementare furnizate de planul de execuie pentru a obine rezultatul cererii.

Presupunem c utilizatorul transmite sistemului de gestiune o cerere exprimat prin ordine SQL. Pentru a rspunde cererii, SGBD-ul trebuie s neleag cererea utilizatorului. Cererea trebuie s fie corect sintactic, datele trebuie s fie disponibile utilizatorului i trebuie localizate analiznd diferite drumuri de acces la ele. Aceste funcii sunt realizate de SGBD cu ajutorul a dou module funcionale care comunic permanent:

analizorul cererilor, care asigur verificarea sintactic i semantic a cererii, localizarea datelor implicate n cerere (gsirea adresei blocurilor ce conin datele), furnizarea planului de execuie. administratorul datelor (executorul), care execut efectiv cererea (primete planurile de execuie furnizate de modulul de optimizare i le execut). Execuia presupune cutarea blocurilor ce conin datele i transferul blocurilor n memoria cache.

Ideea general: cerere arbore algebric (nu este unic) plan de executie optimizare Un plan de execuie implic o secven de pai pentru evaluarea cererii (n mod obinuit, fiecare pas din planul de execuie corespunde unei operaii relaionale) precum i metoda care va fi folosit pentru evaluarea operaiei. De obicei, pentru o operaie relaional dat, exist mai multe metode ce pot fi folosite pentru evaluarea acesteia. Dou planuri de execuie diferite care au ntotdeauna acelai rezultat se numesc echivalente. Planuri de execuie echivalente pot avea diferite costuri. Scopul optimizrii cererilor este de a gsi, printre diversele planuri de execuie echivalente, pe acela de cost minim. ntr-un sistem centralizat, costul evalurii unei cereri este suma a dou componente, costul I/O (transferuri de date) i costul CPU (verificare de condiii, operaii join etc.).

35

Ordinea de execuie a operaiilor

O interogare const dintr-un numr de operaii. Ordinea n care se efectueaz operaiile are un rol important n evaluarea costului necesar realizrii interogrii. Exist dou modaliti de abordare pentru a determina ordinea de execuie a operaiilor: algebric; bazat pe estimarea costului. Ambele folosesc o mulime de reguli care permit transformarea unui plan de execuie (reprezentat ca o expresie scris n termenii algebrei relaionale) n altul, echivalent. Optimizarea cererilor bazat pe algebra relaional se realizeaz n dou etape: se exprim cererile sub forma unor expresii algebrice relaionale; se aplic acestor expresii transformri algebrice care conduc la expresii echivalente, dar care vor fi executate mai eficient. Procesul de transformare a cererilor se realizeaz conform unei strategii de optimizare care poate s fie: independent de modul de memorare a datelor (strategie general); dependent de modul de memorare (strategie specific unui anumit SGBD).

Proprietile operatorilor algebrei relaionale

Proprietatea 1. Comutativitatea operaiilor de join i produs cartezian: JOIN(R1, R2) = JOIN(R2, R1) R1 R2 = R2 R1 Proprietatea 2. Asociativitatea operaiilor de join i produs cartezian: JOIN(JOIN(R1, R2), R3) = JOIN(R1, JOIN(R2, R3)) (R1 R2) R3 = R1 (R2 R3) Proprietatea 3. Compunerea proieciilor: A1,...,Am (B1,...,Bn (R)) = A1,...,Am (R), unde {A1, A2,...,Am } {B1, B2,...,Bn}. Proprietatea 4. Compunerea seleciilor: cond1 (cond2 (R)) = cond1cond2 (R) = cond2 (cond1 (R)), unde am notat prin cond condiia dup care se face selecia.

36

Proprietatea 5. Comutarea seleciei cu proiecia: A1,...,Am (cond (R)) = cond (A1,...,Am (R)), unde condiia dup care se face selecia implic numai atributele A1,...,Am. Dac condiia implic i atributele B1,...,Bn, care nu aparin mulimii {A1,...,Am}, atunci: A1,...,Am (cond (R)) = A1,...,Am (cond (A1,...,Am,B1,...,Bn (R))) Proprietatea 6. Comutarea seleciei cu produsul cartezian: Dac toate atributele menionate n condiia dup care se face selecia sunt atribute ale relaiei R1, atunci: cond (R1 R2) = cond (R1) R2 Dac condiia este de forma cond1cond2 i dac cond1 implic numai atribute din R1, iar cond2 implic numai atribute din R2, atunci cond (R1 R2) = cond1 (R1) cond2 (R2) Dac cond1 implic numai atribute din R1, iar cond2 implic atribute att din R1 ct i din R2, atunci: cond (R1 R2) = cond2 (cond1 (R1) R2) Proprietatea 7. Comutarea seleciei cu reuniunea: cond (R1 R2) = cond (R1) cond (R2) Proprietatea 8. Comutarea seleciei cu diferena: cond (R1 R2) = cond (R1) cond (R2) Proprietatea 9. Comutarea proieciei cu reuniunea: A1,...,Am (R1 R2) = A1,...,Am (R1) A1,...,Am (R2) Proprietatea 10. Comutarea proieciei cu produsul cartezian: Dac A1,...,Am este o list de atribute ce apar n schemele relaionale R1 i R2 i dac lista este format din atribute aparinnd lui R1 (notate prin B1,...,Bn) i din atribute aparinnd lui R2 (notate prin C1,...,Ck) atunci: A1,...,Am (R1 R2) = B1,...,Bn (R1) C1,...,Ck (R2) Proprietatea 11. Compunerea proieciei cu operaia join: Dac A1,...,Am este o list de atribute ce apar n schemele relaionale R1 i R2 i dac lista este format din atribute aparinnd lui R1 (notate prin B1,...,Bn) i din atribute aparinnd lui R2 (notate prin C1,...,Ck) atunci: A1,...,Am (JOIN(R1,R2,D)) = A1,...,Am (JOIN(D,B1,...,Bn(R1), D,C1,...,Ck(R2),D), unde am notat prin JOIN(R1, R2, D) operaia de compunere natural ntre R1 i R2 dup atributul comun D.

37

Proprietatea 12. Compunerea seleciei cu operaia join: cond (JOIN (R1, R2, D)) = cond (JOIN (D,A (R1), D,A (R2), D)), unde A reprezint atributele care apar n condiia dup care se face selecia.

Reguli de optimizare frecvent folosite:

Regula de optimizare 1. Seleciile se execut ct mai devreme posibil. Motivaia acestei reguli este c seleciile reduc substanial dimensiunea relaiilor. Regula de transformare 4 poate fi folosit pentru a separa dou sau mai multe selecii n selecii individuale care pot fi distribuite join-ului sau produsului cartezian folosind comutarea seleciei cu join-ul. Regula de optimizare 2. Produsurile carteziene se nlocuiesc cu join-uri, ori de cte ori este posibil. Un produs cartezian ntre dou relaii este de obicei mult mai scump (ca i cost) dect un join ntre cele dou relaii, deoarece primul genereaz concatenarea tuplurilor n mod exhaustiv i poate genera un rezultat foarte mare. Aceast transformare se poate realiza folosind legtura dintre produs cartezian, join i selecie. Regula de optimizare 3. Dac sunt mai multe join-uri atunci cel care se execut primul este cel mai restrictiv. Un join este mai restrictiv dect altul dac produce o relaie mai mic. Se poate determina care join este mai restrictiv pe baza factorului de selectivitate sau cu ajutorul informaiilor statistice. Algebric, acest lucru se poate realiza folosind regula de transformare 2. Regula de optimizare 4. Proieciile se execut la nceput pentru a ndeprta atributele nefolositoare. Dac un atribut al unei relaii nu este folosit n operaiile ulterioare atunci trebuie ndeprtat. n felul acesta se va folosi o relaie mai mic n operaiile ulterioare. Aceasta se poate realiza folosind comutarea proieciei cu join-ul. Exemple curs!!!

Regulile lui Codd

Caracteristici ale modelului relaional: nu exist tupluri identice; ordinea liniilor i a coloanelor este arbitrar; articolele unui domeniu sunt omogene; fiecare coloan definete un domeniu distinct i nu se poate repeta n cadrul aceleiai relaii;

38

toate valorile unui domeniu corespunztoare tuturor cazurilor nu mai pot fi descompuse n alte valori (sunt atomice). Avantajele modelului relaional: fundamentare matematic riguroas; independen fizic a datelor; posibilitatea filtrrilor; existena unor structuri de date simple; realizarea unei redundane minime; suplee n comunicarea cu utilizatorul neinformatician. Ca limite ale modelului relaional putem meniona: rmne totui redundan, ocup spaiu, apar fenomene de inconsisten, nu exist mecanisme pentru tratarea optim a cererilor recursive, nu lucreaz cu obiecte complexe, nu exist mijloace perfecionate pentru exprimarea constrngerilor de integritate, nu realizeaz gestiunea totala a datelor distribuite, nu realizeaz gestiunea cunotinelor. 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 relaional. Nici un sistem de gestiune a bazelor de date pus n vnzare pe piaa comercial nu respect absolut toate regulile definite de Codd, dar acest lucru nu mpiedic etichetarea acestor sisteme drept relaionale. Nu trebuie apreciat un SGBD ca fiind relaional sau nu, ci msura n care acesta este relaional, deci numrul regulilor lui Codd pe care le respect. Regula 1 regula gestionrii datelor. Un SGBD relaional trebuie s fie capabil s gestioneze o baz de date numai prin posibilitile sale relaionale.

39

Regula 2 regula reprezentrii informaiei. ntr-o baz de date relaional, informaia este reprezentat la nivel logic sub forma unor tabele ce poart numele de relaii. Regula 3 regula accesului garantat la date. Fiecare valoare dintr-o baz de date relaional trebuie s poat fi adresat n mod logic printr-o combinaie format din numele relaiei, valoarea cheii primare i numele atributului. Regula 4 regula reprezentrii informaiei necunoscute. Un sistem relaional trebuie s permit utilizatorului definirea unui tip de date numit null pentru reprezentarea unei informaii necunoscute la momentul respectiv. Regula 5 regula dicionarelor de date. Asupra descrierii bazelor de date (informaii relative la relaii, vizualizri, indeci etc. ) trebuie s se poat aplica aceleai operaii ca i asupra datelor din baza de date. Regula 6 regula limbajului de interogare. Trebuie s existe cel puin un limbaj pentru prelucrarea bazei de date. Regula 7 regula de actualizare a vizualizrii. Un SGBD trebuie s poat determina dac o vizualizare poate fi actualizat i s stocheze rezultatul interogrii ntr-un dicionar de tipul unui catalog de sistem. Regula 8 regula limbajului de nivel nalt. Regulile de prelucrare asupra unei relaii luat ca ntreg sunt valabile att pentru operaiile de regsire a datelor, ct i asupra operaiilor de inserare, actualizare i tergere a datelor. Regula 9 regula independenei fizice a datelor: Programele de aplicaie i activitile utilizatorilor nu depind de modul de depunere a datelor sau de modul de acces la date. Regula 10 regula independenei logice a datelor. Programele de aplicaie trebuie s fie transparente la modificrile de orice tip efectuate asupra datelor. Regula 11 regula independenei datelor din punct de vedere al integritii. Regulile de integritate trebuie s fie definite ntr-un sublimbaj relaional, nu n programul de aplicaie. Regula 12 regula independenei datelor din punct de vedere al distribuirii. Distribuirea datelor pe mai multe calculatoare dintr-o reea de comunicaii de date, nu trebuie s afecteze programele de aplicaie. Regula 13 regula versiunii procedurale a unui SGBD. Orice component procedural a unui SGBD trebuie s respecte aceleai restricii de integritate ca i componenta relaional.

40

Deoarece regulile lui Codd sunt prea severe pentru a fi respectate de un SGBD operaional, s-au formulat criterii minimale de definire a unui sistem de gestiune relaional. Un SGBD este minimal relaional dac: toate datele din cadrul bazei sunt reprezentate prin valori n tabele; nu exist pointeri observabili de ctre utilizator; sistemul suport operatorii relaionali de proiecie, selecie i compunere natural, fr limitri impuse din considerente interne. Un SGBD este complet relaional dac este minimal relaional i satisface n plus condiiile: sistemul suport restriciile de integritate de baz (unicitatea cheii primare, constrngerile refereniale, integritatea entitii). sistemul suport toate operaiile de baz ale algebrei relaionale.

NORMALIZAREA RELAIILOR
n procesul modelrii unei baze de date relaionale, o etap important o reprezint normalizarea relaiilor conceptuale (Codd, 1972), adic obinerea de relaii molecularefr a pierde nimic din informaie pentru a elimina: redundana; anomaliile reactualizrii informaiilor. Tehnica normalizrii permite obinerea unei scheme conceptuale rafinate printr-un proces de ameliorare progresiv a unei scheme conceptuale iniiale a bazei de date relaionale. Dup fiecare etap de ameliorare, relaiile bazei de date ating un anumit grad de perfeciune, deci se afl ntr-o anumit form normal. Trecerea unei relaii dintr-o form normal n alta, presupune eliminarea unei anumit tip de dependene nedorite, care sunt transformate n dependene admisibile, adic dependene care nu provoac anomalii. Procesul de ameliorare a schemei conceptuale trebuie: s garanteze conservarea datelor, adic n schema conceptual final trebuie s figureze toate datele din cadrul schemei iniiale; s garanteze conservarea dependenelor dintre date, adic n schema final fiecare dependen trebuie s aib determinantul i determinatul n schema aceleiai relaii;

41

s reprezinte o descompunere minimal a relaiilor iniiale, adic nici una din relaiile care compun schema final nu trebuie s fie coninut ntr-o alt relaie din aceast schem.

Exist dou metode pentru a modela baze de date relaionale fr anomalii sau pierderi de informaie. Schema descompunerii pleac de la o schem relaional universal ce conine toate atributele BD. Schema se descompune prin proiecii succesive n subrelaii. Descompunerea se oprete cnd continuarea ei ar duce la pierderi de informaie. Algoritmii de descompunere se bazeaz, n general, pe descrierea formal a dependenei dintre atribute. Schema sintezei pleac de la o mulime de atribute independente. Utiliznd proprieti de semantic i legturi ntre atribute se pot compune noi relaii, astfel nct, acestea s nu sufere de anumite anomalii. Algoritmii se bazeaz, n general, pe teoria grafurilor pentru a reprezenta legtura ntre atribute.

Dependene funcionale
O relaie universal este o relaie ce grupeaz toate atributele care modeleaz sistemul real cercetat. Fie E, mulimea dependenelor considerate de proiectantul bazei pentru o schem relaional sau pentru o relaie universal. Plecnd de la o mulime de proprieti formale ale dependenelor, proprieti considerate drept reguli de deducie (axiome), poate fi obinut mulimea maximal de dependene asociate lui E. Aceast mulime definete nchiderea lui E. Fie E mulimea dependenelor unei relaii i p1, p2, ..., pr, r 1, proprieti formale ale acestor dependene. Dac exist o mulime E, astfel nct orice dependen a mulimii E este derivabil din E prin aplicarea proprietilor p1, p2, ..., pr, atunci mulimea E definete acoperirea lui E pentru proprietile p1, p2, ..., pr. E este o acoperire minimal pentru E, dac nu exist nici o submulime proprie, nevid a lui E care s fie o acoperire pentru E. Evident, E i E au nchideri identice, deci dispun de acelai potenial informaional! Fie R(A1, A2, ..., An) o schem relaional i fie X, Y submulimi de atribute ale lui R. X determin funcional Y sau Y depinde funcional (FD) de X, dac pentru orice relaie r (valoare curent a lui R) nu exist dou tupluri care s aib aceleai valori pentru atributele lui X i s aib valori

42

diferite pentru cel puin un atribut din Y. Cu alte cuvinte, o valoare a lui X, determin unic o valoare a lui Y. Notaia utilizat pentru desemnarea dependenei funcionale este X Y. X este numit determinant, iar Y este numit determinat (sau dependent). Dependena funcional X Y este trivial dac Y X. Comparnd toate submulimile de atribute ale unei relaii i determinnd legturile dintre ele, se pot obine toate dependenele funcionale pe care o relaie le satisface. Aceast abordare nu este eficient, consumnd mult timp. Exist posibilitatea ca, tiind anumite dependene funcionale i utiliznd reguli de deducie, s fie obinute toate dependenele funcionale. Fie X, Y, Z, W mulimi de atribute ale unei scheme relaionale R i fie urmtoarele axiome: Ax1 reflexivitate. X X. Mai general, dac Y X, atunci X Y. Ax2 creterea determinantului. Pot fi considerate urmtoarele formulri echivalente pentru aceast axiom.
1. 2. 3. 4.

Dac X Y i X Z, atunci Z Y. Dac X Y i W Z, atunci X Z Y W. Dac X Y atunci X Z Y Z. Dac X Y atunci X Z Y.

Ax3 tranzitivitate. Dac X Y i Y Z, atunci X Z. O mulime de axiome este complet dac i numai dac plecnd de la o mulime de dependene E se pot obine toate dependenele nchiderii lui E, utiliznd axiomele mulimii. O mulime de axiome este nchis dac i numai dac plecnd de la o mulime de dependene E, nu poate fi dedus cu ajutorul axiomelor o dependen care nu aparine nchiderii lui E. (nu obin altele!) Ullman a demonstrat c axiomele Ax1 Ax3, numite axiomele lui Amstrong, reprezint o mulime nchis i complet de axiome. Consecina acestui rezultat este c nchiderea lui E reprezint mulimea dependenelor deduse din E, prin aplicarea axiomelor lui Amstrong!!! Nu toate dependenele funcionale sunt folositoare pentru modelarea relaional. O dependen funcional X Y se numete dependen funcional total (FT), dac i numai dac nu exist nici o submulime proprie X X, astfel nct X Y. Dac exist o submulime proprie X

43

X, astfel nct X Y, atunci dependena funcional X Y este parial. n axioma Ax2, dependena Z Y este o dependen funcional parial. n cazul dependenei funcionale totale, axiomele lui Amstrong se reduc la o axiom unic i anume pseudo-tranzitivitatea: dac X Y i W Y Z, atunci W X Z. Aceast axiom este o regul de deducie complet pentru total dependene: pseudo-tranzitivitatea implic tranzitivitatea (W = ); reflexivitatea nu poate fi utilizat pentru a obine dependene totale; reflexivitatea i pseudo-tranzitivitatea implic creterea.

Dac F este o mulime de dependene funcionale totale, atunci nchiderea pseudo-tranzitiv F+ a acestei mulimi este reuniunea mulimilor dependenelor funcionale totale care pot fi obinute din F folosind axioma de pseudo-tranzitivitate. Dou mulimi de dependene funcionale totale sunt echivalente dac au nchideri pseudo-tranzitive identice. Pentru a modela scheme relaionale se consider mulimi minimale de dependene funcionale totale, capabile s genereze toate nchiderile pseudo-tranzitive. Aceste mulimi definesc acoperiri minimale. O mulime de dependene funcionale totale F* asociat unei mulimi de atribute A definete o acoperire minimal dac satisface urmtoarele proprieti: nici o dependen funcional din F* nu este redundant; toate dependenele funcionale totale ntre submulimi ale lui A sunt n nchiderea pseudo-tranzitiv a lui F*. Orice mulime de dependene totale are cel puin o acoperire minimal. Alegerea acoperirii minimale este punctul de start n modelarea schemelor relaionale. Dependenele funcionale ntre atributele bazei pot fi reprezentate grafic. Fie A = {A1, A2, ..., An} o mulime de atribute i fie o mulime de dependene funcionale {Xi Aj}, unde Xi este o submulime a lui A. Graful dependenelor funcionale este un graf direcionat bipartit, definit astfel: 1. pentru fiecare atribut Aj exist un singur nod avnd eticheta Aj;

44

2. 3.

pentru fiecare dependen funcional de forma Ai Aj, exist un arc de la Ai la Aj; pentru fiecare dependen funcional de forma Xi Aj, unde mulimea Xi este definit de Xi = {Ai1, ..., Aip} cu p > 1, exist un nod auxiliar etichetat prin Xi i o mulime de arce plecnd de la Ai1, ..., Aip pentru a obine pe Xi i printr-un arc adiional de la Xi la Aj. Nodurile Xi se reprezint prin dreptunghiuri.

Exemplu: 1. Graful dependenelor funcionale pentru schema relaional CONSUMATOR_DE_VIN(W#, localitate, varsta, calitate, regiune, tara, D#, nume, data, cantitate) i acoperirea minimal.
localitate W# calitate varsta regiune tara data D# nume localitate W# calitate varsta regiune tara data D# cantitate cantitate

45

nume

2. Graful dependenelor funcionale pentru schema relaional OBIECTIV_INVESTITIE. Dependentele sunt deduse din regulile impuse de beneficiar!
aria_construita denumire nr_certificat_urbanizare cod_obiectiv# adresa nr_contract nr_aut_construtie cod_contractant

Necesitatea normalizrii
Anomaliile care apar n lucrul cu baza de date se produc datorit dependenelor care exist ntre datele din cadrul relaiilor bazei de date. Dependenele sunt plasate greit n tabele!!! Avion A# 1 2 3 4 5 6 nume AIRBUS AIRBUS AIRBUS CAR B707 B707 capacitate 250 250 250 100 150 150 localitate PARIS PARIS LONDRA PARIS LONDRA LONDRA

Constrngere: toate avioanele cu acelai nume au aceeai capacitate. Datorit dependenei introduse pot exista: anomalii la inserare, modificare sau tergere, redundan n date, probleme de reconexiune.
1. 2.

Redundan logic. Cuplul (AIRBUS, 250) apare de trei ori. Anomalie la inserie. S-a cumprat un B727 cu 150 locuri. El poate fi inserat n relaia AVION doar dac se definete o nou valoare pentru cheia primar.

46

3.

Anomalie la tergere. Dac este tears nregistrarea pentru care A# este 4, atunci se pierde informaia c un avion CAR are capacitatea 100. Anomalie la modificare. Dac se modific capacitatea lui B707 de la 150 la 170, atunci costul modificrii este mare pentru a modifica toate nregistrrile, iar dac se modific doar o nregistrare atunci constrngerea nu va mai fi verificat. Problema reconexiunii. Considerm schemele relaionale: AVION1 = PROJECT(AVION, A#, nume) AVION22 = PROJECT(AVION, nume, capacitate, localitate) AVION3 = JOIN(AVION1, AVION2). Se observ c schema AVION3 este diferit de AVION. Apare un tuplu nou: (3, AIRBUS, 250, PARIS).

4.

5.

Anomaliile au aprut datorit dependenei funcionale (constrngerii) introduse anterior!!! Normalizarea are drept scop: suprimarea redundanei logice, evitarea anomaliilor la reactualizare, rezolvarea problemei reconexiunii.

Exist o teorie matematic a normalizrii al crei autor este E.F. Codd. Soluia: construirea unor tabele standard (forme normale). Normalizarea este procesul reversibil de transformare a unei relaii, n relaii de structur mai simpl. Procesul este reversibil n sensul c nici o informaie nu este pierdut n timpul transformrii. O relaie este ntr-o form normal particular dac ea satisface o mulime specificat de constrngeri. Procesul normalizrii se realizeaz plecnd de la o relaie universal ce conine toate atributele sistemului de modelat, plus o mulime de anomalii. Orice form normal se obine aplicnd o schem de descompunere. Exist dou tipuri de descompuneri. Descompuneri ce conserv dependenele. Aceast descompunere presupune desfacerea relaiei R n proieciile R1, R2, ..., Rk, astfel nct dependenele lui R sunt echivalente (au nchideri pseudo-tranzitive identice) cu reuniunea dependenelor lui R1, R2, ..., Rk. Descompuneri fr pierderi de informaie (L-join). Aceast descompunere presupune desfacerea relaiei R ntr-o mulime de

47

proiecii R1, R2, ..., Rj, astfel nct pentru orice realizare a lui R este adevrat relaia: R = JOIN(B1 (R), B2 (R), ...,Bj (R)) unde, pentru 1 k j, Bk reprezint mulimea atributelor corespunztoare proieciei Rk (Rk = Bk (R)). Prin urmare, relaia iniial poate fi reconstruit considernd compunerea natural a relaiilor obinute prin descompunere. Formele normale sunt obinute prin descompuneri fr pierderi de informaie. O descompunere fr pierdere de informaie, utilizat n procesul normalizrii, este dat de regula Casey-Delobel: Fie R(A) o schem relaional i fie , , o partiie a lui A. Presupunem c determin funcional pe . Atunci: R(A) = JOIN((R), (R)). mulimea atributelor care intervin n dependenele funcionale; reprezint reuniunea determinantului cu restul atributelor lui A.
Relatia universala FN1 FN2 FN3 BCNF FN4 FN5

Pentru exemplul analizat anterior: = {nume}, = {capacitate}, = {A#, localitate}. Aplicnd Casey-Delobel se obin schemele: AVION1(nume#, capacitate) AVION2)A#, nume, localitate). Se observ c anomaliile comentate au disprut! AVION1 Nume Capacitate

48

AIRBUS CAR B707

150 100 150 Localitate PARIS PARIS LONDRA PARIS LONDRA LONDRA

AVION2 A# Nume 1 AIRBUS 2 AIRBUS 3 AIRBUS 4 CAR 5 B707 6 B707

Forma normal (FN1)

O relaie este n prima form normal dac fiecrui atribut care o compune i corespunde o valoare indivizibil (atomic). Exemplu: variante pentru a implementa FN1 pentru tabelul MASINA:
Persoana Eu Tu El noi Varianta 1 Persoana Eu Eu Eu Tu El El Noi Noi Noi Noi Varianta 2 Persoana Eu Prima R25 Doi W14 Trei R21 Patru Vehicul R25 W14 R21 205 R5 305 BX 305 R12 R25 Vehicul R25 - W14 - R21 205 R5 - 305 BX - 305 - R12 - R25

49

Tu El Noi

205 R5 BX 305 305 R12 R25

Varianta 3 (4 tabele) Masina 31 (similar se definesc Masina_32, Masina_33, Masina_34).. Persoana Eu Tu El Noi Masina_34 Persoana Noi Vehicul R25 Vehicul R25 205 R5 BX

Forma normal 2 (FN2)

O relaie R este n a doua form normal dac i numai dac: relaia R este n FN1; fiecare atribut care nu este cheie (nu particip la cheia primar) este dependent de ntreaga cheie primar.
Job_cod Programator Programator Programator Vanzator Inginer Nr_proiect# P1 P2 P3 P3 P3 Functia Supervizor Cercetator Auxiliar Supervizor Supervizor Suma 60 25 10 60 60

atasat_la Cod_salariat# S1 S1 S1 S3 S5 atasat_2a Cod_salariat# S1 S1 S1 S3 S5 atasat_2b Cod_salariat# Job_cod Nr_proiect# P1 P2 P3 P3 P3 Functia Supervizor Cercetator Auxiliar Supervizor Supervizor Suma 60 25 10 60 60

50

S1 S3 S5

Programator Vanzator Inginer

A doua condiie exprim necesitatea total dependenei de cheia primar. Aceast form normal interzice manifestarea unor dependene funcionale pariale n cadrul relaiei R!!! Pentru a obine o relaie FN2 se poate aplica regula Casey-Delobel. Fie relaia R(K1, K2, X, Y), unde K1 i K2 definesc cheia primar, iar X i Y sunt mulimi de atribute, astfel nct K1 X. Din cauza dependenei funcionale K1 X care arat c R nu este n FN2, se nlocuiete R (fr pierdere de informaie) prin dou proiecii R1(K1, K2, Y) i R2(K1, X).
K1 K2

Exemplu. Presupunem c un antier poate executa mai multe lucrri de baz i c o lucrare poate fi executat de mai multe antiere. LUCRARE(cod_obiectiv#, cod_lucrare#, nume); SANTIER(nr_santier#, specialitate, sef); EXECUTA(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie, conducator, data_inceput, data_sfarsit). Pentru relaia EXECUTA sunt evidente dependenele: {cod_obiectiv#, cod_lucrare#} {data_inceput, data_sfarsit}, {cod_obiectiv#, cod_lucrare#, nr_santier#} {descriere, functie, conducator}. Relaia EXECUTA este n FN1, dar nu este n FN2 deoarece atributele data_inceput i data_sfarsit nu depind de numrul antierului, deci nu depind de ntreaga cheie primar. Pentru a obine o relaie n FN2 se aplic regula Casey Delobel i relaia EXECUTA se desface n:

51

EXECUTA_1(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie, conducator) EXECUTA_2(cod_obiectiv#, cod_lucrare#, data_inceput, data_sfarsit).

Forma normal 3 (FN3)

Intuitiv, o relaie R este n a treia form normal dac i numai dac: relaia R este n FN2; fiecare atribut care nu este cheie (nu particip la o cheie) depinde direct de cheia primar.

Fie R o relaie, X o submulime de atribute ale lui R i A un atribut al relaiei R. A este dependent tranzitiv de X dac exist Y astfel nct X Y i Y A (A nu aparine lui Y i Y nu determin pe X). X nu este dependent funcional de Y sau A! De exemplu, dac K1, K2, K3 A1 i dac K1, K2, A1 A2, atunci K1, K2, K3 K1, K2, A1 i K1, K2, A1 A2. Prin urmare, A2 este dependent tranzitiv de K1, K2, K3. Formal, o relaie R este n a treia form normal dac i numai dac: relaia R este n FN2; fiecare atribut care nu este cheie (nu particip la o cheie) nu este dependent tranzitiv de nici o cheie a lui R.

O relaie este n FN3 dac i numai dac fiecare atribut (coloan) care nu este cheie, depinde de cheie, de ntreaga cheie i numai de cheie. Pentru a obine o relaie FN3 se poate aplica regula Casey-Delobel. Fie relaia R(K, X1, X2, X3), unde atributul X2 depinde tranzitiv de K, iar K este cheia primar a lui R. Presupunem c K X1 X2. Din cauza dependenei funcionale X1 X2 care arat c R nu este n FN3, se nlocuiete R (fr pierdere de informaie) prin dou proiecii R1(K, X1, X3) i R2(X1, X2). K X1 X3 Exemplu: Tabelul atasat_2a nu este in FN3. De ce?
atasat_3a Cod_salariat# Nr_proiect# Functia

X2

52

S1 S1 S1 S3 S5 atasat_3b Functia Supervizor Cercetator Auxiliar

P1 P2 P3 P3 P3 Suma 60 25 10

Supervizor Cercetator Auxiliar Supervizor Supervizor

Exemplu. n tabelul EXECUTA1(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie, conducator) continu s existe redundan n date. Atributul conducator depinde indirect de cheia primar prin intermediul atributului functie. ntre atributele relaiei exist dependenele: {cod_obiectiv#, cod_lucrare#, nr_santier#} {descriere}, {cod_obiectiv#, cod_lucrare#, nr_santier#} {functie} {conducator}. Pentru a aduce relaia EXECUTA_1 n FN3 se aplic regula CaseyDelobel. Relaia se desface, prin eliminarea dependenelor funcionale tranzitive, n proieciile: EXECUTA11(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie) EXECUTA12(functie, conducator).

Schema de sintez pentru obinerea lui FN3

Algoritmul de sintez construiete o acoperire minimal F a dependenelor funcionale totale. Se elimin atributele i dependenele funcionale redundante. Mulimea F este partiionat n grupuri Fi, astfel nct n fiecare grup Fi sunt dependene funcionale care au acelai membru stng i nu exist dou grupuri avnd acelai membru stng. Fiecare grup Fi produce o schem FN3. Algoritmul realizeaz o descompunere ce conserv dependenele. Algoritm SNF3 (aducerea unei relaii n FN3 prin utilizarea unei scheme de sintez): 1. Se determin F o acoperire minimal a lui E (mulimea dependenelor funcionale). 2. Se descompune mulimea F n grupuri notate Fi, astfel nct n cadrul fiecrui grup s existe dependene funcionale avnd aceeai parte stng.

53

3.

4.

5.

6.

Se determin perechile de chei echivalente (X, Y) n raport cu F (dou mulimi de atribute X, Y sunt chei echivalente dac n mulimea de dependene E exist att dependena X Y, ct i dependenta Y X). Pentru fiecare pereche de chei echivalente: se identific grupurile Fi i Fj care conin dependenele funcionale cu partea stng X i respectiv Y; se formeaz un nou grup de dependene Fi j, care va conine dependenele funcionale avnd membrul stng (X, Y); se elimin grupurile Fi i Fj, iar locul lor va fi luat de grupul Fi j. Se determin o acoperire minimal a lui F, care va include toate dependenele X Y, unde X i Y sunt chei echivalente (celelalte dependene sunt redundante). Se construiesc relaii FN3 (cte o relaie pentru fiecare grup de dependene funcionale).

Se observ c algoritmul solicit determinarea unei acoperiri minimale (algoritmii EAR i EDF); determinarea nchiderii (A + ) unei mulimi de atribute A n raport cu mulimea de dependene funcionale E (algoritm AIDF). Determinarea acoperirii minimale presupune eliminarea atributelor i dependenelor redundante. Acoperirea minimal nu este unic i depinde de ordinea n care sunt eliminate aceste atribute i dependene redundante. Algoritm EAR (elimin atributele redundante din determinantul dependenelor funcionale) Pentru fiecare dependen funcional din E i pentru fiecare atribut din partea stng a unei dependene funcionale: Pas1. Se elimin atributul considerat. Pas2. Se calculeaz nchiderea prii stngi reduse. Pas3. Dac nchiderea conine toate atributele din determinantul dependenei, atunci atributul eliminat la pasul 1 este redundant i rmne eliminat. n caz contrar, atributul nu este redundant i se reintroduce n partea stng a dependenei funcionale. Algoritm EDF (elimin dependenele funcionale redundante din E) Pentru fiecare dependen funcional X Y din E: Pas1. Se elimin dependena din E.

54

Pas2. Se calculeaz nchiderea X + , n raport cu mulimea redus de dependene. Pas3. Dac Y este inclus n X + , atunci dependena X Y este redundant i rmne eliminat. n caz contrar, se reintroduce n E. Algoritm AIDF (determin nchiderea lui A) Pas1. Se caut dac exist n E dependene X Y pentru care determinantul X este o submulime a lui A, iar determinatul Y nu este inclus n A. Pas2. Pentru fiecare astfel de dependen funcional se adaug mulimii A atributele care constituie determinatul dependenei. Pas3. Dac nu mai exist dependene funcionale de tipul de la pasul 1, atunci A + = A. Exemplu: Fie dependenele funcionale: f1: F N; F4: P C; f2: F P; f5: P T; f3: P, F, N U; f6: C T; f7: N F.

Pas1 (suprimarea atributelor redundante). Atributul A i este redundant n dependena funcional A 1 , A 2 , A i , A n Z, dac dependena funcional A 1 , A 2 , A i 1 , A i +1 A n Z poate fi generat plecnd de la mulimea iniial de dependene (E) i de la axiomele considerate. f1: F N; f3: P, F, N U sau N, P, F U; Aplicnd axioma de pseudotranzitivitate se obine: F, P, F U P, F U Pas2 (suprimarea dependenelor funcionale redundante). Dependena funcional f este redundant n E dac E + = (E - f) + , unde E + reprezint nchiderea lui E. Se observ c f5 este redundant (poate fi obinut din f4 i f6). La sfritul etapei se obine: f1: F N; f4: P C; f2: F P; f6: C T; f3: P, F U; P este redundant =>F-->U f7: N F.

Pas3 (gruparea dependenelor avnd acelai membru stng).

55

F1 = {f1, f2, f3}; F2 = {f4}; F3 = {f6}; F4 = {f7} Pas4 (regruparea mulimilor F i si F j dac exist dependene de forma X Y i Y X, unde X reprezinta partea stanga a dependenei lui F i i Y este partea stng a dependenei lui F j . Din F1 i F4 se obine: G1 = {f1, f2, f3, f7}; G2 = {f4}; G3 = {f6}. Pas5 (generarea relaiilor FN3). R1(F#, N, P, U); R2(P#, C); R3(C#, T). De remarcat: R1 nu este in BCNF! De ce? Exista dependenta N -->F. Exerciiu: Presupunem c o parte din activitiile de pe un aeroport sunt caracterizate de atributele: A -- numr zbor; B -- tip avion; C -- aeroport plecare; D -- aeroport sosire; E -- linia aerian; F -- ora plecrii; G -- capacitate; H -- numr locuri rezervate; I -- data; J -- tarif; K -- prestaii la bord. ntre aceste atribute exist legturi exprimate prin dependenele: A BEFG ACDI H CD J CDF K BG CF ABE AC D ABD C EG B Aplicnd algoritmul de sintez se obin relaiile: R1(B#, G) R2(E#, G#, B)

56

R3(A#, B, E, F) R4(C#, D#, J) R5(A#, C#, I#, H) R6(A, C, D, F, K) n care cheile primare pot s fie oricare dintre: AD sau AC sau CF. ncercai s justificai acest rezultat!!!

Forma normal Boyce-Codd (BCNF)

Determinantul este un atribut sau o mulime de atribute neredundante, care constituie un identificator unic pentru alt atribut sau alt mulime de atribute ale unei relaii date. Intuitiv, o relaie R este n forma normal Boyce-Codd dac i numai dac fiecare determinant este o cheie candidat. Formal, o relaie R este n forma normal Boyce-Codd dac i numai dac pentru orice dependen funcional total X A, X este o cheie (candidat) a lui R. Regula Casey Delobel pentru R(K1#, K2#, X) presupunnd c exist dependena: X K2. R1(K1#, X) i R2(X#, K2)
K1 K2

Exemplu: ADRESA(cod_parsoana#, telefon#, adresa)

cod_persoana adresa telefon

57

n dependena adresa telefon se observ c determinantul nu este o cheie candidat. Relaia ADRESA se desface n: ADRESA_1(cod_persoana#, adresa); ADRESA_2(adresa#, telefon). Relaiile sunt n BCNF, se conserv datele, dar nu se conserv dependenele (s-a pierdut cod_persoana, telefon adresa). Exemplu: Relaia INVESTESTE_IN leag entitile INVESTITOR i OBIECTIV_INVESTITIE. Ea are schema relaional: INVESTESTE_IN(cod_contractant#, cod_obiectiv#, nr_contract, cota_parte). ntre atributele relaiei exist dependenele: {cod_contractant#, cod_obiectiv#} {nr_contract, cota_parte}, {nr_contract} {cod_obiectiv}. Se aplic regula Casey-Delobel i se aduce relaia n BCNF. INVESTESTE_IN_1(cod_obiectiv, nr_contract#); INVESTESTE_IN_2(cod_contractant#, nr_contract, cota_parte). Pentru ca o relaie s fie adus n BCNF nu trebuie n mod obligatoriu s fie n FN3. Se pot aduce n BCNF i relaii aflate n FN1 sau FN2. Acest lucru este posibil ntruct dependenele funcionale pariale i cele tranzitive sunt tot dependene noncheie, adic dependene ai cror determinani nu sunt chei candidat. Presupunem c R este o relaie ce conine atributele A. Algoritm TFBCNF (aducerea unei relaii R din FN1 n BCNF) 1. Dac relaia conine cel mult dou atribute, atunci R este n BCNF i algoritmul s-a terminat. 2. Dac relaia conine mai mult de dou atribute, se consider toate perechile (X, Y) de atribute distincte din A. + 3. Se determin A1 , nchiderea mulimii A1 = A {X, Y}.
4. 5. 6.

Dac pentru orice pereche (X, Y), X A1+ atunci relaia R este n BCNF i algoritmul s-a terminat. n caz contrar (pentru cel puin o pereche ( X, Y), X aparine lui A1+), relaia R nu este n BCNF. Se reduce progresiv schema relaiei i se reia algoritmul, exploatnd relaia redus. Orice relaie obinut prin reducerea lui

58

R i care este n BCNF se consider ca fcnd parte din descompunerea lui R n procesul aducerii sale n BCNF.

Forma normal 4 (FN4)

FN4 elimin redundanele datorate relaiilor m:n, adic datorate dependenei multiple. Intuitiv, o relaie R este n a patra form normal dac i numai dac relaia este n BCNF i nu conine relaii m:n independente. Fie R o relaie definit pe o mulime de atribute A = {A1, A2, ..., An} i fie X, Y, Z A. Se spune c X multidetermin pe Z sau c Z este multidependent de X : dac pentru fiecare valoare a lui Z n R exist numai o valoare pentru perechea (X, Y); dac valoarea lui Z depinde numai de valoarea lui X. Acest tip de dependen, numit i multivaloare sau multidependen (MVD) se noteaz prin X Z. Intuitiv, multidependena reprezint situaia n care valoarea unui atribut (sau a unei mulimi de atribute) determin o mulime de valori a altui atribut (sau mulimi de atribute)!!! Multidependena X Y poate fi gndit ca o regul de deducie: dac tuplurile <x, y, z> i <x, y, z> sunt n relaie la un moment r, atunci la momentul r sunt n relaie i tuplurile <x, y, z> i <x, y, z>.
x y z

x x x

y' y y'

z' z' z

Orice dependen funcional este o multidependen. Afirmaia invers nu este adevrat. Dac X Y (FD), atunci pentru oricare dou tupluri <x, y, z> i <x, y, z>, se obine y = y. Prin urmare n relaie apar tuplurile <x, y, z> i <x, y, z> i deci X Y (MVD).

59

Fie W, V, X, Y i Z submulimi de atribute ale unei scheme relaionale R. Fiind dat o mulime T de multidependene exist o mulime complet de axiome (Ax1Ax8) care permit obinerea tuturor multidependenelor ce se pot deduce din mulimea T: Ax1. Dac Y X, atunci X Y. Ax2. Dac X Y, atunci X Z Y Z. Ax3. Dac X Y i Y Z, atunci X Z. Ax4. Dac X Y, atunci X R {X Y}. Ax5. Dac X Y i V W, atunci W X V Y. Ax6. Dac X Y i Y Z, atunci X (Z Y). Ax7. Dac X Y, atunci X Y. Ax8. Dac X Y, Z W, W Y i Y Z = , atunci X W. O multidependen elementar este o multidependen care are pri stngi i drepte minimale (nu exist X X i Y Y a.i. X Y). Formal, relaia R este n a patra form normal dac i numai dac: R este n BCNF; orice dependen multivaloare este o dependen funcional. O relaie BCNF este n FN4 dac pentru orice multidependen elementar de forma X Y, X este o supercheie a lui R. Aducerea relaiilor n FN4 presupune eliminarea dependenelor multivaloare atunci cnd sunt mai mult de una n cadrul unei relaii. Regula de descompunere n relaii FN4 . Fie R(X, Y, Z) o schem relaional care nu este n FN4 i fie X Y o multidependen elementar care nu este de forma CHEIE atribut. Aceast relaie este descompus prin proiecie n dou relaii: R = JOIN(XY(R), XZ(R)). Aplicnd recursiv aceast regul, se obin relaii FN4. Exemplu. Fie relaia INVESTITIE(cod_contractant#, denumire, telefon) i presupunem c un investitor poate avea mai multe numere de telefon i c poate investi n mai multe obiective. ntre atributele relaiei exist multidependenele: cod_contractant# denumire; cod_contractant# telefon.

60

Relaia INVESTITIE este n BCNF. Pentru a aduce relaia n FN4 o vom descompune prin proiecie n dou relaii: INVESTITIE_1(cod_contractant#, denumire), INVESTITIE_2(cod_contractant#, telefon). INVESTITIE = JOIN(INVESTITIE_1, INVESTITIE_2).

Forma normal 5 (FN5)

FN5 i propune eliminarea redundanelor care apar n relaii m:n dependente. n general, aceste relaii nu pot fi descompuse. S-a artat c o relaie de tip 3 este diferit de trei relaii de tip 2. Exist totui o excepie, i anume, dac relaia este ciclic Intuitiv, o relaie R este n forma normal 5 dac i numai dac: 1. relaia este n FN4; 2. nu conine dependene ciclice. Dependena funcional i multidependena permit descompunerea prin proiecie, fr pierdere de informaie, a unei relaii n dou relaii. Regulile de descompunere (FN1 FN4) nu dau toate descompunerile posibile prin proiecie ale unei relaii. Exist relaii care nu pot fi descompuse n dou relaii dar pot fi descompuse n trei, patru sau mai multe relaii fr a pierde informaii. Pentru a obine descompuneri L- join n trei sau mai multe relaii, s-a introdus conceptul de join-dependen sau dependen la compunere (JD). Fie {R1, R2, ..., Rp} o mulime de scheme relaionale care nu sunt disjuncte i a cror reuniune este R. R satisface join-dependena *{R1, R2, ..., Rp} dac la fiecare moment al lui R are loc egalitatea: R = JOIN(1(R), 2(R), ..., p(R)) unde k reprezint mulimea atributelor corespunztoare lui Rk(1 k p). Join-dependena *{R1, R2, ..., Rp} are loc n R, dac R1, R2, ..., Rp este o descompunere L-join a lui R. Pentru p = 2 se regsete multidependena. O join- dependen *{R1, R2, ..., Rp} n care una dintre Ri este chiar R, definete o join- dependen trivial. Join-dependena generalizeaz multidependena. ntr-adevr, multidependena X Y n relaia R(X, Y, Z) (deci i X Z), corespunde join-dependenei *{X Y, X Z}. Invers, join-dependena *{R1, R2} corespunde multidependenei R1 R2 R1 (R1 R2).

61

Formal, o relaie R este n FN5 dac i numai dac orice joindependen *{R1, R2, ..., Rp} care are loc n R fie este trivial, fie conine o supercheie a lui R (adic, o anumit component Ri este o supercheie a lui R). Cu alte cuvinte, o relaie R este n FN5 dac orice join-dependen definit pe R este implicat de cheile candidat ale lui R. ntre mulimile de atribute X, Y i Z din cadrul relaiei R exist o join-dependen dac exist multidependene ntre fiecare dintre perechile de mulimi (X, Y), (Y, Z) i (X, Z). Aducerea n FN5 prin eliminarea join dependenelor! Exemplu. Fie schema R(furnizor, cod_consumabil, cantitate, pret). Reguli: un furnizor produce mai multe consumabile; nu toi furnizorii produc aceleai consumabile; preul unui consumabil de la un furnizor este variabil i nu depinde de cantitate.
Cod_consumabil 1 1 1 2 Cantitate 500 100 500 500 Pret 100 80 100 100

Furnizor F1 F2 F2 F2

Relaia este n FN4, dar exist redundan n date. Relaia se descompune prin proiecie n: R1(furnizor#, cod_consumabil#) R2(furnizor#, cantitate, pret) R3(cod_consumabil#, cantitate, pret). S-au eliminat redundanele: (F2,1) pentru R1; (F2, 500, 100) pentru R2; (1, 500, 100) pentru R3. Se observ c: JOIN(R1, R2) R; JOIN(R1, R3) R; JOIN(R3, R2) R; JOIN(R1, R2, R3) = JOIN(R1, JOIN(R2, R3)) = R

62

Exist join dependena: *{R1(furnizor, cod_consumabil), R3(cod_consumabil, cantitate, pret)} R2(furnizor, cantitate, pret),

Exemplu. Fie schema relaional: EXECUTANT(nr_santier#, cod_obiectiv#, cod_lucrare#, data_inceput, data_sfarsit). Un antier poate executa mai multe lucrri referitoare la acelai obiectiv sau poate executa o lucrare pentru un obiectiv n intervale de timp distincte. Se presupune c mai multe antiere pot executa aceeai lucrare, n acelai interval de timp sau n intervale de timp distincte. Relaia, datorit dependenelor formulate anterior, nu este n FN5. Ea se poate desface prin proiecie n trei relaii: EX1(nr_santier#, cod_obiectiv#, cod_lucrare#); EX2(nr_santier#, data_inceput, data_sfarsit); EX3(cod_obiectiv#, cod_lucrare#, data_inceput, data_sfarsit). Sunt evidente relaiile: EXECUTANT JOIN(EX1, EX2), EXECUTANT JOIN(EX1, EX3), EXECUTANT JOIN(EX2, EX3), EXECUTANT = JOIN(JOIN(EX1, EX2), EX3).

Concluzii:
1.

FN1 FN2 elimin redundanele datorate dependenei netotale a atributelor care nu particip la o cheie, fa de cheile lui R. Se suprim dependenele funcionale care nu sunt totale. FN2 FN3 elimin redundanele datorate dependenei tranzitive. Se suprim dependenele funcionale tranzitive. FN3 BCNF elimin redundanele datorate dependenei funcionale. Se suprim dependenele n care partea stng nu este o supercheie. BCNF FN4 elimin redundanele datorate multidependenei. Se suprim toate multidependenele care nu sunt i dependene funcionale.

2.

3.

4.

63

5.

FN4 FN5 elimin redundanele datorate dependentei. ciclice. Se suprim toate join-dependenele care nu sunt implicate de o cheie. BCNF, FN4 i FN5 corespund la regula c orice determinant este o cheie, dar de fiecare dat dependena cu care se definete determinantul este alta i anume dependena funcional, multidependena sau join-dependena). Descompunerea unei relaii FN2 n FN3 conserv datele i dependenele, pe cnd descompunerea unei relaii FN3 n BCNF i, respectiv, a unei relaii BCNF n FN4 conserv doar datele.

6.

7.

Cateva observaii i concluzii PROIECTAREA BAZELOR DE DATE

referitoare

la

Proiectarea conceptual a bazei de date -- construirea

reprezentrii conceptuale a bazei de date, care include identificarea tipurilor importante de entiti, relaii, atribute. 1) identificarea tipurilor de entiti (E); 2) identificarea tipurilor de relaii (R); 3) identificarea i asocierea atributelor (A) cu tipurile de E sau R; 4) determinarea domeniilor atributelor; 5) determinarea atributelor chei candidat i chei primare; 6) specializarea i generalizarea tipurilor de entiti; 7) desenarea diagramei E/R; 8) revizuirea modelului de date conceptual local, mpreun cu utilizatorul, pentru a garanta c modelul este o reprezentare corect a punctului de vedere al utilizatorului asupra sistemului real analizat.

Proiectarea logic a bazei de date -- transpunerea reprezentrii

conceptuale n structura logic a BD, care include proiectarea relaiilor. 1) transpunerea modelului conceptual local n modelul de date logic local:

64

eliminarea relaiilor M:N (nlocuirea prin relaii de tip 1:M sau prin tabele asociative); eliminarea relaiilor complexe (nlocuirea prin relaii de tip 1:M); eliminarea relaiilor recursive (nlocuirea prin relaii dependente); eliminarea atributelor multiple (nlocuirea prin relaii dependente; reexaminarea relaiilor 1:1 (sunt ntr-adevr 2 relaii distincte?); eliminarea relaiilor redundante.

2) extragerea relaiilor din modelul de date logic local pentru a reprezenta entitile i relaiile (legturile); 3) normalizarea relaiilor; 4) validarea modelului conform tranzaciilor utilizatorului pentru a garanta c acesta accept i rezolv operaiile cerute de ctre model (se verific faptul c modelul furnizeaz toate informaiile cerute de fiecare tranzacie i se reprezint schematic calea urmat de fiecare tranzacie, direct n diagrama E/R); 5) desenarea diagramei conceptuale; 6) definirea constrngerilor de integritate; 7) revizuirea modelului de date conceptual local, mpreun cu utilizatorii; 8) construirea i validarea modelului de date logic global prin combinarea modelelor locale: mbinarea modelelor locale (revizuirea E, R, A, CP, CE, constrngeri, revizuirea denumirilor, cutarea entitilor i relaiilor care lipsesc, reactualizarea documentaiei); normalizarea modelului; validarea modelului conform tranzaciilor utilizatorului; verificarea n vederea dezvoltrii ulterioare; desenarea diagramei conceptuale finale; revizuirea modelului de date conceptual global, mpreun cu utilizatorii. Modaliti pentru asigurarea integritii refeniale!!! Se specific constrngeri de existen care definesc condiiile n care o cheie candidat sau o cheie extern poate fi inserat, tears sau reactualizat. Exemplu: DOMENIU_contine_CARTE (1:M)

65

1) Inserare n relaia "copil" (carte) - se verific dac domeniul crii inserate este null sau corespunde unui domeniu existent. 2) tergerea n relaia "copil" (fr probleme). 3) Reactualizarea n relaia "copil" (similar cazului 1). 4) Inserarea n relaia "printe" (domeniu) se face fr probleme. 5) Reactualizarea cheii primare n relaia "printe" (dac exist o apariie n tabelul "copil" care face referin la vechea valoare a cheii, atunci se pierde integritatea refenial). Se pot aplica strategii pentru a asigura integritatea refenial (vezi 6). 6) tergerea unei apariii din relaia "printe" (se pierde integritatea referenial dac se terge un domeniu de carte, dar exist cel puin o carte din domeniul respectiv). Exist 5 strategii care pot fi luate n considerare. NO ACTION (nici o aciune)- nu se poate terge un domeniu dac exist o carte n domeniul respectiv; CASCADE - se terge domeniul i automat se terg toate crile din domeniu .a.m.d.; SET NULL - se terge domeniul, iar toate criile din domeniul respectiv vor avea codul domeniului setat null; SET DEFAULT - setare la o valoare prestabilit; NO CHECK - cnd este ters un domeniu de carte, nu se face nimic pentru a garanta c integritatea refenial este meninut (nici o verificare). Proiectarea fizic a bazei de date -- implementarea fizic a structurii logice ntr-o capacitate de stocare secundar corespunztoare SGBD-ului int. Se descriu structurile de stocare i metodele de acces utilizate pentru realizarea unui acces eficient la date. 1) Transformarea relaiilor extrase din modelul de date logic global ntr-o form care s poat fi implementat n SGBD-ul relaional int (LDD). 2) Proiectarea (definirea) constrngerilor sistemului real modelat n SGBD-ul int (CONSTRAINT, declanatori). 3) Proiectarea reprezentrii fizice - determinarea organizrii fiierelor i a metodelor de acces (indeci) care vor fi utilizate pentru a stoca relaiile de baz (modul n care relaiile i tuplurile vor fi pstrate n cadrul capacitii de stocare secundare). 4) Introducerea unei redundane controlate (denormalizarea).

66

5) Estimarea necesarului de spaiu pe disc cerut de baza de date. 6) Proiectarea mecanismelor de securitate: proiectarea vizualizrilor (VIEW); proiectarea regulilor de acces la relaiile de baz i la vizualizri (privilegii, role-uri). 7) Monitorizarea nentrerupt i reglarea sistemului operaional pentru obinerea unor performane maxime (micorarea configuraiei hardware, timpi de rspuns mai sczui, transfer eficient etc.). Comentm pasul 4 referitor la considerarea introducerii unei redundane controlate (denormalizare). NU exist reguli fixe!!! Pasul 4 presupune: considerarea datelor derivate (calculate); considerarea dublrii atributelor i gruprii relaiilor. Considerarea datelor derivate De exemplu, n relaia PROPRIETATE_DE INCHIRIAT apare drept cmp, codul persoanei care a tranzacionat nchirierea. Prin urmare, s-ar putea calcula pentru fiecare angajat, cte proprieti a nchiriat SAU se poate introduce n tabelul PERSONAL, un cmp calculat (derivat) ce conine numrul proprietilor nchiriate de acesta. Considerarea dublrii atributelor i gruprii relaiilor Dublarea atributelor sau gruparea relaiilor are ca scop reducerea numrului de join-uri necesare pentru efectuarea unei interogri. FILIALA (nr_fil#, strada, zona, oras, codpostal, tel, fax) Relaia nu este n FN3 deoarece codpostal determin funcional atributele zona i oras. Aplic FN3 i se obine: FIL(nr_fil#, strada, codpostal, tel, fax COD_P(zona, oras, codpostal#) Nu este convenabil, deoarece rareori vom accesa adresa filialei, fr informaii referitoare la zona i ora. Prin urmare, preferm FN2. Vom analiza cteva situaii concrete de denormalizare. combinarea relaiilor de tip 1:1 dublarea atributelor care nu sunt chei n relaii 1:M SELECT p.*, ptr.nume

67

FROM WHERE

proprietate_de_inchiriat p, proprietar ptr p.nrptr=ptr.nrptr AND nrfil='S3';

Atributul nrptr este codul proprietarului. Dac se va dubla atributul nume din relaia proprietate_de_inchiriat, atunci interogarea devine: SELECT p.* FROM proprietate_de_inchiriat p WHERE nrfil='S3'; Avantaje sau dejavantaje ?!? Depinde de problemele care pot aprea. tabele de referin (tabele de cutare) Acestea conin, de obicei, un cod i o descriere. De exemplu se poate defini un tabel cutare "printe" pentru tipul de proprietate i modifica tabelul proprietate_de_inchiriat ("copil") astfel: TIP_PROPRIETATE(tip, descriere) PROPRIETATE_DE_INCHIRIAT(nrpte, strada, zona, oras, coppostal, tipul, nrcamere, chirie, nrptr, nrfiliala, nrpersonal) Avantaje: dac este modificat descrierea, atunci se va modifica o singur dat, n tabelul de cutare; se reduce dimensiunea relaiei "copil"; dublarea atributelor cheii externe ntr-o relaie de tip 1:M pentru simplificarea join-urilor S se enumere proprietarii de proprieti de nchiriat dintr-o filial. SELECT ptr.nume FROM proprietate_de_inchiriat p, proprietar ptr WHERE p.nrptr=ptr.nrptr AND p.nrfil='S3'; Dac se dubleaz cheia extern nrfiliala n relaia PROPRIETAR, adic se introduce o relaie direct ntre FILIALA i PERSONAL, atunci cererea devine: SELECT p.nume FROM proprietar p WHERE nrfil='S3'; ATENIE! Sunt necesare constrngeri suplimentare asupra cheilor externe. De exemplu, dac un proprietar ar nchiria prin mai multe filiale (atribut multiplu), atunci modificrile nu mai sunt valabile. De remarcat c singurul motiv pentru care relaia proprietate_de_inchiriat conine atributul nrfiliala const n faptul c este posibil ca o proprietate s nu aib alocat un membru de personal, mai ales la

68

nceput, cnd este preluat iniial de ctre agenie. Dublarea atributelor n relaiile de tip M:N, pentru reducerea join-urilor. Presupunem c relaia M:N dintre chirias i proprietate_de_inchiriat a fost descompus prin introducerea relaiei intermediare VIZITARE. Care sunt chiriaii care au vizitat proprieti, dar mai au de fcut comentarii asupra uneia dintre ele? Personalul de la agenie are nevoie de atributul strada atunci cnd vorbete cu chiriaii. SELECT p.strada, c.*, v.data
FROM chirias c, vizitare v, proprietate_de_inchiriat p

WHERE v.nrpte = p.nrpte AND c.nrch = v.nrch AND comentarii IS NULL; Atributul nrpte este codul proprietii, iar nrch este codul chiriaului. Dac se introduce atributul strada n relaia VIZITARE, atunci cererea devine: SELECT v.strada, c.*, v.data FROM chirias c, vizitare v WHERE c.nrch = v.nrch AND comentarii IS NULL; Comentm pasul 3! Proiectarea reprezentrii fizice Scopul este de a stoca datele n mod eficient. Pentru msurarea eficienei poate fi analizat: capacitatea de stocare pe disc; timpul de rspuns; transferul de tranzacii (numrul de tranzacii care pot fi efectuate ntr-un anumit interval de timp). Pentru mbuntirea performanelor trebuie ca proiectantul s cunoasc cum interacioneaz cele 4 componente hardware (memoria principal, CPU, discul I/O, reeaua) i modul cum acestea afecteaz performanele sistemului. Principiile de baz ale distribuirii datelor pe unitile de disc: fiierele sistemului de operare s fie separate de cele ale BD; fiierele principale ale BD s fie separate de fiierele de indexare; fiierul jurnalului de recuperare s fie separat de restul BD. n aceast etap se face i analizarea tranzaciilor, adic cunoaterea funcionalitii acestora i analizarea celor mai importante dintre acestea.

69

Pentru fiecare tranzacie trebuie detrminat: frecvena estimat cu care va fi rulat; relaiile i atributele accesate; tipul de acces (inserare, interogare, tergere sau rectualizare); atributele care apar n predicate (condiii); atributele care apar n join-uri; constrngerile de timp impuse tranzaciilor.

Limbaje pentru prelucrarea datelor relaionale

Unul dintre cele mai mari merite ale modelului relaional este c prin intermediul multiplelor sale limbaje de interogare (neprocedurale) permite utilizatorului, chiar i neinformatician, s indice rezultatul care l intereseaz, fr a preciza modul n care este obinut acest rezultat. O relaie poate fi definit ca o mulime, sau ca un predicat. Conform dualitii definiiei unei relaii, limbajele de prelucrare a datelor relaionale pot fi grupate n: limbaje algebrice - bazate pe teoria mulimilor (SEQUEL, SQL); limbaje predicative - fondate pe calculul predicatelor. orientate pe tupluri (QUEL, ALPHA); orientate pe domenii (pot fi non-grafice (ILL, FQL) sau grafice). cu variabile domeniu explicite (QBE); fr variabile domeniu explicite (LAGRIF, CUPID, VGQF).

Limbajele predicative pot fi:

Limbajele grafice pot fi:

SQL este limbajul standard de descriere a datelor i acces la informaiile din baza de date. SQL nu este un limbaj unic (cu excepia standardului care este puin utilizat), existnd peste o 100 de dialecte. Au

70

fost concepute i dezvoltate diferite versiuni ale standardului SQL de ctre ANSI, IBM, Microsoft, Borland, etc. Din pcate, lipsa unui standard unic SQL are drept consecine creterea costurilor programelor de gestiune a bazelor de date i ngreunarea ntreinerii arhitecturilor client/server. Un grup de specialiti n baze de date s-au reunit sub numele SAG (SQL Access Group) cu scopul de a construi un limbaj SQL comun i de a realiza pentru fiecare dialect un program de conversie din dialect n SQL, i invers. Rezultatul a fost c n: 1992, Microsoft a lansat ODBC (Open Database Connectivity) care este o mulime de primitive bazate pe activitatea lui SAG; 1994 Borland a lansat IDAPI (Integrated Database Application Programming Interface) care este o bibliotec de funcii SQL ce se pot integra ntr-un program gazd.

Limbaje algebrice
n abordarea algebric, o relaie este considerat ca o mulime de tupluri, iar o baz de date este considerat ca o mulime de relaii pe care sunt definii operatorii algebrici. Exist dou tipuri de operatori algebrici: mulime (intersecie, reuniune, diferen, produs cartezian) i relaionali (proiecie, selecie, diviziune, compunere). Operatorii selecie, proiecie, produs cartezian, reuniune i diferen sunt ireductibili i sunt considerai drept operatori de baz, iar operatorii intersecie, diviziune i compunere pot fi dedui din operatorii anteriori i sunt considerai operatori derivai. Operatorii limbajului algebric permit exprimarea unor cereri nerecursive. Dac cererea este recursiv este necesar un operator special i anume nchiderea tranzitiv a unei relaii. limbaj algebric definit pentru prototipul relaional SYSTEMR. Operaia fundamental a limbajului este SELECT, care are forma general clasic. Operatorii clasici UNION, INTERSECTION, DIFFERENCE i INCLUSION sunt implementai n limbaj. SEQUEL este singurul limbaj relaional care are integrat nchiderea tranzitiv. Limbajul permite reactualizri asupra bazelor (UPDATE, INSERT, DELETE) i calculul unor funcii elementare (COUNT, SUM, AVG, MAX, MIN). Conceptul de partiionare a fost de asemenea introdus n SEQUEL i realizat cu ajutorul clauzelor GROUP BY i HAVING. O extensie comercial a acestui limbaj, adoptat de aproape toate SGBD i considerat drept standard n prelucrarea datelor relaionale, este SQL.

SEQUEL (Structured English as a Query Language) este un

71

Limbaje predicative
Limbajele predicative se bazeaz pe calculul predicatelor. Cererile sunt exprimate sub forma unor mulimi de tupluri sau valori pentru care se specific, sub forma unor predicate, proprietile pe care trebuie s le ndeplineasc. sistemul INGRES. Limbajul QUEL poate fi utilizat independent sau inclus n limbajul de programare C. Limbajul este caracterizat de: declararea unei variabile tuplu pentru fiecare relaie (prin RANGE), absena cuantificatorilor n expresii, utilizarea unor operatori speciali pe mulimi, integrarea operaiilor aritmetice. Exemplu. S se listeze numele cititorilor care au mprumutat cri scrise de Cioran. RANGE OF a IS carte RANGE OF b IS cititor RANGE OF v IS imprumuta RETRIEVE b.nume WHERE (b.codec = v.codec) AND (v.codel = a.codel) AND (a.autor = Cioran) Limbajul accept comenzi de inserare (APPEND), reactualizare (REPLACE), suprimare (DELETE), precum i funcii de calcul (MAX, MIN, SUM, COUNT, AVG). Cuantificatorul existenial este reprezentat implicit prin declaraia RANGE, iar cuantificatorul universal este simulat cu ajutorul funciei COUNT. Exemplu. S se listeze numele cititorilor care au mprumutat toate crile din bibliotec scrise de Cioran. RANGE OF a IS carte RANGE OF b IS cititor RANGE OF v IS imprumuta RETRIEVE b.nume WHERE COUNT (v.codel WHERE (b.codec=v.codec) AND (a.codel=v.codel)

QUEL este un limbaj predicativ orientat pe tupluri, utilizat de

72

AND (a.autor=Cioran)) = COUNT (a.codel WHERE (a.autor=Cioran))

QBE (Query By Example) este un limbaj predicativ orientat pe

domenii. Limbajul dispune de primitive de programare grafic a cererilor de date i a fost conceput pentru utilizatorii neiniiai. Utilizatorii, pentru a manipula datele, completeaz o mulime de cmpuri predefinite pe un ecran special. Exemplu. S se obin titlurile crilor scrise de Cioran, din care exist n bibliotec mai mult de 10 exemplare.

Carte Codel

Titlu P.X

Autor 'Cioran'

Pret

Nrex >10

Coded

Dac utilizatorul dorete i tiprirea, atunci indic rezultatul care l intereseaz sub forma unei variabile domeniu (notat n acest exemplu prin X) prefixat de P (print). Dac condiia care apare n interogare este complex sau se dorete simplificarea scrierii unei cereri, se poate utiliza o caset special (box condition) n care se introduce condiia. n limbaj sunt admise funciile COUNT, MAX, MIN, AVG, SUM, iar pentru eliminarea dublurilor a fost introdus operatorul UNIQUE. Exemplu. S se obin pentru fiecare autor, preul celei mai scumpe cri i numrul exemplarelor scrise de acesta, care s gsesc n bibliotec (tabelul sortat!!!). Carte Codel Titlu Autor GROUP BY Pret MAX Nrex SUM Coded

n QBE exist posibilitatea de a crea o nou relaie care poate fi o schem virtual care reflect modificrile din relaiile de baz sau o imagine n care modificrile nu sunt stocate. Exemplu. Codurile crilor scrise de Popa sau care au titlul Geometrie. Algebric:

73

R1 = SELECT(carte, autor = 'Popa') R2 = SELECT(carte, titlu = Geometrie') R3 = R1 R2 Rezultat = PROJECT (R3, codel) SEQUEL: SELECT FROM WHERE OR QBE: Codel Titlu Autor Pret Nrex Coded P.X 'Popa' P.Y 'Geometrie' Exemplu. Numele cititorilor care au mprumutat cel putin o carte scrisa de Cioran. Algebric: R1 = PROJECT(cititor, codec, nume) R2 = SELECT(carte, autor = 'Cioran') R3 = PROJECT(R2, codel) R4 = PROJECT(imprumuta, codel, codec) R5 = JOIN(R4, R3, codel) R6 = JOIN(R5, R1, codec) Rezultat = PROJECT(R6, nume) QBE: Cititor Imprumuta Codec Y Codel Z Codec Y Autor 'Cioran' Nume P.X Dataim Pret Dep Datares Nrex Dataef Coded Carte codel carte autor = Popa titlu = Geometrie

Carte Codel Titlu Z

SEQUEL: SELECT nume FROM cititor WHERE codec IS IN SELECT codec

74

FROM imprumuta WHERE codel IS IN SELECT codel FROM carte WHERE autor = Cioran

Utilizarea limbajelor de prelucrare a datelor relaionale n contextul limbajelor de programare

Dou abordri: integrarea, extensia.

Integrarea LMD-ului ntr-un limbaj de programare. Se consider limbajul de prelucrare independent de limbajul de programare i exist construcii speciale care permit utilizarea acestuia n limbajul gazd. De exemplu, comenzile SQL pot fi integrate n limbajul PL/1. Ele sunt prefixate de caracterul $ pentru a le distinge de comenzile PL/1. Pentru a realiza integrarea, este necesar fie o precompilare a cererilor, fie o interpretare la execuie. Precompilatoarele actuale acoper majoritatea limbajelor semnificative existente. Alegerea unui precompilator particular depinde de domeniul aplicaiei. Extensia limbajului de programare cu un LMD Se consider un limbaj de programare i se realizeaz extensii ale acestuia cu clauze specifice limbajelor de prelucrare a datelor. Un exemplu tipic este extensia PASCAL/R care permite definirea unui nou tip de date, i anume tipul RELATION. De exemplu, relaia carte este definit: TYPE car = RECORD codel: TEXTE; titlu: TEXTE; autor: TEXTE; nrex: INTEGER; pret: INTEGER; coded: TEXTE END; abc = RELATION OF car; VAR carte: abc; Exemplu.

75

S se obin o relaie avnd numele rezultat, ce conine toate crile scrise de Cioran care au preul mai mare de 150000. VAR rezultat: abc; BEGIN rezultat:=[]; FOR EACH x IN carte DO IF(x.autor = Cioran) AND (x.pret >= 150000) THEN rezultat:=rezultat + [x] END; Relaia rezultat poate fi construit i direct prin atribuirea: rezultat := [EACH (x) IN carte: (x.autor = Cioran) AND (x.pret >= 150000)];

Exemplu pentru BCNF

Exemplu. Pentru al doilea exemplu de chei candidat care se suprapun se va considera un tabel avnd schema relaional: EXEMPLU(A, B, C). Se presupune c asupra tabelului exist constrngeri care se materializeaz prin dependenele funcionale: {A, B} C i C B. Din nou, sunt dou chei candidat care se suprapun {A, B} i {A, C}. Tabelul nu este n BCNF i evident sufer de anomalii, cauzate de faptul c atributul C este un deteminant, dar nu o cheie candidat. Soluia problemei const n divizarea relaiei n dou proiecii conform tehnicii Casey-Delobel: EXEMPLU1(A, C) i EXEMPLU2(C, B). Aceast descompunere evit anumite anomalii, dar poate genera altele. Cele dou proiecii nu sunt independente, adic nu pot fi efectuate actualizri n oricare dintre ele, indiferent de cealalt. De exemplu, dependena {A, B} C nu poate fi dedus din C B. Prin urmare, cele dou proiecii nu pot fi reactualizate independent. Exemplu. Pentru acest exemplu de chei candidat care se suprapun se va considera un tabel avnd schema relaional: EXEMPLU(A, B, C). Se presupune c asupra tabelului exist constrngeri care se materializeaz prin dependenele funcionale: {A, B} C i {B,C} A

76

Din nou, sunt dou chei candidat care se suprapun {A, B} i {B, C}. Totui, tabelul este n BCNF deoarece aceste chei candidat sunt singurii determinani. Prin urmare, suprapunerea cheilor candidat nu genereaz neaprat anomalii.