Sist Gestiune Baze de Date

7/29/2019 Sist Gestiune Baze de Date

1/104

1

SISTEME DE GESTIUNE A BAZELOR DE DATE

1: SISTEME DE GESTIUNE A BAZELOR DE DATE RELAIONALE

1.1. Definiii, terminologie

Apariia i dezvoltarea calculatoarelor electronice au condus la amplificareaactivitilor legate de stocarea, interogarea i administrarea coleciilor de date. Astzi,cele mai multe dintre activitile noastre zilnice necesit accesarea i actualizareainformaiei dintr-o baz de date: extragerea unei sume de bani din contul bancar,rezervarea unei camere de hotel, cumprarea unui bilet de avion, mprumutarea uneicri de la bibliotec, pltirea facturilor de telefon, curent electric etc. Toate acestea sepot face rapid i n siguran pentru c datele respective sunt bine organizate ntr-obaz de datei administrate de un sistem de gestiune a bazelor de date.

Baz de date (BD) = o colecie de date aflate n relaie unele cu altele istructurat astfel nct s poat servi unui anumit scop= un set de date corelate i organizate n scopul prelucrrii lor rapide i concomitentede ctre mai multe persoane.Exemple

1) baza de date a unui muzeu, n care sunt nregistrate operele de art (grupate duptip, autor, tehnic de lucru) i expoziiile itinerante (descrise prin perioad, itinerariu,responsabil, custozi participani);2) baza de date a unui magazin de muzic, n care sunt nregistrate albumele demuzic n funcie tipul de suport fizic (CD, caset etc.), stil, autori, soliti, anul apariieietc.ObservaieTermenul "Database" (baz de date, n limba englez) a aprut pentru prima dat ntitlul unei conferine organizate la Santa Monica, SUA, n 1964: Development andManagement of Computer Centered DataBase.

Figura 1: Structura simplificat a unei baze de date

Sistem de gestiune a bazelor de date (SGBD) = un ansamblu de programe carepermit crearea i administrarea unei baze de date. Prin urmare, un SGBD (Database

Sistem de gestiune a bazei de date

Baza de date

Programe i aplicatii Utilizatori


2/104

2

Management System) este un pachet software de nivel nalt care permite proiectarea,construirea i administrarea bazelor de date dedicate rezolvrii problemelor din celemai variate domenii ale vieii reale.ExempleIMS, DB2(pn la DB9, de la IBM), Ingres II(de la Computer Associates InternationalInc.), Oracle 8i(de la Oracle Corporation), Ms Access(studiat n clasa a X-a), FoxPro(de la Microsoft), Paradox, Visual dBase (de la Borland), Sybase Adapted Server

(de la Sybase Inc.), IRIS(de la Hewlett-Packard).AtenieNu orice colecie de date este o baz de date. De exemplu, lista crilor dintr-obibliotec NU este o baz de date ci un simplu inventar de obiecte, o list, un tabel.Prin urmare, fa de un inventar (un tabel), o baz de date are urmtoarele proprieti: reprezint un anumit aspect al lumii reale, numit microuniversul bazei de date;orice modificare care se produce in acest microunivers se reflect n baza de date (deexemplu: cumprarea unei noi casete n vederea inchirierii, modificarea diferen eipermise ntre cursul de cumprare i cel de vnzare al valutei etc.); este o colecie de date coerent din punct de vedere logic i avnd un nelesintrinsec (de exemplu: din baza de date asociat bibliotecii liceului nu vor face parte

crile de telefon sau lista de materiale didactice din laboratorul de chimie); este proiectat, construit i populat cu date avnd permanent n vedere unanumit scop; o baz de date este destinat utilizrii de ctre un anumit grup depersoane i permite efectuarea unui anumit set de operaii.

Un SGBD foloseste in principiu trei limbaje: un limbaj de descriere al datelor fizice,un limbaj de descriere al datelor logice si un limbaj de prelucrare al datelor. Acestelimbaje pot fi de sine statatoare sau grefate pe un limbaj de programare general (deexemplu, C, COBOL, PL/I etc.).

Arhitectura bazelor de date evidentiaza componentele acestora: baza de date propriu-zisa in care se memoreaza datele; sistemul de gestiune a bazei de date, care realizeaza gestiunea siprelucrarea complexa a datelor;

un dictionar al bazei de date (metabaza de date ),ce contine informatiidespre date, despre structura acestora, statistici, documentatie; mijloace hard utilizate (comune sau specializate); reguli administrative destinate bunei functionari a intregului sistem. personalul implicat (utilizatori finali, administrator, programatori, operatori).

Dintre cerintele care se impun unei baze de date remarcam : sa furnizeze in timp util informatiile solicitate (timp de raspuns la o interogare ); sa asigure costuri minime deprelucrare si intretinere, redundanta minima; sa aiba capacitatea de a satisface cu aceleasi date, necesitatiile informationale,ale unui numar mare de utilizatori, sa permita adaptarea la cerinte noi, raspunsuri lainterogari neprevazute initial (flexibilitate ); sa permita exploatarea simultana a datelor de catre mai multi utilizatori(sincronizare); sa asigure securitatea datelor prin mecanisme de protectie impotriva accesuluineautorizat (confidentialitate); sa contina facilitati destinate validari datelor si recuperarii lor in cazul unordeteriorari accidentale (integritate); sa permita valorificarea eforturilor anterioare si anticiparea nevoilor viitoare(compatibilitate si expandabilitate); sa permita, prin ierarhizarea datelor dupa criteriul frecventei acceselor,reorganizari (eventual dinamice) care sporesc performantele bazei.


3/104

3

Cuvntul dat este de origine latini provine de la verbul a da. n limba englez,substantivul dat (date, la plural) se traduce prin datum (data, la plural). Exemple dedate sunt: cantitile de mere obinute anual ntr-o livad de pomi fructiferi, activitileturistice propuse de ghid participanilor la o excursie; modificrile climatice suferite de oregiune a globului terestru de-a lungul unui numr de ani, cursul bancar al unei valutede-a lungul unei luni sau a unui an calendaristic etc.

Exist o diferen esenial ntre date, informaii i cunotine:1. datele sunt informaii primare care au fost doar culese i inregistrate;2. informaiile sunt date prelucrate, structurate (validate, corectate, organizate,

sortate, relaionate);3. cunotinele sunt informaii contextualizate.Arhitectura sistemelor de gestiune a bazelor de date este puternic determinat demodelul de date al bazelor de date. Dincolo de defini iile date pn acum, ce este defapt o baz de date? Este un obiect (asemenea numerelor, funciilor, mulimilor)? Esteo metod (asemenea algoritmilor, procedurilor)?

O baz de date este n primul rnd un model al microuniversului la care serefer.Model = (n sens strict) un sistem teoretic sau material cu ajutorul cruia pot fi studiateindirect proprietile i transformrile unui alt sistem, mai complex, cu care primulsistem prezint o analogie;= (n sens larg) ceea ce poate servi ca orientare pentru reproduceri (un tipar). (cf. DEX)O baz de date ofer un anumit grad de abstractizare a datelor (asemenea celor maimulte limbaje de programare), ascunznd detaliile de implementare, detalii care nusunt necesare celor mai muli dintre utilizatori. Cu alte cuvinte, programele specificeunei baze de date nu depind de modul de stocare i accesare a datelor la nivel fizic.Acest concept se numete independen a datelor, se realizeaz cu ajutorul unuimodel de date (Data Model1) i este principalul mecanism care asigur partajareadatelor din baza de date ntre diferitele aplicaii care le acceseaz.Model de date = un ansamblu format din:1) o colecie de concepte necesare pentru descrierea structurii bazei de date (atipurilor de date incluse n baza de date, a relaiilor dintre ele i a restriciilor(Constraints) pe care trebuie s le respecte);

2) un set de operaii de baz (care s specifice modul de efectuare a extragerii iactualizrii datelor din baza de date).

1.2. Modele de date: perspectiv istoricEvoluia modelelor de date pentru bazele de date i SGBD-uri a fost sugestiv

sintetizat de R.G.G. Canttell n articolul su "What Are Next-Generation DBSystems?", publicat n revista Communications of the ACM, n octombrie 1991: "Istoriainformaticii a cunoscut multe generaii de sisteme de gestiune a datelor, ncepnd cusistemele de fiiere indexate, continund apoi cu sistemele de tip ierarhic i de tipreea, iar mai nou cu sistemele relaionale. Acum suntem pe punctul de a intra ntr-o nou generaie de sisteme de gestiune a bazelor de date care oferadministrare deobiecte, i care accept tipuri de date mult mai complexe".

Cu toate c a generat o activitate de cercetare foarte susinut dar i o activitate

practic, industrial extrem de productiv, domeniul bazelor de date este unul dintrecele mai tinere domenii ale informaticii. Este general acceptat faptul c "rdcinile" saletrebuie cutate aproximativ acum 40 de ani2 n obiectivul fixat de Preedintele J.F.Kennedy pentru programul Apollo: aducerea primului om pe Lun pn la sfritulanilor '60. In acel moment nu exista nici un instrument informatic care s funcionezeefectiv i care s poat administra uriaele volume de date implicate n programul

1 E.F. Codd este considerat a fi "printele" conceptului de model de date, n general, i alconceptului de model de date relaional, n particular.2Data apariiei primului sistem comercial de gestiune a bazelor de date


4/104

4

spaial. Ca urmare, North American Aviation (NAA) primul contractor al proiectului, adezvoltat un software bazat pe o structur ierarhic (prile se agreg n componentedin ce n ce mai ample) denumit GUAM(Generalized Update Access Method). Spremijlocul anilor '60, IBM s-a alturat NAA dezvoltnd n continuare GUAMi producndunul dintre primele sisteme comerciale de gestiune a bazelor de date: IMS(Information Management System). IBM a preluat modelul ierarhic pentru a respectacerina de stocare a datelor pe benzi magnetice (deci n acces secven ial). Ulterior,aceast restricie a fost nlturat i IMS continu s fie principalul SGBD ieirarhicutilizat de majoritatea calculatoarelor mainframe3.

Construirea bazelor de date a cunoscut o evoluie foarte rapid, trecnd prin maimulte abordri, clasificate dup cum urmeaz: sistemele de fiiere; sistemele prerelaionale (sau "istorice"4): ierarhic i reea, sistemul relaional; sistemele postrelaionale: orientat obiect i hibrid (obiect-relaional); sistemele semantice: multi-dimensional i logic (deductiv).

1.2.1. Modelele prerelaionale

Pot fi caracterizate ca modele de moment: au oferit solu ii pentru problemele

vremii lor dar nu au avut un fundament teoretic puternic i riguros.(I.) Sistemul de gestiune bazat pe fiiere, considerat de fapt un predecesor alsistemelor de gestiune a bazelor de date, este o colecie de programe care realizeaz fiecare cte "un serviciu" pentru utilizatorii datelor (de obicei: generarea derapoarte). Fiecare program i definea i i administra propriile date. Chiar dac a avutnumeroase dezavanataje (abordarea descentralizat n stocarea informaiilor, gradulmare de redundan i dependen program-date), sistemul de gestiune bazat pefiiere a constituit un salt semnificativ fa de fiierele administrate manual: saltul de laabordarea informaional la cea informatic.

(a) (b)

Figura 1: Modele de baze de date: (a) ierarhic; (b) reea

(II.) Att n modelul ierarhic ct i n modelul reea, datele erau reprezentate camulimi de inregistrri (n sensul limbajului de programare Pascal: colecii de date dediferite tipuri: Integer, Boolean, Real etc.). Relaiile dintre ele erau reprezentate prin

3 Un calculator mainframeeste un calculator cu capacitate de memorie i vitez de lucru foartemari, utilizat de marile corporaii pentru a stoca volume foarte mari de date i pentru a coordonasute sau mii de terminale (inclusiv calculatoare personale) conectate la el. Operarea unuimainframe necesit de obicei un personal specializat.4 numite i navigante sau tradiionale (legacy systems)


5/104

5

legaturi de tip pointer (adrese de locaii fizice de memorie). Inregistrrile care formaubaza de date erau organizate: n modelul ierarhic: ca o mulime de arbori; n modelul reea: ca o mulime de grafuri.

Ambele modele prerelaionale permiteau accesul la date de-a lungul unor drumuri(ci) predefinite, explicit stabilite la nivelul programelor de aplica ii (de unde i numelede modele navigante). Ca urmare, orice modificare a structurii bazei de date antrenamodificarea acestor ci n programele deja scrise. Exemple: pentru modelul ierarhic:IMS (amintit mai sus); pentru modelul reea: IDS II (de la Honeywell), IMAGE (de laHewlett Packard).

Aplicaie: Modelarea activitii didacticeIntr-o facultate, cadrele didacticedesfoaractiviti didacticede curssau examen;aceste activiti sunt pentru studeni i se desfoar n locaii (amfiteatre saulaboratoare). De asemenea, cadrele didactice particip la proiecte de cercetaretiinific. Figura 2 prezint modelul ierarhic al bazei de date; Figura 3 prezint modelulreea.

Figura 2: Modelul ierarhic

Figura 3: Modelul reea

Proiect Cadru didactic

Predare

Facultate

Student Cadru didacticActivitate didactic Locaie

Curs Examen Proiect

Examen

Inscriere

Desfurare

Facultate

Student

Activitate didactic

Locaie

Curs


6/104

6

1.2.2. Modelul relaional

Considerat drept cel mai important eveniment din istoria bazelor de date,apariia modelului relaional s-a produs n iunie 1970, odat cu publicarea n revistaCommunications of the ACM a articolului fundamental al lui Edgar Frank Codd5 (de laIBM Research Laboratory): "A Relational Model of Data for Large Shared Databanks".n acest articol, autorul aplica o serie de concepte din algebra relaional pentru arezolva problemele legate de stocarea volumelor mari de date

i enun

a "celebrele" 12

reguli (condiii) pe care trebuie s le ndeplineasc un SGBD pentru a fi declaratrelaional.

S amintim ns existena unui precursor: modelul bazat pe teoria mulimilor,propus de D.L. Childs n articolul su: "Feasability of a Set-Theoretical Data Structure",aprut n 1968 n Proc. Fall Joint Computer Conference.

Cele mai importante prototipuri de sisteme de gestiune a bazelor de date de tiprelaional au fost: System R, dezvoltat la San Jose Research Laboratory din California spre sfritulanilor '70. Acest model a condus la:

o apariia unui limbaj structurat de interogare a bazelor de date: SQL,o producerea mai multor SGBD-uri relaionale comerciale: DB2i SQL/DSde la

IBM i, respectiv, ORACLEde la Oracle Corporation (n deceniul 9 al secolului

trecut); INGRES (Interactive Graphics Retrival System), dezvoltat la UniversitateaBerkeley din California; Peterlee Relational Test Vehicle, dezvoltat la IBM UK Centre din Peterlee, MareaBritanie.

Numrul sistemelor relaionale comerciale a ajuns acum la cteva sute, dintrecare cele mai cunoscute sunt: DB2(de la IBM), Ingres II(de la Computer AssociatesInternational Inc.), Oracle 8i (de la Oracle Corporation), Ms Access, FoxPro (de laMicrosoft), Paradox, Visual dBase (de la Borland), Sybase Adapted Server (de laSybase Inc.). Succesul acestui model continu s fie att de mare nct multe sistemenerelaionale ofer acum i o interfa cu utilizatorii de tip relaional, indiferent demodelul de date pe care se bazeaz de fapt.

Modelul relaional s-a dovedit a fi i un instrument didactic ideal de prezentare a

principiilor bazelor de date, tocmai datorit fundamentrii sale riguroase pe principiilogice i matematice.Ce este de fapt un model relaional de date? Informal, l putem defini ca un model

n care: datele sunt percepute de utilizatori ca nite tabele i numai ca nite tabele; operaiile disponibile pentru utilizatori (spre exemplu, pentru obinerea informaiilor)sunt operaii care genereaz noi tabele pe baza tabelelor vechi: operaia de selecie(SELECT) extrage o submulime de rnduri dintr-o tabel, operaia de proiecie(PROJECT) extrage o submulime de coloane, operaia de juxtapunere (JOIN)asociaz dou tabele pe baza valorilor identice pe care le conin n anumite coloane,de asemenea identice; ori, toate aceste submulimi rezultate pot fi privite i ele nseleca nite tabele.

5 E.F. Codd s-a nscut la 23 august 1923 n Portland, Marea Britanie, i a murit n 18 aprilie2003, n Florida. A fcut studii de matematici chimie la Oxford i s-a mutat n Statele Unite n1948, pentru a lucra la IBM. A introdus termenul OLAP(OnLine Analytical Processing) i aimpus modelul relaional; a avut, de asemenea, contribuii n domeniul modelelor decalculabilitate prin lucrrile sale privind automatele celulare. A obinut de dou ori PremiulTuring: n 1981 i 1994.


7/104

7

(a) (b) (c)Figura 4: Operaii cu tabele: (a) selecie; (b) proiecie, (c) asociere

Numele modelului (model relaional) provine de la conceptul matematic derelaie. Aa cum o funcie f : {1, 2,,n} N R are mai multe reprezentriconvenionale, dintre care cea mai comod este cea de vector, tot astfel relaia poateavea mai multe reprezentri, una dintre ele fiind tabela. Din acest motiv, cel puin lanivel informal, termenii de relaie i tabel pot fi considerai sinonimi.

Principalele concepte cu care lucreaz modelul de date de tip relaional sunt(exemplificarea se face pentru baza de date asociat unui liceu): entitatea (Profesori, Elevi, PersonalAuxiliar, Clase etc.), relaia dintre entiti (PredLa, AreDirigintePe, AreLocIn etc.), atributul (Nume, GradDidactic, DataNaterii, NrLocuri, Locaie etc.).

1.2.3. Modelele postrelaionale

Chiar dac se regsete n descrierea unor situaii reale, cu o organizareintrinsec piramidal, modelul ierarhic i-a atins rapid limitele. La fel, modelul relaional adevenit impropriu pentru rezolvarea unor probleme din realitatea nconjurtoare carepresupun manipularea unor volume uriae de informaie, a unei mari varieti de tipuride date: hri meteorologice sau geografice necesare previziunilor meteorologice saudirijrii traficului, imagini transmise prin satelit utilizate n msurarea factorilor poluani,date neconvenionale pentru proiectarea asistat de calculator n inginerie sauarhitectur, serii dinamice implicate n tranzaciile bursiere sau bancare, stocareaobiectelor binare mari (BLOBs = Binary Large Objects) necesare n digitalizareainformaiei coninut n fiierele audio sau video. Au aprut astfel i s-au dezvoltatmodelele postrelaionale, de generaia a treia: modelul orientat obiect i modelulobiect-relaional.(I.) Modelul orientat obiect permite inglobarea semanticii obiectelor celor mai variate,

la fel ca n limbajele de programare orientate-obiect. De altfel, una dintre deosebirilemajore fa de modelul relaional const n distanarea de conceptul de independenfa de limbajele de programare i dezvoltarea conceptului de integrare a limbajelor deprogramare n sistemul de gestiune a bazei de date (invocarea unor funcii C++ maidegrab dect inglobarea unui limbaj special pentru interogarea datelor, ca de exempluSQL). Acest fapt a fost determinat de: utilizarea aproape exclusiv a limbajelor de programare orientate obiect pentrudezvoltarea aplicaiilor software; includerea n aproape orice aplicaie software a unei baze de date ca elementfundamental al acesteia.

Cele mai cunoscute prototipuri de baze de date orintate obiect sunt:OPENOODB(de la Texas Instruments), IRIS (de la Hewlett Packard), iar ca variantcomercial: GEMSTONE/OPAL (de la GemStone Systems), VERSANT(de la VersantObject Technology). Dei cu o cot de pia semnificativ inferioar sistemului relaional(150 milioane dolari fa de 10 miliarde, numai n SUA n anul 1999), modelul orientatobiect este creditat cu o cretere anual extrem de rapid: 50%.

n ciuda caracterului intuitiv i a altor avantaje evidente ale modelului orientatobiect, modelul relaional continu s domine piaa sistemelor de gestiune a bazelor dedate. Motivele sunt numeroase: fundamentarea matematic riguroas, simplitatea,volumul mare de date deja stocate dup acest model i costul enorm al migrrii spre unmodel complet diferit.


8/104

8

(II) Modelul hibrid extinde modelul relaional oferind un set de tipuri de date maibogat, i include i orientarea obiect. Se incearc astfel combinarea avantajelor celordou abordri: cea relaional i cea orientat obiect. Astfel, atributele i instaneleentitilor pot avea tipuri complexe i pot evita unele dintre restriciile specificemodelului relaional. De exemplu, n timp ce n modelul relaional fiecare atribut trebuies ia pentru fiecare instan a unei entiti o valoare i numai una din domeniul lui dedefiniie, n modelul hibrid poate lua un subset de valori (de exemplu: pentru un angajatoarecare, atributul Telefonpoate lua ca valori numrul telefonului fix de acasi de laservicu, al telefonului mobil propriu i de serviciu, dac angajatul dispune de toatepatru).

Cel mai cunoscut exemplu: Informix Universal Servercare combin tehnologiilerelaionale i orientate obiect din dou produse preexistente: Informix i Illustra.

Principalele avantaje i dezavantaje ale modelelor de date (i ale sistemelor degestiune a bazelor de date corespunztoare) au fost sintetizate de M. Stonebraker prindiagrama din Figura 7 (vezi [18]): modelul relaional permite realizarea chiarsimultan a unor interogri variate i rapide dar complexitatea datelor stocate nudifer prea mult de complexitatea datelor memorate n baze de date de tip ierarhic saureea; cu modelul orientat obiect se poate stoca informaie variati complex (de latexte la sunete i imagini) dar viteza de interogare (n cazul imaginilor i mai ales alsunetelor) este foarte sczut; modelul care pare s elimine toate dezavantajele i scumuleze toate avantajele modelelor anterioare este modelul obiect-relaional.

Figura 7: Clasificarea Michael Stonebraker pentrusistemele de gestiune a bazelor de date

SGBD relaionale SGBD hibride

SGBD prerelaionale SGBD orientate obiect

Faciliti deinterogare /asistena multi-user

Complexitatea datelor /posibile extinderi


9/104

9

1.3. Arhitectura SGBD

Datele din baza de date pot fi descrise pe trei nivele: extern, conceptual i intern:

Figura 5: Arhitectura ANSI6-SPARC7 pe 3 nivele pentru bazele de date

Nivelul extern reprezint modul n care utilizatorul percepe datele. Intruct anumitepri din baza de date sunt relevante pentru unii utilizatori dar irelevante pentru al ii

putem spune c o baz de date are attea nivele externe ci utilizatori o acceseaz.Mai mult, exist entiti care dei snt reprezentate n baza de date nu apar la acestnivel deoarece snt irelevante pentru anumii utilizatori.Nivelul intern (nivelul fizic) reprezint modul n care SGDB-ul i sistemul de operarepercep datele. La acest nivel:

este descris reprezentarea fizic a bazei de date n calculator (suntspecificate: spaiul de stocare a datelor, modul de stocare a acestora, structurilede date, organizarea fiierelor etc.);

sunt utilizate funcii ale sistemului de operare pentru plasarea datelor pedispozitivele de stocare, pentru construirea indecilor, pentru citirea datelor etc.;

Nivelul conceptual (nivelul logic) realizeaz trecerea de la nivelul intern la nivelulextern i asigur independena acestora. Acest nivel:

grupeaz percepiile tuturor utilizatorilor bazei de date (deoarece conine fiecareviziune (view) din nivelul extern, direct sau indirect);

conine structura logic a bazei de date descris prin conceptele de entitate,atribut i relaie, constrngeri referitoare la date, informaii de securitate iintegritate;

6 ANSI = American National Standards Institute7 SPARC = Standards Planning and Requirements Committee

Nivelul extern:

imaginea fiecruiutilizator asupra BD

Nivelul conceptual(structura logic a BD):ansamblul datelor stocaten BD i a relaiilor dintreele (fr detalii deimplementare)

Nivelul intern:implementarea fizic a BD(structuri de date,

indexare, acces)

Organizarea fizic a datelor,coordonat de SGBD isistemul de operare

Schema

extern 2

Schema

extern 3

Schema

extern 1

Schemaconceptual

Bazade date

Schemaintern


10/104

10

descrie datele stocate n baza de date i relaiile dintre ele dar nu conine detaliireferitoare modul de stocare a datelor pe suportul fizic (numrului de octeiocupai pe disc etc.).

Scopul arhitecturii pe cele trei nivele este acela de separare a percepiei fiecruiutilizator individual aspura datelor de modul de reprezentare fizic a acestora n bazade date. Figura 2 ilustreaz acest lucru reprezentnd nivelul intern, nivelul conceptuali dou vederi corespunztoare la nivelul extern: una aparinnd unui utilizator de PL/I,cealalt aparinnd unui utilizator de COBOL.

Nivel extern (PL/I) Nivel extern(COBOL)

DCL 1 ANG,2 ANG# CHAR(6),2 SAL FIXED BIN(31);

01 ANGAJ.02 CODANGAJ PIC X(6).02 CODDEPT PIC X(6).

Nivel conceptual

ANGAJATCOD_ANGAJAT CHARACTER (6)

COD_DEPARTAMENT CHARACTER (4)SALARIU NUMERIC (5)Nivel intern

STORED__ANG BYTES=20PREFIX TYPE=BYTE(6), OFFSET=0ANG# TYPE=BYTE(6), OFFSET=6, INDEX=ANGXDEPT# TYPE=BYTE(4), OFFSET=12SALAR TYPE=FULLWORD, OFFSET=16

Figura 6: Exemplu de arhitectur pe 3 niveluri

Observaie

n timp ce nivelele extern i conceptual trebuie s urmeze acelai model (relaional,orientat-obiect etc.), nivelul intern nu are nimic de a face cu modelul de date al bazei -el constnd din nregistrri memorate, pointeri, indeci etc.

Intr-o baza de date sunt necesare trei nivele de independenta a datelor: independenta fizica: asigura posibilitatea modificarii schemei fizice a datelorfara ca aceasta sa oblige la modificarea schemei conceptuale, schemei logice sia programelor de aplicatie. independenta logica: asigura posibilitatea modificarii schemei conceptuale adatelor fara ca aceasta sa oblige la modificarea schemei logice si aprogramelor de aplicatie. independenta fata de strategiile de acces: permite programului sa precizezedata pe care doreste sa o acceseze, dar nu modul cum acceseaza aceasta data.

SGBD va stabili drumul optim de acces la date.


11/104

11

Figura 7: Modelarea datelor i arhitectura ANSI-SPARC

1.4. Modelul conceptual al bazelor de date relatioanle

A. Prima etap a modelrii conceptuale

Aa cum am vzut n paragraful anterior, proiectarea unei baze de date incepe

cu analiza situaiei reale care trebuie modelat prin baza de date. Aceast analiznecesit un dialog ntre proiectantul bazei de date i viitorii ei utilizatori. Astfel, suntpuse n evident: cerinele utilizatorilor privind datele care trebuie stocate i administrate; cerinele utilizatorilor privind operaiile care trebuie efectuate cu aceste date.

Etapa urmtoare const n realizarea modelului conceptual al bazei de date. ncazul modelului relaional, se ncepe cu o descriere detailat a entititilor i atributelor,a relaiilor dintre entiti i a condiiilor pe care trebuie s le ndeplineasc. Aceastdescriere poate mbraca mai multe forme schema conceptual, diagrama entitate-relaie (diagrama ER).

B. Entiti, atribute, cheie primar

Conform Dicionarului Explicativ al Limbii Romne: o entitate este un coninut desine stttor, o existen determinat (ca ntindere, importan, valoare etc.). Inliteratura dedicat bazelor de date exist mai multe definiii pentru acest termen:DefiniiiEntitate = un "lucru" sau un "obiect" din lumea real care poate fi distins (deosebit) detoate celelalte lucruri sau obiecte = un obiect (precum o rachet, un tablou), uneveniment (precum naterea unei persoane, marcarea unui gol), o activitate (produciade oel a unei uzine, nchirierea unei maini) din lumea real care poate fi descris()prin caracteristici bine definite (despre care exist date care pot fi stocate).Definiii

Schemaextern

Stocarefizic

Schemaconceptual

Schemaintern

Proiectarea la nivel fizic

Proiectarea la nivel logic / conceptual


12/104

12

Entitate i InstanPrin entitate nelegem mulimea tuturor elementelor de un anumit tip (care prezintaceleai caracteristici distinctive).Prin instan a unei entiti nelegem un singur element, bine individualizat, unic, dinmulimea elementelor care formeaz entitatea respectiv.Observaie Entitile dintr-o baz de date pot fi disjuncte sau nu; n al doilea caz avem de aface cu subentiti (de exemlu, entitile Piloi i MecaniciDeBordsunt disjuncte isunt subentiti ale entitii PersonalNavigant). Intr-o baz de date pot exista entiti a cror existen este determinat deexistena altora (de exemplu, entitatea PersoaneInIntretinere depinde de entitateaSalariai); primele se numesc entiti dependente, celelalte se numesc entitiprincipale.DefiniieAtribut = o caracteristic a unei entiti.

Un atribut posed un numei pentru fiecare instan a entitii poate lua ovaloare dintr-o mulime fixat de valori, numitdomeniul de valori ale atributului.

Atributele se pot clasifica dupcomplexitate n: atribute compuse i atribute simple sau elementare, dup cum ele se mai pot

descompune sau nu n alte atribute, de mai mic complexitate. Exist atribute care nupot fi dect simple (atributele Capital, Suprafat, Continentale entitii Tari). Existns atribute care pot fi considerate fie simple, fie compuse. De exemplu: atributulDataNasteriicu valorile: 1 ianuarie 2000, 2 Mai 1990 etc. poate fi privit fie ca un atributsimplu, fie ca unul compus din atributele Zi, Lun, An. Este indicat s l tratm ca unatribut compus dac prevedem necesitatea de a avea acces direct la luna sau anul denatere al unei persoane nregistrate n baza de date. Dac ns o astfel de necesitatenu este probabil i dac dorim s simplificm structura entitii (i deci a bazei dedate) atunci este preferabil s l tratm ca atribut simplu;

Atributele se pot clasifica dupmulimea de valori n: atribute cu valori unice i atribute cu valori multile, dup cum ele pot lua pentruinstanele entitii respective cte o singur valoare (de exemplu, atributele Capital,Suprafat, Continentale entitii Tri) sau, dimpotriv, pentru unele instane pot lua

cte o singur valoare, pentru altele mai multe valori iar pentru altete nici o valoare (deexemplu, atributul OrasCuMinimum2MilioaneLocuitorial entitii Tri). Cnd este cazul,se pot defini limite inferioare i/sau superioare pentru numrul de valori pe care lepoate lua un astfel de atribut pentru o instan oarecare (de exemplu, putem specificafaptul c atributul NrTelefon al entitii Persoane poate lua minimum o valoare telefonul de serviciu i maximum trei.

Atributele se pot clasifica dupstabilitate n: atribute de bazi atribute derivate, dup cum ele au valori de sine stttoaresau care pot fi calculate din valorile altor atribute. De exemplu, s considerm entitilecorelate Cri, cu atributul NumrAutori i Autori, cu atributul Titlu; atributulNumrAutori este un atribut derivat: valorile pe care le ia pentru diferite instan e aleentitii Cri pot fi calculate pe baza numrului de apariii ale atributului Titlu pentrudiferite instane ale entitii Autori.

Utilizarea instanelor unei entiti ridic dou probleme foarte importante: modul de adresare a fiecrei instane a unei entiti; determinarea instanelor care se repet.Pentru a simplifica referirea la instanele unei entiti s-a recurs la mecanismulidentificatorului unic (sau al cheii primare).DefiniieIdentificatorul unic (sau cheie primar) = un atribut sau cea mai mic mulime deatribute ale unei entiti care iau, pentru fiecare instan a entitii respective, o valoarei numai una. Atunci cnd nici un atribut sau grup de atribute ale entitii rezonabil de


13/104

13

numeros nu ia valori disticte pentru fiecare instan a acesteia se poate aduga unatribut convenional care s ndeplineasc aceast condiie. De obicei, acest atributeste denumit cu ajutorul prefixelor cod sau id.

C. Relaii

Oridecteori un atribut al unei entiti se refer la alt entitate din baza de datese stabilete, de fapt, o relaie ntre cele dou entiti. Cnd proiectm baza de date,aceste referiri nu ar trebui s fie reprezentate ca atribute ale entitilor ci ca relaii (attn sensul real ct i n sensul matematic al cuvntului) ntre entiti. Atributele prin carese stabilete aceast relaie se numesc chei sau cmpuri de legatur.DefiniieRelaie ntr-o baz de date = o legtur logic ntre dou sau mai multe entiti.

Modelul conceptual al bazelor de date relaionale poate fi reprezentat printr-oschem conceptual sau printr-o diagram entitate-relaie.

Relaiile sunt caracterizate prin grad i cardinalitate (sau tip).DefiniieGradul unei relaii = numrul de entiti care particip la relaia respectiv.

Dup grad, relaiile pot fi binare (ntre dou entiti; de exemplu: relaia JoacIneste o relaie binar ntre

entitile Actorii Filme); ternare (ntre trei entiti; de exemplu: relaia LanseazMelodia este o relaieternar ntre entitile Compozitori, Textierii Soliti); n-are (ntre mai multe entiti; de exemplu: relaia Monteaz este o relaie de gradulcinci ntre entitile Regizori, Scenografi, DesigneriCostume, Actorii PieseDeTeatru).

Definiie Cardinalitatea (tipul) unei relaiibinare == numrul de instane ale celor dou entiti care sunt asociate prin relaia respectiv.

S considerm dou entiti E1i E2; dup cardinalitate (sau tip), relaiile dintrecele dou entiti pot fi 1 1 (one-to-one); 1 m (one-to-many); n m (many-to-many).

DefiniieRelaie 11 = o relaie ntre dou entiti E1 i E2 n care unei instane a entitii E1 iicorespunde o singura instan din entitatea E2 i reciproc.DefiniieRelaie 1m = o relaie ntre dou entiti E1 i E2 n care unei instane a entitii E1(numit entitate dominant) ii pot corespunde mai multe instane din entitatea E2 darunei instane din E2 nu-i poate corespunde dect cel mult o instan din E1 .DefiniieRelaie nm = o relaie ntre dou entiti E1 i E2 n care unei instane a entitii E1ii pot corespunde mai multe instane din entitatea E2 i, reciproc, unei instane dinentitatea E2 i pot corespunde mai multe instane din entitatea E1 .

D. Modelul relaional: fundamentarea teoreticConceptul matematic aflat la baza modelului relaional al bazelor de date este cel

de relaie:Definiie

Se numete relaie peste mulimile M1, M2, Mn orice submulime a produsului lorcartezian: R M1, x M2, x x MnExemplu


14/104

14

Fie mulimile Marca= {Dacia, Ford, Fiat, Audi, Opel, Volvo}, Tip= {benzin, motorin},CapacCil= {1100, 1200, 1300, 1400, 1600}, NrLoc= {4,5}, NrUi= {2, 4, 5}. Atunci,entitatea Automobilpoate fi reprezentat ca o relaie peste aceste mulimi:Automobil Marca x Tip x CapacCil x NrLoc x NrUi

Iat cteva instane ale acestei entiti: (Dacia, benzin, 1400, 5, 4), (Dacia, motorin,1400, 5, 4), (Dacia, benzin, 1100, 5, 4), (Dacia, motorin, 1400, 5, 5), (Ford, motorin,1400, 5, 5), (Ford, benzin, 1600, 5, 4), (Fiat, benzin, 1300, 5, 4), (Fiat, benzin,1100, 5, 4), (Audi, motorin, 1600, 5, 4), (Opel, benzin, 1400, 5, 5), (Volvo, benzin,1400, 5, 5), (Volvo, motorin, 1600, 5, 4).

Dac generalizm exemplul de mai sus obinem:E A1 x A2 x x Anunde am notat cu E entitatea i cu A1, A2, , An mulimile de valori (domeniile)atributelor sale. Un element al acestei relaii (adic un tuplu al produsului cartezian)reprezint o instan ei a entitii E i const din valori particulare ale atributelor.

Pentru simplitatea reprezentrii, entitile nu sunt reprezentate ca mulimi detupluri (ca n exemplul nostru de mai sus) ci ca tabele (vezi Tabelul 4), tot aa cum, nloc s notm cu


15/104

15

Figura 8: Implementarea unei relaii 1-1 n Ms Access

E.2. Rezolvarea relaiilor 1-m

n acest caz, trebuie s definim noiunea de cheie extern:Fie dou entiti U i V (de exemplu: Clasei Elevi) avnd atributele a1 (cheie

primar), a2, , an i respectiv b1 (cheie primar), b2, , bm, a1, (de exemplu:CodClas, Locaie, nrBanci, nrTable, respectiv CNP, Nume, Prenume, Adresa,CodClas). Prin cheie extern nelegem un atribut al entitii V a crui mulime devalori coincide cu mulimea valorilor cheii primare din entitatea U (aici: atributulCodClas este cheie primar pentru entitatea Clasei cheie extern pentru entitateaElevi).

Pentru a stabili o relaie 1-m ntre dou entiti (aici relaia InCareInva ntreentitile Clasei Elevi) procedm astfel:(1.) includem n descrirea ambelor entiti un acelai atribut (aici: CodClas);(2.) definim acest atribut drept cheie primar pentru entitatea principali drept cheie

extern pentru entitatea secundar.

E.3. Rezolvarea relaiilor n-m

In acest caz, ne bazm pe faptul c n modelul relaional nu numai entitile ci irelaiile dintre ele sunt relaii n sens matematic i, ca urmare, pot fi reprezentate printabele. Am observat, de asemenea, c relaiile dintre entiti pot avea atribute (inclusivchei primare).

Pentru a o stabili o relaie n-m ntre dou entiti (aici: relaia Comand ntreentitile Clienii Furnizori) procedm astfel:


16/104

16

(1.) includem n descrierea relaiei (aici: Comand) pe post de chei externe douatribute care s corespund atributelor care funcioneaz drept chei primare pentrucele dou entiti (aici: CodClienti CodFurnizor);

(2.) reducem astfel stabilirea unei relaii n-m (aici: relaia dintre Clienii Furnizori) lastabilirea a dou relaii 1-m (aici: relaiile dintre Clieni i Comand i respectivdintre Furnizorii Comand).

Figura 9: Implementarea unei relaii de tip n-m n Ms Access

F. Reguli de integritate pentru bazele de date

Dup modelarea bazei de date la nivel structural (definirea entitilor, a atributelor

lor i a relaiilor dintre ele) urmeaz nivelul operaional al modelrii: stabilirea tipurilor de operaii care se pot efectua asupra datelor stocate (sortare,

cutare, vizualizare, adugare, tergere, modificare etc., prezentate mai jos); verificarea respectrii regulilor de integritate (ceea ce va asigura corectitudinea i

consistena datelor).Distingem urmtoarele tipuri principale de reguli integritate:

a entitilor; a relaiior (numiti regula de integritate referenial);


17/104

17

La acestea se adaugi regulile de integritate impuse de situaia real modelat prinbaza de date, numite restriciile contextuale.

F.1. Valorea specialNull a atributelor

Pentru a putea formula prima regul de integritate trebuie s analizm situaiaunei valori speciale pe care o pot lua atributele entitilor: valoarea Null.DefiniieNull = valoarea pe care o ia un atribut pentru o instan a unei entiti atunci cndpentru respectiva instan: nu exist o valoare, exist o valoare dar nu a fost nregistrat (de exemplu, atributul

SerieNrCarteIdentitate), nu tim dac exist sau nu o valoare (de exemplu, atributul NrApartament).

Prin urmare, aceast valoare artificial, care nu trebuie confundat cu valoarea0 sau cu stringul vid a fost incorporat modelului relaional al bazelor de date pentrua permite tratarea excepiilor i a datelor incomplete. In ciuda alternativei, mult mai"nocive": introducerea unor date false, utilizarea valorii Null este inc destul decontroversat (E.F. Codd a susinut-o iar C.J. Date o respinge); exist SGBD-uri carenu implementeaz valoarea Null.

F.2. Integritatea entitilor

Prima regul de integritate se aplic cheilor primare.DefiniieOricare ar fi entitatea E din baza de date, nici un atribut care face parte din cheia saprimar nu poate lua valoarea Nullpentru nici o instan a entitii.

Dac am permite ca un atribut din componena cheii primare a entitii s iavaloarea Null, am contrazice cerina de minimalitate a cheii primare (ar insemna carestul atributelor care formeaz cheia i care iau numai valori din domeniile lorrespective de valori ar fi suficiente pentru a identifica n mod unic fiecare instan aentitii).

F.3. Integritatea referenial

A doua regul de integritate se aplic cheilor externe.DefiniieFie dou entiti U i V relaionate; pentru orice instan a entitii V (secundar)valoarea cheii externe trebuie s corespund valorii cheii primare a unei instaneoarecare a entitii U (principal) sau s fie Null.

Figura 10: Stabilirea integritii refereniale n Ms Access


18/104

18

F.4. Restricii contextuale

In etapa de analiz a situaiei reale care trebuie modelat prin baza de date, ndiscuiile dintre proiectanii bazei de date i viitorii ei proprietari i utilizatori, pot apreainformaii suplimentare privind restriciile pe care trebuie s le ndeplineasc datelestocate i operaiile efectuate asupra lor.DefiniieRestric

ii contextuale = reguli suplimentare privind modul de nregistrare a datelor

i

de efectuare a operaiilor, specifice situaiei reale sau impuse de diferitele categorii departicipani de proiectarea, construirea, administrarea i utilizarea bazei de date.

1.5. Normalizarea bazelor de date

A. Introducere: definiii, terminologie

Normalizarea poate fi privit ca ultima etap n proiectarea unei baze de date.Aa cum am vzut, acest proces de tip top-down ncepe cu identificareaprincipalelor entiti i relaii; urmeaz ca acestea s fie examinate (inclusiv la nivelulraporturilor dintre atributele care le caracterizeaz) n scopul eliminrii tuturor"defectelor" lor i transformrii ntr-un set de relaii adecvat, coerent i bine structurat.

Aceast tehnic a fost iniiat tot de E.F. Codd (a se vedea [6]). El a propus

iniial trei seturi de reguli pe care o relaie trebuie s le satisfac pentru a fi coerentipe care le-a denumit prima (FN1), a doua (FN2), respectiv a treia (FN3) form normal(dnd astfel i numele tehnicii nsi). Ulterior, R. Boyce a introdus, mpreun cu E.F.Codd, o definiie mai tare a FN3 denumit forma normal Boyce-Codd (FNBC). Infine, au mai fost definite nc dou forme normale: a patra (FN4) i a cincea (FN5)form normal, care ns au n vedere situaii destul de rar intalnite.

S remarcm caracterul "progresiv" al acestor forme normale (ilustrat i prinFigura 1): o relaie aflat n FN3 este automat n FN2 i deci i n FN1. De fapt,cteodat din punct de vedere al performanelor n exploatare este preferabil cabaza de date s fie lsat intr-o form normal inferioar (se execut procesul inversnormalizrii, denumit denormalizare a bazei de date).

Figura 11: Formele normale

Este justificat ntrebarea: cte forme normale mai ateapt s fie descoperite?Rspunsul a fost dat de R. Fagin n 1981 (a se vedea [11]). In acest articol esteintrodus o form normal care se bazeaz pe noiunile de domeniu de valori i cheieprimar (FN/DK)i se demonstreaz c o relaie este n FN/DK daci numai dac nuprezint anomalii la modificarea datelor. Aceast teorem arat c nu mai este nevoiede nicio alt form normal (cel puin din punctul de vedere al eliminrii anomaliilor lamodificarea datelor).Definiie


19/104

19

Normalizare = un proces prin care un set de relaii care ncalc anumite principii deproiectare este nlocuit cu un alt set de relaii adecvat, coerent i bine structurat.

Acest proces se desfoar n mai multe etape: n fiecare etap se urmreteeliminarea unui alt tip de defecte ale relaiilor astfel nct, pe msur ce relaiile trec nforme normale superioare, ele devin din ce n ce mai puin vulnerabile fa deanomaliile de actualizare a datelor.

Pentru a prezenta procesul de normalizare, este necesar s definim urmtoareledou concepte: anomalie la actualizare, dependen funcional.

Pentru simplificare, vom utiliza acolo unde este cazul reprezentarea printabele a entitilor i relaiilor din baza de date.

B. Anomalii la actualizare

Unul dintre principalele obiective n proiectarea bazelor de date este eliminarearedundanelor (a nregistrrii acelorai date de mai multe ori). Fie, de exemplu,entitile :Elevi {CNP, CodClas, Nume, Prenume, Adres};Clase {CodClas, Locaie, NrBanci, NrTable};

EleviClase {CNP, Nume, Prenume, Adres, CodClas, Locaie, NrBanci, NrTable}.Dac n baza de date includem tabelele Elevii Clasenu vom avea redundanen date; n schimb, dac includem tabelele Clase i EleviClase (sau Elevi iEleviClase) redundana va fi evident.

Tabelele care conin date redundante pot genera probleme n momentulactualizrii informaiei. Acestea se numesc anomalii la actualizare i sunt de treitipuri:1. anomalii la adugare;2. anomalii la tergere;3. anomalii la modificare.Le vom ilustra prin exemple pentru cazul n care n baza de date includem tabeleleClasei EleviClasedefinite n schema conceptual de mai sus:

CodClas Locaie NrBanci NrTableXIB Cam23 18 3XA Cam12 21 2IXC Cam15 18 2

(a) Entitatea Clase

CNP Nume Prn Adr CodCl Loc NrB NrT1900530123 Savu Ion B IXC Cam09 15 21900924456 Rosu R CJ XA Cam15 21 32900225789 Banu M B XA Cam15 21 32900807246 Rona C AR IXC Cam09 15 21901010357 Mares D DJ XIB Cam23 18 3

(b) Entitatea EleviClase

Figura 12: Dou relaii care pot produce anomalii de actualizare


20/104

20

(1.) Distingem dou tipuri de anomalii la adugare:(a.)

CNP Nume Prn Adr CodCl Loc NrB NrT1900530123 Savu Ion B IXC Cam09 15 21900924456 Rosu R CJ XA Cam15 21 32900225789 Banu M B XA Cam15 21 32900807246 Rona C AR IXC Cam09 15 21901010357 Mares D DJ XIB Cam23 18 31900404135 Olaru S TL XIB Cam23 18 32901010555 Manu D PL XIB Cam23 18 2

(b.)

CNP Nume Prn Adr CodCl Loc NrB NrT

1900530123 Savu Ion B XIB Cam23 18 31900924456 Rosu R CJ XIB Cam23 18 32900225789 Banu M B XA Cam15 21 32900807246 Rona C AR IXC Cam09 15 21901010357 Mares D DJ XIB Cam21 21 3Nul Null Nul Null XE Cam11 16 2

(2.) Anomalii la tergere

CodClas Locaie NrBanci NrTableXA Cam12 21 2IXC Cam15 18 2

CNP Nume Prn Adr CodCl Loc NrB NrT1900530123 Savu Ion B XIB Cam23 18 31900924456 Rosu R CJ XIB Cam23 18 32900225789 Banu M B XA Cam15 21 32900807246 Rona C AR IXC Cam09 15 2

1901010357 Mares D DJ XIB Cam21 21 3

Figura 14: Adugarea unei noi clase (n care nu exist ncelevi) necesit introducerea valorii Nulln celulele destinate

datelor despre elevi, deci inclusiv n cheia primar. Acestlucru contravine regulii de integritate a entitilor

Figura 15: Datele despre clasa a XIB au fost terse din tabela Clasedar datele elevilor din acea clas au rmas n tabela EleviClase

Figura 13 : Repetarea datelor despre clas lanregistrarea fiecrui nou elev trebuie s se fac exact


21/104

21

(3.) Anomalii la modificare

CodClas Locaie NrBanci NrTableXIB Cam23 20 4XA Cam12 21 2IXC Cam15 18 2

CNP Nume Prn Adr CodCl Loc NrB NrT1900530123 Savu Ion B XIB Cam23 18 31900924456 Rosu R CJ XIB Cam23 18 32900225789 Banu M B XA Cam15 21 32900807246 Rona C AR IXC Cam09 15 21901010357 Mares D DJ XIB Cam21 21 3

C. Dependene funcionaleProcesul de normalizare se bazeaz pe examinarea relaiilor dintre atributele

entitilor, oglindite prin conceptul de dependen funcional.DefiniieDependen funcional= o restricie care apare ntre atributele unei entiti la nivelulsemanticii (semnificaiei) acestora: fie a1 i a2 atributele unei entiti E; spunem catributul a2 este dependent funcional de atributul a1 dac fiecrei valori a atributuluia1 i corespunde o valoare i numai una a atributului a2 .Observaie Observm c unei valori a atributului a2 i pot corespunde mai multe valori aleatributului a1. (putem spune c a1 este argumentul iar a2 este imaginea unei funciin sensul matematic al cuvntului). Se pot afla n dependen funcional nu numai atribute individuale ci i grupuri deatribute. Vom ignora dependenele triviale, adic dependenele a1 a2 n care a2depinde funcional de un subset al a1.

Notm dependena funcional a atributelor a1 i a2 prina1 a2i o reprezentm grafic ca n Figura 7.

Figura 17: Reprezentarea grafic a dependenei funcionale

DefiniieDeterminantul unei dependene funcionale = atributul care, prin valorile sale,determin valorile celuilalt atribut (adic: atributul aflat, n oricare dintre cele doureprezentri, n stnga sgeii).ObservaieExaminarea dependenelor funcionale dintre atributele unei entiti ne permite sdeterminm care dintre cheile candidate trebuie s fie aleas drept cheie primar: este

Figura 16: In tabela Clase s-au operat modificri n datelecare descriu una dintre clase dar n tabela EleviClase au

rmas nc datele vechi despre respectiva clas

atributul a2 depinde

funcional de a1a1 a2


22/104

22

aleas cheia candidat care apare ca determinant n toate dependenele funcionaleidentificate la nivelul entitii respective (a se vedea al doilea exemplu de mai sus.

D. Procesul de normalizare

Normalizarea unei baze de date este un proces care se desfoar n mai mulipai. Fiecare pas (cu excepia aducerii bazei de date la FN1) presupune:1. identificarea dependenelor funcionale;2. verificarea ndeplinirii unor anumite proprieti denumite generic forme normale.

Pe msur ce procesul de normalizare progreseaz, relaiile care compun bazade date (fie c acestea corespund unor entiti sau unor relaii dintre entiti) devin dince n ce mai riguroase (forma normal pe care o satisfac este mai restrictiv: a sevedea Figura 1 de mai sus).

Din punctul de vedere al modelului relaional, singura form normal obligatoriepentru toate relaiile din baza de date este FN1; dac ns dorim s evitm toateanomaliile de actualizare (analizate mai sus) este necesar s continum procesul denormalizare cel puin pn la FN3.ObservaieReamintim faptul c n modelul relaional, orice entitate i relaie dintre entiti estemodelat matematic prin conceptul de relaie i reprezentat convenional printr-o

tabel. In continuare, prin relaie vom nelege modelul matematic al unei entiti sau alunei relaii ntre entiti, reprezentat convenional printr-o tabel, ca mai sus.

E. Prima form normal (FN1)

Dup definirea structurii i a operaiilor cu baza de date, urmeaz introducereadatelor (crearea instanelor entitilor i a relaiilor dintre ele). Acest lucru nseamn n principal transferarea datelor concrete din formularele de culegere a datelor ntabelele asociate entitilor / relaiilor. Dup parcurgerea acestui pas, se obin deobicei tabele nenormalizate, adic tabele n care unele celule conin mai multevalori ale aceluiai atribut sau repet valori din alte celule.

ExempluFie baza de date a unei firme de transport auto care se ocup cu transportul de

persoane; dintre entitile care apar intr-o astfel de baz de date enumerm: Angajai,Vehicule, Garaje, Clieni, Trasee. S presupunem c formularele de culegere datecompletate de eful fiecrui garaj conin (pe lng adresa garajului): tipul vehiculelordeinute (limuzin, microbuz, autocar), numerele de nmatriculare ale acestora, datelede identificare ale oferilor care le conduc. Transcrirea direct a datelor din acesteformulare n tabela Garaje poate conduce la rezultatul din Figura 15.

Figura 18: Tabela Garaje11 n Ms Access


23/104

23

Dac examinm celulele din coloana tipAuto (precum i din coloana Soferi)constatm c tabela Garaje se afl n form nenormalizat. Ca urmare, tabelatrebuie trecut n FN1.DefiniieRelaie aflat n prima forma normal (FN1) = o relaie cu proprietatea c oricaredintre celulele tabelei care o reprezint convenional conine o valoare i numai una (nuexist atribute cu valori multiple).

Se cunosc dou metode de a aduce o relaie n FN1; o vom prezenta pe cea maieficient dintre ele (vom presupune c un singur atribut nu respect condiia din FN1):Aducerea unei relaii la FN1

Fie E o entitate (aici: Garaje), a atributul su (aici: tipAuto) responsabil pentru formanenormalizat a tabelei T corespunztoare entitii (aici: tabela Garaje11).Aducerea tabelei la FN1 necesit:(1.) eliminarea atributului a din entitatea E / a coloanei corespunztoare din tabelaT (aici: a coloanei TipAuto din tabela Garaje11; denumim Garaje22 tabela astfelrezultat);(2.) crearea pornind de la atributul a a unei noi entiti E'; fie T' tabela care o

reprezint (aici: pe baza atributului TipAutocrem entitatea Vehiculecu cheia primarNrInmatri atributele: TipAuto, Marca, NrStele, NrLocuri, Culoare);(3.) stabilirea relaiei dintre cele dou entiti, relaie care este dup caz de tip 1-msau n-m (aici: relaia dintre entitile Garaje i Vehicule este de tip 1-m). Prinurmare, cheia primar a entitii E trebuie s inclus cu rol de cheie extern printre atributele entitii E' (aici: includem atributul CodGaraj cu rol de cheieprimar pentru entitatea Garaje pe post de cheie extern pentru entitatea Vehicule).

Figura 19: Tabela Garaje dup prima modificare


24/104

24

Figura 20: Tabela nou creat, Vehicule

Figura 21: Relaiile dintre noile tabele

Atenie

Intr-o relaie pot exista mai multe atribute cu valori multiple, deci care s fie fiecare larndul su responsabile pentru forma nenormalizat a relaiei (tabelei). In acest caz,aducerea relaiei la FN1 se desfoare n tot atia pai cte astfel de atribute exist(aici: noua tabel Garaje22 este tot n form nenormalizat din cauza atributuluiSoferi). Prin urmare, vom proceda pentru acest atribut aa cum am procedat i pentruatributul TipAuto: a se vedea Figura 12 (tabela Garaje33 aflat acum n FN1) iFigura 13 (tabela Soferinou creat) precum i Figura 14 (tabela de jonciune Conducprin care vom realiza relaia de tip nm dintre entitile nou create Soferi i

Vehicule).


25/104

25

Figura 22: Tabela Garaje33 (complet normalizat)

Figura 23: Tabela nou creat, Soferi


26/104

26

Figura 24: Tabela de jocntiune Conduce

Atenie

Procesul de aducere la FN1 a evideniat necesitatea inregistrrii unor informaiinoi: numerele de nmatriculare ale autovehiculelor (la primul pas), datele personale aleoferilor (la al doilea pas). Pe de alt parte, n forma iniial, nenormalizat, tabelaGaraje11 coninea o serie de informaii auxiliare (ce tip de vehicule se afl n fiecaregaraj, ce oferi le conduc) care se pot pierde la normalizare. Acest lucru poate fi evitatdac ntre noile entiti aprute prin normalizare se stabilesc relaiile corespunztoare(aici: la primul pas s-a stabilit o relaie 1-m ntre entitatea Garaje modificat ientitatea Vehicule nou creat, iar la pasul al doilea s-a stabilit o relaie nm ntreentitile nou create Soferi i Vehicule, deoarece n principiu un ofer poateconduce mai multe vehicule i un vehicul poate fi condus de mai muli oferi iar orestricie contextual a bazei de date poate stipula ce vehicule poate conduce fiecareofer i ce oferi pot conduce fiecare vehicul. De aceea, am creat tabela de jonciuneConduc cu atributele CNP, NrInmatr. Acestea sunt chei primare n tabelele Soferirespectiv Vehicule i sunt chei externe n tabela Conduc, dar formeaz mpreuncheia primar pentru tabela Conduc).


27/104

27

Figura 25: Setul de relaii rezultat dup incheierea operatieide aducere la FN1 a entitii Garaje

F. A doua form normal (FN2)

O relaie care este n FN1 dar nu este n FN2 poate suferi de anomalii demodificare, ca n exemplul de mai jos.Exemplu

Fie baza de date a unui institut de cercetri care are mai multe filiale i n caresalariaii sunt pltii n funcie de numrul de ore lucrate n cadrul unui proiect decercetare sau al altuia. Dintre entitile care apar ntr-o astfel de baz de dateenumerm: Filiale = {CodFil, NumeFil, LocFil}, Angajai = {CNP, CodFil, NumeAng,Adresa, SalariuPeOra}, Proiecte = {CodPrj, TitluPrj, CodFil, DataPredrii}. Pe lngacestea, am mai introdus n baza de date i entitatea AngajaiProiecte = {CNP,NumeAng, CodPrj, TitluPrj, NrOre,DataPredrii} cu instanele din Figura 16.S presupunem c data de predare a proiectului tr1 a fost devansat cu o lun; dacnu operm aceast modificare n ambele nregistrri din tabel care se refer la acestproiect atunci apare o anomalie de actualizare i baza de date ii pierde consistena.


28/104

28

Figura 26: Tabela AngajaiProiecte

Observaie

FN2 se refer numai la relaii a cror cheie primar este format din mai multe atributedeoarece se bazeaz pe conceptul de dependen funcional complet.DefiniieDependena funcional complet

Fie a1 i a2 dou (mulimi de) atribute ale entitii E; spunem c a2 este completdependent funcional de a1 daci numai dac a2 este dependent funcional de a1dar nu este dependent funcional de nicio submulime proprie a lui a1.Dac, dimpotriv, putem elimina un atribut din mulimea de atribute a1 iar a2 continus fie dependent funcional de a1 atunci spunem c a2 este doar parial dependentfuncional de a1.ContraexempluS examinm relaia Vehicule din exemplul de mai sus: dependena funcionalNrInmatr, TipAutoCodGarajnu este complet: atributul CodGaraj este dependent funcional de un subset al{NrInmatr, TipAuto}, i anume de NrInmatr.DefiniieA doua form normal

O relaie este n FN2 daci numai dac:(1) este deja n FN1;(2) oricare dintre atributele sale care nu fac parte din cheia primar este completdependent funcional de cheia primar.Aducerea unei relaii la FN2

Fie E o entitate aflat n FN1; aducerea ei la FN2 necesit:(1.) identificarea tuturor dependen

elor func

ionale dintre atributele entit

ii E;

(2.) descompunerea relaiei E ntr-un numr de noi relaii astfel:o fiecare dependen funcional complet definete o nou relaie;o din fiecare dependen funcional parial se elimin acea parte a cheii

primare care este rspunztoare de incompletitudinea dependenei i apoi sedefinete noua relaie.

(3.) stabilirea relaiilor dintre noile entiti (n scopul recuperrii informaii de legatur,pierdute eventual prin inlocuirea entitii iniiale cu entitile normalizate).Aducerea unei relaii la FN2


29/104

29

Ilustrm metoda de mai sus pentru entitatea AngajaiProiectedin Figura 17. Laprima vedere, fiecare dintre atributele entitii: NumeAng, titluPrj, nrOre,dataPredriidepinde funcional de cheia primar a acesteia: CNP, codPrj. Aplicnd definiiadependenei funcionale complete observm c numai atributul nrOre depindefuncional complet de ambele atribute care formeaz cheia primar (a se vedeadependena funcional d.f.1 din Figura 17). Celelalte dependene sunt pariale; din eleobinem urmtoarele dependene complete: d.f.2 i d.f.3. Ca urmare, vom nlocuientitatea AngajaiProiecte cu entitile AP1, AP2, AP3 (Figura 18) i vom stabilirelaiile dintre ele.

d.f.2

d.f.1

CNP codPrj nrOre NumeAng titluPrj dataPredrii

d.f.3

Figura 27: Dependenele funcionale complete din entitatea AngajaiProiecte

AP1 AP2

AP3

codPrj titluPrj dataPredrii

Figura 27: Normalizarea entitii AngajaiProiecte

Figura 28: Relaiile dintre noile tabele aflate n FN2

CNP NumeAngCNP codPrj nrOre


30/104

30

G. A treia form normal (FN3)

O relaie care este n FN2 dar nu este n FN3 poate suferi de anomalii demodificare, ca n exemplul de mai jos.ExempluFie baza de date a institutului de cercetri descris n paragraful anterior. Spresupunem c am mai introdus n baza de date i entitatea AngajaiFiliale = {CNP,NumeAng, Adresa, Oras, CodFil, NumeFil,LocFil} cu instan

ele din Figura 20.

In cazul n care una dintre filiale ii schimb sediul (de exemplu filiala CercAero semut de la Hui la Iai), operarea modificrii numai n una dintre cele dou nregistrricare se refer la filiala respectiv determin apariia unei anomalii de actualizare ibaza de date ii pierde consistena.

Figura 29: Tabela AngajaiFilialeObservaieFN3 se bazeaz pe conceptul de dependene funcionale tranzitive.DefiniieDependene funcioanle tranzitive

Fie a1 , a2 i a3 trei atribute ale unei entii Ecu proprietatea c:(1) a1 a2 i a2 a3(2) a1 nu depinde funcional nici de a2 nici de a3Atunci: a1 a3 ( a3 depinde funcional de a1 via a2).

ExempluS examinm relaia EleviClasedin paragraful 4.2:

CNP Nume Prn Adr CodCl Loc NrB NrT

1900530123 Savu Ion B IXC Cam09 15 2

1900924456 Rosu R CJ XA Cam15 21 3

2900225789 Banu M B XA Cam15 21 3

2900807246 Rona C AR IXC Cam09 15 2

1901010357 Mares D DJ XIB Cam23 18 3

Avem urmtoarele dependene funcionale: CNPCodCli CodClLoc; atunci avem i CNPLoc via atributul CodCl deoarece atributul

CNP nu depinde funcional nici de CodCl nici de Loc.


31/104

31

DefiniieA treia form normal

O relaie este n FN3 daci numai dac:(1) este deja n FN2;(2) nici unul dintre atributele sale care nu fac parte din cheia primar nu este, prin

tranzitivitate, dependent funcional de cheia primar.Aducerea unei relaii la FN3

Fie E o entitate (aici: AngajaiFiliale) aflat n FN2 i a1 , a2 i a3 trei atribute alesale cu proprietatea c: a1 a2 i a2 a3 (aici: CNP, CodFil, LocFil : CNPCodFil, CodFil LocFil):Aducerea tabelei la FN3 necesit:(1.) identificarea tuturor dependenelor tranzitive dintre atributele entitii E;(2.) descompunerea relaiei E ntr-un numr de noi relaii astfel:o atributul a1 impreun cu toate atributele care depind funcional de el (deci

inclusiv a2 ) formeaz o nou relaie (aici: atributele CNP, NumeAng, Adresa,Oras, codFil formeaz entitatea Ang1);

o atributul a2 impreun cu atributul a3 i cu alte atribute care depind funcionalde a1 prin tranzitivitate formeaz o nou relaie (aici: atributul NumeFil seadaug atributelor CodFil i LocFil pentru a forma entitatea Fil1);

(3.) definirea atributului a2 drept cheie primar a celei de-a doua entiti nou create;(4.) stabilirea relaiilor dintre noile entiti (n scopul recuperrii informaiilor delegatur, pierdute eventual prin inlocuirea entitii iniiale cu entiti normalizate).

CNP NumeAng Adresa Oras CodFil NumeFil LocFil

Figura 30: Dependenele funcionale tranzitive din entitatea AngajaiFiliale

CNP NumeAng Adresa Oras CodFil

Figura 31: Normalizarea entitii AngajaiFiliale

Observaie

Observm c atributul care asigur tranzitivitatea (atributul notat a2) nu este nici cheieprimar n relaia respectiv nici mcar parte a cheii primare. Tocmai din acest motiv,dependena a2 a3 nu este dezirabil la nivelul relaiei respective.

CodFil NumeFil LocFil


32/104

32

Condiie de verificat Soluie (normalizare)

FN1 Toate atributele relaieitrebuie s fie atomiceFiecare atribut neatomic setransform intr-o nou relaie

FN2

Relaia este n FN1; Cheia sa primar

const

din mai multe atribute; Toate atributele care nufac parte din cheia primarsunt complet dependentefuncional de cheia primar

Fiecare parte a cheii primare,mpreun cu atributele caredepind funcional complet de eaformeaz o nou relaie; Se stabilesc relaiile necesarentre noile relaii care au nlocuit-o pe cea iniial

FN3

Relaia este n FN2; Nici un atribut care nuface parte dintr-o cheiecandidat nu este funcionaldependent de un alt atributcare nu face nici el partedintr-o cheie candidat (nici

un atribut care nu faceparte dintr-o cheiecandidat nu este funcionaldependent de cheiaprimar prin tranzitivitate)

Se pstreaz n relaia iniialnumai cheia primari atributelecare depind funcional de eadirect (inclusiv atributul"incriminat"); Se creeaz cte o nourelaie din fiecare atribut care nu

face parte din cheia primarmpreun cu toate atributele(care nu fac nici ele parte dincheia primar a relaiei iniiale)care sunt dependente funcionalde acesta; Se stabilesc relaiile necesarentre noile relaii i relaia iniialmodificat

Tabelul 6: Recapitulare a primelor trei etape din procesul de normalizare

1.6. Trecerea de la modelul conceptual la modelul fizic

Dup cum ami observat n capitolele anterioare, regulile ce se pot extrage dintr-un studiu de caz pot fi descrise prin elemente ale modelului conceptual: entiti,atribute, identificatori unici, relaii ntre entiti.

Acest model poate fi utilizat pentru determinarea modelului fizic al oricrui tip debaz de date.

La nivelul modelului fizic: tabela este o structur utilizat pentru stocarea i organizarea datelor. Tabelelesunt formate din linii i coloane; fiecare coloan va reine date de un anumit tip i corespunde unui atribut alentitii; numele atributului devine antetul unei coloane din tabel; un rnd din tabel corespunde unui element al entitii (instan a entitii) i senumete nregistrare. Aceasta va descrie complet proprietile unei instane;

cheie primar este reprezentat de o coloan sau o combinaie de coloane alecror valori sunt unice la nivelul tabelei i sunt completate obligatoriu. Cheile primareprovin din identificatorii unici ai entitii.

Crearea unei tabele se realizeaz n dou etape:1. n prima etap se stabilete structura tabelei, specificndu-se numele cmpurilor,

lungimile acestora, precum i tipul informaiilor care vor fi introduse n fiecarecmp.

2. n a doua etap se ncarc efectiv datele n tabel.


33/104

33

A. Exemplificare n limbajul de programare ACCESS

Dup definirea structurii putem trece la introducerea propriu-zis a datelor ncmpurile tabelei, ncheind astfel operaia de creare (ulterior, tabela va putea fi folositn operaii de modificare a structurii sau de actualizare a datelor). Pentru aceasta:Pas 1. se afieaz tabela n modul Datasheet View Pas 2. se introduc direct datele n cmpurile corespunztoare (se plaseaz cursorul

n celul, se tasteaz valoarea i se acioneaz tasta ENTER). Se folosete tasta TABpentru a trece dintr-o celul n alta. Se folosesc tastele cu sgei pentru a parcurgetabela pe orizontali pe vertical.

B. Exemplificare n limbajul de programare FOXPRO

A) Introducerea datelor

Adugarea articolelor se face la sfritul tabeleiactive. Adugarea unui articol vid se realizeaz cu ajutorulcomenzii APPEND BLANK. Un cmp vid are una dinvalorile: zero pentru cmpul numeric, spaiu pentrucmpul caracter, .F. (fals) pentru cmpurile logice,valoarea {/ /} pentru dat calendaristic.

Structura tabelei se creeaz prin comanda (de exemplu:tabela Elevi):create tableelevi (numr_matricol n(5), nume c(5),prenume c(13), data_naterii d, clasa c(2) )

Se adaug nregistrrile folosind o structur de controlrepetitiv cu numr cunoscut de pai (for), comenzi deafiare pe ecran de elemente de control ncepnd de la olinie i o coloan specificat (de tipul l, c say [introducei...]) i comanda de tipul read (ce realizeaz adugareaefectiv a datelor citite n nregistrarea vid).

fori=1 to8 doappendblank@4,4 say[numr matricol:] getnumr_matricol

@5,4 say[nume:] getnume@6,4 say[prenume:] getprenume@7,4 say[data naterii:] getdata_naterii@8,4 say[clasa:] getclasa

readend forIntroducerea datelor se poate realiza vizual

folosind oricare din editoarele Browse sau Edit, utilizndopiunile meniului View.

Salvarea informaiilor se poate realiza folosind


34/104

34

combinaia de taste Ctrl + Wsau executnd clic pe butonul de nchidere al ferestrei deeditare.

Pentru adugarea vizuala de nregistrri vide la sfritul unei tabele se poateutiliza opiunea AppendNew Recorddin meniul Tablesau opiunea Append Modedinmeniul View.

B) Modificarea datelor

Comanda REPLACEeste utilizat pentru modificarea valorilor din ultima tabelselectat cu expresii ce pot fi evaluate n momentul executrii comenzii:

Forma general a comenzii REPLACEeste:REPLACE WITH [, WITH ]

[domeniu] [FOR ] [WHILE ]

Pentru actualizarea i vizualizarea datelor poate fi utilizat i comandaBROWSEcare va afia tabela activ pe linii i pe coloane (pe prima linie sunt afiatedenumirile cmpurilor din structura tabelei, iar n continuare sunt afiate liniile cu date).

C. Exemplificare n limbajul de programare ORACLE

A) Introducerea datelor

Comanda INSERT este utilizat pentru introducerea unei noi nregistrri ntr-otabel. Sintaxa general a acestei comenzi este:

INSERT INTO[(nume_coloan1, [nume_coloan2, ... ])]VALUES(expresie1, expresie2, ... )Pentru adugarea unui nou articol poate fi utilizat metoda explicit (cnd sunt

specificate explicit cmpurile ce vor fi completate cu valorile din clauza VALUES) saumetoda implicit (cnd nu se specific niciun cmp dar se cunoate structura tabelei icmpurile sunt completate cu valorile corespunztoare din clauza VALUES).

B) Modificarea datelor

Pentru modificarea valorilor existente ntr-un tabel se utilizeaz comanda

UPDATEcare are urmtoarea sintax general:UPDATESETnume_coloan1 = expresie1,

nume_coloan2 = expresie2,......

nume_coloann = expresien[WHEREcondiie]

Vom reveni asupra codului SQL.

2. INTEROGAREA BAZELOR DE DATE

2.1. Generaliti

Pentru utilizator, o interogare este o metod de a regsi anumite informaiidintr-o baz de date, prin intermediul unei aplicaii de baze de date. Din punctul devedere al programatorului aplicaiei de baze de date, interogarea se exprim printr-ocomand echivalent expresiei de interogare, comand care se transmite sistemuluiSGBD.


35/104

35

Din punct de vedere al sistemului de gestiune, o interogare este un program(de exemplu, n limbajul SQL8) pe care l compileaz i apoi l execut. Ca oriceprogram, o interogare este prelucrat de ctre SGBD n mai multe faze: analizalexical, analiza sintactici analiza semantic, pentru validarea interogrii, urmate degenerarea codului. De asemenea, dac exist mai multe soluii pentru aceeaiinterogare, sistemul de gestiune selecteaz soluia optim.

Conceptual, subsistemul SGBD de prelucrare a interogrilor const dinurmtoarele componente: Compilatorul de interogri, care efectueaz analiza lexical i sintactic ainterogrii; acesta valideaz din punct de vedere sintactic interogarea, adic verificexistena relaiilor, a vederilor, a indexurilor i a atributelor implicate n interogare iutilizarea corect a acestora. Optimizatorul de interogri, care efectueaz analiza semantic a interogrii iselecteaz alternativa optim dintre mai multe soluii posibile de execuie a interogrii. Generatorul de cod, care genereaz programul de execuie al interogrii,conform optimizrilor efectuate. Componenta de execuie (runtime), care execut programul interogrii.

Compilarea interogrii se realizeaz la fel ca orice compilare a programelor,fr aspecte specifice sistemelor de baze de date. Optimizarea interogrilor este o

operaie specific sistemelor de gestiune i utilizeaz proprietile operaiilor relaionalepentru a obine performane de execuie a interogrilor ct mai bune. Optimizarea esteefectuat de ctre SGBD, transparent, fr intervenia programatorului.

Interogarea (query) este operaia prin care se obin datele dorite dintr-o bazde date, selectate conform unui anumit criteriu (condiie). Dat fiind c operaia deinterogare este cea mai important operaie de manevrare a datelor, de multe orilimbajele de manevrare a datelor sunt denumite limbaje de interogare.

Pentru formularea conceptual a interogrilor n bazele de date relaionale s-au dezvoltat dou limbaje abstracte de interogare: algebra relaional i calcululrelaional. Algebra relaional (relational algebra) const dintr-o mulime de operaii careau ca operanzi relaii, iar rezultatul este tot o relaie. Calculul relaional (relational calculus) este bazat pe calculul predicatelor i

exprim o interogare formulnd o definiie a rezultatului dorit (de regul, o relaie)printr-o expresie de calcul relaional.Limbajele de interogare reale implementate n sistemele de baze de date

relaionale sunt limbaje definite pe baza unuia sau altuia din limbajele de interogareabstracte, sau pe o combinaie a acestora. Astfel: Limbajul SQL este n cea mai mare parte bazat pe algebra relaional, darmai conine i construcii derivate din calculul relaional. Limbajul ISBL (Information System Base Language) al firmei IBM este bazatn ntregime pe algebra relaional. Limbajul QUEL al SGBD Ingres este bazat pe calculul relaional al tuplurilor. Limbajul QBE (Query by Example), dezvoltat la firma IBM este bazat pecalculul relaional al domeniilor.

Un limbaj de interogare real este denumit rela ional complet dacimplementeaz toate operaiile prevzute de unul din limbajele de interogare abstracte.n general, toate limbajele relaionale implementate n sistemele SGBD sunt limbaje

8 SQL (Structured Query Language) este un limbaj specializat pentru interogarea,

actualizarea si administrarea bazelor de date relationale. Ca sintaxa, instructiunile SQLse termina cu ; (punct si virgula) iar parametrii din listele de parametri sunt separati prin, (virgula). SQL fiind un limbaj structurat clauzele care compun instructiunile saletrebuie sa respecte ordinea impusa de sintaxa.


36/104

36

relaionale mai mult dect complete, coninnd i operaii care nu sunt prevzute nlimbajele relaionale abstracte, ca de exemplu, efectuarea unor calcule aritmeticeasupra valorilor unor atribute (sum, medie, minim, maxim), funcii de tiprire arelaiilor, etc.

Limbajul SQL este limbajul cel mai utilizat n sistemele relaionale.

2.2. Codul SQL

Ilustram codul SQL cu ajutorul unei baze de date Ms Access,AssistRom.mdb:

Instructiunea SELECT

Efect:

Se returneaza informatia ceruta sub forma unui set de inregistrari.

Sintaxa:

SELECT [predicat] { * | tabel.* | [tabel.]camp1 [AS alias1] [, [tabel.]camp2[AS alias2] [, ...]]}FROM expresie_tabel [, ...] [IN baza_de_date_externa][WHERE... ][GROUP BY... ][HAVING... ][ORDER BY... ][WITH OWNERACCESS OPTION]

Instructiunea SELECT are urmatoarele parti:

predicat


37/104

37

este unul dintre urmatoarele predicate: ALL, DISTINCT, DISTINCTROW, sau TOP.Predicatul folosit determina o restrictionare a numarului de inregistrari returnate. Dacanu este specificat, se ia implicit predicatul ALL;*(asterisc)indica faptul ca trebuie selectate toate campurile din tabelele specificate;tabel

numele tabelului care contine campurile care intereseaza pentru selectia inregistrarilor;camp1, camp2numele campurilor care contin datele ce trebuie returnate. Daca sunt indicate maimulte campuri, atunci datele acestora sunt returnate conform ordinii din lista decampuri;alias1, alias2nume de coloane care pot fi folosite ca antete pentru campuri in locul antetelorrespective din tabel;expresie_tabel

o expresie care identifica unul sau mai multe tabele din care vor fi returnate date.Expresia poate fi un nume unic de tabel, numele unei interogari deja salvate sau ocombinatie obtinuta prin oricare dintre cele 3 tipuri de asociere: INNER JOIN, LEFT

JOIN, sau RIGHT JOIN;baza_de_date_externanumele BD care contine tabelul / tabelele specificate in expresie_tabel, daca acesteanu fac parte din BD curenta;

Sintaxa minimala pentru instructiunea SELECT este:SELECT campuri FROM tabel;

Clauzele WHERE,GROUP BY, HAVING, ORDER BY si WITH OWNERACCESSOPTION au rolul de a organiza setul de inregistrari returnate si de a introduce restrictiisuplimentare asupra acestuia. Astfel,

daca trebuie eliminate inregistrarile duplicate sau afisate numai o parte dintreinregistrari etc., atunci trebuie introdus un predicat adecvat: DISTINCTROW, TOPnetc., daca trebuie afisate valorile unui camp atunci numele acestuia trebuie inserat dupaverbul SELECT, in lista_de_campuri; daca mai multe campuri din tabele diferite auacelasi nume ele atunci numele lor va fi precedat de numele tabelului, daca interogarea se bazeaza pe un tabel si / sau interogare deja creata atuncinumele acestuia trebuie sa fie inclus in expresia_tabel a clauzei FROM, daca inregistrarile returnate de interogare trebuie filtrate atunci criteriile de filtrare seintroduc prin clauza WHERE, daca trebuie efectuata o grupare a inregistrarilor si o filtrare a inregistrarilor grupateatunci campul sau campurile dupa care se grupeaza se introduc prin clauza GROUPBY iar criteriile de filtrare prin clauza HAVING, daca inregistrarile returnate de interogare trebuie sortate atunci campul-cheie desortare si ordinea de sortare se indica in clauza ORDER BY, daca proprietarul BD se schimba atunci trebuie indicata noua valoare, Owners, inclauza WITH_OWNERACCESS_OPTION.


38/104

38

Modul de lucru

Programul parcurge tabelul / tabelele specificate in parametrul expresie_tabel, extragecoloanele indicate in parametrii camp1, camp2 etc., selecteaza inregistrarile careverifica criteriul de selectie si sorteaza sau grupeaza inregistrarile rezultate in ordineaspecificata.

Observatie

Instructiunile SELECT este specifica interogarilor simple (de selectie); ea nu modificadatele din BD. Verbul SELECT este, de obicei, primul cuvant dintr-o instructiune SQL.Cele mai frecvent folosite instructiuni SQL sunt SELECT si SELECT INTO.

Exemple

Afisarea numelui si prenumelui clientilor firmei AsistRomSELECT NumeClient, Prenume FROM Clienti;

Utilizarea asteriscului pentru a selecta toate campurile dintr-un tabel.

In exemplul de mai jos se selecteaza toate campurile din tabelul ClientiSELECT * FROM Clienti;

Utilizarea operatorului . (punct) pentru cazul in care tabelele din clauza FROM contincampuri cu acelasi nume. Atunci, toate campurile care apar in instructiunea SELECTtrebuie insotite de numele tabelului din care provin.In exemplul de mai jos campul CodCentru apare si in tabelul Clienti si in tabelulCentreCons; instructiunea SQL trebuie sa selecteze numele clientilor din tabelulClienti si denumirea completa a centrului din tabelul CentreCons (vezi codul SQL alinterogarii Q_SubQuery_Clienti_CentreCons din BD AsistRom )

SELECT DISTINCTROW Clienti.CodClient, Clienti.NumeClient,Clienti.Prenume,

(SELECT [NumeCentru] FROM [CentreCons]WHERE [Clienti].[CodCentru] = [CentreCons].[CodCentru])

AS [Centrul de Consultanta]

FROM CentreCons INNER JOIN ClientiON CentreCons.CodCentru = Clienti.CodCentru;

Utilizarea clauzei AS pentru crearea in RecordSet (setul de inregistrari intoarse deinterogare) a unui nume de camp diferit de cel din tabel.In exemplul de mai jos campul TelefonAcasa capata in RecordSet numeleNrTelefon

SELECT Clienti.TelefonAcasa AS NrTelefon FROM Clienti;Aceasta manevra este recomandata mai ales in cazul utilizarii in interogare a functiilor

predefinite din categori Total sau a criteriilor care returneaza rezultate ambigui sauduplicate. Clauza AS creeaza un nume alternativ pentru campulrezultat intors deinterogare. In exemplul de mai jos, clauza AS atribuie numele TotalNrClienti campuluiin care se face numararea acestora

SELECT COUNT(CodClient) AS TotalNrClienti FROM Clienti;

Utilizarea clauzei AS pentru duplicarea unui camp in vederea efectuarii unor calcule.In exemplul de mai jos, pretul actual al caietelor produse este returnat in campuldenumit CostActual iar in campul CostPropus este afisat noul pret al caietelor daca


39/104

39

pretul unitar creste cu 10% (vezi codul SQL al interogarii Q_AS_Produse din BDAsistRom )

SELECT Produse.CodFirma, Produse.CodProdus, Produse.NumeProdus,Produse.PretUnitar, Produse.Cantitate, [PretUnitar] * [Cantitate] AS Cost,[Cost]*1.1 AS CostPropus FROM Produse;

In exemplul de mai jos sunt numarate produsele din tabelul Produse si este calculatpretul unitar mediu si pretul unitar maxim (vezi Q_CountAvgMax_Produse din BDAsistRom )

SELECT Count(*) AS NrTotalProduse, Avg(PretUnitar) AS [Pret UnitarMediu], Max([PretUnitar]) AS [Pret Unitar Maxim] FROM Produse;

Includerea unui text intre valorile numerice returnate.In exemplul urmator sunt afisate pentru fiecare produs din tabelul Produse numele sipretul sau unitar (aflate in campurile NumeProdus, respectiv PretUnitar), separatede secventa are urmatorul pret unitar (vezi Q_ConcatText_Produse din BDAsistRom )

SELECT NumeProdus, 'are urmatorul pret unitar, PretUnitar FROMProduse;

Definirea unui filtru de selectie pentru inregistrarile returnate.In exemplul urmator sunt afisate numele si prenumele clientilor absolventi aiUniversitatii din Bucuresti

SELECT [Prenume], [NumeClient] FROM [Clienti]WHERE [Studii] = "Univ.Bucuresti";

In exemplul urmator sunt afisate numele si prenumele clientilor din tabelul Clienti careau apelat la un centru de consultanta al carui cod se afla printre codurile din formularuldeschis CentreConsNoi

SELECT [Prenume], [NumeClient] FROM [Clienti]WHERE [CodCentru] = Forms![CentreConsNoi]![CodCentru];

Selectarea inregistrarilor in vederea efectuarii unui calcul.In exemplul urmator este calculat pretul unitar mediu numai pentru produsele al carorpret unitar depaseste valoarea 5; acest pret mediu este afisat in campul nou creatnumit PretulUnitarMediuPeste5

SELECT Avg([PretUnitar]) AS [PretulUnitarMediuPeste5]FROM [Produse] WHERE [PretUnitar] > 5;

Gruparea inregistrarilor in vederea efectuarii unui calcul la nivelul fiecarui grup deinregistrari, dupa ce au fost eliminate inregistarile care nu verif ica un criteriu de selectieanumit.In exemplul urmator este calculat pretul unitar mediu al produselor al caror pret unitardepaseste valoarea 5 la nivelul fiecarei firme (veziQ_GroupBy_Where_Produse_Firma din BD AsistRom )

SELECT Produse.CodFirma, Count(Produse.CodFirma) AS NumarProduse,Avg(Produse.PretUnitar) AS PretulUnitarMediuPeste5 FROM Produse

WHERE (((Produse.PretUnitar) > 5))

GROUP BY Produse.CodFirma;

Gruparea inregistrarilor in vederea efectuarii unui calcul la nivelul fiecarui grup deinregistrari si efectuarea acestui calcul numai pentru grupurile de inregistrari careverifica un criteriu de selectie anumit.


40/104

40

In exemplul urmator este calculat numarul total de produse fabricat de fiecare firma,numai daca firma respectiva produce cel putin doua sortimente distincte (veziQ_GroupBy_Having_Produse din BD AsistRom )

SELECT Produse.CodFirma, Count([Produse].[CodFirma]) ASNumarProduse

FROM ProduseGROUP BY Produse.CodFirma

HAVING Count ([CodFirma]) >= 2;

Clauza FROM

Efect

Specifica tabelele sau interogarile care contin campurile enumerate in instructiuneaSQL.

Sintaxa

SELECT lista_de_campuriFROM expresie_tabel [, ...] [IN baza_de_date_externa]

O instructiune SELECT care foloseste clauza FROM are urmatoarele parti:lista_de_campurinumele campurilor (inclusiv alias-uri) folosite in interogare si, eventual: functiipredefinite SQL, predicate de selectie SQL (ALL, DISTINCT, DISTINCTROW, or TOP)sau alte optiuni ale instructiunii SELECT

expresie_tabel

o expresie care identifica unul sau mai multe tabele din care vor fi returnate date.Expresia poate fi un nume unic de tabel, numele unei interogari deja salvate sau ocombinatie obtinuta prin oricare dintre cele 3 tipuri de asociere: INNER JOIN, LEFTJOIN, sau RIGHT JOIN;

baza_de_date_externa

drumul complet catre BD externa care contine toate tabelele din expresia_tabel.

Observatii

Clauza FROM este obligatorie pentru orice instructiune SELECT;Ordinea numelor tabelelor in expresia-tabel nu este semnificativa;

Exemple

Afisarea numelui si prenumelui clientilor din tabelul Clienti SELECT Prenume, NumeClientFROM Clienti;

Afisarea tuturor informatiilor despre clienti (deci a tuturor campurilor din tabelulClienti)

SELECT * FROM Clienti;

Numararea clientilor (deci a valorilor din campul CodCentru din tabelul Clienti);rezultatul este depus in campul NrTotalClienti

SELECT Count(CodCentru) AS NrTotalClienti FROM Clienti;


41/104

41

Calculul noului pret unitar al produselor firmelor-client in urma aplicarii unei cresteri de10% (in tabelul Produse valorile din campul PretUnitar preturile actuale ramanneschimbate)

SELECT Produse.CodFirma, Produse.CodProdus, Produse.NumeProdus,Produse.Cantitate, Produse.PretUnitar AS PretActual,PretUnitar * 1.1 AS PretPropus FROM Produse;

Evident interogarea poate fi parametrizata si poate returna diferite preturi unitarepentru diferite procente (vezi interogarea QProduse_From din BD AsistRom )

SELECT Produse.CodFirma, Produse.CodProdus, Produse.NumeProdus,Produse.Cantitate, Produse.PretUnitar AS PretActual, [Procent] AS

[P%], [PretUnitar] * [Procent] AS PretPropusFROM Produse WHERE ((([Procent]) = [Indicati procentul]));

Inserarea unui text explicativ intreantetele unor campuri SELECT Firma.NumeFirma, 'are ',Firma.NrSalariati, 'salariati' FROMFirma;

Clauza IN

EfectIdentifica tabele in orice BD externa creata cu o aplicatie compatibila cu MS Access:FoxPro, dBASE etc.

Sintaxa pentru identificarea unui tabel-destinatie[SELECT | INSERT] INTO destinatie IN{drum | ["drum" "tip"] | ["" [tip; DATABASE = drum]]}

Sintaxa pentru identificarea unui tabel-sursaFROM expresie_tabel IN{drum| ["drum" "tip"] | ["" [tip; DATABASE = drum]]}

O instructiune SELECT care contine o clauza IN are urmatoarele parti:destinatienumele bazei de date externe in care sunt inserate informatiile;expresie_tabelo expresie care identifica unul sau mai multe tabele din care vor fi returnate date.Expresia poate fi un nume unic de tabel, numele unei interogari deja salvate sau o


42/104

42

combinatie obtinuta prin oricare dintre cele 3 tipuri de asociere: INNER JOIN, LEFTJOIN, sau RIGHT JOIN;

drumdrumul complet catre directorul sau fisierul care contine tabelul;tipextensia specifica aplicatiei cu care a fost creata BD externa, daca este alta decat MS

Access.Predicatele ALL, DISTINCT, DISTINCTROW, TOPEfectSpecifica inregistrarile selectate de interogarile SQLSintaxaSELECT [ALL | DISTINCT | DISTINCTROW | [TOP n [PERCENT]]]FROM tabel

O instructiune SELECT care foloseste aceste predicate are urmatoarele parti:ALLEste predicatul implicit. Programul selecteaza toate inregistrarile care indeplinesccriteriul specificat in instructiunea SQL.

Urmatoarele instructiuni SQL sunt echivalente si returneaza toate inregistrarile dintabelul CentreCons (ordonate dupa valorile campului CodCentru)

SELECT ALL * FROM CentreCons ORDER BY CodCentru;SELECT * FROM CentreCons ORDER BY CodCentru;

DISTINCTOmite inregistrarile care contin aceleasi date in campurile selectate (pentru a fi inclusein RecordSet, valorile campului din instructiunea SELECT trebuie sa fie unice; dacaapar mai multe campuri in instructiunea SELECT atunci combinatia valorilor lor pentrufiecare inregistrare trebuie sa fie unica).De exemplu, trebuie verificat daca fiecare centru de consultanta este activ (are celputin un client). Vom folosi urmatoarele premize: in tabelul Clienti exista un campnumit CodCentru care contine codul centrului de consultanta la care s-a inregistratclientul (deci, vom baza interogarea pe tabelul Clienti); o inregistrare dintr-un tabel

este considerata fara duplicate (unica) numai in cazul in care combinatia valorilor dintoate campurile sale este unica la nivelul intregului tabel (deci, dintre toate campuriletabelului Clienti vom include in interogare numai campul CodCentru); un camp dintr-un tabel este considerat cu valori unice numai daca oricare dintre valorile sale nu serepeta in nici-o inregistrare din tabel (deci, vom specifica in instructiunea SELECTpredicatul DISTINCT). Prin urmare, se foloseste codul:

SELECT DISTINCT CodCentru FROM Clienti;Daca se elimina predicatul DISTINCT atunci sunt returnate toate valorile (cu duplicate

cu tot) din campul CodCentru.

DISTINCTROW

Omite inregistrarile duplicate, nu numai pe cele care contin campuri duplicate.Problema de mai sus, listarea centrelor de consultanta care au cel putin un client poatefi rezolvata mai complicat - si astfel: stiind ca tabelul CentreCons nu contineinregistrari duplicate dar tabelul Clienti contine, se creeaza o interogare pe bazatabelelor CentreCons si Clienti si se foloseste o instructiune SELECT cu predicatulDISTINCTROW, adica

SELECT DISTINCTROW NumeCentru

FROM Clienti INNER JOIN CentreConsON Clienti.CodCentru = CentreCons.CodCentru


43/104

43

ORDER BY NumeCentru;Daca se omite parametrul DISTINCTROW, interogarea produce, pentru fiecare centru,atatea inregistrari cati clienti are centrul respectiv.

TOP n [PERCENT]Returneaza un anume numar de inregistrari aflate pe primele sau pe ultimele locuri aleunui set de inregistrari specificate intr-o clauza ORDER BY.

Sa presupunem ca trebuie returnate primele 2 firme din Bucuresti care au cel mai marenumar de angajati (ve

Date post:	03-Apr-2018
Category:	Documents
Upload:	ionel-gherasim
View:	226 times
Download:	0 times

Sist Gestiune Baze de Date

Documents