Baza de Date

UNIVERSITATEA TEFAN CEL MARE SUCEAVA FACULTATEA DE TIIN E ECONOMICE I ADMINISTRA IE PUBLIC SPECIALIZAREA : CONTABILITATE I INFORMATIC DE GESTIUNE FORMA
DE NV MNT : NV MNT LA DISTAN
PROF.UNIV.DR. VALERIU LUPU
BAZE DE DATE
CURS PENTRU NV MNT LA DISTAN
BAZE DE DATE
CURS PENTRU NVMNT LA DISTAN
SUCEAVA 2010 2011
BAZE DE DATE
CUPRINS
1. Introducere 1.1. Evoluia organizrii datelor 1.1.1. Organizarea nregistrrilor n fiiere 1.1.2. Limitele tratrii bazate pe fiiere 1.1.3. Avantajele sistemelor de gestiune a bazelor de date 1.1.4. Dezavantajele sistemelor de gestiune a bazelor de date 1.2. INDEPENDENA DATELOR. LIMBAJELE DE DEFINIRE I MANIPULARE A DATELOR 1.2.1. Independena datelor 1.2.2. Limbajele bazelor de date 1.2.2.1. Limbajul de definire a datelor 1.2.2.1.1. Definirea schemei n SQL 1.2.2.1.2. Utilizarea interogrilor SQL n cadrul aplicaiilor 1.2.2.2. Limbajul de manipulare a datelor 1.2.2.2.1. Extragerea informaiilor din bazele de date 1.2.3. Alte caracteristici SQL 1.2.4. Query-By-Example (QBE) 1.3. SISTEME DE GESTIUNE A BAZELOR DE DATE 1.3.1. Componentele unui sistem de gestiune al bazelor de date 1.3.1.1. Componenta hardware 1.3.1.2. Componenta software 1.3.1.3. Date 1.3.1.4. Proceduri 1.3.1.5. Resursele umane 1.3.2. Componentele unui sistem de gestiune a bazelor de date 1.3.3. Funciile sistemelor de gestiune a bazelor de date 2. Modelarea datelor 2.1. Modele de date: reea, ierarhice, relaionale, obiectuale, hibrid 2.1.1. Istoricul bazelor de date 2.1.2. Funciile modelelor 2.1.3. Modele de date bazate pe nregistrri 2.1.3.1. Modelul ierarhic 2.1.3.2. modelul reea 2.1.3.3. modelul relational 2.1.4. Modele logice orientate pe obiecte 2.1.4.1. modelul entitate-relaie; 2.1.4.2. modelul orientat pe obiecte; 2.1.4.3. modelul obiectual-relaional; 2.1.5. Modele fizice de date 2.1.6. Avantajele bazelor de date relaionale 2.1.7. Chei 2.1.7.1. Cheia candidat 2.1.7.2. Cheia primar 2.1.7.3. Cheie alternativ 2.1.7.4. Cheie extern 2.2. Modele arhitecturale: mainframe, integrate, file-server, client-server, distribuite 3
BAZE DE DATE 2.2.1. Introducere 2.2.2. Istoric 2.2.3. Modelul mainframe 2.2.4. Modelul integrat 2.2.4.1. Modelul File-server 2.2.4.2. Modelul Client-server 2.2.5. Baze de date distribuite 3.1. Bazele modelului relaional 3.1.1. Modelul conceptual 3.1.2. Modelul logic 3.1.3. Modelul fizic
3.2. normalizarea bazelor de date. Forme normale 3.2.1. Normalizarea 3.2.2. Forme normale 3.3. Regulile lui Codd 3.3.1. Regula informaiei 3.3.2. Regula de garantare a accesului 3.3.3. Valorile NULL 3.3.4. Catalog actualizat permanent pe baza modelului relaional 3.3.5. Regula de nelegere a sublimbajului de manipulare a datelor 3.3.6. Regula de actualizare a vederilor 3.3.7. Inserarea, actualizarea i eliminarea 3.3.8. Independena fizic de date 3.3.9. Independena logic de date 3.3.10. Independena integritii 3.4. Limbajul MYSQL 3.4.1. Descriere 3.4.2. Tipuri de operaii asupra bazelor de date 3.4.3. Tipuri de date in MySQL 3.4.4. Comenzi elementare MySQL 3.4.5. comenzi pentru interogarea bazelor de date 3.4.6. probleme rezolvate 3.4.7. probleme propuse
BAZE DE DATE
CONTINUT
1. INTRODUCERE N BAZE DE DATE
OBIECTIVE
Oferirea unei imagini sintetice i cuprinztoare a bazelor de date. Cunoaterea evoluiei organizrii bazelor de date, bazat pe conceptul de dat, colecii de date i fiiere. Cunoaterea avantajelor bazelor de date. Prezentarea interdependenelor n definirea i manipularea datelor prin intermediul limbajelor bazelor de date. Cunoaterea limbajului de definire a datelor utilizat la definirea structurii bazei de date. Cunoaterea limbajului de manipulare a datelor utilizat la extragerea informaiilor prin intermediul clauzelor (SELECT, FROM, WHERE, GROUP BY, HAVING), operaiilor (RENAME, STRING, ORDER, DUPLICATE, SET, MODIFY) i funciilor agregat. Oferirea de informaii referitoare la limbajul QBE (Query-By-Example). Prezentarea sistemelor de gestiune a bazelor de date: definiie, obiective, componente, module i funcii.
Data file 1 Data file 1 Data file 1 DBMS
Application 1
Output 1
Application 2
Output 2
2. MODELE I ARHITECTURI DE DATE

OBIECTIVE
Prezentarea n detaliu a modelelor de date: reea, ierarhic, relaional, obiect, hibrid. Cunoaterea funciilor i componentelor modelului. Deprinderea noiunilor i instrumentelor necesare comparrii modelelor bazate pe nregistrri (reea, ierarhic, relaional) i a modelelor logice bazate pe obiecte (entitate-relaie, orientate pe obiecte, orientate pe obiecte relaionale, binare, semantice, infologice i funcionale). Cunoaterea avantajelor bazelor de date relaionale. Cunoaterea rolului i importanei cheilor ntr-o baz de date. Dezvoltarea unei vederi generale i implementarea cunotinelor specifice necesare comparrii modelelor arhitecturale: mainframe, integrat, file-server, client-server i distribuit.
Logical child relationship Database 1 Database 2
BAZE DE DATE
3. MODELUL RELAIONAL DE DATE

OBIECTIVE
nsuirea noiunilor de baz ale unui model de date: definiii, clasificri. nsuirea de cunotine referitoare la proiectarea modelului conceptual al unei baze de date n cazul modelului relaional. Crearea modelului logic de date pe baza modelului conceptual. Utilizarea modelului fizic de date la descrierea reprezentrii datelor n ceea ce privete formatul, nmagazinarea i calea de acces. Proiectarea logic a unei baze de date cu ajutorul tehnicii normalizrii. Cunoaterea conceptului de descompunere i a funciilor sale. Cunoaterea dependenelor funcionale, multivalorice i de cuplare. Cunoaterea formelor normale i utilizarea lor. Prezentarea printelui modelului relaional; unde i n ce context Dr. E.F. Codd a creat cele 12 reguli. nelegerea coninutului i importanei celor 12 reguli ale lui Codd.
FN 1
FN 2
FN 3
FNBC FN 4
FN 5
4. LIMBAJUL MYSQL AL BAZELOR DE DATE

OBIECTIVE
nsuirea de cunotine referitoare la limbajul de manipulare a datelor. Utilizarea interogrilor simple i a interogrilor ce folosesc mai multe tabele. Captarea de informaii referitoare la sistemele ce folosesc limbajul de interogare structurat al datelor. Definirea vederilor, cunoaterea rolurilor acestora precum i a modului lor de utilizare. Cunoaterea de elemente referitoare la vederile simple, vederile agregat i vederile de validare. Cunoaterea caracteristicilor vederilor. Cunoaterea condiiilor n care se pot realiza actualizri n baza de date cu ajutorul vederilor.
CREATE VIEW v AS <expresie interogare>
BAZE DE DATE
Lucrari de laborator 1. 2. 3. 4. 5. 6. Modelul Entitate-Relatie. Reprezentari. Construirea unui model Entitate-Relatie. Procesul de normalizare. 1a, a 2a si a 3a forma normala. Procesul de normalizare. Forma normala Boyce-Codd si a 4a si a 5a forma normala. Utilizarea MySQL. Adaugarea fisierelor si alegerea tipurilor de date. Definirea relatiilor si setarea optiunilor de integritate referentiala. Lucrul cu interogari. Inserarea si stergerea datelor din baza de date. 7. Utilizarea MySQL Server. Crearea tabelelor si relatiilor. 8. Utilizarea MySQL Server. Inserarea si stergerea datelor din baza de date. 9. Utilizarea MySQL Server. Obiecte din bazele de date. 10. Vederi. Crearea si stergerea vederilor.
BAZE DE DATE Evoluia organizrii datelor
Societatea contemporan, caracterizat prin afluxul fr precedent de informaie de diferite tipuri i pe diverse canale, necesit strategii i instrumente din ce in ce mai complexe pentru stocare, procesare i, mai ales, interpretare. In acest context, se pune problema transformrii informaiei n date i organizarea acestora ntr-o asemenea manier nct n orice moment s poat fi extrase, cu promptitudine i exactitate, datele favorabile realizrii unui scop specific. Datele sunt fapte culese din lumea real. Ele sunt preluate din msurtori i observaii i constituie orice mesaj primit de un receptor sub o anumit form. O percepie a lumii reale poate fi privit ca o serie de obiecte sau fenomene distincte sau interdependente. Datele n sine nu au nici un fel de semnificaie. Mai mult dect att, nefiind altceva dect o niruire de litere i cifre, ele pot primi diverse interpretri, cele mai multe dintre ele fiind, de obicei, greite. Datele se refera la numere, fapte, diferite documente etc. Informaiile se refer la date organizate, date care au fost filtrate i ordonate dup anumite criterii. Dorina oricrui utilizator este obinerea de informaie i nu manipularea unor date seci. Un model de date corect alctuit ofer posibilitatea transformrii informaiilor n date i a acestora napoi n informaii fr a denatura sensul lor iniial. A obine informaie nseamn, de fapt, a introduce datele disponibile ntr-un anumit context conferindu-le n acest fel o anume semnificaie. Ceea ce se nmagazineaz ntr-o baz de date, aa cum am artat, sunt datele care au o natur static n sensul c ele rmn n aceeai stare pn n momentul modificrii lor de ctre administratorul bazei de date prin intermediul unui proces manual sau automat. Pentru ca datele s poat fi transformate n informaie ele trebuie organizate astfel nct s poat fi prelucrate efectiv. Pentru a determina n cazul unei aplicaii modul de organizare a datelor, trebuie determinate acele caracteristici ale datelor care permit extragerea esenei nelesului lor. O mulime formal i consistent de reguli definete un model de date. Pentru o aplicaie particular a unui model de date, numele obiectelor bazei de date mpreun cu proprietile lor i asocierile dintre ele se numete schem. Un ansamblu de date organizat dup anumite criterii reprezint o colecie de date. O colecie de obiecte care au identitate proprie i sunt caracterizate de o condiie de apartenen se numete mulime. Procesul de definire i structurare a datelor n colecii, gruparea lor precum i stabilirea elementelor de legtur dintre componentele coleciei i ntre colecii reprezint organizarea datelor. Fiierul este o colecie de date organizate pe criterii calitative, de prelucrare i de scop. Un fiier reprezint o colecie de date aflate n asociere ce are o denumire i care este reprezentat, de obicei, cu ajutorul unei secvene de bytes sub forma celor dou vederi: Vederea logic: reprezint felul n care utilizatorul vede fiierul; Vederea fizic: reprezint felul n care fiierul este stocat n memoria extern a calculatorului. Aceste dou vederi pot fi, evident, foarte diferite ntre ele. O baz de date reprezint o colecie integrat i structurat de date operaionale nmagazinate pe un mediu de stocare. Elsmari i Navathe definesc o baz de date sub forma unei colecii de date aflate n asociere. Scopul unei baze de date este acela de a nmagazina datele n aa fel nct s se poat obine informaia dorit n orice moment. Informaiile, spre deosebire de date, au un caracter dinamic n sensul c ele se modific n funcie de datele nmagazinate n baza de date, dar i n sensul c ele pot fi procesate i prezentate n diverse feluri.
Pentru a face diferena dintre date i informaii, Hernandez propune urmtoarea axiom: 8
BAZE DE DATE
Datele reprezint ceea ce se nmagazineaz; informaia reprezint ceea ce se extrage. Cu alte cuvinte, datele trebuie extrase n aa fel din baza de date nct s capete semnificaie. Evoluia n timp a metodelor de organizare a datelor e legat de soluiile tehnice de nmagazinare a acestora i cuprinde nivelele: 1. Nivelul I - organizarea datelor n fiiere clasice; 2. Nivelul II - organizarea mixt n fiiere; 3. Nivelul III - organizarea datelor n bazele de date clasice; 4. Nivelul IV - organizarea datelor n bazele de date relaionale; 5. Nivelul V - organizarea datelor n baze de date distribuite. n cadrul acestei evoluii se disting etapele: Etapa I - este perioada caracterizat de nregistrarea datelor pe benzi magnetice. Aceast etap se apropie mult de sistemul manual de organizare a datelor (ndosariere - datele sunt organizate, n principal, sub form de fiiere secveniale datorit suportului magnetic (benzi)). Programatorii erau nevoii s efectueze o serie de operaii de gestiune a datelor, datorit puternicei legturi dintre aplicaii i date. n aceast etap se remarc urmtoarele caracteristici: - structura logic coincide cu cea fizic i, prin urmare, programatorul trebuie s descrie i organizarea fizic a datelor pe suport, lucru incomod, la schimbarea suportului; - prelucrarea se face pe loturi; - dependena aplicaiilor fa de date (o modificare n structura datelor sau a dispozitivului de memorare implic modificri ale programelor de aplicaie i recompilarea lor i, ca urmare, trebuie ca datele s fie redefinite n cadrul aplicaiei ori de cte ori apare o modificare n structura bazei de date); - redundan mare n memorarea datelor datorit faptului c aceleai date sunt memorate separat pentru fiecare aplicaie ce are nevoie de ele; - legturile dintre fiiere trebuie specificate n cadrul programelor aplicaie; - fiecare aplicaie are propriile date i este singura care le poate folosi; - programele realizeaz numai operaii simple de intrare/ieire. Etapa a II-a - este caracterizat de nregistrarea datelor pe discul magnetic. Datele se pot organiza acum att n fiiere secvenial-indexate ct i n fiiere cu acces direct. Anterior acestei etape datele erau nmagazinate n fiiere obinuite, fie n format ISAM (Indexed Sequential Access Method) fie n format VSAM (Virtual Storage Access Method). Datele sunt nmagazinate i extrase acum n uniti numite blocuri sau pagini. Spre deosebire de nmagazinarea n memoria RAM, timpul necesar extragerii unei pagini difer n funcie de localizarea acesteia pe disc. Caracteristicile corespunztoare acestei etape sunt: - structura logic nu mai coincide cu cea fizic, ceea ce face ca programatorul s nu mai fie nevoit s descrie i organizarea fizic a datelor pe suport, acest lucru fiind fcut de ctre componentele specializate ale sistemului de operare; - prelucrarea se face online sau n timp real; - schimbarea unitii de memorare nu implic modificarea programelor; - se menine redundan mare deoarece, de multe ori, aceleai date sunt pstrate n mai multe fiiere; - datele sunt nestructurate; - mentenana bazei de date are un cost foarte ridicat; - se menine dependena aplicaiilor fa de date, accesul la date fiind foarte dificil; datorit acestei dependene, aplicaiile noi sunt greu de proiectat; 9
BAZE DE DATE -
se ofer o interfa de programare, numit API (Application Programming Interface); accesul se face la nivel de nregistrare i nu de cmp n cadrul nregistrrii; nu se realizeaz accesul dup chei multiple; controlul concurenei este limitat; legturile ntre fiiere trebuie programate, ceea ce presupune definirea i deschiderea fiecrui fiier, accesarea datelor din primul fiier, prin intermediul cii de acces ce trebuie s apar n cadrul programului, dup care se acceseaz cel de-al doilea fiier, .a.m.d.; deoarece aceste fiiere au un format fix, modificarea structurii unui astfel de fiier reprezint un proces extrem de lent (mai nti se transform datele, apoi fiierul trebuie redefinit n cadrul fiecrei aplicaii care l acceseaz, fiind posibil chiar schimbarea cii de acces spre acesta n cadrul fiecrei aplicaii).
Etapa a III-a - este caracterizat de apariia bazelor de date. Datele se pot organiza acum sub forma unor fiiere integrate. Acestea permit realizarea mai multor fiiere logice pe baza acelorai date fizice. Caracteristici corespunztoare acestei etape sunt: - organizarea fizic a datelor e independent de programele de aplicaii; - se pot constitui fiiere logice n funcie de baza de date; - se remarc un control integrat al datelor prin: - reducerea redundanei datelor fiind posibil folosirea n comun a acelorai date fizice de ctre mai multe aplicaii; - accesul la date la nivel de cmp; - eliminarea inconsistenelor; - asigurarea controlului concurenei; - asigurarea integritii datelor; - gestiunea datelor; - introducerea standardelor de disponibilitate a sistemelor; - mbuntirea securitii datelor; - asigurarea accesului la date dup chei multiple; - organizarea datelor e realizat de o component software (data management); - creterea independenei datelor, prin asigurarea transparenei detaliilor referitoare la organizarea conceptual, structurile de stocare i strategiile de acces ale utilizatorilor la: - nivel logic: - transparena organizrii conceptuale; - transparena strategiilor logice de acces; - nivel fizic: - transparena organizrii nmagazinrii fizice; - transparena cilor fizice de acces. Etapa a IV-a - se caracterizeaz prin asigurarea independenei logice i fizice a datelor fa de programele de aplicaie. Aceasta se realizeaz prin intermediul administratorului de baze de date cu ajutorul descrierii datelor la un nivel logic global. Caracteristicile specifice acestei etape sunt: - datele sunt descrise la nivel logic global; - existena unor fiiere inverse ce permit rspunsul rapid la ntrebri formulate de utilizatori; - mrirea gradului de protecie i securitate a datelor;
10
BAZE DE DATE
- n afara independenei fizice a datelor apare i independena logic prin posibilitatea existenei unor modificri n structura logic fr a afecta aplicaiile; - creterea controlului concurenei, prin existena mai multor vederi asupra datelor oferite utilizatorilor; - posibilitatea introducerii standardizrii prin centralizarea gestiunii datelor cu ajutorul definiiilor n cadrul cataloagelor; - creterea calitii datelor prin introducerea constrngerilor suplimentare n cadrul bazei de date; - redundana datelor este redus la minim. 1.1.1. Organizarea nregistrrilor n fiiere Cea mai eficient i rapid cale de a lucra cu datele existente ntr-o baz de date ar fi aceea de pstrare a tuturor acestor date n memoria intern a sistemului. Pstrarea tuturor datelor din baza de date n memoria intern a sistemului nu se poate face datorit faptului c, pe de o parte memoria intern este foarte scump, iar pe de alt parte aceasta este volatil, motiv pentru care datele trebuie pstrate pe un suport magnetic extern. Prin urmare se impune stabilirea unei strategii de lucru cu datele aflate n baza de date, dup cum urmeaz: - datele utilizate n mod curent se pstreaz n memoria RAM a sistemului; - restul datelor se pstreaz n memoria extern a sistemului (nmagazinare secundar); - copiile de siguran a datelor se pstreaz pe benzi magnetice (nmagazinare teriar). Pentru a organiza nregistrrile unei baze de date n cadrul fiierelor se pot folosi mai multe modaliti: - organizare n fiiere heap; n acest caz, orice nregistrare poate fi plasat oriunde se gsete loc n cadrul fiierului, nefiind impus o anumit ordine; - organizare secvenial; n acest caz nregistrrile sunt stocate ntr-o anumit ordine impus de valoarea cheii de cutare a fiecrei nregistrri; - organizare n fiiere hash; n acest caz se folosete o funcie hash care se aplic atributelor fiecrei nregistrri; rezultatele obinute arat blocul din cadrul fiierului n care trebuie s se afle o anumit nregistrare, fiind strns legate de structura de indexare folosit; - organizarea fiierelor n grupuri; nregistrrile ce provin din mai multe tabele pot fi pstrate n acelai fiier; nregistrrile asociate din tabele diferite sunt pstrate n acelai bloc astfel nct operaiile de intrare/ieire pot parcurge nregistrrile asociate din toate tabelele. n continuare se vor prezenta cteva caracteristici suplimentare ale fiierelor secveniale i ale celor organizate n grupuri. Organizarea secvenial a fiierelor Un fiier secvenial este foarte util la prelucrarea nregistrrilor aflate ntr-o ordine predefinit pe baza unei chei de cutare. nregistrrile din cadrul unui astfel de fiier sunt asociate pe baza unor pointeri ce permit extragerea rapid a datelor pe baza cheii de cutare. nregistrrile sunt nmagazinate fizic n ordinea stabilit pe baza cheii de cutare, ceea ce duce la minimizarea numrului de blocuri ce trebuie accesate, ns este dificil de pstrat aceast ordine pe msur ce se fac introduceri sau tergeri de nregistrri. tergerile pot fi gestionate cu ajutorul lanului de pointeri, dar inserrile pun probleme dac nu exist spaiu n locul n care trebuie plasate nregistrrile. n cazul n care spaiul necesar plasrii unei noi nregistrri este disponibil n locul indicat, nregistrarea poate fi plasat n acel loc, altfel ea trebuie plasat n alt loc, iar pointerii trebuie reorganizai. n aceast situaie anumite nregistrri nu se vor afla n ordinea fizic specificat. Dac numrul de nregistrri care nu se afl n ordinea fizic 11
BAZE DE DATE
specificat este mic, nu vor exista probleme deosebite, dar dac acest numr crete prea mult pointerii trebuie reorganizai, ceea ce presupune un mare consum de resurse i, prin urmare, astfel de operaii trebuie efectuate numai atunci cnd sistemul nu este deloc sau este slab solicitat. Dac inserrile se fac rar, fiierul poate fi pstrat n ordinea fizic stabilit iniial, reorganizarea pointerilor fcndu-se la apariia oricrei noi inserri, caz n care nu mai sunt necesare cmpurile de pointeri. Organizarea fiierelor n grupuri O situaie foarte bun se ntlnete atunci cnd, n bazele de date de mici dimensiuni, fiecare tabel se afl ntr-un fiier separat, iar nregistrrile au o lungime fix, ceea ce va conduce la reducerea dimensiunii programelor. Multe dintre sistemele de baze de date utilizate pe scar larg nu folosesc n mod direct sistemul de operare pentru gestiunea fiierelor. n aceast situaie, bazei de date i este alocat un singur fiier de mari dimensiuni, toate tabelele fiind pstrate n cadrul unui singur fiier. O astfel de structur pune la un loc nregistrri din mai multe tabele, permind prelucrarea eficient a jonciunilor. Dac nregistrrile nu pot fi plasate toate ntr-un singur bloc, cele rmase vor apare n blocurile adiacente. Structura, cunoscut sub numele de grup, permite citirea celor mai multe dintre nregistrri cu ajutorul unui singur bloc. Utilizarea grupurilor este foarte util n cazul prelucrrii particulare a unui anumit tip de jonciuni, dar poate conduce la scderea performanelor n cazul altor tipuri de interogri. nmagazinarea metadatelor n catalog Informaiile referitoare la obiectele bazei de date sunt pstrate n alte tabele cunoscute sub numele de catalogul bazei de date, care conine: - denumirile tabelelor; - denumirile cmpurilor tabelelor; - domeniile de valori i lungimea cmpurilor; - denumirile u definiiile vederilor; - constrngerile de integritate (informaii despre cheile primar i extern). Catalogul mai conine date despre utilizatorii sistemului (numele i condiiile de acces ale acestora), precum i (posibil) date descriptive i statistice, cum ar fi: - numrul de nregistrri din fiecare tabel; - metoda de stocare folosit n cazul fiecrui tabel (de exemplu, n grup). De asemenea mai trebuie pstrate date referitoare indecii folosii n cadrul fiecrui tabel (denumirea indexului, denumirea tabelului pe care se aplic indexul respectiv, tipul indexului, cmpurile pe care se aplic indexul). Se poate spune c, de fapt, toate aceste date formeaz o alt baz de date n miniatur. Baza de date poate fi folosit pentru a nmagazina date despre propria structur, ceea ce va conduce la o structur mai complex a sistemului, permind utilizarea la maxim a puterii bazei de date prin asigurarea accesului rapid la datele sistemului. Modalitatea optim de reprezentare a datelor sistemului poate fi aleas de ctre proiectantul sistemului, o posibil reprezentare fiind urmtoarea: Schema catalogului sistemului = (nume tabel, numr de atribute). Schema atributelor = (nume atribut, nume tabel, tip de dat, poziie, dimensiune). Schema utilizatorului = (nume utilizator, cont de utilizator, cheia de criptare, grup). Schema de indexare = (numele indexului, numele tabelului, tipul indexului, atributul indexului). Schema vederii = (numele vederii, definirea vederii).
12
BAZE DE DATE
1.1.2. Limitele tratrii bazate pe fiiere

n general acestea sunt marcate de: 1. Separarea i izolarea datelor. 2. Dublarea datelor. 3. Dependena datelor. 4. Incompatibilitatea fiierelor. 5. Interogri statice.
Separarea i izolarea datelor

Cu sistemele de fiiere e dificil o prelucrare a datelor atunci cnd acestea sunt izolate n fiiere separate. n acest caz programatorul trebuie s sincronizeze prelucrarea a dou sau mai multe fiiere pentru a se asigura c datele extrase sunt cele corecte. Dificultatea este cu att mai mare cu ct datele necesare se afl n mai multe fiiere.
Dublarea datelor
Se manifest prin faptul c aceleai date se pot afla n dou sau mai multe fiiere n funcie de numrul aplicaiilor sau al utilizatorilor. n aceast situaie pot apare o serie de probleme, cum ar fi: a) creterea costurilor prin creterea spaiului de memorare a datelor; b) apariia inconsistenei datelor prin faptul c o anumit dat poate fi memorat n mai multe locuri; atunci cnd exist mai multe copii ale aceleiai date e posibil ca prin actualizarea unora dintre ele s existe valori diferite ale acelorai date (inconsisten); inconsistena mai poate apare i la introducerea greit a unor date; c) imposibilitatea introducerii unor standarde; d) imposibilitatea aplicrii restriciilor de securitate; e) imposibilitatea meninerii integritii datelor (consisten i validare).
Dependena datelor
Structura fizic i stocarea fiierelor de date i nregistrrilor sunt definite n codul aplicaiei. Aceasta nseamn c orice modificare efectuat n structura existent impune scrierea unui program de tip exeoff (adic un program ce este rulat o singur dat, dup care poate fi nlturat). Acest program trebuie: a) s deschid fiierul iniial pentru a fi citit; b) s creeze un fiier temporar cu noua structur; c) s citeasc o nregistrare din fiierul iniial, s transforme datele pentru a le ncadra n noua structur i s scrie fiierul temporar. Acest lucru trebuie repetat pentru toate nregistrrile din fiierul iniial; d) s tearg fiierul iniial; e) s redenumeasc fiierul temporar cu numele fiierului iniial; f) s modifice toate programele ce apeleaz fiierul iniial pentru a se conforma noii structuri. Toate aceste operaii necesit mult timp i sunt supuse pericolului de apariie a erorilor. Dac structura unui fiier trebuie modificat, trebuie modificat i programul care l folosete, deoarece programul tie prea multe lucruri despre structura acestuia. Diferena dintre conceptul de fiier i cel de baz de date este reprezentat n figurile urmtoare:
13
BAZE DE DATE
Date fiier 1 Date fiier 1 Date fiier 1
Aplicaie 1
Rezultat 1
Aplicaie 2
Rezultat 2
Figura 1.1. Fiiere: dependena aplicaie/date
Date fiier 1 Date fiier 1 Date fiier 1 SGBD
Aplicaie 1
Rezultat 1
Aplicaie 2
Rezultat 2
Figura 1.2. Baze de date: independena aplicaie/date
Formate de fiiere incompatibile

Este posibil ca fiecare fiier s fie apelat de ctre un program scris ntr-un limbaj de programare diferit. n acest caz se impune s se scrie un program de transformare a fiierelor ntr-un format comun astfel nct s se poat face prelucrarea datelor din mai multe fiiere, deoarece fiecare limbaj de programare necesit un anumit tip de fiier.
Interogarea static a programelor aplicaie

n cazul n care apar noi cereri de interogare a datelor aflate n fiiere, trebuie rescrise programele existente, deoarece, altfel, nu se poate rspunde dect la ntrebrile existente. n cazul rescrierii programelor pot apare urmtoarele deficiene: a) documentaie limitat i dificil de ntreinut; b) afectarea securitii i integritii datelor; c) refacerea datelor dup defectarea sistemului e limitat sau inexistent; d) accesul la fiiere e restrns la cte un utilizator odat. n concluzie, limitrile tratrii bazate pe fiiere se datoreaz factorilor: a) definiia datelor e ncorporat n programele aplicaie, n loc s fie stocat separat i independent; b) nu exist control al accesului i manipulrii datelor, n afara celui impus de ctre programele aplicaie.
14
BAZE DE DATE
1.1.3. Avantajele sistemelor de gestiune a bazelor de date

Avantajele sistemelor de gestiune a bazelor de date fa de sistemele clasice, cu fiiere sunt urmtoarele: 1. Controlul redundanei datelor Risipa de spaiu care se face prin stocarea acelorai informaii n mai multe fiiere este mult diminuat prin utilizarea bazelor de date, dar nu complet eliminat datorit altor cereri de mbuntire a performanelor. 2. Coerena datelor Dac un articol de date e nmagazinat de mai multe ori trebuie s se garanteze c toate copiile acestuia vor fi actualizate dac se reactualizeaz o valoare a sa (valoarea articolului e aceeai pentru toate copiile sale). 3. Mai multe informaii de la aceeai cantitate de date Se pot obine prin integrarea fiierelor ce conin informaii diferite despre aceleai date. 4. Partajarea datelor Datele pot fi utilizate de ctre mai muli utilizatori n acelai timp. De asemenea se pot face modificri sau adugiri la baza de date existent fr a fi necesar definirea repetat a tuturor cerinelor referitoare la acestea. 5. Integritatea crescut a datelor Se refer la validitatea i coerena datelor nmagazinate i se exprim prin constrngeri (reguli de coeren). Constrngerile se pot aplica articolelor de date din cadrul unei singure nregistrri sau relaiilor dintre nregistrri. 6. Securitatea crescut Se realizeaz prin atribuirea unor nume de utilizatori i parole ce permit identificarea persoanelor autorizate s foloseasc baza de date i impun modalitatea de utilizare a acestor date. 7. Aplicarea standardelor Se refer la formatul datelor, conveniile privind denumirile, documentarea, procedurile de reactualizare, regulile de acces. 8. Reducerea costurilor Prin realizarea integrrii se aloc fonduri centralizat i nu separat fiecrui departament. 9. Rezolvarea conflictelor Fiecare utilizator va avea propriile cerine ce pot intra n conflict cu ale altora. Administratorul bazei de date poate lua decizii ce duc la utilizarea optim a resurselor. 10. Creterea accesibilitii datelor i a capacitii de rspuns Se realizeaz prin intermediul utilizrii limbajelor de programare din generaia a IV-a (ex. SQL, QBE).
15
BAZE DE DATE
11. Creterea productivitii Prin furnizarea unor funcii ce permit manipularea fiierelor i a introducerii limbajelor de programare din generaia a IV-a ce reduc mult timpul de programare. 12. Independena datelor Duce la creterea capacitii de ntreinere prin faptul c descrierile datelor sunt separate de aplicaii. 13. Controlul concurenei este mbuntit Se garanteaz c dac doi sau mai muli utilizatori acceseaz simultan aceleai date nu se pierd informaii sau nu se altereaz integritatea acestora. 14. Asigurarea salvrii de siguran i a refacerii Prin recuperarea ultimei stri coerente a bazei de date n cazul apariiei unei defeciuni hard sau soft.
1.1.4. Dezavantajele sistemelor de gestiune a bazelor de date

1. Complexitatea Trebuie avute n vedere o serie de probleme referitoare la date care se manifest suplimentar fa de cazul aplicaiilor clasice. Se face mai nti o analiz amnunit a datelor i apoi a aplicaiei propriuzise. 2. Dimensiunea SGBD-urile ocup mult spaiu pe disc. 3. Costul a) sistemelor SGBD; b) elementelor hard achiziionate; c) conversiei aplicaiilor existente la noul SGBD i noua configuraie hard. 4. Performana Este mai redus n cazul utilizrii SGBD-urilor care au un caracter mai general, n locul unei aplicaii simple bazat pe fiiere care apeleaz o singur funcie. 5. Efectul unei defeciuni Este mult mai mare datorit centralizrii (o defeciune minor afecteaz toi utilizatorii).
1.2. INDEPENDENA DATELOR. LIMBAJELE DE DEFINIRE I MANIPULARE A DATELOR

Pornind de la lucrrile lui Codd referitoare la modelul relaional i la limbajele bazate pe algebra relaional sau calculul relaional, comunitatea internaional a fcut, n timp, mari eforturi de redefinire i mbuntire a acestor concepte. n acest sens au fost dezvoltate o serie de versiuni ale limbajelor relaionale, cum ar fi SQL (Structured Query Language), QBE (Query-By-Example) i QUEL (Query Language). SQL i are originile n anul 1974 cnd IBM l-a folosit pentru prima dat n proiectul su de cercetare System R care funciona pe sisteme mainframe VS/2 sub denumirea de Structured English Query Language (sau SEQueL). Ulterior numele i-a fost schimbat n SQL (Structured Query Language, pronunat sequel sau S-Q-L). Produsele ulterioare ale firmei IBM, SQL/DS i, apoi, popularul DB2 16
BAZE DE DATE
folosesc acest limbaj. SQL se bazeaz pe calculul relaional ce are n vedere utilizarea de variabile constituite din tupluri. n 1986, Institutul Naional American pentru Standarde (ANSI) a elaborat i lansat standardele SQL contribuind astfel la extinderea acestuia n ntreaga comunitate a productorilor de baze de date care, dei are numeroase variante, folosete totui acelai set de comenzi i structuri de baz standardizate.
Instane i scheme
Bazele de date se modific des n decursul timpului. Datele aflate ntr-o baz de date la un anumit moment dat alctuiesc o instan a acelei baze de date. Proiectul general al bazei de date este denumit schema bazei de date. O schem reprezint o descriere a datelor conform modelului de date propus. Schema bazei de date reprezint ceea ce n limbajele de programare clasice este cunoscut sub numele de definirea tipurilor de date, iar instana unei baze de date este ceea ce n limbajele de programare clasice este cunoscut sub denumirea de valoarea unei variabile. Schema bazei de date reprezint descrierea general a bazei de date i conine: - informaiile fizice de proiectare; - informaii referitoare la utilizator; - descrieri de nivel nalt ale tranzaciilor i aplicaiilor precum i legturile utilizatorilor cu ele; - relaiile dintre date i tranzacii; - statistici de utilizare. n funcie de nivelul de abstractizare corespunztor exist urmtoarele tipuri de scheme: 1. Schema extern (subschema) se afl la nivel superior i corespunde unei valori a datelor. Ea descrie vederile bazei de date ce se folosesc ntr-o anumit aplicaie i corespunde schemei conceptuale. Schema reprezint vederea utilizatorilor asupra datelor (aplicaia). 2. Schema conceptual (logic) corespunde nivelului conceptual i descrie articolele, relaiile i constrngerile dintre ele. Ea este o descriere abstract i integrat a tuturor datelor, independent de sistemul de gestiune al bazelor de date folosit i trebuie s corespund schemei interne. Schema reprezint perspectiva sistemului de gestiune al bazelor de date. 3. Schema intern se afl la nivel inferior i conine definiiile tuturor nregistrrilor stocate n baza de date, metodele de reprezentare, cmpurile i indexurile datelor (descrie modul de stocare fizic a datelor precum i structurile de acces la date). Schema reprezint perspectiva realizrii sistemului/implementrii. Sistemul de gestiune al bazelor de date efectueaz corespondene ntre cele trei tipuri de scheme pentru a le corela. Dac se produce o modificare la nivel fizic, schema intern trebuie modificat, dar schema conceptual poate rmne neatins. Corespondenele efectuate ntre vederile utilizatorilor (nivelul extern) i stocarea fizic a datelor (nivelul intern) ajut la ascunderea complexitii nivelului fizic, ceea ce face s creasc flexibilitatea i posibilitile de adaptare. Sistemul SGBD trebuie s verifice dac fiecare schem extern poate fi derivat din schema conceptual. Pentru a stabili corespondena dintre fiecare schem extern i cea intern, sistemul trebuie s foloseasc informaiile din schema conceptual.
Schema relaional
Structura relaional a unei baze de date mai este cunoscut i sub denumirea de schem relaional (sau metastructur datorit faptului c ea descrie structura datelor). O schem relaional reprezint o descriere a unei colecii particulare de date, folosind un anumit model dat. Aceasta predefinete posibilele stri ale bazei de date, n sensul c nici o stare a unei baze de date nu poate conine date care s nu fie obinute n urma instanierii schemei respectivei baze de date i nici o stare a unei baze de date nu poate conine o asociere ntre dou seturi de date dac aceast asociere nu a fost definit n schema bazei de date. n plus, procedurile de manipulare a datelor trebuie s fie separate de date. Modelul relaional al datelor este cel mai utilizat model pe plan mondial la ora actual. Conceptul de baz ce fundamenteaz acest model este relaia, transformat ntr-un tabel ce conine rnduri i 17
BAZE DE DATE
coloane. Fiecare relaie are o schem ce descrie coloanele sau cmpurile tabelului. n practic, schema bazei de date conine: a. definiia tipurilor de date; b. definiia relaiilor, specificnd pentru fiecare dintre ele: - intensia (numele tuturor atributelor); - cheia primar. De obicei, ntr-un sistem relaional att schema conceptual ct i schema extern sunt relaionale. Pentru a prezenta proiectul unei baze de date independent de orice limbaj de definire a datelor, de obicei, se folosete o notaie general acceptat care are formatul:
<nume relatie>: <lista numelor atributelor>
O astfel de notaie este util n scopul clarificrii organizrii generale a bazei de date, dar nu lmurete o serie de detalii referitoare, n special, la proprietile domeniilor de valori ale atributelor. O definire mai complet care utilizeaz limbajul de definire a datelor se poate face cu ajutorul notaiei originale propus de Codd, n care componentele sunt descrise n amnunt. Cu ajutorul acestei notaii se pot crea entitile, atributele, domeniile de valori precum i cheile sub forma unor entiti ale schemei bazei de date. Un astfel de limbaj definete doar structura acestor entiti, nu i coninutul lor.
1.2.1. Independena de date

Reprezint faptul c nivelele superioare nu sunt afectate de modificrile fcute la nivelele inferioare. Aceasta nseamn i faptul c vederea unui utilizator (schema extern) este complet independent de vederea altui utilizator, ceea ce are un efect extrem de favorabil n cazul modificrilor efectuate de ctre administratorul bazei de date (ce pot apare ca urmare a cererilor venite din partea utilizatorului respectiv, ca urmare a necesitilor de adaptare a sistemului la noile condiii sau ca urmare a dorinei de optimizare a funcionrii sistemului) care poate face modificri ale vederii unui singur utilizator fr a afecta vederile celorlali utilizatori. Conform arhitecturii propuse de organizaiile ANSI/SPARC se ofer dou nivele de independen a datelor: 1. Independena logic de date 2. Independena fizic de date. Independena logic de date Se refer la imunitatea schemelor externe fa de modificrile efectuate n schema conceptual. Modificrile din schema conceptual pot fi: a. adugarea sau eliminarea de noi entiti; b. adugarea sau eliminarea de atribute; c. adugarea sau eliminarea de relaii. Independena logic de date nseamn c se pot face modificri n schema conceptual fr a fi necesar schimbarea schemei externe existente sau rescrierea programelor de aplicaie. Modificrile nu trebuie s afecteze toi utilizatorii ci doar pe aceia pentru care s-au fcut. Acetia trebuie informai de acest lucru. Independena fizic de date Se refer la imunitatea schemei conceptuale fa de modificrile efectuate n schema intern. Modificrile din schema intern pot fi: a. organizare diferit a fiierelor; b. structuri de stocare diferite; c. dispozitive de stocare diferite; d. indexuri sau algoritmi diferii. Modificrile fcute n schema intern se fac cu scopul mbuntirii performanelor bazei de date. 18
BAZE DE DATE
Independena de date este un concept care rmne de multe ori un deziderat greu de realizat, chiar i n cazul sistemelor din ce n ce mai performante ale zilelor noastre. Totui, bazele de date relaionale, datorit limbajelor relaionale pe care le folosesc, ofer un nalt grad de independen fa de date. Dei, aa cum am artat, ntr-un sistem relaional att schema conceptual ct i cea extern sunt, ambele, relaionale, totui, schema conceptual se construiete cu ajutorul unor instrumente ce au un caracter mult mai general dect cel oferit de modelul relaional. Presupunnd, de exemplu, c o vedere nu mai este necesar unui utilizator, datorit faptului c anumite atribute nu mai sunt de actualitate, alte atribute din baza de date prezentnd interes pentru acesta, se poate efectua o modificare n clauza SELECT pentru a rspunde cererii de modificare. Att timp ct fiecare vedere este definit separat n funcie de schema conceptual i att timp ct schema conceptual nu se modific, orice vedere creat pe baza acelei scheme poate fi actualizat fr a afecta celelalte vederi. Independena de date se mai folosete i atunci cnd se dorete s se obin o independen a vederilor utilizatorilor fa de schema conceptual. De obicei, dac relaiile i atributele la care se face referire n definiia vederii nu sunt eliminate cu ocazia unei modificri, vederea nu va fi afectat de modificare. n acest fel, cererile suplimentare de modificare pot fi efectuate fr teama c ele ar putea afecta aplicaiile existente care folosesc acea baz de date. n sfrit, independena de date se mai refer i la faptul c este posibil modificarea schemei prin care se realizeaz nmagazinarea fizic a datelor, fr a afecta schemele conceptual, respectiv extern.
1.2.2. Limbajele bazelor de date

Pentru a construi o baz de date un utilizator trebuie s: a. defineasc schema bazei de date; b. aplice o colecie de operatori pentru a crea, nmagazina, extrage i modifica datele. Un sistem de gestiune al bazelor de date obinuit trebuie s ofere o serie de instrumente care s uureze activitile specificate anterior. n acest sens, SQL trebuie s fie limbajul standard relaional al bazei de date, avnd urmtoarele componente: a. un limbaj de definire a datelor (Data Definition Language DDL), utilizat la definirea schemei bazei de date b. un limbaj de manipulare a datelor (Data Manipulation Language DML), care permite utilizatorului manipularea obiectelor bazei de date i a relaiilor dintre acestea, n contextul schemei bazei de date. Aceste limbaje pot diferi de la un productor la altul n cadrul modelului pe care acetia l folosesc datorit aspectelor legate de complexitate, funcionalitate i uurina n exploatare (interfaa utilizator). De multe ori aceste limbaje sunt denumite sublimbaje de date deoarece nu includ construcii pentru toate necesitile de calcul cum sunt cele asigurate de limbajele de nivel nalt. Majoritatea sistemelor de gestiune a bazelor de date au ncorporat sublimbajul ntr-un limbaj de programare de nivel nalt (ex. C++). n acest caz limbajul de nivel nalt este numit limbaj gazd.
1.2.2.1. Limbajul de definire a datelor

Permite administratorului bazei de date sau utilizatorului s descrie i s denumeasc entitile din baza de date precum i relaiile ce pot exista ntre diferitele entiti. Limbajul de definire al datelor reprezint o colecie de instruciuni utilizate pentru descrierea tipurilor de date. Administratorul bazei de date trebuie s defineasc structura bazei de date cu ajutorul acestor tipuri de date. Acesta este utilizat pentru a defini o schem a bazei de date sau pentru a modifica una existent. Rezultatul compilrii instruciunilor din limbajul de definire a datelor reprezint un set de tabele stocate n fiiere speciale denumite cataloage de sistem. Catalogul de sistem conine meta-datele (datele care descriu obiectele din baza de date). Metadatele conin definiii ale nregistrrilor datelor i altor obiecte cerute de sistemul de gestiune al bazei de date. Sistemul de gestiune al bazei de date consult mai nti catalogul de sistem pentru a accesa corect datele. Teoretic, sunt trei limbaje de definire a datelor: 19
BAZE DE DATE
- pentru schema extern; - pentru schema conceptual; - pentru schema intern. Limbajul de definire a datelor conine comenzi necesare urmtoarelor operaii: - definirea schemelor de relaie; - eliminarea relaiilor; - crearea indecilor; - modificarea schemelor. Limbajul de definire a datelor permite specificarea urmtoarelor informaii necesare n orice baz de date: - schema fiecrei relaii din baza de date; - domeniul de valori asociat fiecrui atribut; - constrngerile de integritate; - setul de indeci care se creeaz pentru fiecare relaie n parte; - informaii referitoare la securitatea sistemului i la modul de acces la acesta; - structura de nmagazinare fizic pe disc a datelor.
1.2.2.1.1. Definirea schemei n SQL

O relaie n SQL se definete cu ajutorul sintaxei:
CREATE TABLE r (A1;D1;A2;D2; : : :;An;Dn, i, : : : , constrangere_de_integritate1 i) constrangere_de_integritate1
n care r reprezint numele relaiei, AI reprezint numele unui atribut, iar DI reprezint domeniul n care ia valori acel atribut. Constrngerile de integritate permise sunt cheia primar (Aj1; : : :;Ajm) i regulile de validare a domeniului de valori (check(P)). O cheie primar trebuie s ndeplineasc dou condiii: - valorile cheii primare trebuie s fie unice; - ntr-o cheie primar nu trebuie s apar valori nule. Standardul SQL-92 consider c apariia constrngerii not null n cheia primar este un fapt redundant, dar standardul SQL-89 cere definirea explicit a acestui lucru. Regulile de validare a domeniului de valori (check) se dovedesc a fi extrem de utile la creterea funcionalitii bazei de date dar, uneori, sunt foarte costisitoare, aa cum se ntmpl, de exemplu, n cazul folosirii cheii externe. n cazul n care se dorete eliminarea unei relaii din baza de date trebuie folosit urmtoarea relaie:
DROP TABLE r
ceea ce nu este acelai lucru cu:

DELETE r
care pstreaz relaia, dar elimin toate tuplurile din ea. Comanda de modificare a structurii unui tabel poate fi folosit pentru a aduga sau elimina atribute din cadrul unei relaii r existente n baza de date:
ALTER TABLE r ADD A D
n care A reprezint atributul, iar D reprezint domeniul de valori ce trebuie atribuit acestuia.
ALTER TABLE r DROP A
20
BAZE DE DATE
n care A reprezint atributul care trebuie eliminat din baza de date.
1.2.2.1.2. Utilizarea interogrilor SQL n cadrul aplicaiilor

SQL este un limbaj de interogare extrem de performant, datorit avantajului oferit de prelucrarea pe seturi de nregistrri. Totui, el nu poate oferi procedurile necesare efecturii unei serii de activiti i aciuni, cum ar fi: crearea de interfee grafice prietenoase, crearea i imprimarea de rapoarte, interaciuni cu ali utilizatori, transferul datelor ntre baza de date i aplicaii. Din acest motiv este necesar utilizarea unui limbaj de programare din generaia a treia care s realizeze conexiunea cu baza de date i s efectueze sarcini dintre cele artate anterior. Standardul SQL definete instruciunea EXEC care s poat fi folosit n astfel de situaii:
EXEC instructiune SQL
Instruciunile SQL admise sunt: DECLARE CURSOR, OPEN i FETCH care prelucreaz datele din baza de date nregistrare cu nregistrare, precum i instruciunile de modificare, inserare sau tergere a datelor. Componenta dinamic SQL permite crearea i utilizarea de interogri SQL care s se modifice n timpul rulrii aplicaiilor. De asemenea, n standardul SQL-92 sunt introduse module ce permit definirea procedurilor n SQL.
1.2.2.2. Limbajul de manipulare a datelor

Asigur un set de procedee ce permit operaii de baz pentru manipularea datelor din baza de date. Limbajul de manipulare a datelor asigur o colecie de operatori ce pot fi aplicai pentru a valida instanele tipurilor de date n cadrul schemei i de a crea, modifica sau extrage astfel de instane. Cu ajutorul acestor operatori se pot efectua urmtoarele operaii: 1. Regsirea datelor din baza de date (operaie principal). 2. Inserarea de date noi n baza de date. 3. Modificarea datelor existente. 4. tergerea de date din baza de date. Exist dou tipuri de limbaje de manipulare a datelor: Limabje de manipulare a datelor procedurale (specific modelelor reea i ierarhic) care permit utilizatorului s comunice sistemului ce date sunt necesare i cum pot fi ele exact regsite. Aceste limbaje prelucreaz informaia nregistrare cu nregistrare. Limbaje de manipulare a datelor neprocedurale (specifice modelului relaional) care permit utilizatorului s comunice sistemului ce date sunt necesare fr a specifica cum se regsesc datele. Aceste limbaje prelucreaz informaia pe seturi de nregistrri i au urmtoarele caracteristici: - confer o mai mare independen de date; - cresc viteza de prelucrare a informaiei; - sunt limbaje de generaia a patra (4GL - Fourth Generation Language). Exemple de astfel de limbaje ce aparin generaiei a patra sunt: - limbajul SQL; - limbajul QBE; - generatoare de formulare; - generatoare de rapoarte; - generatoare grafice; - generatoare de aplicaii.
1.2.2.2.1. Extragerea informaiilor din bazele de date

Limbajul de manipulare a datelor permite extragerea datelor dintr-o baz de date. Structura de baz a unei expresii SQL const din utilizarea clauzelor SELECT, FROM i WHERE. 21
BAZE DE DATE
SELECT este o clauz ce folosete o list a atributelor ce urmeaz a fi prezentate utilizatorului i care corespunde operaiei de proiecie din algebra relaional. FROM este o clauz ce corespunde produsului cartezian din algebra relaional i n care se introduc relaiile din care urmeaz a fi extrase atributele ce apar n clauza SELECT. WHERE este o clauz ce corespunde predicatului de selecie din algebra relaional. n mod obinuit o interogare se prezint sub forma:
SELECT A1;A2; : : :;An FROM r1; r2; : : :; rm WHERE P
n care fiecare AI reprezint un atribut, fiecare ri reprezint o relaie, iar P este un predicat, ceea ce este echivalent expresiei:
A1;A2;:::;An (_P (r1 _ r2 _ : : :_rm))
Dac se omite clauza WHERE, predicatul P are valoarea True. Lista atributelor poate fi nlocuit printr-un caracter * pentru a le alege pe toate. Prin intermediul SQL se alctuiete produsul cartezian pe baza relaiilor precizate, se poate efectua o selecie cu ajutorul unui predicat, dup care se poate face o proiecie pe anumite atribute. Rezultatul unei interogri SQL este tot o relaie i, n mod implicit, nregistrrile duplicat nu sunt eliminate. n lista de selecie se pot afla i operaii aritmetice.
Clauza WHERE
Predicatele pot avea orice grad de complexitate i pot implica: - conexiuni logice de tip and, or, sau not; - expresii aritmetice ce conin constante sau valori ale tuplurilor; - operatorul between utilizat pentru definirea domeniilor de valori ale variabilelor.
Clauza FROM
Clauza FROM n sine, definete un produs cartezian calculat pe baza relaiilor care sunt specificate n cadrul acesteia. SQL nu ofer echivalentul jonciunii naturale, dar aceasta poate fi exprimat cu ajutorul unui produs cartezian urmate de operaiile de selecie i proiecie. Variabilele, care n SQL sunt reprezentate de tuplurile relaiilor, se definesc n clauza FROM, putnd fi folosite n cadrul expresiilor.
Operaia de redenumire
Redenumirea reprezint un mecanism utilizat la schimbarea numelor relaiilor sau atributelor. Pentru aceasta se poate folosi clauza AS ce poate s apar att n clauza SELECT ct i n clauza FROM, sub forma:
Nume_vechi AS nume_nou
Operaii cu iruri
Cele mai frecvente operaii fcute cu irurile de caractere sunt cele n care se folosesc operatorii Like sau Not Like cu scopul regsirii unor seturi de caractere specificate. Se mai pot folosi i o serie de alte funcii caracter, cum ar fi concatenarea, extragerea subirurilor, determinarea lungimii unui ir de caractere .a.m.d.
22
BAZE DE DATE
Ordonarea afirii nregistrrilor

SQL permite utilizatorului s controleze ordinea de apariie a tuplurilor prin folosirea clauzei ORDER BY. Operaia de sortare poate fi foarte costisitoare i trebuie fcut numai n cazuri n care chiar sunt necesare.
Tupluri duplicat
Limbajele formale de interogare se bazeaz pe relaiile matematice. Din acest motiv, n cadrul relaiilor nu sunt permise nregistrrile duplicat dar, deoarece eliminarea acestora este extrem de costisitoare SQL admite duplicatele. Dac se dorete eliminarea acestora se poate folosi clauza DISTINCT, iar dac se dorete s se obin asigurarea c nregistrrile duplicat nu sunt eliminate se folosete clauza ALL.
Operaii cu mulimi
SQL folosete n acest caz reuniunea, intersecia i diferena. Prin operaia de reuniune se elimin duplicatele dar, dac nu se urmrete acest lucru se poate folosi clauza UNION ALL. n cazul operaiei de diferen se poate face precizarea c standardul SQL din 1986 prevedea pentru aceast operaie clauza MINUS, n timp ce standardul din 1992 a redenumit clauza care este folosit astzi sub denumirea de EXCEPT.
Funcii agregat
SQL poate opera cu funcii pe grupuri de tupluri folosind clauza GROUP BY. Atributele respective sunt folosite pentru a forma grupuri ce au aceleai valori, astfel nct SQL poate determina: - valoarea medie (Avg); - valoarea minim (Min); - valoarea maxim (Max); - suma total a valorilor (Sum); - numrul total al nregistrrilor din grup. Toate aceste funcii sunt denumite funcii agregat sau totalizatoare. Astfel de funcii ntorc drept rezultat o singur valoare. Dac n aceeai interogare apare att clauza WHERE ct i clauza HAVING, predicatul clauzei WHERE este aplicat primul. Acele tupluri care ndeplinesc condiia impus se introduc n cadrul unor grupuri cu ajutorul clauzei GROUP BY. Clauza HAVING este aplicat fiecrui grup care se formeaz. Grupurile ce ndeplinesc condiia impus prin clauza HAVING sunt utilizate de clauza SELECT pentru a genera tuplurile rezultat. Dac nu exist o clauz HAVING, tuplurile ce ndeplinesc condiia impus de clauza WHERE sunt tratate ca i cum ar fi un singur grup.
Conceptul de NULL
Interogrile n care nu se cunosc toate valorile ce trebuie afiate pun probleme, deoarece o valoare necunoscut nu poate fi comparat sau utilizat ca parte a unei funcii agregat. Toate comparaiile care implic valori necunoscute sunt false prin definiie. Pentru a determina dac n setul de rezultate se afl valori necunoscute se poate utiliza cuvntul cheie NULL n scopul efecturii unui astfel de test. Toate funciile agregat, cu excepia funciei COUNT ignor tuplurile ce au valori necunoscute.
Relaii obinute prin cuplare

n cadrul standardului SQL-92 se prevede faptul c fiecare operaie de cuplare trebuie s aibe un tip de jonciune i o condiie de cuplare. Tipurile de jonciuni prevzute n standardul respectiv sunt jonciunile interioare, jonciunile exterioare stnga, jonciunile exterioare dreapta i jonciunile 23
BAZE DE DATE
complete exterioare. Cuvintele cheie interior, respectiv exterior sunt opionale, deoarece tipul de jonciune poate fi dedus din jonciunea propriu-zis. n standardul SQL-92 se mai introduc alte dou noi tipuri de jonciuni: a. jonciunea ncruciat (o jonciune interioar fr condiie de cuplare); b. jonciune de uniune (o jonciune exterioar complet aplicat pe o condiie de cuplare fals, cum ar fi de exemplu situaia n care jonciunea interioar nu conine nici o nregistrare). Utilizarea unei condiii de cuplare este obligatorie n cazul jonciunilor exterioare, dar este opional n cazul jonciunilor interioare (dac se omite, se obine un produs cartezian).
Subinterogri imbricate Membru al unui set de nregistrri

Pentru a determina acest lucru se pot folosi operatorii In i Not In.
Comparaii ntre seturi de nregistrri

Pentru a compara elementele unei mulimi se pot folosi operatorii de comparaie. Se interzice utilizarea funciilor agregat n cadrul altor funcii agregat, astfel nct, de exemplu, nu este acceptat formula Max(Avg()).
Testarea relaiilor ce nu conin nregistrri

Se face cu ajutorul construciei EXISTS care returneaz valoarea True dac subinterogarea care este folosit ca argument conine nregistrri.
Testarea absenei tuplurilor duplicat

Se face cu ajutorul construciei UNIQUE care ntoarce valoarea True dac subinterogarea din argumentul funciei nu conine tupluri duplicat.
Relaii derivate
Standardul SQl-92 permite utilizarea unei subinterogri n cadrul clauzei FROM. Dac se ntmpl acest lucru, relaiei rezultat trebuie s i se dea un nume, iar atributele trebuie redenumite.
Modificrile bazei de date

Limbajul de manipulare a datelor permite acest lucru, aa cum se va vedea din cele ce urmeaz.
tergeri
Eliminarea tuplurilor din cadrul unei relaii se exprim n mod asemntor unei interogri, cu deosebirea c n locul afirii tuplurilor rezultat, acestea sunt eliminate din cadrul relaiei respective, aa cum se poate vedea din sintaxa:
DELETE FROM r WHERE P
Sunt eliminate acele tupluri din relaia r care ndeplinesc condiia specificat n predicatul P. Dac se omite clauza WHERE, sunt eliminate toate tuplurile din cadrul relaiei. Se pot elimina doar tuplurile dintr-o singur relaie la un moment dat, dar se poate asocia un numr nelimitat de relaii cu ajutorul unei clauze SELECT-FROM-WHERE ce se poate introduce n cadrul unei clauze WHERE a clauzei DELETE. O astfel de tehnic trebuie ns folosit cu pruden deoarece poate duce la apariia de ambiguiti. Se recomand ca naintea utilizrii clauzei DELETE s se fac toate testele necesare, marcndu-se tuplurile ce urmeaz a fi terse.
Inserri
24
BAZE DE DATE
Inserarea unei noi nregistrri n cadrul unei relaii se face fie prin specificarea unui tuplu, fie prin utilizarea unei interogri al crei rezultat este setul de tupluri ce urmeaz a fi inserat. Valorile atributelor tuplurilor inserate trebuie s respecte constrngerile de domeniu impuse. nainte de a efectua o operaie de inserare se recomand evaluarea complet a unei instruciuni SELECT corespondent pentru a evita apariia de probleme. Este posibil ca nu toate atributele tuplurilor inserate s aibe valori i, prin urmare, n acest caz acestea trebuie s fie declarate ca fiind necunoscute.
Actualizri
Operaia de actualizare permite modificarea anumitor valori n cadrul tuplurilor fr a fi necesar modificarea lor complet. n general, clauza WHERE aplicat clauzei UPDATE poate conine orice construcie corect acceptat ntr-o clauz SELECT obinuit. O clauz SELECT imbricat n cadrul unei clauze UPDATE poate asocia o relaie care trebuie actualizat.
1.2.3. Alte caracteristici SQL

SQL face parte din categoria aa-numitelor limbaje de generaia a patra datorit puterii sale, a conciziei i a procedurilor de nivel sczut pe care le conine. Produsele de baze de date conin un limbaj special ce ajut programatorii de aplicaii s creeze abloane, interfee utilizator i rapoarte de date. n limbajele de generaia a patra nu exist un standard unanim acceptat. Standardul SQL-92 definete sesiunile i mediile SQL. Sesiunea SQL reprezint un concept legat de tehnologia client/server (conectare, deconectare, efectuare sau reluare a tranzaciilor), n timp ce mediul SQL ofer fiecrui utilizator un identificator i o schem. Ca limbaj neprocedural, SQL permite utilizatorilor s precizeze ce trebuie fcut fr a arta cum trebuie fcut. Cererea fcut de ctre un utilizator este transformat de sistemul de gestiune a bazei de date n detaliile tehnice necesare obinerii datelor. Din acest motiv, se spune c bazele de date relaionale necesit mult mai puine eforturi de programare dect orice alt tip de baze de date sau sistem de fiiere, ceea ce face ca limbajul SQL s fie relativ uor de nvat.
1.2.4. Query-By-Example (QBE)

Limbajele de interogare a datelor au fost dezvoltate la nceputul anilor aptezeci cnd interfeele ommain erau, spre deosebire de cele din zilele noastre, limitate i rudimentare. De exemplu, interaciunea avea loc prin intermediul unor procese alctuite din seturi de comenzi n care comenzile (cereri de tipul ruleaz acest program pe acele date, evalueaz interogarea etc.) erau pregtite pe calculatoare separate i puse la un loc n setul de comenzi care era apoi trimis spre procesare. n timp ce avea loc procesarea datelor, ntre calculator i utilizator nu se producea nici o interaciune. La terminarea procesului de prelucrare rezultatele erau imprimate, iar utilizatorul le examina pentru a determina urmtoarea aciune ce trebuia ntreprins. Setul de comenzi era apoi reluat pn cnd utilizatorul era mulumit de rezultat. Spre deosebire de SQL, limbajul QBE se bazeaz pe calculul relaional. QBE a fost dezvoltat de M.M. Zloof de la IBM Yorktown Heights Laboratory. n limbajul QBE o interogare este o construcie elaborat pe un terminal interactiv ce afieaz imagini bidimensionale ce conin una sau mai multe relaii prezentate sub forma unor formulare care se completeaz prin introducerea valorilor n coloanele selectate (exemple). Sistemul rspunde la ntrebri prin parcurgerea datelor pe baza unui exemplu dat afind rezultatele pe acelai ecran. De obicei, reprezentarea relaiilor este uurat prin intermediul comenzilor interactive care sunt disponibile prin intermediul unor meniuri. Selecia comenzilor din meniu se face n funcie de schema disponibil, eliminndu-se astfel erorile legate de scrierea numelor tabelelor sau atributelor acestora, aa cum s-ar putea ntmpla n cazul folosirii limbajului SQL. Interfaa oferit este un editor structurat pe baza unui limbaj grafic.
25
BAZE DE DATE
1.3. SISTEME DE GESTIUNE A BAZELOR DE DATE Baza de date reprezint una sau mai multe colecii de date aflate n interdependen mpreun cu descrierea datelor i a relaiilor dintre ele. Colecia de date reprezint un ansamblu de date organizat dup anumite criterii i este format din componentele: a) o familie de caracteristici alctuit din atribute ce definesc aspecte ale obiectelor din lumea real; b) un predicat aplicat familiei de caracteristici ce conduce la o submulime ce definete o relaie de ordine ntre caracteristici; c) o suit temporal T = {t0, t1, ..., tj, ...} ce definete un decalaj al timpului n intervale discrete; d) afectarea la fiecare moment tj a unei relaii asociat predicatului. Bazele de date sunt gestionate cu ajutorul unui program numit sistem de gestiune al bazelor de date. Sistemul de gestiune a bazelor de date (SGBD) este un sistem de programe ce permite definirea, crearea i ntreinerea bazei de date precum i accesul controlat la acesta. Din punct de vedere conceptual, gestiunea bazelor de date se bazeaz pe ideea separrii structurii bazei de date de coninutul acesteia. n sistemele de baze de date definirea datelor se separ de programele aplicaie, astfel nct utilizatorii vd doar definiia extern a unui obiect fr a cunoate modul n care e definit acesta i cum funcioneaz. n acest mod, definiia intern a obiectului poate fi modificat fr a afecta utilizatorii acestuia dac nu se modific definiia extern. De exemplu, dac sunt adugate noi structuri de date sau sunt modificate cele existente, atunci programele aplicaie nu sunt afectate dac nu depind direct de ceea ce se modific. Structura bazei de date reprezint o colecie de descrieri statice ale tipurilor de entiti mpreun cu relaiile logice stabilite ntre ele. Relaiile logice reprezint asociaiile dintre mai multe entiti. O entitate este un obiect distinct ce trebuie reprezentat n baza de date. Un atribut este o proprietate ce descrie un anumit aspect al obiectului ce se nregistreaz n baza de date. Scopul unui sistem de gestiune al unei baze de date este acela de a oferi un mediu care s fie i convenabil, dar i eficient pentru a putea fi folosit la: - extragerea informaiilor din baza de date; - nmagazinarea datelor n baza de date. Bazele de date sunt de obicei folosite la gestionarea unei mari cantiti de date, ceea ce presupune existena urmtoarelor caracteristici: - definirea structurilor (modelarea datelor); - utilizarea unor mecanisme de manipulare a datelor; - asigurarea securitii datelor n baza de date; - asigurarea controlului concurenei n cazul utilizrii sistemului de ctre mai muli utilizatori Orice sistem de gestiune al bazelor de date are urmtoarele componente:
Limbajul de definire a datelor

Cu ajutorul acestui limbaj se specific tipurile de date i structurile precum i constrngerile asupra datelor. Instruciunile limbajului sunt compilate i transformate ntr-un set de tabele nmagazinate ntr-un fiier special numit dicionar de date sau catalogul sistemului (descrierea datelor se ntlnete sub denumirile de catalog de sistem, dicionar de date sau meta-date ceea ce nseamn date despre date). Structura de nmagazinare a datelor precum i metodele de acces utilizate de sistemul bazei de date sunt specificate cu ajutorul unui set de definiii folosit cu scopul ascunderii detaliilor de implementare a schemelor bazei de date 26
BAZE DE DATE
Un limbaj de manipulare a datelor

Acest limbaj este folosit pentru a ajuta utilizatorul s acceseze i s foloseasc datele aflate n baza de date ntr-un mod interactiv. Cu ajutorul acestui limbaj se pot: - extrage date din baza de date; - introduce date n baza de date; - elimina date din baza de date; - actualiza date din baza de date.
Administratorul bazei de date

Administratorul bazei de date este un program ce asigur interfaa dintre datele nmagazinate, aplicaiile care folosesc aceste date i ntrebrile adresate sistemului cu ajutorul crora se extrag datele necesare. De obicei, bazele de date necesit un spaiu mare de nmagazinare pe mediul de stocare ales, ce poate ajunge de ordinul gigabytes-ilor. Pentru a putea fi prelucrate datele se transfer din memoria extern n memoria intern a sistemului. Scopul sistemului bazei de date este acela de a uura accesul la date, iar administratorul bazei de date este rspunztor de urmtoarele: - asigur interaciunea cu administratorul de fiiere (trebuie s transfere instruciunile limbajului de manipulare a datelor n comenzi de nivel sczut recunoscute de sistemul de fiiere); - asigur integritatea datelor prin verificrile pe care le efectueaz n momentul actualizrii datelor astfel nct acestea s nu ncalce constrngerile impuse i s fie consistente; - asigur securitatea datelor prin accesul controlat la date pe care l ofer utilizatorilor (acetia nu pot accesa orice fel de date dac nu le este permis acest lucru); - creeaz copiile de siguran i asigur refacerea datelor, n cazul apariiei unei erori sau defeciuni n baza de date, la starea la care acestea se aflau nainte de apariia erorii sau defeciunii; - asigur controlul concurenei pstrnd consistena datelor atunci cnd acestea sunt accesate n acelai timp de mai muli utilizatori.
1.3.1. Componentele unui sistem de gestiune al bazelor de date

Acestea sunt: 1. Hardware 2. Software 3. Date 4. Proceduri 5. Resurse umane
1.3.1.1. Componenta hardware

Aceast component poate fi reprezentat de un singur calculator personal, un singur calculator mainframe sau o reea de calculatoare. De obicei, ntr-o reea de calculatoare, se aplic urmtoarea schem: Se folosete un calculator principal pe care se afl programele back-end - adic partea din sistemul de gestiune al bazei de date care administreaz i controleaz accesul la baza de date i mai multe calculatoare aflate n diferite locaii pe care se afl programele front-end adic partea din sistemul de gestiune al bazei de date ce constituie interfaa cu utilizatorul. n aceast schem, numit client-server, programele back-end reprezint serverul iar cele front-end reprezint clienii.
1.3.1.2. Componenta software

Aceast component este alctuit din: - programele sistemului de gestiune al bazei de date; 27
BAZE DE DATE -
programele aplicaie scrise de obicei n limbaje de programare de generaia a III-a (C, Pascal, Cobol) sau SQL ncorporat ntr-un limbaj de generaia a III-a; - sistemul de operare; - programe de reea. Sistemul de gestiune al bazei de date poate avea ncorporate instrumente din generaia a IV-a, cum ar fi SQL ce permit: dezvoltarea rapid de aplicaii; mbuntirea semnificativ a productivitii; realizarea unor programe uor de ntreinut.
1.3.1.3. Date
Datele acioneaz ca o punte de legtur ntre componentele main (hardware i software) i componenta uman. Baza de date conine att datele operaionale (setul de nregistrri pe care se lucreaz) ct i metadatele. Structura bazei de date este numit schem.
1.3.1.4. Proceduri
Procedurile reprezint instruciunile i regulile aplicate n proiectarea i utilizarea bazei de date. Acestea pot fi: - deschiderea unei sesiuni de lucru n sistemul de gestiune al bazei de date; - pornirea sau oprirea sistemului de gestiune al bazei de date; - utilizarea unui program de aplicaie sau a unei funcii a sistemului de gestiune al bazei de date; - efectuarea de copii de siguran; - tratarea defeciunilor hardware i software; - modificarea structurii unui tabel, reorganizarea bazei de date, mbuntirea performanelor, arhivarea datelor.
1.3.1.5. Resursele umane

Resursele umane sunt reprezentate de: 1. Administratorul de date este responsabil de gestionarea resurselor de date i proiectarea conceptual / logic a bazei de date. 2. Administratorul bazei de date este responsabil de realizarea fizic a bazei de date ce implic proiectarea i implementarea acesteia. Administratorul bazei de date este o persoan care are n rspundere controlul centralizat al datelor i al aplicaiilor ce folosesc aceste date. ndatoririle administratorului bazei de date cuprind: - definete schema bazei de date, ceea ce presupune scrierea unui set de definiii n limbajul de definire a datelor care apoi s poat fi compilate de ctre un compilator DDL i transformate ntrun set de tabele pstrate n catalogul sistemului; - definete structura de stocare i a metodele de acces prin scrierea unui set de definiii transferate compilatorului; - modific schema i organizarea fizic prin scrierea unui set de definiii utilizate de ctre compilatorul DDL pentru a face modificrile cerute n tabele; - asigur securitatea prin acordarea drepturilor de acces utilizatorilor pe baza unor conturi de utilizator create n acest scop; - verific respectarea constrngerilor de integritate ori de cte ori se introduc date n baza de date; - monitorizeaz toate activitile utilizatorilor; - monitorizeaz creterea dimensiunilor bazei de date; - i formeaz o imagine de ansamblu asupra sistemului, urmrind prile tari i slabe ale acestuia; - asigur controlul concurenei prin alegerea tipului de blocare ce va fi folosit atunci cnd aceleai date sunt folosite de mai muli utilizatori n acelai timp; 28
BAZE DE DATE 3. a) b) 4. -
asigur fiabilitatea sistemului n cazul apariiei unor erori. Proiectanii de baze de date care pot fi: Proiectant de baze de date logice: identific datele (entiti i atribute); identific relaiile dintre date; identific constrngerile; identific regulile ce descriu principalele caracteristici ale datelor; implic utilizatori n realizarea modelului de date. Proiectant de baze de date fizice: transpune modelul logic ntr-un set de tabele i constrngeri; selecteaz structuri de stocare i metode de acces specific; asigur securitatea datelor. Utilizatorii finali care pot fi de urmtoarele categorii: Programatorii de aplicaii. Acetia sunt profesionitii ce interacioneaz cu sistemul folosind instruciuni scrise n limbajul de manipulare a datelor pe care le ncorporeaz n cadrul unor interfee create n alte limbaje de programare. Precompilatorul DML convertete apelurile scrise n limbajul de manipulare a datelor n proceduri specifice limbajului gazd. Compilatorul limbajului gazd genereaz apoi codul obiect. - Utilizatori cu pregtire special. Acetia interacioneaz cu sistemul fr a scrie programe, dar ei formuleaz cereri pentru a extrage date din baza de date cu ajutorul instruciunilor specifice limbajului de manipulare a datelor. Aceste cereri sunt transmise procesorului de interogare care desparte o instruciune specific limbajului de manipulare a datelor n instruciuni specifice modulului de administrare a bazei de date. - Utilizatori specializai. Acetia sunt utilizatori cu pregtire special care scriu programe aplicaie specializate pentru diverse zone de interes (sisteme CAD, sisteme expert etc.). - Utilizatori obinuii. Acetia sunt utilizatori care interacioneaz cu sistemul folosind interfeele create de programatorii de aplicaii.
1.3.2. Componentele unui sistem de gestiune a bazelor de date

Sistemele de gestiune a bazelor de date sunt alctuite dintr-o serie de module ce ndeplinesc diverse funcionaliti. Anumite funcionaliti sunt ndeplinite mpreun cu sistemul de operare pe care este folosit sistemul respectiv. Principalele componente ale unui sisteme de gestiune al bazelor de date sunt: Administratorul de fiiere gestioneaz alocarea spaiului pe disc precum i structurile de date utilizate la reprezentarea datelor pe disc. Acesta transmite cererea ctre metoda de acces corespunztoare care fie citete datele din buffer-ul sistemului, fie le scrie n acesta. Administratorul bazei de date accept interogrile i examineaz schemele externe i conceptuale pentru a determina ce nregistrri sunt necesare pentru a satisface o anumit cerere, dup care apeleaz administratorul de fiiere pentru a efectua cererea. Procesorul de interogare transform interogrile ntr-o serie de instruciuni de nivel jos adresate administratorului de baze de date.
29
BAZE DE DATE
Preprocesorul DML convertete instruciunile DML dintr-un program aplicaie n apeluri de funcii standard ale limbajului gazd i interacioneaz cu procesorul de interogare pentru a genera codul corespunztor.
Programatori
Programe aplicaie
Utilizatori

Schema bazei de date
Interogri
Preprocesorul DML
SGBD Procesor de interogare
Compilator DDL
Codul programului obiect
Administrator baza de date
Administrator catalog
Metode de acces
Administrator de fiiere
Buffer
Catalogul sistemului Baza de date
Figura 1.3. Componentele bazei de date Compilatorul DDL transform instruciunile DDL ntr-un set de tabele ce conin meta-datele. Tabelele sunt stocate n catalogul sistemului. Administratorul de catalog gestioneaz accesul i ntreinerea catalogului sistem. Catalogul sistemului este accesat de majoritatea componentelor sistemului de gestiune al bazei de date. Una dintre cele mai importante funcii din cadrul sistemului de gestiune al bazelor de date o are administratorul bazei de date. Acesta pstreaz interfaa cu programele aplicaie i interogrile lansate de utilizatori.
30
BAZE DE DATE
Codul programului obiect
Procesorul de interogare
Administratorul de catalog
Controlul de autorizare
Verificatorul de integritate
Procesorul de comand
Optimizatorul de interogare
Administratorul de tranzacii
Planificatorul
Administratorul de date
Administratorul de buffer
Administratorul de reconstituire
Metode de acces
Administratorul de fiiere
Buffer
Catalogul sistemului
Baza de date
Figura 1.4. Componentele administratorului bazei de date Administratorul bazei de date are una dintre cele mai importante funcii n cadrul unui sistem de gestiune al bazelor de date. Principalele componente ale acestuia sunt prezentate n figura 1.4. Aceste componente pot fi urmtoarele: - Procesorul de interogare este utilizat pentru a simplifica i uura accesul la date. Acesta conine Evaluatorul de interogare care execut fiecare interogare pe baza unui plan. - Administratorul de date este utilizat pentru a minimiza resursele necesare transferului de date dintre memoria intern i cea extern. Administratorul de date este un program care ofer o interfa ntre datele nmagazinate n baza de date i interogrile formulate prin intermediul aplicaiilor. Conine urmtoarele componente:
31
BAZE DE DATE
- Controlul de autorizare care verific dac utilizatorul are dreptul de a efectua operaia cerut. - Administratorul de fiiere. - Administratorul de buffer care rspunde de transferul datelor dintre memoria principal i dispozitivele de stocare secundare. Administratorul de tranzacii este utilizat pentru a controla atomicitatea i concurena tranzaciilor n scopul pstrrii consistenei i durabilitii bazei de date. O tranzacie reprezint o colecie de operaii aplicate bazei de date care sunt efectuate toate deodat sub forma unei singure uniti logice. Aceast component este alctuit din: - Administratorul de tranzacii. - Administratorul de blocare. - Administratorul de reconstituire care garanteaz c baza de date rmne ntr-o stare coerent dup ce n baza de date a aprut o eroare. Acesta este responsabil de reluarea sau abandonarea unei tranzacii.
1.3.3. Funciile sistemelor de gestiune a bazelor de date

1. Stocarea, regsirea i reactualizarea datelor. Este funcia fundamental a unui sistem de gestiune a bazelor de date. Sistemul trebuie s ascund fa de utilizatori detaliile privind implementarea fizic intern. 2. Asigurarea unui catalog accesibil utilizatorului Catalogul sistemului conine date despre scheme, utilizatori, aplicaii. Acesta trebuie s stocheze: a. denumirile, tipurile i dimensiunile articolelor de date; b. denumirile relaiilor; c. constrngerile de integritate asupra datelor; d. numele utilizatorilor autorizai care au acces la date; e. schemele externe, conceptuale, interne precum i transpunerile lor; f. statistica utilizrii (de exemplu: frecvena tranzaciilor, contorizarea numrului de accesri ale obiectelor din baza de date). Utilizarea unui astfel de catalog de sistem asigur o serie de avantaje care sunt prezentate n continuare: - contribuie la controlul datelor ca resurse; - se poate defini n sensul datelor; - simplific comunicarea; - identific utilizatorii; - identific cu uurin redundana i incoerena; - nregistreaz modificrile din baza de date; - impactul unei modificri poate fi determinat nainte de implementare; - mbuntete securitatea; - mbuntete integritatea; - monitorizeaz operaiile efectuate asupra bazei de date. 3. Asigurarea tranzaciilor Tranzacia reprezint un set de aciuni prin care se acceseaz sau se modific coninuturile bazei de date. Dac tranzacia eueaz (nu s-au efectuat toate modificrile, sau modificrile nu s-au efectuat n toate cazurile) baza de date devine incoerent i, ca urmare, trebuie avut n vedere un mecanism care s anuleze toate modificrile efectuate n cadrul tranzaciei i s aduc baza de date n ultima stare coerent anterioar nceperii tranzaciei. 4. Asigurarea serviciilor de control concurente
32
BAZE DE DATE
Sistemul de gestiune al bazei de date trebuie s garanteze c nu vor avea loc interferene atunci cnd mai muli utilizatori acceseaz baza de date.
33
BAZE DE DATE
5. Asigurarea serviciilor de reconstituire n cazul n care n timpul funcionrii sistemului au avut loc defeciuni de natur hardware sau software, acesta trebuie readus ntr-o stare coerent. 6. Asigurarea serviciilor de autorizare n cazul n care n timpul funcionrii utilizatorii ncearc intenionat sau accidental s acceseze date pe care nu au dreptul s le prelucreze, sistemul de gestiune al bazei de date trebuie s intervin. 7. Asigurarea unui suport pentru comunicarea datelor Utilizatorii trebuie s poat accesa o baz de date centralizat de la locaii aflate la distan. 8. Asigurarea serviciilor de integritate Integritatea bazei de date se refer la corectitudinea i coerena datelor stocate i se exprim sub forma unor constrngeri care reprezint regulile de coeren pe care baza de date nu are voie s le ncalce. 9. Asigurarea serviciilor pentru promovarea independenei de date Independena de date este obinut printr-un mecanism de vedere sau subschem. Completa independen logic de date este dificil de obinut. De obicei se pot aduga entiti, atribute, relaii, dar eliminarea lor nu este ntotdeauna posibil. 10. Asigurarea de servicii utilitare Serviciile utilitare ajut la administrarea bazei de date. Cteva astfel de exemple sunt urmtoarele: - faciliti de import; - faciliti de monitorizare, pentru urmrirea utilizrii; - programe de analiz statistic; - faciliti de reorganizare a indecilor; - compactarea i realocarea spaiului eliberat prin ndeprtarea unor nregistrri din dispozitivele de stocare.
2. Modelarea datelor
2.1. Modele de date: reea, ierarhice, relaionale, obiectuale, hibrid naintea construirii unei baze de date este necesar elaborarea unui model de date utilizat pentru reprezentarea datelor. Un astfel de model se dovedete a fi de mare ajutor la nelegerea datelor i la luarea celor mai bune decizii de proiectare n cadrul modelului fizic. Un model este o abstractizare i o structur ce simbolizeaz toate caracteristicile entitilor eseniale ce prezint interes pentru utilizator, o reprezentare i o reflectare a lumii reale (Universul Discursului). Un model de date reprezint o colecie integrat de concepte necesare descrierii datelor, relaiilor dintre ele, precum i a constrngerilor asupra datelor (Connolly .a. 1998). Modelul de date este utilizat la descrierea schemei bazei de date, definind structura datelor, legturile dintre acestea, semantica lor, precum i constrngerile impuse, dei nu este obligatoriu ca ntotdeauna acestea s fie regsite n orice model de date. Pe scurt, un model de date este utilizat pentru a reprezenta date despre date. Modelele de date ofer nelegerea descriptiv necesar definirii schemelor logice i externe i sunt utile descrierii formale a schemei bazei de date. Schema logic a unei baze de date reprezint o descriere abstract a unei poriuni din realitatea modelat mpreun cu instanele bazei de date. Un model de date este alctuit din trei elemente de baz: 34
BAZE DE DATE entiti; atribute;
- relaii. O entitate reprezint un obiect sau concept din lumea real, cum ar fi de exemplu un student sau un curs descris n cadrul bazei de date. Un atribut reprezint acele caracteristici ce descriu aspecte sau condiii ale unei entiti, cum ar fi de exemplu numele studentului sau situaia acestuia. Relaia stabilit ntre dou sau mai multe entiti reprezint o interaciune ntre acele entiti, cum ar fi de exemplu asocierea dintre un student i cursul pe care l urmeaz. Aa cum artau Elmasri i Navathe, modelele de date ajut la nelegerea datelor asociate logic. 2.1.1. Istoricul bazelor de date n continuare se vor prezenta cteva dintre cele mai importante evenimente petrecute pe parcursul dezvoltrii bazelor de date. n anul 1961 Charles Bachman proiecteaz Integrated Data Store (IDS) predecesorul modelului reea. Spre sfritul anilor 60, IBM creeaz Information Management System: IMS bazat pe modelul ierarhic. Spre sfritul anilor 60, grupul CODASYL (Committee for Data System Languages) definete /standardizeaz modelul reea. n 1969 Edgar Codd cercettor la firma IBM construiete modelul relaional. n ani 70 apar SEQUEL (SQL), QBE; QUEL, System R (DB2), Ingres. n anul 1976, Peter Chen construiete modelul Entitate-Relaie. n anii 80 apar sistemele de gestiune a bazelor de date printre care: DB2, Oracle, Sybase, Informix, DBase, Paradox. n anul 1986 a fost definit primul standard SQL.
ntre anii 1990 i 2000 apar concepte precum OODB, ORDB (Postgres), Data Warehouse, OLAP, Data Mining, GIS, Mobile DB, Multimedia DB, Web DB, XML DB. Inabilitatea bazelor de date de a lucra eficient n cadrul fiierelor obinuite cu date ce implic utilizarea grupurilor repetitive de date a condus la dezvoltarea unei mari varieti de structuri de baze de date, numite de obicei i modele de baze de date. 2.1.2. Funciile modelelor Funciile modelelor sunt: 1. Reprezint obiecte, evenimente precum i asocierile dintre acestea. 2. Reprezint aspecte eseniale i inerente, ignornd proprietile accidentale. 3. Au n vedere ansamblul entitilor, atributelor i relaiilor dintre acestea. 4. Asigur regulile de baz i relaiile ce permit proiectanilor i utilizatorilor s comunice corect, fr ambiguiti. Un model de date este alctuit din urmtoarele componente: 1. Partea structural ce reprezint un set de reguli ce fundamenteaz baza de date. 35
BAZE DE DATE -
2. Partea de manipulare ce definete tipurile de operaii ce se pot efectua n baza de date: operaii utilizate pentru actualizarea sau regsirea datelor; - operaii utilizate pentru modificarea structurii bazei de date. 3. Set de reguli de integritate ce garanteaz faptul c datele sunt corecte. Exist trei modele de baze de date: 1. Modelul de date extern utilizat pentru a reprezenta vederea fiecrui utilizator, care mai este cunoscut i sub denumirea de Univers al Discursului. Acest model este reprezentat prin modelele de date bazate pe nregistrri. 2. Modelul de date conceptual care reprezint vederea logic independent de sistemul de gestiune al bazelor de date ales i reprezentat prin modelele de date bazate pe obiecte. 3. Modelul de date intern utilizat pentru ca schema conceptual s poat fi neleas de ctre sistemul de gestiune al bazei de date i reprezentat prin modelele de date fizice. Fiecare model de date are propria reprezentare a datelor, dar ntotdeauna un model este alctuit dintro intensie i o extensie. Extensia unei relaii se refer la setul curent de nregistrri pe care l conine. Acest set de nregistrri nu rmne acelai tot timpul existenei bazei de date, suferind diverse modificri, pe msura introducerii, actualizrii sau tergerii de date. Partea cu caracter permanent n cadrul unei baze de date o reprezint intensia sa sau schema bazei de date. Intensia bazei de date descrie structura tuplurilor unei relaii. Operaiile limbajului de manipulare a datelor pot fi efectuate numai n condiiile n care se cunoate aceast structur. Cu alte cuvinte intensia unei baze de date reprezint tipurile de entiti, fiind considerat a fi modelul conceptual al bazei de date, pe cnd extensia reprezint instanierile tipurilor de nregistrri corespunztoare tipurilor de entiti precum i legturile dintre acestea. 2.1.3. Modele de date bazate pe nregistrri Astfel de modele descriu datele la nivel conceptual. Spre deosebire de modelele orientate pe obiecte, acestea sunt folosite cu scopul de a specifica structura logic general a bazei de date i de a oferi un nivel ridicat al descrierii implementrii. Modelele sunt denumite n acest fel deoarece baza de date este alctuit din nregistrri de acelai tip. Fiecare tip de nregistrare are un numr fix de cmpuri, fiecare cmp avnd, de obicei, o lungime fix, ceea ce duce la simplificarea reprezentrii. Aceste modele nu ofer un mecanism de reprezentare direct a codului din baza de date. Pentru a efectua interogri i actualizri asupra bazei de date se folosesc o serie de limbaje individuale separate asociate modelului. Din aceast categorie de modele fac parte: modelul de date ierarhic; modelul de date reea;
- modelul de date relaional. Astzi, datorit dezvoltrii fr precedent a Internetului, din ce n ce mai mult, se impune un alt tip de model, modelul de date semi-structurat, n format XML.
Modelul ierarhic
Din punct de vedere istoric, acesta a fost primul model de date ce a fundamentat un sistem de gestiune al bazelor de date i a fost dezvoltat de ctre firma IBM pentru produsul su IMS care utiliza limbajul DL/1. Rdcina
Printe Copil
36 Copil
Printe Copil
BAZE DE DATE
Modelul ierarhic lucreaz cu grupuri repetitive prin utilizarea unei structuri de date ce se bazeaz pe parcurgerea de sus n jos a unui arbore: datele aflate n nregistrrile primare reprezint ramurile arborelui, n timp ce datele ce formeaz grupurile repetitive reprezint frunzele acestuia. Avantajul modelului ierarhic este acela c metodele folosite la regsirea nregistrrilor asociate din baza de date sunt mai simple dect cele folosite n modelul reea. Intensia modelului de date ierarhic este reprezentat cu ajutorul unui arbore de definiie ce reprezint o diagram a structurii de date n care sensul legturilor funcionale este ntotdeauna de la nodul printe ctre nodul copil. O astfel de diagram este un graf orientat alctuit cu scopul reprezentrii tipurilor de entiti i a relaiilor dintre acestea. Nodurile grafului corespund tipurilor de entiti, iar arcele grafului reprezint legturile funcionale dintre tipurile de entiti. Extensia modelului de date ierarhic se reprezint sub forma unui tabel n care fiecare linie a tabelului este o nregistrare ce corespunde unei instanieri a tipului de entitate. n tabele sunt permise duplicatele i, prin urmare, pot exista dou instanieri identice ale aceluiai tip de entitate. Un singur tabel din baza de date are rolul de rdcin a arborelui n timp ce restul tabelelor formeaz mulimea prinilor i copiilor arborelui. Figura 2.1. Modelul ierahic O relaie ntr-o baz de date ierarhic este reprezentat prin intermediul perechii printe/copil. n acest tip de relaie, tabelul printe poate fi asociat cu unul sau mai multe tabele copil, dar un singur tabel copil poate fi asociat doar cu un singur tabel printe. Aceste tabele sunt asociate n mod explicit cu ajutorul unor pointeri sau pe baza unui aranjament fizic al nregistrrilor n tabele. Utilizatorul acceseaz datele pornind din rdcina arborelui i parcurge un anumit drum unic pn ajunge la datele cutate. O astfel de metod de acces cere utilizatorului o foarte bun cunoatere a structurii bazei de date. Un avantaj al utilizrii bazelor de date ierarhice este acela c utilizatorul poate extrage datele foarte rapid datorit legturilor explicite definite n structura tabelelor. Un alt avantaj este acela c integritatea referenial se obine prin crearea structurii i nu poate fi nclcat, ceea ce face ca o nregistrare din tabelul copil s fie obligatoriu asociat unei nregistrri existente n tabelul printe, iar o nregistrare tears din tabelul printe s impun eliminarea tuturor nregistrrilor asociate din tabelul copil. Probleme deosebite vor apare n momentul n care utilizatorul dorete s introduc o nregistrare n tabelul copil care nu are asocieri cu nici o nregistrare din tabelul printe. Acest tip de baz de date nu poate suporta asocierile complexe i, de aceea, deseori sunt probleme referitoare la redundana datelor, deoarece este posibil s-i fie permis introducerea de date inconsistente. Aceast problem poate fi ns rezolvat prin crearea a dou baze de date pentru a nlocui tipurile de relaii muli-lamuli, aa cum se prezint n figura de mai jos:
Relaie logic copil Baza de date 1 Baza de date 2
Figura 2.2. Rezolvarea relaiilor muli-la-muli Dei bazele de date ierarhice ofereau un acces direct i rapid la date, dovedindu-i superioritatea ntr-o multitudine de situaii specifice, devenise evident c era necesar introducerea unui nou model de 37
BAZE DE DATE
date pentru a remedia problemele tot mai presante referitoare la redundana datelor i la rezolvarea asocierilor complexe dintre nregistrri.
Modelul reea
Modelul reea a fost creat, n special, ca o ncercare de a rezolva unele dintre problemele modelului ierarhic. Nod proprietar 1 Set structura M Nod membru Figura 2.3. Modelul reea Aa cum se poate observa din figura 2.3., structura unei baze de date de tip reea se poate reprezenta cu ajutorul conceptelor de noduri i seturi. Un nod reprezint o colecie de nregistrri, n timp ce un set stabilete i reprezint relaiile din cadrul unei bazei de date de tip reea. O astfel de construcie transparent relaioneaz o pereche de noduri prin utilizarea unuia dintre ele sub denumirea de proprietar, iar a celuilalt sub denumirea de membru. Structura de tip set este o construcie ce stabilete i reprezint o relaie din cadrul bazei de date reea (reprezint o mbuntire remarcabil fa de relaia printe/copil). O astfel de structur suport o relaie de unu-la-muli, ceea ce nseamn faptul c o nregistrare din nodul proprietar poate fi relaionat cu una sau mai multe nregistrri aparintoare nodului membru, dar unei singure nregistrri din nodul membru i este asociat o singur nregistrare din nodul proprietar. Mai mult dect att, o nregistrare aparintoare nodului membru nu poate exista fr s fie asociat unei nregistrri existente n nodul proprietar. ntre o pereche de noduri se pot defini unul sau mai multe seturi, iar un singur nod poate fi implicat n seturi cu alte noduri din baza de date. Utilizatorul poate accesa date din cadrul unei baze de date de tip reea prin cea mai potrivit structur de seturi. Spre deosebire de bazele de date ierarhice, n care accesul trebuie s nceap cu nodul rdcin, n bazele de date de tip reea utilizatorul poate accesa datele indiferent de nod pe baza structurilor de tip set. CODASYL a dezvoltat limbajul Common Business-Oriented Language (COBOL) pentru a scrie aplicaii ce folosesc datele din bazele de date de tip reea. Cu toate dezavantajele pe care le are, modelul de baze de date propus de CODASYL mai are i astzi o larg rspndire n ntreaga lume. Bazele de date CODASYL folosesc n locul termenului de tabel, termenul de tip de nregistrare, dar caracteristicile acestuia nu difer cu nimic fa de cele ale unui tabel. Tipurile de nregistrri conin pointeri la nregistrrile provenite din alte tipuri de nregistrri. Un pointer este o valoare ce specific locaia unei nregistrri ntr-un fiier sau n memorie. De exemplu, nregistrarea ce conine date referitoare la un student, conine un pointer la o not a acestuia, care n replic va conine un pointer la o alt not ce aparine acelui student, .a.m.d. Termenul generic utilizat la descrierea tipurilor de nregistrri bazate pe pointeri este lista de legtur. Pointerii asociaz nregistrrile ntr-o structur organizat, numit reea. Bazele de date de tip reea au performane excelente n cazul regsirii seturilor de nregistrri ce aparin unui anumit obiect, deoarece relaiile dintre nregistrri (pointeri) reprezint parte constitutiv a bazei de date. n acelai timp, se permite utilizatorilor crearea de interogri mult mai complexe dect cele ce se pot elabora prin intermediul bazelor de date ierarhice, dar viteza bazelor de date de tip reea scade atunci cnd se dorete cutarea nregistrrilor pe baza unor criterii specificate. Principalul 38
BAZE DE DATE
dezavantaj al acestui tip de baze de date este legat de faptul c utilizatorul este obligat s cunoasc foarte bine structura bazei de date pentru a se putea descurca cu structurile de seturi. Totodat, aplicaiile ce lucreaz cu astfel de baze de date (n principal programele COBOL) trebuie s actualizeze att valorile datelor ct i pointerii nregistrrilor ce se adaug, terg sau se modific. Necesitatea actualizrii secveniale att a datelor ct i a pointerilor duce la creterea complexitii proceselor n care sunt implicate tranzacii. Un alt dezavantaj este acela c nu este uoar modificarea structurii bazei de date fr a afecta programele aplicaie care lucreaz cu aceasta. Deoarece, aa cum s-a artat, o relaie este definit n mod explicit sub forma unei structuri de tip set, aceasta nu poate fi modificat fr a afecta programele aplicaie ce folosesc aceast structur la cutarea datelor. Dac se modific o astfel de structur, trebuie modificate n mod corespunztor toate asocierile acesteia definite n programele aplicaie. Intensia modelului de baze de date de tip reea este un graf cu arce numerotate pentru a indica drumul ce trebuie parcurs, deoarece un tip de entitate copil poate fi conectat la mai multe tipuri de entiti printe sau la acelai tip de entitate printe prin mai multe arce. Extensia acestui model este un tabel ce permite introducerea de nregistrri duplicat, dar nregistrrile pot fi ordonate.
Modelul relaional
Acesta este cel mai folosit model de date folosit astzi n ntreaga lume, fiind un model de tip entitaterelaie bazat pe elaborarea unui model conceptual. Modelul relaional al unei baze de date permite extinderea bazelor de date la nivelul calculatoarelor personale nemaifiind obligatorie utilizarea echipamentelor costisitoare cerute de minicalculatoare sau de calculatoarele de tip mainfraime. Modelul a fost dezvoltat de ctre Dr. E. F. Codd de la San Jose Research Laboratories ce aparineau firmei IBM n anul 1970. Cele mai importante caracteristici ale modelului relaional sunt simplitatea, suportul teoretic solid, precum i cele trei elemente componente de baz. Un astfel de model este simplu deoarece el poate fi descris cu ajutorul unui numr mic de concepte care se refer la relaii (structuri de date bidimensionale ce au proprieti speciale), rnduri (datele aflate n cadrul relaiilor), coloane (cmpurile datelor din rndurile corespunztoare) i chei (mecanismul de identificare i asociere a rndurilor aflate n unul sau mai multe tabele). Modelul relaional are un suport teoretic foarte solid deoarece se bazeaz pe teoria matematic a seturilor, ceea ce nseamn faptul c toate operaiile sunt ncheiate cu succes, iar rezultatele operaiilor sunt predictibile. Cele trei componente ale modelului relaional sunt: a. componenta de structur a datelor (relaii cu proprieti speciale); b. componenta de manipulare a datelor (operaii predefinite prin care tehnologia relaional folosete un optimizator inteligent pentru a gsi calea de acces la date); c. componenta de integritate a datelor (reguli necesare proteciei datelor la efectuarea unor operaii incorecte). Principalul avantaj al modelului relaional este acela c nu este necesar utilizarea att a pointerilor ct i a datelor n cadrul tabelelor, folosind n schimb relaii pentru a accesa valori corespondente din mai multe tabele. O relaie const dintr-o asociere ntre nregistrrile aflate n dou tabele ce au aceleai valori ale atributelor. Deoarece tabelele relaionale nu conin pointeri, datele aflate n astfel de tabele sunt independente de metodele folosite de ctre sistemul de gestiune al datelor n lucrul cu nregistrrile tabelelor. Intensia modelului relaional este o schem relaional cu una sau mai multe scheme de relaie. Fiecare schem de relaie are propriul nume i propriile atribute. 39
BAZE DE DATE
Extensia modelului relaional este un tabel ce nu permite nregistrri duplicat. Fiecare schem de relaie introduce un tabel n schema relaional. Modelul de date relaional folosete tabele bidimensionale ce reprezint entitile i const din rnduri i coloane. O coloan reprezint un atribut al unei entiti ce mai poart i denumirea de cmp sau proprietate. Un rnd reprezint un tuplu care este o instan a unui tip de entitate sau de relaie sau orice altceva din baza de date. De obicei una dintre coloanele tabelului este numit cheie primar i are o valoare unic (Brown, The Relational Model). Simplitatea modelului bazei de date relaionale const din simplitatea conceptelor cu care opereaz: structuri simple i abstracte de date, independena fizic de date, cadrul puternic, general i realist oferit aplicaiilor .a.m.d. Modelul relaional ofer o interfa flexibil ce este prevzut cu cele mai potrivite componente necesare oricrui utilizator la toate nivelele, oferind o mare independen a datelor (produsul obinut este relativ independent de implementarea intern). Baza de date relaional const din unul sau mai multe relaii sau tabele. Principalele concepte ale modelului relaional sunt: 1. Atributul este o coloan ce are un nume propriu i unic ntr-o relaie (cmp). Fiecare relaie conine o list de atribute (sau coloane) definite pe un anumit domeniu. 2. Domeniul reprezint setul posibil de valori pe care l poate avea unul sau mai multe atribute. Utilizatorul poate defini domeniul de definiie, dar numai n anumite produse i poate defini propriile domenii. 3. Tuplu un rnd din cadrul unei relaii (nregistrare). Un rnd dintr-un tabel reprezint asocierea dintre seturile de valori. Fiecare relaie conine un set de tupluri (sau rnduri). 4. Intensia structura unei relaii mpreun cu specificaiile i constrngerile de domeniu aplicate. Se modific rar. 5. Extensia starea relaiei (valorile din cadrul unei relaii se pot modifica). Reprezint coninutul curent al bazei de date ce corespunde schemei bazei de date i se modific frecvent. 6. Gradul numrul de atribute dintr-o relaie. 7. Cardinalitatea numrul de tupluri dintr-o relaie. 8. Baza de date relaional reprezint o colecie de relaii ce pot fi modificate (tabele). O astfel de colecie este descris sub forma unui set de scheme de relaii din cadrul bazei de date, numite scheme relaionale ale bazei de date. Relaiile sunt alctuite din dou pri: instana un tabel cu rnduri i coloane; - schema specific numele relaiei mpreun cu numele i tipul fiecrei coloane. Termenul de relaie este folosit n sensul su matematic acceptat: Se d o schem de relaie R = r(A1, ..., An) pe un set de domenii {D1, D2..., Dn}. O relaie n-ar r reprezint un subset al produsului cartezian al acestor domenii: D1 x D2 x ... x Dn. Proprietile unei relaii sunt: relaiile sunt alctuite din rnduri i coloane; ntr-o relaie nu are importan ordinea de apariie a rndurilor sau coloanelor; ntre tabele nu exist o asociere explicit (nici una vizibil cuiva care acceseaz datele); fiecare nregistrare poate fi identificat n mod unic; fiecare rnd din cadrul unui tabel are acelai set de coloane;
- fiecare coloan are un singur tip de dat (nu sunt acceptate redefiniri pentru diferite valori). Datorit acestor proprieti i a fundamentului matematic, modelul relaional permite proiectanilor concentrarea mai nti asupra semanticii datelor i a relaiilor dintre ele i abia apoi asupra 40
BAZE DE DATE
implementarii fizice a semanticii respective pentru a se adapta ct mai bine cerinelor i specificaiilor impuse. 2.1.4. Modele logice orientate pe obiecte Descriu datele la nivelele conceptual i extern oferind o flexibilitate ridicat. Astfel de modele pot specifica n mod explicit constrngerile aplicate datelor i se bazeaz pe urmtoarele concepte: - entitate un obiect sau concept din lumea real ce are identitate proprie; - atribut un set de proprieti utilizate la descrierea entitilor; - relaie o asociere ntre dou sau mai multe entiti. Din aceast categorie fac parte: a. modelul entitate-relaie; b. modelul orientat pe obiecte; c. modelul obiectual-relaional; d. modelul binar; e. modelul semantic de date; f. modelul infologic; g. modelul funcional de date. Dintre acestea se remarc modelele urmtoare:
Modelul entitate-relaie
Se bazeaz pe o percepie a lumii reale ca fiind alctuit dintr-o colecie de obiecte de baz sau concepte (entiti) mpreun cu relaiile care se stabilesc ntre ele. Fiecare entitate are asociat un set de atribute care o descriu, iar o relaie reprezint o asociere dintre dou sau mai multe entiti. Mulimile tuturor entitilor sau relaiilor de acelai tip sunt cunoscute sub denumirea de tipuri de entiti sau relaii. Un alt element important n cadrul diagramelor entitate-relaie l reprezint precizarea constrngerilor de cardinalitate care exprim numrul de entiti asociate altui tip de entitate prin intermediul unui tip de relaie.
Modelul orientat pe obiecte

Un astfel de model este utilizat doar n scopuri speciale, cele mai cunoscute produse de acest tip fiind: ObjectStore, Gemstone, Ontos, O2, Jasmine, Cache. Modelul se bazeaz pe o colecie de obiecte, la fel ca n cazul modelului entitate-relaie. Un obiect conine valorile nmagazinate n cadrul unor variabile instaniate n interiorul acestor obiecte. Spre deosebire de modelul entitate-relaie, valorile sunt ele nsele obiecte. Astfel de obiecte conin alte obiecte imbricate pn la un nivel oarecare. Obiectul mai conine elemente de cod ce opereaz asupra acestuia i care se numesc metode. Obiectele ce conin acelai tip de valori i aceleai metode sunt grupate n clase. O clas poate fi interpretat ca fiind definiia de tip a obiectului respectiv. Singura modalitate prin care un obiect poate accesa datele altui obiect este prin invocarea metodelor acelui obiect, ceea ce este cunoscut sub numele de trimitere de mesaje ctre obiectul respectiv. Prile interne ale obiectului respectiv, variabilele i metodele, nu sunt vizibile n exterior, obinnduse astfel dou nivele de abstractizare a datelor. Spre deosebire de entitile din modelul entitaterelaie, fiecare obiect are un identificator unic indiferent de valorile pe care le conine. Dou obiecte ce au aceleai valori sunt distincte (polimorfism). Distincia se menine i la nivelul fizic prin atribuirea unui identificator unic al obiectului respectiv. Modelul orientat pe obiecte are toate caracteristicile limbajului de programare orientat pe obiecte, fcnd ca modelul relaional s fie cobort la stadiul de depozit de date. Esenial pentru un astfel de model este faptul c proiectantul bazei de date poate opera cu fiecare element al bazei de date, inclusiv cu setul de operaii ce manipuleaz datele din cadrul bazei de date n cadrul aplicaiei scrise ntr-un limbaj orientat pe obiecte. 41
BAZE DE DATE
De aceast dat ns nu mai exist o separare clar ntre date i aplicaie. Spre deosebire de modelul relaional, care are un suport teoretic extrem de solid, modelul orientat pe obiecte nu prezint o astfel de caracteristic, ceea ce face s nu existe un consens n definirea lor. Totui, organizaia OMG (Object Management Group) a depus mari eforturi, reuind s propun un model ce a devenit standard pentru toate sistemele de gestiune a bazelor de date orientate pe obiecte.
Modelul obiectual-relaional
Acest model (cunoscut iniial sub numele de model de date relaional extins) a extins modelul relaional prin introducerea unor serii de elemente i caracteristici specifice modelului obiectual, cum ar fi: clase, ncapsulare, motenire. Cele mai cunoscute produse de pe pia sunt: Postgres, Informix, DB2, Oracle. Scopul acestei extinderi a fost acela de a permite bazelor de date relaionale s opereze cu tipuri complexe de date, cum ar fi: imagini audio, video, elemente de proiectare. Modelul se afl nc la stadiul incipient de dezvoltare, chiar dac este promovat de cei mai mari productori de pe pia de produse de baze de date. 2.1.5. Modele fizice de date Sunt modele utilizate la descrierea datelor la cel mai de jos nivel. Ele conin informaii despre structura nregistrrilor, ordinea nregistrrilor, precum i cile de acces la date. Din aceast categorie fac parte: - modelul unificat al datelor; - memoria cadru. 2.1.6. Avantajele bazelor de date relaionale Sunt urmtoarele: - Integritate ncorporat la mai multe nivele. Integritatea datelor este integrat n cadrul modelului la nivel de cmp pentru a asigura precizia datelor. La nivel de tabel asigur faptul c o nregistrare nu mai poate fi introdus nc o dat n baza de date, precum i detectarea lipsei valorilor din cmpurile cheie primar. La nivel de relaie asigur validitatea acestora ntre tabele. La nivel logic, asigur acurateea logic a datelor. - Independena logic i fizic a datelor de programele aplicaie: nici modificrile efectuate de ctre utilizator modelului logic al bazei de date, nici modificrile efectuate de ctre productorul bazei de date implementrii fizice a acesteia, nu vor afecta programele aplicaiilor care utilizeaz baza de date. - Garanteaz consistena i precizia datelor: datele sunt consistente i precise datorit multiplelor nivele de integritate ce pot fi introduse n baza de date. - Extragerea cu uurin a datelor din baza de date. n urma comenzilor introduse de ctre utilizator, datele din baza de date pot fi extrase fie dintr-un singur tabel, fie dintr-o multitudine de tabele asociate prin intermediul relaiilor, ceea ce ofer posibilitatea prezentrii datelor ntr-un numr nelimitat de moduri. Acestea i alte avantaje au adus beneficii extrem de importante comunitii de afaceri i tuturor acelora care au nevoie de colectarea i nmagazinarea de date. Deocamdat, bazele de date relaionale dein supremaia pe piaa acestor produse, fiind alese n cele mai multe dintre cazuri. Pn de curnd, cel mai mare dezavantaj al bazelor de date relaionale l reprezenta faptul c programele aplicaie care le foloseau erau foarte lente n execuie. Problema nu era una a bazelor de date relaionale, ci tehnologiei deficitare de care se dispunea la momentul introducerii modelului. ncepnd cu anii 90 paii nainte fcui att n domeniul hardware ct i software au fcut ca o astfel de problem s fie din ce n ce mai puin vizibil.
42
BAZE DE DATE 2.1.7. Chei
O cheie este un cmp ce are o valoare unic, corespunztoare fiecrei nregistrri dintr-un tabel. Sunt mai multe tipuri de chei, fiecare avnd propriile caracteristici.
2.1.7.1. Cheia candidat

Este un atribut sau un set de atribute ce identific n mod unic un tuplu dintr-un tabel.
2.1.7.2. Cheia primar

Reprezint una dintre cheile candidat desemnate n cadrul unui tabel. Orice tabel trebuie s aiba o cheie primar. O cheie primar trebuie s fie: 1. Stabil. Valoarea unei chei primare nu trebuie s se modifice sau s devin nul pe tot parcursul existenei unei entiti (Brooks, 1992). O cheie primar stabil ajut la pstrarea unui model stabil (Whitener, 1989). De exemplu, dac se analizeaz nregistrarea datelor unui student, valoarea cheii primare nu trebuie s se modifice n timp, aa cum se ntmpl cu valorile din cmpul n care se pstreaz vrsta acestuia. 2. Minimal. Cheia primar trebuie s fie alctuit dintr-un numr minim de cmpuri ce sunt capabile s asigure unicitatea. 3. Centrat pe date, nu pe informaii. Nu trebuie s apar grupri de caracteristici n cadrul unei valori a unei chei ce pstreaz meta-informaii adiionale, deoarece nu se respect principiul atomicitii atributelor, crescnd astfel posibilitatea ca valorile cheii primare s se modifice. 4. Definitiv. n momentul introducerii unei noi nregistrri, trebuie s existe posibilitatea introducerii unei valori. Cheia primar acioneaz ca un mecanism de constrngere suplimentar a entitii deoarece nu poate fi introdus o instan a unui tip de entitate dac aceasta nu are o valoare permis n cheia primar. 5. Accesibil. Oricine dorete s creeze, citeasc, sau tearg o nregistrare trebuie s poat vizualiza valoarea cheii primare (Whitener, 1989).
2.1.7.3. Cheie alternativ

Este o cheie candidat ce nu a fost desemnat drept cheie primar. Ea poate deveni cheie primar dac cheia primar aleas iniial nu mai corespunde la un moment dat.
2.1.7.4. Cheie extern

Exist doar n situaia n care se stabilesc dou sau mai multe relaii ntre tabelele bazei de date. Un atribut al unui tabel trebuie s existe i n cellalt tabel legat de primul printr-o relaie.
2.2. Modele arhitecturale: mainframe, integrate, file-server, client-server, distribuite

2.2.1. Introducere
De mult timp se cocheta cu ideea crerii unei baze de date universale, adic o baz de date care s conin informaii din ct mai multe domenii i care s poat fi accesat de un numr ct mai mare de persoane. Pn cu puin timp n urm acest ideal se meninea n domeniul viselor. Odat cu apariia a ceea ce numim astzi World Wide Web un astfel de vis a devenit realitate. nc din cele mai vechi timpuri oamenii au avut nevoie de informaii. O dat cu informaia a aprut i necesitatea schimbului de informaii. Pentru aceasta era nevoie de un suport material care s stocheze 43
BAZE DE DATE
informaia i s o transmit mai departe. S-a nceput cu cioplirea informaiilor n piatr i s-a continuat cu alte i alte soluii pn n zilele noastre, cnd asistm la decderea unui suport (hrtia) i ridicarea altuia (suportul electromagnetic). Odat cu evoluia omenirii, informaia a crescut ca dimensiune, punndu-se, prin urmare, problema stocrii unei mari cantiti de date. De asemenea, o alt problem este regsirea informaiei i, odat cu aceasta, rapiditatea obinerii rezultatului. nc din zorii civilizaiei IT s-a observat c - pe lng calculele ce erau preponderente n tehnologia informatic embrionar - computerele s-ar preta i la nmagazinarea i exploatarea volumelor mari de informaii. Astfel, ncepnd cu anul 1948 s-au fcut mai multe studii, cercetri i experimente privind stocarea datelor, iar de-a lungul timpului s-au manifestat mai multe modele, arhitecturi i tehnologii privind bazele de date. Acceptnd un punct de vedere oarecum teoretic, fr ns a intra in detalii aride, vom trece in revist principalele modele de concepie i organizare a bazelor de date, dup care ne vom ocupa de arhitecturile de implementare a sistemelor de gestiune a bazelor de date (SGBD).
2.2.2. Istoric
Pn spre anii 80 contau doar mainframe-urile, minisistemele i supercomputerele, bazele de date fiind foarte mari (rspunznd unor cerine dure impuse de beneficiari pretenioi, pentru c doar acetia aveau puterea financiar de a achiziiona tehnica motivat de probleme complexe i critice este uor s ne imaginm baze de date referindu-se la sute de mii sau milioane de entiti). Tendinele forau mereu limite, iar de aici derivau problematici provocatoare privind performana, accesibilitatea i mentenabilitatea. Prin anii 70, modelul relaional s-a cristalizat ca soluie viabil, iar lupta concurenial dintre marii juctori de pe piaa bazelor de date se va da pn in vremea noastr pe arena SGBDR i SQL. Mult timp modelul de organizare centralizat (datele sunt depozitate pe un sistem central de unde utilizatorii le acceseaz) a raspuns cel mai bine cerinelor de exploatare a bazelor de date. i astzi pentru aproape orice mediu departamental (sau grup de lucru) organizarea centralizat a informaiilor - i nu ne referim neaprat la baze de date (de exemplu, sistemele de gestiune i control al circulaiei documentelor - unde documentele pot fi orice: documentaii, proiecte, desene CAD, arhive etc.) constituie o prim opiune. Odat cu rspndirea i dezvoltarea calculatoarelor s-au deschis i orizonturile, iar ca o prima tendin s-a dovedit necesitatea descentralizrii i interoperrii. Proliferarea diverselor platforme (hardware i/sau sisteme de operare) au forat definirea de standarde de schimb de date i de comunicaii, precum i dezvoltarea reelelor eterogene. Iar pentru c lucrurile se ntmplau odat cu afluxul calculatoarelor personale, inevitabil programatorii s-au gndit la ceva intre SGBD i spreadsheet, iar de aici la apariia unor baze de date desktop de genul lui dBASE n-a fost dect pasul materializrii. Evoluia ramurii desktop a bazelor de date s-a fcut in paralel cu mainstream-ul, dar influenndu-se reciproc. Cele mai evidente tendine se pot descrie pe scurt astfel: bazele de date mici doreau s-i dezvolte funcionaliti de sistem relaional (s poat defini relaii i s ncorporeze SQL) i s-i extind limitele, iar cele mari i-au aplecat atenia asupra accesibilitii, materializat prin interfee utilizator facile chiar i pentru activitile administrative (o interfa de calitate ajunge deseori un argument de pia).
2.2.3. Modelul mainframe

Modelul centralizat iniial presupunea c baza de date este organizat i stocat integral pe un sistem performant (denumit mainframe, sistem sau minisistem n funcie de criterii hardware) de unde poate fi accesat de mai multe console utilizator (terminale de acces cu putere de calcul redus conectate la calculatorul central) prin intermediul unor aplicaii de exploatare rezidente tot pe mainframe. Modelul s-a dovedit performant i sigur att n implementare, ct i n utilizare, dar au existat i cteva puncte sensibile. Problema delicat la mainframe-uri nu este numrul de utilizatori suportai 44
BAZE DE DATE
(cum am fi tentai s credem), ci faptul c aplicaiile au o infrastructur rigida, a cror extindere determin implicaii dure de organizare i administrare, pe lng creterile nedorite ale traficului de date prin reea. Extincia dinozaurilor n-a fost deloc complet: muli nc mai fac fa aplicaiilor critice (care nici nu pot fi ntrerupte fr pierderi), iar interoperabilitatea cu arhitecturile moderne nu-i incomodeaz deloc, ba parca-i retriesc o a doua tineree...
2.2.4. Modelul integrat

Un mediu software independent, instalat pe un singur calculator, include att baza de date propriuzis, ct i interfaa de acces la date (un prim exemplu de astfel de mediu integrat este dBASE), astfel c singurul utilizator va fi beneficiarul. Accesarea datelor se face fie printr-un limbaj de generaia IV (4GL) sau printr-un macrolimbaj, fie prin elemente de interfa (comenzi la prompter, dialoguri QBE, comenzi menu). Datele fiind organizate tabelar, exista posibilitatea de a proiecta aplicaii relaionale. Uzual, astfel de medii ngduie dezvoltarea de aplicaii nerelaionale, ceea ce se mai numete i organizare plat sau bidimensional, spre deosebire de organizarea relaional, care este multidimensional (atenie, exist pericolul confuziei cu denumirea de baza de date multidimensional care corespunde uzual domeniului date warehouse sau aplicaiilor DSS - decision support system - i OLAP - On-Line Analytical Processing, deservind analize economice necesare deciziilor manageriale, adic extragerii ad-hoc de informaii sintetice, unde dimensionalitatea are un caracter mai abstract i mai dinamic i nu contravine modului de stocare). ntr-un sistem nerelaional (revenind la mediul independent), datele care altfel s-ar preta organizrii n nomenclatoare (tabele cu nregistrri unice, legate de celelalte tabele prin relaii unu-la-n) cunosc un grad excesiv de redundan, iar actualizarea lor presupune un efort considerabil. (Redundana datelor, adic faptul c baza de date conine aceleai date stocate de mai multe ori, ridic att problema spaiului ocupat, ct mai ales dificultatea asigurrii consistenei si actualitii).
2.2.4.3. Modelul File-server

n sistemele de gestiune a bazelor de date folosite astzi, se ntlnesc dou concepte ce definesc modul de acces al clienilor la o baz de date centralizat. Primul este conceptul file-server n care serverul lucreaz numai cu fiierele de date, fiind impropriu ca aplicaia s cear un transfer de date. Cel de-al doilea concept este modelul client-server, n care serverul nelege natura datelor cerute, fiind pregtit s execute astfel de cereri. Soluia oferit de modelul file-server implic utilizarea unui server de fiiere centralizat aflat undeva pe o reea, care pune la dispoziia clientului uniti de disc logic cu fiiere partajate. Serverul de fiiere nu are cunotine despre cererile logice care se prelucreaz, dar acioneaz sub forma unui disc ce poate fi accesat prin intermediul unei reele pentru a transfera date de la/spre client. Toate aplicaiile ruleaz la client. Exemple de astfel de produse sunt FoxPro, dBase, MS Access. O baz de date de acest tip are o fiabilitate foarte sczut deoarece ea se pstreaz sub forma unui fiier ntr-un sistem de fiiere, fiind uor de distrus dac se produce o eroare n timpul unei prelucrri sau a unei pierderi de conexiune n timpul efecturii unei tranzacii.
2.2.4.4. Modelul Client-server

n modelul client-server avem de a face cu o baz de date centralizat care prelucreaz cererile logice provenite de la client. Un astfel de server nelege att natura cererii ct i structura i localizarea datelor, majoritatea calculelor fiind efectuate de motorul bazei de date. Clientul are doar o interfa grafic cu care poate accesa baza de date de pe server, folosind aplicaii pentru a transmite comenzi SQL serverului bazei de date, rezultatele fiind primite sub form de tabele. Exemple de astfel de produse sunt: ORACLE, SQL Server, DB2, Sybase i Informix. Prin 45
BAZE DE DATE
inerea sub control, de ctre un server, a tuturor fiierelor bazelor de date, arhitectura client-server ofer o fiabilitate ridicat i o serie de alte caracteristici avantajoase ce nu pot fi oferite de arhitectura file-server, cum ar fi: 1. Copie de siguran ce poate fi creat n timpul lucrului prin utilizarea unui planificator automat ce face copii ale bazelor de date fr a fi necesar ntreruperea conexiunii cu utilizatorii. 2. Tranzacii sigure prin jurnalizarea tranzaciilor, astfel nct actualizrile efectuate prin intermediul unei tranzacii pot fi n orice moment refcute sau anulate, ajungndu-se astfel la ultima stare consistent anterioar nceperii tranzaciei respective, indiferent dac eroarea se produce la client sau la server. Dei motorul Microsoft Jet i fiierele .mdb ofer posibilitatea efecturii de tranzacii, acestea nu sunt gestionate prin intermediul unui jurnal separat, iar datele pot fi distruse fr a mai fi posibil refacerea lor. 3. Fiabilitate i protecie sporit a datelor. O baz de date n model file-server poate fi reparat, n cazul apariiei unei erori, dar n acest caz utilizatorul trebuie deconectat, lucru care se ntmpl foarte rar n cazul modelului client-server. 4. Procesarea mai rapid a interogrilor. Dac se folosete un fiier .mdb prin intermediul unei reele, trebuie ncrcat motorul Jet al bazei de date la clientul la care se face cererea de prelucrare. n acest fel traficul pe reea este foarte mare, fiind necesar transportul unei mari cantiti de date, mai ales atunci cnd baza de date este foarte mare. n cazul modelului client-server, prelucrrile se efectueaz direct pe server, care de obicei, este mult mai performant dect maina clientului. Prelucrarea pe server duce la o ncrcare mult mai mare a acestuia dect n cazul modelului fileserver, dar traficul pe reea va fi substanial sczut. Prezentnd un exemplu cu 5 utilizatori, se constat faptul c n situaia modelului file-server este posibil blocarea reelei, deoarece toate bazele de date trebuie aduse pe calculatorul local. Din acest motiv, atunci cnd utilizatorii pun ntrebri complexe serverului se poate ca reeaua s nu mai fac fa solicitrilor. n concluzie, soluiile file-server nu sunt recomandate ntreprinderilor de mari dimensiuni sau aplicaiilor extinse, preferndu-se n acest caz soluia client-server care scade traficul de pe reea i asigur o fiabilitatea mult crescut a sistemelor. n acelai timp, suntem ispitii s credem, ca un reflex al superficialitii (acesta fiind unul dintre marile riscuri actuale ale informatizrii), c dac se implementeaz o baza de date ce depete - s zicem - un milion de nregistrri, baza de date desktop (mediu integrat) nu mai face fa i trebuie s ne orientam ctre un alt tip de SGBDR. Pentru operarea n regim monoutilizator lucrurile nu se prezint chiar aa: performanele (viteze de accesare i procesare a datelor) sunt ct se poate de comparabile dac este vorba de un hardware bine echilibrat (un PC care s suporte fr probleme un SGBDR mare va favoriza i baza de date integrat). n acest caz altele sunt criteriile care ne orienteaz catre SGBDR-uri mari organizate in model client/server: - operarea multiuser concurenial (considerat punctual, nici aici avantajele nu sunt nete deoarece un FoxPro/LAN cu file-server face fa onorabil); - descongestionarea traficului prin reea datorit transmiterii doar a datelor int (adic un minim); - controlul drepturilor utilizatorilor i monitorizarea activitii (conectare i aplicaii); - implementri unice de logic centralizat (reguli, proceduri, declanatoare - existente doar la nivelul serverului); - gestionarea tranzaciilor, aspect care devine capital/critic atunci cnd se administreaz un sistem complex de date distribuite sau un mediu OLTP (on-line transactions processing); ceva mai recent sub influena Internetului - tranzaciile au loc prin comunicaie asincron (conversaionala) sau chiar fr confirmare ("fire-and-forget); - serverul asigura integritatea, consistena i actualitatea datelor (propagri de actualizri prin mecanismele de integritate referenial); - optimizarea organizrii fizice a datelor (colaborarea la un nivel ct mai jos cu sistemul de operare i cu sistemul de fiiere) i optimizarea accesului la date. (Un exemplu de colaborare la nivel fizic este posibilitatea SGBD-urilor de a face duplicri ale datelor - copiile de siguran fiind unul dintre primele niveluri ale toleranei la defectri. Desigur ca i un LAN desktop - Novell, Windows NT poate face mirroring, ins nuanele difer.) 46
BAZE DE DATE
- recuperarea datelor n caz de blocare/cdere a sistemului i refacerea tranzaciilor neterminate; - jurnalizarea acceselor, tranzaciilor i a sesiunilor de lucru sau de administrare; - economicitatea upgrade-ului: ridicarea performanelor globale rezid n principal n creterea puterii calculatorului pe care ruleaz serverul bazei de date, privind mai puin calculatoarele client pe care se afla software-ul front-end etc. Client si server pot fi vzute i ca dou procesoare distincte rulnd pe maini diferite (mai rar pe aceeai main), bazate eventual (dar nu obligatoriu) pe acelai sistem de operare. Comunicaia prin care partea "client a aplicaiei solicit servicii prii server se face prin mesaje (message-passing), fiind complet transparent utilizatorului. Posturile de lucru pot fi uzual PC-uri, laptop-uri, staii UNIX sau Macintosh, iar serverul poate fi un mainframe, un server departamental sau chiar un PC bine dopat. Software-ul bazelor de date implementate prin arhitectura client/server se prezint generic astfel: SGBD-urile asigur partea de server, iar aplicaiile de exploatare a datelor se afl uzual la nivelul client (sculele de editare a aplicaiilor utilizator aparin de productorii SGBD-urilor implementate sau pot fi din familia celor bazate pe specificaii deschise: ODBC, JDBC, Embeded SQL, DCOM, OLE etc.). Repartizarea datelor i a aplicaiei (logicii) ntre straturile "client i "server nu este preimpusa, fiecare implementare fiind susceptibila de un optim. Arhitectura client/server dovedete suplee (modularitatea i scalabilitatea oferind disponibilitate crescut la reorganizri i extinderi) i deschidere (chiar se consider ca ea a aprut din necesitatea de a asigura o deschidere i interoperabilitate superioare modelului centralizat cu mainframe). Modelul client/server a fost i el susceptibil de perfecionri de principiu, iar una dintre cele mai interesante este impunerea de niveluri/straturi intermediare intre client i server (n-tier), ca raspuns la dilema legata de poziionarea programelor de aplicaie (logica de operare/afacere): care dintre pri trebuie sa fie mai "groase, clientul sau serverul? ntruct avantajele locale erau permanent necomplementare, s-a dezvoltat ideea unui strat intermediar, concretizat ntr-un server de aplicaii interpus ntre clientul subire i serverul bazei de date (middle-tier), ambele capete fiind astfel descongestionate de partea de logica. Interesant este i observaia unor analiti care asociau tendina modern de accentuare a clientului subire cu revenirea la modelul mainframe cu terminale "chioare. Oricum, cerinele actuale privind deschiderea mediilor informaionale determin diluarea graniei dintre modele, reelele eterogene fiind vzute ca soluia cea mai viabil de a menine echilibrul ntre permanentele inovaii i conservarea investiiilor anterioare. ns cele mai deranjante dezavantaje ale arhitecturii client/server deriv din complexitatea ei (cerine asupra personalului implicat: nelegerea conceptual a arhitecturii de ctre persoanele de decizie, precum i cunotine aprofundate pentru cei care implementeaz/dezvolt efectiv sistemul/aplicaiile) i din standardizarea insuficient. Majoritatea serviciilor Internetului se desfoar n regim client/server (banala navigare nseamn un utilizator accesnd datele dintr-un site-server prin intermediul unei aplicaii client, care este browserul de Web), astfel c devine natural implicarea SGBDR-urilor n aplicaii Internet (de genul e-business sau e-commerce). S ne imaginm urmtorul scenariu: un furnizor de produse i organizeaz un catalog de produse (magazin virtual) pe care utilizatorii l pot consulta prin navigatorul de acas. Lucrurile se desfoar prin pagina HTML pe care serverul de Internet o trimite clientului, la rndul ei respectiva pagina acionnd ca ablon (formular/form) de accesare a informaiilor comerciale din baza de date deservit de un server legat la site-server (cel mai frecvent baza de date conine i imagini dac nu chiar i alte date multimedia). Iar daca utilizatorul va comanda din produsele expuse completnd un formular din pagina Web (controlat printr-un script), se declaneaz o alt serie de comunicaii ntre client i server.
2.2.6. Baze de date distribuite

Adevratul sens al atributului "distribuit n contextul SGBD-urilor corespunde nu faptului c sistemul permite accesarea datelor de la distan (prin reea), ci acelor implementri care ngduie aplicaiilor i utilizatorilor s trateze baza de date ca pe un singur depozit logic chiar dac datele constituente sunt repartizate n mai multe locaii ale reelei (transparena complet a localizrii 47
BAZE DE DATE
datelor). Totui problema este delicat i pentru c - din punctul de vedere al analizei - se poate oricnd crea o aplicaie care s trateze unitar tabele de date situate pe calculatoare diferite. Dar pentru c adevrata baz de date se dorete independent de limbaje (sau de mediile de dezvoltare) sunt de apreciat acele SGBD-uri care conin integrate funcionaliti care s asigure distribuirea datelor n nodurile reelei. innd cont c de obicei volumul i complexitatea datelor spulber idealul "un computer foarte performant cumulnd ntreaga baza de date i deservind toi utilizatorii ntreprinderii/organizaiei i trebuie gsit o soluie de compromis, devine foarte interesant colecia de criterii practice de distribuire a datelor n cazul fiecrei implementri, particularitile cernd un optim jalonat de urmtoarele aspecte: - nu trebuie niciodat pierdut din vedere dezideratul vitezei; - limita de stocare i puterea calculatoarelor gazda; - limita de transfer a reelei; - preferabil ca fiecare aplicaie s acceseze uzual un singur depozit al bazei de date (fr a mpiedica accesarea cu frecven redusa a celorlalte noduri ale reelei); - folosirea funciilor two-phase-commit existente pentru a asigura integritatea datelor actualizate distribuit; - planificarea, controlul i minimizarea duplicrii de obiecte ale bazei de date; - corelarea organizrii cu facilitile de optimizare distribuit ale SGBD-ului. Cercetatorul Chris Date (coleg de proiecte cu E.F. Codd) a enunat cele 12 cerine ideale crora trebuie s li se supun bazele de date distribuite; dintre acestea 9 sunt urmtoarele: 0. Autonomia local: datele locale sunt deinute i administrate local - nici un post nu depinde de altele pentru a funciona. 1. Toate posturile sunt egale: nici un post nu se bazeaz pe o staie central. Funcionare nentrerupt: nu trebuie s fie necesar o oprire planificat (instalrile/tergerile efectuate la un post nu afecteaz funcionarea celorlalte). 2. Transparena amplasrii: utilizatorii nu sunt obligai s tie unde sunt amplasate datele pentru a le extrage. Transparena fragmentrii: relaiile dintre componentele bazei de date pot fi fragmentate pentru stocare, dar acest lucru rmne transparent pentru utilizator. 3. Transparena duplicrii: relaiile i fragmentele pot fi reprezentate fizic prin copii multiple stocate separat, dar transparent pentru utilizator. 4. Prelucrarea interogrilor distribuite: operaiile de citire/scriere se pot desfura la mai multe posturi, permind optimizarea locala i global a interogrilor. 5. Actualizrile distribuite: tranzaciile singulare pot executa codul la mai multe posturi. 6. Independena de hardware: toate calculatoarele particip ca membri egali. 7. Independena de sistemul de operare: sunt suportate mai multe sisteme de operare conectabile la reea. Independena de reea: sunt suportate mai multe reele prin protocoale comune. 8. Independena de bazele de date: se asigur accesul uniform (interfaare unic) pentru datele provenind din SGBD-uri diferite.
3.1. Bazele modelului relaional

Conceptul de baz de date introduce termenul de abstractizare a datelor prin mascarea fa de utilizator a detaliilor legate de tehnica de stocare a datelor n calculator. Principalul instrument folosit la realizarea acestui scop este modelul de date, care este alctuit dintr-un set de concepte ce pot fi utilizate la descrierea structurii bazei de date, cum ar fi de exemplu, tipurile de date, relaiile i constrngerile stabilite pentru datele reprezentate. Exist trei tipuri de modele de date: modelul de date conceptual, modelul de date logic i modelul de date fizic.
48
BAZE DE DATE
3.1.1. Modelul conceptual

Folosete o serie de concepte, cum ar fi entitate, relaie i atribut pentru a descrie ct mai fidel modul n care este perceput de ctre utilizator realitatea ce urmeaz a fi reprezentat n cadrul unei baze de date. Pentru a realiza un model conceptual ct mai corect se folosesc o serie de instrumente ce ajut n modelare, dintre care cel mai folosit este diagrama entitate-relaie. De obicei, proiectarea unui model conceptual respect urmtorul algoritm: Pasul 1. Identificarea tipurilor de entiti. Const din identificarea i documentarea principalelor tipuri de entiti din punct de vedere al beneficiarului bazei de date. n acest scop este necesar citirea cu atenie a tuturor specificaiilor i cerinelor acestuia, urmat de crearea unei liste a potenialelor tipuri de entiti. Tipurile de entiti reprezint obiectele sau conceptele ce prezint cel mai mare interes n cadrul sistemului. De obicei, se creeaz mai multe tipuri de entiti dect este necesar, urmnd ca ulterior s se recurg la o rafinare a acestora, eliminndu-se unele dintre ele. Pasul 2. Eliminarea tipurilor de entiti duplicat. n primul rnd trebuie s se obin asigurarea c, ntr-adevr, fiecare tip de entitate utilizat reprezint un tip distinct de entitate i nu nume diferite ale aceluiai tip de entitate. Este foarte important s nu se cad n capcana definirii unui tip de entitate care s reprezinte ntregul sistem. De exemplu, la modelarea unei biblioteci, tipurile de entiti pot fi crile, autorii, cititorii etc., dar n nici un caz nu poate fi definit un tip de entitate biblioteca deoarece aceasta reprezint ntregul sistem. Pasul 3. Identificarea tipurilor de relaii. n cadrul acestei etape se recurge la identificarea i documentarea celor mai importante tipuri de relaii ce se pot stabili ntre tipurile de entiti rmase dup parcurgerea pasului anterior. n acest scop se examineaz fiecare tip de entitate n parte pentru a putea determina poziia i legturile acesteia n cadrul sistemului. n acelai timp se face o analiz a cardinalitii i a participrii fiecrui tip de entitate, identificndu-se totodat constrngerile impuse tipurilor de entiti participante. Pasul 4. Identificarea i asocierea atributelor corespunztoare fiecrui tip de entitate sau relaie. n aceast etap trebuie obinut asigurarea c tipurile de entiti sunt cu adevrat necesare i nu sunt atribute ale altor tipuri de entiti. De exemplu, telefonul poate fi o entitate de sine stttoare sau un atribut exprimat sub forma unui numr de telefon atribuit tipului de entitate Studeni. Pasul 5. Stabilirea domeniilor de valori ale atributelor. Se realizeaz printr-o analiz amnunit a situaiilor ce pot apare, documentndu-se fiecare hotrre luat. Pasul 6. Stabilirea atributelor cheie candidat i primar. Dac n cadrul analizei se identific mai multe chei candidat, se stabilete cheia primar, documentndu-se hotrrea luat. Pasul 7. Specializare/generalizarea tipurilor de entiti. Aceasta etap este una opional n cadrul modelului relaional i are ca efect stabilirea superclaselor, respectiv a subclaselor tipurilor de entiti, dac este cazul. Pasul 8. Construirea diagramelor entitate-relaie. Prin parcurgerea acestei etape se asigur o mai bun nelegere a realitii care se modeleaz. Pasul 9. Eliminarea tipurilor de relaii duplicat. Pasul 10. Revizuirea diagramei entitate-relaie mpreun cu beneficiarul bazei de date. Modelarea realizat cu ajutorul unei diagrame entitate-relaie este un proces iterativ. De obicei, nu exist o singur soluie i, ca urmare, nici o singur diagram de acest fel. Din acest motiv se practic crearea mai multor diagrame entitate-relaie urmat de rafinarea fiecrei variante din care se va alege ulterior, mpreun cu beneficiarul bazei de date, diagrama optim. De remarcat este faptul c, de cele mai multe ori, nu se poate spune c o variant este mai bun dect alta, dar unele variante pot oferi soluii mai bune dect altele.
Implementarea tipurilor de relaii n cadrul tabelelor

Dndu-se o relaie R care se stabilete ntre dou tipuri de entiti E i F se impun urmtoarele reguli: 49
BAZE DE DATE -
dac relaia E-R-F este de tip unu-la-muli, cheia primar a relaiei F se introduce n relaia E; dac relaia E-R-F este de tip unu-la-unu, cheia primar a relaiei E se introduce n relaia F, sau cheia primar a relaiei F se introduce n relaia E; dac relaia E-R-F este de tip muli-la-muli, se creeaz o nou relaie ce conine cheile primare att ale lui E ct i ale lui F; dac relaia R are atribute, acestea trebuie transferate n cadrul unei relaii folosindu-se cheile externe.
3.1.2. Modelul logic

Acest model folosete concepte ce mai pot fi nelese nc de ctre utilizator, dar care presupun reprezentri referitoare la modul n care utilizatorul dorete s vizualizeze datele. n continuare tehnicile de nmagazinare a datelor rmn transparente utilizatorului. Proiectul logic al unei baze de date relaionale creeaz i valideaz modelul logic de date local. Scopul urmrit este acela de a construi un model logic de date bazat pe modelul conceptual de date creat anterior, dup care se trece la validarea acestui model cu ajutorul tehnicii normalizrii. Un astfel de model parcurge, de regul, urmtorul algoritm: Pasul 1. Transformarea modelului conceptual local n model logic local de date. n acest scop se trece la rafinarea modelului conceptual de date local, prin eliminarea caracteristicilor incomode: a. eliminarea relaiilor muli-la-muli; b. eliminarea relaiilor complexe; c. eliminarea relaiilor recursive; d. eliminarea relaiilor ce conin atribute; e. revizuirea relaiilor unu-la-unu. Pasul 2. Stabilirea relaiilor corespunztoare modelului logic de date. n aceast etap se creeaz i documenteaz fiecare relaie, inclusiv cheile primare i externe. Pasul 3. Validarea modelului folosind tehnica normalizrii. Pasul 4. Validarea modelului n cazul folosirii tranzaciilor. Trebuie s se obin asigurarea c modelul de date creat suport tranzaciile cerute de ctre beneficiarul bazei de date. Pasul 5. Stabilirea constrngerilor de integritate. n acest scop trebuie identificate: a. datele necesare; b. integritatea referenial; c. constrngerile de domeniu impuse atributelor; d. constrngerile logice; e. integritatea entitii. Pasul 6. Revizuirea modelului logic local mpreun cu beneficiarul bazei de date. Pasul 7. Construirea i validarea modelului logic global de date. Scopul acestei etape este acela de a realiza, pe baza modelelor logice locale de date un singur model logic global ce poate fi utilizat la reprezentarea realitii care se modeleaz. Pasul 9. Unificarea modelelor logice locale n cadrul unui singur model loc global. Se urmresc: - revederea numelor tipurilor de entiti i a cheilor primare; - revederea numelor relaiilor; - aducerea n cadrul unui singur model a tipurilor de entiti din cadrul modelelor logice locale; - introducerea n cadrul modelului logic global a tipurilor de entiti specifice fiecrei vederi logice locale; - aducerea n cadrul unui singur model a tipurilor de relaii din cadrul modelelor logice locale; - cutarea tipurilor de entiti i relaii lips; - verificarea cheilor externe; 50
BAZE DE DATE
- verificarea constrngerilor de integritate; - crearea modelului logic global de date; - actualizarea documentaiei. Pasul 10. Validarea modelului logic global. Se face prin utilizarea normalizrii. Pasul 11. Prevederea modificrilor ce trebuie efectuate n vederea dezvoltrilor ulterioare. Pasul 12. Revizuirea modelului logic global mpreun cu beneficiarul bazei de date.
3.1.3. Modelul fizic

Acest tip de model descrie reprezentarea datelor n formatul, modul de acces i ordinea real n care acestea sunt pstrate. Fiecare cmp dintr-un tabel are un anumit tip de dat. Standardul SQL-92 suport o varietate foarte larg de tipuri de date dintre care enumerm: - char(n) sau character(n): ir de caractere de lungime fix, stabilit de utilizator; - varchar(n) sau character varying: ir de caractere de lungime variabil a crui lungime maxim este stabilit de ctre utilizator; - int sau integer: tipul ntreg a crui lungime depinde de sistem; - smallint: tip ntreg de dimensiuni mai mici a crui lungime depinde de sistem; - numeric(p, d): un numr zecimal a crui precizie este stabilit de ctre utilizator, ce const dintrun numr total de cifre (p), dintre care d reprezint cifrele de la partea zecimal; de exemplu, numeric(3, 1) permite stocarea numrului 1.22 exact aa cum apare i nu n formatul 1.2; - real sau double precision: numere reale a cror precizie depinde de sistem; - float(n): numr real a crui precizie este stabilit de ctre utilizator (n cifre); - date: tip de dat calendaristic; - time: exprim ora unei zile n ore, minute i secunde. SQL-92 permite efectuarea de calcule aritmetice i de comparaii pe diverse intervale numerice, folosind operatori de transformare a tipurilor (cast).
3.2. normalizarea bazelor de date. Forme normale

3.2.1. Normalizarea
Normalizarea reprezint proiectul logic al unei baze de date. Principalul obiectiv al unui proiect logic este dezvoltarea schemelor relaionale corecte. n acest scop trebuie: - evitate datele redundante; - evitate anomaliile de modificare; - asigurat reprezentarea relaiilor dintre atribute; - facilitat verificarea actualizrilor care nu trebuie s foreze integritatea bazei de date. Normalizarea este un proces de reducere a redundanelor i cretere a stabilitii unei baze de date. Existena redundanelor ntr-o baz de date produce urmtoarele efecte defavorabile: - pierdere inutil de spaiu; - scderea performanelor de cost; - apariia inconsistenelor; - imposibilitatea reprezentrii datelor. Normalizarea presupune determinarea locului n care trebuie plasate anumite date n cadrul tabelelor bazei de date, stabilind totodat relaiile dintre acestea. Prin cuvntul norm se nelege respectarea unui standard i reprezint setul de condiii impuse i cunoscute sub denumirea de forme normale. Pentru a respecta aceste reguli trebuie identificate condiiile care trebuie respectate n scopul evitrii nclcrii integritii datelor impunndu-se n acest scop descompunerea relaiilor. Denormalizarea este procesul invers, opus normalizrii efectuat cu scopul mbuntirii performanelor bazei de date. Normalizarea este, cu alte cuvinte, un proces de descompunere a unui tabel n dou sau mai multe tabele cu scopul eliminrii redundanelor care genereaz anomalii de actualizare. n 51
BAZE DE DATE
timpul procesului de normalizare, structura tabelelor se testeaz cu ajutorul formelor normale care impun regulile de descompunere. O form normal reprezint, cu alte cuvinte, un set specific de reguli ce pot fi utilizate n scopul testrii structurii unui tabel pentru a obine asigurarea c structura respectiv nu pune probleme la introducerea sau extragerea datelor. Formele normale folosite n mod curent sunt Prima, A doua, A treia form normal, Forma normal Boyce-Codd, A patra i A cincea form normal.
Descompuneri
Fie U o schem de relaie. Un set de scheme de relaii {R1 , R2 , ... , Rn} reprezint o descompunere a lui U dac i numai dac: U = R1 R2 Rn i dac la reunire nu se pierde informaie. O descompunere {R, T} a lui U se face fr pierdere de informaie (referitor la setul de constrngeri) dac:
U = R T n cazul oricrei instane a R, T, i U. Altfel, descompunerea se spune a fi cu pierdere de informaii. Un caz mai general este ns:
U R T Dei descompunerea unui tabel n tabele mai mici este de dorit dintr-un anumit punct de vedere, n scopul reducerii redundanelor i evitrii anomaliilor, totui o astfel de ntreprindere implic anumite riscuri care, n principal, se manifest sub dou aspecte: - posibila pierdere de informaie; - posibila pierdere a dependenelor. Se prezint n continuare un exemplu de pierdere de informaie. Descompunerea R = {A, B}
A
r
B 1 2 1
A
A(r)
B 1 2
B(r)
R1 = {A} R2 = {B} A ( r) B ( r)
A B 1 2 1 2
52
BAZE DE DATE
Proprietile descompunerii
O schem relaional R care are o mulime de dependene funcionale F se descompune n relaiile R1 i R2. 1. Lipsa pierderii de informaie. Se verific dac cel puin una dintre urmtoarele dependene se afl n F+ R1 R2 R1 R1 R2 R2 Dac nu, descompunerea se poate face cu pierdere. 2. Pstrarea dependenelor. Fie Fi o mulime de dependene din F+ ce conine doar atributele relaiei Ri (cu notaia: Fi = Ri ( F + ) ). Se verific dac (F1 F2)+= F+. Dac se modific o relaie nu trebuie s se verifice dac se pstreaz dependenele n celelalte relaii. 3. Eliminarea redundanelor.
Dependene funcionale
Dependenele funcionale sunt constrngeri aplicate mulimii de relaii din baza de date. Acestea permit exprimarea unor fapte din lumea real. Noiunea generalizeaz ideea de supercheie. K este o supercheie a relaiei R dac n orice situaie n care t1[K] = t2[K], t1[R] = t2[R]. Dependenele funcionale permit exprimarea constrngerilor ce nu pot fi exprimate prin intermediul supercheilor (cheia primar, cheia candidat). O mulime F de dependene funcionale poate fi folosit n dou moduri: - pentru a specifica constrngerile aplicate relaiilor; - pentru a verifica dac relaiile mai sunt valabile n cazul aplicrii mulimii de dependene funcionale. Un atribut A este dependent funcional de o mulime de atribute B dac i numai dac: - valoarea lui A este determinat numai prin intermediul valorilor lui B; - valorile lui B determin n mod unic o valoare a lui A Dependena funcional se reprezint astfel: B A ceea ce nseamn c o valoare a lui B afecteaz valoarea lui A. O valoare a lui A nu afecteaz o valoare a lui B. B reprezint determinantul, A reprezint dependentul/determinatul. Dependenele funcionale sunt utilizate n scopul verificrii corectitudinii unei relaii. Exemple: a. K este o supercheie a relaiei R dac K R astfel nct pentru orice t1[k] = t2[k], t1[R]= t2[R]. K determin funcional toate atributele dintr-un tuplu al lui R. b. Eliminarea redundanelor (dependena parial, dependena tranzitiv, dependena funcional propriu-zis, aseriunile logice ce implic dependene funcionale). c. Verificarea constrngerilor aplicate pe un set de relaii. d. Verificarea corectitudinii modelului entitate-relaie. e. Verificarea reprezentrilor ntlnite n diagramele entitate-relaie (atribute ale unor entiti incorect alese, stabilirea de constrngeri de cardinalitate eronate, lipsa tipurilor de relaie unu-lamuli corespunztoare tipului de entitate ales sau existena atributelor multivaloare).
53
BAZE DE DATE
Dndu-se o relaie R care are o mulime de dependene funcionale F, i o cheie K se impune identificarea atributelor independente: 1. Cheia trebuie s identifice toate atributele unei relaii i dac un atribut depinde doar de o parte a cheii, atunci se spune c el este parial dependent de cheie. 2. Dac un atribut depinde de o cheie n mod tranzitiv, atunci el depinde n mod direct de alt atribut i, ca urmare, este independent de cheie. Atributul este dependent tranzitiv fa de cheie 3. Dependenele funcionale sunt transparente modelului entitate-relaie.
Clasa dependenelor funcionale

Clasa reprezint n matematic mulimea elementelor distincte ale unei mulimi. Definiie: Fie F o mulime de dependee. Clasa dependenelor funcionale corespunztoare mulimii F (F+), este alctuit din toate dependenele funcionale generate de dependenele mulimii F. Exemplu: R = {A, B, C, D} F= {A B, A C, CD A} Elementele mulimii F+ sunt: A BC CD B AD B AD ABCD + Dac R F atunci este o supercheie (cheie candidat, cheie primar) a lui R. Axiomele lui Armstrong ajut la determinarea clasei dependenelor funcionale. Reflexivitatea: Dac atunci (oricare ar fi mulimile de atribute i ). Exemplu: {D} {D,C}, astfel nct DC D Augmentarea: Dac atunci . Exemplu: dac C D, atunci BC BD Tranzitivitatea: Dac i atunci . Exemplu: dac C D i D E, atunci C E. Axiomele lui Armstrong sunt necesare i suficiente. Sunt necesare pentru c genereaz numai dependene funcionale corecte i sunt suficiente deoarece genereaz toate dependenele funcionale posibile (F+) pe baza unei mulimi date, F. Mai exist i alte proprieti suplimentare: Reuniunea: Dac i atunci . Exemplu: dac C D i C B atunci C BD Descompunerea: Dac atunci i . Exemplu: dac C BD atunci C B i C D Pseudotranzitivitatea: Dac i atunci . Exemplu: dac C D i AD B atunci CA B Aceste proprieti sunt necesare.
Dependene multivalorice
Urmtorul pas necesar este cel de determinare a tuturor dependenelor multivalorice care sunt generate n mod logic de o mulime dat de dependene multivalorice. Fie R o schem de relaie i R , R . n relaia R exist o dependen multivaloric dac n orice relaie r( R), oricare ar fi perechile de tupluri t1 i t2 din r pentru t1[] = t2[], exist tuplurile t3 i t4 n r astfel nct: t1[] = t2[] = t3[] = t4[] t3[] = t1[] t3[ R -] = t2[ R - ] 54
BAZE DE DATE t4[] = t2[] t4[ R -] = t1[ R -]
Reprezentarea tabelar a dependenei multivalorice este: t1 t2 t3 t4
a1 ai a1 ai a1 ai a1 ai
ai+1aj bi+1bj ai+1aj bi+1bj
R - - aj+1an bj+1bn bj+1bn aj+1an
Fie R o schem de relaie cu o mulime de atribute ce se pot divide n trei submulimi nevide, A, B, C. A B (A l multidetermin pe B) dac i numai dac pentru toate relaiile posibile r( R) {a1 , b1 , c1} r i {a1 , b2 , c2} r rezult {a1 , b1 , c2} r i {a1 , b2 , c1} r Definiia de mai sus presupune formalizarea noiunii prin care unei valori oarecare a lui A i este asociat o mulime de valori ale lui B i o mulime de valori ale lui C, iar mulimile B i C sunt independente una fa de alta. Dependenele multivalorice sunt utilizate n dou moduri: 1. Pentru a verifica corectitudinea relaiilor n cazul apariiei unei mulimi de dependene funcionale i multivaloare. 2. Pentru a specifica constrngerile aplicate mulimii de relaii. Dac o relaie r nu satisface o dependen multivaloric, se poate crea o alt relaie r care satisface dependena multivaloric prin adugarea de tupluri relaiei r. Aici se folosete acelai concept ca i n cazul dependenelor funcionale. Fie D o mulime de dependene funcionale i multivalorice. Mulimea D+ a lui D reprezint mulimea tuturor dependenelor funcionale i multivalorice generate de D. Mulimea D+ se poate calcula pe baza mulimii D, cu ajutorul definiiilor formale ale dependenelor funcionale i multivalorice dar, pentru a determina mulimea dependenelor, sunt mai uor de folosit regulile de inferen. Urmtoarea list de reguli de inferen aplicate dependenelor funcionale i multivalorice este necesar i suficient (primele trei reguli reprezint axiomele lui Armstrong): 1. Reflexivitatea. Dac reprezint mulimea atributelor i , atunci . 2. Augmentarea. Dac i nu este o mulime de atribute, atunci . 3. Tranzitivitatea. Dac i , atunci . 4. Complementaritatea. Dac , atunci R - - . 5. Augmentarea multivaloric. Dac , iar R i , atunci . 6. Tranzitivitatea multivaloric. Dac i atunci - . , 7. Duplicarea. Dac , atunci . 8. Cuplarea. Dac , iar , exist astfel nct R, iar = i , atunci .
Pstrarea dependenelor
Problema pstrrii dependenelor, atunci cnd vorbim despre dependenele multivalorice, nu este la fel de simpl ca n cazul dependenelor funcionale. O descompunere a schemei R n schemele R1,R2, . . .,Rn este o descompunere cu pstrarea dependenelor, corespunztoare mulimii D a dependenelor funcionale i multivalorice dac, pentru fiecare mulime de relaii r1(R1), r2(R2), . . . , rn(Rn) oricare ar fi i, ri satisface Di (restricia mulimii D pe Ri), exist o relaie r(R) care satisface mulimea D i pentru care ri = Ri(r), oricare ar fi i. 55
BAZE DE DATE
Dac se d o mulime de dependene funcionale i multivalorice, proiectul bazei de date ar trebui s ndeplineasc urmtoarele trei criterii: 1. S fie adus la forma normal 4. 2. S pstreze dependenele. 3. S nu piard informaie. Dac nu pot fi ndeplinite toate cele trei criterii, se poate ajunge la un compromis, cerndu-se respectarea doar a primelor dou criterii.
Dependenele de cuplare (jonciune)

Proprietatea de lips a pierderilor datorate cuplrilor este una dintre proprietile necesare obinerii unui proiect corespunztor al unei baze de date, datorit faptului c dac aceast proprietate nu se respect se pierde informaie. Dup ce relaiile au fost testate n raport cu dependenele funcionale i multivalorice, este obligatoriu s se foloseasc aceste dependene pentru a arta c descompunerile nu au pierderi de informaie datorate cuplrilor. Fie R o schem de relaie i R1, R2, . . ., Rn o descompunere a lui R. Dependena de cuplare *(R1, R2, . . . , Rn) este folosit pentru a restrnge mulimea relaiilor la acelea pentru care R1, R2, . . .,Rn nu reprezint o descompunere cu pierdere de cuplare a lui R. Formal, dac R = {R1, R2 . . . Rn}, se spune c o relaie r(R) satisface dependena de cuplare *(R1, R2, . . .,Rn) dac: ... r = R1 (r ) R2 (r ) Rn (r ) O dependen de cuplare este trivial dac una dintre relaiile Ri este chiar R. Fie dependena de cuplare *(R1, R2) pe schema R. O astfel de dependen impune ca pentru toate r(R), r = R1 (r) R2 (r) Fiecare dependen de cuplare de forma *(R1, R2) este, din acest motiv, echivalent cu o dependen multivaloric. Exist ns dependene de cuplare care nu sunt echivalente cu nici o dependen multivaloric. Cel mai simplu exemplu de astfel de dependen l reprezint schema: R = {A, B, C} cu dependena de cuplare: *((A, B), (B, C), (A, C)) care nu este echivalent cu nici o mulime de dependene multivalorice. Aa cum dependena multivaloric reprezint o modalitate prin care se demonstreaz independena unei perechi de relaii, dependena de cuplare este o modalitate de a demonstra c elementele unei mulimi de relaii sunt independente unele fa de altele. Noiunea de independen a relaiilor este o consecin natural a modului general de definire a unei relaii. n cazul dependenelor funcionale i multivalorice, este posibil folosirea unui set de reguli necesare i suficiente. Din pcate un set de reguli asemntor nu exist i n cazul dependenelor de cuplare.
3.2.2. Forme normale

Sunt proprieti sau constrngeri aplicate unei scheme de relaie cu scopul de a atinge anumite obiective, cum ar fi reducerea redundanelor. Exist 6 forme normale aplicate de obicei: Prima form normal (sau FN 1). A doua form normal (sau FN 2). 56
BAZE DE DATE
A treia form normal (sau FN 3). Forma normal Boyce Codd (sau FNBC). A patra form normal (sau FN 4). A cincea form normal (sau FN 5).
Fiecare dintre cele 6 forme normale este mai restrictiv ca predecesoarea sa. Astfel, de exemplu, o schem de relaie aflat n forma normal trei este i n forma normal doi, aa cum se reprezint n figura de mai jos:
FN 1
FN 2
FN 3
FNBC FN 4
FN 5
Figura 3.1. Forme normale Scopul formelor normale este acela de a elimina redundanele din cadrul relaiilor prin descompunerea acestora n dou sau mai multe relaii, fr ns a pierde informaie, ceea ce nseamn faptul c este posibil, n orice moment, revenirea la relaia originar doar pe baza relaiilor obinute din descompunere.
Prima form normal (FN 1)

Scopul formei normale unu este acela de a simplifica structura unei relaii prin obinerea asigurrii c ea nu conine date care mai pot fi descompuse sau date generatoare de valori repetitive, ceea ce nseamn faptul c nici un atribut nu poate avea o mulime de valori. Prin aciunea specific de descompunere, atributele ce nu respect aceste condiii sunt plasate n relaii separate, pstrndu-se atribute de legtur care au acelai tip de dat i aceeai dimensiune. Fiecare tabel are o cheie primar. De asemenea, o schem relaional R se afl n forma normal unu dac i numai dac fiecare atribut se afl la nivel atomic.
A doua form normal (FN 2)

O dependen funcional X Y se spune c este o dependen funcional complet dac prin eliminarea unui atribut din X se pierde aceast dependena. De exemplu, AB C este o dependen funcional complet numai dac C depinde funcional att de B ct i de A. O schem relaional se afl n forma normal doi dac i numai dac fiecare atribut care nu face parte din cheie depinde funcional de ntreaga cheie. Cu alte cuvinte, o relaie se afl n forma normal doi dac i numai dac se afl n forma normal unu i dac depinde funcional de ntreaga cheie. Altfel relaia trebuie descompus.
i
A treia form normal (FN 3)

O relaie se afl n forma normal trei dac i numai dac se afl n forma normal doi i dac fiecare atribut care nu face parte din cheie nu depinde tranzitiv de aceasta. Prin urmare, fiecare atribut care nu face parte din cheie nu poate depinde funcional dect de aceasta. Pentru a ajunge din forma normal doi n forma normal trei este necesar s: 57
BAZE DE DATE -
se determine dependenele funcionale dintre atribute; se descompun relaia n alte relaii, fr a pierde ns informaie.
Forma normal Boyce-Codd

O schem de relaie R se afl n FNBC dac, pentru toate dependenele funcionale ce au loc n R i sunt de forma X Y n care R X i R Y sunt ndeplinite condiiile: - X Y este trivial. - X este o cheie candidat a schemei de relaie R astfel nct X R. Cu alte cuvinte, fiecare atribut trebuie s depind de cheie, de ntreaga cheie i de nimic altceva. FNBC este o generalizare a formelor normale doi i trei. De remarcat este faptul c nu ntotdeauna este posibil descompunerea n FNBC cu pstrarea dependenelor.
Forma normal patru (FN 4)

Forma normal patru se bazeaz pe conceptul de dependen multivaloric. O dependen multivaloric apare doar n relaiile ce au cel puin trei coloane. Dac una dintre coloane are rnduri ale cror valori corespund unei singure valori ale unui rnd dintr-o alt coloan, atunci se spune c a aprut o dependen multivaloric. O relaie se afl n forma normal patru dac i numai dac se afl n forma normal Bozce-Codd i dac nu are dependene funcionale multivalorice.
A cincea form normal (FN 5)

A cincea form normal se bazeaz pe conceptul de dependen de cuplare. Dependena de cuplare este o proprietate ce garanteaz c nu se genereaz nregistrri false la reunirea relaiilor obinute prin descompunere. O relaie se afl n forma normal cinci dac ea nu poate fi descompus n alte relaii fr a pierde informaie. Cu alte cuvinte, dac se adaug un rnd suplimentar unei relaii care nu se afl n forma normal cinci i dac aceast relaie se descompune n alte relaii, prin refacerea relaiei iniiale se obin nregistrri false. O dependen de cuplare (jonciune) JD(R1, R2, ... ,Rn) reprezint o constrngere aplicat relaiei R, care arat faptul c fiecare instan r(R) trebuie s aibe pierdere de informaie prin descompunerea n relaiile R1, R2, ... , Rn. O dependen multivaloric reprezint un caz special al unei dependene de cuplare n care n = 2. Dependena de cuplare JD(R1, R2,..., Rn) este o dependen de cuplare trivial dac unele relaii Ri = R. O schem de relaie R se afl n forma normal cinci referitor la o mulime F de dependene funcionale, multivalorice, i de cuplare dac pentru fiecare dependen de cuplare netrivial JD(R1, R2, ... , Rn) din F, fiecare Ri este o supercheie a lui R. 3.3. Regulile lui Codd Edgar F. Codd a murit n data de 18 aprilie 2003, la vrsta de 79 de ani. Codd a fost un cercettor, angajat al firmei IBM, care a dezvoltat pentru prima oar, n 1970, modelul relaional al bazelor de date n care prezint operaiile ce pot fi efectuate asupra unei baze de date cu scopul obinerii accesului rapid i corect la acestea. Un model al unei baze de date are n vedere modul de stocare a datelor ct metodologia folosit la extragerea i actualizarea acestora. Pe parcursul anilor 60-70 Codd a cutat s rezolve problemele induse de modelul ierarhic al bazelor de date care se folosea la IBM n acea perioad. Rezultatul acestor cercetri s-a materializat n promovarea modelului relaional ca o soluie alternativ a modelului ierarhic care se bazeaz pe teoria matematic a mulimilor. Spre deosebire de sistemele ierarhice rigide, bazele de date relaionale sunt uor de parcurs, manipulat i modificat. n principiu, acestea se bazeaz pe conceptul de tabel bidimensional (numit i relaie), fiecare tabel fiind alctuit din nregistrri (rnduri orizontale, numite i tupluri) i cmpuri (coloane verticale numite i atribute). n esen, o baz de date relaional este alctuit dintr-o colecie de

58
BAZE DE DATE
tabele bidimensionale n care coloanele unui tabel pot conine asocieri cu rndurile altor tabele n scopul corespondenei datelor. La nceput IBM nu a luat n consideraie ideile revoluionare ale angajatului su, datorit marilor investiii fcute n produsul de baze de date ierarhice, IMS, pe care ncercau s-l promoveze masiv pe pia. i astfel s-au scurs 7 ani de la lucrrile lui Codd pn cnd Larry Ellison ce conducea o companie ce ulterior avea s devin ORACLE a creat primul produs comercial de baze de date relaionale. n 1981 IBM a realizat produsul SQL/DS, primul lor produs relaional, urmat n 1983 de celebrul DB2. n 1985 Codd a publicat o list de reguli care definesc simplu i concis o baz de date relaional ideal, aceste reguli devenind standardul de evaluare a sistemelor relaionale, fiind n acelai timp i un ghid de proiectare a tuturor sistemelor de baze de date relaionale. Dup publicarea lucrrii, Codd a afirmat c va fi foarte greu, dac nu imposibil de creat un sistem care s satisfac n totalitate setul de reguli, lucru care rmne valabil i astzi. La cele mai multe dintre sistemele relaionale de baze de date regulile 6, 9, 10, 11 i 12 sunt foarte greu de respectat. n continuare se va face o scurt trecere n revist a fiecreia dintre cele 12 reguli.
3.3.1. Regula informaiei

Toate informaiile transferate n cadrul unei baze de date relaionale trebuie reprezentate n mod explicit la nivel logic ntr-o singur modalitate, sub form de valori n cadrul unor tabele. Aceasta este, ceea ce se numete, reprezentare logic a datelor. Fiecare linie sau tuplu dintr-un tabel (relaie) reprezint intrri n coloane modelul aplicndu-se la fel n ntregul tabel astfel nct fiecare rnd are acelai format. Fiecare linie din cadrul tabelului este identificat prin intermediul valorii unei coloane sau combinaii de coloane, numit cheia primar. Fiecare rnd din cadrul tabelului poate fi accesat prin intermediul unei chei externe. Un sistem de gestiune a bazelor de date relaionale trebuie s manipuleze datele folosind doar instrumente specifice modelului relaional. Din acest motiv, att datele ct i metadatele (datele despre date) trebuie pstrate n tabelele bazei de date.
3.3.2. Regula de garantare a accesului

Fiecare dat stocat ntr-o baz de date relaional trebuie s poat fi logic accesibil utilizatorului prin apelarea numelui tabelului n care se afl, prin valoarea cheii primare i prin numele unei coloane aparintoare tabelului respectiv. Accesul la date trebuie s se fac simplu, fr a exista ambiguiti n exprimare. Modelul relaional nu se preocup de aspectele fizice ale extragerii datelor din tabele. Aceast regul afirm faptul c utilizatorul trebuie s aibe acces la datele stocate n baza de date doar prin intermediul numelor i valorilor. Cheia primar, prin care se identific n mod unic o anumit nregistrare din cadrul unui tabel, reprezint elementul fundamental al modelului relaional. ntr-un tabel nu poate exista dect o singur cheie primar care nu are voie s primeasc valori NULL.
3.3.3. Valorile NULL

Valorile NULL (diferite de irul de lungime zero sau de numrul zero) sunt utilizate n cadrul sistemelor de gestiune a bazelor de date relaionale pentru a reprezenta informaia lips sau indisponibil la un moment dat, indiferent de tipul de dat i sunt obligatorii n orice sistem complet relaional. De asemenea, astfel de reprezentri trebuie s poat fi manipulate ntr-un mod sistematic i fr echivoc de ctre orice sistem de gestiune al bazelor de date relaionale (Date, 1991). O valoare NULL poate apare oriunde n cadrul sistemului de gestiune al bazelor de date relaional, dar nu poate fi atribuit nici unei chei primare, majoritatea sistemelor admind specificarea conceptului de cmp nenul sub forma unei constrngeri ce interzice folosirea valorilor NULL n cmpul respectiv (Parkhurst, 2002).
59
BAZE DE DATE
3.3.4. Catalog actualizat permanent pe baza modelului relaional

Descrierea bazei de date este reprezentat, la nivel logic, n acelai fel ca i datele obinuite, astfel nct utilizatorii autorizai pot folosi acelai limbaj relaional pentru a pune ntrebri referitoare la structura acesteia. Sistemul trebuie s suporte existena unui catalog relaional accesibil utilizatorilor autorizai prin intermediul aceluiai limbaj de interogare folosit i n cazul datelor obinuite (Date, 1991). O baz de date relaional trebuie s se autodescrie (Moore). Catalogul reprezint locul n care alturi de alte lucruri se pstreaz toate schemele (externe, conceptuale, interne), dar i toate corespondenele (extern/conceptual, conceptual/intern). Cu alte cuvinte, catalogul conine informaii detaliate (numite i metadate) despre obiectele de interes ale bazei de date i ale ntregului sistem (Date, 2000).
3.3.5. Regula de nelegere a sublimbajului de manipulare a datelor

Un sistem relaional poate folosi mai multe limbaje sau moduri de folosire a terminalelor, dar acesta trebuie s suporte cel puin un limbaj relaional care: 1. are sintax liniar; 2. poate fi folosit att interactiv ct i din cadrul altor programe aplicaie; 3. suport: - operaii de definire a datelor (inclusiv definirea i folosirea vederilor); - operaii de manipulare a datelor (extrageri de date, dar i actualizri); - constrngeri de integritate i securitate; - operaii de gestiune a tranzaciilor (nceput, sfrit, reluare). (Date, 1991). n realitate toate sistemele comerciale de gestiune a bazelor de date relaionale folosesc limbajul structurat de interogare (SQL).
3.3.6. Regula de actualizare a vederilor

Toate vederile care sunt teoretic actualizabile, pot fi actualizate de ctre sistem. Fiecare vedere trebuie s suporte acelai set de reguli de manipulare prin care se poate accesa n mod direct la fel ca i un tabel obinuit (Parkhurst, 2002). O vedere este un tabel virtual, care provine din cel puin un tabel de baz i genereaz o serie de reprezentri ale datelor vizibile utilizatorilor. Tabelele de baz sunt tabelele reale ale bazei de date, cu reprezentare concret n mediul de stocare. Deoarece vederile nu nmagazineaz date ci interogri, acestea sunt numite tabele virtuale (Johnson, 1997). Date a luat n discuie dou principii importante ce trebuie avute n vedere la actualizarea unei vederi: Principiul interschimbabilitii care afirm faptul c nu trebuie s se fac nici un fel de deosebire ntre tabelele de baz i vederi i Principiul relativitii bazei de date prin care tabelele bazei de date sunt considerate a fi tabele de baz din punct de vedere al utilizatorului (Date, 2000).
3.3.7. Inserarea, actualizarea i eliminarea

Datele pot fi extrase din cadrul unei baze de date relaionale sub forma unor mulimi de date alctuite pe baza rndurilor din unul sau mai multe tabele. Operaiile de inserare, actualizare i tergere trebuie s fie aplicate pe orice astfel de mulime la fel cum se aplic i pe un singur rnd dintr-un tabel (Parkhurst, 2002).
60
BAZE DE DATE
3.3.8. Independena fizic de date

Acest lucru se refer la faptul c programele aplicaie nu trebuie s fie afectate dac au loc modificri n reprezentarea stocrii datelor sau n metodele de acces la date. Programele aplicaie sunt imune la modificrile ce au loc n reprezentarea loc fizic sau n metodele de acces la date (Avery). Aceasta nseamn faptul c structura fizic a datelor nu trebuie s provoace probleme utilizatorului care lucreaz cu acele date.
3.3.9. Independena logic de date

Programele aplicaie nu trebuie s fie afectate atunci cnd au loc modificri n structura tabelelor bazei de date, dac modificrile nu le afecteaz n mod direct. O vedere a utilizatorului asupra datelor nu trebuie s fie afectat nici ea n cazul modificrii structurii logice a unei baze de date (de exemplu, adugarea de coloane noi n tabele sau de tabele noi n baza de date) (Avery). Date a definit independena logic de date ca reprezentnd imunitatea utilizatorilor i a programelor acestora la modificrile efectuate n structura logic a unei baze de date. n esen, asupra unei baze de date au loc dou tipuri de operaii: de adugare de coloane sau tabele i de modificare a structurii tabelelor sau bazei de date. Nici una dintre cele dou operaii nu trebuie s afecteze utilizatorii sau programele acestora. Operaia de adugare De multe ori, unei baze de date trebuie s i se adauge fie coloane noi n cadrul tabelelor, fie tabele noi datorit apariiei de date suplimentare ce trebuie implementate n baza de date original. Ca urmare se pot identifica dou tipuri de adugri: 1. extinderea tabelelor prin apariia de atribute noi, de un anumit tip de dat specificat; 2. extinderea bazei de date prin apariia de tabele noi necesare introducerii de noi entiti n baza de date. Operaia de reorganizare a structurii bazei de date Uneori, apare necesitatea de modificare a structurii bazei de date, nu din cauza apariiei de date noi, ci din apariia nevoii de reamplasare a anumitor date n mod diferit n cadrul tabelelor, coninutul acestora rmnnd identic cu cel originar. (Date, 2000).
3.3.10. Independena integritii

Constrngerile de integritate specifice unei anumite baze de date relaionale trebuie s poat fi definite n sublimbajul relaional al datelor i nmagazinate n catalog, nu n programul aplicaie. De asemenea trebuie s fie posibil modificarea unor astfel de constrngeri aa cum cere logica aplicaiei fr a afecta celelalte aplicaii (Date, 1991). Constrngerile de integritate sunt reguli prin care sistemul de gestiune al bazelor de date mpiedic baza de date s ajung ntr-o stare inconsistent. Potrivit celor afirmate de ctre Date n 2001, regula de aur a independenei integritii este: Nu trebuie s fie permis nici un fel de operaie care s lase o anumit valoare ntr-o stare care s contrazic predicatul impus. n acest fel nu poate avea loc nici o tranzacie care ar ncerca s lase baza de date ntr-o stare care s nu corespund propriei condiii impuse. Constrngerile de integritate sunt: 1. Constrngeri NOT NULL Aceast constrngere este preferat de standardul ISO n comenzile CREATE i ALTER TABLE. Constrngerea interzice nmagazinarea n baza de date a valorilor NULL, ceea ce nseamn c nu se permite ca anumite coloane s fie goale (Connolly et al., 1999). 2. Clauza UNIQUE Clauza UNIQUE specific una sau mai multe coloane care identific n mod unic fiecare nregistrare din cadrul unui tabel. n acelai timp, fiecare coloan ce apare n clauza UNIQUE trebuie s fie declarat ca fiind NOT NULL. 61
BAZE DE DATE
SQL anuleaz orice operaie de inserare sau actualizare care are tendina de a genera valori duplicat n cheile candidat. ntr-un tabel nu este permis dect o singur cheie primar, iar clauza UNIQUE se folosete numai dac a fost aleas cheia primar i este necesar ca valorile altei coloane s fie unice. 3. Clauza PRIMARY KEY (integritatea entitii) Cheia primar a unui tabel trebuie s conin o valoare unic nenul pentru fiecare nregistrare introdus n tabel. Standardul ISO impune integritatea entitii prin intermediul clauzei cheii primare ce apare n instruciuni precum CREATE sau ALTER TABLE (Connolly et al., 1999). 4. FOREIGN KEY (integritatea referenial) O cheie extern este un cmp dintr-un tabel ce corespunde coloanei cheie candidat dintr-un alt tabel. O valoare a cheii externe trebuie s aib o valoare corespondent n tabelul printe. Tabelul ce conine cheia extern se numete tabelul referit, copil sau extern, n timp ce tabelul ce conine cheia candidat se numete tabelul de referin, primar, sau printe (Rennhackkamp, 1996). Integritatea referenial are semnificaia faptului c nici o baz de date relaional nu poate conine valori necorespunztoare ale cheii externe. Cheie extern necorespunztoare reprezint o valoare a cheii externe dintr-un tabel referit pentru care nu exist valoare n tabelul de referin. Cu alte cuvinte, constrngerea specific faptul c dac B l refer pe A, atunci A trebuie s existe. Date afirm faptul c, de multe ori, nu este posibil utilizarea unei interogri convenabile pentru a obine un anumit rspuns. Din acest motiv, trebuie s se poat specifica o aciune referenial de tipul CALL proc(), n care proc reprezint procedura creat de utilizator (Date, 2000). Actualizrile bazei de date au loc ntotdeauna la nivel atomic, ceea ce nseamn totul sau nimic, chiar dac sunt implicate actualizri pe mai multe valori, ca n cazul aciunii refereniale CASCADE (Date, 2000). Standardul ISO propune introducerea cheii externe prin intermediul clauzei FOREIGN KEY ce apare n cadrul comenzilor de creare sau modificare a structurii unui tabel. De exemplu, dac tabelul B are o cheie extern care face referire la o coloan din tabelul A, integritatea referenial interzice introducerea unei valori n tabelul B care nu are corespondent n tabelul A. n plus, regulile de integritate referenial pot avea n vedere i faptul c ori de cte ori se elimin o valoare din tabelul A, valorile corespunztoare din tabelul B pot fi i ele eliminate, ceea ce este cunoscut sub denumirea de tergere n cascad. Regulile de integritate referenial mai pot specifica i faptul c ori de cte ori se modific o valoare din tabelul A, toate valorile corespunztoare din tabelul B sunt i ele modificate automat, ceea ce este cunoscut sub denumirea de actualizare n cascad (Webopedia, Referential Integrity). SQL prevede urmtoarele opiuni ce pot fi alese n astfel de situaii (Connolly et al., 1999): 1. CASCADE: prin tergerea unei nregistrri din tabelul printe automat se elimin toate nregistrrile corespunztoare din tabelul copil. Deoarece nregistrrile eliminate pot conine o cheie candidat utilizat drept cheie extern n alt tabel, regulile cheii externe se aplic i n tabelul respectiv, .a.m.d. 2. SET NULL: terge nregistrarea din tabelul printe i provoac setarea coloanelor cheie extern din tabelul copil la valoarea NULL, dar o astfel de operaie este posibil numai dac coloanele cheii externe nu au setat opiunea NOT NULL. 3. SET DEFAULT: terge nregistrarea din tabelul printe i provoac setarea fiecrei componente a cheii externe din tabelul copil la valoarea implicit specificat, dar operaia este valabil numai dac coloanele cheii primare au setat opiunea DEFAULT. 4. NO ACTION: resping operaia de tergere din tabelul printe, fiind opiunea implicit dac nu se introduc explicit reguli pentru ON DELETE. 5. Constrngerea CHECK Exist dou tipuri de constrngeri CHECK. Una dintre ele este denumit constrngere de domeniu, deoarece stabilete mulimea de valori pe care o poate lua un atribut, iar cealalt se numete constrngerea logic utilizat cu scopul de a pune n eviden anumite condiii suplimentare (Connolly et al, 1999). Standardul ISO prevede astfel de constrngeri ce pot fi introduse n cadrul comenzilor de creare sau modificare a unui tabel. Clauza CHECK permite definirea unei constrngeri pe o coloan sau pe 62
BAZE DE DATE
ntregul tabel. n cazul utilizrii clauzei la nivel de coloan, aceasta nu poate face referire dect la coloana respectiv (Connolly et al, 1999). Cel puin urmtoarele dou constrngeri trebuie s existe n orice baz de date relaional: a. Integritatea entitii: nici o component a cheii primare nu are voie s aibe valoarea NULL. b. Integritatea referenial: pentru fiecare valoare nenul a cheii externe din baza de date relaional, trebuie s existe o valoare corespunztoare din acelai domeniu de valori i de acelai tip (cheia primar).
63
BAZE DE DATE
3.4. LIMBAJUL MYSQL
3.4.1. DESCRIERE
Bazele de date sunt folosite pentru stocarea informatiilor in vederea furnizarii ulterioare in functie de solicitarea primita. MySQL este un sistem de baze de date functional independent. In PHP exista functii pentru toate operatiile executate asupra bazelor de date MySQL. Administrarea MySQL se poate face din linie de comanda sau folosind browserul si accesand aplicatia numita PHPMyAdmin scrisa in PHP. 3.4.2. Operaii asupra bazelor de date Cele mai uzuale operatii cu bazele de date sunt: Comanda Semnificatie CREATE creaza o baza de date sau un tabel DROP sterge o baza de date sau un tabel INSERT adauga inregistrari intr-un tabel DELETE sterge inregistrari dintr-un tabel UPDATE updateaza inregistrarile dintr-un tabel SELECT selecteaza un tabel ALTER alterarea unui tabel 3.4.3. Tipuri de date MySQL In MySQL spatiul alocat pe discul serverului este functie de tipul de date. Cateva din tipurile de date folosite in bazele de date MySQL sunt: Tip Semnificatie int() numar intreg 32 biti Bigint() numar intreg 64 biti tinyint() numar intreg (-128 la 127 sau 0 la 255) 8 biti mediumint() numar intreg 24 biti smallint() numar intreg 16 biti char() sectiune cu lungime fixa de la 0 la 255 caractere varchar() sectiune cu lungime variabila de la 0 la 255 caractere float() numar mic cu virgula flotanta Double numar mare cu virgula flotanta Text sir cu maximum 65535 caractere date() data in format YYYY-MM-DD Date data in format YYYY-MM-DD HH:MM:SS Time ora in format HH:MM:SS Pentru ca baza de date sa fuctioneze mai bine coloanelor li s-au adaugat modificatori de coloana. Tipul de date intregi incep de la valori negative la pozitive. Daca se adauga optiunea UNSIGNED, care este un modificator de coloana, nu vor mai fi valori negative ci vor incepe de la 0. 64
BAZE DE DATE
Alti modificatori sunt: AUTO_INCREMENT functioneaza cu orice tip intreg. La fiecare rand nou adaugat in baza de date numarul asociat va fi incrementat. NULL inseamna fara valoare (diferit de spatiu sau zero). NOT NULL inseamna ca orice inregistrare va fi considerata ceva. PRIMARY KEY este rolul primei coloane din tabel, totodata reprezentand elementul de referinta pentru fiecare linie. 3.4.4. Comenzi elementare MySQL Cele mai frecvent utilizate comenzi MySQL sunt prezentate n coloana de mai jos. Ele sunt mult mai multe, dar aici nu doresc dect s fac o scurt prezentare, urmnd ca voi s studiai n detaliu comenzile utiliznd manualul oficial pe care l gsii la adresa http://dev.mysql.com/doc/ SHOW DATABASES; # afieaz o list cu numele bazelor de date existente USE numele_bazei_de_date # alegerea bazei de date cu care lucrm n continuare SHOW TABLES; # afieaz tabelele existente n baza curent SHOW COLUMNS; # afieaz informaii despre coloanele unui tabel CREATE DATABASE numele_bazei; # creaz o baz de date cu numele respectiv CREATE TABLE tabel_unu (camp_a TEXT); # creaz tabelul 'tabel_unu' cu un cmp numit 'camp_a' al crui tip este TEXT CREATE TABLE tabel_unu (camp_a TEXT,# creaz tabelul 'tabel_unu' cu un cmp numit camp_b INT, camp_c TINYINT); 'camp_a' al crui tip este TEXT, un cmp numit 'camp_b' n care datele de pe coloana respectiv vor fi numere ntregi i n cmpul 'camp_c' vor fi introduse doar numere ntre -128 i 127 DROP TABLE tabel_unu; # terge tabelul numit 'tabel_unu' DROP DATABASE numele_bazei; # terge baza de date cu numele 'numele_bazei' INSERT INTO tabel (camp1, camp2, camp3)# introduce n tabelul cu numele 'tabel', n VALUES (valoarea1, valoarea2, valoarea3); 'campul1' 'valoarea1', n 'campul2' 'valoarea2' i n 'campul3' 'valoarea3'. Iata cum ar arta n format tabelar: campul1 campul2 campul3 valoarea1 valoarea2 valoarea3 INSERT INTO tabel (camp1, camp2) VALUES# Se poate omite una din coloane, dac avem 5 (valoarea1, valoarea2); coloane, dar vrem s introducem numai n 3, specificm cmpul i valoarea doar pentru cele pe care le vrem, restul le ignorm. campul1 campul2 campul3 valoarea1 valoarea2 INSERT INTO tabel VALUES (valoarea1,# o variant simplificat care se poate aplica doar valoarea2, valoarea3); cnd introducem valori n toate cmpurile tabelului (nu se poate omite) INSERT INTO tabel VALUES (valoarea1,# identic ca cea dinainte, doar c n lipsa unei valoarea2, ''); valori se pun ghilimele. SELECT * FROM tabel; # Afieaz tot (*) ce exist n tabelul cu numele 'tabel' SELECT campul1 FROM tabel; # afieaz coninutul cmpului 'campul1' din tabelul 'tabel' 65
BAZE DE DATE SELECT campul1, campul2 FROM tabel
# afieaz coninutul cmpurilor 'campul1' i 'campul2' din tabelul 'tabel' SELECT * FROM tabel WHERE campul1 =# afieaz cmpurile a cror coninut este la fel cu 'valoare1'; 'valoare1' SELECT campul1, campul2 FROM tabel WHERE# caut i afieaz toate nregistrrile n care campul2 LIKE 'valoare2'; 'campul2' este asemntor cu 'valoare2' SELECT campul1, campul2 FROM tabel WHERE# caut i afieaz toate nregistrrile n care campul2 LIKE 'valoare2%'; 'campul2' ncepe cu 'valoare2' SELECT campul1, campul2 FROM tabel WHERE# caut i afieaz toate nregistrrile n care campul2 LIKE '%valoare2'; 'campul2' se termin cu 'valoare2' SELECT campul1, campul2 FROM tabel WHERE# caut i afieaz toate nregistrrile n care campul2 LIKE '%valoare2%'; 'campul2' se aseamn cu 'valoare2' oriunde n cadrul textului. SELECT * FROM tabel WHERE# afieaz toate cmpurile care conin 'valoarea1' campul1=valoare1 AND campul2 LIKEi se aseamn cu 'valoare2' '%valoare2%'; SELECT campul1, campul2 FROM tabel WHERE# caut i afieaz toate cmpurile care difer de campul1 != valoarea3; 'valoarea3' SELECT campul1, campul2 FROM tabel WHERE# caut i afieaz toate cmpurile care nu ncep cu campul2 NOT LIKE 'valoarea3%'; 'valoare3' SELECT campul1 FROM tabel ORDER BY# afieaz coninutul cmpului 'campul1' n ordine campul1 ASC; cresctoare SELECT campul1, campul2 FROM tabel ORDER# afieaz coninutul cmpului 1 n ordine BY campul1 ASC, campul2 DESC; cresctoare i cmpul 2 n ordine descresctoare. SELECT count(*) FROM tabel; # afieaz cte nregistrri sunt n total n tabel SELECT count (*) FROM tabel WHERE# cte nregistrri sunt n tabel al cror 'camp1' este campul1=variabila1; 'variabila1' SELECT camp1 FROM tabel GROUP BY camp1# afieaz coninutul cmpului 1 grupat dup ORDER BY camp1 ASC; 'camp1' ascendent SELECT * FROM tabel LIMIT 0,3; # afieaz din tabel ncepnd de la prima nregistrare nc 3. SELECT * FROM tabel LIMIT 10,5; # afieaz ncepnd de la nregistrarea 10 nc 5 nregistrri din tabel DELETE FROM tabel WHERE conditii; # terge nregistrarea din tabel. Sintaxa este la fel ca la comanda SELECT. UPDATE tabel SET coloana1='noua valoare a# pentru actualizarea coninutului unei nregistrri coloanei 1', coloana2='noua valoare a coloanei 2'din tabel. Sintaxa este la fel ca la comanda WHERE conditii; SELECT. (se terge valoarea veche i se scrie cea nou) ALTER TABLE tabel ADD dat TEXT; # adugare la tabelul existent a unei coloane numit 'dat' de tip text. ALTER TABLE tabel CHANGE dat data TEXT; # redenumete coloana numit 'dat' cu numele 'data' ALTER TABLE tabel CHANGE data data DATE; # modific tipul coloanei 'data' din 'TEXT' n coloana de tip 'DATE' ALTER TABLE tabel ADD nr MEDIUMINT# adaug o coloan numita 'nr' dupa 'coloana1' n UNSIGNED AFTER coloana1; tabelul 'tabel' INDECSI # vezi descrierea de mai jos Dei MySQL are suport pentru diacritice i setul de caractere 8859-2, este preferabil s nu folosii diacritice n numele bazelor de date, tabelelor sau cmpurilor. De asemenea, nu putei folosi ca nume de tabel sau de cmp cuvinte rezervate (nume de funcii, tipuri de caractere din MySQL precum CREATE, DROP sau COLUMN). Se pot folosi nume de tabele care conin spaii dar n practic 66
BAZE DE DATE
trebuie s ncadrai numele ntre back-ticks ` (semnul ` l gsii pe tasta aflat imediat sub Escape i nainte de 1). Exemplu: CREATE TABLE `tabel al carui nume are spatii` (`camp 1`, TEXT); SHOW COLUMNS FROM `tabel al carui nume are spatii`; Semnul * este definit n MySQL ca nsemnnd tot/toate. Semnul % este folosit n interogrile MySQL dac vrem s gsim cuvntul oriunde n cadrul textului. Mai exact: %cuvant_cautat - dac vrem s afieze toate cuvintele care se termin cu 'cuvantul_cautat' (pot fi i cteva caractere) cuvant_cautat% afieaz toate cuvintele care ncep cu 'cuvantul_cautat' %cuvant_cautat% - afieaz toate cuvintele care conin 'cuvantul_cautat' oriunde n text. Putem afla cte nregistrri sunt pentru un criteriu de selecie cu ajutorul lui count(). Putem afla astfel cte nregistrri sunt n total n tabel sau cte nregistrri sunt n tabel al cror cmp este cel cautat... Cu ajutorul instruciunii GROUP BY putem "grupa" rezultatele astfel nct s nu vedem duplicatele i s vedem doar valorile unice. Pentru a limita numrul ncepnd de la nregistrarea 10 nc 5 nregistrri). Pentru tergerea nregistrrilor dintr-un tabel se folosete comanda DELETE. Pentru tergerea unui tabel sau a unei baze de date comanda este DROP. Comanda UPDATE se folosete cnd vrem s modificm coninutul unei nregistrri fr a o terge. Dac dorim s schimbm structura unui tabel existent sau s adugm alte coloane folosim comanda ALTER TABLE. INDECSI - Cel mai folosit tip de index este id-ul. Id-ul este un numr unic de identificare pentru un element distinct (un rnd) al unui tabel. Un exemplu de id din viaa real este numerotarea cd-urilor. Cnd avei un cd nou l numerotai i l punei n raft la sfrit iar n catalog putei s l punei sortat dup titlu sau dup numrul de ordine. La fel i ntr-o baz de date, putei crea un cmp care s introduc automat un nr pentru fiecare rnd nou adugat n baza de date i la afiare putei s l folosii (de exemplu la vizualizarea ultimilor 10 vizitatori folosii id-ul). Pentru a creea un index avem urmtoarele comenzi: S zicem c avem o baz de date numit lista cu un cmp caseta i adugm cmpul id_casete comanda este urmtoarea: ALTER TABLE `caseta` ADD ìd_caseta` INT; ALTER TABLE `caseta` CHANGE ìd_caseta` ìd_caseta` INT(11) UNSIGNED NOT NULL; ALTER TABLE `caseta` ADD PRIMARY KEY (id_caseta); ALTER TABLE `caseta` CHANGE ìd_caseta` ìd_caseta` INT(11) UNSIGNED DEFAULT "0" NOT NULL AUTO_INCREMENT; i din acest moment, orice caset nou introdus va avea automat un nr de ordine. Este posibil ca toat niruirea de comenzi de mai sus s se poat face printr-o singur linie de cod, dar este mai sigur s facei cte o modificare n parte dect toate odat, pentru a detecta eventualele erori. Este bine s creai un id la nceputul tabelului, cnd nu avei intrri n baza de date, pentru a face incrementarea automat, altfel e posibil s v dea erori. Cu ajutorul id-ului putei afia de exemplu noutaile, cu o comand de genul - afieaz ultimele 10 intrri sortate dup id..., tiind c ntotdeauna ultima intrare are numrul cel mai mare... Ct de mare poate fi un tabel? MySQL stocheaz fizic datele unui tabel ntr-un fiier pe hard disc i cu ct tabelul e mai mare, cu att mrimea acestui fiier crete. Versiunea 3.22 a MySQL are o limit de 4 GB pentru mrimea unui tabel. n versiunile superioare aceast limit este extins pn la 8 milioane TB pentru tipul de tabel MyISAM. Cu toate acestea, sistemele de operare pot avea propriile limitri ale mrimii fiierelor. Mrimea impicit a tabelelor MySQL este de aproximativ 4 GB. Putei verifica mrimea maxim pentru un tabel cu ajutorul
67
BAZE DE DATE
3.4.5. COMENZI PENTRU INTEROGAREA BAZELOR DE DATE. FRAZA SELECT

n SQL o interogare se formuleaz printr-o fraz SELECT. Aceasta prezint trei clauze principale: SELECT, FROM i WHERE. SELECT corespunde operatorului proiecie din algebra relaional, fiind utilizat pentru desemnarea listei de atribute (coloanele) din tabela-rezultat; FROM este cea care permite enumerarea relaiilor din care vor fi extrase informaiile aferente consultrii; prin WHERE se desemneaz predicatul selectiv al algebrei relaionale, relativ la atribute ale relaiilor care apar n clauza FROM. La modul general o consultare simpl n SQL poate fi prezentat astfel: SELECT C1, C2, ..., Cn FROM R1, R2, ..., Rm WHERE P Execuia unei fraze SELECT se concretizeaz n obinerea unei tabele (relaii) rezultat. Acest poate fi o tabel propriu-zis sau o tabel temporar (care, de obicei, nu poate fi actualizat), dar i o tabel derivat (imagine). Uneori tabela rezultat poate fi obinut sub "forma" unei variabile-tablou. Ci - reprezint coloanele (care sunt atribute sau expresii de atribute) tabelei-rezultat; Rj - sunt relaiile ce trebuie parcurse pentru obinerea rezultatului; P - este predicatul (condiia) simplu sau compus ce trebuie ndeplinit de tupluri pentru a fi incluse n tabela-rezultat. Cnd clauza WHERE este omis, se consider implicit c predicatul P are valoarea logic "adevrat". Dac n locul coloanelor C1, C2, ... Cn apare simbolul "*", n tabela-rezultat vor fi incluse toate coloanele (atributele) din toate relaiile specificate n clauza FROM. De asemenea, n tabelarezultat, nu este obligatoriu ca atributele s prezinte nume identic cu cel din tabela enumerat n clauza FROM. Schimbarea numelui se realizeaz prin opiunea AS. Rezultatul unei fraze SELECT l vom considera ca fiind sub forma unei tabele oarecare. Trebuie avut n vedere, ns, c rezultatul interogrii poate fi obinut i sub forma unei tabele temporare sau chiar a unei variabile-tablou (matrice). n unele SGBD-uri, cum ar fi FoxPro, formatul general al frazei SELECT conine i clauza INTO. SELECT FROM INTO destinaie WHERE Destinaie specific dac se va obine o tabel "normal", o tabel temporar (tabel care se terge automat la nchiderea sa) sau o variabil-tablou. Dac clauza INTO nu este utilizat, atunci n urma interogrii se obine o tabel temporar cu numele predeterminat (Query).
68
BAZE DE DATE
Uneori, tabela rezultat ("normal" sau temporar) "ncalc" poruncile modelului relaional. Conform restriciei de entitate, ntr-o relaie nu pot exista dou linii identice. Or, n SQL, tabela obinut dintr-o consultare poate conine dou sau mai multe tupluri identice. Spre deosebire de algebra relaional, n SQL nu se elimin automat tuplurile identice (dublurile) din tabela-rezultat. Pentru aceasta este necesar utilizarea opiunii DISTINCT: SELECT DISTINCT C1, C2, ..., Cn FROM R1, R2, ..., Rm
WHERE P
LOCALITI CodPosta Localitate l 6600 Iai 5300 Focani 5725 Pacani 6750 Tg. Frumos CLIENI CodClien t 1001 1002 1003 1004 1005 1006 1007 1008 NumeClient TEXTILA SA MODERN SRL OCCO SRL FILATURA SA INTEGRATA SA AMI SRL AXON SRL ALFA SRL
Jude Iai Vrancea Iai Iai Adresa Bld. Copou, 87 Bld. Grii, 22 NULL Bld. Unirii, 145 I.V.Viteazu, 115 Galaiului, 72 Silvestru, 2 Prosperitii, 15 CodPostal 6600 5300 6600 5300 5725 6750 6600 5725
FACTURIEMISE NrFactur CodClient 111111 1003 111112 1001 111113 1004 111114 1003 111115 1008 111116 1008 111117 1006 111118 1007 111119 1005 111120 1003 111121 1001 111122 1007 111123 1006 111124 1004 111125 1003 111126 1002
Data 17.06.2000 17.06.2000 18.06.2000 18.06.2000 18.06.2000 19.06.2000 20.06.2000 23.06.2000 24.06.2000 24.06.2000 24.06.2000 24.06.2000 25.06.2000 25.06.2000 30.06.2000 01.07.2000
ValoareTotal 17000000 2850000 5850000 28500000 35700000 8700000 11000000 15000000 47250000 3000000 4250000 8750000 6600000 38650000 12850500 54250000
TVAColectat 2714286 455042 934034 4550420 5700000 1389076 1756303 2394958 7544118 478992 678571 1397059 1053782 6171008 2051761 8661765
Figura nr. 6.1. Baza de date utilizat n exemple
69
BAZE DE DATE
n concluzie, o fraz SELECT, n forma n care a fost prezentat, corespunde: unei selecii algebrice (clauza WHERE - P) unei proiecii (SELECT - Ci) unui produs cartezian (FROM - R1 R2 ... Rm) i conduce la obinerea unei noi relaii (tabele-rezultat) cu n coloane, fiecare coloan fiind: un atribut din R1, R2, ..., Rm sau o expresie calculat pe baza unor atribute din R1, R2, ..., Rm. n exemplele incluse n acest capitol se va utiliza baza de date prezentat n figura 6.1.
Exemplu
Care este, pentru fiecare factur emis, valoarea fr TVA ? SELECT NrFactur, ValoareTotal - TVAColectata AS ValFaraTVA
FROM FACTURIEMISE
Tabela rezultat din figura 6.2 conine dou atribute: NrFactur i ValFaraTVA. Ultimul este un cmp calculat.
Figura nr. 6.2. Exemplu de cmp calculat (ValFaraTVA)
Interogri care utilizeaz operatorii asambliti din algebra relaional

Reuniunea SELECT * FROM R1 UNION SELECT *
FROM R2
Operatorul pentru reuniune este deci UNION. De remarcat c, la reuniune, SQL elimin automat dublurile, deci nu este necesar utilizarea clauzei DISTINCT. Operatorul UNION este prezent n toate SGBD-urile importante.
70
BAZE DE DATE
Intersecia Pentru realizarea interseciei a dou tabele, R1 i R2 se utilizeaz operatorul INTERSECT:

SELECT * FROM R1
INTERSECT SELECT *
FROM R2
Dac n produsele profesionale, precum DB2 (IBM) sau Oracle operatorul este prezent, n schimb multe din cele din categoria uoar, precum Visual Fox Pro, INTERSECT rmne un deziderat, funcionalitatea sa realizndu-se prin subconsultri (operatorii IN i EXISTS) sau, uneori, prin jonciune. Diferena Diferena dintre tabelele R1 i R2 se realizeaz utiliznd operatorul MINUS sau EXCEPT. Fraza SELECT urmtoare funcioneaz n Oracle. SELECT * FROM R1 MINUS SELECT *
FROM R2
n DB2 MINUS trebuie nlocuit cu EXCEPT, iar n Visual FoxPro exist nici MINUS i nici EXCEPT, astfel nct, ca i n cazul interseciei, este necesar a se recurgere la ali operatori, precum IN sau EXISTS. Produsul cartezian n SQL nu exist operator explicit pentru efectuarea produsului cartezian. Dac n clauza FROM apar dou relaii, R1 i R2, atunci, n lipsa unei condiii de jonciune formulat n clauza WHERE, tabela rezultat va conine liniile obinute din produsul cartezian R1 R2. SELECT * FROM R1, R2
Interogri care utilizeaz operatorii relaionali din algebra relaional

Selecia
Exemplu 1 Care sunt localitile din judeul Iai n care firma are clieni ? Tabela n care se afl rezultatul i asupra creia se aplic predicatul de selecie este LOCALITI. Predicatul este Jude = "Iai". Fraza SELECT va avea forma: SELECT * FROM LOCALITI WHERE Jude = "Iai" Rezultat:
CodPostal
Localitate
Jude 71
BAZE DE DATE
6600 5725 6750 Iai Pacani Tg. Frumos Iai Iai Iai
Exemplu 2 Care dintre facturile emise dup 23.06.98 prezint valoarea mai mare sau egal cu 3 000 000 lei ? SELECT * FROM FACTURIEMISE WHERE Data > {23.06.2000} AND ValoareTotala >= 3000000 Rezultat: NrFactur CodClient 111119 1005 111124 1004 111126 1002 Data 24.06.2000 25.06.2000 01.07.2000 ValoareTotal 4 725 000 3 850 000 5 425 000 TVAColectat 850 500 693 000 976 500
Dup cum se observ, operatorul AND a fost utilizat pentru a introduce un "I" logic, dup cum OR se utilizeaz pentru SAU logic. n SQL, pentru comparare, n afara operatorilor "clasici" specificai mai sus, pot fi utilizai i ali operatori, dintre care n acest paragraf ne vom opri la: BETWEEN (ntre, cuprins ntre), LIKE (ca i, la fel ca), IN (n) i IS NULL. Operatorul BETWEEN Acest operator permite specificarea unui interval de valori n care trebuie s se ncadreze cmpul/expresia testat. Acest interval se refer la valori numerice sau la date calendaristice.
Exemplu 3 Se reformuleaz ultima interogare: Care sunt facturile emise dup 23.06.2000 i care au valoarea cuprins ntre 3 000 000 i 4 000 000 lei ? Fr operatorul BETWEEN fraza SELECT se scrie: SELECT * FROM FACTURIEMISE WHERE Data > {23.06.2000} AND ValoareTotala >= 3000000 AND ValoareTotala <= 4000000 Utiliznd operatorul BETWEEN se poate scrie: SELECT * FROM FACTURIEMISE WHERE Data > {23.06.2000} AND ValoareTotala BETWEEN 3000000 AND 4000000
Operatorul LIKE Acest operator se folosete pentru a compara un atribut de tip ir de caractere (ex. NumeClient, Adresa, Localitate) cu un literal (constant de tip ir de caractere). Astfel, dac se dorete obinerea unei tabele-rezultat care s conin numai clienii ai cror nume ncepe cu litera M, putem scrie predicatul din clauza WHERE sub forma: NumeClient LIKE "M%". Deoarece dup litera M apare semnul "%", se vor extrage din tabela CLIENI toate tuplurile pentru care valoarea atributului
72
BAZE DE DATE
NumeClient ncepe cu litera M, indiferent de lungimea acestuia (ex. MELCRET, MIGAS, MITA, MATSUSHITA etc.). Despre semnul "%" se spune c este un specificator multiplu, joker sau masc. Un alt specificator multiplu utilizat n multe versiuni SQL este liniua de subliniere ("_"). Spre deosebire de "%", "_" substituie un singur caracter. Diferena dintre cei doi specificatori multipli este pus n eviden n exemplele urmtoare.
Exemplu 4 Care sunt clienii ai cror nume este format din apte caractere, ncepe cu litera A i sunt societi cu rspundere limitat (SRL-uri) ?
SELECT * FROM CLIENI WHERE NumeClient LIKE "A__ SRL"

Rezultatul va fi cel din figura 6.3.
Figura nr. 6.3. Utilizarea specificatorului multiplu "_"
Dac s-ar fi utilizat simbolul "%":
SELECT * FROM CLIENI WHERE NumeClient LIKE "A%SRL",

rezultatul ar fi fost cel din figura 6.4.
Figura nr. 6.4. Utilizarea specificatorului multiplu "%"
n concluzie, "_" nlocuiete (substituie) un singur caracter, n timp ce "%" nlocuiete un ir de caractere de lungime variabil (ntre 0 i n caractere). Cei doi specificatori multipli pot fi utilizai mpreun. Operatorul IN Format general:
expresie1 IN (expresie2, expresie3, ...)
Rezultatul evalurii unui predicat ce conine acest operator va fi "adevrat" dac valoarea expresiei1 este egal cu (cel puin) una din valorile: expresie2, expresie3, ... Este util atunci cnd condiiile de selecie sunt mai complexe.
Exemplu 6 Care sunt localitile din judeele Iai i Vaslui? Fr utilizarea operatorului IN interogarea se scrie: SELECT * FROM LOCALITI
73
BAZE DE DATE
WHERE Jude = "Iai" OR Jude = "Vaslui" Utiliznd operatorul IN: SELECT * FROM LOCALITI WHERE Jude IN ("Iai", "Vaslui")
Operatorul IS NULL O valoare nul este o valoare nedefinit. Este posibil ca la adugarea unei linii ntr-o tabel, valorile unor atribute s fie necunoscute. n aceste cazuri valoarea atributului pentru tuplul respectiv este nul. Reamintim c, prin definiie, nu se admit valori nule pentru grupul atributelor care constituie cheia primar a relaiei.
Exemplu 7 Dac se dorete aflarea clienilor pentru care nu s-a introdus adresa, interogarea se poate scrie: SELECT * FROM CLIENTI WHERE Adresa IS NULL Cum n baza noastr de date, numai clientului OCCO SRL nu-i cunoatem adresa, rezultatul interogrii este cel din figura 6.5.
Figura nr. 6.5. Extragerea valorilor NULLe
Observaii d. Valoarea NULL nu se confund cu valoarea zero (pentru atributele numerice) sau cu valoarea "spaiu" (pentru atributele de tip ir de caractere) e. Operatorul NULL se utilizeaz cu IS i nu cu semnul "=". Dac s-ar utiliza forma expresie = NULL i nu expresie IS NULL, rezultatul evalurii va fi ntotdeauna fals, chiar dac expresia nu este nul !
Proiecia. Opiunea ORDER BY Coloanele tabelei-rezultat al consultrii sunt specificate n clauza SELECT, fiind separate prin virgul.
Exemplu 1 Care sunt judeele n care firma are clieni ? Este necesar parcurgerea relaiei LOCALITI, singurul atribut care intereseaz fiind Jude. Deoarece SQL nu elimin dublurile automat, dac se dorete ca n tabela-rezultat o localitate s figureze o singur dat, se utilizeaz opiunea DISTINCT: SELECT DISTINCT Jude FROM LOCALITI Exemplu 2 Care este denumirea fiecrei localiti i judeul n care se afl ? SELECT Localitate, Jude FROM LOCALITI
74
BAZE DE DATE
Prezentarea localitilor n ordinea alfabetic a numelui acestora este posibil prin apelnd la clauza ORDER BY:
SELECT Localitate, Jude FROM LOCALITI ORDER BY Localitate
Pentru ordonarea liniilor tabelei-rezultat n funcie de jude i, n cadrul aceluiai jude, n ordinea invers a localitii (de la Z la A), fraza SELECT se formuleaz astfel:
SELECT * FROM LOCALITI ORDER BY Jude ASCENDING, Localitate DESCENDING
Figura nr. 6.6. Clauza ORDER BY
Opiunile ASCENDING (cresctor) i DESCENDING (descresctor) indic deci modul n care se face ordonarea tuplurilor tabelei-rezultat al interogrii. Prioritatea de ordonare este stabilit prin ordinea atributelor specificate n ORDER BY: ordonarea "principal" se face n funcie de valorile primului atribut specificat; n cadrul grupelor de tupluri pentru care valoarea primului atribut este identic, ordinea se stabilete dup valoarea celui deal doilea atribut specificat .a.m.d. Dac n ORDER BY lipsesc opiunile ASCENDING/DESCENDING, ordonarea se face cresctor. onciunea SQL nu prezint clauze sau operatori speciali pentru realizarea theta-jonciunii, echi-jonciunii sau jonciunii naturale. Dar, aa cum am vzut, o jonciune este o combinaie de produs cartezian i selecie.
Exemplu 1 Revenind la exemplele din algebra relaional, echi-jonciunea tabelelor FURNIZOR1 i FURNIZOR2 n SQL se realizeaz prin fraza SELECT: SELECT * FROM FURNIZOR1, FURNIZOR2 WHERE FURNIZOR1.CodF = FURNIZOR2.CodF Observaie: n SQL2, echijonciunea poate fi realizat prin clauza INNER JOIN plasat n clauza FROM. Astfel, ultima fraz SELECT se poate redacta, n SQL2, fr clauza WHERE: SELECT * FROM FURNIZOR1 INNER JOIN FURNIZOR2 ON FURNIZOR1.CodF = FURNIZOR2.CodF Exemplu 2 Care sunt clienii din municipiul Focani ?
75
BAZE DE DATE
SELECT * FROM CLIENI INNER JOIN LOCALITI ON CLIENI.CodPostal = LOCALITI.CodPostal WHERE Localitate=Focsani
Produsul cartezian al tabelelor CLIENI i LOCALITI este prezentat n figura 6.7.
Figura nr. 6.7. Produsul cartezian CLIENI LOCALITI
Din cele 32 de linii sunt selectate cele care ndeplinesc condiia de jonciune, CLIENI.CodPostal = LOCALITI.CodPostal, i pe cea suplimentar - Localitate=Focsani. n final, rezultatul este cel din figura 6.8.
Figura nr. 6.8. Rezultatul final al jonciunii i al seleciei suplimentare
Exemplu 3 Care sunt facturile emise clienilor din judeul Iai ?
SELECT NrFactura FROM FACTURIEMISE, CLIENI, LOCALITI WHERE FACTURIEMISE.CodClient = CLIENI.CodClient AND CLIENI.CodPostal = LOCALITI.CodPostal AND Jude=Iai Soluia este echivalent cu urmtoarea: 76
BAZE DE DATE
SELECT NrFactura FROM FACTURIEMISE FE INNER JOIN CLIENI C ON FE.CodClient = C.CodClient INNER JOIN LOCALITI L ON C.CodPostal = L.CodPostal WHERE Jude=Iai
Exemplu 4 Care sunt facturile emise n aceeai zi ca i factura 111113 ? Problema propus poate fi rezolvat relativ uor folosind o subconsultare, dup cum va fi prezentat n paragraful urmtor. Pn una-alta, soluia pe care o avem n acest moment la ndemn se bazeaz pe autojonciune. Autojonciune nseamn jonciunea unei tabele cu ea-nsi, practic, jonciunea a dou instane ale unei aceleai tabele: SELECT FE1.NrFactura, FE1.Data
FROM FACTURIEMISE FE1 INNER JOIN FACTURIEMISE FE2 ON FE1.Data= FE2.Data AND FE2.NrFactura=111113
Soluia de mai sus conduce la rezultatul din figura 6.9. S vedem prin ce mecanism.
Figura nr. 6.9. Facturile emise n aceeai zi ca i 111113
Jonciunea celor dou instane, FE1 i FE2, ale tabelei FACTURIEMISE dup condiia FE1.Data = FE2.Data: SELECT * FROM FACTURIEMISE FE1 INNER JOIN FACTURIEMISE FE2 ON FE1.Data= FE2.Data conduce la un rezultat precum cel din figura 6.10.
77
BAZE DE DATE
Figura nr. 6.10. Auto-jonciunea, dup valorile Data, tabelei FACTURIEMISE
Din cele 38 de linii, prin predicatul FE2.NrFactura=111113 rmn numai 3, cele din figura 6.9.
Exemplu 5 Care sunt clienii crora NU le-am ntocmit facturi pe 18/06/2000 ?
La aceast problem se pot formula mai multe soluii. Una ar fi bazat pe diferena dintre toi clienii (extrai din tabela CLIENI) i cei crora le-am trimis facturi pe 18 iunie. innd seama c numele clientului este cheie alternativ, deci unic, se poate scrie: SELECT NumeClient FROM CLIENTI MINUS SELECT NumeClient
FROM CLIENTI INNER JOIN FACTURIEMISE
ON CLIENTI.CodClient=FACTURIEMISE.CodClient Data={^2000/06/18}
AND
O asemenea soluie funcioneaz n Oracle (folosind funcia de conversie TO_DATE pentu constant), DB2 (nlocuind, n plus, MINUS cu EXCEPT), nu ns i n Visual FoxPro. Avnd n vedere c nu avem cunotine privind subconsultrile, putem recurge la un artificiu bazat pe o form interesana a jonciunii, i anume jonciunea extern. S examinm fraza SELECT urmtoare i rezultatul acesteia din figura 6.11. SELECT * FROM CLIENTI C LEFT OUTER JOIN FACTURIEMISE FE ON C.CodClient=FE.CodClient AND Data={^2000/06/18}
78
BAZE DE DATE
Figura nr. 6.11. O jonciune extern
Prima observaie: n rezultat sunt incluse toi clienii, adic, toate nregistrrile din tabela CLIENI. A doua observaie: jonciunea nu mai este de tip INNER i LEFT OUTER, adic extern la stnga. Cum dintre CLIENI i FACTURIEMISE, cea de la stnga este prima, rezult c n rezultat sunt extrase toate liniile din aceasta, chiar dac nu au linii corespondente n tabela din dreapta. n cazul nostru, TEXTILA SA, MODERN SRL, INTEGRATA SA, AMI SRL AXON SRL nu au fcut cumprturi de la firma noastr pe 18 iunie 2000. Ne dm seama de acest lucru observnd c pe liniile coresponde acestora, valorile atributelor preluate din FACTURIEMISE sunt NULL. Astfel nct, pentru a rspunde punctual la problema pus, ar trebui extrase liniile n care, n urma jonciunii externe, FE.NrFactur (sau oricare alt atribut din FE) este NULL. Paradoxal sau nu, fraza urmtoare nu obine rezultatul scontat n VFP:
SELECT * FROM CLIENTI C LEFT OUTER JOIN FACTURIEMISE FE ON C.CodClient=FE.CodClient AND Data={^2000/06/18} WHERE FE.NrFactura IS NULL
n schimb, se poate folosi un artificiu prin ntrebuinarea funciei NVL: SELECT * FROM CLIENTI C LEFT OUTER JOIN FACTURIEMISE FE ON C.CodClient=FE.CodClient AND Data={^2000/06/18}
WHERE NVL(FE.NrFactura,0) = 0
Funcia NVL convertete valorile nule ale atributului NrFactura n 0. Principial, soluia bazat pe NVL are acelai mecanism ca i precedenta interogare. Cu singura diferen c funcioneaz, dup reiese din figura 6.12.
Figura nr. 6.12. Clienii fr facturi pe 18 iunie 2000
Firete, pentru a obine numai numele clienilor, este necesar nlocuirea asteriscului din clauza SELECT cu atributul NumeClient. Ar mai fi de adugat c exist trei tipuri de jonciune extern: la stnga (LEFT OUTER JOIN), la dreapta (RIGHT OUTER JOIN) i total (FULL OUTER JOIN). La jonciunea extern la dreapta sunt extrase liniile echi-jonciunii plus liniile tabelei din dreapta ce nu ndeplinesc condiia formulat prin predicatul de jonciune. Jonciunea extern total reprezint, n fapt, reuniunea (cu eliminarea dublurilor) jonciunilor la stnga i la dreapta. 79
BAZE DE DATE
Sub-consultri. Operatorul IN
O alt facilitate deosebit de important a limbajului SQL o constituie posibilitatea includerii (imbricrii) a dou sau mai multe fraze SELECT, astfel nct pot fi formulate interogri cu mare grad de complexitate. Operatorul IN poate fi utilizat i pentru includerea unei fraze SELECT ntr-o alt fraz SELECT.
Exemplu 1 Care sunt facturile emise n aceeai zi n care a fost ntocmit factura 111113 ? SELECT * FROM FACTURIEMISE WHERE Data IN (SELECT Data FROM FACTURIEMISE WHERE NrFactur=111113)
Sub-consultarea
SELECT Data FROM FACTURIEMISE WHERE NrFactur=111114
are ca rezultat o tabel alctuit dintr-o singur coloan (Data) i o singur linie ce conine valoarea atributului Data pentru factura 111113, ca n figura 6.13:
Figura nr. 6.13. Rezultatul sub-consultrii
Clauza WHERE Data IN determin cutarea n tabela FACTURIEMISE a tuturor tuplurilor (liniilor) care au valoarea atributului Data egal cu una din valorile tuplurilor (n cazul nostru, egal cu valoarea tuplului) din tabela obinut prin "sub-consultare" (n cazul nostru, tabela din figura 6.13). Cu alte cuvinte, n acest caz WHERE Data IN va selecta toate facturile pentru care data emiterii este 18/06/2000 figura 6.14.
Figura nr. 6.14. Facturile emise n aceeai zi ca i 111113
Exemplu 2 Care sunt facturile emise n alte zile dect cea n care a fost ntocmit factura 111113? SELECT * FROM FACTURIEMISE WHERE Data NOT IN (SELECT Data FROM FACTURIEMISE WHERE NrFactur=111113)
80
BAZE DE DATE
S-a utilizat negaia, testndu-se non-apartenena la o relaie creat printr-o sub-fraz SELECT (vezi figura nr. 6.15).
Figura nr. 6.15. Facturile emise n alte zile dect factura 111113
Exemplu 3 Care sunt clienii crora li s-au trimis facturi ntocmite n aceeai zi cu factura 111113? SELECT DISTINCT NumeClient FROM CLIENI WHERE CodClient IN (SELECT CodClient FROM FACTURIEMISE WHERE Data IN (SELECT Data FROM FACTURIEMISE WHERE NrFactur=111113))
Am ilustrat modul n care pot fi imbricate (nlnuite, incluse) trei fraze SELECT. Soluia este valabil n SGBD-urile profesionale (DB2, Oracle), nu ns i n VFP, n care orice interogare poate fi desfutata pe maximum dou nivele (SELECT-ul principal, plus un nivel de sub-consultri). Pentru a reduce numrul straturilor de corelare, se poate folosi, n acest caz, jonciunea: SELECT DISTINCT NumeClient FROM CLIENI, FACTURIEMISE WHERE CLIENI.CodClient=FACTURIEMISE.CodClient AND Data IN (SELECT Data FROM FACTURIEMISE WHERE NrFactura=111113) Rezultatul din figura 6.16 demonstreaz c soluia este viabil.
Figura nr. 6.16. Clieni pentru care exist mcar o factur ntocmit n aceeai zi cu 111113
81
BAZE DE DATE
Se poate reine, ca regul general, c aproape orice consultare poate fi redactat n mai multe moduri, n funcie de experiena i imaginaia celui care o formuleaz.
Funcii de agregare: COUNT, SUM, AVG, MAX, MIN

Formatul general al unei fraze SELECT ce conine funcii predefinite este: SELECT funcia-predefinit1, ... , funcia-predefinitN FROM list-tabele WHERE condiii Rezultatul oricrei fraze SELECT este o nou relaie (tabel). n lipsa opiunii GROUP BY, dac n clauza SELECT este prezent o funcie predefinit, tabela rezultat va conine o singur linie. Funcia COUNT contorizeaz valorile unei coloane, altfel spus, numr, ntr-o relaie, cte valori diferite de NULL are coloana specificat.
Exemplu 1
Ci clieni are firma ? SELECT COUNT (CodClient) AS Nr_Clienti

FROM CLIENTI
n funcia COUNT se poate utiliza ca argument, n locul numelui unei coloane, semnul *; n acest caz se va determina cte linii are tabela la care se aplic funcia respectiv.
Exemplu 2
La ci clieni s-au trimis facturi ? SELECT COUNT () FROM CLIENTI WHERE CodClient IN (SELECT CodClient FROM FACTURIEMISE)
Rezultatul corect poate fi ns obinut i prin utilizarea clauzei DISTINCT astfel:
SELECT COUNT (DISTINCT CodClient)

FROM FACTURIEMISE
Funcia SUM calculeaz suma valorilor unei coloane.

Exemplu 3
Care este valoarea total a facturilor emise ? SELECT SUM (ValoareTotala) AS Total_FP FROM FACTURIEMISE
Figura 6.17. Totalul vnzrilor
Exemplu 4
Care este totalul valorii facturilor trimise clientului AXON SRL ? SELECT SUM (ValoareTotala) AS Total_FE_AXON FROM FACTURIEMISE, CLIENTI
WHERE FACTURIEMISE.CodClient = CLIENTI.CodClient
82
BAZE DE DATE
AND NumeClient = "AXON SRL" Funciile MAX i MIN. Determin valorile maxime, respectiv minime ale unei coloane n cadrul unei tabele.
Exemplu 5
Care este cea mai mic valoare a unei facturi emise ? SELECT MIN(ValoareTotala) FROM FACTURIEMISE
Exemplu 6
Care este factura emis ce are cea mai mare valoare ? SELECT NrFactura, ValoareTotala FROM FACTURIEMISE WHERE ValoareTotala = (SELECT MAX (ValoareTotala) FROM FACTURIEMISE) Subconsultarea extrage valoarea total maxim a unei facturi, valoare ce va fi utilizat ca argument pentru SELECT-ul principal. Rezultatul este cel din figura 6.18.
Figura nr. 6.18. Factura cea mai valoroas
Atenie ! Varianta urmtoare nu este corect: SELECT NrFactura, MAX(ValoareTotala ) FROM FACTURIEMISE Dac n Oracle sau DB2 la execuia acestei interogri se afieaz un mesaj de eroare, n Visual FoxPro nu, aa c unii utilizatori s-ar putea baza pe rezultatul afiat.
Gruparea tuplurilor. Clauzele GROUP BY i HAVING

SQL permite utilizarea clauzei GROUP BY pentru a forma grupe (grupuri) de tupluri ale unei relaii, pe baza valorilor comune ale unei coloane. n frazele SELECT formulate pn n acest paragraf, prin intermediul clauzei WHERE au fost selectate tupluri din diferite tabele. Prin asocierea unei clauze HAVING la o clauz GROUP BY este posibil selectarea anumitor grupe de tupluri ce ndeplinesc un criteriu. Rezultatul unei fraze SELECT ce conine clauza GROUP BY este o tabel care va fi obinut prin regruparea tuturor liniilor din tabelele enumerate n FROM, care prezint o aceeai valoare pentru o coloan sau un grup de coloane. Formatul general este: SELECT coloan 1, coloan 2, ...., coloan m FROM tabel GROUP BY coloan-de-regrupare
Exemplu 1
Care este totalul zilnic al valorii facturilor emise ? 83
BAZE DE DATE
SELECT Data, SUM (ValoareTotala) AS Total_Zilnic FROM FACTURIEMISE GROUP BY Data n acest caz tabela-rezultat va avea un numr de linii egal cu numrul de date calendaristice distincte din tabela FACTURIEMISE. Pentru toate facturile aferente unei zile se va calcula suma valorilor, datorit utilizrii funciei SUM(ValoareTotala). Succesiunea pailor este urmtoarea: 1. Se ordoneaz liniile tabelei FACTURIEMISE n funcie de valoarea atributului Data - figura 6.19.
Figura nr. 6.19. Pasul 1 al gruprii
2. Se formeaz cte un grup pentru fiecare valoare distinct a atributului Data - vezi figura 6.20.
Figura nr. 6.20. Al doilea pas al gruprii
3. Pentru fiecare din cele nou grupuri se calculeaz suma valorilor atributului ValoareTotala. Tabela rezultat va avea nou linii, ca n figura 6.21. 84
BAZE DE DATE
Figura nr. 6.21. Rezultatul final al gruprii
Exemplu 2
Care este numrul facturilor emise pentru fiecare client ? SELECT NumeClient, COUNT(NrFactura)
FROM FACTURIEMISE INNER JOIN CLIENTI
ON FACTURIEMISE.CodClient = CLIENTI.CodClient
GROUP BY FACTURIEMISE.CodClient
Pn la standardul SQL99 i publicarea Amendamentului OLAP la acest standard, n SQL nu pot fi calculate, prin GROUP BY, subtotaluri pe mai multe niveluri. Pentru aceasta este necesar scrierea de programe n SGBD-ul respectiv. Clauza HAVING permite introducerea unor restricii care sunt aplicate grupurilor de tupluri, deci nu tuplurilor "individuale", aa cum "face" clauza WHERE. Din tabela rezultat sunt eliminate toate grupurile care nu satisfac condiia specificat. Clauza HAVING "lucreaz" mpreun cu o clauz GROUP BY, fiind practic o clauz WHERE aplicat acesteia. Formatul general este: SELECT coloan 1, coloan 2, .... , coloan m FROM tabel GROUP BY coloan-de-regrupare HAVING caracteristic-de-grup
Exemplu 3
Pentru facturile emise intereseaz valoarea zilnic a acestora (n funcie de data la care au fost ntocmite, dar numai dac aceasta (valoarea zilnic) este de mai mare de cinci milioane lei. SELECT Data, SUM(ValoareTotala) FROM FACTURIEMISE GROUP BY Data
HAVING SUM(ValoareTotala) > 15000000 La execuia acestei fraze, se parcurg cei trei pai prezentai la exemplul 1, apoi, din cele nou tupluri obinute prin grupare, sunt extrase numai cele care ndeplinesc condiia SUM(ValoareTotala)>15000000. Rezultatul final este cel din figura 6.22.
85
BAZE DE DATE
Figura 6.22. Rezultatul consultrii - exemplul 3
Exemplu 4
S se afieze ziua n care s-au ntocmit cele mai multe facturi. SELECT Data FROM FACTURIEMISE GROUP BY Data HAVING COUNT(*) >= ALL (SELECT COUNT(*)
FROM FACTURIEMISE
GROUP BY Data) Din pcate, nici acest tip de interogare (prezena subconsultrilor n clauza HAVING) nu este agreat de Visual FoxPro, astfel nct este necesar utilizarea mai multor fraze SELECT i salvarea rezultatelor intermediare fie n tabele derivate (view-uri), fie n cursoare (NR_PE_ZILE) care, n VFP sunt tabele temporare a cror via este limitat de nchiderea lor, explicit sau implicit: SELECT Data, COUNT(*) AS Nr ;
FROM FACTURIEMISE ;
INTO CURSOR NR_PE_ZILE ; GROUP BY Data SELECT Data, Nr ; FROM NR_PE_ZILE ; WHERE Nr >= ; (SELECT MAX(Nr) ; FROM NR_PE_ZILE) Coninutul cursorului NR_PE_ZILE, precum i rezultatul final sunt cele din figura 6.23.
Figura 6.23. Obinerea n VFP a zilei cu cele mai multe facturi
86
BAZE DE DATE
COMENZI PENTRU ACTUALIZAREA BAZELOR DE DATE

SQL prezint comenzi specifice pentru modificarea coninutului unei tabele, nelegnd prin aceasta trei aciuni prin care se actualizeaz baza: a) adugarea de noi linii la cele existente ntr-o tabel, b) tergerea unor linii, c) modificarea valorii unui atribut.
Adugarea de nregistrri
Exemplu 1 S presupunem c, la un moment dat, ntreprinderea vinde produse i firmei RODEX SRL care are sediul pe strada Sapienei, nr.44 bis, n localitatea Iai.
Acest nou client trebuie "introdus" n baza de date, operaiune care n SQL, se realizeaz prin comanda: INSERT INTO CLIENI VALUES (1009, RODEX SRL, Sapienei, 44 bis, 6600) Fraza INSERT de mai sus poate fi scris i sub forma INSERT INTO CLIENI (CodClient, NumeClient, Adresa, CodPostal) VALUES (5009, RODEX SRL, Sapienei 44 bis, 6600). Dup cum se observ, dup numele tabelei (CLIENI) au fost enumerate toate atributele pentru care se introduc valori prin clauza VALUES. Dac nu s-ar fi cunoscut adresa clientului RODEX, atunci fraza INSERT ar fi avut una din formele: INSERT INTO CLIENI (CodClient, NumeClient, Adresa, CodPostal) VALUES (5009, "RODEX SRL", NULL, 6600) sau INSERT INTO CLIENI (CodClient, NumeClient, CodPostal) VALUES (5009, RODEX SRL, 6600) n noua linie a tabelei CLIENI valoarea atributului Adresa va fi NULL.
tergerea de nregistrri
Operaiunea de eliminarea a una sau mai multe linii dintr-o tabel, pe baza unui predicat, se realizeaz n SQL prin comanda DELETE care are sintaxa: DELETE FROM nume-tabel WHERE predicat
Exemplu 2 S se elimine din tabela CLIENI linia aferent clientului MODERN SRL (cod 1002).
DELETE FROM CLIENI

WHERE CodClient = 1002
87
BAZE DE DATE
Exemplu 3 S se tearg datele referitoare la fiecare vnzare de produs pentru clienii din oraul Focani.
DELETE FROM FACTURIEMISE WHERE CodClient IN (SELECT CodClient

FROM CLIENI, LOCALITI
WHERE CLIENI.CodPostal=LOCALITI.CodPostal AND Localitate = "Focani")) Nici aceast form nu funcioneaz n VFP. n general, tergerea unor linii trebuie privit cu mult circumspecie, deoarece atunci cnd linia de ters conine valori ale unor atribute ce apar n alte tabele ca i chei strine, exist riscul pierderii integritii refereniale. Standardul SQL92 (nu i dialectul SQL din VFP) permite la crearea unei tabele descrierea aciunii care se va derula la tergerea unei linii printe n cazul n care exist linii-copil. Spre exemplu, se poate refuza tergerea de linii din tabela CLIENI, dac la crearea tabelei FACTURIEMISE se specific: CREATE TABLE FACTURIEMISE (NrFactura DECIMAL(8) NOT NULL, DataFactura DATE, CodClient DECIMAL(6) NOT NULL, ValoareTotala DECIMAL(15) not NULL, TVAColectata DECIMAL(14) , PRIMARY KEY (NrFactura),
FOREIGN KEY (CodClient) REFERENCES CLIENTI
ON DELETE RESTRICT)
Modificarea valorilor unor atribute

Pentru modificarea valorilor unuia sau multor atribute dintr-o tabel, comanda utilizat este UPDATE care are formatul general: UPDATE tabel SET atribut = expresie WHERE predicat Ca rezultat, vor fi modificate valorile atributului specificat, noile valori ale acestuia fiind cele care rezult n urma evalurii expresiei; modificarea se va produce pe toate liniile tabelei care ndeplinesc condiia specificat n predicat.
Exemplu 4 n tabela CLIENI, fiecrui client i-a fost atribuit un cod unic, ncepnd cu 1001. Dac din diferite motive, se dorete ca "numerotarea" clienilor s nceap de la 3001, pstrndu-se ordinea, se poate articula fraza UPDATE urmtoare:
UPDATE CLIENI SET CodClient = CodClient + 2000 Exemplul este suficient de neinspirat, deoarece n practic modificarea codului clienilor antreneaz modificarea valorilor acestui atribut n toate tabelele n care apare (n cazul nostru FACTURIEMISE), datorit faptului c este o cheie strin. 3.4.6. Aplica ii rezolvate 88
BAZE DE DATE
CURS PENTRU NVMNT LA DISTAN ntr-o entitate economic. Baza de date Data curenta (DATACRT) date Unitate de msur (UM) Varchar(3)
Se consider o aplicaie de gestiune economic care ruleaz (gest_ec) conine urmtoarele tabele: PRODUSE Cod depozit Cod Denumire Stoc (CODD) Produs Produs (STOC) (CODP) (DENP) Int(11) Int(11) Varchar(60) Double(12,3) PRETURI Cod produs (CODP) INT(11) COMENZI nr.comand (NRCOM) Int(11) Pret maxim (PRETMAX) DOUBLE(12,2) Cod produs (CODP) Int(10) Pret minim (PRETMIN) DOUBLE(12,2)
Data de inceput (DATAI) DATE
Data de sfrit (DATASF) DATE Pret (PRET) Double(10,2)
Cod client (CODCL) Int(10)
Data livrarii (DATAL) date
Cantitate (CANT) Double(10,2) Nr. De salariai (NRSAL) Int(2)
DEPOZITE Cod depozit(CODD) Int(10) SALARIATI Marca Nume (MARCA) (NUME) Int(10) CLIENI Cod client CODL Int(10) Char(50) Denumire client (DENCL) Char(50)
Denumire depozit (DEND) Varchar (50) Functie (FUNCT) Char(20) Cod depozit (CODD) Int(10) Salariu (SALA) Int(10)
Venit suplimentar (VENS) Int(10)
Cod superior (CODS) Int(10) Sold (SOLD) Double(12,3)
Cod fiscal Registrul CODFISC comertului (REGCOM) Char(20) Char(20)
Adresa (ADRESA) Char(50)
Telefon (TELEFON) Char(10)
1. S se creeze tabelele CREATE TABLE PRODUSE (CODD INTEGER NOT NULL, CODP INTEGER NOT NULL, DENP VARCHAR(50) NOT NULL, STOC DOUBLE(10,3), DATACRT DATE, UM VARCHAR(3), PRIMARY KEY (CODD,CODP), FOREIGN KEY (CODD) REFERENCES DEPOZITE(CODD), FOREIGN KEY (CODP) REFERENCES PRETURI(CODP) ); CREATE TABLE PRETURI (CODP INTEGER NOT NULL PRIMARY KEY, PRETMAX DOUBLE(10,2) NOT NULL, PRETMIN DOUBLE(10,2) NOT NULL, DATAI DATE NOT NULL, DATASF DATE NOT NULL, FOREIGN KEY (CODP) REFERENCES COMENZI(CODP)); CREATE TABLE COMENZI (NRCOM INTEGER NOT NULL, CODP INTEGER NOT NULL, CODC INTEGER NOT NULL, DATAL DATE, CANT DOUBLE(10,3) NOT NULL, PRET DOUBLE(10,2) NOT NULL, FOREIGN KEY (CODC) REFERENCES CLIENTI(CODC));
89
BAZE DE DATE
CREATE TABLE DEPOZITE (CODD INTEGER NOT NULL PRIMARY KEZ, DEND VARCHAR(50) NOT NULL, NRSAL INTEGER NOT NULL , DATACRT DATE, UM VARCHAR(3), FOREIGN KEY (CODD) REFERENCES SALARIATI(CODD)); CREATE TABLE SALARIATI (MARCA INTEGER NOT NULL PRIMARY KEY, NUME VARCHAR(50) NOT NULL, FUNCT VARCHAR(20), CODD INTEGER NOT NULL, SALA INTEGER NOT NULL, CODS INTEGER NOT NULL); CREATE TABLE CLIENTI (CODC INTEGER NOT NULL PRIMARY KEY , DENC VARCHAR(50) NOT NULL, CODFISCAL VARCHAR(20) NOT NULL, REGCOM VARCHAR(20) NOT NULL, ADRESA VARCHAR(50) NOT NULL, TELEFON VARCHAR(20) NOT NULL, SOLD DOUBLE(10,2)); 2. sa se insereze in tabela SALARIATI urmatoarele inregistrari Marca Nume Funct Codd Sala Vens Cods 1111 AVRAM ION VANZATOR 100000 21200 1000 1000 1222 BARBU DAN VANZATOR 120000 20750 2000 1000 1000 COMAN RADU SEF DEP 130000 35000 2500 1000 3500 DAN ION VANZATOR 160000 24500 3550 2500 2500 VLAD VASILE SEF DEP 160000 36500 1500 2500 3700 MANU DAN VANZATOR 160000 27500 2500 2500 2650 VLAD ION VANZATOR 120000 25060 3500 1000 Insert into salariati set marca=1111,nume=AVRAM ION,funct=vanzator, codd=100000, sala=21200, vens=1000, cods=1000; sau Insert into salariati value (1111,AVRAM ION,vanzator,100000,21200,1000,1000); 3. S se selecteze toate coloanele din tabela SALARIATI. SELECT * FROM SALARIATI; 4. Sa se selecteze coloanele MARCA,NUME,SALA,VENS din tabela SALARIATI; Select marca,nume,sala,vens from SALARIATI ; 5. Sa se selecteze NUME din tabela SALARIATI SELECT NUME FROM SALARIATI ; 6. Sa se selecteze coloana FUNCT din tabela SALARIATI in variantele utilizarii si neutilizarii clauzei distinct. A. SELECT FUNCT FROM SALARIATI ; B. SELECT DISTINCT FUNCT FROM SALARIATI; 7. Sa se selecteze toate inregistrarile privind salariatii al caror salariu este mai mare de 15000 lei. SELECT * FROM SALARIATI WHERE SALA>15000 ; 9. sa se selecteze coloanele MARCA,NUME si veniturile totale (SALA+VENS) pentru angajatii care au un salariu mai mare ca 35000 lei. SELECT MARCA,NUME, SALA+VENS FROM SALARIATI WHERE SALA>35000 ; 10. Sa se selecteze coloanele NUMA si FUNCT pentru salariatii care au functia de vanzator. Select nume,funct from salariati where funct= vanzator 11. Sa se selecteze coloanele MARCA,NUME, CODD din tabela SALARIATI, daca venitul este mai mare decat salariul. Select MARCA,NUME,CODD from SALARIATI where vens>sala ; 12. sa se selecteze si afiseze campurile MARCA,NUME, SALARIU pentru salariatii ale caror venituri suplimentare sunt mai mari ca 1500 lei si lucreaza in subordinea superiorului cu codul 1000. Select MARCA,NUME,SALA from salariati where vens>1500 and cods=1000 ; 13. sa se afiseze toate coloanele pentru salariatii cu functia vanzator, care au salariul mai mare ca 20000 lei si lucreaza in subordinea superiorului cu codul 1000. Select * from SALARIATI where sala>20000 and cods=1000 ; 90
BAZE DE DATE
14. sa se afiseze coloana NUME pentru angajatii care au salariul mai mic ca 21000 lei. Select NUME from salariati where sala < 21000 ; 15. sa se selecteze inregistrarile pentru care functia este SEF DEP sau salariul este mai mare ca 35000 lei. Select * from salariati where funct = SEF DEP or sala>35000 ; 16. sa se selecteze inregistrarile pentru care functia este vanzator si nu lucreaza in sbordinea superiorului cu codul 1000. Select * from salariati where funct = vanzator and cods!=1000 ; 17. sa se selecteze toti salariatii care lucreaza in subordinea superiorului cu codul 1000 , precum si cei care au salariul mai mic de 30000 lei sau functia de vanzator. Select * from salariati where funct= vanzator or sala <30000 and cods=1000 ; 18. sa se selecteze toate inregistrarile care contin date despre angajatii a caror functie este cea de sef de deposit sau care au un salariu de 35000 lei si lucreaza in subordinea superiorului cu codul 1000. Select * from salariati where funct= sef dep or (sala=35000 and cods=1000); 19. sa se selecteze marca si numele salariatilor care lucreaza in subordinea superiorului cu marca 1000 si care au functia de sef de deposit sau sau salariul in valoare de 35000 lei. Select * from salariati where (funct= sef dep or sala=35000) and cods=1000 ; 20. sa se afiseze valorile coloanelor marca, nume, funct privind angajatii care lucreaza in subordinea superiorului cu marca 1000 si au functia de sef de deposit sau vanzator. Select * from salariati where (funct= sef dep or funct= vanzator ) and cods=1000 ; 21. sa se selecteze MARCA,NUME, FUNCT pentru salariatii care au functia de sef de deposit sau pentru cei care lucreaza in subordinea superiorului cu marca 1000 si au functia de vanzator. Select * from salariati where funct= sef dep or (funct= vanzator and cods=1000) ; 23. sa se selecteze toti angajatii din tabela SALARIATI care nu au functia de vanzator. Select * from SALARIATI where not(funct=vanzator) ; 24. sa se selecteze valorile coloanelor MARCA,NUME, FUNCT,SALA+VENS pentru angajatii care au salariul cuprins intre 24500 si 36000. Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where sala between 24500 and 36000 ; 25. sa se selecteze campurile MARCA,NUME, FUNCT,SALA+VENS pentru angajatii care au salariul mai mic decat 24500 si mai mare decat 36000. Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where sala not between 24500 and 36000 ; 26. sa se selecteze campurile MARCA,NUME, FUNCT,SALA+VENS pentru angajatii care lucreaza in depozitul cu codurile 100000 sau 160000 Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where codd in (100000,160000); 27. sa se selecteze campurile MARCA,NUME, FUNCT,SALA+VENS pentru angajatii care au alta functie decat cea de vanzator. Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where funct not in (vanzator); 28. sa se selecteze campurile NUME,MARCA,FUNCT si veniturile suplimentare pentru angajatii al caror nume incepe cu litera C Select MARCA,NUME,FUNCT, VENS from SALARIATI where nume like C%; 29. sa se selecteze campurile MARCA,NUME, FUNCT,SALA+VENS pentru angajatii al caror nume se termina cu litera N. Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where nume like %N; 30. sa se selecteze campurile MARCA,NUME, FUNCT,SALA+VENS pentru angajatii al caror nume este format din noua caractere, pe ultima pozitie fiind N. Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where nume like ________N; 31. sa se selecteze angajatii al caror nume are pe pozitia a treia litera M. Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where nume like __M%; 32. 30. sa se selecteze campurile MARCA,NUME, FUNCT,SALA+VENS pentru angajatii al caror nume este format din noua caractere. 91
BAZE DE DATE
Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where nume like _________; 33. Sa se selecteze salariatii care nu venit suplimentar. Select * from salariati where vens is null ; 3.4.7. Probleme propuse
1.Sa se afiseze codul produsului, data de sfirsit si a unui nou termen de valabilitate a unui pret dat, calculat prin adaugarea a trei luni. Sa se selecteze doar produsele al caror cod este mai mic decit 13333 si data de sfirsit este mai mare decit data curenta plus trei luni. 2.Sa se afiseze numele, marca, raportul VENS/SALA si veniturile totale pentru sefii de depozite. Ordonarea datelor sa fie facuta crescator dupa valorile raportului mentionat. 3. Sa se afiseze media anuala a veniturilor totale (SALA+VENS) pentru salariatii cu functia 'VINZATO'. 4. Sa se selecteze codul produsului, data de sfarsit, data curenta, valorile expresiilor TRUNC(DATSF+90)TRUNC(SYSDATE) si DATASF+90. Selectia sa se realizeze pentru produsele cu codul mai mare ca13333 si data de sfirsit plus 90 de zile mai mare decit data curenta. 5. Sa se selecteze salariatii al caror nume are o lungime de noua caractere. 6. La selecteze coloanele CODP, DATASF la produsele cu codul mai mare ca 13333, afisand primele trei litere de la zi, luna in litere si anul cu patru cifre. 7. Sa se selecteze marca si numele salariatilor care lucreaza in subordinea superiorului cu marca 1000 si au functia sef de depozit sau salariul in valoare de 3500000 de lei. 8. Din tabela COMENZI (definita prin etichetele T1 si T2) sa se selecteze CODP, CODC, in conditiile in care valoarea comenzii este mai mare ca 500000 lei. (JOIN -ul unei tabele pe ea insasi). 9. Sa se selecteze coloanele NUME, MARCA, VENS, SALA+VENS din tabela SALARIATI, in conditiile in care codul superiorului este 1000.
10. Sa se afiseze cimpurile CODP, DENP, STOC si CANT, utilizand criteriul egalitatii OUTERJOIN, pe campul comun CODP (se afiseaza datele despre datele despre acele produse pentru care exista comenzi dar nu sunt in nomenclatorul de produse). Liniile sa fie ordonate crescator dupa campul CODP.
11.Sa se afiseze numele si marca acelor angajati al caror nume se pronunta asemanator cu DORU DAN. 12. Sa se selecteze campurile NUME si FUNCT ale salariatilor cu functia identica cu a lui RADU IOANA. 13. Sa se selecteze codul produsului, data maxima admisa de practicare a unui pret si data curenta pentru acele produse care indeplinesc conditia ca DATASF+10 sa fie mai mare decit SYSDATE, 14. Sa se selecteze cimpurile MARCA, NUME, SALA, VENS pentru salariatii care au alta functie decat cea de vanzator. 15. Sa se selecteze crescator dupa salariu, angajatii cu functia vinzator, si pentru care marca superiorului este 1000. 16. Sa se selecteze si afiseze valoarea medie zilnica a comenzilor ce trebuie onorate in perioada 01-03 Iulie 2005. 17. Sa se afiseze primele 5 carcatere din nume, marca si primul carcater din functie, pentru toti angajatii. 18. Sa se afiseze o situatie finala prin care sa fie redate cimpurile NUME si MARCA angajatului reunite intr-un camp comun, denumit "INFORMATIE" si cimpul venituri totale anuale denumit VENIT_ANUAL. Selectia este ceruta pentru angajatii cu codul superiorului egal cu 1000. 19. Sa se selecteze campurile NUME si CODD ale angajatilor cu codul superiorului 1000 si care au aceeasi functie cu DORU DAN. Sa se afiseze numai salariatii pentru care exista corespondenta de CODD in tabelele DEPOZITE si SALARIATI. Datele sa fie ordonate crescator dupa valorile CODD si NUME. 20.Sa se selecteze cimpurile CODP, DENP, PRET, PRETMAX, PRETMIN pentru produsele al caror pret negociat este cuprins intre pretul maxim si pretul minim. Ordonarea sa se faca crescator dupa campul CODP. 21. Din tabela COMENZI (definita prin etichetele T1 si T2) sa se selecteze CODP, CODC, in conditiile in care valoarea comenzii este mai mare ca 500000 lei. (JOIN -ul unei tabele pe ea insasi). 22. Sa se afiseze toate coloanele pentru salariatii cu functia vanzator, care au salariul mai mare ca 3500000 lei si lucreaza in subordinea superiorului cu codul 1000. 23. Sa se selecteze coloanele CODP, DATASF la produsele cu codul mai mare ca 13333, afisind ziua si luna in litere iar anul cu patru cifre. 24. Sa se selecteze coloanele MARCA, NUME, CODD, VENS ordonate crescator dupa codul depozitului si veniturile suplimentare.
92
BAZE DE DATE
25. Sa se selecteze toate coloanele din tabela SALARIATI. 26.Sa se afiseze valoarea totala a salariilor si veniturilor suplimentare pentru salariatii cu functia 'VINZATO'. 27. Sa se selecteze salariatii al caror nume are o lungime de noua caractere. 28. se selecteze coloanele MARCA, NUME, CODD din tabela SALARIATI, daca venitul suplimentar este mai mare decat salariul. 29. Sa se selecteze din tabela PRETURI valorile cimpului CODP si DATASF. Data de sfirsit (DATASF) sa se prezinte insotita de timpul intern, exprimat in diverse forme de afisare. 30. Sa se afiseze numarul de valori nenule inregistrate in coloana VENS din tabela SALARIATI.
Referinte bibliogafice 1. Moraru, S., Perniu, L. Web-applications on databases in electrical domain, Ed. Lux Libris, 2004. 2. Connolly, T., Begg, C., Strachan, A. Baze de date, Ed. Teora, 2000. 3. Connolly, T., Begg, C., Strachan, A. Database Systems A Practical Approach to Design, Implementation and Management, Addison Wesley Longman Limited 1995, 1998 4. Florescu, V. and co. Databases. Practical and Teoretical Approach, Infomega, 2001 5. Velicanu, M., Lungu, I., Bodea C., Ioni, C., Bdescu G. Database Management Systems, Editura Petrion, 2000 6. Popescu, I. Database Design, Editura Tehnic, 2001 7. Sabu G., Avram V. Computer Systems and Databases, Editura Oscar Print 8. Henderson, K. The Gurus Guide to Transact-SQL, Addison Wesley, 2000 9. Waymire, R., Sawtell, R. Sams Teach Zourself Microsoft SQL Server 2000 in 21 Days, Sams Publishing, 2001 10. Henderson, K. The Gurus Guide to SQL Server Stored Procedures, XML, and HTML Addison Weslwey, 2002 11. Reingruber, M. C., Gregory W. The Data Modeling Handbook, John Wiley & Sons, 1994. 12. Martin J. An end users guide to Data Base, Prentice Hall, 1981 13. Carter J. The relational database, Chapman & Hall, 1995 14. Fleming, von Halle, The Handbook of RelationalDatabase Design, Addison-Wesley. 15. Chen, P. P. The entity-relationship model: toward a unified view of data, ACM Trans. on Database Systems, 1976. 16. Batini, C., S. Ceri, S. B. Navathe, C. Batini Conceptual Database Design: an Entity/Relationship Approach, Addison-Wesley, Reading MA, 1991. 17. R. Jennings, P. Hipson Database Developer's Guide with Visual C++ 4, Second Edition, Sams Publishing, 1996 18. Date, C.J. An Introduction to Database Systems (5th ed.). CA: AddisonWesley, 1991. 19. Date, C.J. An Introduction to Database Systems (7th ed.). CA: AddisonWesley, 2000. 20. Elmasri, R., Navathe, S.B. Fundamentals of Database Systems (3rd ed.). CA: Addison-Wesley, 2000. 21. Johnson, J.L. Database: Model, Languages, Design. NY: Oxford University Press, 1997. 22. Robson, W. Strategic Management & Information Systems (2nd ed). Pitman, 1997. 23. Avery, B. The Relational Model, Kingston University, [PDF document] URL http://www.kingston.ac.uk/~ku12492/MBIT/model.pdf. 24. Brown, C.E. The Relational Model, Database learning module, http://www2.bus.orst.edu/faculty/brownc/lectures/db_tutor/relational_model.ht m#3.1%20Rela-tional%20Data%20Model%20Concepts. 25. Bull, M. Codds Rules for RDBMS, MB-online publication. West Yorkshire, 2002, URL http://hometown.aol.com/mbaddenda/art120.html. 93
BAZE DE DATE
26. Parkhurst, T. Codds 12 rules. DATA MANAGEMENT STRATEGIES, http://www.itworld.com/nl/db_mgr/09022002/pf_index.html, 2002, Feb. 9. 27. Rennhackkamp, M. Relational Integrity Control, DBMS online Server side. http://www.dbmsmag.com/9606d17.html, 1996 June. 28. Webopedia, Referential Integrity, http://www.webopedia.com/TERM/r/referential_integrity.html. 29. Codd, E. "Is Your DBMS Really Relational?" and "Does Your DBMS Run By the Rules?" ComputerWorld, October 14 and October 21, 1985. 30. Hernandez J. M. Database Design for Mere Mortals, Addison Wesley, 1996 31. Davies, C.T., Recovery Semantics for a DB/DC System, In Proc. ACM Annual Conference, 1973. 32. Eswaran, K.P., Gray, J.N., Lorie, R.A., Traiger, I.L. The Notions of Consistency and Predicate Locks in a Database System, CACM 19,11, 1976 33. Scheuerl, S, J.G. Modelling Recovery in Database Systems, School of Mathematical and Computational Sciences University of St Andrews, 1997 34. Yovits, M. C. Advances in Computers, Vol. 38. (Ed.), Academic Press, 1994. 35. Hernandez, M. J. Database design for mere mortals : a hands-on guide to relational database design, 2nd ed., Addison Wesley, 2003.
94

Baza de Date

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Baza de Date

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA TEFAN CEL MARE SUCEAVA FACULTATEA DE TIIN E ECONOMICE I ADMINISTRA IE PUBLIC SPECIALIZAREA : CONTABILITATE I INFORMATIC DE GESTIUNE FORMA

DE NV MNT : NV MNT LA DISTAN

PROF.UNIV.DR. VALERIU LUPU

CURS PENTRU NVMNT LA DISTAN

SUCEAVA 2010 2011

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

Data file 1 Data file 1 Data file 1 DBMS

2. MODELE I ARHITECTURI DE DATE

Logical child relationship Database 1 Database 2

CURS PENTRU NVMNT LA DISTAN

3. MODELUL RELAIONAL DE DATE

4. LIMBAJUL MYSQL AL BAZELOR DE DATE

CREATE VIEW v AS <expresie interogare>

CURS PENTRU NVMNT LA DISTAN

BAZE DE DATE Evoluia organizrii datelor

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

1.1.2. Limitele tratrii bazate pe fiiere

Separarea i izolarea datelor

CURS PENTRU NVMNT LA DISTAN

Date fiier 1 Date fiier 1 Date fiier 1

Figura 1.1. Fiiere: dependena aplicaie/date

Date fiier 1 Date fiier 1 Date fiier 1 SGBD

Figura 1.2. Baze de date: independena aplicaie/date

Formate de fiiere incompatibile

Interogarea static a programelor aplicaie

CURS PENTRU NVMNT LA DISTAN

1.1.3. Avantajele sistemelor de gestiune a bazelor de date

CURS PENTRU NVMNT LA DISTAN

1.1.4. Dezavantajele sistemelor de gestiune a bazelor de date

1.2. INDEPENDENA DATELOR. LIMBAJELE DE DEFINIRE I MANIPULARE A DATELOR

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

1.2.1. Independena de date

CURS PENTRU NVMNT LA DISTAN

1.2.2. Limbajele bazelor de date

1.2.2.1. Limbajul de definire a datelor

CURS PENTRU NVMNT LA DISTAN

1.2.2.1.1. Definirea schemei n SQL

ceea ce nu este acelai lucru cu:

CURS PENTRU NVMNT LA DISTAN

n care A reprezint atributul care trebuie eliminat din baza de date.

1.2.2.1.2. Utilizarea interogrilor SQL n cadrul aplicaiilor

1.2.2.2. Limbajul de manipulare a datelor

1.2.2.2.1. Extragerea informaiilor din bazele de date

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

Ordonarea afirii nregistrrilor

Relaii obinute prin cuplare

CURS PENTRU NVMNT LA DISTAN

Subinterogri imbricate Membru al unui set de nregistrri

Comparaii ntre seturi de nregistrri

Testarea relaiilor ce nu conin nregistrri

Testarea absenei tuplurilor duplicat

Modificrile bazei de date

CURS PENTRU NVMNT LA DISTAN

1.2.3. Alte caracteristici SQL

1.2.4. Query-By-Example (QBE)