baze de date

August 6, 2017 | Author: Adrian Petcu | Category: N/A
Share Embed Donate


Short Description

Database SQL, baze de date...

Description

Proictarea Bazelor de Date Curs Specializarea Ingineria Informației - anul IV-A

Facultatea de Electronica, Telecomunicatii si Tehnologia Informatiei

Prof. Felicia Ionescu http://info.tech.pub.ro/~fionescu/

Bibliografie „ Felicia Ionescu, “Baze de date relationale si aplicatii”, Editura Tehnica, Bucureşti, 2004 „ C. J. Date, “An Introduction to Database Systems”, 8th Edition, 2004 „ R. Elmasri and S. B. Navathe, “Fundamentals of Database Systems”, Fourth Edition, 2004 „ J. Ullman, J. Windom, “A First Course In Database Systems”, Prentice Hall, 1997 „ Kevin Kline, Daniel Kline, “ SQL In A Nutshell”, O’Reilly, 2001 „ Oracle 11g Documentation http://www.oracle.com/technetwork/database/enterprise-edition/documentation/index.html

„ MySQL Documentation - http://dev.mysql.com/doc/ „ PostgreSQL Documentation - http://www.postgresql.org/docs/manuals/ „ Microsoft SQL Server Books Online – MSDN - Academic Alliance

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

2

Capitolul 1: Introducere „ Definiții – baze de date, sisteme de baze de date „ Componentele sistemelor de baze de date „ Arhitectura interna a sistemelor de baze de date „ Avantajele oferite de sistemele de baze de date „ Clasificari ale sistemelor de baze de date ● Clasificare dupa modelul de date ● Clasificare dupa numarul de utilizatori ● Clasificare dupa numarul de statii pe care este memorata baza de date

„ Modelarea datelor ● Modele conceptuale de nivel inalt ● Modele specifice de date

„ Evolutia sistemelor de baze de date

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

3

Sisteme de baze de date „ Bazele de date se folosesc in aproape toate domeniile de activitate actuale: ●

Activitati bancare si comerciale (depozite bancare, vanzari produse)



Productie (gestiunea stocurilor, gestiunea financiar-contabila, salarizare etc.)



Evidenta populatiei, taxe si impozite



Servicii (servicii medicale, rezervari bilete de calatorie etc.)

„ Definitie (in sens larg): O baza de date (database) este o colecţie de date corelate din punct de vedere logic, care reflecta un anumit aspect al lumii reale şi este destinata unui anumit grup de utilizatori. In acest sens pot fi considerate ca fiind “baze de date”: ●

Fise de evidenta (mentinute manual)



Fisiere de documente sau foi de calcul tabelar (Microsoft Word, Microsoft Excel)



Baze de date mentinute computerizat

„ Definitie (in sens restrans): O bază de date este o colecţie de date creată şi menţinută computerizat, care permite operaţii de: ●

Introducere (insert)



Stergere (delete)



Actualizare (update)



Interogare (query)

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

4

Componentele unui Sistem de Baze de Date (1) „ Un sistem de baze de date (Database System) este un sistem computerizat de menţinere a evidenţei unei anumite activităţi, folosind baze de date „ Componentele unui sistem de baze de date sunt: hardware, software, utilizatori si date persistente „ Hardware: ● Sistemele de baze de date sunt instalate pe calculatoare de uz general ● Bazele de date sunt memorate fizic ca fisiere pe discuri magnetice (hard-discuri)

„ Software: ● Sisteme de operare, biblioteci, instrumente de dezvoltare, interfete ● Sistemul de Gestiune a Bazelor de Date (SGBD) (Database Management System – DBMS) - recepţionează cererile utilizatorilor de acces la baza de date, le interpretează, execută operaţiile corespunzătoare şi returnează rezultatul ● Aplicatii de baze de date: (Database Applications) – sunt programe care oferă anumite utilizari ale unei baze de date

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

5

Componentele unui Sistem de Baze de Date (2) Baza de date

Utilizator final

Date

Program aplicaţie

Date

SGBD Date

Date

„ Utilizatori: ● Programatori de aplicatii ● Utilizatori finali ● Administratorul bazei de date ● Analisti si proiectanti ai bazelor de date

„ Datele persistente – sunt memorate in fisiere pe hard-disk „ Limbaje conceptuale pentru lucrul cu bazele de date: ● Limbaje pentru Definirea Datelor(LDD) (Data Definition Languages – DDL) ● Limbaje pentru Manipularea Datelor (LMD) (Data Manipulation Languages – DML) Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

6

Arhitectura interna a unui Sistem de BD „ Arhitectura pe 3 niveluri relativ independente: nivelul intern, nivelul conceptual şi nivelul extern (Standard ANSI/X3/SPARC -1975) „ Schema Ædescrierea datelor pe un anumit nivel: schema interna, conceptuala si scheme externe (vedere utilizator) „ Corespondente intre niveluri (mappings)

Nivelul extern

Nivelul conceptual

Vedere utilizator #1

Vedere utilizator #2

Vedere utilizator #n

Schema conceptuală SGBD

Nivelul intern

Schema internă

Date memorate

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

7

Avantaje oferite de Sistemele de BD „ Compactitate ridicată a datelor „ Reprezentarea unor asocieri complexe intre date „ Timp de dezvoltare a bazelor de date redus „ Viteza mare de actualizare si regasire a datelor „ Redundanta controlata a datelor (si cat mai scazuta) „ Flexibilitate, mentinerea datelor actualizate la zi „ Independenta datelor fata de suportul hardware utilizat „ Securitatea datelor: autentificarea utilizatorilor si autorizarea accesului „ Impunerea de restrictii (constrangeri) de integritate la introducerea si actualizarea datelor „ Mentinerea integritatii datelor in caz de defecte: salvare si refacere „ Posibilitatea de partajare a datelor intre mai multe categorii de utilizatori „ Posibilitatea de introducere a standardelor

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

8

Clasificarea Sistemelor de Baze de Date (1) „ Clasificare dupa modelul de date: ● Modelul ierarhic de date ● Modelul de date retea ● Modelul relational ● Modelul obiect-orientat ● Modelul obiect-relational

„ Clasificare dupa numarul de utilizatori ● Sisteme mono-utilizator ● Sisteme multi-utilizator

„ Clasificare dupa numarul de statii pe care este memorata baza de date: ● Baze de date centralizate ● Baze de date distribuite

„ Arhitectura client-server: ● Server (back-end): SGBD-ul si baza de date ● Client (front-end): program (programe) de aplicatie Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

9

Clasificarea Sistemelor de Baze de Date (2) Aplicaţie Client

Aplicaţie Client

Aplicaţie Client

Aplicaţie Client

Reţea de comunicaţie Server

Server

SGBD

SGBD

BD

BD

a

b

Sisteme de baze de date centralizate: a- mono-utilizator; b- multi-utilizator Aplicaţie Client

Aplicaţie Client

Aplicaţie Client Reţea de comunicaţie

Server

Server SGBD

SGBD

BD

BD

Sistem de baze de date distribuit Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

10

Modelarea datelor „ Un model este o abstractizare a unui sistem: ● captează cele mai importante trăsături caracteristice ale sistemului (concepte) ● conceptele trebuie sa fie relevante din punct de vedere al scopului pentru care se defineşte modelul respectiv

