Documente Academic
Documente Profesional
Documente Cultură
Baze de Date Iacob
Baze de Date Iacob
Introducere
Aplicaii tradiionale bazate pe fiiere; limitri
Pentru o mai bun nelegere a evoluiei prelucrrilor de date vom rezerva cteva
rnduri la nceputul cursului nostru pentru o scurt trecere n revist a metodelor tradiionale
de prelucrare a masivelor de date, aa-numitele sisteme tradiionale bazate pe fiiere.
n primii ani, calculatoarele erau utilizate mai ales pentru a duce la bun sfrit calcule
laborioase n care nu erau implicate cantiti prea mari de date, aa-numitele calcule
tiinifice. Odat cu apariia limbajelor de nivel nalt i a posibilitii stocrii de mari cantiti
de informaie pe suport magnetic adresabil (memorie externa) s-a pus i problema
eficientizrii prelucrrii acestora. De data aceasta nu calculele creteau costul n timp al
prelucrrilor ci manipularea datelor, respectiv regsirea, actualizarea, etc. S-a constatat c un
factor important al creterii eficienei prelucrrilor este modul de organizare al informaiilor.
De aici i pn la a gndi sisteme unitare de reprezentare i manipulare a masivelor de date na mai fost dect un pas.
Prima variant de prelucrare a cantitilor mari de informaie s-a bazat pe organizarea
datelor sub forma nregistrrilor n fiiere tradiionale pe suport adresabil. n aceast variant
se elaborau programe de aplicaie care defineau i manipulau propriile date i aveau n general
ca scop elaborarea de rapoarte pentru diveri beneficiari. Aceste programe au avut menirea de
a nlocui prelucrarea sistemelor de fiiere manuale care mai funcioneaz i astzi n unele
locuri cum ar fi cabinetele medicale. Aadar prelucrrile oferite de un sistem tradiional bazat
pe fiiere copiau n mare msur metodele manuale de prelucrare. Evident c puterea de
calcul i memorare caracteristic sistemelor de calcul au fcut ca gama prelucrrilor s
creasc simitor, la aceasta adugndu-se viteza i sigurana prelucrrilor.
Cu toate c la momentul respectiv abordarea tradiional bazat pe fiiere a fost un
evident progres, putem s amintim aici i o serie de limitri ale acestui sistem de prelucrare a
datelor:
Separarea i izolarea datelor
Duplicarea datelor
Dependena datelor
Incompatibilitatea fiierelor
Interogri fixe / proliferarea aplicaiilor
Comentm pe scurt n continuare semnificaia acestora.
Separarea i izolarea datelor
Accesul la date care se afl n fiiere diferite este dificil deoarece cade n sarcina
programatorului s sincronizeze nregistrrile din fiiere n aa fel nct datele extrase s fie
corecte.
Duplicarea datelor
n situaia n care se realizeaz prelucrri descentralizate de date, pe compartimente,
este posibil s fie necesar duplicarea datelor. Totui duplicarea este de evitat din urmtoarele
motive:
- necesit costuri mari n timp i spaiu de memorie.
- duce la pierderea integritii datelor. Datele nu mai sunt consistente, deci nu se mai
poate conta pe ele.
Dependena datelor
Aa cum am subliniat deja, structura fizic i modul de memorare al datelor este
definit n fiecare program de aplicaie n parte. Este evident ct de dificile sunt schimbrile n
structura datelor. Toate programele trebuie ajustate la noua structur de date. O simpl
modificare a lungimii unui cmp poate genera probleme. Dependena se refer aadar la
dependena program-date.
Incompatibilitatea fiierelor
Aceast limitare se trage tot din dependena de programe a structurii fiierelor.
Structura fiind descris n programe ea depinde de limbajul de programare. De exemplu,
structura unui fiier declarat ntr-un program COBOL difer de structura unui fiier generat
de un program C. Dac e necesar prelucrarea de date din ambele fiiere, programatorul este
obligat s scrie programe de conversie, pentru a aduce fiierele la un format comun posibil de
prelucrat.
Interogri fixe / proliferarea aplicaiilor
Deoarece prelucrarea masivelor de date a devenit mai uoara i mai rapida cu ajutorul
calculatorului, beneficiarii au lrgit gama prelucrrilor lansnd interogri noi sau modificnd
interogri mai vechi, pentru obinerea de informaii mai complexe. Orice interogare nou sau
orice modificare a unei interogri mai vechi se rezolv n sistemele tradiionale prin realizarea
de noi programe de ctre programatorul de aplicaie. Inutil de subliniat ct de costisitoare sunt
acestea. Un efect secundar era c se nmuleau programele aplicaiei i de multe ori i fiierele
de prelucrat.
Obiectivele cursului
Cursul de baze de date este un curs de baz pentru meseria de informatician. La
sfritul acestui curs, studenii vor fi capabili s:
Proiecteze o baz de date
Programeze cereri n SQL
Realizeze un sistem cu baz de date
Cerine preliminare
Cursul se va susine studenilor dup cursul de structuri de date.
Cunotinele 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.
Structura cursului
Cursul de baze de date este structurat n trei module, astfel: primul modul cuprinde
patru uniti de nvare, al doilea modul cuprinde dou uniti de nvare, al
treilea modul cuprinde dou uniti de nvare, al patrulea modul cuprinde dou
uniti de nvare, iar al cincilea modul cuprinde ase uniti de nvare. La
rndul su, fiecare unitate de nvare cuprinde: obiective, aspecte teoretice privind
tematica unitii de nvare respective, exemple, teste de autoevaluare precum i
probleme propuse spre discuie i rezolvare.
La sfritul fiecrui modul sunt date teste de autoevaluare. Rezolvarea acestor teste
se gsete la sfritul crii.
Durata medie de studiu individual
Parcurgerea de ctre studeni a unitilor de nvare ale cursului de baze de date
(att aspectele teoretice ct i rezolvarea testelor de autoevaluare i rezolvarea
problemelor propuse) se poate face n 1-4 ore pentru fiecare unitate.
Evaluarea
La sfritul semestrului, fiecare student va primi o not, care va cuprinde: un
examen scris cu materia din modulele 1, 3 i 4 care va deine o pondere de 60% n
nota final i notele aferente celor dou capitole de la laborator ACCESS i
ORACLE.
CUPRINS
Modulul 1. Sisteme de Gestiune a Bazelor de Date (SGBD) ................................ ..................... 5
Unitatea de nvare 1. Istoric; comentarii ................................ ................................ ......... 6
Criterii minimale de definire a unui SGBDR ................................ ................................ ... 10
Unitatea de nvare 1.2 Abstractizarea datelor ................................ ................................ 14
Unitatea de nvare 1.3 Principalele componente i funciuni ale unui SGBD ............... 19
Unitatea de nvare 1.4 Baze de date distribuite ................................ ............................. 27
Modulul 2. Modele de descriere a datelor ................................ ................................ ................ 37
Unitatea de nvare 2.1. Generaliti ................................ ................................ ............... 38
Unitatea de nvare 2.2 Modelare E-R (Entity-Relaionship) ................................ ......... 41
Modulul 3. Limbaje de cereri. ................................ ................................ ................................ .. 53
Unitatea de nvare 3.1 Algebra relaional. ................................ ................................ ... 54
Unitatea de nvare 3.2 SQL ................................ ................................ ........................... 65
Modulul 4. Normalizarea................................ ................................ ................................ .......... 85
Unitatea de nvare 4.1 De ce este nevoie de normalizare i cu ce instrumente facem
normalizarea. ................................ ................................ ................................ .................... 86
Unitatea de nvare 4.2 Forme normale ................................ ................................ ......... 93
Modulul 5. Metodologia de proiectare a bazelor de date relaionale ................................ ...... 99
Unitatea de nvare U5.1 Generaliti i proiectarea conceptual................................ . 101
Unitatea de nvare U5.2 Proiectarea logic. ................................ ................................ 111
Unitatea de nvare U5.3 Proiectarea fizic. ................................ ................................ . 122
Unitatea de nvare U5.4 Tranzacii i concuren................................ ........................ 126
Unitatea de nvare U5.5 Metode de control al concurenei. ................................ ........ 131
Unitatea de nvare U5.6. Securitate i integritate ................................ ........................ 139
Raspunsuri la testele de autoevaluare. ................................ ................................ .................... 147
Bibliografie................................. ................................ ................................ ............................ 164
(SGBD)
Cuprins
Introducere ................................ ................................ ................................ ...................... 3
Obiectivele modului ................................ ................................ ................................ ........ 3
U1.1. Istoric; comentarii
U1.2. Abstractizarea datelor
U1.3. Principalele componente i funciuni ale unui SGBD
U1.4 Baze de date distribuite
Introducere
Evoluia metodelor i tehnicilor de organizare a datelor a fost determinat de
necesitatea de a avea un acces ct mai rapid i mai uor la un volum din ce n ce
mai mare de informaii precum i de perfecionarea echipamentelor de culegere,
memorare, transmitere i prelucrare a datelor. Cel mai important domeniu al
aplicaiilor calculatorului este cel al bazelor de date.
Istoric i comentarii
Se pare c sistemul de baze de date i are rdcinile 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).
Conductor de proiect: Charles Bachmann. Proiectul a condus la mod elul de date reea.
n 1965 CODASYL (the Conference On DAta SYstems Languages) care reunea
reprezentani ai guvernului USA i reprezentani ai lumii afacerilor i comerului, a reuit s
stabileasc un grup de lucru, cunoscut din 1967 sub numele Data Base Task Group (DBTG).
Sarcina acestui grup era s stabileasc specificaii 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 prezentrii primului proiect de
raport CODASYL (Raportul final s-a prezentat n 1971). Ideea principal n organizarea
datelor se baza pe existena a trei nivele de baz:
schema de reea - care reprezenta organizarea logica a ntregii baze de date
subschema - care reprezenta o parte a bazei de date aa cum e vzut de utilizator sau de
programele de aplicaie
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
SGBDR
Tabel
Linie
Coloan
Teoria relaional
Relaie
Tuplu
Atribut
exprima oricare din urmtoarele operaii: definirea tabelelor de date, definirea tabelelor
virtuale, manipularea datelor (interactiv dau prin program), definirea restriciilor de
integritate, autorizarea accesului, precizarea limitelor tranzaciilor. A se nota aici c noul
standard O/I pentru SQL furnizeaz toate aceste funcii, 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 inserrile, modificrile i tergerile n baza de date
Sistemul trebuie s ofere posibilitatea manipulrii unei tabele (da baz sau virtual) nu
numai n cadrul operaiilor de regsire, ci i n aciuni de inserare, modificare i tergere a
datelor.
Aceast regul exprim cerina ca prin operaiile n care se schimb bazei da date s se
lucreze la un moment dat pe o ntreag relaie.
R8: Regula privind independena fizic a datelor
Programele de aplicaie nu trebuie s fie afectate de schimbrile efectuate n modul de
reprezentare a datelor sau n metodele de acces. O schimbare a structurii fizice a datelor nu
trebuie s blocheze funcionarea programelor de aplicaie.
R9: Regula privind independena logic a datelor
Programele de aplicaie nu trebuie s fie afectate de schimbrile efectuate asupra
relaiilor bazei de date, schimbri care conserv datele i care teoretic garanteaz valabilitatea
programelor de aplicaie existente.
R10: Regula privind restriciile de integritate
Restriciile 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
aplicaie.
R11: Regula privind distribuirea geografic a datelor
Limbajul de manipulare a datelor utilizat de sistem trebuie s permit ca, n situaia n
care datele sunt distribuite, programele de aplicaie s fie logic aceleai 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 cnd 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 sczut) orientat pe prelucrare de
recorduri (tupluri) i nu pe prelucrarea mulimilor (relaiilor), acest limbaj nu trebuie s fie
utilizat pentru a se evita restriciile de integritate sau restriciile 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 fr cunoa terea utilizatorului sau a
administratorului bazei de date.
Pe parcursul anilor regulile lui Codd au generat o seam de controverse. Cteva
argumente sunt c aceste reguli nu sunt mai mult dect nite exerciii academice. Unele
revendicri ale produselor existente sunt c ele pot ndeplini cea mai mare parte din reguli,
dar nu toate. Aceast discuie a generat o disput ntre utilizatori i teoreticienii asupra
proprietilor eseniale ale unui SGBDR.
Pentru a accentua implicaia regulilor lui Codd n analiza unui SGBDR, aceste reguli
au fost reorganizate n cinci categorii, i anume:
Reguli fundamentale,
Reguli structurale,
Reguli privind integritatea datelor,
Reguli privind manipularea datelor,
Reguli privind independena datelor.
S ne reamintim...
Abordarea tradiional bazat pe fiiere are o serie de limitri cum ar fi
Separarea i izolarea datelor
Duplicarea datelor
Dependena datelor
Incompatibilitatea fiierelor
Interogri fixe / proliferarea aplicaiilor
Sistemul de baze de date i are rdcinile n anii '60, n proiectul de
aselenizare Apollo
Ideea principal n organizarea datelor se baza pe existena a trei componente
de baz:
schema de reea - care reprezenta organizarea logica a ntregii baze de date
subschema - care reprezenta o parte a bazei de date aa cum e vzut de
utilizator sau de programele de aplicaie
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 organizrii datelor n fiiere, SGBDR i teoriei
relaionale ntre care se pot stabili analogii
Organizarea datelor
fiiere
Fiier
Record(nregistrare)
Cmp
n SGBDR
Tabel
Linie
Coloan
Teoria relaional
Relaie
Tuplu
Atribut
10
regulile lui Codd, fiind formulate n schimb o serie de cerine minimale pa care trebuie s la
satisfac un sistem de gestiune a bazelor de date pentru a putea fi considerat relaional.
Un SGBD este minimal relaional dac satisface urmtoarele condiii:
1. Toate datele din cadrul relaiei sunt reprezentate prin valori n tabele,
2. Nu exist pointeri observabili de ctre utilizatori n tabele, n sensul c operaiile cu relaii
nu fac apel la pointeri, indeci, fiiere inverse, etc.
3. Sistemul suport operatori relaionali de proiecie, selecie i join natural, fr limitri
impuse de considerente interne (cum ar fi de exemplu, necesitatea indexrii atributelor).
Unitatea de informaie cu care se lucreaz n cadrul acestor operaii trebuie s fie relaia.
Un SGBD este complet relaional dac este minimal relaional i satisface n plus
urmtoarele condiii:
4. Sistemul suport toate operaiile de baz ale algebrei relaionale, fr limitri impuse de
considerente interne.
5. Sistemul suport dou dintre restriciile de integritate de baz al modelului relaional i
anume unicitatea cheii unei relaii i restricia referenial.
Un SGBD este pseudorelaional dac satisface numai condiiile 1. i 3.
Un SGBD cu interfa relaional este un SGBD are satisface condiiile 1. i 3., cu
observaia c cerina 3. Este ndeplinit numai n raport cu funcia de interogare
n ultimii ani, ca rspuns la necesitatea de a crete complexitatea aplicaiilor cu baze de
date (ncurajat i de progresele aprute n programare o dat cu programarea orientata obiect)
au aprut modelul de date orientat obiect (Object-Oriented Data Model - OODM) i modelul
de date relaional extins (Extended Relaional Data Model - ERDM). Cu toate c modelul de
date ce sta la baza noilor modele nu este att de clar c n cazul modelului relaional, se poate
considera c aceste din urma dezvoltri reprezint generaia a patra de SGBD.
In esen, conceptul de baz de date poate fi definit ca fiind o colecie partajat de date
aflate n interdependen logic (mpreun cu o descriere a acestor date i a relaiilor dintre
ele), colecie desemnat pentru a rezolva nevoia de informatizare a unei ntreprinderi (sau
organizaii).
Baza de date trebuie s ndeplineasc urmtoarele condiii:
- s asigure o independen sporit a datelor fa de programe i invers;
- structura bazei de date trebuie astfel conceput nct s asigure informaiile necesare i
suficiente pentru cerinele de informare i decizie;
- s asigure o redundan minim i controlat a datelor;
- s permit accesul rapid la informaiile stocate n baz.
Bazele de date sunt extrem de variate n funcie de criteriile luate n considerare. Prezentm
cteva criterii de clasificare:
- dup orientare: generalizate, specializate;
- dup modelul de date: ierarhice, reele, relaionale, 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 ntreinerea bazei de date i pe de alta parte,
permite accesul controlat la informaiile din baza de date n cauz. SGBD este format din
11
n SGBDR
Tabel
Linie
Coloan
13
Teoria relaional
Relaie
Tuplu
Atribut
Se poate face referire spre exemplu la ncercarea de modelare a unei aplicaii ntr-o
ntreprindere. Trebuie modelate 'obiectele' i relaiile dintre ele. Nu realitatea complex n
totalitatea ei intr n discuie 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 aplicaia n cauza). Astfel n cazul modelrii 'obiectului' (sau
entitii) angajat, trebuie alese doar acele proprieti (sau atribute) care intereseaz. Acestea
ar putea fi, de exemplu: numele, adresa, salariul. O mulime impresionant de informaii, 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 albatri, dac este blond
sau brunet, dac ascult cu plcere muzic sau dac este o fire sentimental.
Ce credei c ar interesa s memorm despre studeni ntr-o baz de date a
facultii?
Ce nu ar trebui memorat?
Mai mult dect 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 informaiile stocate, funcie de aplicaia pe care o dezvolt.
14
Utilizator 2
View 2
View 1
Nivel
conceptual
Schema
conceptuala
Nivel
intern
Schema
interna
Organizarea la
nivel fizic a datelor
..
Baza de
date
15
View n
16
S ne reamintim...
Descrierea generala a unei baze de date se numete 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.
Independena datelor
Un obiectiv major al arhitecturii pe trei nivele de abstractizare este realizarea
independenei datelor. O aplicaie, n general, este dependent de date n sensul c
modificarea structurii de memorare a datelor sau a strategiei de acces la date afecteaz i
aplicaia. Independena datelor fa de aplicaie este totui necesar cel puin din urmtoarele
considerente:
- diferite aplicaii au nevoie de viziuni diferite asupra acelorai date;
- administratorul bazei de date trebuie s aib libertatea de a schimba structura de memorare
sau strategia de acces, ca rspuns la cerine (schimbri de standarde, prioritile aplicaiilor,
unitile de memorare etc.), fr a modifica aplicaiile existente, baza de date existent,
precum i programele de exploatare a ei, care au fost folosite o perioad de timp i care
reprezint o investiie major la care nu trebuie s se renune prea uor.
De aceea, se impune ca atunci cnd apar noi cerine n cadrul sistemului informaional,
sistemele informatice s poat funciona cu programele i procedurile existente, iar datele
existente s poat fi convertite.
Independena datelor trebuie privit din dou puncte de vedere: independena fizic i
independena logic a datelor.
Independena fizic a datelor face ca memorarea datelor i tehnicile fizice de memorarea s
poat fi modificate fr a determina rescrierea programelor de aplicaie. Aadar independena
fizic a datelor reprezint gradul de imunitate a schemei conceptuale la schimbrile suferite
de schema intern.
Independena logic a datelor se refera la posibilitatea adugrii de noi nregistrri sau la
extinderea structurii conceptuale (globale), fr ca acest lucru s impun rescrierea
programelor existente. Cu alte cuvinte independena logic a datelor reprezint gradul de
imunitate a schemelor externe la schimbrile suferite de schema conceptual.
S ne reamintim...
Independena fizic a datelor face ca memorarea datelor i tehnicile fizice de
memorarea s poat fi modificate fr a determina rescrierea programelor de
aplicaie.
Independena logic a datelor se refer la posibilitatea adugrii de noi
nregistrri sau la extinderea structurii conceptuale (globale), fr ca acest lucru
s impun rescrierea programelor existente.
17
M1.U1.6. Rezumat
Componentele bazei de date pot fi structurate pe trei nivele, n funcie
de clasa utilizatorilor implicai i de viziunea asupra structurrii informaiei,
dup cum urmeaz:
- nivelul logic de vizualizare (view) sau nivelul extern.
- nivelul conceptual (global
- nivelul fizic
Descrierea general a unei baze de date se numete 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.
Independena fizic a datelor face ca memorarea datelor i tehnicile fizice de
memorarea s poat fi modificate fr a determina rescrierea programelor de
aplicaie.
Independena logic a datelor se refer la posibilitatea adugrii de noi
nregistrri sau la extinderea structurii conceptuale (globale), fr ca acest
lucru s impun rescrierea programelor existente.
18
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 unitii de nvare
La sfritul acestei uniti de nvare studenii vor fi capabili s:
descrie componena unui Sistem de Gestiune al Bazei de Date
cunoasc obiectivele unui SGBD
cunoasc i s utilizeze funciunile unui SGBD
innd seama de faptul c exist diferite tipuri de sisteme de gestiune, care se difereniaz:
- prin limbajele utilizate,
- prin anumite componente ce imprim diferite faciliti 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 att n regim local ct i n regim de teleprelucrare,
ajungem la concluzia c nu poate fi stabilit o arhitectur unic, valabil pentru toate
sistemele, ci apar particulariti de la un sistem la altul.
Arhitectura unui SGBD evideniaz componentele acestuia i urmeaz standarde
internaionale. O astfel de arhitectur general cuprinde urmtoarele componente:
- baza de date propriu-zis n care se memoreaz colecia 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 reglementrile administrative,
destinate bunei funcionri a ntregului sistem;
- un dicionar al bazei de date (metabaza de date), ce conine informaii despre date,
structura acestora, elemente de descriere a semanticii, statistici, documentaie etc.
- mijloacele hard utilizate (comune, specializate etc.);
- personalul implicat: (categorii de utilizatori: finali - (neinformaticieni); de specialitate
(administrator), analiti - programatori, gestionari, operatori).
Arhitectura bazei de date d o imagine despre modul general de organizare i funcionare a ei.
S detaliem cteva din componentele prezentate mai sus.
19
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 construcii adecvate oricror necesiti de calcul, asemntoare cu structurile puse la
dispoziie 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 funcii. Fiierul preprocesat este
compilat, plasat ntr-un modul obiect, link-editat cu o bibliotec n care se afl funciile
nlocuite, furnizate o dat cu SGBD, i este executat cnd 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 entitile i
relaiile care se pot stabili ntre acestea.
Schema bazei de date este definita cu ajutorul LDD. Rezultatul compilrii declaraiilor
n acest limbaj este constituit dintr-o serie de tabele memorate ntr-un Fiier special numit
dicionar de date (se mai utilizeaz i termenii de catalog de date sau director de date).
Datele memorate n acest dicionar sunt date despre date i de aceea se mai numesc i
metadate. Definiiile din dicionarul de date se refera la nregistrri, la datele din nregistrri
i la alte obiecte ce compun baza de date. SGBD consulta dicionarul de date naintea oricrui
acces la informaii.
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 operaii care suporta
operaiile de manipulare de baza asupra datelor din baza de date. Operaii de baza sunt
inserarea, tergerea, modificarea i regsirea 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 nregistrrile individual i specifica cum trebuie obinut rezultatul unei interogri. Cu
alte cuvinte trebuie s se specifice un algoritm de prelucrare a nregistrrilor cu ajutorul
operaiilor puse la dispoziie de limbaj.
n contrast, un LMD non-procedural specifica doar ce fel de rezultat trebuie obinut.
SGBD translateaz cererea din limbaj non-procedural transformnd-o ntr-o procedura sau
ntr-o serie de proceduri care manipuleaz datele conform cererii utilizatorului. Limbajele
non-procedurale sunt mai uor de utilizat deoarece scutesc utilizatorii de la a cunoate
implementarea interna a structurilor de date i de la a stabili algoritmi de obinere a
informaiilor.
Partea componenta a unui LMD care se refera la regsirea datelor se numete limbaj
de interogare. nelegem 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 Generaia a Patra). Nu exist
nc un consens asupra semnificaiei 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 generaia a treia, poate s constituie cteva zeci de linii de
program ntr-un limbaj de generaia a patra. Limbajele 4GL sunt non-procedurale i se
20
21
S ne reamintim...
Arhitectura unui SGBD cuprinde urmtoarele componente:
- baza de date propriu-zis n care se memoreaz colecia 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
reglementrile administrative, destinate bunei funcionri a
ntregului sistem;
- un dicionar al bazei de date (metabaza de date), ce conine
informaii despre date, structura acestora, elemente de descriere
a semanticii, statistici, documentaie etc.
- mijloacele hard utilizate (comune, specializate etc.);
- personalul implicat: (categorii de utilizatori: finali (neinformaticieni); de specialitate (administrator), analiti programatori, gestionari, operatori).
24
M1.U1.6. Rezumat
Arhitectura unui SGBD cuprinde urmtoarele componente:
- baza de date propriu-zis n care se memoreaz colecia 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
reglementrile administrative, destinate bunei funcionri a
ntregului sistem;
- un dicionar al bazei de date (metabaza de date), ce conine
informaii despre date, structura acestora, elemente de descriere a
semanticii, statistici, documentaie etc.
- mijloacele hard utilizate (comune, specializate etc.);
- personalul implicat: (categorii de utilizatori: finali (neinformaticieni); de specialitate (administrator), analiti 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 informaii necesare lurii deciziilor, n condiii de
eficienta economica sporita.
Obiectivele sunt:
Asigurarea independentei datelor.
Acest obiectiv consta n ndeplinirea cerinei ca modificrile 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
25
baza de date.
Pe ct posibil, fiecare informaie s apar o singur dat. Nu sunt
excluse nici cazurile n care s se accepte o anumit redundan a
datelor.
Asigurarea unor faciliti sporite de utilizare a datelor.
Asigurarea integritii datelor mpotriva unor tergeri intenionate sau
neintenionate, 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 partajabilitii datelor. Partajabilitatea datelor trebuie
neleas i sub aspectul posibilitii dezvoltrii unor aplicaii fr a se
modifica structura bazei de date.
Funciunile unui SDGBD sunt
Funcia de descriere a datelor care permite definirea structurii bazei
de date cu ajutorul limbajului de definire.
Funcia de manipulare a datelor este cea mai complex funcie i
realizeaz urmtoarele activiti:
- crearea (ncrcarea) bazei de date;
- adugarea de noi nregistrri;
- tergerea unor nregistrri;
- modificarea valorilor unor cmpuri;
- cutarea, sortarea i editarea parial sau total a unei nregistrri
virtuale etc.
Funcia de manipulare a datelor se realizeaz prin intermediul
limbajului de manipulare a datelor.
Funcia de utilizare asigur mulimea interfeelor necesare pentru
comunicarea tuturor utilizatorilor cu baza de date. Sunt recunoscute mai
multe categorii de utilizatori:
- utilizatori "liberi" sau conversaionali. Ei apar ca utilizatori
neinformaticieni;
- utilizatori programatori, care utilizeaz limbajele de manipulare,
realiznd proceduri complexe de exploatare a bazei de date;
- administratorul bazei de date apare ca un utilizator special i are
rolul hotrtor n ceea ce privete funcionarea optim a ntregului
ansamblu.
Funcia de administrare a bazei de date apare ca o funcie complex
i este de competena administratorului bazei de date.
M1.U1.3. Test de autoevaluare a cunotinelor
1.3.1 Care sunt obiectivele unui SGBD?
1.3.2 Care sunt funciunile unui SGBD?
Rspunsurile se gsesc la sfrit la pag 149
26
M1.U1.4 Introducere
O baza de date distribuit (BDD) este o colecie logic corelat de date
partajate, distribuite fizic pe o reea 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
informaii". Ele au aprut ca o necesitate, n special in cazul reelelor de
calculatoare, pentru a sprijini gestionarea datelor n situaia cnd acestea se
regsesc fizic n diferite puncte ale reelei.
Generaliti
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 (reeaua) care constituie suportul unei baze de date distribuite poate fi
format din calculatoare personale, minicomputere, staii de lucru, etc. toate legate n reea i
numite generic site-uri.
Putem reformula definiia de la nceput spunnd ca un sistem de baze de date
distribuite const dintr-o colecie de site-uri, fiecare putnd participa la executarea
tranzaciilor care acceseaz datele de pe un site sau de pe mai multe site -uri.
Printre cerinele pe care trebuie s le asigure un sistem de baze de date distribuite
menionm: autonomia locala n organizarea i prelucrarea datelor, neutilizarea unei
centralizri a evidenei i a datelor, posibilitatea de lucru continuu al site-urilor independent
de schimbrile in configuraiile de lucru (adugari sau eliminari de site-uri), independena
localizrii i fragmentrii datelor (transparena fizic), posibiliti de replicare (copiere) i
independena copiilor, prelucrarea distribuit a cererilor, administrarea distribuit a
tranzaciilor, independena de hardware, de sistemul de operare, de reea i de sistemul de
gestiune a bazelor de date.
27
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
interogri utilizator n regim local, independent de restul reelei, sau este capabil s participe
la procesarea unor date situate n alte site-uri din reea. Pentru a spune c un SGBD este
distribuit trebuie s existe cle puin o cerere global.
Tranzaciile ntr-o baza de date distribuit sunt clasificate n tranzacii locale i
tranzacii 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:
-
datele sunt partajabile dar administrarea lor se bucur de un grad nalt de autonomie local
disponibilitatea bazei de date este evident mai bun dect n cazul centralizat. Dac se
semnaleaz unele erori sau "deri" de sistem la nivel local sistemul ]n ntregime poate s
continue s funcioneze n condiii satisfctoare
fiabilitatea sistemului este mbuntit. Se pot reface rapid fiiere distruse utiliznd
replici aflate pe alte site-uri
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.
28
este necesara o procesare suplimentara care se datoreaza schimburilor de mesaje intre siteuri 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.
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.
29
un dicionar de date global (DDG). Acest dicionar are aceeai funcionalitate ca i und
dicionar de date n cazul SGBD centralizat dar conine informaii suplimentare referitoare
la fragmentare i la alocarea datelor. i DDG poate fi fragmentat i replicat ca orice alt
informaie din baza de date distribuit
fragmentarea datelor informaiile pot fi partitionate n fragmente care sunt apoi stocate
pe diferite site-uri n reea
replicarea se pot realiza copii ale diferitelor relaii sau ale fragmentelor
realizarea, pe cat posibil a accesului in regim de referinte locale. Acolo unde este necesar
i unde permite aplicaia se recomanda utilizarea de copii ale fragment elor
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 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 crete costurile foarte mult
(si riscul obtinerii inconsistentei) deoarece trebuie sa fie realizate asupra datelor de la toate
site-urile.
Alocarea datelor
30
Se cunosc patru strategii de alocare a datelor ntr-o baza de date relaional distribuit:
1. centralizat
Baza de date se afl n ntregime pe un singur site din reea 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 cuvntului. Dezavantajele sunt mai ales
costurile mari de comunicaii i o fiabilitate i o disponibilitate foarte sczute, avnd n
vedere c orice eroare care blocheaz accesul la baza de date, practic paralizeaz ntreaga
activitate n reea pe aceast direcie.
2. fragmentat (partiionat)
Baza de date este partiionat n mai multe fragmente disjuncte care sunt stocate pe
diverse site-uri. Comentarii:
-
dac datele sunt distribuite corect, costurile de comunicare pot fi relativ sczute
3. replicat complet
Pe fiecare site se gseste o copie complet a bazei de date. Comentarii:
-
costurile de stocare sunt n schimb i ele foarte mari, la fel sunt i costurile de
actualizare
4. replicat selectiv
Aceasta strategie este o combinaie intre partiionare, replicare i centralizare cu scopul de
a se cumula, pe cat posibil, avantajele fiecrei 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 aplicaii deoarece nu se poate realiza o
alocare care sa optimizeze toate aplicaiile simultan.
Printre criteriile care duc la decizia corecta de alocare a bazei de date:
-
etc.
Fragmentarea
La baza fragmentarii bazei de date exista, printre altele, urmatoaele motivari:
-
mod de utilizare in general intr-o aplicaie 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
31
securitate datele care nu sunt necesare sunt stocate in alta parte, deci nu sunt la
dispozitia accesului neautoarizat
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
pe orizontal
pe vertical
combinat
Fragmentarea pe orizontal:
Ne putem imagina c o tabel se fragmenteaz orizontal ca mai jos:
32
Completitudinea este asigurat prin faptul c fiecare atribut apare cel puin ntr- una din
submulimile S1 i S2.
Reconstrucia relaiei iniilale se realizeaz prin jonciune natural.
r ( R ) r1 X N r2
Aadar la descompunerea relaiei iniiale n fragmente trebuie s se in seama de regulile care
asigur o descompunere fr pierderi la jonciune.
In cazul descompunerii pe vertical nu este posibil s se realizeze o disjuncie total. Se
admite existena unor atribute comune, i anume a atributelor care formeaz cheile primare
(respectiv cheile externe). Fragmentele verticale se stabilesc prin determinarea afinitilor
ntre atribute, nc din faza de analiz.
Fragmentarea combinat (mixt, hibrid, compus)
1. fragmente verticale fragmentate orizontal
Expresia corespunzatoare n algebra relaional (pentru fiecare dreptunghi din figura de mai
sus) este: P ( A1 ,..., An ( R))
2. fragmente orizontale fragmentate vertical
Expresia corespunztoare n algebra relaional (pentru fiecare dreptunghi din figura de mai
sus) este: A1 ,..., An ( P ( R))
Transparena n SGBDD
Prima regula, considerat 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 transparena poate fi realizat doar ntr-o anumit msur. Tipuri de
transparen:
1. transparena distribuirii
2. transparena tranzaciilor
3. transparena performanelor
Transparena distribuirii
33
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 aplicaiile ce o utilizeaza sa trebuiasca modificate.
34
Transparenta maparii locale reprezinta cel mai jos nivel al transparentei distribuite.
Utilizatorul trebuie sa specifice i numele fragmentelor i localizarea datelor.
Transparena tranzaciilor
Acest tip de transparena asigur faptul c toate tranzaciile distribuite pstreaz
integritatea i consistena BDD.
O tranzacie distribuit acceseaz date stocate la mai mult de o locaie n reea. Fiecare
tranzacie e divizata n sub-tranzacii, cte una pentru fiecare site accesat. Sub-tranzaciile se
execut n paralel pe site-uri i n mod concurent pe fiecare site. SGBDD are sarcini deosebite
n legtur cu gestionarea tranzaciilor distribuite dar acestea nu vor fi tratate in acest capitol.
n cadrul transparenei tranzaciilor se trateaz n mod deosebit transparena
concurenei i transparena erorilor. SGBDD ofer transparen concurenei dac rezultatele
tuturor tranzaciilor concurente (distribuite sau nu) sunt executate independent i sunt logic
echivalente cu rezultatele obtinue n cazul n care tranzaciile sunt executate pe rnd, ntr-o
ordine serial arbitrar.
Transparena erorilor necesit i un mecanism de recovery care ne s asigure c
tranzaciile se comport atomic n faa erorilor: ori sunt executate toate operaiile unei
tranzacii ori nici o operaie nu este executat. Odat ce o tranzacie s-a executat,
transformrile operate de ea asupra bazei de date sunt durabile (permanente).
Transparena performanelor
Transparena performanelor se asigur prin cerina ca sistemul considerat s aib
performane comparabile cu ale unui sistem centralizat. n aceast situaie 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 locaie se utilizeaz. DQP produce o strategie de execuie care este optimizat relativ la o
funcie de cost. Costul asociat cu o interogare distribuita include:
-
M1.U1.6. Rezumat
O baza de date distribuit (BDD) este o colecie logic corelat de date partajate,
distribuite fizic pe o reea de calculatoare.
Tranzaciile ntr-o baza de date distribuit sunt clasificate n tranzacii locale i
tranzacii globale dup site-urile pe care le solicit excutarea lor.
Proiectarea corect a unei baze de date relaionale distribuite necesit, pe lng
cerinele cunoscute pentru sistemele centralizate, i realizarea urmtoarelor:
-
replicarea se pot realiza copii ale diferitelor relaii sau ale fragmentelor
35
pe orizontal
pe vertical
combinat
transparena distribuirii
transparena tranzaciilor
transparena performanelor
36
Cuprins
Introducere
Obiectivele modulului
U2.1 Generaliti
U2.2 Modelare E-R (Entity-Relaionship)
Introducere
Numim model de date o colecie integrat de concepte pentru
descrierea datelor, de relaii ntre date i de restricii asupra datelor,
toate ntr-o organizare unitar.
Un model de date este o abstracie. Un model de date are n
principal rolul de a furniza conceptele de baz i notaiile care s
permit proiectanilor i utilizatorilor bazei de date s comunice n
mod neambiguu legat de modul de organizare a datelor.
37
Modele de date se pot realiza pentru fiecare nivel de abstractizare. Astfel putem vorbi de:
model extern de date (care reprezint aa-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 menionam aici: modelele de
date bazate pe obiecte, modelele de date bazate pe nregistrare, ambele modele fiind utilizate
pentru descrierea organizrii datelor la nivel extern i conceptual. Trebuie s menionam i
modelele fizice de date, care descriu datele la nivel intern.
Aceste modele utilizeaz concepte specifice modelului E-R i anume: entiti, atribute,
relaii. Cele mai cunoscute modele de date sunt: modelul entitate-relaie, modelul semantic,
modelul funcional, modelul orientat obiect.
Modele de date bazate pe nregistrare
ntr-un astfel de model baza de date consta dintr-un numr de nregistrri de format fix
de tipuri eventual diferite. Fiecare tip de nregistrare definete un numr fix de cmpuri,
38
fiecare fiind n general de lungime fixa. Exista trei tipuri importante de modele de date bazate
pe nregistrare: modelul de date relaional, modelul de date reea i modelul ierarhic de
date.
Modelele ierarhic i reea au fost dezvoltate mai nti, modelul relaional aprnd cu o
ntrziere de un deceniu.
Modele fizice de date
Aceste modele descriu efectiv modul n care datele sunt memorate n calculator, la
nivel fizic. Informaia furnizata de aceste modele este cea referitoare la nregistrrile fizice, la
ci de acces, la organizarea nregistrrilor, etc.
Se considera c schema conceptuala sta la baza structurrii unei baze de date. O
schema conceptuala completa i bine gndit permite o reprezentare interna eficienta i
permite realizarea de view-uri utilizator fr 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 informaia de ctre
beneficiar, reprezentare care este independenta de detaliile de implementare cum ar fi
programele de aplicaie, limbajele de programare, SGBD-ul utilizat sau orice alte consideraii
fizice. Un astfel de model se numete model de date conceptual sau model logic.
Modelare E-R (Entity-Relaionship)
Modelul E-R (Entity-Relaionship) 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 restriciilor de cardinalitate. Avnd 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-relaie, modelul
semantic, modelul funcional, modelul orientat obiect.
Exista trei tipuri importante de modele de date bazate pe nregistrare: modelul de
date relaional, modelul de date reea i modelul ierarhic de date.
Modele fizice de date descriu efectiv modul n care datele sunt memorate n
calculator, la nivel fizic.
39
40
Concepte de baz
Conceptele primare ale modelului E-R includ : tip de entitate (mulime-entitate), tip de
relaie (mulime-relaie), atribute.
Numim entitate un obiect sau un concept ce se poate identifica n mod unic.
Noiunea 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, numrul: 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 numrul sau i numele bncii.
Numim tip de entitate sau mulime-entitate un set de entiti de acelai tip.
Exemple
Mulimea tuturor persoanelor care sunt studeni ai Facultii de tiine pot defini
mulimea-entitate sau tipul de entitate student.
Mulimea tuturor profesorilor Facultii de tiine formeaz ce?
41
Tipul de entitate reprezint o mulime de 'obiecte' ce aparin lumii reale i care sunt descrise
de aceleai proprietatea.
Orice obiect care aparine unui tip de entitate i care este identificabil n mod unic este numit
simplu entitate. (se mai ntlnesc denumirile: apariia unei entiti sau instana unei entiti).
Un tip de entitate conine mai multe entiti. O baza de date este o colecie de tipuri de entitat e
din care fiecare conine un numr neprecizat de entiti de acelai tip.
Tipurile de entitate nu sunt neaprat disjuncte. Aceasta nseamn c pot exista entiti care s
aparin mai multor tipuri de entitate.
Exemple
Se pot defini urmtoarele tipuri de entitate: profesor, corespunztor tuturor
cadrelor didactice ale Facultii de tiine i student, corespunztor tuturor
studenilor aceleiai faculti. Se observa uor c pot exista studeni care sunt
n acelai timp i cadre didactice (studeni la master care sunt preparatori sau
asisteni).
Prin domeniul atributului nelegem mulimea valorilor care pot fi atribuite unui atribut
simplu.
Atributele unei entiti conin valorile care descriu fiecare entitate i cu ajutorul crora 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_naterii se poate descompune n subdomeniile: an, lun, zi.
In general putem considera c fiecare entitate este reprezentabila cu ajutorul unei mulimi de
perechi de forma (nume_atribut, valoare_atribut), cate o pereche pentru fiecare atribut ataat
tipului de entitate corespunztor.
42
Exemple
O entitate a tipului de entitate student poate fi reprezentata de mulimea:
{(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), (numr_matricol, 31455), (grupa, 7211)}
Reprezentai 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 corespunztor tipului de entitate student.
Artai 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, numr, ora,
cod_potal i jude.
Artai 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 numrul minim i numrul 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 numrul numerelor de telefon la care poate fi gsit studentul la
43
Numim atribut derivat orice atribut a crui valoare se poate calcula din unul sau mai
multe alte atribute. Aceste atribute nu trebuie neaprat s descrie entitatea creia ii corespunde
atributul derivat.
Exemple
Valoarea pentru atributul vrsta este derivat din valoarea atributului
data_naterii i din data curent.
Artai alte atribute derivate.
Un atribut se reprezint printr-o elips, legat de entitatea creia 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.
44
Dac un atribut este compus, atunci componentele atributului se reprezint prin elipse legate
cu cate o linie de atributul compus.
Exemple
num
e
numr
bloc
adres
a
numr
adres
scara
apartam
matric
a
ent
ol
etaj
adres
a
adres
a
Reprezentarea cu diagrama E-R a entitii locatari
adres
n exemplu entitatea locatari are urmtoarele
atribute: numr_matricol, nume i
a
adresa. Dintre aceste atribute, atributul adresa
este atribut compus, care se
descompune n numr_bloc, scara, etaj adres
i apartament. Explicaia sublinierii
a
atributului numr_matricol se va da n seciunea
care se ocupa de chei, tot n
aceast unitate de nvare.
locatari
45
Numim gradul relaiei numrul entitilor participante n relaie. Aadar relaia reprezentat
mai sus are gradul n. Entitile implicate ntr-o relaie se numesc participani. Dac ntr-o
relaie sunt doi participani, atunci relaia se numete binar.
Tipurile de relaii se reprezint n diagramele E-R cu ajutorul romburilor care sunt etichetate
cu numele tipului de relaie.
Exemple
nume
num
r de
numr
matric
ol
scar
a
bloc
este
locuit
scri
1
adre
sa
locatari
M
Funcia pe care o joaca o entitate ntr-o relaie se numete rolul entitii. n general nu este
necesar s se specifice rolul entitilor ntr-o relaie, deoarece acesta este n general implicit.
Numim relaie recursiv orice relaie n care aceleai entiti particip n roluri diferite. n
acest caz este necesar s se precizeze rolurile entitilor implicate. n cazul relaiilor recursive,
n diagrama E-R corespunztoare, cele dou arce de la entitate la relaie i napoi, primesc
diferite etichete, care sunt importante n nelegerea corect a relaiei.
Exemple
Dac am considera entitile lucrtori i manageri care se refera la personalul
aceleiai ntreprinderi, am face constatarea c sunt descrise de aceleai atribute
deci aparin aceluiai tip de entitate i anume angajai. Relaia binara
lucreaz_pentru, stabilita ntre lucrtori i manageri este o relaie recursiva.
Rolurile jucate de fiecare entitate se pot stabili recurgndu-se la perechi ordonate
(muncitor, manager).
Exemple
lucrator
angajai
manager
46
lucreaz
pentru
Unui tip de relaie i se pot asocia atribute descriptive n acelai mod n care se pot asocia
atribute unui tip de entitate.
Exemple
Tipului de relaie este_locuita_de, care implica tipurile de entitate scri 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
relaie i el nu mai are sens n afara ei.
S ne reamintim...
Numim relaie orice asociere ntre entiti, cnd asocierea include cate o
entitate pentru toate tipurile de entitate participante.
Numim gradul relaiei numrul entitilor participante n relaie. Entitile
implicate ntr-o relaie se numesc participani. Dac ntr-o relaie sunt doi
participani, atunci relaia se numete binar.
Numim relaie recursiv orice relaie n care aceleai entiti particip n
roluri diferite. n acest caz este necesar s se precizeze rolurile entitilor
implicate.
Restricii structurale
Este posibil s se stabileasc diverse restricii la care coninutul unei baze de date
trebuie s se conformeze. Vom trata n continuare restriciile care se pot impune entitilor
participante ntr-o relaie. Aceste restricii trebuie s reflecte caracteristicile relaiilor aa cum
se percep n 'lumea reala'. Doua tipuri importante de restricii sunt de menionat aici: restricii
de cardinalitate i restricii de participare.
a) Restricii de cardinalitate Numim cardinalitate (polaritate) numrul relaiilor posibile
pentru o entitate participant. Altfel spus, cardinalitatea exprima numrul entitilor la care o
alta entitate poate fi asociata prin intermediul unei relaii.
Observaie: Am utilizat n definiia de mai sus referiri la entiti i la relaii pentru a fi mai
explicii. Restriciile structurale se refera insa n mod evident la tipurile de relaie i la tipurile
de entitate asociate. Aceast observaie rmne valabila i n consideraiile ce urmeaz.
Majoritatea tipurilor de relaie 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).
Relaiile unu-la-unu:
47
n relaiile unu-la-unu, o entitate, apartinand unui tip de entitate, este legat de cel mult
o entitate din celalalt tip de entitate implicat n relaia respectiva. Implicarea fiecarei entitati
ntr-o relaie data este numita "participarea entitatii".
In diagrama E-R se eticheteaza arcul dintre relaie i fiecare tip de entitate cu cardinalul
relaiei; n cazul relaiilor unu-la-unu fiecare din cele doua arce se eticheteaza cu 1.
Relaiile unu-la-mai-multe:
In relaia de tip unu-la-mai-multe orice entitate, aparinnd primului tip de entitate, este legat
de 0, 1, sau mai multe entiti apartinand celui de-al doilea tip de entitate participant la relaie.
Exemple
Exemplificm acest tip de relaie prin relaia este_locuita_de dintre tipurile de
entiti scari, respectiv locatari. n reprezentarea grafic a acestui tip de
relaie, arcul dinspre tipul de entitate scri se eticheteaz cu 1 iar arcul dinspre
tipul de entitate locatari se eticheteaz cu M
nume
num
r de
numr
matric
ol
scar
a
bloc
adre
sa
este
locuit
scri
locatari
1
Modelul semantic
este_locuita_de.
din
M
figur
reprezint
relaia
unu-la-mai-multe
Din exemplul de mai sus se observ uor c dac relaia direct este de unu-la-maimulte, atunci relaia invers este de unu-la-unu.
Relaiile mai-multe-la-mai-multe:
Acest tip de relaie se deosebete de relaia unu-la-mai-multe prin faptul c relaia
invers nu este de unu-la-unu, ci de unu-la-mai-multe. Deci, dac i relaia direct i relaia
invers sunt de tipul unu-la-mai-multe, atunci relaia directa este de tipul mai-multe-la-maimulte i se noteaz cu (N:M).
Dai un exemplu de n la m ntre student i materii.
Exemple
atribu
te
nr_blo
c
scara
scri
nr_blo
c
scara
Sc.B
nr_blo
c
scara
Sc.
A
este locuita
de
R1
R2
locatari
Fam
.1
Fam
.2
R3
Sc.C
48
Fam
.3
atribu
tenr_ma
t
numel
e
nr_ma
t
numel
e
nr_ma
t
b) Restricii de participare
Numim restricii de participare acele restricii prin care se determin dac existena
unui tip de entitate depinde de faptul c este legat sau nu de un alt tip de entitate prin
intermediul relaiei n discuie.
Participarea unei entiti poate fi total sau parial. Participarea este totala daca
existenta entitii respective necesita existenta unei entiti asociate n relaia dat. n caz
contrar participarea se numete parial. Termenii participare totala i participare parial pot
fi nlocuii cu participare obligatorie respectiv participare opionala. n diagrama E-R aceste
tipuri de relaii se reprezint prin arc cu linie dubl pentru participarea total, respectiv cu
linie simpl pentru participarea parial. Pentru participarea parial, exist un mod de notaie
prin care se eticheteaz arcele relaiei cu perechea de numere ce reprezint minimul, respectiv
maximul entitilor participante la relaie.
Exemple
Daca se considera filialele unei firme oarecare ca entiti n tipul de entitate
filiala i daca se considera tipul de entitate personal (unde entitile reprezint
personalul firmei respective) se poate defini tipul de relaie 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 relaia are_alocat este totala. Daca insa admitem c unii membri ai
personalului (de exemplu vnztorii) nu lucreaz n birourile nici unei filiale,
atunci participarea tipului de entitate personal n relaia are_alocat este pariala.
49
c) Dependenele de existen
Numim tip slab de entitate un tip de entitate, a crui existen este dependent de
existenta unui alt tip de entitate.
Numim tip tare de entitate un tip de entitate, a crui existen nu depinde de existenta nici
unui alt tip de entitate.
Entitile slabe se mai numesc existenial dependente sau subordonate iar entitile tari se
mai numesc printe 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 notaie se extinde i la relaii. Astfel: o relaie care leag doua tipuri de
entitate tari este reprezentata cu un romb trasat cu linie simpla iar relaia 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 entitile i relaiile individuale care participa la modelarea
unei baze de date sunt distincte ntre ele. Diferena ntre entiti sau diferena ntre relaii se
exprima cu ajutorul atributelor care le descriu.
Numim supercheie asociata unui tip de entitate, orice submulime a mulimii de
atribute ce descriu tipul de entitate, submulime care poate duce la identificarea n mod unic a
oricrei entiti n cadrul tipului de entitate luat n considerare.
Este evident ca, daca o submulime de atribute formeaz o supercheie, atunci orice
mulime de atribute care include supercheia este tot o supercheie.
Numim cheie candidat orice supercheie care conine un numr minim de atribute.
Pentru o cheie candidat nici o submulime proprie nu mai este supercheie. Putem spune c o
cheie candidat este caracterizata de urmtoarele proprietatea:
- unicitatea, deoarece valoarea cheii este unica pentru fiecare entitate n parte;
Dai exemple de chei n entitatea profesor.
S ne reamintim...
Participarea unei entiti poate fi total sau parial. Participarea este totala
daca existenta entitii respective necesita existenta unei entiti asociate n
relaia dat. n caz contrar participarea se numete parial.
Numim supercheie asociata unui tip de entitate, orice submulime a
mulimii de atribute ce descriu tipul de entitate, submulime care poate
duce la identificarea n mod unic a oricrei entiti n cadrul tipului de
50
51
M2.U2.2. Rezumat
Numim relaie orice asociere ntre entiti, cnd asocierea include cate o entitate
pentru toate tipurile de entitate participante.
Numim gradul relaiei numrul entitilor participante n relaie. Entitile
implicate ntr-o relaie se numesc participani. Dac ntr-o relaie sunt doi
participani, atunci relaia se numete binar.
Numim relaie recursiv orice relaie n care aceleai entiti particip n roluri
diferite. n acest caz este necesar s se precizeze rolurile entitilor impli cate.
Numim cardinalitate (polaritate) numrul relaiilor posibile pentru o entitate
participant.
Majoritatea tipurilor de relaie 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-maimulte (M:N).
n relaiile unu-la-unu, o entitate, apartinand unui tip de entitate, este legat de cel
mult o entitate din celalalt tip de entitate implicat n relaia respectiva
In relaia de tip unu-la-mai-multe orice entitate, aparinnd primului tip de
entitate, este legat de 0, 1, sau mai multe entiti apartinand celui de-al doilea tip
de entitate participant la relaie.
Relaiile mai-multe-la-mai-multe se deosebete de relaia unu-la-mai-multe prin
faptul c relaia invers nu este de unu-la-unu, ci de unu-la-mai-multe. Deci, dac
i relaia direct i relaia invers sunt de tipul unu-la-mai-multe, atunci relaia
directa este de tipul mai-multe-la-mai-multe i se noteaz cu (N:M).
Numim supercheie asociata unui tip de entitate, orice submulime a mulimii de
atribute ce descriu tipul de entitate, submulime care poate duce la identificarea n
mod unic a oricrei entiti n cadrul tipului de entitate luat n considerare.
Numim cheie candidat orice supercheie care conine un numr minim de
atribute. Pentru o cheie candidat nici o submulime 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 entitilor n cadrul tipului de entitate respectiv.
Si relaiile au chei. Cu ajutorul cheilor se pot identifica n mod unic relaiile
individuale. Cheia primara a tipului de relaie este formata din reuniunea mulimilor de
atribute care formeaz cheile primare ale tipurilor de entitate participante.
52
Cuprins
Introducere
Obiectivele modului
U3.1 Algebra relaional.
U3.2 SQL.
M3. Introducere
Una din funciunile importante ale SGBD+urilor este regsirea datelor. Pentru
aceasta trebuie s facem cereri la baza de date. Modelul matematic al acestor
cereri la baza de date relaional este algebra relaional, iar limbajul standardizat
de cereri este SQL.
53
54
Exemple
Sa considerm, de exemplu domeniile D1, D2, D3, definite astfel:
D1: ("F","M")
D2 : (x / x aparine N, x aparine [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 apartinnd
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> aparin produsului cartezian: D3 x D1 x
D2
S presupunem c se acord o anumit semnificaie valorilor domeniilor D1, D2, D3,
definite anterior.
Sa considerm, de exemplu ca D1 cuprinde valorile referitoare la sexul unei persoane,
D2 conine valori care exprim vrsta unei persoane i D3 cuprinde numele unor persoane.
Numai unele dintre tuplurile produsului cartezian: D3 x D1 x D2 pot avea o
semnificaie i anume cele care conin numele, sexul i vrsta aceleiai persoane.
Dintre cele 202 tupluri care au valoarea "Vasile" pe prima pozitie, numai unul
poate avea o semnificaie, dac presupunem c exist o singur persoan cu
acest nume.
Se desprinde de aici necesitatea definirii unei submulimi de tupluri, din cadrul
produsului cartezian al domeniilor, submulime care s cuprind numai tuplurile cu
semnificaie.
Relaia reprezint un subansamblu al produsului cartezian al mai multor domenii,
subansamblu caracterizat printr-un nume i care conine tupluri cu semnificatie. Considernd
de exemplu c nu se cunosc dect dou persoane definim realia R prin tuplurile care descriu
aceste persoane i anume:
R : (<"Maria", "F", 30>, <"Vasile", "M", 35>)
Intr-o relaie, tuplurile trebuie s fie distincte (nu se admit duplicri ale
tuplurilor) .
O reprezentare comod a relaiei este tabelul bidimensional (tabela de date n care
liniile reprezinta tuplurile, iar coloanele corespund domeniilor (fig.3.1.).
Exemple
55
Semnificaia valorilor din cadrul unui tuplu se stabilete n acest caz nu numai pe baza
domeniului de care aparin valorile, ci i in funcie de poziia ocupat n cadrul tuplului.
Dependena fat de ordine a datelor inseamn o reducere a flexibiltii 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 diferenia coloanele care conin valori ale
aceluiai domeniu i a elimina astfel dependena de poziie n cadrul tabelei se asociaz
fiecarei coloane un nume distinct, ceea ce duce la aparita n oiunii de atribut.
Atributul reprezint coloana unei tabele de date, caracterizat printr -un nume. Numele
coloanei (atributului) exprim de obicei semnificaia valorilor din cadrul coloanei respective.
Schema unei relaii
Prin schema unei relaii se ntelege numele relaiei, urmat de lista atributelor, pentru
fiecare atribut precizndu-se domeniul asociat. Astfel, pentru o relaie R, cu atributele A1, A2,
..., An i domeniile: D1, D2,..., Dm, cu m <= n, schema relaiei R poate fi reprezentat ntr una din formele
A1:D1
R(A1:D1, , A n:Dm)
a)
b)
56
An:Dm
57
Exemple
JUDE: D1
Braov
Dmbovia
Braov
Dmbovia
Braov
Dmbovia
JUDE:D1
Braov
Dmbovia
TRANSPORT:D3
tramvai
tramvai
autobuz
autobuz
troleibuz
troleibuz
ANSP:D3
tramvai
X
autobuz
troleibuz
ORAE:
TARIF:D4
30
30
50
50
50
50
TARIF:D3
30
50
50
TARIFE
58
4. Proiecia. Reprezint o operaie din AR definit asupra unei relaii R, operaie care const
din construirea unei noi relaii P, n care se regsesc unele atribute din R, nseamn efectuarea
unor tieturi verticale asupra lui R, care pot avea ca efect apariia unor tupluri duplicate ce se
cer a fi eliminate.
Prin operaia de proiecie se trece de la o relaie de grad n la o relaie de grad
p, mai mic dect cel iniial (p < n) ceea ce explic i numele de proiecie atribuit operaiei.
Notaia uzual pentru operaia de proiecie este:
Ai,Aj,,Am (R)
Exemple
unde: "operator de comparaie" poate fi: <, <=, >=, > sau <>.
Notaia folosit in mod uzual pentru desemnarea operaiei de selecie este urmtoarea:
(conditie)R
59
Exemple
60
Jonciunea natural. In cazul equijoinului, schema relaiei conine toate atributele celor
doi operanzi (fig.3.10.) n toate tuplurile relaiei rezultat vor exista de aceea cel puin dou
valori egale. In sensul eliminrii acestei redundane s-a introdus jonciunea natural, ca
operaie definit pe dou relaii: R1 i R2, prin care este construit o noua relaie R3, a crei
schem este obinut prin reuniunea atributelor din relaiile R1 i R2 (atributele cu acelai
nume se iau o singur dat) i a crei extensie conine tuplurile obinute prin concatenarea
tuplurilor din R1 cu tuplurile din R2 care prezint aceleai valori pentru atributele cu acelai
nume.
Notaia uzual pentru jonciunea natural este:
Reprezentarea grafic a acestei operaii este prezentat n fig. 3.10.
61
Exemple
62
Exemple
Intersecia reprezint o operaie derivat, care poate fi exprimat prin intermediul unor
operaii de baz. De exemplu, operaia de intersecie se poate exprima prin intermediul
operaiei de diferen, cu ajutorul urmtoarelor echivalene:
R1 R2=R1-(R1-R2)
R1 R2=R2-(R2-R1)
M3.U3.1. Rezumat
Reuniunea reprezint o operaie a AR definita pe doua relaii: R1 i R2 ambele
cu o aceeai schem, operaie care const din construirea unei noi relaii R3, cu
schema identic cu R1 i R2 i avnd drept extensie tuplurile din R1 i R2 luate
impreun o singur dat.
Diferena reprezint operaie din AR definit pe doua relaii: R1 i R2, ambele
cu o aceeai schem, operaia constnd din construirea unei noi relaii R3, cu
schema identic cu a operanzilor i cu extensia format din acele tupluri ale
relaiei R1 care nu se regsesc i n relaia R2.
Produs cartezian reprezint o operaie a AR definit pe dou relaii: R1 i R2,
operaie care const din construirea unei noi relaii R3, a crei schem se obine
prin concatenarea schemelor relaiilor R1 i R2 i a crei extensie cuprinde toate
combinaiile tuplurilor din R1 cu cele din R2.
Proiecia reprezint o operaie din AR definit asupra unei relaii R, operaie
care const din construirea unei noi relaii P, n care se regsesc unele atribute
din R, nseamn efectuarea unor tieturi verticale asupra lui R, care pot avea ca
efect apariia unor tupluri duplicate ce se cer a fi eliminate.
Prin operaia de proiecie se trece de la o relaie de grad n la o relaie de grad
p, mai mic dect cel iniial (p < n) ceea ce explic i numele de proiecie atribuit
operaiei.
Selecia reprezint o operaie din AR definit asupra unei relaii R,
operaie care const din construierea unei relaii S, a crei schem este identic
63
cu cea a relaiei R i a crei extensie este constituit din acele tupluri din R care
satisfac o condiie menionat explicit n cadrul operaiei. ntruct cel mai
adesea, nu toate tuplurile din R satisfac, aceast condiie, selecia nseamn
efectuarea unor tieturi orizontale asupra relaiei R, adic eliminarea de tupluri.
Jonciunea (Joinul) reprezint o operaie din AR definit pe dou relaii: R1 i
R2, operaie care const din construirea unei noi relaii R3, prin
concatenarea unor tupluri din R1 cu tupluri din R2. Se concateneaza acele
tupluri din R1 i R2 care satisfac o anumita condiie, specificat explicit n
cadrul operaiei. Extensia relaiei R3 va contine deci combinaiile acelor tupluri
care satisfac condiia de concatenare.
Jonciunea natural. In cazul equijoinului, schema relaiei conine toate
atributele celor doi operanzi n toate tuplurile relaiei rezultat vor exista de aceea
cel puin dou valori egale. In sensul eliminrii acestei redundane s-a introdus
jonciunea natural, ca operaie definit pe dou relaii: R1 i R2, prin care este
construit o noua relaie R3, a crei schem este obinut prin reuniunea
atributelor din relaiile R1 i R2 (atributele cu acelai nume se iau o singur dat)
i a crei extensie conine tuplurile obinute prin concatenarea tuplurilor din R1
cu tuplurile din R2 care prezint aceleai valori pentru atributele cu acelai
nume.
M3.U3.1. Test de autoevaluare a cunotinelor
3.1.1 Cosiderai instane ale tabelei student, profesor,materii i catalog.
a)
Facei selecie din student dup grupa
b)
Facei proiecie la student i la profesor dup nume. La acestea dou din
urm facei reuniunea.
c)
Faceti jonciunea natural intre student i catalog apoi ntre rezultat i
materii.
d)
Facei selecia tabelei de mai nainte dup nota < 5.
3.1.2 S se exprime n algebra relaional cererile:
a)
Studenii grupei 7271
b)
Studenii care sunt i profesori
c)
Studenii corigeni
d)
Studenii integraliti
Rspunsurile se gsesc la sfrit la pag 152
64
65
Lista_selecie
Cuprinde toate cmpurile care vor aparea n tabela cu rezulta tele interogrii.
Atenie! }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 relaional, dup cum urmeaz:
Clauza SELECT menioneaz o list de atribute i corespunde proieciei din algebra
relaional;
Clauza FROM menioneaz o list de relaii (tabele) i corespunde produsului cartezian din
algebra relaional;
Clauza WRERE descrie un predicat de selecie i corespunde seleciei din algebra relai onal.
nelesul diferit al termenului select utilizat n SQL i n algebra relaional este un fapt
istoric nefericit. n SQL, select desemneaz proiecia, iar n algebra relaional acelai
termen desemneaz selecia dup un predicat de selecie.
Lista de atribuire care apare n clauza SELECT din SQL poate fi nlocuit cu simbolul *
dac se dorete selectarea tuturor atributelor care apar n relaiile din clauza FROM.
Clauza ORDER BY
Utilizat atunci cnd se dorete ca rezultatele interogrii s fie ordonate n mod
cresctor (ASC) sau descresctor (DESC). Sortarea este opional i se poate realiza dupa
unul sau mai multe cmpuri_criteriu (definite drept chei de sortare). Componenta BY a
clauzei nu poate s lipseasc atunci cnd se dorete sotrarea rezultatelor interogrii SQL.
Rezultatul unei interogri SQL este ntotdeauna o relaie (o tabel).
Pentru a putea da exemple concrete ne vom referi la baza de date: centrul de nchiriere casete
video. Avem urmtoarele 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 afieze toate datele despre toi clienii.
SELECT *
FROM Clieni
.S se afieze toate datele despre toi actorii.
Exemple
S se afieze oraele de reedin ale tuturor clienilor
SELECT Ora
FROM Clieni
66
Exemple
S se afieze datele despre filmele din baza de date n ordinea alfabetic a
titlurilor filmelor
SELECT *
FROM Filme
ORDER BY Titlu,ASC
Afiai, ca mai sus, dar n ordine descendent.
S se afieze 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 meniunea ASC, ordinea tuplelor ar fi fost
aceeai deoarece ordinea ascendent este implicit.
n scrierea interogrilor de selecie simple SQL se pot folosi i funcii totalizatoare,
cunoscute i sub numele de funcii standard sau funcii agregat, care apar n clauza SELECT
i se aplic atributelor din tabelele implicate n interogare. Funcii standard sunt:
valoarea medie AVG
valoarea minima MIN
valoarea maxima MAX
total (sumare) SUM
numaratoare COUNT
Nu este permis utilizarea acestor funcii n clauza WHERE deoarece ele acioneaz la nivel
de atribut i nu la nivel tuplu.
Exemple
Care este suma minim pltit?
SELECT MIN (suma)
67
FROM plati
.Care este suma maxim pltit?
Exemple
Care este preul mediu al casetelor?
SELECT AVG(Pret)
FROM Casete
Care este suma medie ncasat.
Exemple
Care este suma total pltit pentru mprumutul cu cod 30?
SELECT SUM (suma)
FROM plati
WHWRE Cod_imprumut=30
Care este valoarea total a casetelor.
Exemple
Cate tulpe conine tabela de casete?
SELECT COUNT (*)
FROM Casete
Cte tupe conine tabela clienti.
Exemple
Cate genuri de filme sunt nregistrate pentru filmele din baza de date?
SELECT COUNT (DISTINCT Gen)
FROM Filme
68
Funciile de grup agregat permit construirea unor interogri SQL complexe, prin care
utilizatorul poate s efectueze diverse calcule pentru grupuri de nregistrri care au cmpuri cu
aceeasi valoare. n cazul utilizrii lor se folosete urmtoarea form a frazei SELECT:
SELECT [domeniu] [funcie agregat (nume_cmp) AS alias [,lista_selecie]
F ROM nume_tabela1, nume_tabela2
GROUP BY cmp_de_grupare
[HAVING criteriu_de_grupare]
[ORDER BY cmpuri_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 relaiile din care fac parte
atributele. Aadar o interogare SQL trebuie s conin cel puin urmtoarele informaii:
SELECT <lista de atribute>
FROM <lista de relatii>
restul clauzelor sunt opionale.
Lista selecie
Se va referi la una sau mai multe funcii agregate care au ca argumente nume de cmpuri ale
bazei de date. Exist restricia ca aceste cmpuri sa fie ntotdeauna de tip num eric.
AS alias
Asociaz un pseudonim (nume) rezultatului utilizrii funciei agregat
Clauza GROUP BY i HAVING
n unele cazuri, utilizatorul dorete anumite situatii sintetice, cum ar fi obinerea de totaluri i
subtotaluri. Pentru aceste operaii, limbajul SQL permite utilizarea clauzelor GROUP BY i
HAVING.
Aceste clauze organizeaz tuplele n grupuri asupra crora se pot realiza anumite
operaii, n special prin aplicarea funciilor agregat.
Clauza GROUP BY grupeaza tuplele din relaie dup atributele cu aceeai valoare
care sunt specificate n clauz, i genereaz un tuplu pentru fiecare grup de tuple cu aceeai
valoare pe atribut
Atributele care apar n clauza SELECT pot fi de dou feluri:
-atribute care alctuiesc 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 cte ri avem filme.
Exemple
Ci clieni au sediul n fiecare oras?
SELECT Oras,COUNT(*)
69
FROM Client
GROUP BY Oras
Cte filme sunt din fieare ar.
Exemple
n care case locuiesc cel puin 3 clieni?
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 puin 2 filme.
Exemple
S se afieze n ordine alfabetic oraele n care exist clieni ai centrului.
SELECT Oras
FROM Clienti
GROUP BY Oras
ORDER BY Oras
S se afieze n ordine alfabetic rile din care avem filme.
Exemple
Care sunt clienii 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 fcute dup data 01/01/2009 .
70
Operatori logici
Dac o clauza WHERE conine mai multe condiii formate prin utilizarea aceluiai tip de
operator logic, evaluarea se va face de la stnga la dreapta. Tipul de operator logic este dat de
precedena operatorilor. Operatorul NOT are cea mai mare prioritate, urmat de OR i AND
care practic sunt de prioriti egale. Pentru a schimba ordinea de evaluare a unei expresii se
utilizeaz parantezele rotunde ().
Exemple
Sa se afieze codul i titlul filmelor din SUA care au anul apariiei mai mare
dect 2000.
SELECT Cod_film,Titlu
FROM Filme
WHERE Tara=SUAAND An_aparitie>2000
S se afieze plile mai mari de 100 lei fcut n anul 2009.
Exemple
Sa se afieze codul i titlul filmelor din SUA sau care au anul apariiei mai mare
dect 2000.
SELECT Cod_film ,Titlu
FROM Filme
WHERE Tara=SUAOR An_aparitie>2000
A se observa c ultima interogare este echivalent cu interogarea :
SELECT Cod_film ,Titlu
FROM Filme
WHERE Tara=SUAOR NOT An_aparitie<=2000
72
Exemple
Care filme au acelasi gen cu filmul Titanic? A se observa c aceast interogare
necesit realizarea produsului cartezian al tabelei cu ea nsi.
SELECT p1.Titlu,p2.Titlu,p1.Gen.p2.Gen
FROM Filme p1,Filme p2
WHERE p1.Gen=p2.Gen AND p2.Titlu=Titanic
73
Exemple
Sa se afieze codul casetelor, preul 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=[CaseteFiml].Cod_film
WHERE (((Casete.disponibile)=Yes));
Sa se afieze filmele i casetele pe care se gsesc. Procedai ca mai sus.
74
SELECT A1,,Am
FROM
[WHERE]
UNION
SELECT A1,,Am
FROM
[WHERE]
Exemple
S se afieze numele clienilor care sunt fie din Rnov fie din Braov 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);
75
76
Exemple
Care sunt clienii 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 clieni 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 interogri difer doar prin operatorul logic NOT. De
asemenea se poate remarca faptul c prima interogare amintete de apartenena din teoria
mulimilor iar a doua interogare corespunde operaiei minus (diferena). Dac versiunea SQL
nu are un cuvnt rezervat pentru operaia diferena inter tabele, se poate construi aceasta
operaie cu ajutorul predicatului NOT IN ca n exemplul de mai sus.
Subinterogri corelate
n exemplele de pn acum, interogarea interioar era evaluat prima, dup care
valoarea, sau valorile, rezultate erau utilizate de ctre clauza WHERE din interogarea
exterioar.
Exista i o alt forma de subinterogare i anume Subinterogarea corelat, caz n care
interogarea exterioar transmite repetat cte o valoare pentru interogarea interioar.
De fiecare dat cnd este transmis o valoare, este evaluat interogarea interioar.
Dac ambele interogri acceseaza acelai table, trebuie asigurate alias-uri pentru fiecare
referina la tabelul respectiv. Ambele interogri acceseaz tuple diferite din acelai table n
acelai moment.
Exemple
Sa se afieze codurile imprumuturilor, data imprumutului, data unei plai i suma
pltit, pentru sumele maxime care s-au pltit, ordonate dup data mprumutului.
SELECT Imprumuturi.Cod_imprumut, Imprumuturi.Data_ imprumut,
plati.data,plati.suma
FROM Imprumuturi INNER JOIN plati ON Imprumuturi.Cod
77
_imprumut=plati.cod_imprumut
WHERE suma=
(SELECT MAX(suma)
FROM plati
WHERE Imprumuturi.Cod_ Imprumut=plati.cod_ Imprumut) ORDER BY
Imprumuturi..Data_ Imprumut;
Restricionare subinterogrilor
Operatorii ANY i ALL
Operatorul ANY poate fi utilizat n cobinaie cu oricare dintre operatorii relaionali (=
< > <= >= !=) pentru a se varifica dac valorile unui atribut este egal, mai mic, mai mare,
etc. dect oricare dintre valorile menionate 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. dect toate valorile generate de interogarea
interioar. S facem observaia c acest operator nu poate fi utilizat cu operatorul relaional =,
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 dm
mai jos o serie de cazuri concrete.
S presupunem ca interogarea este de forma:
SELECT
FROM
WHERE x <ALL (1,2,3,4)
S observm c dac nlocuim operatorul ALL cu expresia verbal toate putem citi
Valorile lui x trebuie s fie mai mici dect toate valorile d in paranteza ce urmeaza dup
ALL.
Atunci vom lua n considerare urmatoarele situaii:
Expresia din clauza WHERE
X<ALL
X<=ALL
X>ALL
X>=ALL
78
Exemple
Exemple:
S se afieze titlul filmelor, anul apariiei i genul, pentru filmele din SUA,
care au anul apariiei 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 afieza codul casetelor, preul, 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= [CaseteFilme].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 relaiei exist tuple care
satisfac condiia interogrii 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 relaie diferit de cea
utilizat n interogarea exterioar.)
Ca i operatorii ANY i ALL, operatorul EXISTS apare n clauza WHERE.
Exemple
S se afieze titlui filmelor, anul aparitiei i genul pentru filmele care au un an de
apariie mai mare sau egal cu anul maxim de apariie al fi lmelor de gen fabula.
79
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 definete o tabel care conine tuple pentru care se
verific condiia din clauza WHERE intern.
Actualizri ale bazei de date.
SQL poate fi folosit att pentru interogarea bazei de date ct i pentru actualizarea
bazelor de date. Comenzile pentru actualizri nu sunt att de complexe ca declaraia SELECT.
Declaraiile SQL aferente actualizrii unei baze de date se refer la modificrile unei tabele
(adugare sau tergere de linii, modificarea datelor dintr -o tabel):
Adugarea se face cu declaraia INSERT care are dou forme prima accepta
adugarea unei singure linii, iar a doua adugarea mai multor linii.
I. Adugarea 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 ecificm aceast
list atributele pe care dorim s le omitem trebuie s le declarm ca NULL. Numrul de
elemente din cele dou liste trebuie s coincid, s aib aceai ordine de declarare i s fie
compatibile ca tip.
Exemple
Exemplu:
Inserai o nou nregistrare n tabela Conducere completnd 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)
Inserai o nou nregistrare n tabela casete.
Exemple
80
II. Adugarea 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 declaraie valid.
Exemple
Inserai o nou nregistrare n tabela Conducere completnd datele doar pentru
atributele obligatorii cod, Nume, Prenume, Functie
INSERT INTO Conducere
VALUES (cd44, Aduducai, Maria, NULL, NULL,asisent manager,NULL,
NULL)
Exemplu:
Exemple
Presupunnd c n tabela ContConducere conine numele celor din
conducere i numrul serviciilor pe care le au n subordine populai tabela
ContConducere folosind detalii din tabelele Conducere i PorpServicii o nou
nregistrare n tabela Conducere completnd 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))
81
Exemple
Modificarea tuturor nregistrrilor pentru mrirea salariior tuturor celor din
conducere cu 3%.
UPDATE CONDUCERE
SET salariu = salariu*1.03
Modificarea preului la casetele cu preul maxim prin reducere cu 10%.
2. Modificarea doar a unor nregistrri specificate
UPDATE CONDUCERE
SET salariu = salariu*1.05
WHERE functie=manager
Modificarea nregistrrilor pentru mai multe atribute
UPDATE CONDUCERE
SET functie=manager, salariu = 18.000.000
WHERE id=cd73
tergerea se face cu declaraia DELETE , sintaxa acestei comenzi este :
DELETE FROM nume_tabela
WHERE conditie_cautare
Dac opiunea WHERE lipsete atunci se terg toate nregistrrile darn nu i tabelul,
pentru a terge un tabel folosim declaraia DROP TABLE. Se poate terge un tabel numai
dac nu mai are nregistrri.
Exemple
1. tergerea tuturor nregistrrilor din tabela vedere (view)
DELETE FROM viewing;
2. tergerea anumitor nregistrri din tabela vedere (view)
DELETE FROM viewing;
WHERE id = cd72
tergerea tuturor nregistrrilor din tabela casete.
tergerea nregistrrilor din tabela casete cu pre minim.
82
M3.U3.2. Rezumat
Pentru definirea interogrilor de selecie simple se utilizeaz urmtoarea sintax
a instruciunii SELECT:
SELECT[domeniu]lista_selecie
FROMnume_tabela1,nume_tabela2
[WHERE criteriu_de_selecie}
ORDER BY cmpuri_criteriu [ASC/DESC]];
Funciile de grup agregat permit construirea unor interogri SQL
complexe, prin care utilizatorul poate s efectueze diverse calcule pentru grupuri
de nregistrri care au cmpuri cu aceeasi valoare. n cazul utilizrii lor se
folosete urmtoarea form a frazei SELECT:
SELECT [domeniu] [funcie agregat (nume_cmp) AS alias [,lista_selecie]
FROM nume_tabela1, n ume_tabela2
GROUP BY cmp_de_grupare
[HAVING criteriu_de_grupare]
[ORDER BY cmpuri_criteriu [ASC/DESC]];
Sintaxa general pentru jonciuni este urmtoarea:
SELECT [domeniu] lista_selecie
FROM nume_tabela1,nume_tabela 2
WHERE criteriul_de_asociere]
[ORDER BY cmpuri_criteriu[ASC?DESC];
O alt abordare privete jonciunile ca fiind: interne (INNER JOIN) i externe
(OUTER JOIN). Primele determin o asociere a nregistrrilor din tabele, astfel
ncat sa rezulte un numar total de nregistrri din fiecare tabela. Jonciunile
externe, la randul lor, sunt de doua tipuri: de stanga (LEFT OUTER JOIN) i de
dreapta (RIGHT OUTER JOIN) fiind destul de puin utilizate.
n acest mod de abordare al jonciunulor sintaxa va avea forma:
SELECT [domeniu] lista_selecie
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_selecie]
[ORDER BY cmpuri_criteriu {ASC/DESC]]:
Unul din motivele pentru care SQL este considerat un limbaj puternic de
interogare este acela c ofer posibilitatea construirii interogrilor complexe,
formate din mai multe subinterogri simple.
Aceste interogri complexe sunt construite prin includerea n clauza
WHERE a nc unei clauze SELECT. Forma general a unei astfel de
construcii este:
SELECT <lista atributelor>
FROM <lista relatii1>
WHERE <subinterogare>
SQL poate fi folosit att pentru interogarea bazei de date ct i pentru
actualizarea bazelor de date. Comenzile pentru actualizri nu sunt att de
complexe ca declaraia SELECT.
Adugarea se face cu declaraia INSERT care are dou forme prima accepta
adugarea unei singure linii, iar a doua adugarea mai multor linii.
83
84
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.
85
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 relaii cu
scopul de a minimiza redundana informaiilor i (odata cu aceasta) spaiul ocupat de relatii
(tabele sau fiiere) pe suportul magnetic.
Exemple
Fie relaia 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
2,150,000
R1234567
C15
Incalzire 30.06.99
F100
500,000
R1234567
C16
F110
Renel
3,000,000
R7654321
C10
Iluminat
30.06.99
F110
200,000
R7654321
C11
Lift
30.06.99
Romgaz
Renel
Anomalii de tergere
n cazul tergerii unei cheltuieli a asociaiei de locatari ctre 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 relaia Furnizori_Cheltuieli dorim s schimbm valoarea unui atribut al unui
furnizor, va trebui s schimbm datele pentru fiecare apariie a acelui furnizor. De exemplu
dac dorim s schimbm codul fiscal al furnizorului cu codul F100, va trebui s schimbm
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
87
Ri = R
i 1
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 r 1, r2, , rn construite
pe schemele de relatie ce formeaza descompunerea. In termenii algebrei relaionale se poate
considera egalitatea;
ri =
Ri
(r)
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.
Dependene funcionale
Unul din cele mai importante concepte asociate cu normalizarea este conceptul de
dependen funcional. Dependena funcional 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 A R
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 t 1[A]=t2[A], are loc intotdeauna i t 1[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 funcionale, atributul, sau mulimea
atributelor din partea stng a sgeii.
Exemple O parte dintre
Furnizori_Cheltuieli sunt:
dependenele
Cod_furn Den_furn
88
funcionale
pentru
relaia
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 t 1 i t2 din r, pentru care t 1[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. Dependena funcional este o proprietate legata de
semantica atributelor n relaii. Dependentele functionale pot fi stabilite de cine cunoaste exact
legaturile intre valorile atributelor, deci de catre cineva care cunoaste foarte bine aplicaia 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 creterii 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
89
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:
r X ri
i 1
unde prin X s-a notat produsul cartezian, operatie din algebra relaionala. Altfel spus, orice
tuplu din relatia r duce, prin descompunere, la cate un tuplu t i 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 {R 1, R 2, , 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:
n
r= X Ri (r)
i 1
Vom prezenta in continuare un criteriu cu ajutorul caruia se poate verifica daca este o
descompunere fara pierderi la jonctiune sau nu.
90
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, R 2, , Rn} o descompunere a lui R. Notam cu F i restrictia la R i a multimii de dependente
functionale F. (Se cere ca dependentele functionale din F i sa includa doar atribute care se
regasesc in relatia R i).
n
Vom obtine un set de multimi de dependente functionale F1, F2, , Fn. Fie F'=
Fi,
i 1
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 proiectrii incorecte pot aprea anomalii la in serare de noi
nregistrri, la terger i la modificri.
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 {R 1, R2, , R n} daca
n
Ri = R
i 1
Ri
(r)
91
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 t 1[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 creterii 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.
92
C11
Lift
30.06.99
200,000
Tabela nenormalizat Furnizori_Cheltuieli.
Conform primei modaliti, eliminm grupurile repetitive, prin crearea altor
nregistrri, 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
relaie mpreun cu cheia primar din tabela iniial. Putem avea mai mu lte grupuri repetitive.
n acest caz crem mai multe relaii noi. Aceste relaii noi, precum i tabela normalizat vor fi
n form normal unu.
Observm 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
intersecie linie coloan.
Daca vom normaliza dupa prima metoda, vom scrie repetiiile pe diferite rnduri iar
coloanele care nu conin repetiii, vor fii copiate corespunzator pe fiecare rnd
Exemple 4.2.2
Cod_furn Den_furn Cod_fiscal Cod_chelt
Valoare
F100
Romgaz
R1234567 C15
2,150,000
F100
Romgaz
R1234567 C16
500,000
F110
Renel
R7654321 C10
3,000,000
F110
Renel
R7654321 C11
200,000
Tabela Furnizori_Cheltuieli n 1NF
Den_chelt Data
Incalzire 30.06.99
Apa calda 30.06.99
Iluminat
30.06.99
Lift
30.06.99
94
F110
Renel
R7654321
95
Toi cei trei determinani sunt i chei candidat in relatiile lor. Deci relatiile din
exemplul de mai sus sunt n form normal Boyce-Codd. Relaiile n form normal trei sunt
n general i n form normal Boyce-Codd. n cazul n care relaia nu este n form normal
Boyce-Codd, trecerea la BCNF se realizeaz prin tergerea din relaia iniial a atributelor
care sunt asociate unui determinant care nu este cheie candidat i crearea unei noi relaii cu
aceste atribute i determinantul lor.
Exist situaii cnd este foarte greu de descompus relatiile, ca s ajungem la BCNF. n
aceste situaii este indicata rmnerea la forma normal trei.
M4.U4.2. Rezumat
Forma Normal Unu (1NF)
Trebuie s cutm toate interseciile de linii i coloane, unde exist repetiii.
Aceste repetiii se pot elimina prin dou madaliti:
Crearea de noi nregistrri pentru fiecare valoare a repetiiei, dup care se caut
o nou cheie primar.
tergerea atributelor care conin repetiii i crearea de noi relaii care vor
conine atributele terse, precum i cheia primara din relaia iniial.
97
Valoare
1500000
500000
3000000
200000
98
Cuprins
Introducere
Obiectivele modului
U5.1 Generaliti i proiectarea conceptual
U5.2 Proiectarea logica
U5.3 Proiectarea fizica
U5.4 Tranzacii i concuren
U5.5 Metode de control al concurenei.
M5. Introducere
Metodologia de proiectare este o aproximare structurat, care utilizeaz
proceduri, tehnici, instrumente i documentaii pentru a facilita procesul de
proiectare.
Metodologia de proiectare se compune din etape, care la rndul lor se
compun din pai, care orienteaz proiectantul la fiecare nivel al crerii bazei de
date.
n mod obinuit, un sistem SGBD deservete mai muli 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 execuia concurent a mai multor procese. Execuia concurent a mai multor
procese poate avea loc att ntr-un sistem uniprocesor, prin partajarea (mprirea)
timpului de execuie al procesorului ntre mai multe procese, ct 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 numrul de procesoare ale sistemului,
accesul concurent al mai multor utilizatori la datele memorate n tabelele unei baze de
date necesit tehnici de meninere a consistenei (corectitudinii) i a siguranei datelor
memorate.
99
proiecteze formulare
proiecteze rapoarte
construiasc tranzacii corecte
aleag cea mai bun metod de control al concurenei
introduc regulile de integritate
s impun msuri de securitate
100
M5U1 Introducere
Metodologia de proiectare are o mare importan n ordonarea muncii grele de
proiectare a unui sistem informatic. Prima etap, mai puin standardizat i care
depinde esenial de experiena celui care o deplinete, este proiectarea
conceptual, n care trebuie s aflm cum funcioneaz intreprinderea i ce parte
din circuitul informaional va fi automatizat.
M5.U1. Obiectivele unitii de nvare
La sfritul acestei uniti de nvare studenii vor fi capabili s:
respecte o metodologie de proiectare
creeze modelul conceptual al unui sistem informatic
101
Problema proiectrii bazelor de date este complicat i de faptul c, de cele mai multe ori,
procesul de proiectare ncepe cu cerine foarte generale i imprecis formulate. Prin contrast, proiectul
rezultat trebuie s conin schema bazei de date precis definit, dat fiind c, dup implementarea
aplicaiilor, modificarea bazei de date este mult mai dificil.
Terminologia folosit n domeniul proiectrii bazelor de date este destul de variat, existnd i
unele ambiguiti 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 lucrri din domeniul proiectrii bazelor de date.
nainte de a se proiecta efectiv o baz de date, este necesar s se cunoasc ce rezultate se ateapt
utilizatorii poteniali s obin de la baza de date respectiv i ce informaii primare sunt disponibile
pentru aceasta. De asemenea, este necesar s se cunoasc ce aplicaii se vor efectua (aplicaii de gestiune
a stocurilor, aplicaii contabile, aplicaii de urmrire a consumurilor, aplicaii de salar izare, etc.).
n general, n aceast faz de colectare i analiz a cerinelor, se desfoar urmtoarele activiti:
Chestionare structurate, n general n limbaj natural, pe baza crora 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.
102
S ne reamintim...
O metodologie este o cale de a apllica n proiectare metoda divide et
impera. Separarea n pai asigur divizarea problemei iniiale n probleme mai
mici i deci mai uor de rezolvat, iar partea de impera este rezolvat de
succesiunea strict a pailor i de faze speciale cum ar fi, n cazul nostru,
realizarea modelului logic global.
Paii mari ai metodologiei pe care o prezentm aici sunt proiectarea
logic i proiectarea fizic.
Problema proiectrii bazelor de date este complicat i de faptul c, de cele mai
multe ori, procesul de proiectare ncepe cu cerine foarte generale i imprecis formulate.
Prin contrast, proiectul rezultat trebuie s conin schema bazei de date precis definit.
nainte de a se proiecta efectiv o baz de date, este necesar s se cunoasc ce
rezultate se ateapt utilizatorii poteniali s obin de la baza de date respectiv i ce
informaii primare sunt disponibile pentru aceasta.
n aceast faz de colectare i analiz a cerinelor, se desfoar urmtoarele
activiti:
i interviuri.
Prezentarea metodologiei
Prima dat s vedem care sunt paii de urmat n proiectare:
Pasul 1. Proiectarea logic a bazei de date relaionale: Crearea unui model conceptual
local, pentru vederile utilizatorilor.
Pasul 1.1. Identificarea tipurilor de entiti.
Pasul 1.2. Identificarea tipurilor de relaii.
Pasul 1.3. Identificarea i atribuirea de atribute la tipurile de entiti i tipurile de
relaii.
Pasul 1.4. Determinarea domeniilor de definiie a atributelor.
Pasul 1.5. Determinarea atributelor care compun cheile candidate i primare.
Pasul 1.6. Specializare/generalizare (pas opional).
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 relaiilor pentru modelul logic local.
Pasul 2.3. Validarea modelului, utiliznd normalizarea.
Pasul 2.4. Validarea modelului din nou, utiliznd tranzaciile.
Pasul 2.5. Desenarea diagramei ER.
103
104
105
Exemple
Scrile sunt Locuite de Locatari
Furnizorii Provoac Cheltuieli
Descriei, printr-un verb al relaiei, relaia dintre student i facultate.
Descriei, printr-un verb al relaiei, relaia dintre student i note.
La identificarea relaiilor vom lua n considerare doar relaiile care ne intereseaz.
Degeaba exist i alte relaii care s se poat identificate, dac nu prezint importan pentru
problema noastr, atunci nu le lum n consideraie.
n cele mai multe din cazuri, relaiile sunt binare, adic se realizeaz ntrea exact dou
entiti. Exist i relaii mai complexe, care se realizeaz ntre mai multe entiti, sau relaii
recursive, care pune n relaie o singur entitate cu ea nsi.
Determinarea cardinalitii i a participrii la tipurile de relaii
Dup identificarea tipurilor de relaii, trebuie s determinm cardinalitatea lor, alegnd
dintre posibilitiile: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Dac se
cunosc valori specifice ale cardinalitiilor, aceste valori se scriu la documentarea relaiilor. n
continuare determinm i participarea la relaie, care poate fii total, sau parial.
Care este cardinalitatea relaiei dintre student i facultate.
Care este cardinalitatea relaiei dintre student i note.
Documentarea tipurilor de relaii
Dup identificarea tipurilor de relaii, le denumim i le introducem n dicionarul de
date, mpreun cu cardinalitatea i participarea lor.
Utilizarea modelrii ER
Pentru vizualizarea sistemelor complicate, utilizm diagrama ER, pentru c este mult
mai uor de a cuprinde toate informaiile. V propunem ca s utilizai ntotdeauna diagrama
ER, pentru o mai bun vizualizare a datelor.
Pasul 1.3. Identificarea i asocierea de atribute la tipurile de entiti i tipurile de
relaii
Obiectivul: Asocierea de atribute la tipurile de entiti i la tipurile de relaii.
Urmtorul pas n metodologie este identificarea atributelor. Aceste atribute se
identific n aceeai mod ca i entitiile. Pentru o mai uoar identificare, trebuie s lum
entitiile i relaiile ra rnd i s ne punem urmtoarea ntrebare: Ce informaii deinem
despre aceast ? Rspunsul la aceast ntrebare ne va da atributele cutate.
Atribute simple sau compuse
Este important s notm dac un atribut este simplu sau compus. Conform acestei
informaii va trebui s lum 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 lsm compus n caz contrar.
Exemple
De exemplu, atributul Adres conine informaiile (Nr_Bloc, Scara, Etaj,
Apartament). Noi va trebui s prelucrm aceste informaii separat, deci vom
descompune acest atribut n cele patru atribute simple.
Descompunei atributul adres din tabela student.
106
107
Prin procesul de identificare a cheilor primare, deducem i dac o entitate este entitate
tare, sau entitate slab. Dac reuim s identificm o cheie primar, atunci entitatea este
tare, altfel este slab. O entitate slab nu poate exista fr o entitate tare, care s-i fie
printe. Cheia primar a entitii slabe este derivat parial sau total din cheia primar a
entitii tari.
Documentarea cheilor primare i alternante
nscriem cheile primare i pe cele alternante n dicionarul de date.
Pasul 1.6. Specializarea/generalizarea tipurilor de entiti (pas opional)
Obiectivul: Identificarea entitiilor subclas respectiv superclas, ntre entitiile
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 entitii respective. Dac ns alegem procesul de
generalizare, vom cuta superclase pentru acea entitate.
Un exemplu pentru procesul de generalizare ar fii entitiile ef_de_scar i Familii.
Ambele entiti au atribuite urmtoarele atribute: Nr_mat, Nr_bloc, Scara, Etaj, Apartament i
Nume. Pe lng 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 entiti avnd atribute n comun, le putem generaliza n entitatea Locatari,
care va conine atributele comune, i entitile ef_de_scar i Familii, coninnd doar
atributele diferite - particularizrile 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 msur s prezentm o giagram complet a modelului
bazat pe vederile utilizatorilor despre ntreprindere.
108
M5.U5.1. Rezumat
O metodologie este o cale de a apllica n proiectare metoda divide et
impera. Separarea n pai asigur divizarea problemei iniiale n probleme mai
mici i deci mai uor de rezolvat, iar partea de impera este rezolvat de
succesiunea strict a pailor i de faze speciale cum ar fi, n cazul nostru,
realizarea modelului logic global.
Paii mari ai metodologiei pe care o prezentm aici sunt proiectarea logic
i proiectarea fizic.
Problema proiectrii bazelor de date este complicat i de faptul c, de cele mai
multe ori, procesul de proiectare ncepe cu cerine foarte generale i imprecis formulate.
Prin contrast, proiectul rezultat trebuie s conin schema bazei de date precis definit.
nainte de a se proiecta efectiv o baz de date, este necesar s se cunoasc ce
rezultate se ateapt utilizatorii poteniali s obin de la b aza de date respectiv i ce
informaii primare sunt disponibile pentru aceasta.
n aceast faz de colectare i analiz a cerinelor, se desfoar urmtoarele
activiti:
i interviuri.
109
110
Scari
Nr_Bloc
Scara
Cod_Cheltuiala (FK)
Cod_Furnizor (FK)
Nr_factura
Data_factura
Valoare_factura
Lift
Sunt platite de
Cheltuieli
Scari
Nr_Bloc
Scara
Lift
Nr_Crt
Pe scari
Scara (FK)
Nr_Crt (FK)
Nr_Bloc (FK)
Au cheltuieli
Cod_Furnizor (FK)
Cod_cheltuiala
Nr_factura
Data_factura
Valoare_factura
Se calculeaza
a). Relaie de tipul N:M. (b). Relaie transfornamt n dou relaii 1:M.
112
Aceast relaie se poate elimina, prin crearea unui tip de entitate suplimentar,
care s fac legtura dintre scri i cheltuieli. Diagrama acestor relaii se vede n figura b).
Notm, c tipul de entitate nou creat - Pe_scri - este tip de entitate slab, pentru c
depinde att de tipul de entitate Scri, ct i de tipul de entitate Cheltuieli.
(2) Eliminarea relaiilor complexe
O relaie complex este o relaie ntre mai mult de cou tipuri de entiti. Dac n
modelul conceptual apar relaii complexe, acestea trebuie eliminate. Se pot elimina prin
crearea unui nou tip de entitate, care s fie n relaie de tipul 1:M cu fiecare tip de entitate din
relatia iniial, partea cu M a relaiei fiind spre tipul de entitate nou creat.
(3) Eliminarea relaiilor recursive
Relaiile recursive sunt nite relaii particulare, prin care un tip de entitate este n
relaie cu el nsui. Dac apare o astfel de relaie n modelul conceptual, ea trebuie eliminat.
Eliminarea se poate rezolva prin crearea unei noi entiti unde s se evidenieze fiecare
entitate care este legat de entitatea din tipul de entitate iniial. n acest caz vom avea o relaie
de tipul 1:M ntre tipul de entitate iniial i tipul de entitate nou creat i o relaie de tipul 1:1
ntre tipul de entitate nou creat i tipul de entitate iniial.
(4) Eliminarea relaiilor cu atribute
Dac n modelul conceptual avem relaie cu atribute, putem descompune aceast
relaie, identificnd un nou tip de entitate n care s nregistrm atributele necesare.
(5) Reexaminarea relaiilor de tipul 1:1
n modelul conceptual putem avea entiti ntre care s avem relaie de tipul 1:1. Se
poate ntmpla ca aceste entiti s fie de fapt aceeai entitate cu nume diferite. Dac suntem
n acest caz, unim cele dou entiti, cheia primar devenind cheia primar al uneia dintre
entiti.
(6) Eliminarea relaiilor redundante
O relaie 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 relaiile redundante nu sunt necesare. Decizia c o relaie este redundant trebuie s fie
precedat de o analiz amnunit a relaiilor care compun cele dou drumuri dintre cele dou
entiti, pentru c pot aprea situaii, cnd o relaie 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 relaii peste modelul logic local
Obiectivul: Crearea de relaii peste modelul logic.
Relaia pe care un tip de entitate o are cu alt tip de entitate este reprezentat prin
mecanismul cheie primar/cheie strin. Cheia strin pentru o entitate este reproducerea
cheii primare a altei entiti. Pentru a decide entitiile unde vom include copia cheii primare a
altei entiti, trebuie nainte s identificm entitile printe i fiu. Entitile printe se
refer la acele entiti ale cror chei primare se vor copia n entitile fiu.
Pentru descrierea relaiilor vom folosi un limbaj de definire a bazei de date (Database
Definition Language - DDL). n acest limbaj, specificm prima dat numele entitii, urmat de
atributele asociate ntre paranteze. Dup aceea identificm cheia primar i toate cheile
alternante, precum i/sau cheile strine.
113
Menionm c n cazul acesta cheia strin este i n compunerea chei primare. Deci
nainte de introducerea cheii strine, cheia primar nu identifica unic o entitate. La terminarea
acestui pas, putem identifica cheile prinare pentru toate tipurile de entiti din modelul logic.
Tipurile de relaii binare de tipul unu-la-unu (1:1)
Pentru fiecare tip de relaie binar de tipul 1:1 ntre dou tipuri de entitate E1 i E2
gsim o copie a cheii primare a tipului de entitate E1 n compunerea tipului de entitate E2, sub
denumirea de cheie strin. Identificarea tipului de entitate printe i a tipului de entitate
fiu depinde de participarea entitilor la relaie. Tipul de entitate care particip parial la
relaie este desemnat ca fiind printe iar cel cu participare total fiu. Dac ambele tipuri
de entitate particip parial sau total la relaie, atunci tipurile de entiti se pot evidenia ca
fiind printe sau fiu arbitrar. n cazul n care participarea este total, putem ncerca s
combinm cele dou tipuri de entiti ntr-una singur. Aceast compunere poate s fie
posibil n cazul n care nici unul dintre cele dou tipuri de entiti nu mai ia parte la alt
relaie.
Tipurile de relaii binare de tipul unu-la-multe 1:M
Pentru toate relaiile 1:M ntre dou entiti E1 i E2 n modelul logic de date, vom
avea copia cheii primare a entitii E1 n compunerea entitii E2. Totdeauna e ntitatea de
partea unu a relaiei este considerat entitate printe, iar cealalt entitate fiu.
Atributele cu mai multe valori
114
Pentru ficarea atribut A care permite mai multe valori din entitatea E1 n modelul
logic de date, crem o nou relaie care va conine atributul A mpreun cu cheia primar a
entitii E1 pe post de cheie strin. Cheia primar a noii relaii va fi atributul A, sau dac este
necesar, compunerea ei cu cheia primar al lui E1.
Documentarea relaiilor i a atributelor din cheile strine
Actualizm dicionarul de date, ntroducnd fiacare atribut nou introdus n
compunerea unei chei la acest pas.
Pasul 2.3. Validarea, utiliznd normalizarea
Obiectivul: Validarea modelului logic, utiliznd tehnica normalizrii.
Examinm procesul de normalizare dup cum am descris n capitolul 5 Prin
normalizare trebuie s demonstrm c modelul creat este consistent, conine redundan
minimal i are stabilitate maxim.
Normalizarea este procesul prin care se decide dac atributele pot sau nu s rmn
npreun. Conceptul de baz a teoriei relaiilor este c atributele sunt grupate mpreun pentru
c exist o relaie logic ntre ele. Cteodat baza de date nu este cea mai eficient. Acesta se
argumenteaz prin urmtoarele:
Proiectarea normalizat organizeaz datele n funcie de dependenele funcionale. Deci
acest proces este situat undeva ntre proiectarea conceptual i cea fizic.
Proiectul logic nu este un proiect final. El ajut priectantul s neleag natura datelor n
ntreprindere. Proiectul fizic poate fi diferit. Exist posibilitatea ca unele tipuri de entiti
s se denormalizeze. Totui normalizarea nu este un timp pierdut.
Proiectul normalizat este robust i independent de anomaliile de actualizare prezentate
nunitatea de nvare anterioar..
Calculatoarele moderne au mult mai mult putere de calcul, ca cele de acum civa ani.
Din aceast cauz, cteodat este mai convenabil implementarea unei baze de date cu
puin redundan, dect suportarea cheltuielilor pentru procedurile adiionale.
Normalizarea produce o baz de date care va fi uor extensibil n viitor.
Pasul 2.2. Validarea modelului prin tranzacii
Obiectivul: Verificarea ca modelul de date suporte toate tranzaciile cerute de
utilizator.
n acest pas se valideaz baza de date prin verificarea tranzaciilor ce se cer de catre
utilizator. Lund n considerare tipurile de entiti, relaiile, cheile primare i strine, ncercm
s rezolvm manual cerinele utilizatorilor. Dac reuim s rezolvm fiecare tranzacie cerut,
atuci nseamn c modelul creat este valid. Dac nu putem rezolva o tranzacie, atunci este
foarte posibil s fi omis un atribut, o relaie, sau o entitate din modelul de date.
Trebuie s examinm dac baza de date suport tranzaciile cerute. Mai nti ar fi prin
rezolvarea de tranzacii.
Exemple
De exemplu s lum relaia dintre Furnizori i Cheltuieli exemplificat n figur
115
Cheltuieli
Furnizori
Nr_Crt
Cod_Furnizor
Cod_Furnizor (FK)
Cod_cheltuiala
Nr_factura
Data_factura
Valoare_factura
Denumire
Cod_fiscal (AK1)
Cont
Banca
Strada
Nr
Bl
Sc
Ap
Localitate
Judet
Provoaca
Exemplu de relaie
pentru validarea prin
tranzacii.
116
117
SETARE IMPLICIT
118
120
S ne reamintim...
Activitile proiectrii 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 posibilitii 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
Activitile proiectrii logice locale sunt:
Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.
Pasul 2.2. Crearea relaiilor pentru modelul logic local.
Pasul 2.3. Validarea modelului, utiliznd normalizarea.
Pasul 2.2. Validarea modelului din nou, utiliznd tranzaciile.
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.
Activitile proiectrii 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 posibilitii 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.
121
Timpul de rspuns. Acesta este intervalul de timp dintre lansarea i execuie a unei tranzacii
i primirea rspunsului la acea tranzacie. Cea mai mare pondere n timpul de rspuns o are
execuia operaiilor 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 ctre sistemul de operare, timpi:
de comunicaie, etc.).
Utilizarea spaiului de memorare. Aceasta este dimensiunea spaiului pe disc utilizat de
fiierele bazei de date i de structurile de acces l date.
Capacitatea tranzacionala (transaction throughput). Acesta este numrul mediu de
tranzacii care pot fi prelucrate pe minut de ctre sistemul de baze de date, msurat n
momentele de vrf ale ncrcrii. Acesta este un parametru critic n multe aplicaii, n particular
n acele aplicaii n care exist un numr mare de utilizatori care acceseaz concurent baza
de date (aplicaii bancare, rezervri de bilete, etc.).
122
In mod obinuit, trebuie s fie specificate valorile medii i limitele n cazurile cele mai
defavorabile ale acestor parametri n cadrul cerinelor de performane ale sistemului. Pentru
compararea valorilor acestor parametri, corespunztoare diferitelor decizii de proiectare
fizic, se fac diferite evaluri analitice sau msurtori experimentale (prototipuri, simulri).
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
aplicaiilor care se vor executa i n principal a interogrilor i tranzaciilor pe care acestea le
vor lansa, n continuare se vor prezenta cteva aspecte ale analizei interogrilor i tranzaciilor
necesare pentru a stabili opiunile proiectului fizic al unei baze de date relaionale.
Analiza atributelor accesate de interogri i tranzacii trebuie s evidenieze:
123
124
M5.U5.3. Rezumat
Pasul 8. Proiectarea fizic i implementarea bazei de date relaionale:
Translatarea modelului logic global n SGBD.
Pasul 8.1. Proiectarea relaiilor de baz n SGBD.
Pasul 8.2. Crearea regulilor de integritate n SGBD.
Pasul 9. Proiectarea i implementarea reprezentrii fizice.
Pasul 9.1. Analizarea tranzaciilor.
Pasul 9.2. Alegerea organizrii fiierelor.
Pasul 9.3. Alegerea indecsilor secundari.
Pasul 9.4. Introducerea unei redundane comntrolate.
Pasul 9.5. Estimarea spaiului 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 operaional.
Alegerea sistemului de gestiune al bazei de date rebuie s in cont de
calitile SGBD-ului legatede Definirea datelor, Accesibilitate, Utilitare,
Dezvoltare, Definirea fizic i Alte faciliti/opiuni
125
Tranzacia este o aciune sau o serie de aciuni, executate de un singur utilizator sau un
program, care acceseaz sau schimb coninutul bazei de date.
Tranzacia este o unitate logic de lucru a bazei de date. Nu exist reguli de stabilire
automat a acestei uniti. Pentru a demonstra acest concept o s dm urmtoarele exemple.
Fie schemele:
Personal = (nrmat, nume, adres, salariu)
Proprietate = (nrprop, strad, ora, tip, nrmat)
care leag proprietatea de o persoan prin nrmat printr -o relaie de cardinalitate n la 1,
Putem avea urmtoarele tranzacii:
Exemple 5.4.1
cit (nrmat = x, salariu)
salariu = salariu * 1,1
scrie (nrmat = x, salariu)
care mrete salariul cu 10%
126
Exemple 5.4.2
cit (nrmat =x )
terge (nrmat = x )
pentru toate nregistrrile din Proprietate
begin
cit ( nrprop, nrmat)
dac (nrmat = x ) atunci
terge (nrprop)
end
care terge persoana x i toate proprietile ei
begin_transaction
cit(bal x)
bal x = balx - 10
scrie(bal x)
commit
T2
balx
begin_transaction
cit(bal x)
bal x = balx + 10
scrie(bal x)
commit
100
100
100
200
90
90
begin_transaction
cit(bal x)
bal x = balx - 10
scrie(bal x)
commit
T4
balx
begin_transaction
cit(bal x)
bal x = balx + 10
scrie(bal x)
100
100
100
200
200
100
190
190
rollback
Rezultatul este 190, ai putea spune c este bun, dar inei cont c tranzacia 4 a fost ntrerupt
i, cnd se va relua, va mai mri cu 100 contul ceea ce va deveni incorect.
Chiar i cnd unele tranzacii numai citesc baza de date se pot ntmpla neplceri.
Aceast problem este problema analizei inconsistente sau problema citirii murdare.
De exemplu tranzaciile 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 urmtoare ce se poate ntmpla ncazul concurenei libere,
necontrolate:
128
Exemple 4.4.5
Time T5
A t1
A t2
A t3
A t4
A t5
A t6
A t7
A t8
A t9
A t10
A t11
T6
balx baly
begin_transaction
100
begin_transaction
sum = 0
100
cit(bal x)
cit(bal x)
100
bal x = balx sum = sum + 100
10
balx
scrie(bal x)
cit(bal y)
90
cit(bal z)
sum = sum + 90
baly
bal z = balz +
90
10
scrie(bal z)
90
commit
cit(bal z)
90
sum = sum + 90
balz
commit
90
balz
sum
50
50
50
50
25
25
25
25
0
0
100
50
50
25
25
100
150
50
25
150
50
50
50
35
35
35
150
150
185
50
35
185
129
M5.U5.4. Rezumat
Tranzacia este o aciune sau o serie de aciuni, executate de un singur utilizator
sau un program, care acceseaz sau schimb coninutul bazei de date.
Tranzaciile trebuie s respecte proprietile ACID.
Atomicitate este proprietatea totul sau nimic. O tranzacie este o
unitate indivizibil care se execut n ntregime sau deloc.
Consisten o tranzacie trebuie s transforme baza de date dintro form consistent ntr-o alt form tot consistent.
Independen o tranzacie se execut inependent de oricare alta,
adic efectele pariale ale unei tranzacii incomplete nu trebuie s
influeneze o alt tranzacie.
130
131
Exemple 5.5.1
Time T1
A t1
A t2
A t3
A t4
A t5
A t6
A t7
A t8
A t9
A t10
A t11
begin_transaction
ex_bloc(bal x)
ATEAPT
ATEAPT
ATEAPT
cit(bal x)
bal x = balx -10
scrie(bal x)
deblo c(balx)
commit
Exemple 5.5.2
Time T3
A t1
A t2
A t3
A t4
A t5
A t6
A t7
A t8
A t9
A t10
A t11
A t12
begin_transaction
ex_bloc(bal x)
ATEAPT
ATEAPT
cit(bal x)
bal x = balx -10
scrie(bal x)
debloc(bal x)
commit
132
T2
balx
begin_transaction
ex_bloc(bal x)
cit(bal x)
bal x = balx +100
scrie(bal x)
debloc(bal x)
commit
100
100
100
100
200
200
200
200
190
190
190
T4
balx
begin_transaction
ex_bloc(bal x)
cit(bal x)
balx = balx +100
scrie(bal x)
debloc(bal x)
rollback
100
100
100
100
200
100
100
100
100
90
90
90
Exemple 5.5.3
Time T5
A t1
A t2
A t3
A t4
A t5
A t6
A t7
A t8
A t9
A t10
A t11
A t12
A t13
A t14
A t15
A t16
A t17
A t18
A t19
A t20
A t21
A t22
begin_transaction
ex_bloc(balx)
cit(bal x)
bal x = balx 10
scrie( balx)
ex_bloc(balz)
cit(bal z)
bal z = balz +
10
scrie(bal z)
debloc(bal x
, balz)
commit
T6
sum
begin_transaction
sum = 0
100 50
100 50
100 50
25
25
25
0
0
part_bloc(bal x)
ATEAPT
100 50
100 50
25
25
0
0
ATEAPT
ATEAPT
90
90
50
50
25
25
0
0
ATEAPT
ATEAPT
90
90
50
50
25
25
0
0
ATEAPT
ATEAPT
90
90
50
50
35
35
0
0
ATEAPT
cit(bal x)
sum = sum + bal x
part_bloc(bal y)
cit(bal y)
sum = sum + bal y
part_bloc(bal z)
cit(bal z)
sum = sum + bal z
90
90
90
90
90
90
90
90
90
90
50
50
50
50
50
50
50
50
50
50
35
35
35
35
35
35
35
35
35
35
0
0
90
90
90
140
140
140
175
175
90
50
35
175
debloc(balx,baly,balz)
commit
133
Exemple 5.5.4
Time T7
A t1
A t2
A t3
A t4
A t5
A t6
A t7
A t8
A t9
A t10
A t11
A t12
A t13
A t14
A t15
A t16
T8
T9
begin_transaction
ex_bloc(bal x)
cit(bal x)
part_bloc(bal y)
bal x = baly +
balx
scrie(bal x)
debloc(bal x)
begin_transaction
ex_bloc(bal x)
cit(bal x)
scrie(bal x)
debloc(balx)
rollback
rollback
begin_transaction
part_bloc(balx)
rollback
A t17
A t18
T11
begin_transaction
ex_bloc(bal x)
cit(bal x)
bal x = balx -10
scrie(bal x)
ex_bloc(bal y)
ATEAPT
ATEAPT
ATEAPT
begin_transaction
ex_bloc(bal y)
cit(bal y)
bal y = bal y +100
scrie(bal y)
ex_bloc(bal x)
ATEAPT
ATEAPT
ATEAPT
Blocajul ciclic este detectat , de obicei, prin constuirea unui graf de preceden care arat
dependena ntre tranzacii n felul urmtor:
se creaz un nod pentru fiecare tranzacie
se creaz o muchie direcionat Ti Tj dac tranzacia Ti ateapt 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
urmtorul:
134
Exemple 5.5.6
y
T10
T11
x
T7
T8
begin_transaction
cit(balx)
cit(bal x)
balx = balx
bal x = balx
+10
+100
scrie(bal x)
scrie(bal x)
begin_transaction
cit(baly)
cit(bal y)
baly = baly
bal y = baly
+20
+20
cit(baly)
scrie(bal y)
scrie(bal y)**
baly = baly
+30
scrie(bal y)
balz=100
scrie(bal z)
balz=50
bal z=50
scrie(bal z)
scrie(bal z)* begin135
T9
begin_transaction
cit(baly)
bal y = baly
+30
scrie(bal y)
bal z=100
scrie(bal z)
commit
A t15
A t16
A t17
A t18
_transaction
cit(bal y)
bal y = baly
+20
scrie(baly)
commit
cit(baly)
commit
baly = baly
+20
scrie(bal y)
Faza de validare. Urmeaz dup faza de citire i controleaz dac nu sar nclca
serializabilitatea n cazul c s-ar aplica actulizarea n baza de date. Dac avem o
tranzacie care numai citete baza (adic nu scrie), controlul const n a verifica dac
datele citite snt nc datele curente n baz i, dac este aa, atunci se face commit,
altfel se ntrerupe i se reia mai trziu. Dac trnzacia face i rescrieri n baz, atunci se
verific dac se pstreaz serializabilitatea i dac baza de date rmne ntr-o stare
consistent; dac acest lucru nu se ntmpl, atunci se ntrerupe.
Faza de scriere. Este o faz care este necesar numai la tranzaciile care fac rescrieri.
Dac faza anterioar s-a terminat cu succes, atunci actualizrile efectuate n copia
local, snt nregistrate definitiv n baza de date.
Iat cum se desfoar acest tip de control:
Fiecrei tranzacii i este ataat, la nceputul primei faze, un marcaj start(T), la
nceputul celei de a doua faze, valid(T) i la sfrit fin(T), dup scriere n copia local,
daceste cazul. Ca s treac faza de validare trebuie s avem una din urmtoare le situaii:
1) Toate tranzaciile cu un marcaj mai mic, trebuie s se fi terminat nainte ca
tranzacia T s fi nceput; adic fin(S) < start(T).
2) Dac tranzacia start(S) < start(T) (S a nceput naintea lui T) i nu s-a terminat
adic fin(S) < fin(T) atunci:
136
M5.U5.5. Rezumat
Avem dou tipuri de tehnici pentru controlul concurenei.
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 tranzacie, dup ce s-a fcut 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) ataeaz un timp fiecrei tranzacii
(marc(T)) i timpul tranzaciei care realizeaz operaia fiecrei citiri sau scrieri a
unei nregistrri. Deci fiecare tranzacie va avea o valoare de marcaj i fiecare
nregistrare prelucrat va avea dou marcaje; unul care spune ce marcaj a avut
tranzacia care a citit-o (cit_marc) i cellalt care spune ce marcaj a avut tranzacia
care a scris-o (scri_marc).
O tehnic optimist nseamn s lsm tranzaciile s ruleze fr s impunem
ntrzieri care s asigure serializabilitatea, iar cnd o tranzacie vrea s fac
commit, s efectum un control care s determine dac a avut loc un conflict. Dac
a avut loc un conflict, tranzacia trebuie ntrerupt i restartat. Pentru c am spus c
137
aceeste conflicte snt rare, aceste nteruperi i restartri vor fi, i ele, rare.
138
Integritate
Integritatea bazelor de date se refera la corectitudinea informaiilor 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
relaionala 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
139
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 relaional 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.
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.
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
140
(i)
(ii)
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.
141
142
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 aplicaii.
143
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 aplicaiile 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
144
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 informaiilor 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
145
-la nivel SGBD sistemul ofera anumite facilitati care sprijina protectia
datelor
Tehnici de asigurare a securitatii datelor:
1.
Identificarea utilizatorilor.
2.
3.
4.
146
Nivel
extern
View 2
View 1
Nivel
conceptual
Schema
conceptuala
Nivel
intern
Schema
interna
Organizarea la
nivel fizic a datelor
..
View n
Baza de
date
147
148
Unitatea 1.4
1.4.1 Ce este o baz de date distribuit?
1)
datele sunt partajabile dar administrarea lor se bucur de un grad nalt de autonomie local
disponibilitatea bazei de date este evident mai bun dect n cazul centralizat. Dac se
semnaleaz unele erori sau "deri" de sistem la nivel local sistemul ]n ntregime poate s
continue s funcioneze n condiii satisfctoare
fiabilitatea sistemului este mbuntit. Se pot reface rapid fiiere distruse utiliznd
replici aflate pe alte site-uri
fragmentarea datelor informaiile pot fi partitionate n fragmente care sunt apoi stocate
pe diferite site-uri n reea
replicarea se pot realiza copii ale diferitelor relaii sau ale fragmentelor
Se cunosc patru strategii de alocare a datelor ntr-o baza de date relaional distribuit:
149
a!. centralizat
Baza de date se afl n ntregime pe un singur site din reea 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 cuvntului. Dezavantajele sunt mai ales
costurile mari de comunicaii i o fiabilitate i o disponibilitate foarte sczute, avnd n
vedere c orice eroare care blocheaz accesul la baza de date, practic paralizeaz ntreaga
activitate n reea pe aceast direcie.
a2. fragmentat (partiionat)
Baza de date este partiionat n mai multe fragmente disjuncte care sunt stocate pe
diverse site-uri. Comentarii:
-
dac datele sunt distribuite corect, costurile de comunicare pot fi relativ sczute
costurile de stocare sunt n schimb i ele foarte mari, la fel sunt i costurile de
actualizare
disjuncie dac data d i apare n fragmentul R i atunci nu este permis s apar n nici un alt
fragment. De la aceast regul se admite doar o excepie, cazul cnd o relaie este
fragmentat pe vertical.
pe orizontal
pe vertical
combinat
Fragmentarea pe orizontal:
150
r ( R ) r1 X N r2
Aadar la descompunerea relaiei iniiale n fragmente trebuie s se in seama de regulile care
asigur o descompunere fr pierderi la jonciune.
In cazul descompunerii pe vertical nu este posibil s se realizeze o disjuncie total. Se
admite existena 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 relaional (pentru fiecare dreptunghi din figura de mai
sus) este: P ( A1 ,..., An ( R))
Sau se poate face din fragmente orizontale fragmentate vertical
151
Expresia corespunztoare n algebra relaional (pentru fiecare dreptunghi din figura de mai
sus) este: A1 ,..., An ( P ( R)) .
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
relaional, modelul de date retea i modelul ierarhic de date.
Unitatea 2.2
2.2.1 Gsii cheile candidat ale tabelei student. Stabilii 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 Dai exemple de relaii unu la unu, unu la mai muli i muli la muli.
Relaia editur carte este de unu la mai muli pentru c o editur editeaz mai mul te cri dar o
anumit carte este scoas de o singur editur (vez ISBN care este unic),
Relaia student materii este de muli la muli pentru c un student face mai multe materii i o
materie ete fcut de mai muli studeni.
2.2.3 Stabilii domeniul fiecrui 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 mulimea(preparator,asistent,lectoe,confereniar,profesor)
sex una din dou M sau F
Unitatea 3.1
Cosiderai instane ale tabelei student, profesor,materii i catalog.
1 Ion ion 7271
5 Dan soc 7271
7 Pan tor 7273
15
23
1
2
Prof1
Prof2
Bv lunga 22
Fag oltet 34
Baze de date
Algoritmica
152
Structuri de date
nrmatricol
1
1
5
7
7
codmaterie
1
2
3
1
3
nota
5
8
4
3
9
e)
Facei selecie din student dup grupa 7271
1 Ion ion 7271
5 Dan soc 7271
f)
Facei proiecie la student i la profesor dup nume. La acestea dou din urm fac ei
reuniunea.
Ion ion
Dan soc
Pan tor
Prof1
Prof2
g)
Faceti jonciunea natural intre student i catalog apoi ntre rezultat i materii.
nrmatricol
1
1
5
numestd
Ion ion
Ion ion
Dan soc
grupa
7271
7271
7271
codmaterie
1
2
3
7
7
Pan tor
Pan tor
7273
7273
1
3
h)
Facei selecia tabelei de mai nainte dup nota < 5.
nrmatricol
numestd
grupa
codmaterie
5
Dan soc
7271
3
7
Pan tor
7273
f)
grupa=7271
(student)
153
denmaterie
Baze de date
Algoritmica
Structuri de
date
Baze de date
Structuri de
date
nota
5
8
4
denmaterie
Structuri de
date
Baze de date
nota
4
3
9
g)
nume
(student)
(profesor)
(student N catalog
Studenii integraliti
nume
nume
Studenii corigeni
(
h)
nume5
nota<5
(student) \
(
nume
nota<5
j note))
N
(student
j catalog j note))
N
Unitatea 3.2
Se dau urmtoarele relaii cu schemele lor:
-Scri (Nr_bloc, Scara, Lift)
-Apartamente(Nr_bloc,Scara,Apartament,Suprafaa,Cutii_potale, 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 scrile 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
154
Renel
R7654321
Nr.
Crt.
1
2
3
4
Cod
Chelt.
C15
C16
C10
C11
Denumire
Cheltuial
Chelt pt. nclzire
Chelt pt. Buctrii
Chelt cu iluminatul
Chelt pt. Func. liftului
Valoare
1500000
500000
3000000
200000
155
n tabela normalizat, noua cheie va fi (Cod Furn., Nr. Crt ., Cod Chelt.).
Normaliznd tabela iniial dup a doua modalitate, vom crea o a doua tabel cu
informaiile care nu se repet, mpreun cu cheia primar din tabela iniial. Deci cele dou
tabele vor fi urmtoarele:
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)
Dependenele d1 i d2 sunt dependene pariale de cheie.
Relaiile rezultate au urmtoarea form:
Furnizori =
(Cod Furn., Denumire, Cod fiscal)
Tip cheltuial =
(Cod Chelt., Denumire cheltuial)
Cheltuieli =
(Nr. Crt., Cod Furn., Cod Chelt., Valoare)
Fie relaia din enun:
carte = (c_carte, titlu, cod_domeniu, den_domeniu) cu cheia c_carte. n afara dependenelor
care definesc cheia mai avem dependena:
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 relaia:
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 dependenele funcionale:
nrmatricol,codmaterie nota
codmaterie denumirematerie aceasta fiind dependen parial de cheie deci nu este FN2
se obine forma fina:
stud1=( nrmatricol,nume,adresa)
catalog=( nrmatricol,codmaterie,nota)
materii=( codmaterie,denumirematerie)
Unitatea 5.1
5.1.1 Facei proiectul conceptual local pentru subsistemul didactic al facultii.
Pasul 1.1. Identificarea tipurilor de entiti.
tipurile de entiti sunt:
student, materii, profesori, orar, sali
156
Tip de entitate
Tip de relaie
Tip de entitate
cardinalitate
participare
student
face
Materii
N:M
P:T
profesor
preda
Materii
orar
Relaie
complex cu
N:1
T:T
Atribute
domeniu
student
nrmatricol
Numeric de 5
nume
text
adresa
text
sex
M sau F
grupa
Numeric de 4
materii
Codmaterie
Numeric de 3
Text
Denmaterie
.
Pasul 1.7. Desenarea modelului ER.
157
student
materii
M
profesori
1
orar
sali
zile
ore
Unitatea 5.2
5.2.1 Facei proiectul logic local pentru subsistemul didactic al facultii.
Pasul 2.1. Proiectarea modelului local conceptual n modelul local logic.
n acest pas eliminm 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
urmtorii pai:
(1) Eliminarea relaiilor de tipul N:M.
Este cazul relaiei dintre student i materii. Apare entitatea catalog.
student
N
catalog
1
158
materii
N
zile
ore
1
Sali
1
N zileore N
1
N zioresali
materii
1
N
1
N orar
materii
M
N
zile
ore
1
Sali
1
N zileore N
1
N zioresali
N
1
N orar
159
profesori
1
Unitatea 5.3
Realizai, n ACCESS, proiectul fizic al subsistemului didactic al facultii.
Se vor urmri paii din Access la purttor [8]
160
Unitatea 5.4
5.4.1 Dai exemple de pierdere a consistenei.
1) Tranzacia T1 citete contul lui x (balx) i scade 10 din cont. Tranzacia T 2 citete
contul lui x (balx) i adun 100 la cont. Pornind cu un cont de 100, evident c dac se
execut mai nti prima tranzacie i apoi a doua contul lui x ar fi fost 10010+100=190. n cealalt ordine am fi avut 100+100-10=190 aceeai valoare. S
considerm urmtorul plan de tranzacii.
Time
T1
A t1
A t2
begin_transaction
A t3
cit(b alx)
A t4
bal x = balx - 10
A t5
scrie(bal x)
A t6
commit
Se ved c bal x are valoarea greit 90.
T2
balx
begin_transaction
cit(bal x)
bal x = balx + 10
scrie(bal x)
commit
100
100
100
200
90
90
Unitatea 5.5
5.5.1 Ce este blocajul?
1) Cnd o tranzacie blocheaz partajat o anumit unitate de memorie, o alt tranzacie nu
mai poate s rescrie tot acolo, iar cnd o tranzacie 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 urmtor. Cele dou trnzacii T 10 i T11 se
blocheaz reciproc.
Time T10
T11
A t1
A t2
A t3
A t4
A t5
A t6
A t7
A t8
A t9
A t10
A t11
begin_transaction
ex_bloc(bal x)
cit(bal x)
bal x = balx -10
scrie(bal x)
ex_bloc(bal y)
ATEAPT
ATEAPT
ATEAPT
begin_transaction
ex_bloc(bal y)
cit(bal y)
bal y = bal y +100
scrie(bal y)
ex_bloc(bal x)
ATEAPT
ATEAPT
ATEAPT
161
integritatea referentiala
restrictiile de domeniu
restriciile de intreprindere
162
163
Bibliografie.
[1] L.mbulea - Structuri de date i bnci 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.Bsc 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 nceptori. Ed. Universitii din Piteti. 2000
[8]iacob P. Access la purttor Ed.Lux libris 2007
[9]iacob P. Oracle la purttor Ed.Lux libris 2008
[10] M. Stanescu i colectiv - Limbaje de programare i bnci 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.
164