Download - Baze de date_Iacob

Transcript
Page 1: Baze de date_Iacob

Paul IACOB

Page 2: Baze de date_Iacob

1

Introducere

Aplicaţii tradiţionale bazate pe fişiere; limitări

Pentru o mai bună înţelegere a evoluţiei prelucrărilor de date vom rezerva câteva

rânduri la începutul cursului nostru pentru o scurtă trecere în revistă a metodelor tradiţionale

de prelucrare a masivelor de date, aşa-numitele sisteme tradiţionale bazate pe fişiere.

În primii ani, calculatoarele erau utilizate mai ales pentru a duce la bun sfârşit calcule

laborioase în care nu erau implicate cantităţi prea mari de date, aşa-numitele calcule

ştiinţifice. Odată cu apariţia limbajelor de nivel înalt şi a posibilităţii stocării de mari cantităţi

de informaţie pe suport magnetic adresabil (memorie externa) s-a pus şi problema

eficientizării prelucrării acestora. De data aceasta nu calculele creşteau costul în timp al

prelucrărilor ci manipularea datelor, respectiv regăsirea, actualizarea, etc. S-a constatat că un

factor important al creşterii eficienţei prelucrărilor este modul de organizare al informaţiilor.

De aici şi până la a gândi sisteme unitare de reprezentare şi manipulare a masivelor de date n-

a mai fost decât un pas.

Prima variantă de prelucrare a cantităţilor mari de informaţie s-a bazat pe organizarea

datelor sub forma înregistrărilor în fişiere tradiţionale pe suport adresabil. În această variantă

se elaborau programe de aplicaţie care defineau şi manipulau propriile date şi aveau în general

ca scop elaborarea de rapoarte pentru diverşi beneficiari. Aceste programe au avut menirea de

a înlocui prelucrarea sistemelor de fişiere manuale care mai funcţionează şi astăzi în unele

locuri cum ar fi cabinetele medicale. Aşadar prelucrările oferite de un sistem tradiţional bazat

pe fişiere copiau în mare măsură metodele manuale de prelucrare. Evident că puterea de

calcul şi memorare caracteristică sistemelor de calcul au făcut ca gama prelucrărilor să

crească simţitor, la aceasta adăugându-se viteza şi siguranţa prelucrărilor.

Cu toate că la momentul respectiv abordarea tradiţională bazată pe fişiere a fost un

evident progres, putem să amintim aici şi o serie de limitări ale acestui sistem de prelucrare a

datelor:

Separarea şi izolarea datelor

Duplicarea datelor

Dependenţa datelor

Incompatibilitatea fişierelor

Interogări fixe / proliferarea aplicaţiilor

Comentăm pe scurt în continuare semnificaţia acestora.

Separarea şi izolarea datelor

Accesul la date care se află în fişiere diferite este dificil deoarece cade în sarcina

programatorului să sincronizeze înregistrările din fişiere în aşa fel încât datele extrase să fie

corecte.

Duplicarea datelor

În situaţia în care se realizează prelucrări descentralizate de date, pe compartimente,

este posibil să fie necesară duplicarea datelor. Totuşi duplicarea este de evitat din următoarele

motive:

- necesită costuri mari în timp şi spaţiu de memorie.

- duce la pierderea integrităţii datelor. Datele nu mai sunt consistente, deci nu se mai

poate conta pe ele.

Page 3: Baze de date_Iacob

2

Dependenţa datelor

Aşa cum am subliniat deja, structura fizică şi modul de memorare al datelor este

definit în fiecare program de aplicaţie în parte. Este evident cât de dificile sunt schimbările în

structura datelor. Toate programele trebuie ajustate la noua structură de date. O simplă

modificare a lungimii unui câmp poate genera probleme. Dependenţa se referă aşadar la

dependenţa program-date.

Incompatibilitatea fişierelor

Această limitare se trage tot din dependenţa de programe a structurii fişierelor.

Structura fiind descrisă în programe ea depinde de limbajul de programare. De exemplu,

structura unui fişier declarată într-un program COBOL diferă de structura unui fişier generat

de un program C. Dacă e necesară prelucrarea de date din ambele fişiere, programatorul este

obligat să scrie programe de conversie, pentru a aduce fişierele la un format comun posibil de

prelucrat.

Interogări fixe / proliferarea aplicaţiilor

Deoarece prelucrarea masivelor de date a devenit mai uşoara şi mai rapida cu ajutorul

calculatorului, beneficiarii au lărgit gama prelucrărilor lansând interogări noi sau modificând

interogări mai vechi, pentru obţinerea de informaţii mai complexe. Orice interogare nouă sau

orice modificare a unei interogări mai vechi se rezolvă în sistemele tradiţionale prin realizarea

de noi programe de către programatorul de aplicaţie. Inutil de subliniat cât de costisitoare sunt

acestea. Un efect secundar era că se înmulţeau programele aplicaţiei şi de multe ori şi fişierele

de prelucrat.

Obiectivele cursului

Cursul de baze de date este un curs de bază pentru meseria de informatician. La

sfârşitul acestui curs, studenţii vor fi capabili să:

Proiecteze o bază de date

Programeze cereri în SQL

Realizeze un sistem cu bază de date

Cerinţe preliminare

Cursul se va susţine studenţilor după cursul de structuri de date.

Cunoştinţele acumulate la acest curs pot fi utile la un curs de informatică de

gestiune.

Resurse

Pentru a proiecta un sistem cu bază de date vom folosi sistemul ACCESS de la

Microsoft şi ORACLE 10G Express edition.

Page 4: Baze de date_Iacob

3

Structura cursului

Cursul de baze de date este structurat în trei module, astfel: primul modul cuprinde

patru unităţi de învăţare, al doilea modul cuprinde două unităţi de învăţare, al

treilea modul cuprinde două unităţi de învăţare, al patrulea modul cuprinde două

unităţi de învăţare, iar al cincilea modul cuprinde şase unităţi de învăţare. La

rândul său, fiecare unitate de învăţare cuprinde: obiective, aspecte teoretice privind

tematica unităţii de învăţare respective, exemple, teste de autoevaluare precum şi

probleme propuse spre discuţie şi rezolvare.

La sfârşitul fiecărui modul sunt date teste de autoevaluare. Rezolvarea acestor teste

se găseşte la sfârşitul cărţii.

Durata medie de studiu individual

Parcurgerea de către studenţi a unităţilor de învăţare ale cursului de baze de date

(atât aspectele teoretice cât şi rezolvarea testelor de autoevaluare şi rezolvarea

problemelor propuse) se poate face în 1-4 ore pentru fiecare unitate.

Evaluarea

La sfârşitul semestrului, fiecare student va primi o notă, care va cuprinde: un

examen scris cu materia din modulele 1, 3 şi 4 care va deţine o pondere de 60% în

nota finală şi notele aferente celor două capitole de la laborator ACCESS şi

ORACLE.

Page 5: Baze de date_Iacob

4

CUPRINS

Modulul 1. Sisteme de Gestiune a Bazelor de Date (SGBD) ................................ ..................... 5

Unitatea de învăţare 1. Istoric; comentarii ................................ ................................ ......... 6

Criterii minimale de definire a unui SGBDR ................................ ................................ ... 10

Unitatea de învăţare 1.2 Abstractizarea datelor ................................ ................................ 14

Unitatea de învăţare 1.3 Principalele componente şi funcţiuni ale unui SGBD ............... 19

Unitatea de învăţare 1.4 Baze de date distribuite ................................ ............................. 27

Modulul 2. Modele de descriere a datelor ................................ ................................ ................ 37

Unitatea de învăţare 2.1. Generalităţi ................................ ................................ ............... 38

Unitatea de învăţare 2.2 Modelare E-R (Entity-Relaţionship) ................................ ......... 41

Modulul 3. Limbaje de cereri. ................................ ................................ ................................ .. 53

Unitatea de învăţare 3.1 Algebra relaţională. ................................ ................................ ... 54

Unitatea de învăţare 3.2 SQL ................................ ................................ ........................... 65

Modulul 4. Normalizarea................................ ................................ ................................ .......... 85

Unitatea de învăţare 4.1 De ce este nevoie de normalizare şi cu ce instrumente facem

normalizarea. ................................ ................................ ................................ .................... 86

Unitatea de învăţare 4.2 Forme normale ................................ ................................ ......... 93

Modulul 5. Metodologia de proiectare a bazelor de date relaţionale ................................ ...... 99

Unitatea de învăţare U5.1 Generalităţi şi proiectarea conceptuală ................................ . 101

Unitatea de învăţare U5.2 Proiectarea logică. ................................ ................................ 111

Unitatea de învăţare U5.3 Proiectarea fizică. ................................ ................................ . 122

Unitatea de învăţare U5.4 Tranzacţii şi concurenţă................................ ........................ 126

Unitatea de învăţare U5.5 Metode de control al concurenţei. ................................ ........ 131

Unitatea de învăţare U5.6. Securitate şi integritate ................................ ........................ 139

Raspunsuri la testele de autoevaluare. ................................ ................................ .................... 147

Bibliografie. ................................ ................................ ................................ ............................ 164

Page 6: Baze de date_Iacob

5

Modulul 1. Sisteme de Gestiune a Bazelor de Date (SGBD)

Cuprins

Introducere ................................ ................................ ................................ ...................... 3

Obiectivele modului ................................ ................................ ................................ ........ 3

U1.1. Istoric; comentarii

U1.2. Abstractizarea datelor

U1.3. Principalele componente şi funcţiuni ale unui SGBD

U1.4 Baze de date distribuite

Introducere

Evoluţia metodelor şi tehnicilor de organizare a datelor a fost determinată de

necesitatea de a avea un acces cât mai rapid şi mai uşor la un volum din ce în ce

mai mare de informaţii precum şi de perfecţionarea echipamentelor de culegere,

memorare, transmitere şi prelucrare a datelor. Cel mai important domeniu al

aplicaţiilor calculatorului este cel al bazelor de date.

M1. Obiectivele modulului

La sfârşitul acestui modul studenţii vor fi capabili să:

Distingă gradul de relaţional al unui SGBD

descrie componenţa unui Sistem de Gestiune al Bazei de Date

cunoască obiectivele unui SGBD

cunoască şi să utilizeze funcţiunile unui SGBD

înţeleagă ce este o bază de date distribbuită

cum se proiectează o bază de date distribuită

Page 7: Baze de date_Iacob

6

Unitatea de învăţare 1. Istoric; comentarii

M1.U1.1. Introducere

Este important să ştim cum a evoluat modelul şi softul pentru bazele de date. Ne

ocupăm, în acest curs, de cel mai important dintre modele şi anume modelul

relaţional.

M1.U1.2. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

Înţeleagă nivelul la care au ajuns bazele de date

Distingă gradul de relaţional al unui SGBD.

Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Istoric şi comentarii

Se pare că sistemul de baze de date îşi are rădăcinile în anii '60, în proiectul de

aselenizare Apollo. Deoarece pe atunci nu există un astfel de sistem, North American

Aviation (actualmente Rockwell International) a dezvoltat un pachet de programe cunoscut

sub numele GUAM (Generalized Update Access Method), care se baza pe date organizate în

mod ierarhic. Modelul de date ierarhic, unul din modelele abstracte ale bazelor de date, îşi are

originea în acest proiect.

In anii ‘60 General Electric a dezvoltat sistemul IDS (Integrated Data Store).

Conducător de proiect: Charles Bachmann. Proiectul a condus la modelul de date reţea.

În 1965 CODASYL (the Conference On DAta SYstems Languages) care reunea

reprezentanţi ai guvernului USA şi reprezentanţi ai lumii afacerilor şi comerţului, a reuşit să

stabilească un grup de lucru, cunoscut din 1967 sub numele Data Base Task Group (DBTG).

Sarcina acestui grup era să stabilească specificaţii cu rol de standarde pentru un mediu care ar

permite crearea de baze de date şi manipularea datelor.

Conceptul de bază de date s-a definit în 1969 cu ocazia prezentării primului proiect de

raport CODASYL (Raportul final s-a prezentat în 1971). Ideea principală în organizarea

datelor se baza pe existenţa a trei nivele de bază:

schema de reţea - care reprezenta organizarea logica a întregii baze de date

subschema - care reprezenta o parte a bazei de date aşa cum e văzută de utilizator sau de

programele de aplicaţie

un limbaj de gestionare a datelor - care definea caracteristicile datelor, structura lor şi care

manipula datele

Pentru standardizare, s-au propus trei limbaje:

un limbaj de definire a datelor (LDD) la nivel de schemă

un limbaj la nivel de subschemă

Page 8: Baze de date_Iacob

7

un limbaj de manipulare a datelor (LMD)

Cu toate că nu a fost adoptată formal de ANŞI (American National Standard Institute)

propunerea DBTG a fost aplicată într-o serie de sisteme dezvoltate ulterior şi ea stă la baza

conceptului modern de bază de date.

Proiectul ierarhic şi cel prezentat de CODASYL reprezintă prima generaţie de Sisteme de

Gestiune a Bazelor de Date (SGBD).

În 1978 E.F.Codd de la IBM Research Laboratory a elaborat o lucrare care a avut o

influenţă covârşitoare în dezvoltarea bazelor de date. Lucrarea trata despre modelul de date

relaţional.

De aici încolo s-au proiectat multe sisteme dintre care menţionăm System R dezvoltat la

IBM's San Jose Research Laboratory din California, la sfârşitul anilor '70. Acest proiect a dus

la:

dezvoltarea unui limbaj structurat de interogare (numit SQL) care de atunci a devenit un

standard pentru sistemele relaţionale;

producerea în anii '80 de sisteme comerciale arhicunoscute dintre care menţionăm: DB2 şi

SQL/DS de la IBM şi ORACLE de la ORACLE Corporation.

Alte exemple de sisteme relaţionale: INGRES de la Relaţional Technology Inc., Informix de

la Informix Sofware Inc., Sybase de la Sybase Inc.. Dintre sistemele relaţionale pentru

microcalculatoare enumerăm aici: Paradox şi dBase IV de la Borland, Access de la Microsoft,

FoxPro şi R:base de la Microrim. Toate acestea constituie generaţia a doua de SGBD.

Definirea sistemelor de gestiune ale bazelor de date relaţionale Într-o primă încercare de definire, se poate considera un sistem de gestiune a bazelor de

date relaţionale (SGBDR) ca reprezentând un SGBD care utilizează drept concepţie de

organizare a datelor modelul relaţional. Astfel spus, un SGDBR reprezintă un sistem care

suportă modelul relaţional.

Definiţia de mai sus este prea generală pentru a putea fi operaţională, deoarece modul de

implementare a modelului relaţional diferă, de regulă atât între diferitele SGBDR, cât şi în

raport cu modelul “ teoretic”, cel definit în cadrul teoriei relaţionale, datorită eforturilor

producătorilor de a realiza sisteme cât mai performanţe care să satisfacă cerinţele şi

exagerările utilizatorilor. Cât de aproape (sau de departe) de modelul relaţional teoretic

trebuie să fie modelul datelor efectiv utilizat de SGBD pentru a putea afirma că SGBD-ul

respectiv utilizează sau nu modelul relaţional, deci este sau nu SGBDR?

Diversitatea modelelor relaţionale operaţionale au determinat, în mod natural existenţa

unei mari diversităţii de SGBDR, pentru a căror prezentare a fost necesară nuanţarea

terminologiei. Au apărut o serie de sintagme precum: sisteme cu interfaţă relaţională, sisteme

pseudorelaţionale, sisteme complet relaţionale.

Conceptele specifice organizării datelor în fişiere, SGBDR şi teoriei relaţionale între care

se pot stabili analogii

Organizarea datelor în fişiere SGBDR Teoria relaţională

Fişier Tabelă Relaţie

Record(înregistrare) Linie Tuplu

Câmp Coloană Atribut

În general, conceptele utilizate la prezentarea SGBDR şi a modelelor relaţionale

operaţionale diferă de cele din cadrul teoriei relaţionale. Figura de mai sus prezintă

Page 9: Baze de date_Iacob

8

comparativ conceptele organizării datelor în fişiere, concepte SGBDR şi ale teoriei

relaţionale.

Faptul că se pot stabili analogii între conceptele organizării datelor în fişiere şi

conceptele relaţionale, i-au determinat pe unii producători să prezinte sisteme fără nici o

legătură cu modelul relaţional drept SGBDR, în scopul asigurării succesului comercial al

acestor sisteme.

Regulile lui Codd

Definirea unui SGBDR impune o detaliere a caracteristicilor pe care trebuie să le prezinte

un SGBD pentru a putea fi considerat relaţional. În acest sens, Codd a formulat 13 reguli care

exprimă cerinţele pe care trebuie să le prezinte un SGBD ca să fie relaţional. Deşi reguli au

stârnit o serie de controverse, eu le voi prezenta în continuare, ele fiind deosebit de utile în

evaluarea unui SGBDR.

R0: Regula privind gestionarea datelor la nivel de relaţie

Sistemul trebuie să gestioneze baza de date numai prin mecanisme relaţionale.

Acest lucru înseamnă că sistemul trebuie să-şi îndeplinească toate funcţiile prin

manipulări în care unitatea de informaţie să fie mulţimea (relaţia), adică să utilizeze limbaje,

precum SQL, care să opereze la un moment dat pe o întreagă relaţie. Dec i SGBD nu trebuie să

accepte operaţii non-relaţionale care să îndeplinească operaţiile de definire şi manipulare a

datelor.

Unele sisteme utilizează mecanisme relaţionale numai pentru o parte din funcţii, în special

pentru interogare. Aceste sisteme se numesc sisteme cu interfaţă relaţională ţi nu SGBDR.

R1: Regula privind reprezentarea logică a datelor

Toate datele din baza de date relaţională trebuie să fie reprezentate explicit la nivel

logic, într-un singur mod, şi anume ca valori în tabele de date. Ac este lucru înseamnă că toate

datele trebuie să fie memorate şi prelucrate în acelaşi mod. Informaţiile privind numele de

tabele,coloane, domenii, definiţiile tabelelor virtuale, restricţii de integritate trebuie să fie

memorare tot în tabele de date (cataloage). Referinţa la 'nivelul logic' înseamnă că construcţia

fizică nu este reprezentată şi nu necesită explicaţie.

R2: Regula privind garantarea accesului la date.

Orice dată din baza de date relaţională trebuie să poată fi accesată prin specificarea

numelui da tabelă, valorii cheii primare şi numelui de coloană.

Această regulă exprimă cerinţa ca limbajul de cereri al SGBDR să permită accesul la

fiecare valoare atomică din baza de date.

R3: Regula privind valorile null

Sistemele trebuie să permită declararea să manipularea sistematică a valorilor null, cu

semnificaţia unor date lipsă sau inaplicabile. Valorile null, care diferă de şirurile de caractere '

spaţiu' sau de şirurile vide da caractere sunt deosebit de importante în implementarea

restricţiilor de integritate (integritatea entităţii şi integritatea referenţială).

R4: Regula privind metadatele

Descrierea bazei de date trebuie să se prezinte la nivel logic în acelaşi mod cu descrierea

datelor propiu-zise, astfel încât utilizatorii autorizaţi să poată descrierii bazei de date aceleaşi

operaţii ca şi asupra datelor obişnuite.

Această regulă specifică că trebuie să existe un unic limbaj de manipulare a metadatelor şi

a datelor propui-zise, mai mult, există o unică structură logică folosită pentru a depozita

informaţiile de sistem.

Sisteme nu trebuie să facă diferenţieri în definirea şi tratarea datelor şi a metadatelor,

utilizând o singură structură, şi anume cea relaţională.

R5: Regula privind facilităţile limbajelor utilizate

Un sistem relaţional trebuie să facă posibilă utilizarea mai multor limbaje, în mai multe

moduri. Trebuie să existe însă cel puţin un limbaj de nivel înalt ale cărui instrucţiuni să poată

Page 10: Baze de date_Iacob

9

exprima oricare din următoarele operaţii: definirea tabelelor de date, definirea tabelelor

virtuale, manipularea datelor (interactiv dau prin program), definirea restricţiilor de

integritate, autorizarea accesului, precizarea limitelor tranzacţiilor. A se nota aici că noul

standard O/I pentru SQL furnizează toate aceste funcţii, deci orice limbaj care acceptă acest

standard va satisface automat această regulă.

R6: Regula privind actualizarea tabelelor virtuale.

Toate tabelele virtuale care teoretic sunt posibil de actualizat trebuie să poată fi efectiv

actualizabile. Nu toate atributele din cadrul unei tabele virtuale, deci nu toate tabele virtuale

sunt teoretic actualizabile.

R7: Regula privind inserările, modificările şi ştergerile în baza de date

Sistemul trebuie să ofere posibilitatea manipulării unei tabele (da bază sau virtuală) nu

numai în cadrul operaţiilor de regăsire, ci şi în acţiuni de inserare, modificare şi ştergere a

datelor.

Această regulă exprimă cerinţa ca prin operaţiile în care se schimbă bazei da date să se

lucreze la un moment dat pe o întreagă relaţie.

R8: Regula privind independenţa fizică a datelor

Programele de aplicaţie nu trebuie să fie afectate de schimbările efectuate în modul de

reprezentare a datelor sau în metodele de acces. O schimbare a structurii fizice a datelor nu

trebuie să blocheze funcţionarea programelor de aplicaţie.

R9: Regula privind independenţa logică a datelor

Programele de aplicaţie nu trebuie să fie afectate de schimbările efectuate asupra

relaţiilor bazei de date, schimbări care conservă datele şi care teoretic garantează valabilitatea

programelor de aplicaţie existente.

R10: Regula privind restricţiile de integritate

Restricţiile de integritate trebuie să fie definite în limbajul utilizat de sistem pentru

definirea datelor ţi să fie memorate în cadrul bazei de date şi nu în cadrul programului de

aplicaţie.

R11: Regula privind distribuirea geografică a datelor

Limbajul de manipulare a datelor utilizat de sistem trebuie să permită ca, în situaţia în

care datele sunt distribuite, programele de aplicaţie să fie logic aceleaşi cu cele utilizate în

cazul în care datele sunt fizic centralizate.

Utilizatorul trebuie să perceapă datele ca fiind centralizate. Sarcina de localizare a

datelor, atunci când acestea sunt distribuite geografic precum şi sarcina recompunerii datelor

trebuie să revină sistemului şi nu utilizatorului.

R12: Regula privind prelucrarea datelor la nivelul de bază

Dacă sistemul posedă un limbaj de bază (de nivel scăzut) orientat pe prelucrare de

recorduri (tupluri) şi nu pe prelucrarea mulţimilor (relaţiilor), acest limbaj nu trebuie s ă fie

utilizat pentru a se evita restricţiile de integritate sau restricţiile introduse prin utilizarea

limbajelor de nivel înalt, adică accesul la toate datele va fi controlat de SGBDR, altfel

integritate bazelor de date nu poate fi compromisă fără cunoaşterea utilizatorului sau a

administratorului bazei de date.

Pe parcursul anilor regulile lui Codd au generat o seamă de controverse. Câteva

argumente sunt că aceste reguli nu sunt mai mult decât nişte exerciţii academice. Unele

revendicări ale produselor existente sunt că ele pot îndeplini cea mai mare parte din reguli,

dar nu toate. Această discuţie a generat o dispută între utilizatori şi teoreticienii asupra

proprietăţilor esenţiale ale unui SGBDR.

Pentru a accentua implicaţia regulilor lui Codd în analiza unui SGBDR, aceste reguli

au fost reorganizate în cinci categorii, şi anume:

Reguli fundamentale,

Page 11: Baze de date_Iacob

10

Reguli structurale,

Reguli privind integritatea datelor,

Reguli privind manipularea datelor,

Reguli privind independenţa datelor.

Să ne reamintim...

Abordarea tradiţională bazată pe fişiere are o serie de limitări cum ar fi

Separarea şi izolarea datelor

Duplicarea datelor

Dependenţa datelor

Incompatibilitatea fişierelor

Interogări fixe / proliferarea aplicaţiilor

Sistemul de baze de date îşi are rădăcinile în anii '60, în proiectul de

aselenizare Apollo

Ideea principală în organizarea datelor se baza pe existenţa a trei componente

de bază:

schema de reţea - care reprezenta organizarea logica a întregii baze de date

subschema - care reprezenta o parte a bazei de date aşa cum e văzută de

utilizator sau de programele de aplicaţie

un limbaj de gestionare a datelor - care definea caracteristicile datelor,

structura lor şi care manipula datele

Pentru standardizare avem trei limbaje:

un limbaj de definire a datelor (LDD) la nivel de schemă

un limbaj la nivel de subschemă

un limbaj de manipulare a datelor (LMD)

Conceptele specifice organizării datelor în fişiere, SGBDR şi teoriei

relaţionale între care se pot stabili analogii

Organizarea datelor în

fişiere

SGBDR Teoria relaţională

Fişier Tabelă Relaţie

Record(înregistrare) Linie Tuplu

Câmp Coloană Atribut

Codd a formulat 13 reguli care exprimă cerinţele pe care trebuie să le prezinte

un SGBD ca să fie relaţional.

Criterii minimale de definire a unui SGBDR

Nici unul dintre SGBDR disponibile astăzi nu respectă întru totul cerinţele exprimate de

Codd, în cadrul celor 13 reguli. De aceea pentru caracterizarea unui SGBD nu sunt utilizate

Page 12: Baze de date_Iacob

11

regulile lui Codd, fiind formulate în schimb o serie de cerinţe minimale pa care trebuie să la

satisfacă un sistem de gestiune a bazelor de date pentru a putea fi considerat relaţional.

Un SGBD este minimal relaţional dacă satisface următoarele condiţii:

1. Toate datele din cadrul relaţiei sunt reprezentate prin valori în tabele,

2. Nu există pointeri observabili de către utilizatori în tabele, în sensul că operaţiile cu relaţii

nu fac apel la pointeri, indecşi, fişiere inverse, etc.

3. Sistemul suportă operatori relaţionali de proiecţie, selecţie şi join natural, fără limitări

impuse de considerente interne (cum ar fi de exemplu, necesitatea indexării atributelor).

Unitatea de informaţie cu care se lucrează în cadrul acestor operaţii trebuie să fie relaţia.

Un SGBD este complet relaţional dacă este minimal relaţional şi satisface în plus

următoarele condiţii:

4. Sistemul suportă toate operaţiile de bază ale algebrei relaţionale, fără limitări impuse de

considerente interne.

5. Sistemul suportă două dintre restricţiile de integritate de bază al modelului relaţional şi

anume unicitatea cheii unei relaţii şi restricţia referenţială.

Un SGBD este pseudorelaţional dacă satisface numai condiţiile 1. şi 3.

Un SGBD cu interfaţă relaţională este un SGBD are satisface condiţiile 1. şi 3., cu

observaţia că cerinţa 3. Este îndeplinită numai în raport cu funcţia de interogare

În ultimii ani, ca răspuns la necesitatea de a creşte complexitatea aplicaţiilor cu baze de

date (încurajată şi de progresele apărute în programare o dată cu programarea orientata obiect)

au apărut modelul de date orientat obiect (Object-Oriented Data Model - OODM) şi modelul

de date relaţional extins (Extended Relaţional Data Model - ERDM). Cu toate că modelul de

date ce sta la baza noilor modele nu este atât de clar că în cazul modelului relaţional, se poate

considera că aceste din urma dezvoltări reprezintă generaţia a patra de SGBD.

In esenţă, conceptul de bază de date poate fi definit ca fiind o colecţie partajată de date

aflate în interdependenţă logică (împreună cu o descriere a acestor date şi a relaţiilor dintre

ele), colecţie desemnată pentru a rezolva nevoia de informatizare a unei întreprinderi (sau

organizaţii).

Baza de date trebuie să îndeplinească următoarele condiţii:

- să asigure o independenţă sporită a datelor faţă de programe şi invers;

- structura bazei de date trebuie astfel concepută încât să asigure informaţiile necesare şi

suficiente pentru cerinţele de informare şi decizie;

- să asigure o redundanţă minimă şi controlată a datelor;

- să permită accesul rapid la informaţiile stocate în bază.

Bazele de date sunt extrem de variate în funcţie de criteriile luate în considerare. Prezentăm

câteva criterii de clasificare:

- după orientare: generalizate, specializate;

- după modelul de date: ierarhice, reţele, relaţionale, orientate obiect;

- după amploarea geografica: locale, distribuite;

Numim SGBD (Sistem de Gestiune al Bazelor de Date) un sistem software care

permite, pe de o parte, definirea, crearea şi întreţinerea bazei de date şi pe de alta parte,

permite accesul controlat la informaţiile din baza de date în cauză. SGBD este format din

Page 13: Baze de date_Iacob

12

programe de software care interacţionează cu programele de aplicaţie ale utilizatorilor şi cu

baza de date. Sistemul de gestiune al bazei de date asigură realizarea următoarelor activităţi:

- definirea structurii bazei de date;

- încărcarea datelor în baza de date;

- accesul la date (interogare, actualizare);

- întreţinerea bazei de date (colectarea şi reutilizarea spatiilor goale, refacerea bazei de

date în cazul unui incident);

- reorganizarea bazei de date (restructurarea şi modificarea strategiei de acces);

- integritatea datelor;

- securitatea datelor.

Aşadar, sistemul de gestiune al bazei de date apare ca un sistem complex de programe

care asigură interfaţa între o bază de date şi utilizatorii acesteia.

Clasificarea SGBD se poate realiza din mai multe puncte de vedere.

Din punctul de vedere al sistemelor de calcul pe care se implementează. SGBD pot fi:

sisteme de gestiune pentru calculatoarele mari;

sisteme de gestiune pentru minicalculatoare;

sisteme de gestiune pentru microcalculatoare.

In prezent se manifesta tendinţa ca marea majoritate a sistemelor de gestiune a bazelor de

date să fie compatibile pe platforme cât mai largi de sisteme de calcul.

2. Din punctul de vedere al limbajului pe care îl utilizează, sunt: sisteme cu limbaj gazdă;

sisteme cu limbaj autonom.

Sistemele cu limbaj gazdă realizează activităţile de creare, actualizare şi interogare a

bazei de date, utilizând limbajele de nivel înalt sau extensii ale acestora, proprii sistemului de

calcul pe care se implementează baza de date. Avantajul acestor sisteme constă în

posibilităţile sporite ce le oferă limbajele de nivel înalt la elaborarea unor proceduri complexe.

Sistemele cu limbaj gazdă prezintă dezavantajul că formularea cerinţelor nu este atât de

simplificată ca în cazul sistemelor cu limbaj autonom.

3. Din punctul de vedere al concepţiei de organizare a datelor pe care le gestionează, SGBD

se clasifică în: sisteme de gestiune a bazelor de date cu structuri ierarhice şi reţea; sisteme de

gestiune a bazelor de date relaţionale; sisteme de gestiune a bazelor de date orientate obiect.

4. Din punctul de vedere al modului de localizare a bazelor de date avem: sisteme de gestiune

a bazelor de date centralizate; sisteme de gestiune a bazelor de date distribuit e.

Marea majoritate a sistemelor de gestiune apărute în ultima perioadă dispun şi de o

componentă de gestiune distribuită a datelor.

Să ne reamintim...

Un SGBD este minimal relaţional dacă satisface următoarele condiţii:

Toate datele din cadrul relaţiei sunt reprezentate prin valori în tabele,

Nu există pointeri observabili de către utilizatori în tabele, în sensul că

operaţiile cu relaţii nu fac apel la pointeri, indecşi, fişiere inverse, etc.

Sistemul suportă operatori relaţionali de proiecţie, selecţie şi join natural, fără

limitări impuse de considerente interne (cum ar fi de exemplu, necesitatea

indexării atributelor). Unitatea de informaţie cu care se lucrează în cadrul

acestor operaţii trebuie să fie relaţia.

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

în plus următoarele condiţii:

Page 14: Baze de date_Iacob

13

Sistemul suportă toate operaţiile de bază ale algebrei relaţionale, fără limitări

impuse de considerente interne.

Sistemul suportă două dintre restricţiile de integritate de bază al modelului

relaţional şi anume unicitatea cheii unei relaţii şi restricţia referenţială.

În esenţă, conceptul de bază de date poate fi definit ca fiind o colecţie partajată

de date aflate în interdependenţă logică (împreună cu o descriere a acestor date

şi a relaţiilor dintre ele), colecţie desemnată pentru a rezolva nevoia de

informatizare a unei întreprinderi.

Clasificarea SGBD se poate realiza din mai multe puncte de vedere: din punctul

de vedere al sistemelor de calcul pe care se implementează. SGBD, din punctul

de vedere al limbajului pe care îl utilizează şi din punctul de vedere al

concepţiei de organizare a datelor pe care le gestionează

M1.U1.6. Rezumat

Conceptul de bază de date poate fi definit ca fiind o colecţie partajată de date

aflate în interdependenţă logică (împreună cu o descriere a acestor date şi a

relaţiilor dintre ele), colecţie desemnată pentru a rezolva nevoia de

informatizare a unei întreprinderi.

Sistemul de baze de date îşi are rădăcinile în anii '60, în proiectul de

aselenizare Apollo

Ideea principală în organizarea datelor se baza pe existenţa a trei componente

de bază:

schema de reţea - care reprezenta organizarea logica a întregii baze de date

subschema - care reprezenta o parte a bazei de date aşa cum e văzută de

utilizator sau de programele de aplicaţie

un limbaj de gestionare a datelor - care definea caracteristicile datelor,

structura lor şi care manipula datele

Pentru standardizare avem trei limbaje:

un limbaj de definire a datelor (LDD) la nivel de schemă

un limbaj la nivel de subschemă

un limbaj de manipulare a datelor (LMD)

Conceptele specifice organizării datelor în fişiere, SGBDR şi teoriei

relaţionale între care se pot stabili analogii

Organizarea datelor în

fişiere

SGBDR Teoria relaţională

Fişier Tabelă Relaţie

Record(înregistrare) Linie Tuplu

Câmp Coloană Atribut

Page 15: Baze de date_Iacob

14

Unitatea de învăţare 1.2 Abstractizarea datelor

M1.U1.1. Introducere

Un scop important al unui sistem de gestiune al bazelor de date este să poată

asigura o viziune abstractă asupra realităţii. Este necesar să se reţină din mulţimea

vastă de informaţii doar acelea care sunt necesare unei anumite aplicaţii.

M1.U1.2. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

înţeleagă care este structura pe trei nivele a bazei de date

înţeleagă ce este independenţa logică şi ce este cea fizică şi de ce este

importantă această independenţă

Durata medie de parcurgere a primei unităţi de învăţare este de 2 or e.

Se poate face referire spre exemplu la încercarea de modelare a unei aplicaţii într-o

întreprindere. Trebuie modelate 'obiectele' şi relaţiile dintre ele. Nu realitatea complexă în

totalitatea ei intră în discuţie ci doar o mică parte a ei, constituită din anumite 'obiecte' şi

pentru acele obiecte se iau în considerare doar o parte din caracteristici (acele caracteristici

care sunt importante pentru aplicaţia în cauza). Astfel în cazul modelării 'obiectului' (sau

entităţii) angajat, trebuie alese doar acele proprietăţi (sau atribute) care interesează. Acestea

ar putea fi, de exemplu: numele, adresa, salariul. O mulţime impresionantă de informaţii, care

contribuie la descrierea unei persoane anume, nu sunt luate în seamă, deoarece nu prezintă

interes pentru întreprindere.

Exemple

De exemplu, nu interesează dacă persoana are ochii albaştri, dacă este blondă

sau brunetă, dacă ascultă cu plăcere muzică sau dacă este o fire sentimentală.

Ce credeţi că ar interesa să memorăm despre studenţi într-o bază de date a

facultăţii?

Ce nu ar trebui memorat?

Mai mult decât faptul că realitatea este reprezentată codificat şi foarte simplificat,

deoarece baza de date este o resursă partajată, este foarte probabil ca fiecare utilizator s ă

dorească doar o parte din informaţiile stocate, funcţie de aplicaţia pe care o dezvoltă.

Page 16: Baze de date_Iacob

15

Pentru a se rezolva aceste cerinţe, se apelează la reprezentarea pe nivele a organizării

informaţiilor într-o baza de date. În general este acceptată arhitectura pe trei nivele ANSI-

SPARC.

Componentele bazei de date pot fi structurate pe trei nivele, în funcţie de clasa

utilizatorilor implicaţi şi de viziunea asupra structurării informaţiei, după cum urmează:

- nivelul logic de vizualizare (view) sau nivelul extern. Este dat de viziunea

programatorului de aplicaţii, care realizează programele de aplicaţii pentru manipularea

datelor la nivel de structură logică (subschema) corespunzătoare descrierii datelor aplicaţiei;

- nivelul conceptual (global). Este dat de viziunea administratorului bazei de date, care

realizează structura conceptuală (schema) corespunzătoare descrierii întregii baze de date şi

administrează componentele bazei de date. Acest nivel descrie ce date sunt memorate în baza

de date şi ce relaţii sunt stabilite între date. Nivelul conceptual reprezintă:

- toate entităţile, atributele lor şi relaţiile dintre ele;

- restricţiile impuse datelor

- informaţiile semantice despre date

- informaţiile privitoare la securitatea şi integritatea datelor.

- nivelul fizic. Este dat de viziunea inginerului de sistem care realizează structura fizică

corespunzătoare descrierii datelor pe suportul fizic (periferic). Acest nivel descrie cum sunt

memorate datele în baza de date. Nivelul intern se ocupă de:

- alocarea spaţiului de memorie pentru date şi indecşi;

- descrierea înregistrărilor pentru memorare;

- plasarea înregistrărilor pe suport;

- tehnicile de compresie şi de criptare a datelor.

View 1

View 2

View n

Schema

conceptuala

Schema

interna

Baza de

date

Utilizator 1 Utilizator 2

Nivel

extern

Nivel

conceptual

Nivel

intern

Organizarea la

nivel fizic a datelor

…..

Page 17: Baze de date_Iacob

16

Arhitectura ANSI-SPARC pe trei nivele

Să ne reamintim...

Componentele bazei de date pot fi structurate pe trei nivele, în funcţie

de clasa utilizatorilor implicaţi şi de viziunea asupra structurării informaţiei,

după cum urmează:

- nivelul logic de vizualizare (view) sau nivelul extern. Este dat de

viziunea programatorului de aplicaţii

- nivelul conceptual (global). Este dat de viziunea administratorului bazei

de date, care realizează structura conceptuală (schema) corespunzătoare

descrierii întregii baze de date şi administrează componentele bazei de date.

- nivelul fizic. Este dat de viziunea inginerului de sistem care realizează

structura fizică corespunzătoare descrierii datelor pe suportul fizic (periferic).

Scheme, corespondenţe şi instanţe

Descrierea generala a unei baze de date se numeşte schema bazei de date. Conform

nivelelor de abstractizare a datelor există trei tipuri de scheme pentru fiecare bază de date. La

nivelul cel mai înalt există (în general) mai multe scheme externe (numite şi subscheme)

care descriu diferitele view-uri ale bazei de date. La nivelul conceptual există schema

conceptuală iar la nivelul cel mai de jos de abstractizare există schema internă.

Pentru fiecare bază de date o singura schemă conceptuală descrie datele şi relaţiile

între ele, precum şi restricţiile de integritate. Schemei conceptuale îi corespunde o schemă

internă care descrie organizarea fizică a datelor.

SGBD realizează corespondenţa între cele trei nivele de abstractizare, realizând

corespondenţa între cele trei tipuri de scheme. Astfel corespondenţa conceptual / intern

leagă schema conceptuală de schema internă. Datorită acestei corespondenţe se identifică

înregistrarea sau combinaţia de înregistrări la nivel fizic, care constituie înregistrarea logică

în schema conceptuală, împreună cu restricţiile de integritate corespunzătoare. Analog, fiecare

schemă externă este legată de schema conceptuală prin corespondenţa extern / conceptual.

Aceasta corespondenţă permite SGBD să facă legătura între numele din view-urile utilizator

şi partea corespunzătoare relevantă din schema conceptuală. Este de reţinut că trebuie să

facem distincţie între descrierea bazei de date (schema bazei de date) şi baza de date propriu-

zisă. Numim instanţa (în cazul unei baze de date) datele aflate în baza de date la un anumit

moment dat. Altfel spus, mai multe instanţe pot să corespundă aceleiaşi scheme conceptuale

pentru o bază de date.

Page 18: Baze de date_Iacob

17

Să ne reamintim...

Descrierea generala a unei baze de date se numeşte schema bazei de date.

Conform nivelelor de abstractizare a datelor există trei tipuri de scheme

pentru fiecare bază de date. La nivelul cel mai înalt există (în general) mai

multe scheme externe (numite şi subscheme) care descriu diferitele view-uri

ale bazei de date. La nivelul conceptual există schema conceptuală iar la

nivelul cel mai de jos de abstractizare există schema internă.

Independenţa datelor

Un obiectiv major al arhitecturii pe trei nivele de abstractizare este realizarea

independenţei datelor. O aplicaţie, în general, este dependentă de date în sensul că

modificarea structurii de memorare a datelor sau a strategiei de acces la date afectează şi

aplicaţia. Independenţa datelor faţă de aplicaţie este totuşi necesară cel puţin din următoarele

considerente:

- diferite aplicaţii au nevoie de viziuni diferite asupra aceloraşi date;

- administratorul bazei de date trebuie să aibă libertatea de a schimba structura de memorare

sau strategia de acces, ca răspuns la cerinţe (schimbări de standarde, priorităţile aplicaţiilor,

unităţile de memorare etc.), fără a modifica aplicaţiile existente, baza de date existentă,

precum şi programele de exploatare a ei, care au fost folosite o perioadă de timp şi care

reprezintă o investiţie majoră la care nu trebuie să se renunţe prea uşor.

De aceea, se impune ca atunci când apar noi cerinţe în cadrul sistemului informaţional,

sistemele informatice să poată funcţiona cu programele şi procedurile existente, iar datele

existente să poată fi convertite.

Independenţa datelor trebuie privită din două puncte de vedere: independenţa fizică şi

independenţa logică a datelor.

Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de memorarea să

poată fi modificate fără a determina rescrierea programelor de aplicaţie. Aşadar independenţa

fizică a datelor reprezintă gradul de imunitate a schemei conceptuale la schimbările suferite

de schema internă.

Independenţa logică a datelor se refera la posibilitatea adăugării de noi înregistrări sau la

extinderea structurii conceptuale (globale), fără ca acest lucru să impună rescrierea

programelor existente. Cu alte cuvinte independenţa logică a datelor reprezintă gradul de

imunitate a schemelor externe la schimbările suferite de schema conceptuală.

Să ne reamintim...

Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de

memorarea să poată fi modificate fără a determina rescrierea programelor de

aplicaţie.

Independenţa logică a datelor se referă la posibilitatea adăugării de noi

înregistrări sau la extinderea structurii conceptuale (globale), fără ca acest lucru

să impună rescrierea programelor existente.

Page 19: Baze de date_Iacob

18

M1.U1.6. Rezumat

Componentele bazei de date pot fi structurate pe trei nivele, în funcţie

de clasa utilizatorilor implicaţi şi de viziunea asupra structurării informaţiei,

după cum urmează:

- nivelul logic de vizualizare (view) sau nivelul extern.

- nivelul conceptual (global

- nivelul fizic

Descrierea generală a unei baze de date se numeşte schema bazei de

date. Conform nivelelor de abstractizare a datelor există trei tipuri de scheme

pentru fiecare bază de date. Există (în general) mai multe scheme externe

(numite şi subscheme) care descriu diferitele view-uri ale bazei de date. La

nivelul conceptual există schema conceptuală iar la nivelul cel mai de jos de

abstractizare există schema internă.

Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de

memorarea să poată fi modificate fără a determina rescrierea programelor de

aplicaţie.

Independenţa logică a datelor se referă la posibilitatea adăugării de noi

înregistrări sau la extinderea structurii conceptuale (globale), fără ca acest

lucru să impună rescrierea programelor existente.

M1.U1.2. Test de autoevaluare a cunoştinţelor

1.2.1 Ce ar trebui memorat despre profesori într-o bază de date a facultăţii?

1.2.2 Ce nu ar trebui memorat despre profesori într-o bază de date a

facultăţii?

1.2.3 Ce este arhitectura pe trei nivele?

Răspunsurile se găsesc la sfârşit la pag 147

Page 20: Baze de date_Iacob

19

Unitatea de învăţare 1.3 Principalele componente şi funcţiuni al e unui SGBD

M1.U1.3. Introducere

Pentru a concepe şi a utiliza o bază de date trebuie să ştim ce putem cere de la o

bază de date şi de la un SGBD:

M1.U1.3. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

descrie componenţa unui Sistem de Gestiune al Bazei de Date

cunoască obiectivele unui SGBD

cunoască şi să utilizeze funcţiunile unui SGBD

Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Ţinând seama de faptul că există diferite tipuri de sisteme de gestiune, care se diferenţiază:

- prin limbajele utilizate,

- prin anumite componente ce imprimă diferite facilităţi de exploatare a bazei de date,

- şi prin faptul că unele oferă posibilitatea lucrului în regim de teleprelucrare, altele

numai în regim local, iar altele atât în regim local cât şi în regim de teleprelucrare,

ajungem la concluzia că nu poate fi stabilită o arhitectură unică, valabilă pentru toate

sistemele, ci apar particularităţi de la un sistem la altul.

Arhitectura unui SGBD evidenţiază componentele acestuia şi urmează standarde

internaţionale. O astfel de arhitectură generală cuprinde următoarele componente:

- baza de date propriu-zisă în care se memorează colecţia de date;

- sistemul de gestiune al bazei de date, care este un ansamblu de programe (soft) care

realizează gestiunea şi prelucrarea complexă a datelor;

- un set de proceduri manuale şi automate, precum şi reglementările administrative,

destinate bunei funcţionări a întregului sistem;

- un dicţionar al bazei de date (metabaza de date), ce conţine informaţii despre date,

structura acestora, elemente de descriere a semanticii, statistici, documentaţie etc.

- mijloacele hard utilizate (comune, specializate etc.);

- personalul implicat: (categorii de utilizatori: finali - (neinformaticieni); de specialitate

(administrator), analişti - programatori, gestionari, operatori).

Arhitectura bazei de date dă o imagine despre modul general de organizare şi funcţionare a ei.

Să detaliem câteva din componentele prezentate mai sus.

Page 21: Baze de date_Iacob

20

Limbajele utilizate într-un SGBD sunt de două tipuri: Limbajul de definire a datelor

(Data Definition Language - DDL) şi Limbajul de manipulare a datelor (Data Manipulation

Language - DML). Aceste limbaje mai sunt cunoscute ca sublimbaje de date deoarece ele nu

includ construcţii adecvate oricăror necesităţi de calcul, asemănătoare cu structurile puse la

dispoziţie de limbajele de nivel înalt.

Multe SGBD au facilitatea de a incorpora sublimbajul într-un limbaj de nivel înalt

(numit limbaj gazdă) cum ar fi COBOL, Fortran, Pascal, Ada, C. Pentru compilare, comenzile

sublimbajului sunt înlocuite în limbajul gazdă cu apeluri de funcţii. Fişierul preprocesat este

compilat, plasat într-un modul obiect, link-editat cu o bibliotecă în care se află funcţiile

înlocuite, furnizate o dată cu SGBD, şi este executat când este necesar.

Limbajul de Definire a Datelor (LDD) este un limbaj descriptiv care permite

administratorului bazei de date sau utilizatorilor să descrie şi să denumească entităţile şi

relaţiile care se pot stabili între acestea.

Schema bazei de date este definita cu ajutorul LDD. Rezultatul compilării declaraţiilor

în acest limbaj este constituit dintr-o serie de tabele memorate într-un Fişier special numit

dicţionar de date (se mai utilizează şi termenii de catalog de date sau director de date).

Datele memorate în acest dicţionar sunt date despre date şi de aceea se mai numesc şi

metadate. Definiţiile din dicţionarul de date se refera la înregistrări, la datele din înregistrări

şi la alte obiecte ce compun baza de date. SGBD consulta dicţionarul de date înaintea oricărui

acces la informaţii.

Teoretic, se poate identifica cate un LDD pentru fiecare nivel de abstractizare al

datelor, în realitate există un singur limbaj care tratează toate aspectele definirii datelor.

Limbajul de manipulare a datelor (LMD) furnizează un set operaţii care suporta

operaţiile de manipulare de baza asupra datelor din baza de date. Operaţii de baza sunt

inserarea, ştergerea, modificarea şi regăsirea datelor în baza de date. Manipularea datelor se

aplica la nivel conceptual şi extern.

Se cunosc doua tipuri de LMD: procedural şi non-procedural. Un LMD procedural

tratează înregistrările individual şi specifica cum trebuie obţinut rezultatul unei interogări. Cu

alte cuvinte trebuie să se specifice un algoritm de prelucrare a înregistrărilor cu ajutorul

operaţiilor puse la dispoziţie de limbaj.

În contrast, un LMD non-procedural specifica doar ce fel de rezultat trebuie obţinut.

SGBD translatează cererea din limbaj non-procedural transformând-o într-o procedura sau

într-o serie de proceduri care manipulează datele conform cererii utilizatorului. Limbajele

non-procedurale sunt mai uşor de utilizat deoarece scutesc utilizatorii de la a cunoaşte

implementarea interna a structurilor de date şi de la a stabili algoritmi de obţinere a

informaţiilor.

Partea componenta a unui LMD care se refera la regăsirea datelor se numeşte limbaj

de interogare. Înţelegem prin interogare orice cerere de acces la datele din baza de date,

formulata într-un limbaj de interogare.

4GL

4GL înseamnă Fourth-Generation Language (Limbaj de Generaţia a Patra). Nu există

încă un consens asupra semnificaţiei acestei denumiri. în general 4GL desemnează un limbaj

de programare de mare rapiditate pentru programator. Ceea ce se programează în sute de linii

de program într-un limbaj de generaţia a treia, poate să constituie câteva zeci de linii de

program într-un limbaj de generaţia a patra. Limbajele 4GL sunt non-procedurale şi se

Page 22: Baze de date_Iacob

21

bazează pe tools-uri performante. Utilizatorul trebuie să definească parametri pentru aceste

tools-uri iar acestea generează programe de aplicaţie pe baza parametrilor respectivi. Un

avantaj important al utilizării limbajelor 4GL este o productivitate deosebita în programare.

Un 4GL cuprinde:

- limbaje de interogare;

- generatoare de ecrane;

- generatoare de rapoarte;

- limbaje specializate cum ar fi spreadsheet-urile şi limbajele specifice bazelor de date;

- generatoare de aplicaţii, etc.

Exemple de limbaje de interogare 4GL sunt SQL şi QBE, limbaje comerciale asupra

cărora vom reveni ulterior.

Generatoare de ecrane

Un generator de ecrane este un tool cu ajutorul căruia se pot crea uşor şi rapid ecrane

pentru culegerea (introducerea) informaţiilor necesare programelor sau chiar pentru

introducerea şi modificarea datelor din baza de date.

Generatoare de rapoarte

Un generator de rapoarte ajuta la crearea de rapoarte (liste) pornind de la datele

memorate în baza de date. Se cunosc doua tipuri de generatoare de rapoarte: orientat pe limbaj

şi orientat visual. în primul caz se utilizează comenzile unui sublimbaj pentru a defini datele

ce se vor include în raport, în al doilea caz, acelaşi lucru se realizează cu ajutorul unei

facilităţi grafice similare cu generatorul de ecrane.

Generatoare de grafice

Un astfel de generator este o facilitate care regăseşte date din baza de date şi afişează

aceste date sub forma unor grafice.

Generatoare de aplicaţii

Utilizarea unui generator de aplicaţii poate reduce timpul necesar realizării unei

aplicaţii unitare. Generatoarele de aplicaţii constau în module predefinite care cuprind

majoritatea funcţiilor de baza ce sunt prezente în majoritatea programelor. Aceste module

constituie o biblioteca de funcţii la dispoziţia utilizatorilor.

Page 23: Baze de date_Iacob

22

Să ne reamintim...

Arhitectura unui SGBD cuprinde următoarele componente:

- baza de date propriu-zisă în care se memorează colecţia de

date;

- sistemul de gestiune al bazei de date, care este un ansamblu de

programe (soft) care realizează gestiunea şi prelucrarea

complexă a datelor;

- un set de proceduri manuale şi automate, precum şi

reglementările administrative, destinate bunei funcţionări a

întregului sistem;

- un dicţionar al bazei de date (metabaza de date), ce conţine

informaţii despre date, structura acestora, elemente de descriere

a semanticii, statistici, documentaţie etc.

- mijloacele hard utilizate (comune, specializate etc.);

- personalul implicat: (categorii de utilizatori: finali -

(neinformaticieni); de specialitate (administrator), analişti -

programatori, gestionari, operatori).

Obiectivele unui SGBD

După cum este cunoscut, obiectivul informaticii îl constituie culegerea, verificarea,

transmiterea, stocarea şi prelucrarea automata a datelor cu ajutorul mijloacelor electronice de

calcul, în scopul satisfacerii diferitelor nivele de conducere cu informaţii necesare luării

deciziilor, în condiţii de eficienta economica sporita.

In aceste condiţii, necesitatea acută de informare trebuie satisfăcută ţinând seama de o serie de

cerinţe prin care să se asigure:

- minimizarea costului procesului de prelucrare a datelor; creşterea vitezei de răspuns la

întrebările solicitate de utilizatori;

- adaptarea facilă a sistemului informatic la evoluţia în timp a sistemului informaţional

din care face parte;

- posibilitatea răspunsului la anumite întrebări neanticipate de către proiectanţii de

sistem;

- posibilitatea folosirii sistemului de informare dispunând de un minim de cunoştinţe

despre modul lui de organizare în general şi despre informatica în special;

- integritatea şi securitatea datelor etc.

In acest context, sistemului de gestiune al bazei de date îi revin o serie de obiective, cum sunt:

1. Asigurarea independenţei datelor.

Aşa cum am arătat mai devreme, acest obiectiv consta în linii mari din îndeplinirea următoarei

cerinţe: modificările care se fac la un anumit nivel de structura de date nu trebuie să fie

'vizibile' la nivelul de organizare imediat superior.

Page 24: Baze de date_Iacob

23

2. Asigurarea unei redundanţe minime şi controlate a datelor din baza de date.

Spre deosebire de sistemele clasice de prelucrare automata a datelor, stocarea datelor în cazul

bazelor de date se face astfel încât, pe cât posibil, fiecare informaţie să apară o singură dată.

Totuşi, nu sunt excluse nici cazurile în care, pentru a realiza performante sporite (mai ales în

ce priveşte timpul de acces la date şi implicit, timpul de răspuns la solicitările utilizatorilor) să

se accepte o anumita redundanta a datelor. în acest caz se va institui insa un control automat al

redundantei în vederea asigurării coerenţei datelor din baza.

3. Asigurarea unor facilităţi sporite de utilizare a datelor . Aceasta presupune:

- folosirea datelor de câtre mai mulţi utilizatori în diferite scopuri (aplicaţii);

- accesul cât mai simplu al utilizatorilor la date, fără ca aceştia să fie nevoiţi să cunoască

structura întregii baze de date, acest lucru rămânând în sarcina administratorului bazei

de date;

- existenta unor limbaje performante de regăsire a datelor, care permit exprimarea cu

uşurinţă a criteriilor de selecţie a datelor şi indicarea unor reguli cât mai generale pentru

editarea informaţiilor solicitate;

- spre deosebire de sistemul tradiţional bazat pe Fişiere, unde există un singur criteriu

de adresare (cel care a stat la baza organizării Fişierului) în cazul bazelor de date,

sistemul de gestiune trebuie să ofere posibilitatea unui acces multicriterial, fără sortări

suplimentare. Modificarea criteriului la fişierele clasice implică, în majoritatea

cazurilor, reorganizarea lor;

- utilizarea unui limbaj cât mai apropiat de limbajul natural, cu posibilitatea exploatării

bazei de date în regim conversaţional. Aceasta ar oferi posibilitatea exploatării în mod

facil a bazei de date şi de câtre utilizatorii neinformaticieni.

4. Sporirea gradului de securitate a datelor împotriva accesului neautorizat la ele.

Administratorul bazei de date poate prevedea ca accesul la baza de date să se facă numai prin

canale corespunzătoare, şi poate, totodată, defini verificări de autorizare care să se realizeze

oricând se încearcă accesul la anumite date.

5. Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate,

prin intermediul unor proceduri de validare, a unor protocoale de control concurent şi a unor

proceduri de refacere a bazei de date după incidente.

6. Asigurarea partajabilităţii datelor. Partajabilitatea datelor trebuie înţeleasă nu numai sub

aspectul asigurării accesului mai multor utilizatori la aceleaşi date, ci şi sub acela al

posibilităţii dezvoltării unor aplicaţii fără a se modifica structura bazei de date.

Să ne reamintim...

Obiectivele unui SGBD sunt:

Asigurarea independentei datelor.

Asigurarea unei redundante minime şi controlate a datelor din

baza de date.

Asigurarea unor facilităţi sporite de utilizare a datelor. Aceasta

presupune:

Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate

sau neintenţionate.

Asigurarea partajabilităţii datelor.

Page 25: Baze de date_Iacob

24

Funcţiile unui SGBD

Sistemele de gestiune a bazelor de date dispun de o serie de componente ce permit efectuarea

numeroaselor operaţii necesare funcţionării optime a sistemului. În funcţie de natura lor şi de

scopul urmărit, operaţiile pot fi grupate pe activităţi. Activităţile acceptă şi ele o grupare pe

funcţii (una sau mai multe activităţi, relativ omogene, realizează o anumita funcţie).

Ţinând seama de complexitatea sistemului de gestiune, de facilităţile oferite de acesta, de

limbajele utilizate şi de tipul bazei de date ce urmează a fi gestionată de SGBD, gruparea

activităţilor pe funcţii are un oarecare caracter relativ. În situaţia sistemelor de gestiune ce

utilizează limbaje gazdă de nivel înalt, identificarea şi delimitarea funcţiilor nu este atât de

evidentă. Totuşi, în ciuda acestor particularităţi, se pot prezenta câteva funcţii cu caracter de

generalitate pentru toate sistemele de gestiune a bazelor de date şi anume:

1. Funcţia de descriere a datelor permite definirea structurii bazei de date cu ajutorul

limbajului de definire. Definirea datelor poate fi realizată la nivel logic, conceptual şi fizic.

Aceasta funcţie asigură:

- descrierea atributelor (câmpurilor) din cadrul structurii bazei de date,

- descrierea legăturilor dintre entităţile bazei de date sau dintre atributele aceleiaşi

entităţi,

- definirea eventualelor criterii de validare a datelor,

- definirea metodelor de acces la date,

- definirea aspectelor referitoare la asigurarea integrităţii şi confidenţialităţii datelor, etc.

Toate acestea se concretizează în schema bazei de date, memorată în cod intern.

2. Funcţia de manipulare a datelor este cea mai complexa funcţie şi realizează următoarele

activităţi:

- crearea (încărcarea) bazei de date;

- adăugarea de noi înregistrări;

- ştergerea unor înregistrări;

- modificarea valorilor unor câmpuri;

- căutarea, sortarea şi editarea parţială sau totală a unei înregistrări virtuale etc.

Funcţia de manipulare a datelor se realizează prin intermediul limbajului de

manipulare a datelor.

3. Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor

utilizatorilor cu baza de date. Sunt recunoscute mai multe categorii de utilizatori:

- utilizatori "liberi" sau conversaţionali. Aceştia reprezintă categoria beneficiarilor de

informaţii (utilizatori finali) care utilizează limbajele de interogare a bazei de date într-o

formă simplistă. Ei apar ca utilizatori neinformaticieni;

- utilizatori programatori, care utilizează limbajele de manipulare, realizând proceduri

complexe de exploatare a bazei de date;

- administratorul bazei de date apare ca un utilizator special şi are rolul hotărâtor în ceea

ce priveşte funcţionarea optimă a întregului ansamblu.

Page 26: Baze de date_Iacob

25

4. Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de

competenţa administratorului bazei de date.

Să ne reamintim...

Funcţiunile unui SGBD sunt:

Funcţia de descriere a datelor permite definirea structurii bazei de

date cu ajutorul limbajului de definire.

Funcţia de manipulare a datelor.

Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru

comunicarea tuturor utilizatorilor cu baza de date.

Funcţia de administrare a bazei de date apare ca o funcţie

complexă şi este de competenţa administratorului bazei de date.

M1.U1.6. Rezumat

Arhitectura unui SGBD cuprinde următoarele componente:

- baza de date propriu-zisă în care se memorează colecţia de date;

- sistemul de gestiune al bazei de date, care este un ansamblu de

programe (soft) care realizează gestiunea şi prelucrarea complexă

a datelor;

- un set de proceduri manuale şi automate, precum şi

reglementările administrative, destinate bunei funcţionări a

întregului sistem;

- un dicţionar al bazei de date (metabaza de date), ce conţine

informaţii despre date, structura acestora, elemente de descriere a

semanticii, statistici, documentaţie etc.

- mijloacele hard utilizate (comune, specializate etc.);

- personalul implicat: (categorii de utilizatori: finali -

(neinformaticieni); de specialitate (administrator), analişti -

programatori, gestionari, operatori).

Obiectivul informaticii îl constituie culegerea, verificarea, transmiterea,

stocarea şi prelucrarea automata a datelor cu ajutorul mijloacelor

electronice de calcul, în scopul satisfacerii diferitelor nivele de

conducere cu informaţii necesare luării deciziilor, în condiţii de

eficienta economica sporita.

Obiectivele sunt:

Asigurarea independentei datelor.

Acest obiectiv consta în îndeplinirea cerinţei ca modificările care se fac

la un anumit nivel de structura de date să nu fie 'vizibile' la nivelul de

organizare imediat superior.

Asigurarea unei redundante minime şi controlate a datelor din

Page 27: Baze de date_Iacob

26

baza de date.

Pe cât posibil, fiecare informaţie să apară o singură dată. Nu sunt

excluse nici cazurile în care să se accepte o anumită redundanţă a

datelor.

Asigurarea unor facilităţi sporite de utilizare a datelor .

Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau

neintenţionate, prin intermediul unor proceduri de validare, a unor

protocoale de control concurent şi a unor proceduri de refacere a bazei

de date după incidente.

Asigurarea partajabilităţii datelor. Partajabilitatea datelor trebuie

înţeleasă şi sub aspectul posibilităţii dezvoltării unor aplicaţii fără a se

modifica structura bazei de date.

Funcţiunile unui SDGBD sunt

Funcţia de descriere a datelor care permite definirea structurii bazei

de date cu ajutorul limbajului de definire.

Funcţia de manipulare a datelor este cea mai complexă funcţie şi

realizează următoarele activităţi:

- crearea (încărcarea) bazei de date;

- adăugarea de noi înregistrări;

- ştergerea unor înregistrări;

- modificarea valorilor unor câmpuri;

- căutarea, sortarea şi editarea parţială sau totală a unei înregistrări

virtuale etc.

Funcţia de manipulare a datelor se realizează prin intermediul

limbajului de manipulare a datelor.

Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru

comunicarea tuturor utilizatorilor cu baza de date. Sunt recunoscute mai

multe categorii de utilizatori:

- utilizatori "liberi" sau conversaţionali. Ei apar ca utilizatori

neinformaticieni;

- utilizatori programatori, care utilizează limbajele de manipulare,

realizând proceduri complexe de exploatare a bazei de date;

- administratorul bazei de date apare ca un utilizator special şi are

rolul hotărâtor în ceea ce priveşte funcţionarea optimă a întregului

ansamblu.

Funcţia de administrare a bazei de date apare ca o funcţie complexă

şi este de competenţa administratorului bazei de date.

M1.U1.3. Test de autoevaluare a cunoştinţelor

1.3.1 Care sunt obiectivele unui SGBD?

1.3.2 Care sunt funcţiunile unui SGBD?

Răspunsurile se găsesc la sfârşit la pag 149

Page 28: Baze de date_Iacob

27

Unitatea de învăţare 1.4 Baze de date distribuite

M1.U1.4 Introducere

O baza de date distribuită (BDD) este o colecţie logic corelată de date

partajate, distribuite fizic pe o reţea de calculatoare.

Un sistem de gest iune al unei baze de date distribuite (SGBDD) este un

sistem software care permite gestionarea BDD şi face distribuirea transparentă

pentru utilizator.

Sistemele de date distribuite sunt menite să rezolve problema "insulelor de

informaţii". Ele au apărut ca o necesitate, în special in cazul reţelelor de

calculatoare, pentru a sprijini gestionarea datelor în situaţia când acestea se

regăsesc fizic în diferite puncte ale reţelei.

M1.U1.4. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

înţeleagă ce este o bază de date distribbuită

cum se proiectează o bază de date distribuită

Durata medie de parcurgere a primei unităţi de învăţare este de 2 o re.

Generalităţi

Primele sisteme de baze de date distribuite au fost INGRES/STAR, versiune

distribuită a lui INGRES, SQL*STAR versiune distribuită a lui ORACLE şi R* versiune

distribuita a lui DB2.

Sistemul fizic (reţeaua) care constituie suportul unei baze de date distribuite poate fi

format din calculatoare personale, minicomputere, staţii de lucru, etc. toate legate în reţea şi

numite generic site-uri.

Putem reformula definiţia de la început spunând ca un sistem de baze de date

distribuite constă dintr-o colecţie de site-uri, fiecare putând participa la executarea

tranzacţiilor care accesează datele de pe un site sau de pe mai multe site -uri.

Printre cerinţele pe care trebuie să le asigure un sistem de baze de date distribuite

menţionăm: autonomia locala în organizarea şi prelucrarea datelor, neutilizarea unei

centralizări a evidenţei şi a datelor, posibilitatea de lucru continuu al site-urilor independent

de schimbările in configuraţiile de lucru (adăugari sau eliminari de site-uri), independenţa

localizării şi fragmentării datelor (transparenţa fizică), posibiliăţti de replicare (copiere) şi

independenţa copiilor, prelucrarea distribuită a cererilor, administrarea distribuită a

tranzacţiilor, independenţa de hardware, de sistemul de operare, de reţea şi de sistemul de

gestiune a bazelor de date.

Page 29: Baze de date_Iacob

28

Un SGBDD constă dintr-o singură bază de date care este descompusă în fragmente,

eventual unele fragmente sunt multiplicate, şi fiecare fragment sau copie se pastrează pe unul

sau mai multe site-uri, sub controlul unui SGBD local. Fiecare site este capabil sa proceseze

interogări utilizator în regim local, independent de restul reţelei, sau este capabil să participe

la procesarea unor date situate în alte site-uri din reţea. Pentru a spune că un SGBD este

distribuit trebuie să existe cle puţin o cerere globală.

Tranzacţiile într-o baza de date distribuită sunt clasificate în tranzacţii locale şi

tranzacţii globale după site-urile pe care le solicită excutarea lor.

O configuratie pe retea reprezinta o baza de date distribuita daca diversele site-uri sunt

"constiente" de existenta celorlalte site-uri şi daca fiecare site ofera un mediu in care se pot

executa tranzactii locale şi globale.

Avantajele distribuirii bazelor de date:

- sistemul distribuit se modelează cel mai bine pe structura organizaţională a multor

organizaţii, avand în vedere ca multe companii sunt localizate "distribuit" din punct de

vedere geografic

- datele sunt partajabile dar administrarea lor se bucură de un grad înalt de autonomie locală

- disponibilitatea bazei de date este evident mai bună decât în cazul centralizat. Dacă se

semnalează unele erori sau "ăderi" de sistem la nivel local sistemul ]n întregime poate să

continue să funcţioneze în condiţii satisfăcătoare

- fiabilitatea sistemului este îmbunătăţită. Se pot reface rapid fişiere distruse utilizând

replici aflate pe alte site-uri

- performanţele în prelucrarea datelor se îmbunătăţesc prin posibilitatea prelucr[rii în

paralel a unor interog[ri

- un sistem distribuit oferă avanatje economice dacă luăm în considerare costurile

implementării şi întreţinerii unei reţele faţă de costurile corespunzătoare ale unui sistem

centralizat de putere comparabilă de prelucrare. Costuri scazute se mai obtin daca se

realizeaza prelucrări locale cât mai multe (în cază sistemul şi aplicaţiile permit acest

lucru). De asemenea este mult mai convenabil să se "ajusteze" o reţea de calculatoare la

nevoile organiza’iei (dac[ de exemplu este necesară adăugarea unor site-uri în plus) decât

un calculator central de putere asemănătoare

- capacitatea de gestionare modulară a sistemului permite extensii ale acestuia sau

rezolvarea unor "căderi" parţiale fără să se afecteze prea tare (uneori fără a se afecta

deloc) mersul activităţilor pe ansamblul sistemului distribuit.

Printre dezavantajele distribuirii amintim complexitatea crescuta a unui astfel de sistem.

Acesta este un dezavantaj major din care decurg unele dezavantaje "consecinta" dintre care:

- este mai greu de gestionat şi de implementat un sistem distribuit

- costurile legate de un astfel de sistem sunt mult mai mari decat in cazul centralizat. Deja la

nivelul proiectarii şi implementarii sistemului este necesar mai mult timp şi personal

specializat. Ambele lucruri necesita costuri mai mari in bani. La aceste costuri se pot

adauga acelea care vin din necesitatea asigurarii echipamentelor hardware performante şi

a soft-ului necesar. De asemenea, in cazul exploatarii sistemului la costurile obisnuite se

vor adauga costuri destul de ridicate de comunicatii.

- potential marit de erori. La erorile obisnuite in lucrul cu baze de date se pot adauga o serie

de erori cum ar fi de exemplu cele generate de algoritmi distribuiti.

Page 30: Baze de date_Iacob

29

- este necesara o procesare suplimentara care se datoreaza schimburilor de mesaje intre site-

uri şi a coordonarii acestora in general

- securitatea unui sistem distribuit este mai greu de asigurat decat in cazul unui sistem

centralizat. Datele sunt mai usor disponibile unor persoane neautorizate deoarece se poate

incerca acces la ele prin intermediul accesului intre calculatoare. Controlul la nivel fizic

administrativ are mai putina pondere decat in cazul unui sistem centralizat.

- intergitatea datelor este de asemenea mai greu de realizat intr-un sistem distribuit.

Integritatea se exprima de obicei in termeni de restrictii (reguli, conditii) pe care trebuie sa

le verifice datele din baza de date. Datorita costurilor mari de comunicatii (in timp şi bani)

uneori se renunta la verificarea unor reguli in detrimentul consistentei bazei de date.

- lipsa standardelor. Nu se poate vorbi de o lipsa totala de standarde dar, lucrul cu sisteme

de date distribuite inca nu are la baza standarde internationale unanim acceptate. De aici

decurg dezavantaje cum ar fi: probleme de comunicare care se pun deoarece standardele

de comunicatii şi protocoalele de acces la date inca nu au standarde fixate şi acceptate pe

scara larga. Nu exista foarte multa experienta privind lucrul distribuit şi proiectarea,

gestionarea şi exploatarea unui sistem distribuit sunt mai dificile decat in cazul centralizat.

- un alt dezavantaj pe care il mentionam aici il constituie posibilitatea aparitiei unui flux

mare de informatii intre site-uri şi de aici necesitatea rezolvarii unor probleme cum ar fi

sincronizarea mesajelor, detectarea şi corectarea unor perturbari, eliminarea unor

inconsistente datorate redundantelor, etc.

Functiile şi arhitectura unui SGBDD

Enumeram mai jos functiile principale ale unui SGBDD:

- toate functiile pe care le atribuim unui SGBD centralizat

- sa extinda comunicatiile pentru a furniza acces la site-urile din retea şi sa permita

transferul de date şi realizarea interogarilor

- sa gestioneze un dictionar de date extins pentru detalii legate de modul de distribuire a

datelor

- sa permita şi sa sustina procesarea distribuita a interogarilor

- sa faciliteze un control extins al concurentei in scopl mentinerii unui grad satisfacator al

consistentei datelor

- sa ofere servicii de recovery extinse care sa rezolve caderi ale site-urilor şi ale

comunicatiilor

Arhitectura ANSI-SPARC pe trei nivele a unei baze de date distribuite este redata grafic in

pagina urmatoare, Fig 7.1. Dam mai jos cateva explicatii referitoare la unele elemente

prezente in schema:

- schema conceptuala globala este o descriere logica a intregii baze de date, fara a se

evidentia aspectul distribuit. La acest nivel se definesc entitatile, relatiile, restrictiile de

integritate, informatiile generale de securitate a datelor.

- schemele de fragmentare descriu modelul logic al partitionarii bazei de date iar alocarea

descrie repartizarea fragmentelor şi a eventualelor copii ale acestora pe site -urile retelei

- schemele locale de mapare redau fragmentele din schema de alocare in "obiecte" externe

bazei de date locale. Aceasta descriere este independenta de SGBD-ul ales şi datorita

acestui fapt se poate vorbi de SGBD heterogene.

Page 31: Baze de date_Iacob

30

Ca o paranteza mentionam aici clasificarea SGBD-urilor distribuite in heterogene şi

omogene.

SGBD omogene reprezinta situatia cand pe toate site-urile din retea este hardware similar,

sistem de operare identic si, cel mai important, SGBD local identic.

În cazul SGBD heterogene exista mai multe situatii dupa cum difera dotarea hardware,

sistemele de operare si/sau SGBD-urile utilizate local pe site-uri. Diferentele pot fi impinse

pana la a avea structuri ale bazei de date diferite (date de modele de date diferite) dar, evident,

lucrul in acest caz este destul de greoi şi este supus multor limitari.

În cadrul unui SGBDD putem identifica urmatoarele componente:

- o componentă locală SGBD (LSGBD)

- o componentă de comunicaţii de date (CD)

- un dicţionar de date global (DDG). Acest dicţionar are aceeaşi funcţionalitate ca şi und

dicţionar de date în cazul SGBD centralizat dar conţine informaţii suplimentare referitoare

la fragmentare şi la alocarea datelor. Şi DDG poate fi fragmentat şi replicat ca orice altă

informaţie din baza de date distribuită

- componente de SGBD distribuit (SGBDD)

Proiectarea unei baze de date relaţionale distribuite

Proiectarea corectă a unei baze de date relaţionale distribuite necesită, pe lângă cerinţele

cunoscute pentru sistemele centralizate, şi realizarea următoarelor:

- fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi stocate

pe diferite site-uri în reţea

- replicarea – se pot realiza copii ale diferitelor relaţii sau ale fragmentelor

- alocarea fragmentelor şi a replicilor pe diferite site-uri

Definirea fragmentelor şi alocarea acestora pe site-uri au ca obiective:

- realizarea, pe cat posibil a accesului in regim de referinte locale. Acolo unde este necesar

şi unde permite aplicaţia se recomanda utilizarea de copii ale fragmentelor

- obtinerea unei fiabilitati şi a unei disponibilitati deosebite ale bazei de date prin utilizarea

optima a replicarii fragmentelor

- realizarea unor parametri deosebiti de performanta. Daca se aloca prost datele pe site-uri

se ajunge fie la suprasolicitarea unui site (loc ingust) fie la utilizarea resurselor la un nivel

inferior

- optimizarea capacitatii şi a costurilor de stocare. Capacitatea şi costuril de stocare trebuie

puse in balanta cu tendinta de a avea referinte locale, deoarece au efecte contrare.

- optimizarea costurilor de comunicare. Aici sunt de luat in considerare mai ales costurile

interogarilor intre site-uri. Trebuie sa se aiba in vedere ca, daca se pot micsora costurile de

regasire atunci cand referintele sunt mai ales locale (sau cand fiecare site are propriile

copii ale datelor) in schimb actualizarile in aceeasi situatie pot creşte costurile foarte mult

(si riscul obtinerii inconsistentei) deoarece trebuie sa fie realizate asupra datelor de la toate

site-urile.

Alocarea datelor

Page 32: Baze de date_Iacob

31

Se cunosc patru strategii de alocare a datelor într-o baza de date relaţională distribuită:

1. centralizat

Baza de date se află în întregime pe un singur site din reţea şi este gestionată de un singur

DBMS. Spunem în acest caz că baza de date este procesată distribuit, ea de fapt nu mai

este o bază de date distribuită in adevaratul sens al cuvântului. Dezavantajele sunt mai ales

costurile mari de comunicaţii şi o fiabilitate şi o disponibilitate foarte scăzute, având în

vedere că orice eroare care blochează accesul la baza de date, practic paralizează întreaga

activitate în reţea pe această direcţie.

2. fragmentat (partiţionat)

Baza de date este partiţionată în mai multe fragmente disjuncte care sunt stocate pe

diverse site-uri. Comentarii:

- aceasta parţitionare a datelor poate îmbunătăti frecvenţa referinţelor locale

- dacă nu există replici ale fragmentelor, costurile de stocare sunt reduse

- fiabilitatea şi disponibilitatea sunt scăzute dar nu aşa de mici ca în cazul centralizat

- dacă datele sunt distribuite corect, costurile de comunicare pot fi relativ scăzute

3. replicat complet

Pe fiecare site se găseste o copie completă a bazei de date. Comentarii:

- eficienţa referirilor locale, fiabilitatea şi disponibilitatea sunt maxime

- costurile de stocare sunt în schimb şi ele foarte mari, la fel sunt şi costurile de

actualizare

4. replicat selectiv

Aceasta strategie este o combinaţie intre partiţionare, replicare şi centralizare cu scopul de

a se cumula, pe cat posibil, avantajele fiecărei strategii şi să se elimine dezavantajele.

Definirea replicilor şi a fragmentelor, precum şi alocarea acestora trebuie sa se bazeze pe

modul de utilizare a datelor din baza de date. In faza de analiza, la proiectarea bazei de date

trebuie sa se tina cont de cele mai frecvent utilizate aplicaţii deoarece nu se poate realiza o

alocare care sa optimizeze toate aplicaţiile simultan.

Printre criteriile care duc la decizia corecta de alocare a bazei de date:

- frecventa cu care se ruleaza o aplicaţie

- site-urile de la care se ruleaza cel mai frecvent aplicaţia

- modul de lucru al tranzactiilor executate de aplicaţie şi tipurile de acces la date

- etc.

Fragmentarea

La baza fragmentarii bazei de date exista, printre altele, urmatoaele motivari:

- mod de utilizare – in general intr-o aplicaţie utilizatorii au acces mai mult la view-uri

decat la intreaga baza de date

- eficienta – se doreste ca datele sa fie stocate acolo unde sunt utilizate mai frecvent

- paralelism – o tranzactie poate fi divizata in mai multe subinterogari care opereaza pe

fragmente in paralel şi astfel se castiga t imp

Page 33: Baze de date_Iacob

32

- securitate – datele care nu sunt necesare sunt stocate in alta parte, deci nu sunt la

dispozitia accesului neautoarizat

Dezavantajele lucrului cu fragmente ale bazei de date:

- performantele pot fi destul de scazute daca sunt necesare date ce apar in diverse

fragmente

- controlul integritatii datelor este mai dificil daca datele şi dependentele functionale

sunt fragmentate şi localizate pe diferite site-uri

Reguli de bază care duc la o fragmentare corectă a bazei de date:

1. completitudine – dacă relaţia R este descompusă în fragmentele R1, R2, …,Rn, trebuie

luate măsuri care să prevină pierderea de informaţii

2. reconstrucţie – să fie posibil în orice moment să se refacă relaţia R de la care s -a pornit

cu fragmentarea. Aceasta regulă conservă dependenţele funcţionale.

3. disjuncţie – dacă data di apare în fragmentul Ri atunci nu este permis să apară în nici

un alt fragment. De la această regulă se admite doar o excepţie, cazul când o relaţie

este fragmentată pe verticală.

Tipuri de fragmentare:

- pe orizontală

- pe verticală

- combinată

Fragmentarea pe orizontală:

Ne putem imagina că o tabelă se fragmentează orizontal ca mai jos:

Un fragment al unei relaţii partitionate pe orizontală constă dintr-o submulţime a tuplelor

relaţiei respective.

Un fragment orizontal se produce prin selecţie:

Fiecare tuplu din relatia R apare într-un anume fragment, o singură dată. Dacă se doreşte

reconstrucţia relaţiei, se utilizează reuniunea pentru a obţine relaţia R iniţiala.

R= R1R2…Rn

In general fragmentele unei relaţii R sunt disjuncte.

Fragmentarea pe verticală

Un fragment vertical dintr-o relaţie consta dintr-o relaţie care are ca atribute o submulţime a

atributelor relaţiei iniţiale.

Un fragment vertical se produce prin proiecţie:

Dacă S1R şi S2R atunci )(11 Rr S şi )(22 Rr S .

Page 34: Baze de date_Iacob

33

Completitudinea este asigurată prin faptul că fiecare atribut apare cel puţin într- una din

submulţimile S1 şi S2.

Reconstrucţia relaţiei iniţilale se realizează prin joncţiune naturală.

21)( rXrRr N

Aşadar la descompunerea relaţiei iniţiale în fragmente trebuie să se ţină seama de regulile care

asigură o descompunere fără pierderi la joncţiune.

In cazul descompunerii pe verticală nu este posibil să se realizeze o disjuncţie totală. Se

admite existenţa unor atribute comune, şi anume a atributelor care formează cheile primare

(respectiv cheile externe). Fragmentele verticale se stabilesc prin determinarea afinităţilor

între atribute, încă din faza de analiză.

Fragmentarea combinată (mixtă, hibridă, compusă)

1. fragmente verticale fragmentate orizontal

Expresia corespunzatoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai

sus) este: ))(( ,...,1R

nAAP

2. fragmente orizontale fragmentate vertical

Expresia corespunzătoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai

sus) este: ))((,...,1RPAA n

Transparenţa în SGBDD

Prima regula, considerată regula de baza in sistemele distribuite, este cerinta ca

aspectul distribuit trebuie sa fie transparent pentru util izator.

Cu alte cuvinte utilizatorul nu trebuie sa-si dea seama ca lucreaza cu o baza de date

distribuita, deci nu trebuie sa aiba cunostinte in plus ca sa utilizeze resursele unei astfel de

baze de date.

În realitate transparenţa poate fi realizată doar într-o anumită măsură. Tipuri de

transparenţă:

1. transparenţa distribuirii

2. transparenţa tranzacţiilor

3. transparenţa performanţelor

Transparenţa distribuirii

Page 35: Baze de date_Iacob

34

Dacă se realizează transparenţa distribuirii, utilizatorul percepe baza de date ca pe o

entitate unitară din punct de veder logic.

Acest tip de transparenţă se poate descompune în două aspecte: utilizatorul nu trebuie

să cunoască faptul că există fragmentarea datelor (transparenţa fragmentării) sau utilizatorul

nu ştie de localizarea datelor pe reţea (transparenţa localizării).

Transparenţa fragmentării este cel mai înalt grad de transparenţa. Utilizatorul se

adresează cu interogări bazei de date ca şi când ar fi localizată centralizat, deci nu trebuie să

se preocupe de existenţa fragmentelor.

Transparenţa fragmentării este strâns legată de acordarea numelor (identificatorilor) în

cadrul bazei de date distribuite. Şi într-o bază de date distribuită (ca şi în cazul centralizat)

numele diferitelor "obiecte" trebuie să fie unic. Două site-uri nu pot conţine obiecte cu nume

identice.

Sunt cateva solutii posibile:

1. Se poate crea un server central de nume care are menirea sa sigure ca numele date in

aplicaţii distribuite sunt nume unice pe toata baza de date. Aceasta abordare are

dezavantajele ca se pierde autonomia locala a site-urilor, se poate ajunge la o

suprasolicitarea serverului de nume (se creeaza un asa-numit loc ingust - "bottleneck") şi

disponibilitatea bazei de date este redusa (daca serverul de nume iese din uz temporar, se

blocheaza accesul la date)

2. Alternativa la solutia de mai sus este sa se recurga la prefixarea obiectelor cu un

identificator de site, de fragment, de copie.

Exemple

Prin notatia s1.client.f3.c2 se poate desemna copia a doua a

fragmentului 3 a tabelei client care se afla pe site-ul s1.

Consecinta cea mai grava a acestui mod de a numi obiectele este pierderea completa a

transparentei. In aceasta situatie mai exista un mod prin care se poate "indulci" situatia: se

utilizeaza alias-uri. De exemplu s1.client.f3.c2 poate avea ca alias numele client_local pentru

utilizatorii site-ului s1.

Transparenta localizarii reprezinta un nivel mediu de transparenta. In aceasta situatie

utilizatorul stie cum este fragmentata baza de date dar nu stie unde sunt plasate diferitele

fragmente sau copii ale acestora.

În interogari vor aparea numele fragmentelor dar nu se vor face referiri la localizare. O

interogare poate avea un format asemanator cu cel de mai jos:

select A1,…An

from f1

where conditie1

union

select A1,…An

from f2

… … …

Avantajul major in cazul de mai sus consta in faptul ca se poate oricand reorganiza

baza de date (ca locatii) fara ca aplicaţiile ce o utilizeaza sa trebuiasca modificate.

Page 36: Baze de date_Iacob

35

Transparenta maparii locale reprezinta cel mai jos nivel al transparentei distribuite.

Utilizatorul trebuie sa specifice şi numele fragmentelor şi localizarea datelor.

Transparenţa tranzacţiilor

Acest tip de transparenţa asigură faptul că toate tranzacţiile distribuite păstrează

integritatea şi consistenţa BDD.

O tranzacţie distribuită accesează date stocate la mai mult de o locaţie în reţea. Fiecare

tranzacţie e divizata în sub-tranzacţii, câte una pentru fiecare site accesat. Sub-tranzacţiile se

execută în paralel pe site-uri şi în mod concurent pe fiecare site. SGBDD are sarcini deosebite

în legătură cu gestionarea tranzacţiilor distribuite dar acestea nu vor fi tratate in acest capitol.

În cadrul transparenţei tranzacţiilor se tratează în mod deosebit transparenţa

concurenţei şi transparenţa erorilor. SGBDD oferă transparenţă concurenţei dacă rezultatele

tuturor tranzacţiilor concurente (distribuite sau nu) sunt executate independent şi sunt logic

echivalente cu rezultatele obtinuţe în cazul în care tranzacţiile sunt executate pe rând, într-o

ordine serială arbitrară.

Transparenţa erorilor necesită şi un mecanism de recovery care ne să asigure că

tranzacţiile se comportă atomic în faţa erorilor: ori sunt executate toate operaţiile unei

tranzacţii ori nici o operaţie nu este executată. Odată ce o tranzacţie s-a executat,

transformările operate de ea asupra bazei de date sunt durabile (permanente).

Transparenţa performanţelor

Transparenţa performanţelor se asigură prin cerinţa ca sistemul considerat să aibă

performanţe comparabile cu ale unui sistem centralizat. În această situaţie trebuie ca SGBDD

să determine strategia cea mai eficientă de a executa fiecare interogare în parte. În acest scop

un DQP (Distributed Query Processor) mapeaza o cerere de date într-o secvenţă ordonată de

operatii asupra bazei de date. DQP decide ce fragment se accesează, ce copie se utilizează,

care locaţie se utilizează. DQP produce o strategie de execuţie care este optimizată relativ la o

funcţie de cost. Costul asociat cu o interogare distribuita include:

- timp de acces (input/output) la accesarea datelor fizice pe suportul respectiv,

- timp CPU la executatrea operatiilor asupra datelor in memoria principala,

- costuri de comunicatii asociate cu transmiterea datelor prin retea.

M1.U1.6. Rezumat

O baza de date distribuită (BDD) este o colecţie logic corelată de date partajate,

distribuite fizic pe o reţea de calculatoare.

Tranzacţiile într-o baza de date distribuită sunt clasificate în tranzacţii locale şi

tranzacţii globale după site-urile pe care le solicită excutarea lor.

Proiectarea corectă a unei baze de date relaţionale distribuite necesită, pe lângă

cerinţele cunoscute pentru sistemele centralizate, şi realizarea următoarelor:

- fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi

stocate pe diferite site-uri în reţea

- replicarea – se pot realiza copii ale diferitelor relaţii sau ale fragmentelor

- alocarea fragmentelor şi a replicilor pe diferite site-uri

Page 37: Baze de date_Iacob

36

Se cunosc patru strategii de alocare a datelor într-o baza de date relaţională

distribuită:

centralizat

fragmentat (partiţionat)

replicat complet

replicat selectiv

Tipuri de fragmentare:

- pe orizontală

- pe verticală

- combinată

Prima regula, considerata regula de baza in sistemele distribuite, este cerinta ca

aspectul distribuit trebuie sa fie transparent pentru utilizator.

Cu alte cuvinte utilizatorul nu trebuie sa-si dea seama ca lucreaza cu o baza de date

distribuita, deci nu trebuie sa aiba cunostinte in plus ca sa utilizeze resursele unei

astfel de baze de date.

În realitate transparenţa poate fi realizată doar într-o anumită măsură. Tipuri de

transparenţă:

transparenţa distribuirii

transparenţa tranzacţiilor

transparenţa performanţelor

M1.U1.4. Test de autoevaluare a cunoştinţelor

1.4.1 Ce este o bază de date distribuită?

1.4.2 Care sunt avantajele unui sistem distribuit?

1.4.3 Cum se poate face proiectarea alocării datelor?

1.4.4 Cum se face o fragmentare corectă?

1.4.5 Ce este fragmentarea?

Răspunsurile se găsesc la sfârşit la pag 149

Page 38: Baze de date_Iacob

37

Modulul 2. Modele de descriere a datelor

Cuprins

Introducere

Obiectivele modulului

U2.1 Generalităţi

U2.2 Modelare E-R (Entity-Relaţionship)

Introducere

Numim model de date o colecţie integrată de concepte pentru

descrierea datelor, de relaţii între date şi de restricţii asupra datelor,

toate într-o organizare unitară.

Un model de date este o abstracţie. Un model de date are în

principal rolul de a furniza conceptele de bază şi notaţiile care să

permită proiectanţilor şi utilizatorilor bazei de date să comunice în

mod neambiguu legat de modul de organizare a datelor.

M3. Obiectivele modulului

La sfârşitul acestui modul studenţii vor fi capabili să:

aleagă ce model de date vor folosi pentru baza concretă de date

distingă modele la diferite nivele

descrie structura bazei de date cu ajutorul unui model grafic

să aleagă cheia unei relaţii în mod optim

Page 39: Baze de date_Iacob

38

Unitatea de învăţare 2.1. Generalităţi

M2.U2.1. Introducere

Un model de date cuprinde trei părţi:

(1) o parte referitoare la structură, care constă într-un set de reguli ce impun

modul de alcătuire al bazei de date;

(2) o parte referitoare la manipularea datelor, care defineşte tipul de operaţii care

sunt permise asupra datelor. Sunt incluse aici operaţiile care sunt utilizate

pentru a actualiza sau a regăsi datele în baza de date precum şi operaţiile

pentru schimbarea structurii bazei de date;

(3) o parte referitoare la integritatea datelor, parte care cuprinde reguli de

integritate care asigura acurateţea datelor.

M2.U2.1. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

aleagă ce model de date vor folosi pentru baza concretă de date

distingă modele la diferite nivele

Durata medie de parcurgere a primei unităţi de învăţare este de 1 oră.

Modele de date se pot realiza pentru fiecare nivel de abstractizare. Astfel putem vorbi de:

model extern de date (care reprezintă aşa-numitul univers al discursului, adică punctul de

vedere al utilizatorului);

model de date conceptual (care reprezintă structura logica a bazei de date, independenta de

sistemul de gestiune ales);

model de date intern (care reprezintă schema conceptuala într-un mod în care poate fi

perceputa de SGBD).

Dintre diversele modele propuse în literatura de specialitate menţionam aici: modelele de

date bazate pe obiecte, modelele de date bazate pe înregistrare, ambele modele fiind utilizate

pentru descrierea organizării datelor la nivel extern şi conceptual. Trebuie să menţionam şi

modelele fizice de date, care descriu datele la nivel intern.

Aceste modele utilizează concepte specifice modelului E-R şi anume: entităţi, atribute,

relaţii. Cele mai cunoscute modele de date sunt: modelul entitate-relaţie, modelul semantic,

modelul funcţional, modelul orientat obiect.

Modele de date bazate pe înregistrare

Într-un astfel de model baza de date consta dintr-un număr de înregistrări de format fix

de tipuri eventual diferite. Fiecare tip de înregistrare defineşte un număr fix de câmpuri,

Page 40: Baze de date_Iacob

39

fiecare fiind în general de lungime fixa. Exista trei tipuri importante de modele de date bazate

pe înregistrare: modelul de date relaţional, modelul de date reţea şi modelul ierarhic de

date.

Modelele ierarhic şi reţea au fost dezvoltate mai întâi, modelul relaţional apărând cu o

întârziere de un deceniu.

Modele fizice de date

Aceste modele descriu efectiv modul în care datele sunt memorate în calculator, la

nivel fizic. Informaţia furnizata de aceste modele este cea referitoare la înregistrările fizice, la

căi de acces, la organizarea înregistrărilor, etc.

Se considera că schema conceptuala sta la baza structurării unei baze de date. O

schema conceptuala completa şi bine gândită permite o reprezentare interna eficienta şi

permite realizarea de view-uri utilizator fără dificultate.

Modelarea conceptuala sau proiectarea conceptuala a bazei de date este procesul de

construire a unui model care să reprezinte modul în care este utilizata informaţia de câtre

beneficiar, reprezentare care este independenta de detaliile de implementare cum ar fi

programele de aplicaţie, limbajele de programare, SGBD-ul utilizat sau orice alte consideraţii

fizice. Un astfel de model se numeşte model de date conceptual sau model logic.

Modelare E-R (Entity-Relaţionship)

Modelul E-R (Entity-Relaţionship) este un model conceptual de nivel înalt, dezvoltat

de Chen în 1976. Primele idei legate de utilizarea modelului E-R la proiectarea unei baze de

date au fost expuse de Chen (1977) şi au fost continuate de Sakai (1980). Conceptele de

specializare şi generalizare au fost introduse de Smith şi Smith (1977) şi au fost utilizate

ulterior de Lenzerini şi Santucci (1983) la definirea restricţiilor de cardinalitate. Având în

vedere limitele modelului E-R, vom discuta un model mai complex, modelul EE-R şi

conceptul principal asociat acestuia, conceptul de specializare/generalizare.

M2.U2.1. Rezumat

Putem vorbi de:

model extern de date (adică punctul de vedere al utilizatorului);

model de date conceptual (care reprezintă structura logica a bazei de date,

independenta de sistemul de gestiune ales);

model de date intern (care reprezintă schema conceptuala într-un mod în care

poate fi perceputa de SGBD).

Modelele de date bazate pe obiecte sunt: modelul entitate-relaţie, modelul

semantic, modelul funcţional, modelul orientat obiect.

Exista trei tipuri importante de modele de date bazate pe înregistrare: modelul de

date relaţional, modelul de date reţea şi modelul ierarhic de date.

Modele fizice de date descriu efectiv modul în care datele sunt memorate în

calculator, la nivel fizic.

Page 41: Baze de date_Iacob

40

M2.U2.1. Test de autoevaluare a cunoştinţelor

2.1.1 Care sunt modele de date bazate pe înregistrare?

Răspunsurile se găsesc la sfârşit la pag 152

Page 42: Baze de date_Iacob

41

Unitatea de învăţare 2.2 Modelare E-R (Entity-Relaţionship)

M2.U2.2. Introducere

Modelul E-R constituie un mod de reprezentare a bazelor de date relaţionale

şi de aceea este un instrument util în proiectarea acestora. În acest capitol, vom

descrie conceptele primare care stau la baza modelului E-R, după care vom

identifica problemele care pot apărea prin utilizarea unui astfel de model. Vom

discuta de asemenea problemele generate prin utilizarea modelul E-R la

reprezentarea unor aplicaţii.

M2.U2.2. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

descrie structura bazei de date cu ajutorul unui model grafic

să aleagă cheia unei relaţii în mod optim

Durata medie de parcurgere a primei unităţi de învăţare este de 3 ore.

Concepte de bază

Conceptele primare ale modelului E-R includ : tip de entitate (mulţime-entitate), tip de

relaţie (mulţime-relaţie), atribute.

Numim entitate un obiect sau un concept ce se poate identifica în mod unic.

Noţiunea de entitate este un concept de baza în cadrul modelului E-R. Ea reprezintă 'obiecte'

concrete (cu existenta fizica) sau abstracte (cu existenta conceptuala).

Exemple

Popescu Ion, posesor al buletinului de identitate seria ABC, numărul: 444555

este o entitate deoarece identifica în mod unic o persoana în acest univers.

Ce este studentul Ion Ion?

Ce este grupa 7172?

O entitate care reprezintă un obiect ceva mai abstract poate fi, de exemplu, un cont la

banca identificabil în mod unic prin numărul sau şi numele băncii.

Numim tip de entitate sau mulţime-entitate un set de entităţi de acelaşi tip.

Exemple

Mulţimea tuturor persoanelor care sunt studenţi ai Facultăţii de Ştiinţe pot defini

mulţimea-entitate sau tipul de entitate student.

Mulţimea tuturor profesorilor Facultăţii de Ştiinţe formează ce?

Page 43: Baze de date_Iacob

42

Tipul de entitate reprezintă o mulţime de 'obiecte' ce aparţin lumii reale şi care sunt descrise

de aceleaşi proprietatea.

Orice obiect care aparţine unui tip de entitate şi care este identificabil în mod unic este numit

simplu entitate. (se mai întâlnesc denumirile: apariţia unei entităţi sau instanţa unei entităţi).

Un tip de entitate conţine mai multe entităţi. O baza de date este o colecţie de tipuri de entitat e

din care fiecare conţine un număr neprecizat de entităţi de acelaşi tip.

Tipurile de entitate nu sunt neapărat disjuncte. Aceasta înseamnă că pot exista entităţi care să

aparţină mai multor tipuri de entitate.

Exemple

Se pot defini următoarele tipuri de entitate: profesor, corespunzător tuturor

cadrelor didactice ale Facultăţii de Ştiinţe şi student, corespunzător tuturor

studenţilor aceleiaşi facultăţi. Se observa uşor că pot exista studenţi care sunt

în acelaşi timp şi cadre didactice (studenţi la master care sunt preparatori sau

asistenţi).

Arătaţi că nici tipurile de entitate personal auxiliar şi profesor nu sunt

disjuncte.

Un tip de entitate se identifică printr-un nume şi o listă de proprietatea. O bază de date

conţine în general mai multe tipuri de entităţi.

Numim atribute proprietăţile ataşate unui tip de entitate.

Exemple

Entitatea student poate fi descrisă de atributele: nume_student,

prenume_student, data_nasterii, sex, adresa, telefon, număr_matricol, grupa.

Cum aţi descrie entitatea materii?

Prin domeniul atributului înţelegem mulţimea valorilor care pot fi atribuite unui atribut

simplu.

Atributele unei entităţi conţin valorile care descriu fiecare entitate şi cu ajutorul cărora fiecare

entitate se poate identifica în mod unic. Aceste valori reprezintă cea mai mare parte a datelor

memorate într-o baza de date.

Domeniul unui atribut nu se poate defini întotdeauna foarte exact. De exemplu, atributul

nume_student trebuie să fie un şir de caractere dar poate lua ca valori doar un nume de familie

existent. Unele domenii se pot descompune în mai multe subdomenii. De exemplu

data_naşterii se poate descompune în subdomeniile: an, lună, zi.

In general putem considera că fiecare entitate este reprezentabila cu ajutorul unei mulţimi de

perechi de forma (nume_atribut, valoare_atribut), cate o pereche pentru fiecare atribut ataşat

tipului de entitate corespunzător.

Page 44: Baze de date_Iacob

43

Exemple

O entitate a tipului de entitate student poate fi reprezentata de mulţimea:

{(nume_student, Popescu), (prenume_student, Ion), (data_nasterii, 15.11.1981),

(sex, masculin), (adresa, B-dul Garii, 12, Brasov, cod 2200, judetul Brasov),

(telefon, 068/444555), (număr_matricol, 31455), (grupa, 7211)}

Reprezentaţi o entitate a tipului de entitate materii.

Atributele se pot clasifica în simple sau compuse; cu o singură valoare sau cu mai multe

valori; respectiv derivate.

Numim atribut simplu orice atribut care are doar o singură componentă şi o existenţă

independentă.

Aceste atribute nu se pot diviza în mai multe atribute distincte. Ele se mai numesc şi atribute

atomice.

Exemple

Atributul sex corespunzător tipului de entitate student.

Arătaţi alte atribute simple ale tipului de entitate materii.

Numim atribut compus orice atribut care are mai multe componente, fiecare cu o existenţă

independentă.

Aceste atribute se pot diviza în general în mai multe atribute simple.

Exemple

Atributul adresă se poate descompune în atributele: strada, număr, oraş,

cod_poştal şi judeţ.

Arătaţi alte atribute compuse.

Decizia ca un atribut compus să se descompună în mai multe atribute simple este dependentă

de modul în care se va utiliza acel atribut: pe componente, sau ca un întreg.

Numim atribut cu o singură valoare orice atribut care poate lua cate o singură valoare

pentru fiecare entitate.

Majoritatea atributelor sunt atribute cu o singură valoare.

Numim atribut cu mai multe valori orice atribut care poate lua mai multe valori pentru

fiecare entitate.

Pentru atributele cu mai multe valori trebuie precizate numărul minim şi numărul maxim de

valori pe care le poate lua atributul respectiv.

Exemple

Atributul telefon poate fi un atribut cu mai multe valori. În acest caz se poate

limita de exemplu numărul numerelor de telefon la care poate fi găsit studentul la

Page 45: Baze de date_Iacob

44

minim 0 şi la maxim 3. Deci se pot stabili numărul minim şi numărul maxim de

valori pe care le poate lua atributul.

Arătaţi alte atribute cu mai multe valori.

Numim atribut derivat orice atribut a cărui valoare se poate calcula din unul sau mai

multe alte atribute. Aceste atribute nu trebuie neapărat să descrie entitatea căreia ii corespunde

atributul derivat.

Exemple

Valoarea pentru atributul vârsta este derivată din valoarea atributului

data_naşterii şi din data curentă.

Arătaţi alte atribute derivate.

Valoarea atributului numărul_total_de_entităţi se poate calcula numărând entităţile

înregistrate.

Să ne reamintim...

entitate care reprezintă un obiect ceva mai abstract poate fi, de

exemplu, un cont la banca identificabil în mod unic prin numărul sau şi

numele băncii.

Numim tip de entitate sau mulţime-entitate un set de entităţi de

acelaşi tip.

Prin domeniul atributului înţelegem mulţimea valorilor care pot fi

atribuite unui atribut simplu.

Numim atribut simplu orice atribut care are doar o singură componentă

şi o existenţă independentă

Numim atribut compus orice atribut care are mai multe componente,

fiecare cu o existenţă independentă.

Numim atribut cu mai multe valori orice atribut care poate lua mai

multe valori pentru fiecare entitate.

Numim atribut derivat orice atribut a cărui valoare se poate calcula din

unul sau mai multe alte atribute.

Reprezentare grafică - diagrame E-R

Întreaga structura logica a unei baze de date poate fi reprezentata grafic cu ajutorul

diagramelor E-R. O astfel de diagrama conţine elemente grafice cum ar fi:

dreptunghiuri, care reprezintă tipuri de entitate;

elipse, care reprezintă atribute;

linii, care au rolul de a evidenţia legăturile între elementele diagramei.

Dreptunghiurile şi elipsele sunt etichetate cu numele 'obiectului' reprezentat. Acestea nu sunt

singurele elemente grafice utilizate într-o diagrama E-R. Pe măsură ce vom defini noi

concepte vom reveni cu precizări legate de modul de a le reprezenta.

Un atribut se reprezintă printr-o elipsă, legată de entitatea căreia îi este asociat cu o linie şi

etichetată cu numele atributului. Elipsa este trasata cu linie punctată, dacă atributul este un

atribut derivat şi respectiv cu linie dublă, daca atributul poate lua mai multe valori.

Page 46: Baze de date_Iacob

45

Dacă un atribut este compus, atunci componentele atributului se reprezintă prin elipse legate

cu cate o linie de atributul compus.

Exemple

Reprezentarea cu diagrama E-R a entităţii locatari

În exemplu entitatea locatari are următoarele atribute: număr_matricol, nume şi

adresa. Dintre aceste atribute, atributul adresa este atribut compus, care se

descompune în număr_bloc, scara, etaj şi apartament. Explicaţia sublinierii

atributului număr_matricol se va da în secţiunea care se ocupa de chei, tot în

această unitate de învăţare.

Desenaţi structura corespunzătoare tipului de entitate student.

Numim tip de relaţie orice asociere între tipuri de entităţi.

Numim relaţie orice asociere între entităţi, când asocierea include cate o entitate pentru toate

tipurile de entitate participante.

Fie E1, E2, ..., En tipuri de entitate. Formal, un tip de relaţie este o submulţime a următoarei

mulţimi:

{( e1, e2, ..., en) | unde e1E1, e2E2, ..., enEn }

ceea ce înseamnă că ( e1, e2, ..., en) reprezintă formal o relaţie.

Exemple

Într-o aplicaţie care ar servi unor evidente în cadrul asociaţiilor de locatari putem

considera tipul de entitate locatari descris de atributele: nume, adresa şi

număr_matricol şi tipul de entitate scări descris de atributele număr_de_bloc şi

scara. Între tipul de entitate scări şi tipul de entitate locatari se poate stabili un

tip de relaţie numit este_locuita_de. Acest tip de relaţie va conţine relaţii de tipul

('Scara A', 'Popescu Ion') care va fi interpretata: "Scara A este locuita de Popescu

Ion".

Descrieţi relaţiile care apar între student şi catalog.

locatari

num

e

numãr

matric

ol

adres

a

adres

a

adres

a

adres

a

adres

a

adres

a

numãr

bloc

scara

etaj

apartam

ent

Page 47: Baze de date_Iacob

46

Numim gradul relaţiei numărul entităţilor participante în relaţie. Aşadar relaţia reprezentată

mai sus are gradul n. Entităţile implicate într-o relaţie se numesc participanţi. Dacă într-o

relaţie sunt doi participanţi, atunci relaţia se numeşte binară.

Tipurile de relaţii se reprezintă în diagramele E-R cu ajutorul romburilor care sunt etichetate

cu numele tipului de relaţie.

Exemple

Reprezentarea cu diagrama E-R a relaţiei este_locuita_de

Reprezentaţi relaţia dintre student şi catalog.

Funcţia pe care o joaca o entitate într-o relaţie se numeşte rolul entităţii. în general nu este

necesar să se specifice rolul entităţilor într-o relaţie, deoarece acesta este în general implicit.

Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în roluri diferite. în

acest caz este necesar să se precizeze rolurile entităţilor implicate. În cazul relaţiilor recursive,

în diagrama E-R corespunzătoare, cele două arce de la entitate la relaţie şi înapoi, primesc

diferite etichete, care sunt importante în înţelegerea corectă a relaţiei.

Exemple

Dacă am considera entităţile lucrători şi manageri care se refera la personalul

aceleiaşi întreprinderi, am face constatarea că sunt descrise de aceleaşi atribute

deci aparţin aceluiaşi tip de entitate şi anume angajaţi. Relaţia binara

lucrează_pentru, stabilita între lucrători şi manageri este o relaţie recursiva.

Rolurile jucate de fiecare entitate se pot stabili recurgându-se la perechi ordonate

(muncitor, manager).

Exemple

1 M

locatari scări

număr

matric

ol

nume

adre

sa

numă

r de

bloc

scar

a

este

locuită

angajaţi lucrează

pentru

lucrator

manager

Page 48: Baze de date_Iacob

47

Reprezentarea cu diagrama E-R a relaţiei recursive lucrează_pentru

Astfel relaţia ('Popescu Ion', 'Ionescu Gheorghe') se interpretează "Popescu Ion

lucrează pentru (este subordonatul lui) Ionescu Gheorghe".

Daţi un exemplu de relaţie recursivă legată de entitatea profesor.

Unui tip de relaţie i se pot asocia atribute descriptive în acelaşi mod în care se pot asocia

atribute unui tip de entitate.

Exemple

Tipului de relaţie este_locuita_de, care implica tipurile de entitate scări şi

locatari, i se poate asocia atributul data care să retina data la care locatarul L s-a

mutat pe scara S. După cum se observa, acest atribut descrie exclusiv tipul de

relaţie şi el nu mai are sens în afara ei.

Să ne reamintim...

Numim relaţie orice asociere între entităţi, când asocierea include cate o

entitate pentru toate tipurile de entitate participante.

Numim gradul relaţiei numărul entităţilor participante în relaţie. Entităţile

implicate într-o relaţie se numesc participanţi. Dacă într-o relaţie sunt doi

participanţi, atunci relaţia se numeşte binară.

Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în

roluri diferite. în acest caz este necesar să se precizeze rolurile entităţilor

implicate.

Restricţii structurale

Este posibil să se stabilească diverse restricţii la care conţinutul unei baze de date

trebuie să se conformeze. Vom trata în continuare restricţiile care se pot impune entităţilor

participante într-o relaţie. Aceste restricţii trebuie să reflecte caracteristicile relaţiilor aşa cum

se percep în 'lumea reala'. Doua tipuri importante de restricţii sunt de menţionat aici: restricţii

de cardinalitate şi restricţii de participare.

a) Restricţii de cardinalitate Numim cardinalitate (polaritate) numărul relaţiilor posibile

pentru o entitate participantă. Altfel spus, cardinalitatea exprima numărul entităţilor la care o

alta entitate poate fi asociata prin intermediul unei relaţii.

Observaţie: Am utilizat în definiţia de mai sus referiri la entităţi şi la relaţii pentru a fi mai

expliciţi. Restricţiile structurale se refera insa în mod evident la tipurile de relaţie şi la tipurile

de entitate asociate. Această observaţie rămâne valabila şi în consideraţiile ce urmează.

Majoritatea tipurilor de relaţie au gradul doi. Cardinalitatea în acest caz poate fi de tipurile:

unu-la-unu (1:1), unu-la-mai-multe (1:M), sau mai-multe-la-mai-multe (M:N).

Relaţiile unu-la-unu:

Page 49: Baze de date_Iacob

48

În relaţiile unu-la-unu, o entitate, apartinand unui tip de entitate, este legată de cel mult

o entitate din celalalt tip de entitate implicat în relaţia respectiva. Implicarea fiecarei entitati

într-o relaţie data este numita "participarea entitatii".

In diagrama E-R se eticheteaza arcul dintre relaţie şi fiecare tip de entitate cu cardinalul

relaţiei; în cazul relaţiilor unu-la-unu fiecare din cele doua arce se eticheteaza cu 1.

Relaţiile unu-la-mai-multe:

In relaţia de tip unu-la-mai-multe orice entitate, aparţinând primului tip de entitate, este legată

de 0, 1, sau mai multe entităţi apartinand celui de-al doilea tip de entitate participant la relaţie.

Exemple

Exemplificăm acest tip de relaţie prin relaţia este_locuita_de dintre tipurile de

entităţi scari, respectiv locatari. în reprezentarea grafică a acestui tip de

relaţie, arcul dinspre tipul de entitate scări se etichetează cu 1 iar arcul dinspre

tipul de entitate locatari se etichetează cu M

Modelul semantic din figură reprezintă relaţia unu-la-mai-multe

este_locuita_de.

Din exemplul de mai sus se observă uşor că dacă relaţia directă este de unu-la-mai-

multe, atunci relaţia inversă este de unu-la-unu.

Relaţiile mai-multe-la-mai-multe:

Acest tip de relaţie se deosebeşte de relaţia unu-la-mai-multe prin faptul că relaţia

inversă nu este de unu-la-unu, ci de unu-la-mai-multe. Deci, dacă şi relaţia directă şi relaţia

inversă sunt de tipul unu-la-mai-multe, atunci relaţia directa este de tipul mai-multe-la-mai-

multe şi se notează cu (N:M).

Daţi un exemplu de n la m între student şi materii.

Exemple

locatari scări

număr

matric

ol

nume

adre

sa

numă

r de

bloc

scar

a

este

locuită

1 M

Sc.

A

Sc.B

Sc.C

scări este locuita

de R1

R2

R3

Fam

.1

Fam

.2

Fam

.3

locatari nr_blo

c

scara

nr_blo

c scara

nr_blo

c scara

atribu

te nr_ma

t numel

e

nr_ma

t numel

e

nr_ma

t numel

atribu

te

Page 50: Baze de date_Iacob

49

Reprezentarea cu reţele semantice a relaţiei 1:M este_locuita_de

Reprezentaţi cu reţea semantică relaţia dintre student şi catalog.

Să ne reamintim...

Restricţii de cardinalitate

Numim cardinalitate (polaritate) numărul relaţiilor posibile pentru o

entitate participantă.

Majoritatea tipurilor de relaţie au gradul doi. Cardinalitatea în acest caz

poate fi de tipurile: unu-la-unu (1:1), unu-la-mai-multe (1:M), sau mai-

multe-la-mai-multe (M:N).

În relaţiile unu-la-unu, o entitate, apartinand unui tip de entitate, este

legată de cel mult o entitate din celalalt tip de entitate implicat în relaţia

respectiva

In relaţia de tip unu-la-mai-multe orice entitate, aparţinând primului tip de

entitate, este legată de 0, 1, sau mai multe entităţi apartinand celui de -al

doilea tip de entitate participant la relaţie.

Relaţiile mai-multe-la-mai-multe se deosebeşte de relaţia unu-la-mai-

multe prin faptul că relaţia inversă nu este de unu-la-unu, ci de unu-la-

mai-multe. Deci, dacă şi relaţia directă şi relaţia inversă sunt de tipul unu -

la-mai-multe, atunci relaţia directa este de tipul mai-multe-la-mai-multe şi

se notează cu (N:M).

b) Restricţii de participare

Numim restricţii de participare acele restricţii prin care se determină dacă existenţa

unui tip de entitate depinde de faptul că este legat sau nu de un alt tip de entitate prin

intermediul relaţiei în discuţie.

Participarea unei entităţi poate fi totală sau parţială. Participarea este totala daca

existenta entităţii respective necesita existenta unei entităţi asociate în relaţia dată. În caz

contrar participarea se numeşte parţială. Termenii participare totala şi participare parţială pot

fi înlocuiţi cu participare obligatorie respectiv participare opţionala. În diagrama E-R aceste

tipuri de relaţii se reprezintă prin arc cu linie dublă pentru participarea totală, respectiv cu

linie simplă pentru participarea parţială. Pentru participarea parţială, există un mod de notaţie

prin care se etichetează arcele relaţiei cu perechea de numere ce reprezintă minimul, respectiv

maximul entităţilor participante la relaţie.

Exemple

Daca se considera filialele unei firme oarecare ca entităţi în tipul de entitate

filiala şi daca se considera tipul de entitate personal (unde entităţile reprezintă

personalul firmei respective) se poate defini tipul de relaţie are_alocat stabilit

între o filiala concreta şi personalul firmei. În acest caz, daca se considera că

fiecare filiala are alocat personal al firmei atunci participarea tipului de entitate

filiala în relaţia are_alocat este totala. Daca insa admitem că unii membri ai

personalului (de exemplu vânzătorii) nu lucrează în birourile nici unei filiale,

atunci participarea tipului de entitate personal în relaţia are_alocat este parţiala.

Page 51: Baze de date_Iacob

50

Discutaţi participarea în relaţia student cu materii.

Să ne reamintim...

Participarea unei entităţi poate fi totală sau parţială. Participarea este totala daca

existenta entităţii respective necesita existenta unei entităţi asociate în relaţia

dată. În caz contrar participarea se numeşte parţială.

c) Dependenţele de existenţă

Numim tip slab de entitate un tip de entitate, a cărui existenţă este dependentă de

existenta unui alt tip de entitate.

Numim tip tare de entitate un tip de entitate, a cărui existenţă nu depinde de existenta nici

unui alt tip de entitate.

Entităţile slabe se mai numesc existenţial dependente sau subordonate iar entităţile tari se

mai numesc părinte sau dominante.

În diagrama E-R tipurile de entitate tari se reprezintă cu un dreptunghi trasat cu linie simpla.

Pentru tipurile de entitate slabe conturul dreptunghiului este trasat cu linie dubla. De

asemenea aceasta notaţie se extinde şi la relaţii. Astfel: o relaţie care leagă doua tipuri de

entitate tari este reprezentata cu un romb trasat cu linie simpla iar relaţia care leagă un tip de

entitate tare de un tip de entitate slab este reprezentata cu un romb trasat cu linie dubla.

Chei

Conceptual este evident că entităţile şi relaţiile individuale care participa la modelarea

unei baze de date sunt distincte între ele. Diferenţa între entităţi sau diferenţa între relaţii se

exprima cu ajutorul atributelor care le descriu.

Numim supercheie asociata unui tip de entitate, orice submulţime a mulţimii de

atribute ce descriu tipul de entitate, submulţime care poate duce la identificarea în mod unic a

oricărei entităţi în cadrul tipului de entitate luat în considerare.

Este evident ca, daca o submulţime de atribute formează o supercheie, atunci orice

mulţime de atribute care include supercheia este tot o supercheie.

Numim cheie candidat orice supercheie care conţine un număr minim de atribute.

Pentru o cheie candidat nici o submulţime proprie nu mai este supercheie. Putem spune că o

cheie candidat este caracterizata de următoarele proprietatea:

- unicitatea, deoarece valoarea cheii este unica pentru fiecare entitate în parte;

Daţi exemple de chei în entitatea profesor.

Să ne reamintim...

Participarea unei entităţi poate fi totală sau parţială. Participarea este totala

daca existenta entităţii respective necesita existenta unei entităţi asociate în

relaţia dată. În caz contrar participarea se numeşte parţială.

Numim supercheie asociata unui tip de entitate, orice submulţime a

mulţimii de atribute ce descriu tipul de entitate, submulţime care poate

duce la identificarea în mod unic a oricărei entităţi în cadrul tipului de

Page 52: Baze de date_Iacob

51

- ireductibilitatea, deoarece nici o submulţime proprie de atribute ale cheii nu are

proprietatea de unicitate.

Observaţie: Faptul că valorile unei chei candidat sunt unice pentru fiecare entitate nu poate fi

determinat decât cu ajutorul informaţiilor semantice referitoare la valorile atributelor ce

formează cheia. Trebuie să se cunoască semnificaţiile din lumea reala a atributelor ce

formează cheia pentru a se stabili daca acestea vor avea valori unice. Doar faptul ca, pentru o

mulţime oarecare de entităţi concrete, valorile diferă între ele nu este de ajuns.

Pentru un tip de entitate este posibil să se poată determina una sau mai multe chei

candidat. Dintre acestea, cheia primară este cheia aleasa ca mijloc principal de identificare a

entităţilor în cadrul tipului de entitate respectiv. Cheia primară este în general cea mai scurtă

dintre cheile candidat. In diagrama E-R atributele care intră în componenţa cheii primare, se

evidenţiază prin sublinierea numelui atributului.

Numim cheie compusă orice cheie candidat care conţine cel puţin două atribute.

Probleme se ivesc atunci când trebuie să identificam în mod unic entităţile unui tip de entitate

slab. Să observam că un tip de entitate tare are întotdeauna o cheie primara, deci are

întotdeauna cel puţin o cheie candidat. Un tip de entitate slab nu are cheie primara.

Numim discriminatorul unui tip de entitate slab, un set de atribute care permite

realizarea unei distincţii între entităţile care depind de o anume entitate tare. Aşadar, cheia

primara a unui tip de entitate slab este formata din cheia primara a tipului de entitate tare

de care este dependenta existenţial, la care se adaugă mulţimea atributelor care compun

discriminatorul tipului de entitate slab.

entitate luat în considerare.

Numim cheie candidat orice supercheie care conţine un număr minim

de atribute. Pentru o cheie candidat nici o submulţime proprie nu mai

este supercheie.

Pentru un tip de entitate este posibil să se poată determina una sau mai

multe chei candidat.

Dintre acestea, cheia primară este cheia aleasa ca mijloc principal de

identificare a entităţilor în cadrul tipului de entitate respectiv.

Numim cheie compusă orice cheie candidat care conţine cel puţin două

atribute.

Numim discriminatorul unui tip de entitate slab, un set de atribute care

permite realizarea unei distincţii între entităţile care depind de o anume

entitate tare. Aşadar, cheia primara a unui tip de entitate slab este

formata din cheia primara a tipului de entitate tare de care este

dependenta existenţial, la care se adaugă mulţimea atributelor care

compun discriminatorul tipului de entitate slab.

Si relaţiile au chei. Cu ajutorul cheilor se pot identifica în mod unic

relaţiile individuale.

Cheia primara a tipului de relaţie este formata din reuniunea

mulţimilor de atribute care formează cheile primare ale tipurilor de

entitate participante.

Page 53: Baze de date_Iacob

52

Si relaţiile au chei. Cu ajutorul cheilor se pot identifica în mod unic relaţiile

individuale. Cheia primara a tipului de relaţie este formata din reuniunea mulţimilor de

atribute care formează cheile primare ale tipurilor de entitate participante.

M2.U2.2. Rezumat

Numim relaţie orice asociere între entităţi, când asocierea include cate o entitate

pentru toate tipurile de entitate participante.

Numim gradul relaţiei numărul entităţilor participante în relaţie. Entităţile

implicate într-o relaţie se numesc participanţi. Dacă într-o relaţie sunt doi

participanţi, atunci relaţia se numeşte binară.

Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în roluri

diferite. în acest caz este necesar să se precizeze rolurile entităţilor impli cate.

Numim cardinalitate (polaritate) numărul relaţiilor posibile pentru o entitate

participantă.

Majoritatea tipurilor de relaţie au gradul doi. Cardinalitatea în acest caz poate fi

de tipurile: unu-la-unu (1:1), unu-la-mai-multe (1:M), sau mai-multe-la-mai-

multe (M:N).

În relaţiile unu-la-unu, o entitate, apartinand unui tip de entitate, este legată de cel

mult o entitate din celalalt tip de entitate implicat în relaţia respectiva

In relaţia de tip unu-la-mai-multe orice entitate, aparţinând primului tip de

entitate, este legată de 0, 1, sau mai multe entităţi apartinand celui de-al doilea tip

de entitate participant la relaţie.

Relaţiile mai-multe-la-mai-multe se deosebeşte de relaţia unu-la-mai-multe prin

faptul că relaţia inversă nu este de unu-la-unu, ci de unu-la-mai-multe. Deci, dacă

şi relaţia directă şi relaţia inversă sunt de tipul unu-la-mai-multe, atunci relaţia

directa este de tipul mai-multe-la-mai-multe şi se notează cu (N:M).

Numim supercheie asociata unui tip de entitate, orice submulţime a mulţimii de

atribute ce descriu tipul de entitate, submulţime care poate duce la identificarea în

mod unic a oricărei entităţi în cadrul tipului de entitate luat în considerare.

Numim cheie candidat orice supercheie care conţine un număr minim de

atribute. Pentru o cheie candidat nici o submulţime proprie nu mai este

supercheie.

Pentru un tip de entitate este posibil să se poată determina una sau mai multe chei

candidat.

Dintre acestea, cheia primară este cheia aleasa ca mijloc principal de identificare

a entităţilor în cadrul tipului de entitate respectiv.

M2.U.2.2 Test de autoevaluare a cunoştinţelor

2.2.1 Găsiţi cheile candidat ale tabelei student. Stabiliţi cheia primară.

2.2.2 Daţi exemple de relaţii unu la unu, unu la mai mulţ i şi mulţi la mulţi.

2.2.3 Stabiliţi domeniul fiecărui atribut din tabela profesor.

Răspunsurile se găsesc la sfârşit la pag 152

Page 54: Baze de date_Iacob

53

Modulul 3. Limbaje de cereri.

Cuprins

Introducere

Obiectivele modului

U3.1 Algebra relaţională.

U3.2 SQL.

M3. Introducere

Una din funcţiunile importante ale SGBD+urilor este regăsirea datelor. Pentru

aceasta trebuie să facem cereri la baza de date. Modelul matematic al acestor

cereri la baza de date relaţională este algebra relaţională, iar limbajul standardizat

de cereri este SQL.

M3. Obiectivele modulului

La sfârşitul acestui modul studenţii vor fi capabili să:

Facă operaţii în algebra relaţională

Exprime cereri în algebra relaţională

Exprime cereri în SQL

exprime actualizări ale bazei de date

Page 55: Baze de date_Iacob

54

Unitatea de învăţare 3.1 Algebra relaţională.

M3.U3.1. Introducere

In cadrul bazelor de date relaţionale, datele sunt organizate sub forma unor

tablouri bidimensionale (tabele) de date, numite relaţii. Asocierile dintre relaţii se

reprezintă explicit prin atribute de legătură. Aceste atribute figurează într -una din

relaţiile implicate in asociere (de regulă, în cazul legaturilor de tip "unu la mulţi")

sau sunt plasate într-o relaţie distinctă, construită special pentru exprimarea

legaturilor între relaţii (în cazul legaturilor de tip "mulţi la mulţi"). O bază de date

relaţională (BDR) reprezintă un ansamblu de relaţii, prin care se reprezintă atât

datele cât şi legăturile dintre date.

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

relaţiilor, în scopul realizarii funcţiilor de prelucrare asupra bazei de date,

respectiv consultarea, inserarea, modificarea şi ştergerea datelor.

Restricţiile de integritate ale modelului relaţional permit definirea st ărilor

coerente ale bazei de date.

În continuare, vor fi prezentate pe larg aceste componente.

M3.U3.1. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

Facă operaţii în algebra relaţională

Exprime cereri în algebra relaţională

Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Structura relaţionala a datelor

Prezentarea structurii relaţionale a datelor impune reluarea noţiunilor de: domeniu,

relaţie, atribut şi schemă a unei relaţii.

Domeniul reprezintă un ansamblu de valori, caracterizat printr -un nume. Un domeniu

se poate defini explicit, prin enumerarea tuturor valorilor apartinând acestuia sau implicit, prin

precizarea proprietăţilor pe care le au valorile din cadrul domeniului respectiv.

Page 56: Baze de date_Iacob

55

Exemple

Sa considerăm, de exemplu domeniile D1, D2, D3, definite astfel:

D1: ("F","M")

D2 : (x / x aparţine N, x aparţine [0,100])

D3 :(s/s=şir de caractere)

În cazul lui D1 s-a recurs la o definire explicită, în timp ce pentru D2 şi D3 s-a

utilizat definirea implicită.

Pentru un ansamblu de domenii D1, D2, ..., Dn produsul catezian al acestora

reprezinta ansamblul tuplurilor <v1, v2, . .., vn>, unde: v1 este o valoare apartinând

domeniului D1, v2 este o valoare din D2 s.a.m.d.

Exemple

De exemplu, tuplurile: <"Maria", "F", 50>, <"Vasile", "M",15>,

<"Vasile","M",20>, <"Vasile", "F",100> aparţin produsului cartezian: D3 x D1 x

D2

Să presupunem că se acordă o anumită semnificaţie valorilor domeniilor D1, D2, D3,

definite anterior.

Sa considerăm, de exemplu ca D1 cuprinde valorile referitoare la sexul unei persoane,

D2 conţine valori care exprimă vârsta unei persoane şi D3 cuprinde numele unor persoane.

Numai unele dintre tuplurile produsului cartezian: D3 x D1 x D2 pot avea o

semnificaţie şi anume cele care conţin numele, sexul şi vârsta aceleiaşi persoane.

Dintre cele 202 tupluri care au valoarea "Vasile" pe prima pozitie, numai unul

poate avea o semnificaţie, dacă presupunem că există o singură persoană cu

acest nume.

Se desprinde de aici necesitatea definirii unei submulţimi de tupluri, din cadrul

produsului cartezian al domeniilor, submulţime care să cuprindă numai tuplurile cu

semnificaţie.

Relaţia reprezintă un subansamblu al produsului cartezian al mai multor domenii,

subansamblu caracterizat printr-un nume şi care conţine tupluri cu semnificatie. Considerând

de exemplu că nu se cunosc decât două persoane definim realţia R prin tuplurile care descriu

aceste persoane şi anume:

R : (<"Maria", "F", 30>, <"Vasile", "M", 35>)

Intr-o relaţie, tuplurile trebuie să fie distincte (nu se admit duplicări ale

tuplurilor) .

O reprezentare comodă a relaţiei este tabelul bidimensional (tabela de date în care

liniile reprezinta tuplurile, iar coloanele corespund domeniilor (fig.3.1.).

Exemple

Relaţie reprezentată sub forma unei tabele de date

Page 57: Baze de date_Iacob

56

Reprezentarea tabelară este preferată adesea altor forme de reprezentare a relaţiilor,

întrucat este uşor de înţeles şi de utilizat.

În prezentarea conceptului de reţatie se recurge uneori la analogii cu alte concepte,

extrem de bine cunoscute în domeniul prelucrării automate a datelor precum cel de fişier.

Relaţia poate avea semnificaţia unui fişier,tuplul poate fi considerat drept o înregistrare, iar

valorile din cadrul tuplului pot fi interpretate drept valori ale câmpurilor de înre gistrare.

În cadrul modelului relaţional nu intereseaza decat relaţiile finite, chiar dacă

în construirea relaţiilor se admit domenii infinite. Numărul tuplurilor dintr -o

relaţie reprezinta cardinalul relaţiei, în timp ce numărul valorilor dintr -un tuplu defineste

gradul relaţiei.

In timp ce tuplurile dintr-o relaţie trebuie să fie unice un domeniu poate apare de mai

multe ori în produsul cartezian pe baza căruia este definită relaţia.

Exemple

Să considerăm, de exemplu că pentru o persoana dispunem de urmatoarele date:

nume,sex, vârsta şi numele soţului/soţiei.

O posibilitate de organizare a acestor date o reprezintă relaţia din figură

R: D3 D1 D2

“Maria” “F” 30

“Vasile” “M” 35

Relatia PERS reprezintă un subansamblu al produsului cartezian:

D3 x D1 x D2 x D3.

Semnificaţia valorilor din cadrul unui tuplu se stabileşte

Semnificaţia valorilor din cadrul unui tuplu se stabileşte în acest caz nu numai pe baza

domeniului de care aparţin valorile, ci şi in funcţie de poziţia ocupată în cadrul tuplului.

Dependenţa fată de ordine a datelor inseamnă o reducere a flexibiltăţii organizarii datelor.

Într-o organizare eficientă, flexibilă, ordinea liniilor şi a coloanelor din cadrul tabele i de date

nu trebuie să prezinte nici o importanţă. Pentru a diferenţia coloanele care conţin valori ale

aceluiaşi domeniu şi a elimina astfel dependenţa de poziţie în cadrul tabelei se asociază

fiecarei coloane un nume distinct, ceea ce duce la aparitţa noţiunii de atribut.

Atributul reprezintă coloana unei tabele de date, caracterizată printr -un nume. Numele

coloanei (atributului) exprimă de obicei semnificaţia valorilor din cadrul coloanei respective.

Schema unei relaţii

Prin schema unei relaţii se întelege numele relaţiei, urmat de lista atributelor, pentru

fiecare atribut precizându-se domeniul asociat. Astfel, pentru o relaţie R, cu atributele A1, A2,

..., An şi domeniile: D1, D2,..., Dm, cu m <= n, schema relaţiei R poate fi reprezentată într -

una din formele

R(A1:D1, …, An:Dm)

a) b)

Operatorii modelului relaţional.

Modelul relaţional oferă două colecţii de operatori pe relaţii şi anume:

- algebra relaţionala;

- calculul relaţional.

A1:D1 … An:Dm

Page 58: Baze de date_Iacob

57

La rândul sau, calculul relaţional este de două tipuri:

- calcul relaţional orientat pe tuplu;

calcul relaţional orientat pe domeniu.

Ne limităm, în cele ce urmează, la elemente de algebră relaţională.

Algebra relaţională şi extensiile sale

E. F. Codd a introdus algebra relaţionala (AR) cu operaţii pe relaţii, fiecare operaţie

având drept operanzi una sau mai multe relaţii şi

producând ca rezultat o altă relaţie.

Unele operaţii ale AR pot fi definite prin intermediul altor operaţii. În acest sens,

putem vorbi de:

- operaţii de bază, precum: reuniunea, diferenţa, produsul cartezian etc.

- operaţii derivate, ca: intersecţia, diviziunea etc.

Codd a introdus aşa numita AR standard, constituită din 6 operaţii de bază: reuniunea,

diferenţa, produsul cartezian, proiecţia, selecţia şi joncţiunea precum şi din două operaţii

derivate: intersecţia şi diviziunea.

Ulterior, la operaţiile AR standard au fost adăugate şi alte operaţii, aşa

numitele operaţii "adiţionale" sau extensii ale AR standard, precum:comple-

mentara unei relaţii, splitarea (spargerea) unei relaţii, închiderea tranzitivă etc.

În continuare vor fi prezentate principalele operaţii ale AR, precum şi modul lor de

utilizare.

1. Reuniunea. Reprezintă o operaţie a AR definita pe doua relaţii: R1 şi R2 a mbele cu

o aceeaşi schemă, operaţie care constă din construirea unei noi relaţii R3, cu schema identică

cu R1 şi R2 şi având drept extensie tuplurile din R1 şi R2 luate impreună o singură dată.

Notaţia uzuală pentru reuniune este: R1 U R2

Reprezentarea grafică a reuniunii este prezentata in fig. 3.3.

Exemple

Reuniunea relatiilor ORASE şi MUNICIPII

Diferenţa. Reprezintă operaţie din AR definită pe doua relaţii: R1 şi R2, ambele cu o

aceeaşi schemâ, operaţia constând din construirea unei noi relaţii R3, cu schema identică cu a

operanzilor şi cu extensia formată din acele tupluri ale relaţiei R1 care nu se regăsesc şi în

relaţia R2.

Notaţia uzuală pentru operaţia de diferenţă a doua relaţii este: R1-R2

Page 59: Baze de date_Iacob

58

Exemple

Diferenţa relaţiilor ORAŞE şi MUNICIPII

3. Produs cartezian. Reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2,

operaţie care constă din construirea unei noi relaţii R3, a cărei schemă se obţine prin

concatenarea schemelor relaţiilor R1 şi R2 şi a cărei extensie cuprinde toate combinaţiile

tuplurilor din R1 cu cele din R2.

Notaţia uzuală pentru desemnarea operaţiei este: R1xR2

Exemple

Produsul cartezian al relaţiilor ORAŞE şi TARIFE

ORAŞ:D1 JUDEŢ: D1 TRANSPORT:D3 TARIF:D4

Braşov Braşov tramvai 30

Târgovişte Dâmboviţa tramvai 30

Braşov Braşov autobuz 50

Târgovişte Dâmboviţa autobuz 50

Braşov Braşov troleibuz 50

Târgovişte Dâmboviţa troleibuz 50

ORAŞ:D1 JUDEŢ:D1

Braşov Braşov

Târgovişte Dâmboviţa

ANSP:D3 TARIF:D3

tramvai 30

autobuz 50

troleibuz 50

TRANSPORT

X

TARIFE ORAŞE:

Page 60: Baze de date_Iacob

59

4. Proiecţia. Reprezintă o operaţie din AR definită asupra unei relaţii R, operaţie care constă

din construirea unei noi relaţii P, în care se regăsesc unele atribute din R, înseamnă efectuarea

unor tăieturi verticale asupra lui R, care pot avea ca efect apariţia unor tupluri duplicate ce se

cer a fi eliminate.

Prin operaţia de proiecţie se trece de la o relaţie de grad n la o relaţie de grad

p, mai mic decât cel iniţial (p < n) ceea ce explică şi numele de proiecţie atribuit operaţiei.

Notaţia uzuală pentru operaţia de proiecţie este:

ΠAi,Aj,…,Am(R)

Exemple

Proiectia relaţiei ORAŞE pe atributul "Judeţ"

5. Selecţia. Roprezintă o operaţie din AR definită asupra unei relaţii R,

operaţie care constă din construierea unei relaţii S, a cărei schemă este identică

cu cea a relaţiei R şi a cărei extensie este constituită din acele tupluri din R care satisfac o

condiţie menţionată explicit în cadrul operaţiei. Întrucât cel mai adesea, nu toate tuplurile din

R satisfac, această condiţie, selecţia înseamnă efectuarea unor tăieturi orizontale asupra

relaţiei R, adică eliminarea de tupluri. Condiţia precizată în cadrul operaţiei de selecţie este în

general de forma:

unde: "operator de comparaţie" poate fi: <, <=, >=, > sau <>.

Notaţia folosită in mod uzual pentru desemnarea operaţiei de selecţie este următoarea:

Σ(conditie)R

Page 61: Baze de date_Iacob

60

Exemple

Selecţie efectuata asupra relaţiei ORAŞE

6. Joncţiunea (Joinul). Reprezintă o operaţie din AR defin ită pe două relaţii: R1 şi

R2, operaţie care constă din construirea unei noi relaţii R3, prin concatenarea unor

tupluri din R1 cu tupluri din R2. Se concateneaza acele tupluri din R1 şi R2 care satisfac o

anumita condiţie, specificată explicit în cadrul operaţiei. Extensia relaţiei R3 va contine deci

combinaţiile acelor tupluri care satisfac condiţia de concatenare.

Notaţiiile uzuale pentru desemnarea operaţiei de joncţiune sunt:

Reprezentarea grafica a operaţiei de joncţiune

In general, condiţia de concatenare menţionata in cadrul operaţiei de joncţiune este de

forma:

In funcţie de operatorul do comparaţie din cadrul condiţiei de concatenare, joinul

poate fi de mai multe tipuri. Cel mai important tip de join, în sensul celei mai frecvente

utilizări este equijoinul.

Equijoinul reprezinta joncţiunea dirijată de o condiţie de forma:

Operatia de joncţiune se poate exprima cu ajutorul operaţiilor de produs cartezian şi

selecţie, rezultatul unui join fiind acelaşi cu rezultatul unei selecţii operate asupra unui produs

cartezian, adică:

Page 62: Baze de date_Iacob

61

JOIN (R1,R2, condiţie) = RESTRICT(PRODUCT(R1,R2), condiţie)

Produsul cartezian reprezintă o operaţie laborioasă şi foarte costisitoare, ceea ce face

ca in locul produsului să fie utilizat joinul ori de câte ori acest lucru este posibil. Cu toate că

apare drept o operaţie derivată, joinul este prezentat de obicei drept o operaţie de bază din

AR, dată fiind importanţa sa in cadrul sistemelor relaţionale, în special la construirea relaţiilor

virtuale.

In cadrul fig.3.9. este ilustrată operaţia de equijoin.

Au fost definite numeroase variante ale operaţiei de joncţiune, variante care dife ră nu

numai în funcţie de tipul condiţiilor de concatenare, ci şi după modul de definire a schemei şi

respectiv, extensiei relaţiei rezultate prin joncţiune.

Exemple

Operaţia de equijoin a relaţiilor ORAŞE şi ESTIMARI

Joncţiunea naturală. In cazul equijoinului, schema relaţiei conţine toate atributele celor

doi operanzi (fig.3.10.) În toate tuplurile relaţiei rezultat vor exista de aceea cel puţin două

valori egale. In sensul eliminării acestei redundanţe s-a introdus joncţiunea naturală, ca

operaţie definită pe două relaţii: R1 şi R2, prin care este construită o noua relaţie R3, a cărei

schemă este obţinută prin reuniunea atributelor din relaţiile R1 şi R2 (atributele cu acelaşi

nume se iau o singură dată) şi a cărei extensie conţine tuplurile obţinute prin concatenarea

tuplurilor din R1 cu tuplurile din R2 care prezintă aceleaşi valori pentru atributele cu acelaşi

nume.

Notaţia uzuală pentru joncţiunea naturală este:

Reprezentarea grafică a acestei operaţii este prezentată în fig. 3.10.

Reprezentarea grafică a operaţiei de joncţiune

Page 63: Baze de date_Iacob

62

Exemple

7. Intersecţia. Reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2 ambele cu aceeaşi

schemă, operaţie care constă din construirea unei noi relaţii R3, cu schema identică cu a

operanzilor şi cu extensia formată din tuplurile comune lui R1 şi R2.

Notaţile uzuale folosite pentru desemnarea operaţiei de intersecţie sunt:

Reprezentarea grafică a operaţiei de intersecţie este prezantată în fig. 3.12., iar

un exemplu de intersecţie a doua relaţii figurează în fig. 3.13.

Reprezentarea grafica a operatiei de intersectie

Page 64: Baze de date_Iacob

63

Exemple

Intersecţia relatiilor ORAŞE şi MUNICIPII

Intersecţia reprezintă o operaţie derivată, care poate fi exprimată prin intermediul unor

operaţii de bază. De exemplu, operaţia de intersecţie se poate exprima prin intermediul

operaţiei de diferenţă, cu ajutorul următoarelor echivalenţe:

R1 R2=R1-(R1-R2)

R1 R2=R2-(R2-R1)

M3.U3.1. Rezumat Reuniunea reprezintă o operaţie a AR definita pe doua relaţii: R1 şi R2 ambele

cu o aceeaşi schemă, operaţie care constă din construirea unei noi relaţii R3, cu

schema identică cu R1 şi R2 şi având drept extensie tuplurile din R1 şi R2 luate

impreună o singură dată.

Diferenţa reprezintă operaţie din AR definită pe doua relaţii: R1 şi R2, ambele

cu o aceeaşi schemâ, operaţia constând din construirea unei noi relaţii R3, cu

schema identică cu a operanzilor şi cu extensia formată din acele tupluri ale

relaţiei R1 care nu se regăsesc şi în relaţia R2.

Produs cartezian reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2,

operaţie care constă din construirea unei noi relaţii R3, a cărei schemă se obţine

prin concatenarea schemelor relaţiilor R1 şi R2 şi a cărei extensie cuprinde toate

combinaţiile tuplurilor din R1 cu cele din R2.

Proiecţia reprezintă o operaţie din AR definită asupra unei relaţii R, operaţie

care constă din construirea unei noi relaţii P, în care se regăsesc unele atribute

din R, înseamnă efectuarea unor tăieturi verticale asupra lui R, care pot avea ca

efect apariţia unor tupluri duplicate ce se cer a fi eliminate.

Prin operaţia de proiecţie se trece de la o relaţie de grad n la o relaţie de grad

p, mai mic decât cel iniţial (p < n) ceea ce explică şi numele de proiecţie atribuit

operaţiei.

Selecţia reprezintă o operaţie din AR definită asupra unei relaţii R,

operaţie care constă din construierea unei relaţii S, a cărei schemă este identică

Page 65: Baze de date_Iacob

64

cu cea a relaţiei R şi a cărei extensie este constituită din acele tupluri din R care

satisfac o condiţie menţionată explicit în cadrul operaţiei. Întrucât cel mai

adesea, nu toate tuplurile din R satisfac, această condiţie, selecţia înseamnă

efectuarea unor tăieturi orizontale asupra relaţiei R, adică eliminarea de tupluri.

Joncţiunea (Joinul) reprezintă o operaţie din AR definită pe două relaţii: R1 şi

R2, operaţie care constă din construirea unei noi relaţii R3, prin

concatenarea unor tupluri din R1 cu tupluri din R2. Se concateneaza acele

tupluri din R1 şi R2 care satisfac o anumita condiţie, specificată explicit în

cadrul operaţiei. Extensia relaţiei R3 va contine deci combinaţiile acelor tupluri

care satisfac condiţia de concatenare.

Joncţiunea naturală. In cazul equijoinului, schema relaţiei conţine toate

atributele celor doi operanzi În toate tuplurile relaţiei rezultat vor exista de aceea

cel puţin două valori egale. In sensul eliminării acestei redundanţe s-a introdus

joncţiunea naturală, ca operaţie definită pe două relaţii: R1 şi R2, prin care este

construită o noua relaţie R3, a cărei schemă este obţinută prin reuniunea

atributelor din relaţiile R1 şi R2 (atributele cu acelaşi nume se iau o singură dată)

şi a cărei extensie conţine tuplurile obţinute prin concatenarea tuplurilor din R1

cu tuplurile din R2 care prezintă aceleaşi valori pentru atributele cu acelaşi

nume.

M3.U3.1. Test de autoevaluare a cunoştinţelor

3.1.1 Cosideraţi instanţe ale tabelei student, profesor,materii şi catalog.

a) Faceţi selecţie din student după grupa …

b) Faceţi proiecţie la student şi la profesor după nume. La acestea două din

urmă faceţi reuniunea.

c) Faceti joncţiunea naturală intre student şi catalog apoi între rezultat şi

materii.

d) Faceţi selecţia tabelei de mai nainte după nota < 5.

3.1.2 Să se exprime în algebra relaţională cererile:

a) Studenţii grupei 7271

b) Studenţii care sunt şi profesori

c) Studenţii corigenţi

d) Studenţii integralişti

Răspunsurile se găsesc la sfârşit la pag 152

Page 66: Baze de date_Iacob

65

Unitatea de învăţare 3.2 SQL

M3.U3.2. Introducere

SQL (Structured Query Language), a fost conceput iniţial de firma IBM,

pentru produsul dBASE, ca un limbaj standard de descriere a datelor şi de

acces la informţtiile din bazele de date. Limbaj de interogare a bazelor de

date relaţionale, SQL a fost utilizat pe scară largă şi pană în prezent au fost

dezvoltate şapte versiuni ale standardului SQL, trei dintre ele aparţinînd

Institutului National American de Standarde (ANSI), celelalte fiind

concepute de firme de prestigiu ca IBM, Microsoft şi Borland sau de cãtre

consorţii ca SAG (The SQL Access Group) şi X/Open.

Primul standard SQL a fost creat in anul 1989 de cãtre ANSI fiind cunoscut

sub numele de ANSI-SQL'89 şi a fost revizuit in octombrie 1992 sub noua

denumire: ANSI-SQL'92.

M3.U3.2. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

Exprime cereri în SQL

exprime actualizări ale bazei de date

Durata medie de parcurgere a primei unităţi de învăţare este de 4 ore.

Cereri de interogare simple

Instructiunile de regăsire reprezintă una din categoriile cele mei importante ale

limbajului de interogare SQL. Indiferent dacă sunt simple sau complexe, punctul de plecare al

interogărilor îl constituie fraza SELECT, prin care se r egăsesc şi se afişeaza informaţiile

dorite de utilizator.

Pentru definirea interogărilor de selecţie simple se utilizează următoarea sintaxă a

instrucţiunii SELECT:

SELECT [domeniu] lista_selecţie

FROM nume_tabela1,nume_tabela2…

[WHERE criteriu_de_selecţie}

ORDER BY câmpuri_criteriu [ASC/DESC]];

Domeniu:

- Determină stabilirea modalităţii de manipulare a înregistrărilor din baza de date asupra

căreia se efectuează selecţia şi poate fi:

ALL - permite includerea tuturor inregistrărilor ce indeplinesc condiţiile impuse. Este

folosit foarte rar deoarece este implicit.

DISTINCT - are ce efect eliminarea înregistrărilor care conţin duplicate în câmpurile

selectate; astfel se va afişa doar o apariţie a datei multiple ( ceea ce este în concordanţă cu

algebra relaţională).

DISTINCTROW - are în vedere înregistrările duplicate în ansamblul lor, nu numai pe cele

care au câmpuri duplicate.

Page 67: Baze de date_Iacob

66

Lista_selecţie

Cuprinde toate câmpurile care vor aparea în tabela cu rezulta tele interogării.

Atenţie! }n list[ vor ap[rea numai aatribute ale tabelelor din clauya FROM.

Clauzele SQL SELECT, FROM şi WRERE pot fi puse în corespondenţă cu operatorii din

algebra relaţională, după cum urmează:

Clauza SELECT menţionează o listă de atribute şi corespunde proiecţiei din algebra

relaţională;

Clauza FROM menţionează o listă de relaţii (tabele) şi corespunde produsului cartezian din

algebra relaţională;

Clauza WRERE descrie un predicat de selecţie şi corespunde selecţiei din algebra relaţională.

Înţelesul diferit al termenului “select” utilizat în SQL şi în algebra relaţională este un fapt

istoric nefericit. În SQL, ”select” desemnează proiecţia, iar în algebra relaţională acelaşi

termen desemnează selecţia după un predicat de selecţie.

Lista de atribuire care apare în clauza SELECT din SQL poate fi înlocuită cu simbolul *

dacă se doreşte selectarea tuturor atributelor care apar în relaţiile din clauza FROM.

Clauza ORDER BY

Utilizată atunci când se doreşte ca rezultatele interogării să fie ordonate în mod

crescător (ASC) sau descrescător (DESC). Sortarea este opţională şi se poate realiza dupa

unul sau mai multe câmpuri_criteriu (definite drept chei de sortare). Componenta BY a

clauzei nu poate să lipsească atunci când se doreşte sotrarea rezultatelor interogării SQL.

Rezultatul unei interogări SQL este întotdeauna o relaţie (o tabelă).

Pentru a putea da exemple concrete ne vom referi la baza de date: centrul de închiriere casete

video. Avem următoarele tabele:

Clienti (Cod_client , Nume, Prenume, Strada, Nr, Bloc, Scara, Apartament, Oras, Seria_BI,

Nr_BI, Data_ nasterii, Telefon)

Casete (Cod_caseta,Pret, Disponibila)

Filme ( Cod_film, Titlu, An_aparitie, Tara. Gen)

Casete-Filme (Cod_casetafilm, Cod_caseta, Cod_film)

Actori (Cod_actor,Nume, Sex)

Filme_Actori (Cod_filmactor, Cod_film, Cod_actor)

Imprumuturi (Cod_imprumut, Cod_client, Data_imprumut, Stare)

Plati (Cod_plata, Cod_imprumut, Data , Suma)

Casete imprumutate (Cod_imprcaseta, Cod_imprumut, Cod_caseta, Restituita)

Exemple

Să se afişeze toate datele despre toţi clienţii.

SELECT *

FROM Clienţi

.Să se afişeze toate datele despre toţi actorii.

Exemple

Să se afişeze oraşele de reşedinţă ale tuturor clienţilor

SELECT Oraş

FROM Clienţi

Page 68: Baze de date_Iacob

67

Să se afişeze toate genurile filmelor. Ce puteţi spune despre numărul genurilor

faţă de numărul genurilor.

Ca rezultat al acestei interogări se va obţine o tabelă cu o singură coloană, care conţine

numele oraşelor de reşedinţă ale clienţilor. Se va observa că se repetă numele oraşelor,

deoarece se vor afişa oraşele pentru fiecare client în parte din tabela clienţi.

Exemple

Să se afişeze oraşele de reşedinţă ale clienţilor, dar să apară fiecare ora ş o singură

dată în tabela-rezultat.

SELECT DISTINCT Oraş

FROM Clienti

Să se afişeze toate genurile distincte ale filmelor.

Exemple

Să se afişeze datele despre filmele din baza de date în ordinea alfabetică a

titlurilor filmelor

SELECT *

FROM Filme

ORDER BY Titlu,ASC

Afişaţi, ca mai sus, dar în ordine descendentă.

Să se afişeze datele despre filmele din baza de date în ordinea alfabetică a titlurilor filmelor

SELECT *

FROM Filme

ORDER BY Titlu,ASC

A se observa că dacă ar fi lipsit menţiunea ASC, ordinea tuplelor ar fi fost

aceeaşi deoarece ordinea ascendentă este implicită.

În scrierea interogărilor de selecţie simple SQL se pot folosi şi funcţii totalizatoare,

cunoscute şi sub numele de funcţii standard sau funcţii agregat, care apar în clauza SELECT

şi se aplică atributelor din tabelele implicate în interogare. Funcţii standard sunt:

valoarea medie – AVG

valoarea minima – MIN

valoarea maxima –MAX

total (sumare) – SUM

numaratoare – COUNT

Nu este permisă utilizarea acestor funcţii în clauza WHERE deoarece ele acţionează la nivel

de atribut şi nu la nivel tuplu.

Exemple

Care este suma minimă plătită?

SELECT MIN (suma)

Page 69: Baze de date_Iacob

68

FROM plati

.Care este suma maximă plătită?

Exemple

Care este preţul mediu al casetelor?

SELECT AVG(Pret)

FROM Casete

Care este suma medie încasată.

Exemple

Care este suma totală plătită pentru împrumutul cu cod ’30’?

SELECT SUM (suma)

FROM plati

WHWRE Cod_imprumut=’30’

Care este valoarea totală a casetelor.

Exemple

Cate tulpe conţine tabela de casete?

SELECT COUNT (*)

FROM Casete

Câte tupe conţine tabela clienti.

Exemple

Cate genuri de filme sunt înregistrate pentru filmele din baza de date?

SELECT COUNT (DISTINCT Gen)

FROM Filme

Cereri de interogare complexe

Limbajul de interogare SQL permite, pe lângă definirea de interogări de selecţie simple,

crearea unor interogări cu o structura complexă, cum ar fi cele în care regăsim funcţiile

agregate, asocierile (JOIN) sau combinările (UNION).

Funcţiile de grup(agregat)

Page 70: Baze de date_Iacob

69

Funcţiile de grup agregat permit construirea unor interogări SQL complexe, prin care

utilizatorul poate să efectueze diverse calcule pentru grupuri de înregistrări care au câmpuri cu

aceeasi valoare. În cazul utilizării lor se foloseşte următoarea formă a frazei SELECT:

SELECT [domeniu] [funcţie agregată (nume_câmp) AS alias [,lista_selecţie]

FROM nume_tabela1, nume_tabela2…

GROUP BY câmp_de_grupare

[HAVING criteriu_de_grupare]

[ORDER BY câmpuri_criteriu [ASC/DESC]];

Dupa cum se observă, singurele elemente obligatorii într-o interogare SQL sunt clauzele

SELECT cu lista de atribute ce vor fi extrase şi clauza FROM cu relaţiile din care fac parte

atributele. Aşadar o interogare SQL trebuie să conţină cel puţin următoarele informaţii:

SELECT <lista de atribute>

FROM <lista de relatii>

restul clauzelor sunt opţionale.

Lista selecţie

Se va referi la una sau mai multe funcţii agregate care au ca argumente nume de câmpuri ale

bazei de date. Există restricţia ca aceste câmpuri sa fie întotdeauna de tip num eric.

AS alias

Asociază un pseudonim (nume) rezultatului utilizării funcţiei agregat

Clauza GROUP BY şi HAVING

În unele cazuri, utilizatorul doreşte anumite situatii sintetice, cum ar fi obţinerea de totaluri şi

subtotaluri. Pentru aceste operaţii, limbajul SQL permite utilizarea clauzelor GROUP BY şi

HAVING.

Aceste clauze organizează tuplele în grupuri asupra cărora se pot realiza anumite

operaţii, în special prin aplicarea funcţiilor agregat.

Clauza GROUP BY grupeaza tuplele din relaţie după atributele cu aceeaşi valoare

care sunt specificate în clauză, şi generează un tuplu pentru fiecare grup de tuple cu aceeaşi

valoare pe atribut

Atributele care apar în clauza SELECT pot fi de două feluri:

-atribute care alcătuiesc baza pentru grupare (cele care apar în clauza GROUP BY);

-atribute care nu participa la gruparea rezultatelor.

Exemple

În ce orase exista clienti ai centrului de închiriere casete video?

SELECT Oras

FROM Clienti

GROUP BY Oras

În urma executarii vor aparea orasele din tabela clientilor listate o singură dată.

Din câte ţări avem filme.

Exemple

Câţi clienţi au sediul în fiecare oras?

SELECT Oras,COUNT(*)

Page 71: Baze de date_Iacob

70

FROM Client

GROUP BY Oras

Câte filme sunt din fieare ţară.

Exemple

În care case locuiesc cel puţin 3 clienţi?

SELECT Oras,COUNT(*)

FROM Clienti

GROUP BY Oras

HAVING COUNT(*)>=3

Clauza GROUP BY se poate folosi şi cu ORDER BY şi WHERE.

Din ce ţări avem cel puţin 2 filme.

Exemple

Să se afişeze în ordine alfabetică oraşele în care există clienţi ai centrului.

SELECT Oras

FROM Clienti

GROUP BY Oras

ORDER BY Oras

Să se afişeze în ordine alfabetică ţările din care avem filme.

Exemple

Care sunt clienţii care au împrumutat casete înainte de data de 6/5/2004?

SELECT Cod_client

FROM Imprumuturi

WHERE Data_imprumut<#6/5/2002#

GROUP BY Cod_client

Care sunt împrumuturile făcute după data 01/01/2009 .

Clauza FROM are forma generală:

FROM <<nume relatie>/<nume view>[alias]…>

şi specifică relaţiile (pot fi şi nume view) din care vor fi regăsite datele. În cazul în care se

operează cu mai multe tabele, este utilă atribuirea unor prescurtări, (numite alias) ale numelor

de tabele ce vor fi utilizate în interogare.

Exemple

Să se afişeze codurile casetelor, numele clienţilor, codul împrumutului şi data

împrumutului pentru clienţii care au cel puţin un împrumut.

Page 72: Baze de date_Iacob

71

SELECTC Cod_caseta, [Nume] &””& [Prenume] AS Numele,

Cod_imprumut, B.Data_imprumut

FROM Clienti A, Imprumuturi B, [casete imprumutate] C

WHERE A.Cod_client=B.Cod_client AND B.Cod_imprumut=C. Cod_imprumut

A se observa că nu s-a mai utilizat notaţia cu alias pentru atributele Nume şi

Prenume din tabela Clienti deoarece nu este pericol de confuzie. În schimb s-a

utilizat notaţia pentru a deosebi atributul Cod_client din tabela Clienti de

atributul cu acelaşi nume din tabela Imprumuturi.

Să se afişeze actorii care joacă cel puţin într-un film.

Pentru a restrânge tuplele ce apar în tabela-rezultat, se specifică o condiţie de cautare prin

utilizarea unui predicat de selecţie în clauza WHERE.

Clauza WHERE are forma generala:

WHERE <predicat> / <expresie>;

Numai tuplele care satisfac predicatul de selecţie vor fi incluse în tabela-rezultat. Predicatul

de cautare poate fi specificat printr-o condiţie logica în care se utilizeaza urmatoarele

elemente:

Operatori:

-aritmetici:+ - / * ** ^

-relaţionali: < > <= >= <> != =

-logici:NOT AND OR

-operatori SQL:IN,EXISTS,ALL,ANY

Sub-interogări(exprimate prin interogări SQL)cu observatia ca acestea vor

fi primele evaluate şi tabela-rezultat trebuie sa corespunda operatorilor ce i se aplica în

continuare.

Operatori aritmetici

Ace;ti operatori sunt binecunoscuţi şi menţionăm aici doar faptul ca şi ^ si ** reprezint[

ridicarea la putere.

Ca operanzi, se pot utiliza atribute,constante,funcţii sau expresii algebrice. Expresiile

algebrice pot aparea în clauzele SELECT sau WHERE.

Operatori relaţionali

< mai mic

> mai mare

! negarea operatorilor <,>,=. Se obţin operatorii: != (diferit),!< (nu mai mic),!> (nu mai

mare).

<= mai mic sau egal

=> mai mare sau egal

<> diferit

Facem observaţia că valorile comparate trebuie să aparţină unor tipuri de date compatbile

(care se pot compara între ele.).

Exemple

Sa se afişeze codurile şi titlurile filmelor de gen acţiune.

SELECT Cod_film<Titlu

FROM Filme

WHERE Gen=”actiune”

Page 73: Baze de date_Iacob

72

Să se afişeze filmele din Romania.

Operatori logici

Dacă o clauza WHERE conţine mai multe condiţii formate prin utilizarea aceluiaşi tip de

operator logic, evaluarea se va face de la stânga la dreapta. Tipul de operator logic este dat de

precedenţa operatorilor. Operatorul NOT are cea mai mare prioritate, urmat de OR şi AND

care practic sunt de priorităţi egale. Pentru a schimba ordinea de evaluare a unei expresii se

utilizează parantezele rotunde ().

Exemple

Sa se afişeze codul şi titlul filmelor din SUA care au anul apariţiei mai mare

decât 2000.

SELECT Cod_film,Titlu

FROM Filme

WHERE Tara=”SUA”AND An_aparitie>2000

Să se afişeze plăţile mai mari de 100 lei făcut în anul 2009.

Exemple

Sa se afişeze codul şi titlul filmelor din SUA sau care au anul apariţiei mai mare

decât 2000.

SELECT Cod_film ,Titlu

FROM Filme

WHERE Tara=”SUA”OR An_aparitie>2000

A se observa că ultima interogare este echivalentă cu interogarea :

SELECT Cod_film ,Titlu

FROM Filme

WHERE Tara=”SUA”OR NOT An_aparitie<=2000

Operatorul IN permite simplificarea predicatului de căutare. Predicatul IN testează dacă

valoarea unui atribut specficat în lista de atribute din clauza WHERE se potriveşte uneia din

valorile listei specificate în predicatul IN (testeaza apartenenţa la o mulţime).

Exemple

Să se afişeze toate datele despre clienţii care au sediul în Râşnov sau în

Braşov.

SELECT *

FROM Clienti

WHERE Oras IN (“Rasnov”,”Brasov”)

Page 74: Baze de date_Iacob

73

Să se afişeze, în două moduri, toate datele despre clienţii care au sediul în

Râşnov sau în Braşov sau în B ucuresti.

Asocierile (interogările JOIN)

Una dintre operaţiile cele mai frecvente realizate cu mai multe tabele este joncţiunea

sau produsul cartezian. Joncţiunea aminteşte de operaţiile din algebra relaţională şi chiar e ste

posibil de realizat (urmând anumite structuri ale interogării SQL) oricare dintre tipurile de

joncţiune prezentate teoretic în cadrul algebrei relaţionale. Se pot de asemenea realiza operaţii

ca reuniunea, intersectia şi diferenţa. Sintaxa interogării SQL diferă de la un SGBD la altul

dar sub o formă directă sau printr-o construcţie sintactică specifică se pot realiza oricare dintre

operaţiile amintite.

Putem distinge mai multe categorii de joncţiuni:CROSS (încrucişată) - mai

puţin utilizată, cu rol în ilustrarea elementelor specifce proprietăţilor combinatorii ale tuturor

asocierilor; ECHIVALENTĂ (echijoncţiunea)-cea mai folosită, presupune folosirea clauzei

WHERE (pentru selecţia înregistrărilor) asociată cu o egalitate dorită; NEECHIVALENTA

(non echijoncţiune) - care, spre deosebire de precedenta, face apel în clauza WHERE la

oricare operator de comparare în afară de semnul (“=”). Acest din urmă tip de joncţiune este

în general foarte rar de utilizat.

Sintaxa generală pentru joncţiunile echivalente şi neechivalente este următoarea:

SELECT [domeniu] lista_selecţie

FROM nume_tabela1,nume_tabela 2…

WHERE criteriul_de_asociere]

[ORDER BY câmpuri_criteriu[ASC?DESC];

Deoarece în instrucţiunile SQL care descriu joncţiunea se utilizeaza câmpuri ce fac

parte din tabele diferite, este necesara întotdeauna spacificarea tabelei la care apartin. Forma

generala de descriere a unui câmp va fi urmatoarea:nume_tabela.nume_câmp. Se pot folosi şi

alias-uri.

Exemple

Sa se afişeze numele clientilor şi codurile imprumuturilor pentru

imprumuturile neterminate.

SELECT[Nume]&””&[Prenume] AS Numele,b.Cod_imprumut

FROM Clienti 1,Imprumuturi b

WHERE 1.Cod_client=b.Cod_client AND Stare=Yes

Sa se afişeze filmele şi casetele pe care se găsesc.

Exemple

Care filme au acelasi gen cu filmul “Titanic”? A se observa că această interogare

necesită realizarea produsului cartezian al tabelei cu ea însăşi.

SELECT p1.Titlu,p2.Titlu,p1.Gen.p2.Gen

FROM Filme p1,Filme p2

WHERE p1.Gen=p2.Gen AND p2.Titlu=”Titanic”

Page 75: Baze de date_Iacob

74

O altă abordare priveşte joncţiunile ca fiind: interne (INNER JOIN) şi externe

(OUTER JOIN). Primele determină o asociere a înregistrărilor din tabele, astfel încat sa

rezulte un numar total de înregistrări din fiecare tabela. Joncţiunile externe, la randul lor, sunt

de doua tipuri: de stanga (LEFT OUTER JOIN) şi de dreapta (RIGHT OUTER JOIN) fiind

destul de puţin utilizate.

În acest mod de abordare al joncţiunulor sintaxa va avea forma:

SELECT [domeniu] lista_selecţie

FROM num_tabela1

JOIN nume_tabela2

ON criteriu_de_asociere

[{INNER/LEFT OUTER/ RIGHT OUTER} JOIN nume_tabela3

ON criteriu_de_asociere]…

[WHERE criteriu_de_selecţie]

[ORDER BY câmpuri_criteriu {ASC/DESC]]:

De remarcat faptul ca SQL acceptă scrierea interogărilor externe fără specificarea

explicită a lui OUTER.

JOIN – specifică tabela care va fi asociată (nume_tabela2,nume_tabela3…) tabelei preciată în

clauza FROM ON criteriu_de_asociere – arată relaţia dintre câmpurile pe care se bazează

joncţiunea. Unul se află în tabela asociată, iar celălalt există într-o altă tabelă din lista cu

numele tabelelor. Expresia criteriul_de asociere conţine un operator de comparaţie de tip

egalitate (=) şi va returna valorile logice TRUE sau FALSE

Exemple

Sa se afişeze codul casetelor, preţul şi filmele de pe casete, pentru casetele care

sunt disponibile.

SELECT Casete.Cod_caseta,Filme.Titlu,Casete.Pret

FROM Filme INNER JOIN (Casete INNER JOIN [Casete-Filme] ON

Casete.Cod_caseta=[Casete-Filme].Cod_caseta)ON Filme.Cod_film=[Casete-

Fiml].Cod_film

WHERE (((Casete.disponibile)=Yes));

Sa se afişeze filmele şi casetele pe care se găsesc. Procedaţi ca mai sus.

Combinările (interogările UNION)

Clauza UNION permite realizarea reuniunii de tabele. În cazul când dorim să reunim

două sau mai multe tabele, este obligatoriu ca acestea să fie daschise de scheme de relatie

identică (acelaşi număr de atribute şi corespunzator – de la stanga la dreapta – atributele din

tabele au aceleasi nume şi aceeaşi descriere). Aceste condiţii sunt impuse tabelelor implicate

în operaţiile intersecţie şi minus (diferenţă). Operaţiile reuniune, intersecţie şi diferenţă de

tabele acţionează analog cu aceleaşi operaţii aplicate în mulţimi.

Forma generală a reuniunii de tabele este:

Page 76: Baze de date_Iacob

75

SELECT A1,…,Am

FROM

[WHERE…]

UNION

SELECT A1,…,Am

FROM…

[WHERE…]

Exemple

Să se afişeze numele clienţilor care sunt fie din Râşnov fie din Braşov şi adresa

lor.

SELECT [Nume]&””&[Prenume]AS Nume,Clienti.Strada,Clienti.Nr,

Clienti.Bloc,Clienti.Scara,Clienti.Apartament,Clienti.Oras,Clienti.Telefon

FROM Clienti

WHERE Oras=”Rasnov”

UNION (SELECT [Nume] &””&[Prenume] AS Numele, Clienti.

Strada,Clienti.Apartament, Clienti.Oras,Clienti.Telefon

FROM Clienti

WHERE Oras=”Brasov”);

Cereri de interogare imbricate (subinterogări)

Unul din motivele pentru care SQL este considerat un limbaj puternic de interogare

este acela că oferă posibilitatea construirii interogărilor complexe, formate din mai multe

subinterogări simple.

Aceste interogări complexe sunt construite prin includerea în clauza WHERE a încă

unei clauze SELECT. Forma generală a unei astfel de construcţii este:

SELECT <lista atributelor>

FROM <lista relatii1>

WHERE <subinterogare>

Se observă că această construcţie a fost deja utilizată în exemplul de mai sus care

ilustrează o clauză UNiON.

În construcţia de mai sus clauza SELECT interioară generează valorile pentru condiţia de

căutare a clauzei SELECT exterioare care o conţine. Clauza SELECT exterioară generează o

relaţie pa baza valorilor generate de către clauza interioară. Modul de construire a interogării

exterioare depinde de numărul valorilor returnate de către interogarea interioară. În acest sens,

putem distinge:

subinterogări care returnează o singură valoare;

subinterogări care returnează mai multe valori.

Din punctul de vedere al ordinii de evaluare al interogărilor putem distinge:

Subinterogări simple

Interogarea interioara este evaluata prima, independent de interogarea exterioara.

Rezultatul evaluarii interogării interioare este utilizat de catre nterogarea

exterioara.

Subinterogări corelate

Valorile returnate de catre interogarea interioară depind de valorile returnate de catre

interogarea exterioară. Interogarea interioară este evaluată reletat pentru fiecare tuplu cercetat

de interogarea exterioara.

Page 77: Baze de date_Iacob

76

Subinterogări simple care returneaza o singura valoare

Aceste interogări au urmatoarea sintaxă:

SELECT <lista atribute>

FROM <lista relatii>

WHERE <atribut> 0 (<subinterogare>)

unde 0 este un operator relaţional: =,< > >= <= !=

Exemple

Sa se afişeze numarul împrumuturilor neîncheiate pentru clienta Ciurar Cristina.

SELECT Count(Cod_imprumut) AS [Nr de imprumuturi]

FROM Imprumuturi

WHERE (((Imprumuturi.Cod_client)=SELECT Clienti.Cod_client

FROM Clienti

WHERE [Nume] & “ “ &

[Prenume]=’Ciurar Cristina’)));

Sa se afişeze casetelew care au filme din USA.

Procesul de evaluare a acestei interogări se desfasoară astfel:

Se evalueaza în primul rînd interogarea interioară. Condiţia de evaluare a interogării

interioare este [Nume] & “ ” & [Prenume]=’Ciurar Cristina’.

Valoarea obţinută pentru atributul Cod_client este stocata într-o tebelă temporară.

Rezultatul evaluării interogării interioare devine condiţie de căutare pentru interogarea

exterioară, care ar putea fi exprimată în această fază ca:

SELECT Count(Cod_imprumut) AS [Nr de imprumuturi]

FROM Imprumuturi

WHERE (Imprumuturi.Cod_client)=6

În urma executării interogării exterioare este creată o relaţie finală, ce va contine

tuplele ale căror Cod_client este acelaşi cu valoarea stocată în tabela temporară.

Interogarea interioară poate conţine în clauza WHERE şi condiţii complexe, formate

prin utilizarea operatorilor logici (NOT,AND, OR) şi a funcţiilor agregat (AVG,MAX,…).

Exemple

Sa se afişeze codul casetelor, pretul şi titlurile filmelor, pentru casetele care au un

pret maxim.

SELECT Casete.Cod_caseta,Casete.Pret,Filme.Titlu

FROM Filme INNER JOIN (Casete INNER JOIN[Casete-Filme] ON

Casete.Cod_caseta=[Casete-Filme].Cod_caseta) ON

Filme.Cod_film=[Casete-ilme].Cod_film

WHERE Pret=(SELECT MAX(Pret) FROM Casete);

Să se afişeze filmele din casetele, cu preţ minim, împrumutate şi nerestiruite.

Suinterogări simple care returnează mai multe valori.

Principiul de construire a acestui tip de interogare imbricate utilizează în clauza

WHERE condiţii, care evaluate, generează o mulţime de valori. În această categorie intră

operatorii (NOT) IN, (NOT) ANY,(NOT) AND,(NOT) EXISTS.

Page 78: Baze de date_Iacob

77

Exemple

Care sunt clienţii care mai au de restituit casete.

SELECT [Nume]&””&[Prenume]AS Numele

FROM Clienti

WHERE Cod_client IN

(SELECT Cod_client

FROM Imprumuturi INNER JOIN [casete imprumutate]

ON Imprumuturi.Cod_imprumut =[ casete imprumutate] cod_imprumut

WHERE restituit=NO);

Care sunt actorii care joacă în casetele împrumutate.

Exemple

Care clienţi nu mai au nimic de restituit.

SELECT [Nume]&””&[Prenume]AS Numele

FROM Clienti

WHERE Cod_client NOT IN

(SELECT Cod_client

FROM Imprumuturi INNER JOIN [casete imprumutate]

ON Imprumuturi.Cod_imprumut =[ casete imprumutate] cod_imprumut

WHERE restituit=NO);

A se observa ce cele două interogări diferă doar prin operatorul logic NOT. De

asemenea se poate remarca faptul că prima interogare aminteşte de apartenenţa din teoria

mulţimilor iar a doua interogare corespunde operaţiei minus (diferenţa). Dacă versiunea SQL

nu are un cuvânt rezervat pentru operaţia diferenţa inter tabele, se poate construi aceasta

operaţie cu ajutorul predicatului NOT IN ca în exemplul de mai sus.

Subinterogări corelate

În exemplele de până acum, interogarea interioară era evaluată prima, după care

valoarea, sau valorile, rezultate erau utilizate de către clauza WHERE din interogarea

exterioară.

Exista şi o altă forma de subinterogare şi anume Subinterogarea corelată, caz în care

interogarea exterioară transmite repetat câte o valoare pentru interogarea interioară.

De fiecare dată când este transmisă o valoare, este evaluată interogarea interioară.

Dacă ambele interogări acceseaza acelaşi table, trebuie asigurate alias-uri pentru fiecare

referinţa la tabelul respectiv. Ambele interogări accesează tuple diferite din acelaşi table în

acelaşi moment.

Exemple

Sa se afişeze codurile imprumuturilor, data imprumutului, data unei plaţi şi suma

plătită, pentru sumele maxime care s-au plătit, ordonate după data împrumutului.

SELECT Imprumuturi.Cod_imprumut, Imprumuturi.Data_ imprumut,

plati.data,plati.suma

FROM Imprumuturi INNER JOIN plati ON Imprumuturi.Cod

Page 79: Baze de date_Iacob

78

_imprumut=plati.cod_imprumut

WHERE suma=

(SELECT MAX(suma)

FROM plati

WHERE Imprumuturi.Cod_ Imprumut=plati.cod_ Imprumut) ORDER BY

Imprumuturi..Data_ Imprumut;

Restricţionare subinterogărilor

Operatorii ANY şi ALL

Operatorul ANY poate fi utilizat în cobinaţie cu oricare dintre operatorii relaţionali (=

< > <= >= !=) pentru a se varifica dacă valorile unui atribut este egală, mai mică, mai mare,

etc. decât oricare dintre valorile menţionate o dată cu operatorul. Urmatoarele predicate sunt

echivalente:

=ANY si IN

!=ANY si NOT IN

Operatorul ALL returnează tuplele pentru care valorile atributului din clauza WHERE

sunt mai mici, mai mari, mai mici sau egale, ect. decât toate valorile generate de interogarea

interioară. Să facem observaţia că acest operator nu poate fi utilizat cu operatorul relaţional =,

ceea ce ar corespunde cazului banal în care toate valorile din listă sunt identice.

Pentru a stabili mai exact modul în care se selectează valorile cu operatorii ANY şi ALL dăm

mai jos o serie de cazuri concrete.

Să presupunem ca interogarea este de forma:

SELECT…

FROM …

WHERE x <ALL (1,2,3,4)

Să observăm că dacă înlocuim operatorul ALL cu expresia verbală toate putem citi

“Valorile lui x trebuie să fie mai mici decât toate valorile d in paranteza ce urmeaza după

ALL”.

Atunci vom lua în considerare urmatoarele situaţii:

Expresia din clauza WHERE Valori ale lui x care corespund

X<ALL 0,-1,-2,…

X<=ALL 1,0,-1,-2,…

X>ALL 5,6,7,…

X>=ALL 4,5,6,…

Daca vom studia o interogare de forma:

SELECT…

FROM …

WHERE x <ANY (1,2,3,4)

Să observăm că dacă înlocuim operatorul ANY cu expresia verbală oricare putem citi

“Valorile lui x trebuie să fie mai mici decât oricare dintre valorile din paranteza ce urmeaza

dupa ALL”.

Page 80: Baze de date_Iacob

79

Vom lua în considerare următorul table:

Expresia din clauza WHERE Valori ale lui x care corespund

X<ANY 3,2,1,0,-1,-2,…

X<=ANY 4,3,2,1,0,-1,-2,…

X>ANY 2,3,4,5,6,7,…

X>=ANY 1,2,3,4,5,6,…

Exemple

Exemple:

Să se afişeze titlul filmelor, anul apariţ iei şi genul, pentru filmele din SUA,

care au anul apariţiei maxim.

SELECT Filme.Titlu,Filme.An_aparitie,Filme.Gen

FROM Filme

WHERE An_aparitie<ALL

(SELECT An_aparitie

FROM Filme

WHERE Tara=’SUA’);

Exemple

Să se afişeza codul casetelor, preţul, titlurile filmelor pentru

Casetele disponibile, din care le excludem pe cele de preţ maxim.

SELECT Casete.Cod_caseta,Casete.Pret,Casete.disponibil,Filme.titlu

FROM Filme INNER JOIN (Casete INNER JOIN[Casete-Filme] ON

Casete.Cod_caseta=[ Casete-Filme].Cod_caseta) ON Filme.Cod_film= [Casete-

Filme].Cod_film

WHERE disponibil=Yes AND Pret<ANY

(SELECT Pret

FROM Casete

WHERE disponibil=YES);

Operatorul EXISTS

Operatorul EXISTS verifică dacă pentru fiecare tuplu al relaţiei există tuple care

satisfac condiţia interogării interioare. În cazul în care există asemenea tuple, EXISTS ia

valoarea de adevar TRUE. Astfel, operatorul EXISTS permite specificarea mai multor

attribute în interogarea interioară. Acest lucru este posibil deoarece nu se verifică valoarea

unui atribut, ca în cazurile anterioare, ci se generează o valoare de adevar ( TRUE sau

FALSE), după cum există sau nu există o anumită valoare într-o relaţie diferită de cea

utilizată în interogarea exterioară.)

Ca şi operatorii ANY şi ALL, operatorul EXISTS apare în clauza WHERE.

Exemple

Să se afişeze titlui filmelor, anul aparitiei şi genul pentru filmele care au un an de

apariţie mai mare sau egal cu anul maxim de apariţie al fi lmelor de gen fabula.

Page 81: Baze de date_Iacob

80

SELECT Titlu,An_aparitie,Gen

FROM Filme f

WHERE NOT EXISTS

(SELECT *

FROM Filme

WHERE Gen=’fabula’ AND An_aparitie>f.An_aparitie);

Interogarea SELECT interioară defineşte o tabelă care conţine tuple pentru care se

verifică condiţia din clauza WHERE internă.

Actualizări ale bazei de date.

SQL poate fi folosit atât pentru interogarea bazei de date cât şi pentru actualizarea

bazelor de date. Comenzile pentru actualizări nu sunt atât de complexe ca declaraţia SELECT.

Declaraţiile SQL aferente actualizării unei baze de date se referă la modificările unei tabele

(adăugare sau ştergere de linii, modificarea datelor dintr -o tabelă):

Adăugarea se face cu declaraţia INSERT care are două forme prima accepta

adăugarea unei singure linii, iar a doua adăugarea mai multor linii.

I. Adăugarea unei singure linii

INSERT INTO nume_tabela [(lista_atribute)]

VALUES (lista_valorilor_datelor)

Nume_tabela reprezintă numele unei tabele din baza de date sau o vedere actualizată a

acesteia, lista_atribute reprezintă o listă de una sau mai multe nume ale coloanelor tabelei

separate prin virgulă. Dacă această listă nu este specificată SQL consideră toate atributele

tabelei în ordinea în care au fost create în tabela originală. În cazul în care sp ecificăm această

listă atributele pe care dorim să le omitem trebuie să le declarăm ca NULL. Numărul de

elemente din cele două liste trebuie să coincidă, să aibă aceaşi ordine de declarare şi să fie

compatibile ca tip.

Exemple

Exemplu:

Inseraţi o nouă înregistrare în tabela Conducere completând datele pentru toate

atributele:

INSERT INTO Conducere

VALUES (‘cd16’, ‘Ionescu’, ‘Alex’, ‘George Enescu 37, ap.4, Bucuresti’, ‘021 -

456-12456’,’director economic’,’m’, date ’01.07.1945’)

Inseraţi o nouă înregistrare în tabela casete.

Exemple

.

Page 82: Baze de date_Iacob

81

II. Adăugarea mai multor linii prin copierea lor dintr -o tabelă sau mai multe tabele într-o altă

tabelă

INSERT INTO nume_tabela [(lista_atribute)]

SELECT …

Nume_tabela şi lista de atribute sunt definite la fel ca la cazul anterior, iar clauza SELECT

poate fi orice declaraţie validă.

Exemple

Inseraţi o nouă înregistrare în tabela Conducere completând datele doar pentru

atributele obligatorii cod, Nume, Prenume, Functie

INSERT INTO Conducere

VALUES (‘cd44’, ‘Aduducai’, ‘Maria’, NULL, NULL,’asisent manager’,NULL,

NULL)

Exemplu:

Exemple

Presupunând că în tabela ContConducere conţine numele celor din

conducere şi numărul serviciilor pe care le au în subordine populaţi tabela

ContConducere folosind detalii din tabelele Conducere şi PorpServicii o nouă

înregistrare în tabela Conducere completând datele pentru toate atributele:

INSERT INTO ContConducere

(SELECT s.id, nume, prenume, COUNT(*)

FORM Conducere s, PropServicii p

WHERE s.id=p.id

GROUP BY s.id, nume, prenume)

UNION

(SELECT id, nume, prenume, 0

FORM Conducere

WHERE id NOT IN

(SELECT DISTINCT id

FROM PropServicii))

Modificarea se face cu declaraţia UPDATE care permite modificarea datelor unor

înregistrări existente într-o tabelă dată. Sintaxa acestei comenzi este:

UPDATE nume_tabela

SET nume_atribut1=valoare1[,nume_atribut2=valoare2 ….]

[WHERE conditie_cautare]

Clauza SET specifică numele unui atribut sau a mai multor atribute care urmează a fi

modificate, WHERE este o clauză opţională, prin omiterea ei se consideră că toate că toate

înregistrările for fi modificate pentru atributele alese la clauza SET, iar dacă ea este

specificată atunci doar acele înregistrări care îndeplinesc condiţiile de căutare. Tipul datelor

valoare1,…. trebuie să fie compatibile cu cele ale atributelor corespunzătoare.

Page 83: Baze de date_Iacob

82

Exemple

Modificarea tuturor înregistrărilor pentru mărirea salariior tuturor celor din

conducere cu 3%.

UPDATE CONDUCERE

SET salariu = salariu*1.03

Modificarea preţului la casetele cu preţul maxim prin reducere cu 10%.

2. Modificarea doar a unor înregistrări specificate

UPDATE CONDUCERE

SET salariu = salariu*1.05

WHERE functie=’manager’

Modificarea înregistrărilor pentru mai multe atribute

UPDATE CONDUCERE

SET functie=’manager’, salariu = 18.000.000

WHERE id=’cd73’

Ştergerea se face cu declaraţia DELETE , sintaxa acestei comenzi este :

DELETE FROM nume_tabela

WHERE conditie_cautare

Dacă opţiunea WHERE lipseşte atunci se şterg toate înregistrările darn nu şi tabelul,

pentru a şterge un tabel folosim declaraţia DROP TABLE. Se poate şterge un tabel numai

dacă nu mai are înregistrări.

Exemple

1. Ştergerea tuturor înregistrărilor din tabela vedere (view)

DELETE FROM viewing;

2. Ştergerea anumitor înregistrări din tabela vedere (view)

DELETE FROM viewing;

WHERE id = ‘cd72’

Ştergerea tuturor înregistrărilor din tabela casete.

Ştergerea înregistrărilor din tabela casete cu preţ minim.

Page 84: Baze de date_Iacob

83

M3.U3.2. Rezumat Pentru definirea interogǎrilor de selecţie simple se utilizeazǎ urmǎtoarea sintaxǎ

a instrucţiunii SELECT:

SELECT[domeniu]lista_selecţie FROMnume_tabela1,nume_tabela2… [WHERE criteriu_de_selecţie} ORDER BY câmpuri_criteriu [ASC/DESC]]; Funcţiile de grup agregat permit construirea unor interogǎri SQL

complexe, prin care utilizatorul poate sǎ efectueze diverse calcule pentru grupuri

de înregistrǎri care au câmpuri cu aceeasi valoare. În cazul utilizǎrii lor se

foloseşte urmǎtoarea formǎ a frazei SELECT:

SELECT [domeniu] [funcţie agregatǎ (nume_câmp) AS alias [,lista_selecţie]

FROM nume_tabela1, n ume_tabela2…

GROUP BY câmp_de_grupare

[HAVING criteriu_de_grupare]

[ORDER BY câmpuri_criteriu [ASC/DESC]];

Sintaxa generalǎ pentru joncţiuni este urmǎtoarea:

SELECT [domeniu] lista_selecţie

FROM nume_tabela1,nume_tabela 2…

WHERE criteriul_de_asociere]

[ORDER BY câmpuri_criteriu[ASC?DESC];

O altǎ abordare priveşte joncţiunile ca fiind: interne (INNER JOIN) şi externe

(OUTER JOIN). Primele determinǎ o asociere a înregistrǎrilor din tabele, astfel

încat sa rezulte un numar total de înregistrǎri din fiecare tabela. Joncţiunile

externe, la randul lor, sunt de doua tipuri: de stanga (LEFT OUTER JOIN) şi de

dreapta (RIGHT OUTER JOIN) fiind destul de puţin utilizate.

În acest mod de abordare al joncţiunulor sintaxa va avea forma:

SELECT [domeniu] lista_selecţie

FROM num_tabela1

JOIN nume_tabela2

ON criteriu_de_asociere

[{INNER/LEFT OUTER/ RIGHT OUTER} JOIN nume_tabela3

ON criteriu_de_asociere]…

[WHERE criteriu_de_selecţie]

[ORDER BY câmpuri_criteriu {ASC/DESC]]:

Unul din motivele pentru care SQL este considerat un limbaj puternic de

interogare este acela cǎ oferǎ posibilitatea construirii interogǎrilor complexe,

formate din mai multe subinterogǎri simple.

Aceste interogǎri complexe sunt construite prin includerea în clauza

WHERE a încǎ unei clauze SELECT. Forma generalǎ a unei astfel de

construcţii este:

SELECT <lista atributelor>

FROM <lista relatii1>

WHERE <subinterogare>

SQL poate fi folosit atât pentru interogarea bazei de date cât şi pentru

actualizarea bazelor de date. Comenzile pentru actualizǎri nu sunt atât de

complexe ca declaraţia SELECT.

Adǎugarea se face cu declaraţia INSERT care are douǎ forme prima accepta

adǎugarea unei singure linii, iar a doua adǎugarea mai multor linii.

Page 85: Baze de date_Iacob

84

I. Adǎugarea unei singure linii

INSERT INTO nume_tabela [(lista_atribute)]

VALUES (lista_valorilor_datelor)

Nume_tabela reprezintǎ numele unei tabele din baza de date sau o vedere

actualizatǎ a acesteia, lista_atribute reprezintǎ o listǎ de una sau mai multe nume

ale coloanelor tabelei separate prin virgulǎ. Dacǎ aceastǎ listǎ nu este specificatǎ

SQL considerǎ toate atributele tabelei în ordinea în care au fost create în tabela

originalǎ. În cazul în care specificǎm aceastǎ listǎ atributele pe care dorim sǎ le

omitem trebuie sǎ le declarǎm ca NULL. Numǎrul de elemente din cele douǎ

liste trebuie sǎ coincidǎ, sǎ aibǎ aceaşi ordine de declarare şi sǎ fie compatibile

ca tip.

Modificarea se face cu declaraţia UPDATE care permite modificarea datelor

unor înregistrǎri existente într-o tabelǎ datǎ. Sintaxa acestei comenzi este:

UPDATE nume_tabela

SET nume_atribut1=valoare1[,nume_atribut2=valoare2 ….]

[WHERE conditie_cautare]

Ştergerea se face cu declaraţia DELETE , sintaxa acestei comenzi este:

DELETE FROM nume_tabela

WHERE conditie_cautare

M3.U3.2. Test de autoevaluare a cunoştinţelor

Se dau următoarele relaţii cu schemele lor:

-Scări (Nr_bloc, Scara, Lift)

-Apartamente(Nr_bloc,Scara,Apartament,Suprafaţa,Cutii_poştale, Nr_prize_tv)

- Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)

-Locatari Nr_Mat, Nr_bloc, Scara, Etaj, Apartament,Nume

Să se exprime în SQL cererile:

3.2.1 (tabel nominal cu locatarii de pe scara = 3 din bloc = 34) = R1

3.2.2 (tabel nominal cu locatarii de pe scara = 1 din bloc = 34) = R2

3.2.3 (tabel nominal cu locatarii de pe scara = 2 din bloc = 34) = R3

3.2.4 tabel nominal cu locatarii de pe scările 1,2,3 ale blocului 34

3.2.5 lista apartamentelor cu suprafaţa mai mare decât 50 mp

3.2.6 tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 şi nu locuiesc şi

pe scara 1 a aceluiaşi bloc

Răspunsurile se găsesc la sfârşit la pag 154

Page 86: Baze de date_Iacob

85

Modulul 4. Normalizarea

Cuprins

Introducere

Obiectivele modului

U4.1 De ce este nevoie de normalizare şi cu ce instrumente facem normalizarea.

U4.2 Forme normale

M4 Introducere

La proiectarea unei baze de date, un obiectiv foarte important, care trebuie

urmarit cand se gandeste un model de date, este realizarea unei reprezentari

corecte a datelor, a relatiilor dintre date şi a restrictiilor impuse asupra datelor.

Pentru realizarea acestui obiectiv se utilizeaza tehnica normalizarii, care are ca

scop principal identificarea setului celui mai adecvat de relatii care sa modeleze

realitatea dorita.

M4. Obiectivele modulului

La sfârşitul acestui modul studenţii vor fi capabili să:

descopere dependenţele funcţionale între atribute, şi să le pună în

evidenţă proprietăţile

descopere anomaliile din descrierea unei baze de date

aducă o bază de date la formele normale 1, 2 şi 3. descopere

anomaliile din descrierea unei baze de date

aducă o bază de date la formele normale 1, 2 şi 3.

Page 87: Baze de date_Iacob

86

Unitatea de învăţare 4.1 De ce este nevoie de normalizare şi cu ce instrumente facem

normalizarea.

M4.U4.1. Introducere

Procesul de normalizare este o metodă formală care identifica relaţiile

bazandu-se pe cheile primare ale acestora (sau pe cheile candidat în cazul BCNF)

şi pe dependenţele funcţionale care exista intre atributele acestor relatii.

Normalizarea sprijina proiectantul bazei de date, dandu-i posibilitatea sa aplice o

serie de teste asupra relatiilor individuale, asa incat schema relaţionala poate fi

normalizata la forma normala dorita, pentru a se preveni aparitia anomaliilor la

actualizare.

M4.U4.1. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

realizeze importanţa normalizării

descopere dependenţele funcţionale între atribute, şi să le pună în

evidenţă proprietăţile

Durata medie de parcurgere a primei unităţi de învăţare este de 1 oră.

Pentru a ilustra procesul de normalizare, vom utiliza exemple din sistemul informatic

Asociatie de locatari.

Partea cea mai importantă la proiectarea bazei de date este gruparea atributelor în relaţii cu

scopul de a minimiza redundanţa informaţiilor şi (odata cu aceasta) spaţiul ocupat de relatii

(tabele sau fişiere) pe suportul magnetic.

Exemple

Fie relaţia Furnizori_Cheltuieli exemplificată mai jos. In exemple se vor

simplifica numele atributelor. Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data Valoare

F100 Romgaz R1234567 C15 Incalzire 30.06.99

2,150,000

F100 Romgaz R1234567 C16 Apa calda 30.06.99

500,000

F110 Renel R7654321 C10 Iluminat 30.06.99

3,000,000

F110 Renel R7654321 C11 Lift 30.06.99

200,000

Relaţia Furnizori_Cheltuieli instanţiată

Sa presupunem ca aplicaţia pe care o vom studia ca exemplu contine datele organizate intr-o

singura relatie descrisa de urmatoarele schema de relatie:

Page 88: Baze de date_Iacob

87

Furnizori_Cheltuieli = (Cod_furn, Den_furn, Cod_fiscal, Cod_chelt, Den_chelt, Data,

Valoare)

Dintre atribute, cele evidentiate constituie cheia primara pentru relatia respectiva.

Relatia Furnizori_Cheltuieli are cheia compusa din atributele Cod_furn, Cod_Chelt şi Data.

Datele sunt prost organizate in relatia prezentata.

Informaţia despre furnizori din relatia Furnizori_Cheltuieli este redundantă. Detaliile

despre furnizor se repetă la fiecare introducere a unei cheltuieli noi.

Nu este insa singura problema pe care o organizare nepotrivita a datelor o poate

genera.

O altă consecinta a redundanţei informatiilor din baza de date, o reprezinta problemele de

actualizare a informaţiei stocate. Enumeram mai jos o parte dintre acestea.

Anomalii de adaugare

Anomaliile de inserare se pot clasifica în două tipuri:

Pentru a adauga detaliile despre o cheltuială către un furnizor, în relaţia

Furnizori_Cheltuieli trebuie obligatoriu adăugate şi detaliile despre furnizorul în cauză,

chiar dacă ele există deja în baza de date. Această anomalie poate duce la apariţia de

informatii diferite despre acelasi furnizor în înregistrări diferite. Informatia despre furnizor

isi pierde in acest mod consistenta, nu ne mai putem baza pe corectitudinea datelor despre

furnizor in baza de date.

Pentru a adăuga detalii despre un furnizor nou în relaţia Furnizori_Cheltuieli, trebuie

neapărat adăugată şi o cheltuială pentru asociaţia de locatari către acel furnizor. În cazul în

care încă nu a sosit factura de la furnizor, nu se poate înregistra nici o cheltuială şi deci

trebuie introduse valori nule. Este nerecomandabil sa se lucreze cu valori nule deoarece se

genereaza probleme la regasirea şi actualizarea informatiilor.

Anomalii de ştergere

În cazul ştergerii unei cheltuieli a asociaţiei de locatari către un furnizor nou (tot in cadrul

relatiei Furnizori_Cheltuieli ), se va şterge şi furnizorul. Deci toate detaliile introduse despre

acel furnizor vor fi pierdute, ceea ce duce la obligativitatea reintroducerii datelor la o nouă

folosire al acelui furnizor.

Anomalii de modificare

Dacă în relaţia Furnizori_Cheltuieli dorim să schimbăm valoarea unui atribut al unui

furnizor, va trebui să schimbăm datele pentru fiecare apariţie a acelui furnizor. De exemplu

dacă dorim să schimbăm codul fiscal al furnizorului cu codul F100, va trebui să schimbăm

acest atribut în toate tuplele in care apare furnizorul F100. Din nou , este posibil ca datele sa

nu fie modificate corect. Este posibil sa ramana tuple cu datele nemodificate sau este posibil

sa se modifice datele respective cu valori diferite in locuri diferite. (Nu dorim sa insistam

asupra cauzelor care pot duce la aceste situatii.).

Anomaliile enumerate mai sus se pot evita prin folosirea (in acest caz) a două relatii

distincte: Cheltuieli şi Furnizori. În acest caz dacă trebuie modificat un atribut al unui

furnizor, modificarea se va xecuta intr-un singur loc în relatia Furnizori. Asemanator, daca e

necesara o stergere in relatia Cheltuieli, aceasta nu va mai afecta furnizorii din relatia

Furnizori. De asemenea orice cheltuiala adaugata şi orice furnizor nou adaugat nu se vor mai

conditiona reciproc in nici un fel.

Descompuneri cu pierderi de informatii

Page 89: Baze de date_Iacob

88

În urma analizarii anomaliilor de actualizare prezentate mai sus am tras concluzia ca o

descompunere a relatiilor care ne fac probleme este binevenita şi duce la rezolvarea

problemelor. Este bine insa sa tratam descompunerile de relatii cu prudenta deoarece o

descompunere neglijenta ne poate crea probleme la fel de mari cu acelea de care tocmai ne-

am ocupat. Este posibil sa pierdem informatii daca nu suntem atenti la modul in care se

realizeaza descompunerea.

În general se poate urmari ca in fiecare relatie sa se reprezinte informatii despre o

singura multime-entitate. Criteriul este mai mult de ordin intuitiv şi el nu ne este de mare

ajutor in cazul reprezentarii multimilor-relatie. In acest caz, intr-o relatie se intalnesc date

despre mai multe multimi-entitate. Este necesar sa se stabileasca o modalitate riguroasa de a

decide care sunt informatiile care trebuie sa alcatuiasca o astfel de relatie.

Orice relatie se construieste pe baza unei scheme de relatie. Fie R o schema oarecare

de relatie. Un set de scheme de relatie reprezinta o descompunere a lui R şi se noteaza {R1,

R2, …, Rn} daca

n

i

iR1

= R

Aceasta inseamna ca orice atribut din schema de relatie initiala R se regaseste in cel

putin o schema de relatie din descompunere. Daca ne raportam la relatiile care se bazeaza pe

schemele de mai sus, fie r relatia construita pe schema R sie fie relatiile r1, r2, …, rn construite

pe schemele de relatie ce formeaza descompunerea. In termenii algebrei relaţionale se poate

considera egalitatea;

ri = iR(r) pentru toti 1in.

Deci fiecare ri este proiectia relatiei r pe atributele care apar in schema de relatie R i.

Descompunerile cu pierderi de informatii se pot clasifica in Descompuneri cu

pierderi la jonctiune şi Descompuneri cu pierderea dependentelor. Pentru a clarifica

lucrurile in aceasta directie este necesara mai intai definirea notiunii de dependenta

functionala.

Dependenţe funcţionale

Unul din cele mai importante concepte asociate cu normalizarea este conceptul de

dependenţă funcţională. Dependenţa funcţională descrie un anumit tip de legatura care se

stabileste intre atributele aceleiasi relatii.

Fie o schema de relatie R şi fie submultimile de atribute A şi B din R. Se verifica AR

şi BR. Spunem ca B depinde functional de A şi scriem AB daca pentru orice relatie legala

r, construita pe schema de relatie R, se verifica urmatoarea situatie: pentru orice pereche de

tuple t1 şi t2 din r, pentru care t1[A]=t2[A], are loc intotdeauna şi t1[B]=t2[B].

Aceasta inseamna ca atunci cand un tuplu t1 are (pe submultimea de atribute A)

aceeasi valoare cu alt tuplu t2, obligatoriu cele doua tuple vor avea aceeasi valoare şi pe

submultimea de atribute B. Valorile din B sunt in mod unic determinate de valorile din A.

Numim determinant al unei dependente funcţionale, atributul, sau mulţimea

atributelor din partea stângă a săgeţii.

Exemple O parte dintre dependenţele funcţionale pentru relaţia

Furnizori_Cheltuieli sunt:

Cod_furn Den_furn

Page 90: Baze de date_Iacob

89

Cod_furn Cod_fiscal

Cod_chelt Den_chelt

Cod_chelt, Cod_furn, Data Valoare

Numele furnizorului este determinat in mod unic de codul furnizorului. La coduri

egale, numele sunt identice.

Valoarea insa nu poate fi determinata in mod unic decat de combinatia cod

cheltuiala, cod furnizor şi data. Intr-o anume data, un anumit furnizor, pentru un

anumit serviciu (care duce la un anume cod cheltuiala) cere o suma bine

determinata de bani. Nici una dintre valori nu poate determina valoarea şi nici in

combinatii de cate doua. Daca nu se iau cele trei informatii impreuna se pot crea

confuzii in legatura cu valoarea. (Acelasi cod de cheltuiala poate corespunde la

valori diferite in date diferite. Acelasi furnizor poate avea chiar şi coduri de

cheltuiala diferite darmite valoarea care le reprezinta, s.a.m.d. …)

Notiunea de dependenta functionala generalizeaza notiune de cheie. Se poate da

urmatoarea definitie a supercheii:

Spunem ca submultimea deatribute K din schema de relatie R este o supercheie daca

KR, adica pentru orice pereche de tuple t1 şi t2 din r, pentru care t1[K]=t2[K], are loc

intotdeauna şi t1[R]=t2[R].

Dependentele functionale ne permit sa exprimam restrictii asupra relatiilor pe care nu

le putem exprima cu ajutorul cheilor. Dependenţa funcţională este o proprietate legata de

semantica atributelor în relaţii. Dependentele functionale pot fi stabilite de cine cunoaste exact

legaturile intre valorile atributelor, deci de catre cineva care cunoaste foarte bine aplicaţia şi

semnificatia informatiilor din relatii.

Nu se pot da retete pentru stabilirea dependentelor functionale, dar se pot da metode

de a determina toate dependentele functionale dintr-o relatie daca se cunosc cateva

dependente de la care poate porni algoritmul.

O metoda de a determina multimea tuturor dependentelor functionale dintr-o relatie se

bazeaza pe asa-numitele Axiome ale lui Armstrong.

Regulile (Axiomele) lui Armstrong:

1) regula reflexivitatii – daca X este un subset de atribute din R şi YX, atunci are loc

XY;

2) regula creşterii – daca X, Y şi W sunt subseturi de atribute din R şi daca XY atunc

WXWY;

3) regula tranzitivitatii – daca X, Y şi Z sunt subseturi de atribute din R şi daca XY şi

YZ atunci are loc şi XZ.

Cele trei reguli sunt suficiente şi formeaza un set complet pentru a se putea determina

toate dependentele functionale daca se porneste de la un set de baza initial. Totusi se mai

utilizeaza in mod obisnuit şi reguli suplimentare (care pot fi deduse din primele trei) deoarece

usureaza calculele.

Astfel:

4) regula reuniunii – daca X, Y şi Z sunt subseturi de atribute din R şi daca XY şi XZ

Page 91: Baze de date_Iacob

90

atunci şi XYZ;

5) regula descompunerii – daca daca X, Y şi Z sunt subseturi de atribute din R şi daca

XYZ atunci au loc şi XY şi XZ;

6) regula pseudotranzitivitatii - daca X, Y, W şi Z sunt subseturi de atribute din R şi daca

XY şi WYZ atunci şi WXZ

Exemple

EXEMPLU:

Fie schema de relatie R={A, B, C, G, H, I} şi fie setul de dependente initial notat

cu F şi format din dependentele: AB, AC, CGH, CGI, BH.

Pornind de la acest set initial se mai pot calcula şi urmatoarele dependente:

AH, utilizand regula tranzitivitatii aplicata la dependentele AB şi BH;

CGHI, utilizand regula reuniunii pentru dependentele CGH şi CGI;

si asa mai departe… …

Daca se noteaza cu F setul initial de dependente functionale, cu F+

se va nota

inchiderea lui F (deci toate dependentele functionale care se pot defini pentru relatia in cauza.)

Putem reveni in acest moment pentru a trata descompunerile de relatii. Am subliniat

mai inainte ca este necesar sa fim atenti la descompuneri pentru a evita pierderea de

informatii.

Descompuneri fara pierderi la joncţiune

Fie o descompunere oarecare {R1, R2, …, Rn} a relatiei R, asa cum am definit-o

formal la inceputul acestui capitol. Pentru o descompunere oarecare se verifica intotdeuna

relatia:

rn

1iX

ri

unde prin X s-a notat produsul cartezian, operatie din algebra relaţionala. Altfel spus, orice

tuplu din relatia r duce, prin descompunere, la cate un tuplu ti in fiecare relatie ri. Cand se

realizeaza produsul cartezian cu toate relatiile ri, se obtin in general mai multe tuple decat au

fost in relatia initiala r, deoarece produsul cartezian are ca rezultat toate combinatiile posibile

intre elementele participante.

Asupra relatiilor dintr-o baza de date se impun intotdeauna anumite restrictii sau

conditii, care sa asigure corectitudinea informatiilor din respectiva baza de date.

În general spunem ca o relatie este legala daca satisface toate regulile sau restrictiile

care sunt impuse la proiectarea bazei de date.

Fie C un set de restrictii asupra bazei de date. O descompunere {R1, R2, …, Rn} a unei

scheme de relatie R este o descompunere fara pierderi la jonctiune pentru R, daca pentru toate

relatiile r definite pe schema R (care sunt legale sub restrictiile C) se verifica:

r=n

1iX

r)(iR

Vom prezenta in continuare un criteriu cu ajutorul caruia se poate verifica daca este o

descompunere fara pierderi la jonctiune sau nu.

Page 92: Baze de date_Iacob

91

Definitie. Fie R o schema de relatie şi fie descompunerea lui R reprezentata de {R1, R2}.

Aceasta descompunere este fara pierderi la jonctiune daca cel putin una dintre urmatoarele

dependente functionale se gasesc in F+:

R1R2R1

R1R2R2

Descompuneri cu pastrarea dependentelor

Pastrarea dependentelor duce la pastrarea consistentei informatiilor din baza de date.

Se pot impune restrictii care permit sistemului sa verifice la orice actualizare a informatiilor

ca nu se va crea o relatie ilegala.

Fie F setul initial de dependente functionale, definit pe o schema de relatie R. şi fie

{R1, R2, …, Rn} o descompunere a lui R. Notam cu Fi restrictia la Ri a multimii de dependente

functionale F. (Se cere ca dependentele functionale din Fi sa includa doar atribute care se

regasesc in relatia Ri).

Vom obtine un set de multimi de dependente functionale F1, F2, …, Fn. Fie F'=n

i 1

Fi,

reuniunea seturilor de dependente funtionale. In general F'F. Dar s-ar putea ca sa se verifice

relatia F'+=F

+. Daca se intampla asa atunci spunem ca descompunerea este o descompunere cu

pastrarea dependentei.

M4.U4.1. Rezumat Din cauza proiectării incorecte pot apărea anomalii la in serare de noi

ănregistrări, la şterger şi la modificări.

In urma analizarii anomaliilor de actualizare prezentate mai sus am tras

concluzia ca o descompunere a relatiilor care ne fac probleme este binevenita

şi duce la rezolvarea problemelor. Este posibil sa pierdem informatii daca nu

suntem atenti la modul in care se realizeaza descompunerea.

Orice relatie se construieste pe baza unei scheme de relatie. Fie R o schema

oarecare de relatie. Un set de scheme de relatie reprezinta o descompunere a

lui R şi se noteaza {R1, R2, …, Rn} daca

n

i

iR1

= R

Aceasta inseamna ca orice atribut din schema de relatie initiala R se regaseste

in cel putin o schema de relatie din descompunere. Daca ne raportam la

relatiile care se bazeaza pe schemele de mai sus, fie r relatia construita pe

schema R sie fie relatiile r1, r2, …, rn construite pe schemele de relatie ce

formeaza descompunerea. In termenii algebrei relaţionale se poate considera

egalitatea;

ri = iR(r) pentru toti 1in.

Deci fiecare ri este proiectia relatiei r pe atributele care apar in schema de

relatie Ri.

Descompunerile cu pierderi de informatii se pot clasifica in Descompuneri cu

pierderi la jonctiune şi Descompuneri cu pierderea dependentelor. Pentru

Page 93: Baze de date_Iacob

92

a clarifica lucrurile in aceasta directie este necesara mai intai definirea notiunii

de dependenta functionala.

Fie o schema de relatie R şi fie submultimile de atribute A şi B din R. Se

verifica AR şi BR. Spunem ca B depinde functional de A şi scriem AB

daca pentru orice relatie legala r, construita pe schema de relatie R, se verifica

urmatoarea situatie:

pentru orice pereche de tuple t1 şi t2 din r, pentru care t1[A]=t2[A], are loc

intotdeauna şi t1[B]=t2[B].

Regulile (Axiomele) lui Armstrong:

7) regula reflexivitatii – daca X este un subset de atribute din R şi YX,

atunci are loc XY;

8) regula creşterii – daca X, Y şi W sunt subseturi de atribute din R şi daca

XY atunc WXWY;

9) regula tranzitivitatii – daca X, Y şi Z sunt subseturi de atribute din R şi

daca XY şi YZ atunci are loc şi XZ.

M4.U4.1. Test de autoevaluare a cunoştinţelor

4.1.1 Descoperiţi dependenţele funcţionale din tabela:

Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota))

Răspunsurile se găsesc la sfârşit la pag 155

Page 94: Baze de date_Iacob

93

Unitatea de învăţare 4.2 Forme normale

M4.U4.2 Introducere

Procesul de normalizare a fost introdus de E. F. Codd (1972). Iniţial s-au propus

trei forme normale, notate 1NF, 2NF, respectiv 3NF. Mai târziu, prin enuntarea

unei definitii mai tari a formei normale trei, s-a obtinut forma Boyce-Codd, după

numele celor care au introdus aceasta forma normala: R. Boyce şi E. F. Codd

(1974). Toate aceste forme normale se bazeaza pe dependentele functionale

stabilite intre atributele unei relatii.

Formele normale cele mai folosite sunt: forma normală 3 şi forma normală

Boyce-Codd. Există şi forme normale mai tari - forma normală 4 (4NF) şi forma

normală 5 (5NF) - dar acestea se folosesc foarte rar.

M4.U4.2. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

descopere anomaliile din descrierea unei baze de date

aducă o bază de date la formele normale 1, 2 şi 3.

Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Normalizarea este un proces de organizare a datelor in relatiile unei baze de d ate.

Acest proces presupune respectarea unor reguli prin care baza de date se poate normaliza până

la un anumit grad, adica se aduce la o anumita forma normala.

Normalizarea se execută trecând prin toate formele normale, până la forma normală cerută. La

proiectarea unei baze de date e recomandabil sa se ajunga cel puţin pana la forma normală

trei. Aceasta asigura evitarea anomaliilor descrise la inceputul acestui capitol.

Forma Normală Unu (1NF)

Numim Formă Nenormalizată (UNF) orice tabelă care conţine una sau mai multe grupuri

repetitive pe atribute.

Forma Normală Unu (1NF): Spunem ca o relaţie se gaseste in Forma normala unu daca

orice atribut este atomic, adica nu exista nici atribute compuse nici repetitive.

Pentru a transforma tabela din exemplul următor în forma normală unu, identificăm şi

ştergem grupurile repetitive din tabelă. Eliminarea acestor grupuri repetitive se poate realiza

în două moduri:

Exemple 4.2.1

Pentru relaţia Furnizori_Cheltuieli:

Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data

Valoare

F100 Romgaz R1234567 C15 Incalzire 30.06.99

2,150,000

C16 Apa calda 30.06.99 500,000

F110 Renel R7654321 C10 Iluminat 30.06.99

3,000,000

Page 95: Baze de date_Iacob

94

C11 Lift 30.06.99 200,000

Tabela nenormalizată Furnizori_Cheltuieli.

Conform primei modalităţi, eliminăm grupurile repetitive, prin crearea altor

înregistrări, în care să fie introduse valorile din aceste grupuri, împreună cu celelalte valori ale

atributelor din înregistrarea la care se lucrează. Tabele astefel rezultată va fi în formă normală

unu.

În a doua modalitate, fiecere valoare a grupurilor repetitive le copiem într-o nouă

relaţie împreună cu cheia primară din tabela iniţială. Putem avea mai mu lte grupuri repetitive.

În acest caz creăm mai multe relaţii noi. Aceste relaţii noi, precum şi tabela normalizată vor fi

în formă normală unu.

Observăm că pentru furnizorul "Romgaz" avem două tipuri de cheltuieli. La fel şi

pentru furnizorul "Renel".

Pentru a transforma această tabelă în 1NF, trebuie să avem o singură valoare la fiecare

intersecţie linie coloană.

Daca vom normaliza dupa prima metoda, vom scrie repetiţiile pe diferite rânduri iar

coloanele care nu conţin repetiţii, vor fii copiate corespunzator pe fiecare rând

Exemple 4.2.2

Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data

Valoare

F100 Romgaz R1234567 C15 Incalzire 30.06.99

2,150,000

F100 Romgaz R1234567 C16 Apa calda 30.06.99

500,000

F110 Renel R7654321 C10 Iluminat 30.06.99

3,000,000

F110 Renel R7654321 C11 Lift 30.06.99

200,000

Tabela Furnizori_Cheltuieli în 1NF

În tabela normalizatã, cheia va fi (Cod_furn, Cod_chelt, Data).

Normalizând tabela iniţială după a doua modalitate, vom crea o a doua tabelă cu

informaţiile care nu se repetă, împreună cu cheia primară din tabela iniţială. Deci cele două

tabele vor fi următoarele:

Exemple 4.2.3

Furnizori (Cod_furn, Den_furn, Cod_fiscal)

Cheltuieli (Cod_furn, Cod_chelt, Data, Den_chelt, Valoare)

Cele două tabele astfel create sunt în 1NF:

Cheltuieli

Cod_furn. Cod_chelt Data Den_chelt Valoare

F100 C15 30.06.99 Incalzire 1500000

F100 2 C16 30.06.99 Apa calda 500000

F110 3 C10 30.06.99 Iluminat 3000000

F110 4 C11 30.06.99 Lift 200000

Furnizori

Cod_furn Den_furn Cod_fiscal

F100 Romgaz R1234567

Page 96: Baze de date_Iacob

95

F110 Renel R7654321

Relaţiile Cheltuieli şi Furnizori, create prin metoda a doua de normalizare.

Pentru a demonstra trecerea la forma normală doi şi mai departe, vom folosi relaţia

Furnizori_Cheltuieli, prezentata în exemplul 4.2.2.

Forma Normală Doi (2NF)

Forma normală doi se obtine utilizand conceptul de dependenţă funcţională totală.

Dependenţa funcţională totală. Dacă A este un subset de doua sau mai multe atribute şi B

este atribut (sau subset de atribute) al aceleiasi relaţii, spunem ca B este total dependent

funcţional de grupul de atribute A, dacă B este dependent funcţional de A, dar nu este

dependent funcţional de nici un subset de atribute din A.

Exemple 4.2.4

De exemplu să luăm următoarea dependenţă funcţională:

Cod_chelt, Cod_furn, Data Valoare

Dependenţa funcţională este totala pentru ca Valoare nu depinde functional de

nici un subset de atribute al grupului Cod_chelt, Cod_furn, Data.

Forma normală doi trebuie verificată doar la relaţiile care au cheie compusă pe poziţie

de cheie primară. Relaţia la care cheia primară se compune dintr-un singul atribut, este în 2NF

daca este in 1NF.

Forma Normală Doi (2NF). O relaţie este în forma normală doi, dacă este în forma normală

unu şi fiecare atribut care nu aparţine cheii primare, este total dependent funcţional de cheia

primară.

Vom demonstra aducerea la forma normală doi, folosind relaţia Furnizori_Cheltuieli.

Putem trece la forma normală doi prin ştergerea atributelor care nu depind total de cheia

primară şi trecerea lor într-o altă tabelă împreună cu determinantul lor. După efectuarea

acestor transformări, vom obtine următoarele relaţii:

Exemple Relatia Cheltuieli:

Cod_furn. Cod_chelt Data Valoare

F100 C15 30.06.99 1500000

F100 C16 30.06.99 500000

F110 C10 30.06.99 3000000

F110 C11 30.06.99 200000

Relaţia Furnizori:

Cod_furn Den_furn Cod_fiscal

F100 Romgaz R1234567

F110 Renel R7654321

Relatia Tip_cheltuiala:

Cod_Chelt Den_chelt C15 Incalzire

C16 Apa calda

C10 Iluminat

C11 Lift

Figura 5.5. Relaţiile rezultate după trecerea la 2NF a relaţiei

Furnizori_Cheltuieli.

Relaţiile rezultate au următoarele scheme de relatie:

Furnizori = (Cod_furn., Den_furn, Cod_fiscal)

Page 97: Baze de date_Iacob

96

Tip cheltuială = (Cod_Chelt., Den_chelt)

Cheltuieli = (Cod_furn, Cod_chelt, Data, Valoare)

Forma Normală Trei (3NF)

Forma normală doi chiar dacă nu conţine atâta redundanţă ca forma normală unu,

totuşi există cazuri în care pot apărea anomalii la actualizare. Aceste anomalii apar din cauza

redundanţei generate de dependenţa tranzitivă.

Dependenţă tranzitivă. Dacă atributele A, B, C sunt în relaţiile AB şi BC, atunci

spunem că atributul C este dependent tranzitiv de atributul A, via B.

Forma Normală Trei (3NF). Spunem ca o relaţie este în formă normala trei daca este deja in

forma normală doi şi nici un atribut care nu aparţine cheii p rimare nu este tranzitiv dependent

de cheia primara.

În cazul existenţei dependenţei tranzitive, ştergem coloanele care sunt tranzitiv

dependente de cheia primară şi creăm o relaţie nouă cu aceste coloane, împreună cu

determinantul lor, adică cheia primară.

Examinând relaţiile în forma normală de mai sus, observăm că nu există dependenţe

tranzitive. Deci relaţiile sunt în formă normală trei.

Exemple

Să considerăm tabela cu schema:

Carte=(cod_car,titlu,cod_dom,denumire_domeniu)

Cheia este cod_car.

Avem depemdenţele funcţionale:

cod_car cod_dom

cod_car titlu

cod_dom denumiredomeniu

vedem că dependeţa lui denumire_domeniu de cod_car este tranzitivă (via

cod_dom)

Descompunerea acestei scheme pentru a ajunge la formă normală trei este:

Carte=(cod_car,titlu,cod_dom)

Cu cheia cod_car.

Domenii=( cod_dom,denumire_domeniu)

Cu cheia cod_dom.

Forma Normală Boyce-Codd (BCNF)

Baza de date trebuie proiectată astfel încât să nu conţină dependenţe parţiale sau

tranzitive, pentru că altfel ne putem confrunta cu anomaliile descrise la inceputul capitolului.

Forma normală Boyce-Codd se obtine utilizand cheile candidat din relaţie. O relaţie cu o

singură cheie candidat în formă normală trei este şi în formă normală Boyce -Codd.

Forma normală Boyce-Codd (BCNF). Spunem ca o relaţie este în forma normală Boyce-

Codd dacă şi numai dacă orice determinant din relaţie este cheie candidat.

Să căutăm determinanţii din exemplul de mai sus:

Cod_furn Den_furn, Cod_fiscal

Cod_chelt Den_chelt

Cod_furn, Cod_chelt, Data Valoare

Page 98: Baze de date_Iacob

97

Toţi cei trei determinanţi sunt şi chei candidat in relatiile lor. Deci relatiile din

exemplul de mai sus sunt în formă normală Boyce-Codd. Relaţiile în formă normală trei sunt

în general şi în formă normală Boyce-Codd. În cazul în care relaţia nu este în formă normală

Boyce-Codd, trecerea la BCNF se realizează prin ştergerea din relaţia iniţială a atributelor

care sunt asociate unui determinant care nu este cheie candidat şi crearea unei noi relaţii cu

aceste atribute şi determinantul lor.

Există situaţii când este foarte greu de descompus relatiile, ca să ajungem la BCNF. În

aceste situaţii este indicata rămânerea la forma normală trei.

M4.U4.2. Rezumat

Forma Normală Unu (1NF)

Trebuie să căutăm toate intersecţiile de linii şi coloane, unde există repetiţii.

Aceste repetiţii se pot elimina prin două madalităţi:

Crearea de noi înregistrări pentru fiecare valoare a repetiţiei, după care se caută

o nouă cheie primară.

Ştergerea atributelor care conţin repetiţii şi crearea de noi relaţii care vor

conţine atributele şterse, precum şi cheia primara din relaţia iniţială.

Forma Normală Doi (2NF)

Se caută dependenţele totale de cheia primara, adică toate atributele care depind

funcţional de un subset de atribute a cheii primare. Dacă cheia primară este

compusă dintr-un singur atribut, atunci relaţia este în forma normală doi, daca

este deja in forma normala unu. Dacă există dependenţe partiale, ştergem

atributele care depind parţial de cheia primara şi creăm o relaţie nouă care să se

compună din atributele şterse împreună cu determinantul lor.

Forma Normală Trei (3NF)

Pentru a trece la forma normală trei, trebuie să eliminăm dependenţele tranzitive.

Eliminarea se realizează prin ştergerea câmpurilor dependente tranzitiv de cheia

primară din relaţia iniţială şi crearea unei noi relaţii cu aceste atribute şi

determinantul lor.

Forma Normală Boyce-Codd (BCNF)

Cerinţa la forma normală Boyce-Codd este ca fiecare determinant din relaţie să

fie cheie candidat. În cazul în care nu este îndeplinită această cerinţă, vom şterge

atributele dependente funcţional de determinantul care nu este cheie candidat şi

creăm o nouă relaţie în care să avem atributele şterse şi determinantul lor. În

unele cazuri trecerea la forma normală Boyce-Codd complică foarte mult baza de

date, caz în care este de preferat rămânerea la forma normală trei.

Page 99: Baze de date_Iacob

98

M4.U4.2. Test de autoevaluare a cunoştinţelor

4.2.1) Aduceţi la forma normală 1 urmărtoarea tabelă:

Relaţia Furnizori_Cheltuieli:

Cod

Furn.

Denumire Cod

fiscal

Nr.

Crt.

Cod

Chelt.

Denumire

Cheltuială

Valoare

F100 Romgaz R1234567 1 C15 Chelt pt.

Încălzire

1500000

2 C16 Chelt pt.

Bucătării

500000

F110 Renel R7654321 3 C10 Chelt cu

iluminatul

3000000

4 C11 Chelt pt.

Func. liftului

200000

4.2.2 Aduceţi la forma normală 2 schema:

(Cod Furn., Denumire, Cod fiscal, Cod Chelt., Denumire cheltuială, Nr. Crt., Cod,

Valoare)

4.2.3 Aduceţi la forma normală 3 schema:

carte = (c_carte, titlu, cod_domeniu, den_domeniu)

4.2.4 Aduceţi, pe rând, la formă nprmală 1, 2 şi 3 tabela:

Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota))

Răspunsurile se găsesc la sfârşit la pag 155

Page 100: Baze de date_Iacob

99

Modulul 5. Metodologia de proiectare a bazelor de date relaţionale

Cuprins

Introducere

Obiectivele modului

U5.1 Generalităţi şi proiectarea conceptuală

U5.2 Proiectarea logica

U5.3 Proiectarea fizica

U5.4 Tranzacţii şi concurenţă

U5.5 Metode de control al concurenţei.

M5. Introducere

Metodologia de proiectare este o aproximare structurată, care utilizează

proceduri, tehnici, instrumente şi documentaţii pentru a facilita procesul de

proiectare.

Metodologia de proiectare se compune din etape, care la rândul lor se

compun din paşi, care orientează proiectantul la fiecare nivel al creării bazei de

date.

În mod obişnuit, un sistem SGBD deserveşte mai mulţi utilizatori, care accesează concurent datele din tabele. Accesul concurent al utilizatorilor este asigurat prin capacitatea de multiprogramare a sistemului de operare al calculatorului gazdă, care permite execuţia concurentă a mai multor procese. Execuţia concurentă a mai multor procese poate avea loc atât într-un sistem uniprocesor, prin partajarea (împărţirea) timpului de execuţie al procesorului între mai multe procese, cât şi într-un sistem multiprocesor în care mai multe procese pot fi executate în mod real simultan, pe mai

multe procesoare ale sistemului. Indiferent de numărul de procesoare ale sistemului, accesul concurent al mai multor utilizatori la datele memorate în tabelele unei baze de date necesită tehnici de menţinere a consistenţei (corectitudinii) şi a siguranţei datelor memorate.

M5. Obiectivele modulului

La sfârşitul acestui modul studenţii vor fi capabili să:

respecte o metodologie de proiectare

creeze modelul conceptual al unui sistem informatic

realizeze proiectul logic local

realizeze proiectul logic global

aleagă, în cunoştinţă de cauză, SGBD-ul cel mai potrivit.

Page 101: Baze de date_Iacob

100

descrie corect structura fizică a bazei de date

proiecteze cereri

proiecteze formulare

proiecteze rapoarte

construiască tranzacţii corecte

aleagă cea mai bună metodă de control al concurenţei

introducă regulile de integritate

să impună măsuri de securitate

Page 102: Baze de date_Iacob

101

Unitatea de învăţare U5.1 Generalităţi şi pro iectarea conceptuală

M5U1 Introducere

Metodologia de proiectare are o mare importanţă în ordonarea muncii grele de

proiectare a unui sistem informatic. Prima etapă, mai puţin standardizată şi care

depinde esenţial de experienţa celui care o îdeplineşte, este proiectarea

conceptuală, în care trebuie să aflăm cum funcţionează intreprinderea şi ce parte

din circuitul informaţional va fi automatizată.

M5.U1. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

respecte o metodologie de proiectare

creeze modelul conceptual al unui sistem informatic

Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

În orice domeniu folosirea unei metodologii are o mare importanţă. O metodologie

este o cale de a apllica în proiectare metoda divide et impera. Separarea în paşi asigură

divizarea problemei iniţiale în probleme mai mici şi deci mai uşor de rezolvat, iar partea de

impera este rezolvată de succesiunea strictă a paşilor şi de faze speciale cum ar fi, în cazul

nostru, realizarea modelului logic global. Un alt avantaj îl constitue faptul că la terminarea

activităţii de proiectare, avem o mare parte din documentaţia proiectului realizată. De

asemenea urmărirea uinei metodologii face posibil lucru în echipă prin divizarea sarcinilor ţi

posibibilitatea urmăririi stadiului la care s-a ajuns.

Paşii mari ai metodologiei pe care o prezentăm aici sunt proiectarea logică şi

proiectarea fizică.

Definiţie: Proiectare logică: Procesul de construcţie a unui model de informaţii folosite într-o

întreprindere, bazată pe modelul de date, dar independent de particularizările sistemului de

gestiune a bazei de date şi a altor considerente fizice.

Proiectarea logică începe cu crearea modelului conceptual al bazei de date, care este

independent de implementarea într-un SGBD. Modelul conceptual este apoi proiectat pe un

model logic, care va influenţa mai târziu modelul de date în care se va implementa.

Definiţie: Proiectare fizică: Este procesul de descriere a implementării bazei de date

într-un SGBD.

În această etapă a proiectării este creată baza de date într-un SGBD, împreună cu

procedurile de actualizare. În această etapă există un feedback între proiectarea fizică şi cea

logică, pentru că deciziile luate la implementarea fizică pot afecta baza de date logice. Pe parcursul activităţii de proiectare trebuie să fie satisfăcute mai multe cerinţe, multe dintre ele fiind

contradictorii şi dificil de îndeplinit: obţinerea unu i timp de răspuns la interogări cât mai mic, şi, în

acelaşi timp, utilizarea unui spaţiu de memorare cât mai redus; asigurarea unui mod de acces la date

cât mai simplu dar intuitiv, etc.

Page 103: Baze de date_Iacob

102

Problema proiectării bazelor de date este complicată şi de faptul că, de cele mai multe ori,

procesul de proiectare începe cu cerinţe foarte generale şi imprecis formulate. Prin contrast, proiectul

rezultat trebuie să conţină schema bazei de date precis definită, dat fiind că, după implementarea

aplicaţiilor, modificarea bazei de date este mult mai dificilă. Terminologia folosită în domeniul proiectării bazelor de date este destul de variată, existând şi

unele ambiguităţi privind denumirile etapelor sau ale tipurilor de scheme ale bazelor de date. Cel mai

frecvent, pentru proiectul conceptual al unei baze de date se folosesc denumirile de schemă

conceptuală de nivel înalt sau schemă conceptuală independentă de SGBD sau, chiar mai simplu,

schemă conceptuală. Proiectul logic al unei baze de date este denumit schemă logică sau schemă

conceptuală dependentă de SGBD în cele mai multe lucrări din domeniul proiectării bazelor de date. Înainte de a se proiecta efectiv o bază de date, este necesar să se cunoască ce rezultate se aşteaptă

utilizatorii potenţiali să obţină de la baza de date respectivă şi ce informaţii primare sunt disponibile

pentru aceasta. De asemenea, este necesar să se cunoască ce aplicaţii se vor efectua (aplicaţii de gestiune

a stocurilor, aplicaţii contabile, aplicaţii de urmărire a consumurilor, aplicaţii de salar izare, etc.). În general, în această fază de colectare şi analiză a cerinţelor, se desfăşoară următoarele activităţi:

• Identificarea grupurilor de utilizatori potenţiali si a aplicaţiilor. De regulă, persoana cea mai avizată din cadrul fiecărui grup de utilizatori este cooptată ca participant în activităţile ulterioare de colectare şi analiză a cerinţelor.

• Revederea documentaţiei existente privind aplicaţiile dorite, în afară de documentaţiile

aplicaţiilor dorite se studiază şi alte documentaţii şi interviuri. Se colectează

răspunsuri scrise de la utilizatorii potenţiali la diferite seturi de întrebări şi se

organizează interviuri cu persoanele care reprezintă diferitele grupuri de utilizatori,

în felul acesta, proiectanţii pot înţelege care sunt priorităţile de proiectare a

bazei de date, importanţa diferitelor aplicaţii şi performanţele dorite de la acestea.

Toate aceste activităţi oferă informaţii slab(diagramele de organizare a întreprinderii, formularele existente de introducere a datelor, rapoartele utilizate în controlul activităţii respective, etc.), pentru a se decide dacă aceste aspecte influenţează cerinţele bazei de date.

• Analiza mediului de operare şi a cerinţelor de prelucrare a datelor. Această activitate include analiza fluxului de informaţii în cadrul sistemului, precum şi analiza tipurilor de tranzacţii şi a frecventei de lansare a acestora. Deosebit de

importantă este şi stabilirea volumului de date conţinute în mod tipic de baza de date, a volumului şi frecvenţei datelor actualizate precum şi a volumului datelor retumate de interogări şi a frecvenţei acestora.

Chestionare structurate, în general în limbaj natural, pe baza cărora se pot construi diagrame, tabele, grafice, etc., manual sau folosind diferi te instrumente software de proiectare. Această fază este puternic consumatoare de timp, dar este crucială pentru succesul sistemului informatic.

Page 104: Baze de date_Iacob

103

Prezentarea metodologiei

Prima dată să vedem care sunt paşii de urmat în proiectare:

Pasul 1. Proiectarea logică a bazei de date relaţionale: Crearea unui model conceptual

local, pentru vederile utilizatorilor.

Pasul 1.1. Identificarea tipurilor de entităţi.

Pasul 1.2. Identificarea tipurilor de relaţii.

Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi tipurile de

relaţii.

Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.

Pasul 1.5. Determinarea atributelor care compun cheile candidate şi primare.

Pasul 1.6. Specializare/generalizare (pas opţional).

Pasul 1.7. Desenarea diagramei entity-relationship.

Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.

Pasul 2. Crearea şi validarea modelului logic local.

Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.

Pasul 2.2. Crearea relaţiilor pentru modelul logic local.

Pasul 2.3. Validarea modelului, utilizând normalizarea.

Pasul 2.4. Validarea modelului din nou, utilizând tranzacţiile.

Pasul 2.5. Desenarea diagramei ER.

Să ne reamintim...

O metodologie este o cale de a apllica în proiectare metoda divide et

impera. Separarea în paşi asigură divizarea problemei iniţiale în probleme mai

mici şi deci mai uşor de rezolvat, iar partea de impera este rezolvată de

succesiunea strictă a paşilor şi de faze speciale cum ar fi, în cazul nostru,

realizarea modelului logic global.

Paşii mari ai metodologiei pe care o prezentăm aici sunt proiectarea

logică şi proiectarea fizică. Problema proiectării bazelor de date este complicată şi de faptul că, de cele mai

multe ori, procesul de proiectare începe cu cerinţe foarte generale şi imprecis formulate.

Prin contrast, proiectul rezultat trebuie să conţină schema bazei de date precis definită.

Înainte de a se proiecta efectiv o bază de date, este necesar să se cunoască ce

rezultate se aşteaptă utilizatorii potenţiali să obţină de la baza de date respectivă şi ce

informaţii primare sunt disponibile pentru aceasta.

în această fază de colectare şi analiză a cerinţelor, se desfăşoară următoarele activităţi:

• Identificarea grupurilor de utilizatori potenţiali si a aplicaţiilor.

• Revederea documentaţiei existente privind aplicaţiile dorite

• şi interviuri.

• Toate aceste activităţi oferă informaţii slab(diagramele de organizare a întreprinderii, formularele existente de introducere a datelor, rapoartele utilizate în controlul activităţii respective, etc.), pentru a se decide dacă aceste aspecte influenţează cerinţele bazei de date.

• Analiza mediului de operare şi a cerinţelor de prelucrare a datelor.

Page 105: Baze de date_Iacob

104

Pasul 2.6. Definirea regulilor de integritate a bazei de date.

Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.

Pasul 3. Crearea şi validarea modelului logic global de date.

Pasul 3.1. Compunerea medelelor logice locale într-un model logic global.

Pasul 3.2. Validarea modelului logic global.

Pasul 3.3. Verificarea posibilităţii de a completa baza de date în viitor.

Pasul 3.4. Desenarea diagramei ER finale.

Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.

Pasul 4. Proiectarea fizică şi implementarea bazei de date relaţionale: Translatarea

modelului logic global în SGBD.

Pasul 4.1. Proiectarea relaţiilor de bază în SGBD.

Pasul 4.2. Crearea regulilor de integritate în SGBD.

Pasul 5. Proiectarea şi implementarea reprezentării fizice.

Pasul 5.1. Analizarea tranzacţiilor.

Pasul 5.2. Alegerea organizării fişierelor.

Pasul 5.3. Alegerea indecsilor secundari.

Pasul 5.4. Introducerea unei redundanţe comntrolate.

Pasul 5.5. Estimarea spaţiului pe disc.

Pasul 6. Proiectarea şi implementarea unui mechanism de securitate.

Pasul 6.1. Crearea view-urilor pentru utilizatori.

Pasul 6.2. Proiectarea regulilor de acces la baza de date.

Pasul 7. Verificarea sistemului operaţional.

Proiectarea logică a bazei de date se divide în trei paşi mari. Primul pas are ca

obiectiv, descompunerea proiectării sistemului informatic în vederi, care se pot discuta cu

utilizatorii sistemului. Modelul de date astfel creat, se validează prin normalizare şi prin

tranzacţii în pasul doi. În final, se generează modelul global al întreprinderii, care este la

rândul lui validat şi verificat cu ajutorul utilizatorului sistemului.

Factori critici pentru succesul proiectării logice:

Lucrul interactiv cu utilizatorul sistemului.

Folosirea unei metodologii structurate pentru procesul de proiectare a bazei de date.

Încorporarea regulilor de integritate în modelul logic de date.

Combinarea validării conceptuale, prin normalizare şi prin tranzactii, la proiectarea

modelului logic de baze de date.

Utilizarea diagramelor pentru a reprezenta cât mai multe modele logice posibile.

Crearea dicţionarului de date, ca supliment al modelului de date.

Crearea modelului logic

Pasul 1. Crearea modelului conceptual local, pentru utilizatori.

Deşi nu este obligatoriu, această fază se poate menţine independentă de SGBD şi produce un model de date de nivel înalt, care va fi implementat după transpunerea lui într-un model de date specific. Chiar dacă proiectanţii pot porni direct cu scheme conceptuale specifice unui anumit SGBD

(care se mai numesc şi scheme logice), este totuşi recomandabil să se realizeze mai întâi schema conceptuală de nivel înalt independentă de SGBD, datorită u rmătoarelor motive:

• Scopul proiectării schemei conceptuale este înţelegerea cât mai completă a structurii bazei de date, a asocierilor şi a constrângerilor de către proiectanţi şi programatori. Acest deziderat se obţine mult mai bine independent de un anumit SGBD, deoarece un model de date de nivel înalt este mult mai general şi mai expresiv, în timp ce fiecare SGBD

Page 106: Baze de date_Iacob

105

are propriile restricţii şi soluţii particulare, care nu trebuie să influenţeze proiectul schemei conceptuale.

Obiectivul: Crearea unui model conceptual local, pentru view-urile utilizatorilior.

Primul pas în proiectarea bazei de date este de a colecta datele necesare pentru

realizarea sistemului, ceea ce putem culege, discutând cu viitorii utilizatori ai bazei de date.

Acrastă discuţie presupune o despărţire în vederi, a bazei de date, vederi care pot lucra

separat.

Despărţirea în vederi se poate realiza în mai multe moduri. O modaliate ar fi analiza

datelor globale şi găsirea de părţi relativ independente. O altă modalitate ar fi analiza

rapoartelor, procedurilor cerute şi/sau observarea sistemului existent în lucru.

Modelele conceptuale locale trebuie să conţină:

tipuri de entităţi,

tipuri de relaţii,

atribute,

domeniile atributelor,

cheile candidat,

chei primare

Paşii din prima etapă a proiectării logice sunt:

Pasul 1.1. Identificarea tipurilor de entităţi.

Pasul 1.2. Identificarea tipurilor de relaţii.

Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi tipurile de

relaţii.

Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.

Pasul 1.5. Determinarea atributelor care compun cheile candidate şi primare.

Pasul 1.6. Specializare/generalizare (pas opţional).

Pasul 1.7. Desenarea diagramei entity-relationship.

Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.

Pasul 1.1. Identificarea tipurilor de entităţi

Obiectivul: Identificarea tipurilor de entităţi principale în vederile utilizatorilor.

Primul pas în proiectarea bazei de date este identificarea entităţiilor din datele

furnizate de utilizatori. De exemplu, dacă avem informaţiile Nr_Mat, Nr_Bloc, Scara, Etaj,

Apartament şi Nume, putem identifica entitatea Locatari. În general putem identifica

entităţiile în mai multe moduri. De exemplu în locul entităţii Locatari, am putea crea o entitate

Locatari cu atributele Nr_Mat şi Nume, iar celelelte informaţii în entitatea

ProprietateLocatari.

Există cazuri când entităţiile sunt greu de identificat, pentru că modul de prezentare a

viitorilor utilizatori necesită explicaţii. Utilizatorii descriu aceste entităţi, folosind sinonime şi

omonime, ceea ce îngreunează identificarea entităţilor. Sinonimele prin care se descrie aceaşi

entitate, se pot considera sinonime şi la crearea modelului logic, evidenţiind aceste sinonime

ca diverse aliasuri ai entităţiilor.

Documentarea tipurilor de entităţi

După identificarea entităţiilor, le dăm câte un nume, iar aceste nume le vom evidenţia

în dicţionarul de date, împreună cu explicaţiile despre entităţi, precum şi posibilele aliasuri.

Pasul 1.2. Identificarea tipurilor de relaţii

Obiectivul: Identificarea relaţiilor importante dintre entităţi.

După identificarea entităţiilor, va trebui să identificăm şi relaţiile importante dintre

aceste entităţi. Relaţiile se descriu printr-un verb al relaţiei. De exemplu:

Page 107: Baze de date_Iacob

106

Exemple

Scările sunt Locuite de Locatari

Furnizorii Provoacă Cheltuieli

Descrieţi, printr-un verb al relaţiei, relaţia dintre student şi facultate.

Descrieţi, printr-un verb al relaţiei, relaţia dintre student şi note.

La identificarea relaţiilor vom lua în considerare doar relaţiile care ne interesează.

Degeaba există şi alte relaţii care să se poată identificate, dacă nu prezintă importanţă pentru

problema noastră, atunci nu le luăm în consideraţie.

În cele mai multe din cazuri, relaţiile sunt binare, adică se realizează întrea exact două

entităţi. Există şi relaţii mai complexe, care se realizează între mai multe entităţi, sau relaţii

recursive, care pune în relaţie o singură entitate cu ea însăşi.

Determinarea cardinalităţii şi a participării la tipurile de relaţii

După identificarea tipurilor de relaţii, trebuie să determinăm cardinalitatea lor, alegând

dintre posibilităţiile: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Dacă se

cunosc valori specifice ale cardinalităţiilor, aceste valori se scriu la documentarea relaţiilor. În

continuare determinăm şi participarea la relaţie, care poate fii totală, sau parţială.

Care este cardinalitatea relaţiei dintre student şi facultate.

Care este cardinalitatea relaţiei dintre student şi note.

Documentarea tipurilor de relaţii

După identificarea tipurilor de relaţii, le denumim şi le introducem în dicţionarul de

date, împreună cu cardinalitatea şi participarea lor.

Utilizarea modelării ER

Pentru vizualizarea sistemelor complicate, utilizăm diagrama ER, pentru că este mult

mai uşor de a cuprinde toate informaţiile. Vă propunem ca să utilizaţi întotdeauna diagrama

ER, pentru o mai bună vizualizare a datelor.

Pasul 1.3. Identificarea şi asocierea de atribute la tipurile de entităţi şi tipurile de

relaţii

Obiectivul: Asocierea de atribute la tipurile de entităţi şi la tipurile de relaţii.

Următorul pas în metodologie este identificarea atributelor. Aceste atribute se

identifică în aceeaşi mod ca şi entităţiile. Pentru o mai uşoară identificare, trebuie să luăm

entităţiile şi relaţiile ra rând şi să ne punem următoarea întrebare: Ce informaţii deţinem

despre această … ? Răspunsul la această întrebare ne va da atributele căutate.

Atribute simple sau compuse

Este important să notăm dacă un atribut este simplu sau compus. Conform acestei

informaţii va trebui să luăm decizii referitoare la acel atribut. Dacă un atribut este compus,

atunci putem opta pentru descompunerea sa, dacă este necesară prelucrarea separată a detelor

compuse, sau putem să-l lăsăm compus în caz contrar.

Exemple

De exemplu, atributul Adresă conţine informaţiile (Nr_Bloc, Scara, Etaj,

Apartament). Noi va trebui să prelucrăm aceste informaţii separat, deci vom

descompune acest atribut în cele patru atribute simple.

Descompuneţi atributul adresă din tabela student.

Page 108: Baze de date_Iacob

107

Putem avea cazuri în care atributele simple să le compunem.

Exemple

De exemplu în cazul atributelor Nume_Familie şi Prenume, neavând nevoie de

aceste informaţii separat, le vom compune în atributul Nume.

Ce puteţi spune despre atributul nume din tabela student.

Atribute derivate (calculate)

Sunt acele atribute, care se pot calcula din alte atribute existente în baza de date.

Exemple

De exemplu numărul locatarilor de pe o scară se poate număra în tipul de entitate

Locatari. Deci acest atribut este atribut derivat.

Ce puteţi spune despre atributul vârsta din tabela student.

În general aceste atribute nu trebuie incluse în modelul de date, pentru că în cazul în

care se modifică atributul din care se calculează atributul derivat, trebuie să se modifice şi

acesta. În cazul în care nu se modifică, baza de date devine inconsistentă. De aceea este

important de a menţiona dacă un atribut este sau nu derivat.

Dacă identificăm un atribut care să nu-l putem asocia nici unei entităţi sau relaţii, ne

întoarcem la paşii anteriori, identificând noua relaţie sau entitate la care să asociem atributul

respectiv.

În cazul în care putem asocia acelaşi atribut la mai multe entităţi, atunci va trebui să

decidem dacă generalizăm sau nu aceste entităţi, proces care este descris la pasul 1.6.

Documentarea atributelor

După identificarea atributelor, le asociem un nume, şi le înregistrăm în dicţionarul de

date, împreună cu următoarele informaţii:

numele şi descrierea atributului,

toate aliasurile şi sinonimele prin care este cunoscut atributul,

tipul de date şi lungimea,

valorile iniţiale ale atributelor (dacă există),

dacă atributul acceptă sau nu valoarea nulă,

dacă atributul este sau nu compus, şi dacă este atunci atributele simple care îl compun,

dacă atributul este sau nu derivat şi atributul din care derivă,

dacă atributul acceptă sau nu mai multe valori.

Pasul 1.2. Determinarea domeniului atributelor

Obiectivul: Determinarea domeniului atributelor în modelul conceptual local.

Domeniul atributului este o mulţime de valori pe care o poate lua. Pentru a controla în

totalitate domeniul atributelor, se poate evidenţia următoarele:

setul de valori admisibile pentru un atribut,

operaţiile admisibile asupra unui atribut,

Page 109: Baze de date_Iacob

108

ce atribute se pot compara cu atributul respectiv, în combinaţiile cu alte atribute,

mărimea şi formatul câmpului atributului.

Documentarea domeniilor atributelor

Actualizăm dicţionarul de date cu domeniul de definiţie al fiecărui atribut.

Pasul 1.5. Determinarea atributelor care compun cheile candidat şi primare

Obiectivul: Identificarea cheilor candidat pentru fiecare entitate şi alegerea cheilor

primare în cazul în care sunt mai multe chei candidat.

Identificarea cheilor şi selectarea cheilor primare

O cheie candidat este un atribut, sau un grup de atribute care identifică unic fiecare

înregistrare din tipul de entitate. Putem identifica una, sau mai multe chei candidat. În acest

caz trebuie să alegem dintre ele o cheie primară. Cheile candidat care nu sunt primare, se vor

numi chei alternante. Pentru alegerea unei chei ca fiind cheie primară, vom ţine cont de

următoarele:

cheia candidat, care are un număr minim de atribute,

cheia candidat, care îşi va schimba cel mai rar valoarea,

cheia candidat, care este cel mai puţin probabil să sufere modificări în viitor,

cheia candidat, care este compusă din cele mai puţine caractere (în cazul atributelor de tip

caracter),

cheia candidat, care este cel mai uşor de folosit din punctul de vedere al utilizatorului.

Care ar fi cheile candidat ale tabelei student. Care va fi cheia principală.

Prin procesul de identificare a cheilor primare, deducem şi dacă o entitate este entitate

“tare”, sau entitate “slabă”. Dacă reuşim să identificăm o cheie primară, atunci entitatea este

tare, altfel este slabă. O entitate slabă nu poate exista fără o entitate tare, care să-i fie

“părinte”. Cheia primară a entităţii slabe este derivată parţial sau total din cheia primară a

entităţii tari.

Documentarea cheilor primare şi alternante

Înscriem cheile primare şi pe cele alternante în dicţionarul de date.

Pasul 1.6. Specializarea/generalizarea tipurilor de entităţi (pas opţional)

Obiectivul: Identificarea entităţiilor subclasă respectiv superclasă, între entităţiile

apropiate.

În acest pas putem opta pentru a continua modelarea ER, folosind procesul de

generalizare sau specializare. Dacă alegem procesul de specializare, vom încerca să definim

una, sau mai multe subclase ale entităţii respective. Dacă însă alegem procesul de

generalizare, vom căuta superclase pentru acea entitate.

Un exemplu pentru procesul de generalizare ar fii entităţiile Şef_de_scară şi Familii.

Ambele entităţi au atribuite următoarele atribute: Nr_mat, Nr_bloc, Scara, Etaj, Apartament şi

Nume. Pe lângă aceste atribute, entitatea Şef_de_scară mai are asociate atributul

Data_intrare_func; iar entitatea Familii, atributele Nr_pers, Nr_pers_prezente şi Nr_chei.

Deci, cele două entităţi având atribute în comun, le putem generaliza în entitatea Locatari,

care va conţine atributele comune, şi entităţile Şef_de_scară şi Familii, conţinând doar

atributele diferite - particularizările faţă de superclasă.

Pasul 1.7. Desenarea diagramei ER.

Obiectivul: Desenarea unei diagrame ER. care va fi reprezentarea conceptuală a

vederilor utilizatorilor despre întreprindere.

În momentul acesta suntem în măsură să prezentăm o giagramă completă a modelului

bazat pe vederile utilizatorilor despre întreprindere.

Page 110: Baze de date_Iacob

109

Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului

Obiectivul: Verificarea modelului conceptual local cu ajutorul utilizatorului, pentru a

vedea dacă modelul este o reprezentare adevărată a vederii utilizatorului despre întreprindere.

Înainte de a termina pasul 1, trebuie verificat modelul conceptual elaborat. Acest

model include diagrama ER şi documentaţia anexată. În cazul în care apare orice fel de

anomalie, repetăm procesul de mai înainte şi remediem problema.

Să ne reamintim...

Paşii din prima etapă a proiectării logice sunt:

Pasul 1.1. Identificarea tipurilor de entităţi.

Pasul 1.2. Identificarea tipurilor de relaţii.

Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi

tipurile de relaţii.

Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.

Pasul 1.5. Determinarea atributelor care compun cheile candidate şi

primare.

Pasul 1.6. Specializare/generalizare (pas opţional).

Pasul 1.7. Desenarea diagramei entity-relationship.

Pasul 1.8. Verificarea modelului conceptual local cu ajutorul

utilizatorului.

M5.U5.1. Rezumat

O metodologie este o cale de a apllica în proiectare metoda divide et

impera. Separarea în paşi asigură divizarea problemei iniţiale în probleme mai

mici şi deci mai uşor de rezolvat, iar partea de impera este rezolvată de

succesiunea strictă a paşilor şi de faze speciale cum ar fi, în cazul nostru,

realizarea modelului logic global.

Paşii mari ai metodologiei pe care o prezentăm aici sunt proiectarea logică

şi proiectarea fizică. Problema proiectării bazelor de date este complicată şi de faptul că, de cele mai

multe ori, procesul de proiectare începe cu cerinţe foarte generale şi imprecis formulate.

Prin contrast, proiectul rezultat trebuie să conţină schema bazei de date precis definită.

Înainte de a se proiecta efectiv o bază de date, este necesar să se cunoască ce

rezultate se aşteaptă utilizatorii potenţiali să obţină de la b aza de date respectivă şi ce

informaţii primare sunt disponibile pentru aceasta.

în această fază de colectare şi analiză a cerinţelor, se desfăşoară următoarele activităţi:

• Identificarea grupurilor de utilizatori potenţiali si a aplicaţiilor.

• Revederea documentaţiei existente privind aplicaţiile dorite

• şi interviuri.

Page 111: Baze de date_Iacob

110

M5.U5.1. Test de autoevaluare a cunoştinţelor

5.1.1. Realizaţi paşii de proiectare conceptuala locală pentru subsistemul

didactic din facultate.

Răspunsurile se găsesc la sfârşit la pag 156

• Toate aceste activităţi oferă informaţii slab(diagramele de organizare a întreprinderii, formularele existente de introducere a datelor, rapoartele utilizate în controlul activităţii respective, etc.), pentru a se decide dacă aceste aspecte influenţează cerinţele bazei de date.

Analiza mediului de operare şi a cerinţelor de prelucrare a datelor. Paşii din prima etapă a proiectării logice sunt:

Pasul 1.1. Identificarea tipurilor de entităţi.

Pasul 1.2. Identificarea tipurilor de relaţii.

Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi

tipurile de relaţii.

Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.

Pasul 1.5. Determinarea atributelor care compun cheile candidate şi

primare.

Pasul 1.6. Specializare/generalizare (pas opţional).

Pasul 1.7. Desenarea diagramei entity-relationship.

Pasul 1.8. Verificarea modelului conceptual local cu ajutorul

utilizatorului.

Page 112: Baze de date_Iacob

111

Unitatea de învăţare U5.2 Proiectarea logică.

M5U2 Introducere

În faza de proiectare logică a unei baze de date se realizează schema conceptuală

globală şi schemele conceptuale (vederile) externe pentru sistemul SGBD ales, pornind de

la schema conceptuală şi schemele externe de nivel înalt independen te de SGBD, proiectate

în faza precedentă.

M5.U2. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

realizeze proiectul logic local

realizeze proiectul logic global

Durata medie de parcurgere acestei unităţi de învăţare este de 3 ore.

Această fază de proiectare logică poate fi realizată în două subfaze: Transpunerea schemei conceptuale în modelul de date al sistemului SGBD ales, dar

independent de sistemul de gestiune propriu-zis. în cazul modelului relaţional,

transpunerea se face prin corespondenţa dintre elementele schemei conceptuale de

nivel înalt reprezentată prin diagrama Entitate-Asociere (tipuri de entităţi, atribute,

asocieri) şi elementele modelului relaţional (relaţii, atribute, referinţe). Se obţine un

proiect logic dependent de modelul de date, dar independent de sistem, în această

subfazâ se face şi analiza normalizării relaţiilor, normalizarea fiecărei relaţii până la

nivelul adecvat şi documentarea tuturor dependenţelor de date care nu

sunt determinate de chei ale relaţiilor (necesară pentru proiectarea procedurilor de

verificare şi impunere a dependenţelor respective).

Rafinarea schemei conceptuale şi a schemelor externe obţinute anterior, astfel

încât să se utilizeze unele (sau cât mai multe) din facilităţile oferite de sistemul

SGBD ales (modul de generare a cheilor primare, definirea constrângerilor, etc.). Rezultatul acestei faze de proiectare îl constituie schema conceptuală şi schemele externe

ale bazei de date, dependente de sistemul SGBD ales şi de modelul de date al acestuia.

Pasul 2. Crearea şi validarea modelului logic local

Obiectivul: Crearea unui model logic local bazată pe modelul conceptual al

utilizatorilor asupra întreprinderii şi validarea ei prin procesul de normalizare şi prin tehnica

tranzacţiilor cerute.

În acest pas verificăm modelul conceptual creat în pasul anterior şi eliminăm din el

structurile care sunt dificil de realizat într-un SGBD. Dacă la sfârşitul acestui proces modelul

ete alterat, vom corecta aceste probleme şi ne vom referi în continuare la modelul rezultat, ca

fiind modelul logic local. Vom valida modelul logic prin procesul de normalizare şi a

tranzacţiilor.

Activităţile din acest pas sunt:

Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.

Pasul 2.2. Crearea relaţiilor pentru modelul logic local.

Page 113: Baze de date_Iacob

112

Pasul 2.3. Validarea modelului, utilizând normalizarea.

Pasul 2.2. Validarea modelului din nou, utilizând tranzacţiile.

Pasul 2.5. Desenarea diagramei ER.

Pasul 2.6. Definirea regulilor de integritate ale bazei de date.

Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.

Pasul 2.1. Proiectarea modelului conceptual local pe modelul logic local

Obiectivul: Verificarea modelului conceptual local pentru eliminarea structurilor care

se pot implementa greu într-un SGBD şi proiectarea modelului rezultat la modelul logic local.

În pasul întâi am pregătit un model conceptual bazat pe informaţiile date de utilizator.

Acest model trebuie prelucrat, pentru a putea fi uşor de prelucrat de sistemul de gestiune a

bazelor de date. Obiectivele acestui pas sunt:

(1) Eliminarea relaţiilor M:N.

(2) Eliminarea relaţiilor complexe.

(3) Eliminarea relaţiilor recursive.

(4) Eliminarea relaţiilor cu atribute.

(5) Reexaminarea relaţiilor 1:1.

(6) Eliminarea relaţiilor redundante.

(1) Eliminarea relaţiilor multe-la-multe

Dacă în modelul de date apar relaţii de tipul multe-la-multe (M:N), trebuie

descompuse în două relaţii unu-la-multe (1:M) prin adăugarea unei noi entităţi suplimentare.

Exemple

De exemplu, pot exista mai multe cheltuieli pentru o scară, dar şi o cheltuială

(factură) poate să se refere la mai multe scări. Deci relaţia dintre entitatea Scări şi

entitatea Cheltuieli este de M:N, ceea de este evidenţiat în figură.

Sunt platite de

ScariNr_BlocScara

Lift

CheltuieliNr_Crt

Cod_Cheltuiala (FK)Cod_Furnizor (FK)Nr_facturaData_facturaValoare_factura

Se calculeazaAu cheltuieli

Pe scariScara (FK)Nr_Crt (FK)Nr_Bloc (FK)

CheltuieliNr_Crt

Cod_Furnizor (FK)Cod_cheltuialaNr_facturaData_facturaValoare_factura

ScariNr_BlocScara

Lift

a). Relaţie de tipul N:M. (b). Relaţie transfornamtă în două relaţii 1:M.

Page 114: Baze de date_Iacob

113

Desfiinţaţi relaţia dintre student şi note.

Această relaţie se poate elimina, prin crearea unui tip de entitate suplimentar,

care să facă legătura dintre scări şi cheltuieli. Diagrama acestor relaţii se vede în figura b).

Notăm, că tipul de entitate nou creat - Pe_scări - este tip de entitate slabă, pentru că

depinde atît de tipul de entitate Scări, cât şi de tipul de entitate Cheltuieli.

(2) Eliminarea relaţiilor complexe

O relaţie complexă este o relaţie între mai mult de couă tipuri de entităţi. Dacă în

modelul conceptual apar relaţii complexe, acestea trebuie eliminate. Se pot elimina prin

crearea unui nou tip de entitate, care să fie în relaţie de tipul 1:M cu fiecare tip de entitate din

relatia iniţială, partea cu M a relaţiei fiind spre tipul de entitate nou creat.

(3) Eliminarea relaţiilor recursive

Relaţiile recursive sunt nişte relaţii particulare, prin care un tip de entitate este în

relaţie cu el însuşi. Dacă apare o astfel de relaţie în modelul conceptual, ea trebuie eliminată.

Eliminarea se poate rezolva prin crearea unei noi entităţi unde să se evidenţieze fiecare

entitate care este legată de entitatea din tipul de entitate iniţial. În acest caz vom avea o relaţie

de tipul 1:M între tipul de entitate iniţial şi tipul de entitate nou creat şi o relaţie de tipul 1:1

între tipul de entitate nou creat şi tipul de entitate iniţial.

(4) Eliminarea relaţiilor cu atribute

Dacă în modelul conceptual avem relaţie cu atribute, putem descompune această

relaţie, identificând un nou tip de entitate în care să înregistrăm atributele necesare.

(5) Reexaminarea relaţiilor de tipul 1:1

În modelul conceptual putem avea entităţi între care să avem relaţie de tipul 1:1. Se

poate întâmpla ca aceste entităţi să fie de fapt aceeaşi entitate cu nume diferite. Dacă suntem

în acest caz, unim cele două entităţi, cheia primară devenind cheia primară al uneia dintre

entităţi.

(6) Eliminarea relaţiilor redundante

O relaţie este redundantă dacă se poate ajunge de la un tip de entitate la alt tip de

entitate pe mai multe drumuri. Vă amintim că noi vrem să ajungem la un model minimal şi

deci relaţiile redundante nu sunt necesare. Decizia că o relaţie este redundantă trebuie să fie

precedată de o analiză amănunţită a relaţiilor care compun cele două drumuri dintre cele două

entităţi, pentru că pot apărea situaţii, când o relaţie este aparent redundantă, dar în realitate

este nevoie de ea.

În finalul acestui pas putem spune că am eliminat din modelul conceptual acele

structuri care sunt dificil de implementat şi deci este mai corect ca în continuare să ne referim

la acest model ca fiind un model logic local de date.

Pasul 2.2. Crearea de relaţii peste modelul logic local

Obiectivul: Crearea de relaţii peste modelul logic.

Relaţia pe care un tip de entitate o are cu alt tip de entitate este reprezentată prin

mecanismul cheie primară/cheie străină. Cheia străină pentru o entitate este reproducerea

cheii primare a altei entităţi. Pentru a decide entităţiile unde vom include copia cheii primare a

altei entităţi, trebuie înainte să identificăm entităţile “părinte” şi “fiu”. Entităţile “părinte” se

referă la acele entităţi ale căror chei primare se vor copia în entităţile “fiu”.

Pentru descrierea relaţiilor vom folosi un limbaj de definire a bazei de date (Database

Definition Language - DDL). În acest limbaj, specificăm prima dată numele entităţii, urmat de

atributele asociate între paranteze. După aceea identificăm cheia primară şi toate cheile

alternante, precum şi/sau cheile străine.

Page 115: Baze de date_Iacob

114

Tipuri de entitaţi tari

Pentru tipurile de entităţi tari în modelul logic crearea unei relaţii include toate

atributele entităţii. Pentru atributele compuse al unei entităţi, vom include numai atributele

simple din compunerea atributului compus în descrierea entităţii.

Exemple

De exemplu tipul de entitate Familii, prezentată în figură se descrie în următorul

mod.

Familii (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers,

Nr_pers_prezente, Nr_chei)

Cheie primară: Nr_mat

Descrieţi relaţia dintre student şi catalog.

Tipurile de entităţi slabe

Descrierea tipurilor de entităţi slabe se face la fel ca şi tipurile de entităţi tari, cu o

completare şi anume, evidenţierea cheii străine.

Exemple

De exemplu descrierea tipului de entitate de mai sus se descrie astfel:

Plăţi (Data, Nr_mat, Valoare, Restanţă)

Cheie primară: Data, Nr_mat

Cheie străină: Nr_mat se referă la Familii(Nr_mat)

Descrieţi tabela catalog.

Menţionăm că în cazul acesta cheia străină este şi în compunerea chei primare. Deci

înainte de introducerea cheii străine, cheia primară nu identifica unic o entitate. La terminarea

acestui pas, putem identifica cheile prinare pentru toate tipurile de entităţi din modelul logic.

Tipurile de relaţii binare de tipul unu-la-unu (1:1)

Pentru fiecare tip de relaţie binară de tipul 1:1 între două tipuri de entitate E1 şi E2

găsim o copie a cheii primare a tipului de entitate E1 în compunerea tipului de entitate E2, sub

denumirea de cheie străină. Identificarea tipului de entitate “părinte” şi a tipului de entitate

“fiu” depinde de participarea entităţilor la relaţie. Tipul de entitate care participă parţial la

relaţie este desemnat ca fiind “părinte” iar cel cu participare totală “fiu”. Dacă ambele tipuri

de entitate participă parţial sau total la relaţie, atunci tipurile de entităţi se pot evidenţia ca

fiind “părinte” sau “fiu” arbitrar. În cazul în care participarea este totală, putem încerca să

combinăm cele două tipuri de entităţi într-una singură. Această compunere poate să fie

posibilă în cazul în care nici unul dintre cele două tipuri de entităţi nu mai ia parte la altă

relaţie.

Tipurile de relaţii binare de tipul unu-la-multe 1:M

Pentru toate relaţiile 1:M între două entităţi E1 şi E2 în modelul logic de date, vom

avea copia cheii primare a entităţii E1 în compunerea entităţii E2. Totdeauna entitatea de

partea unu a relaţiei este considerată entitate “părinte”, iar cealaltă entitate “fiu”.

Atributele cu mai multe valori

Page 116: Baze de date_Iacob

115

Pentru ficarea atribut A care permite mai multe valori din entitatea E1 în modelul

logic de date, creăm o nouă relaţie care va conţine atributul A împreună cu cheia primară a

entităţii E1 pe post de cheie străină. Cheia primară a noii relaţii va fi atributul A, sau dacă este

necesar, compunerea ei cu cheia primară al lui E1.

Documentarea relaţiilor şi a atributelor din cheile străine

Actualizăm dicţionarul de date, întroducând fiacare atribut nou introdus în

compunerea unei chei la acest pas.

Pasul 2.3. Validarea, utilizând normalizarea

Obiectivul: Validarea modelului logic, utilizând tehnica normalizării.

Examinăm procesul de normalizare după cum am descris în capitolul 5 Prin

normalizare trebuie să demonstrăm că modelul creat este consistent, conţine redundanţă

minimală şi are stabilitate maximă.

Normalizarea este procesul prin care se decide dacă atributele pot sau nu să rămână

înpreună. Conceptul de bază a teoriei relaţiilor este că atributele sunt grupate împreună pentru

că există o relaţie logică între ele. Câteodată baza de date nu este cea mai eficientă. Acesta se

argumentează prin următoarele:

Proiectarea normalizată organizează datele în funcţie de dependenţele funcţionale. Deci

acest proces este situat undeva între proiectarea conceptuală şi cea fizică.

Proiectul logic nu este un proiect final. El ajută priectantul să înţeleagă natura datelor în

întreprindere. Proiectul fizic poate fi diferit. Există posibilitatea ca unele tipuri de entităţi

să se denormalizeze. Totuşi normalizarea nu este un timp pierdut.

Proiectul normalizat este robust şi independent de anomaliile de actualizare prezentate

înunitatea de învăţare anterioară..

Calculatoarele moderne au mult mai multă putere de calcul, ca cele de acum câţiva ani.

Din această cauză, câteodată este mai convenabilă implementarea unei baze de date cu

puţină redundanţă, decât suportarea cheltuielilor pentru procedurile adiţionale.

Normalizarea produce o bază de date care va fi uşor extensibilă în viitor.

Pasul 2.2. Validarea modelului prin tranzacţii

Obiectivul: Verificarea ca modelul de date suporte toate tranzacţiile cerute de

utilizator.

În acest pas se validează baza de date prin verificarea tranzacţiilor ce se cer de catre

utilizator. Luând în considerare tipurile de entităţi, relaţiile, cheile primare şi străine, încercăm

să rezolvăm manual cerinţele utilizatorilor. Dacă reuşim să rezolvăm fiecare tranzacţie cerută,

atuci înseamnă că modelul creat este valid. Dacă nu putem rezolva o tranzacţie, atunci este

foarte posibil să fi omis un atribut, o relaţie, sau o entitate din modelul de date.

Trebuie să examinăm dacă baza de date suportă tranzacţiile cerute. Mai întâi ar fi prin

rezolvarea de tranzacţii.

Exemple

De exemplu să luăm relaţia dintre Furnizori şi Cheltuieli exemplificată în figură

Page 117: Baze de date_Iacob
Page 118: Baze de date_Iacob

117

Reguli asupra domeniului atributelor.

Unele atribute au un domeniu de definiţie bine definit. Aceste domenii trebuie

respectate. Domeniile de definiţie au fost deja identificate când am documentat domeniile

atributelor în pasul 1.2.

Integritatea entităţilor.

Cheia primară a entităţilor nu poate lua valori nule. De exemplu fiecare furnizor

trebuie să aibă un cod diferit de zero.

Aceste reguli au fost deja identificate, când am documentat cheile primare în pasul

1.5.

Integritatea referinţelor

Cheia străina din tipul de entitate “fiu” face ligătura cu o entitate din tipul de entitate

“părinte”. Deci, dacă cheia străină conţine o valoare, ea trebuie neapărat să se regăsească şi în

tipul de entitate “părinte”. De exemplu tipul de entitate Cheltuieli conţine cheia străină

Cod_furnizor, care se referă la Furnizori(Cod_furnizor). Dacă această cheie nu este nu lă,

atunci trebuie să găsim un furnizor care să aibă acel cod.

Prima întrebare pe care trebuie să ne-o ponem este: Poate fii cheia străină nulă? În

cazul exemplului nostru asta ar însemna că există cheltuieli care nu se prătesc nimănui. Aceste

cazuri nu sunt admise de lege, deci nu putem avea valoare nulă în cheia străină din tipul de

entitate Cheltuieli.

În general dacă pariciparea tipului de entitate “fiu” este totală, atunci nu putem avea

valoare nulă în cheia străină. În caz contrar putem avea valoare nulă.

Pentru a demonstra diferitele cazuri la definirea acestor reguli, folosim relaţia de mai

sus dintre Furnizori şi Cheltuieli, care este de tipul 1:M. Considerăm următoarele cazuri:

Cazul 1: Inserarea unei entităţi în tipul de entitate “fiu” (Cheltuieli): Pentru a verifica

integritatea referinţei, verificăm dacă atributele din componenţa cheii străine (Cod_furnizor)

sunt vide, sau să existe entitate în tipul de entitate “părinte” care să aibă valoare cheii primare

egală cu valoare cheii străine.

Cazul 2: Ştergerea unei entităţi din tipul de entitate “fiu” (Cheltuieli): Ştergerea unei

entităţi din tipul de entitate “fiu” nu creează probleme la integritatea referinţelor.

Cazul 3: Actualizarea cheii străine în tipul de entitate “fiu” (Cheltuieli): Acest caz

este similar cazului 1.

Cazul 4: Stergerea unei entităţi din tipul de entitate “părinte” (Furnizori): Dacă se

şterge o entitate din tipul de entitate “părinte”, integritatea referinţelor se strică în cazul în

care există entităţi în tipul de entitate “fiu”, care se referă la entitatea ştearsă. Există strategii

severe de a rezolva integritatea referinţelor:

FĂRĂ ACŢIUNE Neacceptarea ştergerii unei entităţi din tipul de entitate părinte, dacă

acesta este referit de o entitate din tipul de entitate fiu. În cazul nostru, nu se acceptă

ştergerea furnizorului, dacă el are o factură de încasat.

CASCADĂ Dacă o entitate din tipul de entitate părinte este ştearsă, se şterg automat

toate entităţiile din tipurile de entităţi fiu. Dacă tipurile de entităţi fiu au şi ei la rândul lor

alte tipuri de entităţi fiu, se va efectua ştergerea în cascadă în toate tipurile de entităţi fiu,

până la ultimul nivel. Cu alte cuvinte, dacă se şterge un furnizor, atunci automat se şterge

fiacare factură pe carea are de încasat acest furnizor.

SETARE LA NUL Dacă o entitate din tipul de entitate părinte se şterge, atunci se vor seta

la valoare nulă toate cheile străine ai tipurilor de entităţi fiu în cascadă până la ultimul

nivel. În exemplul nortru, dacă se şterge un furnizor, atunci se vor seta la valoare nulă toate

referinţele la acest furnizor în tipul de entitate Cheltuieli. Acesta înseamnă că nu vom ştii

ca anumite cheltuieli la ce furnizor trebuie plătite.

Page 119: Baze de date_Iacob

118

SETARE IMPLICITĂ Este analog cazului de setare la nul, cu diferenţa că aici se

setează cheia străină la o valoare implicită în loc de valoare nulă. În exemplul nostru putem

seta cheia străină din Cheltuieli la o valoare a cheii primare din Furnizori, care să conţină

un furnizor predefinit - de exemplu cu numele de “Furnizor şters”.

FĂRĂ MODIFICARE În cazul ştergerii unei entităţi din tipul de antitate părinte, nu se

actualizează deloc cheile străine din tipurile de entităţi fiu.

Cazul 6: Modificarea cheii primare în tipul de entitate părinte (Furnizori): Dacă se

modifică cheia primară din tipul de entitate părinte, integritatea referinţelor se strică. Pentru

menţinerea integrităţii, se pot folosii toate cazurile descrise mai sus, dar cel mai indicat este

folosirea cazului CASCADĂ.

Regulile întreprinderii.

În final evidenţiem acele reguli care sunt date de realitatea ce se va modela în baza de

date.

Documentarea tuturor regulilor de integritate.

Trecem toate regulile de integritate în dicţionarul de date.

Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.

Obiectivul: Convingerea că modelul creat reprezintă în totalitate realitatea care trebuie

modelată în baza de date.

La acest pas modelul local logic este clomplet şi este bine documentat. Înainte de a

trece la pasul 3, trebuie verificat modelul, să fie conform cu realitatea. În cazul în care se

găsesc diferenţe, ne vom reîntoarce la paşii anteriori şi modificăm cele necasare.

Să ne reamintim...

Activităţile proiectării logice locale sunt:

Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.

Pasul 2.2. Crearea relaţiilor pentru modelul logic local.

Pasul 2.3. Validarea modelului, utilizând normalizarea.

Pasul 2.2. Validarea modelului din nou, utilizând tranzacţiile.

Pasul 2.5. Desenarea diagramei ER.

Pasul 2.6. Definirea regulilor de integritate ale bazei de date.

Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.

Pasul 3. Crearea şi validarea modelului global logic de date.

Obiectivul: Combinarea modelelor locale logice într-un model logic global care să

reprezinte întreprinderea care este modelată.

A treia activitate majoră în proiectarea bazei de date logice este crearea modelului

logic global, prin compunerea tuturor modelelor locale. După combinarea modelelor locale,

trebuie validat modelul global prin tehnica de normalizare şi după aceea, prin tehnica

tranzacţiilor. Acest proces utilizează aceleaşi tehnici pe care le -am descris la paşii 2.3. şi 2.2.

Acest proces este foarte important în proiectarea bazei de date, pentru că el

demonstrează că reprezentarea întreprinderii este independentă de orice utilizator, funcţie sau

aplicaţie. Activităţile din acest pas sunt:

Pasul 3.1. Compunerea medelelor logice locale într-un model logic global.

Pasul 3.2. Validarea modelului logic global.

Pasul 3.3. Verificarea posibilităţii de a completa baza de date în viitor.

Page 120: Baze de date_Iacob

119

Pasul 3.2. Desenarea diagramei ER finale.

Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.

Pasul 3.1. Compunerea modelelor logice locale într-un model logic global.

Obiectivul: Compunerea tuturor modelelor logice locale într-un model logic global al

întreprinderii.

În cazul unui sistem mic, cu puţine vederi ai utilizatorilor, este relativ uşor de a

compune modelele logice locale. În cazul unui sistem mai mare însă, trebuie să urmăm un

proces sistematic de realizare a modelului global. Paşii acestui proces sunt următoarele:

(1) Verificarea numelor entităţilor şi a cheilor lor primare.

(2) Verificarea numelor relaţiilor.

(3) Compunerea entităţilor de pe view-urile locale.

(4) Includerea (fără compunere) a entităţilor care apar pe doar una dintre view -uri.

(5) Compunerea relaţiilor de pe view-urile locale.

(6) Includerea (fără compunere) a relaţilor care apar pe doar una dintre view -uri.

(7) Căutarea entităţilor şi a relaţilor care lipsesc (dacă există).

(8) Căutarea cheilor străine.

(9) Căutarea regulilor de integritate.

(10) Desenarea modelului logic global.

(11) Actualizarea documentaţiei.

Cel mai uşor de compus mai multe modele locale este compunerea succesivă a două

câte două dintre modele.

(1) Verificarea numelor entităţilor şi a cheilor lor primare.

Această verificare se face folosind şi dicţionarul creat în decursul paşilor de dinainte.

Probleme apar doar atunci când:

Două entităţi au acelaşi nume, dar sunt de fapt diferiţi.

Două entităţi sunt aceleaşi, dar nu au aceleaşi nume.

Probabil va fi necesară analizarea atributelor antităţilor, prntru a rezola această

problemă. În particular, putem utiliza cheia primară şi numele entităţii, pentru a identifica

entităţile echivalente.

(2) Verificarea numelor relaţiilor.

Această activitate este asemănătoare celei descrise la entităţi.

(3) Compunerea entităţilor de pe view-urile locale.

Examinăm numele şi atributele entităţilor ca vor fi compuse. Activităţile care se includ

în acest pas sunt:

Compunerea entităţilor cau au aceleaşi nume şi aceleaşi chei primare.

Compunerea entităţilor care au aceleaşi nume, dar cu chei primare diferite.

Compunerea entităţilor care au nume diferite, cu chei primare egale sau diferite.

Compunerea entităţilor care au aceleaşi nume şi aceleaşi chei primare. În general

entităţile cu aceleaşi chei primare reprezintă “lumea reală”, şi deci pot fi compuse. Atributele

care apar în entităţile de pe ambele view-uri, vor fi trecute doar o singură dată. Dacă într-un

view apare un atribut compus, iar într-un alt view acelaşi atribut dar descompus în atribute

simple, atunci vom întreba, dacă se poate, utilizatorii pentru a decide asupra formei de

utilizare a atributului.

Compunerea entităţilor care au aceleaşi nume, dar au chei primare diferite. În astfel

de situaţii, căutăm două entităţi care au aceleaşi nume şi nu au aceleaşi chei primare, dar au

aceleaşi chei candidat. Cele două entităţi pot fi compuse, urmând ca după compunere să

alegem o cheie primară, restul rămănând chei alternante.

Page 121: Baze de date_Iacob

120

Compunerea entităţilor care nu au nume comune şi nu au aceleaşi chei primare.

Aceste entităţi se pot depista prin analiza atributelor celor două entităţi.

(4) Includerea (fără compunere) a entităţilor care apar doar într-un view.

Pasul anterior identifică toate entităţile comune. Celelalte entităţi, se vor include în

modelul logic global exact aşa cum apar în view-ul respectiv.

(5) Compunerea relaţiilor de pe modelele locale.

În acest pas analizăm similitudinile dintre relaţii de pe diferite modele locale. În

timpul compunerii relaţiilor trebuie rezolvate şi conflictele dintre relaţii, ca şi regulile de

cardinalitate şi participare. Putem compune relaţii care au aceleaşi nume şi acelaşi scop, sau

acelaşi scop, dar nume diferite.

(6) Includerea (fără compunere) a relaţiilor care apar doar pe un view.

Relaţile care au rămas neincluse în modelul global după pasul anterior, se includ în

modelul global fără modificare.

(7) Căutarea entităţilor şi relaţilor care lipsesc.

Este unul din cei mai grei paşi din crearea modelului global. Trebuie căutate acele

entităţi şi relaţii, care s-au omis la paşii anteriori şi n-au ajuns în modelul global.

(8) Căutarea cheilor străine.

În decursul paşilor anterioare, s-au modificat entităţi, chei primare şi chei străine. În

acest pas verificăm dacă cheile străine sunt corecte în fiecare entitate fiu şi efectuăm toate

modificările necesare.

(9) Căutarea regulilor de integritate

Verificăm dacă regulile de integritate a modelului global nu sunt în conflict cu regulile

definite la modelele locale. Fiecare problemă de acest gen se rezolvă cu ajutorul utilizatorului

sistemului.

(10) Desenarea diagramei ER.

Acum desenăm diagrama ER pentru modelul global de date.

(11) Actualizarea documentaţiei.

Actualizăm documentaţia, ca să reflecte toate modificările aduse în acest pas

modelului.

Pasul 3.2. Validarea modelului logic global.

Obiectivul: Validarea modelului global logic de date, folosind normalizarea, după care

folosind tranzacţile cerute.

Acest pas este schivalent cu paşii 2.3. şi 2.4., unde am validat modelul local de date.

Pasul 3.3. Verificarea posibilităţilor de extindere a bazei de date în viitor.

Obiectivul: Determinarea ca dacă modelul se acomodează uşor la modificări oricât de

mari ce pot intervenii în viitor.

Este important ca modelul creat să fie expansibil în viitor. Dacă modelul nu are

această calitate, viaţa lui poate fi scurtă şi pentru o mai mare modificare va trebui refăcută de

la început.

Pasul 3.4. Desenarea diagramei Entity-Relationship finale.

Obiectivul: Desenarea unei diagrame ER, care să reprezinte modelul global de date al

întreprinderii.

Pasul 3.5. Verificarea modelului global cu ajutorul utilizatorului.

Obiectivul: Verificarea că modelul global reprezintă în totalitate realitatea.

În acest moment modelul global este complet şi documentat. Împreună cu utilizatorul

sistemului se verifică acest model şi se aduc eventualele corecturi prin întoarcerea la paşii în

cauză.

Page 122: Baze de date_Iacob

121

Să ne reamintim...

Activităţile proiectării logice globale sunt:

Pasul 3.1. Compunerea medelelor logice locale într-un model logic global.

Pasul 3.2. Validarea modelului logic global.

Pasul 3.3. Verificarea posibilităţii de a completa baza de date în viitor.

Pasul 3.2. Desenarea diagramei ER finale.

Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.

M5.U5.2. Rezumat

Activităţile proiectării logice locale sunt:

Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.

Pasul 2.2. Crearea relaţiilor pentru modelul logic local.

Pasul 2.3. Validarea modelului, utilizând normalizarea.

Pasul 2.2. Validarea modelului din nou, utilizând tranzacţiile.

Pasul 2.5. Desenarea diagramei ER.

Pasul 2.6. Definirea regulilor de integritate ale bazei de date.

Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.

Activităţile proiectării logice globale sunt:

Pasul 3.1. Compunerea medelelor logice locale într-un model logic global.

Pasul 3.2. Validarea modelului logic global.

Pasul 3.3. Verificarea posibilităţii de a completa baza de date în viitor.

Pasul 3.2. Desenarea diagramei ER finale.

Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.

M5.U5.2. Test de autoevaluare a cunoştinţelor

5.2.1 Faceţi proiectul logic local pentru subsistemul didactic al

facultăţii.

Răspunsurile se găsesc la sfârşit la pag 158

Page 123: Baze de date_Iacob

122

Unitatea de învăţare U5.3 Proiectarea fizică.

M5U5.3 Introducere

Proiectarea fizică a bazei de date este procesul de alegere a structurilor de memorare

şi de acces a fişierelor bazei de date, pentru a obţine performanţe cât mai bune, pentru cât

mai multe din aplicaţiile proiectate. De asemenea, în această fază, se sciu programele care

dau cereri, formulare şi rapoarte.

M5.U5.3. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

aleagă, în cunoştinţă de cauză, SGBD-ul cel mai potrivit.

descrie corect structura fizică a bazei de date

proiecteze cereri

proiecteze formulare

proiecteze rapoarte

Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Fiecare SGBD oferă o varietate de opţiuni de organizare a fişierelor şi a modului de acces la datele stocate: indexuri, gruparea înregistrărilor corelate în aceleaşi blocuri pe disc (clustering), tabele de dispersie (hashing), etc.

După alegerea sistemului SGBD, în faza de proiectare fizică a bazei de date se aleg structurile fişierelor bazei de date dintre cele oferite de sistemul de gestiune respectiv, cele mai

potrivite cu cerinţele de proiectare a sistemului de baze de date.

Ca parametri generali de alegere a opţiunilor proiectului fizic al unei baze de date relaţionale se

pot enumera: Timpul de răspuns. Acesta este intervalul de timp dintre lansarea i execuţie a unei tranzacţii

şi primirea răspunsului la acea tranzacţie. Cea mai mare pondere în timpul de răspuns o are

execuţia operaţiilor în sistemul SGBD, dar există şi factori care nu se află sub controlul

acestuia (viteza de operare a procesorului, dimensiunea memorie; principale, planificarea

sarcinilor de către sistemul de operare, timpi:

de comunicaţie, etc.).

Utilizarea spaţiului de memorare. Aceasta este dimensiunea spaţiului pe disc utilizat de

fişierele bazei de date şi de structurile de acces l date.

Capacitatea tranzacţionala (transaction throughput). Acesta este numărul mediu de

tranzacţii care pot fi prelucrate pe minut de către sistemul de baze de date, măsurat în

momentele de vârf ale încărcării. Acesta este un parametru critic în multe aplicaţii, în particular

în acele aplicaţii în care există un număr mare de utilizatori care accesează concurent baza

de date (aplicaţii bancare, rezervări de bilete, etc.).

Page 124: Baze de date_Iacob

123

In mod obişnuit, trebuie să fie specificate valorile medii şi limitele în cazurile cele mai

defavorabile ale acestor parametri în cadrul cerinţelor de performanţe ale sistemului. Pentru

compararea valorilor acestor parametri, corespunzătoare diferitelor decizii de proiectare

fizică, se fac diferite evaluări analitice sau măsurători experimentale (prototipuri, simulări).

Pentru o schemă conceptuală dată există o multitudine de alternative ale proiectului fizic

pentru un SGBD dat. Deciziile de proiectare fizică se pot lua numai după o analiză a

aplicaţiilor care se vor executa şi în principal a interogărilor şi tranzacţiilor pe care acestea le

vor lansa, în continuare se vor prezenta câteva aspecte ale analizei interogărilor şi tranzacţiilor

necesare pentru a stabili opţiunile proiectului fizic al unei baze de date relaţionale. Analiza atributelor accesate de interogări şi tranzacţii trebuie să evidenţieze: Atributele de proiecţie, atributele care sunt conţinute în condiţiile de interogare şi atributele

comune a două sau mai multe relaţii pe care se execută joncţiunile. Astfel de atribute sunt

candidate pentru definirea unor structuri suplimentare de acces (indexuri secundare) care

să accelereze operaţiile de interogare.

Atributele pe care sunt specificate condiţii de selecţie pentru operaţii de ştergere sau

actualizare. La fel ca mai sus, astfel de atribute sunt candidate pentru definirea unor

structuri suplimentare de acces (indexuri secundare).

• Atributele ale căror valori se modifică în cursul operaţiilor de actualizare. Este

recomandabil ca pe astfel de atribute să nu se definească structuri suplimentare de acces

(indexuri secundare) deoarece ar trebui ca şi acestea să fie actualizate la fiecare operaţie de

actualizare a relaţiilor.

Analiza frecvenţei estimate de invocare a interogărilor şi a tranzacţiilor, împreună cu listele

de atribute care intervin în interogări şi tranzacţii, permit obţinerea unei situaţii globale

privind frecvenţa estimată de accesare a atributelor relaţiilor, în general, pentru volume mari de

prelucrări, se respectă regula "80-20". Această regulă stipulează că 80% din operaţiile de

prelucrare sunt executate în 20% din interogările şi tranzacţiile tuturor aplicaţiilor

implementate. De aceea, în cazurile practice nu sunt necesare statistici exhaustive ale

frecvenţelor de invocare a tuturor interogărilor şi a tranzacţiilor, ci este suficient să fie

determinate cele mai importante 20% dintre acestea.

Analiza constrângerilor de timp ale interogărilor trebuie să evidenţieze care dintre interogări

şi tranzacţii trebuie să se termine într-un anumit interval de timp. De exemplu, o tranzacţie

trebuie să se termine în mai puţin de 5 secunde în 95% din cazuri şi să nu depăşească niciodată

durata de 20 de secunde. Astfel de constrângeri pot fi folosite pentru a adăuga priorităţi

suplimentare atributelor candidate pentru indexare. Atributele de selecţie utilizate de interogări

şi tranzacţii cu constrângeri de timp devin candidate cu mare prioritate pentru indexare.

Tot în faza de proiectare fizică se poate rafina procesul de normalizare a relaţiilor, folosind

informaţiile de frecvenţă a invocării interogărilor şi tranzacţiilor şi constrângerile de timp

impuse unora dintre acestea, în general, pentru obţinerea unor timpi de răspuns mai mici

pentru unele interogări, se efectuează o denormalizare a unor relaţii, adică se combină două

sau mai multe relaţii existente într-o singură relaţie cu un grad de normalizare mai redus, în care

apar, bineînţeles, date redundante şi sunt posibile anomalii de actualizare. Odată cu

denormalizarea unor relaţii trebuie să se prevadă şi procedurile necesare (care depind de

SGBD) pentru verificarea datelor şi evitarea anomaliilor.

Alegerea sistemului de gestiune al bazei de date rebuie să ţină cont de:

Definirea datelor

Gestiunea cheilor primare Specificarea cheilor străine Tipuri de date disponibile

Extensibilitatea tipurilor de date Specificarea domeniilor Uşurinţa restructurării Mecanism de

tabele derivate Controlul integrităţii Dicţionar de date Independenţa datelor Tipul de model de

date utilizat

Accesibilitate

Page 125: Baze de date_Iacob

124

Suport pentru standardele SQL Interfaţă cu 3GL Mulţi utilizator Securitate:

controlul accesului

mecanism de autorizare

Utilitare

Măsurarea performanţei Acordare (run/ng)/optimizare Facilităţi de încărcare/descărcare Suport

pentru administrarea BD

Dezvoltare

Instrumente 4GL

Instrumente CASE

Facilităţi vizuale

Proceduri de stocare, declanşatoare

Instrumente de dezvoltare Web

Controlul tranzacţiilor

Rutine de salvare şi restaurare Puncte de salvare intermediare Suport pentru jurnalizare

Granularitatea accesului simultan Strategia de rezolvare a interblocajelor Procesare paralelă a

interogărilor

Definirea fizică

Structuri fizice disponibile

întreţinerea structurii de fişiere

Uşurinţa reorganizării

Indexare

Atribute/înregistrări de mărime variabilă

Compresia datelor

Rutine de criptare

Cerinţe de memorie

Alte facilităţi/opţiuni

Evolutivitate

Stabilitatea furnizorului

Baza de utilizatori

Pregătire şi suport pentru utilizatori

Documentare

Sistem de operare cerut

Cost

Help oniine

Standarde utilizate

Managementul versiunilor

Optimizare a interogărilor

Scalabilitate

Suport pentru instrumente OLAP

Interoperabilitate cu alte SGBD

Integrare Web

Utilitare de replicare

Facilităţi de distribuire

Portabilitate

Cerinţe hardware

Suport pentru reţea

Facilităţi de orientare pe obiect

Arhitecturi pe două, trei... straturi

Performanţă

Rata de tranzacţii pe secundă (minut)

Page 126: Baze de date_Iacob

125

Număr maxim de utilizatori simultani

Suport pentru XML

M5.U5.3. Rezumat

Pasul 8. Proiectarea fizică şi implementarea bazei de date relaţionale:

Translatarea modelului logic global în SGBD.

Pasul 8.1. Proiectarea relaţiilor de bază în SGBD.

Pasul 8.2. Crearea regulilor de integritate în SGBD.

Pasul 9. Proiectarea şi implementarea reprezentării fizice.

Pasul 9.1. Analizarea tranzacţiilor.

Pasul 9.2. Alegerea organizării fişierelor.

Pasul 9.3. Alegerea indecsilor secundari.

Pasul 9.4. Introducerea unei redundanţe comntrolate.

Pasul 9.5. Estimarea spaţiului pe disc.

Pasul 10. Proiectarea şi implementarea unui mecanism de securitate.

Pasul 10.1. Crearea view-urilor pentru utilizatori.

Pasul 10.2. Proiectarea regulilor de acces la baza de date.

Pasul 11. Verificarea sistemului operaţional.

Alegerea sistemului de gestiune al bazei de date rebuie să ţină cont de

calităţile SGBD-ului legatede Definirea datelor, Accesibilitate, Utilitare,

Dezvoltare, Definirea fizică şi Alte facilităţi/opţiuni

M5.U5.3. Test de autoevaluare a cunoştinţelor

5.3.1 Realizaţi, în ACCESS, proiectul fizic al subsistemului didactic al facultăţii.

Răspunsurile se găsesc la sfârşit la pag 160

Page 127: Baze de date_Iacob

126

Unitatea de învăţare U5.4 Tranzacţii şi concurenţă

M5 U5.4 Introducere

O tranzacţie (transaction) este o unitate logică de prelucrare indivizibilă (atomică) a datelor unei baze de date prin care se asigură consist enţa acesteia.

În principiu, orice execuţie a unui program care accesează o bază de date poate fi considerată o tranzacţie, dacă baza de date este într -o stare consistentă atât înainte cât şi

după execuţie. O'tranzacţie trebuie să asigure consistenţa bazei de date indiferent dacă a fost executată individual sau concurent cu alte tranzacţii precum şi în condiţiile în care au apărut defecte ale sistemului hardware în cursul execuţiei tranzacţiei.

M5.U5.4. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

construiască tranzacţii corecte

Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Tranzacţia este o acţiune sau o serie de acţiuni, executate de un singur utilizator sau un

program, care accesează sau schimbă conţinutul bazei de date.

Tranzacţia este o unitate logică de lucru a bazei de date. Nu există reguli de stabilire

automată a acestei unităţi. Pentru a demonstra acest concept o să dăm următoarele exemple.

Fie schemele:

Personal = (nrmat, nume, adresă, salariu)

Proprietate = (nrprop, stradă, oraş, tip, nrmat)

care leagă proprietatea de o persoană prin nrmat printr -o relaţie de cardinalitate n la 1,

Putem avea următoarele tranzacţii:

Exemple 5.4.1

cit (nrmat = x, salariu)

salariu = salariu * 1,1

scrie (nrmat = x, salariu)

care măreşte salariul cu 10%

Page 128: Baze de date_Iacob

127

Exemple 5.4.2

cit (nrmat =x )

şterge (nrmat = x )

pentru toate înregistrările din Proprietate

begin

cit ( nrprop, nrmat)

dacă (nrmat = x ) atunci

şterge (nrprop)

end

care şterge persoana x şi toate proprietăţile ei

O tranzacţie trebuie să transforme întotdeauna baza de date dintr-o stare consistentă

într-o altă stare tot consistentă.

O tranzacţie se poate termina în două moduri. Dacă tranzacţia s-a terminat cu succes,

atunci spunem că tranzacţia a făcut ‘commit’ şi baza de date a trecut în noua stare consistentă.

Dacă tranzacţia nu s-a terminat cu succes atunci, ea este întreruptă şi, în acest caz , baza de

date trebuie să fie readusă în starea consistentă în care era înainte să înceapă tranzacţia.

Spunem, în acest caz, că tranzacţia face ‘roll back’ este derulată înapoi. O tranzacţie care a

făcut ‘commit’ nu mai poate fi întreruptă, dar o tranzacţie întreruptă poate fi reluată mai târziu

şi atunci s-ar putea să se termine cu succes.

Un SGBD trebuie să aibă posibilitatea de a defini şi mânui tranzacţii.

Găsim astfel cuvintele cheie cu semnificaţie imediată BEGIN TRANSACTION, COMMIT,

ROLLBACK.

Proprietăţile tranzacţiilor.

Deşi nu avem reguli automate pentru construcţia tranzacţiilor ele trebuie să respecte

proprietăţile ACID.

Atomicitate este proprietatea ‘totul sau nimic’. O tranzacţie este o unitate indivizibilă

care se execută în întregime sau deloc.

Consistenţă o tranzacţie trebuie să transforme baza de date dintr-o formă consistentă

într-o altă formă tot consistentă.

Independenţă o tranzacţie se execută inependent de oricare alta, adică efectele

parţiale ale unei tranzacţii incomplete nu trebuie să influenţeze o altă tranzacţie.

Durabilitate efectele unei tranzacţii terminată cu succes sunt definitiv înregistrate în

baza de date şi nu se mai pot pierde în tranzacţiile întrerupte ulterior.

Dacă fiecare tranzacţie lucrează pe rînd, se pierde timp când calculatorul stă să aştepte

terminarea unei operaţii de intrare/ieşire, sau în timpul altei întreruperi. Pe de altă parte,

dacă lăsăm să lucreze deodată, fiecare în timpul lăsat liber de cel din nainte, zicem că

avem tranzacţii concurente. Concurenţa va mări randamentul timpului de lucru al

calculatorului dar ea trebuie controlată pentru că altfel poate da naştere la inconsistenţă.

Prezentăm în continuare, trei exemple în care arătăm cum se poate pierde cinsistenţa.

În primul exemplu tranzacţia T1 citeşte contul lui x (balx) şi scade 10 din cont.

Tranzacţia T2 citeşte contul lui x (balx) şi adună 100 la cont. Pornind cu un cont de 100,

evident că dacă se executa mai întâi prima tranzacţie şi apoi a doua contul lui x ar fi fost

100-10+100=190. În cealaltă ordine am fi avut 100+100-10=190 aceeaşi valoare. Să

considerăm următorul plan de tranzacţii.

Page 129: Baze de date_Iacob

128

Un plan de tranzacţii este o secvenţă posibilă în timp a modului de execuţie a

tranzacţiilor. Putem observa, în timpii înscrişi în stânga, cum evoluează contul din ultima

coloană.

Exemple 5.4.3

Time

T1 T2 balx

A t1 begin_transaction 100

A t2 begin_transaction cit(bal x) 100

A t3 cit(bal x) bal x = balx + 10 100

A t4 bal x = balx - 10 scrie(bal x) 200

A t5 scrie(bal x) commit 90

A t6 commit 90

Problema se numeşte problema pierderii actualizării.

Problema dependenţei de o tranzacţie neterminată apare când o tranzacţie este

lăsatăsă ‘vadă’ rezultatele intermediare alei alte tranzacţii înainte ca ea să facă ‘commit’.

Aceleaşi tranzacţii ca în figura precedentă se desfăşoară acum după un alt plan.

Exemple 5.4.4

Time

T3 T4 balx

A t1 begin_transaction 100

A t2 cit(bal x) 100

A t3 bal x = balx + 10 100

A t4 begin_transaction scrie(bal x) 200

A t5 cit(bal x) 200

A t6 bal x = balx - 10 rollback 100

A t7 scrie(bal x) 190

A t8 commit 190

Rezultatul este 190, aţi putea spune că este bun, dar ţineţi cont că tranzacţia 4 a fost întreruptă

şi, când se va relua, va mai mări cu 100 contul ceea ce va deveni incorect.

Chiar şi când unele tranzacţii numai citesc baza de date se pot întâmpla neplăceri.

Această problemă este problema analizei inconsistente sau problema ‘citirii murdare’.

De exemplu tranzacţiile T5 şi T6 executate serial, adică una după alta, ar trebui să dea

rezultatele:

T5T6 balx=100-10=90, balz=25+10=35, sum=90+50+35+175

sau T6T5 sum=100+50+25=175, balx=100-10=90, balz=25+10=35

şi putem vedea în figura următoare ce se poate întâmpla încazul concurenţei libere,

necontrolate:

Page 130: Baze de date_Iacob

129

Exemple 4.4.5

Time

T5 T6 balx baly balz sum

A t1 begin_transaction 100 50 25

A t2 begin_transaction sum = 0 100 50 25 0

A t3 cit(bal x) cit(balx) 100 50 25 0

A t4 bal x = balx -

10

sum = sum +

balx

100 50 25 100

A t5 scrie(bal x) cit(baly) 90 50 25 100

A t6 cit(bal z) sum = sum +

baly

90 50 25 150

A t7 bal z = balz +

10

90 50 25 150

A t8 scrie(bal z) 90 50 35 150

A t9 commit cit(balz) 90 50 35 150

A t10 sum = sum +

balz

90 50 35 185

A t11 commit 90 50 35 185

Nu putem, deci, lăsa concurenţa necontrolată, dar nici nu este profitabil să o

desfiinţăm de tot. Spunem că un plan de tranzacţii este serial cînd tranzacţiile se execută una

după alta fără a intercala operaţii din altă tranzacţie. Spunem că un plan de tranzacţii este

neserial când tranzacţiile sînt concurente , adică între operaţiile unei tranzacţii se intercalează

operaţiile alteia. Vom spune că un plan de tranzacţii este corect atunci când el are ca rezultat

acelaşi cu unul executat serial; acesta se va numi serializabil. Aveţi deja exemple de planuri

neserializabile.

Page 131: Baze de date_Iacob

130

M5.U5.4. Rezumat

Tranzacţia este o acţiune sau o serie de acţiuni, executate de un singur utilizator

sau un program, care accesează sau schimbă conţinutul bazei de date.

Tranzacţiile trebuie să respecte proprietăţile ACID.

Atomicitate este proprietatea ‘totul sau nimic’. O tranzacţie este o

unitate indivizibilă care se execută în întregime sau deloc.

Consistenţă o tranzacţie trebuie să transforme baza de date dintr-

o formă consistentă într-o altă formă tot consistentă.

Independenţă o tranzacţie se execută inependent de oricare alta,

adică efectele parţiale ale unei tranzacţii incomplete nu trebuie să

influenţeze o altă tranzacţie.

Durabilitate efectele unei tranzacţii terminată cu succes sunt

definitiv înregistrate în baza de date şi nu se mai pot pierde în

tranzacţiile întrerupte ulterior.

Problemele concurenţei fără control sunt: problema pierderii actualizării.

problema dependenţei de o tranzacţie neterminată

problema analizei inconsistente sau problema ‘citirii murdare’.

Spunem că un plan de tranzacţii este serial cînd tranzacţiile se execută una

după alta fără a intercala operaţii din altă tranzacţie. Spunem că un plan de

tranzacţii este neserial când tranzacţiile sînt concurente , adică între operaţiile

unei tranzacţii se intercalează operaţiile alteia. Vom spune că un plan de tranzacţii

este corect atunci când el are ca rezultat acelaşi cu unul executat serial; acesta se

va numi serializabil.

M5.U5.4 Test de autoevaluare a cunoştinţelor

5.4.1 Daţi exemple de pierdere a consistenţei.

Răspunsurile se găsesc la sfârşit la pag 161

Page 132: Baze de date_Iacob

131

Unitatea de învăţare U5.5 Metode de control al concurenţei.

M5U5.5 Introducere

Am văzut că problemele apar atunci când o tranzacţie ‘vede’ (citeşte) sau scrie

într-un moment nepotrivit. Ideile de a controla concurenţa sînt legate de a nu lăsa

pe celălalt (de a bloca) sau de a ţine cont de momente (de a marca timpul).

M5.U5.5. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

aleagă cea mai bună metodă de control al concurenţei

Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Ce înseamnă să blocăm ? Când o tranzacţie blochează partajat (part_bloc) o anumită

unitate de memorie, o altă tranzacţir nu mai poate să rescrie tot acolo, iar când o tranzacţie

blochează exclusiv (ex_bloc) o alta nu mai poate nici să o citească.

Despre ce unitate de memorie este vorba? Aceasta este problema granularităţii la

care se face blocajul. Blocajul se poate face la nivel de:

- întreaga bază de date

- tabela(fişier)

- înregistrare (cel mai des)

- câmp din înregistrare

Mai spunem că avem granularitate dinamică atunci când SGBD-ul poate să schimbe

granularitatea în timpul unei tranzacţii.

Cititorul poate să demonstreze singur pe un exemplu (vezi problema ) că numai

simpla blocare urmată cândva de deblocare (debloc) nu asigură serializabilitatea.

Serializabilitatea este asigurată dacă se respectă protocolul de blocare în două faze.

Acesta constă din împărţirea tranzacţiei în două faze una de blocări şi creşteri de blocaje şi a

doua de descreşteri şi deblocaje. Aceasta înseamnă că după ce s-a făcut prima deblocare nu se

mai pot face blocări.

Următoarele trei exemple reiau tranzacţiile T1 şiT2 din exemplul 5.4.1respectiv T3 şi

T4 din exemplul 5.4.2 şi T5 şi T6 din exemplul 5.4.3 cu protocolul în două faze şi realizează

planuri serializabile.

Page 133: Baze de date_Iacob

132

Exemple 5.5.1

Time

T1 T2 balx

A t1 begin_transaction 100

A t2 begin_transaction ex_bloc(balx) 100

A t3 ex_bloc(bal x) cit(balx) 100

A t4 AŞTEAPTĂ balx = balx +100 100

A t5 AŞTEAPTĂ scrie(bal x) 200

A t6 AŞTEAPTĂ debloc(balx) 200

A t7 cit(bal x) commit 200

A t8 bal x = balx -10 200

A t9 scrie(bal x) 190

A t10 deblo c(balx) 190

A t11 commit 190

Exemple 5.5.2

Time

T3 T4 balx

A t1 begin_transaction 100

A t2 ex_bloc(balx) 100

A t3 cit(balx) 100

A t4 begin_transaction balx = balx +100 100

A t5 ex_bloc(bal x) scrie(bal x) 200

A t6 AŞTEAPTĂ debloc(balx) 100

A t7 AŞTEAPTĂ rollback 100

A t8 cit(bal x) 100

A t9 balx = balx -10 100

A t10 scrie(bal x) 90

A t11 debloc(bal x) 90

A t12 commit 90

Page 134: Baze de date_Iacob

133

Exemple 5.5.3

Time

T5 T6 balx baly balz sum

A t1 begin_transaction 100 50 25

A t2 begin_transaction sum = 0 100 50 25 0

A t3

ex_bloc(balx)

100 50 25 0

A t4 cit(bal x) part_bloc(balx) 100 50 25 0

A t5 bal x = balx -

10

AŞTEAPTĂ 100 50 25 0

A t6 scrie(balx) AŞTEAPTĂ 90 50 25 0

A t7

ex_bloc(balz)

AŞTEAPTĂ 90 50 25 0

A t8 cit(bal z) AŞTEAPTĂ 90 50 25 0

A t9 bal z = balz +

10

AŞTEAPTĂ 90 50 25 0

A t10 scrie(bal z) AŞTEAPTĂ 90 50 35 0

A t11 debloc(bal x

, balz)

AŞTEAPTĂ 90 50 35 0

A t12 commit AŞTEAPTĂ 90 50 35 0

A t13 cit(balx) 90 50 35 0

A t14 sum = sum + balx 90 50 35 90

A t15 part_bloc(baly) 90 50 35 90

A t16 cit(baly) 90 50 35 90

A t17 sum = sum + baly 90 50 35 140

A t18 part_bloc(balz) 90 50 35 140

A t19 cit(balz) 90 50 35 140

A t20 sum = sum + balz 90 50 35 175

A t21

debloc(balx,baly,balz)

90 50 35 175

A t22 commit 90 50 35 175

Protocolul de blocare în două faze asigură serializanilitatea dar nu ne scuteşte de

probleme. Pezentăm în cele două exemple următoare rollback-ul în cascadă şi blocajul

ciclic.

Observaţi, în figura 9.7 la momentul t14 tranzacţia T7 face rollback (dintr-un motiv

extern) şi, pentru că T8 este dependentă de T7 care a citit o înregistrare care a fost

actualizată de T7, trebuie să facă şi T8 rollback, ceea ce pe urmă se întâmplă şi cu T 9.

Page 135: Baze de date_Iacob

134

Exemple 5.5.4

Time

T7 T8 T9

A t1 begin_transaction

A t2 ex_bloc(bal x)

A t3 cit(bal x)

A t4 part_bloc(bal y)

A t5 bal x = baly +

balx

A t6 scrie(bal x)

A t7 debloc(bal x) begin_transaction

A t8 … ex_bloc(balx)

A t9 … cit(balx)

A t10 … balx = balx +100

A t11 … scrie(bal x)

A t12 … debloc(balx)

A t13 … …

A t14 rollback …

A t15 rollback begin_transaction

A t16

part_bloc(balx)

A t17 …

A t18 rollback

O altă problemă este blocarea ciclică prezentată în exemplul următor. Cele

două trnzacţii T10 şi T11 se blochează reciproc.

Exemple 5.5.5

Time

T10 T11

A t1 begin_transaction

A t2 ex_bloc(bal x) begin_transaction

A t3 cit(bal x) ex_bloc(bal y)

A t4 bal x = balx -10 cit(bal y)

A t5 scrie(bal x) bal y = baly +100

A t6 ex_bloc(bal y) scrie(bal y)

A t7 AŞTEAPTĂ ex_bloc(bal x)

A t8 AŞTEAPTĂ AŞTEAPTĂ

A t9 AŞTEAPTĂ AŞTEAPTĂ

A t10 … AŞTEAPTĂ

A t11 … …

Blocajul ciclic este detectat , de obicei, prin constuirea unui graf de precedenţă care arată

dependenţa între tranzacţii în felul următor:

- se crează un nod pentru fiecare tranzacţie

- se crează o muchie direcţionată Ti Tj dacă tranzacţia Ti aşteaptă să blocheze

o înregistrare care este deja blocată de Tj.

Pe acest graf se detectează un blocaj ciclic dacă există un circuit. Pentru figura 9.8 graful ar fi

următorul:

Page 136: Baze de date_Iacob

135

x

y

Exemple 5.5.6

O altă metodă de a evita blocajul ciclic păstrând serializabilitatea este protocolul cu

marcarea timpului (time stamp). Acest protocol ataşează un timp (timpul real din calculator

sau un număr care se măreşte autmat de câte ori este solicitat) fiecărei tranzacţii (marc(T)) şi

timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a unei înregistrări. Deci

fiecare tranzacţie va avea o valoare de marcj şi fiecare înregiistrare prelucrată va avea două

marcaje; unul care spune ce marcaj a avut tranzacţia care a citit-o (cit_marc) şi celălalt care

spune ce marcaj a avut tranzacţia care a scris-o (scri_marc).

Numai în următoarele trei situaţii se pun probleme deosebite:

1. Tranzacţia T cere să citească o înregistrare x care a fost deja actualizată de o tranzacţie

cu scri_marc(x) > marc(T), adică o înregistrare scrisă de o tranzacţie care a început

mai târziu. Ce ar rescrie ea ar putea da naştere la inconsistenţă deci trnzacţia respectivă

trebuie întreruptă.

2. Tranzacţia cere să scrie înregistrarea x a cărei valoare a fost deja citită de o tranzacţie

care a început mai tîrziu marc(T) < cit_marc(x). Aceasta înseamnă că tranzacţia vrea

să rescrie o înregistrare, pe care o altă tranzacţie începută mai târziu, a citit-o şi o

foloseşte. Şi în acest caz tranzacţia trebuie întreruptă.

3. Tranzacţia cere să scrie o înregistrare x a cărei valoare a fost deja scrisă de o tranzacţie

care a început mai târziu, adică marc(T) < scri_marc(x). Este o încercare de a scrie o

valoare perimată şi în acest caz se ignoră această scriere.

În figura următoare se poate observa cum funcţionează acest protocol.

Exemple 5.5.7

Time

Op T7 T8 T9

A t1 begin_transaction

A t2 cit(balx) cit(balx)

A t3 balx = balx

+10

balx = balx

+100

A t4 scrie(balx) scrie(balx) begin-

_transaction

A t5 cit(baly) cit(baly)

A t6 baly = baly

+20 baly = baly

+20

begin-

_transaction

A t7 cit(baly) cit(baly)

A t8 scrie(baly) scrie(baly)**

A t9 baly = baly

+30

baly = baly

+30

A t10 scrie(baly) scrie(baly)

A t11 balz=100 balz=100

A t12 scrie(balz) scrie(bal z)

A t13 balz=50 balz=50 commit

A t14 scrie(balz) scrie(balz)*

begin-

T10 T11

Page 137: Baze de date_Iacob

136

_transaction

A t15 cit(baly) commit cit(baly)

A t16 baly = baly

+20

baly = baly

+20

A t17 scrie(baly) scrie(baly)

A t18 commit

* la timpul t8 scrierea de către tranzacţia T13 violează regula 2 şi de aceea este întreruptă

şi reluată la momentul t14

** la timpul t14 scrierea de către tranzacţia T12 poate fi ignorată conform celei de a treia

reguli

9.4 Tehnici optimiste. Nu întotdeuna este necesar să pierdem timp în calculator controlând concurenţa.

Atunci când conflictele între tranzacţii sînt rare putem adopta aşa-numitele tehnici optimiste.

Asta înseamnă să lăsăm tranzacţiile să ruleze fără să impunem întârzieri care să asigure

serializabilitatea, iar când o tranzacţie vrea să facă ‘commit’ să efectuăm un control care să

determine dacă a avut loc un conflict. Dacă a avut loc un conflict, tranzacţia trebuie întreruptă

şi restartată. Pentru că am spus că aceeste conflicte sînt rare, aceste înteruperi şi restartări vor

fi, şi ele, rare.

Distingem trei faze ale unui control optimist al concurenţei.

Faza de citire. Această fază durează de la începutul tranzacţiei până înainte de

‘commit’. Tranzacţia citeşte valorile de care are nevoie din baza de date şi le stochează

in variabile locale. Actualizările nu sînt făcute direct în baza de date ci într-o copie

locală.

Faza de validare. Urmează după faza de citire şi controlează dacă nu s–ar încălca

serializabilitatea în cazul că s-ar aplica actulizarea în baza de date. Dacă avem o

tranzacţie care numai citeşte baza (adică nu scrie), controlul constă în a verifica dacă

datele citite sînt încă datele curente în bază şi, dacă este aşa, atunci se face ‘commit’,

altfel se întrerupe şi se reia mai târziu. Dacă trnzacţia face şi rescrieri în bază, atunci se

verifică dacă se păstrează serializabilitatea şi dacă baza de date rămâne într-o stare

consistentă; dacă acest lucru nu se întâmplă, atunci se întrerupe.

Faza de scriere. Este o fază care este necesară numai la tranzacţiile care fac rescrieri.

Dacă faza anterioară s-a terminat cu succes, atunci actualizările efectuate în copia

locală, sînt înregistrate definitiv în baza de date.

Iată cum se desfşoară acest tip de control:

Fiecărei tranzacţii îi este ataşat, la începutul primei faze, un marcaj start(T), la

începutul celei de a doua faze, valid(T) şi la sfârşit fin(T), după scriere în copia locală,

dacăeste cazul. Ca să treacă faza de validare trebuie să avem una din următoare le situaţii:

1) Toate tranzacţiile cu un marcaj mai mic, trebuie să se fi terminat înainte ca

tranzacţia T să fi început; adică fin(S) < start(T).

2) Dacă tranzacţia start(S) < start(T) (S a început înaintea lui T) şi nu s-a terminat

adică fin(S) < fin(T) atunci:

Page 138: Baze de date_Iacob

137

a. Datele scrise de tranzacţia anterioară S nu sînt cele citite de cea curentă

T şi

b. Tranzacţia anterioară S îşi completează faza de scriere înainte ca

tranzacţia curentă T să intre în faza de validare adică start(T) < fin(S) <

valid(T).

Deşi tehnicile optimiste sînt eficiente când conflictele sînt rare totuşi pot apărea multe

reluări (rollback); să reţinem că aceste reluări nu sînt în cascadă pentru că se lucrează pe o

coppie locală.

Ce ne facem dacă apar totiţi inconsistenţe? Trebuie s{ [putem recupera baza de date

într-o stare anterioară consistentă.

Controlul recuperării. Din diferite motive se poate întâmpla ca baza de date să ajungă într-o stare incorectă

sau să se piardă de tot. Un SGBD trebuie să prevadă mecanisme de recuperare automată sau

manuală de recuperare a unei stări corecte a bazei de date şi posibilitatea de ajunge la zi cu

actualizările ulterioare.

O tranzacţie este formată din paşi mici care se execută pe rând şi când a început

acţiunea ‘commit’ ea nu s-a şi terminat. Datele sînt mai întâi duse într-un buffer (o memorie

internă intermediară) şi pe urmă scrise în bază (pe disc). Dacă între scrierea în buffer şi

scrierea pe disc apare vreo cădere, atunci SGBD-ul trebuie să reia scrierea (redo), iar dacă nu

s-au umplut bufferele şi a apărut o cădere atunci SGBD-ul trebuie să facă întreruperea şi

reluarea tranzacţiei (undo sau rollback).

Un SGBD trebuie să aibă un mecanism care să facă copii ale bazei de date şi jurnale

ale tranzacţiilor după care ele să poată fi refăcute. Copiile se fac autmat, fără intervenţii

manuale, şi recuperarea, în multe cazuri, trebuie să se facă tot automat.

M5.U5.5. Rezumat

Avem două tipuri de tehnici pentru controlul concurenţei.

Controlul pesimist se poate face cu blocaje prin protocolul în două faze sau cu

marcarea timpului.

Protocolul de blocare în două faze impune ca, într-o tranzacţie, după ce s-a făcut o

deblocare sa nu se mai facă nici o deblocare. putem, în acest caz să avem blocare

ciclică sau ROLLBACK în cascadă.

Protocolul cu marcarea timpului (time stamp) ataşează un timp fiecărei tranzacţii

(marc(T)) şi timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a

unei înregistrări. Deci fiecare tranzacţie va avea o valoare de marcaj şi fiecare

înregistrare prelucrată va avea două marcaje; unul care spune ce marcaj a avut

tranzacţia care a citit-o (cit_marc) şi celălalt care spune ce marcaj a avut tranzacţia

care a scris-o (scri_marc).

O tehnică optimistă înseamnă să lăsăm tranzacţiile să ruleze fără să impunem

întârzieri care să asigure serializabilitatea, iar când o tranzacţie vrea să facă

‘commit’, să efectuăm un control care să determine dacă a avut loc un conflict. Dacă

a avut loc un conflict, tranzacţia trebuie întreruptă şi restartată. Pentru că am spus că

Page 139: Baze de date_Iacob

138

aceeste conflicte sînt rare, aceste înteruperi şi restartări vor fi, şi ele, rare.

M5 U5.5 Test de autoevaluare a cunoştinţelor

5.5.1 Ce este blocajul?

5.5.2 Ce este blocaju ciclic? Exemplu.

5.5.3 Ce este protocolul de blocare în două faze?

5.5.4 Care este protocolul de control cu marcarea timpului (time stamp)?

5.5.5 Ce este o tehnică optimistă de control al concurenţei?

Răspunsurile se găsesc la sfârşit la pag 161

Page 140: Baze de date_Iacob

139

Unitatea de învăţare U5.6. Securitate şi integritate

M5U5.6 Introducere

M5.U5.6. Obiectivele unităţii de învăţare

La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

introducă regulile de integritate

să impună măsuri de securitate

Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Integritate

Integritatea bazelor de date se refera la corectitudinea informaţiilor şi presupune

detectarea, corectarea şi prevenirea diferitelor erori care pot afecta datele introduse în bazel e

de date. Cand facem referiri la integritatea datelor, întelegem că datele sunt consistente relativ

la toate restrictiile formulate anterior (care se aplica datelor respective) şi ca urmare a acestui

fapt, datele sunt considerate valide.

Conditiile de integritate numite şi reguli sau restrictii de integritate nu permit

introducerea in baza de date a unor date aberante şi sunt exprimate prin conditii puse asupra

datelor.

În general sunt acceptate mai multe criterii de clasificare a regulilor de integritate .

O serie de conditii sunt de tip structural, legate de anumite egalitati intre valori, şi exprimate

prin dependente functionale sau prin declararea unor campuri cu valori unice (de cele mai

multe ori aceste campuri sunt chei).

O alta serie de conditii se clasifica dupa unitatea la care se aplica restrictia si, in acest

caz, exista restrictii pe domenii (ce privesc anumite valori pentru atribute) sau restrictii pe

tabele (relatii). Restrictiile pe tabele pot fi unituplu (se refera la fiecare tuplu in parte) sau

multituplu (se refera la combinatii de mai multe tupluri).

O restrictie de integritate de relatie unituplu impune ca in fiecare tuplu al unei relatii

de baza, in campurile corespunzatoare cheii primare, sa apara valori diferite de valorile nule

corespunzatoare. Aceasta regula se mai poate enunta şi sub forma: "intr-o baza de date

relaţionala nu se inregistreaza nici o informatie despre ceva ce nu poate fi identificat."

Un exemplu de restrictie de integritate de relatie de tip multituplu este restrictia

referentiala care se exprima prin conditia ca, pentru cheile externe, daca nu sunt nule, sa se

admita valori corespunzatoare uneia din cheile primare existente in relatia referita. Verificarea

Page 141: Baze de date_Iacob

140

acestei conditii are loc de cate ori se insereaza un nou tuplu ce contine o cheie externa sau se

modifica valoarea unei chei externe a unui tuplu, semnalandu-se eventualele neconcordante şi

anuland modificarile. Verificarea unicitatii cheii primare şi restrictiile rezultate din

dependentele functionale şi multivaloare sunt alte exemple de acelasi tip.

Un alt criteriu de clasificare este acela prin care se deosebesc regulile de integritate ce

se refera la diferitele stari ale bazei de date de regulile ce se refera la tranzitia dintr-o stare in

alta.

Restrictiile pot fi clasificate şi din punct de vedere al momentului in care se aplica ele,

astfel avem reguli imediate (ce se verifica in momentul in care se efectueaza operatia indicata)

sau reguli amanate (ce se verifica numai dupa ce au fost executate şi alte operatii asociate dar

inainte de a se modifica baza de date).

În functie de aria de aplicare, restrictiile pot fi impartite in restrictii generale,

aplicabile tuturor relatiilor din baza de date şi restrictii particulare, care se pot aplica numai la

anumite relatii.

Regulile de integritate se aplica relatiilor de baza in care sunt reprezentate efectiv datele bazei

de date. Dintre regulile generale cel mai des folosite in modelul relaţional sunt regulile ce

privesc cheile primare (vezi unicitatea valorilor cheilor primare in cadrul relatiei) şi cheile

externe.

Analizam in continuare cateva tipuri de restrictii de integritate.

I. Restrictii pentru integritatea entitatii

Enunt: Intr-o relatie de baza nici un atribut al unei chei primare nu poate avea valori nule.

Deja cunoastem ca se cere (in multe situatii) ca valorile cheilor primare sa fie unice. In

majoritatea SGBD unicitatea cheii primare şi integritatea entitatii sunt conditii obligatorii.

II. Restrictii pentru integritatea referentiala

Enunt: Daca exista o cheie externa intr-o relatie, ori valoarea cheii externe trebuie sa se

potriveasca cu valoarea unei chei candidat a vreunui tuplu in relatia de origine, ori valoarea

cheii externe trebuie sa fie nula.

Cu late cuvinte, daca o valoare exista intr-o relatie pe post de cheie externa, ori ea trebuie sa

se potriveasca cu valoarea unei chei primare dintr-o alta relatie ori sa fie nula.

Probleme serioase apar in momentul cand sunt de efectuat modificari sau stergeri de valori ale

cheilor primare.

Daca se actualizeaza o cheie primara sau se sterge intregul tuplu şi daca

1) valoarea cheii primare nu apare nicaieri ca şi cheie externa

atunci se permite efectuarea operatiei

2) valoarea cheii primare apare in alta parte ca şi cheie externa

atunci

a) nu se permite efectuarea operatiei

b) se permite efectuarea operatiei dar de asemenea se seteaza aparitiile cheii externe

la valorile nule sau o valoare implicita (daca s-a specificat vreuna)

c) se permite efectuarea operatiei dar de asemenea

Page 142: Baze de date_Iacob

141

(i) in cazul actualizarii – se propaga valoarea schimbata la aparitiile cheii

externe unde cheia externa este o parte a cheii primare a relatiei si, de

asemenea, se propaga schimbarile acolo unde aceasta din urma cheie

primara este cheie externa intr-o alta relatie

(ii) in cazul stergerilor – se propaga stergerea , adica se sterg tuplele care au

valori ale cheii externe care se potrivesc cu cheia primara

d) se intra in dialog cu utilizatorul

Toate acestea sunt reguli generale care, dupa caz, pot suferi mici transformari, in functie de

aplicaţia concreta.

Situatiile descrise mai sus pot fi rezolvate in cadrul aplicaţiei sau se pot include in SGBD

utilizand mecanismul trigger-elor. Mai multe SGBD permit sa se creeze şi sa se memoreze

proceduri referitoare la baza de date şi aceste proceduri pot fi invocate cand au loc anumite

evenimente, cum ar fi actualizari şi stergeri ale unor atribute.

Standardul SQL furnizeaza controale pentru integritatea referentiala in declaratiile de creare a

tabelelor.

III. Restrictiile de domeniu

Aceste restrictii sunt intotdeauna restrictii de stare imediate. Aceste restrictii se pot referi la

tipul de date pentru un atribut, la o lista de valori posibile, la un ordin de marime, la un format

sau o forma, la o conditie exprimata cu o formula logica sau la o procedura care este apelata

de cate ori are loc o modificare pentru domeniul specificat.

Exemplu: Restrictiile de domeniu referitoare la o data calendaristica pot fi exprimate

(eventual) in felul urmator:

create domain ZI char(2)

check is_integer(ZI) and num(ZI) >= 1 and num(ZI) <= 31;

create domain LUNA char(2)

check is_integer(LUNA) and num(LUNA) >= 1 and num(LUNA) <= 12;

create domain AN char(2)

check is_integer(AN) and num(AN) >= 0 and num(AN) <= 99;

create domain DATA(ZZ domain(ZI), LL domain(LUNA), AA domain(AN))

check if num(LL) in (1,3,5,7,8,10,12) then num(ZZ) < 31;

check if num(LL) in (4,6,9,11) then num(ZZ) < 30;

check if num(LL) = 2 and mod(num(AA),4) = 0 and

mod(num(AA),100) <> 0 then num(ZZ) < 29;

check if num(LL) = 2 and mod(num(AA),4) <> 0

then num(ZZ) < 28;

Restrictiile de integritate pot fi exprimate prin intermediul limbajului de prelucrare a datelor

sub forma unei egalitati sau ca o relatie intre rezultatele a doua cereri.

Integritatea datelor este strans corelata cu securitatea datelor unei baze de date.

Daca se definesc controalele de securitate in absenta celor de integritate, validitatea şi

consistenta datelor se bazeaza exclusiv pe utilizarea corecta şi de buna credinta a sistemului

de catre utilizatorii autorizati. Daca insa se definesc numai controale de integritate, datele au

sansa sa fie consistente dar sunt susceptibile la pericolele care provin din lipsa securitatii.

Page 143: Baze de date_Iacob

142

Este important de mentionat aici ca restrictiile de integritate nu garanteaza corectitudinea

datelor. Aceasta deoarece este aproape imposibil (in multe situatii) ca verificarea

corectitudinii sa fie realizata automat.

Exemplu: Nu se poate verifica automat daca numele unei persoane este "Pop" sau "Popa",

cum nu se poate verifica automat daca data nasterii este "10.01.2001" sau "01.01.2001", et c.

Pentru a asigura un grad multumitor de integritate a datelor trebuie prevazute restrictii de

integritate in asociere cu principalele momente in care datele respective sunt manipulate, cum

ar fi: introducerea, actualizarea şi stergerea. Acestea sunt operatii susceptibile de introducerea

de date inconsistente in baza de date.

Restrictiile de integritate pot fi memorate in multe cazuri chiar in SGBD, dar gradul in care

acest lucru este posibil depinde de SGBD.

Asociata cu integritatea datelor este şi protectia datelor impotriva unor evenimente de avarie

cum ar fi caderea sistemului cauzata de defectarea unor componente hardware sau software.

Pierderea accidentala de consistenta a datelor poate rezulta din:

-incidente ce apar pe parcursul executarii tranzactiilor,

-anomalii datorate accesului concurent la baza de date,

-anomalii datorate lucrului cu date distribuite pe mai multe calculatoare intr-o retea,

-erori logice care apar din programele utilizator,

si altele.

Pentru reconstituirea bazelor de date in cazul cand pot sa apara inconsistente in

general, majoritatea bazelor de date se copiaza periodic pe medii magnetice ce se pastreaza in

locuri sigure. De asemenea se tine o evidenta a tuturor transformarilor efectuate in baza de

date de cand s-a efectuat ultima copie. Fisierul care contine aceste modificari se numeste

jurnal. Fiecare inregistrare din jurnal contine un identificator al programului care a facut

modificarea, fosta valoare şi noua valoare introdusa pentru un element. Tot in jurnal se mai

pastreaza diferitele momente importante din desfasurarea programelor (inceput, sfarsit,

terminarea unor operatii, etc.). Toate mecanismele mentionate in acest paragraf sunt

caracteristice lucrului cu tranzactii. La terminarea unei tranzactii, indiferent daca ea s-a

incheiat normal sau prin eroare, baza de date trebuie sa aiba acelasi grad de integritate ca la

momentul inceperii executiei tranzactiei respective.

Se spune despre o tranzactie ca este comisa daca au fost terminate toate calculele

produse de ea in aria de lucru şi s-a facut o copie a rezultatelor ei in jurnal. Aparitia unor

caderi dupa ce o tranzactie a fost comisa nu afecteaza continutul bazei de date deoarece se

poate reconstitui baza de date cu ajutorul ultimei copii şi a jurnalului in care se gasesc toate

rezultatele tranzactiilor comise. Modificarile tranzactiilor abandonate sau necomise nu sunt

luate in considerare la parcurgerea jurnalului pentru restaurarea bazei de date.

Se defineste strategia de comitere in doua faze astfel: o tranzactie poate sa scrie intr-o

baza de date numai dupa ce a fost comisa şi o tranzactie poate fi comisa numai dupa ce a

inregistrat in jurnal toate schimbarile de elemente produse de ea.

Securitate

Prin securitatea bazelor de date se intelege protejarea bazelor de date impotriva folosirii

neautorizate a lor şi in special a modificarilor şi distrugerilor nedorite de date şi a citirilor

Page 144: Baze de date_Iacob

143

nepermise de date. Pentru realizarea securitatii datelor din baza de date se utilizeaza controale

tehnice şi administrative.

Securitatea este in general asociata cu urmatoarele situatii:

-acces fraudulos la date,

-pierderea confidentialitatii (secretului) datelor,

-pierderea caracterului privat al datelor,

-pierderea integritatii datelor,

-pierderea disponibilitatii datelor

Este mai dificila protejarea datelor impotriva accesului rauvoitor, intentionat. Se

recunoaste ca de fapt nu exista protectie absolut sigura ci doar protectii şi masuri de securitate

mai eficiente sau mai putin eficiente.

Forme de acces intentionat şi rauvoitor la datele unei baze de date:

-citire neautorizata a unor date,

-modificari neutorizate de date,

-distrugeri de date.

Notiunea de securitate a bazei de date este de obicei asociata cu accesul rauvoitor, pe

cand integritatea se refera la evitarea pierdelor accidentale de consistenta. Adevarul este insa

undeva la mijloc.

Pentru protectia bazei de date se pot lua masuri de asigurare a securitatii la mai multe

nivele:

-la nivel fizic - locurile in care se afla calculatoarele trebuie protejate de accesul

persoanelor neautorizate;

-la nivel uman – este recomandabil sa se acorde autorizatiile de acces cu multa grija şi

sa se tina evidente stricte ale persoanelor autorizate

-la nivel sistem de operare – slabiciunile protectiei la nivel de sistem de operare

trebuie eliminate sau compensate de alte masuri

-la nivel SGBD – sistemul ofera anumite facilitati care sprijina protectia datelor

Tehnici de asigurare a securitatii datelor:

1. Identificarea utilizatorilor.

Fiecarui utilizator in parte i se acorda anumite drepturi de operare pe diferite portiuni din baza

de date la diferite nivele cum ar fi relatia, inregistrarea, pagina, atributul, etc. Drepturile se

refera la posibilitatea citirii, inserarii, stergerii sau modificarii datelor respective. Identificarea

se face de obicei prin parole stabilite fie de administratorul bazei de date fie de utilizator.

2. Protejarea datelor prin codificare (criptare).

Deoarece s-ar putea ajunge la date şi prin alte mijloace decat prin intermediul SGBD-ului (de

exemplu prin citirea directa a mediului magnetic) se poate face o protectie prin pastrarea

codificata a datelor pe mediul magnetic. Decodificarea datelor se poate face numai dupa

identificarea utilizatorului prin garzi asociate lui.

3. Utilizarea view-urilor in aplicaţii.

Page 145: Baze de date_Iacob

144

Abilitatea view-urilor de a "ascunde" o parte din informatiile din baza de date poate fi

utilizata şi pentru stabilirea unui anumit grad de securitate a datelor. Astfel se poate vorbi de

acces la nivel de relatie (tabela) sau acces la nivel de view.

In unele sisteme nu sunt acceptate modificari prin intermediul view-urilor. Astfel de view-uri

se numesc read-only (numai pentru citire) şi sunt utilizate mai ales in aplicaţiile in care datele

pot fi citite de toti utilizatorii (baze de date publice) dar modificarile se fac numai cu

aprobarea administratorului/proprietarului bazei de date.

Modificarile din view-uri nu sunt in general admise deoarece pot duce la efecte laterale ce

privesc parti din baza de date ce nu apar in view-uri. De exemplu stergerea unui element din

view poate sa duca la eliminarea unui alt element care are singura legatura cu elemntul sters şi

care nu se afla in view.

4. Administrarea şi transmiterea drepturilor.

Se tine evidenta stricta a drepturilor de acces ale fiecarui utilizator la portiuni din baza de

date şi se fixeaza reguli de transmitere de la un utilizator la altul a dreptului de acces.

Forme de autorizare:

-autorizare la citire (consultare)

-autorizare la inserare (adaugare)

-autorizare la actualizare (care exclude stergerile)

-autorizare la stergeri (la nivel de tuplu)

În situatiile de mai sus nu se pune problema modificarilor la nivel de schema a bazei

de date.

Daca consideram şi acest aspect putem vorbi de:

-autorizare la nivel de index (creare-stergere de indexi)

-autorizare la nivel de relatii (creare)

-autorizare de modificari la nivel de relatii (stergeri sau adaugari de atribute in cadrul

relatiilor)

-autorizari de stergeri ale relatiilor

Diferitele protectii pot fi indicate prin intermediul limbajului de prelucrare a datelor.

Portiunile din baza de date ce pot fi folosite de utilizator pot fi definite prin operatii de selectie

şi proiectie care fac invizibile alte portiuni ale bazei de date.

Conducerea organizatiei, care este proprietara bazei de date, trebuie sa ia masuri de

securitate care reduc riscul de a se pierde informatii sau de a se distruge informatii. Prin

pierdere de informatii se poate intelege ca se pierde caracterul privat al informatiilor, ele

devin accesibile unui grup mai mare de persoane decat cel prevazut. Nu intotdeauna

"scurgerile" de informatii lasa urme, deci nu se materializeaza intotdeauna in schimbari

detectabile la nivelul bazei de date.

Problema securitatii cuprinde aspecte legale, sociale şi etice, aspecte privind controlul

fizic (paza şi posibilitati de blocarea accesului la terminale), aspecte de politie (fixarea

conditiilor de acces), aspecte operationale (modul de stabilire a parolelor), aspecte privind

controlul hard (modul de acces hard la diferite componente), securitatea sistemului de operare

(protejarea informatiilor şi anularea rezultatelor intermediare pentru pastrarea secretului

Page 146: Baze de date_Iacob

145

datelor) aspecte privind notiunea de proprietate asupra datelor din baza de date şi altele

asemanatoare.

Trebuie sa mentionam aici ca furturile şi fraudele nu sunt neaparat legate de baza de

date, ele sunt un factor de risc pentru intreaga organizatie, gravitatea acestor fapte depinzand

şi de profilul organizatiei in cauza.

În Comunitatea Europeana exista o preocupare serioasa legata de actualizarea

legislatiei la noile nevoi generate de utilizarea intensiva a calculatoarelor. Se incearca in

principal sa se adopte legi care sa protejeze persoana sau organizatia şi sa tina seama de

nevoia ca anumite informatii sa aiba caracter privat, deci sa nu fie accesibile publicului larg

sau nici macar unui grup relativ restrans, daca acest fapt ar dauna proprietarului informatiilor

respective. Putem enumera aici o paleta larga de domenii care lucreaza cu informatii al caror

caracter privat trebuie neaparat pastrat: domeniul bancar, domeniul medical, evidente

administrativ-financiare, domeniul productiei in majoritatea firmelor de marca, etc.

M5.U5.6. Rezumat

Integritatea bazelor de date se refera la corectitudinea informaţiilor şi presupune

detectarea, corectarea şi prevenirea diferitelor erori care pot afecta datele introduse

în bazele de date. Cand facem referiri la integritatea datelor, întelegem că datele sunt

consistente relativ la toate restrictiile formulate anterior (care se aplica datelor

respective) şi ca urmare a acestui fapt, datele sunt considerate valide.

Tipuri de restrictii de integritate.

Restrictii pentru integritatea entitatii.

Restrictii pentru integritatea referentiala

Restrictiile de domeniu

Prin securitatea bazelor de date se intelege protejarea bazelor de date impotriva

folosirii neautorizate a lor şi in special a modificarilor şi distrugerilor nedorite de

date şi a citirilor nepermise de date.

Securitatea este in general asociata cu urmatoarele situatii:

-acces fraudulos la date,

-pierderea confidentialitatii (secretului) datelor,

-pierderea caracterului privat al datelor,

-pierderea integritatii datelor,

-pierderea disponibilitatii datelor

Pentru protectia bazei de date se pot lua masuri de asigurare a securitatii la mai

multe nivele:

-la nivel fizic - locurile in care se afla calculatoarele trebuie protejate de

accesul persoanelor neautorizate;

-la nivel uman – este recomandabil sa se acorde autorizatiile de acces cu

multa grija şi sa se tina evidente stricte ale persoanelor autorizate

-la nivel sistem de operare – slabiciunile protectiei la nivel de sistem de

operare trebuie eliminate sau compensate de alte masuri

Page 147: Baze de date_Iacob

146

-la nivel SGBD – sistemul ofera anumite facilitati care sprijina protectia

datelor

Tehnici de asigurare a securitatii datelor:

1. Identificarea utilizatorilor.

2. Protejarea datelor prin codificare (criptare).

3. Utilizarea view-urilor in aplicaţii.

4. Administrarea şi transmiterea drepturilor.

M5.U5.6. Test de autoevaluare a cunoştinţelor

5.6.1 Care sunt restricţiile de integritate?

5.6.2 Ce înseamnă integritatea entitatii?

5.6.3 Ce înseamnă integritatea referentiala?

5.6.4 Ce înseamnă restrictiile de domeniu?

5.6.5 Care este deosebirea între integritate şi securitate?

5.6.6 Cum poate fi încălcată securitatea datelor într-o baza de date ?

5.6.7 Enumeraţi măsuri de protecţie pentru asigurerea securităţii datelor.

5.6.8 Enumeraţi forme de autorizare.

Răspunsurile se găsesc la sfârşit la pag 162

Page 148: Baze de date_Iacob

147

Raspunsuri la testele de autoevaluare. Unitatea 1.2

1.2.1 Ce ar trebui memorat despre profesori într-o bază de date a facultăţii?

Nume, adresa,adresa de e-mail,grad didactic,sex

1.2.2 Ce nu ar trebui memorat despre profesori într-o bază de date a facultăţii?

Pasiuni, înălţime, greutate, culoarea părului

1.2.3 Ce este arhitectura pe trei nivele?

Arhitectura ANSI-SPARC pe trei nivele

Unitatea 1.3

1.3.1 Care sunt obiectivele unui SGBD?

Bazei de date îi revin o serie de obiective, cum sunt:

-Asigurarea independenţei datelor.

-Asigurarea unei redundanţe minime şi controlate a datelor din baza de date.

View 1

View 2

View n

Schema

conceptuala

Schema

interna

Baza de

date

Nivel

extern

Nivel

conceptual

Nivel

intern

Organizarea la

nivel fizic a datelor

…..

Page 149: Baze de date_Iacob

148

- Asigurarea unor facilităţi sporite de utilizare a datelor

- Sporirea gradului de securitate a datelor împotriva accesului neautorizat la date.

-Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate,

prin intermediul unor proceduri de validare, a unor protocoale de control concurent şi a unor

proceduri de refacere a bazei de date după incidente.

-Asigurarea partajabilitatii datelor. Partajabilitatea datelor trebuie inţeleasă nu numai

sub aspectul asigurarii accesului mai multor utilizatori la aceleaşi date, ci şi acela al

posibiliăţtii dezvoltarii unor aplicaţii fără a se modifica structura bazei de date.

1.3.2 Care sunt funcţiunile unui SGBD?

1. Funcţia de descriere a datelor permite definirea structurii bazei de date cu ajutorul

limbajului de definire. Definirea datelor poate fi realizată la nivel logic, conceptual şi fizic.

Aceasta funcţie asigură:

-descrierea atributelor (câmpurilor) din cadrul structurii bazei de date,

-descrierea legăturilor dintre entităţile bazei de date sau dintre atributele aceleiasi

entităţi,

-definirea eventualelor criterii de validare a datelor,

-definirea metodelor de acces la date,

-definirea aspectelor referitoare la asigurarea integrităţii si confidenţi alităţii datelor, etc.

2. Funcţia de manipulare a datelor este cea mai complexă funcţie şi realizează

urmatoarele activităţi:

- crearea (incarcarea) bazei de date;

- adaugarea de noi inregistrări;

- ştergerea unor inregistări;

- modificarea valorilor unor câmpuri;

- căutarea, sortarea şi editarea parţială sau totală a unei inregistrări virtuale etc.

3. Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor

utlizatorilor cu baza de date. Sunt recunoscute mai multe categorii de utilizatori:

- utilizatori "liberi" sau conversaţionali. Aceaştia reprezintă categoria beneficiarilor de

informaţii (utilizatori finali) care utilizează limbajele de interogare a bazei de date intr-o

formă simplistă. Ei apar ca utilizatori neinformaticieni;

- utilizatori programatori, care utilizează limbajele de manipulare, realizând proceduri

complexe de exploatare a bazei de date;

- administratorul bazei de date apare ca un utilizator special şi are rolul hotarâtor în ceea

ce priveşte funcţionarea optimă a întregului ansamblu.

4. Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de competenţa

administratorului bazei de date.

Page 150: Baze de date_Iacob

149

Unitatea 1.4

1.4.1 Ce este o bază de date distribuită?

1) Un SGBDD constă dintr-o singură bază de date care este descompusă în

fragmente, eventual unele fragmente sunt multiplicate, şi fiecare fragment sau

copie se pastrează pe unul sau mai multe site-uri, sub controlul unui SGBD local.

Fiecare site este capabil sa proceseze interogări utilizator în regim local,

independent de restul reţelei, sau este capabil să participe la procesarea unor date

situate în alte site-uri din reţea. Pentru a spune că un SGBD este distribuit trebuie

să existe cle puţin o cerere globală.

1.4.2 Care sunt avantajele unui sistem distribuit?

2) Avantajele distribuirii bazelor de date sunt:

- sistemul distribuit se modelează cel mai bine pe structura organizaţională a multor

organizaţii, avand în vedere ca multe companii sunt localizate "distribuit" din punct de

vedere geografic

- datele sunt partajabile dar administrarea lor se bucură de un grad înalt de autonomie locală

- disponibilitatea bazei de date este evident mai bună decât în cazul centralizat. Dacă se

semnalează unele erori sau "ăderi" de sistem la nivel local sistemul ]n întregime poate să

continue să funcţioneze în condiţii satisfăcătoare

- fiabilitatea sistemului este îmbunătăţită. Se pot reface rapid fişiere distruse utilizând

replici aflate pe alte site-uri

- performanţele în prelucrarea datelor se îmbunătăţesc prin posibilitatea prelucr[rii în

paralel a unor interog[ri

- un sistem distribuit oferă avanatje economice dacă luăm în considerare costurile

implementării şi întreţinerii unei reţele faţă de costurile corespunzătoare ale unui sistem

centralizat de putere comparabilă de prelucrare. Costuri scazute se mai obtin daca se

realizeaza prelucrări locale cât mai multe (în cază sistemul şi aplicaţiile permit acest

lucru). De asemenea este mult mai convenabil să se "ajusteze" o reţea de calculatoare la

nevoile organiza’iei (dacă de exemplu este necesară adăugarea unor site-uri în plus) decât

un calculator central de putere asemănătoare

- capacitatea de gestionare modulară a sistemului permite extensii ale acestuia sau

rezolvarea unor "căderi" parţiale fără să se afecteze prea tare (uneori fără a se afecta

deloc) mersul activităţilor pe ansamblul sistemului distribuit.

1.4.3 Cum se poate face proiectarea alocării datelor?

Proiectarea corectă a unei baze de date relaţionale distribuite necesită, pe lângă cerinţele

cunoscute pentru sistemele centralizate, şi realizarea următoarelor:

- fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi stocate

pe diferite site-uri în reţea

- replicarea – se pot realiza copii ale diferitelor relaţii sau ale fragmentelor

- alocarea fragmentelor şi a replicilor pe diferite site-uri

Se cunosc patru strategii de alocare a datelor într-o baza de date relaţională distribuită:

Page 151: Baze de date_Iacob

150

a!. centralizat

Baza de date se află în întregime pe un singur site din reţea şi este gestionată de un singur

DBMS. Spunem în acest caz că baza de date este procesată distribuit, ea de fapt nu mai

este o bază de date distribuită in adevaratul sens al cuvântului. Dezavantajele sunt mai ales

costurile mari de comunicaţii şi o fiabilitate şi o disponibilitate foarte scăzute, având în

vedere că orice eroare care blochează accesul la baza de date, practic paralizează întreaga

activitate în reţea pe această direcţie.

a2. fragmentat (partiţionat)

Baza de date este partiţionată în mai multe fragmente disjuncte care sunt stocate pe

diverse site-uri. Comentarii:

- aceasta parţitionare a datelor poate îmbunătăti frecvenţa referinţelor locale

- dacă nu există replici ale fragmentelor, costurile de stocare sunt reduse

- fiabilitatea şi disponibilitatea sunt scăzute dar nu aşa de mici ca în cazul centralizat

- dacă datele sunt distribuite corect, costurile de comunicare pot fi relativ scăzute

a3. replicat complet

Pe fiecare site se găseste o copie completă a bazei de date. Comentarii:

- eficienţa referirilor locale, fiabilitatea şi disponibilitatea sunt maxime

- costurile de stocare sunt în schimb şi ele foarte mari, la fel sunt şi costurile de

actualizare

a4. replicat selectiv

Aceasta strategie este o combinaţie intre partiţionare, replicare şi centralizare cu scopul de a

se cumula, pe cat posibil, avantajele fiecărei strategii şi să se elimine dezavantajele.

1.4.4 Cum se face o fragmentare corectă?

Reguli de bază care duc la o fragmentare corectă a bazei de date:

- completitudine – dacă relaţia R este descompusă în fragmentele R1, R2, …,Rn, trebuie

luate măsuri care să prevină pierderea de informaţii

- reconstrucţie – să fie posibil în orice moment să se refacă relaţia R de la care s -a pornit

cu fragmentarea. Aceasta regulă conservă dependenţele funcţionale.

- disjuncţie – dacă data di apare în fragmentul Ri atunci nu este permis să apară în nici un alt

fragment. De la această regulă se admite doar o excepţie, cazul când o relaţie este

fragmentată pe verticală.

1.4.5 Ce este fragmentarea?

Tipurile de fragmentare sunt:

- pe orizontală

- pe verticală

- combinată

Fragmentarea pe orizontală:

Page 152: Baze de date_Iacob

151

Ne putem imagina că o tabelă se fragmentează orizontal ca mai jos:

Un fragment al unei relaţii partitionate pe orizontală constă dintr-o submulţime a tuplelor

relaţiei respective.

Un fragment orizontal se produce prin selecţie:

Fiecare tuplu din relatia R apare într-un anume fragment, o singură dată. Dacă se doreşte

reconstrucţia relaţiei, se utilizează reuniunea pentru a obţine relaţia R iniţiala.

R= R1R2…Rn

In general fragmentele unei relaţii R sunt disjuncte.

Fragmentarea pe verticală

Un fragment vertical dintr-o relaţie constă dintr-o relaţie care are ca atribute o submulţime a

atributelor relaţiei iniţiale.

Un fragment vertical se produce prin proiecţie:

Dacă S1R şi S2R atunci )(11 Rr S şi )(22 Rr S .

Completitudinea este asigurată prin faptul că fiecare atribut apare cel puţin într- una din

submulţimile S1 şi S2.

Reconstrucţia relaţiei iniţilale se realizează prin joncţiune naturală.

21)( rXrRr N

Aşadar la descompunerea relaţiei iniţiale în fragmente trebuie să se ţină seama de regulile care

asigură o descompunere fără pierderi la joncţiune.

In cazul descompunerii pe verticală nu este posibil să se realizeze o disjuncţie totală. Se

admite existenţa unor atribute comune, şi anume a atributelor care formează cheile primare

(respectiv cheile externe).

Fragmentarea combinată (mixtă, hibridă, compusă)

Se poate face din fragmente verticale fragmentate orizontal:

Expresia corespunzatoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai

sus) este: ))(( ,...,1R

nAAP

Sau se poate face din fragmente orizontale fragmentate vertical

Page 153: Baze de date_Iacob

152

Expresia corespunzătoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai

sus) este: ))((,...,1RPAA n

.

Unitatea 2.1

2.1.1 Care sunt modele de date bazate pe înregistrare?

Exista trei tipuri importante de modele de date bazate pe inregistrare: modelul de date

relaţional, modelul de date retea şi modelul ierarhic de date.

Unitatea 2.2

2.2.1 Găsiţi cheile candidat ale tabelei student. Stabiliţi cheia primară.

Student=(nrmatricol,cnp,nume,adresa,nrtelefon,sex,grupa,datanasterii)

chei candidat:

nrmatricol

cnp

nume,adresa

nrtelefon

cheia principală va fi nrmatricol pentru că:

cnp este mai lung

nume,adresa are două componente şi adresa se poate schimba

nrtelefon se poate schimba.

2.2.2 Daţi exemple de relaţii unu la unu, unu la mai mulţi şi mulţi la mulţi.

Relaţia editură carte este de unu la mai mulţi pentru că o editură editează mai mul te cărţi dar o

anumită carte este scoasă de o singură editură (vez ISBN care este unic),

Relaţia student materii este de mulţi la mulţi pentru că un student face mai multe materii şi o

materie ete făcută de mai mulţi studenţi.

2.2.3 Stabiliţi domeniul fiecărui atribut din tabela profesor.

profesor=(Nume, adresa,adresa de e-mail,grad didactic,sex)

nume Alfabetic

adresa compus

adresa de e-mail şir de caractere urmat de @ şi de alt şir de caractere

grad didactic La alegere din mulţimea(preparator,asistent,lectoe,conferenţiar,profesor)

sex una din două M sau F

Unitatea 3.1

Cosideraţi instanţe ale tabelei student, profesor,materii şi catalog.

1 Ion ion 7271

5 Dan soc 7271

7 Pan tor 7273

15 Prof1 Bv lunga 22

23 Prof2 Fag oltet 34

1 Baze de date

2 Algoritmica

Page 154: Baze de date_Iacob

153

3 Structuri de date

nrmatricol codmaterie nota

1 1 5

1 2 8

5 3 4

7 1 3

7 3 9

e) Faceţi selecţie din student după grupa 7271

1 Ion ion 7271

5 Dan soc 7271

f) Faceţi proiecţie la student şi la profesor după nume. La acestea două din urmă fac eţi

reuniunea.

Ion ion

Dan soc

Pan tor

Prof1

Prof2

g) Faceti joncţiunea naturală intre student şi catalog apoi între rezultat şi materii.

nrmatricol numestd grupa codmaterie denmaterie nota

1 Ion ion 7271 1 Baze de date 5

1 Ion ion 7271 2 Algoritmica 8

5 Dan soc 7271 3 Structuri de

date

4

7 Pan tor 7273 1 Baze de date 3

7 Pan tor 7273 3 Structuri de

date

9

h) Faceţi selecţia tabelei de mai nainte după nota < 5.

nrmatricol numestd grupa codmaterie denmaterie nota

5 Dan soc 7271 3 Structuri de

date

4

7 Pan tor 7273 1 Baze de date 3

3.1.2 Să se exprime în algebra relaţională cererile:

e) Studenţii grupei 7271

grupa=7271(student) f) Studenţii care sunt şi profesori

Page 155: Baze de date_Iacob

154

nume(student) nume (profesor)

g) Studenţii corigenţi

nume(nota<5 (student jN catalog jN note))

h) Studenţii integralişti

nume5 (student) \ nume(nota<5 (student jN catalog jN note))

Unitatea 3.2

Se dau următoarele relaţii cu schemele lor:

-Scări (Nr_bloc, Scara, Lift)

-Apartamente(Nr_bloc,Scara,Apartament,Suprafaţa,Cutii_poştale, Nr_prize_tv)

- Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)

-Locatari Nr_Mat, Nr_bloc, Scara, Etaj, Apartament,Nume

Să se exprime în SQL cererile:

3.2.1 (tabel nominal cu locatarii de pe scara = 3 din bloc = 34) = R1

select nume

from scari, locatari

where (scari.bloc=34) and(scari.bloc = locatari.bloc)

and (scari.scara=3) and (scari.scara= locatar.scara)

3.2.2 (tabel nominal cu locatarii de pe scara = 1 din bloc = 34) = R2

select nume

from scari, locatari

where (scari.bloc=34) and(scari.bloc = locatari.bloc)

and (scari.scara=1) and (scari.scara= locatar.scara)

3.2.3 (tabel nominal cu locatarii de pe scara = 2 din bloc = 34) = R3

select nume

from scari, locatari

where (scari.bloc=34) and(scari.bloc = locatari.bloc)

and (scari.scara=2) and (scari.scara= locatar.scara)

3.2.4 tabel nominal cu locatarii de pe scările 1,2,3 ale blocului 34

select nume

from scari, locatari

where (scari.bloc=34) and(scari.bloc = locatari.bloc)

and (scari.scara=3) and (scari.scara= locatar.scara)

union select nume

from scari, locatari

where (scari.bloc=34) and(scari.bloc = locatari.bloc)

and (scari.scara=1) and (scari.scara= locatar.scara)

union select nume

from scari, locatari

Page 156: Baze de date_Iacob

155

where (scari.bloc=34) and(scari.bloc = locatari.bloc)

and (scari.scara=2) and (scari.scara= locatar.scara)

3.2.5 lista apartamentelor cu suprafaţa mai mare decât 50 mp

select Nr_bloc,Scara,Apartament

from apartamente

where suprafaţa > 50

3.2.6 tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 şi nu locuiesc şi pe scara 1 a

aceluiaşi bloc

select nume

from scari, locatari

where (scari.bloc=34) and(scari.bloc = locatari.bloc)

and (scari.scara=3) and (scari.scara= locatar.scara)

and not in ( select nume

from scari, locatari

where (scari.bloc=34) and(scari.bloc locatari.bloc)

and (scari.scara=1) and (scari.scara= locatar.scara))

Unitatea 4.1

4.1.1 Dependenţele funcţionale din tabela:

Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota)) sunt:

nrmatricol nume

nrmatricol adresa

nrmatricol,codmaterie nota

codmaterie denumirematerie

4.2.1 Fie tabela din enunţ:

Cod

Furn.

Denumire Cod

fiscal

Nr.

Crt.

Cod

Chelt.

Denumire

Cheltuială

Valoare

F100 Romgaz R1234567 1 C15 Chelt pt. Încălzire 1500000

2 C16 Chelt pt. Bucătării 500000

F110 Renel R7654321 3 C10 Chelt cu iluminatul 3000000

4 C11 Chelt pt. Func. liftului 200000

În această tabelă observăm că pentru furnizorul “Romgaz” avem două tipuri de

cheltuieli. Grupul de atribute (nr.crt., cod chelt., denumire cheltuială, valoare) apare de mai

multe ori. Pentru a transforma această tabelă în 1NF, trebuie să avem o singură valoare la

fiecare intersecţie linie coloană.

În cazul primei modalităţi, scriem repetiţiile pe diferite rânduri iar coloanele care nu

conţin repetiţii, vor fi copiate pe fiecare rând. După despărţirea repetiţiilor pe mai multe

rânduri, identificăm o nouă cheie.

Cod

Furn.

Denumire Cod

fiscal

Nr.

Crt.

Cod

Chelt.

Denumire

Cheltuială

Valoare

F100 Romgaz R1234567 1 C15 Chelt pt. Încălzire 1500000

F100 Romgaz R1234567 2 C16 Chelt pt. Bucătării 500000

F110 Renel R7654321 3 C10 Chelt cu iluminatul 3000000

F110 Renel R7654321 4 C11 Chelt pt. Func. liftului 200000

Tabela Furnizori_Cheltuieli în 1NF creată prin prima modaliate de transformare.

Page 157: Baze de date_Iacob

156

În tabela normalizată, noua cheie va fi (Cod Furn., Nr. Crt ., Cod Chelt.).

Normalizând tabela iniţială după a doua modalitate, vom crea o a doua tabelă cu

informaţiile care nu se repetă, împreună cu cheia primară din tabela iniţială. Deci cele două

tabele vor fi următoarele:

Furnizori (Cod Furn., Denumire, Cod fiscal)

Cheltuieli (Cod Furn., Cod Chelt., Nr. Crt., Denumire cheltuială, Valoare)

Cele două tabele astfel create sunt în 1NF:

4.2.2 Fie R = (Cod Furn., Denumire, Cod fiscal, Cod Chelt., Denumire cheltuială, Nr. Crt.,

Cod, Valoare)

Vom avea dependentele functionale:

K = (Cod Furn., Cod Chelt., Nr. Crt.) R deci K este cheie.

d1 Cod Chelt Denumire cheltuială

d2 Cod Furn (Denumire, Cod fiscal)

Dependenţele d1 şi d2 sunt dependenţe parţiale de cheie.

Relaţiile rezultate au următoarea formă:

Furnizori = (Cod Furn., Denumire, Cod fiscal)

Tip cheltuială = (Cod Chelt., Denumire cheltuială)

Cheltuieli = (Nr. Crt., Cod Furn., Cod Chelt., Valoare)

Fie relaţia din enunţ:

carte = (c_carte, titlu, cod_domeniu, den_domeniu) cu cheia c_carte. În afara dependenţelor

care definesc cheia mai avem dependenţa:

cod_domeniu den_domeniu şi pentru că c_carte este cheie avem şi

c_carte cod_domeniu deci den_domeniu depinde tranzitiv de cheie.

Prin descompunere rezultă două scheme 3NF:

carte1 = (c_carte, titlu, cod_domeniu) şi

domeniu = (cod_domeniu, den_domeniu).

Fie relaţia:

Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota))

Are grup repetitiv deci nu este FN1.

se descompune în:

stud1=( nrmatricol,nume,adresa) care este FN3 şi

stud2=( nrmatricol,codmaterie,denumirematerie,nota) unde avem dependenţele funcţionale:

nrmatricol,codmaterie nota

codmaterie denumirematerie aceasta fiind dependenţă parţială de cheie deci nu este FN2

se obţine forma finaţă:

stud1=( nrmatricol,nume,adresa)

catalog=( nrmatricol,codmaterie,nota)

materii=( codmaterie,denumirematerie)

Unitatea 5.1

5.1.1 Faceţi proiectul conceptual local pentru subsistemul didactic al facultăţii.

Pasul 1.1. Identificarea tipurilor de entităţi.

tipurile de entităţi sunt:

student, materii, profesori, orar, sali

Page 158: Baze de date_Iacob

157

Identificarea tipurilor de relaţii.

În continuare identificăm tipurile de relaţii. Tipurile de relaţii se reprezintă prin verbe

ale relaţiilor.

În continuare vom determina cardinalul şi participarea relaţiilor prezentate în tabelele

de mai sus. Cardinalul poate să fie unul dentre următoarele: unu-la-unu (1:1), unu-la-multe

(1:M), sau multe-la-multe (M:N). Participarea poate să fie parţială sau totală.

Tip de entitate Tip de relaţie Tip de entitate cardinalitate participare

student face Materii N:M P:T

profesor preda Materii N:1 T:T

orar Relaţie

complexă cu

Zile, Sali, ore,

materii

Atributele tipurilor de entităţi

Tip de entitate Atribute domeniu

student nrmatricol Numeric de 5

nume text

adresa text

sex M sau F

grupa Numeric de 4

materii Codmaterie Numeric de 3

Denmaterie

….

Text

Pasul 1.7. Desenarea modelului ER.

Page 159: Baze de date_Iacob

158

Unitatea 5.2

5.2.1 Faceţi proiectul logic local pentru subsistemul didactic al facultăţii.

Pasul 2.1. Proiectarea modelului local conceptual în modelul local logic.

În acest pas eliminăm acele structuri din baza de date, care sunt dificil de implementat

în sistemul de gestiune al bazelor de date. Pentru a rezolva această problemă, se vor urma

următorii paşi:

(1) Eliminarea relaţiilor de tipul N:M.

Este cazul relaţiei dintre student şi materii. Apare entitatea catalog.

(2) Eliminarea relaţiilor complexe.

Avem relaţia cu orarul. Se modifică în felul următor:

profesori

1

orar

sali zile ore

student

N

materii

M N

student

N

materii

N

catalog

1 1

Page 160: Baze de date_Iacob

159

(3) Eliminarea relaţiilor recursive. Nu avem.

(4) Eliminarea relaţiilor cu atribute. Nu avem.

(5) Reexaminarea relaţiilor de tipul 1:1. Nu avem

Desenarea diagramei ER.

Modelul conceptual care este reprezentat anterior s-a modificat în acest pas. Am

eliminat din acest model, toate structurile greu de implementat într-un sistem de gestiune a

bazelor de date. Diagrama modificată se va numi în continuare modelul local logic al bazei de

date.

N orar N

zile

1

ore

1

N zileore N

1

Sali

1

N zioresali N

1

materii

1

student

N

materii

M N

profesori

1

N orar N

zile

1

ore

1

N zileore N

1

Sali

1

N zioresali N

1

Page 161: Baze de date_Iacob

160

Pasul 2.2. Crearea de relaţii peste modelul logic local.

În acest pas vom crea relaţiile între entităţile din modelul logic local de date, cu

ajutorul mecanismului chei primare/chei străine. de exemplu:

Student=(nrmatricol,nume,adresa,sex,grupa)

Cheie primară nrmatricol

Catalog=(nrmatricol,codmaterie,nota)

Cheie primară nrmatricol,codmaterie

Cheie străină nrmatricol referă nrmatricol din student

Cheie străină codmaterie referă codmaterie din materii

materii=(codmaterie,denmaterie)

Cheie primară codmaterie

Pasul 2.3. Validarea modelului prin normalizare.

În acest pas validăm baza de date prin normalizare. Procesul de normalizare este

descris amănunţit în capitolul 4.

Forma Normală Unu (1NF), eliminarea repetiţiilor din atribute.

Forma Normală Doi (2NF), eliminarea dependenţelor parţiale de cheia primară.

Forma Normală Trei (3NF), eliminarea dependenţelor tranzitive de cheia primară.

Forma Normală Boyce-Codd (BCNF), eliminarea anomaliilor care au mai rămas.

Trebuie să analizăm fiecare relaţie care este descrisă în anexa 6.3.5. Verificăm dacă

relaţiile sunt în forma normală Boyce-Codd, iar dacă găsim una care nu satisface această

formă normală, ne întoarcem la paşii precedenţi şi rezolvăm problema.

În cazul nostru toate tabelele sunt în FN3

Pasul 2.2. Validarea modelului prin tranzacţiile cerute.

Tranzacţiile vor fi:

T1 Tabel nominal cu studenţii grupei…

T2 Catalogul grupei.. la materia…

Pentru fiecare tranzacţie vom da fraza SQL:

T1 SELECT nume

FROM student

WHERE grupa=…

T2 SELECT student.nume,denmaterie,nota

FROM student,catalog,materii

WHERE grupa=… AND denmaaterie=…

AND student.nrmatricol=catalog.nrmatricol

AND catalog.codmaterie)materii.codmaterie

Unitatea 5.3

Realizaţi, în ACCESS, proiectul fizic al subsistemului didactic al facultăţii.

Se vor urmări paşii din Access la purtător [8]

Page 162: Baze de date_Iacob

161

Unitatea 5.4

5.4.1 Daţi exemple de pierdere a consistenţei.

1) Tranzacţia T1 citeşte contul lui x (balx) şi scade 10 din cont. Tranzacţia T2 citeşte

contul lui x (balx) şi adună 100 la cont. Pornind cu un cont de 100, evident că dacă se

execută mai întâi prima tranzacţie şi apoi a doua contul lui x ar fi fost 100-

10+100=190. În cealaltă ordine am fi avut 100+100-10=190 aceeaşi valoare. Să

considerăm următorul plan de tranzacţii.

Time

T1 T2 balx

A t1 begin_transaction 100

A t2 begin_transaction cit(bal x) 100

A t3 cit(b alx) bal x = balx + 10 100

A t4 bal x = balx - 10 scrie(bal x) 200

A t5 scrie(bal x) commit 90

A t6 commit 90

Se ved că balx are valoarea greşită 90.

Unitatea 5.5

5.5.1 Ce este blocajul?

1) Când o tranzacţie blochează partajat o anumită unitate de memorie, o altă tranzacţie nu

mai poate să rescrie tot acolo, iar când o tranzacţie blochează exclusiv o alta nu mai

poate nici să o citească.

5.5.2 Ce este blocaju ciclic? Exemplu.

1) Blocarea ciclică este prezentată în exemplul următor. Cele două trnzacţii T10 şi T11 se

blochează reciproc.

Time

T10 T11

A t1 begin_transaction

A t2 ex_bloc(bal x) begin_transaction

A t3 cit(bal x) ex_bloc(bal y)

A t4 bal x = balx -10 cit(bal y)

A t5 scrie(bal x) bal y = baly +100

A t6 ex_bloc(bal y) scrie(baly)

A t7 AŞTEAPTĂ ex_bloc(bal x)

A t8 AŞTEAPTĂ AŞTEAPTĂ

A t9 AŞTEAPTĂ AŞTEAPTĂ

A t10 … AŞTEAPTĂ

A t11 … …

5.5.3 Ce este protocolul de blocare în două faze?

1) Protocolul de blocare în două faze constă din împărţirea tranzacţiei în două faze una

de blocări şi creşteri de blocaje şi a doua de descreşteri şi deblocaje. Aceasta înseamnă

că după ce s-a făcut prima deblocare nu se mai pot face blocări.

5.5.4 Care este protocolul de control cu marcarea timpului (time stamp)?

Protocolul cu marcarea timpului (time stamp) ataşează un timp fiecărei tranzacţii

(marc(T)) şi timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a unei

Page 163: Baze de date_Iacob

162

înregistrări. Deci fiecare tranzacţie va avea o valoare de marcaj şi fiecare înregistrare

prelucrată va avea două marcaje; unul care spune ce marcaj a avut tranzacţia care a citit-o

(cit_marc) şi celălalt care spune ce marcaj a avut tranzacţia care a scris-o (scri_marc).

Numai în următoarele trei situaţii se pun probleme deosebite:

1. Tranzacţia T cere să citească o înregistrare x care a fost deja actualizată de o

tranzacţie cu scri_marc(x) > marc(T), adică o înregistrare scrisă de o tranzacţie

care a început mai târziu. Ce ar rescrie ea ar putea da naştere la inconsistenţă

deci trnzacţia respectivă trebuie întreruptă.

2. Tranzacţia cere să scrie înregistrarea x a cărei valoare a fost deja citită de o

tranzacţie care a început mai tîrziu marc(T) < cit_marc(x). Aceasta înseamnă

că tranzacţia vrea să rescrie o înregistrare, pe care o altă tranzacţie începută

mai târziu, a citit-o şi o foloseşte. Şi în acest caz tranzacţia trebuie întreruptă.

3. Tranzacţia cere să scrie o înregistrare x a cărei valoare a fost deja scrisă de o

tranzacţie care a început mai târziu, adică marc(T) < scri_marc(x). Este o

încercare de a scrie o valoare perimată şi în acest caz se ignoră această scriere.

5.5.5 Ce este o tehnică optimistă de control al concurenţei?

O tehnică optimistă înseamnă să lăsăm tranzacţiile să ruleze fără să impunem întârzieri

care să asigure serializabilitatea, iar când o tranzacţie vrea să facă ‘commit’, să

efectuăm un control care să determine dacă a avut loc un conflict. Dacă a avut loc

un conflict, tranzacţia trebuie întreruptă şi restartată. Pentru că am spus că aceeste

conflicte sînt rare, aceste înteruperi şi restartări vor fi, şi ele, rare.

Unitatea 5.6

5.6.1 Care sunt restricţiile de integritate?

integritatea entitatii

- integritatea referentiala

- restrictiile de domeniu

- restricţiile de intreprindere

5.6.2 Ce înseamnă integritatea entitatii?

1) Intr-o relaţie de baza nici un atribut al unei chei primare nu poate avea valori nule.

5.6.3 Ce înseamnă integritatea referentiala?

Daca exista o cheie externa intr-o relaţie, ori valoarea cheii externe trebuie să se potriveasca

cu valoarea unei chei candidat a vreunui tuplu în relaţia de origine, ori valoarea cheii externe

trebuie să fie nulă.

5.6.4 Ce înseamnă restrictiile de domeniu?

Aceste restricţii se pot referi la tipul de date pentru un atribut, la o listă de valori

posibile, la un ordin de mărime, la un format sau o formă, la o condiţie exprimată cu o

formulă logică sau la o procedură care este apelată de cate ori are loc o modificare

pentru domeniul specificat.

5.6.5 Care este deosebirea între integritate şi securitate?

Noţiunea de securitate a bazei de date este de obicei asociată cu accesul răuvoitor, pe cand

integritatea se refera la evitarea pierdelor accidentale de consistenţă

Page 164: Baze de date_Iacob

163

5.6.6 Cum poate fi încălcată securitatea datelor într-o baza de date ?

Securitatea este in general asociată cu urmatoarele situaţii:

-acces fraudulos la date,

-pierderea confidenţialitatii (secretului) datelor,

-pierderea caracterului privat al datelor,

-pierderea disponibiliţatii datelor.

5.6.7 Enumeraţi măsuri de protecţie pentru asigurerea securităţii datelor.

Pentru protectia bazei de date se pot lua masuri de asigurare a securităţii la mai multe nivele:

-la nivel fizic - locurile în care se afla calculatoarele trebuie protejate de accesul

persoanelor neautorizate;

-la nivel uman – este recomandabil sa se acorde autorizaţiile de acces cu multa grijă şi

să se ţină evidenţe stricte ale persoanelor autorizate

-la nivel sistem de operare – slăbiciunile protecţiei la nivel de sistem de operare

trebuie eliminate sau compensate de alte măsuri

-la nivel SGBD – sistemul ofera anumite facilităţi care sprijina protecţia datelor.

5.6.8 Enumeraţi forme de autorizare.

Forme de autorizare:

-autorizare la citire (consultare)

-autorizare la inserare (adăugare)

-autorizare la actualizare (care exclude ştergerile)

-autorizare la ştergeri (la nivel de tuplu)

In situaţiile de mai sus nu se pune problema modificarilor la nivel de schemă a bazei de date.

Dacă considerăm şi acest aspect putem vorbi de:

-autorizare la nivel de index (creare-ştergere de indecşi)

-autorizare la nivel de relaţii (creare)

-autorizare de modificări la nivel de relaţii (ştergeri sau adăugari de atribute în cadrul

relaţiilor)

-autorizări de ştergeri ale relaţiilor.

Page 165: Baze de date_Iacob

164

Bibliografie. [1] L.Ţâmbulea - Structuri de date şi bănci de date, Universitatea Babeş-Bolyai, Cluj, 1992

[2] H.F.Korth, A.Silberschatz - Database System Concepts, McGraw Hill, New York, 1987

[3] T.Connoly,C.Begg,A.Strachan – Database Systems, Assison-Wesley, 1997

[4] O.Bâscă – Baze de date,All,1997

[5] Lungu I. Bodea C. Badescu G. Ionita C. Baze de date Ed.ALL 1995

[6] Iacob P.Baze de date pentru începători. Ed. Universităţii din Piteşti. 2000

[8]iacob P. Access la purtător Ed.Lux libris 2007

[9]iacob P. Oracle la purtător Ed.Lux libris 2008

[10] M. Stanescu şi colectiv - Limbaje de programare şi bănci de date, ASE, Bucuresti, 1992

[11] R Steiner - Theorie und Praxis relationaler Datenbanken, Vieweg Verlag, 1994

[12] J.L.Harrington,Relational database design,AP PROFESSIONAL,1998.