„ Tehnica de identificare a trăsăturilor caracteristice esenţiale ale unui sistem se numeşte abstractizare „ Un model de date stabileşte regulile de organizare şi interpretare a unei colecţii de date. „ În proiectarea bazelor de date se folosesc 2 categorii de modele: ● Modele conceptuale de nivel înalt (modelul Entitate-Asociere, modelul Entitate-Asociere Extins)– descriu concis colectiile de date care modelează activitatea dorită fără să detalieze modul de reprezentare sau de prelucrare a datelor - schemă conceptuală de nivel înalt ● Modele specifice (modelul ierarhic, modelul reţea, modelul relaţional, etc.) descriu reprezentarea mulţimilor de entităţi şi a asocierilor dintre acestea prin structuri de date specifice implement[rii - schemă conceptuală (logică)

„ Trecerea de la modelul conceptual de nivel înalt la un model de date specific Æ proiectare logică a bazei de date. Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

11

Modelul Entitate-Asociere „ Modelul Entitate-Asociere (Entity-Relationship Model) defineste multimile de entităţi şi asocierile dintre ele, dar nu impune nici un mod specific de structurare şi prelucrare (gestiune) a datelor; Introdus în 1976 de P.S. Chen „ O entitate (entity) este „orice exista in realitatea obiectiva si poate fi identificat în mod distinctiv“ ● Exemple: o persoana, o planta, o activitate, un concept etc.

„ Un atribut (attribute) este o proprietate care descrie un anumit aspect al unei entităţi ● Exemple: persoanele au nume, prenume, adresa etc.

„ Tip de entitate (entity type): se refera la entitătile similare, care pot fi descrise prin aceleasi atribute ● Exemple: tipul persoana, tipul planta

„ Multime de entitati (entities set): colecţia tuturor entităţilor de acelaşi tip dintr-o bază de date constituie o mulţime de entităţi ● Exemple: multimea tuturor persoanelor, multimea tuturor plantelor

„ O entitate este o instanta a unui tip de entitate si un element al multimii de entitati de acel tip „ In exprimarea curenta, adeseori nu se face diferentierea dintre entitate, tip de entitate si multime de entitati, dar diferenta este evidenta „ Asemanare cu modelul obiect: tip de entitate - clasa; entitate - obiect Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

12

Asocieri „ O asociere (relationship) este o legătură (corespondenţă) între entităţi din două sau mai multe mulţimi de entităţi; asocierile pot avea atribute „ Tipul asocierii (relationship type) – se refera la asocierile similare, care pot fi definite intre entitati din 2 sau mai multe multimi de entitati „ Multime de asocieri (relationship set): multimea asocierilor de acelasi tip „ O asociere este o instanta a unui tip de asociere si un element al multimii de asocieri de acel tip „ In exprimarea curenta, adeseori nu se face diferentierea dintre asociere, tip de asociere si multime de asocieri, dar diferenta este evidenta „ Gradul unui (tip de) asociere (degree): numărul de (mulţimi de) entităţi asociate; dupa grad, asocierile pot fi: ● binare (de gradul 2, între 2 mulţimi de entităţi) – majoritatea asocierilor ● multiple (între k mulţimi de entităţi, k > 2)

„ Categorii (tipuri) de asocieri binare - după numărul elementelor din fiecare dintre cele două mulţimi puse în corespondenţă: ● ● ● ●

“unul-la-unul” (one-to-one) – 1:1; exemplu: sot-sotie ”unul-la-multe” (one-to-many) – 1:N; exemplu: parinte-fii “multe-la-unul” (many-to-one) – N:1; exemplu: fii-parinte “multe-la-multe” (many-to-many) – M:N; exemplu: profesori-studenti

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

13

Categorii de asocieri binare (1)

“unul-la-unul” – 1:1

“unul-la-multe”- 1:N

Asocieri binare intre multimile de entitati A si B Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

14

Categorii de asocieri binare (2)

“multe-la-unul”- N:1

“multe-la-multe”- M:N

Asocieri binare intre multimile de entitati A si B Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

15

Cardinalitatea asocierilor „ Cardinalitatea (multiplicitatea) unei asocieri faţă de o mulţime de entităţi (cardinality, multiplicity) este numărul maxim de elemente din acea mulţime care pot fi asociate cu un element din altă mulţime a asocierii ● Exemplu: asocierea “unul-la-multe” dintre mulţimile A şi B prezintă multiplicitatea 1 faţă de mulţimea A şi multiplicitatea N (se înţelege o valoare oarecare N > 1) faţă de mulţimea B

„ Raport de cardinalitate (cardinality ratio): raportul dintre valorile cardinalităţilor unei asocieri faţă de două din mulţimile de entităţi asociate ● Exemple pentru asocieri binare: 1:1, 1:N, N:1, M:N ● Asocierile multiple (k-are, k > 2) prezintă câte un raport de cardinalitate pentru fiecare pereche de mulţimi de entităţi pe care le asociază.

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

16

Diagrama Entitate-Asociere „ Diagrama Entitate-Asociere (Entity-Relationship Diagram) reprezintă grafic modelul Entitate-Asociere prin mulţimile de entităţi şi asocierile dintre acestea „ Multimi (tipuri) de entitati: ● Puternice (de sine statatoare) ● Slabe (depind de alte multimi de entitati)

„ Notatii: Tip de entitate puternică

Tip entitate

Tip entitate

Tip de entitate slabă

Nume atribut

A

Prof. Felicia Ionescu

1

Atribut

N

B

Cap.1 - Introducere in Baze de date

Asociere binară 1:N între 2 tipuri de entităţi

17

Exemplu de diagrama Entitate-Asociere (1) „ Multimi de entitati puternice: ● SECTII (Numar, Nume, Buget) ● ANGAJATI (Nume, Prenume, DataNasterii, Adresa, Functie, Salariu) ● PROIECTE (Denumire, DataInceperii, Termen, Buget)

„ Multimi de entitati slabe: DEPENDENTI (Nume, Prenume, DataNasterii, GradRud) Buget

Număr

Salariu

Nume

1 SECTII Cuprind

N

ANGAJATI 1

M Lucreaza

Intretin N

N DEPENDENTI

Nume

Prof. Felicia Ionescu

GradRudenie

Cap.1 - Introducere in Baze de date

PROIECTE

Denumire

Buget

18

Exemplu de diagrama Entitate-Asociere (2) „ Asocieri: „ Asocierea SECTII - ANGAJATI - 1:N „ Asocierea ANGAJATI - PROIECTE - M:N „ Asocierea ANGAJATI - DEPENDENTI - 1:N

„ Raportul de cardinalitate al unei asocieri este stabilit de proiectant astfel încât să reflecte cât mai corect modul de organizare a activităţii modelate „ Modul de stabilire a tipurilor de entităţi şi a asocierilor nu este unic: aceeaşi funcţionalitate se poate obţine printr-o varietate de diagrame E-A „ O mulţime de entităţi se denumeste printr-un substantiv, iar o asociere se denumeste (de regulă) printr-un verb, deoarece o asociere reprezintă o interacţiune între entităţi „ Modelul E-A nu precizează modul cum sunt realizate asocierile între mulţimile de entităţi: acest aspect depinde de modelul de date specializat utilizat pentru definirea bazei de date „ Exemple: în modelul ierarhic asocierile sunt realizate explicit, prin pointeri de la o entitate la entităţile asociate; în modelul relaţional asocierile se realizează prin egalitatea valorilor unor atribute comune ale multimilor de entităţi (chei) Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

19

Modelul Entitate-Asociere Extins „ Modelul Entitate-Asociere Extins (Enhanced Entity-Relationship Model) permite definirea de subtipuri ale unui tip de entităţi, care moştenesc atribute de la tipul de entitate respectiv „ Crearea ierarhiilor: specializare si generalizare „ Tipurile şi a subtipurile formeaza ierarhii de tipuri de entităţi complexe, organizate pe mai multe niveluri „ Diagrama Entitate-Asociere Extinsa Nume

Prenume

DataNasterii

Adresa

Salariu

ANGAJAT d

SECRETARA

VitezaRedactare

Prof. Felicia Ionescu

TEHNICIAN

INGINER

Calificare

Specialitate

Cap.1 - Introducere in Baze de date

20

Modelul de date ierarhic „ Modelul ierarhic (Hierarchical Model): baza de date se reprezinta printr-o structură ierarhică de înregistrări (records) conectate prin legături (links). „ A fost primul model folosit pentru dezvoltarea bazelor de date „ Cel mai cunoscut SGBD ierarhic: sistemul IMS (Information Management System) dezvoltat de IBM în programul de cercetări Apollo, în perioada anilor 1960

„ O înregistrare de date în modelul ierarhic este o instanţă a unui tip de înregistrare (record type) şi constă dintr-o colecţie de câmpuri (fields), fiecare câmp conţinând valoarea unui atribut. „ Un tip de legătură în modelul ierarhic: tip de asociere cu raportul de cardinalitate 1:N (părinte-fiu) între două tipuri de înregistrări „ Schema conceptuală a unei baze de date în modelul ierarhic se reprezintă printr-un număr oarecare de scheme ierarhice „ O schemă ierarhică este un arbore direcţionat, reprezentat pe mai multe niveluri, în care nodurile sunt tipuri de înregistrări, iar arcele sunt tipuri de legături

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

21

Baze de date ierarhice FACULTATI FACULTATI

FACULTATI

f1

1 N PROFESORI

f2

f3 PROFESORI

PROFESORI

p1

M

p2

p3 STUDENTI

N STUDENTI (a) Diagrama E-A

STUDENTI

s1

(b) Schema ierarhica

s2

s3

s1

s2

s4

(c) Arbori de instantiare a datelor

„ Numai legături de tipul părinte-fiu, care corespund asocierilor 1:1 şi 1:N din modelul E-A „ Asocierile M:N se pot reprezenta prin multiplicarea înregistrărilor de tip fiu, atunci când sunt referite de mai multe înregistrări de tip părinte „ mare redundanţă a datelor

„ Avantaje: simplitatea şi eficienţa de calcul „ Deficiente: „ nu exista separare intre descrierea logica si fizica a datelor „ interogarile trebuie să fie prevăzute explicit in structura datelor

„ Utilizari actuale - aplicatii specializate, baze de date XML Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

22

Modelul de date retea „ Modelul reţea (Network Model) foloseşte o structură de graf pentru definirea schemei conceptuale a bazei de date „ Modelele ierarhic si retea Æ modele pre-relationale „ Standardizat în 1971, de o comisie DBTG (Database Task Group). „ Sisteme de gestiune comerciale in modelul retea: IDS II (Honeywell), UNISYS (Burroughs), IDMS (Computer Associates) „ Nodurile grafului sunt tipuri de entităţi (înregistrări - records), iar muchiile reprezintă asocierile (legăturile-links) dintre tipurile de entităţi „ Asocierile M:N se reprezintă fără duplicarea înregistrărilor, fiecare înregistrare putând fi referită de mai multe înregistrări, ceea ce elimină FACULTATI (micșorează) redundanţa „ Dezavantaje:

f1

f2

f3

„ aceleasi ca si la modelul ierarhic, la care se adauga „ complexitatea mare in reprezentarea datelor

PROFESORI p1

„ Actualmente modelul retea:

p2

p3 STUDENTI

„ este rar utilizat pentru baze de date de uz general „ se utilizeaza pentru aplicații specializate

s1

de ex, pentru baze de date grafice (scene virtuale) Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

s2

s3

s4

Modelul retea 23

Modelul de date relational „ Modelul relaţional (Relational Model) se bazează pe noţiunea de relaţie (relation) din matematică, care corespunde unei mulţimi de entităţi „ Fundamentat de E.F. Codd (IBM), prin lucrarea "Un Model Relaţional de Date pentru Bănci Mari de Date Partajate" (1970) „ Dezvoltare extraordinara a sistemelor de gestiune a bazelor de date relationale, datorită simplităţii şi a fundamentării matematice a modelului „ Alte lucrări ale cercetatorilor C.J. Date, P. Chen, R. Boyce, J.D. Ullman, R. Fagin, W. Armstrong, M. Stonebraker etc. au perfecţionat modelul relaţional „ Primul Sistem de Gestiune a Bazelor de Date Relaţionale (SGBDR) a fost prototipul System R (IBM, 1970) „ După aceasta numeroase companii au realizat sisteme de gestiune relaţionale: Oracle, Microsoft, Ingres, Sybase, IBM, Informix „ SGBDR folosesc limbajul SQL (Structured Query Language), pentru care au fost emise mai multe standarde ANSI (American National Standardization Institute) si ISO (International Standardization Office) „ Majoritatea SGBD-urilor relaţionale actuale implementează versiunea SQL2 (SQL92) sau versiuni ulterioare (SQL-1999, SQL-2003, SQL-2006) Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

24

Modelul obiect-orientat „ Modelul obiect (Object Model) este un concept unificator „ Necesar in domenii în care se manipulează date de tipuri complexe: „ proiectarea sistemelor de calcul: programare, hardware, interfete „ proiectarea asistată de calculator (CAD-CAM) „ sisteme de informaţii geografice „ fizică, biologie, medicină şi altele

„ Strategii pentru dezvoltarea sistemelor de gestiune a bazelor de date obiect-orientate (SGBDOO): „ Extinderea unui limbaj de programare obiect-orientat cu capacităţi de administrare a obiectelor persistente: sistemul GemStone (extinde Java si C++) „ Extinderea unui limbaj de programare relaţional cu capacităţi de orientare spre obiecte. Exemplu: limbajul OQL (Object Query Language) (sau Object SQL), Există mai multe astfel de sisteme, cum sunt: Ontos, Versant, O2. „ Dezvoltarea unui limbaj obiect-orientat pentru baze de date complet nou: SIM (Semantic Information Manager).

„ Dificultati: „ Complexitate in dezvoltare a bazei de date şi a aplicaţiilor „ Interogarile trebuie să fie prevăzute explicit in structura datelor

„ Utilizare SGBDOO: cam 5% din sistemele de gestiune actuale Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

25

Modelul obiect-relational „ Modelul obiect-relaţional (Object-Relational Model) reprezintă extinderea modelului relaţional cu caracteristici ale modelului obiect „ Modelul obiect-relaţional păstrează structurarea datelor în relaţii, si, in plus: „ permite definirea unor noi tipuri de date, ca domenii ale atributelor „ permite extinderea tipurilor de date prin moştenire

„ Sistemele de gestiune a bazelor de date obiect-relaţionale (SGBDOR) se realizează prin extinderea sistemelor relaţionale, de regula în mod gradat, adăugându-se de la o versiune la alta cât mai multe caracteristici posibile ale modelului obiect „ Aceasta abordare asigură rularea în continuare a aplicaţiilor relaţionale existente în noile versiuni de sisteme SGBDOR, ceea ce permite producătorilor să-şi păstreze clienţii şi domeniile de utilizare „ Limbajele de programare pentru SGBDOR sunt implementări de standarde mai recente ale limbajului SQL: SQL3 (SQL-1999), SQL-2003, SQL-2006

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

26

Complexitatea datelor si a interogarilor „ Clasificare propusa de M. Stonebraker (1996) Complexitatea interogărilor

SGBDR

SGBDOR

Sisteme de fişiere

SGBDOO Complexitatea datelor

„ SGBDR prelucrează tipuri simple de date, dar permit interogări complexe „ SGBDOO prelucrează tipuri de date complexe, dar în care rezolvarea interogărilor este destul de dificil㠄 SGBDOR permit prelucrarea datelor complexe şi rezolvarea interogărilor complexe; sistemele de baze de date obiect-relaţionale sunt considerate sisteme de baze de date universale Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

27

Evolutia sistemelor de baze de date 1960

Modele prerelationale: ierarhic si retea Primele produse de baze de date (DBOM, IMS, IDS, Total, IDMS) Standarde Codasyl

1970

Modelul relational – prototipuri de SGBDR Lucrari teoretice asupra modelului relational Arhitectura interna pe 3 niveluri a bazelor de date (ANSI and Codasyl) Modelul Entitate-Asociere

1980

Dezvoltarea SGBDR comerciale Primul standard SQL (1986 - ANSI, ISO) Baze de date distribuite

1990

Arhitectura client/server a sistemelor de baze de date (two-tier arch.) Baze de date obiect-orientate Baze de date obiect-relationale Standarde SQL: SQL 92, SQL 99

2000

Arhitectura pe 3 niveluri a sistemelor de baze de date (three-tier arch.) Baze de date in sistemul WWW (World Wide Web)

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

28

Sisteme de Gestiune a Bazelor de date Sisteme Comerciale Oracle ($$$$) DB2 (IBM) ($$$) SQL Server (Microsoft) ($$) Sisteme Open Source PostgreSQL MySQL

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

29

Prof. Felicia Ionescu

Cap.1 - Introducere in Baze de date

30

Capitolul 2: Baze de date relaționale „ Relații, atribute, domenii; schema relației „ Reprezentarea relațiilor prin tabele „ Limbajul SQL: „ Convenții lexicale „ Expresii, operatori, functii „ Instructiuni de definire a datelor: CREATE, ALTER, DROP „ Instructiuni de manipulare a datelor: SELECT, INSERT, UPDATE, DELETE

„ Constrângerile de integritate ale relațiilor „ Constrângeri de domeniu „ Constrângeri de tuplu: cheia primară – chei secundare „ Constrângeri de integritate referențială – chei străine

„ Indexarea relațiilor „ Indexul primar „ Indexuri secundare

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

1

Relații – Atribute – Domenii „ Modelul relațional: E.F.Codd, 1970 – IBM „ O bază de date relaţională este compusă dintr-o mulţime finită de relaţii „ fiecare relaţie reprezinta o mulțime (tip) de entitati sau o mulțime (tip) de asocieri „ fiecare relație este unica intr-o baza de date „ o relație se defineste prin intermediul atributelor sale

„ Atributele unei relaţii corespund atributelor tipului de entitate sau de asociere pe care îl reprezintă relaţia respectiv㠄 fiecare atribut are un nume (Ai) și un domeniu de definiţie D(Ai) „ pentru o entitate data, un atribut poate lua o singură valoare (scalar)

„ Atributele pot fi: simple (un element) sau compuse (o submulțime de atribute) „ Domeniu: o mulțime de valori D = {di | i = 1,…, n }, definit printr-o specificare de tip, unde: „ D este numele domeniului „ di este un element al domeniului care satisface anumite constrângeri „ Elementele domeniilor sunt atomice (indivizibile) „ O valoare speciala, null, poate apartine oricarui domeniu (inseamna lipsa de informatie sau valoare necunoscuta) Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

2

Schema relației „ Schema relaţiei: descriere a unei relaţii (tipul, intensiunea relaţiei) „ Schema relaţiei: R(A1,A2,...Ai,...An), unde: „ R este numele schemei relaţiei „ lista ordonată a atributelor sale A1,A2,...Ai,..An „ fiecare atribut Ai definit pe domeniul său de definiţie, D(Ai) „ Gradul relaţiei: numărul de atribute ale schemei acelei relații (n) „ Exemplu: STUDENTI (Nume, Prenume, DataNasterii, Adresa, Facultatea)

„ O relaţie r definita prin schema R(A1,A2,...Ai,...An) este: „ o mulţime finita de n-tupluri t „ tuplul t este o listă ordonată de n valori: t = , unde 1 ≤ i ≤ n „ vi este o valoare a atributului Ai, vi ∈ D(Ai)

„ Relația r(R): r este variabila, instanta a schemei (tipului) R „ Valoarea variabilei: starea sau extensiunea relației „ Numarul de tupluri ale unei relații: cardinalitatea relației „ Fiecare tuplu este unic intr-o relație (nu exista tupluri duplicat) „ Corespondenta: relațieÆmulțime de entitati (sau de asocieri); tuplu Æ entitate

„ În mod curent: se foloseste R atat pentru schema cat și pentru relația insasi Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

3

Reprezentarea relațiilor prin tabele „ Un tabel (table) = reprezentarea grafică a unei relaţii; compusă din: „ Numele tabelului - identic cu numele relaţiei „ Coloanele corespund atributelor relației „ Capul tabelului- contine numele atributelor (coloanelor) Æ schema relației „ O mulţime de linii, fiecare linie corespunzând unui tupluÆ starea relației „ Valori ale atributelor fiecarui tuplu

„ Exemplu: Tabelul care reprezinta relația (starea relației) STUDENTI Valori atribute

Coloane - Atribute

Numele STUDENTI Nume

Prenume

DataNasterii

Adresa

Facultatea

Anghelescu

Octavian

1999

Bucuresti

ETTI

Beldiman

Cristina

1998

Bucuresti

ETTI

Boeru

Marius

1999

null

ETTI

Capul tabelului Linii - tupluri

„ Tabelul sugerează ordonarea atributelor (coloanelor) și a tuplurilor (liniilor) – ceea ce nu corespunde modelului matematic (relație = mulțime de tupluri) Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

4

Afișarea tabelelor „ SGBD-urile oferă instrumnente de proiectare și afisare a tabelelor ● De exemplu, afișarea tabelului Employees din baza de date Northwind folosind toolset-ul SQL Query Analyser din Microsoft SQL Server

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

5

Ordonarea valorilor atributelor în tupluri „ Din punct de vedere logic, ordinea valorilor atributelor într-un tuplu nu conteaza; această structurare poate fi exprimată prin următoarele definiţii: „ Schema relaţiei: R = {A1,A2, ...Ai,...An} (o mulţime de atribute) „ Relaţia r(R): o mulţime de n-tupluri t, unde: „ fiecare tuplu t este o mulţime de n perechi ordonate , unde 1 ≤ i ≤ n, „ t = {,,..., ...} „ vi este valoarea atributului Ai, vi ∈ D(Ai)

„ Observații asupra celor două definiții: „ A doua definiție a relaţiei este mult mai generală decat prima definitie „ Prima definiție simplifică notaţiile şi corespunde reprezentării prin tabel a relaţiei şi de aceea va fi folosită în continuare destul de frecvent „ În implementările reale, există o anumită ordine a valorilor atributelor memorate în fișiere, dar aceasta nu este relevantă din punct de vedere logic

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

6

Limbajul SQL „ Limbajul IBM Sequel dezvoltat ca parte a proiectului System R la IBM San Jose Research Laboratory (1970) „ Redenumit Structured Query Language (SQL) „ Standarde SQL - ANSI și ISO: Anul

Denumire

Caracteristici

1986

SQL-86

Publicat de ANSI (SQL1); ratificat de ISO în 1987

1989

SQL-89

Revizii minore

1992

SQL-92

Revizii majore, redenumit SQL2

1999

SQL-1999

Redenumit SQL3, adauga unele caracteristici obiect-relaționale

2003

SQL-2003

Adauga unele trasaturi referitoare la limbajul XML

2006

SQL-2006

Utilizare SQL în conjunctie cu XML

„ Fiecare SGBDR implementează un dialect al limbajului SQL, ceea ce micşorează gradul de portabilitate a aplicaţiilor „ În diferitele implementări ale limbajului SQL pot să lipsească unele comenzi prevăzute în standard, dar pot exista extensii specifice SGBD-ului respectiv Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

7

Caracteristicile generale ale limbajului SQL „ Limbajul SQL foloseste reprezentarea prin tabele a relaţiilor, reprezentare care este mai simplă şi mai intuitivă (foloseste termenii tabel, linie, coloană) „ Limbajul SQL cuprinde: „ Componenta de descriere a datelor (Limbaj de Descriere a Datelor – LDD) „ Componenta de manipulare a datelor (Limbaj de Manipulare a Datelor – LMD) „ Alte componente: controlul tranzactiilor, controlul securitatii, protectia datelor etc.

„ Limbajul SQL2 este un limbaj neprocedural: „ o instrucţiune SQL2 specifică ce informaţii trebuie să fie setate sau obţinute, nu modul (procedura) în care se opereaz㠄 limbajul SQL2 nu conţine instrucţiuni de control al fluxului execuţiei (instrucţiuni ca for, while, if, etc)

„ Standardul SQL3 prevede instructiuni de control și crearea de tipuri definite de utilizator, fiind implementat în SGBD-urile obiect-relaționale „ Pentru aplicaţiile de baze de date, s-au dezvoltat extensii procedurale ale limbajului SQL, biblioteci şi interfeţe de programare care integrează instrucţiunile SQL Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

8

Structura lexicala a limbajului SQL „ O instrucţiune SQL (statement) este o secvenţă de elemente - de regula terminată cu semnul punct şi virgulă (;) „ Fiecare instrucţiune SQL conţine o comandă SQL (command), care specifică ce acţiune se efectuează, urmată de alte elemente, care specifică operaţii, clauze, parametri etc. „ Exemplu: SELECT * FROM ANGAJATI;

„ Elementele (tokens) instrucţiunilor SQL „ cuvânte cheie (key words): CREATE, INSERT, SELECT , WHERE, FROM etc. „ identificatori (identifiers): „ simpli - numai caractere alfa-numerice și underscore(_): ANGAJATI, Nume, Prenume etc. „ delimitati (quoted) - pot contine orice caracter, foloseste ghilimele : ‘Nume’, ‘Prenume’ etc.

„ constante (literali): 1000, 100.5, ‘Ionescu’, NULL „ caractere speciale: *, ., ;

„ Spaţiile albe (whitespaces) separa elementele: spaţiu, linie nouă, tab „ O instructiune se poate scrie pe una sau mai multe linii, iar într-o linie se pot introduce una sau mai multe instructiuni „ Limbajul SQL este case-insensitive (nu deosebeste literele mici de cele mari) cu exceptia identificatorilor delimitati (quoted) care sunt case-sensitive Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

9

Expresii și operatori în limbajul SQL „ O expresie SQL constă dintr-unul sau mai mulţi operanzi, operatori şi paranteze „ Parantezele se pot folosi pentru a preciza o anumită ordine a operaţiilor, dacă aceasta este diferită de ordinea implicită data de precedenta operatorilor.

„ Un operand poate fi: „ numele unei coloane – în acest caz se foloseste valoarea memorata în acea colona intr-una sau mai multe linii ale tabelului „ o constantă (literal) „ valoarea returnată de o functie

„ Un operator SQL este exprimat prin: „ unul sau mai mai multe caractere speciale; exemple: +, -, *, /, %, 1000; SELECT * FROM city WHERE (Population > 200000) AND (CountryCode=‘ROM‘); Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

23

Clauze secundare – funcții agregat „ Clauzele secundare sunt: ORDER BY, GROUP BY, HAVING „ Clauza ORDER BY specifică numele atributului după care se face ordonarea liniilor tabelului rezultat SELECT * FROM city order by CountryCode;

„ Ordonarea în ordine crescătoare: parametrul ASC (implicit); în ordine descrescatoare: DESC. Exemplu: SELECT * FROM city order by CountryCode DESC;

„ Clauzele GROUP BY și HAVING se folosesc împreună cu funcțiile agregat „ Funcţiile agregat definite în limbajul SQL2 sunt următoarele: Functia

Valoarea returnata

COUNT

Numarul de linii al tabelului rezultat

SUM

Suma valorilor din coloana dată ca argument

MAX

Valoarea maxima din coloana dată ca argument

MIN

Valoarea minima din coloana dată ca argument

AVG

Valoarea medie din coloana dată ca argument

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

24

Funcții agregat „ Exemple de funcții agregat fără clauze secundare: SELECT COUNT(*) FROM city;

-- returneaza numarul de linii din tabel

SELECT COUNT(col) FROM city;

-- return nr de valori dif de null din acea col.

SELECT MAX(Population) FROM city; SELECT MIN(Population) FROM city; SELECT AVG(Population) FROM city;

„ Clauza GROUP BY se foloseşte pentru gruparea rezultatelor funcţiilor agregat dupa valoarea uneia sau mai multor coloane. Exemplu: SELECT CountryCode, AVG(Population) FROM city GROUP BY CountryCode;

„ Clauza HAVING înlocuiește clauza WHERE atunci când în condiția care trebuie să fie îndeplinită se folosesc funcții agregat. Exemplu: SELECT CountryCode, AVG(Population) FROM city GROUP BY CountryCode HAVING AVG(Population) >800000;

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

25

Instrucțiunea INSERT „ Instrucţiunea INSERT se foloseşte pentru introducerea datelor în tabele şi are următoarea sintaxă: INSERT INTO nume_tabel (col1,col2,...coln) VALUES(val1,val2,...valn);

„ Între valori şi numele de coloane trebuie să existe o corespondenţă pozitională. De exemplu: INSERT INTO SECTII (Numar, Nume, Buget) VALUES (1,‘Productie’, 40000);

„ Lista de coloane poate să lipsească dacă se introduc valori în toate coloanele tabelului și în această situatie: „ ordinea valorilor introduse trebuie să respecte ordinea coloanelor tabelului „ ordinea coloanelor provine din ordinea de definire a atributelor prin instrucţiunea CREATE TABLE, precum şi din operaţiile ulterioare de alterare a tabelului „ ordinea coloanelor se poate afla prin instrucţiunea DESCRIBE nume_tabel.

„ De exemplu, introducerea unei linii cu toate valorile în tabelul ANGAJATI (IdAngajat,Nume,Prenume,DataNasterii,Adresa,Functia,Salariu) se poate face cu instrucţiunea: INSERT INTO ANGAJATI VALUES(100,‘Mihailescu’, ‘Mihai’,‘1950-04-05’,‘Craiova’,’Inginer’, 3000);

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

26

Instrucțiunile UPDATE și DELETE „ Instrucţiunea UPDATE permite actualizarea valorilor coloanelor (atributelor) din una sau mai multe linii ale unui tabel și are sintaxa: UPDATE nume_tabel SET col1 = expr1 [, . . . n] [WHERE conditie];

„ Clauza WHERE: actualizarea valorilor se efectueaza numai asupra acelor linii care îndeplinesc condiţia dată. Exemplu: UPDATE ANGAJATI SET Adresa = ‘Bucuresti’ WHERE Nume = ‘Popescu’;

„ Dacă este omisă clauza WHERE, vor fi modificate valorile coloanelor din toate liniile tabelului. „ Instrucţiunea DELETE permite ştergerea uneia sau mai multor linii dintr-un tabel şi are sintaxa: DELETE FROM nume_tabel [WHERE conditie];

„ Din tabel se şterg acele linii care îndeplinesc condiţia dată în clauza WHERE. Dacă este omisă clauza WHERE, vor fi sterse toate liniile din tabel. „ Exemplu: DELETE FROM ANGAJATI WHERE Nume =‘Ionescu’;

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

27

Constrângeri de integritate (1) „ Constrângerile de integritate (integrity constraints) sunt reguli care se impun pentru ca datele memorate să corespundă cât mai bine celor din realitate: „ se definesc la proiectarea bazei de date „ trebuie să fie respectate de orice stare a acesteia

„ Clasificare după locul unde se definesc: constrângeri de coloana și constrângeri de tabel „ Clasificare după numărul de relații implicate: constrângeri intra-relaţie şi constrângeri inter-relaţii. „ Constrângerile intra-relaţie - reguli care se impun în cadrul unei singure relaţii; sunt de trei categorii: „ Constrângeri de domeniu - condiţii ce se impun valorilor domeniilor atributelor „ Constrângeri de tuplu - condiţii ce se impun tuplurilor unei relaţii prin chei (primare sau secundare) „ Constrângeri impuse prin dependenţe de date (dependenţe funcţionale, multivalorice sau de joncţiune); acestea sunt constrângeri intre valorile atributelor dintr-o relaţie

„ Constrângerile inter-relaţii - reguli care se impun între două sau mai multe relaţii; asigura integritarea referenţială prin intermediul cheilor străine Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

28

Constrângeri de integritate (2) „ Clasificare din punct de vedere al modului de definire și de verificare a respectării constrângerilor: inerente, implicite şi explicite. „ Constrângerile inerente sunt cele ale modelului de date însuşi, care nu trebuie să fie definite deoarece sunt incluse în sistemul de gestiune „ De exemplu: în modelul relaţional constrângerea ca valoarea fiecărui atribut să fie atomică (indivizibilă) este o constrângere inerentă

„ Constrângerile implicite sunt reguli specifice fiecărui sistem de gestiune; acestea se definesc de către proiectant, iar sistemul de gestiune le verifică şi le impune automat „ Exemple: connstrângerile de domeniu, constrângerile de tuplu şi constrângerile de integritate referenţială sunt constrângeri implicite.

„ Constrângerile explicite sunt constrângeri suplimentare, specifice bazei de date respective; proiectantul definește constrângerile explicite precum și procedurile de verificare ale accestora (funcții, proceduri stocate, triggere) „ Exemple: dependenţele de date care nu sunt determinate de cheile relaţiilor

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

29

Constrângeri de domeniu (1) „ Constrângerile de domeniu: constrângerea NOT NULL, constrângerea de valoare implicită (DEFAULT), constrângerea de verificare (CHECK) „ Constrângerea NOT NULL însemna că atributul respectiv nu poate lua valoarea NULL în nici un tuplu al relaţiei. „ Valoarea NULL a unui atribut într-un tuplu semnifică faptul că valoarea acelui atribut nu este cunoscută pentru acel tuplu. Exemple: „ nu se cunoaste deloc data de nastere a unei personalitati istorice; „ nu se cunoaşte valoarea unui atribut în momentul inserarii tuplului, dar aceasta va fi cunoscuta și completată ulterior

„ La crearea unui tabel opţiunea NULL este implicită (nu se specifică nimic), sau se poate introduce explicit; optiunea NOT NULL se introduce explicit. „ Optiunile NULL și NOT NULL se introduc ca și constrângeri de coloana în instructiunea SQL CREATE TABLE. Exemplu: CREATE TABLE ANGAJATI ( Nume varchar(20) NOT NULL, Prenume varchar(20) NOT NULL, DataNasterii date NULL, Functie varchar(20), Salariu numeric); Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

30

Constrângeri de domeniu (2) „ Constrangerea de valoare implicită a unui atribut (DEFAULT): dacă la inserarea unui tuplu nu se specifică valoarea unui atribut, atunci: „ atributul primeşte valoarea implicită (DEFAULT), dacă a fost definit㠄 atributul primeşte valoarea NULL, dacă nu a fost definită valoare implicită, dar sunt admise valori NULL „ se generează o eroare, dacă nu a fost definită o valoare implicită şi nici nu sunt admise valori NULL. Exemplu: CREATE TABLE STUDENTI ( Nume varchar (20) NOT NULL, Prenume varchar (20) NOT NULL, Tara varchar (20) DEFAULT ‘Romania’ ) ;

„ Constrângerea de verificare (CHECK) – pentru verificarea valorilor atributelor printr-o conditie care trebuie sa ia valoarea TRUE. „ Se introduce ca o constrangere de tabel în instructiunea CREATE TABLE: [CONSTRAINT nume_constrangere] CHECK (conditie); Exemplu: CREATE TABLE ANGAJATI ( Nume varchar(20) NOT NULL, Prenume varchar(20) NOT NULL, Salariu numeric, CONSTRAINT Verificare_Salariu CHECK (Salariu >= 1500 ));

„ MySql 5.0 nu face verificarea CHECK, chiar daca admite acest cuvânt cheie Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

31

Constrângeri de tuplu „ O relaţie = mulţime de tupluri Æ tuplurile unei relaţii trebuie să fie distincte (nu pot exista două sau mai multe tupluri identice) „ Pentru ca tuplurile unei relații să fie distincte se folosește câte o cheie primară (primary key) în fiecare relație „ O cheie primară PK a unei relații este un atribut (simplu sau compus) al acelei relații care are proprietatea de unicitate, adică fiecare valoare a cheii primare este unică în acea relație. Aceasta înseamnă că: „ Nu există două tupluri distincte (diferite) care să aibă aceeași valoare a cheii primare (sau combinație de valori) pentru orice stare a relației, adică: ti[PK] ≠ tj[PK] dacă i ≠ j, unde ti și tj sunt 2 tupuri diferite ale relației

„ Proprietatea de unicitate a cheii primare este o constrângere de integritate a tuplurilor: fiecare tuplu poate fi identificat în mod precis și se păstrează integritatea acestuia, dacă se cunoaște valoarea cheii sale primare „ Cheia primară este o constrângere implicită: se definește de proiectant la crearea tabelului și este verificată de SGBD (să nu existe duplicate, etc) „ Cheia primară mai are următoarele restricţii: „ Este ireductibilă: nu există o submulțime proprie nevidă a cheii PK care să aibă proprietatea de unicitate „ Nici o valoare a atributelor cheii primare nu poate fi modificată prin operaţii de actualizare (UPDATE) „ Nu se admit valori de NULL pentru nici unul dintre atributele cheii primare Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

32

Chei primare naturale și artificiale (1) „ Se pot defini chei primare naturale sau chei primare artificile, cu condiția ca acestea să îndeplinească condiția de unicitate „ O cheie primară naturală este un atribut (simplu sau compus) al relației: „ reprezintă o proprietate a tipului de entitate (sau asociere) reprezntat de acea relație „ are în mod natural valori unice: nu există două tupluri cu aceeași valoare a cheii primare, deoarece nu există două entități cu acceași valoare a proprietății respective

„ O cheie primară artificială este un atribut (de obicei simplu) care nu reprezintă o proprietate a tipului de entitate sau asociere reprezentat de relație, ci se adaugă în schema relaţiei special pentru identificarea unică a tuplurilor „ Exemplu: ANGAJATI (IdAngajat, CNP, Nume, Prenume, DataNasterii, Adresa, Functia, Salariu): „ IdAngajat este o cheie primară artificial㠄 Ar putea fi definite și chei primare naturale prin atribute simple sau compuse care au proprietatea de unicitate în anumite condiții: „ atributul simplu {CNP} – valabil numai pentru persoanele din Romania „ atributul compus {Nume, Prenume, DataNasterii, Adresa}

„ Din motive de eficiență a operațiilor de identificare a tuplurilor, se preferă chei primare cu un număr cât mai mic de atribute (atribut simplu) Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

33

Chei primare naturale și artificiale (2) „ Modul de asigurare a unicităţii valorii cheii primare artificiale depinde de sistemul SGBD folosit. De exemplu: „ În Microsoft SQL Server se pot obţine valori unice ale cheii primare folosind parametrul IDENTITY, care asigură incrementarea valorii atributului cheii la introducerea fiecărei linii noi „ În sistemele Oracle se pot genera chei artificiale folosind obiecte SEQUENCE; un obiect SEQUENCE geneaza un numar unic la fiecare apel al metodei NEXTVAL „ În MySQL, se foloseste parametrul AUTO_INCREMENT pentru generarea numerelor unice pentru cheile primare.

„ SGBD-urile interzic introducerea liniilor (tuplurilor) care au valori identice ale cheilor primare

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

34

Definirea cheii primare „ Cheia primară se defineste prin instructiunea CREATE TABLE ca o constrângere de tabel sau ca o constrângere de coloan㠄 Definirea cheii primare ca o constrângere de tabel: [CONSTRAINT nume_constr] PRIMARY KEY (lista_atribute) Exemplu: CREATE TABLE SECTII ( IdSectie int, Nume varchar(50) NOT NULL, Buget numeric, CONSTRAINT PK PRIMARY KEY (IdSectie) );

„ Dacă cheia primară este simplă (formată dintr-un singur atribut), ea se poate specifica și ca o constrângere de coloană; exemplu: CREATE TABLE ANGAJATI ( IdAngajat int PRIMARY KEY AUTO_INCREMENT, Nume varchar(20) NOT NULL, Prenume varchar(20) NOT NULL, DataNasterii Date, Adresa varchar(50), Salariu numeric) ; Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

35

Superchei, chei candidate „ O supercheie (superkey) este o submulţime SK de atribute ale unei relaţii care prezintă proprietatea de unicitate (orice combinaţie de valori ale atributelor supercheii este unică pentru orice stare a relaţiei) „ Dacă se cunoaşte valoarea (combinaţia de valori ale atributelor) supercheii, atunci acel tuplu poate fi identificat în mod unic „ Orice relație are cel puțin o supercheie, care este mulțimea tuturor atributelor sale

„ O cheie candidată (candidate key) este o supercheie ireductibilă: „ Unicitate: nu există două tupluri diferite ale relaţiei care să conţină aceeaşi combinaţie de valori ale atributelor cheii CK; „ Ireductibilitate: nu există nici o submulţime proprie, nevidă a cheii CK care să aibă proprietatea de unicitate

„ O cheie candidată poate fi simplă (un atribut), sau compusă (mai multe atribute) „ Exemplu: ANGAJATI (IdAngajat, CNP, Nume, Prenume, DataNasterii, Adresa, Functia, Salariu) SK1 = {IdAngajat, CNP, Nume, Prenume, DataNasterii, Adresa, Functia, Salariu} SK2 = {CNP, Nume, Prenume, DataNasterii, Adresa}; SK3 = {IdAngajat, CNP} CK1= {Nume, Prenume, DataNasterii, Adresa}; CK2 = {CNP}; CK3 ={IdAngajat} Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

36

Chei candidate, primare și secundare „ Atunci când există mai multe chei candidate (cu proprietățile de unicitate și ireductibilitate), una dintre ele se alege ca şi cheie primară, iar celelalte chei se pot defini ca și chei secundare „ Cheia primară este o cheie candidată aleasă (desemnată) de proiectant la definirea tabelului „ O cheie secundară (alternativă, unică) (secondary, alternate, unique key) este o cheie candidată definită de proiectant „ Cheile secundare se definesc în instrucțiunea CREATE TABLE folosind specificatorul UNIQUE [KEY] în loc de PRIMARY KEY

„ Alegerea cheii primare dintre mai multe chei candidate este arbitrară, dar, din motive de eficiență, se alege cheia cu cel mai mic număr de atribute „ Cheile secundare se deosebesc de cele primare prin: „ Pot fi modificate prin instrucțiuni UPDATE, dacă se respectă proprietatea de unicitate „ Cheile secundare compuse admit valori NULL pentru unele din atributele lor

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

37

Constrângeri inter-relații „ Asocierile (relaționships) 1: N între două mulțimi de entităţi (din modelul Entitate-Asociere) se realizează în modelul relaţional prin chei străine „ Exemplu: Pentru a realiza asocierea 1: N dintre relaţiile SECTII și ANGAJATI, se adaugă în relaţia ANGAJATI cheia străină IdSectie, care reprezintă identificatorul (numărul) secţiei în care lucrează angajatul respectiv: ANGAJATI (IdAngajat, Nume, Prenume, DataNasterii, Adresa, Salariu, IdSectie) SECTII SECTII

1

N

ANGAJATI

Diagrama E-A

IdSectie

Nume

Buget

1

Productie

400000

2

Proiectare

300000

3

Cercetare

200000

4

Documentare

100000

ANGAJATI IdAngajat

Nume

Prenume

DataNasterii

Adresa

Functia

Salariul

IdSectie

1

Ionescu

Ion

1960.01.05

Bucuresti

inginer

4000

1

2

Popa

Petre

1965.02.97

Bucuresti

tehnician

3200

1

3

Carol

Ana

1961.03.06

Bucuresti

secretara

2000

2

4

Marin

Radu

1970.03.98

Bucuresti

inginer

4000

3

Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

38

Cheia străin㠄 Fie două relații R1 și R2, între care exista o asociere cu raportul 1: N. O cheie străină (foreign key) este o submulţime FK de atribute ale relaţiei R2 care referă cheia CK din relaţia R1 şi satisface următoarele condiţii: „ atributele cheii străine FK sunt definite pe domenii compatibile cu cele ale atributelor cheii candidate CK a relaţiei R1 „ valorile atributelor FK într-un tuplu din relaţia R2, fie sunt identice cu valorile atributelor CK ale unui tuplu oarecare din starea curentă a relaţiei R1, fie sunt NULL

„ Două domenii sunt compatibile dacă ele sunt compatibile din punct de vedere al tipului de date și compatibile semantic (are sens să fie comparate) „ În limbajul SQL verificarea domeniilor se rezumă la verificarea tipurilor de date, iar compatibiltatea semantică trebuie să fie asigurată de proiectant

„ Cheia străină reprezintă o constrângere referenţială între cele 2 relații „ Relația referită (R1) – relație părinte, relația care referă (R2) – relație fiu

„ Cheia străină se specifică în comanda CREATE TABLE sau ALTER TABLE: [CONSTRAINT nume_constr] FOREIGN KEY (cheie_străina) REFERENCES relația_referita (cheie_candidata)

„ Exemplu: CREATE TABLE ANGAJATI ( IdAngajat int PRIMARY KEY, Nume varchar(20) NOT NULL, Prenume varchar(20) NOT NULL, IdSecţie int, CONSTRAINT FK FOREIGN KEY (IdSectie) REFERENCES SECTII(IdSectie)); Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

39

Mentinerea integrității referențiale a relațiilor (1) „ Integritatea referenţială (referential integrity) este proprietatea bazei de date prin care orice cheie străină: „ fie are o valoare care se regăseşte printre valorile cheii candidate referite „ fie are valoarea NULL

„ Pentru menținerea integrității referențiale trebuie să fie inpuse restrictii operaţiilor de modificare a stării relaţiilor (INSERT, DELETE, UPDATE) „ Restricţiile care se impun operaţiilor de modificare a relaţiilor depind de rolul relaţiei (relaţie care referă, relaţie referită, sau poate avea ambele roluri) „ Operaţia INSERT: „ Într-o relaţie care nu referă altă relație, inserarea se poate face fără restricţii „ Într-o relaţie care referă (care conţine o cheie străină): SGBD-ul permite introducerea unui tuplu nou numai dacă: (a) valoarea cheii străine a tuplului nou este NULL sau (b) există o valoare a cheii referite egală cu valoarea cheii străine a tuplului nou

„ Operatia DELETE: „ Într-o relație care nu este referită ștergerea se poate face fără restricții „ Într-o relație referită se admite: ştergere restricţionată, ştergere în cascadă, anularea (SET NULL) a cheilor străine care refereau tuplul șters

„ Ştergerea restricţionată interzice ştergerea unui tuplu din relaţia referită dacă acesta este referit de un tuplu din relaţia care o referă Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

40

Mentinerea integrității referențiale a relațiilor (2) „ Ştergerea în cascadă permite ştergerea unui tuplu din relaţia referită; dacă tuplul şters era referit de unul sau mai multe tupluri, atunci se şterg şi acestea din relaţia care o referă; dacă tuplurile şterse din relaţia care referă sunt, la rândul lor referite de alte tupluri din alte relații, atunci trebuie să fie şterse şi acestea, ş.a.m.d.; se execută deci o ştegere în cascad㠄 Operaţia UPDATE este o ştergere urmată de o introducere, deci restricţiile de actualizare reprezintă combinaţia restricţiilor de introducere şi de ştergere „ În limbajul SQL se specifică opţiunile ON DELETE și ON UPDATE constrîngerii de cheie străină; valorile posibile ale acestor opţiuni sunt: „ „ „ „

RESTRICT – ştergerea restricţionată (este valoare implicită) CASCADE – ştergerea în cascadă; SET NULL – anularea cheilor străine care refereau tuplul șters NO ACTION – se admit valori care nu respectă integritatea relațională

„ Exemplu: CREATE TABLE ANGAJATI ( IdAngajat int PRIMARY KEY, Nume varchar (20) NOT NULL, ........................ Sectie int, CONSTRAINT FK FOREIGN KEY (Sectie) REFERENCES SECTII (IdSectii) , ON DELETE CASCADE ON UPDATE RESTRICT); Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

41

Indexarea relațiilor (1) „ Timpul de execuţie a operatiilor asupra datelor din relații depinde de modul de reprezentare a mulţimii de elemente (tupluri) ale relaţiilor „ Operaţia de căutare a unui element într-o mulţime se execută mai rapid dacă elementele mulţimii sunt reprezentate printr-o colecţie ordonată, cum sunt liste, arbori, tabele de dispersie (hash table). De exemplu: „ Timpul de căutare a unui element într-o mulțime neordonată de N elemente este proportional cu N: TC = k1 * N = O(N) „ Timpul de căutare al unui element memorat într-o structură arbore binar de căutare ordonat după valoarea etichetei (cheii) de ordonare este TC = k2* log N = O(log N)

„ Un arbore binar ordonat complet cu d niveluri: pe nivelul 0 are 20 = 1 nod pe nivelul 1 are 21 = 2 noduri pe nivelul j are 2j noduri

Nivelul 0

4

Nr. total noduri N = 20 + 21 + … 2j + 2d-1 = 2d – 1 Nivelul 2 d = log (N + 1)

6

2

Nivelul 1 1

3

5

7

Pentru căutare se parcurg max d pași, deci timpul de căutare TC = k2* log N = O(log N) Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

42

Indexarea relațiilor (2) „ Rezultă că, deşi o relaţie nu presupune ordonarea tuplurilor sale, pentru accelerarea operaţiei de căutare (SELECT) a unui tuplu se folosesc colecţii ordonate „ Și celelate operații (INSERT, UPDATE, DELETE) se execută mai rapid în colecții ordonate „ Pentru inserarea unui tuplu se verifică mai întâi să nu existe deja un tuplu cu aceeași valoare a cheii „ Pentru modificarea unui tuplu se caută mai întâi tuplul dorit, apoi se fac modificările „ Pentru ștergere se caută mai întâi tuplul dorit și apoi se șterge

„ Un index al unei relaţii este o structură auxiliară, memorată în baza de date, care permite accesul rapid la tuplurile relaţiei prin ordonarea acestora „ Structuri folosite în indexare: arbori binari de căutare, arbori BTREE, arbori RTREE, tabele de dispersie (HASH) etc. „ Exista două categorii de indexuri ale unei relații: „ un index primar, care determină localizarea tuplurilor în fişierele bazei de date „ zero, unul sau mai multe indexuri secundare, care nu modifică localizarea tuplurilor, dar sunt folosiţi pentru regăsirea rapidă a tuplurilor după valorile unor atribute Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

43

Indexul primar (1) „ Indexul primar (primary index) se defineşte pe cheia primară a relaţiei „ Fiecare element al indexului primar corespunde unui tuplu al relației și elementele sunt ordonate după valoarea cheii primară PK „ De exemplu, pentru o structură arbore binar ordonat a indexului primar al unei relații cu ckeia primară PK și atributele (A, B, C, ...), un element (nod) Ni este memorat la adresa Li pe hard-disk și conține: „ Valoarea cheii primare a tuplului (pki), care este și eticheta de ordonare a arborelui „ Valorile celorlalte atribute ale tuplului (ai, bi, ci, ...) „ Adresele fiilor (Lj, Lk) (locațiile de memorare pe hard-disk a nodurilor fii)

(Li) (pki) (ai, bi, ci, ...) (Lj) (Lk)

(4)(‘Marin’, ….)

(2)(‘Popa’, ….) (Lj)

(Lk) (1)(‘Ionescu’,..)

Prof. Felicia Ionescu

(6)(‘Ionescu’,….)

(3)(‘Carol’,...)

Cap. 2 - Baze de date relationale

(5)(‘Ene’,….)

(7)(‘Dobre’,….) 44

Indexul primar (2) „ Structura indexului primar este memorată împreună cu tuplurile relației „ Operaţiile de interogare care se fac după indexul primar (cheia primară) se execută eficient, fiind o căutare într-o mulțime ordonată după acea valoare „ Exemplu: “Care sunt funcția și salariul angajatului cu cheia primara 3?” Se caută nodul arborelui care are valoarea etichetei de ordonare (care este și cheia primară a relației) egală cu valoarea dată (3) După găsirea nodului se extrag valorile atributelor tuplului memorat în acel nod Sunt necesari maximum d (log N) pași de căutare (N este nr total de tupluri ale relației)

„ Operatiile de interogare care se fac după valoarea altor atribute (decât indexul primar) se execută mult mai ineficient, fiind o căutare într-o mulțime neordonată după acea valoare „ Exemplu: “Care sunt funcția și salariul angajatului cu numele ‘Dobre’ ?” Pentru căutare se vor parcurge pe rând toate tuplurile relației (memorate în nodurile arborelui - există astfel de algoritmi de parcurgere) pentru a găsi tuplul (sau tuplurile) cu valoarea atributului Nume egală cu ‘Dobre’ Sunt necesari maximum N pași (N este nr total de tupluri ale relației)

„ Pentru rezolvarea mai eficientă a unor astfel de interogări se definesc indexuri secundare pe acele atribute care intervin în clauza WHERE din interogări Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

45

Indexuri secundare (1) „ Un index secundar pe un atribut al unei relaţii (secondary index) este o structură ordonată după valoarea acelui atribut; un element al unui index secundar conține: „ valoarea atributului indexat (care este etichetă de ordonare) „ adresa (sau adresele) tuplurilor care conțin acea valoare a atributului respectiv

„ Sunt două categorii de indexuri secundare: unice (UNIQUE) și “normale” „ Un index secundar UNIQUE este definit pe un atribut A (simplu sau compus) al relației care ia valori unice (cum este o cheie unică - secundară sau alternativă) „ Un element (nod) al indexului este compus din valoarea ai atributului indexat A și adresa (Li) a unui singur tuplu care are acea valoare a atributului A „ Dacă relația are N tupluri, indexul va avea M = N elemente

„ Index secundar “normal” (care nu este unic - nu are o denumire specifică) este definit pe un atribut A care nu ia valori unice (nu este cheie unică) „ Un element (nod) al indexului este compus din valoarea ai a atributului indexat A și lista (Li1 , Li2 , …) a adreselor (pe hard-disk) a tuplurilor ti1, ti2, … care au valoarea ai a atributului A „ Dacă relația are N tupluri, indexul va avea M ≤ N elemente

„ Pentru o structură arbore binar a indexului, fiecare nod mai conține și adresele nodurilor fii (stânga, dreapta) (nereprezentate în figura următoare) Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

46

Indexuri secundare (2) „ Exemplu: indexul secundar (cu structură arbore binar) definit pe atributul Nume al relației ANGAJATI, al cărei index primar este cel dat în figura precedent㠄 La interogarea “Care sunt functia și salariul angajaților cu numele ‘Dobre’ ?” se parcurge indexul secundar definit pe atributul Nume și se află adresa unui singur tuplu (L7) „ La interogarea “Care sunt functia și salariul angajatilor cu numele ‘Ionescu’ ?” se parcurge indexul secundar definit pe atributul Nume și se află adresele tuplurilor (L1 și L6) care au valoarea atributului Nume egală cu ‘Ionescu’ „ Dacă indexul are o structură arbore binar ordonat, se vor executa max (log N) pași

„ Un index secundar nu modifică adresa de memorare a unui tuplu (care se află în indexul primar), dar conţine informaţii pentru găsirea rapidă a unui tuplu după valoarea acestui index (‘Ionescu’) (L1, L6)

(‘Dobre’) (L7)

(‘Carol’) (L3) Prof. Felicia Ionescu

(‘Ene’) (L5) Cap. 2 - Baze de date relationale

(‘Marin’) (L4)

(‘Popa’) (L2) 47

Indexuri secundare (3) „ Un index secundar se poate crea cu comanda CREATE TABLE (ca o costrângere de tabel), cu ALTER TABLE sau cu CREATE INDEX; ex.: CREATE [optiuni] INDEX nume_index ON nume_tabel (lista_atribute_index); Una din opţiunile care se pot introduce în CREATE INDEX este UNIQUE

„ În general, sistemele SGBD adaugă: „ Un index secundar UNIQUE pentru fiecare cheie candidată (definită prin constrângerea UNIQUE KEY) „ Un index secundar normal pentru fiecare cheie străină; un astfel de index secundar ajută la găsirea rapidă a tuturor tuplurilor asociate cu o valoare a cheii străine (“Care sunt angajații care lucrează în secția cu numărul (identificatorul IdSectie) 1?”

„ În sistemele SGBD avansate (obiect-relaționale), pot exista și indexuri secundare speciale, cum sunt „ Indexuri spațiale (indexarea obiectelor reprezentate în spașiul bi sau tridimensional) „ Indexuri de context (indexarea textelor) „ Indexuri XML (indexarea documentelor XML)

„ Indexurile secundare au avantaje și dezavantaje: „ Avantaje: accelerează operațiile de interogare care se fac după valoarea indexului „ Dezavantaje: ocupă spațiu de memorie și consumă timp la actualizarea relațiilor

„ În general, se recomandă utilizarea unui număr cât mai mic de indexuri secundare, definite pe atributele care intervin cel mai frecvent în interogări Prof. Felicia Ionescu

Cap. 2 - Baze de date relationale

48

Capitolul 3: Interogarea bazelor de date „ Limbaje de interogare „ Algebra relationala si calculul relational „ Operatiile pe multimi ale algebrei relationale „ „ „ „

Reuniunea Intersecția Diferenta Produsul Cartesian

„ Operatiile speciale ale algebrei relationale „ „ „ „

Selectia Proiectia Jonctiunea Diviziunea

„ Interogarea bazelor de date „ Interogarea intr-o singura relatie „ Interogarea in doua sau mai multe relatii

Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

1

Limbaje de interogare „ Interogarea (query): operaţia prin care se obţin informatiile dorite dintr-o bază de date, selectate conform unui anumit criteriu (condiţie); „ Limbaje de interogare: abstracte si “concrete” (reale - implementari in diferite SGBD-uri) „ Limbaje de interogare abstracte: algebra relationala si calculul relational „ Algebra relationala (relational algebra) - constă dintr-o mulţime de operaţii care au ca operanzi relaţii, iar rezultatul este tot o relaţie „ Calculul relaţional (relational calculus) - bazat pe calculul predicatelor exprimă o interogare definind rezultatul dorit ca expresie de calcul relaţional „ Calculul relational al tuplurilor foloseste variabile de tuplu (variabile definite pe mulţimea tuplurilor unei relaţii) „ Calculul relational al domeniilor foloseste variabile de domeniu (variabile definite pe domenii de definiţie ale atributelor) „ Cele trei limbaje formale sunt echivalente din punct de vedere al interogarilor „ Limbajele de interogare reale sunt definite pe baza unuia sau altuia din limbajele de interogare abstracte, sau pe o combinaţie a acestora. „ De exemplu, limbajul SQL2 este în cea mai mare parte bazat pe algebra relaţională, dar mai conţine şi construcţii derivate din calculul relaţional. Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

2

Algebra relațional㠄 Algebra relaţională (relational algebra) - interogările sunt expresii compuse din operatii care au ca operanzi relatii si rezultatul este o relatie „ Operatiile algebrei relationale: operatii pe multimi si operatii speciale, la care se adauga operatia de redenumire (rename) a atributelor (E.Codd) „ Operatiile relationale pe multimi acţionează asupra relaţiilor văzute ca mulţimi (de tupluri), fără a lua în consideraţie compoziţia fiecărui tuplu; acestea sunt: „ „ „ „

Reuniunea Intersecţia Diferenţa Produsul cartezian

„ Operaţiile relaţionale speciale iau în consideraţie compoziţia tuplurilor, formate din valori ale atributelor relaţiilor; acestea sunt: „ „ „ „

Restricţia Proiecţia Joncţiunea Diviziunea

„ Proprietatea de închidere: operanzii (unul sau doi operanzi) sunt relații, rezultatul este o relaţie; această proprietate permite operaţii imbricate: proiecţia unei joncţiuni etc. Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

3

Operația de reuniune „ Reuniunea (union) a două relaţii compatibile r(R) şi s(S): q = r ∪ s = { t | t ∈ r or t ∈ s} „ Pentru ca r si s sa fie compatibile, trebuie ca: „ r si s să aiba acelasi grad (acelasi numar de atribute) „ Atributele corespondente (în ordine pozitională) să fie compatibile

„ Tuplurile care aparţin ambelor relaţii se introduc în relaţia rezultat o singură dată (nu se duplică) „ Relatia rezultat are un numar de tupluri (cardinalitatea) mai mic sau egal cu suma numerelor de tupluri ale celor doi operanzi „ Exemplu: A

B

A

B

A

B

α

1

α

2

α

1

α

2

β

3

α

2

β

1

β

1

β

3

s

r

r∪s Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

4

Operațiile de intersecție și diferenț㠄 Intersectia (set-intersection) a două relaţii compatibile r(R) şi s(S): q = r ∩ s = { t | t ∈ r and t ∈ s} Exemplu: A

α α β

B

A

α β

1 2 1

B

A

B

2 3

α

2

s

r∩s

r „ Diferența (set-difference) a două relaţii compatibile r(R) şi s(S): q = r - s = { t | t ∈ r and t ∉ s} „ Exemplu:

A α α β

B 1 2 1

A

B

α β

2 3

A α β

B 1 1

s

r-s r „ Reuniunea si intersectia sunt comutative si asociative (r ∪ s = s ∪ r ; r ∪ (s ∪ t) = (r ∪ s) ∪ t); diferenta nu este nici nici comutativa, nici asociativa Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

5

Operatia de produs Cartesian „ Produsul Cartesian (Cartesian-Product) a două relaţii r(R) şi s(S): q = r x s = { tp | t ∈ r and p ∈ s}, Q = R ∪ S „ Se presupune că multimile R si S sunt disjuncte, adica R ∩ S = ∅ „ Daca atributele din R si S nu sunt disjuncte, atunci (unele): „ se pot redenumi (RENAME nume_atribut AS noul_nume_atribut) sau „ se pot califica cu numele relatiei careia ii apartin (folosind operatorul “punct”)

„ Tuplurile relaţiei rezultat se obtin prin concatenarea valorilor atributelor fiecărui tuplu din prima relaţie cu valorile atributelor tuturor tuplurilor din a doua relaţie „ Relația rezultată are numărul de tupluri (cardinalitatea) egal cu produsul numarului de tupluri ale relatiilor operand A B C D E „ Exemplu: C D E A B α 1 α 10 a α 10 a α 1 β 10 a α 1 β 10 a α 1 β 20 b β 2 β 20 b α 1 γ 10 b r γ 10 b β 2 α 10 a β 2 β 10 a s β 2 β 20 b β 2 γ 10 b rxs Prof. Felicia Ionescu Cap. 3 - Interogarea bazelor de 6 date

Exprimarea operatiilor pe multimi in SQL (1) „ Reuniunea: SELECT lista_coloane1 FROM tabel1 [WHERE condiţie1] UNION SELECT lista_coloane2 FROM tabel2 [WHERE condiţie2];

Exemplu (MySQL, Intreprindere): SELECT Nume, Prenume, Adresa FROM FURNIZORI UNION SELECT Nume, Prenume, Adresa FROM CLIENTI; Afiseaza numele tuturor furnizorilor si al clientilor, precum si adresa acestora

„ Intersectia: SELECT lista_coloane1 FROM tabel1 [WHERE condiţie1] INTERSECT SELECT lista_coloane2 FROM tabel2 [WHERE condiţie2];

„ Diferenta: SELECT lista_coloane1 FROM tabel1 [WHERE condiţie1] MINUS SELECT lista_coloane2 FROM tabel2 [WHERE condiţie2];

Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

7

Exprimarea operatiilor pe multimi in SQL (2) „ Produsul Cartesian: SELECT * from R, S; SELECT lista_col_R, lista_col_S from R, S; Exemplu (MySQL, Intreprindere): SELECT * FROM ANGAJATI, SECTII; SELECT IdAngajat, Nume, Prenume, DataNasterii, Adresa, Functia, Salariu, ANGAJATI.IdSectie, SECTII.IdSectie, Denumire, Buget FROM ANGAJATI, SECTII;

„ Produsul Cartesian este implementat in toate SGBD-urile (instructiunea SQL SELECT) „ In sistemul Oracle sunt implementate toate operatiile pe multimi „ In alte SGBD-uri nu sunt implementate toate operaţiile pe mulţimi; in SQL Server 2000 si in MySQL 5.0 nu sunt implementate operaţiile INTERSECT şi MINUS Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

8

Operația de selecție „ Selecța (sau restricția – select, restriction) într-o relatie r(R) - definita astfel: σp(r) = {t | t ∈ r and p(t)} unde p, predicatul selectiei, este o expresie logică compusă din termeni conectati prin operatorii and, or‚ not (și, eventual, paranteze)

„ Fiecare termen este o valoare logică obținută ca rezultat al unei operații de comparație de forma: op sau op , unde op este un operator de comparatie aritmetic (=, ≠, >, ≥. 10000000; Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

9

Operatia de proiecție „ Proiectia (project) pe atributele A1, A2, .. Ak intr-o relatie r(R) se notează: Π A1, A2, …Ak (r), unde A1 ∈R, A2 ∈R, …Ak ∈R „ Rezultatul este o relatie cu k atribute, cele din lista data „ Daca {A1, A2, …Ak} nu contine o supercheie, pot sa apara tupluri duplicat; teoretic, tuplurile duplicat se elimina, dat fiind ca rezultatul este o multime „ Exemplu:

r

A

B

C

A

C

A

C

α

10

1

α

1

α

1

α

20

1

α

1

β

1

β

30

1

β

1

β

2

β

40

2

β

2

=

∏A,C (r)

„ In limbajul SQL proiectia se exprima astfel: SELECT DISTINCT A1, A2, …Ak FROM R Daca nu se introduce parametrul DISTINCT, nu se elimina tuplurile duplicat

„ Exemplu (MySQL, WORLD): SELECT DISTINCT CountryCode FROM City; Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

10

Operația de joncțiune naturală (1) „ Joncțiunea naturală (natural join) combină tuplurile din doua relatii „ Fie multimile de atribute: A = {A1,A2,...Am} , B= {B1,B2,...Bn}, C={C1,C2,…Ck} si doua relatii r(R) si s(S), unde: „ R ={A, B}, S = {B, C} „ deci atributele R ∩ S = B = {B1, B2,...Bn} sunt comune celor două relaţii

„ Joncţiunea naturală este o relatie q = r  s, care se obţine în felul următor: „ se calculează produsul cartesian al celor doua relatii: p = r x s, P = {A, R.B, S.B, C}; „ din tuplurile produsului cartesian se selecteza acele tupluri care au valori egale pentru atributele comune (B1, B2,...Bn): R.B = S.B, adică R.B1=S.B1, R.B2=S.B2,.. „ se face proiectia rezultatului pe multimea de atribute R ∪ S = {A, B, C}

„ Schema relatiei rezultat este Q = R ∪ S = {A, B, C} q = r  s = ΠA,B,C σ (r.B1=s.B1 AND r.B2=s.B2 … AND r.Bn = s.Bn) (r x s) „ Atributele comune R.B si S.B trebuie să fie compatibile în cele doua relatii; dacă sunt compatibile, ele se consideră identice chiar dacă au denumiri diferite, si în reuniunea atributelor R ∪ S se introduc o singură dat㠄 Cazul cel mai frecvent de jonctiune naturala: intre doua relatii asociate (1: N), atributul comun fiind cheia straină – cheia primară (candidată) referită Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

11

Operatia de jonctiune naturala (2) „ Exemplul 1: r  s = ΠA,B,C,D,E σ (r.D = s.D ) (r x s) A

B

C

D

D

E

A

B

α β γ δ ∈

α β γ α δ

1 2 4 1 2

C

D

E

a α a α b β a α b β r  s s r „ In SQL trebuie sa fie introduse explicit lista atributelor rezultatului si conditiile de egalitate ale atributelor comune:

α β γ α δ

1 2 4 1 2

α γ β γ β

a a b a b

a b c d e

α γ β γ β

SELECT A,B,C,R.D,E FROM R, S WHERE R.D = S.D;

„ Exemplul 2: ANGAJATI  SECTII; cheia straina: ANGAJATI.IdSectie SELECT IdAngajat, ANGAJATI.Nume, Prenume, DataNasterii, Adresa, Salariu, ANGAJATI.IdSectie, SECTII.Nume, Buget FROM ANGAJATI, SECTII WHERE ANGAJATI.IdSectie=SECTII.IdSectie;

„ Exemplul 3:(MySQL-WORLD) city  country; cheia straina: city.countryCode SELECT ID, city.Name Oras, CountryCode 'Cod Tara', city.Population, country.Name Tara, Continent from city, country where city.countryCode=country.CODE order by country.Name; Daca nu se afiseaza toate atributele joncţiunii, înseamna ca s-a combinat cu o proiecţie Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

12

Joncţiuni interne şi externe „ Joncţiunea naturală se mai numeşte şi joncţiune internă şi se mai poate exprima in SQL cu cuvintele cheie INNER JOIN „ Exemplu de joncţiune (combinată cu o proiecţie si o selectie)(MySQL – world) SELECT city.Name Oras, Code 'Cod Tara', country.Name Tara, Continent FROM city INNER JOIN country ON CountryCode=Code WHERE Continent='Antarctica' OR Continent = 'Europe' ORDER BY Continent;

„ Joncţiunea externă introduce în plus toate liniile care exită în prima relaţie (pentru LEFT OUTER JOIN) sau în cea de-a doua relaţie (pentru RIGHT OUTER JOIN) şi pentru care nu există linii în cealălaltă relaţie care să îndeplinească condiţia de join; exemplu: SELECT city.Name Oras, Code 'Cod Tara', country.Name Tara, Continent FROM city RIGHT OUTER JOIN country ON CountryCode=Code WHERE Continent='Antarctica' OR Continent = 'Europe' ORDER BY Continent; Se vor afişa si ţările care nu au nici un oras înscris în tabelul city.

Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

13

Operaţia de diviziune „ Fie relaţiile r(R) si s(S), unde: ● R = {A, B} unde A={A1,A2,..Am}, B={ B1,B2,..Bn} ● S = {B}

„ Relaţia q = r ÷ s are schema Q = R – S = {A} si: r ÷ s = { t | t ∈ ∏ R-S (r) ∧ ∀ u ∈ s ( tu ∈ r ) } unde tu inseamna concatenarea tuplurilor t si u

„ În limbajul SQL, diviziunea se exprimă printr-o instrucţiune SELECT, introducând explicit toate conditiile impuse valorilor atributelor „ Exemplu: A B A B

α α α β β δ δ

1 2 3 1 2 1 3

1 2

α β

s

r÷s

r Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

14

Concluzii: operatiile algebrei relationale „ Algebra relaţională este o colecţie de operaţii asupra relaţiilor „ Cele opt operaţii propuse de E.F.Codd nu constituie o mulţime minimă de operaţii ale algebrei relaţionale „ Mulţimea minimă de operaţii ale algebrei relaţionale consta din cinci operaţii primitive, pe baza cărora se poate construi orice expresie de algebra relaţionala: „ „ „ „ „

Reuniunea Diferenţa Produsul Cartesian Restricţia (selectia) Proiecţia

„ Celelalte operaţii se pot exprima prin intermediul acestora: „ Intersecţia se poate exprima prin expresia: R ∩ S = R – (R – S); „ Joncţiunea este o proiecţie a unei restricţii a produsului cartezian al relaţiilor; „ Diviziunea este o proiecţie a unei restricţii asupra relaţiei deîmpărţit

„ Si celelalte trei operaţii sunt deosebit de utile în formularea interogărilor, astfel încât algebra relaţională a păstrat toate cele opt operaţii propuse de E.F.Codd, la care s-a adăugat operaţia de redenumire a atributelor Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

15

Formularea interogarilor „ Interogarea este operatia prin care se obtin informaţiile dorite (care indeplinesc o anumita conditie) dintr-o bază de date. O interogare: ● se formuleaza mai intai în limbaj natural, ● apoi se exprima într-un limbaj abstract de interogare (algebra relaţională sau calculul relaţional), ● se transpune în limbajul de interogare al SGBD-ului folosit (ex., limbajul SQL), ● iar aplicatia client transmite SGBD-ului instructiunea (sau instructiunile) obtinute

„ Sistemul SGBD prelucreaza programul interogarii în mai multe faze: ● ● ● ●

analiza lexicală, sintactică şi semantică optimizarea interogarii generarea codului executia si returnarea rezultatului

„ În algebra relaţională o interogare se formulează printr-o expresie care defineste următoarele elemente: ● Lista atributelor relaţiei rezultat, care se numesc atribute de proiecţie; ● Lista relaţiilor din care se extrag informaţiile ● Condiţiile pe care trebuie să le îndeplinească tuplurile relaţiei rezultat.

„ Sunt posibile două situaţii: ● interogări care se rezolvă în cadrul unei singure relaţii ● interogări care se rezolvă folosind două sau mai multe relaţii ale bazei de date Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

16

Interogări într-o singură relaţie „ Interogare in relatia r(R): ● Expresia de algebra relationala: q = ∏ lista_atribute σ p(r) ● Instructiunea SQL: SELECT lista_atribute FROM R WHERE p;

„ Exemplul 1: Fie relaţia ANGAJATI şi interogarea: „Care sunt numele şi prenumele angajaţilor care au un salariu mai mare sau egal cu 2000?”. ● Expresia de algebră relaţională: q = ∏ Nume, Prenume σ Salariu >= 2000 (ANGAJATI) ● Instrucţiunea SQL: ● SELECT Nume, Prenume FROM ANGAJATI WHERE Salariu >= 2000;

„ Exemplul 2: (MySQL - WORLD): “Care sunt numele si populatia oraselor din tara cu codul ‘ROM’ ?” ● Expresia de algebră relaţională: q = ∏ Name, Population σ CountryCode=‘ROM’ (city) ● Instructiunea SQL: ● SELECT Name, Population FROM city WHERE CountryCode=‘ROM';

„ Exemplul 3: Fie relaţia ANGAJATI şi interogarea: „Care sunt numele, prenumele si adresa angajaţilor care lucreaza in sectia numarul 1?”. ● Expresia de algebră relaţională: q = ∏ Nume, Prenume, Adresa σ IdSectie = 1 (ANGAJATI) ● Instructiunea SQL: ● SELECT Nume, Prenume, Adresa FROM ANGAJATI WHERE IdSectie=1; Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

17

Interogări în două sau mai multe relaţii „ Daca atributele de proiecţie şi atributele din condiţia de interogare nu aparţin unei singure relaţii, pentru rezolvarea interogării trebuie să fie folosite toate acele relaţiile care, împreună, conţin atributele şi asocierile necesare „ Conceptual, o astfel de interogare se rezolvă astfel: ● se construieste mai întâi o relaţie care să conţină toate atributele implicate prin combinarea relaţiilor necesare, folosind operaţii de produs cartezian sau joncţiuni; ● in relatia obtinuta se aplica o selectie (restrictie) (cu condiţia de interogare p); ● apoi se face proiecţia (pe atributele de proiecţie).

„ Expresia generala de algebra relationala a interogarii este: q = Πlista_atribute σp(r x s x t...) „ Daca intre relatiile din produsul cartesian exista atribute comune care trebuie sa aiba valori egale (de regula, perechile cheie străină - cheie candidata) atunci se pot face operaţii de joncţiune: q = Πlista_atribute σp1 AND conditii-join(r x s x t...) = Πlista_atribute σp1 (r  s  t...)

„ O interogare poate conţine una sau mai multe subinterogări „ In limbajul SQL, o interogare se exprima prin instructiuni SELECT in care: „ Clauza WHERE combina atat conditiile impuse valorilor atributelor cat si conditiile de jonctiuni „ Jonctiunile se pot specifica şi în clauza FROM (cu INNER JOIN, OUTER JOIN) Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

18

Exemplu: interogare în două relaţii „ Fie interogarea: Care sunt numele, prenumele, funcţia, salariul şi denumirea secţiei în care lucrează angajaţii? „ Expresia de algebră relaţională este: q = ∏ Nume, Prenume,Salariu, Denumire (ANGAJATI  SECTII) „ Instructiunea SQL corespunzatoare acestei interogări: SELECT Nume, Prenume, Salariul, Denumire FROM ANGAJATI, SECTII WHERE SECTII.IdSectie = ANGAJATI.IdSectie

Se efectueaza o “navigare” în baza de date, pe atributul comun (IdSectie) ANGAJATI IdAngajat

Nume

Prenume

DataNasterii

Adresa

Salariu

IdSectie

SECTII Buget

Denumire IdSectie

„ Fie interogarea: Care sunt numele, prenumele, funcţia şi salariul angajaţilor care lucrează în secţia cu denumirea ‘Productie’? q = ∏ Nume, Prenume, Functia, Salariu σDenumire= ‘Productie’ (ANGAJATI  SECTII) SELECT Nume, Prenume, Functia, Salariu FROM ANGAJATI, SECTII WHERE SECTII.IdSectie = ANGAJATI.IdSectie AND Denumire = ‘Productie’; Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

19

Exemplu: interogare in trei relatii (1) „ Fie urmatoarele relatii asociate din baza de date SAKILA (MySQL): „ FILM (film_id, title, description, release_year, ....) „ ACTOR (actor_id, first_name, last_name, last_update) „ FILM_ACTOR (film_id, actor_id, last_update) FILM

1

N

FILM_ACTOR

N

1

ACTOR

„ Interogarea: “În ce filme au jucat fiecare din actorii din baza de date sakila ?” q = ∏ first_name, last_name, title (film  film_actor  actor) „ Instructiunea SQL: SELECT first_name, last_name, title FROM FILM, FILM_ACTOR, ACTOR WHERE FILM.film_id = FILM_ACTOR.film_id AND ACTOR.actor_id = FILM_ACTOR.actor_id ORDER BY FILM.film_id;

„ Se poate folosi şi sintaxa INNER JOIN: SELECT first_name, last_name, title FROM (FILM INNER JOIN FILM_ACTOR ON FILM.film_id=FILM_ACTOR.film_id) INNER JOIN ACTOR ON ACTOR.actor_id = FILM_ACTOR.actor_id ORDER BY.... ; Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

20

Exemplu: interogare in trei relatii (2)

Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

21

Subinterogări „ Subinterogările sunt operaţii care determină diferite date (valori scalare, tabele rezultat, număr de elemete etc.) folosite în interogarea de baz㠄 Subinterogările pot conţine la rândul lor alte subinterogări „ Exemplul 1: Care sunt angajaţii (nume, prenume, adresa) care lucrează în aceeaşi secţie cu angajatul cu numele Ionescu şi prenumele Ion? „ Se determină printr-o subinterogare în ce secţie lucrează angajaul dat „ Se selectează toţi angajaţii din acea secţie: SELECT Nume, Prenume, Adresa FROM ANGAJATI WHERE IdSectie = (SELECT IdSectie FROM ANGAJATI WHERE Nume = 'Ionescu' AND Prenume = 'Ion');

„ Exemplul 2: Care sunt numele, prenumele, denumirea secţiei şi salariul angajaţilor care au salariul egal cu salariul maxim pe una din secţii: „ Se determină printr-o subinterogare tabelul cu valori maxime ale salariului în fiecare secţie „ Se selecteză angajaţii care au salariul în mulţimea salariilor maxime pe sectii: SELECT Nume, Prenume, Salariul, Denumire FROM ANGAJATI INNER JOIN SECTII ON ANGAJATI.IdSectie=Sectii.IdSectie WHERE Salariul IN (SELECT MAX(Salariul) FROM ANGAJATI Group By IdSectie); Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

22

„

Prof. Felicia Ionescu

Cap. 3 - Interogarea bazelor de date

23

Capitolul 4: Dezvoltarea sistemelor de baze de date Fazele de dezvoltare a bazelor de date „ Colectarea si analiza cerintelor „ Proiectarea bazelor de date ● ● ● ●

Proiectarea conceptuala a bazelor de date Alegerea unui SGBD Proiectarea logica a bazelor de date Proiectarea fizica a bazelor de date

„ Implementarea bazelor de date

Dezvoltarea aplicatiilor de baze de date „ Limbaje procedurale de extensie a limbajului SQL ● Limbajul Transact-SQL ● Cursoare, proceduri stocate, functii, triggere

„ Limbajul SQL integrat (Embeded SQL) „ Interfete de programare a aplicatiilor de baze de date ● Interfata ODBC ● Interfata JDBC Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

1

Dezvoltarea sistemelor de baze de date (1) „ Sistemul informatic (information system) al unei organizatii include toate resursele acelei organizaţii care sunt implicate în colectarea, administrarea, utilizarea şi diseminarea informaţiilor „ Sistemele informatice: ● Pana in anii 1970 erau sisteme de fişiere (pe disc sau bandă magnetică) ● Actual se folosesc sisteme de baze de date, care permit gestionarea unor volume de date mari într-un timp redus, cu protecţia si securitatea datelor

„ Fazele de dezvoltare a sistemelor de baze de date: ● Analiza şi definirea sistemului: definirea scopului sistemului de baze de date, a utilizatorilor şi a aplicaţiilor acestuia ● Proiectarea sistemului: în această etapă se realizează proiectul logic şi proiectul fizic al sistemului, pentru un anumit SGBD ales ● Implementarea: este etapa în care se scriu definiţiile obiectelor bazei de date (tabele, vederi, etc.) şi se implementează aplicaţiile software ● Testarea şi validarea: noul sistem de baze de date este testat şi validat cât mai riguros posibil

„ În mod tipic, dezvoltarea unui sistem de baze de date constă din: ● dezvoltarea structurii si a continutului bazei de date ● dezvoltarea modulelor de prelucrare a datelor Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

2

Dezvoltarea sistemelor de baze de date (2) „ Fazele importante de dezvoltare a sistemelor de baze de date sunt: Faza 1: Colectarea şi analiza cerinţelor Faza 2: Proiectare conceptuală

Cerinţe de date

Proiectarea schemei conceptuale şi a schemelor conceptuale externe (independente de SGBD)

Cerinţe de prelucrare Proiectarea conceptuală a tranzacţiilor (indep. de SGBD)

Faza 3: Alegerea unui SGBD Faza 4: Proiectare logică

Proiectarea schemei logice şi a schemelor logice externe (dependente de SGBD)

Faza 5: Proiectare fizică

Proiectarea schemei interne

Faza 6: Implementare

Faza 7: Testare si validare Prof. Felicia Ionescu

Instrucţiuni de descriere a datelor

Testarea datelor Cap. 4 - Dezvoltarea sistemelor de baze de date

Proiectarea tranzacţiilor (dependente de SGBD)

Implementarea tranzacţiilor

Testarea tranzactiilor 3

Colectarea si analiza cerintelor „ Înainte de a se proiecta efectiv o bază de date (in cadrul unui sistem informatic – sistem de baze de date), este necesar să se cunoască: „ ce rezultate se aşteaptă utilizatorii potenţiali să obţină de la baza de date respectiv㠄 ce informaţii primare sunt disponibile pentru acestea „ ce aplicaţii se vor executa (aplicaţii de gestiune a stocurilor, aplicaţii contabile, aplicaţii de urmărire a consumurilor, aplicaţii de salarizare, etc.).

„ Toate acestea sunt informaţii slab structurate, în general în limbaj natural, pe baza cărora se pot construi diagrame, tabele, grafice etc., manual sau folosind diferite instrumente software de proiectare „ Dar din aceste informatii trebuie sa fie extrase date precise de proiectare a bazelor de date si a aplicatiilor „ Această fază este puternic consumatoare de timp, dar este crucială pentru succesul sistemului informatic

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

4

Proiectarea conceptuală a bazelor de date „ Proiectarea conceptuală a bazei de date: „ Proiectarea schemei conceptuale a bazei de date „ Proiectarea schemelor conceptuale externe (vederi ale urilizatorilor) „ Proiectarea conceptuală a tranzactiilor

„ Proiectul conceptual este independent de modelul de date și de SGBD și reprezintă o descriere principială și stabilă a bazei de date, care poate fi utilizată pentru particularizarea pentru orice model de date sau SGBD „ Moduri de proiectare conceptuală: „ Proiectare descendenta (up-bottom) : se definește diagrama E-A, pe baza tipurilor de entitati si a asocierilor dintre acestea „ Proiectare ascendenta (bottom-up): se porneste de la o schemă conceptuală universală (care conține toate atributele din baza de date), care se rafinează (se împarte în relații)

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

5

Exemplu: proiectarea conceptuală a unei baze de date „ Baza de date INTREPRINDERE cu multimile de entitati puternice: ● ● ● ● ● ●

SECTII(Nume,Buget) ANGAJATI(Nume, Prenume, DataNasterii, Adresa, Functie, Salariu) PROIECTE(Denumire,Termen, Buget) PRODUSE(Denumire, Descriere) COMPONENTE(Denumire, Descriere) FURNIZORI(Nume,Prenume,Adresa) ; CLIENTI(Nume, Prenume, Adresa)

„ Diagrama E-A: SECTII 1

COMPONENTE

PROIECTE

COMPOZITII

M

ACTIVITATI

N

N

ACHIZITII

ANGAJATI

P

N

M

PRODUSE N

1

VANZARI

d

P

N DEPENDENTI Prof. Felicia Ionescu

INGINERI

SECRETARE

FURNIZORI

Cap. 4 - Dezvoltarea sistemelor de baze de date

M

M N

CLIENTI 6

Alegerea unui SGBD „ Factori pentru alegerea unui SGBD: tehnici, economici şi administrativi „ Factorii tehnici: „ Modelul de date (ierarhic, reţea, relaţional, obiect-orientat, obiect-relaţional) „ Capacitatea de stocare a datelor „ Posibilităţile de control al concurenţei şi de refacere a datelor „ Configuraţia hardware-software necesar㠄 Cerinţe de dezvoltare a programelor de aplicaţii (limbaje, compilatoare etc.)

„ Factorii economici şi administrativi: „ Costul de achiziţie a software-ului, care include costul de bază, la care se adaugă diferite opţiuni (opţiuni de salvare-refacere, documentaţie, limbaje şi interfeţe de programare, drivere, etc.) „ Costul de întreţinere, pentru a obţine serviciul furnizorului de menţinere la zi a versiunii SGBD. „ Costul de pregătire a personalului se referă la cursurile care se organizează pentru persoanele care se ocupă cu întreţinerea şi operarea sistemului „ Cunoştinţele de programare a personalului într-un anumit SGBD

„ Beneficiile achiziţionării unui anumit SGBD nu sunt uşor de apreciat sau de măsurat, dar analiza raportului cost-performanţe poate da o imagine a rezultatelor obţinute Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

7

Proiectarea logică a bazelor de date „ Se porneste de la schema conceptuală şi schemele conceptuale externe independente de SGBD (diagrama E-A), si se realizează schema logica (diagrama logica) si schemele logice externe pentru sistemul SGBD ales „ Proiectarea logică poate fi realizată în două subfaze: „ Transpunerea schemei conceptuale în schemă logică a modelului de date dorit, dar independent de un anumit SGBD „ Rafinarea schemei logice şi a schemelor logice externe pentru un anumit SGBD ales (modul de generare a cheilor primare, definirea constrângerilor, etc.)

„ Transpunerea modelului Entitate-Asociere (diagrama E-A) în model relaţional: „ Proiectarea relaţiilor corespunzătoare mulţimilor de entităţi din diagrama E-A „ Proiectarea asocierilor; asocierile se pot reprezenta prin chei străine sau prin relaţii de asociere; acestea sunt relaţii suplimentare care se adaugă în schema conceptuală a bazei de date relaţionale pentru a reprezenta asocierile M:N

„ In mod frecvent, etapele de proiectare conceptuala si proiectare logica (cu cele două subfaze) se efectueaza impreuna, proiectand direct schema (diagrama) logica a bazei de date cu ajutorul toolset-urilor de dezvoltare oferite de SGBDul utilizat Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

8

Diagrama logică a bazei de date INTREPRINDERE (1) „ Dezvoltata in Microsoft Access

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

9

Diagrama logică a bazei de date INTREPRINDERE (2) „ Dezvoltata in MySQL Workbench

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

10

Proiectarea relatiilor „ Mulţimile de entităţi puternice (normale) din diagrama E-A devin relaţii: „ Numele fiecărei relaţii trebuie să fie unic în baza de date „ Atributele relatiei corespund atributelor entităţilor din multimea de entitati data „ Cheia primară se defineşte: ● fie ca o cheie primara naturală (combinaţie de atribute care definesc în mod unic un tuplu) ● fie ca o cheie primară artificială ● De exemplu, în relaţiile ANGAJATI, SECTII, PROIECTE, COMPONENTE, PRODUSE, FURNIZORI, CLIENTI s-a adăugat câte o cheie primară artificială (IdAngajat, IdSectie etc.)

„ Mulţimile de entităţi slabe din diagrama E-A devin relaţii aflate în asociere N:1 cu relaţia corespunzătoare mulţimii de entităţi de care acestea depind ● Pentru realizarea acestei asocieri, în relaţia dependentă se adaugă o cheie străină care referă cheia primară a relaţiei puternice referite; de exemplu: cheia straina dAngajat in introdusa in relatia DEPENDENTI . De ex: DEPENDENTI( IdAngajat, Nume, Prenume, DataNasterii, GradRudenie)

● Cheia primară a relaţiei dependente poate fi: ● o combinaţie formată din atributul cheie străină şi alte atribute care asigură posibilitatea de identificare unică a unui tuplu sau poate fi o cheie artificială. De ex: (IdAngajat, Nume, Prenume ) ● sau o cheie primara artificiala (de ex. idDependenti) Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

11

Proiectarea asocierilor (1) „ Asocierea binară 1: N dintre două mulţimi de entităţi puternice se realizeaza prin intermediul unei chei străine în a doua relaţie (cea cu multiplicitatea N a asocierii) care referă cheia primară din prima relaţie ● De exemplu, asocierea 1:N între relaţiile SECTII – ANGAJATI se realizează prin cheia străină IdSecţie din relatia ANGAJATI

„ Asocierea binară 1: N intre relaţia corespunzătoare unei mulţimi de entităţi puternice si relatia corespunzătoare unei mulţimi de entităţi slabe se realizeaza la fel, printr-o cheie straina in relatia multimii de entitati slabe „ Asocierea binară M:N dintre două mulţimi de entităţi se realizeaza cu o noua relaţie, numită relaţie de asociere „ Aceasta are rapoartele de multiplicitate M :1, respectiv N :1 cu fiecare din cele două relaţii date, prin intermediul a două chei străine „ Cheia primară a unei relaţii de asociere poate fi: ● o cheie primara artificială ● sau poate fi compusă din cheile străine, împreună cu alte atribute ale relaţiei

„ Exemplu: asocierea M:N dintre relaţiile COMPONENTE-PRODUSE se realizeaza cu o relaţie de asociere, numită COMPOZITII ● Relatia COMPOZITII contine cheile străine IdComponenta şi IdProdus ● Cheia primară a relaţiei COMPOZITII poate fi compusă din cheile străine IdComponenta şi IdProdus sau poate fi o cheie artificiala (IdCompozitii) Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

12

Proiectarea asocierilor (2) „ Asocierea binară 1:1 între două mulţimi de entităţi puternice se poate transpune în modelul relaţional în două moduri: ● fie prin intermediul unei chei străine (caz particular al asocierii 1:N), ● fie printr-o relaţie de asociere (caz particular al unei asocierii M:N).

„ Exemplu: intre relaţiile SOTI, SOTII, se realizeaza o asociere 1:1 cu o cheie straina introdusa intr-una dintre relatii: SOTI (IdSoti, Nume, Prenume, DataNasterii, Adresa) SOTII (IdSotii,Nume, Prenume, DataNasterii, Adresa, IdSoti)

„ Realizarea asocierii 1:1 între două relaţii folosind o relatie de asociere De exemplu: CASATORII(IdSot, IdSotie, DataCasatoriei)

„ Asocierea binară 1:1 dintre o mulţime de entităţi de subtip şi mulţimea de entităţi supertip este tot o asociere1:1 între relaţiile corespunzătoare „ Se realizeaza prin definirea în relaţia corespunzătoare subtipului de entitati a unei chei străine, care este în acelaşi timp şi cheie primară De exemplu: INGINERI(IdAngajat, Specialiatea)

„ Exemple de date in tabele asociate Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

13

Proiectarea asocierilor (3) „ Asocierea multiplă M:N:P:…. se realizează la fel ca asocierea binară, prin intermediul unei noi relaţii care se află în asociere M:1, N:1, P:1, etc, cu fiecare din relaţiile date. „ Pentru aceasta, in relatia de asociere se introduc chei straine care refera relatiile care se asociaza, fiecare cheie străină referind cheia primară dintr-una din relaţiile asociate. „ Cheia primară a unei relaţii de asociere multiplă poate fi: ● o cheie primara artificială ● sau poate fi compusă din toate cheile străine, eventual împreună cu alte atribute ● De exemplu: asocierea între relaţiile COMPONENTE, FURNIZORI, ANGAJATI se realizeaza prin relatia ACHIZITII (IdComponenta, IdFurnizor, IdAngajat, Data, NrComponente, PretUnitar)

„ In concluzie, în modelul relaţional toate asocierile se realizează prin chei străine „ Proiectare directa (forward engineering): se proiecteaza schema logica, se exporta un script, care se poate executa si se obtine baza de date „ Proiectare inversa (reverse engineering): se creeaza baza de date (de exemplu, in Msql Query Browser), se genereaza scriptul (cu comanda mysqldump –u root –p database_name > script_name.sql), se importa scriptul (de ex. in Msql Workbench), care va desena diagrama logica a bazei de date Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

14

Proiectarea relatiilor normalizate in prima forma normala „ O relaţie este normalizată în prima formă normală (FN1) dacă fiecare atribut ia numai valori atomice şi scalare din domeniul său de definiţie. „ O situaţie frecvent întâlnită este aceea în care un atribut poate lua mai multe valori pentru fiecare entitate ● De exemplu, în mulţimea de entităţi PERSOANE (Nume, Prenume, Adresa, NrTelefon) atributul NrTelefon poate lua mai multe valori (numărul telefonului de acasă, al telefonului de la birou, al telefonului mobil, etc)

„ Relaţia în care un atribut poate avea valori multiple (un vector de valori) este o relaţie nenormalizată, care nu este admisă de SGBD relaţionale „ Transformarea unei relaţii nenormalizate în relaţie normalizată în prima forma normală (FN1): ● se înlocuieşte atributul care ar putea avea valori multiple cu câte un atribut pentru fiecare din posibilităţile existente: Exemplu: PERSOANE (IdPersoana, Nume, Prenume, Adresa,TelefonAcasa, TelefonBirou, TelefonMobil) ● se înlocuieşte atributul care ar putea avea valori multiple cu o nouă relaţie care referă relaţia iniţială printr-o cheie străină. Exemplu: PERSOANE(IdPersoana, Nume, Prenume, Adresa), TELEFOANE(NrTelefon, IdPersoana, Descriere)

„ Exemple de date in tabele cu diferite tipuri de asocieri Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

15

Proiectarea fizica a bazelor de date „ Fiecare SGBD oferă o varietate de opţiuni de organizare a fişierelor şi a modului de acces la datele stocate: ● indexuri ● tipuri de fisiere ● gruparea înregistrărilor corelate în aceleaşi blocuri pe disc (clustering)

„ Proiectarea fizică a bazei de date este procesul de alegere a acestor structuri de memorare şi de acces la fişierele bazei de date, pentru a obţine performanţe cât mai bune pentru SGBD-ul ales, pentru cât mai multe din aplicaţiile proiectate „ Parametrii generali de alegere a opţiunilor proiectului fizic al bazei de date: ● Timpul de răspuns: intervalul de timp dintre lansarea în execuţie a unei tranzacţii şi primirea răspunsului la acea tranzacţii ● Utilizarea spaţiului de memorare: dimensiunea spaţiului pe disc utilizat de fişierele bazei de date şi de structurile de acces la date ● Capacitatea tranzacţională (transaction throughput): numărul mediu de tranzacţii care pot fi prelucrate pe minut de către sistemul de baze de date

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

16

Implementarea bazelor de date „ În faza de implementare a bazelor de date relaţionale: ● Se creează obiectele principale ale bazei de date (tabele, vederi, indexuri), pe baza proiectului logic şi a proiectului fizic, folosind limbajul de descriere a datelor (LDD) oferit de sistemul SGBD ales, sau toolset-uri grafice (de ex. table editor) sau prin executia scriptului generat de un toolset de proiectare ● Se implementează procedurile care asigură verificarea şi forţarea tuturor constrângerilor explicite (aserţiuni, dependenţe de date care nu sunt determinate de chei ale relaţiilor), a căror previziune şi documentare a fost realizată în faza de proiectare logică a bazei de date ● Se populeaza baza de date cu informatii obţinute prin conversia unor date existente sub formă de fişiere sau introduse direct în tabele

„ Tot în această fază programatorii de aplicaţii implementează, pe baza specificaţiilor conceptuale ale tranzacţiilor, programele de aplicaţii, în diferite tehnologii de programare disponibile (limbaje procedurale de extensie a limbajului SQL, limbajul SQL integrat, interfeţe şi biblioteci de programare) „ După crearea şi popularea bazei de date şi implementarea programelor de aplicaţii se poate trece la etapa de testare si operare a sistemului de baze de date, în paralel cu monitorizarea şi întreţinerea acestuia Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

17

Dezvoltarea aplicatiilor de baze de date „ Aplicaţiile de baze asigura: ● interfaţa (grafică) cu utilizatorii ● implementarea algoritmilor de calcul necesari ● interfaţa cu sistemele de gestiune a bazelor de date Aplicatie de baza de date Utilizatori

•Limbajul SQL integrat (Embeded SQL) •Interfete de programare a aplicatiilor (API)

Instr. SQL

SGBD •Limbajul SQL

Rezultate

•Extensii procedurale ale limbajului SQL

„ Limbajul SQL, folosit in SGBD-uri este un limbaj neprocedural, adica nu prevede instrucţiuni de control al ordinii de execuţie a operaţiilor „ De aceea SGBD-urile mai folosesc si extensii procedurale a limbajului SQL: ● PL/SQL in sistemele Oracle, PL/PLGSQL in sistemele PostGreSQL ● Transact-SQL in sistemele Microsoft SQL Server ● Extensie SQL in MySQL (asemanatoare cu Transact SQL) etc.

„ Aplicatiile de baze de date folosesc: ● Limbajul SQL integrat intr-un limbaj de nivel inalt (Embeded SQL) ● Interfete de programare a aplicatiilor (API) (call level interface) Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

18

Limbaje procedurale de extensie a SQL „ Extensiile procedurale ale limbajului SQL definesc: „ Variabile, instructiuni pentru controlul ordinii de execuţie (bucle while, instrucţiuni condiţionale if etc.), instrucţiuni SQL extinse „ ofera suport de crearea cursoarelor, a procedurilor stocate, a funcţiilor definite de utilizator şi a declanşatorilor (triggere)

„ Variabilele sunt folosite pentru stocarea in memorie a unor valori care pot fi testate sau modificate şi pot fi folosite pt transferul datelor către şi de la tabele „ Variabilele locale au ca domeniu de definiţie blocul, procedura, functia sau trigger-ul în care au fost declarate „ Un bloc este un grup de instructiuni delimitat prin instructiunile: BEGIN ... END; un bloc este considerat o instructiune compusa „ O variabilă locală se declară si se initializeaza diferit de la un SGBD la altul. ex: • • •

in Transact SQL: DECLARE @contor INT in PL/SQL (Oracle): DECLARE CONTOR := 1; in MySQL: DECLARE contor INT;

SELECT @contor = 0 SET contor = 0;

„ Ordinea de execuţie a instrucţiunilor este controlată prin instrucţiuni ca: BEGIN...END GOTO IF...ELSE RETURN Prof. Felicia Ionescu

REPEAT...UNTIL WHILE BREAK CONTINUE

FOR

Cap. 4 - Dezvoltarea sistemelor de baze de date

19

Instructiuni SQL extinse „ Extensiile procedurale definesc clauze suplimentare in instructiunile SQL, astfel încât acestea să poată fi folosite în combinaţie cu variabilele locale „ De exemplu - instrucţiunea SELECT prin care se incarca valori ale unor atribute selectate din baza de date in variabile locale: • In Transact-SQL: • In PL/SQL (Oracle): • In MySQL:

SELECT @var1 = col1, @var2 = col2, ... @varn = coln FROM lista_tabele WHERE conditie SELECT lista_coloane INTO lista_variabile FROM lista_tabele [WHERE conditie] [optiuni] SELECT lista_coloane INTO lista_variabile FROM lista_tabele [WHERE conditie] [optiuni]

„ Astfel de instrucţiuni sunt utile pentru interogările care returnează o singură linie, deoarece variabilele locale sunt setate cu valorile atributelor din prima linie a rezultatului, iar valorile din celelalte linii se pierd. De ex. (in MySQL): DECLARE id_angajat int; DECLARE s_nume, s_prenume varchar(20); SET id_angajat = 5; SELECT Nume, Prenume INTO s_nume, s_prenume FROM ANGAJATI WHERE IdAngajat = id_angajat

„ Atunci când o interogare returnează o mulţime de linii, se foloseste un cursor „ Variabilele locale mai pot fi folosite în clauza WHERE a instructiunii SELECT precum si in instructiunile INSERT sau UPDATE (ca valori introduse) Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

20

Proceduri stocate „ O procedură stocată (stored procedure) este o procedură care implementează o parte din algoritmii de calcul ai aplicaţiilor şi care este memorată in baza de date, la fel ca şi alte obiecte ale bazei de date „ Procedurile stocate se definesc folosind extensiile procedurale ale SQL: In Transact-SQL: CREATE PROCEDURE nume_proc [parametri] AS instructiune In PL/SQL (Oracle): CREATE PROCEDURE nume_proc [parametri] AS instructiune In MySQL: CREATE PROCEDURE nume_proc [parametri] instructiune_compusa

„ Parametrii pot fi de intrare (IN), de iesire (OUT) sau de intrare-iesire (INOUT); apelul unei proceduri stocate de către un client (aplicaţie) produce execuţia de catre SGBD a tuturor instrucţiunilor procedurii şi returnarea rezultatrlor in parametrii OUT si INOUT „ Avantaje - imbunatatirea performantelor sistemului prin: ● Scaderea comunicaţiei între aplicaţie şi serverul bazei de date ● Scaderea timpului de execuţie a sarcinii respective, dat fiind că procedura stocată este deja compilată, optimizată si memorata, putand fi apelata oricand, de oricati clienti

„ Dezavantaje: congestionarea serverului si scaderea performantelor acestuia, dacă prea multe aplicaţii executa operaţiile de prelucrare pe server prin intermediul procedurilor stocate Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

21

Exemplu: Procedura stocata in MySQL „ Folosim tabelele: Studenti, Examene, Discipline:

„ Procedura stocata: Calculul mediei notelor la o disciplina data: DELIMITER $$ /* se redefineste delimitatorul deoarece ; este obligatoriu intre instr. din blocuri */ DROP PROCEDURE IF EXISTS SP_Media $$ CREATE PROCEDURE SP_Media (OUT media float, IN disciplina varchar(4)) BEGIN SELECT AVG(nota) INTO media FROM DISCIPLINE, EXAMENE WHERE DISCIPLINE.idDiscipline = EXAMENE.idDiscipline AND Acronim = disciplina; END$$ DELIMITER ;

„ Apelul procedurii: call SP_Media(@media, 'PBD'); /* o variabila precedata de @ este implicit locala */ select @media; Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

22

Functii definite de utilizator „ O funcţie definită de utilizator (user-defined function) este o funcţie memorată in baza de date, la fel ca o procedură stocat㠄 O funcţie are numai parametri de intrare, returnează întotdeauna o valoare şi poate fi folosită direct în expresii (o procedură stocată poate să returneze zero, una sau mai multe valori prin parametrii de tip OUT sau INOUT) „ Functiile se definesc folosind extensiile procedurale ale limbajului SQL: In Transact-SQL: CREATE FUNCTION nume_func [parametri] AS instructiune In PL/SQL (Oracle): CREATE FUNCTION nume_func [parametri] AS instructiune In MySQL: CREATE FUNCTION nume_func [parametri] instructiune_compusa

„ Exemplu de creare a unei functii in MySQL: DELIMITER $$ DROP FUNCTION IF EXISTS Func_Media$$ CREATE FUNCTION Func_Media(disc varchar(4)) RETURNS float BEGIN DECLARE nota_medie float; SELECT AVG(nota) INTO nota_medie FROM DISCIPLINE, EXAMENE WHERE DISCIPLINE.idDiscipline = EXAMENE.idDiscipline AND Acronim = disc; RETURN nota_medie; END$$ DELIMITER ;

„ Utilizarea valorii returnate de o functie: select Func_Media('PBD'); Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

23

Cursoare „ Un cursor (cursor) este o structură (un buffer) care permite memorarea unei mulţimi de linii returnate de o instrucţiune de interogare, urmata de extragerea si prelucrarea (eventual repetata) in programele de aplicatii a fiecarei linii „ Cursoarele se pot crea folosind limbajul SQL sau extensiile procedurale ale acestuia „ Instrucţiunile SQL de definire şi de operare a cursoarelor: ● Definire cursor: DECLARE nume_cursor [OPTIUNI] CURSOR FOR instructiune_select; ● Deschidere cursor (popularea cu datele din tabele): OPEN nume_cursor; ● Extragerea unei (sau mai multor) linii dintr-un cursor de la pozitia curenta: FETCH [FROM] nume_cursor INTO lista_variabile; ● Inchiderea cursor: CLOSE nume_cursor;

„ Cursoarele pot fi memorate: „ la server, iar clientul primeşte câte o linie (sau un grup de linii) de la server la fiecare instrucţiune de extragere „ la client şi liniile sunt folosite direct în programul respectiv

„ In general, cursoarele la server sunt mai avantajoase decât cursoarele la client, deoarece cursoarele la client necesită ca toate liniile rezultat să fie transferate dintr-o dată de la server la client Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

24

Exemplu: Cursor intr-o procedura stocata MySQL (1) „ Procedura: Calculul mediei unui student dat (nume, prenume) DELIMITER $$ DROP PROCEDURE IF EXISTS Medii_Studenti $$ CREATE PROCEDURE Medii_Studenti(OUT media float, IN s_nume varchar(20), IN s_prenume varchar(20)) BEGIN DECLARE done INT DEFAULT 0; DECLARE student, id_student INT; /*Crearea cursorului*/ DECLARE cursor_examene CURSOR FOR SELECT idStudenti, avg(nota) FROM EXAMENE GROUP BY idStudenti; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1; SELECT idStudenti INTO student FROM STUDENTI WHERE Nume = s_nume AND Prenume = s_prenume; OPEN cursor_examene; REPEAT FETCH cursor_examene INTO id_student, media; UNTIL done = 1 OR id_student = student END REPEAT; CLOSE cursor_examene; END$$ DELIMITER ; Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

25

Exemplu: Cursor intr-o procedura stocata MySQL (2) „ Pentru parcurgerea liniilor cursorului se defineste un handler pentru conditia de terminare a parcurgerii liniilor cursorului (not found); un handler este un fel de rutina de tratare a exceptiilor „ Apelul procedurii: call Medii_Studenti(@media, 'Popescu', 'Marius'); select @media;

„ Se obtine rezultatul:

@media 6.5

„ Parcurgerea liniilor cursorului se poate face si cu instructiunea while: FETCH cursor_examene INTO id_student, media; WHILE done = 0 AND id_student student DO FETCH cursor_examene INTO id_student, media; END WHILE;

„ Declararea unei variabile locale (cu instructiunea DECLARE) se poate face numai intr-un bloc BEGIN ... END si numai la inceputul acestuia „ Declaratiile trebuie sa fie facute intr-o anumita ordine: cursoarele se declara inaintea declararii handler-elor, iar variabilele locale inaintea declararii cursoarelor si a handler-elor Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

26

Triggere „ Un trigger este o procedură stocată specială, care este executată automat atunci când se efectuează operaţii de actualizare a relaţiilor (INSERT, DELETE, UPDATE) „ Triggerele pot fi create folosind extensiile procedurale ale limbajului SQL; sintaxa difera de la un SGBD la altul (sunt neportabile): In Transact-SQL: CREATE TRIGGER nume_trigger ON nume_tabel {FOR|AFTER|INSTEAD OF} {[DELETE][,INSERT][,UPDATE]} AS instructiuni In Pl/SQL (Oracle): CREATE TRIGGER nume_trigger {BEFORE|AFTER} [INSERT, DELETE, UPDATE] [FOR EACH ROW [WHEN conditie]] CALL procedura In MySQL: CREATE TRIGGER nume_trigger ON tabel FOR EACH ROW instructiune

„

Utilizarea triggerelor: ● Extinderea capacităţii SGBD-ului de menţinere a integrităţii datelor relaţionale impunerea constrângerile explicite cum sunt dependenţele de date (dependenţe funcţionale sau multivalorice care nu sunt determinate de chei) ● Generarea automată a unor valori care rezultă din valori ale altor atribute ● Jurnalizarea transparentă a evenimentelor sau culegerea de date statistice în legătură cu accesarea relaţiilor.

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

27

Exemplu: trigger in MySQL „ Se defineste un trigger care genereaza coloana ‘nota’ in tabelul examene_2(idExamene, idDiscipline, notaLab, notaExam, nota): DELIMITER $$ DROP TRIGGER IF EXISTS calcul_nota $$ CREATE TRIGGER calcul_nota BEFORE UPDATE ON `examene_2` FOR EACH ROW BEGIN SET NEW.nota = NEW.notaLab + NEW.notaExam; END; $$ DELIMITER ;

„ Instructiunile dupa FOR EACH ROW se executa de fiecare data cand triggerul este activat, ceea ce se intampla la fiecare linie afectata de instructiunea de declansare a triggerului (UPDATE in exemplul dat): update examene_2 set notaLab = 2 , notaExam = 5 where idStudenti=1 AND idDiscipline = 2;

„ Cuvintele cheie OLD si NEW permit accesarea coloanelor din linia afectata: • pentru triggere INSERT se poate folosi numai NEW, • pentru triggere DELETE numai OLD, • pentru triggere UPDATE se poate folosi OLD (pentru valorile dinainte de UPDATE) sau NEW (pentru valorile actualizate). Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

28

Limbajul SQL integrat (Embeded SQL) „ În limbajul SQL integrat (Embeded SQL) instrucţiunile limbajului SQL sunt incluse direct în codul programului sursă scris într-un limbaj gazdă de nivel înalt (Ada, PL/1, Pascal, Fortran, Cobol, C) „ Controlul fluxului de operaţii este realizat prin instrucţiunile limbajului gazdă, iar operaţiile cu baza de date sunt realizate prin instrucţiuni SQL „ Instrucţiunile SQL integrate în programul scris în limbajul gazdă sunt prelucrate de un instrument software adecvat (numit preprocesor), fiind transformate în apeluri de funcţii ale unei biblioteci speciale a SGBD-ului „ Rezultatul preprocesării este un program sursă în limbajul gazdă, care poate fi compilat cu compilatorul limbajului gazdă respectiv şi apoi legat (link) cu bibliotecile de sistem şi bibliotecile SGBD-ului „ Standardul SQL2 specifică suport integrat pentru limbajele PL/1, C, Pascal, Cobol, Fortran, Mumps. Pentru produsele Oracle, limbajul SQL a fost integrat în limbajul Java, sub numele de SQLJ „ Pentru sistemele Microsoft SQL Server se poate folosi limbajul ESQL/C (Embedded SQL for C), pentru MySQL exista biblioteca mysqld Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

29

Interfete si biblioteci de programare a aplicatiilor de baze de date „ In general se folosesc 2 categorii de interfete de programare a aplicatiilor de baze de date: interfete specifice unui anumit SGBD si interfete independente de SGBD „ Interfete specifice unui anumit SGBD sunt biblioteci care contin funcţii şi macrodefiniţii ce permit aplicaţiilor să interacţioneze cu serverul bazei de date. De exemplu: ● Biblioteci dezvoltate pentru limbajul C ( biblioteca C pentru sistemul Microsoft SQL Server - DB-Library for C, biblioteca MySQL C API) ● Biblioteci pentru alte limbaje (C++, Perl, PHP, etc)

„ Interfeţe independente de SGBD, cu un grad ridicat de generalitate, care pot fi folosite pentru mai multe tipuri de SGBD-uri; cele mai cunoscute sunt: ● Interfata ODBC (Open DataBase Connectivity) ● Interfata JDBC (Java DataBase Connectivity)

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

30

Interfata ODBC „ Tehnologia ODBC (Open Database Connectivity) - interfaţă de programare a aplicaţiilor prin apel de funcţii independente de sistemul SGBD folosit „ Independenţă se obţine prin drivere specifice fiecărui SGBD „ Driverul transformă apelurile de funcţii ODBC în comenzi SQL (sau într-un limbaj procedural de extensie a limbajului SQL) si le transmite SGBD-ului

Interfaţa ODBC

Aplicaţie Administrator de drivere Driver

Sursa de date

SGBD şi Baza de date

Prof. Felicia Ionescu

Driver

Sursa de date

SGBD şi Baza de date

Cap. 4 - Dezvoltarea sistemelor de baze de date

Driver

Sursa de date

SGBD şi Baza de date

31

Interfața JDBC „ JDBC este o interfaţă de programare a aplicaţiilor de baze de date independentă de platformă şi de sistemul SGBD „ Interfaţa JDBC constă din clase si obiecte Java şi permite interacţiunea cu baze de date relaţionale, precum şi cu alte surse de date în format tabelar „ Arhitectura JDBC constă din mai multe niveluri care asigură independenţa funcţiilor de acces apelate din programele de aplicaţie de SGBD Interfaţa JDBC

Program de aplicatie Java

Administratorul de drivere (DriverManager) Driver JDBC de retea

Punte JDBCODBC

Driver combinat

Driver Java pur

Driver ODBC

Protocol JDBCmiddleware Prof. Felicia Ionescu

Protocoale de acces specifice SGBD-urilor Cap. 4 - Dezvoltarea sistemelor de baze de date

32

Prof. Felicia Ionescu

Cap. 4 - Dezvoltarea sistemelor de baze de date

33

Capitolul 5: Gestiunea tranzactiilor „ Tranzactii „ Anomalii de acces concurent la bazele de date ● Actualizare pierduta ● Citire improprie ● Citire irepetabila ● Citire fantoma

„ Proprietatile tranzactiilor „ Operatiile efectuate de tranzactii „ Starile tranzactiilor „ Planificarea tranzactiilor „ Tehnici de control al concurentei ● Controlul concurentei prin blocare ● Controlul concurentei prin marci de timp

„ Tehnici de refacere a bazelor de date Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

1

Tranzactii „ În mod obişnuit, un sistem SGBD deserveşte mai mulţi utilizatori, care accesează concurent datele din tabele „ Execuţia concurentă a mai multor procese poate avea loc: ● într-un sistem uniprocesor, prin partajarea (împărţirea) timpului de execuţie al procesorului între mai multe procese (multiprogramare) ● într-un sistem multiprocesor, în care mai multe procese pot fi executate în mod real simultan, pe mai multe procesoare ale sistemului (multiprocesare)

„ O tranzacţie (transaction) este o unitate logică de prelucrare indivizibilă (atomică) a datelor unei baze de date prin care se asigură consistenţa acesteia „ O tranzacţie trebuie să asigure consistenţa bazei de date in diferite situatii: ● tranzactia se execută individual sau concurent cu alte tranzacţii ● apar defecte ale sistemului în cursul execuţiei tranzacţiei

„ O tranzacţie este o operaţie indivizibilă de acces la baza de date care: ● fie se execută cu succes toate acţiunile şi se termină cu o validare a modificărilor efectuate asupra bazei de date (commit) ● fie nu poate efectua (din diferite motive) toate acţiunile şi este abandonată şi anulată (abort, rollback) Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

2

Exemplu de tranzactie Exemplu: un sistem de rezervare a locurilor la curse aeriene

„ ●

PASAGERI (IdPasager, Nume, Prenume, Adresa)



CURSE (IdCursa, AeroportPlecare, AeroportSosire, DataCursa, NrLocuriLibere)



FACTURI (IdFactura, IdPasager, IdCursa, DataFactura, Pret)

Pentru rezervarea unui loc se efectuează mai multe operaţii:

„

1.

Se inserează o linie nouă în tabelul PASAGERI, cu datele pasagerului

2.

Dacă există locuri libere la cursa dorită, atunci se face propriu-zis rezervarea, prin inserarea unei linii noi în tabelul FACTURI; altfel, nu se face rezervarea

3.

Se tipăreste factura

4.

Se emite (tipăreşte) biletul

Probleme care pot sa apara:

„

„



Dacă sistemul se defectează după ce s-a executat pasul 2, s-a făcut o rezervare, dar biletul nu a fost facturat şi nici emis



Dacă defecţiunea are loc după pasul 3, clientului i se trimite factura, dar el nu a primit biletul



Dacă nu se defectează sistemul, dar doi agenţi de vânzări atribuie acelaşi loc la doi pasageri diferiţi, atunci vor fi probleme la îmbarcarea pasagerilor

Astfel de probleme ar disparea dacă toate actiunile efectuate pentru o rezervare ar fi grupate ca o operaţie indivizibilă (atomică)

Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

3

Anomalii de acces concurent la bazele de date (1) „ Unitatea de transfer a datelor între discul magnetic şi memoria principală a sistemului este un bloc, care corespunde unui sector de pe disc si in care se memoreaza mai multe inregistrari (tupluri) „ Un articol (data item) este un câmp care memorează valoarea unui atribut dintr-o înregistrare (tuplu), dar poate fi o înregistrare întreagă sau chiar o grupare de inregistrari memorate intr-un bloc „ Operaţiile de acces la un articol X al bazei de date pot fi: ● read(X): citeşte articolul X din baza de date într-o variabilă a programului; pentru simplificarea notaţiilor se va considera că variabila în care se citeşte articolul X este notată, de asemenea, cu X. ● write(X): scrie variabila de program X în articolul X al bazei de date.

„ Tranzacţiile lansate de diferiţi utilizatori se pot executa concurent şi este posibil să actualizeze aceleaşi articole ale bazei de date „ Dacă execuţia concurentă a tranzacţiilor este necontrolată, este posibil ca baza de date să ajungă într-o stare inconsistentă (incorectă), chiar dacă: ● fiecare tranzacţie în parte a fost executată corect ● nu au apărut defecte de funcţionare ale sistemului Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

4

Anomalii de acces concurent la bazele de date (2) „ Actualizare pierduta (lost update): rezulta X=X-M (b) in loc de valoarea

corecta X= X+N-M (a)

„ Citire improprie (dirty read): T2 citeste X+N, desi X=X+N nu a fost validata (c) Timp

T1

T2

T1

T2

T1

read(X)

read(X)

read(X)

X=X+N

X=X+N

X=X+N

write(X)

read(X) X=X-M write(X)

write(X)

X=X-M

read(X)

T2

read(X)

write(X)

X=X-M write(X)

write(X) abort

(a)

(b)

(c)

„ Citire irepetabilă (nonrepetable read): o tranzacţie citeşte un articol de două ori, iar între cele două citiri, o altă tranzacţie a modificat chiar acel articol „ Citire fantomă (phantom read): o tranzacţie prelucrează un set de linii rezultat al unei interogări si în timpul acestei prelucrări o altă tranzacţie insereaza sau sterge o linie Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

5

Proprietatile tranzactiilor (ACID) „ Atomicitatea (atomicity): proprietatea unei tranzacţii de a reprezenta o unitate de execuţie indivizibilă, adică de a executa “totul sau nimic” „ Consistenţa (consistency): proprietatea unei tranzactii de a efectua modificări corecte ale bazei de date ● o tranzacţie transformă baza de date dintr-o stare consistentă în altă stare consistentă ● starea unei baze de date este consistentă dacă respectă toate constrângerile de integritate implicite sau explicite

„ Izolarea (isolation): proprietatea unei tranzacţii de a face vizibile modificările efectuate numai după ce a fost validată (committed) ● Dacă rezultatele parţiale ale unei tranzacţii sunt vizibile altor tranzacţii înainte de validarea acesteia şi dacă se întâmplă ca această tranzacţie să fie abandonată şi anulată (rollback), atunci toate tranzacţiile care au accesat rezultatele parţiale ale acesteia vor trebui să fie anulate ● Aceste operaţii de anulare pot produce, la rândul lor alte anulări, ş.a.m.d.

„ Durabilitarea (durability): proprietatea prin care, după validarea unei tranzacţii, modificările efectuate de aceasta în baza de date nu vor mai fi pierdute datorită unor defectări ulterioare a sistemului Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

6

Operatiile efectuate de tranzactii „ Operaţiile efectuate de o tranzacţie şi înregistrate de administratorul de refacere (recovery manager): ● begin: începutul execuţiei unei tranzacţii ● read sau write: operaţii de citire sau scriere a articolelor din baza de date ● end: marchează terminarea operaţiilor de scriere sau citire din baza de date, ceea ce înseamnă că tranzacţia se poate termina; totuşi, este posibil să fie necesare unele operaţii de verificare înainte de validarea (commit) tranzacţiei. ● commit: terminarea cu succes a tranzacţiei, validarea tuturor modificărilor efectuate în baza de date şi vizibilitatea modificărilor efectuate pentru alte tranzacţii; din acest moment, modificările efectuate nu mai pot fi anulate, nici pierdute printr-o defectare ulterioară a sistemului ● rollback (sau abort): semnifica faptul că tranzacţia a fost abandonată şi că orice efect pe care tranzacţia l-a avut asupra bazei de date trebuie să fie anulat (printro “rulare înapoi” a operaţiilor). ● undo: operaţie similară operaţiei rollback, dar se aplică unei singure operaţii, nu unei întregi tranzacţii. ● redo: specifică faptul că unele operaţii ale unei tranzacţii trebuie să fie executate din nou pentru a se putea valida întreaga tranzacţie.

„ Ultimele două operaţii sunt necesare numai în anumite tehnici de refacere Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

7

Starile tranzactiilor „ Diagrama de stare a unei tranzactii: read, write begin

end ACTIVĂ abort

PARTIAL VALIDATĂ

commit VALIDATĂ

abort

ABANDONATĂ

TERMINATĂ

„ Pentru refacerea bazei de date, sistemul SGBD menţine un fişier jurnal (log file), în care memorează operaţiile efectuate de fiecare tranzacţie, identificată printr-un identificator unic (T) generat de sistem „ Fişierul jurnal este memorat pe disc şi nu este afectat de erori de execuţie, cu excepţia unei defectări catastrofice a discului „ Fişierul jurnal este salvat periodic pe un suport auxiliar (bandă magnetică) Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

8

Planificarea tranzactiilor „ O planificare (schedule, sau istorie - history) S a n tranzacţii T1,T2,..Ti,...Tn este o ordonare a operaţiilor tranzacţiilor astfel încât: ● Pentru orice tranzacţie Ti care participă în S, operaţiile lui Ti în S respectă ordinea iniţială din Ti ● Alte operaţii (ale altor tranzacţii Tj, unde j ≠ i) pot fi întreţesute cu operaţii ale tranzacţiei Ti

„ Două operaţii dintr-o planificare sunt conflictuale (conflicting operations) dacă aparţin unor tranzacţii diferite, accesează acelaşi articol şi cel puţin una dintre operaţii este operaţie de scriere „ Planificări seriale (serial schedules): o planificare S se numeşte serială dacă pentru orice tranzacţie T participantă în planificare, toate operaţiile din T se execută consecutiv în S; altfel, planificarea se numeşte neserial㠄 Pentru n tranzactii pot exista n! planificari seriale „ Orice planificare seriala a unor tranzactii corecte este corecta, dar nu permite întreţeserea operaţiilor şi concurenţa tranzacţiilor „ De aceea, în cazul sistemelor de baze de date cu utilizatori multipli se folosesc planificările serializabile, care admit concurenţa, asigurând în aceelaşi timp consistenţa bazei de date Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

9

Planificari seriale ale tranzactiilor „ Planificarile seriale posibile ale tranzactiilor T1 si T2 sunt SA si SB: T1

T2

T1

T2

read(X) – r1(X)

read(X) – r2(X)

X=X-N

X=X+M

write(X) – w1(X)

write(X) – w2(X)

read(Y) – r1(Y)

SA

Y=Y+N write(Y) – w1(Y)

read(X) – r1(X) X=X-N

SB

write(X) – w1(X) read(X) – r2(X)

read(Y) – r1(Y)

X=X+M

Y=Y+N

write(X) – w2(X)

write(Y) – w1(Y)

„ Notam operaţiile de begin, read, write, commit şi abort cu b, r, w, c, a, cu indice numarul tranzacţiei şi ca parametru articolul pe care l-a citit sau scris: SA: b1; r1(X); w1(X); r1(Y); w1(Y); c1; b2; r2(X); w2(X); c2; SB: b2; r2(X); w2(X); c2; b1; r1(X); w1(X); r1(Y); w1(Y); c1;

„ Perechile de operaţii conflictuale sunt: „ in SA: ((r1(X), w2(X)), w1(X), r2(X)), (w1(X), w2(X)); „ in SB: (r2(X), w1(X)), (w2(X), r1(X)), (w2(X), w1(X)) Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

10

Planificari serializabile ale tranzactiilor (1) „ O planificare a n tranzacţii se numşte serializabilă dacă este echivalentă cu o planificare serială a celor n tranzacţii „ Două planificări sunt echivalente (din punct de vedere al conflictelor) dacă operaţiile din oricare pereche de operatii conflictuale se execută în aceeaşi ordine în cele două planificări „ Planificarile SC si SD sunt planificari echivalente cu SA, deci sunt serializabile T1

T2

T1

read(X) – r1(X)

read(X) – r1(X)

X=X-N

X=X-N

write(X) – w1(X)

write(X) – w1(X) read(X) – r2(X)

SC

read(Y) – r1(Y)

SD

X=X+M

read(X) – r2(X)

write(X)- w2(X)

X=X+M

read(Y) – r1(Y)

Y=Y+N

Y=Y+N

write(Y) – w1(Y)

write(Y) – w1(Y) Prof. Felicia Ionescu

T2

write(X) –w2(X) Cap. 5 - Gestiunea tranzactiilor

11

Planificari serializabile ale tranzactiilor (2) „ Planificarile SE si SF nu sunt sunt echivalente nici cu SA nici cu SB, deci sunt neserializabile T1

T1

T2

read(X) – r1(X)

read(X) – r1(X)

X=X-N

X=X-N read(X) – r2(X)

read(X) – r2(X) write(X) – w1(X)

T2

SE

X=X+M

X=X+M

write(X) – w1(X)

write(X)- w2(X)

read(Y) – r1(Y)

read(Y) – r1(Y)

Y=Y+N

Y=Y+N

write(Y) – w1(Y)

SF

write(X) – w2(X)

write(Y) – w1(Y)

„ Testarea echivalentei unei planificări cu o planificare seriala prin testarea ordinii operatiilor din toate perechile de operatii conflictuale este foarte costisitoare „ DAR s-a demonstrat ca se poate asigura echivalenta planificarilor (deci serializabilitatea lor) prin tehnici de control al concurenţei tranzacţiilor, care interzic execuția în ordine incorectă a operațiilor din perechile conflictuale „ De exemplu: în SE se interzice execuția r2(X) înaintea de w1(X) Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

12

Tehnici de control al concurentei tranzactiilor „ Pentru a asigura proprietăţile ACID ale tranzacţiilor şi, prin aceasta, consistenţa datelor, este necesar controlul execuţiei concurente a tranzacţiilor „ Cele mai utilizate tehnici de control al concurenţei sunt: „ Tehnici bazate pe blocarea accesului la date prin zăvoare (locks) „ Tehnici bazate pe mărci de timp (timestamps)

„ Protocoalele de control al concurenţei sunt implementate de SGBD-uri: „ programatorii de aplicaţii nu operează explicit cu zăvoare sau mărci de timp „ ei stabilesc opţiunile prin care sistemul SGBD executa anumite operatii de control

„ Un zăvor (lock) este o variabilă L(X) asociată cu un articol X al bazei de date care descrie starea acelui articol în raport cu operaţiile care i se pot aplica „ Tipuri de zavoare utilizate in SGBD-uri: „ zăvoare binare, zăvoare cu stări multiple

„ Un zăvor binar (binary lock) L(X) poate avea două stări: „ L(X) = 1 - liber (sau neblocat - free, unlocked) – se poate accesa articolul X „ L(X) = 0 - ocupat (sau blocat - busy, locked) – nu se poate accesa articolul X

„ Asupra unui zăvor binar L(X) se pot executa două operaţii: „ operaţia de blocare, lock(X) – trece zăvorul în starea blocat (ocupat) „ operaţia de eliberare, unlock(X) – trece zăvorul în starea neblocat (liber) Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

13

Zavoare binare „ Dacă zăvorul articolului X este liber (L(X)=1), atunci tranzactia: ● achiziţionează zăvorul (trecându-l în starea ocupat prin operatia lock ) ● execută operaţiile necesare asupra articolului X ● eliberează zăvorul (trcându-l in starea liber prin operaţia unlock)

„ Dacă zăvorul articolului X este ocupat (L(X)=0), atunci tranzacţia: ● aşteaptă până ce acesta este eliberat (de o altă tranzacţie, care şi-a terminat operaţiile de acces la acel articol), ● după care execută aceeaşi secvenţă de operaţii: blocarea zăvorului, execuţia operaţiilor care accesează articolul respectiv şi eliberarea zăvorului

„ Operaţia de blocare se executată ca operaţie indivizibilă (folosind instrucţiuni speciale ale procesoarelor de tip TestAndSet) „ Regulile respectate de fiecare tranzacţie care foloseşte un zăvor binar: 1. O tranzacţie trebuie să blocheze zăvorul articolului X (prin operatia lock(X)), înainte de a efectua orice operaţie de citire sau de scriere a articolului X 2. O tranzacţie trebuie să elibereze zăvorul unui articol X (prin operaţia unlock(X)) după ce a efectuat toate operaţiile de citire sau de scriere a articolului X 3. O tranzacţie nu poate achizitiona un zăvor pe care îl deţine deja 4. O tranzacţie nu poate elibera un zăvor pe care nu îl deţine Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

14

Zăvoare cu stări multiple (1) „ Tehnica zăvoarelor binare este prea restrictivă şi limitează în mod nejustificat concurenţa în execuţia tranzacţiilor „ De exemplu, mai multe tranzacţii pot efectua operaţii de citire în mod concurent asupra aceluiași articol, fără ca acest lucru să afecteze consistenţa bazei de date, dar acest lucru este interzis în tehnica zăvoarelor binare „ De aceea, multe sisteme de gestiune a bazelor de date utilizează zăvoare cu stări multiple „ Un zăvor cu stări multiple (multiple-mode lock) M(X) poate fi într-una din următoarele trei stări: ● liber (neblocat, unlocked): zăvorul nu este deţinut de nici o tranzacţie şi prima tranzacţie care lansează o operaţie de blocare îl poate obţine ● blocat pentru citire (sau blocat partajat,read-locked): oricâte tranzacţii pot deţine zăvorul respectiv şi pot efectua operaţii de citire a articolului X, dar nici o tranzacţie nu poate scrie în acest articol ● blocat pentru scriere (sau blocat exclusiv, write-locked): o singură tranzacţie poate deţine zăvorul şi poate citi sau scrie în articolul X, nici o altă tranzacţie neputând accesa articolul respectiv, nici pentru scriere nici pentru citire

■ Operatiile cu zăvoarele cu stări multiple: ■ read_lock(X) - blocarea pentru citire (partajată) a zăvorului M(X) ■ write_lock(X) - blocarea pentru scriere (exclusivă) a zăvorului M(X) ■ unlock(X) - deblocarea zăvorului M(X) Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

15

Zăvoare cu stări multiple (2) „ Orice tranzacţie care utilizează un zăvor cu stări multiple M(X) trebuie să respecte următoarele reguli: 1. O tranzacţie trebuie să execute o operaţie de blocare partajată sau exclusivă a zăvorului articolului X (read_lock(X) sau write_lock(X)) înainte de a efectua orice operaţie de citire a articolului X 2. O tranzacţie trebuie să execute o operaţie de blocare exclusivă a zăvorului articolului X (write_lock(X)) înainte de a efectua orice operaţie de scriere a lui X 3. O tranzacţie trebuie să elibereze zăvorul unui articol X (unlock(X)) după ce a efectuat toate operaţiile de citire sau de scriere a articolului X

„ Operaţia de eliberare a unui zăvor poate fi executata numai de o tranzactie care deţine (în mod exclusiv sau partajat) acel zavor

Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

16

Blocarea folosind zăvoare binare „ Fie tranzactiile T3,T4, o planificarea serială (a) si planificarile neseriale (b) si (c) ● Daca se foloseste un singur zavor binar pentru toate articolele grupate (XY) si se respecta protocolul de utilizare a zavoarelor, se obtin planificari serializabile (b) ● Daca se folosesc mai multe zavoare, se pot obtine planificari neserializabile (c), chiar daca se respecta protocolul de utiliz. a zavoarelor T3 T4 T3

T3

T4

T4

lock(Y)

read(Y)

lock(XY)

read(Y)

read(X)

read(Y)

unlock(Y)

X=X+Y

read(X)

write(X) read(X)

(a)

lock(X) lock(XY)

X=X+Y

T4 blocata

read(X)

(b)

unlock(X)

read(Y)

write(X)

lock(Y)

Y=X+Y

unlock(XY)

read(Y)

write(Y)

„ Fie: X=20, Y=30:

read(X)

Y=X+Y

read(Y)

write(Y)

Y=X+Y

unlock(Y)

write(Y)

lock(X)

unlock(XY)

read(X)

● planificarile (a) si (b): rezultat corect (X=50, Y=80) ● planificarea neseriala(c): rezultat eronat (X=50,Y=50) Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

(c)

X=X+Y write(X) unlock(X)

17

Protocolul de blocare in doua faze (1) „ Pentru a asigura serializabilitatea planificărilor tranzactiilor care folosesc mai multe zavoare, pe lângă regulile de utilizare a zăvoarelor, mai este necesar să se respecte un protocol privind ordinea operatiilor de blocare şi de eliberare a zăvoarelor, cum este protocolul de blocare in doua faze „ Protocolul de blocare în două faze (two-phase locking) impune ca fiecare tranzactie sa respecte protocolul de utilizare a zavoarelor si toate operaţiile de blocare a zăvoarelor sa preceada prima operaţie de eliberare a unui zăvor „ O astfel de tranzacţie poate fi divizată în două faze: ● faza de creştere (growing phase), în care pot fi achiziţionate noi zăvoare ale articolelor care vor fi accesate, dar nici un zăvor nu poate fi eliberat ● faza de descreştere (shrinking phase), în care zăvoarele deţinute pot fi eliberate, dar nici un alt zăvor nu mai poate fi achiziţionat.

„ S-a demonstrat că, dacă fiecare tranzacţie a unei planificări respectă protocolul de blocare în două faze, atunci planificarea este serializabil㠄 Planificarea tranzacţiilor din figura precedenta (c) nu respectă protocolul de blocare în două faze deoarece: ● T3 eliberează zăvorul articolului Y (unlock(Y) ) înaintea achiziţionării zăvorului pentru scrierea articolului X (lock(X)) ● T4 eliberează zăvorul articolului X (unlock(X) ) înaintea achiziţionării zăvorului pentru scrierea articolului Y (lock(Y))

„ Aceasta planificare este neserializabilă, cu rezultat al execuţiei incorect, aşa cum s-a arătat mai înainte Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

18

Protocolul de blocare in doua faze (2) „ Planificarea din figura alaturata este serializabilă, echivalentă cu planificarea serială T3, T4 (cu rezultat corect X=50, Y=80) „ Daca T3 lansează operaţia de blocare a zăvorului articolului X înaintea tranzacţiei T4, tranzacţia T4 este blocata, asteptând eliberarea zăvorului articolului X, după care efectueaza restul operaţiilor „ Probleme care apar la utilizarea zăvoarelor: ● impasul (deadlock): blocarea execuţiei tranzacţiilor atunci când două sau mai multe tranzacţii se aşteaptă una pe cealălaltă ca să elibereze un zăvor; exista tehnici de prevenire si de eliminare a impasului ● amânarea permanentă (“înfometare”) (livelock, indefinit postponement, starvation): o tranzacţie se află în stare de amânare nedefinită dacă ea nu poate continua execuţia o perioadă lungă de timp, în timp ce toate celelalte tranzacţii se execută normal; prevenirea se face prin asigurarea unei politici echilibrate de obtinere (blocare) a zavoarelor Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

T3

T4

lock(Y) read(Y) lock(X) lock(X) unlock(Y)

T4 blocata

read(X) X=X+Y write(X) unlock(X) read(X) lock(Y) unlock(X) Y=X+Y write(Y) unlock(Y)

19

Controlul concurentei bazat pe marci de timp „ O marcă de timp (timestamp) este un identificator unic al unei tranzacţii, creat de sistemul de gestiune a bazei de date, care se bazează pe timpul de start al tranzacţiei „ O marcă de timp se poate crea: ● fie folosind valoarea curentă a ceasului sistemului de operare ● fie folosind un numărător care este incrementat la fiecare asignare a unei noi mărci, în ordinea de lansare a tranzacţiilor

„ O tranzacţie T va avea o marcă de timp unică, notată TS(T) „ Pentru fiecare articol X al bazei de date se definesc două mărci de timp: ● R_TS(X) - marca de timp de citire a articolului X; este cea mai mare marcă de timp dintre toate mărcile de timp ale tranzacţiilor care au citit articolul X ● W_TS(X) - marca de timp de scriere a articolului X; este cea mai mare marcă de timp dintre toate mărcile de timp ale tranzacţiilor care au scris în articolul X

„ Serializabilitatea planificărilor se obţine dacă se impun anumite condiţii ordinii de accesare a articolelor de mai multe tranzacţii concurente, în funcţie de mărcile de timp ale acestora Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

20

Ordonarea operatiilor după mărcile de timp ■ La lansarea unei operaţii de citire a articolului X (read(X)): ● Dacă TS(T) < W_TS(X), atunci tranzacţia T trebuie să fie abandonată şi rulată înapoi, deoarece o altă tranzacţie cu o marcă de timp mai mare a scris deja în articolul X, înainte ca T să fi avut şansa să citească articolul X ● Dacă TS(T) >= W_TS(X), atunci T va executa operaţia de citire din articolul X şi va seta marca R_TS(X) la cea mai mare dintre valorile TS(T) şi R_TS(X)

■ La lansarea unei operaţii de scriere a articolului X (write(X)): ● Dacă TS(T) < R_TS(X) , atunci tranzacţia T trebuie să fie abandonată şi rulată înapoi, deoarece o altă tranzacţie cu o marcă de timp mai mare (deci lansată după T) a citit deja valoarea lui X, înainte ca T să fi avut şansa să scrie în X ● Dacă TS(T) < W_TS(X), atunci tranzacţia T nu va executa operaţia de scriere, dar va putea continua cu celelalte operaţii. Aceasta, deoarece o altă tranzacţie, cu o marcă de timp mai mare a scris deja o valoare în articolul X, care este mai recentă, iar valoarea pe care ar dori să o înscrie T este deja perimată ● Dacă nu a apărut nici una din situaţiile precedente, atunci T va executa operaţia de scriere în articolul X şi va seta W_TS(X) = TS(T)

■ Ulterior, o tranzacţie T care a fost anulată şi rulată înapoi va fi relansată, dar cu o nouă marcă de timp, corespunzătoare noului moment de lansare ■ Ordonarea după mărcile de timp garantează serializabilitatea planificărilor ■ In acest protocol nu poate sa apara impasul, dar poate apare amânarea indefinită Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

21

Controlul tranzactiilor „ Tehnicile de gestiune a tranzacţiilor şi de refacere a datelor sunt incluse în SGBD-uri, iar aplicaţiile de baze de date au un control limitat asupra tranzacţiilor prin intermediul unor comenzi SQL „ Comenzi SQL pentru tranzacţii: ● SET TRANSACTION: setare optiuni : Nivelul de izolare a tranzacţiilor (ISOLATION LEVEL) Modul de refacere a datelor (SET CONSTRAINTS) Modul de acces la articole - cu valorile posibile READ ONLY, READ WRITE ● COMMIT [WORK] – terminarea tranzactiei ● ROLLBACK [WORK] – abandonarea si rularea inapoi a tranzactiei

Pentru orice nivel de izolare (ISOLATION LEVEL) este interzisa pierderea actualizarilor, dar se admit unele citiri incorecte, asa cum se vede in tabel

Prof. Felicia Ionescu

Nivel de izolare

Citire impropie

Citire nerepetabila

READ UNCOMMITTED

DA

DA

DA

READ COMMITTED

NU

DA

DA

REPEATABLE READ

NU

NU

DA

SERIALIZABLE

NU

NU

NU

Cap. 5 - Gestiunea tranzactiilor

Citire fantoma

22

Exemplu de tranzactie in MySQL (1) „ In mod MySQL o tranzactie se lanseaza cu comanda START TRANSACTION „ Fie baza de date ZBORURI cu tabelele descrise la inceputul capitolului:

■ Se defineste o tranzactie pentru rezervarea unui loc la o cursa aeriana in procedura stocata sp_rezervari() ■ Daca tabelul CURSE contine linia (1, ‘Bucuresti’, ‘Paris’, 2008-12-30,1) si se apeleaza: sp_rezervari(@rez, 100, ‘Ionescu’, ‘Ion’, ‘Craiova’, ‘Bucuresti’, ‘Paris’, ‘2009-12-30’, 500) atunci: ● Se obtine @rez=1 (executie corecta) ● NrLocuriLibere in tabelul CURSE este decrementat cu 1 (mai sunt 0 locuri) ● Tabelul PASAGERI va contine si linia (100, ‘Ionescu’, ‘Ion’, ‘Craiova’) ● Tabelul FACTURI va contine si linia: (1, 100,1,’2008-12-28’,500)

■ Daca se incearca inca o rezervare, se obtine @rez=0 si nicio modificare in tabele (s-a executat rollback) Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

23

Exemplu de tranzactie in MySQL (2) DELIMITER $$ DROP PROCEDURE IF EXISTS `zboruri`.`sp_rezervari` $$ CREATE PROCEDURE `zboruri`.`sp_rezervari`(OUT rezultat INT, s_pasager INT, s_nume varchar(20), s_prenume varchar(20), s_adresa varchar(20), plecare varchar(20), sosire varchar(20), s_data date, s_pret decimal) BEGIN DECLARE l_cursa, l_locuri INT; SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; SET autocommit = 0; START TRANSACTION; INSERT INTO PASAGERI values(s_pasager, s_nume, s_prenume, s_adresa); SELECT IdCursa, NrLocuriLibere INTO l_cursa, l_locuri FROM CURSE WHERE AeroportPlecare=plecare AND AeroportSosire=sosire AND DataCursa = s_data; IF l_locuri > 0 THEN BEGIN UPDATE CURSE SET NrLocuriLibere = l_locuri - 1; INSERT INTO FACTURI(IdPasager,IdCursa, DataFactura,Pret) values (s_pasager, l_cursa, CURDATE(), s_pret); COMMIT; SET rezultat = 1; END; ELSE BEGIN ROLLBACK; SET rezultat = 0; END; END IF; END $$ DELIMITER ; Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

24

Proiectarea tranzactiilor ■ Tranzacţiile sunt corecte dacă lasă baza de date într-o stare consistentă ■ Tranzacţiile sunt cu atât mai eficiente cu cât sunt mai scurte (ca timp de execuţie şi ca număr de articole ale bazei de date accesate) deoarece astfel: ● se limiteaza frecvenţa de apariţie a impasului (în cazul folosirii zăvoarelor) ● creste eficienţei operaţiilor de anulare şi de blocare a resurselor

■ Ori de câte ori se poate înlocui o tranzacţie complexă, cu număr mare de operaţii şi timp de execuţie ridicat, cu mai multe tranzacţii scurte, este indicat să se facă această transformare ■ De asemenea, pentru menţinerea tranzacţiilor cât mai scurte posibil, se recomandă ca o tranzacţie să nu fie pornită până ce nu au fost pregătite toate datele (citirea datelor de intrare, parcurgerea, analiza şi prelucrarea acestora) ■ Toate operaţiile de gestiune a tranzacţiilor şi de refacere a datelor sunt prevăzute în diferitele componente ale sistemelor SGBD (administratorul de tranzacţii, administratorul de refacere), iar aplicaţiile: ● trebuie să se prevadă tranzacţii corecte ● pot selecta diferite opţiuni de control al tranzacţiilor şi de refacere a datelor oferite de sistemul de gestiune respectiv Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

25

Tehnici de refacere a bazelor de date „ Refacerea unei baze de date după producerea unui defect (database recovery) înseamnă aducerea bazei de date într-o stare precedentă corectă, din care, eventual, se poate reconstrui o nouă stare corectă şi cât mai apropiată de momentul apariţiei defectului „ Tehnicile de refacere a bazelor de date sunt, în general, integrate cu tehnicile de control al concurenţei si depind de SGBD „ Pentru operaţiile de refacere se foloseşte fişierul jurnal (log file), şi (sau) o copie de rezervă a bazei de date (database backup) stocată în general pe bandă magnetic㠄 Un punct de validare (commit point) este punctul atins de o tranzacţie care a executat cu succes toate operaţiile sale şi le-a înregistrat în fişierul jurnal ● Într-un astfel de punct, o tranzacţie T înscrie în fişierul jurnal operaţia [commit,T] şi, de asemenea, trebuie să scrie blocul din bufferul de scriere în fişierul jurnal

„ Un punct de control (checkpoint) este înscris în fişierul jurnal atunci când se scriu în fişierele bazei de date toate rezultatele operaţiilor de scriere ale tranzacţiilor validate ● Aceasta înseamnă că toate tranzacţiile care au înregistrarea [commit,T] înscrisă în fişierul jurnal înaintea unui punct de control nu vor necesita reluarea operaţiilor de scriere în cazul unei defectări a sistemului

„ Administratorul de refacere al SGBD-ului (recovery manager) decide la ce interval de timp (sau după câte tranzacţii) introduce un nou punct de control Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

26

Refacerea datelor dupa defecte necatastrofice „ Dacă baza de date nu este distrusă fizic, dar a devenit inconsistentă datorită unui defect necatastrofic, atunci strategia de refacere constă în: ● anularea modificărilor care au produs inconsistenţa (prin operaţii undo) ● executarea din nou a modificărilor care s-au pierdut (prin operaţii redo)

„ În acest caz nu este necesară copia de rezervă, ci se foloseşte starea actuală a bazei de date şi fişierul jurnal „ Exista două tehnici de refacere a datelor dupa defecte necatastrofice: ● Refacerea cu actualizare amânată (deferred update) ● Refacerea cu actualizare imediată (immediate update)

■ Pentru refacerea cu actualizare amanata se executa urmatoarele operatii: ● Se parcurge fişierul jurnal în sens invers, începând de la ultima înregistrare, până se întâlneşte primul punct de control ● Se construieste o listă a tranzacţiilor validate, în care se introduc toate tranzacţiile T care au o înregistrare de tipul [commit,T] în fişierul jurnal între punctul de control considerat şi sfârşitul fişierului jurnal, ● Se construieste o listă a tranzacţiilor nevalidate, în care se introduc toate tranzacţiile T’ care au o înregistrare de start ([begin,T’]) în fişierul jurnal, dar nu au şi înregistrarea corespunzătoare de validare. ● După aceasta, se execută reluarea (REDO) tuturor operaţiilor de scriere (write(X)) ale tranzacţiilor validate, în ordinea în care apar în fişierul jurnal, iar tranzacţiile nevalidate sunt relansate Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

27

Refacerea cu actualizare imediata „ In tehnicile de refacere cu actualizare imediată, atunci când o tranzacţie lansează o comandă de actualizare a bazei de date, actualizarea este efectuată imediat, fără să se mai aştepte ajungerea la un punct de validare „ In majoritatea acestor tehnici se impune ca modificarea să fie mai întâi memorată în fişierul jurnal (pe disc), înainte de a fi aplicată bazei de date; această regulă este cunoscută sub numele de “protocol de scriere în avans a fişierului jurnal” (write-ahead log protocol) „ Dacă se admite actualizarea imediată, atunci la refacere trebuie să se poată anula (prin operaţii undo) modificările efectuate de o tranzacţie, dacă aceasta eşuează ulterior din diferite motive „ In felul acesta se efectueaza rularea înapoi (rollback) a tranzacţiei „ Tehnica de refacere cu actualizare imediată are avantajul simplităţii operaţiilor de scriere, care se efectuează direct în baza de date, fără să fie necesar să se aştepte atingerea unui punct de validare pentru transferarea datelor în baza de date „ Dezavantajul acestei metode este faptul că pot apare anulări în cascadă, care necesită operaţii complicate de refacere Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

28

Refacerea datelor dupa defecte catastrofice „ Dacă baza de date a fost puternic distrusă datorită unei defectări serioase a discului, atunci se restaurează starea bazei de date din copia de rezervă a bazei de date (database backup) „ Ultima copie salvată se încarcă de pe bandă pe disc (după ce acesta a fost înlocuit sau reparat) şi sistemul este repornit „ Totuşi, tranzacţiile efectuate de la ultima operaţie de salvare până în momentul apariţiei defectului se pierd „ Deoarece fişierul jurnal este mult mai mic decât fişierele bazei de date, se obişnuieşte ca acesta să fie salvat mai des decât baza de date însăşi şi să fie iniţializat la fiecare operaţie de salvare a bazei de date „ In această situaţie, după încărcarea ultimei copii salvate a bazei de date se foloseşte fişierul jurnal pentru a reface toate tranzacţiile validate existente în copia salvată a fişierului jurnal (care este mai recentă decât copia salvată a bazei de date)

Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

29

Prof. Felicia Ionescu

Cap. 5 - Gestiunea tranzactiilor

30

Capitolul 6: Normalizarea relatiilor „ Dependentele de date si formele normale ale relatiilor „ Redundanta datelor si anomaliile de actualizare a relatiilor „ Dependentele functionale (DF) ● Tipuri de DF ● Multimi de DF ● DF si cheile relatiilor

„ Descompunerea relatiilor ● Descompunere fara pierdere de informatie la jonctiune ● Descompunere cu conservarea DF

„ Formele normale ale relatiilor determinate de DF: ● FN1 ● FN2 ● FN3 ● FNBC

„ Dependente multivalorice – forma normala FN4 „ Dependente de jonctiune – forma normala FN5 Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

1

Dependentele de date „ Dependenţele de date (data dependencies) reprezintă constrângeri care se impun valorilor atributelor unei relaţii şi care determină proprietăţile relaţiei în raport cu operaţiile de inserare, ştergere şi actualizare a tuplurilor. „ O formă normală a unei relaţii (normal form) presupune anumite condiţii pe care le îndeplinesc valorile atributelor şi dependenţele de date definite pe acea relaţie „ Dependentele de date: ● Dependente functionale: E.F. Codd a propus trei forme normale: FN1, FN2, FN3; apoi a fost introdusă forma normală Boyce-Codd (FNBC) ● Dependenţelor multivalorice: forma normala 4 (FN4) ● Dependenţelor de joncţiune: forma normala 5 (FN5)

„ Formele normale ale relaţiilor formează o colecţie ordonată (FN1, FN2, FN3, FNBC, FN4, FN5), şi ele impun condiţii din ce în ce mai restrictive asupra dependenţelor de date „ Ordonarea formelor normale de la FN1 la FN5 înseamnă că orice relaţie aflată în FN2 este în FN1, orice relaţie în FN3 este în FN1 şi FN2 etc. „ Normalizarea relaţiilor (normalization) constă în descompunerea lor, astfel încât relaţiile să fie in forme normale cât mai avansate Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

2

Redundanta datelor si anomaliile de actualizare „ In relatia AP, cu cheia primara PK={IdAngajat, IdProiect} sunt valori redundante ale atributelor: Nume, prenume, Adresa ● Anomalii de inserare: nu se pot introduce date despre un angajat (numele, prenumele, adresa) dacă nu există cel puţin un proiect la care acesta să lucreze ● Anomalii de ştergere: dacă se şterg toate tuplurile referitoare la un anumit proiect, se pot pierde toate datele referitoare la acei angajaţi care lucrează doar la proiectul respectiv ● Anomalii de actualizare: dacă se modifică într-un tuplu valoarea unuia din atributele care au valori redundante, starea relaţiei poate deveni inconsistentă IdAngajat

Nume

Prenume

Adresa

IdProiect

Ore

1

Ionescu

Ion

Bucuresti

P1

100

2

Popescu

Petre

Ploiesti

P1

80

3

Marinescu

Marin

Craiova

P3

200

1

Ionescu

Ion

Bucuresti

P2

100

2

Popescu

Petre

Ploiesti

P3

120

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

3

Eliminarea anomaliilor datorate redundantei „ Eliminarea anomaliilor provocate de redundanta datelor se poate face: ● Fie prin prevederea unor proceduri stocate (sau triggere) care sa verifice corectitudinea fiecarei operatii de actualizare a relatiilor ● Fie prin descompunerea relatiilor care prezinta redundante in relatii mai simple; exemplu: descompunerea relatiei AP in 2 relatii, A si P A P IdAngajat Nume

Prenume

Adresa

IdAngajat

IdProiect Ore

1

Ionescu

Ion

Bucuresti

1

P1

100

2

Popescu

Petre

Ploiesti

2

P1

80

3

Marinescu Marin

Craiova

3

P1

200

1

P2

100

2

P2

120

„ Relatiile A si P au un grad de normalizare mai ridicat si nu mai au anomalii „ Dar unele interogari sunt mai ineficiente in A si P decat in AP z Exemplu: “Care este numărul de ore lucrate de Ionescu la proiectul P1 ?”: Q1 = Π Ore σ Nume ='Ionescu' AND IdProiect ='P1‘ (AP) Q2 = Π Ore σ Nume ='Ionescu' AND IdProiect ='P1‘ (A P) Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

4

Dependente functionale (1) „ Dependentele funcţionale (functional dependencies) sunt constrangeri in relatii, prin care valoarea unui anumit set de atribute determina in mod unic valoarea altor atribute „ Fie R o schema de relatie si doua submultimi ale atributelor sale: X ⊆ R and Y ⊆ R . Dependenta functionala (DF) X → Y exista in R daca si numai daca pentru orice stare a relatiei r(R), egalitatea valorilor atributelor X din doua tupluri t1 si t2 din r (t1 ∈ r si t2 ∈ r) implica egalitatea valorilor atributelor Y din acele tupluri, adica: t1[X] = t2 [X] ⇒ t1[Y ] = t2 [Y ] „ Atributul din stânga se numește determinant, cel din dreapta, determinat „ Dependentele functionale sunt generalizarea notiunilor de chei ale relatiilor: orice cheie determina o DF in acea relatie ● Daca Y = R, atunci X este o cheie a relatiei ● Reciproc, daca X este o cheie, Y = R (X → R) ● In acest caz t1[X] = t2 [X] ⇒ t1 = t2 ,dar, cum intr-o relatie nu pot exista doua tupluri identice, rezulta ca t1 si t2 sunt unul si acelasi tuplu

„ Cheile relaţiilor: „ se pot preciza explicit (şi atunci ele implică DF corespunzătoare) „ pot fi deduse din mulţimea DF stabilite de proiectant, folosind diferiti algoritmi Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

5

Dependenţe funcţionale (2) „ O multime F de dependente functionale in R defineste constrangerile pe care trebuie sa le respecte orice relatie r(R) pentru a fi legala (corecta) ● Se spune ca F se mentine in R daca toate relatiile legale pe R ( r(R)) satisfac multimea de dependente functionale F ● Reciproc, o relatie r este legala in raport cu o multime de dependente functionale F, daca r satisface F

„ Proiectantul bazei de date specifică acele DF pe care le doreste să fie respectate și care sunt evidente din punct de vedere semantic; „ De exemplu, în relația AP se pot defini DF: a) IdAngajat →Nume (b) IdAngajat →Prenume (c) IdAngajat →Adresa (d) {IdAngajat, IdProiect} →Ore

„ Primele 3 impun ca un identificator IdAngajat să identifice un singur angajat, iar ultima impune ca un angajat efectuează un anumit numar de ore la fiecare din proiectele la care lucrează Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

6

Tipuri de dependenţe funcţionale „ Atributele care aparţin unei chei se numesc atribute prime, iar celelalte se numesc atribute neprime „ Dependenţe funcţionale triviale si ne-triviale ● O dependenta functională este trivială daca este satisfacuta de orice stare a relatiei; in general X → Y este triviala daca Y este o submultime (proprie sau nu) a lui X, adică Y ⊆ X; ex. {IdAngajat, IdProiect} → IdAngajat sau Nume → Nume ● Celelalte dependente (in care Y nu este o submultime a lui X) sunt netriviale; ex: IdAngajat → Nume

„ Dependenţele funcţionale parţiale si totale ● O dependenţă funcţională X →Y este parţială dacă există o submulţime proprie Z a lui X (Z ⊂ X și Z ≠X) care determină funcţional pe Y (Z → Y); ex: {IdAngajat,IdProiect} → Nume este partiala deoarece IdAngajat → Nume ● O dependenţă funcţională X → Y este totală, dacă nu există nici o submulţime proprie Z a lui X care să determine funcţional pe Y ● Cazuri particulare: ● dacă atributul X este simplu, dependenţa funcţională X → Y este totală; ex: IdAngajat → Nume ● dacă X este o cheie candidată a lui R, atunci dependenţa X → Y este totală; ex: {IdAngajat, IdProiect} → Ore Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

7

Multimi de dependente functionale (1) „ „

Dintr-o mulțime dată de DF se pot deduce si alte DF, folosind regulile de deducere (inferenţă - inference rules) ale lui Armstrong: 1. Reflexivitatea (reflexivity): dacă Y ⊆ X, atunci X →Y; prin această regulă se deduc DF triviale; de ex. în relaţia AP în care au fost definite DF: (a) IdAngajat →Nume (b) IdAngajat →Prenume (c) IdAngajat →Adresa (d) {IdAngajat,IdProiect} →Ore

se pot deduce prin reflexivitate si DF: (e) {IdAngajat, IdProiect} →IdAngajat (f) {IdAngajat, IdProiect} →IdProiect

„

2. Augmentarea (augmentation): dacă X →Y, atunci (X ∪ Z) → (Y ∪ Z); următoarele DF (g şi h) sunt deduse prin augmentare, pornind de la dependenţele funcţionale (a) şi respectiv (b), augmentate cu Z = {Nume}, respectiv Z = {Prenume} (se stie ca Nume ∪ Nume = Nume etc.) (g) {IdAngajat, Nume} →Nume (h) {IdAngajat, Prenume} →Prenume

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

8

Multimi de dependente functionale (2) „

3. Tranzitivitatea (transitivity): dacă X→Y şi Y→Z, atunci X→Z. De exemplu, din DF (e) şi (a) rezultă: {IdAngajat,IdProiect} →Nume

„ „

Aceste trei reguli sunt suficiente pentru calculul tuturor dependenţelor funcţionale pe care le implică o mulţime dată de DF Din aceste reguli de bază se pot deduce şi alte reguli; de exemplu: Proiecţia (projection): dacă X→(Y ∪ Z), atunci X→Y şi X→Z Reuniunea (union): dacă X→Y şi X→Z, atunci X→(Y ∪ Z) Pseudo-tranzitivitatea (pseudo-transitivity): dacă X→Y şi (W ∪ Y) →Z, atunci (W ∪ X) →Z.

„

Reprezentarea dependentelor functionale: Nume IdAngajat IdProiect

Prenume Adresa Ore

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

9

Inchiderea unei multimi de DF „ Fiind dată o mulţime F de DF, mulţimea tuturor DF care sunt implicate de F se numeşte închiderea mulţimii F (closure set of F) şi se notează F+ ● F+ se poate deduce prin aplicarea repetată a regulilor de inferenţă asupra DF din F ● Pentru a testa daca o DF X→Y poate fi dedusă dintr-o mulţime F de DF, se afla închiderea F+ a mulţimii F şi se testează dacă (X→Y)∈F+ ● Două mulţimi de DF, E şi F sunt echivalente dacă închiderile lor sunt egale (E+ = F+); adica: ∀DF ∈ E ⇒ DF ∈ F+ şi ∀DF ∈ F ⇒ DF ∈ E+

„ O mulţime G de DF este minimă dacă satisface următoarele condiţii: ● membrul drept al oricărei DF din G este un atribut simplu; ● orice dependenţă funcţională din G este totală; ● mulţimea G este ireductibilă, adică, dacă se exclude o DF din G, mulţimea rezultată H nu este echivalentă cu G (adică H+ ≠ G+).

„ Acoperirea minimă a unei mulţimi F de DF (minimal cover of a set F of DFs) este o mulţime minimă de dependenţe funcţionale G care este echivalentă cu F, adică G+ = F+ ● Pot exista mai multe acoperiri minime ale unei mulţimi de DF

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

10

Dependenţele funcţionale şi cheile relaţiilor „ In orice relaţie pot exista două categorii de DF: ● DF determinate de cheile (candidate) ale relaţiei; astfel de DF nu produc redundanţa datelor şi nici anomalii de actualizare a relaţiei; de ex. {IdAngajat, IdProiect} → Ore ● DF în care atributul determinant nu este o cheie a relaţiei; astfel de DF produc redundanţa datelor şi anomalii de actualizare a relaţiei; de ex. IdAngajat → Nume

„ DF determinate de cheile candidate sunt constrângeri implicite, conţinute în definiţia relaţiei şi sunt verificate şi impuse automat de SGBD ● Proiectantul bazei de date nu trebuie să prevadă nimic suplimentar pentru ca aceste constrângeri să fie satisfăcute de orice stare a relaţiei

„ DF în care atributul determinant nu este o cheie sunt constrângeri explicite, care nu sunt verificate şi nici impuse de SGBD „ Pentru DF în care atributul determinant nu este o cheie, se aplica una din urmatoarele solutii: (a) Se accepta astfel de DF, dar se asigura verificarea şi impunerea lor procedurala, prin triggere, proceduri stocate, sau funcţii în programele de aplicaţii (b) Se descompune relatia in relatii mai simple, in care nu mai exista astfel de DF, dar trebuie făcută o descompunere “corecta” (cel puțin fără pierdere de informație la joncțiune sau, dacă se poate, reversibilă) Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

11

Inchiderea unui atribut fata de o multime de DF (1) „ Închiderea unui atribut faţă de o mulţime F de DF (the closure of an atribute under F). Fie un atribut X al unei relaţii pe care este definită mulţimea F de DF; mulţimea X+ a tuturor atributelor determinate de X (X→X+) se numeşte închiderea lui X în raport cu F „ Algoritmul prin care se poate deduce inchiderea unui atribut: 1. se setează X+ = X și P_F = F 2. repetă se extrage o DF Y→Z din P_F (adica se alege o DF Y→Z din P_F si se seteaza P_F = P_F – (Y→Z) ) dacă Y ⊆ X+ atunci X+ = X+ ∪ Z până când P_F = ∅

„ Se aplică acest algoritm pentru dependenţele funcţionale din relatia AP: FAP = {IdAngajat → Nume, IdAngajat → Prenume, IdAngajat → Adresa, {IdAngajat, IdProiect} → Ore}

„ Se obtin inchiderile atributelor astfel: {IdAngajat}+ = {IdAngajat, Nume, Prenume, Adresa} {IdAngajat, IdProiect}+ = {IdAngajat, IdProiect, Nume, Prenume, Adresa, Ore} {Nume}+ = {Nume}, {Prenume}+ = {Prenume}, {IdProiect}+ = {IdProiect}; {Adresa}+ = {Adresa}, {Ore}+ = {Ore} Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

12

Inchiderea unui atribut fata de o multime de DF (2) ■ Din algoritmul de mai sus se poate deduce că închiderea unui atribut care nu determină funcţional nici un alt atribut (nu apare în partea stângă a nici unei DF) este chiar atributul respectiv: {Nume}+ = {Nume}, {Prenume}+ = {Prenume}, {Adresa}+ = {Adresa}, {Ore}+ = {Ore}

■ Acest algoritm poate fi folosit pentru a verifica dacă o DF dată X→Y este consecinţa logică a mulţimii F (daca (X→Y) ∈ F+) ■ Pentru aceasta, se calculează X+ faţă de F; dacă Y ⊆ X+, atunci (X→Y)∈ F+, deci X→Y este consecinţa logică a lui F

■ Acest algoritm poate fi folosit şi pentru a verifica dacă un atribut K (simplu sau compus) este supercheie a relaţiei R cu mulţimea F de DF ■ Pentru aceasta se calculează K+ în raport cu F; daca K+ = R, atunci K este supercheie în R

■ Pentru aflarea cheilor candidate ale unei relaţii din mulţimea DF: ■ se consideră o supercheie a relației ■ se testeaza condiţia de ireductibilitate pentru fiecare din atributele componente ale supercheii si se elimină orice atribut care poate fi eliminat fără să se piardă proprietatea de unicitate a cheii

■ Acest algoritm de aflare a cheilor candidate ale unei relaţii din mulţimea DF este prezentat in continuare Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

13

Aflarea cheilor unei relaţii din multimea DF ■ Fiind dată o relaţie cu schema R şi mulţimea F a DF pe această relaţie, cheile candidate K ale relaţiei se pot afla cu urmatorul algoritm: 1. Se setează supercheia K = R 2. Pentru fiecare atribut X din K se testeaza daca (K – X) este supercheie în R 3. Dacă (K – X) este supercheie, atunci K = (K – X), altfel K nu se modifica

■ Prin parcurgerea repetată a paşilor 2 şi 3, se găseşte una din cheile candidate ale relaţiei; dacă există mai multe chei candidate, atunci ordinea găsirii cheilor candidate depinde de atributul selectat în pasul 2 al algoritmului ■ De exemplu, se aplică algoritmul de mai sus pentru găsirea unei chei candidate a relaţiei AP cu mulţimea FAP a DF (definita la inceputul capitolului) ■ Se porneşte cu K = R = {IdAngajat, Nume, Prenume, Adresa, IdProiect, Ore}, se selectează X = Nume; ● {K – X} = {IdAngajat, Prenume, Adresa, IdProiect, Ore} ● {K – X}+ = {IdAngajat, Nume, Prenume, Adresa, IdProiect, Ore} = R, ● deci K - X este supercheie in R, deci se repetă pașii 2 și 3 pentru alte atribute

■ Se repeta pasii 2 si 3 pentru X = Prenume, apoi X = Adresa si X = Ore; aceste atribute pot fi eliminate, si se obtine K = {IdAngajat, IdProiect} ■ Atributele IdProiect, IdAngajat nu se pot elimina din K, deci {IdProiect, IdAngajat} e cheie candidată (chiar primară) Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

14

Descompunerea relatiilor „ O descompunere D = {R1, R2,..Ri,...Rk} a schemei de relaţie R (relation schema decomposition) este formată din submulţimi proprii ale lui R (R1⊂ R, R2⊂ R,…Rk⊂ R a caror reuniune este egala cu R (R = R1∪ R2…∪ Rk) „ Proiectiile relatiei r(R) pe submultimile R1, R2,...Ri, …Rk (r1 = ΠR1(r), r2 = ΠR2(r), ….. ri = ΠRi(r),… rk = ΠRk(r)) reprezinta descompunerea relaţiei r(R) pe aceste submulţimi de atribute „ Fie o relaţie cu schema R şi mulţimea F de DF ale acesteia; o descompunere a relaţiei r(R) este reversibilă dacă are proprietăţile de: ● Conservarea informatiei (descompunere fără pierdere de informaţie la joncţiune) inseamna ca r = r1  r2  …ri  …rk ● Conservarea dependenţelor funcţionale: dacă oricare din dependenţele din F se regăseşte sau poate fi dedusă din DF ale relaţiilor cu schemele R1,R2,...Ri,…Rk

„ Teorema lui Ullman. Descompunerea D = {R1, R2} a unei scheme de relaţie R este o descompunere fără pierdere de informaţie la joncţiune în raport cu mulţimea F de DF, dacă şi numai dacă este îndeplinită una din condiţiile: (a) ((R1 ∩ R2) → (R1 - R2)) ∈ F+, sau (b) ((R1 ∩ R2) → (R2 - R1)) ∈ F+ ● Dacă R1 ∩ R2 este o supercheie a uneia dintre relaţiile R1 sau R2, atunci descompunerea este fără pierdere de informaţie la joncţiune; ● Demonstratie: dacă (R1 ∩ R2) este o supercheie în R1, atunci ea determina functional orice submultime de atribute din R1, inclusiv (R1 - R2) adică (R1 ∩ R2) →(R1 - R2); ● La fel se demonstreaza daca (R1 ∩ R2) este o supercheie în R2 Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

15

Descompunere fără pierdere de informație la jonctiune „ Lipsa acestei proprietăţi se manifestă în mod paradoxal prin apariţia unor tupluri noi (parazite) în relaţia obţinută prin joncţiunea relaţiilor r1,r2,...ri,...rk, tupluri care nu existau în relaţia r(R) „ Exemplu: descompunerea relaţiei AP în relaţiile A şi P: A ∩ P = {IdAngajat}, A − P = {Nume,Prenume,Adresa}; P − A = {IdProiect,Ore} Din DF IdAngajat→Nume, IdAngajat→Prenume, IdAngajat→ Adresa Se deduce: IdAngajat→{Nume, Prenume, Adresa} (cf. regulii de reuniune a DF) Rezultă: ((A ∩ P)→(A − P))∈ F+ Deci, conform teoremei lui Ullman desc. este fără pierdere de informaţie la joncţiune

„ Descompunerea succesivă fără pierdere de informaţie la joncţiune ● Dacă o descompunere D = {R1,R2,...Ri,...Rk} a unei scheme R este fără pierdere de informaţie la joncţiune în raport cu mulţimea F de DF ● şi D1 = {Q1,Q2,...Qm} este o descompunere fără pierdere de informaţie la joncţiune a lui R1 în raport cu proiecţia lui F pe R1, ● atunci descompunerea D2 = {Q1,Q2,...Qm,R2,...Rk} este o descompunere fără pierdere de informaţie a lui R în raport cu F

„ Această proprietate permite descompunerea fără pierdere de informaţie la joncţiune a unei relaţii în mai multe etape (mai întâi in două relaţii, apoi fiecare dintre acestea se descompune în alte două relaţii, ş.a.m.d) Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

16

Conservarea dependenţelor funcţionale „ O descompunere D = {R1, R2, ...Ri,...Rk} a unei scheme de relaţie R prezintă proprietatea de conservare a mulţimii F de DF, dacă reuniunea proiecţiilor lui F pe schemele de relaţii Ri (unde 1 ≤ i ≤ k) este echivalentă cu F, adică: ((ΠR1(F)) ∪ (ΠR2(F)) ... ∪ (ΠRk(F)))+ = F+ „ Proiecţia unei mulţimi de dependenţe funcţionale. Fiind dată mulţimea F de DF definite pe R, şi o descompunere D = {R1,R2,..Rk} a lui R, proiecţia lui F pe Ri (unde 1 ≤ i ≤ k), notată ΠRi(F), este mulţimea de DF X→Y ∈ F+, astfel încât X ⊆ Ri şi Y ⊆ Ri „ Exemplu: descompunerea relaţiei AP in relaţiile A şi P: FAP = {IdAngajat→Nume, IdAngajat→Prenume, IdAngajat→Adresa,{IdAngajat,IdProiect}→Ore} Proiecţiile mulţimii FAP pe A si P sunt: ΠA(FAP) = {IdAngajat→Nume, IdAngajat→Prenume, IdAngajat→Adresa} ΠP(FAP) = {{IdAngajat,IdProiect}→Ore} Dat fiind că ΠA(FAP)∪ ΠP(FAP) = FAP, rezultă că această descompunere conservă DF

„ Dacă, prin descompunerea unei relaţii, se pierd una sau mai multe DF, pentru verificarea lor, trebuie să se efectueze mai întâi joncţiunea relaţiilor obtinute „ Cele două proprietăţi ale unei descompuneri, conservarea informaţiei şi conservarea dependenţelor funcţionale, sunt independente Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

17

Formele normale ale relatiilor (FN1 si FN2) „ O relaţie este normalizată în prima formă normală (FN1) dacă fiecare atribut ia numai valori atomice şi scalare din domeniul său de definiţie ● Sistemele SGBD relaţionale nu admit relaţii care să nu fie cel puţin în FN1, dar proiectarea relaţiilor normalizate în FN1 este intotdeauna posibila

„ Fie o schema de relatie R si multimea F de DF definite pe aceasta. O relaţie r(R) este normalizată în FN2, dacă este în FN1 şi dacă în F+ nu există nici o DF parţială a unui atribut neprim faţă de o cheie a relaţiei „ Exemplu: relatia AP cu multimea FAP de DF este in FN1, dar nu este in FN2:

● ● ● ●

FAP = {IdAngajat → Nume, IdAngajat → Prenume, IdAngajat → Adresa, {IdAngajat, IdProiect} → Ore} Cheia primara este {IdAngajat, IdProiect}, deci {IdAngajat, IdProiect}→Nume Această DF se poate deduce din FAP; cf. reflexivitatii, {IdAngajat, IdProiect} → IdAngajat; cf.tranzitivitatii, daca IdAngajat→Nume, {IdAngajat, IdProiect}→Nume DF {IdAngajat, IdProiect}→Nume este parţială deoarece exista: IdAngajat→Nume Rezultă că relaţia AP nu este în FN2, deci prezinta redundante si anomalii

„ Anomaliile se pot evita prin (a) normalizare sau (b) prin impunerea DF „ Normalizarea relatiei AP prin descompunere in relatiile A si P: ● A(IdAngajat, Nume, Prenume, Adresa) ● P(IdAngajat, IdProiect, Ore), ● S-a demonstrat ca aceasta descompunere prezinta proprietatile de jonctiune fara pierdere de informatie si conservarea DF si se poate arata ca A si P sunt in FN2 Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

18

Impunerea DF in relatia nenormalizata AP (1) „ Dacă relaţia AP nu se normalizează, atunci trebuie să se prevadă proceduri speciale care să impună DF care nu sunt determimate de chei „ De exemplu, daca la inserare nu se admit doi sau mai mulţi angajaţi cu acelasi identificator (IdAngajat) dar cu nume, prenume, adresă diferite se defineste urmatorul trigger (trigger_AP) „ Trigger-ul trigger_AP arata astfel: DELIMITER $$ DROP TRIGGER IF EXISTS `normalizare`.`trigger_AP`$$ CREATE TRIGGER `trigger_AP` BEFORE INSERT ON `normalizare`.`AP` FOR EACH ROW BEGIN DECLARE done INT DEFAULT 0; DECLARE error INT DEFAULT 0; DECLARE l_nume, l_prenume, l_adresa VARCHAR(20); DECLARE cursor_AP CURSOR FOR SELECT Nume, Prenume, Adresa FROM AP WHERE IdAngajat = NEW.IdAngajat; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1; OPEN cursor_AP; REPEAT FETCH cursor_AP INTO l_nume, l_prenume, l_adresa; IF NEW.Nume l_nume OR NEW.Prenume != l_prenume OR NEW.Adresa l_adresa THEN SET error = 1; END IF; UNTIL done = 1 OR error = 1 END REPEAT; CLOSE cursor_AP; IF error = 1 THEN SET NEW.IdAngajat = NULL; END IF; END $$ DELIMITER ;

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

19

Impunerea DF in relatia nenormalizata AP(2) „ Trigger-ul este de tip BEFORE INSERT, astfel ca linia dorita se insereaza in tabel numai daca verificarile facute de trigger permit inserarea „ In trigger se citesc intr-un cursor toate liniile care au valoarea atributului IdAngajat egală cu valoarea de inserat (NEW.IdAngajat) „ Se parcurg liniile cursorului si daca valorile de inserat ale atributelor Nume, Prenume, Adresa (NEW.Nume, NEW.Prenume, NEW.Adresa) difera de cele existente in tabel, se seteaza error = 1. Daca dupa parcurgerea cursorului: „ error = 0, se termină triggerul (instructiunea END), apoi se introduce linia noua „ error=1, se seteaza SET NEW.IdAngajat = NULL, apoi se termină triggerul (instructiunea END); după aceasta SGBD-ul nu va introduce linia noua deoarece un atribut al cheii primare este NULL (IdAngajat)

„ Exemplu: ● Fie tabelul AP cu liniile (1,’Ionescu’,’Ion’, ’Bucuresti’,1,50), (1,’Ionescu’,’Ion’, ’Bucuresti’,2,100) si (1,’Ionescu’,’Ion’,’Bucuresti’,3,80) ● Se observa redundanta datelor: valorile ‘Ionescu’, ‘Ion’, ‘Bucuresti’ sunt memorate pentru fiecare proiect la care lucreaza angajatul cu IdAngajat = 1 ● Anomalia de inserare: daca nu se activeaza trigger-ul, se poate insera si linia (1,’Marinescu’,’Mihai’,’Bucuresti’,4,60), ceea ce inseamna ca angajatul cu IdAngajat =1 este nedeterminat (este Ionescu Ion sau Marinescu Mihai?) ● Aceasta linie nu se poate insera daca s-a activat trigger-ul trigger_AP Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

20

A treia forma normala (FN3) „ Fie o schema de relatie R si multimea F de DF definite pe aceasta. O relaţie r(R) este normalizată în FN3, dacă este în FN2 şi dacă oricare DF din F+ a unui atribut neprim este determinata de o cheie a relatiei „ Exemplu: AFS(IdAngajat, Nume, Prenume, Adresa, Functie, Salariu) FAFS={IdAngajat→Nume, IdAngajat→Prenume, IdAngajat →Adresa, IdAngajat→Functie, Functie→Salariu}. ● Cheia primară a relaţiei este IdAngajat, şi poate fi dedusă din FAFS ● DF față de cheia primară (primele patru DF) sunt totale, deci relaţia este în FN2 ● Relaţia nu este în FN3 datorita DF Functie→Salariu; prezinta redundante si anomalii

„ Normalizare prin descompunere in: AF(IdAngajat, Nume, Prenume, Adresa, Functie) FS(Functie, Salariu)

„ Se demonstreaza ca AF si FS sunt in FN3 si ca descompunerea este reversibila ● Proiectiile multimii FAFS: FAF={IdAngajat→Nume,IdAngajat→Prenume,IdAngajat →Adresa,IdAngajat→Functie} FFS = {Functie→Salariu} si se deduc (sau se verifica) cheile relatiilor ● PKAF={IdAngajat}, PKFS={Functie}, deci AF si FS sunt in FN3 ● FAF ∪ FFS = FAFS deci descompunerea conserva DF ● AF ∩ FS = {Functie} si ( Functie → Salariu) ∈ FAFS, deci, cf. regulii lui Ullman, descompunerea este fara pierdere de informatie la jonctiune Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

21

Impunerea DF in relatia nenormalizata AFS (1) „ Dacă relaţia AFS nu se normalizează, atunci trebuie să se prevadă proceduri speciale care să verifice şi să impună DF care nu sunt determinate de chei „ Se poate inlocui operatia de INSERT cu apelul unei proceduri stocate care verifica mai intai valorile si executa INSERT numai daca acestea respecta DF „ Procedura stocata pentru relatia AFS arata astfel: DELIMITER $$ DROP PROCEDURE IF EXISTS sp_AFS $$ CREATE PROCEDURE `sp_AFS`(OUT error INT, s_id INT, s_nume VARCHAR(20), s_prenume VARCHAR(20), s_adresa VARCHAR(20), s_functia VARCHAR(20), s_salariu DECIMAL) BEGIN DECLARE done INT DEFAULT 0; DECLARE l_salariu DECIMAL; DECLARE cursor_AFS CURSOR FOR SELECT Salariu FROM AFS WHERE Functia = s_functia; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1; SET error = 0; OPEN cursor_AFS; REPEAT FETCH cursor_AFS INTO l_salariu; IF s_salariu l_salariu THEN SET error = 1; END IF; UNTIL done = 1 OR error = 1 END REPEAT; CLOSE cursor_AFS; IF error = 0 THEN INSERT INTO AFS VALUES (s_id, s_nume, s_prenume, s_adresa, s_functia, s_salariu);END IF; END$$ DELIMITER ; Prof. Felicia Ionescu Cap. 6 - Normalizarea relatiilor 22

Impunerea DF in relatia nenormalizata AFS (2) „ Fie tabelul AFS care contine liniile: (1, ‘Ionescu’,’Ion’,’Bucuresti’,’inginer’,2000), (2, ‘Popescu’,’Petre’,’Craiova’,’inginer’,2000) „ Se observa redundanta datelor: valoarea salariului este memorata de fiecare data pentru o functie anume, desi trebuie sa fie aceeasi (conform DF Functie →Salariu) „ Datorita redundantei pot apare anomalii: se poate insera linia (3, ‘Mateescu’, ’Viorel’,’Bucuresti’,‘inginer’, 2100), care este admisă de SGBD, deși nu respectă DF Functie → Salariu: pentru functia ‘inginer’ se admite si salariul 2000 si salariul 2100; (se sterge apoi linia inserata eronat, pentru ca ulterior sa functioneze bine procedura stocata) „ Inserarea liniilor in tabelul AFS prin apelul procedurii stocate sp_AFS inlatura aceasta anomalii „ De exemplu, la apelul procedurii stocate cu aceleasi valori: call sp_AFS(@error, 7, ‘Mateescu', ‘Irinel', 'Bucuresti','inginer', 2100); select @error;

se obtine @error=1 si linia respectiva nu va fi introdusa in tabelul AFS

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

23

Forma normala Boyce-Codd (FNBC) „ Fie schema de relatie R si multimea F de DF definite pe aceasta. O relaţie r(R) este în forma normală Boyce-Codd (FNBC) în raport cu F dacă este în FN1 şi dacă orice DF netrivială din F+ este determinata de o cheie a relaţiei „ Este evident că o relaţie în FNBC este în FN3, dar o relaţie în FN3 poate să fie sau nu în FNBC „ Exemplu: relaţia EDP(IdElev, IdDisciplina,IdProfesor), cu cheia PK= {IdElev, IdDisciplina} şi cu mulţimea FEDP de DF: FEDP = {{IdElev,IdDisciplina}→IdProfesor, IdProfesor→IdDisciplina}

„ Se consideră că relaţia este în FN1; din FEDP se observă că nu există DF parţiale faţă de cheia relaţiei (deci relaţia este în FN2) şi nu există nici o DF a unui atribut neprim faţă de un alt atribut neprim, deci relaţia este în FN3 „ Relaţia EDP nu este în FNBC, datorită DF a atributului prim IdDisciplina faţă de atributul neprim IdProfesor; aceasta relatie prezintă redundante de date şi anomalii de actualizare „ Exemplu: fie starea in care tabelul EDP contine liniile (1,1,1) si (2,1,1) „ redundanta: disciplina (1) predata de profesorul 1 este memorata de doua ori in tuplurile (1,1,1) si (2,1,1) „ anomalie de inserare: se poate insera si tuplul (1,2,1) care nu respecta DF IdProfesor→IdDisciplina (profesorul 1 preda si disciplina 1 si disciplina 2) Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

24

Impunerea DF in relatia nenormalizata EDP ■ Dacă relaţia EDP nu se normalizeaza, atunci trebuie să se prevadă o procedura care să verifice şi să impună DF (IdProfesor→IdDisciplina) care nu este determinata de cheia relatiei, pentru operatiile de INSERT si UPDATE „ De ex: se inlocuieste operatia INSERTcu apelul unei proceduri stocate care verifica mai intai valorile si executa INSERT numai daca acestea respecta DF DELIMITER $$ DROP PROCEDURE IF EXISTS `sp_EDP`$$ CREATE PROCEDURE `sp_EDP`(INOUT error INT, s_Elev INT, s_Disciplina INT, s_Profesor INT) BEGIN DECLARE done INT DEFAULT 0; DECLARE l_Disciplina INT; DECLARE cursor_EDP CURSOR FOR SELECT IdDisciplina FROM EDP WHERE IdProfesor = s_Profesor; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1; SET error = 0; OPEN cursor_EDP; REPEAT FETCH cursor_EDP INTO l_Disciplina; IF s_Disciplina l_Disciplina THEN SET error = 1; END IF; UNTIL done = 1 OR error = 1 END REPEAT; CLOSE cursor_EDP; IF error = 0 THEN INSERT INTO EDP VALUES (s_Elev, s_Disciplina, s_Profesor); END IF; END$$ DELIMITER ;

■ Pentru verificare: se sterge linia(1,2,1) (daca exista) si se executa: ● call sp_EDP(@error,1,2,1); select @error; ● se obtine @error = 1 si nu s-a inserat acest tuplu Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

25

Normalizarea relatiei EDP ■ Normalizarea relaţiei EDP astfel încât relaţiile obţinute să fie în FNBC se poate face prin descompunerea acesteia. Se pot încerca trei descompuneri: D1 = {EP,PD}, unde EP = {IdElev, IdProfesor}, PD = {IdProfesor, IdDisciplina}; D2 = {ED,PD}, unde ED = {IdElev, IdDisciplină}, PD = {IdProfesor, IdDisciplina}; D3 = {EP,ED}, unde EP = {IdElev, IdProfesor}, ED = {IdElev, IdDisciplina}.

■ Se poate observa că relaţiile rezultate în oricare din aceste descompuneri sunt relaţii în FNBC (fiind relaţii formate din două atribute). ■ Dintre cele trei descompuneri, descompunerea D1 prezintă proprietatea de joncţiune fără pierdere de informaţie. Într-adevăr, EP ∩ PD = {IdProfesor}, PD − EP = {IdDisciplina} şi IdProfesor→IdDisciplina, deci este îndeplinită condiţia lui Ullman de conservare a informaţiei. ■ Celelalte descompuneri, D2 şi D3, nu îndeplinesc această condiţie. ■ In oricare din aceste descompuneri se pierde dependenţa funcţională {IdElev,IdDisciplina}→IdProfesor, deci relaţia EDP nu poate fi descompusă în mod reversibil în relaţii FNBC. Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

26

Impunerea constrangerilor pierdute prin descompunere (1) ■ Dacă relaţia EDP se normalizeaza prin descompunerea (EP, PD) atunci trebuie să se prevadă o procedura care să verifice şi să impună constrangerea pierduta ■ Se pot inlocui operatiile de INSERT in tabelele EP, PD cu apelul unei proceduri stocate care verifica mai intai valorile si executa INSERT numai daca acestea respecta constrangerea: {IdElev, IdDisciplina} → IdProfesor DELIMITER $$ DROP PROCEDURE IF EXISTS `sp_EP_PD`$$ CREATE PROCEDURE `sp_EP_PD`(OUT error INT, s_Elev INT, s_Disciplina INT, s_Profesor INT) BEGIN DECLARE done INT DEFAULT 0; DECLARE l_Elev, l_Profesor, l_Disciplina INT; DECLARE cursor_EP_PD CURSOR FOR SELECT IdElev, EP.IdProfesor, IdDisciplina FROM EP, PD WHERE EP.IdProfesor = PD.IdProfesor ; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1; SET error = 0; OPEN cursor_EP_PD; REPEAT FETCH cursor_EP_PD INTO l_Elev, l_Profesor, l_Disciplina; IF s_Elev = l_Elev AND s_Disciplina = l_Disciplina AND s_Profesor l_Profesor THEN SET error = 1; END IF; UNTIL done = 1 OR error = 1 END REPEAT; CLOSE cursor_EP_PD; IF error = 0 THEN INSERT INTO EP VALUES (s_Elev, s_Profesor); INSERT INTO PD VALUES (s_Profesor, s_Disciplina); END IF; END$$ DELIMITER ; Prof. Felicia Ionescu Cap. 6 - Normalizarea relatiilor 27

Impunerea constrangerilor pierdute prin descompunere (2) ■ Procedura sp_EP_PD primeşte ca argumente un flag de eroare şi valorile celor trei atribute IdElev, IdDisciplină, IdProfesor care trebuie sa respecte constrângerea {IdElev, IdDisciplina} → IdProfesor ■ În această procedura se creează un cursor în care se încarcă rezultatul joncţiunii naturale între relaţiile EP şi PD pe atributul comun IdProfesor ■ Pentru fiecare linie a rezultatului joncţiunii EP  PD se verifică respectarea constrângerii dorite, testând valorile existente în linia respectivă cu noile valori care urmează să fie introduse: ● daca această constrângere este respectată, atunci se execută două instrucţiuni INSERT, cate una in foiecare din tabelele EP si PD ● daca această constrângere nu este respectată, nu se introduce nici o linie

■ Exemplu: daca tabelul EP contine linia (1,1) si tabelul (PD) contine linia (1,1), prin INSERT se pot introduce si valorile (1,1,2) pentru (IdElev, IdDisciplina, IdProfesor) adica liniile: (1,2) in EP si (2,1) in PD; dar aceste valori nu respecta constrangerea {IdElev, IdDisciplina} → IdProfesor deoarece: ● in liniile existente (IdElev, IdDisciplina) = (1,1), iar IdProfesor = 1 ● in valorile de inserat (IdElev, IdDisciplina) = (1,1), iar IdProfesor = 2

■ In schimb apelul procedurii: call sp_EP_PD(@error, 1,1,2); select @error; produce @error=1 si nu se introduce nici o linie

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

28

Dependente multivalorice „ O dependenţă multivalorică - DMV- (multivalued dependency) X→→Y specificată pe schema de relatie R = {X,Y,Z} stabileşte următoarele constrângeri pe care trebuie să le respecte orice relaţie r(R): dacă există două tupluri t1 şi t2 în r astfel ca t1[X] = t2[X]= x, atunci vor exista şi tuplurile t3 şi t4 cu următoarele proprietăţi: t3[X] = t4[X] = t1[X] = t2[X] = x; t3[Y] = t1[Y] = y1 şi t4[Y] = t2[Y] = y2 ; t3[Z] = t2[Z] = z2 şi t4[Z] = t1[Z] = z1 .

„ Datorită simetriei egalităţilor de mai sus, rezulta că, dacă într-o relaţie cu schema R există DMV X→→Y, atunci există şi X→→Z, unde Z = R−(X∪Y) „ O DF este un caz particular al unei DMV: DF X→Y este o DMV X →→ Y cu restricţia că unei valori a lui X îi corespunde o singură valoare a lui Y „ O relaţie cu schema R este în a patra formă normală (FN4) în raport cu o mulţime F de DF şi DMV dacă este în FN1 şi dacă, pentru orice DMV netrivială X→→Y din F+, X este cheie a relaţiei r(R). „ Asemănarea acestei definiţii cu definiţia FNBC: pentru FNBC se impun restricţii DF, iar pentru FN4 se impun restricţii DMV „ Dacă o schemă de relaţie respectă condiţia de FN4, atunci înseamnă că ea respectă şi condiţia de FNBC Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

29

Dependente de jonctiune „ Fie o schema de relaţie R şi R1,R2,...Rk submulţimi de atribute ale lui R, unde R1 ∪ R2 ∪...∪ Rk = R. Se spune că există o dependenţă de joncţiune (DJ) pe R, notată *(R1,R2,...Rk), dacă şi numai dacă orice relaţie r(R) este egală cu joncţiunea proiecţiilor relaţiei pe submulţimile R1,R2,..Rk, adică r = ΠR1(r) ΠR2(r)... ΠRk(r). „ Rezulta ca: ● *(R1,R2,...Rk) este o DJ pe R dacă şi numai dacă descompunerea lui R în proiecţiile pe R1,R2,...Rk este fără pierdere de informaţie la jonctiune ●

Relaţia r(R) este k-decompozabilă fără pierdere de informaţie dacă există o DJ *(R1,R2,...Rk)

„ Tipuri de DJ (dupa valoarea lui k): ● Cazul k = 1 reprezintă o DJ trivială ● Cazul k = 2 al unei DJ este o DMV; o DMV X→→Y în relaţia r(R) reprezintă o DJ *(XY, XZ), unde Z = R–(X ∪ Y). ● In cazul k > 2, DJ nu mai sunt echivalente cu DMV

„ DJ sunt dificil de identificat şi nu există reguli de deducere (inferenţă) care să genereze toate DJ pornind de la o mulţime dat㠄 Datorită acestor aspecte, analiza DJ are un pronunţat caracter intuitiv Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

30

Forma normala FN5 „ O relaţie cu schema R este în a cincea formă normală (FN5) în raport cu o mulţime F de dependenţe funcţionale, multivalorice sau de joncţiune dacă este în FN1 şi dacă, pentru orice dependenţă de joncţiune *(R1,R2,... Ri,...Rk) din F+, Ri (unde 1 ≤ i ≤ k) este o cheie a relaţiei r(R) „ Având în vedere faptul că o dependenţă multivalorică este un caz special de dependenţă de joncţiune, iar o dependenţă funcţională este un caz special de dependenţă multivalorică, se poate afirma că o relaţie care este în FN5, este implicit în FN4, deci şi în FNBC, ş.a.m.d. „ S-a demonstrat că orice relaţie poate fi transformată în relaţii FN5 (sau FN4, sau FNBC) printr-o descompunere fără pierdere de informaţie la joncțiune, dar nu se asigura conservarea tuturor DF „ Conditiile de normalizare in FNBC, FN4 si FN5 se pot rezuma la faptul că întro relaţie normalizată nu există decât dependenţe determinate de chei: „ O relație este în FNBC dacă orice DF este determinată de o cheie a relației „ O relație este în FN4 dacă orice DF sau DMV este determinată de o cheie a relației „ O relație este în FN5 dacă orice DF, DMV sau DJ este determinată de o cheie a relației Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

31

Proiectarea relatiilor normalizate „ Normalizarea relaţiilor asigură un proiect al bazei de date mai concis şi de aceea se consideră că a normaliza este avantajos, chiar dacă normalizarea nu este o garanţie că s-a realizat cel mai bun model „ Proiectarea bazelor de date pornind de la diagrama Entitate-Asociere conduce, în general, la relaţii normalizate, deoarece: ● Relaţiile corespunzătoare mulţimilor de entităţi sunt, de regulă, relaţii normalizate, dat fiind că toate atributele descriu tipul de entitate respectiv. ● Relaţiile de asociere binară, care conţin două chei străine care referă cheile primare din cele două relaţii pe care le asociază, rezultă tot ca relaţii normalizate ● Relaţiile care modelează asocierile multiple pot să rezulte nenormalizate şi necesită operaţii de normalizare suplimentare

„ Dar, cu cât nivelul de normalizare creşte, cu atât se obţin mai multe relaţii cu grad mai mic şi pentru fiecare interogare sunt necesare mai multe operaţii de joncţiune, ceea ce face ca timpul de execuţie a interogărilor să crească; in general, se recomandă ca: ● relaţiile asupra cărora se efectuează operaţii de actualizare frecvente să fie normalizate într-o formă normală cât mai avansată ● relaţiile asupra cărora se efectuează interogări frecvente pot fi păstrate într-o formă de normalizare mai redusă

„ Mentinerea unei relaţii într-o formă de normalizare mai redusă se numeşte “denormalizare”, şi are scopul de a obţine performanţe ridicate la interogări Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

32

Algoritmi de normalizare „ Analiza normalizării relaţiilor trebuie să fie facuta pentru orice proiect de baze de date, pentru a asigura funcţionarea corectă a acesteia: ● Dacă o relaţie se păstrează într-o formă de normalizare mai redusă, atunci trebuie să se prevadă proceduri de verificare şi impunere a dependenţelor de date care nu sunt determinate de cheile relaţiei (ca si constrângeri explicite) ● Dacă se normalizeaza o relaţie, dar prin descompunere se pierd unele DF, acestea pot fi impuse explicit prin proceduri stocate sau funcţii în programele de aplicaţie, care execută joncţiunea între relaţiile rezultate şi impun constrângerea respectiva

„ S-a demonstrat si exista algoritmi prin care orice relatie poate fi descompusa reversibil (cu conservarea informatiei si conservarea DF) in relatii in formele normale FN2 sau FN3 „ S-a demonstrat si exista algoritmi prin care orice relatie poate fi descompusa in relatii FN2, FN3, FNBC, FN4 sau FN5 fara pierdere de informatie la jonctiune, dar se pot pierde unele dependențe

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

33

Descompunerea fara pierdere de informatie la jonctiune (1) „ Fiind dată o relaţie cu schema R şi mulţimea F de DF, o descompunere D fără pierdere de informaţie la joncţiune în relaţii într-una din formele normale FN2, FN3 sau FNBC se poate obţine aplicând algoritmul următor: 1. se setează D = {R}; 2. atât timp cât în D există o relaţie Q (cu mulţimea FQ a DF) care nu se află în forma normală dorită: - se alege o DF X → W din FQ care nu respecta forma normala dorita şi se construieşte închiderea X+ a atributului X şi mulţimea Y = X+ – X; - în D se înlocuieşte relaţia Q cu două relaţii: Q1 = X ∪ Y şi Q2 = X ∪ Z, unde Z = Q – (X ∪ Y);

„ Demonstraţie: • La fiecare pas de execuţie a algoritmului, o relaţie Q se descompune în două relaţii Q1 şi Q2, astfel încât Q1 ∩ Q2 = X, şi Q1 − Q2 = Y • Din definiţia închiderii unui atribut rezultă că X→Y, deci, conform teoremei lui Ullman, această descompunere este fără pierdere de informaţie la joncţiune • Astfel de descompuneri succesive păstrează caracterul de descompuneri fără pierdere de informaţie la joncţiune

„ Există algoritmi similari pentru descompunerea fară pierdere de informatie la joncțiune a unei relații in relații în forme normale FN4 sau FN5 Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

34

Descompunerea fara pierdere de informatie la jonctiune (2) „ Exemplu de aplicare a algoritmului pentru descompunerea in relatii FNBC a relatiei R = {dAngajat, Nume, Prenume, Adresa, Functie, Salariu, IdProiect, Ore} cu PK = {IdAngajat, IdProiect}, aflata în FN1 şi cu mulţimea F de DF F = {IdAngajat→Nume,IdAngajat→Preume, IdAngajat→Adresa,IdAngajat→Functie, Functie→Salariu, {IdAngajat,IdProiect}→Ore}

„ Executia algoritmului: • Se setează D = {R} • Din F se alege DF IdAngajat→Nume care nu respectă condiţia impusă de FNBC • Închiderea atributului X=IdAngajat este [IdAngajat]+= {IdAngajat, Nume, Prenume, Adresa, Functie, Salariu} şi rezultă Y = X+ – X = {Nume,Prenume, Adresa, Functie, Salariu} şi Z = R – (X ∪ Y) = R - X+ = {IdProiect,Ore}. • Se obtine descompunerea D a relaţiei R: D = {R11, R12}, unde R11 = X ∪ Y = {IdAngajat, Nume, Prenume, Adresa, Functie, Salariu}; in FN2 R12 = X ∪ Z = {IdAngajat, IdProiect, Ore}; in FNBC • In acelasi mod se descompune relaţia R11, in relatiile R111 si R112: R111 = {Functie, Salariu}; este in FNBC R112 = {IdAngajat, Nume, Prenume, Adresa, Functie}; este in FNBC

„ Se poate demonstra usor ca descompunerea obtinuta D= (R111, R112, R12) conserva si dependentele functionale Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

35

Prof. Felicia Ionescu

Cap. 6 - Normalizarea relatiilor

36

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF